Policy Patterns

Warum “Patterns”?

Policies scheitern selten an der Syntax, sondern an Betrieb: Rollout, Ausnahmen, Ownership und Signal-to-Noise. Patterns helfen, wiederkehrende Governance-Ziele konsistent umzusetzen.

Pattern 1: Audit → Deny (in Wellen)

Viele Guardrails sollten nicht sofort als Deny starten.

Bewährter Ablauf:

1. Audit tenantweit oder auf Pilot-MG.
2. Findings analysieren (welche Teams/Deployments betroffen?).
3. Remediation/Migrationspfad definieren.
4. Danach Deny auf den Zielscopes aktivieren.

Das reduziert “Überraschungs-Fehler” in Pipelines erheblich.

Praktische Ergänzung: Kommuniziere konkret, was sich ändert. “Ab Datum X wird Public IP Deny” ist besser als “Wir härten Policies”.

Pattern 2: Initiative als Baseline-Paket

Statt einzelne Policies zuzuweisen, bündelst du eine Baseline als Initiative:

• gemeinsamer Parametersatz
• klare Versionierung
• ein Assignment pro Scope

Siehe dazu auch Azure Policy vs. Initiative.

Pattern 3: DeployIfNotExists für Betriebsstandards

Für Betriebsstandards (z. B. Diagnostics Settings) sind DeployIfNotExists-Policies ein guter Hebel – aber nur, wenn du den Betrieb mitdenkst:

• Remediation braucht Identitäten/Rollen.
• Rollout muss auf vorhandene Ressourcen angewendet werden (Remediation Tasks).
• DCR/AMA-Strategie muss klar sein (sonst “Logs überallhin”).

Zusätzlich wichtig:

• Prüfe, ob dein Remediation-Mechanismus in allen Subscriptions funktioniert (RBAC + Identität + Netzwerkpfade).
• Behandle Remediation wie Change: roll out, monitor, fallback.

Pattern 4: Modify für Tagging (mit Augenmaß)

Modify kann Tags erzwingen oder ergänzen. Das ist nützlich, aber gefährlich, wenn es Ownership verschleiert.

Gute Praxis:

• Nur wenige, gut definierte Pflicht-Tags.
• Klare Quelle für Tag-Werte (Pipeline/Repo/Service Catalog), nicht “Rate mal”.
• Noncompliance Message, die erklärt, wie es zu beheben ist.

Pattern 5: Exemptions statt “abschalten”

Ausnahmen passieren. Entscheidend ist, dass sie:

• begründet sind,
• einen Scope haben,
• ein Ablaufdatum besitzen,
• reviewt werden.

Exemptions sind dafür das passende Werkzeug.

Ein hilfreiches Minimum für Exemptions:

• Owner (Team/Verantwortlicher)
• Begründung (warum ist es nötig?)
• Ablaufdatum (wann wird es überprüft?)
• Scope (so klein wie möglich)

Anti-Patterns

• Eine Initiative, die “alles” enthält.
• Deny ohne Vorlauf oder ohne Dokumentation.
• Ausnahmen durch Nicht-Zuweisen: führt zu intransparenten Scopes.

Pattern 6: Schichten statt Monster-Initiativen

Wenn deine Baselines wachsen, hilft ein Schichtmodell:

• Core Baseline (überall)
• Environment Baseline (Prod strenger als Non-Prod)
• Workload Baseline (nur für bestimmte Landing Zone Typen)

Das macht Rollouts kontrollierbarer und reduziert “eine Initiative für alles”.

Nächste Schritte

• Struktur: Management Groups
• Baseline-Design: Landing Zones