Azure Policy und Initiative Definitions Governance-Regeln sauber strukturieren

In meinen Azure-Kursen stoße ich regelmäßig auf dasselbe Muster: Unternehmen haben bereits dutzende Azure-Ressourcen im Einsatz, aber kaum eine durchdachte Governance-Struktur. Policies wurden ad hoc erstellt, Assignments (Zuweisungen) liegen kreuz und quer auf verschiedenen Scopes (Geltungsbereichen), und niemand weiß mehr, welche Regel eigentlich woher kommt. Das Ergebnis: unkontrollierte Umgebungen, Compliance-Lücken und ein Audit, der zum Albtraum wird. Azure Policy und Initiative Definitions lösen genau dieses Problem – vorausgesetzt, man baut die Struktur von Anfang an sauber auf.

Azure Policy ist ein Dienst, mit dem Sie Regeln für Ressourcen in Ihrem Azure-Tenant durchsetzen können. OK. Das müssen wir noch weiter spezifizieren.

Was sind Azure Policy und Initiative Definitions?

Eine Policy Definition (Richtliniendefinition) beschreibt dabei eine einzelne Regel – zum Beispiel: „Alle Storage Accounts müssen HTTPS-only sein“ oder „Virtuelle Maschinen dürfen nur in bestimmten Regionen erstellt werden.“ Eine Initiative Definition (früher auch Policy Set Definition genannt) ist eine Sammlung mehrerer Policy Definitions, die zusammen ein Compliance-Ziel abbilden – etwa „ISO 27001“ oder eine unternehmensinterne Sicherheitsbaseline.

Der entscheidende Unterschied liegt im Scope des Einsatzes: Einzelne Policies sind präzise Werkzeuge für spezifische Anforderungen. Initiativen sind das Organisationsmittel, wenn Governance skalieren soll. In der Praxis empfehle ich fast immer, Policies in Initiativen zu bündeln – auch wenn zunächst nur eine einzige Policy enthalten ist. Das hält die Zuweisung (Assignment) später flexibel.

Merksatz: Eine Policy Definition beschreibt was geprüft wird. Ein Assignment legt wo es gilt. Eine Initiative bündelt mehrere Policies zu einem kohärenten Compliance-Paket.

Aufbau einer Policy Definition: Struktur und Effekte

Jede Policy Definition besteht aus einem JSON-Dokument mit klar definierten Bestandteilen. Die wichtigsten Felder sind policyRule, parameters und metadata. Innerhalb der policyRule wird über if die Bedingung definiert und über then der Effekt (Effect) gesteuert.

Die Wahl des richtigen Effekts ist einer der häufigsten Stolperpunkte. Hier eine Übersicht der gängigen Effekte:

Praxistipp: Starten Sie neue Policies immer mit dem Effekt Audit. So sehen Sie zunächst, wie viele bestehende Ressourcen betroffen wären, ohne den Betrieb zu unterbrechen. Erst nach Analyse der Compliance-Ergebnisse wechseln Sie auf Deny oder DeployIfNotExists.

Ein einfaches Beispiel: Eine Policy, die sicherstellt, dass ein bestimmtes Tag vorhanden ist, sieht im policyRule-Abschnitt so aus:

{
  "if": {
    "field": "tags['CostCenter']",
    "exists": "false"
  },
  "then": {
    "effect": "Deny"
  }
}

Parameter (parameters) machen Policies wiederverwendbar. Statt den Tag-Namen hart zu kodieren, übergeben Sie ihn als Parameter – so lässt sich dieselbe Policy für „CostCenter“, „Owner“ und „Environment“ nutzen, ohne drei separate Definitionen zu pflegen.

Initiative Definitions: Policies sinnvoll bündeln

Ich hatte mich in diesem Zusammenhang in einem Kundenprojekt mit genau dieser Frage auseinandergesetzt: Wann lohnt sich eine eigene Initiative, und wann reicht eine einzelne Policy? Die Antwort ist fast immer: Initiativen lohnen sich sobald mehr als zwei Policies zu einem Thema gehören oder sobald ein Compliance-Framework (z.B. CIS, NIST, ISO 27001) abgebildet werden soll.

Microsoft liefert eine Vielzahl von Built-in Initiative Definitions mit – darunter vollständige Mappings für gängige Regulierungsframeworks. Diese können direkt zugewiesen oder als Basis für eigene Custom Initiatives genutzt werden. Für die meisten mittelständischen Unternehmen empfehle ich einen pragmatischen Ansatz:

Eigene Initiative Definition im JSON-Editor – mehrere Policy Definitions werden über ihre IDs referenziert.

Eine Custom Initiative besteht aus einem JSON-Dokument mit dem Array policyDefinitions, das die einzelnen Policy-IDs referenziert, sowie einem parameters-Block auf Initiative-Ebene. Wichtig: Parameter auf Initiativenebene müssen explizit an die enthaltenen Policies durchgereicht werden – das ist ein typischer Fehler, der in meinen Azure-Kursen immer wieder für Verwirrung sorgt.

{
  "properties": {
    "displayName": "Unternehmens-Baseline v1.0",
    "policyDefinitions": [
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/...",
        "parameters": {
          "tagName": {
            "value": "[parameters('requiredTag')]"
          }
        }
      }
    ],
    "parameters": {
      "requiredTag": {
        "type": "String",
        "defaultValue": "CostCenter"
      }
    }
  }
}

Merksatz: Versionieren Sie Ihre Initiative Definitions im Namen oder in der metadata. Eine Initiative namens „Unternehmens-Baseline v1.0“ lässt sich sauber durch „v1.1“ ersetzen, ohne alte Assignments sofort zu brechen.

Praxisempfehlung: KMU-taugliche Governance-Struktur

Noch mal in Kürze – kurz, knapp und strukturiert, zum Abharken:

Für ein mittelständisches Unternehmen mit einer Management-Group-Hierarchie empfehle ich folgende Einstiegsstruktur:

Wer diese Struktur konsequent aufbaut, hat ein solides Fundament für Compliance-Reporting, Audits und weiterführende Governance-Mechanismen wie Microsoft Defender for Cloud oder Azure Blueprints. Und falls Sie tiefer einsteigen möchten: In meinen Azure-Kursen behandeln wir Azure Policy hands-on – von der ersten Custom Definition bis zum vollständig parametrisierten Initiative Assignment auf Management-Group-Ebene.