Azure Policy verstehen: Grundlagen, Grenzen und sinnvolle Einsatzbereiche

Viele Teams sprechen über Azure Policy erst dann ernsthaft, wenn ein Audit ansteht oder bereits ein Wildwuchs an verschieden konfigurierten Ressourcen entstanden ist. Dabei ist das Thema nicht nur für große Plattformen relevant. Auch kleine Teams oder neue Azure-Umgebungen profitieren davon, früh ein paar klare Guardrails zu setzen. Azure Policy hilft dir dabei, Plattformregeln technisch durchzusetzen, Ressourcen konsistent zu bewerten und Abweichungen früh sichtbar zu machen. Das gilt bei einer ersten Subscription genauso wie bei größeren Landing Zones, also standardisierten Plattformstrukturen für mehrere Teams.

Azure Policy bewertet Ressourcen und Änderungen gegen definierte Regeln und setzt so technische Plattformvorgaben durch. Wichtig ist dabei die richtige Erwartungshaltung. Azure Policy ersetzt weder die ordentliche Strukturierung von Ressourcen noch saubere Architekturentscheidungen. Dieser Artikel ist der Auftakt einer kompakten dreiteiligen Reihe. Hier geht es um das gemeinsame Begriffsmodell, sinnvolle Einsatzbereiche, die Grenzen des Werkzeugs und die grundlegende Wirkung wichtiger Policy-Effects.

Was Azure Policy technisch eigentlich ist

Azure Policy bewertet Azure-Ressourcen gegen Regeln, die als Definitionen beschrieben werden. Diese Regeln schauen auf Eigenschaften einer Ressource oder auf ergänzende Ressourcen, die vorhanden sein sollten. Die offizielle Übersicht zu Azure Policy beschreibt das als kontinuierliche Bewertung von Zielzuständen. Praktisch bedeutet das zweierlei. Azure Policy prüft neue oder geänderte Ressourcen bei Create- und Update-Vorgängen. Zusätzlich bewertet Azure bestehende Ressourcen regelmäßig in einem von Azure gesteuerten Compliance-Zyklus. Im Standardfall interessiert sich Azure Policy vor allem dafür, ob der tatsächliche Ressourcenzustand mit dem gewünschten Regelwerk vereinbar ist.

Eine Policy Definition beschreibt eine einzelne Regel. Eine Initiative bündelt mehrere Definitionen zu einem zusammenhängenden Regelwerk. Ein Assignment aktiviert eine Definition oder Initiative auf einem konkreten Scope wie einer Management Group, Subscription oder Resource Group. Eine Exemption dokumentiert schließlich, dass eine bestimmte Abweichung bewusst akzeptiert wird. Dieses Modell ist einfach genug, um schnell verstanden zu werden, und gleichzeitig stark genug, um große Plattformlandschaften konsistent zu steuern.

Wichtig ist außerdem der Unterschied zwischen laufender Bewertung und aktiver Kontrolle während eines Deployments. Azure Policy bewertet bestehende Ressourcen regelmäßig neu. Einmal alle 24 Stunden werden Bestandsressourcen gescannt und mögliche Compliance Verstöße aufgedeckt. Zusätzlich greift die Auswertung bei Create- und Update-Vorgängen, bei neuen Assignments und bei Änderungen an Definitionen oder Assignments. Deshalb kann eine neu eingeführte Policy gleichzeitig bestehende Abweichungen sichtbar machen und neue Create- oder Update-Vorgänge direkt beeinflussen.

Das folgende vereinfachte JSON-Beispiel zeigt den Kern einer Regel, die nur freigegebene Regionen erlaubt. Es bildet bewusst nur die für das Verständnis relevanten Properties ab.

{
  "properties": {
    "policyType": "Custom",
    "mode": "Indexed",
    "displayName": "Nur freigegebene Regionen verwenden",
    "parameters": {
      "allowedLocations": {
        "type": "Array",
        "metadata": {
          "displayName": "Erlaubte Regionen"
        }
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "audit"
      }
    }
  }
}

policyType: Custom bedeutet, dass die Regel von dir selbst stammt und nicht als Built-in von Microsoft geliefert wird. mode: Indexed ist für viele Regeln rund um Tags oder Regionen passend, weil Azure dabei nur die dafür unterstützten Ressourcentypen und Eigenschaften betrachtet. Die policyRule enthält die Bedingung und den effect. audit meldet eine Abweichung, blockiert den Request aber nicht. Die Werte für allowedLocations kommen später beim Assignment. Das Beispiel zeigt nur eine Policy Definition, die ohne Assignment erst einmal keinerlei Auswirkungen hat. Erst ein Assignment auf einem Scope, also zum Beispiel auf einer Management Group, Subscription oder Resource Group, macht die Regel wirksam.

Warum der effect die reale Wirkung einer Policy bestimmt

Die Bedingung beschreibt, wann Azure Policy einen Verstoß erkennt. Der effect entscheidet, was dann tatsächlich passiert. Genau deshalb kann dieselbe Regel je nach effect vom harmlosen Lagebild bis zum harten Deployment-Stopper reichen.

audit ist für viele Teams der vernünftigste Einstieg. Du bekommst ein reales Compliance-Signal, ohne Create- oder Update-Vorgänge sofort zu blockieren. So erkennst du früh, ob eine Regel fachlich richtig geschnitten ist und wie groß die Abweichung im Bestand tatsächlich ist.

deny verschiebt die gleiche Logik in eine andere operative Liga. Die Regel wird dann zum Guardrail im Deployment-Pfad. Das ist für klare No-Go-Vorgaben genau richtig, etwa bei verbotenen Regionen oder unerwünschten öffentlichen Endpunkten. Gleichzeitig steigt der Schaden eines unpräzisen Scopes sofort, weil aus einer unklaren Regel direkt ein blockierter Release werden kann.

modify liegt praktisch dazwischen. Der Effect blockiert nicht zwingend, sondern verändert unterstützte Eigenschaften einer Ressource direkt im Create- oder Update-Pfad, zum Beispiel beim Ergänzen oder Korrigieren von Tags. Damit eignet er sich für technische Normalisierung, ist aber kein Ersatz für beliebige Automatisierung, weil er nur auf unterstützte Felder und Szenarien wirkt.

deployIfNotExists verfolgt noch einmal ein anderes Ziel. Hier geht es nicht nur um Sichtbarkeit oder Blockade, sondern um das Nachziehen fehlender Begleitkonfigurationen, zum Beispiel bei Diagnostic Settings. Wenn also in der Policy definiert ist, dass SQL Server Audit Logs per Diagnostic Settings an ein Ziel gesendet werden sollen, diese Konfiguration im Deployment aber fehlt, kann deployIfNotExists die fehlende Begleitressource nachziehen.

Für den Einstieg reicht deshalb eine einfache Leitfrage. Willst du Abweichungen zuerst sehen, Eingaben technisch normalisieren, Verstöße verhindern oder fehlende Baselines ergänzen?

Wofür Azure Policy gut geeignet ist und wofür nicht

Aus Plattformsicht ist Azure Policy besonders stark, wenn du technische Mindeststandards beschreiben willst. Typische Beispiele sind Pflichtkonfigurationen auf Ressourcen, Logging- und Security-Baselines, erlaubte Regionen oder das Verhindern unnötig öffentlicher Endpunkte. Der Dienst eignet sich damit besonders für technische Guardrails, die direkt auf Ebene der Zielressourcen greifen sollen. Du definierst nicht nur eine Empfehlung, sondern ein auswertbares Regelwerk.

Auch Architekturentscheidungen lassen sich nicht nachträglich durch Policies retten. Wenn Landing Zones unsauber geschnitten sind, Verantwortlichkeiten unklar bleiben oder Test- und Produktivscopes wild gemischt werden, wird Azure Policy diese Schwächen eher sichtbar machen als lösen. Dasselbe gilt für komplexe Business-Logik. Sobald Regeln stark kontextabhängig sind oder tiefes Wissen über Applikationszustände brauchen, gehören sie eher in Infrastructure as Code (IaC), in CI/CD-Pipelines oder in Anwendungscode.

Scope, Vererbung und warum die erste Strukturentscheidung so wichtig ist

Die erste große Stolperfalle liegt fast immer beim Scope. Die Scope-Dokumentation von Microsoft trennt klar zwischen dem Ort einer Definition und dem Scope eines Assignments. Diese Trennung wirkt zunächst banal. In realen Plattformen entscheidet sie aber darüber, ob dein Regelwerk wiederverwendbar, testbar und später noch verständlich bleibt.

In vielen Umgebungen ist die Management Group der richtige Ort für wiederverwendbare Definitionen und Initiatives. Dort erreichst du mehrere Subscriptions mit derselben Logik, ohne Regeln zu duplizieren. Ein Assignment auf einer übergeordneten Management Group vererbt sich nach unten, also auf Subscriptions, Resource Groups und einzelne Ressourcen. Dadurch kann eine einzige Zuweisung sehr viel Wirkung entfalten.

Gleichzeitig wirken Policies kumulativ und im Konfliktfall restriktiv. Wenn ein übergeordnetes Assignment eine Region verbietet, macht ein permissiveres untergeordnetes Assignment diese Entscheidung nicht automatisch rückgängig. Genau deshalb sorgen zu breite Scopes und schlecht getrennte Test- und Produktivbereiche später oft für operative Probleme. Was am Anfang nach Bequemlichkeit aussieht, wird später zum operativen Debugging-Problem.

Häufig wird dann mit Ausschlüssen über notScopes gearbeitet, um bestimmte untergeordnete Scopes wieder vom Assignment auszunehmen. Das folgende vereinfachte Assignment zeigt nur den für das Beispiel relevanten Teil rund um notScopes.

{
  "properties": {
    "displayName": "Plattform-Baseline für Non-Prod",
    "policyDefinitionId": "/providers/Microsoft.Management/managementGroups/contoso/providers/Microsoft.Authorization/policySetDefinitions/platform-baseline",
    "notScopes": [
      "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-sandbox"
    ],
    "parameters": {
      "allowedLocations": {
        "value": ["westeurope", "northeurope"]
      }
    }
  }
}

Solche Ausschlüsse können sinnvoll sein. Wenn du sie aber früh und unstrukturiert stapelst, wird aus einem klaren Regelwerk schnell eine Ansammlung von Sonderfällen. Ein späterer Teil der Reihe greift genau diese Fehlerbilder noch einmal systematisch auf.

Die wichtigsten Grenzen von Azure Policy

Azure Policy ist mächtig, aber es ist kein Alleskönner. Die erste praktische Grenze liegt bei den unterstützten Ressourcentypen und Aliases. Nur was ein Resource Provider sauber für die Policy-Evaluation bereitstellt, lässt sich robust prüfen. Ein Alias ist dabei vereinfacht gesagt der von Policy adressierbare Pfad zu einer Ressourceneigenschaft. Wenn dir ein benötigter Alias fehlt oder ein Provider nur unvollständig unterstützt ist, wird eine scheinbar einfache Regel schnell fragil. Ein Blick in die Policy Samples zeigt oft schon früh, ob ein gewünschter Use Case realistisch ist.

Die zweite Grenze ist Wartbarkeit. Je komplexer Bedingungen, verschachtelte Ausnahmen und Parameter-Matrizen werden, desto schwerer lässt sich das Regelwerk noch erklären und sicher ändern. Viele Plattformteams überschätzen anfangs, wie viele Spezialfälle sie in ein einziges Regelwerk pressen sollten. Ein kleiner Satz robuster Regeln ist in der Praxis meist wertvoller als ein großes Regelwerk, das niemand mehr mit gutem Gewissen anfassen will.

Die dritte Grenze betrifft die operative Wirkung. Bestehende Ressourcen werden nicht automatisch repariert, nur weil sie als non-compliant markiert sind. Mit modify oder deployIfNotExists lässt sich in manchen Fällen nachsteuern. Das ist aber ein eigener Remediation-Prozess, der je nach Effekt zum Beispiel eine Managed Identity, also eine von Azure verwaltete Identität, zusätzliche Berechtigungen und Tests vor dem breiten Rollout braucht. Gerade deployIfNotExists wirkt dabei nicht wie eine transaktionale Garantie im ursprünglichen Deployment, sondern stößt eine zusätzliche Aktion an, die separat fehlschlagen kann. Auch technische Limits für Definitionen, Initiatives, Assignments und Exemptions pro Scope spielen mit hinein. Gerade größere Plattformen sollten diese Skalierungsgrenzen früh kennen.

Die entscheidende Nuance ist deshalb einfach. Nicht jede gewünschte Plattformregel ist ein guter Fit für Azure Policy. Wenn eine Regel tiefen Anwendungskontext braucht, mehrere Deploymentschritte koordinieren muss oder fachliche Zustände auswertet, ist Azure Policy meist nicht das passende Werkzeug. Disziplin bei der Toolwahl ist hier wichtiger als maximale Abdeckung auf dem Papier.

Ein pragmatischer Start für Plattformteams

Wenn du eine neue Plattform aufsetzt, beginne nicht mit einem Katalog aus fünfzig Deny-Regeln. Ein sinnvoller Einstieg konzentriert sich auf wenige Baselines mit hohem Nutzen und geringer Überraschung. Erlaubte Regionen, fehlende Diagnostic Settings oder unerwünschter Public Network Access auf sensiblen Ressourcentypen sind gute erste Kandidaten. Diese Regeln sind fachlich gut erklärbar und operativ meist leicht zu überprüfen.

Microsoft empfiehlt in den Empfehlungen zum Policy-Management, zunächst mit audit oder auditIfNotExists zu starten. Das ist keine schwache Vorstufe, sondern ein sehr vernünftiger Rollout-Pfad. Du gewinnst erst ein realistisches Bild über Abweichungen, ohne bestehende Pipelines sofort zu blockieren. Gleichzeitig solltest du Definitionen und Assignments früh als Code versionieren, damit spätere Änderungen reviewbar und reproduzierbar bleiben.

Ebenso wichtig ist der Scope deines Einstiegs. Teste Regeln zunächst in Non-Prod-Umgebungen oder klar geschnittenen Testscopes. Dort kannst du beobachten, welche Ressourcen compliant sind, welche Fehlmeldungen Teams sehen und ob die Regel wirklich den beabsichtigten technischen Effekt hat. Diese Reihenfolge reduziert spätere Rollout-Probleme spürbar, weil du nicht gleichzeitig Regel, Scope und Kommunikationspfad im Produktivbetrieb lernen musst.

Ein pragmatischer Start fühlt sich meistens unspektakulär an. Das ist ein gutes Zeichen. Wenn deine ersten Policies vor allem Transparenz schaffen, gut erklärbar sind und im Code sauber verwaltet werden, entsteht daraus ein belastbares Fundament für härtere Guardrails. Die nächsten zwei Teile der Reihe bauen genau darauf auf.

Die richtige Erwartungshaltung für den Rest der Reihe

Azure Policy ist am stärksten als technisches Plattformwerkzeug mit klaren Grenzen. Der Dienst bewertet Ressourceneigenschaften, hilft bei Guardrails und Baselines und wird besonders wertvoll, wenn Scopes und Vererbung früh sauber geschnitten sind. Genauso wichtig ist die Einsicht, dass wenige robuste Regeln meist mehr Wert liefern als ein scheinbar vollständiges Governance-Portfolio, das in der Praxis niemand mehr sicher betreiben kann.

In den zwei folgenden Teilen schauen wir zuerst auf Policy as Code mit Bicep oder Terraform und darauf, wie du Regeln mit Initiatives zu einem wartbaren Regelwerk bündelst. Danach geht es um den sicheren Rollout, saubere Scopes, Ausnahmen und Vererbung im laufenden Betrieb.

Wie setzt du Azure Policy heute ein, eher als technisches Guardrail oder eher als reines Compliance-Werkzeug? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.