CA Deep Dive (3/3) — Wenn der Türsteher ausfällt

Jedes Gym hat einen Notfallplan. Defibrillator an der Wand, Ersthelfer benannt, Fluchtwege markiert. Nicht weil jeden Tag etwas passiert — sondern weil an dem einen Tag, an dem es passiert, jede Sekunde zählt.

Dein Tenant braucht genau so einen Plan. Denn Conditional Access ist mächtig — aber was passiert, wenn der Türsteher selbst ausfällt?

Break Glass Accounts — dein Notfallzugang

Ich habe in der Security-Split-Serie bereits über Break Glass Accounts geschrieben. Hier nochmal die Zusammenfassung im CA-Kontext:

Cloud-only Accounts — breakglass01@tenant.onmicrosoft.com und breakglass02@tenant.onmicrosoft.com
Permanente Global Admin Rolle — die einzige bewusste Ausnahme von PIM
Zufälliges Passwort mit 16+ Zeichen — ausgedruckt und in versiegelten Umschlägen in Safes gelagert
FIDO2-Sicherheitsschlüssel — als primäre Authentifizierung registriert
Ausgeschlossen aus ALLEN CA-Policies — jede einzelne, ohne Ausnahme
Zwei Accounts an zwei Standorten — physische Redundanz

👉 Wenn du nur eine Sache aus dieser Serie mitnimmst: Richte Break Glass Accounts ein, bevor du sie brauchst.

CA Resilience Defaults — wenn CA selbst ein Problem hat

Was passiert, wenn Conditional Access als Dienst eine Störung hat? Wenn die Policy-Engine selbst nicht erreichbar ist?

Microsoft hat dafür Resilience Defaults eingebaut:

Bei einem CA-Ausfall fallen bestehende Sessions auf vorhandene Tokens zurück
Bereits authentifizierte User behalten ihren Zugriff
Neue Anmeldungen können je nach Konfiguration erlaubt oder blockiert werden

Prüfe in deinem Tenant, wie die Resilience Defaults konfiguriert sind. Das findest du unter Conditional Access → Resilience Defaults.

Der Notfallplan — kein Dokument im Regal

Ein Notfallplan ist nur so gut wie seine letzte Übung. Hier ist, was dein Emergency Protocol enthalten muss:

Zugang

Wer hat Zugang zu den Safes? — namentlich benannte Personen, mindestens zwei pro Standort
Wo sind die Safes? — exakte Standorte, nicht “irgendwo im Serverraum”
Wie kommt man rein? — Schlüssel, Code, Vier-Augen-Prinzip

Eskalationskette

Incident erkannt — durch Alert, User-Meldung oder Monitoring
Severity bewerten — ist ein Break Glass Login nötig oder reicht ein normaler Admin?
Benannte Person kontaktieren — wer öffnet den Safe?
Break Glass Login durchführen — dokumentieren, wer, wann, warum
Problem beheben — die eigentliche Ursache lösen
Post-Incident — Passwort rotieren, FIDO2-Key prüfen, Incident Report erstellen

Trigger-Kriterien

Wann wird der Notfallplan aktiviert? Definiere klare Kriterien:

Alle Admins sind ausgesperrt
CA-Fehlkonfiguration blockiert den gesamten Tenant
MFA-Dienst ist global ausgefallen
Verdacht auf kompromittierten Admin-Account mit aktiven Rechten

Monitoring — der stille Wächter

Jeder Login eines Break Glass Accounts muss einen Alert auslösen. Jeden. Ohne Ausnahme.

Severity: Critical — höchste Priorität
Benachrichtigung: E-Mail und SMS an Security-Team
SIEM-Integration: Log-Eintrag in Sentinel mit automatischem Incident

Und dann: Teste den Alert. Nicht theoretisch, sondern praktisch. Logge dich mit dem Break Glass Account ein und prüfe:

Kommt der Alert an?
Kommt er bei den richtigen Personen an?
Kommt er schnell genug an?

Regelmäßige Tests — quartalsweise

Wie im Gym: Ein Plan, den du nicht regelmäßig überprüfst, veraltet. Führe jeden Quartal diese Checks durch:

✅ Accounts aktiv? — sind die Break Glass Accounts noch vorhanden und nicht deaktiviert?
✅ Login funktioniert? — kannst du dich tatsächlich anmelden?
✅ Alert feuert? — kommt die Benachrichtigung durch die gesamte Kette an?
✅ Protokoll aktuell? — stimmen die benannten Personen, Telefonnummern, Standorte noch?
✅ Safe-Zugang korrekt? — kommen die benannten Personen tatsächlich an die Safes?

CA ist kein Projekt, das du abhakst

Conditional Access ist eine lebende Konfiguration. Sie muss gepflegt werden:

Monatlich: CA Workbook im Entra ID Portal reviewen — welche Policies greifen, welche nicht?
Quartalsweise: Policy Review — sind alle Policies noch aktuell? Gibt es neue Anforderungen?
Jährlich: Grundlegender Review — stimmt die gesamte Architektur noch? Neue Microsoft-Features berücksichtigt?

Dein Tenant verändert sich. Neue User, neue Apps, neue Geräte, neue Bedrohungen. Deine CA-Landschaft muss mitwachsen.

Das war der dritte und letzte Teil der CA Deep Dive Serie. Zusammen mit der Security Split Serie hast du jetzt ein solides Fundament, um deinen Tenant wirklich abzusichern — nicht nur auf dem Papier, sondern in der Praxis.

Bleib dran. Bleib konsequent. 💪

Gruß Micha