Azure Databricks: Unity Catalog Voor Data Governance Inschakelen

Zonder Unity Catalog zijn organisaties beperkt tot workspace-level permissions, wat betekent dat elke Databricks workspace zijn eigen, geïsoleerde set machtigingen heeft zonder mogelijkheid tot gecentraliseerd beheer. Dit creëert aanzienlijke uitdagingen: er is geen cross-workspace governance mogelijk waardoor dezelfde data in verschillende workspaces verschillende toegangsregels kan hebben, een gecentraliseerde audittrail ontbreekt wat compliance-audits bemoeilijkt, data lineage-informatie is niet beschikbaar waardoor organisaties niet kunnen aantonen hoe data wordt verwerkt en getransformeerd (een kritieke compliance-eis voor AVG en andere regelgeving), data discovery-mogelijkheden ontbreken wat resulteert in 'shadow data' waarbij teams niet weten welke gevoelige data waar staat, en handmatig toegangsbeheer wordt een schaalbaarheidsnachtmerrie bij groeiende organisaties met tientallen of honderden data-assets. Unity Catalog adresseert al deze problemen door een gecentraliseerde metastore te bieden die metadata voor meerdere workspaces beheert, fine-grained toegangscontrole tot op tabel- en kolomniveau mogelijk te maken, automatische audit logging te bieden voor alle data-toegang en -wijzigingen, data lineage-tracking te implementeren die precies toont hoe data van bron naar bestemming vloeit en wordt getransformeerd, data discovery en classification te faciliteren waarbij gevoelige data automatisch wordt geïdentificeerd en geclassificeerd, en cross-workspace en zelfs cross-cloud governance mogelijk te maken. Voor organisaties met meerdere Databricks workspaces, strikte compliance-vereisten of complexe data-landschappen is Unity Catalog essentieel om controle en zichtbaarheid te behouden.

Implementatie

Deze maatregel implementeert Unity Catalog voor Azure Databricks, wat een fundamentele wijziging is in hoe data governance wordt georganiseerd. Unity Catalog introduceert een hiërarchische architectuur die bestaat uit verschillende lagen: bovenaan staat de Metastore die als centrale metadata-repository fungeert en aan meerdere workspaces kan worden gekoppeld. Binnen de metastore worden Catalogs gecreëerd die fungeren als top-level containers (vergelijkbaar met databases in traditionele systemen). Binnen catalogs bevinden zich Schemas (databases) die verwante tabellen en views groeperen. Onderaan de hiërarchie staan Tables en Views die de daadwerkelijke data bevatten, plus Volumes voor file-based data. Toegangscontrole werkt via standaard SQL GRANT en REVOKE statements, wat data engineers en analisten een vertrouwde syntax biedt. Geavanceerde features omvatten row-level security waarbij toegang tot specifieke rijen kan worden beperkt op basis van gebruikersattributen, column masking waarbij gevoelige kolommen automatisch worden gemaskeerd voor ongeautoriseerde gebruikers, en attribute-based access control (ABAC) voor dynamische toegangsregels. Unity Catalog biedt automatische audit logging die alle data-toegang registreert zonder extra configuratie, data lineage-visualisatie die grafisch toont hoe data door pipelines en transformaties stroomt, automatische discovery van gevoelige data zoals persoonsgegevens, PII-classification die GDPR-relevante data markeert, en cross-workspace data sharing waarbij datasets veilig kunnen worden gedeeld tussen teams zonder data-duplicatie. De implementatie vereist Databricks Premium tier, Microsoft Entra ID-integratie voor identiteitsbeheer, een dedicated Azure Data Lake Storage Gen2-account voor de metastore-storage, en een zorgvuldige migratieplanning om bestaande tabellen naar Unity Catalog over te zetten zonder business interruption.

Vereisten

Voordat Unity Catalog kan worden geïmplementeerd voor Azure Databricks, moeten organisaties ervoor zorgen dat ze beschikken over de juiste infrastructuur, licenties, toegangsrechten en strategische planning. Deze vereisten zijn essentieel voor een succesvolle implementatie en om te voldoen aan enterprise data governance-standaarden en compliance-vereisten. Het niet voldoen aan deze vereisten kan leiden tot implementatiefalen, compliance-problemen of aanzienlijke operationele verstoringen.

De primaire technische vereiste is een Azure Databricks workspace op het Premium tier. Unity Catalog is uitsluitend beschikbaar op de Premium tier en kan niet worden geconfigureerd op de Standard tier. Dit betekent dat organisaties die momenteel gebruikmaken van de Standard tier moeten upgraden naar Premium voordat Unity Catalog kan worden geïmplementeerd. De Premium tier biedt naast Unity Catalog ook aanvullende beveiligings- en governance-functies zoals advanced access control, audit logging, data lineage-tracking en enhanced compliance capabilities, waardoor de upgrade vaak een logische stap is voor organisaties met enterprise data governance-vereisten. De kosten van de Premium tier zijn hoger dan de Standard tier (ongeveer €0,55 per DBU versus €0,40), maar de governance-voordelen rechtvaardigen deze investering voor organisaties met meerdere workspaces, gevoelige data of strikte compliance-vereisten.

Een tweede kritieke vereiste is Microsoft Entra ID-integratie met SCIM-provisioning. Unity Catalog gebruikt Azure AD-groepen en gebruikers voor toegangsbeheer, wat betekent dat organisaties een volledig geconfigureerde Azure AD-integratie moeten hebben. SCIM-provisioning zorgt ervoor dat gebruikers en groepen automatisch worden gesynchroniseerd tussen Azure AD en Databricks, wat essentieel is voor schaalbaar toegangsbeheer. Zonder SCIM-provisioning moeten gebruikers handmatig worden toegevoegd aan elke workspace, wat onpraktisch is voor enterprise-organisaties met honderden gebruikers. De Azure AD-integratie moet ook zijn geconfigureerd met de juiste permissions zodat Databricks-beheerders gebruikers en groepen kunnen beheren via de Databricks-interface.

Een dedicated Azure Data Lake Storage Gen2-account is vereist voor de Unity Catalog metastore-opslag. Dit storage account moet specifiek zijn geconfigureerd voor Unity Catalog en mag niet worden gedeeld met andere workloads om prestatie- en beveiligingsredenen. Het storage account moet Hierarchical Namespace hebben ingeschakeld (dit is wat ADLS Gen2 onderscheidt van gewone Blob Storage) omdat Unity Catalog een hiërarchische bestandsstructuur gebruikt voor metadata-opslag. Het storage account moet zich in dezelfde Azure-regio bevinden als de Databricks-workspaces om lage latentie te garanderen en om te voldoen aan data residency-vereisten. De opslagvereisten voor de metastore zijn relatief klein (meestal minder dan 100 GB), maar het account moet worden geconfigureerd met Soft Delete ingeschakeld om onbedoeld verlies van metadata te voorkomen.

Account admin-toegang is vereist voor het aanmaken van de Unity Catalog metastore. Dit is een account-level operatie die alleen kan worden uitgevoerd door gebruikers met Databricks Account Admin-rechten. Deze rechten worden toegekend via de Databricks Account Console en zijn anders dan workspace admin-rechten. Organisaties moeten ervoor zorgen dat ten minste twee personen account admin-rechten hebben om single points of failure te voorkomen. Deze account admins zijn verantwoordelijk voor het aanmaken van de metastore, het toewijzen van de metastore aan workspaces, en het beheren van metastore-level configuraties zoals default catalog admins.

Een uitgebreid migratieplan is essentieel voor organisaties met bestaande Databricks-workspaces die al tabellen bevatten. Unity Catalog introduceert een nieuwe drie-niveau namespace-structuur (catalog.schema.table) die verschilt van de traditionele Hive metastore-structuur (database.table). Bestaande tabellen worden niet automatisch gemigreerd naar Unity Catalog, wat betekent dat organisaties een gestructureerd migratieproces moeten plannen. Het migratieplan moet omvatten: een inventarisatie van alle bestaande tabellen, views en functies die moeten worden gemigreerd, een beslissing over de catalog- en schema-structuur voor de nieuwe organisatie, een strategie voor data-migratie (CREATE TABLE AS SELECT versus EXTERNAL TABLE pointers), een plan voor het bijwerken van alle notebooks en jobs die verwijzen naar oude tabelnamen, coördinatie met development teams over SQL-syntaxwijzigingen, en planning van maintenance windows voor productie-migraties. Voor enterprise-organisaties met honderden tabellen kan dit proces 4-8 weken duren.

Gedocumenteerde data governance-beleidsregels zijn vereist om ervoor te zorgen dat Unity Catalog wordt gebruikt volgens organisatorische standaarden. Deze beleidsregels moeten specificeren: wie eigenaar is van welke catalogs en schemas, hoe nieuwe tabellen worden geclassificeerd en waar ze moeten worden geplaatst, welke toegangscontrole-standaarden worden toegepast (bijvoorbeeld least privilege, column-level security voor PII), hoe data lineage wordt gedocumenteerd en gebruikt, procedures voor regelmatige toegangsreviews en permission-cleanup, en escalation-procedures voor toegangsverzoeken. Zonder duidelijke governance-beleidsregels kan Unity Catalog leiden tot een chaotische data-structuur waarbij teams niet weten waar data moet worden opgeslagen of wie toegang moet hebben.

Implementatie

Gebruik PowerShell-script databricks-unity-catalog.ps1 (functie Invoke-Monitoring) – Checks Unity Catalog enablement status voor Databricks workspaces.

⚠️ **KRITIEKE PLANNING VEREIST**: Unity Catalog is een fundamentele architectuurwijziging voor Databricks data governance die zorgvuldige planning, stakeholder-afstemming en uitgebreide gebruikerstraining vereist. Dit is geen plug-and-play functie maar een complete governance-transformatie die 3-6 weken planning en 2-4 weken implementatie kan vergen voor enterprise-deployments.

**FASE 1: Azure Data Lake Storage Gen2 Voorbereiden voor Metastore (Duur: 1-2 uur)**

De eerste fase van de implementatie richt zich op het opzetten van een beveiligde Azure Data Lake Storage Gen2-account die specifiek is geconfigureerd voor Unity Catalog metastore-opslag. Begin met het creëren van een nieuw Azure Data Lake Storage Gen2-account via de Azure Portal. Het is cruciaal om te begrijpen dat dit ADLS Gen2 moet zijn met Hierarchical Namespace ingeschakeld, niet gewone Blob Storage. De Hierarchical Namespace-functie is wat ADLS Gen2 onderscheidt van traditionele Blob Storage en is vereist omdat Unity Catalog een hiërarchische bestandsstructuur gebruikt voor metadata-opslag. Gebruik een consistente naming convention zoals 'adlsdbricksmetastore[organisatienaam]' om duidelijkheid te creëren over het doel van het storage account. Dit storage account moet dedicated zijn voor Unity Catalog en mag niet worden gedeeld met andere workloads om prestatie- en beveiligingsredenen.

Configureer het storage account in dezelfde Azure-regio als uw primaire Databricks-workspaces. Deze regionale co-locatie is essentieel om lage latentie te garanderen voor metadata-operaties en om te voldoen aan data residency-vereisten die kunnen gelden voor gevoelige metadata. Wanneer de metastore en workspaces zich in verschillende regio's bevinden, kan dit leiden tot aanzienlijke prestatieproblemen en mogelijk compliance-problemen als data residency-vereisten specificeren dat metadata binnen een bepaalde regio moet blijven.

Creëer een dedicated container binnen het storage account genaamd 'unity-catalog-metastore' voor metadata-opslag. Deze container zal alle Unity Catalog-metadata bevatten, inclusief catalog-definities, schema-structuren, tabel-metadata, toegangsbeleid en audit logs. Het gebruik van een dedicated container helpt bij het organiseren van de metadata en maakt het eenvoudiger om backup- en lifecycle management-beleid toe te passen. Zorg ervoor dat de container wordt aangemaakt met de juiste toegangsrechten zodat alleen de Databricks Access Connector Managed Identity toegang heeft.

Schakel Soft Delete in met een retentieperiode van minimaal 90 dagen om onbedoelde verwijderingen te beschermen. Het verlies van de Unity Catalog metastore zou catastrofaal zijn omdat dit alle metadata bevat die nodig is voor data governance, inclusief catalog-structuren, toegangsbeleid en audit logs. Wanneer metadata per ongeluk wordt verwijderd, blijft deze gedurende de retentieperiode beschikbaar voor herstel, waardoor organisaties de tijd hebben om onbedoelde verwijderingen te detecteren en ongedaan te maken. Soft Delete is verplicht voor alle Unity Catalog-implementaties en kan niet worden uitgeschakeld nadat het storage account is aangemaakt.

Implementeer Lifecycle Management-beleid voor kostenoptimalisatie. Hoewel de metastore relatief klein is (meestal minder dan 100 GB), groeit deze gestaag naarmate meer tabellen en metadata worden toegevoegd. Configureer een beleid dat oude metadata automatisch verplaatst naar de Cool tier na 90 dagen van inactiviteit. Dit kan de opslagkosten met 30-50 procent verminderen zonder impact op de functionaliteit, omdat metadata zelden wordt benaderd nadat het is aangemaakt. Voor zeer oude metadata (ouder dan 1 jaar) kunt u overwegen om deze te verplaatsen naar de Archive tier voor verdere kostenbesparingen, hoewel dit recovery-tijd kan toevoegen als de metadata moet worden hersteld.

Configureer netwerkbeveiliging om het storage account te beschermen tegen onbevoegde toegang. Schakel de storage account firewall in en whitelist alleen de Databricks service IP-ranges en beheerderswerkstations met bekende IP-adressen. Voor organisaties met strikte netwerkisolatie-vereisten kunnen Private Endpoints worden geïmplementeerd, waardoor het storage account alleen toegankelijk is via privénetwerken. Private Endpoints bieden maximale isolatie en voorkomen dat het storage account wordt blootgesteld aan het openbare internet, wat essentieel is voor high-security workloads. Alternatief kunnen IP-based firewall-regels worden geconfigureerd die alleen toegang verlenen aan vertrouwde Azure-services en beheerderswerkstations.

Tag het storage account met relevante metadata voor resource governance. Gebruik tags zoals Purpose=DatabricksMetastore, Criticality=High, BackupRequired=Yes, en Environment=Production om duidelijkheid te creëren over het doel en de kritiekheid van het storage account. Deze tags helpen bij resource management, kostenallocatie en compliance-documentatie. Ze maken het ook eenvoudiger om het storage account te identificeren in Azure Resource Manager-queries en om automatische policies toe te passen voor backup, monitoring en kostenbeheer.

**FASE 2: Unity Catalog Metastore Aanmaken (Duur: 1 uur)**

De tweede fase omvat het aanmaken van de Unity Catalog metastore via de Databricks Account Console. Het is belangrijk om te begrijpen dat dit een account-level operatie is, niet een workspace-level operatie. Navigeer naar de Databricks Account Console via https://accounts.azuredatabricks.net en selecteer 'Data' in het navigatiemenu, gevolgd door 'Metastores'. De Account Console is een aparte interface van de workspace console en wordt gebruikt voor account-level configuraties zoals metastore-beheer, workspace-toewijzingen en account-level gebruikersbeheer.

Klik op 'Create Metastore' om het aanmaakproces te starten. Specificeer een duidelijke metastore-naam zoals 'production-metastore-westeu' die het doel en de regio aangeeft. De Azure-regio die u selecteert MOET exact matchen met de regio waar het ADLS Gen2 storage account zich bevindt. Als de regio's niet matchen, zal de metastore-aanmaak falen met een connectivity-error. Voer de ADLS Gen2 storage account URL in het formaat 'abfss://unity-catalog-metastore@adlsdbricksmetastore[organisatienaam].dfs.core.windows.net/' in. Het 'abfss://'-protocol is het Azure Data Lake Storage Gen2-protocol dat wordt gebruikt voor hiërarchische namespace-toegang. Zorg ervoor dat de container-naam ('unity-catalog-metastore') exact overeenkomt met de container die u in Fase 1 heeft aangemaakt.

Configureer de Access Connector for Azure Databricks, wat een managed identity is die Unity Catalog toestaat om het storage account te benaderen. Navigeer naar de Azure Portal en selecteer 'Create Resource', zoek naar 'Access Connector for Azure Databricks' en start het deployment-proces. Deploy de Access Connector in dezelfde resource group als uw Databricks-workspaces voor consistente resource management. De Access Connector is een Azure-resource die een managed identity creëert die specifiek is ontworpen voor Databricks Unity Catalog-toegang tot storage accounts. Deze managed identity wordt automatisch beheerd door Azure en vereist geen wachtwoord of secret management.

Ken de juiste permissions toe aan de Access Connector Managed Identity op het storage account. Navigeer naar het ADLS Gen2 storage account in de Azure Portal, selecteer 'Access control (IAM)' en klik op 'Add role assignment'. Wijs de rol 'Storage Blob Data Contributor' toe aan de Access Connector Managed Identity. Deze rol geeft de managed identity de benodigde permissions om metadata te lezen en schrijven in de Unity Catalog-metastore container. Zonder deze permissions zal de metastore niet kunnen functioneren omdat Unity Catalog geen toegang heeft tot de metadata-opslag. Het is belangrijk om alleen de minimaal benodigde permissions toe te kennen volgens het principe van least privilege.

Valideer de metastore-connectiviteit voordat u doorgaat naar de volgende fase. In de Account Console, navigeer naar 'Metastores', selecteer de zojuist aangemaakte metastore en klik op 'Test Connection'. Deze test verifieert dat de Access Connector Managed Identity correct is geconfigureerd, dat de storage account URL correct is, en dat er geen netwerk- of permission-problemen zijn. Als de test faalt, controleer dan de Access Connector-configuratie, de storage account permissions, en de netwerkfirewall-instellingen. De test moet slagen voordat u doorgaat, omdat het toewijzen van een niet-functionerende metastore aan workspaces zal leiden tot operationele problemen.

Wijs Default Catalog Admins toe door een Azure AD-groep te specificeren van Databricks-beheerders die volledige metastore-rechten krijgen. Deze groep, bijvoorbeeld 'Databricks-Admins', krijgt automatisch admin-rechten op alle catalogs binnen de metastore, wat betekent dat ze catalogs kunnen aanmaken, verwijderen en beheren zonder expliciete permissions per catalog. Het is belangrijk om een Azure AD-groep te gebruiken in plaats van individuele gebruikers om schaalbaarheid en beheerbaarheid te waarborgen. Wanneer nieuwe beheerders moeten worden toegevoegd, hoeft u alleen de Azure AD-groep bij te werken in plaats van individuele permissions te wijzigen in elke catalog.

**FASE 3: Metastore Toewijzen aan Databricks Workspaces (Duur: 30 minuten per workspace)**

De derde fase omvat het toewijzen van de Unity Catalog metastore aan de Databricks-workspaces die gecentraliseerde data governance nodig hebben. Navigeer naar de Databricks Account Console, selecteer 'Workspaces' in het navigatiemenu, en kies de workspace waaraan u de metastore wilt toewijzen. Klik op de 'Metastore'-tab om de metastore-configuratie voor deze specifieke workspace te bekijken. Op dit punt zal de workspace nog steeds gebruikmaken van de traditionele Hive metastore voor data governance.

Klik op 'Assign Metastore' en selecteer de metastore die u in Fase 2 heeft aangemaakt uit de dropdown-lijst. Het is cruciaal om te begrijpen dat eenmaal een workspace is toegewezen aan Unity Catalog, deze NIET kan worden ontkoppeld zonder volledige workspace re-creation. Dit betekent dat alle bestaande tabellen, views en functies die gebruikmaken van de Hive metastore moeten worden gemigreerd naar Unity Catalog voordat de workspace kan worden gebruikt. Zorg ervoor dat u volledig begrijpt wat deze toewijzing betekent voordat u doorgaat, omdat het een onomkeerbare architectuurwijziging is die alle data-governance-operaties beïnvloedt.

Specificeer een Default Catalog voor deze workspace, bijvoorbeeld 'production_data' of 'analytics_workspace_1'. De default catalog is de catalog die automatisch wordt gebruikt wanneer gebruikers SQL-queries uitvoeren zonder expliciet een catalog te specificeren. Elke workspace kan zijn eigen default catalog hebben, maar alle workspaces die aan dezelfde metastore zijn toegewezen delen dezelfde catalog-structuur en toegangsbeleid. Dit betekent dat een catalog die in één workspace wordt aangemaakt automatisch beschikbaar is in alle andere workspaces die aan dezelfde metastore zijn toegewezen, wat de kern is van gecentraliseerde cross-workspace governance.

Herhaal dit proces voor alle workspaces die Unity Catalog governance moeten gebruiken. Multi-workspace toewijzing aan dezelfde metastore is de kern van gecentraliseerde governance omdat het betekent dat toegangsbeleid, catalog-structuren en audit logs worden gedeeld over alle workspaces. Dit elimineert de noodzaak om dezelfde gebruiker handmatig toe te voegen aan elke workspace en zorgt ervoor dat toegangsbeleid consistent is over alle workspaces. Voor enterprise-organisaties met tientallen workspaces kan dit proces enkele uren duren, maar het is een eenmalige investering die aanzienlijke operationele efficiëntie oplevert op de lange termijn.

Verifieer de toewijzing door de workspace te openen en te navigeren naar het 'Data'-icoon in de sidebar. U moet nu 'Catalogs' zien in plaats van alleen 'Hive metastore', wat bevestigt dat Unity Catalog-integratie succesvol is. Wanneer u op 'Catalogs' klikt, zou u de default catalog moeten zien die u heeft gespecificeerd, evenals eventuele andere catalogs die zijn aangemaakt in de metastore. Als u nog steeds alleen 'Hive metastore' ziet, betekent dit dat de toewijzing niet succesvol is voltooid en dat u de configuratie moet controleren. Het kan enkele minuten duren voordat de wijzigingen worden doorgevoerd, dus wacht even en ververs de pagina als de catalogs niet onmiddellijk verschijnen.

**FASE 4: Catalogs en Schemas Structuur Ontwerpen (Duur: 3-5 uur voor enterprise)**

De vierde fase richt zich op het ontwerpen van een logische catalog- en schema-structuur die aansluit bij de organisatorische structuur en data governance-behoeften. Het ontwerp van deze hiërarchie is cruciaal omdat het de basis vormt voor alle toekomstige data-organisatie en toegangscontrole. Er zijn verschillende benaderingen mogelijk: Option A is een domain-driven aanpak waarbij catalogs worden georganiseerd per business domain, zoals 'sales_catalog', 'marketing_catalog' en 'finance_catalog'. Deze aanpak is ideaal voor organisaties met duidelijke business domain-grenzen en domain-driven data ownership waarbij elk domein verantwoordelijk is voor zijn eigen data. Option B is een environment-based aanpak waarbij catalogs worden georganiseerd per omgeving, zoals 'dev_catalog', 'test_catalog' en 'prod_catalog'. Deze aanpak is ideaal voor organisaties die strikte scheiding tussen ontwikkel-, test- en productieomgevingen vereisen. Option C is een hybride aanpak die beide dimensies combineert, zoals 'prod_sales', 'prod_finance', 'dev_sales', enzovoort. Deze aanpak biedt maximale flexibiliteit maar kan complexer zijn om te beheren. Kies de aanpak die het beste past bij uw organisatorische structuur en data governance-beleid.

Creëer de catalogs via de Databricks SQL Editor met standaard SQL DDL-statements. Gebruik 'CREATE CATALOG IF NOT EXISTS sales_catalog;' om een nieuwe catalog aan te maken. Het 'IF NOT EXISTS'-clausule voorkomt fouten als de catalog al bestaat, wat handig is bij het uitvoeren van scripts meerdere keren. Na het aanmaken van een catalog, gebruik 'USE CATALOG sales_catalog;' om de context te schakelen naar die catalog zodat alle volgende SQL-statements binnen die catalog worden uitgevoerd. Het is belangrijk om consistente naming conventions te gebruiken voor catalogs, zoals lowercase met underscores, om verwarring te voorkomen en om compatibiliteit te waarborgen met verschillende SQL-clients en tools.

Binnen elke catalog, creëer schemas voor logische groepering van gerelateerde tabellen en views. Schemas fungeren als databases binnen een catalog en helpen bij het organiseren van data op een logische manier. Gebruik 'CREATE SCHEMA IF NOT EXISTS sales_catalog.customer_data;' om een schema aan te maken binnen de sales_catalog. Creëer meerdere schemas binnen een catalog om verschillende soorten data te scheiden, zoals 'sales_catalog.customer_data' voor klantgegevens, 'sales_catalog.transaction_data' voor transactiegegevens, en 'sales_catalog.reference_data' voor referentiedata. Deze logische scheiding maakt het eenvoudiger om toegangscontrole toe te passen op groepen van gerelateerde tabellen en helpt gebruikers te begrijpen waar specifieke data zich bevindt.

Documenteer de catalog- en schema-structuur uitgebreid in een governance-document dat beschikbaar is voor alle teams. Dit document moet specificeren: welke catalogs en schemas bestaan, wat het doel is van elke catalog en schema, wie eigenaar is van elke catalog en schema, waar nieuwe tabellen moeten worden geplaatst afhankelijk van hun type en doel, welke naming conventions worden gebruikt voor tabellen binnen elk schema, en procedures voor het aanvragen van nieuwe catalogs of schemas. Zonder duidelijke documentatie zullen teams niet weten waar nieuwe tabellen moeten worden geplaatst, wat kan leiden tot een chaotische data-structuur waarbij tabellen willekeurig worden geplaatst zonder logische organisatie.

Stel catalog- en schema-eigendom in met 'ALTER CATALOG sales_catalog SET OWNER TO `sales-data-team@company.com`;' waarbij u de Azure AD-groep e-mail gebruikt. Eigendom definieert wie permissions kan beheren op de catalog of schema, wat betekent dat alleen de eigenaar-groep GRANT- en REVOKE-statements kan uitvoeren. Dit is essentieel voor gedecentraliseerd data governance waarbij verschillende teams verantwoordelijk zijn voor hun eigen data, terwijl de metastore-admins de overall structuur beheren. Zorg ervoor dat elke catalog en schema een duidelijke eigenaar heeft, zodat er altijd iemand verantwoordelijk is voor toegangsbeheer en data governance binnen die catalog of schema.

**FASE 5: Bestaande Tabellen Migreren naar Unity Catalog (Duur: Varieert, 8-40 uur afhankelijk van tabel-aantallen)**

De vijfde fase omvat het migreren van bestaande tabellen van de traditionele Hive metastore naar Unity Catalog. Het is cruciaal om te begrijpen dat bestaande tabellen in de workspace Hive metastore NIET automatisch worden gemigreerd naar Unity Catalog - dit is een volledig handmatig proces dat zorgvuldige planning en uitvoering vereist. Wanneer een workspace wordt toegewezen aan Unity Catalog, blijven bestaande Hive metastore-tabellen beschikbaar via het 'hive_metastore'-prefix, maar nieuwe tabellen moeten worden aangemaakt in Unity Catalog. Voor productie-workspaces met honderden tabellen kan dit migratieproces weken duren en vereist het uitgebreide coördinatie met development teams.

Begin met een volledige inventarisatie van alle bestaande tabellen, views en functies die moeten worden gemigreerd. Gebruik 'SHOW TABLES IN hive_metastore.default;' om alle tabellen in de default database te lijsten, en herhaal dit voor alle databases in de Hive metastore. Documenteer voor elke tabel: de tabelnaam, de database waarin deze zich bevindt, het aantal rijen en de geschatte grootte, de locatie van de onderliggende data (als het een externe tabel is), afhankelijkheden van andere tabellen, en welke notebooks of jobs deze tabel gebruiken. Deze inventarisatie is essentieel voor het plannen van de migratie-volgorde en het identificeren van potentiële problemen voordat de migratie begint.

Er zijn twee primaire migratie-opties beschikbaar, elk met voor- en nadelen. Option A is 'CREATE TABLE AS SELECT' waarbij u een nieuwe tabel aanmaakt in Unity Catalog en alle data kopieert: 'CREATE TABLE sales_catalog.customer_data.customers AS SELECT * FROM hive_metastore.default.customers;'. Deze aanpak kopieert alle data naar een nieuwe locatie, wat betekent dat de originele data intact blijft en dat er een volledige backup wordt gemaakt tijdens de migratie. Het nadeel is dat dit proces lang kan duren voor grote tabellen (bijvoorbeeld dagen voor tabellen met terabytes aan data) en dat het extra opslagruimte vereist tijdens de migratie. Option B is een 'EXTERNAL TABLE pointer' waarbij u een externe tabel aanmaakt die verwijst naar de originele data-locatie: 'CREATE EXTERNAL TABLE sales_catalog.customer_data.customers LOCATION 'abfss://container@storageaccount.dfs.core.windows.net/path/to/data';'. Deze aanpak is veel sneller omdat er geen data wordt gekopieerd, maar het betekent dat de tabel afhankelijk blijft van de originele data-locatie. Kies Option A voor kritieke productietabellen waar data-integriteit en backup belangrijk zijn, en Option B voor grote tabellen waar snelheid belangrijker is dan data-duplicatie.

Test de migratie eerst met kleine, niet-kritieke tabellen om het proces te valideren voordat u productie-schaal migraties uitvoert. Kies een paar kleine tabellen (bijvoorbeeld minder dan 1 GB) en migreer deze volledig, inclusief het bijwerken van alle notebooks en jobs die deze tabellen gebruiken. Verifieer dat queries correct werken met de nieuwe drie-niveau namespace-syntax, dat data-integriteit behouden blijft, en dat prestatie niet significant verslechtert. Documenteer alle problemen die u tegenkomt en ontwikkel oplossingen voordat u doorgaat met grotere tabellen. Deze testfase is essentieel om te voorkomen dat u halverwege een productie-migratie vastloopt op onverwachte problemen.

Update alle notebooks en jobs die verwijzen naar gemigreerde tabellen. Alle SQL-queries moeten worden bijgewerkt van de oude twee-niveau namespace (bijvoorbeeld 'default.customers') naar de nieuwe drie-niveau namespace (bijvoorbeeld 'sales_catalog.customer_data.customers'). Dit is een MAJOR code change die uitgebreide testing vereist omdat een typefout in de namespace zal leiden tot 'table not found'-fouten. Gebruik zoek-en-vervang in alle notebooks om consistentie te waarborgen, maar controleer handmatig of de vervangingen correct zijn omdat automatische vervangingen fouten kunnen introduceren. Test alle bijgewerkte notebooks en jobs grondig in een testomgeving voordat u ze in productie implementeert. Overweeg het gebruik van een code review-proces waarbij een tweede persoon alle wijzigingen controleert voordat ze worden gecommit.

Coördineer uitgebreid met development teams over de SQL-syntaxwijzigingen en de impact op hun werk. Communiceer proactief over de migratie-tijdlijn, welke tabellen wanneer worden gemigreerd, en welke syntaxwijzigingen vereist zijn. Organiseer training-sessies om teams te leren hoe ze de nieuwe drie-niveau namespace moeten gebruiken en hoe ze Unity Catalog-catalogs en schemas kunnen navigeren. Plan maintenance windows voor productie-migraties waarbij kritieke workloads tijdelijk worden gepauzeerd om data-integriteit te waarborgen. Zorg ervoor dat alle teams op de hoogte zijn van de wijzigingen en dat ze voldoende tijd hebben om hun code bij te werken voordat de migratie plaatsvindt. Documenteer alle communicatie en training-sessies voor toekomstige referentie.

**FASE 6: Granulaire Toegangscontrole Configureren (Duur: 5-10 uur)**

De zesde fase richt zich op het implementeren van granulaire toegangscontrole via SQL GRANT- en REVOKE-statements. Unity Catalog biedt fine-grained toegangscontrole tot op tabel- en kolomniveau, wat essentieel is voor het beschermen van gevoelige data zoals persoonsgegevens, financiële informatie en intellectueel eigendom. Implementeer het principe van least privilege waarbij gebruikers alleen de minimaal benodigde permissions krijgen om hun werk uit te voeren. Begin met table-level permissions door 'GRANT SELECT ON TABLE sales_catalog.customer_data.customers TO `sales-analysts@company.com`;' uit te voeren, waarbij u de Azure AD-groep e-mail gebruikt. Dit geeft de sales-analysts groep read-only toegang tot de customers-tabel, wat betekent dat ze data kunnen lezen maar niet kunnen wijzigen, verwijderen of nieuwe rijen kunnen toevoegen.

Implementeer column-level security voor persoonsgegevens (PII) om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot gevoelige kolommen. Gebruik 'GRANT SELECT (customer_id, name, country) ON TABLE sales_catalog.customer_data.customers TO `marketing-team@company.com`;' om de marketing-team toegang te geven tot alleen specifieke kolommen. Deze statement geeft GEEN toegang tot PII-kolommen zoals e-mailadressen, telefoonnummers of BSN-nummers, wat essentieel is voor AVG-compliance. Wanneer de marketing-team een query uitvoert op deze tabel, kunnen ze alleen de gespecificeerde kolommen zien, en alle andere kolommen (inclusief PII-kolommen) zijn volledig onzichtbaar voor hen. Dit is een krachtige functie die organisaties in staat stelt om data te delen met teams zonder hen toegang te geven tot gevoelige informatie.

Implementeer table-level restricties waarbij specifieke teams alleen toegang krijgen tot relevante tabellen. Het finance-team krijgt bijvoorbeeld alleen toegang tot financiële tabellen zoals 'finance_catalog.transactions.revenue' en 'finance_catalog.budget.allocations', terwijl het marketing-team alleen toegang krijgt tot marketing-tabellen zoals 'marketing_catalog.campaigns.performance' en 'marketing_catalog.customers.segments'. Deze scheiding zorgt ervoor dat het finance-team geen marketing-data kan zien en vice versa, wat data privacy en compliance waarborgt. Gebruik consistente naming conventions en catalog-organisatie om het eenvoudig te maken om te bepalen welke teams toegang moeten hebben tot welke tabellen.

Implementeer row-level security via views om toegang tot specifieke rijen te beperken op basis van gebruikersattributen of data-kenmerken. Creëer een view die alleen rijen bevat die relevant zijn voor een specifieke groep, bijvoorbeeld 'CREATE VIEW sales_catalog.customer_data.customers_europe AS SELECT * FROM sales_catalog.customer_data.customers WHERE country IN ('NL','DE','FR');'. Vervolgens verleen toegang tot deze view in plaats van de onderliggende tabel: 'GRANT SELECT ON VIEW sales_catalog.customer_data.customers_europe TO `eu-analysts@company.com`;'. Dit zorgt ervoor dat de EU-analysts alleen klanten uit Europese landen kunnen zien, wat region-based data isolation biedt. Deze aanpak is ideaal voor organisaties met geografische data residency-vereisten of voor het implementeren van data mesh-architecturen waarbij verschillende teams verantwoordelijk zijn voor verschillende regio's.

Gebruik DENY-statements voor extra beveiliging wanneer u expliciet wilt voorkomen dat bepaalde groepen toegang krijgen tot specifieke tabellen, zelfs als ze indirecte toegang zouden kunnen hebben via andere permissions. Bijvoorbeeld: 'DENY SELECT ON TABLE finance_catalog.sensitive_data.salaries TO `contractors-group@company.com`;'. Explicit denial overschrijft grants, wat betekent dat zelfs als de contractors-group indirect toegang zou kunnen krijgen via een andere permission, de DENY-statement ervoor zorgt dat ze geen toegang hebben. Dit is nuttig voor high-security scenario's waarbij u absoluut zeker wilt zijn dat bepaalde groepen geen toegang hebben tot zeer gevoelige data, ongeacht andere permission-configuraties.

Documenteer alle permission-grants uitgebreid in een governance-spreadsheet of database voor audit trails en regelmatige permission-reviews. Deze documentatie moet bevatten: welke groepen toegang hebben tot welke tabellen, welke kolommen zichtbaar zijn voor elke groep (voor column-level security), wanneer permissions zijn toegekend en door wie, de business justification voor elke permission, en wanneer de laatste review heeft plaatsgevonden. Deze documentatie is essentieel voor compliance-audits waarbij auditors willen zien wie toegang heeft tot welke data en waarom. Plan kwartaalreviews waarbij alle permissions worden geëvalueerd om te verifiëren dat ze nog steeds nodig zijn en dat het principe van least privilege wordt gehandhaafd. Tijdens deze reviews moeten orphaned permissions worden opgeruimd (permissions voor groepen die niet meer bestaan of niet meer worden gebruikt) en moeten nieuwe permissions worden toegekend voor nieuwe use cases.

⏱️ **Totale Implementatietijd**: 16-24 uur voor basis Unity Catalog-deployment (single workspace, beperkte data migratie). Enterprise-deployment met meerdere workspaces, volledige data-migratie en comprehensive governance: 60-100 uur verspreid over 4-8 weken.

💰 **Kosten**: Unity Catalog zelf is gratis (included in Premium tier). ADLS Gen2 storage: €20-50/maand voor metastore (kleine footprint, groeit langzaam). Databricks Premium tier premium: zie Databricks pricing. Totaal: verwaarloosbare extra costs voor storage, primary cost is Premium tier requirement.

Monitoring

Gebruik PowerShell-script databricks-unity-catalog.ps1 (functie Invoke-Monitoring) – Automatiseert monitoring van Unity Catalog-configuratie en toegangscontrole.

Effectieve monitoring van Unity Catalog is essentieel om te waarborgen dat data governance correct functioneert, dat beveiligingsincidenten tijdig worden gedetecteerd, en dat compliance-vereisten worden nageleefd. Monitoring omvat het continu volgen van toegangspatronen, het detecteren van afwijkend gedrag dat kan wijzen op beveiligingsbedreigingen, het verifiëren dat toegangsbeleid correct wordt toegepast, en het waarborgen dat alle data-toegang wordt gelogd voor auditdoeleinden. Zonder uitgebreide monitoring kunnen organisaties niet garanderen dat hun data governance-beleid effectief is en dat ze voldoen aan compliance-vereisten zoals AVG, NIS2 en ISO 27001.

Unity Catalog audit logs registreren automatisch alle data-toegang en -wijzigingen zonder extra configuratie. Deze logs bevatten gedetailleerde informatie over wie welke data heeft geraadpleegd, wanneer de toegang plaatsvond, welke queries werden uitgevoerd, en of de toegang succesvol was of werd geweigerd. Analyseer deze access patterns regelmatig om normale gebruikspatronen te identificeren en afwijkingen te detecteren. Ongebruikelijke toegangspatronen, zoals een gebruiker die plotseling toegang krijgt tot veel meer tabellen dan normaal, of toegang buiten normale werkuren, kunnen wijzen op beveiligingsincidenten zoals gecompromitteerde accounts of insider threats. Configureer Azure Monitor alert rules die automatisch waarschuwingen genereren wanneer dergelijke afwijkingen worden gedetecteerd.

Gebruik het data lineage dashboard om data flows te volgen en te begrijpen hoe data door verschillende tabellen en transformaties stroomt. Data lineage-visualisatie toont grafisch de upstream- en downstream-relaties tussen tabellen, wat essentieel is voor impact-analyses wanneer data quality-issues worden gedetecteerd, voor forensisch onderzoek na data breaches, en voor compliance-bewijsvoering waarbij auditors willen zien hoe persoonsgegevens worden verwerkt. Het dashboard helpt ook bij het identificeren van afhankelijkheden tussen tabellen, wat cruciaal is bij het plannen van schema-wijzigingen of tabel-migraties. Review het lineage dashboard regelmatig om te verifiëren dat data flows correct zijn gedocumenteerd en dat er geen onverwachte afhankelijkheden zijn ontstaan.

Gebruik de gevoelige data discovery-functionaliteit om automatisch persoonsgegevens (PII) te identificeren en te classificeren. Unity Catalog kan automatisch scannen naar veelvoorkomende PII-patterns zoals e-mailadressen, telefoonnummers, BSN-nummers en creditcardnummers, en deze data markeren als gevoelig. Deze automatische classificatie helpt bij het identificeren van data die extra bescherming nodig heeft en bij het waarborgen dat column-level security correct wordt toegepast op PII-kolommen. Review regelmatig de discovery-resultaten om te verifiëren dat alle gevoelige data correct is geïdentificeerd en dat de juiste toegangscontrole is geïmplementeerd. Voor AVG-compliance is het essentieel om te kunnen aantonen dat u weet waar persoonsgegevens zich bevinden en dat deze correct worden beschermd.

Voer regelmatige toegangscontrole- en authenticatie-compliance reviews uit om te verifiëren dat toegangsbeleid correct wordt toegepast en dat het principe van least privilege wordt gehandhaafd. Tijdens deze reviews moeten organisaties verifiëren dat alle permissions nog steeds nodig zijn, dat orphaned permissions worden opgeruimd (permissions voor groepen of gebruikers die niet meer bestaan), en dat nieuwe toegangsverzoeken correct worden afgehandeld. Plan kwartaalreviews waarbij alle GRANT- en REVOKE-statements worden geëvalueerd en waarbij wordt geverifieerd dat toegangsbeleid consistent is over alle workspaces. Documenteer alle reviews en alle wijzigingen die worden doorgevoerd voor auditdoeleinden.

Monitor alle GRANT- en REVOKE-activiteiten om te detecteren wanneer toegangsbeleid wordt gewijzigd. Configureer alert rules die waarschuwingen genereren wanneer permissions worden toegekend aan nieuwe groepen, wanneer permissions worden ingetrokken, of wanneer er wijzigingen zijn in catalog- of schema-eigendom. Deze monitoring helpt bij het detecteren van onbevoegde wijzigingen aan toegangsbeleid en bij het waarborgen dat alle permission-wijzigingen worden goedgekeurd volgens change management-procedures. Review deze alerts regelmatig om te verifiëren dat alle wijzigingen legitiem zijn en dat ze overeenkomen met goedgekeurde toegangsverzoeken.

Compliance en Auditing

Unity Catalog voor Azure Databricks is essentieel voor het voldoen aan verschillende compliance-frameworks en regelgevingsvereisten die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. Deze maatregel helpt organisaties te voldoen aan vereisten voor data governance, toegangscontrole, audit logging en data lineage-tracking zoals gespecificeerd in internationale standaarden en Nederlandse wetgeving. Zonder Unity Catalog kunnen organisaties niet volledig voldoen aan de vereisten van frameworks zoals AVG, NIS2, ISO 27001, BIO en SOC 2.

De Algemene Verordening Gegevensbescherming (AVG), ook wel bekend als GDPR, vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen implementeren om persoonsgegevens te beveiligen. Unity Catalog helpt bij het voldoen aan deze vereisten door granulaire toegangscontrole tot op kolomniveau mogelijk te maken, waardoor organisaties PII-kolommen kunnen beschermen terwijl ze andere data delen. Artikel 30 vereist dat organisaties een register van verwerkingsactiviteiten bijhouden, wat Unity Catalog faciliteert via automatische audit logging van alle data-toegang. Artikel 25 vereist data protection by design, wat Unity Catalog ondersteunt door toegangscontrole en data classification te integreren in de data-architectuur. Voor Nederlandse organisaties die persoonsgegevens verwerken in Databricks is Unity Catalog daarom vaak een absolute vereiste voor AVG-compliance.

ISO 27001 controle A.18.1.4 richt zich op gegevensbescherming en privacy en vereist dat organisaties passende maatregelen implementeren om persoonsgegevens te beschermen. Unity Catalog helpt bij het voldoen aan deze controle door column-level security te bieden voor PII, automatische audit logging van alle data-toegang, en data lineage-tracking die toont hoe persoonsgegevens worden verwerkt. Controle A.9.4.1 vereist dat organisaties toegangsrechten beperken en controleren, wat Unity Catalog faciliteert via granulaire GRANT- en REVOKE-statements en regelmatige permission-reviews. Organisaties moeten kunnen aantonen dat toegangscontrole correct wordt toegepast en dat alle data-toegang wordt gelogd, wat Unity Catalog automatisch biedt zonder extra configuratie.

De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen implementeren voor data governance en toegangscontrole. Deze vereiste is met name relevant voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg en financiële dienstverlening. Artikel 21 specificeert dat organisaties moeten kunnen aantonen dat ze controle hebben over data-toegang en dat ze in staat zijn om toegang onmiddellijk in te trekken bij beveiligingsincidenten. Unity Catalog stelt organisaties in staat om te voldoen aan deze vereisten door gecentraliseerd toegangsbeheer, automatische audit logging, en de mogelijkheid om permissions onmiddellijk in te trekken via REVOKE-statements. Het niet implementeren van Unity Catalog kan resulteren in niet-naleving van NIS2-vereisten, wat kan leiden tot boetes en andere handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM) of andere toezichthouders.

De Baseline Informatiebeveiliging Overheid (BIO) specificeert in Thema 15.01 dat organisaties informatiebeheer moeten implementeren met passende maatregelen voor data governance en toegangscontrole. Voor Nederlandse overheidsorganisaties is de BIO-baseline verplicht, en het niet voldoen aan deze vereisten kan leiden tot beveiligingsincidenten en compliance-problemen. Unity Catalog stelt overheidsorganisaties in staat om te voldoen aan BIO-vereisten door gecentraliseerd metadata-management, granulaire toegangscontrole, automatische audit logging, en data lineage-tracking. Organisaties moeten kunnen aantonen dat toegangsbeleid consistent is over alle workspaces, dat alle data-toegang wordt gelogd, en dat data lineage correct wordt gedocumenteerd, wat Unity Catalog automatisch biedt.

SOC 2 Type II-certificering vereist dat organisaties kunnen aantonen dat data-toegang correct wordt gecontroleerd en dat alle toegang wordt gelogd voor auditdoeleinden. Unity Catalog helpt bij het voldoen aan SOC 2-vereisten door automatische audit logging van alle data-toegang, granulaire toegangscontrole die kan worden geverifieerd tijdens audits, en data lineage-tracking die toont hoe data wordt verwerkt. Voor organisaties die SOC 2-certificering nastreven of behouden, is Unity Catalog essentieel om te kunnen aantonen dat data governance correct wordt geïmplementeerd en dat alle toegang wordt gecontroleerd en gelogd.

Remediatie

Gebruik PowerShell-script databricks-unity-catalog.ps1 (functie Invoke-Remediation) – Automatiseert de implementatie van Unity Catalog voor nieuwe Databricks workspaces.

Remediatie van Unity Catalog voor Azure Databricks omvat het implementeren van Unity Catalog voor workspaces die momenteel gebruikmaken van de traditionele Hive metastore, of het corrigeren van configuratiefouten in bestaande Unity Catalog-implementaties. Het is belangrijk om te begrijpen dat Unity Catalog een fundamentele architectuurwijziging is die zorgvuldige planning en uitvoering vereist. Voor nieuwe workspaces kan remediatie relatief eenvoudig zijn door Unity Catalog te configureren tijdens workspace-aanmaak, terwijl voor bestaande workspaces een uitgebreid migratieproces noodzakelijk is.

Voor nieuwe workspaces die nog niet in productie zijn, is remediatie relatief eenvoudig. Unity Catalog kan worden geconfigureerd tijdens het aanmaakproces van de workspace via de Databricks Account Console. Volg de implementatie-instructies in de vorige secties om de metastore aan te maken, de metastore toe te wijzen aan de workspace, en de catalog- en schema-structuur op te zetten. Omdat er nog geen bestaande tabellen zijn, is er geen migratie nodig en kan Unity Catalog direct worden gebruikt voor alle nieuwe tabellen. Dit is de ideale situatie omdat het de complexiteit van data-migratie vermijdt.

Voor bestaande productie-workspaces is remediatie veel complexer en vereist een zorgvuldige planning en uitvoering. Het proces begint met een uitgebreide assessment van de huidige workspace-configuratie, inclusief een inventarisatie van alle tabellen, views, functies en jobs die gebruikmaken van de Hive metastore. Plan een maintenance window van minimaal 4-8 uur, afhankelijk van het aantal tabellen en de complexiteit van de workloads. Communiceer proactief met alle stakeholders, inclusief data scientists, data engineers en business gebruikers, over de geplande migratie en de verwachte impact op hun werkzaamheden. Het is essentieel om alle teams op de hoogte te stellen van de SQL-syntaxwijzigingen die vereist zijn (van twee-niveau naar drie-niveau namespace) en om training te bieden over hoe Unity Catalog werkt.

De eerste stap in het remediatieproces is het opzetten van de vereiste infrastructuur volgens de implementatie-instructies. Dit omvat het creëren van een Azure Data Lake Storage Gen2-account met Hierarchical Namespace ingeschakeld, het aanmaken van de Unity Catalog metastore via de Account Console, het configureren van de Access Connector Managed Identity met de juiste permissions, en het toewijzen van de metastore aan de workspace. Zorg ervoor dat alle infrastructuur-componenten correct zijn geconfigureerd voordat u begint met de data-migratie, omdat configuratiefouten tijdens de migratie kunnen leiden tot aanzienlijke vertragingen en extra downtime.

Ontwerp en implementeer de catalog- en schema-structuur volgens de organisatorische behoeften. Beslis over de catalog-organisatie (domain-based, environment-based, of hybrid) en creëer de benodigde catalogs en schemas via SQL DDL-statements. Stel eigendom in voor elke catalog en schema om gedecentraliseerd data governance mogelijk te maken. Documenteer de structuur uitgebreid zodat teams weten waar nieuwe tabellen moeten worden geplaatst.

Migreer bestaande tabellen van de Hive metastore naar Unity Catalog volgens de migratie-strategie die u heeft gekozen (CREATE TABLE AS SELECT voor data-kopie of EXTERNAL TABLE pointers voor snelheid). Begin met kleine, niet-kritieke tabellen om het proces te valideren voordat u doorgaat met productie-tabellen. Update alle notebooks en jobs die verwijzen naar gemigreerde tabellen om de nieuwe drie-niveau namespace-syntax te gebruiken. Test alle bijgewerkte notebooks en jobs grondig in een testomgeving voordat u ze in productie implementeert.

Implementeer granulaire toegangscontrole via GRANT- en REVOKE-statements volgens het principe van least privilege. Begin met table-level permissions en implementeer vervolgens column-level security voor PII-kolommen. Gebruik row-level security via views voor geografische of organisatorische data-isolatie. Documenteer alle permissions uitgebreid voor auditdoeleinden en plan regelmatige reviews om te verifiëren dat toegangsbeleid correct wordt toegepast.

Voor bestaande Unity Catalog-implementaties die configuratiefouten hebben, kan remediatie worden uitgevoerd zonder volledige workspace-migratie. Als de metastore-connectiviteit problemen heeft, controleer dan de Access Connector-configuratie en de storage account permissions. Als de catalog- of schema-structuur moet worden aangepast, kunnen nieuwe catalogs en schemas worden aangemaakt en kunnen tabellen worden verplaatst via ALTER TABLE-statements. Voor problemen met toegangscontrole kunnen permissions worden gecorrigeerd via GRANT- en REVOKE-statements zonder impact op de onderliggende data. Het is belangrijk om alle configuratiewijzigingen te documenteren en te testen in een testomgeving voordat ze in productie worden geïmplementeerd.

Compliance & Frameworks

• BIO: 15.01.01, 15.01.02 - Informatiebeheer - Data governance
• ISO 27001:2022: A.18.1.4, A.9.4.1 - gegevensbescherming en access restriction
• NIS2: Artikel - Data governance en Toegangsbeheer

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Unity Catalog is het gecentraliseerde data governance-platform voor Azure Databricks dat organisatie-brede metadata-management, granulaire toegangscontrole en compliance-automation biedt. Kernfunctionaliteit: Gecentraliseerde metastore die alle Databricks-workspaces overspant met consistente catalog/schema/table structuur, granulaire toegangscontrole tot op tabel- en kolomniveau via SQL GRANT-statements zodat specifieke kolommen met PII kunnen worden afgeschermd, automatische audit logging van alle data-toegang voor compliance-bewijsvoering, data lineage-tracking die volledige upstream/downstream relaties visualiseert, geautomatiseerde PII-detectie en classificatie voor AVG-compliance, en Azure AD-groep integratie voor centralized identity management. Unity Catalog is essentieel voor: multi-workspace enterprise-deployments (3+ workspaces waar consistente governance critical is), organisaties met AVG/GDPR persoonsgegevens (column-level security vereist), gereguleerde sectoren zoals finance/healthcare (audit trails mandatory), en organisaties met data mesh-architecturen (gedecentraliseerde data ownership maar gecentraliseerde governance). Optioneel voor: single workspace met < 20 gebruikers en niet-gevoelige data. Belangrijke vereisten: Databricks Premium tier (Unity Catalog niet beschikbaar op Standard), dedicated Azure Data Lake Storage Gen2 account voor metastore-opslag (€20-50/maand), en awareness dat Unity Catalog een fundamentele architectuurwijziging is die zorgvuldige planning, user training (SQL-syntax veranderingen) en data migratie (bestaande tabellen moeten worden geïmporteerd) vereist. Implementatie-effort: 16-24 uur voor basis-deployment (metastore setup, workspace-koppeling, initial catalogs/schemas, access policies), plus 40-60 uur voor enterprise-scale deployment met volledige data migratie en governance-policies. Doorlopende inspanning: 8 uur per maand voor permission-management en policy-updates. Return on investment komt van: schaalbaarheid van permission-management over workspaces, compliance-success bij audits, reduced data breach-risico door column-level security, en operational efficiency door gecentraliseerd metadata-management.

• Implementatietijd: 24 uur
• FTE required: 0.3 FTE