Exporteer Microsoft Purview Unified Catalog-permissions met PowerShell

Purview Unified Catalog heeft permissions op tenant-, catalog- en governance-domainniveau. Dat is flexibel. Het maakt een simpele auditvraag ook verrassend lastig:

Wie mag wat, en waar?

Ik heb een PowerShell-script gemaakt dat de role definitions, policy assignments, governance domains, data products, product contacts en opgeloste Microsoft Entra-principals naar CSV en JSON exporteert. Dus niet ieder domain handmatig openen. En ook geen spreadsheet die al verouderd is voordat de lunch begint.

Download het script

Download Export-PurviewUnifiedCatalogPermissions.ps1

Het script is read-only. Het gebruikt je bestaande Azure CLI-sessie voor Purview en Microsoft Graph en schrijft de resultaten naar een lokale map.

Wat wordt geëxporteerd?

De nuttige output is bewust opgesplitst:

Het script bewaart daarnaast vier ruwe JSON-responses. Die zijn handig wanneer de CSV-weergave net dat ene veld verbergt dat je bij troubleshooting nodig hebt.

Een belangrijk onderscheid: een data product-contact is niet automatisch een policy assignment. Daarom staan contacts en catalog-policyrollen in aparte bestanden.

Vereisten

Je hebt nodig:

1. PowerShell 7 of Windows PowerShell;
2. Azure CLI;
3. een aangemelde Azure CLI-sessie;
4. permission om de relevante Purview Unified Catalog-configuratie te lezen; en
5. Microsoft Graph-permission om directory-objectnamen op te lossen.

Meld je aan en voer het script uit:

az login
.\Export-PurviewUnifiedCatalogPermissions.ps1

De tenant-ID komt automatisch uit de actieve Azure CLI-context. Je kunt hem na aanmelding bij die tenant ook expliciet meegeven:

.\Export-PurviewUnifiedCatalogPermissions.ps1 `
  -TenantId "<tenant-guid>" `
  -OutputDir ".\purview-permissions"

Het script stopt wanneer -TenantId niet overeenkomt met de actieve Azure CLI-tenant. Zo wordt een token voor de ene tenant nooit naar de Purview-endpoint van een andere tenant gestuurd.

Verwacht resultaat:

Export complete: C:\...\purview-permissions
{
  "tenantId": "...",
  "exportedAt": "...",
  "businessDomainCount": ...,
  "dataProductCount": ...,
  "roleDefinitionCount": ...,
  "policyAssignmentCount": ...,
  "dataProductContactCount": ...
}

Hoe werkt het?

Het script haalt eerst een Purview access token op via Azure CLI. Daarna leest het:

• data-governance role definitions;
• catalog policies en hun attribute rules;
• business domains; en
• data products en hun contacts.

Iedere policy rule bevat een role en een scope. Het script classificeert die scope als tenant/catalog, governance domain, data product of een bekende policy-specifieke scope. Vervolgens zoekt het recursief naar principal object-ID’s in de policy condition en resolveert die via Microsoft Graph in batches van maximaal twintig objecten.

Die laatste stap is belangrijk. Een object-ID is technisch correct, maar een beroerd auditrapport. Een display name, user principal name en object type maken de export bruikbaar voor een menselijke reviewer.

Als Graph een object niet kan vinden, blijft de regel bestaan met de waarde UNRESOLVED. Dat kan wijzen op een verwijderd object, onvoldoende Graph-permissions of een tijdelijke lookupfout. Onderzoeken dus, niet stilletjes weggooien.

Wat bewijst dit niet?

Deze export bevat Unified Catalog governance-rollen, policies en product contacts. Het script berekent geen effectieve toegang tot iedere onderliggende tabel, file, Power BI semantic model of Fabric-item.

Microsofts documentatie maakt die grens ook duidelijk: Unified Catalog combineert tenant-level permissions, catalog-rollen, governance-domainrollen, Data Map-permissions en permissions op de bronresource. Een gebruiker kan dus een catalogusconcept ontdekken zonder dat deze export bewijst dat die gebruiker ieder onderliggend asset kan bevragen.

Dit is ook iets anders dan security uit een bronsysteem synchroniseren naar OneLake. Voor dat scenario kun je mijn artikel lezen over Databricks- en Fabric-permissions gelijkhouden met Policy Weaver.

Validatie

Ik heb het downloadbare script op 8 oktober 2026 getest:

• PowerShell-parser: geslaagd;
• Azure CLI-authenticatie: geslaagd;
• ophalen van het Purview access token: geslaagd;
• lezen van Purview-rollen, policies, domains en data products: geslaagd;
• alle 11 verwachte CSV- en JSON-bestanden zijn in 22,1 seconden gegenereerd;
• de fallback voor een niet-resolveerbare principal is gevalideerd met een directory-object dat het testaccount niet mocht lezen; en
• de download bevat geen tenant-ID, token of geëxporteerde tenantdata.

De gebruikte API’s bevatten preview- en service-endpoints. Microsoft documenteert inmiddels ook een Unified Catalog API in public preview. Preview-contracten kunnen veranderen. Zie dit script daarom als audittool die je na grotere Purview-updates opnieuw test, niet als een interface die voor eeuwig in steen is gebeiteld.

Ga zorgvuldig om met de output

De export bevat namen, e-mailachtige user principal names, object-ID’s, governance-structuur en role assignments. Dat is nuttige auditdata en mogelijk gevoelige organisatie-informatie.

Commit de gegenereerde export niet naar een publieke repository. Bewaar hem op een passend beveiligde locatie, beperk de toegang en verwijder tijdelijke kopieën wanneer de review klaar is.

Mijn oordeel

Het interessante is niet dat Purview veel rollen heeft. Het interessante is dat permissions op verschillende lagen bestaan, terwijl de portal die lagen per object laat zien.

Een herhaalbare export maakt er iets van dat je kunt vergelijken, beoordelen en bespreken met domain owners. Het vervangt geen access review, maar geeft die review wel een goed startpunt.

Bronnen

• Data Governance Roles and Permissions in Microsoft Purview, geraadpleegd op 8 oktober 2026
• Governance Domains in Unified Catalog, geraadpleegd op 8 oktober 2026
• Data Products in Unified Catalog, geraadpleegd op 8 oktober 2026
• Unified Catalog API public preview, geraadpleegd op 8 oktober 2026