M365 PIM-Rollenkonzept | Admin-Rechte nur dann, wenn wirklich benötigt!

Ein Administrator mit dauerhaft aktivem Global Administrator ist kein Admin, sondern ein wandelndes Risiko. Wer ISO 27001 oder TISAX im Haus hat, weiß das. Und wer Entra ID P2 lizenziert hat, hat das passende Werkzeug bereits bezahlt: Privileged Identity Management, kurz PIM.

PIM ist aber nicht nur dann sinnvoll, wenn ein Audit-Termin im Kalender steht. Auch ohne ISO oder TISAX im Haus profitierst du sofort: weniger Standing Privileges, sauberer Audit-Trail, weniger Bauchgefühl bei der Frage „wer hat eigentlich gerade welche Rechte". Und falls du heute noch keine P2-Lizenz hast: Eine Entra ID P2 kostet aktuell rund 7,80 € pro Benutzer und Monat (Listenpreis, jährliche Abrechnung, zzgl. MwSt., Stand Mai 2026).

Wichtig: Du brauchst die Lizenz nur für die Accounts, die per PIM verwaltet werden, also typischerweise deine Admin-Accounts, nicht für jeden Standard-User. Bei drei bis fünf Admin-Accounts reden wir von 25 bis 45 € im Monat. Das ist günstiger als jede Schadensbegrenzung nach einem kompromittierten Global Admin.

Mit AiTM-Phishing-Kits und Token-Diebstahl als Massenphänomen ist Standing Privileges heute kein theoretisches Restrisiko mehr, sondern der Hauptangriffspfad. Genau dagegen wirkt PIM, weil es dem Angreifer selbst mit gestohlenem Token noch die Aktivierungs-Hürde mit MFA-Challenge und Justification vorsetzt. Genau das habe ich für meinen eigenen Admin-Account vor Jahren umgesetzt und seitdem mehrfach geschärft. Hier ist die Version, die du übernehmen kannst.

Standing Privileges sind das Hauptproblem. Wenn ein Angreifer per Phishing oder Token-Diebstahl an einen aktiven Global Admin kommt, hat er sofort Tenant-weite Kontrolle. Bei einer Eligible-Zuweisung muss der Angreifer zusätzlich die Aktivierung durchlaufen, also MFA-Challenge, Justification-Eingabe und gegebenenfalls einen Approval-Workflow. Jede dieser Hürden ist ein zusätzlicher Detektionspunkt.

Der zweite Grund ist Audit-Tauglichkeit. Bei jeder PIM-Aktivierung entsteht ein Eintrag mit Zeitstempel, Begründung und Geltungsdauer. Im ISO-27001-Audit ist das Gold wert, weil du Zugriffe nicht nur policy-konform geregelt, sondern auch nachweisbar dokumentiert hast.

Der dritte Grund ist Selbstdisziplin. Wer für jede Aktion eine Justification tippen muss, überlegt zweimal, ob er gerade in der Produktion oder im Testsystem unterwegs ist. Das senkt die Fehlerquote im Tagesgeschäft.

Kurz sind die Aktivierungsdauern (1 bis 2 Stunden) und entsprechend hart die Authentifizierungs-Anforderungen mit FIDO2 oder Windows Hello for Business als Pflicht.

Den Hybrid Identity Administrator haben viele nicht auf dem Radar, weil die Rolle harmlos klingt. Sie ist es nicht. Wer Entra Connect oder Cloud Sync kontrolliert, kontrolliert die On-Prem-Brücke und damit potenziell die gesamte Identity-Pipeline. Eine kompromittierte Sync-Engine kann Passwörter umschreiben, Gruppen manipulieren oder Privileged Accounts mit Backdoor-Attributen versehen.

Beim Security Administrator habe ich bewusst FIDO2 statt klassischer App-MFA gewählt, weil die Rolle Defender-Policies, Identity Protection und Secure Score steuert. Wer das deaktivieren kann, schaltet die Detection ab, bevor er den eigentlichen Angriff fährt.

Die zweite Tabelle ist der pragmatische Teil. Hier geht es um die Rollen, die du im Daily Business brauchst, vom User-Onboarding bis zur Exchange-Mailbox-Konfiguration. Justification, MFA und Logging reichen hier in der Regel aus.

Die Aufteilung folgt einer einfachen Logik: Je breiter der Wirkbereich der Rolle, desto kürzer die Aktivierungsdauer. Ein Exchange Administrator bekommt 8 Stunden, weil er typischerweise an einer konkreten Migrations- oder Troubleshooting-Aufgabe arbeitet, die einen halben Arbeitstag dauern kann. Ein User Administrator bekommt nur 4 Stunden, weil User-Manipulation in der Regel punktuelle Aktionen sind und längere Aktivierungen nur unnötig Angriffsfläche schaffen.

Reader-Rollen bekommen großzügige 8 Stunden, weil sie keinen Schaden anrichten können und du den Global Reader oder Security Reader oft als Hintergrund-Tab beim Troubleshooting offen hast. Justification ist hier optional, weil reines Lesen kein Audit-Event rechtfertigt, das jedes Mal eine Begründung erfordert.

Die Aktivierungsdauer ist nur die halbe Miete. Die andere Hälfte sind die Notification- und Assignment-Einstellungen, die du einmal pro Rolle konfigurierst und danach vergisst.

Permanent Active Assignments sind in dieser Konfiguration komplett verboten. Das ist die zentrale Härtungs-Entscheidung. Wenn du eine Rolle dauerhaft brauchst, machst du sie Eligible mit langer Aktivierungsdauer, nicht Active. Die einzige Ausnahme sind die Break-Glass-Accounts, die per Definition außerhalb der PIM-Logik stehen, weil sie bei einem MFA- oder Conditional-Access-Ausfall den letzten Zugang zum Tenant darstellen.

Permanent Eligible mit jährlichem Access Review sorgt dafür, dass alte Eligible-Zuweisungen, die nach Projektende vergessen wurden, automatisch auf den Tisch kommen. Das ist gleichzeitig der Audit-Nachweis für „Need-to-know" und „Need-to-have", den ISO 27001 explizit fordert.

Ein Detail, das oft übersehen wird: PIM lässt sich mit Conditional Access Auth Contexts verknüpfen. Damit erzwingst du beim Activation-Request zusätzlich Compliant Device und phishing-resistente MFA, unabhängig davon, womit der User beim ursprünglichen Login angekommen ist.

Konkret heißt das: Selbst wenn jemand mit gültigem Refresh Token, aber ohne Compliant Device PIM aktivieren will, schlägt die Aktivierung am CA-Auth-Context fehl. Für die kritischen Rollen aus der ersten Tabelle ist das Pflicht, für die Tagesgeschäft-Rollen optional.

PIM auf einem Account, der parallel für Mail, Teams und private Browser-Sessions genutzt wird, verschenkt einen Großteil seiner Schutzwirkung. Jeder Admin sollte einen separaten, ausschließlich administrativen Cloud-Only-Account haben, der weder Mailbox noch Teams-Lizenz besitzt. Der reguläre Account bleibt für die normale Arbeit, der Admin-Account ist die Hülle, in die du PIM-Aktivierungen lädst.

Ein Break-Glass-Konto ist kein Notfall-Account, sondern deine Versicherung gegen deine eigenen Richtlinien. Genau dieser Unterschied wird in den meisten Tenants verwischt, und entsprechend schwach sind die Konfigurationen, die ich in Audits sehe.

Typische Fehler: Das Break-Glass nutzt dieselbe Authenticator-App wie der reguläre Admin-Account. Der Account hängt im selben Conditional-Access-Scope wie alle anderen User. Das Passwort liegt in der gleichen Vault, in der auch die regulären Admin-Credentials gespeichert sind. Die letzte erfolgreiche Anmeldung war vor acht Monaten, einen dokumentierten Test gibt es nicht. Und auf den Sign-In schaut niemand.

Jeder dieser Punkte killt die Schutzwirkung. Wenn der Authenticator des Admins kompromittiert ist, ist das Break-Glass mitkompromittiert. Wenn eine fehlerhafte CA-Policy alle Admins aussperrt, sperrt sie auch das Break-Glass aus. Wenn das Passwort in der gleichen Vault liegt wie die normalen Admin-Credentials, hilft es bei einem Vault-Kompromiss exakt nichts.

So sieht ein Break-Glass aus, das im Ernstfall trägt:

Zwei dieser Accounts gehören in den Tenant, nicht einer und auch nicht drei! Echte Redundanz heißt: Wenn der eine FIDO2-Stick im Tresor defekt ist oder ein Passwort-Lifecycle abgelaufen ist, übernimmt der zweite. Ein einzelner Break-Glass-Account ist kein Backup, sondern ein Single Point of Failure.

Der wichtigste Satz zum Schluss, weil er in der Praxis am häufigsten ignoriert wird: Wenn der Alert auf einen Break-Glass-Sign-In feuert und du nicht selbst gerade im Notfall-Szenario bist, hast du ein Problem. 

Ein Break-Glass-Account, der nicht überwacht wird, ist keine Notfall-Vorsorge, sondern eine offene Hintertür.

Ein PIM-Rollenkonzept lebt nicht von der Anzahl der eingebundenen Rollen, sondern von der Konsequenz, mit der du Standing Privileges eliminierst. Die hier gezeigte Aufteilung in „kritische Rollen" mit kurzen Aktivierungsfenstern und FIDO2-Pflicht plus „Tagesgeschäft-Rollen" mit pragmatischen 4 bis 8 Stunden funktioniert in Solo-Admin-Setups genauso wie in kleinen bis mittleren Teams ohne formelle Approver-Rollen.

Was diese Konfiguration leistet: Sie reduziert das Angriffsfenster auf Stunden statt permanent, sie erzeugt einen lückenlosen Audit-Trail, sie macht Privilege Escalation für einen Angreifer messbar aufwendiger, und sie ist in unter zwei Stunden produktiv ausgerollt. Was sie nicht leistet: Sie ersetzt keine harten Detection-Regeln in Sentinel oder Defender. PIM ist der Zugangsschutz, nicht das Monitoring. Beides muss zusammenspielen.

Wer noch keine Access Reviews konfiguriert hat, sollte mit den jährlichen Reviews der Eligible-Zuweisungen anfangen, bevor er das Konzept weiter ausbaut. Das ist der einzige Weg, wie das Rollenkonzept über Jahre nicht zur historischen Altlast verkommt. ISO-27001-Auditoren prüfen genau das, und zwar als Erstes.

PIM hat sein eigenes Vokabular. Wer ISO-27001-konform dokumentieren oder mit Auditoren reden will, sollte die folgenden Begriffe sicher verwenden können.