Werden Sie gerade angegriffen? Hilfe bei der Vorfallsbehandlung

Identität und Zugriff

Break-Glass-Konten in Entra ID: Zugang, wenn nichts mehr geht

Wie ein kleines IT-Team zwei Entra-ID-Notfallkonten aufbaut, von Conditional Access ausnimmt, jede Anmeldung alarmiert und alle 90 Tage testet.

Auch verfügbar auf:EnglishTürkçeFrançaisEspañolItalianoPolskiNederlandsEesti

Illustration: Break-Glass-Konten in Entra ID: Zugang, wenn nichts mehr geht

Ein Tenant kann sich auch ohne Angreifer selbst aussperren. Sind alle Zuweisungen für Global Administrator und Privileged Role Administrator eligible, verlangt die Aktivierung eine Genehmigung und sind keine Genehmiger ausgewählt, kann niemand etwas genehmigen. Standardmäßig sind aktive Administratoren die Genehmiger, und es gibt keine. Der Ausweg sind zwei rein cloudbasierte Break-Glass-Konten, die im Voraus eingerichtet und geübt wurden.

Wann Sie sie brauchen

Der Leitfaden von Microsoft zum Notfallzugriff nennt die typischen Fälle. Die Föderation ist ausgefallen, weil der Host Ihres Identity Providers defekt ist. Alle Administratoren haben für MFA nur Anrufe und SMS registriert, und das Mobilfunknetz ist gestört. Die letzte Person mit Global-Administrator-Zugriff verlässt das Unternehmen, und ihr Konto wird On-Premises deaktiviert oder gelöscht, was Entra ID nicht verhindert.

Die Konten einrichten

Legen Sie mindestens zwei Konten an. Machen Sie sie rein cloudbasiert auf der Domain *.onmicrosoft.com, weder föderiert noch aus dem lokalen Verzeichnis synchronisiert. Weisen Sie jedem Konto die Rolle Global Administrator zu.

Setzen Sie diese Zuweisung in Privileged Identity Management (PIM) auf active permanent, nicht auf eligible. Alltägliche Administratoren sollten Just-in-Time-Zugriff nutzen, doch diese Konten dürfen nicht von einem Aktivierungsschritt abhängen, denn genau dieser Schritt kann im Notfall ausfallen. PIM erfordert Microsoft Entra ID P2 oder Entra ID Governance.

Die Quellen behandeln keine Tenants ohne PIM, daher ist dieser Teil unsere eigene Überlegung. Die Einstellung active versus eligible gehört zu PIM und greift dort nicht. Die Konten brauchen dennoch eine direkte, dauerhafte Zuweisung als Global Administrator, aus demselben Grund: Nichts soll erst aktiviert werden müssen.

Wählen Sie für die Authentifizierung ein passwortloses Verfahren, das die MFA-Anforderung erfüllt:

  • Passkey (FIDO2), was Microsoft empfiehlt.
  • Zertifikatsbasierte Authentifizierung, wenn Sie bereits eine PKI betreiben.

Verwenden Sie ein anderes Verfahren als Ihre alltäglichen Administratoren. Nutzen diese die Microsoft-Authenticator-App, geben Sie den Notfallkonten einen FIDO2-Sicherheitsschlüssel. Binden Sie gemeinsam genutzte Konten nicht an eine Person oder an ein von Mitarbeitenden gestelltes Gerät wie ein Smartphone. Microsoft erlaubt auch individuelle Notfallkonten pro Administrator, was Nachvollziehbarkeit schafft und die Nutzung von entfernten Standorten ermöglicht. Entscheiden Sie sich bewusst für ein Modell.

Bewahren Sie die Schlüssel in feuerfesten Tresoren an sicheren, getrennten Orten auf, erreichbar für die berechtigten Personen. Nutzen Sie für jede Anmeldung mit diesen Konten eine dafür vorgesehene gesicherte Arbeitsstation, etwa eine Privileged Access Workstation.

Von Conditional Access ausnehmen

Eine erzwungene Richtlinie, die MFA, ein konformes Gerät oder eine andere Kontrolle verlangt, kann das Konto im Notfall unbrauchbar machen. Geschützt wird das Konto durch die phishingresistente Anmeldeinformation. Nehmen Sie es daher von jeder Richtlinie aus, die Anmeldungen blockiert oder einschränkt. Conditional Access erfordert Entra ID P1.

Legen Sie eine dedizierte Sicherheitsgruppe an, zum Beispiel EmergencyAccess, nehmen Sie beide Konten hinein auf und schließen Sie die Gruppe in diesen Richtlinien aus. Richtlinien im Nur-Bericht-Modus (report-only) blockieren nichts und brauchen keinen Ausschluss.

Eine Gruppe allein genügt nicht, weil neue Richtlinien von Personen geschrieben werden, die vielleicht nicht wissen, dass es diese Konten gibt. Öffnen Sie jede aktivierte Richtlinie und prüfen Sie im Abschnitt Exclude, ob die Gruppe dort steht. Prüfen Sie Report-only-Richtlinien erneut, bevor jemand sie scharf schaltet. Nehmen Sie die Frage „Ist EmergencyAccess ausgeschlossen?" in die Prüfliste für jede neue Richtlinie auf und testen Sie nach jeder wesentlichen Änderung eine Anmeldung.

Bei jeder Anmeldung alarmieren

Diese Konten sollten sich nur für Übungen und echte Notfälle anmelden, daher verdient jede Anmeldung einen Alarm. Das Beispiel von Microsoft nutzt Azure Monitor und setzt voraus, dass Ihre Entra-Anmeldeprotokolle zuvor an einen Log-Analytics-Workspace gesendet werden.

  1. Gehen Sie im Entra admin center mindestens als User Administrator zu Entra ID > Users, öffnen Sie jedes Notfallkonto und kopieren Sie dessen Object ID.
  2. Öffnen Sie im Azure-Portal mindestens als Monitoring Contributor Monitor > Alerts und wählen Sie + Create > Alert rule.
  3. Wählen Sie auf der Registerkarte Scope Ihren Log-Analytics-Workspace.
  4. Wählen Sie auf der Registerkarte Condition als Signalnamen Custom log search und als Abfragetyp Aggregated logs.
  5. Geben Sie eine Abfrage mit beiden Object IDs ein:
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
  1. Wählen Sie unter Measurement die Kennzahl, den Aggregationstyp und die Aggregationsgranularität. Wählen Sie unter Split by dimensions die Spalte Resource ID.
  2. Setzen Sie unter Alert logic den Schwellenwerttyp auf Static, den Operator auf Greater than und den Schwellenwert auf 0. Stellen Sie die Auswertungshäufigkeit so ein, wie schnell Sie benachrichtigt werden möchten.
  3. Leiten Sie den Alarm per E-Mail und SMS an mehrere Administratoren weiter, nicht nur an eine Person.

Microsoft zeigt außerdem eine Abfrage über den UserPrincipalName. Wir verwenden aus Gewohnheit die Object ID, denn eine auf einem Namen basierende Abfrage hängt davon ab, dass dieser Name unverändert bleibt. Fügen Sie für jedes weitere Konto eine zusätzliche Klausel or UserId == "ObjectGuid" hinzu.

Wenn in Ihrem Team niemand außerhalb der Arbeitszeiten Alarme beobachtet, kann ein Managed-Monitoring-Service diesen Teil übernehmen.

Testen und jede Nutzung auswerten

Prüfen Sie die Konten mindestens alle 90 Tage. Eine Übung sollte die Liste der berechtigten Personen, eine echte Anmeldung mit dem Sicherheitsschlüssel und eine administrative Aufgabe umfassen. Sie sollte bestätigen, dass sich die Konten mit Ihrer aktuellen Conditional-Access-Konfiguration weiterhin anmelden können und dass jeder Schlüssel bzw. jedes Zertifikat vorhanden ist und weder abgelaufen ist noch durch eine automatische Bereinigung entfernt wurde.

Jede Übung sollte Ihren Alarm auslösen. Wiederholen Sie den Test nach jeder Änderung am Workspace oder an den Diagnoseeinstellungen, die ihn speisen. Führen Sie ein kurzes Protokoll:

DatumDurchgeführt vonKonto und SchlüsselSchlüssel oder Zertifikat gültigAlarm eingegangen nachFestgestellte Fehler
Konto 1, Schlüssel A
Konto 2, Schlüssel B

Führen Sie nach jeder echten Nutzung eine Nachbesprechung durch. Klären Sie, ob die Nutzung autorisiert war und ob die ergriffenen Maßnahmen angemessen waren. Regulierte Organisationen können diese Aufzeichnung zusammen mit den Protokollen und dem Übungsprotokoll als Nachweis dafür vorlegen, dass der Notfallzugriff geregelt ist. Wenn Sie eine externe Prüfung wünschen, kann unser Beratungsteam die Konfiguration begutachten.

Wo Sie anfangen

  1. Listen Sie Ihre Global Administratoren im Entra admin center auf und vergleichen Sie die Anzahl mit der Microsoft-Empfehlung von weniger als fünf. Klären Sie, ob bereits ein Konto für Notfälle vorgesehen ist.
  2. Erstellen Sie zwei rein cloudbasierte .onmicrosoft.com-Konten mit dauerhaft aktiver Global-Administrator-Zuweisung und registrieren Sie für jedes einen eigenen FIDO2-Schlüssel.
  3. Legen Sie die Gruppe EmergencyAccess an und schließen Sie sie von jeder Conditional-Access-Richtlinie aus, die Anmeldungen blockiert oder einschränkt.
  4. Senden Sie die Anmeldeprotokolle an Log Analytics und erstellen Sie die Alarmregel mit einem Schwellenwert größer als 0 für beide Object IDs.
  5. Lagern Sie die Schlüssel an getrennten feuerfesten Orten, benennen Sie die berechtigten Personen und stellen Sie sicher, dass keine Anmeldeinformation abläuft oder in den Bereich einer automatischen Bereinigung fällt.
  6. Melden Sie sich mit jedem Konto an, bestätigen Sie, dass der Alarm ausgelöst wird, füllen Sie die erste Zeile des Übungsprotokolls aus und tragen Sie die nächste Übung innerhalb von 90 Tagen in den Kalender ein.

So können wir helfen

Beratung und Schulung

Wir ermitteln, wo Sie stehen, setzen mit Ihnen Prioritäten und schulen Ihre Mitarbeitenden darin, Angriffe zu erkennen.

Schreiben Sie uns
AngelForce-Team

Geschrieben vom AngelForce-Team: Sicherheitsberater mit CEH-, LPT-Master- und CISA-Zertifizierung, die Systeme von Organisationen in ganz Europa testen, überwachen und schützen.

Mit KI-Unterstützung auf Grundlage der unten aufgeführten öffentlichen Quellen verfasst und vor der Veröffentlichung vom AngelForce-Team geprüft.

Quellen

  1. learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
  2. learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices

Artikel zum Thema Identität und Zugriff

Sagen Sie uns, was Sie schützen müssen

Beschreiben Sie Ihre Umgebung und was Sie erreichen möchten. Wir antworten per E-Mail.

Schreiben Sie uns
info@angelforce.eu +372 5705 2044

AngelForce OÜ · Tallinn, Estland