Azure: Break-Glass Noodtoegangsaccounts Configureren

Zonder toegewijde break-glass accounts kan een organisatie permanent worden buitengesloten van de eigen Azure-tenant bij verschillende kritieke scenario's. Een verkeerd geconfigureerd Conditional Access-beleid dat per ongeluk alle beheerders blokkeert door bijvoorbeeld een te strikte locatierestrictie of apparaatcompliance-eis kan ervoor zorgen dat geen enkele beheerder meer kan inloggen om het beleid te corrigeren, wat een volledige beheerdersuitsluiting veroorzaakt. Azure Multi-Factor Authenticatie service-uitval waarbij Microsoft's MFA-infrastructuur tijdelijk niet beschikbaar is, blokkeert alle beheerders die meervoudige authenticatie vereisen, wat kritieke incidentrespons onmogelijk maakt. Gefedereerde identiteitsproviderstoringen in hybride omgevingen waarbij de on-premises Active Directory Federation Services of andere federatieservice uitvalt, kunnen alle gefedereerde beheerdersaccounts blokkeren. Onbedoelde verwijdering van de laatste Globale beheerder door een verkeerd geconfigureerd script of automatiseringfout kan volledige tenantuitsluiting veroorzaken zonder herstelmogelijkheid. Identity Protection fout-positieven kunnen legitieme beheerders blokkeren bij hoge risicodetecties. In al deze scenario's duurt herstel via Microsoft Support minimaal 24-72 uur en vereist uitgebreide identiteitsverificatieprocedures, wat kan resulteren in bedrijfsuitval met kosten van €100.000-500.000+ voor grote organisaties waarbij kritieke Azure-resources niet kunnen worden beheerd tijdens incidenten. Break-glass accounts elimineren deze risico's door directe noodtoegang te bieden waarbij permanente Globale beheerderrechten bestaan zonder afhankelijkheid van Conditional Access-beleidsregels die verkeerd kunnen worden geconfigureerd, MFA-services die kunnen uitvallen, of gefedereerde identiteitsproviders die kunnen falen. Deze accounts fungeren als laatste redmiddel, vandaar de term 'break-glass' die verwijst naar het breken van een glazen noodkast, en moeten alleen worden gebruikt in absolute noodsituaties. Voor naleving van ISO 27001-controle A.17.1.1 voor bedrijfscontinuïteitsplanning, BIO-richtlijn 17.01 voor noodtoegangsprocedures, en NIS2-artikel 21 voor bedrijfscontinuïteitsvereisten is het hebben van gedocumenteerde noodtoegangsprocedures inclusief break-glass accounts vaak verplicht.

Implementatie

Deze maatregel implementeert minimaal twee break-glass accounts voor redundantie, waarbij elk account zeer specifieke configuratievereisten heeft. De accounts moeten uitsluitend in de cloud bestaan zonder synchronisatie vanaf on-premises Active Directory om afhankelijkheid van on-premises infrastructuur te elimineren. De wachtwoorden moeten willekeurig worden gegenereerd met minimaal 64 tekens en maximale entropie voor bescherming tegen brute-force-aanvallen. Elke account moet permanente toewijzing van de rol Globale beheerder hebben zonder tijdslimieten omdat noodtoegang direct beschikbaar moet zijn. De accounts moeten expliciet worden uitgesloten van alle Conditional Access-beleidsregels via een toegewijde beveiligingsgroep met de naam 'Break-Glass-Exclusion' om te voorkomen dat beleidsregels deze accounts blokkeren. De accounts hebben geen vereiste voor meervoudige authenticatie omdat MFA-uitval een van de uitsluitingsscenario's is, wat wordt gecompenseerd door extreme wachtwoordsterkte en intensieve monitoring. Referenties moeten worden opgeslagen in een fysieke kluis met dubbele controle waarbij minimaal twee directieleden samen de kluis moeten openen volgens gedocumenteerde procedures. Kritiek is dat deze accounts continu worden gemonitord waarbij elke aanmelding direct beveiligingswaarschuwingen met hoge prioriteit triggert naar directieleden, beveiligingsteam en Security Operations Center, omdat gebruik buiten echte noodsituaties wijst op gestolen referenties of ongemachtigde toegang. De accounts moeten normaal gesproken exact nul aanmeldingen hebben per jaar. Elke aanmelding vereist formeel incidentonderzoek met oorzaakanalyse. Kwartaalonderzoek moet worden uitgevoerd waarbij gecontroleerde testaanmeldingen worden gemaakt om functionaliteit te verifiëren, gevolgd door directe wachtwoordreset na de test om blootstelling te minimaliseren. Naamgevingsconventie moet duidelijk zijn zoals breakglass-01@tenant.onmicrosoft.com en breakglass-02@tenant.onmicrosoft.com. De implementatie kost vier uur technisch werk voor accountconfiguratie, monitoringsconfiguratie en kluisaanschaf plus vier uur organisatorisch werk voor documentatie van noodprocedures en directietraining. Deze accounts zijn absoluut noodzakelijk voor alle Azure-tenants en voldoen aan CIS Azure Foundations-controle 1.3 Niveau 1.

Vereisten

Voor de implementatie van break-glass accounts zijn specifieke technische en organisatorische vereisten noodzakelijk. Deze vereisten vormen de basis voor een veilige en effectieve noodtoegangsoplossing die voldoet aan de hoogste beveiligingsstandaarden en compliance-vereisten voor Nederlandse overheidsorganisaties.

De primaire technische vereiste is een actieve Entra ID-tenant (voorheen Azure Active Directory). Entra ID vormt het fundament van de identiteits- en toegangsbeheerinfrastructuur voor Microsoft-cloudservices en biedt de benodigde functionaliteit voor het creëren en beheren van break-glass accounts. De tenant moet beschikken over een geldige licentie die het gebruik van beheerdersrollen ondersteunt, waarbij de rol van Globale beheerder beschikbaar moet zijn voor toewijzing aan de break-glass accounts. Organisaties die gebruikmaken van hybride identiteitsoplossingen waarbij on-premises Active Directory wordt gesynchroniseerd met Entra ID, moeten ervoor zorgen dat de break-glass accounts expliciet worden geconfigureerd als cloud-only accounts zonder synchronisatie. Dit voorkomt afhankelijkheid van on-premises infrastructuur die tijdens een noodsituatie mogelijk niet beschikbaar is.

Naast de technische vereisten voor Entra ID is een fysieke kluis essentieel voor de veilige opslag van referenties. Deze kluis moet voldoen aan beveiligingsstandaarden die passen bij de gevoeligheid van de opgeslagen informatie. De kluis moet bestand zijn tegen brand, water en fysieke inbraak, waarbij minimaal een brandwerendheid van 60 minuten wordt aanbevolen. De locatie van de kluis moet strategisch worden gekozen: toegankelijk genoeg voor geautoriseerd personeel tijdens noodsituaties, maar voldoende beveiligd tegen onbevoegde toegang. De kluis moet zich bij voorkeur bevinden in een beveiligde ruimte met toegangscontrole, zoals een serverruimte of een speciaal daarvoor ingerichte beveiligingskamer.

De organisatorische vereisten omvatten de implementatie van dubbele controleprocedures voor toegang tot de kluis. Dit betekent dat minimaal twee geautoriseerde personen samen aanwezig moeten zijn om de kluis te openen, waarbij beide personen hun identiteit moeten verifiëren en de reden voor toegang moeten documenteren. Deze personen moeten op directieniveau of senior managementniveau functioneren en moeten volledig op de hoogte zijn van de procedures en risico's. De lijst van geautoriseerde personen moet regelmatig worden gecontroleerd en bijgewerkt, waarbij wijzigingen worden gedocumenteerd en goedgekeurd door de Chief Information Security Officer (CISO) of een vergelijkbare functie.

Aanvullende vereisten betreffen de beschikbaarheid van monitoring- en alertingsystemen. De organisatie moet beschikken over een Security Operations Center (SOC) of een vergelijkbare monitoringfaciliteit die 24/7 beveiligingsgebeurtenissen kan monitoren en direct kan reageren op waarschuwingen. Microsoft Sentinel of een vergelijkbaar Security Information and Event Management (SIEM)-systeem is aanbevolen voor geavanceerde monitoring en correlatie van beveiligingsgebeurtenissen. Daarnaast moet er een geformaliseerd incidentresponsproces bestaan dat specifiek is afgestemd op het gebruik van break-glass accounts, waarbij duidelijk is gedefinieerd wie moet worden geïnformeerd, welke acties moeten worden ondernomen en hoe het incident moet worden gedocumenteerd.

Voor compliance-doeleinden moet de organisatie beschikken over documentatie- en auditmogelijkheden. Dit omvat de mogelijkheid om alle activiteiten met betrekking tot break-glass accounts te loggen, te archiveren en te rapporteren aan auditors. De documentatie moet procedures bevatten voor het gebruik van de accounts, contactgegevens van geautoriseerde personen, en een overzicht van alle gerelateerde beveiligingsmaatregelen. Deze documentatie moet regelmatig worden gecontroleerd en bijgewerkt, waarbij wijzigingen worden goedgekeurd door de relevante beveiligings- en compliancefuncties binnen de organisatie.

Monitoring

Gebruik PowerShell-script break-glass-accounts-azure.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring van break-glass accounts vormt een kritieke component van de beveiligingsstrategie, omdat elk gebruik van deze accounts een potentieel beveiligingsincident of een legitieme noodsituatie kan vertegenwoordigen. De monitoring moet zodanig worden geconfigureerd dat elke aanmeldingspoging, succesvol of mislukt, onmiddellijk wordt gedetecteerd en geëscaleerd naar de hoogste beveiligingsniveaus binnen de organisatie.

De primaire monitoringbron voor break-glass accounts zijn de aanmeldingslogboeken (sign-in logs) in Entra ID. Deze logboeken bevatten gedetailleerde informatie over elke aanmeldingspoging, inclusief tijdstip, locatie, apparaat, IP-adres, en het resultaat van de authenticatie. Organisaties moeten gebruikmaken van Microsoft Sentinel of een vergelijkbaar SIEM-systeem om deze logboeken continu te monitoren en automatische waarschuwingen te genereren bij detectie van activiteit op break-glass accounts. De waarschuwingen moeten worden geconfigureerd met de hoogste prioriteit en moeten direct worden doorgestuurd naar meerdere kanalen: e-mail naar directieleden en het beveiligingsteam, SMS-berichten naar on-call beveiligingspersoneel, en automatische tickets in het incidentmanagementsysteem.

Naast real-time monitoring van aanmeldingslogboeken moeten organisaties regelmatige controle- en rapportageprocessen implementeren. Wekelijkse rapporten moeten worden gegenereerd die alle activiteit op break-glass accounts documenteren, zelfs als er geen activiteit is geweest. Deze rapporten moeten worden gereviewd door de CISO of een vergelijkbare functie en moeten worden gearchiveerd voor auditdoeleinden. Maandelijkse diepgaande analyses moeten worden uitgevoerd waarbij alle aanmeldingsgebeurtenissen worden geëvalueerd op patronen, anomalieën of indicatoren van compromittering. Deze analyses moeten worden gedocumenteerd en besproken tijdens beveiligingsbeoordelingen op directieniveau.

De monitoringconfiguratie moet ook rekening houden met de context van elke aanmelding. Geografische locatie, tijdstip, en apparaatkenmerken moeten worden geëvalueerd om te bepalen of de aanmelding legitiem is of verdacht. Aanmeldingen vanaf onbekende locaties, buiten normale kantooruren, of vanaf niet-geautoriseerde apparaten moeten extra aandacht krijgen en kunnen aanvullende verificatiestappen vereisen. De monitoringoplossing moet in staat zijn om deze contextuele informatie te correleren en intelligente waarschuwingen te genereren die rekening houden met meerdere factoren.

Voor organisaties die gebruikmaken van Microsoft Sentinel kunnen specifieke detectieregels worden geconfigureerd die zijn afgestemd op break-glass accounts. Deze regels moeten worden geconfigureerd om niet alleen aanmeldingen te detecteren, maar ook om deze te correleren met andere beveiligingsgebeurtenissen zoals wijzigingen in Conditional Access-beleidsregels, wijzigingen in beheerdersrollen, of andere verdachte activiteiten. De detectieregels moeten worden getest en gevalideerd om ervoor te zorgen dat ze effectief zijn en geen valse positieven genereren die de beveiligingsteams overbelasten.

Het incidentresponsproces voor break-glass account activiteit moet duidelijk zijn gedefinieerd en regelmatig worden getest. Wanneer een waarschuwing wordt gegenereerd, moet het beveiligingsteam onmiddellijk kunnen bepalen of de activiteit legitiem is (bijvoorbeeld tijdens een geplande test of een echte noodsituatie) of verdacht. Voor legitieme activiteit moet worden geverifieerd dat de juiste procedures zijn gevolgd, dat de activiteit is goedgekeurd, en dat alle stappen zijn gedocumenteerd. Voor verdachte activiteit moet onmiddellijk een incident worden geopend, moeten de accounts worden geblokkeerd, en moeten forensische onderzoeken worden gestart om de omvang en impact van het potentiële beveiligingsincident te bepalen.

Implementatie

Gebruik PowerShell-script break-glass-accounts-azure.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van break-glass accounts vereist een gestructureerde aanpak waarbij technische configuratie, beveiligingsmaatregelen en organisatorische procedures zorgvuldig worden afgestemd. Het proces begint met het creëren van minimaal twee cloud-only accounts in Entra ID met duidelijke naamgevingsconventies zoals breakglass-01@tenant.onmicrosoft.com en breakglass-02@tenant.onmicrosoft.com. Deze accounts moeten expliciet worden geconfigureerd als cloud-only accounts zonder synchronisatie vanaf on-premises Active Directory, zelfs als de organisatie gebruikmaakt van hybride identiteitsoplossingen. Dit elimineert afhankelijkheid van on-premises infrastructuur die tijdens een noodsituatie mogelijk niet beschikbaar is.

Na het aanmaken van de accounts moet aan elk account de rol van Globale beheerder worden toegewezen. Deze roltoewijzing moet permanent zijn zonder tijdslimieten, omdat noodtoegang direct beschikbaar moet zijn zonder aanvullende goedkeuringsstappen. De roltoewijzing moet worden gedocumenteerd en geregistreerd in het beveiligingsbeheerregister. Organisaties moeten ervoor zorgen dat de roltoewijzing wordt uitgevoerd door een geautoriseerde beheerder met de juiste rechten, en dat de actie wordt gelogd voor auditdoeleinden.

Het genereren van wachtwoorden voor break-glass accounts vereist speciale aandacht voor beveiliging. De wachtwoorden moeten minimaal 64 tekens lang zijn en moeten worden gegenereerd met behulp van een cryptografisch veilige willekeurige generator die maximale entropie garandeert. Het gebruik van menselijk leesbare woorden, patronen of voorspelbare sequenties moet strikt worden vermeden. De wachtwoordgeneratie moet worden uitgevoerd op een beveiligd systeem dat niet is verbonden met het internet, en de wachtwoorden moeten direct na generatie worden opgeslagen in een verzegelde envelop zonder dat ze ooit in platte tekst worden weergegeven op schermen of in logbestanden.

De referenties moeten worden opgeslagen in een fysieke kluis die voldoet aan beveiligingsstandaarden. Elke break-glass account moet zijn eigen verzegelde envelop hebben die duidelijk is gelabeld met de accountnaam en de datum waarop de referenties zijn gegenereerd. De envelop moet worden verzegeld met een beveiligingszegel dat wijzigingen detecteert, en de verzegeling moet worden gecontroleerd bij elke toegang tot de kluis. De kluis moet worden beveiligd met dubbele controle, waarbij minimaal twee geautoriseerde personen samen aanwezig moeten zijn om de kluis te openen. Alle toegang tot de kluis moet worden gedocumenteerd in een logboek dat de datum, tijd, personen en reden voor toegang vastlegt.

Een kritieke stap in de implementatie is het uitsluiten van break-glass accounts van alle Conditional Access-beleidsregels. Dit moet worden bereikt door de accounts toe te voegen aan een toegewijde beveiligingsgroep met een duidelijke naam zoals 'Break-Glass-Exclusion', en deze groep vervolgens expliciet uit te sluiten van alle Conditional Access-beleidsregels in de tenant. Organisaties moeten een proces implementeren waarbij bij het creëren van nieuwe Conditional Access-beleidsregels automatisch wordt gecontroleerd of break-glass accounts zijn uitgesloten. Daarnaast moeten break-glass accounts worden uitgesloten van alle MFA-registratievereisten, omdat MFA-uitval een van de scenario's is waarbij break-glass accounts nodig zijn.

De configuratie van alerting op aanmeldingspogingen moet worden geïmplementeerd voordat de accounts operationeel worden. De alerting moet worden geconfigureerd om onmiddellijk waarschuwingen te genereren bij elke aanmeldingspoging, succesvol of mislukt, op een break-glass account. De waarschuwingen moeten worden doorgestuurd naar meerdere kanalen inclusief e-mail naar directieleden en het beveiligingsteam, SMS-berichten naar on-call personeel, en automatische tickets in het incidentmanagementsysteem. De waarschuwingen moeten de hoogste prioriteit hebben en moeten voldoende context bevatten om snelle beoordeling mogelijk te maken.

Kwartaalonderzoek moet worden uitgevoerd om te verifiëren dat de break-glass accounts functioneel zijn en dat alle configuraties correct zijn geïmplementeerd. Tijdens deze tests moeten gecontroleerde testaanmeldingen worden uitgevoerd waarbij wordt geverifieerd dat de accounts kunnen worden gebruikt om in te loggen, dat de roltoewijzingen correct zijn, en dat de monitoring en alerting correct functioneren. Na elke test moet onmiddellijk een wachtwoordreset worden uitgevoerd om de blootstelling van de referenties te minimaliseren. De testresultaten moeten worden gedocumenteerd en gereviewd door de CISO of een vergelijkbare functie.

De volledige implementatie moet worden gedocumenteerd in een beveiligingsbeheerregister dat alle configuratiedetails, procedures, en contactgegevens bevat. Deze documentatie moet regelmatig worden gecontroleerd en bijgewerkt, en moet beschikbaar zijn voor auditors en beveiligingspersoneel. De implementatie moet worden goedgekeurd door de CISO of een vergelijkbare functie voordat de accounts operationeel worden, en alle betrokkenen moeten worden getraind in de procedures en risico's.

Compliance en Audit

Break-glass accounts spelen een cruciale rol in de naleving van verschillende beveiligings- en compliance-standaarden die relevant zijn voor Nederlandse overheidsorganisaties. De implementatie en het beheer van deze accounts moeten voldoen aan specifieke controles en vereisten die zijn gedefinieerd in internationale en nationale standaarden.

De CIS Azure Foundations Benchmark controle 1.3 vereist expliciet dat organisaties noodtoegangsaccounts implementeren die kunnen worden gebruikt wanneer normale beheerdersaccounts niet beschikbaar zijn. Deze controle is geclassificeerd als Niveau 1, wat betekent dat het een fundamentele beveiligingsmaatregel is die door alle organisaties moet worden geïmplementeerd. De controle specificeert dat noodtoegangsaccounts moeten worden geconfigureerd met permanente beheerdersrechten, moeten worden uitgesloten van Conditional Access-beleidsregels, en moeten worden gemonitord op gebruik. Organisaties die voldoen aan deze controle demonstreren dat zij beschikken over een mechanisme om kritieke beheerdersuitsluitingen te voorkomen en bedrijfscontinuïteit te waarborgen.

De BIO-richtlijn 17.01 (bedrijfscontinuïteit) vereist dat organisaties procedures implementeren voor het waarborgen van bedrijfscontinuïteit tijdens noodsituaties. Break-glass accounts vormen een essentieel onderdeel van deze procedures, omdat zij garanderen dat kritieke IT-systemen en -services kunnen worden beheerd en hersteld, zelfs wanneer normale toegangsmechanismen zijn uitgevallen. De richtlijn vereist dat organisaties gedocumenteerde procedures hebben voor het gebruik van noodtoegangsaccounts, dat deze procedures regelmatig worden getest, en dat alle activiteiten worden gelogd en geaudit. Nederlandse overheidsorganisaties die voldoen aan de BIO-richtlijn moeten kunnen aantonen dat zij beschikken over effectieve break-glass account procedures die zijn geïntegreerd in hun bredere bedrijfscontinuïteitsplanning.

ISO 27001 controle A.17.1.1 (Planning van informatiebeveiligingscontinuïteit) vereist dat organisaties processen en procedures implementeren voor het waarborgen van informatiebeveiligingscontinuïteit. Break-glass accounts ondersteunen deze controle door te garanderen dat beveiligingsbeheer kan worden voortgezet, zelfs tijdens noodsituaties waarbij normale toegangsmechanismen zijn gecompromitteerd of uitgevallen. De controle vereist dat organisaties risicoanalyses uitvoeren, bedrijfscontinuïteitsplannen ontwikkelen, en regelmatig testen en bijwerken. Break-glass accounts moeten worden opgenomen in deze plannen, waarbij duidelijk wordt gedefinieerd wanneer en hoe de accounts mogen worden gebruikt, wie geautoriseerd is om de accounts te gebruiken, en welke procedures moeten worden gevolgd.

Voor auditdoeleinden moeten organisaties uitgebreide documentatie bijhouden over alle aspecten van break-glass accounts. Dit omvat een lijst van alle break-glass accounts, de configuratie van Conditional Access-uitsluitingen, alle aanmeldingsgebeurtenissen en waarschuwingen, en de resultaten van kwartaalonderzoeken. Deze documentatie moet minimaal 7 jaar worden bewaard en moet beschikbaar zijn voor auditors tijdens compliance-audits. De documentatie moet regelmatig worden gecontroleerd en bijgewerkt om ervoor te zorgen dat deze accuraat en compleet is.

Tijdens compliance-audits zullen auditors specifiek controleren of break-glass accounts correct zijn geconfigureerd, of zij daadwerkelijk zijn uitgesloten van Conditional Access-beleidsregels, en of de monitoring en alerting correct functioneren. Auditors zullen ook de documentatie en procedures evalueren om te bepalen of deze voldoen aan de vereisten van de relevante standaarden. Organisaties moeten kunnen aantonen dat break-glass accounts regelmatig worden getest, dat alle activiteit wordt gemonitord en gelogd, en dat er duidelijke procedures bestaan voor het gebruik van de accounts tijdens noodsituaties.

Remediatie

Gebruik PowerShell-script break-glass-accounts-azure.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie van problemen met break-glass accounts vereist een gestructureerde aanpak waarbij technische correcties, beveiligingsmaatregelen en organisatorische procedures worden gecombineerd. Wanneer wordt vastgesteld dat break-glass accounts niet correct zijn geconfigureerd, niet voldoen aan beveiligingsvereisten, of niet functioneren zoals bedoeld, moeten onmiddellijk corrigerende maatregelen worden genomen om de beveiligingspostuur te herstellen en compliance te waarborgen.

Een veelvoorkomend probleem is dat break-glass accounts niet correct zijn uitgesloten van Conditional Access-beleidsregels, waardoor de accounts mogelijk worden geblokkeerd tijdens een noodsituatie. Remediatie vereist een grondige audit van alle Conditional Access-beleidsregels in de tenant om te identificeren welke beleidsregels van toepassing zijn op break-glass accounts. Vervolgens moeten de accounts expliciet worden toegevoegd aan een toegewijde beveiligingsgroep en moeten alle Conditional Access-beleidsregels worden bijgewerkt om deze groep uit te sluiten. Dit proces moet worden gedocumenteerd en gevalideerd door het beveiligingsteam om ervoor te zorgen dat alle beleidsregels correct zijn geconfigureerd.

Wanneer break-glass accounts niet beschikken over de juiste roltoewijzingen, moet onmiddellijk worden gecontroleerd of de rol van Globale beheerder correct is toegewezen. Als de roltoewijzing ontbreekt of onjuist is geconfigureerd, moet deze worden gecorrigeerd door een geautoriseerde beheerder. De roltoewijzing moet permanent zijn zonder tijdslimieten, en de configuratie moet worden gedocumenteerd en gevalideerd. Organisaties moeten ook controleren of er geen tijdelijke of voorwaardelijke roltoewijzingen zijn geconfigureerd die de beschikbaarheid van de accounts kunnen beïnvloeden.

Als wordt vastgesteld dat de wachtwoorden van break-glass accounts niet voldoen aan beveiligingsvereisten, moeten nieuwe wachtwoorden worden gegenereerd die voldoen aan de specificaties: minimaal 64 tekens, cryptografisch veilig gegenereerd met maximale entropie. De oude wachtwoorden moeten worden geïnvalideerd en de nieuwe referenties moeten worden opgeslagen in de fysieke kluis volgens de gedocumenteerde procedures. Alle personen die toegang hebben gehad tot de oude referenties moeten worden geïnformeerd over de wijziging, en de wijziging moet worden gelogd voor auditdoeleinden.

Wanneer monitoring en alerting niet correct functioneren, moet onmiddellijk worden gecontroleerd of de configuratie van de monitoringoplossing correct is. Dit omvat verificatie van de connectiviteit tussen Entra ID en het SIEM-systeem, controle van de detectieregels, en validatie van de alertingkanalen. Als waarschuwingen niet worden gegenereerd of niet correct worden doorgestuurd, moeten de configuraties worden gecorrigeerd en getest om ervoor te zorgen dat ze correct functioneren. Testwaarschuwingen moeten worden gegenereerd om te verifiëren dat alle kanalen correct werken en dat de juiste personen worden geïnformeerd.

In het geval van verdachte activiteit op break-glass accounts moet onmiddellijk een incident worden geopend en moeten forensische onderzoeken worden gestart. De accounts moeten worden geblokkeerd om verdere ongeautoriseerde toegang te voorkomen, en alle aanmeldingsgebeurtenissen moeten worden geanalyseerd om de omvang en impact van het incident te bepalen. Nieuwe referenties moeten worden gegenereerd en de oude referenties moeten worden geïnvalideerd. Het beveiligingsteam moet een grondige analyse uitvoeren om te bepalen hoe de accounts mogelijk zijn gecompromitteerd en welke aanvullende beveiligingsmaatregelen nodig zijn om herhaling te voorkomen.

Na remediatie moeten alle wijzigingen worden gedocumenteerd en moeten de configuraties worden gevalideerd door het beveiligingsteam. Kwartaalonderzoek moet worden uitgevoerd om te verifiëren dat alle corrigerende maatregelen effectief zijn en dat de accounts correct functioneren. De remediatie-activiteiten moeten worden gereviewd door de CISO of een vergelijkbare functie, en lessen moeten worden getrokken om toekomstige problemen te voorkomen. Alle documentatie moet worden bijgewerkt om de huidige configuratie en procedures accuraat weer te geven.

Compliance & Frameworks

• CIS M365: Control 1.3 (L1) - Emergency access accounts
• BIO: 17.01 - bedrijfscontinuïteit planning
• ISO 27001:2022: A.17.1.1 - Continuity planning

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

Break-Glass Accounts (minimaal 2): Uitsluitend cloud-accounts (NIET gesynchroniseerd), rol Globale beheerder, uitgesloten van ALLE Conditional Access en meervoudige authenticatie, willekeurige wachtwoorden van minimaal 64 tekens in fysieke kluis, waarschuwing bij gebruik (elke aanmelding triggert waarschuwing). Activatie: Maak 2 accounts aan, sluit uit van Conditional Access, documenteer in kluis. Gratis. Verplicht CIS 1.3. Implementatie: 4-8 uur. Noodtoegang voor beheerders als laatste redmiddel.

• Implementatietijd: 5 uur
• FTE required: 0.05 FTE