Stellt euch vor, es ist Dienstagmorgen 09:00 Uhr. Ein routinemäßiges Update eurer Conditional Access Policies (Bedingter Zugriff) in Microsoft Entra geht schief. Ein kleiner logischer Fehler, ein falsch gesetztes Häkchen bei den Ausschlüssen und plötzlich bist du und dein gesamtes Admin-Team aus dem Tenant ausgesperrt. Kein Zugriff auf Microsoft 365, kein Azure-Management, komplette Handlungsunfähigkeit.

Notfälle passieren jeden Tag. Meistens betreffen sie die anderen. Bis zu dem Tag, an dem es euer eigenes Unternehmen trifft. Was tut ihr dann?

Wir bei TEAL wissen aus der täglichen Beratungspflicht: Die meisten IT-Verantwortlichen wissen zwar theoretisch, dass Dinge schiefgehen können. Doch kaum ein Unternehmen investiert genug Zeit in das Szenario, was passiert, wenn man die totale Kontrolle über die eigene Cloud-Umgebung verliert. Das ist verständlich… solange, bis eine Fehlkonfiguration, ein globaler Systemausfall oder ein gezielter Cyberangriff das theoretische Problem in eine sehr reale Realität verwandelt.

Genau hier kommen Notfallkonten ins Spiel: die sogenannten Break-Glass Accounts. In diesem Artikel zeigen wir euch, wie ihr diese letzte Verteidigungslinie in Microsoft Entra nach aktuellen Best Practices absolut sicher aufbaut, härtet und überwacht.

Die bittere Realität in vielen Serverräumen

Auf dem Papier ist die Notwendigkeit von Notfallzugriffen für jeden Identity- & Access-Management-Experten (IAM) ein absoluter No-Brainer. Schauen wir uns jedoch die Realität in Unternehmen an, vom gehobenen Mittelstand (SMB) bis hin zu Großkonzernen, stoßen wir meist auf eines von drei Schreckensszenarien:

1. 1. 1. Es existieren schlichtweg überhaupt keine Break-Glass Accounts
      2. Es gibt zwar ein Notfallkonto, dieses wurde jedoch vor Jahren von einem ehemaligen Mitarbeiter erstellt, das Passwort ist unauffindbar und ein Login wurde noch nie getestet
      3. Konten existieren aber es existiert keine Dokumentation und auch kein Notfallhandbuch

Erschwerend kommt hinzu, dass sich die technische Landschaft rasant verändert. Microsofts Secure Future Initiative erzwingt mittlerweile rigoros Multi-Faktor-Authentifizierung (MFA) für Admin-Portale und CLI-Tools. Der veraltete Ansatz, einfach ein Notfallkonto mit einem 30-stelligen Passwort zu erstellen und es von jeglicher MFA auszuschließen, funktioniert heute technisch nicht mehr und ist brandgefährlich. Euer Break-Glass-Setup darf kein statisches Dokument in der Schublade sein; es muss leben.

Break-Glass Accounts „Done Right“

Ein Break-Glass Account in Microsoft Entra ID ist ein eigenständiges Konto, das mit der Rolle des Globalen Administrators ausgestattet ist. Es ist an keine reale Person gekoppelt. Warum? Weil der Zugriff im Ernstfall nicht davon abhängen darf, ob ein bestimmter Mitarbeiter im Urlaub, krank oder überhaupt noch im Unternehmen beschäftigt ist.

Um diese Konten wie kritische Infrastruktur zu schützen, empfehlen wir euch folgendes Vorgehen:

1. Benennung: Schluss mit „Security by Obscurity“

Früher hieß es oft, Notfallkonten sollten unauffällige Namen tragen, um bei einer Aufklärung (Reconnaissance) durch Angreifer nicht aufzufallen. Diese Denkweise ist veraltet. Angreifer suchen nicht nach Namen, sie suchen nach Berechtigungen.

Unsere Empfehlung: „Verwendet klare, eindeutige Namen (z. B. BreakGlass01@ihrefirma.onmicrosoft.com) und nutzt ausschließlich die standardmäßige .com-Domain. Euer eigenes SOC-Team und die Admins müssen im Ernstfall sofort und ohne Rätselraten erkennen, um welches Konto es sich handelt.“ – so unser Security Architekt Fabian Böhm.

2. Berechtigungen: Dauerhaft und aktiv

Das Notfallkonto muss sofort funktionieren, wenn alles andere brennt. Daher darf diese Rolle nicht via Privileged Identity Management (PIM) erst beantragt oder zeitlich befristet werden. Es muss eine direkte, permanente Zuweisung als Globaler Administrator sein. Microsoft empfiehlt maximal 4 Globale Administratoren pro Tenant. Eure zwei Break-Glass Konten müsst ihr hier bereits einrechnen.

3. Gruppenbasierter Ansatz vs. Einzelkonten

Sollten Break-Glass Accounts in einer Sicherheitsgruppe organisiert sein? Hier scheiden sich oft die Geister. Wir bei TEAL haben hierzu eine klare Haltung:

• • Der Einzelkonten-Ansatz
  • Unsere Empfehlung (Gruppenbasierter Ansatz): Nutzen Sie eine rollen-zuweisbare Sicherheitsgruppe (role-assignable security group). Das fügt zwar eine strukturelle Ebene hinzu, erlaubt es euch aber, Authentifizierungsmethoden wie Passkeys (FIDO2) und gerätegebundene Profile exakt für diese Gruppe zu erzwingen und die Nutzung über AAGUIDs auf freigegebene Hardware-Token (z. B. YubiKeys) zu beschränken.

4. Das Management einschränken via RMAU

Da es sich bei den Konten und Gruppen um Objekte im Tenant handelt, könnten sie theoretisch von anderen privilegierten Admins manipuliert oder gelöscht werden. Das verhindern wir durch den Einsatz von Restricted Management Administrative Units (RMAU). Indem ihr eure Break-Glass Accounts und deren Sicherheitsgruppe in eine RMAU legt, sperrt ihr den administrativen Zugriff für Standard-Admins komplett aus. Nur explizit definierte Identitäten können diese Konten verwalten. Ein massiver Sicherheitsgewinn.

Monitoring & Prozeduren: Wenn das Notfallkonto flüstert, muss das SOC schreien

Ein Notfallkonto darf im Normalbetrieb niemals verwendet werden. Jede einzelne Anmeldung, ob erfolgreich oder fehlgeschlagen, muss sofort einen kritischen Alarm der höchsten Priorität auslösen.

Dazu müsst ihr die Microsoft Entra Logs zwingend an einen Log Analytics Workspace (oder direkt in ein SIEM wie Microsoft Sentinel) streamen. Sobald eine Aktivität des Kontos registriert wird, muss eine automatisierte Alarmierung die IT-Leitung und das Sicherheitszentrum (SOC) per Telefon, SMS oder dedizierten Kanälen aufschrecken.

Darüber hinaus nützt die beste technische Absicherung nichts ohne die passenden organisatorischen Prozesse:

• • Sichere Verwahrung: Die Passwörter und Hardware-Token gehören in physische Safes (z. B. an zwei getrennten Unternehmensstandorten).
  • Regelmäßiges Testing: Mindestens einmal pro Quartal müsst ihr den Ernstfall simulieren und den Login mit dem Break-Glass Account exzessiv testen.
  • Dokumentation & Training: Euer IT-Personal muss im Schlaf wissen, wo die Schlüssel liegen, wer berechtigt ist, den Tresor zu öffnen, und wie die technischen Schritte zur Wiederherstellung aussehen.

Fazit

Ein sicherer Microsoft Entra Tenant zeichnet sich nicht nur dadurch aus, wie gut er Angriffe abwehrt, sondern vor allem dadurch, wie resilient er im Moment einer Katastrophe reagiert. Ein sauber aufgesetzter, gruppenbasierter und via RMAU geschützter Break-Glass Account sorgt dafür, dass ihr im Ernstfall agieren könnt, statt in Panik zu geraten.

Habt ihr den Ernstfall für euren Tenant bereits durchgespielt? Wir unterstützen euch dabei, eure IAM-Architektur auf Enterprise-Niveau zu heben, Fallstricke bei der Microsoft-MFA-Umstellung zu vermeiden und eure Notfallprozesse wasserdicht zu machen.

Quelle: Chance of Security