Comprendre l’étendue dans Azure Policy

  • Article

Il existe de nombreux paramètres qui déterminent les ressources qui peuvent être évaluées et les ressources qui sont évaluées par Azure Policy. Le concept principal de ces contrôles est l’étendue. Dans Azure Policy, l’étendue est basée sur le fonctionnement de l’étendue dans Azure Resource Manager. Pour une vue d’ensemble de haut niveau, consultez la section Étendue d’Azure Resource Manager.

Cet article explique l’importance de l’étendue dans Azure Policy et les objets et propriétés qui y sont associés.

Emplacement de la définition

L’étendue utilisée en premier lieu par Azure Policy est la création d’une définition de stratégie, qui doit être enregistrée dans un groupe d’administration ou un abonnement. L’emplacement détermine l’étendue à laquelle l’initiative ou la stratégie peut être affectée. Les ressources doivent faire partie de la hiérarchie de ressources de l’emplacement de la définition à cibler pour l’affectation. Les ressources couvertes par Azure Policy décrivent l’évaluation des stratégies.

Si l’emplacement de la définition est l’un ou l’autre élément suivant :

  • abonnement : l’abonnement où la stratégie est définie et les ressources de cet abonnement peuvent être affectées à la définition de stratégie.
  • Groupe d’administration - le groupe d’administration où la stratégie est définie et les ressources dans les groupes d’administration enfants et les abonnements enfants peuvent être affectés à la définition de stratégie. Si vous voulez appliquer la définition de stratégie à plusieurs abonnements, l’emplacement doit correspondre à un groupe d’administration comportant chaque abonnement.

L’emplacement doit être le conteneur de ressources partagé par toutes les ressources sur lequel vous souhaitez utiliser la définition de stratégie. Ce conteneur de ressources est généralement un groupe d’administration proche du groupe d’administration racine.

Étendues d’affectation

Plusieurs propriétés d’une affectation définissent une étendue. L’utilisation de ces propriétés détermine quelles ressources doivent être évaluées par Azure Policy et quelles ressources sont prises en compte pour la conformité. Ces propriétés sont liées aux concepts suivants :

  • Inclusion : la conformité d’une hiérarchie de ressources ou d’une ressource individuelle doit être évaluée par la définition. La propriété properties.scope sur un objet d’affectation détermine quelles ressources inclure et pour lesquelles la conformité doit être évaluée. Pour plus d’informations, consultez la section Définition d’affectation.

  • Exclusion : la conformité d’une hiérarchie de ressources ou d’une ressource individuelle ne doit pas être évaluée par la définition. La propriété de tableauproperties.notScopes sur un objet d’affectation détermine les ressources à exclure. Les ressources comprises dans ces étendues ne sont pas évaluées ou incluses dans le décompte de conformité. Pour plus d’informations, consultez la section Définition d’affectation : étendues exclues.

En plus des propriétés d'affectation de stratégie figure un objet d'exemption de stratégie. Les exemptions améliorent le scénario d'étendue en fournissant une méthode qui permet d'identifier une partie à ne pas évaluer au sein d'une affectation.

  • Exemption : la conformité d’une hiérarchie de ressources ou d’une ressource individuelle doit être évaluée par la définition, mais elle ne sera pas évaluée en raison d’une dérogation ou d’une atténuation par une autre méthode. Les ressources dans cet état apparaissent comme Exemptées dans les rapports de conformité afin de pouvoir être suivies. L’objet d’exemption est créé sur la hiérarchie de ressources ou la ressource individuelle en tant qu’objet enfant, afin de déterminer l’étendue de l’exemption. Une hiérarchie de ressources ou une ressource individuelle peuvent être exemptes de plusieurs affectations. Il est possible de configurer l’exemption pour qu’elle expire selon un calendrier précis grâce à la propriété expiresOn. Pour plus d’informations, consultez la section Définition d’exemption.

    Notes

    En raison de l’impact de l’octroi d’une exemption pour une hiérarchie de ressources ou une ressource individuelle, les exemptions comportent des mesures de sécurité supplémentaires. Au-delà de la nécessité de l’opération Microsoft.Authorization/policyExemptions/write sur la hiérarchie de ressources ou la ressource individuelle, le créateur d’une exemption doit avoir le verbe exempt/Action sur l’affectation cible.

Comparaison d’étendue

Le tableau suivant présente une comparaison des options d’étendue :

Inclusion Exclusion (notScopes) Exemption
Les ressource sont évaluées ✔ - -
Objet Gestionnaire des ressources - - ✔
Nécessite la modification d’un objet d’affectation de stratégie ✔ ✔ -

Alors, sur quel critère choisir d’utiliser une exclusion ou une exemption ? En règle générale, les exclusions sont recommandées pour contourner définitivement une évaluation pour une vaste étendue telle qu’un environnement de test qui ne nécessite pas le même niveau de gouvernance. Les exemptions sont recommandées pour des scénarii limités dans le temps ou plus spécifiques dans lesquels une ressource ou une hiérarchie de ressources doit toujours faire l’objet d’un suivi et sinon être évaluée, mais il existe une raison spécifique pour laquelle elle ne doit pas être évaluée pour la conformité.

Étapes suivantes