Break-glass-konton är inte bara ytterligare ett MFA-skyddat adminkonto

Varje MSP får förr eller senare frågan varför en kund behöver dedikerade nödåtkomstkonton om alla administratörer redan måste använda multifaktorautentisering. Svaret är att break-glass-konton löser ett annat problem: de ska förbli användbara när identitetsleverantören eller själva MFA-systemet inte är tillgängligt, inte lägga till ytterligare ett lager ovanpå ett system som redan fungerar.

Vad Microsoft rekommenderar

Microsofts vägledning för Entra ID kräver minst två molnbaserade nödåtkomstkonton som inte synkroniseras från en lokal katalog eller federeras via en extern identitetsleverantör – eftersom ett konto som är beroende av samma infrastruktur som det är tänkt att rädda egentligen inte är något nödkonto. Microsoft rekommenderar nätfiskeresistent autentisering som FIDO2-nycklar eller certifikatbaserad autentisering, medvetet oberoende av de metoder som vanliga administratörer använder, och en permanent – inte berättigad eller tidsbegränsad – tilldelning av rollen Global administratör i Privileged Identity Management, eftersom ett aktiveringsarbetsflöde är precis det som kanske inte fungerar under ett avbrott. Dessa konton bör fortfarande omfattas av Conditional Access-principer som kräver nätfiskeresistent MFA; det rekommenderade undantaget gäller specifikt geolokaliseringsbaserad blockering, inte åtkomstkontroller generellt, med tanke på tidigare fall där legitima inloggningar har felklassificerats geografiskt i timmar i sträck.

Vad NIST och OWASP tillför

Kontrollen AC-2(2) i NIST SP 800-53 beskriver nödkonton som något som aktiveras för en definierad kris och sedan automatiskt inaktiveras eller tas bort efteråt, snarare än att finnas kvar på obestämd tid. OWASP:s MFA-vägledning pekar ut återställnings- och kringgåendeprocesser som ett attackmål i sig: den mekanism som återställer åtkomst under en nödsituation får inte i tysthet bli ett sätt att hoppa över MFA under normala förhållanden.

Hur "bevisa att det fungerar" ser ut

• Övervaka inloggningar till just dessa konton, med en avisering vid varje försök – lyckat eller misslyckat.
• Genomför åtkomstövningar enligt ett fast schema, vanligen var 90:e dag, i stället för att anta att konfigurationen fortfarande fungerar.
• Skriv en kort efterhandsanalys efter varje verklig användning eller övning och justera konfigurationen utifrån vad den visade.
• Dokumentera vem som kan hämta ut autentiseringsuppgifter och hur, eftersom redundans utan en hämtningsprocess egentligen inte är redundans.

En utformning för nödåtkomst som aldrig har testats under simulerade fel är inte ett skydd – det är ett antagande.

Källor: Microsoft Learn – nödåtkomstkonton, NIST SP 800-53 Rev. 5.