Partager via

Présentation d’Azure Policy

Cette vue d’ensemble décrit comment Azure Policy permet d’appliquer des normes organisationnelles et d’évaluer la conformité à grande échelle. Avec son tableau de bord de conformité, il fournit une vue agrégée permettant d’évaluer l’état général de l’environnement, avec la possibilité d’explorer au niveau de chaque ressource et stratégie. Il vous aide également à mettre vos ressources en conformité par le biais de la correction en bloc pour les ressources existantes et de la correction automatique pour les nouvelles ressources.

Remarque

Pour plus d’informations sur la correction, consultez Corriger les ressources non conformes avec Azure Policy.

Les cas d’usage courants pour Azure Policy incluent la mise en œuvre de la gouvernance pour la cohérence des ressources, la conformité réglementaire, la sécurité, le coût et la gestion. Les définitions de stratégie pour ces cas d’usage courants sont déjà disponibles dans votre environnement Azure comme éléments intégrés pour vous aider à démarrer.

Voici quelques actions de gouvernance utiles que vous pouvez appliquer avec Azure Policy :

  • Assurez-vous que votre équipe déploie des ressources Azure uniquement dans les régions autorisées.
  • Appliquez l’application cohérente des balises taxonomiques.
  • Exiger des ressources pour envoyer des journaux de diagnostic à un espace de travail Log Analytics.

Il est important de reconnaître qu’avec l’introduction d’Azure Arc, vous pouvez étendre votre gouvernance basée sur les stratégies à différents fournisseurs cloud et même à vos centres de données locaux.

La totalité des données et objets Azure Policy sont chiffrés au repos. Pour plus d’informations, consultez Chiffrement des données Azure au repos.

Vue d’ensemble

Azure Policy évalue les ressources et actions dans Azure en comparant les propriétés de ces ressources aux règles d’entreprise. Ces règles d’entreprise, décrites au format JSON, sont appelées définitions de stratégie. Pour simplifier la gestion, plusieurs règles métier peuvent être regroupées pour former une initiative de stratégie, également appelée policySet.

Une fois que vos règles d’entreprise sont formées, la définition de stratégie ou l’initiative est affectée à n’importe quelle étendue de ressources qu’Azure prend en charge. Par exemple, les groupes d’administration, les abonnements, les groupes de ressources ou les ressources individuelles. L’affectation s’applique à toutes les ressources au sein de l’étendue Resource Manager de cette affectation. Des sous-étendues peuvent être exclues, si nécessaire. Pour plus d’informations, consultez Étendue d’Azure Policy.

Azure Policy utilise un format JSON afin de former la logique utilisée par l’évaluation pour déterminer si une ressource est conforme ou non. Les définitions incluent des métadonnées et la règle de stratégie. La règle définie peut utiliser des fonctions, des paramètres, des opérateurs logiques, des conditions et des alias de propriété afin d’établir une correspondance exacte au scénario de votre choix. La règle de stratégie détermine quelles ressources de l’étendue de l’affectation sont évaluées.

Comprendre les résultats de l’évaluation

Les ressources sont évaluées à des moments spécifiques pendant le cycle de vie des ressources, le cycle de vie d’affectation de stratégie, et en vue d’une évaluation régulière et continue de la conformité. Voici les moments ou les événements qui provoquent l’évaluation d’une ressource :

  • Création ou mise à jour d’une ressource dans une étendue avec une affectation de stratégie.
  • Un périmètre reçoit une nouvelle affectation d'une politique ou d'une initiative.
  • Mise à jour d’une stratégie ou initiative déjà assignée à une étendue.
  • Cycle d’évaluation de conformité standard qui se produit une fois toutes les 24 heures.

Pour plus d’informations sur le moment et la façon dont l’évaluation de la stratégie se produit, consultez Déclencheurs d’évaluation.

Contrôler la réponse à une évaluation

Les règles d’entreprise pour la gestion des ressources non conformes varient considérablement d’une organisation à l’autre. Voici des exemples de la façon dont une organisation peut souhaiter que la plateforme réponde à une ressource non conforme :

  • Refuser la modification de la ressource.
  • Journaliser la modification de la ressource.
  • Modifiez la ressource avant la modification.
  • Modifiez la ressource après la modification.
  • Déployez les ressources conformes associées.
  • Bloquer les actions sur les ressources.

Azure Policy rend possible chacune de ces réponses métier par le biais de l’application d’effets. Les effets sont définis dans la partie règle de stratégie de la définition de stratégie.

Remédier aux ressources non conformes

Bien que ces effets affectent principalement une ressource lors de sa création ou de sa mise à jour, Azure Policy prend également en charge la gestion des ressources non conformes existantes sans avoir à modifier ces ressources. Pour plus d’informations sur la conformité des ressources existantes, consultez Corriger les ressources non conformes avec Azure Policy.

Prise en main

Azure Policy et Azure RBAC

Il existe quelques différences importantes entre Azure Policy et le contrôle d’accès en fonction du rôle Azure (Azure RBAC). Azure Policy évalue l’état en examinant les propriétés des ressources qui sont représentées dans Resource Manager et les propriétés de certains fournisseurs de ressources. Azure Policy garantit que l’état des ressources est conforme à vos règles d’entreprise sans se préoccuper de qui a apporté la modification ou qui a l’autorisation d’apporter une modification. Azure Policy, par l’effet DenyAction, peut également bloquer certaines actions sur les ressources. Certaines ressources Azure Policy, telles que les définitions de stratégie, les définitions d’initiative et les attributions, sont visibles par tous les utilisateurs. Cette conception permet à tous les utilisateurs et services de savoir en toute transparence quelles règles de stratégie sont définies dans leur environnement.

Azure RBAC est axé sur la gestion des actions des utilisateurs dans différentes étendues. Si le contrôle d’une action est nécessaire sur la base des informations utilisateur, Azure RBAC est l’outil qu’il convient d’utiliser. Même si une personne est autorisée à exécuter une action, si le résultat est une ressource non conforme, Azure Policy bloque toujours la création ou la mise à jour.

La combinaison d’Azure RBAC et d’Azure Policy fournit un contrôle d’étendue complète dans Azure.

Autorisations Azure RBAC dans Azure Policy

Azure Policy dispose d’autorisations, aussi appelées opérations, dans deux fournisseurs de ressources :

Plusieurs rôles intégrés accordent des autorisations aux ressources Azure Policy. Le rôle Contributeur de stratégie de ressource inclut la plupart des opérations d’Azure Policy. Quant au rôle Propriétaire, il dispose de tous les droits. Les rôles Contributeur et Lecteur ont accès à toutes les opérations de lecture Azure Policy.

Le contributeur peut déclencher la correction des ressources, mais ne peut pas créer ou mettre à jour des définitions et des affectations. L’administrateur(-trice) des accès utilisateur est nécessaire pour accorder à l’identité gérée sur deployIfNotExists ou modify les autorisations nécessaires.

Remarque

Tous les objets de stratégie, y compris les définitions, les initiatives et les affectations, sont lisibles pour tous les rôles sur son étendue. Par exemple, une attribution de stratégie étendue à un abonnement Azure est lisible par tous les titulaires de rôles dans l'étendue de l’abonnement et à des niveaux inférieurs.

Si aucun des rôles intégrés ne dispose d’autorisations, créez un rôle personnalisé.

Les opérations d’Azure Policy peuvent avoir un effet significatif sur votre environnement Azure. Attribuez uniquement le jeu minimal d’autorisations nécessaires pour effectuer une tâche et accordez uniquement ces autorisations aux utilisateurs qui ont besoin d’autorisations.

Remarque

L'identité managée d'une attribution de stratégie deployIfNotExists ou modify a besoin de privilèges suffisants pour créer ou mettre à jour des ressources ciblées. Pour plus d’informations, consultez Configurer la définition de stratégie.

Autorisations spéciales requises pour Azure Policy avec Azure Virtual Network Manager

Azure Virtual Network Manager (préversion) vous permet d’appliquer des stratégies de gestion et de sécurité cohérentes à plusieurs réseaux virtuels Azure dans toute votre infrastructure cloud. Les groupes dynamiques Azure Virtual Network Manager (AVNM) utilisent des définitions Azure Policy pour évaluer l’appartenance au réseau virtuel dans ces groupes.

Pour créer, modifier ou supprimer des stratégies de groupe dynamique Azure Virtual Network Manager, vous avez besoin des éléments suivants :

  • Lire et écrire des autorisations RBAC Azure dans la stratégie sous-jacente
  • Autorisations RBAC Azure pour rejoindre le groupe réseau. L’autorisation Administrateur classique n’est pas prise en charge.

L’autorisation du fournisseur de ressources requise est Microsoft.Network/networkManagers/networkGroups/join/action.

Important

Pour modifier les groupes dynamiques AVNM, vous devez vous voir accorder l’accès via l’attribution de rôle RBAC Azure uniquement. L’administrateur classique ou l’autorisation héritée n’est pas prise en charge. Si votre compte n'était attribué qu'au rôle d'abonnement Co-Administrateur, vous ne disposeriez pas d'autorisations sur les groupes dynamiques AVNM.

Ressources couvertes par Azure Policy

Bien qu’une stratégie puisse être affectée au niveau du groupe d’administration, seules les ressources au niveau de l’abonnement ou du groupe de ressources sont évaluées.

Pour certains fournisseurs de ressources tels que Configuration de la machine, Azure Kubernetes Service et Azure Key Vault, il existe une intégration plus poussée pour la gestion des paramètres et des objets. Pour en savoir plus, accédez aux Modes Fournisseur de ressources.

Recommandations pour la gestion des stratégies

Voici quelques conseils et astuces à garder à l’esprit :

  • Commencez avec un effet audit ou auditIfNotExists au lieu d'un effet d'application (deny, modify, deployIfNotExists) pour suivre comment votre définition de stratégie affecte les ressources de votre environnement. Si vous avez déjà des scripts en place pour mettre à l’échelle automatiquement vos applications, définir un effet d'application des règles pourrait entraver ces tâches d’automatisation déjà en place.

  • Prenez en compte les hiérarchies organisationnelles lorsque vous créez des définitions et des affectations. Nous vous recommandons de créer des définitions à des niveaux supérieurs, comme au niveau de l’abonnement ou du groupe d’administration. Ensuite, créez l’affectation au niveau enfant suivant. Si vous créez une définition au niveau d’un groupe d’administration, l’affectation peut être limitée à un abonnement ou groupe de ressources au sein de ce groupe d’administration.

  • Nous vous recommandons de créer et d’affecter des définitions d’initiative même si vous commencez avec une définition de stratégie unique. Cette méthode vous permet d’ajouter des définitions de stratégie à l’initiative ultérieurement sans augmenter le nombre d’affectations à gérer.

    • Par exemple, imaginez que vous créez une définition de stratégie policyDefA et que vous l’ajoutes à la définition d’initiative initiativeDefC. Si vous créez ultérieurement une autre définition de stratégie pour policyDefB avec des objectifs similaires à policyDefA, vous pouvez l’ajouter sous initiativeDefC et les suivre ensemble.

    • Après avoir créé une attribution d’initiative, les définitions de stratégie ajoutées à l’initiative font également partie des affectations de cette initiative.

    • Lors de l’évaluation d’une affectation d’initiative, toutes les stratégies dans l’initiative sont également évaluées. Si vous devez évaluer une stratégie individuellement, il est préférable de ne pas l’inclure dans une initiative.

  • Gérez les ressources Azure Policy en tant que code avec des révisions manuelles sur les modifications apportées aux définitions, initiatives et affectations. Pour en savoir plus sur les modèles et les outils suggérés, consultez Concevoir Azure Policy en tant que flux de travail de code.

Objets Azure Policy

Les objets incluent des définitions de stratégie, des définitions d’initiative et des affectations.

Définition de stratégie

Le parcours de création et d’implémentation d’une stratégie dans Azure Policy commence lorsque vous créez une définition de stratégie. Chaque définition de stratégie a des conditions qui sont appliquées. Si les conditions sont remplies, un effet défini se produit.

Dans Azure Policy, nous proposons plusieurs stratégies intégrées qui sont disponibles par défaut. Exemple :

  • Références SKU de compte de stockage autorisées (Refuser) : Détermine si un compte de stockage en cours de déploiement se trouve dans un ensemble de tailles de référence SKU. Son effet consiste à refuser tous les comptes de stockage dont la taille ne fait pas partie de l’ensemble de tailles de référence SKU définies.
  • Type de ressource autorisé (Refuser) : Définit les types de ressources que vous pouvez déployer. Son effet consiste à refuser toutes les ressources qui ne font pas partie de cette liste définie.
  • Emplacements autorisés (Refuser) : Restreint les emplacements disponibles pour les nouvelles ressources. Son effet permet d’appliquer vos exigences de conformité géographique.
  • Références SKU de machine virtuelle autorisées (Refuser) : Spécifie un ensemble de références SKU de machine virtuelle que vous pouvez déployer.
  • Ajouter une balise aux ressources (Modifier) : applique une balise requise et sa valeur par défaut si la demande de déploiement ne la spécifie pas.
  • Types de ressources non autorisés (Refuser) : Empêche une liste de types de ressources d’être déployés.

Pour implémenter ces définitions de stratégie (définitions intégrées et personnalisées), vous devez les affecter. Vous pouvez affecter l’une de ces stratégies par le biais du portail Azure, de PowerShell ou d’Azure CLI.

Une évaluation de la stratégie a lieu avec plusieurs actions différentes comme l’affectation de stratégie ou les mises à jour de stratégie. Pour obtenir la liste complète, consultez Policy evaluation triggers (Déclencheurs d’évaluation de stratégie).

Pour en savoir plus sur les structures des définitions de stratégie, consultez les principes de base de la structure de définition Azure Policy.

Les paramètres de stratégie permettent de simplifier la gestion des stratégies en réduisant le nombre de définitions de stratégies que vous devez créer. Vous pouvez définir des paramètres lors de la création d’une définition de stratégie, pour la rendre plus générique. Vous pouvez ensuite réutiliser cette définition de stratégie pour différents scénarios. Pour ce faire, transmettez différentes valeurs lors de l’affectation de la définition de stratégie. Par exemple, spécifiez un ensemble d’emplacements pour un abonnement.

Les paramètres sont définis lorsque vous créez une définition de stratégie. La définition du paramètre inclut le nom du paramètre et les valeurs facultatives. Par exemple, vous pouvez définir un paramètre pour une stratégie intitulée Emplacement. Vous pouvez ensuite lui attribuer différentes valeurs comme EastUS ou WestUS lors de l’affectation d’une stratégie.

Pour plus d’informations sur les paramètres de stratégie, consultez les paramètres de structure de définition Azure Policy.

Définition d’initiative

Une définition d’initiative est une collection de définitions de stratégie qui sont spécialement conçues pour atteindre un objectif global particulier. Les définitions d’initiative simplifient la gestion et l’affectation des définitions de stratégie. Elles simplifient ces procédures en regroupant un ensemble de stratégies en un seul élément. Par exemple, vous pourriez créer une initiative intitulée Activation de la surveillance dans Microsoft Defender pour le cloud afin de surveiller toutes les recommandations de sécurité disponibles dans votre instance Microsoft Defender pour le cloud.

Remarque

Le SDK, et notamment Azure CLI et Azure PowerShell, utilisent des propriétés et des paramètres nommés PolicySet pour référencer les initiatives.

Dans cette initiative, vous avez par exemple des définitions de stratégie comme celles-ci :

  • Surveiller une base de données SQL non chiffrée dans Microsoft Defender pour le cloud : pour surveiller les bases de données et les serveurs SQL Server non chiffrés.
  • Surveiller les vulnérabilités du système d’exploitation dans Microsoft Defender pour le cloud : pour surveiller les serveurs qui ne répondent pas à la ligne de base configurée.
  • Surveiller l’absence d’Endpoint Protection dans Microsoft Defender pour le cloud : pour surveiller les serveurs dépourvus d’agent de protection de point de terminaison installé.

Comme les paramètres de stratégie, les paramètres d’initiative permettent de simplifier la gestion en réduisant la redondance. Les paramètres d’initiative sont les paramètres utilisés par les définitions de stratégie dans l’initiative.

Par exemple, dans le scénario suivant, vous disposez d'une définition d'initiative initiativeC, avec des définitions de stratégie policyA et policyB où chacun attend un type de paramètre différent :

Policy Nom de paramètre Type de paramètre Remarque
policyA allowedLocations tableau Ce paramètre attend une liste de chaînes pour une valeur, car le type de paramètre a été défini en tant que tableau.
policyB allowedSingleLocation string Ce paramètre attend un mot pour une valeur, car le type de paramètre a été défini comme une chaîne.

Lorsque vous définissez les paramètres d’initiative pour initiativeC, vous avez trois options :

  • Utilisez les paramètres des définitions de stratégie dans cette initiative : dans cet exemple, allowedLocations et allowedSingleLocation devenez des paramètres d’initiative pour initiativeC.
  • Fournir des valeurs pour les paramètres des définitions de stratégie dans la définition de cette initiative. Dans cet exemple, vous pouvez fournir une liste d’emplacements au paramètre allowedLocations et à policyBallowedSingleLocation. Vous pouvez également fournir des valeurs lorsque vous affectez cette initiative.
  • Fournir une liste d’options de valeurs qui peuvent être utilisées lors de l’affectation de cette initiative. Lorsque vous affectez cette initiative, les paramètres hérités des définitions de stratégie dans l’initiative peuvent avoir seulement des valeurs provenant de cette liste fournie.

Lorsque vous créez des options de valeur dans une définition d’initiative, vous ne pouvez pas entrer une valeur différente pendant l’affectation de l’initiative, car elle ne fait pas partie de la liste.

Pour en savoir plus sur les structures des définitions d’initiative, consultez la structure de définition d’initiative Azure Policy.

Attributions

Une affectation est une définition de politique ou une initiative qui a été affectée à une portée spécifique. Cette étendue peut aller d’un groupe d’administration à une ressource individuelle. Le terme étendue désigne l’ensemble des ressources, groupes de ressources, abonnements ou groupes d’administration auxquels la définition est affectée. Toutes les ressources enfants héritent des attributions. Grâce à cette structure, si une définition est appliquée à un groupe de ressources, elle est également appliquée à toutes les ressources de ce groupe. Toutefois, vous pouvez exclure une sous-étendue de l’affectation.

Par exemple, dans l’étendue de l’abonnement, vous pouvez affecter une définition qui empêche la création de ressources réseau. Vous pouvez exclure un groupe de ressources au sein de cet abonnement qui est destiné à l’infrastructure réseau. Vous accordez ensuite l’accès à ce groupe de ressources réseau aux utilisateurs auxquels vous faites confiance avec la création des ressources réseau.

Dans un autre exemple, vous souhaiterez peut-être affecter une définition de liste d’autorisation de type de ressource au niveau du groupe d’administration. Ensuite, vous affecterez une stratégie plus permissive (autorisant plus de types de ressources) à un groupe d’administration enfant ou même directement aux abonnements. Toutefois, cet exemple ne fonctionnera pas, car Azure Policy est un système de refus explicite. Au lieu de cela, vous devez exclure le groupe d’administration enfant ou l’abonnement de l’affectation au niveau du groupe d’administration. Affectez ensuite la définition plus permissive au niveau du groupe d’administration enfant ou de l’abonnement. Si une affectation se traduit par le refus d’une ressource, alors la seule façon d’autoriser la ressource consiste à modifier l’affectation de refus.

Les affectations de stratégie utilisent toujours l’état le plus récent de leur définition ou initiative affectée lors de l’évaluation des ressources. Si une définition de stratégie affectée est modifiée, toutes les affectations existantes de cette définition utilisent la logique mise à jour lors de l’évaluation.

Pour plus d’informations sur les affectations par le biais du portail, consultez Créer une affectation de stratégie pour identifier les ressources non conformes dans votre environnement Azure. Les étapes pour PowerShell et Azure CLI sont également disponibles. Pour plus d’informations sur la structure d’affectation, consultez la structure d’affectation Azure Policy.

Nombre maximal d’objets Azure Policy

Il existe un nombre maximal pour chaque type d'objet concernant Azure Policy. Pour les définitions, une entrée d’étendue désigne le groupe d’administration ou l’abonnement. Pour les affectations et les exemptions, une entrée de Portée désigne le groupe d'administration, l'abonnement, le groupe de ressources ou la ressource individuelle.

Where Quoi Nombre maximal
Étendue Définitions de stratégies 500
Étendue Définitions d’initiative 200
Locataire Définitions d’initiative 2 500
Étendue Affectations de stratégies et d'initiatives 200
Étendue Exemptions 1 000
Définition de stratégie Paramètres 20
Définition d’initiative Stratégies 1 000
Définition d’initiative Paramètres 400
Affectations de stratégies et d'initiatives Exclusion (notScopes) 400
Règle de stratégie Éléments conditionnels imbriqués 512
Tâche de correction Ressources 50 000
Définition de la stratégie, initiative ou corps de la demande d’affectation Octets 1,048,576

Les règles de stratégie générale limitent davantage le nombre de conditions et leur complexité. Pour plus d’informations, consultez Limites des règles de stratégie.

Étapes suivantes

Maintenant que vous disposez d’une vue d’ensemble d’Azure Policy et de certains des concepts clés, utilisez les liens suivants pour en savoir plus sur le service.

  • Last updated on