Comprendre les effets d’Azure Policy

Chaque définition de stratégie dans Azure Policy a un effet unique. Cet effet détermine ce qu’il se passe lorsque la règle de stratégie est évaluée pour une mise en correspondance. Les effets se comportent différemment selon qu’ils concernent une nouvelle ressource, une ressource mise à jour ou une ressource existante.

Une définition de stratégie prend en charge ces effets :

Effets interchangeables

Parfois, plusieurs effets peuvent être valides pour une définition de stratégie donnée. Les paramètres sont souvent utilisés pour spécifier les valeurs d’effet autorisées afin qu’une définition unique puisse être plus polyvalente. Toutefois, il est important de noter que tous les effets ne sont pas interchangeables. Les propriétés de ressource et la logique dans la règle de stratégie peuvent déterminer si un certain effet est considéré comme valide pour la définition de stratégie. Par exemple, les définitions de stratégie avec effet AuditIfNotExists nécessitent d’autres détails dans la règle de stratégie qui ne sont pas requis pour les stratégies avec effet Audit. Les effets se comportent également différemment. Les stratégies d’audit évaluent la conformité d’une ressource en fonction de ses propres propriétés, tandis que les stratégies AuditIfNotExists évaluent la conformité d’une ressource en fonction des propriétés d’une ressource enfant ou d’extension.

La liste suivante présente des conseils généraux sur les effets interchangeables :

  • Audit, Denyet Modify ou Append sont souvent interchangeables.
  • AuditIfNotExists et DeployIfNotExists sont souvent interchangeables .
  • Manuel n’est pas interchangeable.
  • Désactivé est interchangeable avec n’importe quel effet.

Ordre d’évaluation

Les demandes de création ou de mise à jour d’une ressource sont évaluées en premier par Azure Policy. Azure Policy répertorie toutes les affectations qui s’appliquent à la ressource, puis évalue la ressource en fonction de chaque définition. Pour un mode Fournisseur de ressources, Azure Policy traite plusieurs des effets avant de transmettre la demande au fournisseur de ressources approprié. Cet ordre empêche un fournisseur de ressources d’effectuer un traitement inutile d’une ressource quand elle ne satisfait pas aux contrôles de gouvernance d’Azure Policy. Avec un mode Fournisseur de ressources, le fournisseur de ressources gère l’évaluation et le résultat, et renvoie les résultats à Azure Policy.

  • Disabled est coché en premier pour déterminer si la règle de stratégie doit être évaluée.
  • Append et Modify sont ensuite évalués. Les deux pouvant modifier la requête, une modification peut empêcher le déclenchement d’un effet d’audit ou de refus. Ces effets sont disponibles uniquement avec un mode Gestionnaire des ressources.
  • Deny est ensuite évalué. L’évaluation de Deny avant Audit empêche la double journalisation d’une ressource indésirable.
  • Audit est évalué.
  • Manual est évalué.
  • AuditIfNotExists est évalué.
  • denyAction est évalué en dernier.

Une fois que le Fournisseur de ressources retourne un code de réussite sur une requête en mode Gestionnaire des ressources, AuditIfNotExists et DeployIfNotExists effectuent une évaluation pour déterminer si une journalisation ou une action de conformité supplémentaire est requise.

Les demandes PATCH qui modifient uniquement les champs associés à tags limitent l’évaluation de la stratégie aux stratégies contenant des conditions qui inspectent les champs associés à tags.

AddToNetworkGroup

AddToNetworkGroup est utilisé dans Azure Virtual Network Manager pour définir l’appartenance dynamique au groupe de réseaux. Cet effet est spécifique aux définitions de mode de stratégieMicrosoft.Network.Data uniquement.

Avec les groupes réseau, votre définition de stratégie inclut votre expression conditionnelle pour les réseaux virtuels correspondants répondant à vos critères et spécifie le groupe de réseaux de destination où toutes les ressources correspondantes sont placées. L’effet addToNetworkGroup est utilisé pour placer des ressources dans le groupe de réseaux de destination.

Pour en savoir plus, accédez à Configuration d’Azure Policy avec des groupes de réseaux dans Azure Virtual Network Manager.

Ajouter

Append permet d’ajouter plus de champs à la ressource demandée lors de la création ou de la mise à jour. Un exemple courant consiste à spécifier des adresses IP autorisées pour une ressource de stockage.

Important

Append est destiné à être utilisé avec des propriétés autres que des étiquettes. Même si Append peut ajouter des étiquettes à une ressource dans le cadre d’une requête de création ou de mise à jour, il est recommandé d’utiliser l’effet Modify pour les étiquettes.

Évaluation Append

L’évaluation Append se produit avant que la requête ne soit traitée par un fournisseur de ressources lors de la création ou de la mise à jour d’une ressource. Append ajoute des champs à la ressource lorsque la condition if de la règle de stratégie est remplie. Si l’effet Append remplace une valeur dans la requête d’origine avec une valeur différente, il agit comme un effet Deny et rejette la demande. Pour ajouter une nouvelle valeur à un tableau existant, utilisez la version [[*]] de l’alias.

Lorsqu’une définition de stratégie utilisant l’effet Append est exécutée dans le cadre d’un cycle d’évaluation, elle n’apporte pas de modifications aux ressources qui existent déjà. Au lieu de cela, elle marque comme non conforme toute ressource qui répond à la condition if.

Propriétés d’Append

Un effet Append prend en charge la propriété obligatoire details uniquement, laquelle est un tableau de données. En tant que tableau, details peut contenir une ou plusieurs paires champ/valeur. Reportez-vous à la structure de définition pour afficher la liste des champs autorisés.

Exemples Append

Exemple 1 : paire champ/valeur unique utilisant un alias non [*] avec un tableau value afin de définir des règles IP sur un compte de stockage. Lorsque l’alias non [*] est un tableau, l’effet ajoute la value comme tableau entier. Si le tableau existe déjà, un événement de refus se produit à partir du conflit.

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

Exemple 2 : paire champ/valeur unique utilisant un alias[*] avec un tableau value afin de définir des règles IP sur un compte de stockage. En utilisant l’alias [*], l’effet ajoute la valeur à un groupe potentiellement préexistant. Si le tableau n’existe pas encore, il est créé.

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

Audit

Audit permet de créer un événement d’avertissement dans le journal d’activité lors de l’évaluation d’une ressource non conforme, mais il n’arrête pas la requête.

Évaluation Audit

Audit est le dernier effet vérifié par Azure Policy pendant la création ou la mise à jour d’une ressource. Pour un mode Gestionnaire des ressources, Azure Policy envoie ensuite la ressource au fournisseur de ressources. Lors de l’évaluation d’une requête de création ou de mise à jour pour une ressource, Azure Policy ajoute une opération Microsoft.Authorization/policies/audit/action au journal d’activité et marque la ressource comme non conforme. Pendant un cycle d’évaluation de conformité standard, seul l’état de conformité de la ressource est mis à jour.

Propriétés d’Audit

Pour un mode Gestionnaire des ressources, l’effet d’audit n’a pas d’autres propriétés utilisables dans la condition then de la définition de stratégie.

Pour un mode Fournisseur de ressources de Microsoft.Kubernetes.Data, l’effet audit contient les sous-propriétés de details suivantes. L’utilisation de templateInfo est requise pour les définitions de stratégie nouvelles ou mises à jour, compte tenu du fait que constraintTemplate est déconseillé.

  • templateInfo (requis)
    • Impossible à utiliser avec constraintTemplate.
    • sourceType (requis)
      • Définit le type de source pour le modèle de contrainte. Valeurs autorisées : PublicURL ou Base64Encoded.

      • Si PublicURL, associé à la propriété url pour fournir l’emplacement du modèle de contrainte. L'emplacement doit être accessible publiquement.

        Avertissement

        N’utilisez pas d’URI SAS, de jetons d’URL ou d’autres éléments susceptibles d’exposer des secrets en texte brut.

      • Si Base64Encoded, associé à la propriété content pour fournir le modèle de contrainte encodé en base 64. Consultez Créer une définition de stratégie à partir d’un modèle de contrainte pour créer une définition personnalisée à partir d’un modèle de contrainteOpen Policy Agent (OPA) Gatekeeper v3.

  • constraint (déconseillée)
    • Impossible à utiliser avec templateInfo.
    • Implémentation CRD du modèle de contrainte. Utilise des paramètres transmis via des valeurs telles que {{ .Values.<valuename> }}. Dans l’exemple 2 ci-dessous, ces valeurs sont {{ .Values.excludedNamespaces }} et {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (déconseillé)
    • Impossible à utiliser avec templateInfo.
    • Doit être remplacé par templateInfo lors de la création ou de la mise à jour d’une définition de stratégie.
    • Modèle de contrainte CustomResourceDefinition (CRD) qui définit de nouvelles contraintes. Le modèle définit la logique Rego, le schéma de contrainte et les paramètres de contrainte transmis via des objets values (valeurs) d’Azure Policy. Pour plus d’informations, consultez Contraintes Gatekeeper.
  • constraintInfo (facultatif)
    • Ne peut pas être utilisé avec constraint, constraintTemplate, apiGroups, kinds, scope, namespaces, excludedNamespaces, ou labelSelector.
    • Si constraintInfo n’est pas fourni, la contrainte peut être générée à partir de templateInfo et de la stratégie.
    • sourceType (requis)
      • Définit le type de source pour la contrainte. Valeurs autorisées : PublicURL ou Base64Encoded.

      • Si PublicURL, associée à la propriété url pour fournir l’emplacement de la contrainte. L'emplacement doit être accessible publiquement.

        Avertissement

        N’utilisez pas d’URI ou de jetons SAS dans url ou tout autre élément susceptible d’exposer un secret.

  • namespaces (facultatif)
    • Tableau des espaces de noms Kubernetes auxquels limiter l’évaluation de la stratégie.
    • En cas de valeur vide ou manquante, l’évaluation de la stratégie inclut tous les espaces de noms non définis dans excludedNamespaces.
  • excludedNamespaces (facultatif)
  • labelSelector (facultatif)
    • Objet qui inclut des propriétés matchLabels (objet) et MatchExpression (tableau) pour permettre de spécifier les ressources Kubernetes à inclure pour l’évaluation de stratégie correspondant aux étiquettes et aux sélecteurs fournis.
    • En cas de valeur vide ou manquante, l’évaluation de la stratégie inclut tous les sélecteurs et étiquettes, à l’exception de espaces de noms définis dans excludedNamespaces.
  • Étendue (facultatif)
    • Une chaîne contenant la propriété étendue pour permettre de spécifier si les ressources étendues au cluster ou à l’espace de noms sont mises en correspondance.
  • apiGroups (requis en cas d’utilisation de templateInfo)
    • Tableau qui inclut les groupes d’API à mettre en correspondance. Un tableau vide ([""]) correspond au groupe d’API principal.
    • La définition de ["*"] pour apiGroups n’est pas autorisée.
  • kinds (requis en cas d’utilisation de templateInfo)
    • Tableau qui inclut le type d’objet Kubernetes auquel limiter l’évaluation.
    • La définition de ["*"] pour kinds n’est pas autorisée.
  • values (facultatif)
    • Définit des paramètres et valeurs à transmettre à la contrainte. Chaque valeur doit exister et correspondre à une propriété dans la section de validation openAPIV3Schema du CRD du modèle de contrainte.

Exemple Audit

Exemple 1 : Utilisation de l’effet audit pour les modes Gestionnaire des ressources.

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

Exemple 2 : Utilisation de l’effet audit pour le mode Fournisseur de ressources Microsoft.Kubernetes.Data. Les informations supplémentaires contenues dans details.templateInfo déclarent l’utilisation de PublicURL et définissent url sur l’emplacement du modèle de contrainte à utiliser dans Kubernetes pour limiter les images de conteneur autorisées.

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

AuditIfNotExists

AuditIfNotExists active l’audit de ressources liées à la ressource qui correspond à la condition if, mais dont les propriétés ne sont pas spécifiées dans les détails (details) de la condition then.

Évaluation AuditIfNotExists

AuditIfNotExists s’exécute après qu’un fournisseur de ressources a traité une requête de création ou de mise à jour de ressource et a renvoyé un code d’état de réussite. L’effet Audit est déclenché s’il n’existe pas de ressources connexes ou si les ressources définies par ExistenceCondition ne retournent pas de valeur true. Pour les nouvelles ressources et celles mises à jour, Azure Policy ajoute une opération Microsoft.Authorization/policies/audit/action dans le journal d’activité et marque la ressource comme non conforme. Dans ce cas, la ressource qui a rempli la condition if est en fait la ressource qui est marquée comme non conforme.

Propriétés d’AuditIfNotExists

La propriété details des effets AuditIfNotExists possède toutes les sous-propriétés qui définissent les ressources connexes testées.

  • Type (obligatoire)
    • Spécifie le type de la ressource connexe à évaluer.
    • Si type est un type de ressource sous la ressource de condition if, la stratégie envoie des requêtes pour les ressources de ce type dans l’étendue de la ressource évaluée. Sinon, les requêtes de stratégie dans le même groupe de ressources ou abonnement que la ressource évaluée en fonction de l’existenceScope.
  • Name (facultatif)
    • Spécifie le nom exact de la ressource à tester et amène la stratégie à extraire une ressource spécifique au lieu de toutes les ressources du type spécifié.
    • Lorsque les valeurs de condition pour if.field.type et then.details.type correspondent, Name devient required et doit être [field('name')], ou [field('fullName')] pour une ressource enfant. Toutefois, un effet audit doit être considéré à la place.

Remarque

Les segments Type et Nom peuvent être combinés pour récupérer génériquement des ressources imbriquées.

Pour récupérer une ressource spécifique, vous pouvez utiliser "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" et "name": "parentResourceName/nestedResourceName".

Pour récupérer une collection de ressources imbriquées, un caractère ? générique peut être fourni à la place du segment de nom. Par exemple : "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" et "name": "parentResourceName/?". Cela peut être combiné avec des fonctions de champ pour accéder aux ressources liées à la ressource évaluée, telles que "name": "[concat(field('name'), '/?')]". »

  • ResourceGroupName (facultatif)
    • Permet l’évaluation de la ressource connexe provenant d’un groupe de ressources différent.
    • Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
    • La valeur par défaut est le groupe de ressources de la ressource de condition if.
  • ExistenceScope (facultatif)
    • Les valeurs autorisées sont Subscription et ResourceGroup.
    • Définit la portée d’où la ressource connexe évaluée est extraite.
    • Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
    • Pour ResourceGroup, ne considérerait que le groupe de ressources dans ResourceGroupName, si spécifié. Si ResourceGroupName n’est pas spécifié, ne considère que le groupe de ressources de la ressource de condition if, qui est le comportement par défaut.
    • Pour Subscription, le traitement interroge l’abonnement entier pour la ressource associée. L’étendue d’affectation doit être définie au niveau de l’abonnement ou supérieur pour une évaluation appropriée.
    • La valeur par défaut est ResourceGroup.
  • EvaluationDelay (facultatif)
    • Spécifie à quel moment l’existence des ressources associées doit être évaluée. Le délai est utilisé uniquement pour les évaluations qui résultent d’une requête de création ou de mise à jour de ressource.
    • Les valeurs autorisées sont AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure ou une durée ISO 8601 comprise entre 0 et 360 minutes.
    • Les valeurs AfterProvisioning inspectent le résultat du provisionnement de la ressource qui a été évaluée dans la condition IF de la règle de stratégie. AfterProvisioning s’exécute une fois le provisionnement terminé, quel que soit le résultat. Si le provisionnement prend plus de 6 heures, il est considéré comme un échec lors de la détermination des délais d’évaluation de AfterProvisioning.
    • La valeur par défaut est PT10M (10 minutes).
    • La spécification d’un délai d’évaluation long peut empêcher la mise à jour de l’état de conformité enregistré de la ressource jusqu’au prochain déclencheur d’évaluation.
  • ExistenceCondition (facultatif)
    • Si elle n’est pas spécifiée, toute ressource connexe du type remplit les conditions de l’effet et ne déclenche pas l’audit.
    • Utilise la même langue que la règle de stratégie pour la condition if mais est évaluée individuellement sur chaque ressource associée.
    • Si une ressource connexe correspondante renvoie true, l’effet est satisfait et ne déclenche pas l’audit.
    • Peut utiliser [field()] pour vérifier l’équivalence des valeurs dans la condition if.
    • Par exemple, permet de vérifier que la ressource parent (dans la condition if) réside dans le même emplacement de la ressource en tant que ressource connexe correspondante.

Exemple AuditIfNotExists

Exemple : évalue les machines virtuelles pour déterminer si l’extension Antimalware existe, puis effectue un audit si l’extension est absente.

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

Deny

Deny empêche l’exécution d’une requête de ressource qui ne correspond pas aux normes définies via une définition de stratégie et qui fait échouer la requête.

Évaluation Deny

Lors de la création ou de la mise à jour d’une ressource correspondante dans un mode Gestionnaire des ressources, deny empêche l’envoi de la demande au fournisseur de ressources. La requête renvoie une erreur 403 (Forbidden). Dans le portail, l’erreur 403 (Interdit) peut être considérée comme l’état du déploiement qui a été empêché par l’affectation de stratégie. Pour un mode Fournisseur de ressources, le fournisseur de ressources gère l’évaluation de la ressource.

Lors de l’évaluation des ressources existantes, les ressources qui correspondent à une définition de stratégie Deny sont marquées comme non conformes.

Propriétés de Deny

Pour un mode Gestionnaire des ressources, l’effet deny n’a pas d’autres propriétés utilisables dans la condition then de la définition de stratégie.

Pour un mode Fournisseur de ressources de Microsoft.Kubernetes.Data, l’effet deny contient les sous-propriétés de details suivantes. L’utilisation de templateInfo est requise pour les définitions de stratégie nouvelles ou mises à jour, compte tenu du fait que constraintTemplate est déconseillé.

  • templateInfo (requis)
    • Impossible à utiliser avec constraintTemplate.
    • sourceType (requis)
      • Définit le type de source pour le modèle de contrainte. Valeurs autorisées : PublicURL ou Base64Encoded.

      • Si PublicURL, associé à la propriété url pour fournir l’emplacement du modèle de contrainte. L'emplacement doit être accessible publiquement.

        Avertissement

        N’utilisez pas d’URI ou de jetons SAS dans url ou tout autre élément susceptible d’exposer un secret.

      • Si Base64Encoded, associé à la propriété content pour fournir le modèle de contrainte encodé en base 64. Consultez Créer une définition de stratégie à partir d’un modèle de contrainte pour créer une définition personnalisée à partir d’un modèle de contrainteOpen Policy Agent (OPA) Gatekeeper v3.

  • constraint (facultatif)
    • Impossible à utiliser avec templateInfo.
    • Implémentation CRD du modèle de contrainte. Utilise des paramètres transmis via des valeurs telles que {{ .Values.<valuename> }}. Dans l’exemple 2 ci-dessous, ces valeurs sont {{ .Values.excludedNamespaces }} et {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (déconseillé)
    • Impossible à utiliser avec templateInfo.
    • Doit être remplacé par templateInfo lors de la création ou de la mise à jour d’une définition de stratégie.
    • Modèle de contrainte CustomResourceDefinition (CRD) qui définit de nouvelles contraintes. Le modèle définit la logique Rego, le schéma de contrainte et les paramètres de contrainte transmis via des objets values (valeurs) d’Azure Policy. Pour plus d’informations, consultez Contraintes Gatekeeper.
  • constraintInfo (facultatif)
    • Ne peut pas être utilisé avec constraint, constraintTemplate, apiGroups ou kinds.
    • Si constraintInfo n’est pas fourni, la contrainte peut être générée à partir de templateInfo et de la stratégie.
    • sourceType (requis)
      • Définit le type de source pour la contrainte. Valeurs autorisées : PublicURL ou Base64Encoded.

      • Si PublicURL, associée à la propriété url pour fournir l’emplacement de la contrainte. L'emplacement doit être accessible publiquement.

        Avertissement

        N’utilisez pas d’URI ou de jetons SAS dans url ou tout autre élément susceptible d’exposer un secret.

  • namespaces (facultatif)
    • Tableau des espaces de noms Kubernetes auxquels limiter l’évaluation de la stratégie.
    • En cas de valeur vide ou manquante, l’évaluation de la stratégie inclut tous les espaces de noms, à l’exception de ceux définis dans excludedNamespaces.
  • excludedNamespaces (requis)
  • labelSelector (requis)
    • Objet qui inclut des propriétés matchLabels (objet) et MatchExpression (tableau) pour permettre de spécifier les ressources Kubernetes à inclure pour l’évaluation de stratégie correspondant aux étiquettes et aux sélecteurs fournis.
    • En cas de valeur vide ou manquante, l’évaluation de la stratégie inclut tous les sélecteurs et étiquettes, à l’exception de espaces de noms définis dans excludedNamespaces.
  • apiGroups (requis en cas d’utilisation de templateInfo)
    • Tableau qui inclut les groupes d’API à mettre en correspondance. Un tableau vide ([""]) correspond au groupe d’API principal.
    • La définition de ["*"] pour apiGroups n’est pas autorisée.
  • kinds (requis en cas d’utilisation de templateInfo)
    • Tableau qui inclut le type d’objet Kubernetes auquel limiter l’évaluation.
    • La définition de ["*"] pour kinds n’est pas autorisée.
  • values (facultatif)
    • Définit des paramètres et valeurs à transmettre à la contrainte. Chaque valeur doit exister dans le modèle de contrainte CRD.

Exemple Deny

Exemple 1 : Utilisation de l’effet deny pour les modes Gestionnaire des ressources.

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

Exemple 2 : Utilisation de l’effet deny pour le mode Fournisseur de ressources Microsoft.Kubernetes.Data. Les informations supplémentaires contenues dans details.templateInfo déclarent l’utilisation de PublicURL et définissent url sur l’emplacement du modèle de contrainte à utiliser dans Kubernetes pour limiter les images de conteneur autorisées.

"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 est utilisé pour bloquer les demandes en fonction de l’action prévue sur les ressources à l’échelle. La seule action prise en charge aujourd’hui est DELETE. Cet effet et ce nom d’action permet d’éviter toute suppression accidentelle de ressources critiques.

Évaluation DenyAction

Lorsqu’un appel de demande avec un nom d’action applicable et une étendue ciblée est envoyé, denyAction empêche la demande de réussir. La requête renvoie une erreur 403 (Forbidden). Dans le portail, l’erreur 403 (Interdit) peut être considérée comme l’état du déploiement qui a été empêché par l’affectation de stratégie.

Microsoft.Authorization/policyAssignments, Microsoft.Authorization/denyAssignments, Microsoft.Blueprint/blueprintAssignments, Microsoft.Resources/deploymentStacks, Microsoft.Resources/subscriptions et Microsoft.Authorization/locks sont tous exemptés de l’application DenyAction pour empêcher les scénarios de verrouillage.

Suppression de l’abonnement

La stratégie ne bloque pas la suppression des ressources qui se produit lors d’une suppression d’abonnement.

Suppression du groupe de ressources

La stratégie évalue les ressources qui prennent en charge l’emplacement et les balises par rapport aux DenyAction stratégies lors d’une suppression de groupe de ressources. Seules les stratégies qui ont la cascadeBehaviors valeur définie deny sur dans la règle de stratégie bloquent la suppression d’un groupe de ressources. La stratégie ne bloque pas la suppression des ressources qui ne prennent pas en charge l’emplacement et les balises, ni aucune stratégie avec mode:all.

Suppression en cascade

La suppression en cascade se produit lorsque la suppression d’une ressource parente supprime implicitement toutes ses ressources enfants. La stratégie ne bloque pas la suppression des ressources enfants lorsqu’une action de suppression cible les ressources parentes. Par exemple, Microsoft.Insights/diagnosticSettings est une ressource enfant de Microsoft.Storage/storageaccounts. Si une denyAction stratégie cible Microsoft.Insights/diagnosticSettings, un appel de suppression au paramètre de diagnostic (enfant) échoue, mais une suppression du compte de stockage (parent) supprime implicitement le paramètre de diagnostic (enfant).

Ce tableau indique si une ressource sera protégée contre la suppression compte tenu de la ressource applicable à la stratégie denyAction affectée et de l’étendue ciblée de l’appel DELETE. Dans le contexte de cette table, une ressource indexée est une ressource qui prend en charge les balises et les emplacements, et une ressource non indexée est une ressource qui ne prend pas en charge les étiquettes ou les emplacements. Pour plus d’informations sur les ressources indexées et non indexées, reportez-vous aux modes de définition. Les ressources enfants sont des ressources qui existent uniquement dans le contexte d’une autre ressource. Par exemple, une ressource d’extension de machines virtuelles est un enfant de la machine virtuelle, qui est la ressource parente.

Entité en cours de suppression Entité applicable aux conditions de stratégie Action entreprise
Ressource Ressource Protected
Abonnement Ressource Deleted
Resource group Ressource indexée Dépend de cascadeBehaviors
Resource group Ressource non indexée Deleted
Ressource enfant Ressource parent Le parent est protégé ; l’enfant est supprimé
Ressource parent Ressource enfant Deleted

Propriétés DenyAction

La propriété détails de l'effet DenyAction comporte toutes les sous-propriétés qui définissent l’action et les comportements.

  • actionNames (obligatoire)
    • Tableau qui spécifie les actions à empêcher d’être exécutées.
    • Voici les noms d’action pris en charge : delete.
  • cascadeBehaviors (facultatif)
    • Objet qui définit le comportement qui sera suivi lorsque la ressource est supprimée implicitement par la suppression d’un groupe de ressources.
    • Pris en charge uniquement dans les définitions de stratégie avec le mode défini sur indexed.
    • Valeurs autorisées : allow ou deny.
    • La valeur par défaut est deny.

Exemple DenyAction

Exemple : refusez tout appel de suppression ciblant des comptes de base de données dont l’environnement de balise est égal à prod. Étant donné que le comportement en cascade est défini sur deny, bloquez tout appel DELETE qui cible un groupe de ressources avec un compte de base de données applicable.

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

DeployIfNotExists

Comme pour AuditIfNotExists, une définition de stratégie DeployIfNotExists exécute un déploiement de modèle lorsque la condition est remplie. Les affectations de stratégie dont l’effet est défini sur DeployIfNotExists nécessitent une identité managée pour effectuer une correction.

Notes

Les modèles imbriqués sont pris en charge avec deployIfNotExists, mais les modèles liés ne sont actuellement pas pris en charge.

Évaluation DeployIfNotExists

DeployIfNotExists s’exécute après un délai configurable quand qu’un fournisseur de ressources traite une requête de création ou de mise à jour d’un abonnement ou d’une ressource et qu’il retourne un code d’état de réussite. Un déploiement de modèle est déclenché s’il n’existe pas de ressources connexes ou si les ressources définies par ExistenceCondition ne retournent pas de valeur true. La durée du déploiement dépend de la complexité des ressources incluses dans le modèle.

Au cours d’un cycle d’évaluation, les définitions de stratégie ayant un effet DeployIfNotExists sur les ressources sont marquées comme non conformes, mais aucune action n’est effectuée sur ces ressources. Les ressources non conformes existantes peuvent être corrigées à l’aide d’une tâche de correction.

Propriétés de DeployIfNotExists

La propriété details de l’effet DeployIfNotExists comprend toutes les sous-propriétés qui définissent les ressources connexes testées, ainsi que le déploiement de modèle à exécuter.

  • Type (obligatoire)
    • Spécifie le type de la ressource connexe à évaluer.
    • Si type est un type de ressource sous la ressource de condition if, la stratégie envoie des requêtes pour les ressources de ce type dans l’étendue de la ressource évaluée. Sinon, les requêtes de stratégie dans le même groupe de ressources ou abonnement que la ressource évaluée en fonction de l’existenceScope.
  • Name (facultatif)
    • Spécifie le nom exact de la ressource à tester et amène la stratégie à extraire une ressource spécifique au lieu de toutes les ressources du type spécifié.
    • Lorsque les valeurs de condition pour if.field.type et then.details.type correspondent, Name devient required et doit être [field('name')], ou [field('fullName')] pour une ressource enfant.

Remarque

Les segments Type et Nom peuvent être combinés pour récupérer génériquement des ressources imbriquées.

Pour récupérer une ressource spécifique, vous pouvez utiliser "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" et "name": "parentResourceName/nestedResourceName".

Pour récupérer une collection de ressources imbriquées, un caractère ? générique peut être fourni à la place du segment de nom. Par exemple : "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" et "name": "parentResourceName/?". Cela peut être combiné avec des fonctions de champ pour accéder aux ressources liées à la ressource évaluée, telles que "name": "[concat(field('name'), '/?')]". »

  • ResourceGroupName (facultatif)

    • Permet l’évaluation de la ressource connexe provenant d’un groupe de ressources différent.
    • Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
    • La valeur par défaut est le groupe de ressources de la ressource de condition if.
    • L’exécution d’un déploiement de modèle s’effectue dans le groupe de ressources de cette valeur.
  • ExistenceScope (facultatif)

    • Les valeurs autorisées sont Subscription et ResourceGroup.
    • Définit la portée d’où la ressource connexe évaluée est extraite.
    • Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
    • Pour ResourceGroup, ne considérerait que le groupe de ressources dans ResourceGroupName, si spécifié. Si ResourceGroupName n’est pas spécifié, ne considère que le groupe de ressources de la ressource de condition if, qui est le comportement par défaut.
    • Pour Subscription, le traitement interroge l’abonnement entier pour la ressource associée. L’étendue d’affectation doit être définie au niveau de l’abonnement ou supérieur pour une évaluation appropriée.
    • La valeur par défaut est ResourceGroup.
  • EvaluationDelay (facultatif)

    • Spécifie à quel moment l’existence des ressources associées doit être évaluée. Le délai est utilisé uniquement pour les évaluations qui résultent d’une requête de création ou de mise à jour de ressource.
    • Les valeurs autorisées sont AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure ou une durée ISO 8601 comprise entre 0 et 360 minutes.
    • Les valeurs AfterProvisioning inspectent le résultat du provisionnement de la ressource qui a été évaluée dans la condition IF de la règle de stratégie. AfterProvisioning s’exécute une fois le provisionnement terminé, quel que soit le résultat. Si le provisionnement prend plus de 6 heures, il est considéré comme un échec lors de la détermination des délais d’évaluation de AfterProvisioning.
    • La valeur par défaut est PT10M (10 minutes).
    • La spécification d’un délai d’évaluation long peut empêcher la mise à jour de l’état de conformité enregistré de la ressource jusqu’au prochain déclencheur d’évaluation.
  • ExistenceCondition (facultatif)

    • Si elle n’est pas spécifiée, toute ressource connexe de type satisfait à l’effet en question et ne déclenche pas le déploiement.
    • Utilise la même langue que la règle de stratégie pour la condition if mais est évaluée individuellement sur chaque ressource associée.
    • Si une ressource connexe correspondante renvoie true, l’effet est satisfait et ne déclenche pas le déploiement.
    • Peut utiliser [field()] pour vérifier l’équivalence des valeurs dans la condition if.
    • Par exemple, permet de vérifier que la ressource parent (dans la condition if) réside dans le même emplacement de la ressource en tant que ressource connexe correspondante.
  • roleDefinitionIds (obligatoire)

  • DeploymentScope (facultatif)

    • Les valeurs autorisées sont Subscription et ResourceGroup.
    • Définit le type de déploiement à déclencher. Subscription indique un déploiement au niveau de l’abonnement, ResourceGroup indique un déploiement dans un groupe de ressources.
    • Une propriété location doit être spécifiée dans Deployment pour les déploiements au niveau de l’abonnement.
    • La valeur par défaut est ResourceGroup.
  • Deployment (obligatoire)

    • Cette propriété doit inclure le déploiement de modèle complet, car elle est transmise à l’API PUT Microsoft.Resources/deployments. Pour plus d’informations, consultez l’API REST Deployments.
    • Les éléments Microsoft.Resources/deployments imbriqués dans le modèle doivent utiliser des noms uniques pour éviter tout conflit entre plusieurs évaluations de stratégie. Le nom du déploiement parent peut être utilisé comme partie du nom de déploiement imbriqué via [concat('NestedDeploymentName-', uniqueString(deployment().name))].

    Notes

    Toutes les fonctions à l’intérieur de la propriété Deployment sont évaluées en tant que composants du modèle, et non pas de la stratégie. La propriété parameters y fait exception car elle transmet les valeurs de la stratégie au modèle. Dans cette section, la propriété value sous le nom de paramètre du modèle permet d’effectuer la transmission de valeurs (voir fullDbName dans l’exemple DeployIfNotExists).

Exemple DeployIfNotExists

Exemple : évalue les bases de données SQL Server pour déterminer si transparentDataEncryption est activé. Sinon, un déploiement destiné à l’activer est exécuté.

"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')]"
          }
        }
      }
    }
  }
}

Désactivé

Cet effet peut s’avérer utile pour tester certaines situations ou lorsque la définition de stratégie a paramétré l’effet. Cette flexibilité permet de désactiver une seule affectation plutôt que de désactiver toutes les affectations de cette stratégie.

Notes

Les définitions de stratégie qui utilisent l’effet Disabled ont l’état de conformité par défaut Compliant après l’affectation.

enforcementMode, qui est défini au moment de l’affectation de stratégie, est une alternative à l’effet Disabled. Lorsque enforcementMode est Désactivé, les ressources sont toujours évaluées. La journalisation, notamment les journaux d’activité, et l’effet de stratégie ne se produisent pas. Pour plus d’informations, consultez Attribution de stratégie - Mode de mise en conformité.

Manuel

Le nouvel effet manual vous permet d’attester automatiquement la conformité des ressources ou des étendues. Contrairement aux autres définitions de stratégie qui recherchent activement l’évaluation, l’effet Manuel permet des modifications manuelles apportées à l’état de conformité. Pour modifier la conformité d’une ressource ou d’une étendue ciblée par une stratégie manuelle, vous devez créer une attestation. La meilleure pratique consiste à concevoir des stratégies manuelles qui ciblent l’étendue qui définit la limite des ressources dont la conformité a besoin d’être attestée.

Notes

La prise en charge de la stratégie manuelle est disponible via diverses initiatives de conformité réglementaire Microsoft Defender pour le cloud. Si vous êtes un client Microsoft Defender pour le cloud de niveau Premium, reportez-vous à la vue d’ensemble de l’expérience.

Actuellement, les initiatives de stratégie réglementaire suivantes incluent des définitions de stratégie contenant l’effet manuel :

  • FedRAMP Niveau élevé
  • 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

L’exemple suivant cible les abonnements Azure et définit l’état de conformité initial sur Unknown.

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

La propriété defaultState a trois valeurs possibles :

  • Inconnu : état initial et par défaut des ressources ciblées.
  • Conforme : la ressource est conforme selon vos normes de stratégie manuelles
  • Non conforme : la ressource n’est pas conforme selon vos normes de stratégie manuelles

Le moteur de conformité Azure Policy évalue toutes les ressources applicables à l’état par défaut spécifié dans la définition (Unknown si elle n’est pas spécifiée). Un état de conformité Unknown indique que vous devez attester manuellement l’état de conformité des ressources. Si l’état de l’effet n’est pas spécifié, il est défini par défaut sur Unknown. L’état de conformité Unknown indique que vous devez attester l’état de conformité vous-même.

La capture d’écran suivante montre comment une affectation de stratégie manuelle avec l’état Unknown apparaît dans le portail Azure :

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

Lorsqu’une définition de stratégie avec l’effet manual est affectée, vous pouvez définir les états de conformité des ressources ou étendues ciblées par le biais d’attestations personnalisées. Les attestations vous permettent également de fournir des informations supplémentaires facultatives sous la forme de métadonnées et de liens vers des preuves qui accompagnent l’état de conformité choisi. La personne qui attribue la stratégie manuelle peut recommander un emplacement de stockage par défaut pour la preuve en spécifiant la propriété evidenceStorages des métadonnées de l’affectation de stratégie.

Modifier

L’option Modifier est utilisée pour ajouter, mettre à jour ou supprimer les propriétés ou les étiquettes d’un abonnement ou d’une ressource lors d’une création ou d’une mise à jour. Un exemple courant consiste à mettre à jour les étiquettes des ressources telles que costCenter. Les ressources non conformes existantes peuvent être corrigées à l’aide d’une tâche de correction. Une même règle Modify peut avoir autant d’opérations que vous le souhaitez. Les affectations de stratégie dont l’effet est défini sur Modify nécessitent une identité managée pour effectuer une correction.

Les opérations suivantes sont prises en charge par Modify :

  • Ajouter, remplacer ou supprimer des étiquettes. Pour les étiquettes, mode doit être défini sur indexed dans la stratégie Modify, sauf si la ressource cible est un groupe de ressources.
  • Ajouter ou remplacer la valeur du type d’identité managée (identity.type) des machines virtuelles et des Virtual Machine Scale Sets. Vous pouvez uniquement modifier les identity.type machines virtuelles ou les groupes de machines virtuelles identiques.
  • Ajouter ou remplacer les valeurs de certains alias.
    • Utiliser Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } dans Azure PowerShell 4.6.0 ou une version ultérieure pour obtenir la liste des alias pouvant être utilisés avec Modify.

Important

Si vous gérez des balises, il est recommandé d’utiliser Modify plutôt qu’Append, car Modify fournit plus de types d’opérations, ainsi que la possibilité de corriger les ressources existantes. Toutefois, Append est recommandé si vous n’êtes pas en mesure de créer une identité managée ou si Modify ne prend pas encore en charge l’alias de la propriété de ressource.

Évaluation Modify

L’évaluation Modify a lieu avant que la requête ne soit traitée par un fournisseur de ressources lors de la création ou de la mise à jour d’une ressource. Les opérations Modify sont appliquées au contenu de la requête lorsque la condition if de la règle de stratégie est remplie. Chaque opération Modify peut spécifier une condition qui détermine le moment où elle est appliquée. Les opérations avec des évaluations de condition false sont ignorées.

Lorsqu’un alias est spécifié, les vérifications supplémentaires suivantes sont effectuées pour s’assurer que l’opération Modify ne modifie pas le contenu de la requête de manière à ce que le fournisseur de ressources le rejette :

  • La propriété à laquelle l’alias correspond est marquée comme « modifiable » dans la version d’API de la requête.
  • Le type de jeton dans l’opération Modify correspond au type de jeton attendu pour la propriété dans la version d’API de la requête.

Si l’une de ces vérifications échoue, l’évaluation de la stratégie revient à la sous-propriété conflictEffect spécifiée.

Important

Il est recommandé que les définitions de Modify qui incluent des alias utilisent la propriété d'effet de conflitaudit pour éviter l'échec des requêtes utilisant des versions d'API où la propriété mappée n'est pas « modifiable ». Si le même alias se comporte différemment entre les versions d’API, des opérations Modify conditionnelles peuvent être utilisées pour déterminer l’opération Modify utilisée pour chaque version de l’API.

Lorsqu’une définition de stratégie utilisant l’effet Modify est exécutée dans le cadre d’un cycle d’évaluation, elle n’apporte pas de modifications aux ressources qui existent déjà. Au lieu de cela, elle marque comme non conforme toute ressource qui répond à la condition if.

Propriétés de Modify

La propriété details de l’effet Modify comporte toutes les sous-propriétés qui définissent les autorisations nécessaires à la correction, ainsi que les opérations utilisées pour ajouter, mettre à jour ou supprimer les valeurs des étiquettes.

  • roleDefinitionIds (obligatoire)
    • Cette propriété doit inclure un tableau de chaînes qui correspondent aux ID de rôle de contrôle de l’accès en fonction du rôle accessibles par l’abonnement. Pour plus d’informations, consultez Correction - Configurer une définition de stratégie.
    • Le rôle défini doit inclure toutes les opérations accordées au rôle Contributeur.
  • conflictEffect (facultatif)
    • Détermine la définition de stratégie « wins » si plusieurs définitions de stratégie modifient la même propriété ou lorsque l’opération Modify ne fonctionne pas sur l’alias spécifié.
      • Pour les ressources nouvelles ou mises à jour, la définition de stratégie avec deny est prioritaire. Les définitions de stratégie avec audit ignorent toutes les opérations. Si plusieurs définitions de stratégie ont l’effet deny, la demande est refusée pour raison de conflit. Si toutes les définitions de stratégie ont audit, aucune des opérations des définitions de stratégie en conflit n’est traitée.
      • Pour les ressources existantes, si plusieurs définitions de stratégie ont l’effet deny, l’état de conformité est Conflit. Si au plus une définition de stratégie a l’effet deny, chaque attribution retourne l’état de conformité Non conforme.
    • Valeurs disponibles : audit, deny, disabled.
    • La valeur par défaut est deny.
  • operations (obligatoire)
    • Tableau de toutes les opérations d’étiquette à effectuer sur les ressources correspondantes.
    • Propriétés :
      • operation (obligatoire)
        • Définit l’action à effectuer sur une ressource correspondante. Les options sont les suivantes : addOrReplace, Add, Remove. Add a le même comportement que l’effet Append.
      • field (obligatoire)
        • Étiquette à ajouter, remplacer ou supprimer. Les noms d’étiquette doivent respecter la même convention de nommage que les autres champs.
      • value (facultatif)
        • Valeur à affecter à l’étiquette.
        • Cette propriété est obligatoire si l’opération est addOrReplace ou Add.
      • condition (facultatif)
        • Chaîne contenant une expression de langage Azure Policy avec fonctions de stratégie qui prend la valeur true ou false.
        • Ne prend pas en charge les fonctions de stratégie suivantes : field(), resourceGroup() et subscription().

Opérations Modify

Le tableau de propriétés operations permet de modifier plusieurs étiquettes de différentes façons à partir d’une même définition de stratégie. Chaque opération est constituée des propriétés operation, field et value. La propriété operation détermine ce que fait la tâche de correction aux étiquettes, la propriété field détermine l’étiquette qui est modifiée et la propriété value définit le nouveau paramètre de l’étiquette. L’exemple suivant effectue les modifications de balises suivantes :

  • Définit la balise environment sur « Test », même si elle existe déjà avec une autre valeur.
  • Supprime l’étiquette TempResource.
  • Définit l’étiquette Dept sur le paramètre de stratégie DeptName configuré pour l’attribution de stratégie.
"details": {
  ...
  "operations": [
    {
      "operation": "addOrReplace",
      "field": "tags['environment']",
      "value": "Test"
    },
    {
      "operation": "Remove",
      "field": "tags['TempResource']",
    },
    {
      "operation": "addOrReplace",
      "field": "tags['Dept']",
      "value": "[parameters('DeptName')]"
    }
  ]
}

La propriété operation comprend les options suivantes :

Opération Description
addOrReplace Ajoute la propriété/l’étiquette et la valeur définies à la ressource, même si la propriété/l’étiquette a déjà une autre valeur.
Ajouter Ajoute la propriété/l’étiquette et la valeur définies à la ressource.
Supprimer Supprime la propriété/l’étiquette définie de la ressource.

Exemples Modify

Exemple 1 : Ajoutez l’étiquette environment et remplacez les étiquettes environment existantes par « Test » :

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

Exemple 2 : Supprimez l’étiquette env et ajoutez l’étiquette environment, ou remplacez les étiquettes environment existantes par une valeur paramétrable :

"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')]"
      }
    ]
  }
}

Exemple 3 : assurez-vous qu’un compte de stockage n’autorise pas l’accès public aux blobs. L’opération Modify est appliquée uniquement lors de l’évaluation des requêtes dont la version de l’API est supérieure ou égale à 2019-04-01 :

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

Muter (préversion)

La mutation est utilisée dans Azure Policy pour Kubernetes pour corriger des composants de cluster AKS, comme des pods. Cet effet est spécifique aux définitions de mode de stratégieMicrosoft.Kubernetes.Data uniquement.

Pour en savoir plus, accédez à Comprendre Azure Policy pour les clusters Kubernetes.

Propriétés de la mutation

  • mutationInfo (en option)
    • Ne peut pas être utilisé avec constraint, constraintTemplate, apiGroups ou kinds.
    • Ne peut pas être paramétré.
    • sourceType (requis)
      • Définit le type de source pour la contrainte. Valeurs autorisées : PublicURL ou Base64Encoded.
      • Si le type est PublicURL et est associé à la propriété url pour fournir l’emplacement du modèle de contrainte. L'emplacement doit être accessible publiquement.

        Avertissement

        N’utilisez pas d’URI ou de jetons SAS dans url ou tout autre élément susceptible d’exposer un secret.

Superposition de définitions de stratégie

Une ressource peut être affectée par plusieurs affectations. Ces affectations peuvent se situer dans la même étendue ou dans des étendues différentes. Chaque affectation est également susceptible d’avoir un effet différent. La condition et l’effet de chaque stratégie sont évalués indépendamment. Par exemple :

  • Stratégie 1
    • Restreint l’emplacement de la ressource à westus
    • Affectée à l’abonnement A
    • Effet Deny
  • Stratégie 2
    • Restreint l’emplacement de la ressource à eastus
    • Affectée au groupe de ressources B de l’abonnement A
    • Effet Audit

Cette configuration génère le résultat suivant :

  • Toute ressource figurant déjà dans le groupe de ressources B dans eastus est marquée comme conforme à la stratégie 2 et non conforme à la stratégie 1
  • Toute ressource figurant déjà dans le groupe de ressources B, mais pas dans eastus est marquée comme non conforme à la stratégie 2 et non conforme à la stratégie 1 si elle ne figure pas dans westus
  • Toute nouvelle ressource figurant dans l’abonnement A, mais pas dans westus est refusée par la stratégie 1
  • Toute nouvelle ressource de l’abonnement A et du groupe de ressources B dans westus est créée et non conforme à la stratégie 2

Si la stratégie 1 et la stratégie 2 avaient pour effet Deny, le scénario serait le suivant :

  • Toute ressource figurant déjà dans le groupe de ressources B, mais pas dans eastus est non conforme à la stratégie 2
  • Toute ressource figurant déjà dans le groupe de ressources B, mais pas dans westus est non conforme à la stratégie 1
  • Toute nouvelle ressource figurant dans l’abonnement A, mais pas dans westus est refusée par la stratégie 1
  • Toute nouvelle ressource du groupe de ressources B de l’abonnement A est refusée

Chaque affectation est évaluée individuellement. Par conséquent, une ressource ne peut pas passer en cas d’écart en raison de différences dans la portée. La superposition de définitions de stratégie est considérée comme cumulative et la plus restrictive. Par exemple, si les stratégies 1 et 2 ont un effet Deny, une ressource est bloquée par les définitions de stratégie qui se chevauchent et qui sont en conflit. Si vous avez toujours besoin que la ressource soit créée dans l’étendue cible, révisez les exclusions de chaque attribution pour vérifier que les attributions de stratégies appropriées agissent sur les bonnes étendues.

Étapes suivantes