FUAM toont de groep. Ik wil de mensen zien.

FUAM geeft me een nuttig overzicht van mijn Fabric-omgeving. Maar als een workspacerol aan een groep is toegewezen, heb ik nog steeds de vraag waarmee de review begon: wie zijn de mensen achter die groep?

Fabric-Finance-Contributors is een prima manier om toegang te beheren. Het is geen lijst met mensen. En voor iedere groep apart Entra openen vind ik geen bijzonder goede monitoringworkflow.

Daarom heb ik FabricPermissions gebouwd: een PowerShell-rapport voor een snelle controle en een Fabric-notebook voor herhaalbare verzameling en het volgen van veranderingen.

De ontbrekende stap in een toegangsreview

Fabric Unified Admin Monitoring, oftewel FUAM, brengt administratieve en operationele gegevens samen in Fabric. De open architectuur met een lakehouse geeft je ook ruimte om die gegevens zelf te verrijken.

Daar past dit bij. Niet als vervanger van FUAM en ook niet als officiële FUAM-module. Het is een aparte collector die de informatie over groepslidmaatschap toevoegt die ik naast workspacemonitoring wil zien.

Heb je FUAM nog niet ingericht? Mijn eerdere artikel over FUAM deployen met GitHub Copilot behandelt de installatie en de goedkeuringen die bij een mens moeten blijven.

Een fictief voorbeeld maakt het verschil duidelijk:

Dit zijn synthetische namen, geen resultaten uit een tenantscan.

De groep blijft belangrijk. Die vertelt je hoe iemand toegang krijgt. De persoon vertelt je met wie je die toegang moet bespreken.

Mijn Purview-permissionsexporter volgt hetzelfde idee. Een ander permissionsysteem, maar hetzelfde praktische probleem: de toewijzing is pas het begin van de uitleg.

Twee manieren om het te gebruiken

De repository bevat drie belangrijke bestanden:

Een belangrijk verschil: het huidige PowerShell-script leest directe groepsleden. Het notebook leest transitieve leden, inclusief gebruikers in geneste groepen. Bij geneste groepen leveren ze dus niet hetzelfde overzicht op.

De workflow is overzichtelijk:

Fabric-workspacerollen
  + Microsoft Graph-groepslidmaatschap
  -> mensen, rollen en brongroepen
  -> HTML / CSV, of een Delta-tabel in een lakehouse

De collectors wijzigen geen workspacerechten of groepslidmaatschap. Het notebook schrijft rapportagedata. Het identity-setupscript wijzigt wel Entra, dus behandel dat als een aparte administratieve handeling waarvoor goedkeuring nodig is.

1. Begin met het lokale rapport

Voor een eenmalige review gebruik je PowerShell 7 en Azure CLI:

Set-Location D:\
git clone https://github.com/Remc0000/FabricPermissions.git
Set-Location D:\FabricPermissions

az login
.\get-fabric-workspace-access.ps1 -OutputDirectory "D:\FabricAccessReports"

Het script gebruikt de Azure CLI-sessie voor de API-calls en schrijft bestanden met een timestamp:

workspace-access-report-<timestamp>.html
workspace-access-report-<timestamp>.csv

Open het HTML-rapport om het resultaat te bekijken. Gebruik de CSV om te filteren, te vergelijken of de gegevens in een andere rapportagetool te gebruiken.

Controleer eerst twee afzonderlijke permissiongrenzen. De Fabric-identiteit moet workspacerollen kunnen lezen. De Graph-identiteit moet groepslidmaatschap kunnen lezen. Een workspace kunnen openen betekent niet automatisch dat je beide mag.

De documentatie van de workspace role-assignment API vereist Member of Admin, niet alleen Viewer. Voor delegated calls vermeldt Microsoft ook Workspace.Read.All of Workspace.ReadWrite.All.

Dat is strenger dan de Viewer-voorwaarde die momenteel in de README staat. Volg de API-documentatie.

2. Gebruik het notebook voor herhaalde verzameling

Maak voor een pilot een aparte workspace op een Fabric-capacity, bijvoorbeeld blog_fabric_permissions. Importeer WorkspaceAccessReport.ipynb en koppel een lakehouse.

Het notebook gebruikt een Fabric-token voor workspaces en roltoewijzingen. Het haalt apart een Microsoft Graph-token op via een service principal. Die Graph-identiteit inrichten betekent niet dat ook de Fabric-uitvoeringsidentiteit is ingericht.

Het meegeleverde setupscript maakt of hergebruikt een applicatie met de naam FabricWorkspaceAccessReport, genereert een client secret voor een jaar en verleent de Graph-application permissions GroupMember.Read.All en User.Read.All met admin consent:

.\setup-service-principal.ps1

Lees het script en vraag administratorgoedkeuring voordat je het uitvoert. Het toont het gegenereerde secret. Opnieuw uitvoeren reset applicatiecredentials en vervangt het manifest met vereiste permissions. Gebruik het dus niet zomaar voor een bestaande gedeelde applicatie.

Het notebook verwacht SP_CLIENT_ID, SP_CLIENT_SECRET en SP_TENANT_ID. Haal het secret op via je goedgekeurde secret store, bijvoorbeeld Azure Key Vault. Sla het niet op in een notebook dat je naar GitHub pusht. Houd console-output met credentials buiten transcripts en screenshots.

Voer het notebook eerst handmatig uit. Controleer authenticatie voor beide API’s, inclusief of het Fabric-endpoint de token audience in jouw uitvoeringscontext accepteert. Het huidige notebook vraagt de Power BI-token audience op. Een token kunnen ophalen bewijst niet dat de Fabric-calls werken.

Voor dit artikel is geen nieuwe Fabric-omgeving gedeployed. Dit zijn instructies op basis van de gepubliceerde implementatie, geen claim van een nieuwe end-to-endtest in een tenant.

Wat het lakehouse oplevert

Het notebook schrijft workspace_access_report, met velden voor workspace, principal, rol, brongroep en snapshot. De sleutel voor change detection is:

WorkspaceId | PrincipalId | Role

Bij een bestaande sleutel blijft granted_on_dt behouden. Als de sleutel in een volgende verzameling ontbreekt, wordt revoked_on_dt gevuld.

Na een volledige, geslaagde verzameling kun je actieve gebruikersrecords bekijken via het SQL-endpoint van het lakehouse:

SELECT
    WorkspaceName,
    PrincipalDisplayName,
    Role,
    GroupName,
    granted_on_dt
FROM workspace_access_report
WHERE revoked_on_dt IS NULL
  AND PrincipalType = 'User'
ORDER BY WorkspaceName, Role, PrincipalDisplayName;

Het gebruikersfilter is relevant omdat het notebook ook direct toegewezen niet-gebruikers bewaart. Meerdere toegangspaden kunnen meer dan één rij voor dezelfde persoon opleveren. Het aantal rijen is dus niet automatisch het aantal unieke gebruikers.

Voor recent waargenomen verwijderingen:

SELECT
    WorkspaceName,
    PrincipalDisplayName,
    Role,
    revoked_on_dt
FROM workspace_access_report
WHERE revoked_on_dt >= DATEADD(day, -30, CAST(GETUTCDATE() AS date))
  AND PrincipalType = 'User'
ORDER BY revoked_on_dt DESC;

De tabel is bruikbare input voor een eigen toegangsrapport naast FUAM. De repository breidt niet automatisch het FUAM-semantic model uit en installeert geen nieuwe FUAM-rapportpagina.

Een snapshot is geen auditlog

De datums vertellen wanneer de collector een verandering waarnam, niet wanneer een administrator de toegang precies wijzigde. De eerste verzameling is een baseline, niet de oorspronkelijke grantdatum.

Ook belangrijk: het notebook gebruikt een Delta merge. Het werkt bestaande records bij in plaats van voor iedere run een onveranderbaar event toe te voegen. Als toegang verdwijnt en later terugkomt, wist het de revocationdatum voor die sleutel. Het is dus geen volledig historisch register van iedere grant en revoke.

GroupId zit bovendien niet in de sleutel. Een andere groep die dezelfde persoon dezelfde workspacerol geeft, wordt niet als apart toegangsevent gezien.

Bruikbare change tracking? Ja. Een vervanger voor gezaghebbende auditevents? Nee.

Wat ik zou controleren voordat ik een schedule aanzet

Dit is een gerichte collector. Geen claim dat ieder mogelijk toegangspad is uitgewerkt.

• Workspacescope: de collector gebruikt de standaard list-workspaces API voor de uitvoerende identiteit, geen tenantbrede admininventarisatie.
• Pagination: het notebook volgt Graph-membershippagina’s, maar de huidige Fabric-calls volgen geen continuationpagina’s voor workspaces en rollen. PowerShell leest ook alleen de eerste membershippagina.
• Volledigheid: een mislukte workspacecall of groepsuitbreiding kan een waarschuwing geven terwijl de verzameling doorgaat. Ontbrekende records kunnen daarna op ingetrokken toegang lijken. Zo’n run is geen betrouwbare baseline.
• Effectieve permissions: de gebruikerssamenvatting in het lokale rapport berekent niet de volledige rangorde van rollen. Bekijk de onderliggende toewijzingen als iemand meerdere rollen of toegangspaden heeft.
• Andere toegangslagen: workspacerollen inventariseren niet alle item sharing, app audiences, semantic-modelpermissions, OneLake-securityregels of row-level security.

Voor groepen met verborgen lidmaatschap vereist Microsoft Graph aanvullende permission. De documentatie voor transitive members beschrijft dat, en ook dat onvoldoende permissions beperkte memberdetails kunnen opleveren.

Vergelijk vóór een dagelijkse Notebook activity in een Fabric-pipeline een bekende directe gebruiker, een groepslid en een gebruiker uit een geneste groep met de verwachte toewijzingen. Herhaal de verzameling zonder wijzigingen. Test daarna een grant en verwijdering in een goedgekeurde testworkspace. Los waarschuwingen, paginationgaten en dubbele mergesleutels op voordat je dit als geplande controle gebruikt.

Geeft Fabric 403? Controleer de workspacerol en API-permissions van de uitvoerende identiteit. Geeft Graph 403 of onvolledige namen? Controleer consent en groepszichtbaarheid. Een leeg resultaat bewijst niet dat niemand toegang heeft.

Houd het rapport privé

De output bevat directory-identiteiten en toegangsrelaties. Nuttige governancedata, maar geen materiaal voor een publieke GitHub-issue.

Bescherm HTML en CSV, beperk toegang tot het lakehouse en spreek retentie af. Het notebook gebruikt Fabric-capacity en lakehousestorage. Als je Key Vault toevoegt, horen daar eigen resourcekosten bij. De uitbreiding vereist geen Azure-resourcegroep, tenzij je zelf Azure-prerequisites introduceert.

Zet na de pilot het schedule uit, verwijder onnodige rapportbestanden en testitems en trek dedicated applicatiecredentials en consent in als ze niet meer nodig zijn. Controleer eerst of de identiteit niet gedeeld wordt.

Mijn take

Ik wil group-based access niet vervangen. Groepen zijn juist hoe ik toegang wil beheren.

Ik wil dat de monitoring één stap verder gaat. Een workspaceowner zou niet eerst een Entra-groep naar mensen hoeven te vertalen voordat de toegangsreview kan beginnen.

Dat is het doel van FabricPermissions: bewaar de groep als toegangspad, maar zet de mensen in de review.

Bronnen

Implementatie bekeken op FabricPermissions-commit 9a6d087. Bronnen geraadpleegd op 15 oktober 2026:

• FabricPermissions README en uitvoerbare bestanden
• FUAM in de Microsoft Fabric Toolbox
• Fabric REST API: list workspaces
• Fabric REST API: list workspace role assignments
• Microsoft Graph: list group transitive members