Restore-Funktion für Conditional Access Policies?

Die Verwaltung von Conditional Access Policies in Microsoft Entra ID ist ein zentraler Bestandteil moderner Sicherheitsarchitekturen. Bisher galt: Wer eine Richtlinie löscht, muss sich der Konsequenzen bewusst sein, denn eine Wiederherstellung war nicht möglich. Mit der Einführung einer neuen Restore-Funktion über die Microsoft Graph API ändert sich dieses Paradigma grundlegend. Ziel ist es, versehentlich gelöschte Richtlinien innerhalb eines definierten Zeitraums wiederherstellen zu können, ohne auf manuelle Rekonstruktion angewiesen zu sein.

Warum ist diese Funktion relevant?

Conditional Access Policies steuern den Zugriff auf Unternehmensressourcen basierend auf Identität, Standort, Gerätezustand und weiteren Faktoren. Sie sind ein kritischer Bestandteil der Zero-Trust-Strategie. Ein Fehler bei der Konfiguration oder Löschung kann unmittelbare Auswirkungen auf Compliance und Sicherheit haben. Um diese Risiken zu minimieren, bietet Microsoft nun eine Art „Soft-Delete“-Mechanismus, der die Wiederherstellung ermöglicht, bevor die Richtlinie endgültig entfernt wird.

Architektur und Funktionsweise der Restore-Funktion

Die neue Funktion basiert auf dem Konzept der „soft-deleted objects“, das bereits für andere Entra-Objekte wie Benutzer oder Gruppen existiert. Nach dem Löschen einer Conditional Access Policy wird diese nicht sofort aus dem Verzeichnis entfernt, sondern in einen speziellen Container verschoben. Dort verbleibt sie für einen definierten Zeitraum (aktuell 30 Tage), bevor sie endgültig gelöscht wird.

Technisch erfolgt die Wiederherstellung über die Microsoft Graph API. Der Prozess gliedert sich in drei Schritte:

1. Ermittlung gelöschter Richtlinien:
   Über den Endpunkt https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies können Administratoren prüfen, ob gelöschte Richtlinien vorhanden sind. Die Abfrage erfordert die Berechtigung Policy.Read.ConditionalAccess sowie eine entsprechende Rolle wie „Conditional Access Administrator“.
   
2. Restore-Operation:
   Die Wiederherstellung erfolgt über einen POST-Request an den Endpunkt
   https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies/{PolicyId}/restore.
   Hierfür wird die Berechtigung Policy.ReadWrite.ConditionalAccess benötigt. Nach erfolgreicher Ausführung erscheint die Richtlinie wieder in der Entra Admin Center Oberfläche.
   
3. Optionale endgültige Löschung:
   Falls eine Richtlinie vor Ablauf der 30 Tage endgültig entfernt werden soll, kann dies über einen DELETE-Request an den entsprechenden Endpunkt erfolgen. Dies ist vor allem relevant, wenn Richtlinien aus Sicherheitsgründen nicht länger im Soft-Delete-Status verbleiben sollen.

Warum aktuell nur über die Graph API?

Die Funktion ist derzeit ausschließlich über die Beta-Endpunkte der Microsoft Graph API verfügbar. Das bedeutet, dass Administratoren PowerShell-Skripte oder direkte HTTP-Requests nutzen müssen. Ein entsprechendes Cmdlet im Microsoft Graph PowerShell SDK ist noch nicht vorhanden, wird aber voraussichtlich in einer der kommenden Versionen ergänzt. Bis dahin ist die Nutzung von Invoke-MgGraphRequest der praktikabelste Weg.

Diese Entscheidung folgt einem klaren Muster: Microsoft führt neue Funktionen zunächst über die Graph API ein, um Feedback zu sammeln und Stabilität sicherzustellen, bevor sie in die Entra Admin Center GUI integriert werden. Für Administratoren bedeutet das, dass Kenntnisse in Graph API und PowerShell zunehmend unverzichtbar sind.

Sicherheits- und Compliance-Aspekte

Die Restore-Funktion ist nicht nur ein Komfort-Feature, sondern ein Sicherheitsmechanismus. Sie reduziert das Risiko, dass kritische Richtlinien durch menschliche Fehler verloren gehen. Gleichzeitig bleibt die Kontrolle erhalten, da die Wiederherstellung nur durch Benutzer mit entsprechenden Rollen und Berechtigungen möglich ist. Die 30-Tage-Frist ist ein bewusster Kompromiss zwischen Flexibilität und Datenschutz: Richtlinien sollen nicht unbegrenzt im Soft-Delete-Status verbleiben, um die Angriffsfläche zu minimieren.

Integration mit KI-gestützten Entra-Agenten

Parallel zur Einführung der Restore-Funktion testet Microsoft KI-basierte Optimierungsagenten für Conditional Access. Diese Agenten analysieren bestehende Richtlinien und schlagen Konsolidierungen vor. Das Ziel ist eine schlankere, effizientere Policy-Struktur. Hier entsteht ein neues Risiko: Automatisierte Empfehlungen können zur Löschung von Richtlinien führen, die später doch benötigt werden. Die Restore-Funktion dient in diesem Kontext als Sicherheitsnetz, das Administratoren die Möglichkeit gibt, unerwünschte Änderungen rückgängig zu machen.

Best Practices für den Umgang mit Conditional Access Policies

Auch mit der neuen Restore-Funktion bleibt die Empfehlung bestehen, Richtlinien nicht sofort zu löschen, sondern zunächst zu deaktivieren. Dies ermöglicht eine kontrollierte Beobachtung, ob die Deaktivierung unerwartete Auswirkungen hat. Erst nach einer Testphase sollte die endgültige Löschung erfolgen. Die Restore-Funktion ist eine Absicherung, kein Ersatz für sorgfältige Planung.

Fazit: Mehr Sicherheit, aber kein Freibrief für unüberlegte Änderungen

Die Einführung der Restore-Funktion für Conditional Access Policies ist ein wichtiger Schritt hin zu mehr Resilienz in der Administration von Entra ID. Sie bietet eine zusätzliche Schutzschicht gegen menschliche Fehler und unterstützt die Automatisierung durch KI-Agenten, ohne die Kontrolle aus der Hand zu geben. Dennoch bleibt die Verantwortung beim Administrator: Die Funktion ist kein Ersatz für strategisches Policy-Management, sondern ein Werkzeug zur Schadensbegrenzung.

Aus architektonischer Sicht stärkt Microsoft damit die Konsistenz seines Soft-Delete-Ansatzes über verschiedene Objekttypen hinweg. Für Unternehmen bedeutet das eine höhere Betriebssicherheit und weniger Aufwand bei der Wiederherstellung kritischer Konfigurationen. Der Nutzen ist klar: Zeitersparnis, Risikominimierung und eine bessere Absicherung gegen Compliance-Verstöße. Die Herausforderung liegt darin, die neuen Möglichkeiten in bestehende Prozesse zu integrieren und gleichzeitig die Governance nicht zu vernachlässigen. Wer Conditional Access als Teil einer Zero-Trust-Strategie versteht, wird die Restore-Funktion als sinnvolle Ergänzung sehen – nicht als Einladung zu unüberlegten Änderungen.

weitere Links