Wer privilegierte Rechte in Microsoft Entra ID manuell vergibt, verliert früher oder später den Überblick. Eine Admin-Rolle bleibt länger aktiv, irgendwo kommt eine Ausnahme hinzu, und irgendwann weiß kaum jemand, wer warum worauf Zugriff hat. Eine Entgleisung mit enormen Risikopotenzial.

Microsoft Entra Privileged Identity Management (PIM) hat sich als Best Practice für den Umgang mit privilegierten Entra-Rollen etabliert. Damit lassen sich privilegierte Berechtigungen nach Bedarf und auf begrenzte Zeit vergeben: nach den Prinzipien von Least Priviledge und Just-in-Time Access.

Doch auch PIM-Konfigurationen können im Portal-Wildwuchs enden. Hier setzen wir bei shiftavenue auf Terraform (HashiCorp) als Infrastructure-as-Code-Ansatz (IaC): Statt Gruppen, Berechtigungen und Richtlinien nur per Klick zu verwalten, bilden wir den grundlegenden PIM-Sollzustand als Code ab.

Im Folgenden zeige ich das theoretische und praktische Grundgerüst eines solchen Setups: von der Terraform-Struktur über role-assignable Groups und PIM-Zuweisungen bis zu resistenten Break-Glass-Accounts und einem kontrollierten GitOps-Workflow über GitHub.

Was bringt Terraform für das PIM-Setup?

Mit diesem Ansatz lebt die PIM-Konfiguration nicht mehr nur im Portal. Änderungen am Sollzustand werden im Code versioniert, vor der Umsetzung reviewed und später mit Terraform auf Abweichungen geprüft.

Die eigentliche Aktivierung privilegierter Rollen bleibt dabei weiterhin Aufgabe von Microsoft Entra PIM.

Voraussetzungen für das PIM-Setup

Bevor wir mit der eigentlichen Terraform-Konfiguration starten, müssen ein paar Grundlagen stehen:

Tools & Lizenzen

• Lizenz: Microsoft Entra ID P2 oder Microsoft Entra ID Governance für die Nutzung von PIM.
• Terraform: Die Terraform CLI, lokal oder innerhalb der Pipeline.
• Provider: Der offizielle azuread-Provider von HashiCorp.
• Repository: GitHub für Code, Versionshistorie und später den GitOps-Workflow.
  

Pipeline-Identität und Berechtigungen

Terraform benötigt eine eigene Workload Identity mit den Graph-Berechtigungen, die für die tatsächlich verwalteten Ressourcen nötig sind. Klingt banal, ist aber einer der sensibelsten Teile des gesamten Setups. Da diese Identität selbst hochprivilegiert ist, vergeben wir keine pauschalen Rechte auf Verdacht.

Für bestimmte Operationen an role-assignable Groups ist beispielsweise RoleManagement.ReadWrite.Directory relevant.

Für GitHub Actions setzen wir auf OpenID Connect beziehungsweise Workload Identity Federation. So kommt die Pipeline ohne langlebiges Azure-Client-Secret im Repository aus und arbeitet stattdessen mit kurzlebigen Tokens.

MS Entra PIM- & Governance Setup Rollenverteilung und Funktionen

Struktur ist alles: Projektaufbau & Statefile

Ein sauberes Setup beginnt mit einer durchdachten Projektstruktur. Statt den gesamten Terraform-Code in eine riesige main.tf zu packen, teile ich die einzelnen Bereiche so auf, dass Gruppen, PIM-Zuweisungen, Policies, Emergency Access und Backend-Konfiguration getrennt voneinander nachvollziehbar und reviewbar bleiben.

Infografik: Terraform Structure und State Management

💡Mehr dazu: Rightsizing your Terraform Modules: die Live-Session meines Kollegen @Rene Schach bei den HashiDays London zu strukturierten, wartungsfreundlichen Terraform-Modulen.

Genauso wichtig ist der Umgang mit dem Terraform-Statefile. Es ist das '“Gedächtnis” von Terraform, verbindet die im Code definierten Ressourcen mit den tatsächlichen Objekten im Tenant und kann sensible Informationen enthalten.

Deshalb gehört der State auch weder ins Git-Repository noch ungeschützt auf einen lokalen Rechner. Für das Setup nutze ich Azure Blob Storage als Remote Backend. Zugriffskontrollen, Verschlüsselung und State Locking sorgen dafür, dass der State zentral geschützt wird und nicht mehrere Prozesse gleichzeitig schreibend darauf zugreifen.

Kurz gesagt:

Der Code gehört ins Repository. Der State nicht.

Entra ID Gruppen anlegen & managen

Statt privilegierte Rollen direkt einzelnen Usern zuzuweisen, verwalten wir die Berechtigung in diesem Setup über sogenannte role-assignable Groups. Die entsprechenden User werden der Gruppe hinzugefügt, während die Rollenberechtigung zentral auf Gruppenebene gesteuert wird. Das macht die Rechtevergabe übersichtlicher und vereinfacht das Lifecycle-Management.

Damit einer Gruppe eine Microsoft-Entra-Rolle zugewiesen werden kann, muss sie role-assignable sein. In Terraform erstellen wir dafür eine Sicherheitsgruppe und setzen das Flag:

assignable_to_role = true

Screenshot 1: Role-assignable Entra ID Gruppe in Terraform

Wichtig: PIM for Groups setzt nicht grundsätzlich eine role-assignable Group voraus. In diesem Setup brauchen wir diese Eigenschaft, weil die Gruppe selbst mit einer Microsoft-Entra-Rolle verknüpft wird.

PIM mit Entra ID Gruppen verknüpfen

Sobald die Gruppe steht, kommt die eigentliche PIM-Zuweisung. Mit dem azuread-Provider legen wir ein Eligible Role Assignment auf die zuvor erstellte Gruppe. Das ist die grundsätzliche Berechtigung, eine Rolle bei Bedarf temporär zu aktivieren.

Screenshot 2: PIM-Zuweisung für Entra ID Gruppe mit Terraform

Damit trennen wir zwei Dinge sauber voneinander: Terraform definiert die grundsätzliche Berechtigung. PIM steuert die tatsächliche Aktivierung.

Das Sicherheitsnetz: Break-Glass-Accounts mit Terraform

Was passiert, wenn PIM ausfällt, der reguläre Authentifizierungsweg gestört ist oder unsere CI/CD-Pipeline bricht? Für diese Szenarien brauchen wir Break-Glass-Accounts, also echte Notfall-Admins.

Auch diese bilden wir soweit sinnvoll über Terraform in unserer breakglass.tf ab. Die Accounts werden bewusst nicht über PIM gesteuert, sondern erhalten eine permanente Rollenzuweisung als Global Administrator. Microsoft empfiehlt dafür mindestens zwei unabhängige Accounts.

Für ein belastbares Sicherheitsnetz orientieren wir uns an den Microsoft-Empfehlungen für Emergency Access:

Redundanz & Domänenwahl: Wir legen mindestens zwei unabhängige Emergency-Access-Accounts an. Diese sind cloud-only, verwenden die ursprüngliche *.onmicrosoft.com-Domain und hängen weder von lokaler Synchronisierung noch externer Federation ab. Fällt der reguläre Authentifizierungsweg aus, bleibt damit ein unabhängiger Zugang bestehen.

Exklusion von blockierenden Richtlinien: Die Accounts müssen von Conditional-Access-Policies ausgenommen werden, die ihre Anmeldung im Notfall blockieren oder einschränken könnten. Das betrifft je nach Setup auch risikobasierte Conditional-Access-Regeln.

Wir nutzen Terraform also, um Account-Objekte, permanente Rollen und definierte Policy-Ausnahmen im Code zu verankern. Die eigentlichen Zugangsdaten erzeugen wir dagegen bewusst außerhalb dieser Terraform-Konfiguration und legen sie geschützt ab, beispielsweise in einem Azure Key Vault.

Der Grund dafür bleibt wichtig, braucht aber etwas Präzision: Sensible Werte können im Terraform-State oder Plan-Dateien landen. Neuere Terraform-Versionen bieten mit Ephemeral Values und Write-only Arguments Möglichkeiten, bestimmte Werte davon auszunehmen. Das klappt allerdings nur, wenn die jeweilige Ressource und der Provider diese Mechanismen unterstützen.

Für den absoluten Worst Case reicht eine reine Cloud-Ablage ohnehin nicht aus.

Resilience-Hinweis: Sollte die Identity-Infrastruktur selbst nicht mehr erreichbar oder vertrauenswürdig sein, braucht es einen unabhängigen Weg zurück in den Tenant. Hier setzen wir auf phishing-resistente Authentifizierungsmethoden wie FIDO2-Security-Keys. Mindestens einer dieser Keys gehört zusammen mit den notwendigen Notfall-Informationen komplett offline an einen geschützten Ort - im Zweifel tatsächlich in einen physischen Safe.

Besonders wichtig für die Governance: Break-Glass-Accounts sind nicht für den Arbeitsalltag gedacht. Jede Anmeldung sollte deshalb ein sofortiges, hochpriorisiertes Alerting auslösen (etwa via E-Mail, SMS oder im SIEM/SOC). Zusätzlich prüfen wir regelmäßig, ob die Accounts im Ernstfall noch funktionieren; Microsoft empfiehlt eine Validierung mindestens alle 90 Tage.

Der „Immutable“-Ansatz: PIM-Management via GitHub

Jetzt kommt die Magie: Wir behandeln unser PIM-Setup im GitOps-Sinne als „immutable“. Änderungen am definierten Sollzustand sollen über Code und nicht spontan über das Entra-ID-Portal laufen.

Technisch blockiert Entra ID manuelle Portal-Änderungen allerdings nicht. Deshalb ergänzen wir den Ansatz um Drift Detection: Ein regelmäßig laufender terraform plan, der die mit Terraform verwalteten Ressourcen mit unserem definierten Sollzustand abgleicht. Manuelle Abweichungen werden damit spätestens beim nächsten Lauf sichtbar.

Durch die Anbindung an GitHub und GitHub Actions entsteht daraus unser GitOps-Workflow:

1. Ein Kollege oder Gruppe benötigt künftig Eligibility für eine neue Admin-Rolle. Die Änderung wird in einem eigenen Branch im Terraform-Code vorbereitet.
2. Daraus entsteht ein Pull Request.
3. Die GitHub Action führt terraform plan aus und stellt das Ergebnis direkt im Pull Request für das Review bereit.
4. Ein Senior Admin oder Security-Beauftragter prüft den Code nach dem Vier-Augen-Prinzip und gibt den Request frei.
5. Beim Merge in den main-Branch läuft terraform apply und die freigegebene Änderung wird in Entra ID umgesetzt.

Damit dieser Prozess nicht nur auf freiwilliger Disziplin beruht, lassen sich für den main-Branch verpflichtende Reviews und Status Checks durchsetzen. Für das eigentliche Deployment kann zusätzlich eine geschützte GitHub-Umgebung verhindern, dass die Person, die eine Änderung angestoßen hat, ihr eigenes Deployment freigibt.

Praxis-Tipp für den Notfall (On-Call):

Häufig kommt die Frage auf: „Was passiert, wenn ich nachts im IT-Bereitschaftsdienst einen kritischen Incident habe und sofort Admin-Rechte brauche? Wer genehmigt mir dann mitten in der Nacht meinen Pull Request?“

On-Call um 3 Uhr, und der Approver schläft.

Die Antwort beruhigt: Niemand muss das tun.

Für die Rollenaktivierung braucht es keinen neuen Pull Request.

Über den GitOps-Workflow steuern wir ausschließlich die grundsätzliche Berechtigung, also die Eligibility. Ist das Team oder die On-Call-Gruppe einmal via Code dafür freigeschaltet, aktivieren die Engineers ihre Rolle im Ernstfall (auch nachts) über das reguläre Entra-ID-PIM-Portal (inkl. MFA und Begründung). Das läuft ganz ohne Codeänderung, Git-Interaktion oder Pipeline-Wartezeit.

Welche Schritte dabei erforderlich sind, hängt von der jeweiligen PIM-Richtlinie ab. Neben MFA und Begründung können beispielsweise auch eine Ticketnummer oder die Freigabe durch einen definierten Approver verlangt werden.

GitHub und Terraform kommen erst wieder ins Spiel, wenn sich die grundsätzliche Berechtigungsstruktur ändern soll.

Natürlich lässt sich dieser Ansatz auch in bestehende ITSM-Prozesse mit Jira oder ServiceNow integrieren. Das Change-Management läuft dann über das jeweilige Drittsystem, während die Freigabe aus Schritt 4 mit dem bestehenden Change-Prozess verknüpft werden kann.

Fazit: Das Fundament für ganzheitliches Entra-Hardening

Mit diesem Setup haben wir PIM nicht nur strukturiert als Code abgebildet, sondern auch einen nachvollziehbaren Änderungsprozess über GitHub beziehungsweise das angebundene Change-Management geschaffen. Die tatsächlichen Rollenzuweisungen und Aktivierungen bleiben weiterhin in Microsoft Entra nachvollziehbar.

Dabei ist PIM erst der Anfang. Wenn zentrale Teile der Identity-Infrastruktur einmal als Code definiert sind, lässt sich das Entra ID Hardening schrittweise erweitern.

Über dieselbe Terraform-Basis können je nach Setup etwa folgende Bereiche hinzukommen:

• Conditional Access Policies: Richtlinien für bedingten Zugriff versioniert und reviewbar ausrollen. Der azuread-Provider unterstützt sie direkt.
• Risikobasierter Conditional Access: User- und Sign-in-Risiken aus Microsoft Entra ID Protection können direkt in Conditional-Access-Policies einfließen. Das ist auch langfristig der relevante Weg: Microsoft stellt die bisherigen Legacy-Risikorichtlinien in Entra ID Protection zum 1. Oktober 2026 ein.
• Administrative Units: Administrative Zuständigkeiten innerhalb des Tenants gezielt voneinander abgrenzen. Administrative Units lassen sich ebenfalls über den azuread-Provider verwalten.
• App Registrations & Enterprise Applications: Applications und Service Principals standardisiert als Code verwalten.

Nicht nur für Microsoft: Die Prinzipien hinter Infrastructure as Code, GitOps und versionierter Governance sind nicht auf Entra ID beschränkt. Entscheidend ist, ob die jeweilige Plattform eine geeignete API beziehungsweise einen belastbaren Terraform-Provider bereitstellt. Für diesen Beitrag habe ich bewusst Microsoft Entra ID als Praxisbeispiel gewählt.

Wollt ihr dieses Konzept in eurer eigenen Umgebung praktisch aufbauen? In unserem Terraform-IaC-Workshop entwickeln wir gemeinsam mit eurem Team eine produktionsreife Terraform-Basis, die anschließend eigenständig weitergeführt werden kann.