Management Groups
Zweck von Management Groups
Section titled “Zweck von Management Groups”Management Groups (MGs) sind das Struktur- und Delegationsrückgrat für Azure in größeren Tenants:
- Governance-Vererbung: Policies und RBAC vererben sich nach unten.
- Trennung von Verantwortlichkeiten: Plattformteams können Guardrails auf MG-Ebene setzen, ohne jede Subscription einzeln anzufassen.
- Skalierung: Subscription-Wachstum bleibt steuerbar.
Ein bewährtes Zielbild
Section titled “Ein bewährtes Zielbild”Eine gute MG-Struktur ist nicht “tief” – sie ist aussagekräftig. Typische Achsen:
- Umgebung: Prod vs. Non-Prod (oder “Platform” vs “Workload”)
- Landing Zone Typen: z. B. “Corp” (mit zentralem Egress/Inspection) und “Online” (internet-facing)
- Sonderfälle: Sandbox, Decommission, Policy-Testing
Das Ziel ist, dass du Policies/Assignments und RBAC an wenigen, stabilen Knoten anbringen kannst.
Beispiel-Struktur (lesbar statt perfekt)
Section titled “Beispiel-Struktur (lesbar statt perfekt)”Ein grobes, praxistaugliches Beispiel:
- Tenant Root
- Platform
- Connectivity
- Management
- LandingZones
- Corp
- Prod
- NonProd
- Online
- Prod
- NonProd
- Corp
- Sandbox
- Platform
Wichtig ist nicht die exakte Form, sondern dass sie deine Betriebsrealität abbildet: Wer owned was, und wo willst du Guardrails zentral setzen?
Tenant Root Management Group: mit Vorsicht
Section titled “Tenant Root Management Group: mit Vorsicht”Der Tenant Root ist die Wurzel der Vererbung. Gute Praxis:
- Nur sehr wenige Personen haben Owner/Contributor dort (typisch über PIM).
- Baseline-Guardrails können dort liegen, aber nur wenn sie wirklich tenantweit gelten.
Wenn du zu viel auf Root-Ebene setzt, wird jede Ausnahme später teuer.
Delegation und RBAC
Section titled “Delegation und RBAC”Ein praktikables Pattern:
- Plattformteam: Policy/RBAC-Rechte auf MG-Ebene, aber privilegiert über PIM.
- Workload-Teams: Rechte in “ihren” Subscriptions/RGs, nicht auf MG.
Merksatz: MGs sind für Governance, nicht für Tagesgeschäft.
Subscription Placement und Lifecycle
Section titled “Subscription Placement und Lifecycle”Definiere klare Regeln:
- Wo landen neue Subscriptions (Prod/Non-Prod)?
- Wer darf Subscriptions zwischen MGs verschieben (und wie wird das auditiert)?
- Was passiert mit stillgelegten Subscriptions (Quarantäne-MG)?
Ein häufiges Problem ist “Subscription Drift”: Subscriptions wandern ohne Prozess, Policies wirken plötzlich anders.
Praktische Konsequenz: Das Verschieben einer Subscription ist eine Governance-Änderung. Plane daher:
- Change-Prozess (wer darf verschieben, wie wird dokumentiert?)
- technische Nachwirkungen (Policies, RBAC-Vererbung, Deployments)
- ein “Quarantäne”-Ziel für Sonderfälle (z. B. bei Incident/Containment)
Stolperfallen
Section titled “Stolperfallen”- Zu viele Ebenen: Komplexität steigt, Nutzen sinkt.
- MGs als Org-Chart: Teams ändern sich häufiger als Governance-Ziele.
- Fehlende Policy-Strategie: MG-Struktur ohne klare Baselines ist nur Deko.