Identity Incidents und Recovery

Zwei Notfälle, die nichts miteinander zu tun haben

Unter „Identitätsvorfall“ fallen zwei völlig verschiedene Lagen, und sie verlangen entgegengesetzte Reaktionen. Wer sie verwechselt, macht die falsche Sache schnell.

Zu viel Zugriff

Ein fremder Zugriff auf ein Konto. Die Aufgabe ist, ihn zu beenden — schnell und vollständig.

Zu wenig Zugriff

Niemand kommt mehr in die Verwaltung. Die Aufgabe ist, wieder hineinzukommen, ohne den Schutz abzuschalten.

Die zweite Lage ist die unangenehmere, weil sie sich selbst verstärkt: Die Werkzeuge, mit denen man sie beheben würde, liegen hinter genau der Sperre, die behoben werden soll. Deshalb beginnt dieses Modul mit dem Aussperren und kommt erst danach zur Übernahme.

Fünf dokumentierte Wege in die Aussperrung

Die Dokumentation zählt die Lagen auf, in denen eine Organisation ihre eigene Verwaltung verliert. Sie sind lehrreich, weil keine davon ein Angriff ist.

• Die Konten sind föderiert, und die Föderation ist gerade nicht verfügbar — etwa weil der Identitätsanbieter ausgefallen ist.
• Alle Verwaltenden nutzen mehrstufige Authentifizierung, und ihre Geräte oder der Dienst sind nicht erreichbar. Wer nur Anruf und Kurznachricht registriert hat, ist bei einer Mobilfunkstörung ausgesperrt.
• Die Person mit dem letzten Zugang verlässt die Organisation. Entra verhindert zwar das Löschen des letzten Global Administrators — nicht aber, dass das Konto lokal gelöscht oder deaktiviert wird.
• Ein unvorhergesehenes Ereignis, bei dem Mobilfunk oder andere Netze ausfallen.
• Alle Zuweisungen von Global Administrator und Privileged Role Administrator sind berechtigt statt aktiv, die Aktivierung verlangt eine Genehmigung, und es ist niemand als genehmigende Person hinterlegt.

Der letzte Fall ist der eleganteste und verdient einen eigenen Abschnitt, weil er direkt aus dem Modul zum privilegierten Zugriff folgt.

Die Sackgasse, die man sich selbst baut

Sind keine genehmigenden Personen ausgewählt, gelten laut Dokumentation die aktiven Inhaber von Global Administrator und Privileged Role Administrator als Genehmigende. Wenn aber alle Zuweisungen berechtigt statt aktiv sind, gibt es keine aktiven Inhaber — und damit niemanden, der eine Aktivierung genehmigen kann.

Das Ergebnis: Die Tenantverwaltung ist wirksam gesperrt. Niemand hat etwas falsch gemacht; jeder einzelne Schritt war die empfohlene Praxis. Keine stehenden Privilegien ist richtig. Genehmigung bei der Aktivierung ist richtig. Zusammen ergeben sie einen Kreis.

Notfallzugangskonten: die Anforderungen im Einzelnen

Die Antwort auf alle fünf Wege sind zwei oder mehr Notfallzugangskonten. Aus dem ersten Modul ist die Grundform bekannt; hier stehen die Anforderungen vollständig.

• Reine Cloud-Konten auf der *.onmicrosoft.com-Domäne — nicht föderiert, nicht aus einem lokalen Verzeichnis abgeglichen.
• Ein kennwortloses Verfahren, das die Anforderung an mehrstufige Authentifizierung erfüllt; die Dokumentation empfiehlt einen Passkey nach FIDO2.
• Keiner einzelnen Person zugeordnet und nicht mit privaten Geräten wie Telefonen verbunden.
• Anmeldedaten sicher und getrennt verwahrt, an mehr als einem Ort und für mehrere Personen der Verwaltung erreichbar.
• Anmelde- und Überwachungsprotokolle dieser Konten überwacht.
• Die Konten regelmäßig überprüft.

Keine gemeinsame Abhängigkeit

Die wichtigste Einzelanforderung ist zugleich die am häufigsten übersehene: Das Notfallkonto darf nicht dasselbe Anmeldeverfahren verwenden wie die übrigen Verwaltungskonten.

Die Dokumentation nennt das Beispiel: Nutzen die gewöhnlichen Administratorkonten den Authenticator, dann bekommen die Notfallkonten einen FIDO2-Sicherheitsschlüssel. Der Grund ist eine der fünf Lagen — fällt der Dienst oder das Verfahren aus, das alle nutzen, hilft ein Notfallkonto mit demselben Verfahren niemandem.

Dieselbe Überlegung gilt für die Föderation. Die Dokumentation verlangt, den Notfallzugang für lokale Systeme und den für Cloud-Dienste getrennt zu halten, ohne Abhängigkeit voneinander. Ein Notfallkonto, dessen Anmeldung aus einem anderen System stammt, erbt dessen Ausfälle.

Gemeinsame Abhängigkeit — Ein Bauteil, von dem der Normalbetrieb und der Rettungsweg abhängen. Sie macht den Rettungsweg genau dann unbenutzbar, wenn er gebraucht wird — und ist von außen nicht sichtbar, weil beide Wege einzeln funktionieren.

Die Prüffrage dafür ist kurz und unbequem: Welches Bauteil müsste ausfallen, damit weder der normale noch der Notfallweg funktioniert? Findet sich eine Antwort, ist die gemeinsame Abhängigkeit gefunden. Häufige Kandidaten sind das Anmeldeverfahren, der Identitätsanbieter, das lokale Verzeichnis, ein einzelnes Mobiltelefon — und der Passwortsafe, in dem sowohl die Alltagszugänge als auch die Notfalldaten liegen.

Auch die Aufbewahrung der Anmeldedaten gehört zu dieser Überlegung. Die Dokumentation empfiehlt, sie an sicheren, getrennten Orten zu verwahren und mehreren Personen der Verwaltung zugänglich zu machen. Beides zusammen ist der Punkt: Ein einziger Ort ist ein einzelner Ausfallpunkt, und eine einzige zuständige Person ist es ebenso.

Die Ausnahme in den Zugriffsregeln — genauer betrachtet

Aus dem Modul zu Conditional Access stammt die Regel, Notfallkonten von sperrenden Zugriffsregeln auszunehmen. Die Dokumentation formuliert das präzise, und die Präzisierung ist nützlich.

Zu prüfen ist, dass die Konten von jeder Regel ausgenommen sind, die die Anmeldung blockiert oder einschränkt. Regeln im reinen Berichtsmodus blockieren nichts und brauchen daher keine Ausnahme. Das ist eine willkommene Entlastung: Beim Aufbau neuer Regeln muss man nicht jede Testregel mit einer Ausnahme versehen.

Sitzungen beenden: was der Vorgang leistet

Wechseln wir zur anderen Lage. Bei einer Kontoübernahme genügt es nicht, das Kennwort zu ändern — bestehende Sitzungen laufen weiter. Dafür gibt es einen eigenen Vorgang.

revokeSignInSessions macht laut Dokumentation alle Aktualisierungstoken ungültig, die für Anwendungen dieses Benutzers ausgestellt wurden, sowie die Sitzungscookies im Browser. Technisch geschieht das, indem die Eigenschaft signInSessionsValidFromDateTime auf den aktuellen Zeitpunkt gesetzt wird — alles davor gilt als ungültig.

Die Folge für eine Anwendung: Versucht sie, mit einem ungültig gewordenen Aktualisierungstoken ein Zugriffstoken zu holen, bekommt sie einen Fehler und muss die Person neu anmelden lassen. Die kleinste dafür nötige Berechtigung heißt User.RevokeSessions.All.

Und was der Vorgang nicht leistet

Zwei dokumentierte Einschränkungen entscheiden darüber, ob eine Reaktion wirkt.

Erstens gibt es eine Verzögerung. Nach dem Aufruf kann es laut Dokumentation einige Minuten dauern, bis die Token tatsächlich zurückgezogen sind. Wer unmittelbar danach prüft und noch Aktivität sieht, hat nicht zwingend einen zweiten Zugang gefunden — möglicherweise nur zu früh geschaut. Umgekehrt heißt es, dass ein Angreifer in diesen Minuten weiterarbeiten kann.

Zweitens wirkt der Vorgang nicht für externe Benutzer. Die Dokumentation begründet das: Externe melden sich über ihren Heimat-Tenant an. Bei einem übernommenen Gastkonto lässt sich die Sitzung also nicht von deiner Seite beenden — die Beendigung müsste in der fremden Organisation erfolgen.

Die Verzögerung von wenigen Minuten hat noch eine zweite Folge, die für die Reihenfolge zählt. Wer erst die Sitzungen beendet und dann in Ruhe nach hinterlassenen Zuständen sucht, gibt einem noch aktiven Angreifer ein kurzes Zeitfenster, in dem er bemerkt, dass er entdeckt wurde. Wer dagegen erst sucht und dann beendet, arbeitet länger neben einem aktiven Zugriff. Beides ist vertretbar — die Entscheidung sollte bewusst fallen und nicht dem Zufall der Bearbeitungsreihenfolge überlassen bleiben.

Für privilegierte Konten spricht mehr für das schnelle Beenden: Der mögliche Schaden pro Minute ist hoch, und die hinterlassenen Zustände lassen sich auch danach noch vollständig aus dem Überwachungsprotokoll rekonstruieren. Bei einem gewöhnlichen Konto mit begrenztem Zugriff kann die umgekehrte Reihenfolge sinnvoll sein.

Warum ein Kennwortwechsel allein nicht reicht

Die häufigste unvollständige Reaktion besteht darin, das Kennwort zu wechseln, die Sitzungen zu beenden und den Fall zu schließen. Beides ist richtig und beseitigt nur den Weg, den der Angreifer bisher genutzt hat.

• Registrierte Anmeldeverfahren — ein hinzugefügtes eigenes Verfahren überlebt jeden Kennwortwechsel und erlaubt die erneute Anmeldung.
• Erteilte Anwendungsberechtigungen — eine zugestimmte Anwendung greift mit eigener Identität zu, unabhängig vom Kennwort der Person. Der Fall aus dem Modul zu Workload-Identitäten.
• Weiterleitungen und Regeln in den Diensten — sie kopieren weiter Inhalte nach außen, ohne dass sich jemand anmelden müsste.
• Zusätzliche Nachweise an Anwendungsregistrierungen — ein zweites Geheimnis, das jemand hinterlegt hat.

Der gemeinsame Nenner: Alle vier sind Zustände, die der Angreifer hinterlassen hat, keine Sitzungen. Sie enden nicht mit einer Anmeldung, sondern erst, wenn jemand sie entfernt. Eine Bereinigung, die nur Sitzungen und Kennwort anfasst, schließt die Tür und lässt die Fenster offen.

Am unangenehmsten ist der zweite Punkt, weil er die Bereinigung überlebt und in keiner Kontoansicht auftaucht. Eine Anwendung mit einer erteilten Anwendungsberechtigung greift als sie selbst zu — sie braucht die übernommene Person nicht mehr. Wer das Konto bereinigt und die Zustimmung stehen lässt, hat den Zugang der Person geschlossen und den der Anwendung nicht angerührt.

Für die Reihenfolge folgt daraus eine Faustregel: Erst die Zustände suchen, dann den Fall schließen — nicht umgekehrt. Sobald die betroffene Person wieder arbeitet, vermischen sich ihre eigenen Änderungen mit denen des Angreifers, und die Unterscheidung wird von Stunde zu Stunde schwerer.

Getestet oder angenommen

Die Dokumentation verlangt, die Notfallkonten regelmäßig zu überprüfen. Das klingt nach Formalie und ist der Unterschied zwischen einem Rettungsweg und einer Annahme.

Zu prüfen ist nicht, ob das Konto existiert — das zeigt jede Liste. Zu prüfen ist, ob sich damit tatsächlich anmelden lässt: ob der Sicherheitsschlüssel noch funktioniert und auffindbar ist, ob keine neue Zugriffsregel das Konto inzwischen erfasst, ob die Anmeldedaten am hinterlegten Ort noch stimmen und ob die Personen, die sie holen dürfen, noch im Haus sind.

Sinnvoll ist außerdem, den Test an die Änderungen zu koppeln statt nur an den Kalender. Jede Umstellung, die Anmeldung oder Zugriffsregeln berührt — eine neue sperrende Regel, eine Änderung an den Anmeldeverfahren, die Einführung von PIM — ist ein Anlass, den Notfallweg einmal zu gehen. Genau diese Änderungen sind es, die ihn unbemerkt brechen.

Beim Testen selbst gilt eine Vorsichtsmaßnahme: Die Anmeldung mit einem Notfallkonto erzeugt einen Eintrag in den Protokollen, die laut Dokumentation überwacht werden sollen. Wer testet, ohne es anzukündigen, löst im besten Fall genau die Reaktion aus, die für den Ernstfall vorgesehen ist — was ein guter Nebeneffekt ist, solange alle Beteiligten wissen, dass es eine Übung war.

Durchgerechnet: eine Kontoübernahme bereinigen

Der Preis ist, dass die betroffene Person für die Dauer der Bereinigung vollständig unterbrochen ist, und dass die Suche nach hinterlassenen Zuständen deutlich länger dauert als der Kennwortwechsel — bei einem Konto mit vielen Berechtigungen leicht eine Stunde. Diese Stunde ist der Unterschied zwischen einer beendeten Übernahme und einer, die in zwei Wochen erneut auffällt.

Die Reihenfolge, die alles zusammenhält

Beide Notfälle dieses Moduls haben dieselbe Wurzel: eine Abhängigkeit, die niemand aufgeschrieben hat. Beim Aussperren ist es die Abhängigkeit des Rettungswegs vom Normalbetrieb, bei der Übernahme die Abhängigkeit der Bereinigung von der Annahme, dass ein Kennwort der einzige Zugang war.