Überblick
Diese Referenzimplementierung zeigt ein Governance-Modell für den Zugriff auf Azure-Ressourcen auf Enterprise-Niveau. Die Architektur kombiniert gruppenbasiertes RBAC, Privileged Identity Management (PIM) und durch Azure Policy erzwungene Sicherheitsrichtlinien.
Hochprivilegierte Rollen besitzen keine dauerhaften Berechtigungen. Stattdessen erfolgt die Nutzung über zeitlich begrenzte Just-in-Time-Aktivierungen mit klar definierten Genehmigungsprozessen.
Die gesamte Infrastruktur wird als Code mit Terraform definiert und über eine kontrollierte CI/CD-Pipeline mit Approval Gates für RBAC-Änderungen bereitgestellt.
Kontext
Mit wachsender Azure-Landschaft geraten viele Unternehmen beim Thema Zugriffsverwaltung unter Druck. Direkte Benutzer-zu-Rollen-Zuweisungen nehmen zu, dauerhafte Owner-Rechte werden zur Normalität und Richtlinien werden oft nur manuell überprüft. Dadurch wächst die potenzielle Schadensfläche bei kompromittierten Accounts.
Dieses Projekt simuliert eine typische Governance-Modernisierung: Der Übergang von ad-hoc Zugriffsstrukturen zu einem Modell, in dem privilegierte Zugriffe zeitlich begrenzt, genehmigungspflichtig und technisch durchgesetzt werden.
Architektur
Die Implementierung basiert auf einer mehrschichtigen Governance-Architektur aus Management Groups, Custom Roles, gruppenbasierten RBAC-Zuweisungen und Azure Policy.
Die Management-Group-Hierarchie trennt Plattform-Infrastruktur (Identity, Connectivity) von Application Landing Zones (Prod, NonProd). Dadurch lassen sich unterschiedliche Governance-Regeln anwenden: Plattform-Teams arbeiten mit PIM-berechtigten Rollen, während Anwendungsteams aktive Berechtigungen auf Resource-Group-Ebene erhalten.
RBAC folgt konsequent einem gruppenbasierten Modell. Es existieren keine direkten Benutzer-zu-Rollen-Zuweisungen. Alle Zugriffe erfolgen über Entra ID Security Groups. Das vereinfacht Access Reviews und schafft eine zentrale Steuerungsebene für Mitgliedschaften.
Custom Roles implementieren das Prinzip der minimalen Rechte für CI/CD-Pipelines. Die Rolle CR-AppDeployer erlaubt Infrastruktur-Deployments (ARM Templates, Ressourcenerstellung, Zugriff auf Key Vault Secrets), verbietet jedoch kritische Aktionen wie Rollenvergabe oder das Löschen von Resource Groups. Dadurch wird eine Privilege Escalation durch Service Principals verhindert.
Azure Policy stellt präventive und detektive Kontrollen bereit. Eine Deny-Policy blockiert Owner-Zuweisungen auf Subscription-Ebene und erzwingt stattdessen PIM auf Management-Group-Ebene. Audit-Policies überwachen dauerhafte privilegierte Rollen, während Tag-Policies Governance-Metadaten auf Resource Groups sicherstellen.
Die PIM-Konfiguration unterscheidet zwischen Rollen und Personas. Owner-Rollen für Plattform-Teams erfordern Genehmigungen und sind zeitlich auf zwei Stunden begrenzt. Contributor-Rollen erlauben kürzere Aktivierungsfenster mit weniger Genehmigungsaufwand. Externe Berater erhalten kürzere Eligibility-Zeiträume als interne Mitarbeiter. Aktivierungen erzwingen MFA und eine Begründung.
Repository Struktur
Das Repository ist entlang der Governance-Schichten organisiert und nicht nach technischen Services.
management-groups/– Definition der Management-Group-Hierarchiecustom-roles/– Definition minimaler Custom Rolesrbac/– gruppenbasierte Rollen-Zuweisungen und Scopespim/– PIM Eligible Role Assignments und Aktivierungsrichtlinienpolicies/– Azure Policy Definitionen und Assignmentspipeline/– CI/CD Pipeline für kontrollierte RBAC-Änderungendocs/– ergänzende Dokumentation und Architekturhinweise
Diese Struktur spiegelt typische Änderungsmuster wider: Management Groups ändern sich selten, Custom Roles gelegentlich, RBAC-Zuweisungen häufiger im Zuge von Team- oder Projektänderungen.
CI/CD Design
Die Pipeline implementiert einen kontrollierten Workflow für sicherheitsrelevante RBAC-Änderungen.
Die Validierungsphase führt Terraform-Formatprüfungen, Sicherheitschecks und Modulvalidierungen durch. Dadurch werden Konfigurationsfehler früh erkannt.
In der Plan-Phase werden Terraform-Plans für die verschiedenen Governance-Module erzeugt. Änderungen an RBAC-Zuweisungen werden im Plan klar sichtbar dargestellt, damit Reviewer Privilegänderungen gezielt prüfen können.
Ein manuelles Approval Gate erfordert eine Freigabe durch Security- und Plattform-Verantwortliche. Dabei wird geprüft, ob Privilegien eskaliert werden, Scopes verändert wurden oder Änderungen mit genehmigten Tickets übereinstimmen.
Die Apply-Phase führt die Module in Abhängigkeitsreihenfolge aus: zuerst Management Groups, anschließend Custom Roles, danach RBAC-Zuweisungen und zuletzt Policies. Die Pipeline verwendet die zuvor erzeugten Plan-Artefakte, um sicherzustellen, dass exakt die geprüften Änderungen umgesetzt werden.
Die Authentifizierung der Pipeline erfolgt über Workload Identity Federation statt über statische Service-Principal-Secrets. Terraform State wird in Azure Storage mit aktivierter Versionierung gespeichert.
Infrastructure as Code Struktur
Die Terraform-Module sind nach Änderungsfrequenz und potenzieller Schadenswirkung getrennt.
Management Groups bilden die relativ stabile Basis der Plattformstruktur. Custom Roles ändern sich gelegentlich, während RBAC-Zuweisungen häufiger angepasst werden, wenn sich Teams oder Projekte verändern. Policies entwickeln sich mit Governance-Anforderungen weiter.
Jedes Modul besitzt ein eigenes Terraform State File. Dadurch können Module unabhängig geplant und deployt werden und Lock-Konflikte werden reduziert.
Der Remote State liegt in Azure Storage mit Blob-Lease-Locking. Backend-Konfigurationen werden zur Laufzeit in der Pipeline injiziert.
Variablen trennen statische Konfiguration (Management-Group-Namen, Rollen-Definitionen) von dynamischen Eingaben wie Subscription-IDs.
Sicherheitsmodell
Die Architektur implementiert mehrere Sicherheitsebenen.
Hochprivilegierte Rollen besitzen keine dauerhaften Berechtigungen. Owner- und Contributor-Rollen auf Plattform-Ebene sind ausschließlich als PIM-Eligible Assignments konfiguriert.
Gruppenbasierter Zugriff verhindert Rollen-Sprawl. Azure Policy überwacht direkte Benutzer-zu-Rollen-Zuweisungen.
Custom Roles beschränken Automatisierungsidentitäten. CI/CD-Service-Principals dürfen keine Rollen vergeben oder Autorisierungsrichtlinien ändern. Sie können weder Resource Groups löschen noch Netzwerktopologien verändern.
Präventive Policies blockieren kritische Muster. Owner-Zuweisungen auf Subscription-Ebene werden unterbunden.
Ein Break-Glass-Account ermöglicht Notfallzugriff. Die Zugangsdaten werden außerhalb der Azure-Umgebung gespeichert und jeder Zugriff gilt als sicherheitsrelevantes Ereignis.
Terraform State in Kombination mit Pipeline-Freigaben erzeugt eine nachvollziehbare Audit-Historie für RBAC-Änderungen.
Engineering Überlegungen
Mehrere Designentscheidungen orientieren sich an realen Betriebsanforderungen.
Anwendungsteams erhalten Contributor-Rechte auf Resource-Group-Ebene statt PIM-basierter Aktivierung. Dadurch wird Deployment-Reibung vermieden, während gleichzeitig Isolation zwischen Teams erhalten bleibt.
Security-Teams erhalten spezialisierte Custom Roles mit gezielten Lesezugriffen für Compliance-Prüfungen.
Eligibility-Zeiträume in PIM balancieren Sicherheitsanforderungen und operativen Aufwand. Interne Mitarbeiter erhalten längere Zeiträume, externe Berater kürzere.
Pipeline Approval Gates stellen sicher, dass RBAC-Änderungen strukturiert geprüft werden.
Erkenntnisse
- Gruppenbasiertes RBAC vereinfacht Access Reviews erheblich
- PIM-Workflows benötigen klar definierte Approver und SLAs
- Custom Roles reduzieren das Risiko von Privilege Escalation in CI/CD
- Deny-Policies sind zuverlässiger als reine Audit-Kontrollen
- Terraform kombiniert mit Pipeline-Freigaben schafft nachvollziehbare Governance
- Resource-Group-Scopes reduzieren den Bedarf an PIM für Anwendungsteams
- Break-Glass-Accounts müssen außerhalb der Plattform gespeichert werden
Scope
Dieses Projekt ist eine fokussierte Referenzimplementierung zur Demonstration von Governance-Mustern, PIM-Integration und Infrastructure-as-Code-basiertem Access Management.
Es handelt sich nicht um eine vollständige Produktionsplattform. Monitoring-Dashboards, automatisierte Access Reviews oder ITSM-Integrationen sind bewusst nicht Bestandteil der Implementierung.
Der Fokus liegt auf wiederverwendbaren Architekturmustern: keine dauerhaften Privilegien, gruppenbasiertes RBAC, minimal privilegierte Automatisierungsidentitäten, Policy-Guardrails und kontrollierte RBAC-Änderungen über CI/CD.