Die Nordlicht Reisen GmbH hat drei Teams, die alle im selben Abonnement arbeiten. Nach einem Monat liegen Ressourcen in Regionen, in denen niemand sie haben wollte, eine Produktionsgruppe wurde versehentlich gelöscht, und niemand weiß mehr, welche Ressource zu welcher Kostenstelle gehört. Rollen (Lektion 1.3) sagen, wer etwas tun darf. Hier geht es um das Gegenstück: was in einem Bereich sein darf (Azure Policy), was nicht verschwinden darf (Sperren) und wozu etwas gehört (Tags). Diese Lektion deckt ab: Azure Policy umsetzen und verwalten, Ressourcensperren konfigurieren, Tags anwenden und verwalten.
Vorwissen. Was Richtlinien, Sperren und Tags sind, erklärt „AZ-900 kompakt“, Lektionen 3.1 und 3.2. Wie Entwickelnde sie per Skript einsetzen, zeigt K3, Lektion 3.1.3 (Ordnung, Tags, Sperren) und 3.1.5 (Regeln und Datengrenze). Hier steht der Stoff aus Sicht der Administration, mit Portal und Befehlen.
Azure Policy umsetzen und verwalten
Die Bausteine
| Baustein | Was es ist | Beispiel |
|---|---|---|
| Richtliniendefinition (policy definition) | eine Regel in JSON: unter welcher Bedingung (if) welcher Effekt (then) |
„Allowed locations“ |
| Initiative (initiative definition, in Befehlen auch policy set) | eine Sammlung von Definitionen für ein gemeinsames Ziel | „Get Secure“ aus Microsofts Tutorial |
| Zuweisung (assignment) | eine Definition oder Initiative, angewendet auf einen Bereich | „Allowed locations“ auf die Ressourcengruppe rg-az104-policy |
Eine Definition tut nichts, solange sie nicht zugewiesen ist. Eine Zuweisung kann auf Verwaltungsgruppe, Abonnement, Ressourcengruppe oder einzelne Ressource zeigen und gilt für alles darunter. Microsoft nennt dazu: Wer Definitionen höher ablegt (Verwaltungsgruppe oder Abonnement) und die Zuweisung eine Ebene tiefer vornimmt, kann dieselbe Definition mehrfach nutzen. Außerdem empfiehlt Microsoft, auch eine einzelne Richtlinie als Initiative zuzuweisen: Später kommen weitere Definitionen dazu, ohne dass die Zahl der Zuweisungen wächst.
Parameter machen eine Definition allgemein. „Allowed locations“ kennt den Parameter listOfAllowedLocations; welche Regionen erlaubt sind,
legt erst die Zuweisung fest.
Effekte
Der Effekt steht im then-Teil und bestimmt, was bei einem Treffer passiert. Microsoft wertet sie in dieser Reihenfolge aus:
disabled: Die Regel ist abgeschaltet und wird gar nicht ausgewertet.appendundmodify: ändern die Anfrage, bevor sie weitergeht (modifyfügt etwa ein Tag hinzu).deny: lehnt die Anfrage ab.audit: erlaubt sie und vermerkt die Abweichung als nicht konform.auditIfNotExists,deployIfNotExists: prüfen oder erzeugen verbundene Ressourcen, nachdem der Ressourcenanbieter Erfolg gemeldet hat.denyAction: sperrt bestimmte Aktionen (etwa Löschen) auf Ressourcen.
Zwei Folgen sind prüfungsrelevant. Erstens: deny greift vor audit, damit eine unerwünschte Ressource nicht doppelt erfasst wird. Zweitens:
Bei bereits vorhandenen Ressourcen ändern deny, append und deployIfNotExists nichts; sie zeigen die Ressource nur als nicht konform. Ändern kann sie nur ein
Abhilfeauftrag (remediation task), und nur für modify und deployIfNotExists. Microsofts Empfehlung für den Start: erst audit, dann erzwingen.
Wann wird ausgewertet?
Eine Ressource wird geprüft, wenn sie in einem Bereich mit Zuweisung angelegt oder geändert wird, wenn ein Bereich eine neue Zuweisung bekommt, wenn eine zugewiesene Richtlinie geändert wird und im regulären Zyklus einmal alle 24 Stunden. Nach einer neuen Zuweisung dauert es laut Microsoft etwa fünf Minuten, bis sie auf den Bereich wirkt, danach beginnt die Auswertung der vorhandenen Ressourcen. Wer nicht warten will, stößt eine Auswertung an:
az policy state trigger-scan --resource-group rg-az104-policy
Azure PowerShell kennt dafür Start-AzPolicyComplianceScan -ResourceGroupName rg-az104-policy.
Zuweisen: Portal-Weg
- Im Portal nach Policy suchen (je nach Spracheinstellung heißt der Dienst anders), Assignments (Zuweisungen) öffnen und Assign policy wählen.
- Auf dem Reiter Basics den Scope wählen: Verwaltungsgruppe, Abonnement und optional eine Ressourcengruppe. Unter Exclusions lassen sich Teilbereiche ausnehmen, sie beginnen eine Ebene unter dem Scope.
- Bei Policy definition die Definition suchen, etwa „Allowed locations“. Der Filter Type = Built-in zeigt die integrierten.
- Policy enforcement bleibt auf Enabled. Steht es auf Disabled (im Befehl:
DoNotEnforce), wertet Azure aus, ohne den Effekt auszulösen: der sichere Probelauf. - Auf Parameters die Werte eintragen; auf Remediation bei
modifyunddeployIfNotExistsdie verwaltete Identität anlegen (Pflicht; für „Inherit a tag from the resource group if missing“ schlägt das Portal die Rolle Contributor vor). Auf Non-compliance messages eine Meldung setzen, dann Review + create.
Zuweisen: Befehl
$rgId = az group show --name rg-az104-policy --query id --output tsv
$def = az policy definition list --query "[?displayName=='Allowed locations'].name" --output tsv
'{"listOfAllowedLocations":{"value":["germanywestcentral"]}}' | Set-Content -Path ./erlaubte-regionen.json
az policy assignment create --name erlaubte-regionen --display-name "Erlaubte Regionen" `
--scope $rgId --policy $def --params "@erlaubte-regionen.json"
Weitere Parameter von az policy assignment create: --not-scopes (Ausschlüsse), --enforcement-mode (Default, DoNotEnforce) und --mi-system-assigned mit --location
und --role für Definitionen, die eine Identität brauchen. In Azure PowerShell: New-AzPolicyAssignment mit -NotScope und -EnforcementMode.
Initiativen anlegen
Im Portal: Policy → Definitions → + Initiative definition, Ablage in Verwaltungsgruppe oder Abonnement, Definitionen auf Policies hinzufügen, Werte auf Policy parameters
setzen. Dieselbe Definition darf mehrfach vorkommen, mit eigener reference ID und anderen Parametern. Befehle: az policy set-definition, in Azure PowerShell New-AzPolicySetDefinition.
Ausschluss oder Ausnahme?
Ausschluss (exclusion, notScopes) |
Ausnahme (exemption) | |
|---|---|---|
| Wo | Teil der Zuweisung | eigene Ressource, die auf die Zuweisung zeigt |
| Wirkt auf | einen Teilbereich unter dem Scope der Zuweisung | Bereich der Ausnahme: Abonnement, Gruppe oder einzelne Ressource |
| Kategorie | keine | Waiver (Risiko akzeptiert) oder Mitigated (anderweitig gelöst) |
| Ablauf | keiner | optional ein Ablaufdatum |
Der Grund: Azure Policy ist ein ausdrückliches Verbotssystem. Eine großzügigere Zuweisung weiter unten überstimmt eine ablehnende weiter oben nicht; man nimmt den
Bereich aus oder ändert die ablehnende Zuweisung. Im Portal gibt es auf der Zuweisung die Schaltfläche Create exemption; per Befehl
az policy exemption create --name … --policy-assignment … --exemption-category Waiver --scope … (optional --expires-on).
Konformität lesen
Unter Policy → Compliance erscheinen Zuweisungen mit ihrem Zustand. Direkt nach dem Zuweisen steht dort Not started, nach der Auswertung Compliant oder Non-compliant. Ein Klick auf die Zuweisung zeigt die einzelnen Ressourcen, die Registerkarte Events nennt, wer eine abgelehnte Anfrage gestellt hat. Auf der Befehlszeile:
az policy state list --resource-group rg-az104-policy --filter "(isCompliant eq false)"
Eine abgelehnte Bereitstellung zeigt sich auf der Ressourcengruppe unter Deployments mit dem Status Forbidden; in den Fehlerdetails stehen die Kennungen der beteiligten Richtlinienobjekte. Wichtig: Azure Policy blockiert auch dann, wenn jemand per RBAC alles darf. Rolle und Richtlinie ergänzen sich (Lektion 1.3).