Présentation d’Azure Policy

Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à l’é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.

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.

Plus précisément, certaines actions de gouvernance utiles que vous pouvez appliquer avec Azure Policy incluent :

• La vérification que votre équipe déploie les ressources Azure uniquement dans les régions autorisées
• L’application cohérente des étiquettes taxonomiques
• La demande de 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 d’entreprise peuvent être regroupées pour former une initiative de stratégie (parfois appelée policySet). Une fois que vos règles d’entreprise ont été formées, l’initiative ou la définition de stratégie est affectée à n’importe quelle étendue de ressources prise en charge par Azure, comme des groupes d’administration, des abonnements, des groupes de ressources ou des 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.
• Affectation d’une nouvelle stratégie ou initiative à une étendue.
• Mise à jour d’une stratégie ou initiative déjà assignée à une étendue.
• Lors du cycle d’évaluation de la 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 :

• Refus de la modification de la ressource
• Enregistrement de la modification apportée à la ressource
• Changement de la ressource avant la modification
• Changement de la ressource après la modification
• Déploiement de 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 façon de rendre les ressources existantes conformes, consultez Corriger les ressources non conformes avec Azure Policy.

Présentation vidéo

La présentation suivante d’Azure Policy est à partir de la Build 2018. Pour le téléchargement des diapositives ou de la vidéo, accédez à Govern your Azure environment through Azure Policy (Gouvernance de votre environnement Azure à l’aide d’Azure Policy) sur Channel 9.

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 propose plusieurs autorisations, appelées opérations, dans deux fournisseurs de ressources :

• Microsoft.Authorization
• Microsoft.PolicyInsights

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.

Un Contributeur peut déclencher la correction d’une ressource, mais ne peut pas créer ou mettre à jour des définitions et des affectations. Un Administrateur de l’accès utilisateur est nécessaire pour accorder les autorisations nécessaires à l’identité managée sur les affectations deployIfNotExists ou modify.

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. Seul l’ensemble minimal des autorisations nécessaires pour effectuer une tâche doit être affecté et ces autorisations ne doivent pas être accordées aux utilisateurs qui n’en ont pas besoin.

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 tout au long de votre infrastructure cloud. Les groupes dynamiques Azure Virtual Network Manager (AVNM) utilisent les définitions Azure Policy pour évaluer l’appartenance à un réseau VNet au sein de 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).

Plus précisément, l’autorisation de fournisseur de ressources nécessaire est Microsoft.Network/networkManagers/networkGroups/join/action.

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 auditIfNotExist plutôt qu’un effet d’application (deny, modify, deployIfNotExist) pour suivre l’impact de la définition de votre stratégie sur votre environnement. Si vous avez déjà des scripts en place pour mettre automatiquement à l’échelle vos applications, la définition d’un effet d’application peut entraver ces tâches d’automatisation déjà en place.

• Tenez compte des hiérarchies de l’organisation lors de la création de définitions et d’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. Cela 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.

  • Une fois que vous avez créé une affectation 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 plus d’informations sur les modèles et outils suggérés, consultez Concevoir des workflows Azure Policy en tant que code.

Objets Azure Policy

Définition de stratégie

Pour créer et implémenter une stratégie dans Azure Policy, il faut commencer par créer une définition de stratégie. Chaque définition de stratégie présente des conditions dans lesquelles elle est appliquée. 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. Par 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 étiquette aux ressources (Modifier) : Applique une balise requise et sa valeur par défaut si elle n’est pas spécifiée par la requête de déploiement.
• 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 plus d’informations sur les structures des définitions de stratégie, consultez Structure des définitions de stratégie.

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 lors de la création d’une définition de stratégie. Quand un paramètre est défini, un nom lui est affecté et éventuellement une valeur. 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 Definition structure - Parameters (Structure de la définition - Paramètres).

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.

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, imaginons un scénario où vous avez une définition d’initiative (initiativeC) avec les définitions de stratégie policyA et policyB, et chacune des définitions de stratégie attend un type de paramètre différent :

Dans ce scénario, quand vous définissez les paramètres d’initiative pour initiativeC, vous avec trois options :

• Utilisez les paramètres des définitions de stratégie dans cette initiative : Dans cet exemple, allowedLocations et allowedSingleLocation deviennent 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 de policyA (allowedLocations) et au paramètre de policyB (allowedSingleLocation). Vous pouvez également fournir des valeurs lors de l’affectation de 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 de valeur différente lors de l’affectation d’initiative, car elle ne fait pas partie de la liste.

Pour en savoir plus sur les structures des définitions d’initiative, passez en revue structure des définitions d’initiative.

Attributions

Une affectation est une initiative ou définition de stratégie qui a été affectée à une étendue 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 affectations. 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 déjà affectée est modifiée, toutes les affectations existantes de cette définition vont utiliser la logique mise à jour dans le cadre 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 des affectations, consultez Structure des affectations.

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.

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

Étapes suivantes

Maintenant que vous avez une vue d’ensemble d’Azure Policy et des autres concepts clés, voici les étapes suivantes que nous suggérons :

• Examiner la structure de définition de stratégie
• Affecter une définition de stratégie à l’aide du portail.