Freigeben über

Auswirkung „modify“ von Azure Policy-Definitionen

  • Artikel

Die Auswirkung 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. Bestehende, nicht konforme Ressourcen können ebenfalls mit einem Wartungstask bereinigt werden. Richtlinienzuweisungen, deren Auswirkung auf "modify" festgelegt ist, erfordern für das Durchführen von Korrekturmaßnahmen eine verwaltete Identität. Ein gängiges Beispiel für die Verwendung der modify-Auswirkung ist die Aktualisierung von Tags für Ressourcen wie „costCenter“.

Es gibt einige Nuancen beim Änderungsverhalten für Ressourceneigenschaften. Erfahren Sie mehr über Szenarien, bei denen Änderungen übersprungen werden.

Eine einzelne modify-Regel kann eine beliebige Anzahl von Vorgängen aufweisen. Folgende Vorgänge werden unterstützt:

  • Hinzufügen, Ersetzen oder Entfernen von Ressourcentags. Es können nur Tags entfernt werden. 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. Der identity.type kann nur für VMs oder Virtual Machine Scale Sets geändert werden.
  • 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.

Wenn ein Alias angegeben wird, werden weitere Ü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 „Ändern“, die Aliase enthalten, Überprüfung Konfliktauswirkungverwenden. Damit wird vermieden, dass Anfragen mit API-Versionen fehlschlagen, bei denen die zugeordnete Eigenschaft nicht änderbar ist. 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.

Übersprungene Änderung

Es gibt einige Fälle, in denen Änderungsvorgänge während der Auswertung übersprungen werden:

  • Vorhandene Ressourcen: Wenn eine Richtliniendefinition mit der Auswirkung modify im Rahmen eines Auswertungszyklus ausgeführt wird, werden keine Änderungen an bereits vorhandenen Ressourcen vorgenommen. Stattdessen wird jede Ressource, die die if-Bedingung erfüllt, als nicht konform markiert, sodass sie durch einen Wartungstask bereinigt werden können.
  • n/v: Wenn die Bedingung eines Vorgangs im Array operations als falsch ausgewertet wird, wird dieser bestimmte Vorgang übersprungen.
  • Eigenschaft kann nicht geändert werden: Wenn ein für einen Vorgang angegebener Alias in der API-Version der Anforderung nicht geändert werden kann, verwendet die Auswertung die Konfliktauswirkung. Wenn der Konflikteffekt auf Verweigern festgelegt ist, wird die Anforderung blockiert. Wenn die Konfliktauswirkung Überwachen festgelegt ist, ist die Anforderung zulässig, der modify-Vorgang wird jedoch übersprungen.
  • Eigenschaft nicht vorhanden: Wenn eine Eigenschaft in der Ressourcennutzlast der Anforderung nicht vorhanden ist, wird die Änderung u. U. übersprungen. In einigen Fällen werden modifizierbare Eigenschaften in anderen Eigenschaften verschachtelt und weisen einen Alias wie Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled auf. Wenn die Eigenschaft „parent“ in diesem Fall deleteRetentionPolicy nicht in der Anforderung vorhanden ist, wird die Änderung übersprungen, da diese Eigenschaft angenommen wird, absichtlich weggelassen wird. Ein praktisches Beispiel finden Sie im Abschnitt Beispiel für „Eigenschaft nicht vorhanden“.
  • Kein Vorgang für VM- oder VMSS-Identität: Wenn ein Änderungsvorgang versucht, das Feld identity.type für eine andere Ressource als eine virtuelle Maschine oder eine Virtual Machine Scale Set-Instanz hinzuzufügen oder zu ersetzen, wird die Richtlinienauswertung vollständig übersprungen, sodass die Änderung nicht durchgeführt wird. In diesem Fall gilt die Ressource als nicht anwendbar für die Richtlinie.

Beispiel für „Eigenschaft nicht vorhanden“

Die Änderung der Ressourceneigenschaften hängt von der API-Anforderung und der aktualisierten Ressourcennutzlast ab. Die Nutzlast kann vom verwendeten Client (z. B. Azure-Portal) und anderen Faktoren wie dem Ressourcenanbieter abhängen.

Stellen Sie sich vor, Sie wenden eine Richtlinie an, die Tags für einen virtuellen Computer (VM) ändert. Jedes Mal, wenn der virtuelle Computer aktualisiert wird (etwa während der Größenänderung oder Datenträgeränderungen), werden die Tags unabhängig vom Inhalt der VM-Nutzlast entsprechend aktualisiert. Dies liegt daran, dass Tags von den VM-Eigenschaften unabhängig sind.

Wenn Sie jedoch eine Richtlinie anwenden, die Eigenschaften auf einem virtuellen Computer ändert, hängt die Änderung von der Ressourcennutzlast ab. Wenn Sie versuchen, Eigenschaften zu ändern, die nicht in der Updatenutzlast enthalten sind, erfolgt die Änderung nicht. Dies kann beispielsweise passieren, wenn Sie die assessmentMode-Eigenschaft eines virtuellen Computers (Alias Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration.patchSettings.assessmentMode) patchen. Die Eigenschaft ist „geschachtelt“. Wenn die übergeordneten Eigenschaften also nicht in der Anforderung enthalten sind, wird davon ausgegangen, dass diese Auslassung beabsichtigt ist, und die Änderung wird übersprungen. Damit die Änderung vorgenommen wird, sollte die Ressourcennutzlast diesen Kontext enthalten.

Eigenschaften von „Modify“

Die details-Eigenschaft der Auswirkung modify enthält alle Untereigenschaften, die die erforderlichen Berechtigungen für die Wartung definieren, und die operations, 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. Richtliniendefinitionen mit audit überspringen alle Vorgänge (operations). 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. Die Optionen sind addOrReplace, Add und Remove.
        • Addverhält sich ähnlich wie der Append-Effekt.
        • Remove wird nur für Ressourcentags unterstützt.
      • 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 operation auf addOrReplace oder Add festgelegt 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 in 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 verfügt über folgende 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.
add Fügt der Ressource die definierte Eigenschaft oder das definierte Tag und den Wert hinzu.
remove Entfernt das definierte Tag aus der Ressource. Wird nur für Tags unterstützt.

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
      }
    ]
  }
}

Nächste Schritte