Hoe werkt rolgebaseerde toegangscontrole binnen Power Platform?

Rolgebaseerde toegangscontrole binnen Power Platform (RBAC) bepaalt wie welke apps, data en beheeracties mag gebruiken op basis van vooraf ingestelde rollen en machtigingen. Het systeem werkt met meerdere beveiligingslagen, van omgevingsrollen en Dataverse-beveiligingsrollen tot fijnmazige controle op record- en kolomniveau. Hieronder beantwoorden we de meest gestelde vragen over rollen en machtigingen Power Platform, zodat je jouw omgeving veilig en overzichtelijk inricht.

Welke rollen en machtigingen bestaan er binnen Power Platform? #

Power Platform hanteert een gelaagd rollenmodel dat op meerdere niveaus werkt. Je hebt te maken met tenantbrede beheerdersrollen, omgevingsrollen en, zodra Dataverse is ingeschakeld, specifieke beveiligingsrollen voor data en tabellen. Samen vormen deze lagen de basis van RBAC Power Platform.

Op omgevingsniveau zijn er drie kernrollen:

• Environment Admin — volledige administratieve machtigingen, inclusief het beheren van beveiligingsrollen en het inrichten van de Dataverse-database.
• Environment Maker — mag nieuwe resources aanmaken zoals apps, flows en aangepaste verbindingen, maar heeft géén toegang tot data of tabellen.
• Basic User — kan werken met items die expliciet met hem of haar gedeeld zijn. Deze rol geeft niet automatisch leestoegang tot data; apps en tabelrechten moeten apart worden toegewezen.

Op Dataverse-niveau komen daar rollen bij zoals System Administrator (volledige controle over data en aanpassingen) en System Customizer (aanpassingsrechten maar beperkte datatoegang). Deze Dataverse-rollen verhouden zich tot Microsoft 365- en Azure AD-rollen doordat tenantbeheerders, zoals de Power Platform Administrator, wél beheertaken mogen uitvoeren maar niet automatisch toegang tot Dataverse-data krijgen. Dat vereist altijd een aparte roltoewijzing binnen de omgeving.

Hoe worden rollen toegewezen binnen een Power Platform-omgeving? #

Rollen wijs je toe via het Power Platform Admin Center door naar de gewenste omgeving te navigeren en onder Users + Permissions > Security roles de juiste rol aan een gebruiker te koppelen. Daarnaast kun je Azure Active Directory-beveiligingsgroepen aan een omgeving koppelen voor groepsgebaseerde toewijzing, en werken Dataverse-beveiligingsrollen voor fijnmazige datatoegang.

Er zijn twee hoofdbenaderingen:

• Directe gebruikerstoewijzing — handig bij kleine teams of uitzonderingen, maar wordt bij grotere omgevingen snel onoverzichtelijk.
• Groepsgebaseerde toewijzing via Azure AD — de voorkeursmethode voor middelgrote en grote organisaties. Door beveiligingsgroepen te gebruiken beheer je toegang centraal en consistent.

Een handige bonus: bepaalde rollen kunnen automatisch worden toegewezen op basis van licenties. Wanneer een gebruiker aan Dataverse wordt toegevoegd, koppelt het systeem de bijbehorende rol aan de licentie. Verwijder je de licentie, dan vervalt de rol automatisch.

Wat is het verschil tussen omgevingsrollen en Dataverse-beveiligingsrollen? #

Omgevingsrollen regelen de toegang tot de omgeving zelf: wie mag bouwen en wie mag beheren. Dataverse-beveiligingsrollen bepalen de toegang tot specifieke tabellen, records en velden binnen die omgeving. Beide lagen werken samen, en het ontbreken van een Dataverse-rol kan toegang blokkeren ondanks een geldige omgevingsrol.

Concreet: een gebruiker met de Environment Maker-rol mag apps bouwen, maar zonder een passende Dataverse-beveiligingsrol kan diezelfde gebruiker geen enkele tabel lezen of bewerken. In omgevingen zonder Dataverse zijn Environment Admin en Environment Maker de enige beschikbare rollen. Zodra Dataverse is ingeschakeld, verschuift het zwaartepunt van de toegangscontrole in Power Apps naar het fijnmazige Dataverse-model.

Hoe werkt recordniveau-toegang via business units in Dataverse? #

Business units zijn hiërarchisch opgebouwde organisatie-eenheden in Dataverse die bepalen welke gebruikers welke records kunnen zien. Elke omgeving heeft één root business unit, waaronder child business units kunnen worden aangemaakt. Het eigenaarschap van een record bepaalt de zichtbaarheid: een record behoort tot de business unit van de eigenaar, en de beveiligingsrol van de gebruiker bepaalt of die toegang heeft tot records binnen de eigen unit, child units of de gehele organisatie.

Toegang tot een record wordt bepaald door de combinatie van alle beveiligingsrollen van een gebruiker, de business unit waaraan die gekoppeld is, teamlidmaatschappen en expliciet gedeelde records. Alle toegang is cumulatief — de ruimste machtiging wint altijd. Met access teams en teamgebaseerde beveiliging voeg je aanvullende controle toe zonder extra business units aan te maken.

Welke veelgemaakte fouten ontstaan bij het inrichten van toegangscontrole? #

Bij het inrichten van Power Platform-beveiliging zien we regelmatig dezelfde configuratiefouten terugkomen:

• Te brede omgevingsrollen toewijzen — te veel System Admins aanmaken geeft onnodig brede toegang. Houd dit aantal beperkt tot een paar vertrouwde IT-leads.
• Dataverse- en omgevingsrollen door elkaar halen — aannemen dat een Environment Admin automatisch datatoegang heeft, terwijl daarvoor een aparte Dataverse-rol nodig is.
• Rechten op kolomniveau vergeten — column-level security wordt vaak over het hoofd gezien, waardoor gevoelige velden onbedoeld zichtbaar zijn voor gebruikers die wél tabeltoegang hebben.
• Onbeheerde gastgebruikers — externe gebruikers die toegang behouden nadat een samenwerking is beëindigd, vormen een beveiligingsrisico zonder periodieke review.
• Geen omgevingsscheiding — ontwikkel-, test- en productiedata door elkaar laten lopen vergroot de kans op onbedoelde blootstelling van gevoelige informatie.

Wanneer is een aangepaste beveiligingsrol de juiste keuze? #

Een aangepaste beveiligingsrol is de juiste keuze wanneer standaardrollen te brede of juist te beperkte machtigingen bieden voor jouw specifieke situatie. Denk aan scenario’s met afdelingsspecifieke apps, aangepaste tabellen die specifieke CRUD-rechten vereisen, of wanneer je het principe van minimale rechten (least privilege) strikt wilt toepassen.

De best practice is om een bestaande rol, bij voorkeur de Basic User- of System Customizer-rol, te kopiëren en vervolgens alleen de benodigde machtigingen toe te voegen of te verwijderen. Bouw nooit een rol helemaal vanaf nul op; dat vergroot het risico op ontbrekende basismachtigingen. Alleen een System Administrator kan beveiligingsrollen aanmaken of bewerken, en aangepaste rollen zijn solution-aware, zodat je ze via managed solutions kunt uitrollen naar andere omgevingen.

Hoe beheers en audit je toegangsrollen in de praktijk? #

Na de initiële inrichting is structureel onderhoud essentieel. Gebruik het Power Platform Admin Center voor rolrapporten en het overzicht van toegewezen beveiligingsrollen per omgeving. Schakel Dataverse Audit Logs in om datawijzigingen en gebruikersactiviteiten te traceren, en koppel deze logs aan Azure AD-auditlogs voor een compleet beeld van toegangswijzigingen.

Voer periodieke toegangsreviews uit: controleer minstens per kwartaal of gebruikers nog de juiste rollen hebben en of er ongebruikte accounts actief zijn. Naarmate je omgeving groeit met meerdere apps en teams, wordt een governance-beleid onmisbaar, inclusief duidelijk eigenaarschap van apps, DLP-beleid voor connectors en managed solutions in productieomgevingen.

Een doordachte inrichting van rolgebaseerde toegangscontrole binnen Power Platform bespaart je niet alleen beveiligingshoofdpijn, maar maakt je omgeving ook schaalbaarder en eenvoudiger te beheren. Bij het bouwen van oplossingen zoals Cloudigy CRM passen wij deze beveiligingsprincipes toe binnen de bestaande Microsoft-infrastructuur van onze klanten. Wil je sparren over de juiste rollen en machtigingen voor jouw organisatie? Neem gerust contact met ons op, we denken graag mee.