Noch vor einigen Jahren war es in vielen Microsoft-365-Tenants üblich, dass mehrere Personen dauerhaft globale Administrationsrechte besaßen. Ich kenne Tenants, in denen gleich mehrere Accounts (manchmal sogar Service-Accounts) permanent Global Admin waren, oft mit schwachen Passwörtern oder schlicht aus Bequemlichkeit. Mit dem heutigen Stand von Microsoft Entra ID Governance hat sich diese Sichtweise zum Glück grundlegend geändert. Dauerhafte Berechtigungen gelten inzwischen als erhebliches Risiko, und Privileged Identity Management (PIM) hat sich in der Praxis bewährt, um genau dieses Problem in den Griff zu bekommen.

Just-in-Time-Berechtigungen ersetzen dauerhafte Admin-Rechte

Hinter PIM steht für mich ein einfacher Grundsatz. Niemand soll erhöhte Berechtigungen länger behalten als nötig. Admin-Rollen werden deshalb als „eligible“ zugewiesen, und die berechtigten Personen aktivieren sie bei Bedarf für einen festgelegten Zeitraum. An diese Aktivierung sind immer Bedingungen geknüpft. In der Regel verlangt man eine Multi-Faktor-Authentifizierung (MFA) und eine kurze Begründung, teilweise auch die ausdrückliche Genehmigung durch einen weiteren Admin. Angenehm finde ich, dass sich diese Anforderungen sehr fein pro Rolle und sogar für einzelne Gruppen festlegen lassen. In sensiblen Projekten habe ich zum Beispiel für Exchange-Admins eine tägliche Zugriffsüberprüfung aktiviert, während für die Aktivierung der User-Admins weiterhin MFA und eine Begründung genügen. Alle diese Details legt man in den PIM-Rolleneinstellungen fest.

PIM für Gruppen schafft Flexibilität, bringt aber eigene Risiken mit

Vielen ist gar nicht bewusst, dass PIM seit einiger Zeit auch für Sicherheitsgruppen und Microsoft-365-Gruppen zur Verfügung steht und nicht mehr auf die klassischen Entra-ID-Rollen beschränkt ist (PIM for Groups). Man kann also „eligible“ Mitgliedschaften oder sogar den Gruppenbesitz vergeben, die ebenfalls erst bei Bedarf aktiviert werden. Das passt hervorragend zu Szenarien, in denen etwa ein Support-Team für begrenzte Zeit Zugriff auf bestimmte Ressourcen braucht. Bei dynamischen Gruppen ist allerdings Vorsicht geboten, denn dort entstehen leicht verschachtelte Berechtigungsketten. Die nehme ich in Access Reviews regelmäßig unter die Lupe.

Im Alltag ist eine Rolle in wenigen Schritten aktiviert

In der Praxis ist das Aktivieren einer Rolle oder Gruppenmitgliedschaft denkbar einfach. Der berechtigte Nutzer wählt im Entra-Portal die gewünschte Rolle aus, gibt eine Begründung ein (z. B. „User-Provisionierung für Projekt X“), durchläuft die MFA und wartet – sofern konfiguriert – auf die Genehmigung eines Kollegen. Erst danach greifen die erweiterten Berechtigungen, und zwar nur für das vorgegebene Zeitfenster. Der gesamte Ablauf ist auditierbar und wird im Azure-Log dokumentiert. Ich habe gute Erfahrungen damit gemacht, die Anforderungen an die Aktivierung schrittweise zu verschärfen, vor allem sobald erste Incidents oder „Fast-Track“-Umgehungsversuche auftauchen.

Die folgende Grafik zeigt schematisch, wie eine typische Just-in-Time-Aktivierung mit PIM abläuft:

flowchart TD
  Start["Start: Nutzer mit eligible Rolle"] --> Antrag["Aktivierung beantragen"]
  Antrag --> MFA["MFA durchführen"]
  MFA --> Begründung["Begründung eingeben"]
  Begründung --> Genehmigung["Genehmigung (sofern nötig)"]
  Genehmigung --> Aktiv["Rolle aktiv"]
  Aktiv --> Ablauf["Ablauf nach Zeitfenster"]
  Ablauf --> Ende["Rolle inaktiv"]

Abbildung: Just-in-Time-Aktivierung einer privilegierten Rolle mit PIM

Die Möglichkeit, die Anforderungen je Rolle abzustufen, wird in vielen Projekten gern genutzt. Für besonders kritische Rollen wie Global Admin setze ich praktisch immer eine Genehmigung voraus. Weniger kritische Admins kommen meist mit MFA und einer Begründung aus.

Bei der Einführung tauchen immer wieder dieselben Stolperfallen auf

In der Einführungsphase begegnen mir häufig diese Probleme:

  • Zu viele Personen erhalten „eligible“ Rollen, ohne dass es dafür einen echten Bedarf gibt.
  • Die Aktivierungsanforderungen sind zu lasch oder kaum nach Rollen unterschieden.
  • Niemand überprüft die Zuweisungen regelmäßig (Access Reviews).
  • Beim Umstieg denkt keiner an die Notfall-Accounts.

Mein Tipp aus der Praxis:

Fang mit einem kleinen Kreis vertrauenswürdiger Admins an und hol dann nach und nach alle übrigen privilegierten Accounts in PIM – niemals alles auf einmal! Notfall-Accounts für den Katastrophenfall bleiben grundsätzlich permanent, werden aber streng überwacht und dokumentiert.

Ein Big Bang ist bei der Umstellung auf PIM fehl am Platz. In Workshops lege ich die Prioritäten gern gemeinsam mit den Verantwortlichen fest. Zuerst migrieren wir die Global Admins, danach die rollenbasierten Admins (Exchange, SharePoint, Security) und ganz zum Schluss die spezialisierten Anwendungs-Admins. Notfall-Accounts wie der „Break Glass“-Admin bleiben dauerhaft bestehen, sind aber besonders geschützt – mit strengen Richtlinien, langen Passwörtern, MFA, Monitoring und festgelegten Abläufen für den Ausnahmefall.

PIM protokolliert jede Aktivierung und macht Auffälligkeiten sichtbar

Einen großen Vorteil von PIM sehe ich in der Transparenz. Jede Aktivierung, jede Änderung an den Rolleneinstellungen und jeder Umgehungsversuch landet zentral im Protokoll. Mit Alerts lassen sich ungewöhnliche Aktivitäten sofort melden, etwa wenn ein User auffällig oft Admin-Rechte aktiviert oder mehrere Rollen gleichzeitig anfordert. Auf Access Reviews verzichte ich grundsätzlich nicht, weil ich damit regelmäßig prüfe, ob alle „eligible“ Zuweisungen tatsächlich noch gebraucht werden. Wer die Überwachungsprotokolle an einen Log-Analytics-Workspace weiterleitet (Entra Admin Center → Identität → Überwachung und Integrität → Diagnoseeinstellungen, Kategorie „AuditLogs“), kann die PIM-Aktivierungen im Workspace unter Protokolle mit KQL auswerten, zum Beispiel so:

AuditLogs
| where LoggedByService == "PIM"
| where OperationName == "Add member to role completed (PIM activation)"
| extend Benutzer = tostring(InitiatedBy.user.userPrincipalName), Rolle = tostring(TargetResources[0].displayName)
| summarize Aktivierungen = count() by Benutzer, Rolle

Im Alltag nutze ich solche Dashboards, um auffällige Muster zu erkennen und die Verantwortlichen gezielt darauf anzusprechen. Als Grundlage für eigene Alert-Policies eignet sich die Microsoft-Dokumentation zu PIM gut.

Kontrollierte Zugriffsfenster lösen die Dauer-Admins ab

Für mich gehört die konsequente Einführung von PIM in Entra ID zu den wirksamsten Maßnahmen, mit denen sich das Risiko in Microsoft-365-Umgebungen deutlich senken lässt. In fast allen Tenants, die ich begleite, gibt es nach der Umstellung weniger „Zugriffsleichen“, und es ist viel klarer, wer wann und warum Berechtigungen erhalten hat. Fertig ist man damit allerdings nie. Rollenzuweisungen und Aktivierungsanforderungen sollten regelmäßig überprüft und an neue Bedrohungslagen angepasst werden. Keine Kompromisse mache ich bei den Notfall-Accounts. Sie gehören immer in ein eigenes, strenges Kontrollregime, auch wenn alle anderen Admins längst mit PIM arbeiten.