Azure Policy vs. Initiative

Kurzdefinition

• Azure Policy: Eine einzelne Regel, die Ressourcen bewertet (Audit), verhindert (Deny) oder bei Bedarf korrigiert (DeployIfNotExists/Modify).
• Initiative (Policy Set Definition): Bündel mehrerer Policies inkl. gemeinsamer Parameter/Versionierung. Du weist dann das Set zu, nicht jede Policy einzeln.

Der Unterschied ist weniger technisch als organisatorisch: Initiativen sind der Hebel, um Governance als Produkt zu betreiben.

Wann eine einzelne Policy reicht

Eine einzelne Policy ist sinnvoll, wenn:

• das Thema klar abgegrenzt ist (z. B. “Public IPs verbieten”),
• du sie nur auf wenigen Scopes brauchst,
• Parameter und Ausnahmen minimal sind,
• keine Roadmap absehbar ist (also keine wachsende Sammlung verwandter Policies).

Typische Beispiele:

• Audit/deny auf einzelne Ressourcentypen
• Namenskonventionen für eine begrenzte Workload

Wann du besser eine Initiative baust

Eine Initiative ist fast immer die bessere Wahl, wenn:

• mehrere Policies zusammen ein Kontrollziel abdecken (“Baseline”),
• du konsistente Parameter über mehrere Policies hinweg willst (Regionen, Allowed SKUs, Tag-Namen),
• du Governance iterativ ausrollst (Versionen, Staging, Rollback),
• du Reporting/Compliance für ein Thema als Paket sehen willst.

Praktischer Nutzen:

• ein Assignment statt vieler
• ein Parameter-Set (z. B. allowedLocations, requiredTags)
• verständliche Produktgrenzen (“Landing Zone Baseline”, “Network Baseline”)

Design: Initiative als “Baseline-Paket”

Ein bewährtes Strukturprinzip ist eine Initiative pro Baseline, z. B.:

• lz-baseline-core
• lz-baseline-network
• lz-baseline-security

Je Baseline:

• möglichst wenige, gut dokumentierte Parameter
• klare Owner/Review-Prozesse
• definierte Ausnahmen (Exemptions) statt “Policy ausschalten”

Ein konkretes Beispiel (Baseline-Schnitt)

Eine Initiative ist am wertvollsten, wenn sie ein klares Kontrollziel abgrenzt. Beispiel für eine “Core Baseline” (vereinfachte Darstellung):

• Standort/Regionen: nur definierte Regionen zulassen
• Tags: Pflicht-Tags erzwingen/ergänzen (Owner, Cost Center, Environment)
• Public Exposure: Public IPs/DNS nach Regelwerk einschränken
• Diagnostics: zentrale Diagnostics Settings/DCR ausrollen

Wichtig ist der Zuschnitt: Eine Baseline sollte nicht gleichzeitig Netzwerk-Topologie, Security Center Einstellungen und App-spezifische Konventionen abdecken. Wenn Teams regelmäßig Ausnahmen brauchen, ist das ein Signal für zu breite Baselines oder falsche Scopes.

Parameter als Vertrag

Gute Initiativen haben einen kleinen, stabilen Parametersatz, der wie ein Vertrag behandelt wird. Ein praktikables Muster:

• allowedLocations: Liste, um Deployments planbar zu halten
• tagNames: feste Tag-Keys (nicht pro Team variabel)
• diagnosticsWorkspaceId: zentrale Ziel-IDs (wenn zentral geloggt wird)

Wenn du Parameter häufig änderst, ist oft nicht die Initiative das Problem – sondern die fehlende Versionierung/Kommunikation im Rollout.

Versionierung und Breaking Changes

Initiativen werden schnell “Plattform-API”. Das sollte sich im Betrieb spiegeln:

• Versioniere Baselines (z. B. SemVer oder datumsbasiert) und halte Release Notes kurz fest.
• Definiere, was ein Breaking Change ist (z. B. Wechsel Audit→Deny, neue Pflicht-Tags, neue Deny-Regeln).
• Rolle Breaking Changes in Wellen aus (Pilot-MG → Non-Prod → Prod).

Parameterisierung: weniger ist mehr

Ein häufiger Fehler ist das Überparametrisieren. Gute Parameter:

• sind stabil (ändern sich selten)
• sind fachlich verständlich (z. B. Locations, Tag Keys)
• lassen sich zentral pro Umgebung setzen (Prod/Non-Prod)

Wenn du pro Team/Subscription ständig andere Parameter brauchst, ist die Baseline vermutlich zu breit oder der Scope falsch gewählt.

Ausnahmen sauber modellieren

In Enterprise-Umgebungen sind Ausnahmen normal. Der Unterschied zwischen Chaos und Governance ist, wie du sie behandelst:

• Nutze Exemptions mit Ablaufdatum und Begründung.
• Halte Ausnahmen nah am Scope, wo sie gelten (z. B. Workload-Subscription statt Management Group), aber ohne die Baseline zu zerlegen.
• Baue ein Review (monatlich/vierteljährlich): “Welche Ausnahmen sind noch nötig?”

Remediation: Audit ist nicht genug

Für viele Baselines reicht es nicht, nur zu auditieren. Typische nächste Schritte:

• DeployIfNotExists, um Diagnostik-Einstellungen/Logs konsistent auszurollen
• Modify, um Tags oder Konfigurationen zu ergänzen

Wichtig ist der Betriebsaspekt:

• Remediation braucht passende Identitäten/Rollen.
• Plane Rollout in Wellen (zuerst Audit, dann Deny).

Policy-as-Code: Versionierung und Rollout

Wenn Policies/Initiativen als Code gepflegt werden, wird das Betriebssystem der Governance klarer:

• Änderungen laufen durch Review.
• Versionen sind nachvollziehbar.
• Rollouts können über Umgebungen gestaffelt werden.

Ein pragmatischer Ablauf ist:

1. Neue Policy/Änderung zunächst als Audit ausrollen.
2. Findings beheben, ggf. Parameter nachschärfen.
3. Danach auf Deny wechseln (oder Remediation aktivieren).

Typische Stolperfallen

• Initiativen wachsen ohne Struktur: am Ende ist alles “eine Baseline”.
• Deny ohne Vorlauf: verursacht ungeplante Deploy-Fails.
• Ausnahmen per “Policy nicht zuweisen”: führt zu inkonsistenten Scopes und nicht mehr erklärbarer Governance.

Checkliste für Assignments

• Liegt das Assignment auf dem kleinstmöglichen stabilen Scope (oft MG statt einzelne Subscriptions)?
• Sind Parameterwerte pro Umgebung (Prod/Non-Prod) klar und nachvollziehbar?
• Gibt es einen definierten Prozess für Exemptions (Begründung + Ablaufdatum + Review)?
• Ist der Rolloutpfad dokumentiert (wer wird informiert, was wird gemonitort)?