In Projekten erlebe ich immer wieder, dass jemand versehentlich eine Conditional-Access-Regel deaktiviert oder eine Named Location ändert, ohne dass es auffällt. Danach steht der Tenant plötzlich sperrangelweit offen. In Umgebungen mit mehreren Admins und wechselnden Zuständigkeiten bereitet mir das regelmäßig Bauchschmerzen. Microsoft Entra ID bietet dafür seit einiger Zeit die Protected Actions, die genau an dieser Stelle ansetzen. Besonders kritische Aktionen wie das Anlegen, Ändern oder Löschen von Conditional-Access-Policies lassen sich damit über eine zusätzliche Conditional-Access-Prüfung absichern. Admins müssen dann etwa eine phishing-resistente MFA, ein konformes Gerät oder einen anderen Authentifizierungskontext nachweisen.

Protected Actions verlangen für ausgewählte Vorgänge einen eigenen Nachweis

Mit Protected Actions bekommen sensible Vorgänge im Entra-ID-Portal eine zusätzliche Sicherheitsstufe. Man verlässt sich also nicht darauf, dass ein Admin schon ausreichend geschützt sein wird, sondern fordert für bestimmte Aktionen ausdrücklich einen Authentifizierungskontext. Die Auswahl, die Microsoft getroffen hat, ist überschaubar, deckt aber das Wichtige ab. Dazu zählen beispielsweise das Erstellen, Bearbeiten und Löschen von Conditional-Access-Richtlinien, Named Locations und Trust Framework Policies (siehe Microsoft-Dokumentation). Ein kompromittiertes Adminkonto kann so nicht mehr mit wenigen Klicks großen Schaden anrichten. Mich überrascht immer wieder, wie viele Tenants im Alltag ganz ohne solche Hürden auskommen und Angreifern damit einen bequemen Einstieg bieten.

Vom Prinzip her erinnern Protected Actions an ein Just-in-Time-Access-Szenario. Will ein Admin eine besonders sensible Änderung vornehmen, prüft Entra ID jedes Mal, ob die festgelegte zusätzliche Voraussetzung erfüllt ist. Erst danach geht es weiter, und zwar unabhängig davon, ob der Admin ohnehin schon im Portal angemeldet ist.

Ein Authentifizierungskontext und eine passende Richtlinie bilden die Grundlage

Bevor sich Protected Actions nutzen lassen, braucht man einen eigenen Authentifizierungskontext in Entra ID. Wer damit noch nicht gearbeitet hat, findet eine ausführliche Anleitung in meinem Beitrag Migration auf die Authentifizierungsmethoden-Richtlinie in Entra ID. Anschließend legt man eine Conditional-Access-Policy an, die genau diesen Kontext abdeckt. Sie verlangt dann zum Beispiel, dass für kritische Aktionen ein FIDO2-Key, eine zertifikatsbasierte Authentifizierung oder ein konformes Gerät vorliegt. Die Policy darf sich dabei nicht an alle Benutzer richten, sondern muss gezielt den Authentifizierungskontext adressieren.

Eine Richtlinie mit dem Authentifizierungskontext als Bedingung legt man im Entra-Portal unter Entra ID → Schutz → Conditional Access → Neue Richtlinie an:

Tipp aus der Praxis: Für Tests lege ich gern eine separate CA-Policy für den Authentifizierungskontext an und lasse sie zunächst im Report-Only-Modus laufen. Dann sehe ich, wie sich die Konfiguration auswirkt, und sperre mich nicht aus Versehen selbst aus.

Stehen Authentifizierungskontext und Policy, wählt man im Microsoft Entra Admin Center unter Rollen & Administratoren → Protected Actions → Protected Action hinzufügen die gewünschte Aktion aus, etwa „Conditional Access Policy erstellen oder bearbeiten“, und ordnet sie dem Authentifizierungskontext zu. Microsoft beschreibt das ebenfalls in einer eigenen Anleitung: Protected Actions hinzufügen.

Im Ergebnis läuft die Prüfung folgendermaßen ab:

flowchart TD
    Start["Admin meldet sich im Entra Portal an"] --> Action["Versuch: CA-Policy ändern"]
    Action --> Check["Protected Action erkannt?"]
    Check -- "Nein" --> Allow["Aktion erlaubt"]
    Check -- "Ja" --> StepUp["CA-Policy für Authentifizierungskontext auslösen"]
    StepUp --> Success["Bedingung erfüllt?"]
    Success -- "Nein" --> Deny["Aktion verweigert"]
    Success -- "Ja" --> Allow

Abbildung: Ablauf einer Protected Action mit zusätzlicher Conditional-Access-Prüfung

Im Alltag schließen Protected Actions Lücken, die vorher kaum auffielen

In den Tenants, die ich betreue, schließen Protected Actions immer wieder Sicherheitslücken, die zuvor niemand bemerkt hatte. Vor allem in hybriden Teams und in Organisationen mit vielen delegierten Berechtigungen verhindern sie ungewollte oder leichtfertige Änderungen an den zentralen Schutzmechanismen. Koppelt man beispielsweise jede Änderung an Conditional-Access-Policies an eine starke Authentifizierung oder an ein konformes Gerät, hat ein kompromittiertes Konto nicht sofort die gesamte Zugriffssteuerung in der Hand. Auf dieselbe Weise lassen sich auch Named Locations schützen, die Angreifer gern als Hintertür missbrauchen.

Lizenzseitig ist der Aufwand gering, denn für Protected Actions genügt eine Entra-ID-P1-Lizenz für die betroffenen Admins. Entscheidend ist allerdings, dass die CA-Policy für den Authentifizierungskontext tatsächlich sicher aufgebaut ist und weder schwache MFA-Methoden noch Ausnahmen für Legacy-Apps zulässt. Einzelheiten dazu stehen in Microsofts CA-Dokumentation.

PIM und Notfallkonten ergänzen den Schutz durch Protected Actions

Richtig wirksam werden Protected Actions häufig erst zusammen mit Privileged Identity Management (PIM) und Notfallzugriffskonten. Mit PIM lässt sich die Rollenaktivierung absichern, und das Zeitfenster, in dem Protected Actions überhaupt ausgeführt werden können, wird kleiner. Die Notfallkonten muss man selbstverständlich so konfigurieren, dass diese Kontrolle sie nicht blockiert – andernfalls sperrt man sich im schlimmsten Fall vollständig aus. Bewährt hat sich bei mir, solche Ausnahmen sauber zu dokumentieren und regelmäßig zu testen. Mehr dazu habe ich unter /blog/notfallzugriffskonten-entra-id-break-glass zusammengestellt.

In keinem produktiven Tenant sollten Protected Actions fehlen

Für mich gehören Protected Actions in jeden produktiven Tenant, erst recht, wenn dort mehrere Admins arbeiten. Angreifer haben es damit spürbar schwerer, während der Arbeitsalltag der Admins kaum leidet. Natürlich kostet die Einrichtung ein paar Minuten, und die CA-Policy will sorgfältig aufgebaut sein. Gemessen an der Gefahr, dass ein Angreifer innerhalb weniger Minuten sämtliche Conditional-Access-Policies löscht, fällt die Entscheidung aber leicht. Wer bereits starke Authentifizierung und PIM einsetzt, kann das Konzept sofort ausrollen und seinen Tenant deutlich widerstandsfähiger machen.