Partager via

Informations de base de la structure de définition Azure Policy

  • Article

Les définitions Azure Policy décrivent les conditions de la conformité des ressources et l’effet à exécuter si une condition est remplie. Une condition compare un champ ou une valeur de propriété de ressource à une valeur requise. Les champs de propriétés de ressources sont accessibles à l’aide d’alias. Quand un champ de propriété de ressource est un tableau, un alias de tableau spécial peut être utilisé pour sélectionner les valeurs de tous les membres du tableau et appliquer à chacune d’elles une condition. Apprenez-en davantage sur les conditions.

Les affectations de stratégie vous permettent de contrôler les coûts et de gérer vos ressources. Par exemple, vous pouvez spécifier que seuls certains types de machines virtuelles sont autorisés. Vous pouvez aussi exiger que les ressources soient marquées avec une balise particulière. Les affectations dans une étendue s’appliquent à toutes les ressources au niveau de cette étendue et sous celle-ci. Si une attribution de stratégie est appliquée à un groupe de ressources, elle s’applique à toutes les ressources appartenant à ce groupe de ressources.

Utilisez un fichier JSON pour créer une définition de stratégie qui contient des éléments pour :

  • displayName
  • description
  • mode
  • version
  • metadata
  • parameters
  • policyRule
    • évaluations logiques
    • effect

Par exemple, le code JSON suivant illustre une stratégie qui limite les emplacements où les ressources sont déployées :

{
  "properties": {
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "metadata": {
      "version": "1.0.0",
      "category": "Locations"
    },
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [
          "westus2"
        ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Pour plus d’informations, accédez au schéma de définition de stratégie. Les modèles et les éléments intégrés Azure Policy sont disponibles sous Exemples Azure Policy.

Nom d’affichage et description

Utilisez displayName et description pour identifier la définition de la stratégie et fournir le contexte dans lequel elle est utilisée. displayName a une longueur maximale de 128caractères et description une longueur maximale de 512 caractères.

Remarque

Lors de la création ou de la mise à jour de la définition d'une stratégie, id, type, et name sont définis par des propriétés externes au JSON et ne sont pas indispensables dans le fichier JSON. La récupération (fetch) de la définition de la stratégie via le kit de développement logiciel (SDK) renvoie les propriétés id, type, et name, en tant que composante du JSON. Toutefois, chacune d'entre elles est une information en lecture seule liée à la définition de la stratégie.

Type de stratégie

Bien que vous ne puissiez pas définir la propriété policyType, trois valeurs sont retournées par le Kit de développement logiciel (SDK). Ces valeurs sont visibles dans le portail :

  • Builtin : Microsoft fournit et gère ces définitions de stratégie.
  • Custom: Toutes les définitions de stratégie créées par les clients ont cette valeur.
  • Static: Indique une définition de stratégie de conformité réglementaire avec la propriété de Microsoft. Les résultats de conformité pour ces définitions de stratégie sont les résultats d’audits non-Microsoft de l’infrastructure Microsoft. Sur le portail Azure, cette valeur est parfois affichée comme étant managée par Microsoft. Pour plus d’informations, consultez Responsabilité partagée dans le cloud.

Mode

Le mode est configuré selon que la stratégie cible une propriété Azure Resource Manager ou une propriété de fournisseur de ressources.

Modes Resource Manager

Le mode détermine les types de ressources à évaluer pour une définition de stratégie. Les modes pris en charge sont les suivants :

  • all : évaluer les groupes de ressources, les abonnements et tous les types de ressources
  • indexed : évaluer uniquement les types de ressources qui prennent en charge les balises et l’emplacement

Par exemple, la ressource Microsoft.Network/routeTables prend en charge les étiquettes et l’emplacement, et elle est évaluée dans les deux modes. En revanche, la ressource Microsoft.Network/routeTables/routes ne peut pas être étiquetée et n’est pas évaluée en mode indexed.

Nous vous recommandons de définir mode sur all dans la plupart des cas. Toutes les définitions de stratégie créées via le portail utilisent le mode all. Si vous utilisez PowerShell ou Azure CLI, vous pouvez spécifier le paramètre mode manuellement. Si la définition de stratégie ne comporte pas de valeur mode, elle prend la valeur par défaut all dans Azure PowerShell et null dans Azure CLI. Le mode null a le même effet que indexed, à savoir assurer une compatibilité descendante.

Il est recommandé (quoique non obligatoire) d’utiliser indexed pour créer des stratégies qui appliquent des balises ou des emplacements, car cela empêche les ressources qui ne prennent pas en charge les balises et les emplacements de s’afficher comme non conformes dans les résultats de conformité. Les groupes de ressources et les abonnements font figure d’exception. Les définitions de stratégie qui appliquent des emplacements ou des balises à un groupe de ressources ou un abonnement doivent définir le mode sur all et cibler spécifiquement le type Microsoft.Resources/subscriptions/resourceGroups ou Microsoft.Resources/subscriptions. Pour obtenir un exemple, consultez Modèle : Balises – Exemple 1. Pour obtenir la liste des ressources qui prennent en charge les étiquettes, consultez Prise en charge des étiquettes pour les ressources Azure.

Modes Fournisseur de ressources

Les modes Fournisseur de ressources suivants sont entièrement pris en charge :

  • Microsoft.Kubernetes.Data pour la gestion des clusters et des composants Kubernetes comme les pods, les conteneurs et les entrées. Pris en charge pour les clusters Azure Kubernetes Service et les clusters Kubernetes avec Azure Arc. Les définitions utilisant ce mode Fournisseur de ressources utilisent les effets audit, deny et disabled.
  • Microsoft.KeyVault.Data pour la gestion des coffres et des certificats dans Azure Key Vault. Pour plus d’informations sur ces définitions de stratégie, consultez Intégrer Azure Key Vault à Azure Policy.
  • Microsoft.Network.Data pour gérer les stratégies d’appartenance Azure Réseau virtuel Manager personnalisées à l’aide d’Azure Policy.

Les modes Fournisseur de ressources suivants sont actuellement pris en charge en préversion :

  • Microsoft.ManagedHSM.Data pour gérer les clés du module de sécurité matériel (HSM) managé en utilisant Azure Policy.
  • Microsoft.DataFactory.Data pour utiliser Azure Policy afin de refuser les noms de domaine de trafic sortant Azure Data Factory non spécifiés dans une liste d’autorisation. Ce mode Fournisseur de ressources est uniquement appliqué et ne signale pas la conformité en préversion publique.
  • Microsoft.MachineLearningServices.v2.Data pour gérer les déploiements de modèles Azure Machine Learning. Ce mode Fournisseur de ressources signale la conformité pour les composants récemment créés et mis à jour. Pendant la préversion publique, les enregistrements de conformité sont conservés pendant 24 heures. Les modèles de déploiement qui existent avant l’affectation de ces définitions de stratégie ne signalent pas la conformité.

Remarque

Sauf indication explicite, les modes Fournisseur de ressources prennent uniquement en charge les définitions de stratégie intégrées, et les exemptions ne sont pas prises en charge au niveau du composant.

Lorsque le contrôle de version Azure Policy est publié, les modes Fournisseur de ressources suivants ne prennent pas en charge le contrôle de version intégré :

  • Microsoft.DataFactory.Data
  • Microsoft.MachineLearningServices.v2.Data
  • Microsoft.ManagedHSM.Data

Version (préversion)

Les définitions de stratégie intégrées peuvent héberger plusieurs versions avec le même definitionID. Si aucun numéro de version n’est spécifié, toutes les expériences affichent la dernière version de la définition. Pour afficher une version spécifique d’une définition intégrée, elle doit être spécifiée dans l’API, le kit SDK ou l’interface utilisateur. Pour faire référence à une version spécifique d’une définition au sein d’une affectation, examinez la version de la définition dans l’affectation

Le service Azure Policy utilise les propriétés version, preview et deprecated pour transmettre le niveau de changement à la définition ou à initiative et à l’état d’une stratégie intégrée. Le format de version est le suivant : {Major}.{Minor}.{Patch}. Les états spécifiques, tels que déprécié ou préversion, sont ajoutés à la propriété version ou à toute autre propriété en tant que valeur booléenne.

  • Version majeure (exemple : 2.0.0) : introduction de changements cassants comme des modifications de logique de règle majeures, la suppression de paramètres, l’ajout d’un effet d’application par défaut.
  • Version mineure (exemple : 2.1.0) : introduction de changements comme des modifications de logique de règle mineures, l’ajout de nouvelles valeurs de paramètres autorisées, la modification de roleDefinitionIds, l’ajout ou le déplacement de définitions dans le cadre d’une initiative.
  • Version de correctif (exemple : 2.1.4) : introduction de modifications de chaînes ou de métadonnées et scénarios de procédure d’accès d’urgence (rare).

Pour plus d’informations sur les définitions intégrées des versions d’Azure Policy, consultez Contrôle de version intégré. Pour en savoir plus sur ce que cela signifie pour une stratégie d’être dépréciée ou en préversion, consultez Stratégies en préversion et dépréciées.

Métadonnées

La propriété facultative metadata stocke les informations relatives à la définition de stratégie. Les clients peuvent définir toutes les propriétés et valeurs utiles à leur organisation dans metadata. Cependant, certaines propriétés communes sont utilisées par Azure Policy et dans les éléments intégrés. Chaque propriété metadata a une limite de 1 024 caractères.

Propriétés de métadonnées communes

  • version (chaîne) : Effectue le suivi des détails sur la version du contenu d’une définition de stratégie.
  • category (chaîne) : détermine sous quelle catégorie du portail Azure la définition de stratégie apparaît.
  • preview (booléen) : indicateur true ou false permettant de déterminer si la définition de stratégie est en préversion.
  • deprecated (valeur booléenne) : indicateur true ou false permettant de déterminer si la définition de stratégie est marquée comme déconseillée.
  • portalReview (chaîne) : détermine si les paramètres doivent être examinés dans le portail, quelle que soit l’entrée requise.

Emplacement de la définition

Lors de la création d’une initiative ou d’une stratégie, il est important de spécifier l’emplacement de la définition, qui doit être 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 être des membres directs ou des enfants dans la hiérarchie de l’emplacement de la définition à cibler pour l’affectation.

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

  • Abonnement : seules les ressources au sein de cet abonnement peuvent être affectées à la définition de la stratégie.
  • Groupe d’administration : seules les ressources au sein des groupes d’administration enfants et des abonnements enfants peuvent être affectées à la définition de la 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.

Pour plus d’informations, consultez Comprendre l’étendue d’Azure Policy.

Étapes suivantes