Partager via

Concepts de base de l’effet des définitions d’Azure Policy

  • Article

Chaque définition de stratégie dans Azure Policy a un effect unique dans sa policyRule. Cet effect détermine ce qui 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.

Les éléments suivants constituent les effets de définition d’Azure Policy pris en charge :

Effets interchangeables

Parfois, plusieurs effets peuvent être valides pour une définition de stratégie donnée. Les paramètres servent souvent utilisés à spécifier les valeurs d’effet autorisées (allowedValues) pour qu’une définition unique puisse être plus polyvalente pendant l’affectation. 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 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, deny et modify ou append sont souvent interchangeables.
  • auditIfNotExists et deployIfNotExists sont souvent interchangeables.
  • manual n’est pas interchangeable.
  • disabled est interchangeable avec n’importe quel effet.

Ordre d’évaluation

La première évaluation d’Azure Policy est destinée aux demandes de création ou de mise à jour d’une ressource. 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 vérifié 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 a retourné 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 nécessaire.

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.

Superposition de définitions de stratégie

Plusieurs affectations peuvent affecter une ressource. 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
  • Stratégie 1 refuse toute nouvelle ressource figurant dans l’abonnement A, mais pas dans westus
  • 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
  • Stratégie 1 refuse toute nouvelle ressource figurant dans l’abonnement A, mais pas dans westus
  • 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