Quick Start: Beheerdersaccount Beveiliging - Dag 1-2

Geprivilegieerde accounts vertegenwoordigen de kroonjuwelen van iedere M365-tenant: ze kunnen beveiligingsinstellingen wijzigen, gegevens exporteren, service accounts aanmaken en persistent toegang achterlaten. Aanvallers richten hun campagnes daarom specifiek op beheerders door middel van spearphishing richting IT-personeel, credential stuffing met eerder gelekte wachtwoorden, social engineering tegen servicedesks en geavanceerde technieken zoals Pass-the-Hash of token theft. Wanneer organisaties nog steeds het dagelijkse gebruikersaccount ook voor beheer laten gebruiken, ontstaat een single point of failure waarbij één phishingmail genoeg is voor totale uitval van de omgeving. Ontbrekende rolsegmentatie vergroot bovendien het insider-risico en maakt auditing praktisch onmogelijk. Zonder noodtoegang kunnen zelfs goedbedoelde configuratiefouten in voorwaardelijke toegang leiden tot lock-outs van het hele team. Deze quick start adresseert die risico’s door de basisbescherming onmiddellijk te implementeren zodat alle vervolgstappen op een stabiel fundament rusten.

Implementatie

De aanpak bestaat uit vier samenhangende pijlers die in maximaal twee dagen kunnen worden uitgerold. Eerst worden twee break-glass accounts ingericht die zijn vrijgesteld van beleidsregels, een uniek sterk wachtwoord hebben en fysiek worden opgeslagen zodat de organisatie altijd kan herstellen van een misconfiguratie. Vervolgens wordt voorwaardelijke toegang verzwaard voor alle beheerdersrollen: MFA is verplicht, er mag alleen vanaf compliant beheersystemen worden gewerkt, sessies verlopen na vier uur en verdachte aanmeldingen worden direct geblokkeerd. Parallel hieraan krijgt iedere beheerder een gescheiden identiteit; het reguliere account verliest alle privileged rechten en het nieuwe adminaccount wordt stap voor stap in gebruik genomen inclusief eigen MFA-registratie en logging. Tot slot wordt het aantal Globale beheerders teruggebracht tot maximaal vijf personen (inclusief noodaccounts), bij voorkeur met Just-in-Time activering via Privileged Identity Management en kwartaalreviews. Samen zorgen deze maatregelen voor een aantoonbaar veerkrachtig en controleerbaar adminlandschap.

• Open het Entra-beheercentrum, navigeer naar Gebruikers en kies voor "Nieuwe gebruiker" om breakglass01@domein.nl aan te maken als volledig cloud-only identiteit. Voeg een duidelijke beschrijving toe waarin staat dat het account uitsluitend bedoeld is voor noodscenario’s en niet voor dagelijkse beheertaken.
• Genereer een willekeurig wachtwoord van minimaal vijfentwintig tekens met een betrouwbare wachtwoordgenerator, inclusief hoofdletters, kleine letters, cijfers en symbolen. Noteer het wachtwoord nergens digitaal, maar gebruik tijdelijk een versleutelde kladnotitie die onmiddellijk wordt verwijderd zodra de fysieke documentatie gereed is.
• Schakel het verlopen van wachtwoorden uit zodat het account niet onverwacht wordt geblokkeerd wanneer niemand beschikbaar is om een wijziging door te voeren. Leg in dezelfde handeling vast dat het account geen licentie krijgt, waardoor het uitsluitend voor beheerdoeleinden kan worden gebruikt.
• Ken de rol Globale beheerder toe en controleer in het auditlog dat de toewijzing is vastgelegd. Deze rol is noodzakelijk omdat de noodtoegang anders onvoldoende rechten heeft om een tenant daadwerkelijk te herstellen.
• Sla de multifactorregistratie bewust over, ook al druist dat in tegen het standaardbeleid. Een noodaccount moet werken zonder afhankelijkheid van fysieke tokens of sms-diensten, omdat juist die voorzieningen mogelijk niet beschikbaar zijn tijdens een calamiteit.
• Herhaal alle stappen voor het account breakglass02@domein.nl, inclusief documentatie, controles en licentievrije configuratie. Twee onafhankelijke accounts zijn noodzakelijk om single points of failure te vermijden.
• Voer direct na het aanmaken een aanmeldtest uit op beide accounts via portal.office.com om te bevestigen dat aanmelding mogelijk is zonder MFA, maar dat het wachtwoord wel correct werkt. Leg het resultaat vast in een testlogboek inclusief datum en verantwoordelijke.
• Print de wachtwoorden dubbelzijdig, verzegel ze in afzonderlijke enveloppen en plaats deze in twee fysiek gescheiden kluizen. Laat twee leidinggevenden paraferen dat de enveloppen correct zijn opgeborgen en registreer in het wachtwoordbeheerregister waar de enveloppen zich bevinden.
• Maak in Entra ID een dynamische groep "Emergency Access Accounts" aan of gebruik een statische groep wanneer dynamische lidmaatschap niet beschikbaar is. Beschrijf in het groepsmemo welke procedure geldt voor wijzigingen.
• Voeg beide break-glass accounts toe aan deze groep en controleer via PowerShell of de lidmaatschappen correct zijn gerepliceerd. Documenteer het groepsobject-ID zodat het later eenvoudig kan worden gebruikt in automatiseringsscripts.
• Sluit de ochtend af door de groep expliciet uit te sluiten van alle bestaande en toekomstige voorwaardelijke-toegangsbeleidsregels. Dit voorkomt dat een enthousiaste beheerder de noodtoegang per ongeluk blokkeert bij het uitrollen van nieuwe eisen.
• Maak in het onderdeel Voorwaardelijke toegang een nieuw beleid en kies een duidelijke naam zoals "Require MFA + Compliant Device voor Admins" zodat iedereen in dashboards onmiddellijk ziet welke controles worden afgedwongen.
• Selecteer bij gebruikers en rollen specifiek de directoryrollen Globale beheerder, Security Admin, Privileged Role Administrator, Exchange Admin en SharePoint Admin. Dit garandeert dat iedere beheerder, ongeacht toewijzing aan een individueel account, onder hetzelfde beschermingsniveau valt.
• Sluit de groep met noodtoegangsaccounts uit zodat deze identiteiten buiten het beleid blijven. Controleer met de policy simulator dat de uitsluiting daadwerkelijk wordt toegepast, anders kan het herstelplan alsnog falen.
• Kies als doel "Alle cloud-apps" zodat beheerders nooit ongemerkt op een minder beveiligde portal terechtkomen. Dit voorkomt dat een aanvaller bijvoorbeeld via een vergeten beheerinterface privilege escalation uitvoert.
• Activeer bij voorwaarden de sign-in risk policy en stel in dat zowel middelgrote als hoge risico’s altijd MFA vereisen. Combineer deze instelling met aanmeldingslocaties wanneer beheer uitsluitend vanaf Nederlandse datacenters mag plaatsvinden.
• Kies bij toestemmingen zowel "Multifactorauthenticatie vereisen" als "Apparaat moet compliant zijn". Hiermee voorkom je dat een beheerder vanaf een persoonlijke laptop of mobiel apparaat gevoelige opdrachten uitvoert.
• Beperk de sessieduur door "Aanmeldingsfrequentie" op vier uur te zetten. Regelmatige herauthenticatie verkleint het venster waarin een gestolen token kan worden misbruikt en dwingt beheerders om bewust om te gaan met hun admincontext.
• Zet het beleid eerst twee dagen in report-only modus om te meten welke applicaties of gebruikers mogelijk blokkades ervaren. Plan daarna een change moment om het beleid naar "Ingeschakeld" te schakelen en communiceer de observaties naar alle beheerteams.
• Voer per beheerdersrol een login-test uit vanaf een compliant werkstation en een niet-compliant scenario om te bevestigen dat het beleid correct blokkeert. Documenteer de resultaten inclusief screenshots zodat audit- en SOC-teams bewijs hebben.
• Plan per beheerder een moment waarop het nieuwe adminaccount wordt aangemaakt volgens de afgesproken naamgevingsconventie, bijvoorbeeld admin-voornaam.achternaam@domein.nl. Documenteer in het ticketingsysteem wie de eigenaar is en wie het verzoek heeft goedgekeurd.
• Gebruik het wachtwoordbeleid uit het identity-handboek zodat het adminaccount minimaal veertien tekens bevat en direct wordt afgedwongen door Azure AD Password Protection. Geef het wachtwoord alleen mondeling door tijdens het overdrachtsmoment en stimuleer het gebruik van wachtwoordkluizen waar toegestaan.
• Verplaats alle bestaande beheerdersrollen van het gebruikersaccount naar het nieuwe adminaccount. Doe dit stapsgewijs en controleer in auditlogs dat de toewijzing is gelukt voordat je de oude rollen verwijdert.
• Verwijder vervolgens de rollen van het dagelijkse gebruikersaccount zodat daarop geen privileges achterblijven. Het gebruikersaccount blijft volledig licentiehoudend voor e-mail en samenwerking, maar heeft nul administratieve rechten.
• Organiseer een korte training waarin de beheerder leert om het adminaccount uitsluitend op het beheersysteem te gebruiken, hoe er moet worden omgeschakeld tussen accounts en hoe logging plaatsvindt. Besteed aandacht aan scenario’s zoals PowerShell-sessies en Just-in-Time activering.
• Laat iedere beheerder een aparte MFA-registratie uitvoeren voor het adminaccount, bij voorkeur met FIDO2 of de Microsoft Authenticator app op een apart apparaat. Dit voorkomt dat een aanvaller via het dagelijkse toestel beide accounts kan misbruiken.
• Valideer na iedere migratie of het gebruikersaccount daadwerkelijk geen adminrollen meer heeft door een access review of een PowerShell-query op te vragen. Bewaar deze controles als bewijs in het auditdossier.
• Communiceer de workflowwijzigingen naar het gehele IT-team, inclusief servicedesk en change management, zodat iedereen weet dat verzoeken voortaan vanuit adminaccounts komen en dat dit geen phishingpoging is.
• Hanteer als richtlijn maximaal één beheerder per dag om productie-impact te beperken. Na twee weken moet de gehele organisatie zijn overgezet; monitor de voortgang in een dashboard en escaleer wanneer deadlines dreigen te slippen.
• Voer een audit uit in het Entra-beheercentrum of via Microsoft Graph om de huidige lijst met Globale beheerders op te vragen. Exporteer het resultaat naar CSV zodat je historische vergelijkingen kunt maken en afwijkingen zichtbaar houdt.
• Stel het maximum op vijf accounts, inclusief de twee noodaccounts, en zorg dat dit besluit door het CISO-office is bekrachtigd. Deel het maximum in alle governance-documenten zodat toekomstige projecten niet ongemerkt nieuwe Globale beheerders toevoegen.
• Bespreek per beheerder of de rol daadwerkelijk nodig is. Vaak volstaat een meer specifieke rol zoals Exchange Admin of SharePoint Admin, zeker wanneer ondersteunende taken bij een ander team liggen.
• Ken waar mogelijk least-privilege rollen toe en combineer die met monitoring. Dit verlaagt risico’s zonder de operationele slagkracht van teams te beperken.
• Verwijder overbodige Globale beheerderstoewijzingen direct na goedkeuring en vraag de betrokken beheerder om dit te testen. Indien er afhankelijkheden blijken te zijn, documenteer dan een tijdelijk uitzonderingsplan met einddatum.
• Implementeer Privileged Identity Management wanneer licenties beschikbaar zijn zodat Globale beheerderstoegang alleen just-in-time wordt verleend en automatisch verloopt. Stel activeringsbevestiging, reason codes en ticketreferenties verplicht.
• Leg voor de resterende Globale beheerders een dossier vast met eigenaar, business justification, datum van laatste review en datum van de volgende review. Bewaar dit dossier centraal zodat auditors en het securityteam het snel kunnen raadplegen.

Vereisten

De implementatie van robuuste beheerdersaccountbeveiliging vraagt om een combinatie van technische licenties, organisatorische afspraken en tastbare middelen. Zonder deze randvoorwaarden ontstaat er telkens frictie tijdens het uitrollen van de controles en loop je het risico dat teams na de eerste weerstand terugvallen op oude patronen. Neem daarom de tijd om zowel de digitale als de fysieke randvoorwaarden goed te beleggen, leg verantwoordelijkheden vast in een implementatieplan en laat directies expliciet akkoord geven op de consequenties, zoals het tijdelijk uitfaseren van oude beheerprocessen. Plan bovendien vooraf hoe supportteams vragen van beheerders gaan beantwoorden, welke escalatielijnen gelden en hoe documentatie wordt bijgewerkt na iedere mijlpaal, zodat kennis niet alleen in het projectteam aanwezig is. Deze sectie beschrijft de minimale benodigdheden die klaar moeten staan voordat dag één van de quick start begint, zodat uitvoeringsteam en security officers zich volledig kunnen richten op configuratie, validatie en communicatie.

1. Azure AD Premium P1 is de ondergrens omdat voorwaardelijke toegang inmiddels een harde vereiste is voor veilige beheerdersaccounts; kies bij voorkeur voor P2 of Microsoft Entra ID Governance wanneer Privileged Identity Management wenselijk is. Controleer per tenant welke licenties beschikbaar zijn, wijs ze tijdelijk toe aan het implementatieteam en documenteer het kostenplaatje zodat besluitvormers niet later in het traject worden verrast door aanvullende aankopen.
2. Er is minimaal één gebruiker nodig met de rol Globale beheerder om de initiële configuratie uit te voeren, beleidsregels te testen en break-glass accounts aan te maken. Documenteer welke persoon deze rol tijdelijk behoudt, welke multi-factor-methoden hij of zij gebruikt en welke fallback beschikbaar is wanneer die persoon afwezig is, zodat het project geen vertraging oploopt.
3. Voor de noodtoegangsaccounts is een fysieke kluis, brandwerende kast of beveiligd sleutelbeheer nodig waarin de lange wachtwoorden in verzegelde enveloppen worden opgeslagen. Registreer wie toegang heeft tot de kluis, welke procedure wordt gevolgd bij het openen ervan en hoe vaak het zegel wordt gecontroleerd. Zonder tastbaar opslagpunt verliest een break-glass account namelijk zijn herstelwaarde.
4. Een herkenbare naamgevingsconventie (bijvoorbeeld admin-voornaam.achternaam@domein.nl) voorkomt verwarring in logging, rapportages en PIM-workflows. Leg de conventie vast in het identity-beheerhandboek, zorg dat Azure AD Connect en HR-systemen de conventie begrijpen en reserveer alvast voldoende licenties voor deze administratieve accounts.
5. Een actueel overzicht van alle personen met beheerrechten is onmisbaar, inclusief gastaccounts, serviceaccounts en accounts van leveranciers. Documenteer per rol waarom de toegang nodig is, welke business-eigenaar toestemming gaf en wanneer de volgende review plaatsvindt. Deze inventaris vormt de basis voor het terugbrengen van het aantal Globale beheerders naar maximaal vijf.
6. Voor beheerderswerkzaamheden horen speciale werkstations beschikbaar te zijn: dit kunnen fysiek gescheiden laptops zijn of logisch gescheiden virtuele desktops, maar in alle gevallen moeten ze voldoen aan Intune- of ConfigMgr-compliance, BitLocker, up-to-date antimalware en logging naar het SIEM. Beschrijf in het securityplan hoe deze devices worden uitgegeven, beheerd en gecontroleerd.
7. Tot slot is twee uur gerichte training per beheerder noodzakelijk om de nieuwe workflow te oefenen: inloggen met een apart account, MFA-middelen registreren, werken via een adminwerkplek en noodprocedures volgen. Plan deze sessies vóórdat rollen worden omgezet, lever duidelijke handleidingen aan in het Nederlands en zorg dat er een aanspreekpunt beschikbaar is voor vragen buiten kantooruren.

Implementatie (Dag 1-2)

Gebruik PowerShell-script 02-admin-account-beveiliging.ps1 (functie Invoke-Implementation) – Implementeren.

Dag 1 begint met het opbouwen van redundantie voordat er ook maar één beleidsregel wordt aangescherpt. Break-glass accounts zijn de enige garantie dat je altijd nog kunt inloggen wanneer een voorwaardelijke-toegangsregel te streng blijkt, een certificaat is verlopen of een identiteitsprovider wereldwijd uitvalt. Reserveer daarom de volledige ochtend voor het zorgvuldig aanmaken van twee cloud-only accounts, het configureren van hun wachtwoorden en het borgen van de administratieve procedures rond opslag, logging en testmomenten. Communiceer naar het SOC dat de eerste logins tijdens deze fase verwacht worden zodat eventuele waarschuwingen niet onnodig escaleren.

Gebruik PowerShell-script 02-admin-account-beveiliging.ps1 (functie Invoke-Monitoring) – Valideer admin security configuration inclusief break-glass accounts.

1. Open het Entra-beheercentrum, navigeer naar Gebruikers en kies voor "Nieuwe gebruiker" om breakglass01@domein.nl aan te maken als volledig cloud-only identiteit. Voeg een duidelijke beschrijving toe waarin staat dat het account uitsluitend bedoeld is voor noodscenario’s en niet voor dagelijkse beheertaken.
2. Genereer een willekeurig wachtwoord van minimaal vijfentwintig tekens met een betrouwbare wachtwoordgenerator, inclusief hoofdletters, kleine letters, cijfers en symbolen. Noteer het wachtwoord nergens digitaal, maar gebruik tijdelijk een versleutelde kladnotitie die onmiddellijk wordt verwijderd zodra de fysieke documentatie gereed is.
3. Schakel het verlopen van wachtwoorden uit zodat het account niet onverwacht wordt geblokkeerd wanneer niemand beschikbaar is om een wijziging door te voeren. Leg in dezelfde handeling vast dat het account geen licentie krijgt, waardoor het uitsluitend voor beheerdoeleinden kan worden gebruikt.
4. Ken de rol Globale beheerder toe en controleer in het auditlog dat de toewijzing is vastgelegd. Deze rol is noodzakelijk omdat de noodtoegang anders onvoldoende rechten heeft om een tenant daadwerkelijk te herstellen.
5. Sla de multifactorregistratie bewust over, ook al druist dat in tegen het standaardbeleid. Een noodaccount moet werken zonder afhankelijkheid van fysieke tokens of sms-diensten, omdat juist die voorzieningen mogelijk niet beschikbaar zijn tijdens een calamiteit.
6. Herhaal alle stappen voor het account breakglass02@domein.nl, inclusief documentatie, controles en licentievrije configuratie. Twee onafhankelijke accounts zijn noodzakelijk om single points of failure te vermijden.
7. Voer direct na het aanmaken een aanmeldtest uit op beide accounts via portal.office.com om te bevestigen dat aanmelding mogelijk is zonder MFA, maar dat het wachtwoord wel correct werkt. Leg het resultaat vast in een testlogboek inclusief datum en verantwoordelijke.
8. Print de wachtwoorden dubbelzijdig, verzegel ze in afzonderlijke enveloppen en plaats deze in twee fysiek gescheiden kluizen. Laat twee leidinggevenden paraferen dat de enveloppen correct zijn opgeborgen en registreer in het wachtwoordbeheerregister waar de enveloppen zich bevinden.
9. Maak in Entra ID een dynamische groep "Emergency Access Accounts" aan of gebruik een statische groep wanneer dynamische lidmaatschap niet beschikbaar is. Beschrijf in het groepsmemo welke procedure geldt voor wijzigingen.
10. Voeg beide break-glass accounts toe aan deze groep en controleer via PowerShell of de lidmaatschappen correct zijn gerepliceerd. Documenteer het groepsobject-ID zodat het later eenvoudig kan worden gebruikt in automatiseringsscripts.
11. Sluit de ochtend af door de groep expliciet uit te sluiten van alle bestaande en toekomstige voorwaardelijke-toegangsbeleidsregels. Dit voorkomt dat een enthousiaste beheerder de noodtoegang per ongeluk blokkeert bij het uitrollen van nieuwe eisen.

Tijdens de middag van dag één wordt de toegang voor alle beheerdersrollen aangescherpt. Deze stap levert direct risicoreductie op omdat aanvallers vrijwel altijd een zwak MFA-beleid of niet-compliant apparaat misbruiken na het verkrijgen van inloggegevens. Bouw de beleidsregels in de Entra-beheerportal bij voorkeur via een change window zodat je in report-only modus kunt testen, logs kunt verzamelen en impact op dienstverleningsprocessen kunt beoordelen. Betrek het SOC en de servicedesk zodat zij weten dat beheerders mogelijk vaker moeten herauthenticeren.

1. Maak in het onderdeel Voorwaardelijke toegang een nieuw beleid en kies een duidelijke naam zoals "Require MFA + Compliant Device voor Admins" zodat iedereen in dashboards onmiddellijk ziet welke controles worden afgedwongen.
2. Selecteer bij gebruikers en rollen specifiek de directoryrollen Globale beheerder, Security Admin, Privileged Role Administrator, Exchange Admin en SharePoint Admin. Dit garandeert dat iedere beheerder, ongeacht toewijzing aan een individueel account, onder hetzelfde beschermingsniveau valt.
3. Sluit de groep met noodtoegangsaccounts uit zodat deze identiteiten buiten het beleid blijven. Controleer met de policy simulator dat de uitsluiting daadwerkelijk wordt toegepast, anders kan het herstelplan alsnog falen.
4. Kies als doel "Alle cloud-apps" zodat beheerders nooit ongemerkt op een minder beveiligde portal terechtkomen. Dit voorkomt dat een aanvaller bijvoorbeeld via een vergeten beheerinterface privilege escalation uitvoert.
5. Activeer bij voorwaarden de sign-in risk policy en stel in dat zowel middelgrote als hoge risico’s altijd MFA vereisen. Combineer deze instelling met aanmeldingslocaties wanneer beheer uitsluitend vanaf Nederlandse datacenters mag plaatsvinden.
6. Kies bij toestemmingen zowel "Multifactorauthenticatie vereisen" als "Apparaat moet compliant zijn". Hiermee voorkom je dat een beheerder vanaf een persoonlijke laptop of mobiel apparaat gevoelige opdrachten uitvoert.
7. Beperk de sessieduur door "Aanmeldingsfrequentie" op vier uur te zetten. Regelmatige herauthenticatie verkleint het venster waarin een gestolen token kan worden misbruikt en dwingt beheerders om bewust om te gaan met hun admincontext.
8. Zet het beleid eerst twee dagen in report-only modus om te meten welke applicaties of gebruikers mogelijk blokkades ervaren. Plan daarna een change moment om het beleid naar "Ingeschakeld" te schakelen en communiceer de observaties naar alle beheerteams.
9. Voer per beheerdersrol een login-test uit vanaf een compliant werkstation en een niet-compliant scenario om te bevestigen dat het beleid correct blokkeert. Documenteer de resultaten inclusief screenshots zodat audit- en SOC-teams bewijs hebben.

Dag twee staat in het teken van structurele scheiding tussen werk- en beheeraccounts. Hoewel de daadwerkelijke uitrol per team tot twee weken kan duren, leg je tijdens deze quick start het proces, de communicatie en de tooling vast. Start met de kritieke beheerders (identity, Exchange, Intune) en rol daarna uit naar overige rollen om verstoring te minimaliseren.

1. Plan per beheerder een moment waarop het nieuwe adminaccount wordt aangemaakt volgens de afgesproken naamgevingsconventie, bijvoorbeeld admin-voornaam.achternaam@domein.nl. Documenteer in het ticketingsysteem wie de eigenaar is en wie het verzoek heeft goedgekeurd.
2. Gebruik het wachtwoordbeleid uit het identity-handboek zodat het adminaccount minimaal veertien tekens bevat en direct wordt afgedwongen door Azure AD Password Protection. Geef het wachtwoord alleen mondeling door tijdens het overdrachtsmoment en stimuleer het gebruik van wachtwoordkluizen waar toegestaan.
3. Verplaats alle bestaande beheerdersrollen van het gebruikersaccount naar het nieuwe adminaccount. Doe dit stapsgewijs en controleer in auditlogs dat de toewijzing is gelukt voordat je de oude rollen verwijdert.
4. Verwijder vervolgens de rollen van het dagelijkse gebruikersaccount zodat daarop geen privileges achterblijven. Het gebruikersaccount blijft volledig licentiehoudend voor e-mail en samenwerking, maar heeft nul administratieve rechten.
5. Organiseer een korte training waarin de beheerder leert om het adminaccount uitsluitend op het beheersysteem te gebruiken, hoe er moet worden omgeschakeld tussen accounts en hoe logging plaatsvindt. Besteed aandacht aan scenario’s zoals PowerShell-sessies en Just-in-Time activering.
6. Laat iedere beheerder een aparte MFA-registratie uitvoeren voor het adminaccount, bij voorkeur met FIDO2 of de Microsoft Authenticator app op een apart apparaat. Dit voorkomt dat een aanvaller via het dagelijkse toestel beide accounts kan misbruiken.
7. Valideer na iedere migratie of het gebruikersaccount daadwerkelijk geen adminrollen meer heeft door een access review of een PowerShell-query op te vragen. Bewaar deze controles als bewijs in het auditdossier.
8. Communiceer de workflowwijzigingen naar het gehele IT-team, inclusief servicedesk en change management, zodat iedereen weet dat verzoeken voortaan vanuit adminaccounts komen en dat dit geen phishingpoging is.
9. Hanteer als richtlijn maximaal één beheerder per dag om productie-impact te beperken. Na twee weken moet de gehele organisatie zijn overgezet; monitor de voortgang in een dashboard en escaleer wanneer deadlines dreigen te slippen.

De laatste stap van de quick start richt zich op het terugbrengen van het aantal Globale beheerders en het invoeren van least privilege. Dit is noodzakelijk om de aanvalskans te minimaliseren en om audits te laten zien dat privileged toegang onder controle is. Combineer papier (rollenmatrix) met tooling (PIM, access reviews) zodat het geen eenmalige actie blijft.

1. Voer een audit uit in het Entra-beheercentrum of via Microsoft Graph om de huidige lijst met Globale beheerders op te vragen. Exporteer het resultaat naar CSV zodat je historische vergelijkingen kunt maken en afwijkingen zichtbaar houdt.
2. Stel het maximum op vijf accounts, inclusief de twee noodaccounts, en zorg dat dit besluit door het CISO-office is bekrachtigd. Deel het maximum in alle governance-documenten zodat toekomstige projecten niet ongemerkt nieuwe Globale beheerders toevoegen.
3. Bespreek per beheerder of de rol daadwerkelijk nodig is. Vaak volstaat een meer specifieke rol zoals Exchange Admin of SharePoint Admin, zeker wanneer ondersteunende taken bij een ander team liggen.
4. Ken waar mogelijk least-privilege rollen toe en combineer die met monitoring. Dit verlaagt risico’s zonder de operationele slagkracht van teams te beperken.
5. Verwijder overbodige Globale beheerderstoewijzingen direct na goedkeuring en vraag de betrokken beheerder om dit te testen. Indien er afhankelijkheden blijken te zijn, documenteer dan een tijdelijk uitzonderingsplan met einddatum.
6. Implementeer Privileged Identity Management wanneer licenties beschikbaar zijn zodat Globale beheerderstoegang alleen just-in-time wordt verleend en automatisch verloopt. Stel activeringsbevestiging, reason codes en ticketreferenties verplicht.
7. Leg voor de resterende Globale beheerders een dossier vast met eigenaar, business justification, datum van laatste review en datum van de volgende review. Bewaar dit dossier centraal zodat auditors en het securityteam het snel kunnen raadplegen.

monitoring

Gebruik PowerShell-script 02-admin-account-beveiliging.ps1 (functie Invoke-Monitoring) – monitor admin security: break-glass accounts, admin MFA, CA beleidsregels, rol assignments.

Continue monitoring is de lijm die de nieuwe beheerdersmaatregelen bij elkaar houdt. Zonder structurele opvolging vervagen procedures, worden uitzonderingen permanent en kruipen privileges ongemerkt weer omhoog. Richt daarom een monitoringraamwerk in waarin het SOC, identity team en beveiligingsarchitecten samenwerken. Gebruik Azure AD sign-in logs, Identity Protection, PIM-rapportages en het SIEM om afwijkingen te detecteren. Koppel deze inzichten aan runbooks zodat een analist exact weet welke stappen vereist zijn wanneer bijvoorbeeld een noodaccount onverwacht wordt gebruikt of wanneer een adminaccount plotseling zonder compliant apparaat inlogt. Voeg de belangrijkste indicatoren toe aan het maandelijkse securitydashboard voor CIO en CISO, zodat de bestuurlijke aandacht hoog blijft en middelen beschikbaar komen wanneer aanvullende automatisering of training nodig blijkt. Definieer daarnaast concrete service levels: binnen hoeveel minuten moet een alert worden beoordeeld, wanneer wordt een incident opgeschaald naar CERT-NL en hoe wordt een lessons-learned verwerkt in beleid? Neem monitoring ook op in de interne controlecyclus; laat Internal Audit steekproeven uitvoeren op logging, controleer of scripts nog steeds functioneren na platformupdates en voer jaarlijks een table-topoefening uit waarin het uitvallen van MFA wordt gesimuleerd. Alleen door monitoring als volwaardig proces te behandelen ontstaat er duurzame borging.

1. Stel een alertprofiel in voor break-glass aanmeldingen waarin je onderscheid maakt tussen geplande maandelijkse tests en ongeplande activaties. Wanneer een login buiten het testvenster valt, start je onmiddellijk het incidentresponseplan: identificeer de uitvoerende persoon, controleer of er daadwerkelijk een outage was en reset de wachtwoorden zodra het gebruik is gevalideerd. Registreer tevens welke bedrijfsprocessen geraakt zouden zijn wanneer de noodtoegang nodig bleek, zodat lessons learned direct kunnen worden toegewezen.
2. Monitor dagelijks of honderd procent van de adminaccounts een actieve MFA-registratie hebben. Gebruik Identity Protection of Graph-queries om ontbrekende registraties te detecteren en automatiseer notificaties richting de betreffende beheerder én diens leidinggevende. Neem een escalatiestap op in het HR-proces wanneer iemand na drie herinneringen nog geen registratie heeft voltooid.
3. Rapporteer violations van het voorwaardelijke-toegangsbeleid specifiek voor de beheerderrolset. Elke mislukte aanmelding vanwege non-compliant devices of ontbrekende MFA vormt een signaal dat procedures niet worden gevolgd of dat een aanvaller het account misbruikt. Koppel de rapportage aan Intune zodat meteen zichtbaar is of het apparaat in quarantaine moet worden geplaatst.
4. Configureer een SIEM-regel die triggert wanneer het aantal Globale beheerders boven de afgesproken limiet van vijf komt of wanneer iemand zichzelf die rol toekent buiten PIM om. Koppel het alert aan change tickets zodat ongeautoriseerde wijzigingen direct zichtbaar worden. Voeg ook een automatische reactie toe die de rol tijdelijk intrekt totdat een menselijk review is afgerond.
5. Analyseer adminaanmeldingen op impossible travel, aanmeldingen vanaf anonieme IP-adressen en verhoogde risicoscores. Verrijk deze signalen met device health uit Intune zodat een analist in één oogopslag ziet of er sprake is van een legitieme beheerder of een compromittering. Wanneer twijfel bestaat, forceer dan onmiddellijk een wachtwoordreset en PIM-review.
6. Volg elke wijziging in roltoewijzing met een geautomatiseerd rapport. Wanneer een rol wordt toegevoegd zonder verwijzing naar een change of PIM-activatie, creëer dan een case bij het identiteitsteam om te onderzoeken of er sprake is van privilege escalation. Documenteer de bevindingen in het access-reviewdossier zodat audits eenvoudig kunnen controleren of procesafspraken worden nageleefd.

Compliance en Auditing

Beheerdersaccountbeveiliging vormt een harde compliance-eis omdat vrijwel ieder raamwerk expliciet vraagt om sterke authenticatie, functie- scheiding en gecontroleerd beheer. Binnen CIS Microsoft 365 Foundations worden deze maatregelen concreet benoemd in de controls over administratieve accounts, waarbij multifactor-authenticatie en dedicated accounts verplicht zijn. De Baseline Informatiebeveiliging Overheid (BIO) sluit daarop aan met de maatregelen 09.01.01 en 09.02.01, waarin wordt geëist dat toegang tot informatie en bedrijfsmiddelen wordt geregeld op basis van het need-to-know-principe en dat geprivilegieerde accounts strikt worden beheerd. Door het aantal Globale beheerders terug te brengen tot vijf, het gebruik van PIM vast te leggen en break-glass accounts aantoonbaar te testen, voldoet de organisatie aan de verwachting dat privileged toegang traceerbaar en herstelbaar is. ISO 27001:2022 benadrukt in A.5.15 en A.8.2 dat toegangssystemen continu moeten worden bewaakt en dat privileges periodiek opnieuw moeten worden beoordeeld. De hier beschreven quick start levert concreet bewijs in de vorm van access reviews, trainingsverslagen en monitoringrapportages, waardoor auditors kunnen vaststellen dat de beheersing niet beperkt blijft tot een momentopname. Onder NIS2 artikel 21 moeten essentiële en belangrijke entiteiten aantonen dat zij maatregelen nemen tegen identiteitsmisbruik en supply-chainrisico’s; het scheiden van beheerdersaccounts en het afdwingen van compliant devices voorkomt dat een aanvaller via een externe leverancier alsnog volledige toegang krijgt. Tot slot volgt de aanpak de geest van NIST 800-53 AC-6 (Least Privilege) en IR-5 (Incident Monitoring) doordat alle uitzonderingen worden gelogd, getest en teruggebracht tot een minimum. Documenteer elk besluit, van licentiekeuze tot inclusie van specifieke rollen, in een auditdossier met bewijsstukken zoals screenshots van voorwaardelijke toegang, exports van PIM-activiteiten en logboeken van break-glass tests. Op die manier kan bij controles snel worden aangetoond dat de "Nederlandse Baseline voor Veilige Cloud" niet slechts een beleidstekst is, maar daadwerkelijk operationeel wordt nageleefd. Verlies ook de wet- en regelgeving niet uit het oog. Voor ministeries en vitale aanbieders geldt de Wet beveiliging netwerk- en informatiesystemen (Wbni) en straks de Cyberbeveiligingswet, die nadrukkelijk verwijst naar passende technische en organisatorische maatregelen. Het scheiden van adminaccounts, het voeren van een noodtoegangsprocedure en het beperken van privileges zijn tastbare invullingen die je kunt overleggen bij een onderzoek door Agentschap Telecom of de Inspectie Justitie en Veiligheid. Daarnaast vereist de AVG (artikel 32) dat passende maatregelen worden getroffen om persoonsgegevens te beveiligen; wanneer een beheerder met volledige toegang wordt gecompromitteerd kan de toezichthouder handhavend optreden wegens onvoldoende beveiliging. Door de stappen uit deze quick start in het verwerkingsregister te koppelen aan kritieke applicaties, toon je aan dat privacy by design niet alleen theoretisch is beschreven maar ook praktisch wordt uitgevoerd. Neem ten slotte het audit- en complianceoverzicht op in het jaarplan van de CISO, zodat iedere control een eigenaar, meetmoment en bewijslast kent. Daarmee wordt de beheerdersaccountstrategie een herhaalbaar onderdeel van de bredere governancecyclus. Voor gemeenten en onderwijsinstellingen is bovendien het jaarlijkse ENSIA-proces relevant. De hier beschreven maatregelen leveren direct bewijs voor de vragenlijsten rondom beheer van accounts, logging en continuïteitsmaatregelen. Door de rapportages uit deze quick start (bijvoorbeeld PIM-exporten en break-glass testlogboeken) aan ENSIA-dossiers te koppelen, wordt de auditlast verlaagd en kunnen colleges of raden van toezicht laten zien dat de Nederlandse Baseline voor Veilige Cloud daadwerkelijk wordt nageleefd. Ook accountants die de rechtmatigheidsverantwoording controleren vragen steeds vaker naar aantoonbare beheermaatregelen; een up-to-date adminregister en een getest noodscenario vormen dan concreet bewijs. Zo ontstaat één geïntegreerd complianceverhaal dat aan alle toezichthouders hetzelfde niveau van transparantie biedt.

Remediatie

Gebruik PowerShell-script 02-admin-account-beveiliging.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie draait om snelheid, herhaalbaarheid en documenteerbaarheid. Wanneer monitoring een afwijking detecteert—denk aan een adminaccount zonder MFA, een vergeten licentie op een noodaccount of een onverwachte toename van Globale beheerders—moet het team exact weten welke stappen horen bij het herstel. Begin met het identificeren van de impact: welke functies zijn geraakt, is er sprake van daadwerkelijk misbruik of slechts een configuratiefout, en welke businessprocessen hangen aan het getroffen account? Gebruik vervolgens het PowerShell-script uit dit dossier om rollen opnieuw toe te wijzen, voorwaardelijke toegang te her-evalueren en break-glass accounts te testen. Het script automatiseert onder meer het intrekken van ongeautoriseerde roltoewijzingen, het opnieuw activeren van PIM-controles en het versturen van notificaties naar verantwoordelijken. Combineer de uitkomsten met handmatige controles: laat een tweede beheerder valideren dat de noodtoegang opnieuw werkt, voer een inlogtest uit op een compliant apparaat en sla screenshots op in het incidentregister. Werk altijd volgens het principle of least surprise: communiceer naar betrokken teams welke maatregelen worden genomen, welke tijdelijke beperkingen gelden en wanneer reguliere dienstverlening wordt hervat. Na de technische herstelactie volgt een root-causeanalyse waarin wordt vastgesteld waarom de afwijking kon ontstaan. Misschien ontbreekt er een automatische melding, is er geen vervanger aangewezen of bood een project tijdelijk toegang zonder exitplan. Documenteer de leerpunten, update het runbook en pas waar nodig het script aan zodat dezelfde fout niet terugkeert. Leg tot slot vast welke bewijzen aan auditors kunnen worden overhandigd (bijvoorbeeld aangepaste rolrapporten, bevestigingen van hernieuwde break-glass tests en gelogde change-tickets) zodat remediatie niet alleen operationeel maar ook bestuurlijk aantoonbaar is. Voor scenario’s met daadwerkelijke compromittering hoort het remediatieplan een bredere respons te omvatten. Start een forensisch onderzoek naar de oorsprong van de aanval, verzamel logbestanden volgens het bewaarbeleid en betrek juridische en communicatieafdelingen wanneer meldingsplichten (AVG of NIS2) mogelijk van toepassing zijn. Herstelaccounts krijgen verplicht een wachtwoordreset, alle sessies worden ongeldig verklaard en API-tokens worden opnieuw uitgegeven. Zorg dat lessons learned leiden tot geüpdatete detectieregels; als bijvoorbeeld bleek dat een aanvaller via een legacyprotocol toegang kreeg, blokkeer dat protocol structureel en voeg een regressiontest toe aan het script. Meet de kwaliteit van remediatie door KPI’s vast te leggen, zoals gemiddelde hersteltijd, percentage incidenten dat binnen SLA is opgelost en het aantal herhaalde afwijkingen. Rapporteer deze cijfers elk kwartaal aan het CISO-office zodat management grip houdt op de effectiviteit van de beheerdersstrategie. Voer minimaal één keer per jaar een tabletop-oefening uit waarin het volledige remediatieproces wordt doorlopen: een beheerder wordt bewust als gehackt gemarkeerd, het team activeert het script, communicatie met management wordt geoefend en auditors ontvangen simulatiebewijzen. Deze oefeningen brengen hiaten in bevoegdheden, tooling of personele bezetting aan het licht en geven input voor het verbeterplan. Gebruik de resultaten om budget te onderbouwen voor aanvullende automatisering, bijvoorbeeld het uitbreiden van het script met integraties richting ServiceNow of Azure Automation. Wanneer remediatie zichtbaar onderdeel is van de continue verbetercyclus, blijft de "Nederlandse Baseline voor Veilige Cloud" niet alleen een set maatregelen op papier maar een levend proces dat meebeweegt met dreigingen. Leg alle evaluaties vast in het ISMS.

Compliance & Frameworks

• CIS M365: Control 1.2.1 (L1) - beheerdersaccounts separation en bescherming
• BIO: 09.01.01, 09.02.01 - Toegangsbeleid en geprivilegieerd account management
• ISO 27001:2022: A.5.15, A.8.2 - Toegangscontrole en authenticatie en privileged toegangsrechten
• NIS2: Artikel - geprivilegieerd account security

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

DAG 1-2: Stel in break-glass accounts (2x, physical safe opslag), Maak aan admin CA beleid (MFA + compliant device), Start beheerdersaccount separation (1-2 weken rollout), Restrict Globale beheerder rechtens (max 5). Implementatie: 8 uur over 2 dagen. KRITIEKE FOUNDATION - vereist voor veilige tenant.

• Implementatietijd: 16 uur
• FTE required: 0.2 FTE