05Identity · Infrastructure as Code

GitOps-basierte Identity Governance

Ein Git-basierter Prozess verwaltet Entra-Zugriffspakete und Benutzerzuweisungen über Pull Requests, Infrastructure as Code und getrennte Workload-Identitäten.

Zeitraum
2026
Status
Anonymisierte Fallstudie
Meine Rolle
Security Design und End-to-End-Implementierung

01 — Ausgangslage

Problem & Kontext

Zeitlich begrenzte und genehmigungspflichtige Zugriffe sollten nachvollziehbar verwaltet werden, ohne Änderungen ausschließlich in Portalen oder mit dauerhaft privilegierten Pipeline-Zugängen durchzuführen.

Der entwickelte Prozess verbindet deklarative Zugriffspakete mit Pull-Request-Reviews und der fachlichen Genehmigung in Microsoft Entra My Access. Infrastruktur und konkrete Zuweisungen folgen dabei bewusst unterschiedlichen Berechtigungswegen.

Professionelle Rahmenbedingungen

  • Pull Requests müssen vollständig prüfbar sein, ohne dafür bereits Schreibzugriff auf die Cloud-Umgebung zu erhalten.
  • Löschungen oder Ersetzungen sicherheitsrelevanter Ressourcen dürfen nicht unbemerkt in eine reguläre Änderung geraten.
  • Benutzer müssen eindeutig aufgelöst werden; Gäste, Mehrdeutigkeiten und unvollständige Ergebnisse sind kontrolliert zu behandeln.
  • Die Synchronisierung soll wiederholbar sein und nur tatsächliche Unterschiede zwischen gewünschtem und aktuellem Zustand anwenden.

02 — Verantwortung

Meine Rolle

Ich habe den vollständigen Prozess konzipiert und umgesetzt: Sicherheits- und Berechtigungskonzept, Infrastructure as Code, Graph-Automatisierung, Validierung, Pipelines, Workload-Identitäten und Schutzmechanismen gegen destruktive Änderungen.

  1. 01Sicherheits- und Berechtigungsdesign für Infrastruktur und Synchronisierung
  2. 02Umsetzung mit Terraform, Bicep, PowerShell und Microsoft Graph
  3. 03Aufteilung in Bootstrap-, Pull-Request- und Hauptpipeline
  4. 04Least-Privilege-Trennung privilegierter und eingeschränkter Identitäten
  5. 05Validierung, Tests und Betriebsdokumentation für Änderungs- und Freigabeflüsse

03 — Umsetzung

Ansatz & Entscheidungen

Zugriffspakete und zugehörige Gruppen werden als versionierter Soll-Zustand gepflegt. Pull Requests führen ausschließlich Offline-Prüfungen aus. Erst nach Review und Zusammenführung greifen getrennte Workload-Identitäten mit jeweils begrenzten Rechten auf Infrastruktur oder Zuweisungen zu.

D01

Cloud-freie Pull-Request-Prüfung

Syntax, Referenzen und fachliche Konsistenz werden ohne Azure-Berechtigungen geprüft. Ein manipulierter Pull Request erhält dadurch weder Service Connection noch Zugriff auf Mandantendaten.

D02

Getrennte Workload-Identitäten

Eine privilegierte Identität verwaltet die Infrastruktur, während die laufende Synchronisierung nur die für Zuweisungen nötigen Rechte besitzt. Beide Aufgaben teilen weder Geheimnisse noch unnötige Berechtigungen.

D03

Destruktive Änderungen stoppen

Gespeicherte Pläne, Schutzregeln und Pipeline-Prüfungen lehnen unerwartete Löschungen oder Ersetzungen ab. Kritische Änderungen benötigen damit eine bewusste, separat nachvollziehbare Entscheidung.

D04

Idempotente Synchronisierung

Die Automatisierung vergleicht gewünschten und vorhandenen Zustand, berücksichtigt vollständige paginierte Ergebnisse und wendet nur notwendige Ergänzungen oder Entfernungen an.

04 — Technologie

Technischer Rahmen

  • Microsoft Entra ID
  • Terraform
  • Bicep
  • PowerShell
  • Microsoft Graph
  • Azure DevOps
  • Workload Identity
  • YAML
  • Azure Storage
  • Nix

05 — Rückblick

Ergebnis & Erkenntnisse

Manuelle Zugriffsänderungen wurden in einen versionierten, reviewbaren und standardmäßig destruktionssicheren Prozess mit föderierten Identitäten überführt.

Technische Änderungen bleiben im Pull Request nachvollziehbar, während die fachliche Zugriffsentscheidung weiterhin über den vorgesehenen Genehmigungsprozess erfolgt.

  • L01GitOps für Identitäten braucht eine klare Grenze zwischen technischem Soll-Zustand und fachlicher Zugriffsfreigabe.
  • L02Pull-Request-Pipelines sollten untrusted Änderungen prüfen können, ohne selbst privilegiert zu sein.
  • L03Eine einzige mächtige Pipeline-Identität ist bequem, widerspricht aber einer belastbaren Least-Privilege-Architektur.
  • L04Destruktionsschutz muss Planung, Ausführung und Ressourcenkonfiguration gemeinsam abdecken.