Azure

Azure Policy

Allgemeine Infos

Azure Policy bewertet Ressourcen anhand von Richtliniendefinitionen in JSON. Eine Definition beschreibt eine Bedingung (zum Beispiel „Region nicht in der erlaubten Liste“) und einen Effekt (zum Beispiel deny). Mehrere Definitionen lassen sich zu einer Initiative bündeln und einer Management Group, Subscription oder Resource Group zuweisen.

Die Abgrenzung zu Azure RBAC: RBAC regelt, wer etwas tun darf, Azure Policy regelt, welcher Zustand erlaubt ist, unabhängig davon, wer die Änderung vornimmt. Auch ein Owner kann keine Ressource anlegen, die eine deny-Policy verletzt.

Microsoft liefert eingebaute Definitionen und Initiativen, etwa für den Microsoft Cloud Security Benchmark, die auch Defender for Cloud nutzt. Über Machine Configuration (früher Gastkonfiguration) prüft Azure Policy zusätzlich Einstellungen innerhalb von VMs und Arc-Servern.

Funktionsweise & Details

Azure Policy arbeitet in drei Schritten:

  1. Zuweisung: Eine Definition oder Initiative wird einem Scope zugewiesen, optional mit Parametern und Ausschlüssen (notScopes).
  2. Auswertung: Bei jedem Anlegen oder Ändern einer Ressource, bei neuen oder geänderten Zuweisungen und im Standardzyklus alle 24 Stunden.
  3. Wirkung: Effekte wie audit, auditIfNotExists, deny, denyAction, modify oder deployIfNotExists bestimmen, ob nur protokolliert, blockiert oder korrigiert wird.

Für bestehende Abweichungen erzeugen Remediation-Tasks Korrekturen in großer Zahl. Effekte wie modify und deployIfNotExists nutzen dafür eine Managed Identity, die passende Rechte braucht. Exemptions erlauben begründete Ausnahmen mit Ablaufdatum. Pro Scope gelten Grenzen, etwa 200 Zuweisungen und 1.000 Ausnahmen.

Vorteile & Nutzen

  • Einheitliche Standards in großen Umgebungen, weil Regeln zentral vererbt werden
  • Fehlkonfigurationen werden bereits beim Deployment verhindert statt später gesucht
  • Automatische Korrektur über modify und deployIfNotExists, etwa für Diagnoseeinstellungen
  • Zentrale Compliance-Übersicht als Nachweis für Audits, zum Beispiel im Rahmen von NIS2

Praxisbeispiel

Ein Chemiehandel mit 180 Beschäftigten muss gegenüber Kunden nachweisen, dass Daten in der EU bleiben. Die IT weist auf der Landing-Zone-Management-Group eine Initiative zu: erlaubte Regionen nur Germany West Central und West Europe, Pflicht-Tag Kostenstelle, keine öffentlichen Storage-Konten. Die Regeln laufen zwei Wochen im audit-Modus, danach werden sie auf deny umgestellt. Der Compliance-Bericht dient seither als Anlage für Kundenaudits.

Worauf sollte man achten?

  • Neue Policies zuerst mit audit testen und die Compliance-Ergebnisse auswerten, bevor Du auf deny umstellst
  • Initiativen statt vieler Einzelzuweisungen nutzen, auch für eine einzelne Policy, damit spätere Ergänzungen keine neue Zuweisung erfordern
  • Managed Identity für Remediation mit minimalen Rechten ausstatten
  • Exemptions immer mit Begründung und Ablaufdatum anlegen und regelmäßig prüfen
  • Policy-Definitionen als Code versionieren und über Pipelines ausrollen

Lizenz & Verfügbarkeit

Die Policy-Auswertung für Azure-Ressourcen ist kostenlos. Machine Configuration auf Azure-Arc-Servern ist ein kostenpflichtiges Add-on; enthalten ist sie bei Defender for Servers Plan 2 sowie bei Windows-Server-Lizenzen mit aktiver Software Assurance oder Windows-Server-Subscription über Azure Arc. Stand: Oktober 2026.

Fazit

Azure Policy ist das wichtigste Werkzeug für Cloud-Governance in Azure. Starte im audit-Modus und härte die Regeln schrittweise.

Weiterführende Links

Verwandte Artikel