Azure: Beveiligingsgroepen Aanmaken Beperken Tot Beheerders

Beveiligingsgroepen bepalen de toegang tot Azure-resources, SharePoint-sites en applicaties binnen een organisatie. Wanneer gewone gebruikers de mogelijkheid hebben om zelf beveiligingsgroepen aan te maken, ontstaan er aanzienlijke beveiligingsrisico's. Gebruikers kunnen op deze manier het toegangsbeheer omzeilen door zelf een beheerdersgroep te creëren, buitensporige machtigingen aan zichzelf of collega's toe te kennen, of schaduw-IT-groepen opzetten buiten de IT-governance om. Het aanmaken van beveiligingsgroepen moet daarom beperkt blijven tot het IT-team om een correct toegangsbeheer, adequaat beheer en een volledige auditlogboek te waarborgen. Deze maatregel vormt een fundamenteel onderdeel van het principe van minimale rechtenverlening en voorkomt dat gebruikers onbevoegd toegang krijgen tot kritieke systemen en gegevens.

Implementatie

Deze controle configureert de Azure AD-instellingen zodanig dat gewone gebruikers geen beveiligingsgroepen meer kunnen aanmaken. In de Azure AD-instellingen wordt de optie 'Gebruikers kunnen beveiligingsgroepen aanmaken' ingesteld op 'Nee'. Alleen beheerders met de rol Groepsbeheerder kunnen nog beveiligingsgroepen creëren. Deze configuratie voorkomt dat gewone gebruikers beveiligingsgroepen kunnen aanmaken, leden kunnen toevoegen aan beveiligingsgroepen, of eigendom van groepen kunnen claimen. Het is belangrijk om te benadrukken dat gebruikers nog steeds Microsoft 365-groepen kunnen creëren indien dit toegestaan is voor samenwerkingsdoeleinden, en distributielijsten kunnen aanmaken voor e-mailcommunicatie. Deze scheiding tussen samenwerkingsgroepen en beveiligingsgroepen zorgt voor een duidelijk onderscheid tussen functionele samenwerking en beveiligingsgerelateerd toegangsbeheer, waardoor organisaties flexibiliteit behouden voor samenwerking terwijl ze strikte controle uitoefenen over beveiligingsgerelateerde toegangsrechten.

Vereisten

Voor het succesvol implementeren van deze beveiligingscontrole zijn verschillende technische en organisatorische vereisten noodzakelijk die ervoor zorgen dat de implementatie niet alleen technisch correct wordt uitgevoerd, maar ook dat de organisatie volledig voorbereid is op de operationele veranderingen die deze maatregel met zich meebrengt. Deze voorbereiding is essentieel omdat de wijziging directe impact heeft op hoe gebruikers binnen de organisatie toegang krijgen tot resources en hoe het IT-team beveiligingsgroepen beheert. Toegang met globale beheerdersrechten vormt de fundamentele vereiste voor het wijzigen van de Azure AD-instellingen die bepalen wie beveiligingsgroepen kan aanmaken. Alleen een globale beheerder beschikt over de benodigde machtigingen om deze tenantniveau-instellingen te wijzigen, omdat deze configuratie op het hoogste niveau wordt geplaatst en directe invloed heeft op de beveiligingsstatus van de gehele organisatie. Het is cruciaal dat deze wijziging wordt uitgevoerd door een bevoegde IT-beheerder die volledig begrijpt wat de impact is van deze configuratie op gebruikers en processen, en die beschikt over de nodige kennis van Azure AD-architectuur en toegangsbeheerprincipes om te kunnen inschatten welke gevolgen deze wijziging heeft voor bestaande workflows en gebruikerservaring. Deze persoon moet ook in staat zijn om te communiceren met verschillende stakeholders binnen de organisatie over de noodzaak en impact van deze wijziging. Een duidelijk en gebruiksvriendelijk proces voor het aanvragen van nieuwe beveiligingsgroepen moet worden opgezet voordat de restrictie wordt geactiveerd, zodat gebruikers een eenvoudig alternatief hebben om legitieme behoeften aan te geven zonder dat hun werkzaamheden worden belemmerd. Dit proces moet naadloos integreren met bestaande IT-serviceprocessen en moet voldoende controle bieden aan het IT-team om te kunnen beoordelen of een aanvraag gerechtvaardigd is en of deze past binnen het beveiligingsbeleid van de organisatie. Het aanvraagproces moet een gestructureerd aanvraagformulier bevatten met duidelijke vragen over het doel van de groep, de verwachte gebruikers, de resources waartoe toegang nodig is, en de verwachte duur van de toegang. Daarnaast moet er een goedkeuringsworkflow zijn waarbij de aanvraag wordt beoordeeld door een bevoegde persoon die kan inschatten of de gevraagde groep nodig is of dat bestaande groepen kunnen worden gebruikt, en die kan beoordelen of de gevraagde toegang past binnen het principe van minimale rechtenverlening. Een communicatieproces waarbij de aanvrager op de hoogte wordt gehouden van de status van zijn aanvraag is essentieel, zodat gebruikers niet in het duister tasten over wat er met hun aanvraag gebeurt en wanneer zij een reactie kunnen verwachten. De juiste roltoewijzingen moeten worden geconfigureerd volgens het principe van minimale rechtenverlening, waarbij specifiek de rol Groepsbeheerder wordt toegewezen aan leden van het IT-team die verantwoordelijk zijn voor het beheer van beveiligingsgroepen. Deze rol geeft de benodigde machtigingen om beveiligingsgroepen aan te maken en te beheren, zonder dat deze personen de uitgebreide globale beheerdersrechten nodig hebben die vaak meer macht geven dan nodig is voor hun dagelijkse werkzaamheden. Door alleen de minimale benodigde machtigingen te verlenen, wordt het risico geminimaliseerd dat onbevoegde personen toegang krijgen tot gevoelige functionaliteit, en wordt de organisatie beter beschermd tegen zowel externe bedreigingen als interne fouten. Het is belangrijk om regelmatig te controleren wie deze rol heeft en om deze controle te automatiseren waar mogelijk, zodat wijzigingen in roltoewijzingen direct worden gedetecteerd. Periodieke rapporten die aangeven wie de rol Groepsbeheerder heeft, wanneer deze rol is toegewezen, en of er recent wijzigingen zijn geweest, helpen bij het identificeren van onbevoegde toegang of ongeautoriseerde wijzigingen en vormen waardevolle input voor compliance-audits. Een afzonderlijk beleid moet worden geformuleerd voor het aanmaken van Microsoft 365-groepen, aangezien deze groepen een fundamenteel andere functie hebben dan beveiligingsgroepen en daarom andere beveiligingsoverwegingen vereisen. Microsoft 365-groepen zijn primair bedoeld voor samenwerking en communicatie tussen teamleden, terwijl beveiligingsgroepen specifiek worden gebruikt voor toegangsbeheer en machtigingstoewijzing. Het is daarom logisch en noodzakelijk dat deze verschillende typen groepen verschillende beleidsregels hebben die passen bij hun respectievelijke functies en de risico's die zij met zich meebrengen. Organisaties moeten een bewuste beslissing nemen over of gewone gebruikers Microsoft 365-groepen mogen aanmaken, of dat ook dit beperkt moet worden tot beheerders, waarbij verschillende factoren worden meegenomen zoals de organisatiecultuur, de behoefte aan flexibiliteit in samenwerking, de omvang van de organisatie, en de risicobereidheid. Een grote organisatie met veel teams die snel moeten kunnen samenwerken heeft andere behoeften dan een kleine organisatie waar alle samenwerking centraal kan worden gecoördineerd, en deze verschillen moeten worden weerspiegeld in het beleid. Ongeacht de keuze die wordt gemaakt, moet dit beleid duidelijk en proactief worden gecommuniceerd naar alle gebruikers in de organisatie, zodat er geen verwarring ontstaat over wat wel en niet is toegestaan en gebruikers begrijpen waarom bepaalde restricties gelden. Dit beleid moet worden opgenomen in gebruikershandleidingen, intranetpagina's, en tijdens onboarding van nieuwe medewerkers, zodat iedereen vanaf het begin op de hoogte is van de regels en verwachtingen.

Implementatie

De implementatie van deze beveiligingscontrole vereist een gestructureerde aanpak waarbij zowel technische configuratie als organisatorische voorbereiding uitgebreid aandacht krijgen. De technische implementatie kan worden uitgevoerd via de Azure-portal voor handmatige configuratie, of programmatisch via PowerShell voor geautomatiseerde en reproduceerbare implementatie. De programmatische aanpak heeft de voorkeur omdat deze reproduceerbaarheid biedt, beter te documenteren is, en kan worden opgenomen in infrastructure-as-code workflows die veel organisaties tegenwoordig hanteren voor het beheer van hun cloudomgevingen. De eerste stap in de implementatie is het navigeren naar de juiste instellingen in Azure Active Directory via de Azure-portal. Start door naar Azure Active Directory te navigeren, vervolgens naar het menu-item Groepen te gaan, en dan naar de sectie Algemene instellingen. Hier vindt u de configuratieoptie met de naam 'Gebruikers kunnen beveiligingsgroepen aanmaken'. Deze instelling moet worden gewijzigd van de standaardwaarde 'Ja' naar 'Nee' om de beveiligingscontrole te activeren. Deze wijziging heeft onmiddellijk effect zodra de instelling is opgeslagen: vanaf dat moment kunnen gewone gebruikers geen nieuwe beveiligingsgroepen meer aanmaken via de Azure-portal, het Microsoft 365-beheercentrum, of via programmatische API-aanroepen. Het is belangrijk om te realiseren dat deze wijziging globaal van toepassing is voor de hele Azure AD-tenant en niet kan worden gefilterd op basis van specifieke gebruikers of groepen. Voor geautomatiseerde implementatie en toekomstige compliance-verificatie kan het bijgeleverde PowerShell-script worden gebruikt dat speciaal is ontwikkeld voor deze beveiligingscontrole. Dit script maakt gebruik van de Microsoft Graph API om verbinding te maken met Azure AD, haalt de huidige waarde van de instelling op, en past deze automatisch aan indien de waarde niet overeenkomt met de gewenste configuratie. Het script biedt uitgebreide functionaliteit voor het testen van wijzigingen in een testomgeving voordat deze worden doorgevoerd in de productie-tenant, wat sterk wordt aanbevolen om onverwachte gevolgen te voorkomen. Daarnaast genereert het script gedetailleerde auditlogboeken waarin wordt vastgelegd wanneer de wijziging is doorgevoerd, door welke gebruiker of service principal het script is uitgevoerd, en wat de oude en nieuwe waarden waren. Deze auditlogboeken zijn waardevol voor compliance-doeleinden en kunnen worden gebruikt als bewijs tijdens externe audits. Na de technische configuratie moet er een gestructureerd aanvraagproces worden opgezet voor nieuwe beveiligingsgroepen dat naadloos integreert met de bestaande IT-serviceprocessen van de organisatie. Dit proces kan worden geïmplementeerd via verschillende methoden afhankelijk van de tools en systemen die de organisatie al gebruikt. Een eenvoudige aanpak is een gestructureerd e-mailformulier dat gebruikers kunnen invullen en naar het IT-team kunnen sturen, maar voor grotere organisaties is een ticketingsysteem zoals ServiceNow of Jira aanbevolen omdat deze systemen betere tracking en rapportage bieden. Voor organisaties die volledig geautomatiseerde workflows willen, kan een speciaal ontwikkelde webapplicatie worden gebouwd die is geïntegreerd met Azure AD en automatisch aanvragen kan routeren naar de juiste goedkeurders. Ongeacht de gekozen methode moet het proces gebruiksvriendelijk en duidelijk zijn voor eindgebruikers, en moet er een service level agreement worden vastgesteld die de verwachte verwerkingstijd van aanvragen definieert. Deze SLA helpt gebruikers te begrijpen hoe lang zij moeten wachten op een reactie en zorgt ervoor dat het IT-team een heldere richtlijn heeft voor de prioritering van aanvragen. De volgende kritieke stap is het zorgvuldig toewijzen van de rol Groepsbeheerder aan de juiste personen binnen het IT-team die verantwoordelijk zijn voor het dagelijkse beheer van beveiligingsgroepen. Deze roltoewijzing kan worden uitgevoerd via de Azure-portal door te navigeren naar Azure Active Directory, vervolgens naar het menu-item Rollen en beheerders, en dan de rol Groepsbeheerder te selecteren. Het is van fundamenteel belang om alleen personen deze rol toe te wijzen die daadwerkelijk verantwoordelijk zijn voor het beheer van beveiligingsgroepen en die voldoende kennis hebben van de organisatie en haar toegangsbeheerprocessen. Daarnaast moet deze roltoewijzing regelmatig worden gecontroleerd en geaudit om te verifiëren dat deze nog steeds correct is en dat personen die de organisatie hebben verlaten of van functie zijn gewisseld niet langer deze machtige rol hebben. Overweeg om een goedkeuringsproces in te stellen voor alle roltoewijzingen waarbij een andere beheerder of manager expliciet moet goedkeuren voordat iemand de rol Groepsbeheerder krijgt toegewezen. Dit tweede paar ogen helpt bij het voorkomen van onbevoegde of onjuiste roltoewijzingen. Daarnaast moeten er uitgebreide naamgevingsstandaarden worden gedocumenteerd en gehandhaafd voor alle beveiligingsgroepen die binnen de organisatie worden aangemaakt. Deze standaarden zijn essentieel voor het organiseren van groepen, maken het veel eenvoudiger om te begrijpen wat het doel en de scope van een groep is zonder eerst de ledenlijst te hoeven bekijken, en faciliteren aanzienlijk het beheer en de auditing van toegangsrechten. De naamgevingsstandaarden moeten minimaal een prefix of suffix bevatten die het type groep duidelijk aangeeft, zoals 'SEC-' voor algemene beveiligingsgroepen of 'ADMIN-' voor beheerdersgroepen. Daarnaast moet er een duidelijke en gestandaardiseerde beschrijving worden gebruikt die uitlegt wat het doel van de groep is, welke resources toegankelijk zijn via deze groep, en wie verantwoordelijk is voor het beheer. Richtlijnen voor het gebruik van afkortingen, speciale tekens, en de maximale lengte van groepnamen moeten ook worden vastgelegd om consistentie te waarborgen. Deze standaarden moeten worden gecommuniceerd naar alle personen die beveiligingsgroepen kunnen aanmaken, en moeten strikt worden gehandhaafd tijdens het goedkeuringsproces waarbij aanvragen die niet voldoen aan de standaarden worden afgewezen of terugverwezen voor correctie. Tot slot moet het nieuwe beleid proactief en duidelijk worden gecommuniceerd naar alle gebruikers in de organisatie om te voorkomen dat gebruikers verrast worden door de wijziging en om te zorgen voor breed draagvlak. Deze communicatie moet een duidelijke uitleg bevatten over waarom deze maatregel wordt genomen vanuit beveiligings- en complianceperspectief, wat de concrete impact is voor individuele gebruikers in hun dagelijkse werkzaamheden, en hoe zij op een eenvoudige manier nieuwe beveiligingsgroepen kunnen aanvragen wanneer deze nodig zijn. Overweeg om meerdere communicatiekanalen te gebruiken zoals een informatieve e-mail die naar alle medewerkers wordt gestuurd, een gedetailleerd artikel op het intranet dat beschikbaar blijft voor toekomstige referentie, of een presentatie tijdens een teammeeting of webcast waar gebruikers vragen kunnen stellen. Het is cruciaal om ook expliciet te benadrukken dat Microsoft 365-groepen en distributielijsten nog steeds kunnen worden aangemaakt indien dit toegestaan is door het beleid, zodat gebruikers begrijpen dat deze maatregel specifiek gericht is op beveiligingsgroepen en dat samenwerking niet wordt belemmerd. Deze transparante communicatie helpt bij het verkrijgen van gebruikersacceptatie en voorkomt dat gebruikers proberen de maatregel te omzeilen.

Gebruik PowerShell-script users-cannot-create-security-groups.ps1 (functie Invoke-Implementation) – Automatische implementatie via PowerShell-script.

Compliance en Auditing

De implementatie van deze beveiligingscontrole draagt direct bij aan de naleving van verschillende belangrijke beveiligingsstandaarden en regelgeving die van toepassing zijn op Nederlandse overheidsorganisaties en andere organisaties die werken met gevoelige gegevens. Het beperken van het aanmaken van beveiligingsgroepen is niet alleen een best practice, maar ook een expliciete vereiste in meerdere compliance frameworks. De CIS Azure Foundation Benchmark versie 3.0.0 bevat in controle 1.15 de expliciete aanbeveling om ervoor te zorgen dat gebruikers geen beveiligingsgroepen kunnen aanmaken. Deze benchmark wordt wereldwijd erkend als een autoriteit op het gebied van cloudbeveiliging en wordt vaak gebruikt als basis voor security assessments. De controle valt onder niveau 2 (L2), wat betekent dat deze wordt aanbevolen voor organisaties die een hoger beveiligingsniveau nastreven. Naleving van deze controle is essentieel voor organisaties die een CIS-compliant omgeving willen realiseren en kan worden geverifieerd tijdens externe audits. Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van groot belang. Thema 09.01 en 09.02 binnen de BIO behandelen respectievelijk toegangsbeheer en beheer van toegangsrechten. Het beperken van het aanmaken van beveiligingsgroepen tot bevoegde personen draagt direct bij aan beide thema's. Thema 09.01 richt zich op het bepalen wie toegang heeft tot welke informatie, terwijl thema 09.02 zich richt op het beheren en controleren van deze toegangsrechten. Door gebruikers te voorkomen zelf beveiligingsgroepen aan te maken, wordt voorkomen dat toegangsrechten buiten de gecontroleerde processen om worden toegekend, wat een fundamenteel onderdeel is van beide BIO-thema's. De internationale standaard ISO 27001:2022 bevat in controle A.5.18 specifieke eisen voor toegangsrechtenbeheer. Deze controle vereist dat organisaties een proces hebben voor het toekennen, wijzigen en intrekken van toegangsrechten, en dat dit proces wordt gecontroleerd en geaudit. Het toestaan dat gebruikers zelf beveiligingsgroepen aanmaken zou in strijd zijn met deze controle, omdat er dan geen gecontroleerd proces is voor het toekennen van toegangsrechten. Door deze maatregel te implementeren, zorgt een organisatie ervoor dat alle toekenning van toegangsrechten plaatsvindt via een gecontroleerd proces dat kan worden geaudit en geverifieerd. De NIS2-richtlijn (Network and Information Systems Directive 2) is van toepassing op essentiële en belangrijke entiteiten binnen de Europese Unie, waaronder veel overheidsorganisaties. Artikel 21 van de NIS2-richtlijn behandelt beveiligingsmaatregelen voor toegangscontrole en authenticatie. Hoewel de richtlijn niet expliciet vermeldt dat gebruikers geen beveiligingsgroepen mogen aanmaken, vereist het artikel wel dat organisaties passende maatregelen nemen om ongeautoriseerde toegang te voorkomen. Het beperken van het aanmaken van beveiligingsgroepen is een concrete implementatie van deze vereiste, omdat het voorkomt dat gebruikers onbevoegd toegangsrechten kunnen toekennen. Naast deze specifieke compliance-vereisten is het belangrijk om regelmatig te auditen of de controle daadwerkelijk effectief is geïmplementeerd. Dit kan worden gedaan door periodiek te controleren of de Azure AD-instelling correct is geconfigureerd, door te verifiëren wie de rol Groepsbeheerder heeft, en door te monitoren of er pogingen zijn gedaan door gewone gebruikers om beveiligingsgroepen aan te maken. Deze auditactiviteiten moeten worden gedocumenteerd en kunnen worden gebruikt als bewijs tijdens externe audits of compliance-verificaties.

Monitoring

Effectieve en continue monitoring van deze beveiligingscontrole is essentieel om te waarborgen dat de configuratie correct blijft geconfigureerd en dat er geen ongeautoriseerde wijzigingen plaatsvinden die de beveiligingspostuur van de organisatie kunnen verzwakken. Monitoring moet zowel proactief als reactief zijn om een volledig beeld te krijgen van de status en effectiviteit van de controle. Proactieve monitoring vindt plaats door regelmatig en volgens een vastgesteld schema te controleren of de instelling nog steeds correct is geconfigureerd en of er geen wijzigingen zijn aangebracht zonder autorisatie. Reactieve monitoring richt zich op het detecteren en analyseren van gebeurtenissen wanneer deze zich voordoen, zoals wanneer er pogingen worden gedaan om de instelling te wijzigen of wanneer gebruikers proberen beveiligingsgroepen aan te maken ondanks de restrictie. Deze combinatie van proactieve en reactieve monitoring zorgt ervoor dat problemen snel worden geïdentificeerd en aangepakt voordat ze kunnen leiden tot beveiligingsincidenten. De primaire en meest kritieke monitoringactiviteit is het periodiek en systematisch controleren van de Azure AD-instelling 'Gebruikers kunnen beveiligingsgroepen aanmaken' om te verifiëren dat deze nog steeds correct is geconfigureerd op de waarde 'Nee'. Deze controle moet minimaal maandelijks worden uitgevoerd voor de meeste organisaties, maar voor organisaties met hoge beveiligingseisen zoals financiële instellingen of organisaties die werken met zeer gevoelige gegevens, wordt wekelijkse of zelfs dagelijkse controle aanbevolen. Het bijgeleverde PowerShell-script kan worden gebruikt om deze controle volledig te automatiseren, waardoor menselijke fouten worden geminimaliseerd en consistentie wordt gewaarborgd. Het script maakt gebruik van de Microsoft Graph API om verbinding te maken met Azure AD, haalt de huidige waarde van de instelling op met behulp van de juiste API-endpoints, en vergelijkt deze automatisch met de gewenste waarde. Als de instelling niet correct is geconfigureerd of afwijkt van de gewenste waarde, genereert het script onmiddellijk een gedetailleerde waarschuwing die kan worden verzonden naar het IT-team via e-mail, naar een monitoringoplossing zoals Azure Monitor voor verdere verwerking en escalatie, of naar een SIEM-systeem voor gecentraliseerde beveiligingsmonitoring en correlatie met andere beveiligingsgebeurtenissen. Naast het controleren van de instelling zelf is het van groot belang om regelmatig te monitoren wie de rol Groepsbeheerder heeft en of deze roltoewijzingen nog steeds correct en geautoriseerd zijn. Deze roltoewijzingen moeten minimaal kwartaal worden gecontroleerd, maar maandelijks is aanbevolen voor organisaties met frequente personeelswijzigingen. De controle moet verifiëren dat alleen bevoegde personen deze machtige rol hebben, dat personen die de organisatie hebben verlaten of van functie zijn gewisseld niet langer deze rol hebben, en dat nieuwe toewijzingen zijn goedgekeurd volgens het vastgestelde goedkeuringsproces. Alle wijzigingen in roltoewijzingen moeten worden gelogd en geaudit met details over wanneer de wijziging heeft plaatsgevonden, wie de wijziging heeft doorgevoerd, en wat de reden voor de wijziging was. Overweeg om een geautomatiseerde alert in te stellen die onmiddellijk wordt geactiveerd wanneer iemand de rol Groepsbeheerder krijgt of verliest, zodat het IT-team direct op de hoogte is van wijzigingen en deze kan verifiëren op legitimiteit. Deze alerts helpen bij het snel detecteren van onbevoegde roltoewijzingen die mogelijk wijzen op kwaadwillende activiteit of menselijke fouten. Een andere belangrijke monitoringactiviteit is het systematisch detecteren en analyseren van pogingen door gewone gebruikers om beveiligingsgroepen aan te maken, zelfs wanneer deze pogingen technisch gezien zullen falen vanwege de correct geconfigureerde restrictie. Hoewel deze pogingen niet zullen leiden tot het daadwerkelijk aanmaken van beveiligingsgroepen, is het zeer waardevol om te weten wanneer dergelijke pogingen plaatsvinden omdat deze waardevolle inzichten kunnen opleveren over verschillende aspecten van de beveiligingspostuur. Een groot aantal pogingen kan bijvoorbeeld wijzen op gebruikers die niet op de hoogte zijn van het nieuwe beleid en die mogelijk frustratie ervaren omdat zij verwachten beveiligingsgroepen te kunnen aanmaken. Dit signaleert een mogelijk probleem met de communicatie over het beleid en kan aanleiding zijn voor aanvullende training of communicatie. Daarnaast kunnen meerdere mislukte pogingen van dezelfde gebruiker of binnen een korte tijdsperiode wijzen op kwaadwillende activiteit waarbij iemand probeert toegangsrechten te verkrijgen door het omzeilen van beveiligingscontroles. Azure AD-auditlogboeken bevatten uitgebreide informatie over dergelijke pogingen inclusief tijdstempels, gebruikersidentiteiten, en de gebruikte methode, en deze logboeken moeten regelmatig worden geanalyseerd door het IT-team of via geautomatiseerde tools. Overweeg om een geautomatiseerde analyse in te stellen die waarschuwingen genereert wanneer er meerdere mislukte pogingen worden gedetecteerd van dezelfde gebruiker binnen een bepaalde tijdsperiode, of wanneer er een ongebruikelijk hoog aantal pogingen wordt gedetecteerd binnen de organisatie, zodat het IT-team proactief kan reageren op potentieel verdachte activiteit. Tot slot moet de monitoring ook uitgebreid aandacht besteden aan het aanvraagproces voor nieuwe beveiligingsgroepen om te waarborgen dat dit proces effectief functioneert en dat gebruikers niet onnodig worden belemmerd in hun werkzaamheden. Het is belangrijk om verschillende kernprestatie-indicatoren te meten en te monitoren die inzicht geven in de effectiviteit en efficiëntie van het proces. Meet bijvoorbeeld hoe lang het duurt voordat aanvragen worden verwerkt vanaf het moment van indiening tot het moment van goedkeuring of afwijzing, hoeveel aanvragen er binnenkomen per week of maand, wat het percentage goedgekeurde versus afgewezen aanvragen is, en of er trends zijn die wijzen op problemen zoals een plotselinge toename in het aantal aanvragen of langere verwerkingstijden. Deze metingen helpen bij het identificeren van knelpunten in het proces, het optimaliseren van workflows, en zorgen ervoor dat het IT-team proactief kan reageren op veranderingen in de vraag naar beveiligingsgroepen. Overweeg om gedetailleerde dashboards te maken die deze statistieken en trends visueel weergeven, zodat het IT-team en management snel kunnen zien of er problemen zijn die aandacht vereisen, en zodat beslissingen kunnen worden genomen op basis van concrete data in plaats van aannames. Deze dashboards kunnen ook worden gebruikt tijdens managementrapportages om aan te tonen dat het proces effectief wordt beheerd en dat gebruikers niet onnodig worden belemmerd.

Gebruik PowerShell-script users-cannot-create-security-groups.ps1 (functie Invoke-Monitoring) – Automatische monitoring via PowerShell-script.

Remediatie

Wanneer monitoring aangeeft dat de beveiligingscontrole niet correct is geconfigureerd of dat er afwijkingen zijn geconstateerd, moet er onmiddellijk en direct actie worden ondernomen om de situatie te herstellen en de beveiligingspostuur van de organisatie te herstellen. Remediatie moet snel, gestructureerd en volgens een vastgesteld incident response-proces plaatsvinden om te voorkomen dat de organisatie langdurig blootstaat aan het significante beveiligingsrisico dat ontstaat wanneer gewone gebruikers beveiligingsgroepen kunnen aanmaken zonder controle of goedkeuring. Elke minuut dat de controle niet correct functioneert, neemt het risico toe dat onbevoegde personen toegangsrechten verkrijgen of dat beveiligingsgroepen worden aangemaakt buiten de gecontroleerde processen om. Het meest voorkomende scenario dat leidt tot remediatie is dat de Azure AD-instelling 'Gebruikers kunnen beveiligingsgroepen aanmaken' per ongeluk is gewijzigd naar 'Ja' door een beheerder die niet volledig op de hoogte was van het beleid, of dat de instelling nooit correct is geconfigureerd tijdens de initiële implementatie. In dit geval moet de instelling onmiddellijk en zonder uitstel worden gewijzigd naar 'Nee' om het beveiligingsrisico te mitigeren. Het bijgeleverde PowerShell-script kan worden gebruikt om deze wijziging automatisch en betrouwbaar door te voeren zonder risico op menselijke fouten. Het script voert eerst een controle uit op de huidige waarde van de instelling om te verifiëren dat deze inderdaad niet correct is, en als dit wordt bevestigd, wordt de instelling automatisch aangepast naar de gewenste waarde 'Nee'. Na de wijziging genereert het script een uitgebreid rapport dat documenteert wat er precies is gewijzigd, op welk exact tijdstip deze wijziging heeft plaatsgevonden, door welke gebruiker of service principal het script is uitgevoerd, en wat de oude en nieuwe waarden waren. Dit rapport is essentieel voor auditdoeleinden en kan worden gebruikt als bewijs dat de remediatie correct is uitgevoerd. Na het herstellen van de instelling naar de correcte waarde is het cruciaal om een grondig onderzoek uit te voeren naar hoe en waarom de foutieve configuratie is ontstaan, om te voorkomen dat hetzelfde probleem zich in de toekomst opnieuw voordoet. Was het een onschuldige menselijke fout waarbij een beheerder per ongeluk de verkeerde instelling heeft gewijzigd tijdens het uitvoeren van andere configuratietaken? Was het een onbedoelde wijziging door een andere beheerder die niet volledig op de hoogte was van het beleid en de gevolgen van de wijziging? Of is er mogelijk sprake van kwaadwillende activiteit waarbij iemand opzettelijk de beveiligingscontrole heeft uitgeschakeld om toegangsrechten te verkrijgen? Azure AD-auditlogboeken bevatten uitgebreide informatie die kan worden gebruikt om te achterhalen wie de instelling heeft gewijzigd, op welk exact tijdstip dit is gebeurd, vanaf welk IP-adres of apparaat de wijziging is doorgevoerd, en welke methode is gebruikt. Deze informatie is zeer waardevol voor het voorkomen van toekomstige incidenten en kan worden gebruikt om processen te verbeteren door bijvoorbeeld aanvullende controles in te stellen, training te geven aan beheerders, of goedkeuringsworkflows te implementeren die voorkomen dat één persoon kritieke instellingen kan wijzigen zonder goedkeuring. Een ander belangrijk scenario dat kan optreden tijdens remediatie is dat er beveiligingsgroepen zijn aangemaakt door gewone gebruikers voordat de controle werd geïmplementeerd, of tijdens een periode waarin de instelling onjuist was geconfigureerd waardoor gebruikers tijdelijk in staat waren om beveiligingsgroepen aan te maken. In dit geval moet er een uitgebreide en systematische review worden uitgevoerd van alle beveiligingsgroepen binnen de Azure AD-tenant om te identificeren welke groepen mogelijk onbevoegd zijn aangemaakt buiten het gecontroleerde aanvraag- en goedkeuringsproces om. Deze review moet worden uitgevoerd door het IT-team in samenwerking met de eigenaren van de resources waartoe de groepen toegang verlenen, omdat alleen zij kunnen beoordelen of een groep legitiem is en nodig is voor bedrijfsdoeleinden. Groepen die buiten het gecontroleerde proces om zijn aangemaakt moeten worden geëvalueerd op verschillende aspecten: zijn ze legitiem en noodzakelijk voor bedrijfsdoeleinden en moeten ze daarom worden behouden maar dan wel met correcte documentatie en goedkeuring achteraf, of moeten ze worden verwijderd omdat ze een beveiligingsrisico vormen doordat ze mogelijk zijn aangemaakt om toegangsrechten te verkrijgen die niet zouden zijn goedgekeurd via het normale proces? Deze evaluatie vereist zorgvuldige analyse en moet worden gedocumenteerd voor auditdoeleinden. Als er beveiligingsgroepen moeten worden verwijderd als onderdeel van de remediatie, is het van groot belang om eerst een uitgebreide impactanalyse uit te voeren om te controleren welke resources en systemen toegang verlenen aan deze groepen en welke gebruikers toegang zouden verliezen als de groep wordt verwijderd. Het ondoordacht verwijderen van een beveiligingsgroep kan leiden tot het onbedoeld verlies van toegang voor legitieme gebruikers als de groep ook wordt gebruikt voor andere doeleinden dan waarvoor deze oorspronkelijk onbevoegd was aangemaakt, of als de groep in de loop van de tijd legitieme leden heeft gekregen die afhankelijk zijn geworden van de toegang die via deze groep wordt verleend. Overweeg om eerst de groep te deactiveren in plaats van direct te verwijderen, zodat er voldoende tijd is om te verifiëren dat er geen negatieve impact is op gebruikers of bedrijfsprocessen. Tijdens deze deactivatiefase kunnen gebruikers worden geïnformeerd over de situatie en kunnen alternatieve toegangsmethoden worden georganiseerd indien nodig. Na een voldoende lange periode van monitoring en verificatie, typisch minimaal 30 dagen, kan de groep definitief worden verwijderd als er geen problemen zijn opgetreden en als alle gebruikers toegang hebben via alternatieve methoden. Tot slot moet na elke remediatie-actie een uitgebreide post-incident review worden uitgevoerd die alle aspecten van het incident en de remediatie evalueert om lessen te leren en processen te verbeteren. Deze review moet systematisch evalueren wat er goed ging tijdens de remediatie zoals snelle detectie van het probleem of effectieve samenwerking tussen teams, wat er beter had gekund zoals snellere respons of betere communicatie, welke oorzaken hebben geleid tot het incident, en welke concrete lessen kunnen worden getrokken om toekomstige incidenten te voorkomen of sneller op te lossen. De bevindingen van deze review moeten uitgebreid worden gedocumenteerd in een post-incident rapport en moeten worden gebruikt om processen, procedures, en controles te verbeteren. Overweeg om deze lessen ook te delen met andere teams binnen de organisatie zodat zij kunnen profiteren van de ervaring en vergelijkbare problemen kunnen voorkomen. Deze continue verbetering van processen op basis van geleerde lessen is essentieel voor het opbouwen van een steeds sterkere beveiligingspostuur.

Gebruik PowerShell-script users-cannot-create-security-groups.ps1 (functie Invoke-Remediation) – Automatische remediatie via PowerShell-script.

Compliance & Frameworks

• CIS M365: Control 1.15 (L2) - Zorg ervoor dat gebruikers geen beveiligingsgroepen kunnen aanmaken
• BIO: 09.01, 09.02 - BIO: Toegangsbeheer en beheer van toegangsrechten
• ISO 27001:2022: A.5.18 - Beheer van toegangsrechten
• NIS2: Artikel - Toegangscontrole en authenticatie

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

Gebruikers kunnen geen beveiligingsgroepen aanmaken: Blokkeer gewone gebruikers (alleen groepsbeheerders kunnen beveiligingsgroepen aanmaken). Microsoft 365-groepen blijven toegestaan voor samenwerking. Activatie: Azure AD → Groepen → Gebruikers kunnen beveiligingsgroepen aanmaken: Nee. Gratis. Verplicht CIS 1.15, BIO 9.01. Implementatie: 30 minuten. Gecentraliseerde beveiligingsgroep governance.

• Implementatietijd: 2.5 uur
• FTE required: 0.01 FTE