Wat is een Entra-noodtoegangsaccount?

Het is een uitzonderlijk beheerdersaccount dat ontworpen is om bruikbaar te blijven wanneer de normale toegangswegen niet meer werken.

Het noodaccount, soms « break glass » genoemd, is noch een account voor dagelijks support noch een snelkoppeling om controles te omzeilen. Het dient uitsluitend om opnieuw controle over de tenant te krijgen wanneer een identiteitsstoring, een verkeerd geconfigureerd beleid, het verlies van MFA-middelen of een governancefout alle reguliere beheerders blokkeert. De rechten zijn hoog omdat het incident moet kunnen worden gecorrigeerd; het gebruik moet daarom zeldzaam, zichtbaar en onmiddellijk opnieuw beoordeeld worden.

Microsoft raadt twee of meer accounts aan die cloud-only zijn en gebaseerd zijn op het domein .onmicrosoft.com, zonder afhankelijkheid van lokale federatie. De Microsoft-documentatie, bijgewerkt op 5 juni 2026, verduidelijkt ook dat deze accounts uitsluitend voor noodgevallen mogen worden gebruikt, gemonitord en regelmatig gevalideerd. Redundantie is essentieel: één verloren sleutel, een uitgeschakeld account of een configuratiefout mag de laatste herstelmogelijkheid niet onbruikbaar maken.

Voor een Belgische organisatie gaat dit onderwerp verder dan alleen de techniek. Er moet worden bepaald wie de activering van de oplossing mag goedkeuren, waar de authenticatiemiddelen worden bewaard, hoe een multi-site team toegang krijgt wanneer een gebouw niet beschikbaar is en welke bewijzen worden bijgehouden. De beveiliging van identiteiten met Microsoft Entra moet deze continuïteit vanaf het ontwerp integreren, in plaats van ze pas na een vergrendeling toe te voegen.

In welke scenario’s moet dit account werken?

Het juiste model vertrekt vanuit concrete storingsscenario’s en werkelijk onafhankelijke afhankelijkheden.

Eerste scenario: de federatie of de lokale directory reageert niet meer. Een account dat vanuit Active Directory wordt gesynchroniseerd, kan dan onbruikbaar zijn precies op het moment dat de cloudconfiguratie moet worden aangepast. Een cloud-only account vermindert deze afhankelijkheid. Tweede scenario: de gebruikelijke MFA-methode wordt onbeschikbaar, bijvoorbeeld door een mobiele storing, een externe dienst of verloren smartphones. Het noodmechanisme mag niet dezelfde storingsmodus delen.

Derde scenario: een beleid voor voorwaardelijke toegang blokkeert per ongeluk alle beheerders. Een regel die een compliant apparaat, een benoemde locatie of een verkeerd geïmplementeerde authenticatiesterkte vereist, kan een collectieve vergrendeling veroorzaken. Vierde scenario: alle houders van geprivilegieerde rollen moeten PIM activeren, maar er is geen actieve goedkeurder meer beschikbaar. Vijfde scenario: een cyberincident vereist dat sessies worden ingetrokken of een configuratie wordt gecorrigeerd terwijl de normale accounts mogelijk gecompromitteerd zijn.

Zet elk scenario om in een acceptatietest: vanaf welk toestel aanmelden, met welke sleutel, via welke internetverbinding en om welke minimale actie uit te voeren? Vermijd vage scenario’s zoals « storing van Microsoft ». Het doel is om gemeenschappelijke afhankelijkheden te identificeren: dezelfde telefoon, dezelfde digitale kluis, dezelfde identiteitsprovider, hetzelfde netwerk, dezelfde persoon of hetzelfde gebouw. Een noodarchitectuur is alleen veerkrachtig als ze minstens één plausibele onderbreking van elk van deze elementen kan opvangen.

Hoe ontwerp je een betrouwbare noodarchitectuur?

Maak twee afzonderlijke cloud-only accounts aan, scheid hun authenticatiemiddelen en documenteer een minimaal gebruikspad.

Geef elk account een niet-persoonlijke en niet voor de hand liggende identiteit, bewaar de object-ID in het beveiligingsregister en plaats het account in een specifieke groep voor gecontroleerde uitsluitingen. Microsoft vereist dat de rol Globale beheerder permanent actief is voor deze accounts, in tegenstelling tot gewone gebruikersaccounts waarvoor PIM en least privilege de voorkeur genieten. Deze uitzondering moet beperkt blijven tot deze noodidentiteiten.

Gebruik een phishingbestendige methode. Microsoft raadt FIDO2-passkeys aan en aanvaardt certificaatauthenticatie wanneer er een voldoende onafhankelijke PKI bestaat. Een hardwarematige sleutel is geen wondermiddel: elk exemplaar moet worden geregistreerd, gelabeld, verzegeld, opgeslagen en getest. Voorzie een primaire sleutel en een reserve-exemplaar zonder het account te koppelen aan de privetelefoon van een medewerker. Controleer ook of er geen vervaldatum of automatische opschoning wegens inactiviteit is ingesteld.

Reserveer een beveiligd beheertoestel of een gelijkwaardige omgeving. De browser, extensies, aangemelde accounts en het netwerk moeten worden beheerd. Het toestel mag geen gedeelde computer worden die dagelijks wordt gebruikt. Bepaal de minimaal toegestane actie: een beleid herstellen, een benoemde beheerder activeren, een gecompromitteerd account intrekken of een goedkeuringsketen herstellen. Daarna verlaat de gebruiker het noodaccount en gaat hij verder met een traceerbare persoonlijke identiteit.

Normaal account, PIM of noodaccount: wat is het verschil?

Deze drie mechanismen vullen elkaar aan: het gebruikersaccount beheert de dagelijkse werking, PIM beperkt de duur van de rechten en het noodaccount behandelt een globale vergrendeling.

Het verwarren van deze rollen leidt tot twee tegengestelde excessen. Als het team het noodaccount gebruikt om tijd te winnen, gaat de individuele toewijzing verloren, wordt een permanent privilege genormaliseerd en worden governanceproblemen verborgen. Als het team daarentegen dezelfde afhankelijkheden vereist als voor een normaal account, kan de oplossing samen met de rest van de tenant worden geblokkeerd. De tabel onderscheidt het gebruik, de controle en de beperking van elke optie.

Omdat de mens vaak de zwakste schakel is, sensibiliseren en trainen we uw teams in goede cyberbeveiligingspraktijken om risico's door menselijke fouten te verminderen. goede praktijken voor Microsoft Entra RBAC, bijgewerkt op 1 juni 2026, bevelen least privilege, PIM voor just-in-time-toegang en twee permanente cloud-only noodaccounts met de rol Globale beheerder aan. De nuance is belangrijk: permanente rechten vormen een uitzondering voor continuïteit en zijn geen model dat voor alle beheerders moet worden toegepast.

Hoe behandel je uitsluitingen voor voorwaardelijke toegang?

Sluit noodaccounts uit van beleidsregels die de aanmelding kunnen blokkeren en compenseer deze uitzondering vervolgens met sterke authenticatie, volledige monitoring en tests.

Een uitsluiting is geen algemene vrijstelling. Ze dient te voorkomen dat een vereiste voor een compliant apparaat, locatie, onbeschikbare methode of externe dienst de noodtoegang verhindert. Gebruik een specifieke groep en controleer expliciet het lidmaatschap ervan. Beleidsregels in de modus Alleen rapporteren hebben deze uitsluiting niet nodig, omdat ze de aanmelding niet blokkeren. Documenteer elk beleid waarin de groep wordt uitgesloten en de reden voor deze beslissing.

De authenticatie van het account moet phishingbestendig blijven, zonder afhankelijk te zijn van een blokkerend beleid. De authenticatiesterktes van Microsoft Entra leggen uit hoe verschillende combinaties van methoden kunnen worden onderscheiden. In de noodoplossing komt de bescherming vooral van het gecontroleerde bezit van de sleutel of het certificaat, het beveiligde toestel, de onmiddellijke waarschuwing en de procedure waarbij twee personen betrokken zijn.

Gebruik vóór elke grote wijziging aan voorwaardelijke toegang de modus Alleen rapporteren, evaluatietools en een gefaseerde implementatie. Controleer specifiek de noodaccounts voordat het beleid in productie wordt geactiveerd. Voer na elke wijziging een gecontroleerde aanmelding uit met minstens één account en bevestig vervolgens dat het andere account een onafhankelijk toegangspad behoudt. Een niet opnieuw geteste uitsluiting is een veronderstelling, geen garantie.

Waar bewaar je sleutels, geheimen en instructies?

Scheid de authenticatiemiddelen, instructies en bewaarplaatsen, zodat één persoon of één storing niet alles onder controle heeft.

FIDO2-sleutels en eventuele herstelcodes moeten op veilige, afzonderlijke en voor bevoegde personen toegankelijke fysieke locaties worden bewaard. Microsoft verwijst naar beveiligde en brandwerende kluizen op verschillende locaties. Voor een multi-site organisatie kan dit betekenen dat een primair middel op het hoofdkantoor en een tweede op een andere gecontroleerde locatie wordt bewaard. De inventaris moet het serienummer, het gekoppelde account, de verzegeling, de locatie, de houders en de verificatiedatum vermelden, zonder een geheim in een gewoon ticket bloot te stellen.

De procedure moet beschikbaar blijven wanneer Microsoft 365, de VPN of het netwerk van het hoofdkantoor niet werkt. Een verzegelde papieren kopie of een opslagplaats buiten de belangrijkste afhankelijkheden kan de beheerde versie aanvullen. Vermeld de aanmeldings-URL, het toegestane toestel, de methode, de contactpersonen, de goedkeuringsprocedure, de toegestane acties en het plan om terug te keren naar de normale situatie. Neem geen wachtwoord in leesbare tekst op in dezelfde envelop als alle andere elementen wanneer een gescheiden bewaring mogelijk is.

Hoe monitor je elk gebruik?

Elke aanmeldingspoging van het noodaccount, geslaagd of mislukt, moet een zichtbaar en behandeld evenement worden.

Stuur de aanmeldingslogboeken van Entra naar de gekozen monitoringtool en maak vervolgens een regel die de object-ID’s van de noodaccounts als doel heeft. De officiële Microsoft-procedure geeft een voorbeeld met Azure Monitor, een query op SigninLogs, een drempelwaarde groter dan nul en een actiegroep. Microsoft Sentinel of een andere SIEM kan dezelfde logica toepassen. Monitor ook wijzigingen aan rollen, authenticatiemethoden, uitsluitingsgroepen en de accountstatus.

De waarschuwing moet meerdere personen bereiken via een kanaal dat niet uitsluitend afhankelijk is van de betrokken tenant. Ze bevat minimaal het tijdstip, het account, het resultaat, het IP-adres, de bekende context en het nummer van de test of het incident. Plaats geen onnodige gevoelige informatie in een sms. De persoon van wacht controleert onmiddellijk of het gebruik overeenkomt met een geplande oefening, een verklaarde noodsituatie of ongeoorloofd gedrag.

Le de implementatie van aangepaste MFA voor geprivilegieerde accounts moet ook de monitoring van geregistreerde methoden en hun levenscyclus omvatten. GVISION kan helpen om authenticatie, logboeken, voorwaardelijke toegang en de operationele procedure op elkaar af te stemmen, zonder het bezit van een sleutel op zich als voldoende garantie voor te stellen.

Hoe voer je een driemaandelijkse test uit zonder risico’s te creëren?

Test de volledige keten binnen een voorbereide periode: goedkeuring, toegang, waarschuwing, onschadelijke actie, afsluiting en evaluatie.

Kondig de oefening aan bij het toezichtteam zonder alle details vooraf bekend te maken. Controleer de verzegeling en de inventaris, haal het materiaal met twee personen op en gebruik het beveiligde toestel en een voorzien netwerk. Meld je aan, bevestig de ontvangst van de waarschuwing en voer een vooraf bepaalde niet-destructieve beheerdersactie uit, bijvoorbeeld een instelling raadplegen of bevestigen dat de rolpagina toegankelijk is zonder een toewijzing te wijzigen.

Controleer elk van de twee accounts afzonderlijk. Het succes van het eerste bewijst niets over het tweede. Test ook een alternatieve netwerkroute wanneer het plan daarin voorziet. Registreer de doorlooptijden: goedkeuring verkrijgen, toegang krijgen tot het materiaal, aanmelden, de waarschuwing ontvangen en afsluiten. Deze metingen dienen om het proces te verbeteren en niet om een universele SLA op te stellen. Documenteer elke afwijking, zoals een lege batterij, een niet-herkende sleutel, een te oud toestel of een verouderd contact.

Microsoft vereist een validatie minstens elke 90 dagen en na belangrijke wijzigingen, met name een wijziging binnen het IT-team of een verandering van abonnement. Sluit aan het einde de sessie af, verzegel het materiaal opnieuw, bewaar de logboeken en laat het verslag goedkeuren. Als de test een ernstig gebrek aan het licht brengt, start dan een corrigerende actie met een verantwoordelijke en deadline en voer na de correctie een nieuwe gerichte test uit.

Welke bewijzen moet je binnen een Belgische organisatie bewaren?

Bewaar proportionele bewijzen waaruit blijkt dat de oplossing bestaat, onder controle blijft en is getest, zonder van het artikel een certificering te maken.

Het nuttige register omvat de beslissing om de oplossing te creëren, de proceseigenaars, de accounts en object-ID’s, de rollen, de authenticatiemethoden, de bewaarplaatsen, de gerechtvaardigde uitsluitingen, de waarschuwingsregel en de resultaten van de oefeningen. Voeg wijzigingen in autorisaties, echte incidenten en acties na de evaluatie toe. Beperk de toegang tot deze elementen: te breed verspreide beveiligingsdocumentatie kan misbruik vergemakkelijken.

Voor organisaties die onder NIS2, sectorale vereisten, de AVG of ISO 27001 vallen, kan dit dossier de continuïteit, de controle op geprivilegieerde toegang en de traceerbaarheid ondersteunen. Het bewijst op zichzelf geen compliance en vervangt noch een algemene evaluatie noch een penetratietest. Het doel is een verifieerbare keten van besluitvorming en uitvoering te produceren: wie heeft goedgekeurd, wie heeft het gebruikt, waarom, welke acties zijn uitgevoerd en hoe de situatie werd genormaliseerd.

Stem de governance af op de omvang en de werkelijke werking van de organisatie. Een school, een vzw of een kantoor met een klein team heeft behoefte aan een korte procedure en duidelijk gemandateerde externe back-ups. Een multi-site groep of een zorginstelling moet de wachtdienst, lokale rollen, beschikbaarheid buiten de kantooruren en kritieke afhankelijkheden integreren. Het principe blijft hetzelfde: een noodsituatie ontslaat nooit van verantwoordelijkheid.

Welke fouten maken de oplossing gevaarlijk of onbruikbaar?

De meest voorkomende fouten zijn het gevolg van een gedeelde afhankelijkheid, dagelijks gebruik of een account dat nooit is getest.

Vermijd één enkel account, een gesynchroniseerde identiteit, een methode die gekoppeld is aan de smartphone van één persoon, een sleutel die naast het toestel wordt bewaard of een procedure die uitsluitend beschikbaar is in SharePoint. Elk onnodig gebruik verhoogt de blootstelling en vertroebelt het doel van de oplossing.

Maak geen uitsluiting voor voorwaardelijke toegang zonder inventaris of monitoring en wijzig nooit beide herstelpaden tegelijkertijd. Een test stopt niet bij de aanmelding: de waarschuwing, de onschadelijke actie, het afmelden, het opnieuw verzegelen en het verslag bewijzen samen de werkelijke capaciteit.