Grundlegendes zu Azure Policy-Auswirkungen

  • Artikel

Jede Richtliniendefinition in Azure Policy hat eine einzelne Auswirkung. Diese Auswirkung bestimmt, was geschieht, wenn die Richtlinienregel auf eine Übereinstimmung ausgewertet wird. Die Auswirkungen für eine neue Ressource, eine aktualisierte Ressource oder eine vorhandene Ressource sind hierbei unterschiedlich.

Derzeit werden in einer Richtliniendefinition diese Auswirkungen 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 anzugeben, sodass eine einzelne Definition 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 dem Effekt AuditIfNotExists weitere Details in der Richtlinienregel, die für Richtlinien mit dem Effekt 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 Modify oder Append sind häufig austauschbar.
  • AuditIfNotExists und DeployIfNotExists sind häufig austauschbar.
  • Manual ist nicht austauschbar.
  • Disabled ist mit allen Effekten austauschbar.

Reihenfolge der Auswertung

Anforderungen zum Erstellen oder Aktualisieren einer Ressource werden von Azure Policy zuerst ausgewertet. 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 Deaktiviert überprüft, um zu ermitteln, ob die Richtlinienregel ausgewertet werden soll.
  • Append und Modify werden dann 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.
  • Anschließend 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 vom Ressourcenanbieter ein Erfolgscode für eine Anforderung im Resource Manager-Modus zurückgegeben wurde, 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.

AddToNetworkGroup

AddToNetworkGroup wird in Azure Virtual Network Manager zum Definieren der dynamischen Mitgliedschaft in Netzwerkgruppen verwendet. Diese Auswirkung gilt nur für Definitionen des RichtlinienmodusMicrosoft.Network.Data.

Bei Netzwerkgruppen enthält Ihre Richtliniendefinition den bedingten Ausdruck für den Abgleich von VNets, die Ihre Kriterien erfüllen, und gibt die Zielnetzwerkgruppe an, in der alle übereinstimmenden Ressourcen platziert werden. Die addToNetworkGroup-Wirkung wird verwendet, um Ressourcen in der Zielnetzwerkgruppe zu platzieren.

Weitere Informationen finden Sie unter Konfigurieren von Azure Policy mit Netzwerkgruppen in Azure Virtual Network Manager.

Anfügen

„append“ wird verwendet, um der angeforderten Ressource während der Erstellung oder Aktualisierung weitere Felder hinzuzufügen. Ein häufiges Beispiel ist die Angabe der zulässigen IP-Adressen für eine Speicherressource.

Wichtig

„Append“ ist für die Verwendung mit Nicht-Tag-Eigenschaften vorgesehen. Während „Append“ während einer Erstellungs- oder Aktualisierungsanforderung Tags zu einer Ressource hinzufügen kann, wird empfohlen, stattdessen die Auswirkung Modify für Tags zu verwenden.

Auswertung von „append“

Die Auswertung von „append“ erfolgt vor der Anforderungsverarbeitung durch einen Ressourcenanbieter während der Erstellung oder Aktualisierung einer Ressource. Mit „append“ werden Felder zur Ressource hinzugefügt, wenn die if-Bedingung der Richtlinienregel erfüllt ist. Wenn die Auswirkung „append“ einen Wert in der ursprünglichen Anforderung mit einem anderen Wert überschreiben würde, fungiert sie als Auswirkung „deny“ und lehnt die Anforderung ab. Um einen neuen Wert an ein vorhandenes Array anzufügen, verwenden Sie die [*] -Version des Alias.

Wenn eine Richtliniendefinition mit Auswirkung „append“ im Rahmen eines Auswertungszyklus ausgeführt wird, werden keine Änderungen an bereits vorhandenen Ressourcen durchgeführt. Stattdessen werden alle Ressourcen mit Erfüllung der if-Bedingung als nicht konform markiert.

Eigenschaften von „append“

Die Auswirkung „append“ weist nur ein Array details auf, das erforderlich ist. Da es sich bei details um ein Array handelt, kann es entweder ein einzelnes field/value-Paar oder mehrere Wertepaare verwenden. Eine Liste der gültigen Felder finden Sie unter Struktur von Azure Policy-Definitionen.

Beispiele für „append“

Beispiel 1: Einzelnes field/value-Paar, das einen Nicht-[*]-Alias mit einem Arraywert value verwendet, um IP-Regeln für ein Speicherkonto festzulegen. Wenn der Nicht-[*]-Alias ein Array ist, wird der value durch den Effekt als gesamtes Array angefügt. Wenn das Array bereits vorhanden ist, wird durch den Konflikt ein deny-Ereignis ausgelöst.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
        "value": [{
            "action": "Allow",
            "value": "134.5.0.0/21"
        }]
    }]
}

Beispiel 2: Einzelnes field/value-Paar, das einen [*]-Alias, mit einem Arraywert value verwendet, um IP-Regeln für ein Speicherkonto festzulegen. Wenn Sie [*]-Alias verwenden, fügt der Effekt den value an ein Array an, das möglicherweise bereits vorhanden ist. Ist das Array noch nicht vorhanden, wird es erstellt.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
        "value": {
            "value": "40.40.40.40",
            "action": "Allow"
        }
    }]
}

Audit

Die Auswirkung „audit“ wird verwendet, um ein Warnungsereignis im Aktivitätsprotokoll zu erstellen, wenn eine nicht konforme Ressource ausgewertet wird. Die Anforderung wird jedoch nicht beendet.

Auswertung von „audit“

„audit“ ist die letzte Auswirkung, die von Azure Policy während der Erstellung oder Aktualisierung einer Ressource überprüft wird. Bei einem Resource Manager-Modus wird die Ressource von Azure Policy an den Ressourcenanbieter gesendet. Beim Auswerten einer Erstellungs- oder Aktualisierungsanforderung für eine Ressource fügt Azure Policy dem Aktivitätsprotokoll einen Microsoft.Authorization/policies/audit/action-Vorgang hinzu und markiert die Ressource als nicht konform. Während eines Standard-Konformitätsauswertungszyklus wird nur der Konformitätsstatus für die Ressource aktualisiert.

Eigenschaften von „audit“

Wenn Sie einen Resource Manager-Modus verwenden, verfügt die Auswirkung „audit“ über keine weiteren Eigenschaften für die Verwendung in der Bedingung then der Richtliniendefinition.

Wenn Sie den Ressourcenanbietermodus Microsoft.Kubernetes.Data verwenden, verfügt die Auswirkung „audit“ über folgende weitere Untereigenschaften von details. Die Verwendung von templateInfo ist für neue oder aktualisierte Richtliniendefinitionen erforderlich, da constraintTemplate veraltet ist.

  • templateInfo (erforderlich)
    • Kann nicht mit "constraintTemplate" verwendet werden.
    • sourceType (erforderlich)

      • Definiert den Typ der Quelle für die Einschränkungsvorlage. Zulässige Werte: PublicURL oder Base64Encoded.

      • Wenn PublicURL, gepaart mit der Eigenschaft url zur Angabe des Speicherorts der Einschränkungsvorlage verwendet wird. Auf den Speicherort muss öffentlich zugegriffen werden können.

        Warnung

        Verwenden Sie keine SAS-URIs, URL-Token oder anderen Elemente, die Geheimnisse im Nur-Text-Format verfügbar machen könnten.

      • Wenn Base64Encoded, gepaart mit der Eigenschaft content zur Angabe der Base64-codierten Einschränkungsvorlage verwendet wird. Unter Erstellen einer Richtliniendefinition aus einer Einschränkungsvorlage erfahren Sie, wie Sie eine benutzerdefinierte Definition aus einer vorhandenen Open Policy Agent (OPA) Gatekeeper v3-Einschränkungsvorlage erstellen.

  • constraint (veraltet)
    • Kann nicht mit "templateInfo" verwendet werden.
    • Die CRD-Implementierung der Einschränkungsvorlage. Verwendet Parameter, die über values als {{ .Values.<valuename> }}übergeben werden. In „Beispiel 2“ weiter unten lauten diese Werte {{ .Values.excludedNamespaces }} und {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (veraltet)
    • Kann nicht mit "templateInfo" verwendet werden.
    • Muss beim Erstellen oder Aktualisieren einer Richtliniendefinition durch templateInfo ersetzt werden.
    • Die Einschränkungsvorlage CustomResourceDefinition (CRD), die neue Einschränkungen definiert. Die Vorlage definiert die Rego-Logik, das Einschränkungsschema und die Einschränkungsparameter, die über values von Azure Policy übergeben werden. Weitere Informationen finden Sie unter Gatekeeper-Einschränkungen.
  • constraintInfo (optional)
    • Kann nicht mit constraint, constraintTemplate, apiGroups, kinds, scope, namespaces, excludedNamespaces oder labelSelector verwendet werden.
    • Wenn constraintInfo nicht angegeben wird, kann die Einschränkung aus templateInfo und der Richtlinie generiert werden.
    • sourceType (erforderlich)

      • Definiert den Typ der Quelle für die Einschränkung. Zulässige Werte: PublicURL oder Base64Encoded.

      • Wenn PublicURL, gepaart mit der Eigenschaft url zur Angabe des Speicherorts der Einschränkung verwendet wird. Auf den Speicherort muss öffentlich zugegriffen werden können.

        Warnung

        Verwenden Sie keine SAS-URIs oder Token in url oder andere Elemente, die ein Geheimnis offenlegen könnten.

  • namespaces (optional)
    • Ein Array von Kubernetes-Namespaces, auf das die Richtlinienauswertung beschränkt werden soll.
    • Ein leerer oder fehlender Wert bewirkt, dass die Richtlinienauswertung alle Namespaces einschließt, die nicht in excludedNamespaces definiert sind.
  • excludedNamespaces (optional)
  • labelSelector (optional)
    • Ein Objekt, das die Eigenschaften matchLabels (Objekt) und matchExpression (Array) umfasst, um festlegen zu können, welche Kubernetes-Ressourcen in die Richtlinienauswertung einbezogen werden sollen, die den angegebenen Bezeichnungen und Selektoren entsprechen.
    • Ein leerer oder fehlender Wert bewirkt, dass die Richtlinienauswertung alle Bezeichnungen und Selektoren einschließt, mit Ausnahme der in excludedNamespaces definierten Namespaces.
  • scope (optional)
    • Eine Zeichenfolge, die die Eigenschaft scope enthält, damit angegeben werden kann, ob Ressourcen im Clusterbereich oder Ressourcen im Namespacebereich übereinstimmen.
  • apiGroups (erforderlich bei Verwendung von templateInfo)
    • Ein Array, der die API-Gruppen enthält, die übereinstimmen müssen. Ein leeres Array ([""]) ist die API-Kerngruppe.
    • Das Definieren von ["*"] für apiGroups ist nicht zulässig.
  • kinds (erforderlich bei Verwendung von templateInfo)
    • Ein Array, das die Art von Kubernetes-Objekten festlegt, auf die die Auswertung beschränkt werden soll.
    • Das Definieren von ["*"] für kinds ist nicht zulässig.
  • values (optional)
    • Definiert Parameter und Werte, die an die Einschränkung übergeben werden. Jeder Wert muss vorhanden sein und einer Eigenschaft im Validierungsabschnitt „openAPIV3Schema“ der Einschränkungsvorlagen-CRD entsprechen.

Beispiel für „audit“

Beispiel 1: Verwenden der Auswirkung „audit“ für Resource Manager-Modi:

"then": {
    "effect": "audit"
}

Beispiel 2: Verwenden der Auswirkung „audit“ für den Ressourcenanbietermodus Microsoft.Kubernetes.Data. Durch die zusätzlichen Informationen in details.templateInfo werden die Verwendung von PublicURL deklariert und url auf den Speicherort der Einschränkungsvorlage festgelegt, die in Kubernetes verwendet werden soll, um die zulässigen Containerimages einzuschränken.

"then": {
    "effect": "audit",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

Auswirkung „AuditIfNotExists“

Die Auswirkung „AuditIfNotExists“ ermöglicht die Überwachung von Ressourcen, die zwar mit der Ressource, die die Bedingung if erfüllt, zusammenhängen, für die aber keine Eigenschaften in den Details (details) der Bedingung then angegeben sind.

Auswertung von „AuditIfNotExists“

„AuditIfNotExists“ wird ausgeführt, nachdem ein Ressourcenanbieter eine Anforderung zum Erstellen oder Aktualisieren einer Ressource verarbeitet hat und ein Erfolgsstatuscode zurückgegeben wurde. Die Überprüfung findet statt, wenn keine entsprechenden Ressourcen vorhanden sind oder wenn die über ExistenceCondition definierten Ressourcen nicht als TRUE ausgewertet werden. Bei neuen und aktualisierten Ressourcen fügt Azure Policy dem Aktivitätsprotokoll einen Microsoft.Authorization/policies/audit/action-Vorgang hinzu und markiert die Ressource als nicht konform. Bei Auslösung ist die Ressource, die die if-Bedingung erfüllt hat, die Ressource, die als nicht konform markiert wird.

Eigenschaften von „AuditIfNotExists“

Die details-Eigenschaft der Auswirkung „AuditIfNotExists“ umfasst die folgenden Untereigenschaften zur Definition der entsprechenden Ressourcen für den Abgleich.

  • Type (erforderlich)
    • Gibt den Typ der entsprechenden abzugleichenden Ressource an.
    • Wenn es sich bei type um einen Ressourcentyp unterhalb der Bedingungsressource if handelt, fragt die Richtlinie Ressourcen von diesem type innerhalb des Bereichs der ausgewerteten Ressource ab. Andernfalls werden Richtlinienabfragen innerhalb derselben Ressourcengruppe oder desselben Abonnements wie die ausgewertete Ressource je nach existenceScope durchgeführt.
  • Name (optional)
    • Gibt den exakten Namen der Ressource für den Abgleich an und führt dazu, dass die Richtlinie nicht alle Ressourcen des angegebenen Typs, sondern eine bestimmte Ressource abruft.
    • Wenn die Werte der Bedingung für if.field.type und then.details.type übereinstimmen, wird Nameerforderlich und muss [field('name')] sein (oder [field('fullName')] für eine untergeordnete Ressource). Allerdings sollte stattdessen ein audit-Effekt in Erwägung gezogen werden.

Hinweis

Die Segmente type und name können kombiniert werden, um geschachtelte Ressourcen generisch abzurufen.

Um eine bestimmte Ressource abzurufen, können Sie "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" und "name": "parentResourceName/nestedResourceName" verwenden.

Zum Abrufen einer Sammlung geschachtelter Ressourcen kann anstelle des letzten Namenssegments ein Platzhalterzeichen ? angegeben werden. Beispiel: "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" und "name": "parentResourceName/?". Dieses kann mit Feldfunktionen kombiniert werden, um auf Ressourcen zuzugreifen, die mit der ausgewerteten Ressource in Zusammenhang stehen, z. B. "name": "[concat(field('name'), '/?')]"".

  • ResourceGroupName (optional)
    • Hierdurch ist es möglich, für den Abgleich eine Ressource aus einer anderen Ressourcengruppe festzulegen.
    • Diese Einstellung ist nicht anwendbar, wenn type eine Ressource unterhalb der if-Bedingungsressource angibt.
    • Standardmäßig wird die Ressourcengruppe der if-Bedingungsressource verwendet.
  • ExistenceScope (optional)
    • Zulässige Werte sind Subscription und ResourceGroup.
    • Legt den Bereich fest, aus dem die entsprechende Ressource für den Abgleich abgerufen werden soll.
    • Diese Einstellung ist nicht anwendbar, wenn type eine Ressource unterhalb der if-Bedingungsressource angibt.
    • Für ResourceGroup wird der Bereich auf die Ressourcengruppe in ResourceGroupName begrenzt, falls angegeben. Wenn ResourceGroupName nicht angegeben ist, wird der Bereich auf die Ressourcengruppe der if-Bedingungsressource begrenzt. Dies ist das Standardverhalten.
    • Für Subscription wird das gesamte Abonnement nach der entsprechenden Ressource abgefragt. Der Zuweisungsbereich sollte für die ordnungsgemäße Auswertung auf das Abonnement oder höher festgelegt werden.
    • Die Standardeinstellung ist ResourceGroup.
  • EvaluationDelay (optional)
    • Hiermit wird angegeben, wann die Existenz der zugehörigen Ressourcen ausgewertet werden soll. Die Verzögerung wird nur bei Auswertungen verwendet, die das Ergebnis einer Erstell- oder Aktualisierungsanforderung für die Ressource sind.
    • Zu den zulässigen Werten zählen AfterProvisioning, AfterProvisioningSuccess und AfterProvisioningFailure sowie eine Dauer gemäß ISO 8601 zwischen 0 und 360 Minuten.
    • Die AfterProvisioning-Werte untersuchen die Bereitstellungsergebnisse der Ressource, die in der IF-Bedingung der Richtlinienregel ausgewertet wurde. AfterProvisioning wird unabhängig vom Ergebnis nach der Bereitstellung ausgeführt. Wenn für die Bereitstellung mehr als sechs Stunden benötigt werden, wird diese bei Festlegung von AfterProvisioning-Auswertungsverzögerungen als Fehler behandelt.
    • Der Standardwert ist PT10M (zehn Minuten).
    • Eine lange Auswertungsverzögerung kann dazu führen, dass der aufgezeichnete Konformitätszustand der Ressource bis zur nächsten Auswertungsauslösung nicht aktualisiert wird.
  • ExistenceCondition (optional)
    • Sofern nicht angegeben, erfüllt jede Ressource mit entsprechendem type die Bedingung der Auswirkung und löst keine Überwachung aus.
    • Verwendet dieselbe Sprachsyntax wie die Richtlinienregel für die if-Bedingung, wird jedoch für jede entsprechende Ressource einzeln ausgeführt.
    • Wenn eine übereinstimmende Ressource als TRUE ausgewertet wird, ist die Auswirkung erfüllt und löst keine Überwachung aus.
    • [field()] kann verwendet werden, um auf Äquivalenz mit Werten in der if-Bedingung zu überprüfen.
    • Beispielsweise könnte so überprüft werden, ob die übergeordnete Ressource (in der if-Bedingung) sich am selben Ressourcenstandort befindet wie die übereinstimmende Ressource.

Beispiel für „AuditIfNotExists“

Beispiel: Wertet Virtual Machines aus, um zu bestimmen, ob die Antischadsoftware-Erweiterung vorhanden ist, und überprüft, wenn sie fehlt.

{
    "if": {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
    },
    "then": {
        "effect": "auditIfNotExists",
        "details": {
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
                "allOf": [{
                        "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                        "equals": "Microsoft.Azure.Security"
                    },
                    {
                        "field": "Microsoft.Compute/virtualMachines/extensions/type",
                        "equals": "IaaSAntimalware"
                    }
                ]
            }
        }
    }
}

Verweigern

Mit „deny“ werden Ressourcenanforderungen abgelehnt, welche die über eine Richtliniendefinition festgelegten Standards nicht erfüllen. Für die Anforderung wird anschließend ein Fehler ausgegeben.

Auswertung von „deny“

Beim Erstellen oder Aktualisieren einer entsprechenden Ressource in einem Resource Manager-Modus wird die Anforderung durch „deny“ verhindert, bevor sie an den Ressourcenanbieter gesendet wird. Für die Anforderung wird 403 (Forbidden) zurückgegeben. Im Portal kann „Verboten“ als Status für die Bereitstellung angezeigt werden, die durch die Richtlinienzuweisung verhindert wurde. Bei Verwendung eines Ressourcenanbietermodus wird die Auswertung der Ressource vom Ressourcenanbieter verwaltet.

Während der Auswertung vorhandener Ressourcen werden Ressourcen, die einer „deny“-Richtliniendefinition entsprechen, als nicht konform markiert.

Eigenschaften von „deny“

Wenn Sie einen Resource Manager-Modus verwenden, verfügt die Auswirkung „deny“ über keine weiteren Eigenschaften für die Verwendung in der Bedingung then der Richtliniendefinition.

Wenn Sie den Ressourcenanbietermodus Microsoft.Kubernetes.Data verwenden, verfügt die Auswirkung „deny“ über folgende weitere Untereigenschaften von details. Die Verwendung von templateInfo ist für neue oder aktualisierte Richtliniendefinitionen erforderlich, da constraintTemplate veraltet ist.

  • templateInfo (erforderlich)
    • Kann nicht mit "constraintTemplate" verwendet werden.
    • sourceType (erforderlich)

      • Definiert den Typ der Quelle für die Einschränkungsvorlage. Zulässige Werte: PublicURL oder Base64Encoded.

      • Wenn PublicURL, gepaart mit der Eigenschaft url zur Angabe des Speicherorts der Einschränkungsvorlage verwendet wird. Auf den Speicherort muss öffentlich zugegriffen werden können.

        Warnung

        Verwenden Sie keine SAS-URIs oder Token in url oder andere Elemente, die ein Geheimnis offenlegen könnten.

      • Wenn Base64Encoded, gepaart mit der Eigenschaft content zur Angabe der Base64-codierten Einschränkungsvorlage verwendet wird. Unter Erstellen einer Richtliniendefinition aus einer Einschränkungsvorlage erfahren Sie, wie Sie eine benutzerdefinierte Definition aus einer vorhandenen Open Policy Agent (OPA) Gatekeeper v3-Einschränkungsvorlage erstellen.

  • constraint (optional)
    • Kann nicht mit "templateInfo" verwendet werden.
    • Die CRD-Implementierung der Einschränkungsvorlage. Verwendet Parameter, die über values als {{ .Values.<valuename> }}übergeben werden. In „Beispiel 2“ weiter unten lauten diese Werte {{ .Values.excludedNamespaces }} und {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (veraltet)
    • Kann nicht mit "templateInfo" verwendet werden.
    • Muss beim Erstellen oder Aktualisieren einer Richtliniendefinition durch templateInfo ersetzt werden.
    • Die Einschränkungsvorlage CustomResourceDefinition (CRD), die neue Einschränkungen definiert. Die Vorlage definiert die Rego-Logik, das Einschränkungsschema und die Einschränkungsparameter, die über values von Azure Policy übergeben werden. Weitere Informationen finden Sie unter Gatekeeper-Einschränkungen.
  • constraintInfo (optional)
    • Kann nicht mit constraint, constraintTemplate, apiGroups oder kinds verwendet werden.
    • Wenn constraintInfo nicht angegeben wird, kann die Einschränkung aus templateInfo und der Richtlinie generiert werden.
    • sourceType (erforderlich)

      • Definiert den Typ der Quelle für die Einschränkung. Zulässige Werte: PublicURL oder Base64Encoded.

      • Wenn PublicURL, gepaart mit der Eigenschaft url zur Angabe des Speicherorts der Einschränkung verwendet wird. Auf den Speicherort muss öffentlich zugegriffen werden können.

        Warnung

        Verwenden Sie keine SAS-URIs oder Token in url oder andere Elemente, die ein Geheimnis offenlegen könnten.

  • namespaces (optional)
    • Ein Array von Kubernetes-Namespaces, auf das die Richtlinienauswertung beschränkt werden soll.
    • Ein leerer oder fehlender Wert bewirkt, dass die Richtlinienauswertung alle Namespaces mit Ausnahme der in excludedNamespaces definierten Namespaces einschließt.
  • excludedNamespaces (erforderlich)
  • labelSelector (erforderlich)
    • Ein Objekt, das die Eigenschaften matchLabels (Objekt) und matchExpression (Array) umfasst, um festlegen zu können, welche Kubernetes-Ressourcen in die Richtlinienauswertung einbezogen werden sollen, die den angegebenen Bezeichnungen und Selektoren entsprechen.
    • Ein leerer oder fehlender Wert bewirkt, dass die Richtlinienauswertung alle Bezeichnungen und Selektoren einschließt, mit Ausnahme der in excludedNamespaces definierten Namespaces.
  • apiGroups (erforderlich bei Verwendung von templateInfo)
    • Ein Array, der die API-Gruppen enthält, die übereinstimmen müssen. Ein leeres Array ([""]) ist die API-Kerngruppe.
    • Das Definieren von ["*"] für apiGroups ist nicht zulässig.
  • kinds (erforderlich bei Verwendung von templateInfo)
    • Ein Array, das die Art von Kubernetes-Objekten festlegt, auf die die Auswertung beschränkt werden soll.
    • Das Definieren von ["*"] für kinds ist nicht zulässig.
  • values (optional)
    • Definiert Parameter und Werte, die an die Einschränkung übergeben werden. Jeder Wert muss in der CRD der Einschränkungsvorlage vorhanden sein.

Beispiel für „deny“

Beispiel 1: Verwenden der Auswirkung „deny“ für Resource Manager-Modi:

"then": {
    "effect": "deny"
}

Beispiel 2: Verwenden der Auswirkung „deny“ für den Ressourcenanbietermodus Microsoft.Kubernetes.Data. Durch die zusätzlichen Informationen in details.templateInfo werden die Verwendung von PublicURL deklariert und url auf den Speicherort der Einschränkungsvorlage festgelegt, die in Kubernetes verwendet werden soll, um die zulässigen Containerimages einzuschränken.

"then": {
    "effect": "deny",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

DenyAction

DenyAction wird verwendet, um Anforderungen basierend auf der beabsichtigten Aktion für Ressourcen im großen Maßstab zu blockieren. Die einzige unterstützte Aktion ist derzeit DELETE. Dieser Effekt und die Bezeichnung der Aktion tragen dazu bei, ein versehentliches Löschen wichtiger Ressourcen zu verhindern.

Auswertung von DenyAction

Wenn eine Anforderung mit einem zutreffenden Aktionsnamen und einem bestimmten Bereich aufgerufen wird, verhindert denyAction den Erfolg der Anforderung. Für die Anforderung wird 403 (Forbidden) zurückgegeben. Im Portal kann „Verboten“ als Status für die Bereitstellung angezeigt werden, die durch die Richtlinienzuweisung verhindert wurde.

Microsoft.Authorization/policyAssignments, Microsoft.Authorization/denyAssignments, Microsoft.Blueprint/blueprintAssignments, Microsoft.Resources/deploymentStacks, Microsoft.Resources/subscriptions und Microsoft.Authorization/locks sind alle von der Erzwingung von DenyAction ausgenommen, um Sperrszenarien zu verhindern.

Löschen eines Abonnements

Durch die Richtlinie wird die Entfernung von Ressourcen beim Löschen von Abonnements nicht blockiert.

Löschen einer Ressourcengruppe

Während der Löschung einer Ressourcengruppe wertet die Richtlinie Ressourcen, die Standort und Tags unterstützen, anhand von DenyAction-Richtlinien aus. Nur Richtlinien, bei denen in der Richtlinienregel cascadeBehaviors auf deny festgelegt ist, blockieren das Löschen von Ressourcengruppen. Die Richtlinie blockiert weder das Entfernen von Ressourcen, die keinen Standort und keine Tags unterstützen, noch Richtlinien mit mode:all.

Kaskadierendes DELETE

Kaskadierendes DELETE erfolgt, wenn beim Löschen einer übergeordneten Ressource alle ihre untergeordneten Ressourcen implizit gelöscht werden. Durch die Richtlinie wird das Entfernen von untergeordneten Ressourcen nicht blockiert, wenn eine Löschaktion auf die übergeordneten Ressourcen abzielt. Microsoft.Insights/diagnosticSettings ist beispielsweise eine untergeordnete Ressource von Microsoft.Storage/storageaccounts. Wenn die Richtlinie denyAction auf Microsoft.Insights/diagnosticSettings abzielt, schlägt ein Löschaufruf für die Diagnoseeinstellung (untergeordnet) fehl, aber bei einem Löschvorgang für das Speicherkonto (übergeordnet) wird die Diagnoseeinstellung (untergeordnet) implizit gelöscht.

In dieser Tabelle wird beschrieben, ob eine Ressource vor Löschung geschützt wird, wenn die Ressource der zugewiesenen Richtlinie (denyAction) und dem Zielbereich des Aufrufs von DELETE entspricht. Im Kontext dieser Tabelle ist eine indizierte Ressource eine Ressource, die Tags und Speicherorte unterstützt, und eine nicht indizierte Ressource ist eine Ressource, die weder Tags noch Speicherorte unterstützt. Weitere Informationen zu indizierten und nicht indizierten Ressourcen finden Sie unter Definitionsmodi. Untergeordnete Ressourcen sind Ressourcen, die nur im Kontext einer anderen Ressource verfügbar sind. Beispielsweise ist eine VM-Erweiterungsressource ein untergeordnetes Element der VM, die als übergeordnete Ressource fungiert.

Gelöschte Entität Richtlinienbedingungen unterliegende Entität Ausgeführte Aktion
Resource Resource Protected
Subscription Resource Deleted
Resource group Indizierte Ressource Abhängig voncascadeBehaviors
Resource group Nicht indizierte Ressource Deleted
Untergeordnete Ressource Übergeordnete Ressource Übergeordnetes Element wird geschützt, untergeordnetes Element wird gelöscht
Übergeordnete Ressource Untergeordnete Ressource Deleted

DenyAction-Eigenschaften

Die Eigenschaft details der Auswirkung DenyAction umfasst die folgenden Untereigenschaften zur Definition von Aktion und Verhalten.

  • actionNames (erforderlich)
    • Ein Array, das angibt, welche Aktionen verhindert werden sollen.
    • Unterstützte Aktionsnamen: delete.
  • cascadeBehaviors (optional)
    • Ein Objekt, das bestimmt, welches Verhalten befolgt wird, wenn die Ressource durch Entfernen einer Ressourcengruppe implizit gelöscht wird.
    • Wird nur in Richtliniendefinitionen unterstützt, bei denen der Modus (mode) auf indexed festgelegt ist.
    • Zulässige Werte: allow und deny.
    • Der Standardwert ist deny.

Beispiel für DenyAction

Beispiel: Verweigern aller Löschaufrufe für Datenbankkonten mit einer Umgebung des Typs „tag“, die „prod“ entspricht. Da das kaskadierende Verhalten auf „Deny“ festgelegt ist, werden alle DELETE-Aufrufe blockiert, die auf eine Ressourcengruppe mit einem entsprechenden Datenbankkonto abzielen.

{
   "if": {
      "allOf": [
         {
            "field": "type",
            "equals": "Microsoft.DocumentDb/accounts"
         },
         {
            "field": "tags.environment",
            "equals": "prod"
         }
      ]
   },
   "then": {
      "effect": "denyAction",
      "details": {
         "actionNames": [ "delete" ],
         "cascadeBehaviors": { "resourceGroup": "deny" }
      }
   }
}

Auswirkung „DeployIfNotExists“

Ähnlich wie „AuditIfNotExists“ führt eine „DeployIfNotExists“-Richtliniendefinition eine Vorlagenbereitstellung durch, wenn die Bedingung erfüllt ist. Richtlinienzuweisungen, deren Auswirkung auf "DeployIfNotExists" festgelegt ist, erfordern für das Durchführen von Korrekturmaßnahmen eine verwaltete Identität.

Hinweis

Geschachtelte Vorlagen werden mit deployIfNotExists unterstützt, verknüpfte Vorlagen werden derzeit jedoch nicht unterstützt.

Auswertung von „DeployIfNotExists“

„DeployIfNotExists“ wird nach einer konfigurierbaren Verzögerung ausgeführt, wenn ein Ressourcenanbieter eine Anforderung zum Erstellen oder Aktualisieren eines Abonnements oder einer Ressource verarbeitet hat und ein Erfolgsstatuscode zurückgegeben wurde. Eine Vorlagenbereitstellung findet statt, wenn keine entsprechenden Ressourcen vorhanden sind oder wenn die über ExistenceCondition definierten Ressourcen nicht als TRUE ausgewertet werden. Die Dauer der Bereitstellung hängt von der Komplexität der in der Vorlage enthaltenen Ressourcen ab.

Während eines Auswertungszyklus führen Richtliniendefinitionen mit der Auswirkung „DeployIfNotExists“ dazu, dass übereinstimmende Ressourcen als nicht konform markiert werden. Es wird aber keine Aktion für diese Ressource ausgeführt. Bestehende, nicht konforme Ressourcen können mit einem Wartungstask bereinigt werden.

Eigenschaften von „DeployIfNotExists“

Die details-Eigenschaft der Auswirkung „DeployIfNotExists“ umfasst alle Untereigenschaften, die die entsprechenden Ressourcen für den Abgleich und die auszuführende Vorlagenbereitstellung definieren.

  • Type (erforderlich)
    • Gibt den Typ der entsprechenden abzugleichenden Ressource an.
    • Wenn es sich bei type um einen Ressourcentyp unterhalb der Bedingungsressource if handelt, fragt die Richtlinie Ressourcen von diesem type innerhalb des Bereichs der ausgewerteten Ressource ab. Andernfalls werden Richtlinienabfragen innerhalb derselben Ressourcengruppe oder desselben Abonnements wie die ausgewertete Ressource je nach existenceScope durchgeführt.
  • Name (optional)
    • Gibt den exakten Namen der Ressource für den Abgleich an und führt dazu, dass die Richtlinie nicht alle Ressourcen des angegebenen Typs, sondern eine bestimmte Ressource abruft.
    • Wenn die Werte der Bedingung für if.field.type und then.details.type übereinstimmen, wird Nameerforderlich und muss [field('name')] sein (oder [field('fullName')] für eine untergeordnete Ressource).

Hinweis

Die Segmente type und name können kombiniert werden, um geschachtelte Ressourcen generisch abzurufen.

Um eine bestimmte Ressource abzurufen, können Sie "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" und "name": "parentResourceName/nestedResourceName" verwenden.

Zum Abrufen einer Sammlung geschachtelter Ressourcen kann anstelle des letzten Namenssegments ein Platzhalterzeichen ? angegeben werden. Beispiel: "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" und "name": "parentResourceName/?". Dieses kann mit Feldfunktionen kombiniert werden, um auf Ressourcen zuzugreifen, die mit der ausgewerteten Ressource in Zusammenhang stehen, z. B. "name": "[concat(field('name'), '/?')]"".

  • ResourceGroupName (optional)

    • Hierdurch ist es möglich, für den Abgleich eine Ressource aus einer anderen Ressourcengruppe festzulegen.
    • Diese Einstellung ist nicht anwendbar, wenn type eine Ressource unterhalb der if-Bedingungsressource angibt.
    • Standardmäßig wird die Ressourcengruppe der if-Bedingungsressource verwendet.
    • Wenn eine Vorlagenbereitstellung durchgeführt wird, erfolgt diese in der Ressourcengruppe, die über diesen Wert angegeben wurde.

  • ExistenceScope (optional)

    • Zulässige Werte sind Subscription und ResourceGroup.
    • Legt den Bereich fest, aus dem die entsprechende Ressource für den Abgleich abgerufen werden soll.
    • Diese Einstellung ist nicht anwendbar, wenn type eine Ressource unterhalb der if-Bedingungsressource angibt.
    • Für ResourceGroup wird der Bereich auf die Ressourcengruppe in ResourceGroupName begrenzt, falls angegeben. Wenn ResourceGroupName nicht angegeben ist, wird der Bereich auf die Ressourcengruppe der if-Bedingungsressource begrenzt. Dies ist das Standardverhalten.
    • Für Subscription wird das gesamte Abonnement nach der entsprechenden Ressource abgefragt. Der Zuweisungsbereich sollte für die ordnungsgemäße Auswertung auf das Abonnement oder höher festgelegt werden.
    • Die Standardeinstellung ist ResourceGroup.

  • EvaluationDelay (optional)

    • Hiermit wird angegeben, wann die Existenz der zugehörigen Ressourcen ausgewertet werden soll. Die Verzögerung wird nur bei Auswertungen verwendet, die das Ergebnis einer Erstell- oder Aktualisierungsanforderung für die Ressource sind.
    • Zu den zulässigen Werten zählen AfterProvisioning, AfterProvisioningSuccess und AfterProvisioningFailure sowie eine Dauer gemäß ISO 8601 zwischen 0 und 360 Minuten.
    • Die AfterProvisioning-Werte untersuchen die Bereitstellungsergebnisse der Ressource, die in der IF-Bedingung der Richtlinienregel ausgewertet wurde. AfterProvisioning wird unabhängig vom Ergebnis nach der Bereitstellung ausgeführt. Wenn für die Bereitstellung mehr als sechs Stunden benötigt werden, wird diese bei Festlegung von AfterProvisioning-Auswertungsverzögerungen als Fehler behandelt.
    • Der Standardwert ist PT10M (zehn Minuten).
    • Eine lange Auswertungsverzögerung kann dazu führen, dass der aufgezeichnete Konformitätszustand der Ressource bis zur nächsten Auswertungsauslösung nicht aktualisiert wird.

  • ExistenceCondition (optional)

    • Sofern nicht angegeben, erfüllt jede entsprechende Ressource mit type die Bedingung der Auswirkung und löst keine Bereitstellung aus.
    • Verwendet dieselbe Sprachsyntax wie die Richtlinienregel für die if-Bedingung, wird jedoch für jede entsprechende Ressource einzeln ausgeführt.
    • Wenn eine übereinstimmende Ressource als TRUE ausgewertet wird, ist die Auswirkung erfüllt und löst keine Bereitstellung aus.
    • [field()] kann verwendet werden, um auf Äquivalenz mit Werten in der if-Bedingung zu überprüfen.
    • Beispielsweise könnte so überprüft werden, ob die übergeordnete Ressource (in der if-Bedingung) sich am selben Ressourcenstandort befindet wie die übereinstimmende Ressource.

  • roleDefinitionIds (erforderlich)

  • DeploymentScope (optional)

    • Zulässige Werte sind Subscription und ResourceGroup.
    • Legt den Typ der auszulösenden Bereitstellung fest. Mit Subscription wird eine Bereitstellung auf Abonnementebene und mit ResourceGroup eine Bereitstellung in einer Ressourcengruppe angegeben.
    • Bei der Bereitstellung auf Abonnementebene muss in Deployment eine location-Eigenschaft angegeben werden.
    • Die Standardeinstellung ist ResourceGroup.

  • Deployment (erforderlich)

    • Diese Eigenschaft muss die vollständige Vorlagenbereitstellung enthalten, so wie sie an die PUT-API Microsoft.Resources/deployments übergeben würde. Weitere Informationen finden Sie im Artikel zur REST-API für die Bereitstellung.
    • Geschachtelte Microsoft.Resources/deployments-Elemente innerhalb der Vorlage sollten eindeutige Namen verwenden, um Konflikte zwischen mehreren Richtlinienauswertungen zu vermeiden. Der Name der übergeordneten Bereitstellung kann über [concat('NestedDeploymentName-', uniqueString(deployment().name))] als Teil des Namens der geschachtelte Bereitstellung verwendet werden.

    Hinweis

    Alle Funktionen innerhalb der Deployment-Eigenschaft werden als Komponenten der Vorlage – nicht der Richtlinie – ausgewertet. Eine Ausnahme ist die Eigenschaft parameters, die Werte von der Richtlinie an die Vorlage übergibt. Der in diesem Abschnitt unter einem Vorlagenparameternamen angegebene Wert für value wird verwendet, um diese Wertübergabe durchzuführen (siehe fullDbName im DeployIfNotExists-Beispiel).

Beispiel für „DeployIfNotExists“

Beispiel: Wertet SQL Server-Datenbanken aus, um zu bestimmen, ob „transparentDataEncryption“ aktiviert ist. Falls nicht, wird eine Bereitstellung zur Aktivierung dieser Option durchgeführt.

"if": {
    "field": "type",
    "equals": "Microsoft.Sql/servers/databases"
},
"then": {
    "effect": "deployIfNotExists",
    "details": {
        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
        "name": "current",
        "evaluationDelay": "AfterProvisioning",
        "roleDefinitionIds": [
            "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
            "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
        ],
        "existenceCondition": {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "Enabled"
        },
        "deployment": {
            "properties": {
                "mode": "incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "fullDbName": {
                            "type": "string"
                        }
                    },
                    "resources": [{
                        "name": "[concat(parameters('fullDbName'), '/current')]",
                        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
                        "apiVersion": "2014-04-01",
                        "properties": {
                            "status": "Enabled"
                        }
                    }]
                },
                "parameters": {
                    "fullDbName": {
                        "value": "[field('fullName')]"
                    }
                }
            }
        }
    }
}

Disabled

Diese Auswirkung ist in Testsituationen oder nach dem Parametrisieren der Auswirkung durch die Richtliniendefinition hilfreich. Aufgrund dieser Flexibilität kann eine einzelne Zuweisung deaktiviert werden, statt alle Zuweisungen dieser Richtlinie zu deaktivieren.

Hinweis

Richtliniendefinitionen, die die Auswirkung Deaktiviert verwenden, weisen nach der Zuordnung den Standardkonformitätszustand Konform auf.

Eine Alternative zur Auswirkung Deaktiviert stellt enforcementMode dar (wird in der Richtlinienzuweisung festgelegt). Wenn für enforcementMode der Wert Disabled festgelegt ist, werden Ressourcen dennoch ausgewertet. Eine Protokollierung, z.B. Aktivitätsprotokolle, und die Richtlinienauswirkung treten nicht auf. Weitere Informationen finden Sie unter Richtlinienzuweisung – Erzwingungsmodus.

Manuell

Mit der neuen Auswirkung manual können Sie die Konformität von Ressourcen oder Bereichen selbst nachweisen. Im Gegensatz zu anderen Richtliniendefinitionen, die aktiv nach Auswertung suchen, ermöglicht die Auswirkung „Manuell“ manuelle Änderungen am Konformitätszustand. Um die Konformität einer Ressource oder eines Bereichs zu ändern, die bzw. der einer manuellen Richtlinie unterliegt, müssen Sie einen Nachweis erstellen. Die bewährte Methode ist das Entwerfen manueller Richtlinien, die auf den Bereich abzielen, der die Grenze von Ressourcen definiert, deren Konformität nachgewiesen werden muss.

Hinweis

Die Unterstützung für manuelle Richtlinien steht über verschiedene Microsoft Defender for Cloud-Complianceinitiativen zur Verfügung. Wenn Sie ein Premium-Abonnement von Microsoft Defender for Cloud haben, lesen Sie die Erfahrungsübersicht.

Derzeit umfassen die folgenden Richtlinieninitiativen Richtliniendefinitionen, die den manuellen Effekt enthalten:

  • FedRAMP High
  • FedRAMP Medium
  • HIPAA
  • HITRUST
  • ISO 27001
  • Microsoft CIS 1.3.0
  • Microsoft CIS 1.4.0
  • NIST SP 800-171 Rev. 2
  • NIST SP 800-53 Rev. 4
  • NIST SP 800-53 Rev. 5
  • PCI-DSS 3.2.1
  • PCI-DSS 4.0
  • SOC TSP
  • SWIFT CSP CSCF v2022

Im folgenden Beispiel geht es um Azure-Abonnements, wobei der anfängliche Compliancestatus auf Unknown gesetzt wird.

{
  "if": {
    "field":  "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "manual",
    "details": {
      "defaultState": "Unknown"
    }
  }
}

Die Eigenschaft defaultState weist drei mögliche Werte auf:

  • Unbekannt: Der anfängliche Standardstatus der Zielressourcen.
  • Konform: Die Ressource ist gemäß Ihren manuellen Richtlinienstandards konform.
  • Nicht konform: Die Ressource ist gemäß Ihren manuellen Richtlinienstandards nicht konform.

Die Azure Policy-Compliance-Engine bewertet alle betreffenden Ressourcen anhand des in der Definition angegebenen Standardstatus (Unknown, falls nicht festgelegt). Der Compliancestatus Unknown gibt an, dass Sie den Ressourcencompliancestatus manuell bestätigen müssen. Wenn der Effektstatus nicht angegeben ist, wird er standardmäßig auf Unknown gesetzt. Der Compliancestatus Unknown gibt an, dass Sie den Compliancestatus selbst bestätigen müssen.

Der folgende Screenshot zeigt, wie eine manuelle Richtlinienzuweisung mit dem Status Unknown im Azure-Portal angezeigt wird:

Resource compliance table in the Azure portal showing an assigned manual policy with a compliance reason of 'unknown.'

Wenn eine Richtliniendefinition mit dem Effekt manual zugewiesen wird, können Sie die Compliancestatus von Zielressourcen oder -bereichen über benutzerdefinierte Nachweise festlegen. Mit Nachweisen können Sie auch optionale Zusatzinformationen in Form von Metadaten und Links zu den Beweisen bereitstellen, die den gewählten Compliancestatus ergänzen. Die Person, die die manuelle Richtlinie zuweist, kann einen Standardspeicherort für Beweise vorschlagen, indem sie die Eigenschaft evidenceStorages der Metadaten für die Richtlinienzuweisung angibt.

Ändern

„Modify“ wird verwendet, um Eigenschaften oder Tags während der Erstellung oder Aktualisierung eines Abonnements oder einer Ressource hinzuzufügen, zu aktualisieren oder zu entfernen. Ein häufiges Beispiel ist die Aktualisierung von Tags für Ressourcen wie „costCenter“. Bestehende, nicht konforme Ressourcen können mit einem Wartungstask bereinigt werden. Eine einzelne Modify-Regel kann eine beliebige Anzahl von Vorgängen aufweisen. Richtlinienzuweisungen, deren Auswirkung auf "modify" festgelegt ist, erfordern für das Durchführen von Korrekturmaßnahmen eine verwaltete Identität.

Die folgenden Vorgänge werden von „Modify“ unterstützt:

  • Hinzufügen, Ersetzen oder Entfernen von Ressourcentags. Für Tags sollte mode bei einer Modify-Richtlinie auf indexed festgelegt sein, es sei denn, die Zielressource ist eine Ressourcengruppe.
  • Hinzufügen oder Ersetzen des Werts eines verwalteten Identitätstyps (identity.type) von virtuellen Computern und VM-Skalierungsgruppen
  • Hinzufügen oder Ersetzen der Werte bestimmter Aliase
    • Verwenden Sie Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } in Azure PowerShell 4.6.0 oder höher, um eine Liste der Aliase abzurufen, die mit „Modify“ verwendet werden können.

Wichtig

Wenn Sie Tags verwalten, wird empfohlen, „Modify“ anstelle von „Append“ zu verwenden, da „Modify“ weitere Vorgangstypen und die Möglichkeit bietet, vorhandene Ressourcen zu korrigieren. Allerdings wird „Append“ empfohlen, wenn Sie keine verwaltete Identität erstellen können oder der Alias für die Ressourceneigenschaft von „Modify“ noch nicht unterstützt wird.

Auswertung von „Modify“

Die Auswertung von „Modify“ erfolgt vor der Anforderungsverarbeitung durch einen Ressourcenanbieter während der Erstellung oder Aktualisierung einer Ressource. Die Modify-Vorgänge werden auf den Anforderungsinhalt angewendet, wenn die if-Bedingung der Richtlinienregel erfüllt wird. Jeder Modify-Vorgang kann eine Bedingung angeben, die bestimmt, wann er angewendet wird. Vorgänge mit Bedingungen, die bei Auswertung false ergeben, werden übersprungen.

Wenn ein Alias angegeben wird, werden die folgenden zusätzlichen Überprüfungen durchgeführt, um sicherzustellen, dass der Anforderungsinhalt vom Modify-Vorgang nicht in einer Weise geändert wird, dass er vom Ressourcenanbieter abgelehnt wird:

  • Die Eigenschaft, der der Alias zugeordnet ist, wird in der API-Version der Anforderung als „Modifiable“ gekennzeichnet.
  • Der Tokentyp im Modify-Vorgang entspricht dem erwarteten Tokentyp für die Eigenschaft in der API-Version der Anforderung.

Wenn eine dieser Überprüfungen fehlschlägt, greift die Richtlinienauswertung auf den angegebenen conflictEffect zurück.

Wichtig

Es wird empfohlen, dass Definitionen von „Modify“, die Aliase enthalten, auditconflictEffect verwenden. Damit wird vermieden, dass bei Anforderungen mit API-Versionen, bei denen die zugeordnete Eigenschaft nicht „Modifiable“ lautet, ein Fehler auftritt. Wenn sich derselbe Alias zwischen API-Versionen unterschiedlich verhält, können bedingte Modify-Vorgänge verwendet werden, um den für die einzelnen API-Versionen verwendeten Modify-Vorgang zu bestimmen.

Wenn eine Richtliniendefinition mit Auswirkung „Modify“ im Rahmen eines Auswertungszyklus ausgeführt wird, werden keine Änderungen an bereits vorhandenen Ressourcen durchgeführt. Stattdessen werden alle Ressourcen mit Erfüllung der if-Bedingung als nicht konform markiert.

Eigenschaften von „Modify“

Die details-Eigenschaft der Modify-Auswirkung enthält alle Untereigenschaften, die die für die Bereinigung erforderlichen Berechtigungen definieren, und die Vorgänge, mit denen Tagwerte hinzugefügt, aktualisiert oder entfernt werden.

  • roleDefinitionIds (erforderlich)
    • Diese Eigenschaft muss ein Array von Zeichenfolgen enthalten, das mit der Rollen-ID der rollenbasierten Zugriffssteuerung übereinstimmt, auf die das Abonnement zugreifen kann. Weitere Informationen finden Sie unter Korrigieren nicht konformer Ressourcen mit Azure Policy.
    • Die definierte Rolle muss alle Vorgänge einbeziehen, die der Rolle Mitwirkender erteilt wurden.
  • conflictEffect (optional)
    • Bestimmt, welche Richtliniendefinition verwendet wird, wenn dieselbe Eigenschaft durch mehrere Richtliniendefinitionen geändert wird oder wenn der Modify-Vorgang für den angegebenen Alias nicht funktioniert.
      • Bei neuen oder aktualisierten Ressourcen hat die Richtliniendefinition mit deny Vorrang. Von Richtliniendefinitionen mit audit werden alle Vorgänge (operations) übersprungen. Sind mehrere Richtliniendefinitionen mit dem Effekt deny vorhanden, wird die Anforderung als Konflikt abgelehnt. Enthalten alle Richtliniendefinitionen audit, wird keiner der Vorgänge (operations) der in Konflikt stehenden Richtliniendefinitionen verarbeitet.
      • Falls bei vorhandenen Ressourcen mehrere Richtliniendefinition den Effekt deny enthalten, lautet der Konformitätsstatus Conflict. Ist der Effekt deny in maximal einer Richtliniendefinition enthalten, wird von den einzelnen Zuweisungen jeweils der Konformitätsstatus Non-compliant zurückgegeben.
    • Verfügbare Werte: audit, deny, disabled
    • Standardwert: deny
  • operations (erforderlich)
    • Ein Array aller Tagvorgänge, die auf übereinstimmenden Ressourcen ausgeführt werden sollen.
    • Eigenschaften:
      • operation (erforderlich)
        • Definiert, welche Maßnahme bei einer übereinstimmenden Ressource ergriffen werden sollen. Optionen sind: addOrReplace, Add, Remove. Add verhält sich ähnlich wie die Append-Auswirkung.
      • field (erforderlich)
        • Das Tag, das hinzugefügt, ersetzt oder entfernt werden soll. Tagnamen müssen derselben Namenskonvention für andere Felder entsprechen.
      • value (optional)
        • Der Wert, auf den das Tag festgelegt werden soll.
        • Diese Eigenschaft ist erforderlich, wenn operationaddOrReplace oder Add ist.
      • condition (optional)
        • Eine Zeichenfolge mit einem Azure Policy-Sprachausdruck und Richtlinienfunktionen, der true oder false ergibt.
        • Die folgenden Richtlinienfunktionen werden nicht unterstützt: field(), resourceGroup(), subscription()

Vorgänge für „Modify“

Das operations-Eigenschaftenarray ermöglicht es, mehrere Tags auf unterschiedliche Weise aus einer einzelnen Richtliniendefinition zu ändern. Jeder Vorgang besteht aus den Eigenschaften operation, field und value. „Operation“ bestimmt, wie die Wartungsaufgabe mit den Tags verfährt, „field“ bestimmt, welches Tag geändert wird und „value“ definiert die neue Einstellung für dieses Tag. Im folgenden Beispiel werden die folgenden Tag-Änderungen vorgenommen:

  • Legt das environment-Tag auf „Test“ fest, auch wenn es bereits mit einem anderen Wert vorhanden ist.
  • Entfernt das Tag TempResource.
  • Legt das Dept-Tag auf den Richtlinienparameter DeptName fest, der bei der Richtlinienzuweisung konfiguriert wurde.
"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

Die operation-Eigenschaft hat die folgenden Optionen:

Vorgang BESCHREIBUNG
addOrReplace Fügt die definierte Eigenschaft oder das definierte Tag und den Wert zur Ressource hinzu, auch wenn die Eigenschaft oder das Tag bereits mit einem anderen Wert vorhanden ist.
Hinzufügen Fügt der Ressource die definierte Eigenschaft oder das definierte Tag und den Wert hinzu.
Remove (Entfernen) Entfernt die definierte Eigenschaft oder das definierte Tag aus der Ressource.

Beispiele für „Modify“

Beispiel 1: Fügen Sie das environment-Tag hinzu, und ersetzen Sie vorhandene environment-Tags durch „Test“:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "Test"
            }
        ]
    }
}

Beispiel 2: Entfernen Sie das env-Tag, und fügen Sie das environment-Tag hinzu oder ersetzen Sie vorhandene environment-Tags durch einen parametrisierten Wert:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "conflictEffect": "deny",
        "operations": [
            {
                "operation": "Remove",
                "field": "tags['env']"
            },
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "[parameters('tagValue')]"
            }
        ]
    }
}

Beispiel 3: Sicherstellen, dass ein Speicherkonto keinen öffentlichen Zugriff auf Blobs zulässt. Der Modify-Vorgang wird nur bei der Auswertung von Anforderungen mit einer API-Version größer oder gleich 2019-04-01 angewendet:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
        ],
        "conflictEffect": "audit",
        "operations": [
            {
                "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
                "operation": "addOrReplace",
                "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "value": false
            }
        ]
    }
}

Mutate (Vorschau)

Eine Mutation wird in Azure Policy für Kubernetes verwendet, um AKS-Clusterkomponenten (beispielsweise Pods) zu korrigieren. Diese Auswirkung gilt nur für Definitionen des RichtlinienmodusMicrosoft.Kubernetes.Data.

Weitere Informationen finden Sie unter Grundlegendes zu Azure Policy für Kubernetes-Cluster.

Mutate-Eigenschaften

  • mutationInfo (optional)
    • Kann nicht mit constraint, constraintTemplate, apiGroups oder kinds verwendet werden.
    • Kann nicht parametrisiert werden.
    • sourceType (erforderlich)
      • Definiert den Typ der Quelle für die Einschränkung. Zulässige Werte: PublicURL oder Base64Encoded.
      • Bei PublicURL kombiniert mit der Eigenschaft url, um den Speicherort der Mutationsvorlage anzugeben. Auf den Speicherort muss öffentlich zugegriffen werden können.

        Warnung

        Verwenden Sie keine SAS-URIs oder Token in url oder andere Elemente, die ein Geheimnis offenlegen könnten.

Schichten von Richtliniendefinitionen

Eine Ressource kann von mehreren Zuweisungen betroffen sein. 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.
  • Jede neue Ressource in Abonnement A, die nicht am Standort „westus“ erstellt wird, wird von Richtlinie 1 abgelehnt.
  • 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.
  • Jede neue Ressource in Abonnement A, die nicht am Standort „westus“ erstellt wird, wird von Richtlinie 1 abgelehnt.
  • 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 durch die sich überschneidenden und konfliktverursachenden 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