Lineage, auditlogs en systeemtabellen

Governance zonder bewijs is een beleidsdocument

Een rechtenmodel zegt wie toegang zou moeten hebben. Auditors, securityteams en je eigen incidentreviews stellen een andere vraag: wie heeft het werkelijk gebruikt, wat is er veranderd en waar komt dit getal vandaan? Unity Catalog antwoordt met twee soorten bewijs: lineage, die vastlegt hoe data stroomt, en auditlogs, die vastleggen wie wat deed. Beide zijn als systeemtabel te bevragen.

In deze les gebruiken we lineage voor impactanalyse, auditlogs voor toegangsvragen en systeemtabellen om een kleine set governancecontroles te bouwen die volgens schema draaien. Logs doorsturen naar een extern SIEM behandelen we niet.

Lineage

De documentatie zegt dat Unity Catalog automatisch lineage vastlegt voor queries die op Databricks draaien en die over alle workspaces aggregeert die aan de metastore zijn gekoppeld. Hij volgt tabellen, views, kolommen, ML-modelversies en bestandspaden. Notebooks, jobs en dashboards verschijnen als afnemers van een tabel. In Catalog Explorer toont het tabblad Lineage van een tabel de jobs en dashboards stroomafwaarts en de lineagegraaf toont verbindingen op kolomniveau.

Je instrumenteert niets. Leest je pipeline bronze.orders_raw en schrijft hij silver.orders, dan bestaat de verbinding.

Drie toepassingen verdienen de moeite terug:

1. Impactanalyse vóór een wijziging. "Als ik deze kolom hernoem, welke tabellen, jobs en dashboards breken dan?" Kijk naar stroomafwaartse lineage voor je merget.
2. Oorzaakanalyse bij een incident. "Dit goldgetal is fout." Loop stroomopwaarts naar de eerste tabel waar de waarde afwijkt.
3. Bewijs bij privacyvragen. "Waar eindigt dit persoonsgegeven?" Kolomlineage beantwoordt het en vormt de basis van een verwerkingsregister.

Bevraag het

Lineage is ook beschikbaar in de systeemtabellen system.access.table_lineage en system.access.column_lineage, dus je kunt hem in SQL analyseren. De documentatie zegt dat ze standaard een rollend venster van 395 dagen bewaren, terwijl de lineage in Catalog Explorer onbeperkt wordt bewaard, vanaf 1 september 2024.

-- Schematisch: welke doelen zijn de afgelopen 90 dagen uit een gegeven brontabel gebouwd?
-- Controleer de exacte kolomnamen in je workspace met DESCRIBE system.access.table_lineage.
SELECT DISTINCT target_table_full_name
FROM   system.access.table_lineage
WHERE  source_table_full_name = 'prd_finance.silver.invoices'
  AND  event_date >= current_date() - INTERVAL 90 DAYS
  AND  target_table_full_name IS NOT NULL;

Ken de beperkingen

De documentatie noemt beperkingen die veranderen wat je kunt beweren:

• Lineage van vóór 1 september 2024 is niet beschikbaar.
• Jobs die via het Jobs API-verzoek runs submit of het tasktype spark submit zijn ingediend, tonen geen koppeling met de jobrun.
• Lineage blijft niet behouden als catalogs, schema's, tabellen, views of kolommen worden hernoemd.
• RDD's, globale tijdelijke views en information_schema-tabellen worden niet vastgelegd.
• Lineage via tijdelijke tabellen negeert UPDATE-, DELETE- en MERGE INTO-wijzigingen.
• Kolomlineage wordt niet getoond voor padgebaseerde verwijzingen, hoewel de systeemtabel ze wel vastlegt.
• User-defined functions worden alleen op tabelniveau vastgelegd.

Gebruik lineage als sterk bewijs, niet als garantie. Een ontbrekende verbinding betekent "niet vastgelegd" en bewijst niet dat er geen stroom bestaat. Bouw je een verwerkingsregister voor een toezichthouder, zeg dan hoe het is gemaakt.

Auditlogs

Auditgebeurtenissen landen in system.access.audit. De documentatie beschrijft de kolommen die je het meest gebruikt:

Twee feiten tellen als je erop leunt. De meeste auditlogs zijn alleen beschikbaar in de regio van de workspace en gebeurtenissen op accountniveau leggen workspace_id vast als 0. En als een workspace wordt verwijderd, worden de auditgebeurtenissen ouder dan 14 dagen uit de tabel verwijderd, dus exporteer wat je bewaarbeleid vraagt voor je er een buiten gebruik stelt.

Een beginquery, gebouwd uit de gedocumenteerde kolommen:

-- Schematisch: wie las de afgelopen 7 dagen een tabel en slaagde het verzoek?
-- Actienamen en request_params-sleutels verschillen per gebeurtenistype: bekijk eerst een paar rijen.
SELECT event_time,
       user_identity.email,
       action_name,
       response.statusCode
FROM   system.access.audit
WHERE  event_date >= current_date() - INTERVAL 7 DAYS
  AND  service_name = 'unityCatalog'
  AND  action_name  = 'getTable'
ORDER  BY event_time DESC;

Lees een paar ruwe rijen voor je een filter schrijft. De waarden van action_name en de sleutels in request_params hangen af van de gebeurtenis en je query moet gebaseerd zijn op wat jouw workspace werkelijk uitstuurt.

Vragen die het bewijs beantwoordt

De laatste rij voedt de kwartaalreview van toegang uit les 3: verwijder wat nooit wordt gebruikt.

Governancecontroles als code

Zet de vragen om in geplande queries, met een eigenaar zoals elke pipeline en met alerts bij treffers. Een korte lijst om mee te beginnen:

• Directe rechten aan gebruikers. Lijst rechten op waarvan de principal een persoon is en geen groep. Het doel is nul.
• Eigenaren die personen zijn. Dezelfde controle op eigenaarschap.
• Toegang tot gevoelige tabellen door niet-leden. Vergelijk auditreads op gevoelige tabellen met de toegestane groepen.
• Wijzigingen in het securityschema. Alarmeer bij elke wijziging van filter- en maskerfuncties.
• Ongewoon volume. Een principal die veel meer leest dan gebruikelijk.

Draai deze in de platformrepository, rol ze uit via de bundle en stuur alerts naar de platformeigenaarsgroep. Dit toont governance ook aan een klant: je kunt de controles, de laatste run en de alerts laten zien. Onze case over self-service data-onboarding bij het RIVM beschrijft hoe beheerde onboarding schaalt als de controles onderdeel van het platform zijn.

Bewaartermijn en privacy van het bewijs

Auditlogs en lineage bevatten persoonsgegevens, zoals e-mailadressen van gebruikers. Pas onze privacyregels toe op je eigen bewijs: beperk wie de tabellen mag lezen, stel een bewaartermijn in en exporteer alleen wat je nodig hebt. De audittabel hoort bij de gevoeligste data van het platform.

Veelgemaakte fouten

• Lineage als volledig lezen. Controleer de beperkingen.
• Filteren op event_time in plaats van event_date. Trage queries.
• Een query schrijven voor je naar de data hebt gekeken. Gebeurtenisvormen verschillen.
• Controles met de hand draaien. Plan ze en alarmeer.
• De regionale scope vergeten. Auditlogs zijn grotendeels per regio.

Samenvatting

Gebruik lineage voor impact, oorzaak en privacyvragen en auditlogs voor toegangsvragen. Bevraag de systeemtabellen, respecteer de gedocumenteerde beperkingen en zet je governanceregels om in geplande controles met eigenaren.

Volgende les: data veilig delen met andere organisaties zonder de controle te verliezen.