Data governance in Azure Databricks
Hoe richt je toegangsbeheer in met Unity Catalog?
- Artikel
- Data Engineering
- Data governance
- Databricks
Het is een patroon dat zich met regelmaat herhaalt: een organisatie meldt een datalek, klantgegevens liggen op straat, en de discussie die volgt gaat al snel over firewalls, verouderde software en kwaadwillende aanvallers.
Wat in die nasleep minder vaak wordt benoemd, is wat er daarna boven water komt: gebruikers die toegang hadden tot data die ze nooit hadden mogen zien. Niet omdat een aanvaller ze die toegang gaf, maar omdat de governance simpelweg niet op orde was.
In de vorige artikelen van deze reeks bespraken we waarom data governance belangrijk is, hoe je governance organisatorisch inricht en hoe je deze principes toepast binnen een data- & AI-platform. In dit laatste deel maken we de stap naar de technische implementatie.
Dát is het vraagstuk waar dit artikel over gaat. Meer specifiek zoomen we in op hoe data governance kan worden ingericht binnen Azure Databricks: van het beheren van gebruikers en rollen, tot het inrichten van fine-grained access control en het bijhouden van de audit trail die dit alles verifieerbaar maakt.
Deze artikelreeks bestaat uit vier artikelen:
- Waarom je niet langer kunt wachten met data governance
- In 3 stappen naar effectieve data governance
- In 5 stappen grip op data governance voor je data- & AI-platform
- (Huidig artikel) Data governance in Azure Databricks
*De principes die hier worden behandeld zijn breed toepasbaar, maar de tooling en voorbeelden zijn gebaseerd op het Databricks-ecosysteem en Unity Catalog.
Wie heeft er eigenlijk toegang tot de data?
Welke gebruiker mag welke tabel lezen? Wie heeft rechten gekregen voor een tijdelijk project, en zijn die daarna weer ingetrokken? Is er iemand met toegang tot klantdata waarvoor geen zakelijke reden meer bestaat?
Het zijn vragen die veel organisaties niet direct scherp kunnen beantwoorden. En dat is precies waar het risico ligt.
Een medewerker vertrekt. Het account wordt netjes uitgeschakeld in Active Directory, maar de directe permissies die diezelfde medewerker ooit heeft gekregen op een specifiek Databricks-schema, zijn nooit opgeruimd. Of een data scientist krijgt tijdelijk toegang tot een gevoelige dataset voor een analyse, maar omdat niemand een vervaldatum heeft ingesteld, is die toegang anderhalf jaar later nog altijd actief.
Geen kwaadwillende gebruiker, geen cyberaanval. Wel toegangsrechten die ongemerkt blijven bestaan.
Waarom data governance in Databricks steeds urgenter wordt
Waar data vroeger het domein was van een kleine groep specialisten, is het inmiddels beschikbaar voor een breed scala aan gebruikers binnen de organisatie. Waar een analist vroeger een IT-ticket moest indienen om bij een dataset te komen, communiceert diezelfde analist nu via een LLM rechtstreeks met ruwe data. Dat is een betekenisvolle stap vooruit in productiviteit, maar het vergroot ook het oppervlak van wat er mis kan gaan. Als de toegangsrechten onderliggend niet kloppen, tilt een moderne interface dat probleem gewoon mee naar boven.
Hoe meer gebruikers toegang krijgen tot meer data via meer tools, hoe groter de impact van onduidelijke governance wordt. Het is dan ook geen vraagstuk dat kan wachten totdat het data platform "wat stabieler" is of er in een volgende fase ruimte voor vrijkomt. Governance hoort vanaf het begin onderdeel te zijn van de inrichting, niet een laag die er achteraf overheen wordt gelegd.
Eigenaarschap: de organisatorische kant van data governance
Dit is de vraag die in de praktijk het vaakst onbeantwoord blijft. Wie beheert het datamodel? Wie bepaalt welke definitie van "klant" de correcte is? En wie houdt bij wie toegang heeft tot welke dataset, en waarom?
Technische inrichting lost dat niet automatisch op. Een prachtig rollenmodel dat niemand actief beheert, is binnen een jaar achterhaald.
Governance is daarom niet alleen een technisch vraagstuk, maar ook een organisatorisch vraagstuk. Een belangrijk uitgangspunt is dat het eigenaarschap over toegangsbeslissingen bij de data-eigenaren ligt, en niet bij het platformteam. De mensen die het dichtst bij de data staan en de zakelijke context begrijpen, zouden moeten bepalen wie er toegang toe krijgt.
SCIM, RBAC en ABAC: gebruikersbeheer en toegangsbeheer gescheiden houden
Een onderscheid dat vaak over het hoofd wordt gezien, is het verschil tussen identiteitsbeheer en toegangsbeheer.
Gebruikers en groepen moeten vanuit de identity provider van de organisatie worden gesynchroniseerd naar Databricks via SCIM (System for Cross-domain Identity Management). Dankzij SCIM-integratie blijft de toegang tot Databricks automatisch in lijn met het centrale IAM-systeem wanneer medewerkers in dienst komen of uit dienst gaan. Dit is doorgaans een verantwoordelijkheid op platformniveau, beheerd via Terraform of een vergelijkbaar infrastructuurtool, en ligt bij het platformteam.
Permissies bepalen vervolgens waar die gebruikers en groepen daadwerkelijk toegang toe hebben. En daar komt de rol van de data-eigenaar in beeld. Binnen Databricks zouden permissies altijd moeten worden toegekend aan gesynchroniseerde groepen, en niet aan individuele gebruikers.
Er zijn twee veelgebruikte modellen:
Role-based access control (RBAC)
Bij RBAC worden rechten gekoppeld aan een rol of team. Zo kan een groep met de naam data-analysts SELECT-rechten krijgen op een specifieke catalog.
Attribute-based access control (ABAC)
Bij ABAC worden rechten dynamisch toegepast op basis van attributen en tags. Zo kunnen kolommen die zijn gemarkeerd als persoonlijk identificeerbare informatie (PII) automatisch worden gemaskeerd voor gebruikers buiten een specifieke afdeling.
ABAC wordt vooral waardevol op grotere schaal, wanneer het handmatig beheren van permissies op tabelniveau steeds complexer wordt.
Ongeacht welk model wordt gekozen, blijft de groep de centrale eenheid voor toegangsbeheer. Het toekennen van permissies aan individuele gebruikers leidt juist tot het soort ongecontroleerde en lastig te auditen toegang dat op termijn problemen veroorzaakt.
Databricks system tables gebruiken voor toegangsaudit
Ongeacht hoe toegang wordt ingericht, moet er een manier zijn om de vraag te beantwoorden die security- en compliance-teams altijd stellen: wie heeft er op dit moment toegang tot onze gevoelige data?
Databricks system tables bieden precies dat. Dit zijn querybare audittabellen die zijn ingebouwd in Unity Catalog en een gestructureerd overzicht geven van wie welke permissies heeft gekregen op catalogs, schema's en tabellen, inclusief data lineage metadata die laat zien hoe data assets zich door de tijd heen hebben bewogen en getransformeerd. Wanneer de CISO binnenloopt en vraagt wie er toegang heeft tot de financetabellen, zijn system tables het startpunt voor dat antwoord.
SELECT
grantee,
privilege_type,
object_name,
object_type
FROM system.information_schema.table_privileges
WHERE object_name = 'finance_transactions'Het is belangrijk te benadrukken dat system tables zichtbaarheid bieden, geen controle. Ze tonen wat er is ingericht, maar vervangen niet de behoefte aan een goed gestructureerd proces om die toegang in de eerste plaats in te richten. Beide zijn noodzakelijk en dienen een ander doel.
Purview, Collibra and Alation: governance catalogues versus toegangsbeheer
Tools als Microsoft Purview, Collibra en Alation worden soms gepositioneerd als het antwoord op data governance. Ze zijn zeker waardevol, maar het is belangrijk te begrijpen wat ze daadwerkelijk doen.
Deze platforms bieden primair een gebruiksvriendelijke front-end die het makkelijker maakt om te zien welke dataproducten er bestaan en waar ze te vinden zijn. Ze zijn bijzonder sterk in omgevingen met meerdere data platforms of tools, omdat ze goed integreren over het landschap heen en een uniform overzicht bieden.
Wat ze niet vervangen, is het onderliggende proces van hoe toegang wordt ingericht. Dat proces is wat er werkelijk toe doet voor de governance- en securityteams. Een organisatie met een nette Purview-catalogus maar slecht beheerde permissies in Databricks heeft zichtbaarheid zonder controle. De tooling rondom catalogisering en de tooling rondom toegangsinrichting zijn complementair, niet uitwisselbaar.
Drie manieren om toegang in te richten in Azure Databricks met Unity Catalog
Met het onderscheid tussen gebruikers, groepen en permissies in het achterhoofd, wordt de praktische vraag: hoe moeten permissies daadwerkelijk worden ingericht? Binnen Azure Databricks zijn er drie hoofdbenaderingen. Ze verschillen in technische complexiteit, in wie ze realistisch gezien kan beheren, en in hoe goed ze het principe ondersteunen dat data eigenaren, niet het platform team, de controle moeten hebben.
1. Terraform: het beste voor platform-brede governance
Terraform is de natuurlijke plek voor alles wat op infrastructuurniveau leeft. Dat omvat de SCIM-configuratie die gebruikers en groepen synchroniseert vanuit de identity provider, workspace-instellingen, en platform-brede Unity Catalog-structuren. Voor permissies die stabiel en fundamenteel zijn, biedt Terraform de sterkste garanties: alles is versie-beheerd, gereviewd en gedeployed via een CI/CD-pipeline.
resource "databricks_grant" "analyst_read" {
catalog = "production"
grant {
principal = "data-analysts"
privileges = ["SELECT"]
}
}De afweging is dat dit infrastructuurcode is. Het vereist engineers die vertrouwd zijn met Terraform, en elke wijziging doorloopt hetzelfde proces als elke andere infrastructuurwijziging. Voor data owners die toegang tot hun eigen domein willen beheren, is dit vaak te veel overhead. De Databricks Terraform provider documentatie dekt het volledige scala aan Unity Catalog-resources dat op deze manier kan worden beheerd.
2. Databricks Asset Bundles: het beste voor specifieke dataproducten
Databricks Asset Bundles (DABs) zijn een sterke keuze wanneer het dataproduct zelf ook als bundle wordt beheerd. Permissies kunnen worden gedefinieerd naast de pipelines, notebooks en schema's waarmee ze samenhangen, in YAML die leesbaar is zonder diepgaande infrastructuurkennis.
resources:
schemas:
bronze_layer:
name: bronze
catalog_name: production
grants:
- principal: data-engineers
privileges:
- USE_SCHEMA
- SELECTDit is waar de ontkoppeling tussen platform team en data owner praktisch wordt. Een domeinteam kan de permissies op zijn eigen dataproducten beheren zonder de bredere platformconfiguratie aan te raken. De governance blijft dicht bij de data, precies waar het hoort. Meer detail over hoe permissies binnen bundles werken, is te vinden in de DABs permissiedocumentatie.
3. De GUI: snel en flexibel, maar zonder geheugen
De Databricks-interface maakt het mogelijk om rechten toe te wijzen, schema's aan te maken en permissies aan te passen zonder technische kennis. Voor snelle wijzigingen en experimenteren in een ontwikkelomgeving is die flexibiliteit nuttig.
De beperking is dat niets hiervan automatisch wordt bijgehouden. Er is geen geschiedenis van wie welke toegang heeft verleend en wanneer, of op welke basis. Wanneer er een incident plaatsvindt en een auditor moet reconstrueren wat er is gebeurd, laat de GUI weinig houvast. Als fundament voor productiegovernance schiet het tekort.
Tot slot is het de moeite waard te benadrukken: meerdere benaderingen tegelijk gebruiken kan al snel complex worden. System tables bieden het overzicht ongeacht hoe toegang is ingericht, maar het inrichtingsproces zelf wordt moeilijker te doorgronden wanneer het verspreid is over Terraform, DABs en handmatige GUI-wijzigingen tegelijk. Het loont om bewust te kiezen welke aanpak het beste past bij het team en de organisatie, in plaats van standaard alle drie tegelijk in te zetten.
Conclusie
Goede data governance in Databricks rust op een duidelijke scheiding van verantwoordelijkheden: het platform team beheert identiteitssynchronisatie en fundamentele infrastructuur, data owners beheren de toegang tot hun eigen dataproducten, en system tables bieden de audit trail die dit alles verifieerbaar maakt.
De tooling om dit te ondersteunen is beschikbaar. De vraag is of de organisatie bereid is er structureel tijd en eigenaarschap aan te koppelen, voordat een incident die keuze maakt.
Bouw een schaalbaar governance-model voor je Databricks-platform
Goede governance begint met duidelijk eigenaarschap, transparant toegangsbeheer en een platform dat beide ondersteunt. Wij helpen organisaties bij het ontwerpen en implementeren van schaalbare governance-oplossingen binnen Azure Databricks en moderne data platformen.
Neem contact op of plan een meeting om de mogelijkheden te bespreken.
Dit artikel is geschreven door Cas Hortensius
Cas is een Data Engineer met een passie voor het overbruggen van de kloof tussen ruwe data en bruikbare inzichten voor analytics-teams. Dankzij zijn achtergrond in data engineering zorgt hij ervoor dat data toegankelijk is en optimaal ingericht wordt voor analyse. Hij heeft ervaring in uiteenlopende sectoren, waaronder de muziekindustrie, financiële dienstverlening en de energiesector.
1x per maand data insights, praktijkcases en een kijkje achter de schermen ontvangen?
Meld je aan voor onze maillijst en blijf 'up to data':