Grundlagen: Auswirkungen von Azure Policy-Definitionen

  • Artikel

Jede Richtliniendefinition in Azure Policy weist einen einzelnen effect-Wert in policyRule auf. Der effect-Typ bestimmt, was geschieht, wenn bei der Auswertung der Richtlinienregel eine Übereinstimmung gefunden wird. Die Auswirkungen für eine neue Ressource, eine aktualisierte Ressource oder eine vorhandene Ressource sind hierbei unterschiedlich.

Die folgenden Auswirkungen von Azure Policy-Definitionen werden unterstützt:

Austauschbare Effekte

Manchmal können mehrere Effekte für eine bestimmte Richtliniendefinition gültig sein. Parameter werden häufig verwendet, um zulässige Effektwerte (allowedValues) anzugeben, sodass eine einzelne Definition bei der Zuweisung vielseitiger sein kann. Es ist jedoch wichtig zu beachten, dass nicht alle Effekte austauschbar sind. Die Ressourceneigenschaften und die Logik in der Richtlinienregel können bestimmen, ob ein bestimmter Effekt für die Richtliniendefinition gültig ist. Beispielsweise erfordern Richtliniendefinitionen mit der Auswirkung auditIfNotExists weitere Details in der Richtlinienregel, die für Richtlinien mit der Auswirkung audit nicht erforderlich sind. Auch die Effekte sind unterschiedlich. audit-Richtlinien bewerten die Konformität einer Ressource auf der Grundlage ihrer eigenen Eigenschaften, während auditIfNotExists-Richtlinien die Konformität einer Ressource basierend auf den Eigenschaften einer untergeordneten Ressource oder Erweiterungsressource bewerten.

Die folgende Liste enthält einige allgemeine Hinweise zu austauschbaren Effekten:

  • audit, deny und entweder modify oder append sind häufig austauschbar.
  • auditIfNotExists und deployIfNotExists sind häufig austauschbar.
  • manual ist nicht austauschbar.
  • disabled ist mit allen Auswirkungen austauschbar.

Reihenfolge der Auswertung

Azure Policy wertet zuerst Anforderungen zum Erstellen oder Aktualisieren einer Ressource aus. Azure Policy erstellt eine Liste aller Zuweisungen, die auf die Ressource zutreffen, und wertet dann die Ressource anhand jeder Definition aus. Bei Verwendung eines Resource Manager-Modus werden von Azure Policy einige der Auswirkungen verarbeitet, bevor die Anforderung an den entsprechenden Ressourcenanbieter übergeben wird. Durch diese Reihenfolge wird eine unnötige Verarbeitung durch einen Ressourcenanbieter verhindert, wenn eine Ressource nicht den konfigurierten Governancevorgaben von Azure Policy entspricht. Bei Verwendung eines Ressourcenanbietermodus verwaltet der Ressourcenanbieter die Auswertung und das Ergebnis und gibt die Ergebnisse an Azure Policy zurück.

  • Zuerst wird disabled überprüft, um zu ermitteln, ob die Richtlinienregel ausgewertet werden soll.
  • Anschließend werden append und modify ausgewertet. Die Anforderung kann durch beides geändert werden, deshalb kann eine durchgeführte Änderung die Auslösung der Auswirkung „Audit“ oder „Deny“ verhindern. Diese Auswirkungen sind nur in einem Resource Manager-Modus verfügbar.
  • Danach wird deny ausgewertet. Durch die Auswertung von „deny“ vor „audit“ wird eine zweimalige Protokollierung einer unerwünschten Ressource verhindert.
  • audit wird ausgewertet.
  • manual wird ausgewertet.
  • auditIfNotExists wird ausgewertet.
  • denyAction wird zuletzt ausgewertet.

Nachdem der Ressourcenanbieter einen Erfolgscode für eine Anforderung im Resource Manager-Modus zurückgegeben hat, werden auditIfNotExists und deployIfNotExists ausgewertet, um zu bestimmen, ob eine weitere Konformitätsprotokollierung oder -aktion erforderlich ist.

PATCH-Anforderungen, die nur Felder mit Bezug zu tags ändern, schränken die Richtlinienauswertung auf Richtlinien mit Bedingungen ein, die Felder mit Bezug zu tags überprüfen.

Schichten von Richtliniendefinitionen

Mehrere Zuweisungen können sich auf eine Ressource auswirken. Diese Zuweisungen können für den gleichen Bereich oder für verschiedene Bereiche gelten. Für jede dieser Zuweisungen ist wahrscheinlich auch eine andere Auswirkung definiert. Die Bedingung und die Auswirkung für jede Richtlinie werden unabhängig ausgewertet. Beispiel:

  • Richtlinie 1
    • Schränkt den Ressourcenstandort auf „westus“ ein
    • Abonnement A zugewiesen
    • Auswirkung „deny“
  • Richtlinie 2
    • Schränkt den Ressourcenstandort auf „eastus“ ein
    • Ressourcengruppe B im Abonnement A zugewiesen
    • Auswirkung „audit“

Dies würde zu folgendem Ergebnis führen:

  • Jede Ressource, die sich bereits in Ressourcengruppe B und am Standort „eastus“ befindet, ist gemäß Richtlinie 2 konform und gemäß Richtlinie 1 nicht konform.
  • Jede Ressource, die sich bereits in Ressourcengruppe B und nicht am Standort „eastus“ befindet, ist gemäß Richtlinie 2 nicht konform und auch gemäß Richtlinie 1 nicht konform, wenn sie sich nicht am Standort „westus“ befindet.
  • Richtlinie 1 verweigert alle neuen Ressourcen in Abonnement A, die sich in einer anderen Region als westus befinden.
  • Jede neue Ressource in Abonnement A und Ressourcengruppe B am Standort „westus“ wird erstellt und ist gemäß Richtlinie 2 nicht konform.

Wenn sowohl Richtlinie 1 als auch Richtlinie 2 die Auswirkung „deny“ verwenden, ändert sich die Situation folgendermaßen:

  • Jede Ressource, die sich bereits in Ressourcengruppe B und nicht am Standort „eastus“ befindet, ist gemäß Richtlinie 2 nicht konform.
  • Jede Ressource, die sich bereits in Ressourcengruppe B und nicht am Standort „westus“ befindet, ist gemäß Richtlinie 1 nicht konform.
  • Richtlinie 1 verweigert alle neuen Ressourcen in Abonnement A, die sich in einer anderen Region als westus befinden.
  • Jede neue Ressource in Ressourcengruppe B von Abonnement A wird abgelehnt.

Jede Zuweisung wird einzeln ausgewertet. Daher ist es nicht möglich, dass eine Ressource aufgrund unterschiedlicher Bereiche „durch das Netz schlüpfen“ kann. Das Schichten von Richtliniendefinitionen führt kumulativ zur stärksten Einschränkung. Wenn beispielsweise sowohl Richtlinie 1 als auch Richtlinie 2 die Auswirkung deny verwenden, wird eine Ressource aufgrund der sich überschneidenden und in Konflikt stehenden Richtliniendefinitionen blockiert. Wenn die Ressource dennoch im Zielbereich erstellt werden soll, überprüfen Sie die Ausnahmen für jede Zuweisung, um sicherzustellen, dass die richtigen Richtlinienzuweisungen auf die richtigen Bereiche angewendet werden.

Nächste Schritte