Break-glass-accounts zijn niet zomaar een extra met MFA beveiligde admin

Elke MSP krijgt vroeg of laat de vraag waarom een klant speciale noodtoegangsaccounts nodig heeft als elke admin al verplicht multi-factorauthenticatie moet gebruiken. Het antwoord is dat break-glass-accounts een ander probleem oplossen: bruikbaar blijven wanneer de identityprovider of het MFA-systeem zelf niet beschikbaar is, niet het toevoegen van nog een laag bovenop een systeem dat al werkt.

Wat Microsoft aanbeveelt

De richtlijnen van Microsoft voor Entra ID vragen om ten minste twee cloud-only noodtoegangsaccounts, niet gesynchroniseerd vanuit een on-premises directory of gefedereerd via een externe identityprovider — want een account dat afhankelijk is van dezelfde infrastructuur die het moet redden, is niet echt een noodaccount. Microsoft beveelt phishingbestendige authenticatie aan, zoals FIDO2-sleutels of certificaatgebaseerde authenticatie, bewust onafhankelijk van de methoden die gewone admins gebruiken, en een permanente — niet in aanmerking komende of tijdelijke — roltoewijzing voor Global Administrator in Privileged Identity Management, omdat een activeringsworkflow nu net iets is dat tijdens een storing mogelijk niet werkt. Deze accounts moeten nog steeds worden afgedekt door Conditional Access-beleid dat phishingbestendige MFA vereist; de aanbevolen uitzondering is specifiek voor blokkering op basis van geolocatie, niet voor toegangscontroles in het algemeen, gezien eerdere gevallen waarin legitieme aanmeldingen urenlang geografisch verkeerd werden geclassificeerd.

Wat NIST en OWASP toevoegen

De AC-2(2)-control uit NIST SP 800-53 beschrijft noodaccounts als iets dat wordt geactiveerd voor een gedefinieerde crisis en daarna automatisch wordt uitgeschakeld of verwijderd, in plaats van onbeperkt te blijven bestaan. De MFA-richtlijnen van OWASP benoemen herstel- en bypassprocedures als een aanvalsdoel op zich: welk mechanisme de toegang tijdens een noodsituatie ook herstelt, het mag niet stilletjes een manier worden om MFA onder normale omstandigheden te omzeilen.

Hoe "bewijs dat het werkt" eruitziet

• Monitor aanmeldingen bij deze accounts specifiek, met een melding bij elke poging — geslaagd of mislukt.
• Voer toegangsoefeningen uit volgens een vast schema, doorgaans elke 90 dagen, in plaats van ervan uit te gaan dat de configuratie nog werkt.
• Schrijf een korte post-mortem na elk echt gebruik of elke oefening en pas de configuratie aan op basis van de bevindingen.
• Documenteer wie credentials kan opvragen en hoe, want redundantie zonder een opvraagproces is niet echt redundant.

Een noodtoegangsontwerp dat nooit onder gesimuleerde uitval is getest, is geen bescherming — het is een aanname.

Bronnen: Microsoft Learn — emergency access accounts, NIST SP 800-53 Rev. 5.