Azure: Aangepaste RBAC-rollen Documenteren En Periodiek Reviewen

💼 Management Samenvatting

Aangepaste RBAC-rollen moeten volledig gedocumenteerd zijn met rechtvaardiging, machtigingen en eigenaarschap om rolvervuiling en buitensporige machtigingen te voorkomen.

Aanbeveling
IMPLEMENTEER ROLDOCUMENTATIE
Risico zonder
Medium
Risk Score
5/10
Implementatie
8u (tech: 4u)
Van toepassing op:
Azure

Aangepaste RBAC-rollen zonder documentatie leiden tot machtigingsvervuiling waarbij niemand meer weet waarom bepaalde machtigingen zijn toegekend, verweesde rollen wanneer de maker is vertrokken en het doel onbekend is, beveiligingsrisico's door te ruime machtigingen, en auditfalen. Gedocumenteerde rollen maken periodieke beoordelingen mogelijk en zorgen voor transparantie en verantwoording binnen de organisatie.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources

Implementatie

Documentatie is vereist voor elke aangepaste rol en moet de zakelijke rechtvaardiging, toegewezen machtigingen met onderbouwing, rol-eigenaar, aanmaakdatum, beoordelingsdatum en toegewezen gebruikers of groepen bevatten. Het is essentieel om aangepaste rollen te minimaliseren en waar mogelijk gebruik te maken van ingebouwde rollen die door Microsoft zijn ontwikkeld en getest.

Vereisten

Voor het implementeren van een effectief documentatieproces voor aangepaste RBAC-rollen zijn verschillende basisvereisten noodzakelijk die zorgvuldig moeten worden overwogen voordat het proces wordt gestart. Het eerste en meest fundamentele vereiste is de beschikbaarheid van een actief Azure-abonnement met de juiste toegangsrechten om roldefinities en roltoewijzingen te kunnen bekijken en beheren. Dit vereist minimaal de rol van Lezer op het abonnementsniveau, of een aangepaste rol met specifieke leesmachtigingen voor rolbeheer. Zonder deze toegangsrechten is het onmogelijk om een volledige inventarisatie uit te voeren of om wijzigingen door te voeren wanneer dat nodig is.

Het tweede kritieke vereiste betreft de uitvoering van een volledige en nauwkeurige inventarisatie van alle roltoewijzingen binnen de Azure-omgeving. Deze inventarisatie moet niet alleen de aangepaste rollen zelf omvatten, maar ook alle gebruikers, groepen en service-principals die deze rollen hebben toegewezen gekregen. Bovendien moet de inventarisatie informatie bevatten over wanneer elke toewijzing heeft plaatsgevonden, wie de toewijzing heeft goedgekeurd, en wat de zakelijke rechtvaardiging is voor elke specifieke toewijzing. Zonder een complete en actuele inventarisatie is het onmogelijk om te bepalen welke rollen daadwerkelijk in gebruik zijn, welke rollen mogelijk verweesd zijn geraakt, en welke rollen mogelijk te ruime machtigingen bevatten die moeten worden herzien.

Het derde kritieke vereiste is de beschikbaarheid van een geschikt documentatiesysteem dat voldoet aan de specifieke behoeften van de organisatie. Dit systeem kan variëren van een eenvoudige gedeelde documentbibliotheek in SharePoint tot een gespecialiseerde governance-tool zoals Azure Policy of een externe documentatieoplossing zoals Confluence of een speciaal ontwikkelde interne tool. Het gekozen systeem moet versiebeheer ondersteunen zodat wijzigingen in de documentatie kunnen worden bijgehouden en indien nodig kunnen worden teruggedraaid. Daarnaast moet het systeem toegangscontrole bieden voor gevoelige informatie, aangezien roldocumentatie vaak details bevat over beveiligingsconfiguraties en toegangsrechten die niet voor iedereen toegankelijk moeten zijn.

Het documentatiesysteem moet ook geschikt zijn voor periodieke beoordelingen en goedkeuringsworkflows, waarbij verschillende stakeholders betrokken kunnen worden bij het beoordelen en goedkeuren van wijzigingen aan rollen. Dit kan betekenen dat het systeem notificaties moet kunnen verzenden wanneer een beoordeling moet plaatsvinden, of dat het systeem integratie moet bieden met bestaande goedkeuringssystemen binnen de organisatie. Bovendien moet het systeem geschikt zijn voor het genereren van rapporten die kunnen worden gebruikt tijdens audits of compliance-beoordelingen.

Naast deze technische vereisten is organisatorische commitment cruciaal voor het succes van het documentatieproces. Het documenteren van rollen vereist tijd en discipline van verschillende stakeholders, waaronder security officers die verantwoordelijk zijn voor het beoordelen van beveiligingsrisico's, IT-beheerders die de technische implementatie beheren, en compliance-medewerkers die ervoor zorgen dat de documentatie voldoet aan de vereisten van verschillende frameworks en standaarden. Zonder duidelijke verantwoordelijkheden en een gestructureerde aanpak zal het documentatieproces snel verwateren en niet de gewenste governance-doelen bereiken.

Daarom is het essentieel dat er een duidelijk raamwerk wordt opgesteld dat definieert wie verantwoordelijk is voor welke aspecten van het documentatieproces, welke procedures moeten worden gevolgd bij het opstellen of wijzigen van documentatie, en hoe periodieke beoordelingen worden uitgevoerd. Dit raamwerk moet worden gecommuniceerd naar alle relevante stakeholders en moet regelmatig worden geëvalueerd en bijgewerkt om ervoor te zorgen dat het effectief blijft en aansluit bij de veranderende behoeften van de organisatie.

Monitoring

Gebruik PowerShell-script custom-rbac-roles-documented.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van aangepaste RBAC-rollen is een continu proces dat regelmatige aandacht vereist. Het begint met het inventariseren van alle aangepaste rollen binnen de Azure-omgeving door gebruik te maken van PowerShell-scripts of de Azure Portal. Het monitoringproces moet systematisch alle aangepaste roldefinities identificeren en vervolgens voor elke rol verifiëren of er adequate documentatie bestaat.

Een effectief monitoringproces controleert niet alleen de aanwezigheid van documentatie, maar ook de kwaliteit en volledigheid ervan. De documentatie moet beginnen met een duidelijke beschrijving van het zakelijke doel van de rol. Deze beschrijving moet uitleggen waarom de rol bestaat, welke bedrijfsprocessen of operationele behoeften worden ondersteund, en waarom een ingebouwde Microsoft-rol niet volstaat. Zonder deze context is het onmogelijk om te beoordelen of de rol nog steeds gerechtvaardigd is of kan worden geconsolideerd met andere rollen.

Vervolgens moet de documentatie een uitgebreid overzicht bevatten van alle toegewezen machtigingen, waarbij voor elke machtiging een duidelijke onderbouwing wordt gegeven waarom deze specifieke machtiging noodzakelijk is voor het uitvoeren van de vereiste taken. Deze onderbouwing moet verder gaan dan een simpele opsomming en moet uitleggen welke specifieke acties de rolhouder moet kunnen uitvoeren en hoe deze acties bijdragen aan het zakelijke doel. Het principe van minimale bevoegdheden moet hierbij leidend zijn, wat betekent dat alleen die machtigingen moeten worden toegekend die absoluut noodzakelijk zijn en niet kunnen worden bereikt met meer beperkte machtigingen.

De documentatie moet ook de naam en contactgegevens bevatten van de rol-eigenaar die verantwoordelijk is voor het beheer en de beoordeling van de rol. Deze eigenaar moet een persoon of team zijn dat voldoende kennis heeft van zowel de technische aspecten van de rol als de zakelijke context waarin de rol wordt gebruikt. De eigenaar moet regelmatig beschikbaar zijn voor vragen en moet betrokken worden bij alle wijzigingsverzoeken. Bovendien moet de documentatie de aanmaakdatum van de rol bevatten, evenals de datum van de laatste formele beoordeling, zodat duidelijk is wanneer de rol voor het laatst is geëvalueerd en wanneer de volgende beoordeling gepland staat.

Ten slotte moet de documentatie een compleet overzicht bevatten van alle gebruikers, groepen of service-principals die deze rol momenteel hebben toegewezen gekregen. Voor elke toewijzing moet worden gedocumenteerd wie of wat de rol heeft toegewezen gekregen, wanneer deze toewijzing heeft plaatsgevonden, wie de toewijzing heeft goedgekeurd, en wat de zakelijke rechtvaardiging is voor deze specifieke toewijzing. Dit overzicht is essentieel voor het uitvoeren van periodieke beoordelingen waarbij wordt gecontroleerd of alle toewijzingen nog steeds gerechtvaardigd zijn en of er mogelijk rollen zijn die niet meer worden gebruikt maar nog steeds actief zijn.

Het is sterk aanbevolen om dit monitoringproces minimaal maandelijks uit te voeren, waarbij nieuwe aangepaste rollen worden geïdentificeerd en bestaande rollen worden gecontroleerd op wijzigingen in toewijzingen of documentatie. Tijdens deze maandelijkse controles moet worden gecontroleerd of er nieuwe aangepaste rollen zijn aangemaakt sinds de laatste controle, of er wijzigingen zijn aangebracht aan bestaande rollen, of er nieuwe toewijzingen hebben plaatsgevonden, en of de documentatie nog steeds actueel en compleet is. Deze regelmatige controles helpen bij het vroegtijdig identificeren van problemen voordat deze escaleren tot serieuze beveiligingsrisico's of compliance-problemen.

Automatisering van dit monitoringproces via PowerShell-scripts of andere geautomatiseerde tools kan de efficiëntie aanzienlijk verhogen en ervoor zorgen dat geen rollen over het hoofd worden gezien, zelfs in omgevingen met honderden of duizenden rollen. Geautomatiseerde scripts kunnen niet alleen de inventarisatie uitvoeren, maar ook automatisch rapporten genereren die aangeven welke rollen niet adequaat zijn gedocumenteerd, welke rollen mogelijk verweesd zijn, of welke rollen te ruime machtigingen bevatten. Deze automatisering vermindert niet alleen de werklast voor IT-beheerders, maar verhoogt ook de consistentie en betrouwbaarheid van het monitoringproces.

Daarnaast moeten waarschuwingen worden geconfigureerd die automatisch meldingen genereren wanneer nieuwe aangepaste rollen worden aangemaakt zonder bijbehorende documentatie, of wanneer bestaande rollen worden gewijzigd zonder dat de documentatie wordt bijgewerkt. Deze waarschuwingen kunnen worden geconfigureerd via Azure Monitor, Azure Policy, of andere monitoringtools, en moeten worden verzonden naar de relevante stakeholders zoals security officers of compliance-medewerkers. Door deze proactieve benadering kunnen problemen snel worden geïdentificeerd en opgelost voordat ze leiden tot compliance-problemen of beveiligingsrisico's.

Het monitoringproces moet ook uitgebreide aandacht besteden aan het identificeren van verweesde rollen - rollen waarvan de eigenaar de organisatie heeft verlaten zonder een opvolger aan te wijzen, of rollen die niet meer worden gebruikt maar nog steeds actief zijn binnen de Azure-omgeving. Deze rollen vormen een potentieel beveiligingsrisico omdat ze mogelijk te ruime machtigingen bevatten zonder adequate beoordeling of controle, en omdat ze kunnen worden misbruikt door kwaadwillenden die zich bewust zijn van het feit dat deze rollen mogelijk niet goed worden beheerd. Daarom moet het monitoringproces regelmatig controleren of de eigenaren van rollen nog steeds actief zijn binnen de organisatie, en of rollen die gedurende een langere periode niet zijn gebruikt nog steeds nodig zijn.

Implementatie

Gebruik PowerShell-script custom-rbac-roles-documented.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van een gestructureerd documentatieproces voor aangepaste RBAC-rollen begint met het uitvoeren van een volledige en systematische inventarisatie van alle aangepaste rollen binnen de Azure-omgeving. Dit proces moet worden gestart door gebruik te maken van de PowerShell-cmdlet Get-AzRoleDefinition met de parameter -Custom om alle aangepaste roldefinities binnen uw Azure-abonnement te identificeren. Het is belangrijk om te beseffen dat dit script moet worden uitgevoerd voor elk abonnement binnen uw tenant om een compleet en accuraat overzicht te verkrijgen, aangezien aangepaste rollen op abonnementsniveau worden gedefinieerd en niet automatisch worden gedeeld tussen abonnementen.

Tijdens deze inventarisatiefase is het essentieel om niet alleen de rollen zelf te identificeren, maar ook om voor elke rol te documenteren wanneer deze is aangemaakt, wie de rol heeft aangemaakt, en welke machtigingen de rol bevat. Bovendien moet worden geïnventariseerd welke gebruikers, groepen of service-principals momenteel deze rol hebben toegewezen gekregen, en wanneer deze toewijzingen hebben plaatsgevonden. Deze informatie vormt de basis voor het documentatieproces en helpt bij het identificeren van potentiële problemen zoals verweesde rollen of rollen met te ruime machtigingen.

Voor elke aangepaste rol die wordt geïdentificeerd tijdens de inventarisatie, moet vervolgens uitgebreide en gedetailleerde documentatie worden opgesteld die voldoet aan de vereisten van verschillende compliance-frameworks. Deze documentatie moet beginnen met een duidelijke en uitgebreide beschrijving van het zakelijke doel en de rechtvaardiging voor het bestaan van deze rol. Deze beschrijving moet uitleggen waarom de rol bestaat, welke specifieke bedrijfsprocessen of operationele behoeften worden ondersteund, en waarom een ingebouwde Microsoft-rol niet volstaat om deze behoeften te vervullen. Het is belangrijk om deze vragen grondig te beantwoorden om te voorkomen dat onnodige aangepaste rollen worden gecreëerd die de complexiteit van het toegangsbeheer onnodig verhogen en het beheer moeilijker maken.

Vervolgens moet voor elke individuele machtiging binnen de rol een gedetailleerde onderbouwing worden gegeven die uitlegt waarom deze specifieke machtiging noodzakelijk is voor het uitvoeren van de vereiste taken. Deze onderbouwing moet verder gaan dan een simpele vermelding van de machtiging en moet uitleggen welke specifieke acties de rolhouder moet kunnen uitvoeren met deze machtiging, hoe deze acties bijdragen aan het zakelijke doel van de rol, en waarom deze machtiging niet kan worden vervangen door een meer beperkte machtiging. Het principe van minimale bevoegdheden moet hierbij leidend zijn, wat betekent dat alleen die machtigingen moeten worden toegekend die absoluut noodzakelijk zijn voor het uitvoeren van de vereiste taken en die niet kunnen worden bereikt met meer beperkte machtigingen.

Elke rol moet een duidelijke en geïdentificeerde eigenaar hebben - een persoon of team die verantwoordelijk is voor het beheer, de beoordeling en de goedkeuring van wijzigingen aan de rol. Deze eigenaar moet voldoende kennis hebben van zowel de technische aspecten van de rol als de zakelijke context waarin de rol wordt gebruikt. De eigenaar moet regelmatig beschikbaar zijn voor vragen van andere stakeholders en moet betrokken worden bij alle wijzigingsverzoeken, ongeacht of deze wijzigingen betrekking hebben op de machtigingen binnen de rol, de toewijzingen van de rol, of de documentatie zelf. Daarnaast moet een duidelijk beoordelingsschema worden vastgesteld, waarbij het sterk wordt aanbevolen om minimaal elk kwartaal een formele beoordeling uit te voeren waarbij wordt gecontroleerd of de rol nog steeds nodig is, of de machtigingen nog steeds passend zijn volgens het principe van minimale bevoegdheden, en of alle toewijzingen nog steeds gerechtvaardigd zijn op basis van de huidige bedrijfsbehoeften.

Als onderdeel van het implementatieproces moeten ook verweesde of ongebruikte aangepaste rollen worden geïdentificeerd en waar mogelijk worden verwijderd om rolvervuiling te voorkomen. Een rol wordt als verweesd beschouwd wanneer de eigenaar de organisatie heeft verlaten zonder een opvolger aan te wijzen die de verantwoordelijkheid voor het beheer van de rol overneemt, of wanneer de rol gedurende een langere periode, bijvoorbeeld zes maanden of langer, niet meer is toegewezen aan gebruikers of groepen. Voordat een rol wordt verwijderd, moet echter zeer zorgvuldig worden gecontroleerd of deze niet wordt gebruikt door service-principals of beheerde identiteiten die mogelijk niet direct zichtbaar zijn in de standaard rapportage, aangezien het verwijderen van een rol die nog in gebruik is kan leiden tot het verbreken van kritieke bedrijfsprocessen of applicaties.

Compliance en Auditing

Het documenteren van aangepaste RBAC-rollen is niet alleen een best practice op het gebied van cybersecurity governance, maar vormt ook een expliciete vereiste vanuit verschillende compliance-frameworks die relevant zijn voor Nederlandse overheidsorganisaties. Deze frameworks stellen specifieke eisen aan de manier waarop organisaties toegangsrechten beheren en documenteren, en het niet naleven van deze eisen kan leiden tot ernstige gevolgen zoals auditbevindingen, het verlies van certificeringen, of zelfs boetes en sancties. Daarom is het essentieel dat organisaties een volledig begrip hebben van de compliance-vereisten die van toepassing zijn op rolbeheer en dat zij een gestructureerd proces hebben om aan deze vereisten te voldoen.

De CIS Azure Benchmark versie 1.23, een van de meest erkende beveiligingsstandaarden voor Azure-omgevingen, specificeert in controle 1.23 expliciet dat aangepaste rollen moeten worden gedocumenteerd met duidelijke rechtvaardiging en dat periodieke beoordelingen moeten worden uitgevoerd om te verifiëren dat rollen nog steeds nodig zijn en dat de toegekende machtigingen nog steeds passend zijn. Deze controle is geclassificeerd als Level 2, wat betekent dat deze wordt aanbevolen voor organisaties met verhoogde beveiligingsvereisten, zoals overheidsorganisaties die werken met gevoelige informatie of organisaties die onderworpen zijn aan strikte regelgeving. Voor Nederlandse overheidsorganisaties is naleving van deze controle vaak verplicht omdat zij doorgaans werken met persoonsgegevens en andere gevoelige informatie die extra bescherming vereist.

Het BIO-framework, dat specifiek is ontwikkeld voor de Nederlandse overheid en de publieke sector, bevat in norm 09.01 uitgebreide vereisten voor toegangscontrole en authenticatiebeleid. Deze norm vereist dat organisaties een duidelijk en formeel beleid hebben voor het beheren van toegangsrechten, inclusief het documenteren van de zakelijke rechtvaardiging voor aangepaste rollen, het uitvoeren van regelmatige beoordelingen om te verifiëren dat toegangsrechten nog steeds gerechtvaardigd zijn, en het bijhouden van auditlogs die kunnen worden gebruikt tijdens compliance-beoordelingen. Het niet naleven van deze norm kan leiden tot ernstige bevindingen tijdens audits die worden uitgevoerd door de Autoriteit Persoonsgegevens of andere toezichthouders, en kan de certificering van de organisatie volgens het BIO-framework in gevaar brengen. Voor Nederlandse overheidsorganisaties is BIO-certificering vaak verplicht, waardoor naleving van deze norm niet optioneel is maar een absolute vereiste.

ISO 27001, de internationale standaard voor informatiebeveiligingsmanagement die wereldwijd wordt erkend en gebruikt, bevat in controle A.9.1.1 specifieke en gedetailleerde vereisten voor toegangscontrolebeleid. Deze controle vereist dat organisaties een formeel en gedocumenteerd beleid hebben voor het beheren van toegangsrechten, inclusief het documenteren van alle rollen en de rechtvaardiging voor het bestaan van deze rollen, het uitvoeren van regelmatige beoordelingen om te verifiëren dat toegangsrechten nog steeds nodig zijn, en het bijhouden van uitgebreide auditlogs die kunnen worden gebruikt tijdens externe audits. Voor organisaties die ISO 27001-certificering nastreven of behouden, is adequate en volledige documentatie van aangepaste rollen absoluut essentieel om te voldoen aan de auditvereisten. Zonder deze documentatie zal een externe auditor niet in staat zijn om te verifiëren dat de organisatie voldoet aan de vereisten van de standaard, wat kan leiden tot het niet verkrijgen van certificering of het verlies van bestaande certificering.

Tijdens externe audits en certificeringsprocessen zullen auditors zeer specifiek en gedetailleerd vragen naar de documentatie van aangepaste rollen. Zij zullen willen zien dat elke aangepaste rol een duidelijke en uitgebreide zakelijke rechtvaardiging heeft die uitlegt waarom de rol bestaat en waarom een ingebouwde Microsoft-rol niet volstaat. Zij zullen willen verifiëren dat alle machtigingen binnen elke rol zijn onderbouwd volgens het principe van minimale bevoegdheden, wat betekent dat alleen die machtigingen zijn toegekend die absoluut noodzakelijk zijn voor het uitvoeren van de vereiste taken. Daarnaast zullen auditors willen zien dat er een gestructureerd en gedocumenteerd proces bestaat voor periodieke beoordeling van rollen, waarbij regelmatig wordt gecontroleerd of rollen nog steeds nodig zijn, of de machtigingen nog steeds passend zijn, en of alle toewijzingen nog steeds gerechtvaardigd zijn. Het ontbreken van deze documentatie of het niet kunnen aantonen van een adequaat beoordelingsproces kan leiden tot ernstige bevindingen die moeten worden opgelost voordat certificering kan worden verkregen of behouden, wat kan resulteren in aanzienlijke vertragingen en extra kosten.

Naast deze formele compliance-vereisten draagt goede en uitgebreide documentatie ook aanzienlijk bij aan de algemene governance en transparantie binnen de organisatie. Het stelt management in staat om geïnformeerde en weloverwogen beslissingen te nemen over toegangsbeheer op basis van concrete informatie over welke rollen bestaan, wie deze rollen hebben toegewezen gekregen, en wat de rechtvaardiging is voor elke rol en toewijzing. Deze transparantie helpt bij het identificeren van potentiële beveiligingsrisico's voordat deze problematisch worden, zoals rollen met te ruime machtigingen, verweesde rollen die niet meer worden beheerd, of toewijzingen die niet langer gerechtvaardigd zijn. Voor Nederlandse overheidsorganisaties is deze transparantie bovendien van bijzonder belang vanuit het oogpunt van verantwoording naar burgers en toezichthouders, die het recht hebben om te weten hoe de organisatie omgaat met toegangsrechten en of er adequate controles zijn om misbruik te voorkomen.

Het is belangrijk om te beseffen dat compliance niet een eenmalige activiteit is, maar een continu proces dat regelmatige aandacht en onderhoud vereist. Documentatie moet niet alleen worden opgesteld wanneer een rol wordt aangemaakt, maar moet ook regelmatig worden bijgewerkt wanneer er wijzigingen plaatsvinden in de rol, de toewijzingen, of de zakelijke context waarin de rol wordt gebruikt. Daarnaast moeten periodieke beoordelingen worden uitgevoerd volgens een vastgesteld schema, waarbij wordt gecontroleerd of rollen nog steeds nodig zijn, of de machtigingen nog steeds passend zijn, en of alle toewijzingen nog steeds gerechtvaardigd zijn. Deze continue aandacht voor compliance zorgt ervoor dat de organisatie niet alleen voldoet aan de formele vereisten, maar ook daadwerkelijk de beveiligingspostuur verbetert en risico's vermindert.

Remediatie

Gebruik PowerShell-script custom-rbac-roles-documented.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer aangepaste RBAC-rollen worden geïdentificeerd die niet adequaat zijn gedocumenteerd, moet een gestructureerd en systematisch remediatieproces worden gevolgd om ervoor te zorgen dat alle rollen voldoen aan de vereisten van verschillende compliance-frameworks en best practices. Het eerste en meest kritieke stap in dit proces is het uitvoeren van een volledige inventarisatie van alle aangepaste rollen die momenteel geen of onvolledige documentatie hebben. Deze inventarisatie moet niet alleen identificeren welke rollen problematisch zijn, maar ook de ernst van het probleem beoordelen - heeft de rol helemaal geen documentatie, of is de documentatie slechts onvolledig of verouderd?

Voor elke rol die wordt geïdentificeerd als onvoldoende gedocumenteerd, moet vervolgens worden bepaald of deze rol nog steeds nodig is of kan worden vervangen door een ingebouwde Microsoft-rol. Deze beoordeling moet worden uitgevoerd door een team van stakeholders die voldoende kennis hebben van zowel de technische aspecten van de rol als de zakelijke context waarin de rol wordt gebruikt. Tijdens deze beoordeling moet worden geanalyseerd welke specifieke machtigingen de rol bevat, of deze machtigingen kunnen worden bereikt met een of meer ingebouwde rollen, en wat de impact zou zijn van het vervangen van de aangepaste rol door ingebouwde rollen.

Voor rollen die nog steeds nodig zijn en niet kunnen worden vervangen door ingebouwde rollen, moet onmiddellijk uitgebreide documentatie worden opgesteld die voldoet aan alle vereisten. Dit documentatieproces begint met het identificeren van de oorspronkelijke maker of de huidige eigenaar van de rol, indien deze informatie beschikbaar is. Indien mogelijk, moet deze persoon worden geconsulteerd om het zakelijke doel en de rechtvaardiging voor de rol te begrijpen, aangezien deze persoon vaak de beste bron van informatie is over waarom de rol is aangemaakt en welke specifieke behoeften de rol vervult. Als de oorspronkelijke maker niet meer beschikbaar is, bijvoorbeeld omdat deze persoon de organisatie heeft verlaten, moet een nieuwe eigenaar worden aangewezen die verantwoordelijk wordt voor het beheer van de rol. Deze nieuwe eigenaar moet voldoende kennis hebben van zowel de technische als zakelijke aspecten van de rol.

De documentatie die wordt opgesteld moet alle vereiste elementen bevatten die zijn gespecificeerd in de verschillende compliance-frameworks. Dit omvat een duidelijke en uitgebreide beschrijving van het zakelijke doel van de rol, die uitlegt waarom de rol bestaat en welke bedrijfsprocessen worden ondersteund. Daarnaast moet de documentatie een volledig overzicht bevatten van alle machtigingen binnen de rol, waarbij voor elke machtiging een duidelijke onderbouwing wordt gegeven waarom deze machtiging noodzakelijk is. De documentatie moet ook de naam en contactgegevens bevatten van de rol-eigenaar, de aanmaakdatum van de rol (indien bekend) of de datum waarop de documentatie is opgesteld, en een duidelijk beoordelingsschema dat aangeeft wanneer de rol opnieuw moet worden beoordeeld.

Daarnaast moet de documentatie uitgebreide informatie bevatten over welke gebruikers, groepen of service-principals momenteel deze rol hebben toegewezen gekregen, en wat de rechtvaardiging is voor elke specifieke toewijzing. Voor elke toewijzing moet worden gedocumenteerd wie of wat de rol heeft toegewezen gekregen, wanneer deze toewijzing heeft plaatsgevonden, wie de toewijzing heeft goedgekeurd, en wat de zakelijke rechtvaardiging is voor deze toewijzing. Deze informatie is essentieel voor het uitvoeren van periodieke beoordelingen waarbij wordt gecontroleerd of alle toewijzingen nog steeds gerechtvaardigd zijn.

Voor rollen die niet meer nodig zijn of kunnen worden vervangen door ingebouwde rollen, moet een gedetailleerd migratieplan worden opgesteld dat alle aspecten van de migratie behandelt. Dit plan moet duidelijk identificeren welke ingebouwde rol of rollen de aangepaste rol kunnen vervangen, welke gebruikers, groepen of service-principals momenteel de aangepaste rol hebben toegewezen gekregen, en hoe de migratie kan worden uitgevoerd zonder de operationele continuïteit te verstoren. Het migratieplan moet ook een testfase bevatten waarbij wordt gecontroleerd of de ingebouwde rollen inderdaad alle benodigde machtigingen bieden, en een rollback-plan voor het geval er problemen optreden tijdens de migratie. Na een succesvolle migratie moet de aangepaste rol worden verwijderd om rolvervuiling te voorkomen en de complexiteit van het toegangsbeheer te verminderen.

Het is van kritiek belang om tijdens het gehele remediatieproces ook grondig en systematisch te controleren of de machtigingen binnen de aangepaste rollen nog steeds passend zijn volgens het fundamentele principe van minimale bevoegdheden. Dit principe vormt een van de hoekstenen van effectieve cybersecurity en vereist dat gebruikers, groepen en service-principals alleen die machtigingen krijgen die absoluut noodzakelijk zijn voor het uitvoeren van hun specifieke en welbepaalde taken, en niet meer. Aangepaste rollen die te ruime, overbodige of niet-onderbouwde machtigingen bevatten vormen een significant en concreet beveiligingsrisico omdat ze het aanvalsvlak vergroten en kwaadwillenden meer mogelijkheden geven om toegang te verkrijgen tot gevoelige systemen en gegevens. Deze rollen moeten daarom proactief worden geïdentificeerd, herzien en aangepast, waarbij uitsluitend die machtigingen worden behouden die absoluut onontbeerlijk zijn voor het effectief uitvoeren van de vereiste taken en die niet kunnen worden bereikt met meer beperkte of specifieke alternatieven. Dit revisieproces kan verschillende vormen aannemen, afhankelijk van de specifieke situatie en de aard van de rol. In sommige gevallen kan dit betekenen dat de rol moet worden gesplitst in meerdere meer specifieke en beperkte rollen die elk gericht zijn op een specifieke en afgebakende set van taken en verantwoordelijkheden. In andere gevallen kan dit betekenen dat bepaalde machtigingen moeten worden verwijderd of vervangen als deze niet langer noodzakelijk zijn voor het uitvoeren van de vereiste taken, of als deze machtigingen kunnen worden bereikt met meer beperkte alternatieven die een kleiner aanvalsvlak bieden. Tijdens dit gehele proces moet uiterst zorgvuldig worden gecontroleerd of het verwijderen, beperken of herstructureren van machtigingen geen negatieve impact heeft op de operationele continuïteit of de effectiviteit waarmee gebruikers hun werk kunnen uitvoeren. Deze verificatie moet worden uitgevoerd in nauwe samenwerking tussen security officers, IT-beheerders, rol-eigenaren en de gebruikers zelf om te garanderen dat het beveiligingsniveau wordt verhoogd zonder de functionaliteit onnodig te beperken.

Compliance & Frameworks

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).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Custom RBAC Roles Documented .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.16 Controleert of custom RBAC roles zijn gedocumenteerd. .NOTES Filename: custom-rbac-roles-documented.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.16 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Custom RBAC Roles Documented" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $customRoles = Get-AzRoleDefinition | Where-Object { $_.IsCustom -eq $true } $result = @{ TotalCustomRoles = $customRoles.Count } return $result } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Custom RBAC Roles: $($r.TotalCustomRoles)" -ForegroundColor White if ($r.TotalCustomRoles -gt 0) { Write-Host "`n⚠️ Zorg dat alle custom roles zijn gedocumenteerd" -ForegroundColor Yellow Write-Host "Documenteer: doel, permissions, risk assessment" -ForegroundColor Gray } } else { $r = Test-Compliance Write-Host "`nCustom RBAC Roles: $($r.TotalCustomRoles)" } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Custom RBAC Roles: $($r.TotalCustomRoles)" -ForegroundColor White if ($r.TotalCustomRoles -gt 0) { Write-Host "`n⚠️ Zorg dat alle custom roles zijn gedocumenteerd" -ForegroundColor Yellow Write-Host "Documenteer: doel, permissions, risk assessment" -ForegroundColor Gray } } else { $r = Test-Compliance Write-Host "`nCustom RBAC Roles: $($r.TotalCustomRoles)" } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
Medium: Ongedocumenteerde aangepaste RBAC-rollen leiden tot machtigingsvervuiling waarbij niemand meer weet wat het doel is, auditfalen omdat auditors geen rechtvaardiging kunnen vinden, en verweesde rollen die actief blijven zonder beheer. Dit schendt de compliance-vereisten van CIS 1.23, BIO 9.01 en ISO 27001. Het risico is gemiddeld maar vormt een significant governance-probleem dat kan escaleren tot beveiligingsincidenten.

Management Samenvatting

Documentatie van aangepaste RBAC-rollen: Documenteer het doel, machtigingen, eigenaar en goedkeuringsdatum voor elke aangepaste rol. Voer kwartaalbeoordelingen uit om te verifiëren of rollen nog nodig zijn. Activatie: Inventariseer aangepaste rollen → Documenteer → Voer kwartaalbeoordelingen uit. Geen extra kosten. Verplicht volgens CIS 1.23 en BIO 9.01. Implementatietijd: 4-8 uur. Essentiële governance best practice.