Azure Policy

Contents
Documentation Azure Policy

Vue d’ensemble
Présentation d’Azure Policy
Démarrages rapides
Attribuer une stratégie - Portail
Attribuer une stratégie - PowerShell
Attribuer une stratégie - Azure CLI
Attribuer une stratégie - modèle
Tutoriels
Créer et gérer une stratégie Azure
Créer une définition de stratégie personnalisée
Gérer la gouvernance des balises
Ateliers pratiques - Exploration d’Azure Policy
Exemples
Index
Stratégies prédéfinies
Initiatives intégrées
Modèles d’utilisation
Opérateurs logiques
Champs
Paramètres
Détails des effets
Opérateur value
Opérateur count
Grouper dans une initiative
Déployer des ressources
Concepts
Structure de définition Azure Policy
Comprendre les effets de Policy
Structure d’attribution Azure Policy
Évaluer l’impact d’une nouvelle stratégie
Concevoir des workflows de type Policy as Code
Azure Policy pour Kubernetes
Stratégie pour AKS
Stratégie pour le moteur AKS
Auditer les machines virtuelles avec la configuration invité
Guides pratiques
Extension Azure Policy pour VS Code
Créer des stratégies par programmation
Créer des stratégies pour les propriétés de tableau
Créer une stratégie Guest Configuration
Obtenir des données de conformité
Déterminer les causes de non-conformité
Remédier aux ressources non conformes
Intégration du coffre de clés Azure
Intégrer Key Vault à Azure Policy
Intégration d’Azure Lighthouse
Déployer une stratégie à grande échelle
Déployer une stratégie pouvant être corrigée
Intégration d’Azure Monitor
Activer Azure Monitor pour machines virtuelles (préversion)
Informations de référence
Azure CLI
Azure PowerShell
Stratégie
Policy Insights
Guest Configuration
Kit SDK Azure pour .NET
Attributions
Définitions de stratégies
Kit SDK Azure pour Python
Stratégie
Client de stratégie
Policy Insights
REST
Événements
États
Attributions
Définitions d’initiatives
Ressources suivies par les stratégies
Corrections
Guest Configuration
Modèles Resource Manager
Attributions
Définitions d’initiatives
Ressources
GitHub - Exemples Azure Policy
Vidéo - Version 2018
Chaîne YouTube Governance
Vidéos de configuration invité
Mise en route
Compréhension des initiatives
Attribuer la stratégie
Tâche de correction
Feuille de route Azure
Calculatrice de prix
UserVoice
Présentation d’Azure Policy
02/03/2020 • 20 minutes to read • Edit Online
La gouvernance valide le fait que votre organisation peut atteindre ses objectifs via une utilisation efficace de
l’informatique. Elle répond à ce besoin en clarifiant les objectifs métier et les projets informatiques.
Votre société rencontre un nombre important de problèmes informatiques qui ne semblent jamais résolus ? Une
bonne gouvernance informatique implique la planification de vos initiatives et la définition de priorités à un
niveau stratégique. De cette manière, vous pouvez gérer et éviter les problèmes de manière plus efficace. C’est
pour répondre à ce besoin stratégique qu’Azure Policy entre en jeu,
Azure Policy est un service d’Azure que vous utilisez pour créer, affecter et gérer des stratégies. Ces stratégies
appliquent différentes règles et effets sur vos ressources, qui restent donc conformes aux normes et aux contrats
de niveau de service de l’entreprise. en évaluant vos ressources pour vérifier leur conformité par rapport aux
stratégies affectées. Toutes les données stockées par Azure Policy sont chiffrées au repos.
Par exemple, vous pouvez disposer d’une stratégie qui n’autorise qu’une certaine taille de référence SKU de
machines virtuelles dans votre environnement. Une fois que cette stratégie est implémentée, les ressources
nouvelles et existantes sont évaluées en termes de conformité. Avec le bon type de stratégie, les ressources
existantes peuvent être mises en conformité. Plus tard dans ce document, nous allons parler plus en détail de la
manière de créer et d’implémenter des stratégies avec Azure Policy.
IMPORTANT
L’évaluation de la conformité Azure Policy est désormais fournie pour toutes les affectations, quel que soit le niveau de
tarification. Si vos affectations n’affichent pas les données de conformité, vérifiez que l’abonnement est inscrit auprès du
fournisseur de ressources Microsoft.PolicyInsights.
NOTE
Ce service prend en charge la gestion des ressources déléguées Azure, qui permet aux fournisseurs de services de se
connecter à leur propre locataire pour gérer les abonnements et les groupes de ressources que les clients ont délégués. Pour
plus d’informations, voir Azure Lighthouse.
Quelle est la différence avec RBAC ?

Il existe quelques différences importantes entre Azure Policy et le contrôle d’accès en fonction du rôle (RBAC ). Le
contrôle RBAC porte sur les actions des utilisateurs dans différentes étendues. Vous pouvez être ajouté au rôle de
contributeur pour un groupe de ressources, ce qui vous permet d’apporter des modifications à ce groupe de
ressources. Azure Policy se focalise sur les propriétés des ressources pendant le déploiement et sur les ressources
existantes. Azure Policy contrôle les propriétés telles que les types ou emplacements des ressources.
Contrairement à RBAC, Azure Policy est un système explicite d’autorisation et de refus par défaut.
Autorisations RBAC dans Azure Policy
Azure Policy dispose d’autorisations, aussi 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 peuvent utiliser toutes les opérations en lecture d’Azure Policy,
mais le rôle Contributeur peut aussi les corriger.
Si aucun des rôles intégrés ne dispose d’autorisations, créez un rôle personnalisé.
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 : 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é : 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 : 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 : Spécifie un ensemble de références SKU de machine
virtuelle que vous pouvez déployer.
Ajouter une étiquette aux ressources : 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.
Appliquer la balise et sa valeur : Applique une balise requise et sa valeur à une ressource.
Types de ressources non autorisés : 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.
Affectation de rôle
Une affectation de stratégie est une définition de stratégie qui a été affectée avec 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 de stratégie est affectée. Toutes les ressources enfants héritent des affectations de stratégie. Grâce à
cette structure, si une stratégie est appliquée à un groupe de ressources, elle est également appliquée à toutes les
ressources de ce groupe de ressources. Toutefois, vous pouvez exclure une sous-étendue de l’affectation de
stratégie.
Par exemple, dans l’étendue de l’abonnement, vous pouvez affecter une stratégie 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 stratégie de liste d’autorisation de type de
ressource au niveau du groupe d’administration. Affectez ensuite 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 la stratégie est un système de refus explicite. Au lieu de cela, vous devez exclure
le groupe d’administration enfant ou l’abonnement de l’attribution de stratégie au niveau du groupe
d’administration. Affectez ensuite la stratégie plus permissive au niveau du groupe d’administration enfant ou de
l’abonnement. Si une stratégie se traduit par le refus d’une ressource, alors la seule façon d’autoriser la ressource
est de modifier la stratégie de refus.
Pour plus d’informations sur les définitions de stratégie et 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.
Paramètres 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 pouvez créer une initiative intitulée Activer la surveillance dans Azure Security
Center, avec comme objectif de surveiller toutes les recommandations de sécurité disponibles dans votre centre
Azure Security Center.
NOTE
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 les bases de données non chiffrées dans Security Center : 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 Security Center : pour surveiller les
serveurs qui ne répondent pas à la ligne de base configurée.
Surveiller l’absence d’Endpoint Protection dans Security Center : pour surveiller les serveurs où un
agent Endpoint Protection n’est pas installé.
Affectation d’initiative
Comme une affectation de stratégie, une affectation d’initiative est une définition d’initiative affectée à une
étendue spécifique. Les affectations d’initiative réduisent la nécessité de créer plusieurs définitions d’initiative pour
chaque étendue. Cette étendue peut aussi aller d’un groupe d’administration à une ressource individuelle.
Chaque initiative est affectable à différentes étendues. Une initiative peut être affectée à subscriptionA et
subscriptionB.
Paramètres d’initiative
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 :
STRATÉGIE NOM DE PARAMÈTRE TYPE DE PARAMÈTRE REMARQUE
policyA allowedLocations tableau Ce paramètre attend une

liste de chaînes pour une
valeur, le type de paramètre
ayant été défini comme
tableau
policyB allowedSingleLocation string Ce paramètre attend un mot

pour une valeur, le type de
paramètre ayant été défini
comme chaîne
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.
Nombre maximal d’objets Azure Policy

Il existe un nombre maximal pour chaque type d'objet concernant Azure Policy. Une entrée Scope (Étendue) fait
référence soit à l’abonnement, soit au groupe d’administration.
WHERE QUOI NOMBRE MAXIMAL
Étendue Définitions de stratégies 500
Étendue Définitions d’initiative 100
Locataire Définitions d’initiative 1 000
Étendue Affectations de stratégies et d'initiatives 100

WHERE QUOI NOMBRE MAXIMAL
Définition de stratégie parameters 20
Définition d’initiative Stratégies 100
Définition d’initiative parameters 100
Affectations de stratégies et d'initiatives Exclusion (notScopes) 400
Règle de stratégie Éléments conditionnels imbriqués 512
Recommandations pour la gestion des stratégies

Voici quelques conseils et astuces à garder à l’esprit :
Commencez avec un effet d’audit plutôt qu’un effet de refus 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 de refus 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 pour une définition de
stratégie unique. Par exemple, vous avez la définition de stratégie policyDefA et la créez sous la définition
d’initiative initiativeDefC. Si vous créez une autre définition de stratégie ultérieurement 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 d’initiatives.
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.
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.
É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 :
Affecter une définition de stratégie à l’aide du portail.
Affecter une définition de stratégie avec Azure CLI.
Affecter une définition de stratégie avec PowerShell.
minutes to read • Edit Online
La première étape pour comprendre la conformité dans Azure consiste à identifier l’état de vos ressources. Ce
démarrage rapide vous guide pas à pas dans le processus de création d’une attribution de stratégie pour
identifier les machines virtuelles qui n’utilisent pas de disques managés.
À la fin de ce processus, vous aurez identifié correctement les machines virtuelles qui n’utilisent pas de disques
managés. Elles sont non conformes à l’attribution de stratégie.
Prérequis
Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Créer une affectation de stratégie

Dans ce guide de démarrage rapide, vous créez une attribution de stratégie et affectez la définition de stratégie
Auditer les machines virtuelles qui n’utilisent pas de disques managés.
1. Lancez le service Azure Policy dans le portail Azure en cliquant sur Tous les services, puis en recherchant
et en cliquant sur Stratégie.
2. Sélectionnez Affectations du côté gauche de la page Azure Policy. Une affectation est une stratégie qui a
été affectée pour être appliquée dans une étendue spécifique.
3. Sélectionnez Assigner une stratégie en haut de la pageStratégie - Affectations.

4. Dans la page Assigner une stratégie, sélectionnez l’étendue en cliquant sur les points de suspension et
en sélectionnant un groupe d’administration ou un abonnement. Sélectionnez éventuellement un groupe
de ressources. Une étendue détermine les ressources ou le regroupement de ressources sur lequel la
stratégie est appliquée. Cliquez ensuite sur Sélectionner dans le bas de la page Étendue.
Cet exemple utilise l’abonnement Contoso. Votre abonnement sera différent.
5. Vous pouvez exclure des ressources en fonction de l’étendue. Les exclusions commencent à un niveau
inférieur à celui de l’étendue. Les exclusions étant facultatives, laissez ce champ vide pour l’instant.
6. Sélectionnez les points de suspension de Définition de stratégie pour ouvrir la liste des définitions
disponibles. Azure Policy est fourni avec des définitions de stratégie intégrées que vous pouvez utiliser. De
nombreuses définitions de stratégie sont disponibles, par exemple :
Enforce tag and its value
Apply tag and its value
Nécessitent SQL Server version 12.0
Pour obtenir une liste partielle des stratégies intégrées disponibles, consultez Exemples Azure Policy.
7. Recherchez la définition Auditer les machines virtuelles qui n’utilisent pas de disques managés dans la liste
des définitions de stratégie. Cliquez sur cette stratégie, puis sur Sélectionner.
8. Le Nom de l’attribution est automatiquement rempli avec le nom de stratégie que vous avez
sélectionné, mais vous pouvez le modifier. Pour cet exemple, conservez Auditer les machines virtuelles qui
n’utilisent pas de disques managés. Vous pouvez également ajouter une Description (facultatif). La
description fournit des détails sur cette affectation de stratégie. Le champ Affectée par est
automatiquement renseigné en fonction de l’utilisateur connecté. Ce champ étant facultatif, vous pouvez
entrer des valeurs personnalisées.
9. Laissez la case Créer une identité managée non cochée. Vous devez la cocher si la stratégie ou
l’initiative inclut une stratégie avec l’effet deployIfNotExists. La stratégie utilisée dans ce guide de
démarrage rapide n'étant pas concernée, ne cochez pas la case. Pour plus d’informations, consultez
Identités managées et Fonctionnement de la sécurité par correction.
10. Cliquez sur Affecter.
Vous êtes maintenant prêt à identifier les ressources non conformes pour comprendre l’état de conformité de
votre environnement.
Identifier les ressources non conformes

Sélectionnez Conformité dans la partie gauche de la page. Recherchez ensuite l’affectation de stratégie Auditer
les machines virtuelles qui n’utilisent pas de disques managés que vous avez créée.
Si des ressources existantes ne sont pas conformes à cette nouvelle affectation, elles apparaissent sous
Ressources non conformes.
Si une condition est évaluée par rapport à vos ressources existantes et génère la valeur true, ces ressources sont
marquées comme non conformes à la stratégie. Le tableau suivant montre comment les différents effets des
stratégies fonctionnent avec l’évaluation des conditions pour l’état de conformité résultant. Même si vous ne
voyez pas la logique d’évaluation dans le portail Azure, les résultats de l’état de conformité sont affichés. Le
résultat d’état de conformité est soit conforme, soit non conforme.
ÉVALUATION DE LA
ÉTAT DE LA RESSOURCE EFFET STRATÉGIE ÉTAT DE CONFORMITÉ
Exists Deny, Audit, Append*, True Non conforme

DeployIfNotExist*,
AuditIfNotExist*
Exists Deny, Audit, Append*, False Conforme

DeployIfNotExist*,
AuditIfNotExist*
Nouveau Audit, AuditIfNotExist* True Non conforme
Nouveau Audit, AuditIfNotExist* False Conforme
* Les effets Append, DeployIfNotExist et AuditIfNotExist nécessitent que l’instruction IF ait la valeur TRUE. Les
effets nécessitent également que la condition d’existence ait la valeur FALSE pour être non conformes. Lorsque la
valeur est TRUE, la condition IF déclenche l’évaluation de la condition d’existence pour les ressources associées.
Supprimer des ressources

Pour supprimer l’affectation créée, procédez comme suit :
1. Sélectionnez Conformité (ou Affectations) dans la partie gauche de la page Azure Policy et recherchez
l’affectation de stratégie Auditer les machines virtuelles qui n’utilisent pas de disques managés que
vous avez créée.
2. Cliquez avec le bouton droit sur l’affectation de stratégie Auditer les machines virtuelles qui
n’utilisent pas de disques managés et sélectionnez Supprimer l’attribution.
Étapes suivantes
Dans ce guide de démarrage rapide, vous avez affecté une définition de stratégie à une étendue et vous avez
évalué son rapport de conformité. La définition de stratégie permet de vérifier que toutes les ressources dans
l’étendue sont conformes, ainsi que d’identifier celles qui ne le sont pas.
Pour en savoir plus sur l’affectation de stratégies visant à vérifier que les nouvelles ressources sont conformes,
suivez le tutoriel :
Création et gestion des stratégies
La première étape pour comprendre la conformité dans Azure consiste à identifier l’état de vos ressources. Dans
ce démarrage rapide, vous créerez une affectation de stratégie pour identifier les machines virtuelles qui
n’utilisent pas de disques managés. Lorsque vous aurez terminé, vous identifierez les machines virtuelles qui ne
sont pas conformes.
Le module Azure PowerShell est utilisé pour gérer des ressources Azure à partir de la ligne de commande ou
dans des scripts. Ce guide explique comment utiliser un module Az pour créer une attribution de stratégie.
Conditions préalables requises

Avant de commencer, assurez-vous que la dernière version d’Azure PowerShell est installée. Pour plus
d'informations, consultez Installer le module Azure PowerShell.
Inscrivez le fournisseur de ressources Azure Policy Insights à l’aide d’Azure PowerShell. L’inscription du
fournisseur de ressources permet de s’assurer que votre abonnement fonctionne avec lui. Pour inscrire un
fournisseur de ressources, vous devez avoir l’autorisation pour une opération de fournisseur de ressources.
Cette opération est incluse dans les rôles de contributeur et de propriétaire. Exécutez la commande
suivante pour enregistrer le fournisseur de ressources :
# Register the resource provider if it's not already registered

Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
Pour plus d’informations sur l’inscription et l’affichage des fournisseurs de ressources, consultez
Fournisseurs et types de ressources.
Utiliser Azure Cloud Shell

Azure héberge Azure Cloud Shell, un environnement d’interpréteur de commandes interactif que vous pouvez
utiliser dans votre navigateur. Vous pouvez utiliser Bash ou PowerShell avec Cloud Shell pour utiliser les services
Azure. Vous pouvez utiliser les commandes préinstallées Cloud Shell pour exécuter le code de cet article sans
avoir à installer quoi que ce soit dans votre environnement local.
Pour démarrer Azure Cloud Shell :
OPTION EXEMPLE/LIEN
Sélectionnez Essayer dans le coin supérieur droit d’un bloc de

code. La sélection de Essayer ne copie pas automatiquement
le code dans Cloud Shell.
Accédez à https://shell.azure.com ou sélectionnez le bouton

Lancer Cloud Shell pour ouvrir Cloud Shell dans votre
navigateur.
Sélectionnez le bouton Cloud Shell dans la barre de menus

en haut à droite du portail Azure.
Pour exécuter le code de cet article dans Azure Cloud Shell :
1. Démarrez Cloud Shell.
2. Sélectionnez le bouton Copier dans un bloc de code pour copier le code.
3. Collez le code dans la session Cloud Shell en sélectionnant Ctrl+Maj+V sur Windows et Linux, ou en
sélectionnant Cmd+Maj+V sur macOS.
4. Sélectionnez Entrée pour exécuter le code.

Dans ce guide de démarrage rapide, vous créez une attribution de stratégie pour la définition Auditer des
machines virtuelles sans disques managés. Cette définition de stratégie identifie des machines virtuelles n’utilisant
pas de disques managés.
Exécutez la commande suivante pour créer une nouvelle attribution de stratégie :
# Get a reference to the resource group that will be the scope of the assignment
$rg = Get-AzResourceGroup -Name '<resourceGroupName>'
# Get a reference to the built-in policy definition that will be assigned

$definition = Get-AzPolicyDefinition | Where-Object { $_.Properties.DisplayName -eq 'Audit VMs that do not
use managed disks' }
# Create the policy assignment with the built-in definition against your resource group
New-AzPolicyAssignment -Name 'audit-vm-manageddisks' -DisplayName 'Audit VMs without managed disks
Assignment' -Scope $rg.ResourceId -PolicyDefinition $definition
Les commandes précédentes utilisent les informations suivantes :

Name : nom réel de l’attribution. Pour cet exemple, audit-vm -manageddisks a été utilisé.
DisplayName : nom d’affichage pour l’attribution de stratégie. Dans ce cas, nous allons utiliser l’affectation
Audit VMs without managed disks (Auditer les machines virtuelles sans disques managés).
Definition : définition de la stratégie, que vous utilisez pour créer l’attribution. Dans ce cas, il s’agit de l’ID de
la définition de stratégie Auditer les machines virtuelles qui n’utilisent pas de disques managés.
Scope : une étendue détermine les ressources ou le regroupement de ressources sur lequel l’attribution de
stratégie est appliquée. Elle va d’un abonnement à des groupes de ressources. Assurez-vous de remplacer
<scope> par le nom de votre groupe de ressources.
Vous êtes maintenant prêt à identifier les ressources non conformes pour comprendre l’état de conformité de
votre environnement.

Utilisez les informations suivantes pour identifier les ressources qui ne sont pas conformes à l’attribution de
stratégie que vous avez créée. Exécutez les commandes suivantes :
# Get the resources in your resource group that are non-compliant to the policy assignment
Get-AzPolicyState -ResourceGroupName $rg.ResourceGroupName -PolicyAssignmentName 'audit-vm-manageddisks' -
Filter 'IsCompliant eq false'
Pour plus d’informations sur l’obtention de l’état de la stratégie, voir Get-AzPolicyState.

Vos résultats doivent ressembler à l’exemple suivant :
Timestamp : 3/9/19 9:21:29 PM
ResourceId :
/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachine
s/{vmId}
PolicyAssignmentId :
/subscriptions/{subscriptionId}/providers/microsoft.authorization/policyassignments/audit-vm-manageddisks
PolicyDefinitionId : /providers/Microsoft.Authorization/policyDefinitions/06a78e20-9358-41c9-923c-
fb736d382a4d
IsCompliant : False
SubscriptionId : {subscriptionId}
ResourceType : /Microsoft.Compute/virtualMachines
ResourceTags : tbd
PolicyAssignmentName : audit-vm-manageddisks
PolicyAssignmentOwner : tbd
PolicyAssignmentScope : /subscriptions/{subscriptionId}
PolicyDefinitionName : 06a78e20-9358-41c9-923c-fb736d382a4d
PolicyDefinitionAction : audit
PolicyDefinitionCategory : Compute
ManagementGroupIds : {managementGroupId}
Les résultats correspondent à ce que vous voyez sous l’onglet Conformité des ressources d’une attribution de
stratégie dans la vue du portail Azure.
Nettoyer les ressources

Utilisez la commande suivante pour supprimer l’affectation créée :
# Removes the policy assignment

Remove-AzPolicyAssignment -Name 'audit-vm-manageddisks' -Scope
'/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>'
Étapes suivantes
Dans ce démarrage rapide, vous avez affecté une définition de stratégie pour identifier les ressources non
conformes de votre environnement Azure.
démarrage rapide vous guide pas à pas dans le processus de création d’une attribution de stratégie pour identifier
les machines virtuelles qui n’utilisent pas de disques managés.
Azure CLI permet de créer et de gérer des ressources Azure à partir de la ligne de commande ou dans des scripts.
Ce guide utilise l’interface de ligne de commande Azure pour créer une attribution de stratégie et identifier les
ressources non conformes dans votre environnement Azure.

Ce guide de démarrage rapide nécessite que vous exécutiez la version 2.0.76 (ou ultérieure) d’Azure CLI
pour installer et utiliser l’interface de ligne de commande localement. Pour connaître la version de
l’interface, exécutez az --version . Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Inscrivez le fournisseur de ressources Azure Policy Insights à l'aide d'Azure CLI. L’inscription du
fournisseur de ressources permet de s’assurer que votre abonnement fonctionne avec lui. Pour inscrire un
fournisseur de ressources, vous devez avoir l’autorisation pour une opération de fournisseur de ressources.
Cette opération est incluse dans les rôles de contributeur et de propriétaire. Exécutez la commande
suivante pour enregistrer le fournisseur de ressources :
az provider register --namespace 'Microsoft.PolicyInsights'
Si ce n’est pas déjà fait, installez ARMClient. C’est un outil qui envoie des requêtes HTTP aux API Azure
Resource Manager.
Utiliser Azure Cloud Shell

Azure héberge Azure Cloud Shell, un environnement d’interpréteur de commandes interactif que vous pouvez
utiliser dans votre navigateur. Vous pouvez utiliser Bash ou PowerShell avec Cloud Shell pour utiliser les services
Azure. Vous pouvez utiliser les commandes préinstallées Cloud Shell pour exécuter le code de cet article sans
avoir à installer quoi que ce soit dans votre environnement local.
Pour démarrer Azure Cloud Shell :
OPTION EXEMPLE/LIEN
Sélectionnez Essayer dans le coin supérieur droit d’un bloc de

code. La sélection de Essayer ne copie pas automatiquement
le code dans Cloud Shell.
OPTION EXEMPLE/LIEN
Accédez à https://shell.azure.com ou sélectionnez le bouton

Lancer Cloud Shell pour ouvrir Cloud Shell dans votre
navigateur.
Sélectionnez le bouton Cloud Shell dans la barre de menus

en haut à droite du portail Azure.
Pour exécuter le code de cet article dans Azure Cloud Shell :

1. Démarrez Cloud Shell.
2. Sélectionnez le bouton Copier dans un bloc de code pour copier le code.
3. Collez le code dans la session Cloud Shell en sélectionnant Ctrl+Maj+V sur Windows et Linux, ou en
sélectionnant Cmd+Maj+V sur macOS.
4. Sélectionnez Entrée pour exécuter le code.

Dans ce guide de démarrage rapide, vous créez une attribution de stratégie et affectez la définition Auditer les
machines virtuelles qui n’utilisent pas de disques managés. Cette stratégie identifie les ressources qui ne
sont pas conformes aux conditions définies dans sa définition.
Exécutez la commande suivante pour créer une attribution de stratégie :
az policy assignment create --name 'audit-vm-manageddisks' --display-name 'Audit VMs without managed disks
Assignment' --scope '<scope>' --policy '<policy definition ID>'
La commande précédente utilise les informations suivantes :

Name : nom réel de l’attribution. Pour cet exemple, audit-vm -manageddisks a été utilisé.
DisplayName : nom d’affichage pour l’attribution de stratégie. Dans ce cas, nous allons utiliser l’affectation
Audit VMs without managed disks (Auditer les machines virtuelles sans disques managés).
Policy : ID de définition de la stratégie, que vous utilisez pour créer l’attribution. Dans ce cas, il s’agit de l’ID de
la définition de stratégie Auditer les machines virtuelles qui n’utilisent pas de disques managés. Pour obtenir
l’ID de définition de stratégie, exécutez cette commande :
az policy definition list --query "[?displayName=='Audit VMs that do not use managed disks']"
Scope : une étendue détermine les ressources ou le regroupement de ressources sur lequel l’attribution de
stratégie est appliquée. Elle va d’un abonnement à des groupes de ressources. Assurez-vous de remplacer
<scope> par le nom de votre groupe de ressources.

Pour afficher les ressources qui ne sont pas conformes à cette nouvelle attribution, obtenez l’ID d’attribution de
stratégie en exécutant les commandes suivantes :
az policy assignment list --query "[?displayName=='Audit VMs without managed disks Assignment'].id"
Pour plus d’informations sur les ID d’affectation de stratégie, consultez az policy assignment.
Exécutez ensuite la commande suivante pour obtenir les ID des ressources non conformes, intégrés dans un
fichier JSON :
armclient post
"/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.PolicyInsights/policyStates/late
st/queryResults?api-version=2019-09-01&$filter=IsCompliant eq false and PolicyAssignmentId eq
'<policyAssignmentID>'&$apply=groupby((ResourceId))" > <json file to direct the output with the resource IDs
into>
{
"@odata.context":
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/
$metadata#latest",
"@odata.count": 3,
"value": [{
"@odata.id": null,
"@odata.context":
$metadata#latest/$entity",
"ResourceId":
"/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtual
machineId>"
},
{
"@odata.id": null,
"@odata.context":
"ResourceId":
"/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtual
machine2Id>"
},
{
"@odata.id": null,
"@odata.context":
"ResourceId":
"/subscriptions/<subscriptionName>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtu
almachine3ID>"
}
]
}
Les résultats sont comparables à ce que vous devriez généralement voir sous Ressources non conformes dans
la vue du portail Azure.

Utilisez la commande suivante pour supprimer l’affectation créée :
az policy assignment delete --name 'audit-vm-manageddisks' --scope

'/subscriptions/<subscriptionID>/<resourceGroupName>'
Étapes suivantes
Dans ce démarrage rapide, vous avez affecté une définition de stratégie pour identifier les ressources non
conformes de votre environnement Azure.
démarrage rapide vous guide pas à pas dans le processus de création d’une attribution de stratégie pour identifier
les machines virtuelles qui n’utilisent pas de disques managés.


Dans ce guide de démarrage rapide, vous allez créer une affectation de stratégie et affecter une définition de
stratégie intégrée appelée Auditer les machines virtuelles qui n’utilisent pas de disques managés. Pour obtenir une
liste partielle des stratégies intégrées disponibles, consultez Exemples Azure Policy.
Il existe plusieurs méthodes pour créer des affectations de stratégie. Dans ce guide de démarrage rapide, vous allez
utiliser un modèle de démarrage rapide. Voici une copie du modèle :
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"policyAssignmentName": {
"type": "string",
"metadata": {
"description": "Specifies the name of the policy assignment."
}
},
"rgName":{
"type": "string",
"defaultValue": "[resourceGroup().name]",
"metadata": {
"description": "Specifies the name of the resource group where you want to assign the policy."
}
},
"policyDefinitionID": {
"type": "string",
"metadata": {
"description": "Specifies the ID of the policy definition or policy set definition being assigned."
}
}
},
"resources": [
{
"type": "Microsoft.Authorization/policyAssignments",
"name": "[parameters('policyAssignmentName')]",
"apiVersion": "2018-05-01",
"properties": {
"scope": "[concat(subscription().id, '/resourceGroups/', parameters('rgName'))]",
"policyDefinitionId": "[parameters('policyDefinitionID')]"
}
}
]
}
NOTE
Le service Azure Policy est gratuit. Pour plus d’informations, consultez Vue d’ensemble d’Azure Policy.
1. Sélectionnez l’image suivante pour vous connecter au portail Azure et ouvrir le modèle :
2. Sélectionnez ou entrez les valeurs suivantes :
NAME VALEUR
Subscription Sélectionnez votre abonnement Azure.
Resource group Sélectionnez Créer, spécifiez un nom, puis sélectionnez

OK. Dans la capture d’écran, le nom du groupe de
ressources est mypolicyquickstart<date au format
MMJJ>rg.
Location Sélectionnez une région. Par exemple, USA Centre.

NAME VALEUR
Nom de l’affectation de stratégie Spécifiez un nom d’affectation de stratégie. Vous pouvez

utiliser l’écran de définition de stratégie si vous le
souhaitez. Par exemple, Auditer les machines virtuelles
qui n’utilisent pas de disques managés.
Nom du groupe de ressources Spécifiez le nom du groupe de ressources auquel vous

voulez affecter la stratégie. Dans ce démarrage rapide,
utilisez la valeur par défaut [resourceGroup().name] .
resourceGroup() est une fonction de modèle qui
récupère le groupe de ressources.
ID de définition de stratégie Spécifiez

/providers/Microsoft.Authorization/policyDefinitions/
0a914e76-4921-4c19-b460-a2d36003525a.
J’accepte les termes et conditions mentionnés ci-dessus (Sélectionner)
3. Sélectionnez Achat.
Ressources supplémentaires :
Pour trouver des exemples de modèles supplémentaires, consultez Modèle de démarrage rapide Azure.
Pour obtenir des informations de référence sur les modèles, accédez au document de référence des modèles
Azure.
Pour savoir comment développer des modèles Resource Manager, consultez la documentation Azure Resource
Manager.
Pour découvrir le déploiement au niveau de l’abonnement, consultez Créer des groupes de ressources et des
ressources au niveau de l’abonnement.

Sélectionnez Conformité dans la partie gauche de la page. Recherchez ensuite l’affectation de stratégie Auditer
les machines virtuelles qui n’utilisent pas de disques managés que vous avez créée.
Si des ressources existantes ne sont pas conformes à cette nouvelle affectation, elles apparaissent sous Ressources
non conformes.
Pour plus d’informations, consultez Fonctionnement de la conformité.

Pour supprimer l’affectation créée, procédez comme suit :
1. Sélectionnez Conformité (ou Affectations) dans la partie gauche de la page Azure Policy et recherchez
l’affectation de stratégie Auditer les machines virtuelles qui n’utilisent pas de disques managés que
vous avez créée.
2. Cliquez avec le bouton droit sur l’affectation de stratégie Auditer les machines virtuelles qui n’utilisent
pas de disques managés et sélectionnez Supprimer l’attribution.
Étapes suivantes
Dans ce démarrage rapide, vous avez affecté une définition de stratégie intégrée à une étendue et vous avez évalué
son rapport de conformité. La définition de stratégie permet de vérifier que toutes les ressources dans l’étendue
sont conformes, ainsi que d’identifier celles qui ne le sont pas.
Il est important de comprendre comment créer et gérer des stratégies dans Azure pour rester conforme aux
normes de votre entreprise et aux contrats de niveau de service. Dans ce tutoriel, vous allez découvrir comment
utiliser Azure Policy pour effectuer certaines des tâches les plus courantes liées à la création, à l’affectation et à la
gestion des stratégies dans votre organisation, notamment :
Affecter une stratégie pour appliquer une condition aux ressources que vous créez dans le futur
Créer et affecter une définition d’initiative pour effectuer le suivi de la conformité de plusieurs ressources
Résoudre une ressource non conforme ou refusée
Implémenter une nouvelle stratégie dans l’ensemble de l’entreprise
Si vous souhaitez affecter une stratégie pour identifier l’état actuel de la conformité de vos ressources existantes,
consultez les articles de démarrage rapide qui passent en revue la marche à suivre.

Attribution d’une stratégie

La première étape de l’application de la conformité avec une stratégie Azure consiste à affecter une définition de
stratégie. Une définition de stratégie définit dans quelle condition une stratégie est appliquée et l’action à effectuer.
Dans cet exemple, affectez une définition de stratégie intégrée appelée Exiger SQL Server version 12.0 afin
d’appliquer la condition selon laquelle toutes les bases de données SQL Server doivent être de version 12.0 pour
être compatibles.
1. Accédez au portail Azure pour attribuer des stratégies. Recherchez et sélectionnez Stratégie.
2. Sélectionnez Affectations du côté gauche de la page Azure Policy. Une affectation est une stratégie qui a
été affectée pour être appliquée dans une étendue spécifique.
3. Sélectionnez Assigner une stratégie en haut de la pageStratégie - Affectations.
4. Dans la page Assigner une stratégie, sous l’onglet De base, sélectionnez l’étendue en sélectionnant les
points de suspension, puis en sélectionnant un groupe d’administration ou un abonnement. Sélectionnez
éventuellement un groupe de ressources. Une étendue détermine les ressources ou le regroupement de
ressources sur lequel la stratégie est appliquée. Cliquez ensuite sur Sélectionner au bas de la page
Étendue.
Cet exemple utilise l’abonnement Contoso. Votre abonnement sera différent.
5. Vous pouvez exclure des ressources en fonction de l’étendue. Les exclusions commencent à un niveau
inférieur à celui de l’étendue. Les exclusions étant facultatives, laissez ce champ vide pour l’instant.
6. Sélectionnez les points de suspension de Définition de stratégie pour ouvrir la liste des définitions
disponibles. Vous pouvez filtrer le Type de définition de stratégie sur BuiltIn pour les afficher tous et lire
leurs descriptions.
7. Sélectionnez Ajouter ou remplacer une étiquette dans les ressources. Si vous ne trouvez pas l’option
immédiatement, tapez ajouter ou remplacer dans la zone de recherche, puis appuyez sur Entrée ou
cliquez en dehors de la zone de recherche. Cliquez sur Sélectionner au bas de la page Définitions
disponibles une fois que vous avez trouvé et sélectionné la définition de stratégie.
8. Le Nom de l’attribution est automatiquement rempli avec le nom de stratégie que vous avez sélectionné,
mais vous pouvez le modifier. Pour cet exemple, laissez Ajouter ou remplacer une étiquette dans les
ressources. Vous pouvez également ajouter une Description (facultatif). La description fournit des détails
sur cette affectation de stratégie.
9. Laissez Application de la stratégie définie sur Activée. Le paramètre Désactivée permet de tester le
résultat de la stratégie sans en déclencher l’effet. Pour plus d’informations, consultez Mode de mise en
conformité.
10. Affectée par est automatiquement renseigné en fonction de l’utilisateur connecté. Ce champ étant
facultatif, vous pouvez entrer des valeurs personnalisées.
11. Sélectionnez l’onglet Paramètres en haut de l’Assistant.
12. Pour le nom de l’étiquette, entrez Environnement et pour la valeur de l’étiquette, entrez Dev.
13. Sélectionnez l’onglet Correction en haut de l’Assistant.
14. Laissez la case Créer une tâche de correction décochée. Cette case vous permet de créer une tâche pour
modifier les ressources existantes en plus des ressources nouvelles ou mises à jour. Pour plus
d’informations, consultez Corriger les ressources.
15. La case Créer une identité managée est automatiquement cochée car cette définition de stratégie utilise
l’effet modifier. L’option Autorisations a automatiquement la valeur Contributeur en fonction de la
définition de stratégie. Pour plus d’informations, consultez Identités managées et Fonctionnement de la
sécurité par correction.
16. Sélectionnez l’onglet Vérifier + créer en haut de l’Assistant.
17. Passez en revue vos sélections, puis sélectionnez Créer au bas de la page.
Implémenter une nouvelle stratégie personnalisée

Maintenant que vous avez affecté une définition de stratégie intégrée, vous pouvez continuer avec Azure Policy.
Créez une stratégie personnalisée pour réduire les coûts en veillant à ce que les machines virtuelles créées dans
votre environnement ne puissent pas être dans la série G. De cette manière, à chaque fois qu’un utilisateur de
votre organisation tente de créer une machine virtuelle dans la série G, la requête est refusée.
1. Sélectionnez Définitions sous Création dans la partie gauche de la page Azure Policy.
2. Sélectionnez + Définition de stratégie en haut de la page. Ce bouton ouvre la page Définition de
stratégie.
3. Entrez les informations suivantes :
Le groupe d’administration ou l’abonnement dans lequel la définition de stratégie est enregistrée.
Sélectionnez-le à l’aide du bouton de sélection Emplacement de définition.
NOTE
Si vous envisagez d’appliquer cette définition de stratégie à plusieurs abonnements, l’emplacement doit
correspondre à un groupe d’administration qui contient les abonnements auxquels vous affectez la stratégie.
Il en va de même pour une définition d’initiative.
Le nom de la définition de stratégie : _*nécessite des références (SKU ) de machines virtuelles

inférieures à la série G
La description de l’objectif de la définition de stratégie : cette définition de stratégie impose que
toutes les machines virtuelles créées dans cette étendue possèdent des références SKU inférieures à
la série G afin de réduire le coût.
Faites votre choix parmi les options existantes (par exemple Calculer), ou créez une catégorie pour
cette définition de stratégie.
Copiez le code JSON suivant, puis mettez-le à jour selon vos besoins avec :
Les paramètres de la stratégie.
Les règles/conditions de la stratégie, dans ce cas : la taille de la référence (SKU ) de la machine
virtuelle est égale à la série G
L’effet de la stratégie, dans ce cas – Refuser.
Voici à quoi le code JSON doit ressembler. Collez le code révisé dans le portail Azure.
{
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/sku.name",
"like": "Standard_G*"
}
]
},
"then": {
"effect": "deny"
}
}
}
La propriété champ dans la règle de stratégie doit être une valeur prise en charge. La liste complète des
valeurs est disponible dans les champs de structure de la définition de stratégie. Exemple d’alias :
"Microsoft.Compute/VirtualMachines/Size" .
Pour voir d’autres exemples relatifs à Azure Policy, consultez Exemples Azure Policy.
4. Sélectionnez Enregistrer.
Créer une définition de stratégie avec l’API REST

Vous pouvez créer une stratégie avec l’API REST pour les définitions Azure Policy. L’API REST vous permet de
créer et de supprimer des définitions de stratégies, ainsi que d’obtenir des informations sur les définitions
existantes. Pour créer une définition de stratégie, utilisez l’exemple suivant :
PUT
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.authorization/policydefinition
s/{policyDefinitionName}?api-version={api-version}
Incluez un texte de demande semblable à l’exemple suivant :

{
"properties": {
"parameters": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying resources",
"strongType": "location",
"displayName": "Allowed locations"
}
}
},
"displayName": "Allowed locations",
"description": "This policy enables you to restrict the locations your organization can specify when
deploying resources.",
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "deny"
}
}
}
}
Créer une définition de stratégie avec PowerShell

Avant de passer à l’exemple PowerShell, assurez-vous d’avoir installé la dernière version du module Azure
PowerShell Az.
Vous pouvez créer une définition de stratégie en utilisant l’applet de commande New-AzPolicyDefinition .
Pour créer une définition de stratégie à partir d’un fichier, transmettez le chemin d’accès au fichier.Pour un fichier
externe, utilisez l’exemple suivant :
$definition = New-AzPolicyDefinition `
-Name 'denyCoolTiering' `
-DisplayName 'Deny cool access tiering for storage' `
-Policy 'https://raw.githubusercontent.com/Azure/azure-policy-samples/master/samples/Storage/storage-
account-access-tier/azurepolicy.rules.json'
Pour un fichier local, utilisez l’exemple suivant :
$definition = New-AzPolicyDefinition `
-Name 'denyCoolTiering' `
-Description 'Deny cool access tiering for storage' `
-Policy 'c:\policies\coolAccessTier.json'
Pour créer une définition de stratégie avec une règle en ligne, utilisez l’exemple suivant :
$definition = New-AzPolicyDefinition -Name 'denyCoolTiering' -Description 'Deny cool access tiering for
storage' -Policy '{
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "kind",
"equals": "BlobStorage"
},
{
"field": "Microsoft.Storage/storageAccounts/accessTier",
"equals": "cool"
}
]
},
"then": {
"effect": "deny"
}
}'
Le résultat est stocké dans un objet $definition utilisé lors de l’attribution de la stratégie. L’exemple suivant crée
une définition de stratégie qui inclut des paramètres :
$policy = '{
"if": {
"allOf": [{
"field": "type",
},
{
"not": {
"in": "[parameters(''allowedLocations'')]"
}
}
]
},
"then": {
"effect": "Deny"
}
}'
$parameters = '{
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying storage accounts.",
}
}
}'
$definition = New-AzPolicyDefinition -Name 'storageLocations' -Description 'Policy to specify locations for

storage accounts.' -Policy $policy -Parameter $parameters
Voir les définitions de stratégie avec PowerShell

Pour afficher toutes les définitions de stratégie dans votre abonnement, utilisez la commande suivante :
Get-AzPolicyDefinition
Elle renvoie toutes les définitions de stratégie disponibles, y compris les stratégies intégrées. Chaque stratégie est
renvoyée au format suivant :
Name : e56962a6-4747-49cd-b67b-bf8b01975c4c
ResourceId : /providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c
ResourceName : e56962a6-4747-49cd-b67b-bf8b01975c4c
ResourceType : Microsoft.Authorization/policyDefinitions
Properties : @{displayName=Allowed locations; policyType=BuiltIn; description=This policy enables you
to
restrict the locations your organization can specify when deploying resources. Use to
enforce
your geo-compliance requirements.; parameters=; policyRule=}
PolicyDefinitionId : /providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c
Créer une définition de stratégie avec Azure CLI

Vous pouvez créer une définition de stratégie à l’aide d’Azure CLI avec la commande az policy definition . Pour
créer une définition de stratégie avec une règle en ligne, utilisez l’exemple suivant :
az policy definition create --name 'denyCoolTiering' --description 'Deny cool access tiering for storage' --
rules '{
"if": {
"allOf": [{
"field": "type",
},
{
"field": "kind",
"equals": "BlobStorage"
},
{
"field": "Microsoft.Storage/storageAccounts/accessTier",
"equals": "cool"
}
]
},
"then": {
"effect": "deny"
}
}'
Voir les définitions de stratégie avec Azure CLI

Pour afficher toutes les définitions de stratégie dans votre abonnement, utilisez la commande suivante :
az policy definition list
Elle renvoie toutes les définitions de stratégie disponibles, y compris les stratégies intégrées. Chaque stratégie est
renvoyée au format suivant :
{
deploying resources. Use to enforce your geo-compliance requirements.",
"id": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
"name": "e56962a6-4747-49cd-b67b-bf8b01975c4c",
"policyRule": {
"if": {
"not": {
"in": "[parameters('listOfAllowedLocations')]"
}
},
"then": {
"effect": "Deny"
}
},
"policyType": "BuiltIn"
}
Créer et attribuer une définition d’initiative

Avec une définition d’initiative, vous pouvez regrouper plusieurs définitions de stratégie pour atteindre un objectif
global. Une initiative vérifie si les ressources figurant dans l’étendue de l’attribution sont conformes aux stratégies
incluses. Pour plus d’informations sur les définitions d’initiative, consultez Vue d’ensemble d’Azure Policy.
Créer une définition d’initiative
2. Sélectionnez + Définition d’initiative en haut de la page pour ouvrir la page Définition d’initiative.
3. Utilisez le bouton de sélection Emplacement de définition pour sélectionner un groupe d'administration
ou un abonnement afin de stocker la définition. Si la page précédente se limite à un seul groupe
d’administration ou à un seul abonnement, Emplacement de la définition est automatiquement
renseigné. Après sélection, l’option Définitions disponibles est renseignée.
4. Entrez le nom et la description de l’initiative.
Cet exemple vérifie que les ressources sont conformes aux définitions de stratégie relatives à la
sécurisation. Nommez l’initiative Garantir la sécurité et définissez la description comme suit : Cette
initiative a été créée pour gérer toutes les définitions de stratégie associées à la sécurisation des
ressources.
5. Pour Catégorie, choisissez une des options existantes ou créez une catégorie.
6. Parcourez la liste des définitions disponibles (partie droite de la page Définition d’initiative) et
sélectionnez les définitions de stratégie à ajouter à cette initiative. Pour l’initiative Garantir la sécurité,
ajoutez les définitions de stratégie prédéfinies suivantes en sélectionnant + en regard des informations
correspondantes ou en sélectionnant une ligne de définition de stratégie, puis l’option + Ajouter dans la
page de détails :
Emplacements autorisés
Superviser les agents Endpoint Protection manquants dans Azure Security Center
Les règles de groupe de sécurité réseau pour les machines virtuelles accessibles sur Internet doivent
être renforcées
La sauvegarde Azure doit être activée pour les machines virtuelles
Le chiffrement de disque doit être appliqué sur les machines virtuelles
Une fois que la définition de stratégie est sélectionnée dans la liste, elle est ajoutée sous Catégorie.
7. Si une définition de stratégie ajoutée à l’initiative comporte des paramètres, ils apparaissent sous le nom de
la stratégie dans la zone située sous la zone Catégorie. La valeur peut être définie sur « Définir une valeur
» (codée en dur pour toutes les affectations de cette initiative) ou « Utiliser le paramètre d'initiative »
(définie au cours de chaque affectation d’initiative). Si « Définir une valeur » est sélectionné, la liste
déroulante à droite de Valeurs permet d’entrer ou de sélectionner les valeurs. Si l’option Utiliser le
paramètre d’initiative est sélectionnée, une nouvelle section Paramètres d’initiative s’affiche, ce qui vous
permet de définir le paramètre défini durant l’affectation d’initiative. Les valeurs autorisées sur ce
paramètre d’initiative peuvent restreindre davantage ce qui peut être défini au cours de l’affectation
d’initiative.
NOTE
Dans le cas de certains paramètres strongType , la liste de valeurs ne peut pas être déterminée automatiquement.
Dans ce cas, un bouton de sélection s’affiche à droite de la ligne de paramètre. En le sélectionnant, vous ouvrez la
page Étendue du paramètre (<nom du paramètre>). Sur cette page, sélectionnez l’abonnement à utiliser pour
fournir les options de valeur. L’étendue de ce paramètre est utilisée uniquement lors de la création de la définition
d’initiative et n’a aucun impact sur l’évaluation de la stratégie ou l’étendue de l’initiative lors de l’affectation.
Définissez le paramètre « Emplacements autorisés » sur « USA Est 2 » et laissez les autres paramètres
définis sur la valeur par défaut « AuditifNotExists ».
8. Sélectionnez Enregistrer.
Créer une définition d’initiative de stratégie avec Azure CLI
Vous pouvez créer une définition d’initiative de stratégie à l’aide d’Azure CLI avec la commande
az policy set-definition . Pour créer une définition d’initiative de stratégie avec une définition de stratégie
existante, utilisez l’exemple suivant :
az policy set-definition create -n readOnlyStorage --definitions '[

{
"policyDefinitionId":
"/subscriptions/mySubId/providers/Microsoft.Authorization/policyDefinitions/storagePolicy",
"parameters": { "storageSku": { "value": "[parameters(\"requiredSku\")]" } }
}
]' \
--params '{ "requiredSku": { "type": "String" } }'
Créer une définition d’initiative de stratégie avec Azure PowerShell

Vous pouvez créer une définition d’initiative de stratégie à l’aide d’Azure PowerShell avec la cmdlet
New-AzPolicySetDefinition . Pour créer une définition d’initiative de stratégie avec une définition de stratégie
existante, utilisez le fichier de définition d’initiative de stratégie en tant que VMPolicySet.json :
[
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-
187a4f81c498",
"parameters": {
"tagName": {
"value": "Business Unit"
},
"tagValue": {
"value": "Finance"
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/464dbb85-3d5f-4a1d-bb09-
95a9b5dd19cf"
}
]
New-AzPolicySetDefinition -Name 'VMPolicySetDefinition' -Metadata '{"category":"Virtual Machine"}' -

PolicyDefinition C:\VMPolicySet.json
Attribuer une définition d’initiative

2. Recherchez la définition d’initiative Garantir la sécurité que vous avez précédemment créée et
sélectionnez-la. Sélectionnez Affecter en haut de la page pour ouvrir la page Garantir la sécurité :
affecter l’initiative.
Vous pouvez également cliquer avec le bouton droit sur la ligne sélectionnée ou sélectionner les points de
suspension situé en fin de ligne pour faire apparaître un menu contextuel. Sélectionnez ensuite Affecter.
3. Renseignez la page Garantir la sécurité : affecter l’initiative en entrant les exemples d’informations
suivants. Vous pouvez utiliser vos propres informations.
Étendue : l’abonnement ou le groupe d’administration dans lequel vous avez enregistré l’initiative
devient la valeur par défaut. Vous pouvez changer l’étendue pour affecter l’initiative à un abonnement
ou un groupe de ressources, à l’emplacement d’enregistrement.
Exclusions : configurez des ressources dans l’étendue afin d’empêcher que l’affectation d’initiative leur
soit appliquée.
Définition d’initiative et Nom de l’affectation : Garantir la sécurité (prérenseigné avec le nom de
l’initiative assignée).
Description : cette affectation d’initiative est adaptée afin d’appliquer ce groupe de définitions de
stratégie.
Application de la stratégie : Conservez la valeur par défaut Activée.
Affectée par : renseigné automatiquement en fonction de l’utilisateur connecté. Ce champ étant
facultatif, vous pouvez entrer des valeurs personnalisées.
4. Sélectionnez l’onglet Paramètres en haut de l’Assistant. Si vous avez configuré un paramètre d’initiative
dans les étapes précédentes, définissez une valeur ici.
5. Sélectionnez l’onglet Correction en haut de l’Assistant. Laissez la case Créer une identité managée non
cochée. Cette case doit être cochée quand la stratégie ou l’initiative affectée inclut une stratégie avec les
effets deployIfNotExists ou modifier. Comme ce n’est pas le cas pour la stratégie utilisée dans ce tutoriel, ne
cochez pas la case. Pour plus d’informations, consultez Identités managées et Fonctionnement de la
sécurité par correction.
6. Sélectionnez l’onglet Vérifier + créer en haut de l’Assistant.
7. Passez en revue vos sélections, puis sélectionnez Créer au bas de la page.
Vérifier la conformité initiale

1. Sélectionnez Conformité dans la partie gauche de la page Azure Policy.
2. Localisez l’initiative Garantir la sécurité. Elle est probablement toujours à l’État de conformitéNon
démarrée. Sélectionnez l’initiative pour obtenir tous les détails sur la progression de l’affectation.
3. Une fois l’affectation de l’initiative effectuée, la page de conformité est mise à jour avec l’État de
conformitéConforme.
4. Pour ouvrir la page de détails sur la conformité de la stratégie, sélectionnez une stratégie dans la page de
conformité de l’initiative. Cette page fournit des détails au niveau des ressources pour la conformité.
Exempter une ressource non conforme ou refusée en utilisant

l’exclusion
Après avoir attribué une initiative de stratégie pour exiger un emplacement spécifique, toutes les ressources
créées dans un emplacement différent sont refusées. Dans cette section, vous allez résoudre pas à pas une
situation dans laquelle la demande de création d’une ressource a été refusée en créant une exclusion sur un seul
groupe de ressources. L’exclusion empêche l’application de la stratégie (ou de l’initiative) à ce groupe de
ressources. Dans l’exemple suivant, tous les emplacements sont autorisés dans le groupe de ressources exclu. Une
exclusion peut s’appliquer à un abonnement, à un groupe de ressources ou à des ressources individuelles.
Les déploiements empêchés par une stratégie ou une initiative affectée peuvent être vus dans le groupe de
ressources ciblé par le déploiement : Sélectionnez Déploiements dans la partie gauche de la page, puis
sélectionnez le nom du déploiement qui a échoué. La ressource refusée est listée avec l’état Interdit. Pour
déterminer la stratégie ou l’initiative et l’affectation qui a refusé la ressource, sélectionnez Échec. Cliquez ici
pour plus d’informations -> dans la page Vue d’ensemble du déploiement. Une fenêtre s’ouvre dans la partie
droite de la page pour présenter les informations d’erreur. Sous Détails de l’erreur figurent les GUID des objets
de stratégie associés.
Dans la page Azure Policy : Sélectionnez Conformité du côté gauche de la page et sélectionnez l’initiative de
stratégie Garantir la sécurité. Dans cette page figure une augmentation du nombre de refus de ressources
bloquées. Sous l’onglet Événements se trouvent des détails sur les personnes qui ont essayé de créer ou de
déployer la ressource refusée par la définition de stratégie.
Dans cet exemple, Trent Baker, l’un des spécialistes de la virtualisation chez Contoso, effectuait des tâches
requises. Nous avons besoin d’accorder à Trent un espace pour une exception. Créez un groupe de ressources,
LocationsExcluded, puis octroyez-lui une exception à cette affectation de stratégie.
Mettre à jour une affectation avec une exclusion
1. Sélectionnez Affectations sous Création dans la partie gauche de la page Azure Policy.
2. Parcourez toutes les affectations de stratégie et ouvrez Garantir la sécurité.
3. Définissez l’exclusion en sélectionnant les points de suspension, puis en sélectionnant le groupe de
ressources à exclure, LocationsExcluded dans cet exemple. Sélectionnez Ajouter à l’étendue
sélectionnée, puis Enregistrer.
NOTE
En fonction de la définition de stratégie et de son effet, l’exclusion peut également être octroyée à des ressources
spécifiques au sein du groupe de ressources dans l’étendue de l’affectation. Comme un effet Refuser a été utilisé
dans ce tutoriel, il ne serait pas judicieux de définir l’exclusion sur une ressource spécifique qui existe déjà.
4. Sélectionnez Réviser + enregistrer, puis Enregistrer.

Dans cette section, vous avez résolu la demande refusée en créant une exclusion sur un seul groupe de ressources.

Si vous avez fini d’utiliser les ressources de ce tutoriel, effectuez les étapes suivantes pour supprimer les
affectations ou définitions de stratégie créées ci-dessus :
1. Sélectionnez Définitions (ou Affectations si vous essayez de supprimer une affectation) sous Création
dans la partie gauche de la page Azure Policy.
2. Recherchez la nouvelle définition d’initiative ou de stratégie (ou affectation) à supprimer.
3. Cliquez avec le bouton droit sur la liste ou cliquez sur le bouton de sélection en fin de définition (ou
d’affectation), puis sélectionnez Supprimer la définition (ou Supprimer l’affectation).
Révision
Dans ce didacticiel, vous avez effectué avec succès les tâches suivantes :
Attribué une stratégie pour appliquer une condition aux ressources que vous créez dans le futur
Créé et attribué une définition d’initiative pour effectuer le suivi de la conformité de plusieurs ressources
Résolu une ressource non conforme ou refusée
Implémenté une nouvelle stratégie dans l’ensemble de l’entreprise
Étapes suivantes
Pour plus d’informations sur les structures des définitions de stratégie, consultez cet article :
Une définition de stratégie personnalisée permet aux clients de définir leurs propres règles d’utilisation d’Azure.
Ces règles appliquent souvent :
Des mesures de sécurité
la gestion des coûts ;
Des règles propres à l’organisation (par exemple, de nommage ou d’emplacements)
Quel que soit l’objectif de la création d’une stratégie personnalisée, les étapes de définition de la nouvelle stratégie
personnalisée sont les mêmes.
Avant de créer une stratégie personnalisée, consultez les exemples de stratégie pour voir si une stratégie
correspond déjà à vos besoins.
Voici les étapes de création d’une stratégie personnalisée :
Identifier vos exigences métier
Associer chaque exigence à une propriété de ressource Azure
Associer la propriété à un alias
Déterminer l’effet à utiliser
Composer la définition de stratégie

Identifier les exigences

Avant de créer la définition de stratégie, vous devez bien définir l’intention de la stratégie. Dans ce tutoriel, nous
utilisons une exigence de sécurité d’entreprise courante pour illustrer les étapes à suivre :
Chaque compte de stockage doit être activé pour HTTPS
Chaque compte de stockage doit être désactivé pour HTTP
Vos exigences doivent identifier clairement les deux états de ressource « être » et « ne pas être ».
Nous avons défini l’état attendu de la ressource, mais nous n’avons pas encore défini ce que nous voulons faire
avec les ressources non conformes. Azure Policy prend en charge un certain nombre d’effets. Dans ce tutoriel, nous
définissons l’exigence métier de sorte à empêcher la création des ressources qui sont non conformes aux règles
métier. Pour atteindre cet objectif, nous utilisons l’effet Refuser. Nous voulons aussi pouvoir suspendre la stratégie
pour des attributions spécifiques. Par conséquent, nous utilisons l’effet Désactivé en le définissant comme
paramètre dans la définition de stratégie.
Déterminer les propriétés de ressource

D’après les besoins métier, la ressource Azure à auditer avec Azure Policy est un compte de stockage. Toutefois,
nous ne savons pas quelles sont les propriétés à utiliser dans la définition de stratégie. Azure Policy évalue la
représentation JSON de la ressource ; nous devons donc déterminer les propriétés qui sont disponibles sur cette
ressource.
Il existe de nombreuses façons de déterminer les propriétés d’une ressource Azure. Dans ce tutoriel, nous les
examinons toutes :
Exporter une ressource existante
Expérience de création
Modèles de démarrage rapide (GitHub)
Documentation de référence de modèle
Azure Resource Explorer
Afficher des ressources dans l’extension VS Code
L’extension VS Code peut être utilisée pour parcourir des ressources dans votre environnement et voir les
propriétés Resource Manager sur chaque ressource.
Il existe plusieurs façons d’examiner un modèle Resource Manager qui inclut la propriété à gérer.
Ressource existante dans le portail
Pour rechercher des propriétés, le plus simple est d’examiner une ressource existante du même type. Vous pouvez
aussi comparer les ressources déjà configurées avec le paramètre que vous voulez appliquer. Consultez la page
Exporter le modèle (sous Paramètres) dans le portail Azure pour cette ressource spécifique.
Si la ressource est un compte de stockage, vous voyez un modèle semblable à cet exemple :
...
"resources": [{
"comments": "Generalized from resource:
'/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mys
torageaccount'.",
"type": "Microsoft.Storage/storageAccounts",
"sku": {
"name": "Standard_LRS",
"tier": "Standard"
},
"kind": "Storage",
"name": "[parameters('storageAccounts_mystorageaccount_name')]",
"apiVersion": "2018-07-01",
"location": "westus",
"tags": {
"ms-resource-usage": "azure-cloud-shell"
},
"scale": null,
"properties": {
"networkAcls": {
"bypass": "AzureServices",
"virtualNetworkRules": [],
"ipRules": [],
"defaultAction": "Allow"
},
"supportsHttpsTrafficOnly": false,
"encryption": {
"services": {
"file": {
"enabled": true
},
"blob": {
"enabled": true
}
},
"keySource": "Microsoft.Storage"
}
},
"dependsOn": []
}]
...
Sous propriétés, une valeur nommée supportsHttpsTrafficOnly est définie sur false. Cette propriété a les
caractéristique de celle que nous recherchons. De plus, le type de la ressource est
Microsoft.Storage/storageAccounts. Le type nous permet de limiter la stratégie aux ressources de ce type
uniquement.
Créer une ressource dans le portail
Dans le portail, vous pouvez aussi utiliser l’expérience de création de ressource. Quand vous créez un compte de
stockage dans le portail, sous l’onglet Avancé, vous avez l’option Transfert de sécurité obligatoire. Cette
propriété a des options Désactivé et Activé. L’icône d’informations confirme que cette option est probablement la
propriété qui nous intéresse. Toutefois, le portail n’indique pas le nom de la propriété dans cet écran.
Sous l’onglet Examiner + créer, un lien en bas de la page vous permet de Télécharger un modèle pour
l’automatisation. Sélectionnez le lien pour ouvrir le modèle qui crée la ressource que nous avons configurée.
Dans notre exemple, nous voyons deux informations essentielles :
...
"supportsHttpsTrafficOnly": {
"type": "bool"
}
...
"properties": {
"accessTier": "[parameters('accessTier')]",
"supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...
Ces informations nous indiquent le type de propriété et confirment que supportsHttpsTrafficOnly est la
propriété que nous recherchons.
Modèles de démarrage rapide sur GitHub
Les modèles de démarrage rapide Azure sur GitHub ont des centaines de modèles Resource Manager destinés à
différentes ressources. Ces modèles peuvent être un excellent moyen de trouver la propriété de ressource que vous
recherchez. Certaines propriétés peuvent sembler être celles que vous cherchez, mais contrôlent quelque chose de
différent.
Documentation de référence de la ressource
Pour confirmer que supportsHttpsTrafficOnly est la propriété appropriée, consultez la référence du modèle
Resource Manager pour la ressource de compte de stockage sur le fournisseur de stockage. L’objet de propriétés a
une liste des paramètres valides. Sélectionnez le lien StorageAccountPropertiesCreateParameters-object pour
afficher un tableau des propriétés acceptables. supportsHttpsTrafficOnly est présente et la description
correspond à ce que nous recherchons pour répondre à nos exigences métier.
Azure Resource Explorer
Un autre moyen d’explorer vos ressources Azure est d’utiliser Azure Resource Explorer (préversion). Comme cet
outil utilise le contexte de votre abonnement, vous devez vous authentifier sur le site web avec vos informations
d’identification Azure. Une fois authentifié, vous pouvez parcourir les fournisseurs, les abonnements, les groupes
de ressources et les ressources.
Recherchez une ressource de compte de stockage et examinez ses propriétés. Nous voyons ici la propriété
supportsHttpsTrafficOnly. Sous l’onglet Documentation, nous voyons que la description de la propriété
correspond à ce que nous avons trouvé précédemment dans la documentation de référence.
Rechercher l’alias de propriété

Nous avons identifié la propriété de la ressource, mais nous devons mapper cette propriété à un alias.
Il existe de nombreuses façons de déterminer les alias d’une ressource Azure. Dans ce tutoriel, nous les examinons
toutes :
Azure CLI
Azure PowerShell
Azure Resource Graph
Obtenir des alias dans l’extension VS Code
L’extension Azure Policy pour l’extension VS Code facilite la navigation dans vos ressources et la découverte
d’alias.
Azure CLI
Dans Azure CLI, le groupe de commandes az provider est utilisé pour rechercher des alias de ressource. Nous
filtrons sur l’espace de noms Microsoft.Storage d’après les détails que nous avons obtenus précédemment sur la
ressource Azure.
# Login first with az login if not using Cloud Shell
# Get Azure Policy aliases for type Microsoft.Storage

az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query
"resourceTypes[].aliases[].name"
Dans les résultats, nous voyons un alias pris en charge par les comptes de stockage, nommé
supportsHttpsTrafficOnly. L’existence de cet alias signifie que nous pouvons écrire la stratégie pour appliquer
nos exigences métier !
Azure PowerShell
Dans Azure PowerShell, l’applet de commande Get-AzPolicyAlias est utilisé pour rechercher des alias de
ressource. Nous filtrons sur l’espace de noms Microsoft.Storage d’après les détails que nous avons obtenus
précédemment sur la ressource Azure.
# Login first with Connect-AzAccount if not using Cloud Shell
# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage

(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases
Comme avec Azure CLI, les résultats montrent un alias pris en charge par les comptes de stockage, nommé
supportsHttpsTrafficOnly.
Azure Resource Graph est un service qui fournit une autre méthode pour rechercher les propriétés des ressources
Azure. Voici un exemple de requête permettant d’examiner un seul compte de stockage avec Resource Graph :
Resources
| where type=~'microsoft.storage/storageaccounts'
| limit 1
az graph query -q "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1"
Search-AzGraph -Query "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1"
Les résultats sont similaires à ce que nous avons vu dans les modèles Resource Manager et dans Azure Resource
Explorer. Cependant, les résultats Azure Resource Graph peuvent également inclure des détails d’alias en projetant
le tableau d’alias :
Resources
| limit 1
| project aliases
az graph query -q "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1 | project aliases"
Search-AzGraph -Query "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1 | project aliases"

Voici un exemple de sortie de compte de stockage pour les alias :
"aliases": {
"Microsoft.Storage/storageAccounts/accessTier": null,
"Microsoft.Storage/storageAccounts/accountType": "Standard_LRS",
"Microsoft.Storage/storageAccounts/enableBlobEncryption": true,
"Microsoft.Storage/storageAccounts/enableFileEncryption": true,
"Microsoft.Storage/storageAccounts/encryption": {
"keySource": "Microsoft.Storage",
"services": {
"blob": {
"enabled": true,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
},
"file": {
"enabled": true,
}
}
},
"Microsoft.Storage/storageAccounts/encryption.keySource": "Microsoft.Storage",
"Microsoft.Storage/storageAccounts/encryption.keyvaultproperties.keyname": null,
"Microsoft.Storage/storageAccounts/encryption.keyvaultproperties.keyvaulturi": null,
"Microsoft.Storage/storageAccounts/encryption.keyvaultproperties.keyversion": null,
"Microsoft.Storage/storageAccounts/encryption.services": {
"blob": {
"enabled": true,
},
"file": {
"enabled": true,
}
},
"Microsoft.Storage/storageAccounts/encryption.services.blob": {
"enabled": true,
},
"Microsoft.Storage/storageAccounts/encryption.services.blob.enabled": true,
"Microsoft.Storage/storageAccounts/encryption.services.file": {
"enabled": true,
},
"Microsoft.Storage/storageAccounts/encryption.services.file.enabled": true,
"Microsoft.Storage/storageAccounts/networkAcls": {
"bypass": "AzureServices",
"defaultAction": "Allow",
"ipRules": [],
"virtualNetworkRules": []
},
"Microsoft.Storage/storageAccounts/networkAcls.bypass": "AzureServices",
"Microsoft.Storage/storageAccounts/networkAcls.defaultAction": "Allow",
"Microsoft.Storage/storageAccounts/networkAcls.ipRules": [],
"Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]": [],
"Microsoft.Storage/storageAccounts/networkAcls.ipRules[*].action": [],
"Microsoft.Storage/storageAccounts/networkAcls.ipRules[*].value": [],
"Microsoft.Storage/storageAccounts/networkAcls.virtualNetworkRules": [],
"Microsoft.Storage/storageAccounts/networkAcls.virtualNetworkRules[*]": [],
"Microsoft.Storage/storageAccounts/networkAcls.virtualNetworkRules[*].action": [],
"Microsoft.Storage/storageAccounts/networkAcls.virtualNetworkRules[*].id": [],
"Microsoft.Storage/storageAccounts/networkAcls.virtualNetworkRules[*].state": [],
"Microsoft.Storage/storageAccounts/primaryEndpoints": {
"blob": "https://mystorageaccount.blob.core.windows.net/",
"file": "https://mystorageaccount.file.core.windows.net/",
"queue": "https://mystorageaccount.queue.core.windows.net/",
"table": "https://mystorageaccount.table.core.windows.net/"
},
"Microsoft.Storage/storageAccounts/primaryEndpoints.blob":
"Microsoft.Storage/storageAccounts/primaryEndpoints.blob":
"https://mystorageaccount.blob.core.windows.net/",
"Microsoft.Storage/storageAccounts/primaryEndpoints.file":
"https://mystorageaccount.file.core.windows.net/",
"Microsoft.Storage/storageAccounts/primaryEndpoints.queue":
"https://mystorageaccount.queue.core.windows.net/",
"Microsoft.Storage/storageAccounts/primaryEndpoints.table":
"https://mystorageaccount.table.core.windows.net/",
"Microsoft.Storage/storageAccounts/primaryEndpoints.web": null,
"Microsoft.Storage/storageAccounts/primaryLocation": "eastus2",
"Microsoft.Storage/storageAccounts/provisioningState": "Succeeded",
"Microsoft.Storage/storageAccounts/sku.name": "Standard_LRS",
"Microsoft.Storage/storageAccounts/sku.tier": "Standard",
"Microsoft.Storage/storageAccounts/statusOfPrimary": "available",
"Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly": false
}
Azure Resource Graph peut être utilisé par le biais de Cloud Shell et devient alors un moyen simple et rapide pour
explorer les propriétés de vos ressources.

Choisir ce que vous allez faire de vos ressources non conformes est presque aussi important que choisir ce que
vous devez évaluer en premier lieu. Chaque réponse possible à une ressource non conforme est appelée un effet.
L’effet contrôle si la ressource non conforme est enregistrée, bloquée, a des données ajoutées ou est associée à un
déploiement pour la remettre dans un état conforme.
Dans notre exemple, nous voulons l’effet Refuser pour que les ressources non conformes ne soient pas créées dans
notre environnement Azure. Avant de définir l’effet Refuser, commencez par l’auditer pour déterminer l’impact de
la stratégie. Pour simplifier le changement d’effet par attribution, vous pouvez paramétrer l’effet.Consultez les
paramètres ci-dessous pour plus d’informations sur la procédure à suivre.
Composer la définition
Nous avons maintenant les détails et l’alias de la propriété correspondant à ce que nous voulons gérer. Ensuite,
nous composons la règle de stratégie proprement dite. Si vous n’êtes pas encore familiarisé avec le langage de
stratégie, consultez la structure de définition de stratégie pour savoir comment structurer la définition de stratégie.
Voici un modèle vide de définition de stratégie :
{
"properties": {
"displayName": "<displayName>",
"description": "<description>",
"mode": "<mode>",
"parameters": {
<parameters>
},
"policyRule": {
"if": {
<rule>
},
"then": {
"effect": "<effect>"
}
}
}
}
Métadonnées
Les trois premiers composants sont des métadonnées de stratégie. Ces composants sont faciles à définir puisque
nous connaissons l’objectif de la règle. Le mode concerne essentiellement les étiquettes et l’emplacement de la
ressource. Comme nous n’avons pas besoin de limiter l’évaluation aux ressources qui prennent en charge les
étiquettes, nous utilisons la valeur Tout pour le mode.
"displayName": "Deny storage accounts not using only HTTPS",

"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on
StorageAccounts.",
"mode": "all",
Paramètres
Nous n’avons pas utilisé de paramètre pour changer l’évaluation, mais nous devons utiliser un paramètre afin de
nous autoriser à changer l’effet pour la résolution des problèmes. Nous définissons un paramètre effectType et le
limitons à Refuser et Désactivé uniquement. Ces deux options correspondent à nos exigences métier. Le bloc de
paramètres terminé ressemble à cet exemple :
"parameters": {
"effectType": {
"type": "string",
"defaultValue": "Deny",
"allowedValues": [
"Deny",
"Disabled"
],
"metadata": {
"displayName": "Effect",
"description": "Enable or disable the execution of the policy"
}
}
},
Règle de stratégie
La dernière étape de création de notre définition de stratégie personnalisée est la composition de la règle de
stratégie. Nous avons identifié deux instructions à tester :
Le type du compte de stockage est Microsoft.Storage/storageAccounts
La propriété supportsHttpsTrafficOnly du compte de stockage n’a pas la valeur true
Comme ces instructions doivent avoir la valeur true, nous utilisons l’opérateur logique allOf. Nous passons le
paramètre effectType à l’effet au lieu de faire une déclaration statique. Notre règle terminée ressemble à cet
exemple :
"if": {
"allOf": [
{
"field": "type",
},
{
"field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
"notEquals": "true"
}
]
},
"then": {
"effect": "[parameters('effectType')]"
}
Définition terminée
Voici notre définition terminée avec les trois parties de la stratégie définies :
{
"properties": {
"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly
property on StorageAccounts.",
"mode": "all",
"parameters": {
"effectType": {
"type": "string",
"defaultValue": "Deny",
"allowedValues": [
"Deny",
"Disabled"
],
"metadata": {
"displayName": "Effect",
"description": "Enable or disable the execution of the policy"
}
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
},
{
"field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
"notEquals": "true"
}
]
},
"then": {
}
}
}
}
La définition terminée peut être utilisée pour créer une stratégie. Le portail et chaque SDK (Azure CLI, Azure
PowerShell et API REST) acceptent la définition de différentes façons, vous devez donc passer en revue les
commandes de chacun d’eux pour vérifier comment les utiliser. Attribuez-la ensuite, à l’aide de l’effet paramétré, aux
ressources appropriées pour gérer la sécurité de vos comptes de stockage.

affectations ou définitions créées ci-dessus :
Révision
Dans ce didacticiel, vous avez effectué avec succès les tâches suivantes :
Associer chaque exigence à une propriété de ressource Azure
Associer la propriété à un alias
Composer la définition de stratégie
Étapes suivantes
Ensuite, utilisez votre définition de stratégie personnalisée pour créer et attribuer une stratégie :
Créer et attribuer une définition de stratégie
Les balises représentent un aspect essentiel de l’organisation des ressources Azure dans une taxonomie. Dès lors
que les meilleures pratiques de gestion des balises sont suivies, les balises peuvent servir de base à l’application
des stratégies d’entreprise avec Azure Policy ou au suivi des coûts avec Cost Management. Quels que soient
l’usage et la finalité des balises utilisées, il est important de pouvoir en ajouter, en modifier et en supprimer
rapidement sur des ressources Azure.
L’effet modify d’Azure Policy est conçu pour faciliter la gouvernance des balises à toutes les phases de
gouvernance des ressources. modify est utile dans les cas suivants :
Vous ne connaissez pas encore le cloud et n’avez pas de gouvernance des balises.
Vous possédez déjà des milliers de ressources sans gouvernance des balises.
Vous disposez déjà d’une taxonomie que vous devez modifier.
Dans ce didacticiel, vous allez apprendre à effectuer les tâches suivantes :
Associer chaque spécification à une définition de stratégie
Regrouper les stratégies de balises dans une initiative

Pour suivre ce tutoriel, vous devez disposer d’un abonnement Azure. Si vous n’en avez pas, créez un compte gratuit
avant de commencer.
Identifier les exigences

Comme pour toute bonne implémentation des contrôles de gouvernance, les exigences doivent venir des besoins
professionnels et être bien comprises avant la création de contrôles techniques. Dans le scénario de ce tutoriel, nos
exigences métier seront les suivantes :
Deux balises obligatoires sur toutes les ressources : CostCenter et Env
CostCenter doit apparaître sur tous les conteneurs et toutes les ressources individuelles
Les ressources héritent du conteneur dans lequel elles se trouvent, mais peuvent être remplacées
individuellement
Env doit apparaître sur tous les conteneurs et toutes les ressources individuelles
Les ressources déterminent l’environnement par le schéma de nommage du conteneur et ne peuvent pas
être remplacées
Toutes les ressources d’un conteneur font partie du même environnement
Configurer la balise CostCenter

Dans un environnement Azure géré par Azure Policy en particulier, les spécifications de balise CostCenter exigent
les mesures suivantes :
Refuser les groupes de ressources qui ne contiennent pas la balise CostCenter
Modifier les ressources qui ne contiennent pas la balise CostCenter en l’ajoutant à partir du groupe de
ressources parent
Refuser les groupes de ressources qui ne contiennent pas la balise CostCenter
Dans la mesure où la balise CostCenter d’un groupe de ressources ne peut pas être déterminée par le nom du
groupe, elle doit être définie dans la demande de création du groupe de ressources. La règle de stratégie suivante,
qui utilise l’effet deny, empêche la création et la mise à jour des groupes de ressources qui ne contiennent pas la
balise CostCenter :
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"field": "tags['CostCenter']",
"exists": false
}
]
},
"then": {
"effect": "deny"
}
NOTE
Comme cette règle de stratégie cible un groupe de ressources, le mode de définition de la stratégie doit être « Tous » au lieu
de « Indexé ».
Modifier les ressources qui ne contiennent pas la balise CostCenter pour qu’elles en héritent
Le deuxième critère de CostCenter est que toutes les ressources qui ne contiennent pas la balise l’héritent du
groupe de ressources parent. Si la balise est déjà définie sur la ressource, elle doit être laissée seule, même si elle
est différente du groupe de ressources parent. La règle de stratégie suivante utilise l’effet modify :
"policyRule": {
"if": {
"exists": "false"
},
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"operations": [{
"operation": "add",
"value": "[resourcegroup().tags['CostCenter']]"
}]
}
}
}
Cette règle de stratégie utilise l’opération add au lieu de addOrReplace, car il ne faut pas modifier la valeur de la
balise si elle est présente lors de la correction des ressources existantes. Elle se sert également de la fonction de
modèle [resourcegroup()] pour récupérer la valeur de la balise du groupe de ressources parent.
NOTE
Comme cette règle de stratégie cible des ressources qui acceptent les balises, le mode de définition de la stratégie doit être «
Indexé ». Cette configuration garantit également que la stratégie ignore les groupes de ressources.
Configurer la balise Env

Dans un environnement Azure géré par Azure Policy en particulier, les spécifications de balise Env exigent les
mesures suivantes :
Modifier la balise Env sur le groupe de ressources en fonction du schéma de nommage du groupe de
ressources
Modifier la balise Env de toutes les ressources du groupe de ressources pour qu’elle soit identique à celle du
groupe de ressources parent
Modifier la balise Env des groupes de ressources en fonction du nom
Une stratégie modify est nécessaire pour chacun des environnements de l’environnement Azure. Elle se présentera
pour chacun comme cette définition de stratégie :
"policyRule": {
"if": {
"allOf": [{
"field": "type",
},
{
"field": "name",
"like": "prd-*"
}
]
},
"then": {
"effect": "modify",
"details": {
],
"operations": [{
"operation": "addOrReplace",
"field": "tags['Env']",
"value": "Production"
}]
}
}
}
NOTE
Comme cette règle de stratégie cible un groupe de ressources, le mode de définition de la stratégie doit être « Tous » au lieu
de « Indexé ».
Cette stratégie correspond uniquement aux groupes de ressources dont l’exemple de schéma de nommage utilisé
pour les ressources de production est prd- . Il est possible de créer des modèles de nommage plus complexes en
ajoutant plusieurs conditions de correspondance au lieu de l’unique condition like de cet exemple.
Modifier les ressources pour qu’elles héritent de la balise Env
L’exigence métier impose que toutes les ressources contiennent la balise Env de leur groupe de ressources parent.
Comme cette balise ne peut pas être remplacée, nous allons utiliser l’opération addOrReplace avec l’effet modify.
L’exemple de stratégie modify se présente comme la règle suivante :
"policyRule": {
"if": {
"anyOf": [{
"notEquals": "[resourcegroup().tags['Env']]"
},
{
"exists": false
}
]
},
"then": {
"effect": "modify",
"details": {
],
"operations": [{
"value": "[resourcegroup().tags['Env']]"
}]
}
}
}
NOTE
Comme cette règle de stratégie cible des ressources qui acceptent les balises, le mode de définition de la stratégie doit être «
Indexé ». Cette configuration garantit également que la stratégie ignore les groupes de ressources.
Cette règle de stratégie recherche les ressources qui n’ont pas la valeur de leur groupe de ressources parent pour la
balise Env ou qui ne contiennent pas la balise Env. La balise Env des ressources correspondantes est définie sur la
valeur du groupe de ressources parent, même si elle existait déjà sur la ressource avec une valeur différente.
Assigner l’initiative et corriger les ressources

Une fois les stratégies de balises ci-dessus créées, groupez-les en une initiative unique de gouvernance des balises
et attribuez-les à un groupe d’administration ou à un abonnement. L’initiative et les stratégies incluses évalueront
la conformité des ressources existantes et des demandes de modification des nouvelles ressources et des
ressources mises à jour qui correspondent à la propriété if de la règle de stratégie. Toutefois, la stratégie ne met
pas automatiquement à jour les ressources non conformes existantes en intégrant les modifications de balise
définies.
Comme les stratégies deployIfNotExists, la stratégie modify utilise des tâches de correction pour modifier les
ressources non conformes existantes. Suivez les instructions indiquées dans Guide pratique pour corriger les
ressources pour identifier vos ressources modify non conformes et corriger les balises en fonction de la taxonomie
définie.

affectations ou définitions créées ci-dessus :
Révision
Dans ce tutoriel, vous avez découvert les tâches suivantes :
Faire correspondre chaque spécification à une définition de stratégie
Regrouper les stratégies de balises dans une initiative
Étapes suivantes
Pour plus d’informations sur les structures des définitions de stratégie, consultez cet article :
Cette page est un index de définitions de stratégie intégrées et de modèles d’utilisation de langage Azure
Policy.
Éléments intégrés
Stratégies
Initiatives
Modèles
Voici quelques exemples de modèles différents utilisant le langage et les opérateurs dans Azure Policy :
Fields
Paramètres
Détails des effets
Opérateur value
Opérateur count
Regroupement de définitions de stratégie dans une initiative
Déploiement de ressources avec deployIfNotExists
Étapes suivantes
Consultez les définitions intégrées dans le dépôt Azure Policy de GitHub.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Définitions de stratégie Azure Policy intégrées
Cette page est un index de définitions de stratégie intégrées Azure Policy.

Le nom de chaque définition intégrée est un lien vers la définition de stratégie dans le portail Azure. Utilisez le lien
de la colonne Source pour voir la source dans le dépôt GitHub Azure Policy. Les définitions intégrées sont
regroupées par la propriété category dans metadata. Pour accéder à une catégorie spécifique, utilisez le menu
sur le côté droit de la page. Autrement, utilisez Ctrl-F pour utiliser la fonctionnalité de recherche de votre
navigateur.
Configuration d’application
NOM DESCRIPTION EFFET(S) VERSION GITHUB
App Configuration Cette stratégie audite Audit, Désactivé 1.0.0 Lien

doit utiliser une clé toutes les instances
gérée par le client App Configuration qui
n’utilisent pas de clé
gérée par le client.
App Configuration Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

doit utiliser une toutes les instances Désactivé
liaison privée App Configuration qui
n’utilisent pas de
liaison privée.
Plateforme d’application
Auditer les instances Dans Azure Spring Audit, Désactivé 1.0.0-preview Lien
Azure Spring Cloud Cloud, les outils de
où le suivi distribué suivi distribué
n’est pas activé permettent de
déboguer et de
superviser les
interconnexions
complexes entre les
microservices dans
une application. Ces
outils doivent être
activés et dans un
état d’intégrité
normal.
App Service
L’application API doit L'utilisation de HTTPS Audit, Désactivé 1.0.0 Lien

uniquement être garantit
accessible via HTTPS l'authentification du
serveur/service, et
protège les données
en transit contre les
attaques par écoute
clandestine de la
couche réseau.
L’authentification doit L’authentification AuditIfNotExists, 1.0.0 Lien

être activée sur votre Azure App Service est Désactivé
application API une fonctionnalité qui
peut empêcher les
requêtes HTTP
anonymes d’accéder à
l’application API ou
authentifier celles
ayant des jetons
avant qu’elles
n’accèdent à
l’application API.

application de une fonctionnalité qui
fonction peut empêcher les
requêtes HTTP
l’application de
fonction ou
authentifier celles
ayant des jetons
avant qu’elles
n’accèdent à
l’application de
fonction.

application web une fonctionnalité qui
peut empêcher les
requêtes HTTP
l’application web ou
authentifier celles
ayant des jetons
avant qu’elles
n’accèdent à
l’application web.
CORS ne doit pas Le partage des AuditIfNotExists, 1.0.0 Lien

autoriser toutes les ressources cross- Désactivé
ressources à accéder à origin (CORS) ne doit
votre application API pas autoriser tous les
domaines à accéder à
votre application API.
Autorisez uniquement
les domaines requis à
interagir avec votre
application API.
CORS ne doit pas Le mécanisme CORS AuditIfNotExists, 1.0.0 Lien

autoriser toutes les (Cross-Origin Désactivé
ressources à accéder à Resource Sharing) ne
votre application de devrait pas autoriser
fonction tous les domaines à
accéder à votre
application de
fonction. Autorisez
uniquement les
domaines nécessaires
à interagir avec votre
application de
fonction.
CORS ne doit pas Le mécanisme CORS AuditIfNotExists, 1.0.0 Lien

autoriser toutes les (Cross-Origin Désactivé
ressources à accéder à Resource Sharing) ne
vos applications web devrait pas autoriser
tous les domaines à
accéder à votre
application web.
Autorisez uniquement
les domaines requis à
interagir avec votre
application web.
Les journaux de Auditer l’activation AuditIfNotExists, 1.0.0 Lien

diagnostic d’App des journaux de Désactivé
Services doivent être diagnostic dans
activés l’application. Permet
de recréer les pistes
d’activité à des fins
d’investigation en cas
d’incident de sécurité
ou de compromission
du réseau.
Vérifier que Les certificats clients Audit, Désactivé 1.0.0 Lien

« Certificats clients permettent à
(certificats clients l’application de
entrants) » est activé demander un
pour l’application API certificat pour les
demandes entrantes.
Seuls les clients
disposant d’un
certificat valide
peuvent accéder à
l’application.

pour l’application de certificat pour les
fonction demandes entrantes.
Seuls les clients
disposant d’un
certificat valide
peuvent accéder à
l’application.
Vérifier que la version Régulièrement, de AuditIfNotExists, 1.0.0 Lien

du .NET Framework nouvelles versions Désactivé
est la plus récente, si sont publiées pour le
elle est utilisée dans le logiciel .NET
cadre de l’application Framework, soit en
d’API raison de failles de
sécurité, soit pour
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
d’utiliser la version la
plus récente du .NET
Framework pour les
applications web, afin
de tirer parti des
correctifs de sécurité
(le cas échéant), et/ou
des nouvelles
fonctionnalités.

de fonction raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
Framework pour les
de tirer parti des
des nouvelles
fonctionnalités.

web raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
Framework pour les
de tirer parti des
des nouvelles
fonctionnalités.

de HTTP est la plus nouvelles versions Désactivé
récente, si elle est sont publiées pour
utilisée pour exécuter HTTP, soit en raison
l’application API de failles de sécurité,
soit pour inclure des
fonctionnalités
supplémentaires.
L’utilisation de la
version de HTTP la
plus récente est
recommandée pour
les applications web
afin de tirer parti des
correctifs de sécurité,
le cas échéant, et/ou
des nouvelles
fonctionnalités.

de HTTP est la plus nouvelles versions Désactivé
utilisée pour exécuter HTTP, soit en raison
l’application de de failles de sécurité,
fonction soit pour inclure des
fonctionnalités
supplémentaires.
version de HTTP la
plus récente est
recommandée pour
les applications web
afin de tirer parti des
des nouvelles
fonctionnalités.
Vérifier que la version Les identités du AuditIfNotExists, 1.0.0 Lien

de HTTP est la plus service géré dans App Désactivé
récente, si elle est Service sécurisent
utilisée pour exécuter votre application en
l’application web éliminant les secrets
de cette dernière,
comme les
informations
d’identification dans
les chaînes de
connexion. Lors de
l’inscription auprès
d’Azure Active
Directory dans App
Service, l’application
se connecte à d’autres
services Azure en
toute sécurité sans
avoir besoin de nom
d’utilisateur ni de mot
de passe.

de Java est la plus nouvelles versions Désactivé
utilisée dans le cadre Java, soit en raison de
de l’application API failles de sécurité, soit
pour inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de
Python pour les
applications API afin
de tirer parti des
des nouvelles
fonctionnalités.

récente, si elle est sont publiées pour le
utilisée dans le cadre logiciel Java, soit en
de l’application de raison de failles de
fonction sécurité, soit pour
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de Java
pour les applications
de fonction afin de
tirer parti des
des nouvelles
fonctionnalités.

utilisée dans le cadre logiciel Java, soit en
de l’application web raison de failles de
inclure des
fonctionnalités
supplémentaires.
version la plus récente
de Java pour les
applications web est
recommandée pour
tirer parti des
des nouvelles
fonctionnalités.

de PHP est la plus nouvelles versions Désactivé
utilisée dans le cadre logiciel PHP, soit en
de l’application API raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de PHP
API afin de tirer parti
des correctifs de
sécurité, le cas
échéant, et/ou des
nouvelles
fonctionnalités.

de l’application de raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
de fonction afin de
tirer parti des
des nouvelles
fonctionnalités.

de l’application web raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
web afin de tirer parti
des correctifs de
sécurité, le cas
nouvelles
fonctionnalités.

de Python est la plus nouvelles versions Désactivé
utilisée dans le cadre logiciel Python, soit
de l’application API en raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de
Python pour les
applications API afin
de tirer parti des
des nouvelles
fonctionnalités.

de l’application de en raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de
Python pour les
applications de
fonction afin de tirer
parti des correctifs de
sécurité, le cas
nouvelles
fonctionnalités.

de l’application web en raison de failles de
inclure des
fonctionnalités
supplémentaires.
Nous vous
recommandons
plus récente de
Python pour les
applications web afin
de tirer parti des
des nouvelles
fonctionnalités.
Vérifier que Les identités du AuditIfNotExists, 1.0.0 Lien

l’inscription auprès service géré dans App Désactivé
d’Azure Active Service sécurisent
Directory est activée votre application en
sur l’application API éliminant les secrets
de cette dernière,
comme les
informations
les chaînes de
connexion. Lors de
d’Azure Active
Directory dans App
services Azure en
avoir besoin de nom
de passe.

sur l’application de éliminant les secrets
fonction de cette dernière,
comme les
informations
les chaînes de
connexion. Lors de
d’Azure Active
Directory dans App
services Azure en
avoir besoin de nom
de passe.

sur l’application web éliminant les secrets
de cette dernière,
comme les
informations
les chaînes de
connexion. Lors de
d’Azure Active
Directory dans App
services Azure en
avoir besoin de nom
de passe.

pour l’application web certificat pour les
demandes entrantes.
Seuls les clients
disposant d’un
certificat valide
peuvent accéder à
l’application.
FTPS uniquement doit Activer la mise en AuditIfNotExists, 1.0.0 Lien

être exigé dans votre œuvre de FTPS pour Désactivé
application API renforcer la sécurité
FTPS uniquement doit Activer la mise en AuditIfNotExists, 1.0.0 Lien

être exigé dans votre œuvre de FTPS pour Désactivé
application de renforcer la sécurité
fonction
FTPS doit être exigé Activer la mise en AuditIfNotExists, 1.0.0 Lien

dans votre application œuvre de FTPS pour Désactivé
web renforcer la sécurité
Function App ne doit L'utilisation de HTTPS Audit, Désactivé 1.0.0 Lien

pas être accessible via garantit
HTTPS l'authentification du
serveur/service, et
clandestine de la
couche réseau.
La dernière version de Mise à niveau vers la AuditIfNotExists, 1.0.0 Lien

TLS doit être utilisée version la plus récente Désactivé
dans votre application de TLS
API

de fonction

web
Une identité managée Utiliser une identité AuditIfNotExists, 1.0.0 Lien

doit être utilisée dans managée pour Désactivé
votre application API renforcer la sécurité
de l’authentification

votre application de renforcer la sécurité
fonction de l’authentification

votre application web renforcer la sécurité
de l’authentification
Le débogage à Le débogage à AuditIfNotExists, 1.0.0 Lien

distance doit être distance nécessite que Désactivé
désactivé pour les des ports d’entrée
applications API soient ouverts sur les
applications d’API. Le
débogage à distance
doit être désactivé.
Le débogage à Le débogage distant AuditIfNotExists, 1.0.0 Lien

distance doit être nécessite que des Désactivé
désactivé pour les ports d’entrée soient
applications de ouverts sur les
fonction applications de
fonction. Le débogage
à distance doit être
désactivé.
Le débogage à Le débogage à AuditIfNotExists, 1.0.0 Lien

distance doit être distance exige que Désactivé
désactivé pour les des ports d’entrée
applications web soient ouverts sur
une application web.
Le débogage à
distance doit être
désactivé.
L’application web ne L'utilisation de HTTPS Audit, Désactivé 1.0.0 Lien

doit pas être garantit
accessible via HTTPS l'authentification du
serveur/service, et
clandestine de la
couche réseau.
Automatisation
Les variables de Il est important Audit, Désactivé 1.0.0 Lien

compte Automation d’activer le
doivent être chiffrées chiffrement des
ressources variables
du compte
Automation lors du
stockage de données
sensibles
Batch

diagnostic dans les des journaux de Désactivé
comptes Batch diagnostic Permet de
doivent être activés recréer les pistes
d’activité à utiliser à
des fins
ou de compromission
du réseau.
Des règles d’alerte de Auditez la AuditIfNotExists, 1.0.0 Lien

métrique doivent être configuration des Désactivé
configurées sur les règles d’alerte de
comptes Batch métrique sur le
compte Batch pour
activer la métrique
requise.
Cache
Seules les connexions Auditer l'activation Audit, Refuser, 1.0.0 Lien

sécurisées à votre des connexions via Désactivé
cache Redis doivent SSL uniquement à
être activées votre cache Redis.
L'utilisation de
connexions sécurisées
garantit
l'authentification
entre le serveur et le
service et protège les
données en transit
contre les attaques de
la couche réseau
(attaque de
l'intercepteur ou
« man-in-the-
middle », écoute
clandestine,
détournement de
session).
Calcul
Références SKU de Cette stratégie vous Deny 1.0.0 Lien

machine virtuelle permet de spécifier un
autorisées ensemble de
références de machine
virtuelle que votre
organisation peut
déployer.
Auditer des machines Auditez les machines auditIfNotExists 1.0.0 Lien

virtuelles pour virtuelles configurées
lesquelles la reprise sans reprise d’activité.
d’activité après Pour en savoir plus
sinistre n’est pas sur la reprise
configurée d’activité, consultez
https://aka.ms/asr-
doc.
Faire l’audit des Cette stratégie fait audit 1.0.0 Lien

machines virtuelles l’audit des machines
n’utilisant aucun virtuelles n’utilisant
disque managé pas de disque
managé
Déployer l’extension Cette stratégie deployIfNotExists 1.0.0 Lien

Microsoft déploie une extension
IaaSAntimalware par Microsoft
défaut pour Windows IaaSAntimalware avec
Server une configuration par
défaut quand une
machine virtuelle n’est
pas configurée avec
l’extension de logiciel
anti-programme
malveillant.
Les journaux de Il est recommandé AuditIfNotExists, 1.0.0 Lien

diagnostic dans les d’activer les journaux Désactivé
groupes de machines d’activité pour
virtuelles identiques permettre le traçage
doivent être activés de l’activité lors des
enquêtes requises en
cas d’incident ou de
compromission.
Microsoft Cette stratégie AuditIfNotExists, 1.0.0 Lien

Antimalware pour permet d’effectuer un Désactivé
Azure doit être audit de toutes les
configuré pour mettre machines virtuelles
à jour Windows non
automatiquement les configurées avec la
signatures de mise à jour
protection automatique des
signatures de
protection de
Microsoft
Antimalware.
L’extension Microsoft Cette stratégie AuditIfNotExists, 1.0.0 Lien

IaaSAntimalware doit permet d’auditer Désactivé
être déployée sur des toute machine
serveurs Windows virtuelle Windows
Server sans extension
Microsoft
IaaSAntimalware
déployée.
Seules les extensions Cette stratégie régit Audit, Refuser, 1.0.0 Lien
de machine virtuelle les extensions de Désactivé
approuvées doivent machine virtuelle qui
être installées ne sont pas
approuvées.
Exiger la mise à jour Cette stratégie deny 1.0.0 Lien

corrective applique l’activation
automatique de de la mise à jour
l’image du système corrective
d’exploitation sur les automatique des
groupes de machines images de système
virtuelles identiques d’exploitation sur les
groupes de machines
virtuelles identiques
afin d’assurer la
sécurité des machines
virtuelles par
l’application sécurisée
mensuelle des
derniers correctifs de
sécurité.
Les disques non Cette stratégie Audit, Désactivé 1.0.0 Lien

attachés doivent être permet d’auditer tous
chiffrés les disques non
attachés sans
chiffrement activé.
Les machines Utilisez le nouvel Audit, Refuser, 1.0.0 Lien

virtuelles doivent être Azure Resource Désactivé
migrées vers de Manager pour
nouvelles ressources renforcer la sécurité
Azure Resource de vos machines
Manager virtuelles : contrôle
d’accès en fonction du
rôle (RBAC) renforcé,
audit amélioré,
déploiement et
gouvernance basés
sur Azure Resource
Manager, accès aux
identités managées,
accès au coffre de clés
pour les secrets,
authentification basée
sur Azure AD, et prise
en charge des
étiquettes et des
groupes de
ressources pour
faciliter la gestion de
la sécurité.
Container Registry
Les registres de Auditez les registres Audit, Désactivé 1.0.0-preview Lien

conteneurs doivent de conteneurs pour
être chiffrés avec une lesquels le chiffrement
clé gérée par le client n’est pas activé avec
(CMK) des clés gérées par le
client (CMK). Pour
plus d’informations
sur le chiffrement
CMK, consultez :
https://aka.ms/acr/C
MK.
Les registres de Auditez les registres Audit, Désactivé 1.0.0-preview Lien

conteneurs ne de conteneurs qui
doivent pas autoriser n’ont pas de règles
l’accès réseau non réseau (IP ou réseau
restreint virtuel) configurées et
autorisent tous l’accès
réseau par défaut. Les
registres de
conteneurs avec au
moins une règle
IP/pare-feu ou un
réseau virtuel
configuré sont
considérés comme
conformes. Pour plus
d’informations sur les
règles de réseau
Container Registry,
accédez au site
suivant :
https://aka.ms/acr/vn
et.
Cosmos DB
Déployer Advanced Cette stratégie active DeployIfNotExists, 1.0.0 Lien

Threat Protection Advanced Threat Désactivé
pour les comptes Protection sur les
Cosmos DB comptes Cosmos DB.
Fournisseur personnalisé
Déployer des Déploie une ressource deployIfNotExists 1.0.0 Lien

associations pour un d’association qui
fournisseur associe les types de
personnalisé ressources
sélectionnés au
fournisseur
personnalisé spécifié.
Ce déploiement de
stratégie ne prend
pas en charge les
types de ressources
imbriqués.
Data Lake

diagnostic dans Azure des journaux de Désactivé
Data Lake Store diagnostic. Permet de
des fins
ou de compromission
du réseau.

diagnostic dans Data des journaux de Désactivé
Lake Analytics doivent diagnostic. Permet de
être activés recréer les pistes
des fins
ou de compromission
du réseau.
Exiger un chiffrement Cette stratégie deny 1.0.0 Lien

sur les comptes Data garantit que le
Lake Store chiffrement est activé
sur tous les comptes
Data Lake Store
Event Hub
Toutes les règles Les clients Event Hub Audit, Refuser, 1.0.1 Lien
d’autorisation, sauf ne doivent pas utiliser Désactivé
RootManageSharedAc une stratégie d'accès
cessKey, doivent être au niveau de l'espace
supprimées de de noms qui donne
l’espace de noms accès à l'ensemble des
Event Hub files d'attente et
rubriques d'un espace
de noms. Pour
respecter le modèle
de sécurité basé sur le
privilège minimum,
vous devez créer des
stratégies d’accès au
niveau de l’entité pour
les files d’attente et
les rubriques afin de
limiter l’accès à l’entité
spécifique
Les règles Auditer l’existence de AuditIfNotExists, 1.0.0 Lien

d’autorisation sur règles d’autorisation Désactivé
l’instance Event Hub sur les entités Event
doivent être définies Hub pour accorder un
accès à privilèges
minimum

diagnostic dans Event des journaux de Désactivé
Hub doivent être diagnostic. Permet de
activés recréer les pistes
des fins
ou de compromission
du réseau.
Général
Emplacements Cette stratégie vous deny 1.0.0 Lien

autorisés permet de restreindre
les emplacements que
votre organisation
peut spécifier lors du
déploiement de
ressources. Utilisez-la
pour appliquer vos
exigences de
conformité
géographique. Exclut
les groupes de
ressources,
Microsoft.azureactive
directory/b2cdirectori
es et les ressources
qui utilisent la région
« globale ».
Emplacements Cette stratégie vous deny 1.0.0 Lien

autorisés pour les permet de restreindre
groupes de les emplacements où
ressources votre organisation
peut créer des
groupes de
ressources. Utilisez-la
pour appliquer vos
exigences de
conformité
géographique.
Types de ressources Cette stratégie vous deny 1.0.0 Lien

autorisés permet de spécifier les
types de ressources
que votre
organisation peut
déployer. Seuls les
types de ressources
prenant en charge
« tags » et
« location » sont
affectés par cette
stratégie. Pour
restreindre toutes les
ressources, dupliquez
cette stratégie et
affectez à « mode » la
valeur « All ».
Vérifier que Vérifie que audit 1.0.0 Lien

l’emplacement de la l’emplacement de la
ressource correspond ressource correspond
à l’emplacement du à l’emplacement de
groupe de ressources son groupe de
ressources
Auditer l’utilisation de Auditer des rôles Audit, Désactivé 1.0.0 Lien

règles personnalisées intégrés tels que
RBAC « Propriétaire,
contributeur, lecteur »
au lieu des rôles RBAC
personnalisés, qui
sont susceptibles
d’engendrer des
erreurs. L’utilisation
de rôles personnalisés
est traitée comme
une exception et
nécessite un contrôle
rigoureux et la
modélisation des
menaces
Les rôles de Cette stratégie Audit, Désactivé 1.0.0 Lien

propriétaire garantit qu’il n’existe
d’abonnement aucun rôle de
personnalisé ne propriétaire
doivent pas exister d’abonnement
personnalisé.
Types de ressources Cette stratégie vous Deny 1.0.0 Lien

non autorisés permet de spécifier les
types de ressources
que votre
organisation ne peut
pas déployer.
Guest Configuration
Configurer le fuseau Cette stratégie crée deployIfNotExists 1.0.0-preview Lien

horaire sur les une attribution Guest
machines Windows. Configuration pour
définir le fuseau
horaire spécifié sur
des machines
virtuelles Windows.
Prérequis de Cette stratégie crée deployIfNotExists 1.1.0-preview Lien

déploiement pour une attribution Guest
auditer les machines Configuration pour
virtuelles Linux qui auditer les machines
autorisent les virtuelles Linux qui
connexions à distance autorisent les
à partir des comptes connexions à distance
sans mot de passe à partir de comptes
sans mot de passe.
Elle crée aussi une
identité managée
affectée par le
système et déploie
l’extension de
machine virtuelle
pour Guest
Configuration. Cette
stratégie doit
uniquement être
utilisée avec sa
stratégie d’audit
correspondante dans
une initiative. Pour
sur les stratégies
Guest Configuration,
visitez
https://aka.ms/gcpol

l’audit des machines Configuration pour
n’ont pas les virtuelles Linux qui
autorisations de n’ont pas les
fichier passwd définies autorisations de
sur 0644 fichier passwd définies
sur 0644. Elle crée
aussi une identité
managée affectée par
le système et déploie
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez
Prérequis de Cette stratégie crée deployIfNotExists 1.1.0 Lien

n’ont pas les virtuelles Linux qui
applications spécifiées n’ont pas les
installées applications spécifiées
installées. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

ont des comptes sans virtuelles Linux qui
mot de passe ont des comptes sans
mot de passe. Elle
crée aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

ont les applications virtuelles Linux qui
spécifiées installées ont les applications
spécifiées installées.
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

virtuelles Windows auditer les machines
Server sur lesquelles virtuelles Windows
la console série Server sur lesquelles
Windows n’est pas la console série
activée Windows n’est pas
activée. Elle crée aussi
une identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

l’audit des Configuration pour
configurations de auditer les machines
machines virtuelles virtuelles Windows
Windows dans avec des paramètres
« Modèles non conformes dans
d’administration - la catégorie de
Panneau de stratégie de groupe :
configuration » « Modèles
d’administration -
Panneau de
configuration ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

MSS (hérité) » stratégie de groupe :
« Modèles
MSS (hérité) ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

Réseau » stratégie de groupe :
« Modèles
Réseau ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

Système » stratégie de groupe :
« Modèles
Système ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Options de sécurité non conformes dans
- Comptes » la catégorie de
stratégie de groupe :
« Options de sécurité
- Comptes ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Audit » la catégorie de
- Audit ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Appareils » la catégorie de
- Appareils ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Connexion la catégorie de
interactive » stratégie de groupe :
- Connexion
interactive ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Client réseau la catégorie de
Microsoft » stratégie de groupe :
- Client réseau
Microsoft ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Serveur réseau la catégorie de
Microsoft » stratégie de groupe :
- Serveur réseau
Microsoft ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Accès réseau » la catégorie de
- Accès réseau ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Sécurité réseau » la catégorie de
- Sécurité réseau ».
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Console de la catégorie de
récupération » stratégie de groupe :
- Console de
récupération ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Arrêt » la catégorie de
- Arrêt ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Objets système » la catégorie de
- Objets système ».
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Paramètres la catégorie de
système » stratégie de groupe :
- Paramètres
système ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

- Contrôle de compte la catégorie de
utilisateur » stratégie de groupe :
- Contrôle de compte
utilisateur ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Paramètres de non conformes dans
sécurité - Stratégies la catégorie de
de compte » stratégie de groupe :
« Paramètres de
sécurité - Stratégies
de compte ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Stratégies d’audit non conformes dans
système - Connexion la catégorie de
au compte » stratégie de groupe :
« Stratégies d’audit
système - Connexion
au compte ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Gestion des la catégorie de
comptes » stratégie de groupe :
système - Gestion des
comptes ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Suivi la catégorie de
détaillé » stratégie de groupe :
système - Suivi
détaillé ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Connexion- la catégorie de
Déconnexion » stratégie de groupe :
système - Connexion-
Déconnexion ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Accès la catégorie de
objet » stratégie de groupe :
système - Accès
objet ». Elle crée aussi
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - la catégorie de
Modification de la stratégie de groupe :
stratégie » « Stratégies d’audit
système -
Modification de la
stratégie ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Utilisation la catégorie de
privilégiée » stratégie de groupe :
système - Utilisation
privilégiée ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

système - Système » la catégorie de
système - Système ».
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Attribution de droits non conformes dans
utilisateur » la catégorie de
« Attribution de droits
utilisateur ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Composants non conformes dans
Windows » la catégorie de
« Composants
Windows ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

« Propriétés du pare- non conformes dans
feu Windows » la catégorie de
« Propriétés du pare-
feu Windows ». Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

dans lesquelles le virtuelles Windows
groupe dans lesquelles le
Administrateurs groupe
contient un membre Administrateurs
spécifié contient un membre
spécifié. Elle crée aussi
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

Administrateurs ne groupe
contient pas tous les Administrateurs ne
membres spécifiés contient pas tous les
membres spécifiés.
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

Administrateurs ne groupe
contient pas Administrateurs ne
seulement les contient pas
membres spécifiés seulement les
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

sur lesquelles la virtuelles Windows
configuration DSC sur lesquelles la
n’est pas conforme configuration DSC
(Desired State
Configuration) n’est
pas conforme. Cette
stratégie s’applique
uniquement aux
machines dotées de
WMF 4 et versions
ultérieures. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

sur lesquelles l’agent virtuelles Windows
Log Analytics n’est sur lesquelles l’agent
pas connecté comme Log Analytics n’est
prévu pas connecté aux
espaces de travail
spécifiés. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

sur lesquelles l’état de virtuelles Windows
connexion de l’hôte sur lesquelles l’état de
distant ne correspond connexion de l’hôte
pas à celui spécifié distant ne correspond
pas à celui spécifié.
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

sur lesquelles les virtuelles Windows
services spécifiés ne sur lesquelles les
sont pas installés ni services spécifiés ne
« En cours sont pas installés ni
d’exécution » « En cours
d’exécution ». Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

sur lesquelles virtuelles Windows
Windows Defender sur lesquelles
Exploit Guard n’est Windows Defender
pas activé Exploit Guard n’est
pas activé. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui autorisent la virtuelles Windows
réutilisation des qui autorisent la
24 mots de passe réutilisation des
précédents 24 mots de passe
précédents. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ne sont pas virtuelles Windows
jointes au domaine qui ne sont pas
spécifié jointes au domaine
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ne sont pas virtuelles Windows
définies sur le fuseau qui ne sont pas
horaire spécifié définies sur le fuseau
horaire spécifié. Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui contiennent des virtuelles Windows
certificats arrivant à qui contiennent des
expiration dans le certificats arrivant à
nombre de jours expiration dans le
spécifié nombre de jours
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ne contiennent virtuelles Windows
pas les certificats qui ne contiennent
spécifiés dans la pas les certificats
racine de confiance spécifiés dans le
magasin de certificats
des autorités de
certification racines de
confiance
(Cert:\LocalMachine\R
oot). Elle crée aussi
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui n’ont pas virtuelles Windows
l’antériorité maximale qui n’ont pas
du mot de passe l’antériorité maximale
définie sur 70 jours du mot de passe
définie sur 70 jours.
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

l’antériorité minimale qui n’ont pas
du mot de passe l’antériorité minimale
définie sur 1 jour du mot de passe
définie sur 1 jour. Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui n’ont pas le virtuelles Windows
paramètre de qui n’ont pas le
complexité de mot de paramètre de
passe activé complexité de mot de
passe activé. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui n’ont pas les virtuelles Windows
applications spécifiées qui n’ont pas les
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

déploiement pour une affectation Guest
qui n’ont pas la virtuelles Windows
stratégie d’exécution sur lesquelles
Windows PowerShell Windows PowerShell
spécifiée n’est pas configuré
pour utiliser la
stratégie d’exécution
PowerShell spécifiée.
identité managée
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui n’ont pas les virtuelles Windows
modules Windows qui n’ont pas les
PowerShell spécifiés modules Windows
installés PowerShell spécifiés
installés. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ne limitent pas la virtuelles Windows
longueur minimale du qui ne limitent pas la
mot de passe à longueur minimale du
14 caractères mot de passe à
14 caractères. Elle
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ne stockent pas virtuelles Windows
les mots de passe à qui ne stockent pas
l’aide du chiffrement les mots de passe à
réversible l’aide du chiffrement
réversible. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

redémarré depuis le qui n’ont pas
nombre de jours redémarré depuis le
spécifié nombre de jours
affectée par le
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

qui ont les virtuelles Windows
applications spécifiées qui ont les
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

avec un redémarrage virtuelles Windows
en attente avec un redémarrage
en attente. Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez

l’audit des serveurs Configuration pour
web Windows qui auditer les serveurs
n’utilisent pas de web Windows qui
protocole de n’utilisent pas de
communication protocole de
sécurisé communication
sécurisé (TLS 1.1 ou
TLS 1.2). Elle crée
aussi une identité
l’extension de
machine virtuelle
pour Guest
stratégie doit
uniquement être
utilisée avec sa
correspondante dans
sur les stratégies
visitez
Déployer les prérequis Cette stratégie crée deployIfNotExists 1.1.0 Lien

pour activer la une identité managée
stratégie de affectée par le
configuration d’invité système et déploie
sur les machines l’extension de
virtuelles Linux. machine virtuelle
pour Guest
Configuration sur les
machines virtuelles
Linux. Il s’agit d’un
prérequis pour la
stratégie de
configuration d’invité
et elle doit être
affectée à l’étendue
avant l’utilisation
d’une stratégie de
configuration d’invité.
Pour plus
stratégies Guest
Configuration, visitez
https://aka.ms/gcpol.
Déployer les prérequis Cette stratégie crée deployIfNotExists 1.0.0 Lien

pour activer la une identité managée
stratégie de affectée par le
configuration d’invité système et déploie
sur les machines l’extension de
virtuelles Windows. machine virtuelle
pour la configuration
d’invité sur les
machines virtuelles
Windows. Il s’agit d’un
prérequis pour la
stratégie de
configuration d’invité
et elle doit être
affectée à l’étendue
avant l’utilisation
d’une stratégie de
configuration d’invité.
Pour plus
stratégies Guest
https://aka.ms/gcpol.
Afficher les résultats Cette stratégie doit auditIfNotExists 1.1.0-preview Lien

d’audit des machines uniquement être
virtuelles Linux qui utilisée avec sa
autorisent les stratégie de
connexions à distance déploiement
à partir des comptes correspondante dans
sans mot de passe une initiative. Cette
définition permet à
Azure Policy de traiter
les résultats de l’audit
des machines
virtuelles Linux qui
autorisent les
connexions à distance
à partir des comptes
sans mot de passe.
Pour plus
stratégies Guest

n’ont pas les stratégie de
autorisations de déploiement
fichier passwd définies correspondante dans
sur 0644 une initiative. Cette
des machines
n’ont pas les
autorisations de
fichier passwd définies
sur 0644. Pour plus
stratégies Guest
Afficher les résultats Cette stratégie doit auditIfNotExists 1.1.0 Lien

de l’audit des uniquement être
machines virtuelles utilisée avec sa
Linux qui n’ont pas les stratégie de
applications spécifiées déploiement
installées correspondante dans
une initiative. Cette
des machines
n’ont pas les
applications spécifiées
installées. Pour plus
stratégies Guest

ont des comptes sans stratégie de
mot de passe déploiement
correspondante dans
des machines
ont des comptes sans
mot de passe. Pour
sur les stratégies
visitez

Linux qui ont les stratégie de
des machines
ont les applications
spécifiées installées.
Pour plus
stratégies Guest

Windows Server sur stratégie de
lesquelles la console déploiement
Windows Serial correspondante dans
Console n’est pas une initiative. Cette
activée définition permet à
des machines
virtuelles Windows
Server sur lesquelles
la console Windows
Serial Console n’est
pas activée. Pour plus
stratégies Guest

configurations de utilisée avec sa
machines virtuelles stratégie de
Windows dans déploiement
« Modèles correspondante dans
d’administration - une initiative. Cette
Panneau de définition permet à
configuration » Azure Policy de traiter
des machines
virtuelles Windows
avec des paramètres
non conformes dans
la catégorie de
« Modèles
Panneau de
configuration ». Pour
sur les stratégies
visitez

MSS (hérité) » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Modèles
MSS (hérité) ». Pour
sur les stratégies
visitez

Réseau » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Modèles
Réseau ». Pour plus
stratégies Guest

Système » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Modèles
Système ». Pour plus
stratégies Guest

« Options de sécurité correspondante dans
- Comptes » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Comptes ». Pour
sur les stratégies
visitez

- Audit » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Audit ». Pour plus
stratégies Guest

- Appareils » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Appareils ». Pour
sur les stratégies
visitez

- Connexion une initiative. Cette
interactive » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Connexion
interactive ». Pour
sur les stratégies
visitez

- Client réseau une initiative. Cette
Microsoft » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Client réseau
Microsoft ». Pour plus
stratégies Guest

- Serveur réseau une initiative. Cette
Microsoft » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Serveur réseau
Microsoft ». Pour plus
stratégies Guest

- Accès réseau » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Accès réseau ». Pour
sur les stratégies
visitez

- Sécurité réseau » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Sécurité réseau ».
Pour plus
stratégies Guest

- Console de une initiative. Cette
récupération » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Console de
récupération ». Pour
sur les stratégies
visitez

- Arrêt » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Arrêt ». Pour plus
stratégies Guest

- Objets système » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Objets système ».
Pour plus
stratégies Guest

- Paramètres une initiative. Cette
système » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Paramètres
système ». Pour plus
stratégies Guest

- Contrôle de compte une initiative. Cette
utilisateur » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
- Contrôle de compte
utilisateur ». Pour plus
stratégies Guest

« Paramètres de correspondante dans
sécurité - Stratégies une initiative. Cette
de compte » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Paramètres de
sécurité - Stratégies
de compte ». Pour
sur les stratégies
visitez

« Stratégies d’audit correspondante dans
système - Connexion une initiative. Cette
au compte » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Connexion
au compte ». Pour
sur les stratégies
visitez

système - Gestion des une initiative. Cette
comptes » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Gestion des
comptes ». Pour plus
stratégies Guest

système - Suivi une initiative. Cette
détaillé » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Suivi
détaillé ». Pour plus
stratégies Guest

système - Connexion- une initiative. Cette
Déconnexion » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Connexion-
Déconnexion ». Pour
sur les stratégies
visitez

système - Accès une initiative. Cette
objet » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Accès
objet ». Pour plus
stratégies Guest

système - une initiative. Cette
Modification de la définition permet à
stratégie » Azure Policy de traiter
des machines
virtuelles Windows
non conformes dans
la catégorie de
système -
Modification de la
stratégie ». Pour plus
stratégies Guest

système - Utilisation une initiative. Cette
privilégiée » définition permet à
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Utilisation
privilégiée ». Pour
sur les stratégies
visitez

système - Système » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
système - Système ».
Pour plus
stratégies Guest

« Attribution de droits correspondante dans
utilisateur » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Attribution de droits
utilisateur ». Pour plus
stratégies Guest

« Composants correspondante dans
Windows » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Composants
Windows ». Pour plus
stratégies Guest

« Propriétés du pare- correspondante dans
feu Windows » une initiative. Cette
des machines
virtuelles Windows
non conformes dans
la catégorie de
« Propriétés du pare-
feu Windows ». Pour
sur les stratégies
visitez

Windows dans stratégie de
lesquelles le groupe déploiement
Administrateurs correspondante dans
contient l’un des une initiative. Cette
membres spécifiés définition permet à
des machines
virtuelles Windows
dans lesquelles le
groupe
Administrateurs
contient l’un des
Pour plus
stratégies Guest

virtuelles Windows utilisée avec sa
dans lesquelles le stratégie de
groupe déploiement
Administrateurs ne correspondante dans
contient pas tous les une initiative. Cette
membres spécifiés définition permet à
des machines
virtuelles Windows
dans lesquelles le
groupe
Administrateurs ne
contient pas tous les
Pour plus
stratégies Guest

Windows dans stratégie de
lesquelles le groupe déploiement
Administrateurs ne correspondante dans
contient pas une initiative. Cette
seulement les définition permet à
membres spécifiés Azure Policy de traiter
des machines
virtuelles Windows
dans lesquelles le
groupe
Administrateurs ne
contient pas
seulement les
Pour plus
stratégies Guest

Windows sur stratégie de
lesquelles la déploiement
configuration DSC correspondante dans
n’est pas conforme une initiative. Cette
des machines
virtuelles Windows
sur lesquelles la
configuration DSC
(Desired State
Configuration) n’est
pas conforme. Cette
uniquement aux
machines dotées de
WMF 4 et versions
ultérieures. Pour plus
stratégies Guest

lesquelles l’agent Log déploiement
Analytics n’est pas correspondante dans
connecté comme une initiative. Cette
prévu définition permet à
des machines
virtuelles Windows
sur lesquelles l’agent
Log Analytics n’est
pas connecté aux
espaces de travail
spécifiés. Pour plus
stratégies Guest

lesquelles l’état de déploiement
connexion de l’hôte correspondante dans
distant ne correspond une initiative. Cette
pas à celui spécifié définition permet à
des machines
virtuelles Windows
sur lesquelles l’état de
connexion de l’hôte
distant ne correspond
pas à celui spécifié.
Pour plus
stratégies Guest

lesquelles les services déploiement
spécifiés ne sont pas correspondante dans
installés et 'En cours une initiative. Cette
d’exécution' définition permet à
des machines
virtuelles Windows
sur lesquelles les
services spécifiés ne
sont pas installés et
'En cours d’exécution'.
Pour plus
stratégies Guest

lesquelles Windows déploiement
Defender Exploit correspondante dans
Guard n’est pas activé une initiative. Cette
des machines
virtuelles Windows
sur lesquelles
Windows Defender
Exploit Guard n’est
pas activé. Pour plus
stratégies Guest

qui autorisent la stratégie de
réutilisation des déploiement
24 mots de passe correspondante dans
précédents une initiative. Cette
des machines
virtuelles Windows
qui autorisent la
réutilisation des
24 mots de passe
précédents. Pour plus
stratégies Guest

Windows qui ne sont stratégie de
pas jointes au déploiement
domaine spécifié correspondante dans
des machines
virtuelles Windows
qui ne sont pas
jointes au domaine
spécifié. Pour plus
stratégies Guest

Windows qui ne sont stratégie de
pas définies sur le déploiement
fuseau horaire spécifié correspondante dans
des machines
virtuelles Windows
qui ne sont pas
définies sur le fuseau
horaire spécifié. Pour
sur les stratégies
visitez

Windows qui stratégie de
contiennent des déploiement
certificats arrivant à correspondante dans
expiration dans le une initiative. Cette
nombre de jours définition permet à
spécifié Azure Policy de traiter
des machines
virtuelles Windows
qui contiennent des
certificats arrivant à
expiration dans le
nombre de jours
stratégies Guest

Windows qui ne stratégie de
contiennent pas les déploiement
certificats spécifiés correspondante dans
dans la racine de une initiative. Cette
confiance définition permet à
des machines
virtuelles Windows
qui ne contiennent
pas les certificats
spécifiés dans le
magasin de certificats
des autorités de
certification racines de
confiance
(Cert:\LocalMachine\R
oot). Pour plus
stratégies Guest

qui n’ont pas stratégie de
l’antériorité maximale déploiement
du mot de passe correspondante dans
définie sur 70 jours une initiative. Cette
des machines
virtuelles Windows
qui n’ont pas
l’antériorité maximale
du mot de passe
définie sur 70 jours.
Pour plus
stratégies Guest

qui n’ont pas stratégie de
l’antériorité minimale déploiement
du mot de passe correspondante dans
définie sur 1 jour une initiative. Cette
des machines
virtuelles Windows
qui n’ont pas
l’antériorité minimale
du mot de passe
définie sur 1 jour.
Pour plus
stratégies Guest

qui n’ont pas le stratégie de
paramètre de déploiement
complexité de mot de correspondante dans
passe activé une initiative. Cette
des machines
virtuelles Windows
qui n’ont pas le
paramètre de
complexité de mot de
passe activé. Pour
sur les stratégies
visitez

Windows qui n’ont stratégie de
pas les applications déploiement
spécifiées installées correspondante dans
des machines
virtuelles Windows
qui n’ont pas les
stratégies Guest

pas la stratégie déploiement
d’exécution Windows correspondante dans
PowerShell spécifiée une initiative. Cette
des machines
virtuelles Windows où
Windows PowerShell
n’est pas configuré
pour utiliser la
stratégie d’exécution
PowerShell spécifiée.
Pour plus
stratégies Guest

de l’audit pour les uniquement être
pas les modules déploiement
Windows PowerShell correspondante dans
spécifiés installés une initiative. Cette
des machines
virtuelles Windows
sur lesquelles les
modules Windows
PowerShell spécifiés
ne sont pas installés.
Pour plus
stratégies Guest

qui ne limitent pas la stratégie de
longueur minimale du déploiement
mot de passe à correspondante dans
14 caractères une initiative. Cette
des machines
virtuelles Windows
qui ne limitent pas la
longueur minimale du
mot de passe à
14 caractères. Pour
sur les stratégies
visitez

qui ne stockent pas stratégie de
les mots de passe à déploiement
l’aide du chiffrement correspondante dans
réversible une initiative. Cette
des machines
virtuelles Windows
qui ne stockent pas
les mots de passe à
l’aide du chiffrement
réversible. Pour plus
stratégies Guest

pas redémarré depuis déploiement
le nombre de jours correspondante dans
spécifié une initiative. Cette
des machines
virtuelles Windows
qui n’ont pas
redémarré depuis le
nombre de jours
stratégies Guest

Windows qui ont les stratégie de
des machines
virtuelles Windows
qui ont les
stratégies Guest

Windows avec un stratégie de
redémarrage en déploiement
attente correspondante dans
des machines
virtuelles Windows
avec un redémarrage
en attente. Pour plus
stratégies Guest

d’audit des serveurs uniquement être
web Windows qui utilisée avec sa
n’utilisent pas de stratégie de
protocole de déploiement
communication correspondante dans
sécurisé une initiative. Cette
des serveurs web
Windows qui
n’utilisent pas les
protocoles de
communication
sécurisés (TLS 1.1 ou
TLS 1.2). Pour plus
stratégies Guest
Internet des Objets


diagnostic dans IoT des journaux de Désactivé
Hub doivent être diagnostic. Permet de
des fins
ou de compromission
du réseau.
Key Vault
Déployer les Déploie les deployIfNotExists 2.0.0 Lien

paramètres de paramètres de
diagnostic de Key diagnostic de Key
Vault sur Event Hub Vault pour les
envoyer en streaming
dans un hub
d’événements
régional sur tout
coffre de clés nouveau
ou mis à jour pour
lequel les paramètres
de diagnostic sont
manquants.

diagnostic dans Key des journaux de Désactivé
Vault doivent être diagnostic. Permet de
des fins
ou de compromission
du réseau.
Les objets Key Vault Cette stratégie vérifie Audit, Désactivé 1.0.0 Lien
doivent être si les objets de coffre
récupérables de clés ne sont pas
récupérables. La
fonctionnalité de
suppression réversible
permet de conserver
les ressources
pendant une période
de conservation
donnée (90 jours),
même après une
opération de
SUPPRESSION, tout
en donnant
l’impression que
l’objet est supprimé.
Quand « Protection
de purge » est
activée, un coffre ou
un objet à l’état
supprimé ne peut pas
être vidé avant la fin
de la période de
conservation de
90 jours. Ces coffres
et objets peuvent être
récupérés, ce qui
garantit aux clients le
suivi de la stratégie de
rétention.
Gérer les types de clés Cette stratégie gère audit, deny, disabled 1.0.0-preview Lien
de certificat autorisés les types de clés
autorisés pour les
certificats.
Gérer les noms de Cette stratégie gère audit, deny, disabled 1.0.0-preview Lien
courbe autorisés pour les noms de courbe
les certificats de elliptique autorisés
chiffrement à courbe pour les certificats de
elliptique chiffrement à courbe
elliptique.
Gérer les Cette stratégie gère la audit, deny, disabled 1.0.0-preview Lien
déclencheurs d’action configuration des
de durée de vie de déclencheurs d’action
certificat de durée de vie de
certificat avant
l’expiration du
certificat.
Gérer la période de Cette stratégie gère la audit, deny, disabled 1.0.0-preview Lien
validité de certificat période de validité
maximale des
certificats en mois.
Gère les certificats Cette stratégie gère audit, deny, disabled 1.0.0-preview Lien
émis par une autorité les certificats émis par
de certification non une autorité de
intégrée certification non
intégrée spécifiée.
Gérer les certificat Cette stratégie gère audit, deny, disabled 1.0.0-preview Lien
émis par une autorité les certificats émis par
de certification une autorité de
intégrée certification spécifiée
intégrée au coffre de
clés.
Gérer les certificats Cette stratégie gère audit, deny, disabled 1.0.0-preview Lien
arrivés à un nombre les certificats arrivés à
de jours spécifiés un nombre de jours
avant expiration spécifié de leur date
d’expiration.
Gérer la taille Cette stratégie gère la audit, deny, disabled 1.0.0-preview Lien
minimale de clé pour taille de clé minimale
les certificats RSA des certificats RSA.
Kubernetes
[Préversion] : [Moteur Cette stratégie enforceOPAConstrain 2.0.0-preview Lien

AKS] Ne pas autoriser n’autorise pas la t, désactivé
les conteneurs création de
privilégiés dans un conteneurs privilégiés
cluster Kubernetes dans un cluster
Kubernetes. Pour
obtenir des
instructions sur
l’utilisation de cette
stratégie, accédez à
https://aka.ms/kubep
olicydoc.

AKS] Appliquer une garantit une entrée t, désactivé
entrée HTTPS dans un HTTPS dans un
cluster Kubernetes cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.

AKS] Appliquer des garantit que les t, désactivé
équilibreurs de charge équilibreurs de charge
internes dans un n’ont pas d’adresses
cluster Kubernetes IP publiques dans un
cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.

AKS] Appliquer des garantit que les t, désactivé
étiquettes sur les étiquettes spécifiées
pods dans un cluster sont fournies pour les
Kubernetes pods dans un cluster
Kubernetes. Pour
obtenir des
instructions sur
olicydoc.

AKS] Appliquer des garantit des noms t, désactivé
noms d’hôte d’entrée d’hôte d’entrée
uniques dans les uniques dans les
espaces de noms d’un espaces de noms d’un
cluster Kubernetes cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.

AKS] Garantir que les garantit que des t, désactivé
limites de ressources limites de ressources
de processeur et de de processeur et de
mémoire sur les mémoire sont définies
conteneurs ne sur les conteneurs et
dépassent pas les qu’elles ne dépassent
limites spécifiées dans pas les limites
un cluster Kubernetes spécifiées dans un
cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.

AKS] Garantir que les garantit que les t, désactivé
conteneurs écoutent conteneurs écoutent
uniquement sur les uniquement sur les
ports autorisés dans ports autorisés dans
un cluster Kubernetes un cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.

AKS] Garantir garantit que seules les t, désactivé
seulement les images images conteneur
conteneur autorisées autorisées s’exécutent
dans un cluster dans un cluster
Kubernetes Kubernetes. Pour
obtenir des
instructions sur
olicydoc.

AKS] Garantir que les garantit que les t, désactivé
services écoutent services écoutent
un cluster Kubernetes un cluster Kubernetes.
Pour obtenir des
instructions sur
olicydoc.
Service Kubernetes
[Préversion limitée] : Cette stratégie EnforceRegoPolicy, 1.0.0-preview Lien

[AKS] Ne pas autoriser n’autorise pas la Désactivé
les conteneurs création de
privilégiés dans AKS conteneurs privilégiés
dans un cluster Azure
Kubernetes Service.
Les stratégies en
préversion limitée
fonctionnent
uniquement pour les
abonnements inscrits.
Pour vous inscrire,
accédez à
https://aka.ms/akspoli
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir une garantit une entrée Désactivé
entrée HTTPS dans HTTPS dans un
AKS cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir des garantit que les Désactivé
équilibreurs de charge équilibreurs de charge
internes dans AKS n’ont pas d’adresses
IP publiques dans un
cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir des garantit que les Désactivé
étiquettes sur les étiquettes spécifiées
pods dans AKS sont fournies pour les
pods dans un cluster
Azure Kubernetes
Service. Les stratégies
en préversion limitée
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir des garantit des noms Désactivé
noms d’hôte d’entrée d’hôte d’entrée
uniques dans les uniques dans les
espaces de noms AKS espaces de noms d’un
cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir que les garantit que les Désactivé
conteneurs écoutent conteneurs écoutent
AKS un cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir que garantit que des Désactivé
des limites de limites de ressources
ressources de de mémoire et de
mémoire et de processeur sont
processeur sont définies sur les
définies sur les conteneurs dans un
conteneurs dans AKS cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir que garantit que seules les Désactivé
seules les images images conteneur
conteneur autorisées autorisées s’exécutent
s’exécutent dans AKS dans un cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.

[AKS] Garantir que les garantit que les Désactivé
services écoutent services écoutent
AKS un cluster Azure
Kubernetes Service.
Les stratégies en
fonctionnent
uniquement pour les
Pour vous inscrire,
accédez à
cyonboarding. Pour
obtenir des
instructions sur
cydoc.
Lighthouse
Auditer la délégation Auditez la délégation Audit, Désactivé 1.0.0 Lien

d’étendues sur un d’étendues sur un
locataire gérant locataire gérant via
Azure Lighthouse.
Logic Apps

diagnostic dans Logic des journaux de Désactivé
Apps doivent être diagnostic. Permet de
des fins
ou de compromission
du réseau.
Application managée
Déployer des Déploie une ressource deployIfNotExists 1.0.0 Lien

associations pour une d’association qui
application managée associe les types de
ressources
sélectionnés à
l’application managée
spécifiée. Ce
déploiement de
stratégie ne prend
pas en charge les
types de ressources
imbriqués.
Surveillance
[Préversion] : Vérifier Présente les machines auditIfNotExists 1.0.0-preview Lien

le déploiement de virtuelles comme non
l’agent de conformes si l’image
dépendances - Image de machine virtuelle
de machine virtuelle (OS) n’est pas dans la
(système liste définie et que
d’exploitation) non l’agent n’est pas
listée installé. La liste
d’images de système
d’exploitation fait
l’objet de mises à jour
en même temps que
le support.
[Préversion] : Auditer Signale les groupes de auditIfNotExists 1.0.0-preview Lien

le déploiement de machines virtuelles
Dependency Agent identiques comme
dans des groupes de non conformes si
machines virtuelles l’image de machine
identiques - Image de virtuelle (système
machine virtuelle d’exploitation) ne
(système figure pas dans la liste
d’exploitation) non définie et que l’agent
listée n’est pas installé. La
liste d’images de
système d’exploitation
fait l’objet de mises à
jour en même temps
que le support.
[Préversion] : Auditer Présente les machines auditIfNotExists 1.0.0-preview Lien

le déploiement de virtuelles comme non
l’agent Log Analytics - conformes si l’image
Image de machine de machine virtuelle
virtuelle (système (OS) n’est pas dans la
d’exploitation) non liste définie et que
listée l’agent n’est pas
installé. La liste
en même temps que
le support.
[Préversion] : Auditer Signale les groupes de auditIfNotExists 1.0.0-preview Lien

le déploiement de Log machines virtuelles
Analytics Agent dans identiques comme
des groupes de non conformes si
machines virtuelles l’image de machine
identiques - Image de virtuelle (système
machine virtuelle d’exploitation) ne
(système figure pas dans la liste
d’exploitation) non définie et que l’agent
listée n’est pas installé. La
liste d’images de
jour en même temps
que le support.
[Préversion] : Auditer Signale des machines audit 1.0.0-preview Lien

les machines virtuelles virtuelles comme non
de l’espace de travail conformes si elles ne
Log Analytics - journalisent pas dans
Signaler les l’espace de travail Log
incompatibilités Analytics spécifié dans
l’affectation de
stratégie/d’initiative.
[Préversion] : Déployez Dependency deployIfNotExists 1.0.0-preview Lien

Déployer Dependency Agent pour des
Agent pour des groupe de machines
groupes de machines virtuelles identiques
virtuelles identiques Linux si l’image de
Linux machine virtuelle
(système
d’exploitation) est
dans la liste définie et
que l’agent n’est pas
installé. Remarque : Si
la valeur
upgradePolicy du
groupe identique est
définie sur Manuel,
vous devez appliquer
l’extension à toutes
les machines virtuelles
du groupe en
appelant une mise à
niveau. Dans
l’interface de ligne de
commande, cela se
traduirait par az vmss
update-instances.
[Préversion] : Déploie Dependency deployIfNotExists 1.0.0-preview Lien

Déployer Dependency Agent pour les
Agent pour les machines virtuelles
machines virtuelles Linux si l’image de
Linux machine virtuelle (OS)
est dans la liste
définie et que l’agent
n’est pas installé.
[Préversion] : Déployez Dependency deployIfNotExists 1.0.0-preview Lien

Déployer Dependency Agent pour des
Agent pour des groupe de machines
groupes de machines virtuelles identiques
virtuelles identiques Windows si l’image de
Windows machine virtuelle
(système
d’exploitation) est
dans la liste définie et
que l’agent n’est pas
installé. La liste
en même temps que
le support.
Remarque : Si la
valeur upgradePolicy
du groupe identique
est définie sur
Manuel, vous devez
appliquer l’extension à
toutes les machines
virtuelles du groupe
en appelant une mise
à niveau. Dans
commande, cela se
update-instances.
[Préversion] : Déploie Dependency deployIfNotExists 1.0.0-preview Lien

Déployer l’agent de Agent pour les
dépendances pour les machines virtuelles
machines virtuelles Windows si l’image de
Windows machine virtuelle (OS)
est dans la liste
n’est pas installé. La
liste d’images de
jour en même temps
que le support.
[Préversion] : Déployez Log deployIfNotExists 1.0.0-preview Lien

Déployer Log Analytics Agent pour
Analytics Agent pour les groupes de
des groupes de machines virtuelles
machines virtuelles identiques Linux si
identiques Linux l’image de machine
virtuelle (OS) est dans
la liste définie et que
l’agent n’est pas
installé. Remarque : Si
la valeur
upgradePolicy du
groupe identique est
définie sur Manuel,
vous devez appliquer
l’extension à toutes
du groupe en
appelant une mise à
niveau. Dans
commande, cela se
update-instances.
[Préversion] : Déploie Log Analytics deployIfNotExists 1.0.0-preview Lien

Déployer l’agent Log Agent pour les
Analytics pour les machines virtuelles
machines virtuelles Linux si l’image de
Linux machine virtuelle (OS)
est dans la liste
[Préversion] : Déployez Log deployIfNotExists 1.0.0-preview Lien

Déployer Log Analytics Agent pour
Analytics Agent pour les groupes de
des groupes de machines virtuelles
machines virtuelles identiques Windows si
identiques Windows l’image de machine
virtuelle (OS) est dans
la liste définie et que
l’agent n’est pas
installé. La liste
en même temps que
le support.
Remarque : Si la
valeur upgradePolicy
du groupe identique
est définie sur
Manuel, vous devez
toutes les machines
virtuelles du groupe
en appelant une mise
à niveau. Dans
commande, cela se
update-instances.
[Préversion] : Déploie Log Analytics deployIfNotExists 1.0.0-preview Lien

Déployer Log Agent pour les
Analytics Agent pour machines virtuelles
les machines virtuelles Windows si l’image de
Windows machine virtuelle (OS)
est dans la liste
n’est pas installé. La
liste d’images de
jour en même temps
que le support.
Le journal d’activité Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

doit être conservé le journal d’activité si Désactivé
pendant au moins un la conservation n’est
an pas définie sur
365 jours ou sur
toujours (jours de
conservation définis
sur 0).
Une alerte de journal Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

d’activité doit exister des opérations Désactivé
pour des opérations d’administration
d’administration spécifiques sans
spécifiques aucune alerte de
journal d’activité
configurée.

d’activité doit exister toute opération de Désactivé
pour des opérations stratégie spécifique
de stratégie sans aucune alerte de
spécifiques journal d’activité
configurée.

d’activité doit exister des opérations de Désactivé
pour des opérations sécurité spécifiques
de sécurité spécifiques sans aucune alerte de
journal d’activité
configurée.
Auditer le paramètre Auditez le paramètre AuditIfNotExists 1.0.0 Lien

de diagnostic de diagnostic pour les
types de ressources
sélectionnés
Le profil de journal Cette stratégie AuditIfNotExists, 1.0.0 Lien

Azure Monitor doit garantit qu’un profil Désactivé
collecter des journaux de journal collecte les
pour les catégories journaux pour les
« écriture », catégories « write »,
« suppression » et « delete » et
« action » « action »
Azure Monitor doit Cette stratégie AuditIfNotExists, 1.0.0 Lien

collecter les journaux effectue l’audit du Désactivé
d’activité dans toutes profil de journal Azure
les régions Monitor qui n’exporte
pas d’activités à partir
de toutes les régions
Azure prises en
charge, notamment la
région globale.
La solution 'Security Cette stratégie AuditIfNotExists, 1.0.0 Lien

and Audit' d’Azure garantit que la Désactivé
Monitor doit être solution Security and
déployée Audit est déployée.
Les abonnements Cette stratégie AuditIfNotExists, 1.0.0 Lien

Azure doivent avoir garantit l’activation Désactivé
un profil de journal d’un profil de journal
pour le journal pour l’exportation des
d’activité journaux d’activité.
Elle vérifie si aucun
profil de journal n’a
été créé pour
exporter les journaux
vers un compte de
stockage ou un hub
d’événements.
Déployer les Déploie les DeployIfNotExists, 2.0.0 Lien

paramètres de paramètres de Désactivé
diagnostic de compte diagnostic de compte
Batch sur Event Hub Batch à envoyer en
streaming à un hub
d’événements
régional quand un
compte Batch
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic de compte diagnostic de compte
batch sur l’espace de Batch à envoyer en
travail Log Analytics streaming à un
espace de travail Log
Analytics régional
quand un compte
Batch nouveau ou mis
à jour n’a pas ces
paramètres de
diagnostic.

diagnostic de Data diagnostic de Data
Lake Analytics sur Lake Analytics à
Event Hub envoyer en streaming
à un hub
d’événements
régional quand un
service Data Lake
Analytics nouveau ou
mis à jour n’a pas ces
paramètres de
diagnostic.

Lake Analytics sur Lake Analytics à
l’espace de travail Log envoyer en streaming
Analytics à un espace de travail
Log Analytics régional
quand un service
Data Lake Analytics
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

Lake Storage Gen1 Lake Storage Gen1 à
sur Event Hub envoyer en streaming
à un hub
d’événements
régional quand un
service Data Lake
Storage Gen1
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

Lake Storage Gen1 Lake Storage Gen1 à
sur l’espace de travail envoyer en streaming
Log Analytics à un espace de travail
Log Analytics régional
quand un service
Data Lake Storage
Gen1 nouveau ou mis
à jour n’a pas ces
paramètres de
diagnostic.

diagnostic d’Event diagnostic d’Event
Hub sur Event Hub Hub à envoyer en
streaming à un hub
d’événements
régional quand un
hub d’événements
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic d’Event diagnostic d’Event
Hub sur l’espace de Hub à envoyer en
Analytics régional
quand un hub
d’événements
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic de Key diagnostic de Key
Vault sur l’espace de Vault à envoyer en
Analytics régional
quand un coffre de
clés nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic de Logic diagnostic de Logic
Apps sur Event Hub Apps à envoyer en
streaming à un hub
d’événements
régional quand un
service Logic Apps
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic de Logic diagnostic de Logic
Apps sur l’espace de Apps à envoyer en
Analytics régional
quand un service
Logic Apps nouveau
ou mis à jour n’a pas
ces paramètres de
diagnostic.
Déployer des Cette stratégie deployIfNotExists 1.0.0 Lien

paramètres de déploie
diagnostic pour les automatiquement les
groupes de sécurité paramètres de
réseau diagnostic sur les
groupes de sécurité
réseau. Un compte de
stockage portant le
nom
« {storagePrefixParam
eter}{NSGLocation} »
est automatiquement
créé.
Déployez les Déployez les deployIfNotExists 1.0.0-preview Lien

diagnostic du coffre diagnostic du coffre
Recovery Services sur Recovery Services afin
l’espace de travail Log de les envoyer vers
Analytics pour les l’espace de travail Log
catégories propres à Analytics pour les
une ressource. catégories propres à
une ressource. Si l’une
des catégories
propres à la ressource
n’est pas activée, un
nouveau paramètre
de diagnostic est créé.

diagnostic des diagnostic des
services de recherche services de recherche
sur Event Hub à envoyer en
streaming à un hub
d’événements
régional quand un
service de recherche
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic des diagnostic des
services de recherche services de recherche
sur l’espace de travail à envoyer en
Log Analytics streaming à un
Analytics régional
quand un service de
recherche nouveau ou
paramètres de
diagnostic.

diagnostic de Service diagnostic de Service
Bus sur Event Hub Bus à envoyer en
streaming à un hub
d’événements
régional quand un
Service Bus nouveau
ou mis à jour n’a pas
ces paramètres de
diagnostic.

diagnostic de Service diagnostic de Service
Bus sur un espace de Bus à envoyer en
Analytics régional
quand un Service Bus
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.

diagnostic de Stream diagnostic de Stream
Analytics sur Event Analytics à envoyer
Hub en streaming à un
régional quand un
service Stream
Analytics nouveau ou
paramètres de
diagnostic.

diagnostic de Stream diagnostic de Stream
Analytics sur l’espace Analytics à envoyer
de travail Log en streaming à un
Analytics espace de travail Log
Analytics régional
quand un service
Stream Analytics
nouveau ou mis à
jour n’a pas ces
paramètres de
diagnostic.
L’agent de collecte de Security Center utilise AuditIfNotExists, 1.0.0-preview Lien

données sur le trafic Microsoft Monitoring Désactivé
réseau doit être Dependency Agent
installé sur les pour collecter des
machines virtuelles données sur le trafic
Linux réseau auprès de vos
machines virtuelles
Azure afin d’activer
des fonctionnalités
avancées de
protection réseau :
visualisation du trafic
sur le mappage
réseau,
recommandations sur
le durcissement de la
sécurité réseau,
menaces réseau
spécifiques, et ainsi de
suite.
L’agent de collecte de Security Center utilise AuditIfNotExists, 1.0.0-preview Lien

données sur le trafic Microsoft Monitoring Désactivé
réseau doit être Dependency Agent
installé sur les pour collecter des
machines virtuelles données sur le trafic
Windows réseau auprès de vos
machines virtuelles
Azure afin d’activer
des fonctionnalités
avancées de
protection réseau :
visualisation du trafic
sur le mappage
réseau,
recommandations sur
le durcissement de la
sécurité réseau,
menaces réseau
spécifiques, et ainsi de
suite.
Le compte de Cette stratégie vérifie AuditIfNotExists, 1.0.0 Lien

stockage disposant si le compte de Désactivé
du conteneur des stockage disposant
journaux d’activité du conteneur des
doit être chiffré avec journaux d’activité est
BYOK chiffré avec BYOK. La
stratégie fonctionne
uniquement si le
compte de stockage
se trouve par défaut
dans le même
abonnement que les
journaux d’activité.
Vous trouverez plus
d’informations sur le
chiffrement du
stockage Azure au
repos ici
https://aka.ms/azurest
oragebyok.
L’agent Log Analytics Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

doit être installé sur les groupes de Désactivé
Virtual Machine Scale machines virtuelles
Sets identiques
(Windows/Linux) si
l’agent Log Analytics
L’agent Log Analytics Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

doit être installé sur les machines virtuelles Désactivé
les machines virtuelles Windows/Linux si
l’agent Log Analytics
Réseau
Une stratégie Cette stratégie Audit, Désactivé 1.0.0 Lien

IPsec/IKE garantit que toutes
personnalisée doit les connexions de
être appliquée à passerelle de réseau
toutes les connexions virtuel Azure utilisent
de passerelle de une stratégie IPsec
réseau virtuel Azure (Internet Protocol
Security)/IKE (Internet
Key Exchange).
Algorithmes et forces
de clé pris en charge -
https://aka.ms/AA62k
b0
App Service doit Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

utiliser un point de App Service s’il n’est Désactivé
terminaison de pas configuré pour
service de réseau utiliser un point de
virtuel terminaison de
service de réseau
virtuel.
Les passerelles VPN Cette stratégie Audit, Désactivé 1.0.0 Lien

Azure ne doivent pas garantit que les
utiliser la référence passerelles VPN
SKU « de base » n’utilisent pas de
référence SKU « de
base ».
Container Registry Cette stratégie audite Audit, Désactivé 1.0.0-preview Lien

doit utiliser un point Container Registry s’il
de terminaison de n’est pas configuré
service de réseau pour utiliser un point
virtuel de terminaison de
service de réseau
virtuel.
Cosmos DB doit Cette stratégie audite Audit, Désactivé 1.0.0 Lien

utiliser un point de Cosmos DB s’il n’est
service de réseau
virtuel.
Déployer Network Cette stratégie crée DeployIfNotExists 1.0.0 Lien

Watcher lors de la une ressource
création de réseaux Network Watcher
virtuels dans des régions avec
des réseaux virtuels.
Vous devez vérifier
l’existence d’un
groupe de ressources
nommé
networkWatcherRG,
qui sert à déployer
des instances de
Network Watcher.
Event Hub doit utiliser Cette stratégie audite AuditIfNotExists, 1.0.0 Lien
un point de Event Hub s’il n’est Désactivé
service de réseau
virtuel.
Les sous-réseaux de Cette stratégie refuse deny 1.0.0 Lien

passerelle ne doivent un sous-réseau de
pas être configurés passerelle configuré
avec un groupe de avec un groupe de
sécurité réseau sécurité réseau.
L’attribution d’un
groupe de sécurité
réseau à un sous-
réseau de passerelle
entraîne l’arrêt du
fonctionnement de la
passerelle.
Key Vault doit utiliser Cette stratégie audite Audit, Désactivé 1.0.0 Lien
un point de Key Vault s’il n’est pas
terminaison de configuré pour utiliser
service de réseau un point de
service de réseau
virtuel.
Les interfaces réseau Cette stratégie refuse deny 1.0.0 Lien

doivent désactiver le les interfaces réseau
transfert IP qui permettaient le
transfert IP. Le
paramètre de
transfert IP désactive
la vérification par
Azure de la source et
de la destination
d’une interface
réseau. Il doit être
examiné par l’équipe
de sécurité réseau.
Les interfaces réseau Cette stratégie refuse deny 1.0.0 Lien

ne doivent pas avoir les interfaces réseau
d’adresses IP configurées avec une
publiques adresse IP publique.
Les adresses IP
publiques permettent
aux ressources
Internet de
communiquer avec les
ressources Azure et
aux ressources Azure
de communiquer avec
Internet. Il doit être
examiné par l’équipe
de sécurité réseau.
Network Watcher doit Network Watcher est auditIfNotExists 1.0.0 Lien

être activé un service régional
qui vous permet de
surveiller et de
diagnostiquer l’état
au niveau d’un
scénario réseau dans,
vers et depuis Azure.
La surveillance au
niveau des scénarios
vous permet de
diagnostiquer les
problèmes avec une
vue de bout en bout
du réseau. Les outils
de visualisation et de
diagnostic réseau
disponibles avec
Network Watcher
vous aident à
comprendre,
diagnostiquer et
obtenir des
informations sur votre
réseau dans Azure.
L’accès RDP à partir Cette stratégie audite Audit, Désactivé 1.0.0 Lien
d’Internet doit être toute règle de
bloqué sécurité réseau
autorisant l’accès RDP
à partir d’Internet.
Service Bus doit Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

utiliser un point de Service Bus s’il n’est Désactivé
service de réseau
virtuel.
SQL Server doit Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

utiliser un point de tout serveur SQL Désactivé
terminaison de Server non configuré
service de réseau pour utiliser un point
virtuel de terminaison de
service de réseau
virtuel.
L’accès SSH à partir Cette stratégie audite Audit, Désactivé 1.0.0 Lien
d’Internet doit être toute règle de
bloqué sécurité réseau
autorisant l’accès SSH
à partir d’Internet.
Les comptes de Cette stratégie audite Audit, Désactivé 1.0.0 Lien

stockage doivent les comptes de
utiliser un point de stockage non
terminaison de configurés pour
service de réseau
virtuel.
Les machines Cette stratégie audite Audit, Refuser, 1.0.0 Lien

virtuelles doivent être les machines virtuelles Désactivé
connectées à un connectées à un
réseau virtuel réseau virtuel non
approuvé approuvé.
Les réseaux virtuels Cette stratégie audite AuditIfNotExists, 1.0.0 Lien

doivent utiliser la les réseaux virtuels si Désactivé
passerelle de réseau la route par défaut ne
virtuel spécifiée pointe pas vers la
passerelle de réseau
virtuel spécifiée.
Recherche

diagnostic dans les des journaux de Désactivé
services Search diagnostic. Permet de
des fins
ou de compromission
du réseau.
Security Center
[Préversion] Supervise les AuditIfNotExists, 1.0.0-preview Lien

L’évaluation des vulnérabilités Désactivé
vulnérabilités doit être détectées par
activée sur les l’évaluation des
machines virtuelles vulnérabilités Azure
Security Center sur
Machines Virtuelles
[Préversion] : Des Limitez l’accès à l’API Audit, Désactivé 1.0.0-preview Lien

plages d’adresses IP Gestion des services
autorisées doivent Kubernetes en
être définies sur les n’accordant l’accès à
services Kubernetes l’API qu’à des
adresses IP de plages
spécifiques. Nous
vous recommandons
de limiter l’accès aux
plages d’adresses IP
autorisées afin d’être
sûr que seules les
applications des
réseaux autorisés
puissent accéder au
cluster.
[Préversion] : Le L’activation du AuditIfNotExists, 1.0.0-preview Lien

transfert IP doit être transfert IP sur la Désactivé
désactivé sur votre carte réseau d’une
machine virtuelle machine virtuelle
permet à cette
dernière de recevoir
du trafic adressé à
d’autres destinations.
Le transfert IP n'est
que rarement
nécessaire (par
exemple, lors de
l'utilisation de la
machine virtuelle en
tant qu'appliance
virtuelle de réseau).
Par conséquent, un
examen par l'équipe
de sécurité réseau est
requis.
[Préversion] : Les Mettez à niveau votre Audit, Désactivé 1.0.0-preview Lien

services Kubernetes cluster Kubernetes
doivent être mis à Services vers une
niveau vers une version ultérieure de
version Kubernetes pour le
non vulnérable de protéger des
Kubernetes vulnérabilités connues
de votre version
Kubernetes actuelle.
La vulnérabilité CVE-
2019-9946 a été
corrigée dans
Kubernetes
versions 1.11.9+,
1.12.7+, 1.13.5+ et
1.14.0+
[Préversion] : Des Définissez des Audit, Désactivé 1.0.0-preview Lien

stratégies de sécurité stratégies de sécurité
de pods doivent être de pod pour réduire
définies sur les le vecteur d’attaque
services Kubernetes en supprimant les
privilèges
d’application inutiles.
Nous vous
recommandons de
configurer des
stratégies de sécurité
de pod de façon à ce
que les pods ne
puissent accéder
qu’aux ressources
auxquelles ils sont
autorisés à accéder.
[Préversion] : Le Pour fournir un Audit, Désactivé 1.0.0-preview Lien

contrôle d’accès en filtrage précis des
fonction du rôle actions que les
(RBAC) doit être utilisateurs peuvent
utilisé sur les services effectuer, utilisez le
Kubernetes contrôle d’accès en
fonction du rôle
(RBAC) pour gérer les
autorisations dans les
clusters Kubernetes
Service et configurez
les stratégies
d’autorisation
appropriées.
3 propriétaires Il est recommandé de AuditIfNotExists, 1.0.0 Lien

maximum doivent désigner jusqu'à Désactivé
être désignés pour 3 propriétaires
votre abonnement d'abonnement pour
réduire le risque de
violation par un
propriétaire
compromis.
Une adresse e-mail de Entrez une adresse e- AuditIfNotExists, 1.0.0 Lien

contact de sécurité mail pour recevoir des Désactivé
doit être fournie pour notifications quand
votre abonnement Azure Security Center
détecte des
ressources
compromises
Un numéro de Entrez un numéro de AuditIfNotExists, 1.0.0 Lien

téléphone de contact téléphone pour Désactivé
de sécurité doit être recevoir des
fourni pour votre notifications quand
abonnement Azure Security Center
détecte des
ressources
compromises
L’accès via un point Azure Security Center AuditIfNotExists, 1.0.0 Lien

de terminaison a identifié une partie Désactivé
accessible à partir des règles de trafic
d’Internet doit être entrant de vos
limité groupes de sécurité
réseau comme trop
permissive. Les règles
de trafic entrant ne
doivent pas autoriser
l’accès à partir des
plages « Tout » ou
« Internet ». Cela peut
permettre aux
attaquants de cibler
facilement vos
ressources.
Des contrôles La création éventuelle AuditIfNotExists, 1.0.0 Lien

d’application d’une liste verte Désactivé
adaptatifs doivent d’applications sera
être activés sur les supervisée par Azure
machines virtuelles Security Center
Les recommandations Azure Security Center AuditIfNotExists, 1.0.0 Lien

de renforcement de analyse les tendances Désactivé
réseau adaptatif du trafic des machines
doivent être virtuelles accessibles
appliquées sur les sur Internet et fournit
machines virtuelles des recommandations
accessibles à partir sur les règles de
d’Internet groupe de sécurité
réseau à utiliser pour
réduire la surface
d’attaque potentielle
Le provisionnement Activer le AuditIfNotExists, 1.0.0 Lien

automatique de provisionnement Désactivé
l’agent de supervision automatique de
Log Analytics doit l’agent de supervision
être activé sur votre Log Analytics pour
abonnement collecter les données
de sécurité
DDoS Protection La protection DDoS AuditIfNotExists, 1.0.0 Lien

Standard doit être standard doit être Désactivé
activé activée pour tous les
réseaux virtuels avec
un sous-réseau qui
fait partie d’une
passerelle
d’application avec une
adresse IP publique.
Les comptes Les comptes AuditIfNotExists, 1.0.0 Lien

déconseillés doivent déconseillés doivent Désactivé
être supprimés de être supprimés de vos
votre abonnement abonnements. Les
comptes déconseillés
sont des comptes qui
ont été empêchés de
se connecter.
Les comptes Les comptes AuditIfNotExists, 1.0.0 Lien

déconseillés disposant déconseillés disposant Désactivé
d’autorisations de d’autorisations de
propriétaire doivent type propriétaire
être supprimés de doivent être
votre abonnement supprimés de votre
abonnement. Les
comptes déconseillés
sont des comptes qui
ont été empêchés de
se connecter.
Le chiffrement de Les machines AuditIfNotExists, 1.0.0 Lien

disque doit être virtuelles sans Désactivé
appliqué sur les chiffrement de disque
machines virtuelles activé seront
supervisées par Azure
Security Center en
tant que
recommandation
La notification par e- Activez l’envoi par e- AuditIfNotExists, 1.0.0 Lien

mail pour les alertes à mail des alertes de Désactivé
gravité élevée doit sécurité au contact de
être activée sécurité pour qu’il
reçoive des e-mails
d’alerte de sécurité de
Microsoft. Cela
permet de s’assurer
que les personnes
appropriées sont
informées des
problèmes de sécurité
potentiels et peuvent
réduire les risques
La notification par e- Activez l’envoi AuditIfNotExists, 1.0.0 Lien

mail au propriétaire d’alertes de sécurité Désactivé
de l’abonnement pour par e-mail au
les alertes à gravité propriétaire de
élevée doit être l’abonnement, afin
activée qu’il reçoive des e-
mails d’alerte de
sécurité de Microsoft.
Cela permet de
s’assurer qu’il est
informé de tous les
problèmes de sécurité
potentiels afin de
réduire le risque dans
le délai imparti
Activer Azure Security Identifie les deployIfNotExists 1.0.0 Lien

Center sur votre abonnements
abonnement existants qui ne sont
pas supervisés par
Azure Security Center
(ASC). Les
abonnements non
supervisés par ASC
sont inscrits au niveau
tarifaire gratuit. Les
abonnements déjà
supervisés par ASC
(gratuits ou standard)
sont considérés
comme conformes.
Pour inscrire les
abonnements
récemment créés,
ouvrez l’onglet de
conformité,
sélectionnez
l’affectation non
conforme appropriée
et créez une tâche de
correction. Répétez
cette étape si vous
souhaitez superviser
un ou plusieurs
nouveaux
abonnements avec
Security Center.
La solution de Vérifiez l’existence et AuditIfNotExists, 1.0.0 Lien

protection du point l’intégrité d’une Désactivé
de terminaison doit solution Endpoint
être installée sur les Protection dans vos
groupes de machines groupes de machines
virtuelles identiques virtuelles identiques,
pour les protéger des
menaces et des
vulnérabilités.
Les comptes externes Les comptes externes AuditIfNotExists, 1.0.0 Lien

disposant avec des autorisations Désactivé
d’autorisations de de type propriétaire
propriétaire doivent doivent être
être supprimés de supprimés de votre
votre abonnement abonnement pour
empêcher un accès
non contrôlé.

disposant avec des privilèges Désactivé
d’autorisations de d'accès en lecture
lecture doivent être doivent être
supprimés de votre supprimés de votre
abonnement abonnement afin
d'empêcher un accès
non contrôlé.

disposant avec des privilèges Désactivé
d’autorisations d'accès en écriture
d’écriture doivent être doivent être
supprimés de votre supprimés de votre
abonnement abonnement afin
d'empêcher un accès
non contrôlé.
Les machines Protégez votre AuditIfNotExists, 1.0.0 Lien

virtuelles accessibles à machine virtuelle Désactivé
partir d’Internet contre les menaces
doivent être potentielles en y
protégées avec des limitant l’accès avec
groupes de sécurité un groupe de sécurité
réseau réseau (NSG). Pour en
savoir plus sur le
contrôle du trafic avec
des groupes de
sécurité réseau, visitez
https://aka.ms/nsg-
doc
Le contrôle d’accès L’éventuel accès AuditIfNotExists, 1.0.0 Lien

réseau juste-à-temps juste-à-temps (JIT) au Désactivé
doit être appliqué sur réseau sera supervisé
les machines virtuelles par Azure Security
Center en tant que
recommandation
Les ports de gestion Les ports de gestion à AuditIfNotExists, 1.0.0 Lien

doivent être fermés distance ouverts Désactivé
sur vos machines exposent votre
virtuelles machine virtuelle à un
niveau de risque élevé
des attaques basées
sur Internet. Ces
attaques tentent
d’attaquer par force
brute les informations
d’identification afin
d’obtenir un accès
administrateur à
l’ordinateur.
L’authentification MFA (Multi-Factor AuditIfNotExists, 1.0.0 Lien

multifacteur doit être Authentication) doit Désactivé
activée sur les être activé pour tous
comptes disposant les comptes de
d’autorisations l'abonnement
d’écriture sur votre disposant de
abonnement privilèges d'accès en
écriture pour éviter
une violation des
comptes ou des
ressources.

multifacteur (MFA) Authentication) doit Désactivé
doit être activée sur être activé pour tous
les comptes disposant les comptes de
d’autorisations de l'abonnement
propriétaire sur votre disposant
abonnement d'autorisations de
propriétaire afin
d'éviter une violation
des comptes ou des
ressources.

multifacteur (MFA) Authentication) doit Désactivé
doit être activée sur être activé pour tous
les comptes disposant les comptes de
d’autorisations de l'abonnement
lecture sur votre disposant de
abonnement privilèges d'accès en
lecture afin d'éviter
une violation des
comptes ou des
ressources.
Superviser les agents Les serveurs sans AuditIfNotExists, 1.0.0 Lien

Endpoint Protection agent Endpoint Désactivé
manquants dans Protection installé
Azure Security Center seront supervisés par
en tant que
recommandation
Le niveau tarifaire Le niveau tarifaire Audit, Désactivé 1.0.0 Lien

standard Security standard permet la
Center doit être détection des
sélectionné menaces sur les
réseaux et les
machines virtuelles,
en fournissant des
fonctions de
renseignement sur les
menaces, la détection
d’anomalies et
l’analytique de
comportement dans
Les données sensibles Azure Security Center AuditIfNotExists, 1.0.0-preview Lien

de vos bases de supervise les résultats Désactivé
données SQL doivent de l’analyse de
être classifiées découverte et de
classification des
données pour vos
bases de données
SQL, et fournit des
recommandations
pour classifier les
données sensibles
dans vos bases de
données afin
d’améliorer la
supervision et la
sécurité
les sous-réseaux Protégez votre sous- AuditIfNotExists, 1.0.0 Lien

doivent être associés réseau contre les Désactivé
à un groupe de menaces potentielles
sécurité réseau en y limitant l’accès
avec un groupe de
sécurité réseau (NSG).
Les NSG contiennent
une liste de règles de
liste de contrôle
d’accès (ACL) qui
autorisent ou refusent
le trafic réseau vers
votre sous-réseau.
Les mises à jour Vérifiez si des mises à AuditIfNotExists, 1.0.0 Lien

système sur les jour de sécurité Désactivé
groupes de machines système et des mises
virtuelles identiques à jour critiques sont
doivent être installées manquantes et
doivent être installées
pour assurer la
sécurité de vos
groupes de machines
virtuelles identiques
Windows et Linux.
Les mises à jour Les mises à jour AuditIfNotExists, 1.0.0 Lien

système doivent être système de sécurité Désactivé
installées sur vos manquantes sur vos
machines serveurs seront
supervisées par Azure
Security Center en
tant que
recommandation
Plusieurs propriétaires Il est recommandé de AuditIfNotExists, 1.0.0 Lien

doivent être attribués désigner plusieurs Désactivé
à votre abonnement propriétaires
d'abonnement pour
disposer de la
redondance de l'accès
administrateur.
Les vulnérabilités Auditer les AuditIfNotExists, 1.0.0 Lien

dans les vulnérabilités dans la Désactivé
configurations de la configuration de
sécurité des sécurité sur les
conteneurs doivent machines où Docker
être corrigées est installé et afficher
en tant que
recommandations
dans Azure Security
Center.
Les vulnérabilités Les serveurs qui ne AuditIfNotExists, 1.0.0 Lien

dans la configuration respectent pas la base Désactivé
de la sécurité sur vos de référence
machines doivent être configurée seront
corrigées supervisés par Azure
Security Center en
tant que
recommandation
Les vulnérabilités Auditez les AuditIfNotExists, 1.0.0 Lien

dans la configuration vulnérabilités de Désactivé
de la sécurité de vos système d’exploitation
groupes de machines dans vos groupes de
virtuelles identiques machines virtuelles
doivent être corrigées identiques pour les
protéger des
attaques.
Les vulnérabilités sur Supervisez les AuditIfNotExists, 1.0.0 Lien

vos bases de données résultats de l'analyse Désactivé
SQL doivent être des vulnérabilités et
corrigées les recommandations
sur la correction des
vulnérabilités liées aux
bases de données.
Les vulnérabilités Surveille les AuditIfNotExists, 1.0.0 Lien

doivent être corrigées vulnérabilités Désactivé
avec une solution détectées par la
d’évaluation des solution d’évaluation
vulnérabilités des vulnérabilités et
sans solution
d’évaluation des
vulnérabilités dans
en tant que
recommandation.
Service Bus
Toutes les règles Les clients Service Bus Audit, Refuser, 1.0.1 Lien
d’autorisation, sauf ne doivent pas utiliser Désactivé
RootManageSharedAc une stratégie d’accès
cessKey, doivent être au niveau de l’espace
supprimées de de noms qui donne
l’espace de noms accès à l’ensemble des
Service Bus files d’attente et
rubriques d’un espace
de noms. Pour
respecter le modèle
de sécurité basé sur le
privilège minimum,
vous devez créer des
stratégies d’accès au
niveau de l’entité pour
les files d’attente et
les rubriques afin de
limiter l’accès à l’entité
spécifique

diagnostic dans des journaux de Désactivé
Service Bus doivent diagnostic. Permet de
être activés recréer les pistes
des fins
ou de compromission
du réseau.
Service Fabric
La propriété Service Fabric fournit Audit, Désactivé 1.0.0 Lien

ClusterProtectionLeve trois niveaux de
l doit être définie sur protection (None,
EncryptAndSign pour Sign et
les clusters Service EncryptAndSign) pour
Fabric la communication
nœud à nœud à l’aide
d’un certificat de
cluster principal.
Définissez le niveau
de protection pour
vous assurer que tous
les messages de
nœud à nœud sont
chiffrés et signés
numériquement
Les clusters Service Auditer l'utilisation de Audit, Désactivé 1.0.0 Lien

Fabric ne doivent l'authentification
utiliser Azure Active client uniquement par
Directory que pour le biais d'Azure Active
l’authentification client Directory dans Service
Fabric
SQL
Les paramètres Vérifiez qu’une AuditIfNotExists, 1.0.0 Lien

Advanced Data adresse e-mail est Désactivé
Security pour indiquée dans le
l’instance managée champ « Envoyer des
SQL doivent inclure alertes à » dans les
une adresse e-mail paramètres du
pour la réception des serveur Advanced
alertes de sécurité Data Security. Cette
adresse e-mail reçoit
des notifications
d’alerte quand des
activités anormales
sont détectées sur les
instances managées
SQL.

Advanced Data adresse e-mail est Désactivé
Security pour le indiquée dans le
serveur SQL doivent champ « Envoyer des
inclure une adresse e- alertes à » dans les
mail pour la réception paramètres du
des alertes de sécurité serveur Advanced
Data Security. Cette
des notifications
d’alerte quand des
activités anormales
sont détectées sur les
serveurs SQL.
Advanced Data Auditer les instances AuditIfNotExists, 1.0.0 Lien

Security doit être gérées SQL sans Désactivé
activée sur vos Advanced Data
instances managées Security
SQL
Advanced Data Auditer les serveurs AuditIfNotExists, 1.0.0 Lien

Security doit être SQL sans Advanced Désactivé
activé sur vos Data Security
serveurs SQL
Les types Advanced Nous vous AuditIfNotExists, 1.0.0 Lien

Threat Protection recommandons Désactivé
doivent être définis d’activer tous les
sur « Tous » dans les types Advanced
paramètres Advanced Threat Protection sur
Data Security de vos serveurs SQL.
l’instance managée L’activation de tous
SQL les types offre une
protection contre
l’injection SQL, les
vulnérabilités de base
de données et toute
autre activité
anormale.
Les types Advanced Nous vous AuditIfNotExists, 1.0.0 Lien

Threat Protection recommandons Désactivé
doivent être définis d’activer tous les
sur « Tous » dans les types Advanced
paramètres Advanced Threat Protection sur
Data Security du vos serveurs SQL.
serveur SQL L’activation de tous
les types offre une
protection contre
l’injection SQL, les
de données et toute
autre activité
anormale.
Un administrateur Auditer AuditIfNotExists, 1.0.0 Lien

Azure Active Directory l’approvisionnement Désactivé
doit être d’un administrateur
approvisionné pour Azure Active Directory
les serveurs SQL pour votre serveur
SQL afin d’activer
l’authentification
Azure AD.
L’authentification
Azure AD permet une
gestion simplifiée des
autorisations et une
gestion centralisée
des utilisateurs de
bases de données et
d’autres services
Microsoft
L’audit sur SQL Server L’audit sur votre AuditIfNotExists, 1.0.0 Lien
doit être activé serveur SQL Server Désactivé
doit être activé pour
suivre les activités de
toutes les bases de
données du serveur
et les enregistrer dans
un journal d’audit.
La limitation de Cette stratégie aide à AuditIfNotExists, 1.0.0 Lien

connexion doit être auditer toutes les Désactivé
activée pour les bases de données
serveurs de base de PostgreSQL de votre
données PostgreSQL environnement sans
activer la limitation de
connexion. Ce
paramètre active la
limitation de
connexion temporaire
par adresse IP à la
suite d’un trop grand
nombre de
connexions
infructueuses avec
des mots de passe
non valides.
Déployer Advanced Cette stratégie active DeployIfNotExists 1.0.0 Lien

Data Security sur des Advanced Data
serveurs SQL Security sur les
serveurs SQL. (ce qui
entraîne l’activation
de la détection des
menaces et de
l’évaluation des
vulnérabilités). Elle
crée
automatiquement un
compte de stockage
dans la même région
et le même groupe de
ressources que le
serveur SQL pour
stocker les résultats
de l’analyse, avec le
préfixe « sqlva ».
Déployer l’audit sur Cette stratégie DeployIfNotExists 1.0.0 Lien

des serveurs SQL garantit que l’audit
est activé sur les
serveurs SQL pour
améliorer la sécurité
et la conformité. Elle
crée
automatiquement un
compte de stockage
dans la même région
que celle du serveur
SQL pour stocker les
enregistrements
d’audit.
Déployer les Déploie les DeployIfNotExists 1.0.0 Lien

diagnostic d’Azure diagnostic d’Azure
SQL Database sur SQL Database pour
Event Hub les envoyer en
streaming dans un
régional sur une base
de données Azure
SQL nouvelle ou mise
à jour pour laquelle
les paramètres de
diagnostic sont
manquants.
Déployer le Active Transparent DeployIfNotExists 1.0.0 Lien

chiffrement Data Encryption sur
transparent des les bases de données
données sur les bases SQL
de données SQL
Déployer la détection Cette stratégie vérifie DeployIfNotExists 1.0.0 Lien

de menaces sur les que la détection des
serveurs SQL menaces est activée
sur les serveurs SQL
Server.
Les déconnexions Cette stratégie AuditIfNotExists, 1.0.0 Lien

doivent être permet d’auditer Désactivé
journalisées pour les toutes les bases de
serveurs de bases de données PostgreSQL
données PostgreSQL. de votre
environnement sans
activer le paramètre
log_disconnections.
Les notifications par Vérifiez que « envoyer AuditIfNotExists, 1.0.0 Lien

e-mail aux une notification par e- Désactivé
administrateurs et mail aux
propriétaires administrateurs et aux
d’abonnements propriétaires
doivent être activées d’abonnement » est
dans les paramètres activé dans les
Advanced Data paramètres Advanced
Security de l’instance Threat Protection de
managée SQL l’instance managée
SQL. De cette façon,
les détections
d’activités anormales
sur une instance
managée SQL sont
signalées dès que
possible aux
administrateurs.
Les notifications par Vérifiez que l’option AuditIfNotExists, 1.0.0 Lien

e-mail aux « envoyer une Désactivé
administrateurs et notification par e-mail
propriétaires aux administrateurs et
d’abonnements aux propriétaires
doivent être activées d’abonnement » est
dans les paramètres activée dans les
Advanced Data paramètres Advanced
Security SQL Server Threat Protection du
serveur SQL. De cette
façon, les détections
d’activités anormales
sur un serveur SQL
sont signalées dès
que possible aux
administrateurs.
L’application de la Cette stratégie Audit, Désactivé 1.0.0 Lien

connexion SSL doit permet d’effectuer un
être activée pour les audit sur un serveur
serveurs de base de MySQL qui n’applique
données MySQL pas la connexion SSL.
La base de données
Azure pour MySQL
prend en charge la
connexion de votre
serveur Azure
Database pour
MySQL aux
applications clientes à
l’aide de Secure
Sockets Layer (SSL).
L’application de
connexions SSL entre
votre serveur de base
de données et vos
applications clientes
vous protège contre
les « attaques de
l’intercepteur » en
chiffrant le flux de
données entre le
serveur et votre
application.
L’application de la Cette stratégie Audit, Désactivé 1.0.0 Lien

connexion SSL doit permet d’effectuer un
être activée pour les audit sur un serveur
serveurs de base de PostgreSQL qui
données PostgreSQL n’applique pas la
connexion SSL. La
base de données
Azure pour
PostgreSQL préfère
connecter vos
applications clientes
au service
PostgreSQL via SSL
(Secure Sockets
Layer). L’application
de connexions SSL
entre votre serveur
de base de données
et vos applications
clientes vous protège
contre les « attaques
de l’intercepteur » en
chiffrant le flux de
données entre le
serveur et votre
application
La sauvegarde Cette stratégie Audit, Désactivé 1.0.0 Lien

géoredondante doit permet d’effectuer un
être activée pour audit d’une base de
Azure Database for données Azure
MariaDB Database for MariaDB
si la sauvegarde
géoredondante n’est
pas activée.

Azure Database pour données Azure
MySQL Database pour
MySQL si la
sauvegarde
pas activée.

Azure Database pour données Azure
PostgreSQL Database pour
PostgreSQL si la
sauvegarde
pas activée.
Les points de contrôle Cette stratégie AuditIfNotExists, 1.0.0 Lien

de journal doivent permet d’auditer Désactivé
être activés pour les toutes les bases de
données PostgreSQL de votre
environnement sans
log_checkpoints.
Les connexions de Cette stratégie AuditIfNotExists, 1.0.0 Lien

journal doivent être permet d’auditer Désactivé
activées pour les toutes les bases de
données PostgreSQL de votre
environnement sans
log_connections.
La durée de journal Cette stratégie AuditIfNotExists, 1.0.0 Lien

doit être activée pour permet d’auditer Désactivé
les serveurs de bases toutes les bases de
de données données PostgreSQL
PostgreSQL de votre
environnement sans
log_duration.
La sauvegarde Cette stratégie AuditIfNotExists, 1.0.0 Lien

géoredondante à long permet d’effectuer un Désactivé
terme doit être audit d’une base de
activée pour les bases données Azure SQL
de données Azure Database si la
SQL sauvegarde
géoredondante à long
terme n’est pas
activée.
Le serveur MariaDB Cette stratégie AuditIfNotExists, 1.0.0 Lien

doit utiliser un point permet d’auditer les Désactivé
de terminaison de serveurs MariaDB qui
service de réseau ne sont pas
virtuel configurés pour
utiliser un point de
terminaison de
service de réseau
virtuel.
Le serveur MySQL Cette stratégie AuditIfNotExists, 1.0.0 Lien

doit utiliser un point permet d’auditer les Désactivé
de terminaison de serveurs MySQL qui
service de réseau ne sont pas
virtuel configurés pour
terminaison de
service de réseau
virtuel.
Le serveur Cette stratégie AuditIfNotExists, 1.0.0 Lien

PostgreSQL doit permet d’auditer les Désactivé
utiliser un point de serveurs PostgreSQL
terminaison de qui ne sont pas
service de réseau configurés pour
virtuel utiliser un point de
terminaison de
service de réseau
virtuel.
Le point de Cette stratégie AuditIfNotExists, 1.0.0 Lien

terminaison privé doit permet d’auditer les Désactivé
être activé pour les serveurs MariaDB qui
serveurs MariaDB ne sont pas
configurés pour
terminaison privé.

être activé pour les serveurs MySQL qui
serveurs MySQL ne sont pas
configurés pour
terminaison privé.

être activé pour les serveurs PostgreSQL
serveurs PostgreSQL qui ne sont pas
configurés pour
terminaison privé.
Les paramètres La propriété AuditIfNotExists, 1.0.0 Lien

d’audit SQL doivent AuditActionsAndGrou Désactivé
avoir des groupes ps doit contenir au
d’actions configurés moins
pour capturer les SUCCESSFUL_DATAB
activités critiques ASE_AUTHENTICATIO
N_GROUP,
FAILED_DATABASE_A
UTHENTICATION_GR
OUP,
BATCH_COMPLETED_
GROUP pour assurer
la journalisation totale
de l’audit
Le protecteur TDE de Transparent Data AuditIfNotExists, 1.0.0 Lien

l’instance managée Encryption (TDE) avec Désactivé
SQL doit être chiffré prise en charge de
avec votre propre clé votre propre clé offre
les avantages
suivants :
transparence et
contrôle améliorés sur
le protecteur TDE,
sécurité durcie avec
un service externe
HSM et promotion de
la séparation des
tâches.
Le protecteur TDE du Transparent Data AuditIfNotExists, 1.0.0 Lien

serveur SQL doit être Encryption (TDE) avec Désactivé
chiffré avec votre prise en charge de
propre clé votre propre clé offre
les avantages
suivants :
transparence et
contrôle améliorés sur
le protecteur TDE,
sécurité durcie avec
un service externe
HSM et promotion de
la séparation des
tâches.
Les serveurs SQL Auditez les serveurs AuditIfNotExists, 1.0.0 Lien

doivent être SQL configurés avec Désactivé
configurés avec une une période de
période de conservation d’audit
conservation d’audit inférieure à 90 jours.
supérieure à 90 jours.
Transparent Data Le chiffrement AuditIfNotExists, 1.0.0 Lien

Encryption sur les transparent des Désactivé
bases de données données doit être
SQL doit être activé activé pour protéger
les données au repos
et respecter les
conditions de
conformité requises

d’évaluation des adresse e-mail est Désactivé
vulnérabilités de SQL fournie pour le champ
Server doivent « Envoyer les
contenir une adresse rapports d’analyse à »
e-mail pour recevoir dans les paramètres
les rapports d’analyse d’évaluation des
vulnérabilités. Cette
le récapitulatif des
résultats d’analyse
après l’exécution
d’une analyse
périodique sur les
serveurs SQL.
L’évaluation des Auditez les instances AuditIfNotExists, 1.0.0 Lien

vulnérabilités doit être managées SQL qui Désactivé
activée sur vos n’ont pas d’analyses
instances managées récurrentes
SQL d’évaluation des
vulnérabilités activées.
L’évaluation des
vulnérabilités peut
découvrir et suivre les
potentielles
de données, et vous
aider à y remédier.
L’évaluation des Auditez les serveurs AuditIfNotExists, 1.0.0 Lien

vulnérabilités doit être Azure SQL qui n’ont Désactivé
activée sur vos pas d’analyses
serveurs SQL récurrentes
d’évaluation des
vulnérabilités activées.
L’évaluation des
vulnérabilités peut
découvrir et suivre les
potentielles
de données, et vous
aider à y remédier.
Stockage
Références SKU de Cette stratégie vous Deny 1.0.0 Lien

compte de stockage permet de spécifier un
autorisées ensemble de
références de compte
de stockage que votre
organisation peut
déployer.
Auditer l’accès réseau Auditer l’accès illimité Audit, Désactivé 1.0.0 Lien
illimité aux comptes au réseau dans les
de stockage paramètres de pare-
feu de votre compte
de stockage. Au lieu
de cela, configurer les
règles du réseau de
telle manière que
seules les applications
des réseaux autorisés
puissent accéder au
compte de stockage.
Pour autoriser les
connexions de clients
Internet ou locaux
spécifiques, l’accès au
trafic peut être
autorisé à partir de
réseaux virtuels Azure
spécifiques ou vers
des plages d’adresses
IP Internet publiques
Déployer Advanced Cette stratégie active DeployIfNotExists, 1.0.0 Lien

Threat Protection sur Advanced Threat Désactivé
les comptes de Protection sur les
stockage comptes de stockage.
Le stockage Cette stratégie Audit, Désactivé 1.0.0 Lien

géoredondant doit permet d’auditer un
être activé pour les compte de stockage si
comptes de stockage le stockage
géoredondant n’est
pas activé.
La sécurisation du Auditer l’exigence de Audit, Refuser, 1.0.0 Lien

transfert vers des transfert sécurisé Désactivé
comptes de stockage dans votre compte de
doit être activée stockage. L’option de
sécurisation du
transfert oblige votre
compte de stockage à
accepter uniquement
des requêtes
provenant de
connexions sécurisées
(HTTPS). L’utilisation
de HTTPS garantit
l’authentification entre
le serveur et le service
et protège les
données en transit
contre les attaques de
la couche réseau
(attaque de
l’intercepteur ou
« man-in-the-
middle », écoute
clandestine,
détournement de
session)
Les comptes de Certains services Audit, Refuser, 1.0.0 Lien

stockage doivent Microsoft qui Désactivé
autoriser l’accès à interagissent avec les
partir des services comptes de stockage
Microsoft approuvés fonctionnent à partir
de réseaux qui ne
peuvent pas obtenir
l’accès par le biais des
règles de réseau. Pour
que ce type de service
fonctionne comme
prévu, autorisez
l’ensemble des
services Microsoft
approuvés à
contourner les règles
de réseau. Ces
services utilisent alors
une authentification
forte pour accéder au
compte de stockage.
Les comptes de Profitez des Audit, Refuser, 1.0.0 Lien

stockage doivent être nouveautés d’Azure Désactivé
migrés vers de Resource
nouvelles ressources Manager pour
Azure Resource renforcer la sécurité
Manager de vos comptes de
stockage : contrôle
d’accès plus puissant,
audit amélioré,
déploiement et
gouvernance basés
sur Azure Resource
Manager, accès aux
identités managées,
accès au coffre de clés
pour les secrets,
authentification basée
sur Azure AD, prise en
charge des étiquettes
et des groupes de
ressources pour
faciliter la gestion de
la sécurité, etc.
Stream Analytics

diagnostic dans Azure des journaux de Désactivé
Stream Analytics diagnostic. Permet de
des fins
ou de compromission
du réseau.
Balises
Ajouter une étiquette Ajoute l’étiquette et la modify 1.0.0 Lien

aux groupes de valeur indiquées lors
ressources de la création ou de la
mise à jour d’un
groupe de ressources
auquel cette étiquette
manque. Il est
possible de corriger
des groupes de
ressources existants
en déclenchant une
tâche de correction. Si
l’étiquette existe avec
une valeur différente,
elle n’est pas modifiée.
Ajouter une étiquette Ajoute l’étiquette et la modify 1.0.0 Lien

aux ressources valeur indiquées lors
de la création ou de la
mise à jour d’une
ressource à laquelle
cette étiquette
manque. Il est
des ressources
existantes en
déclenchant une
Ne modifie pas les
balises sur les
groupes de
ressources.
Ajouter ou remplacer Ajoute ou remplace modify 1.0.0 Lien

une étiquette sur des l’étiquette et la valeur
groupes de indiquées lors de la
ressources création ou de la mise
à jour d’un groupe de
ressources. Il est
des groupes de
ressources existants
en déclenchant une
tâche de correction.
Ajouter ou remplacer Ajoute ou remplace modify 1.0.0 Lien

une étiquette dans les l’étiquette et la valeur
ressources indiquées lors de la
création ou de la mise
à jour d’une
ressource. Il est
des ressources
existantes en
déclenchant une
Ne modifie pas les
balises sur les
groupes de
ressources.
Ajouter une étiquette Ajoute l’étiquette append 1.0.0 Lien

et sa valeur à partir indiquée avec sa
du groupe de valeur du groupe de
ressources ressources lors de la
à jour d’une ressource
à laquelle cette
étiquette manque. Ne
modifie pas les
étiquettes des
ressources créées
avant l’application de
cette stratégie, tant
que ces ressources ne
sont pas modifiées.
De nouvelles
stratégies d’effet
« modify » sont
disponibles pour
prendre en charge la
correction des
étiquettes sur les
ressources existantes
(voir
https://aka.ms/modify
doc).
Ajouter une étiquette Ajoute l’étiquette et la append 1.0.0 Lien

et sa valeur aux valeur indiquées lors
groupes de de la création ou de la
ressources mise à jour d’un
groupe ressource
auquel cette étiquette
manque. Ne modifie
pas les étiquettes des
groupes de
ressources créés
que ces groupes de
ressources ne sont
pas modifiés. De
nouvelles stratégies
d’effet « modify » sont
disponibles pour
correction des
étiquettes sur les
(voir
doc).
Ajouter une étiquette Ajoute l’étiquette et la append 1.0.1 Lien

et sa valeur aux valeur indiquées lors
ressources de la création ou de la
cette étiquette
manque. Ne modifie
pas les étiquettes des
ressources créées
que ces ressources ne
sont pas modifiées.
Ne s’applique pas aux
groupes de
ressources. De
nouvelles stratégies
d’effet « modify » sont
disponibles pour
correction des
étiquettes sur les
(voir
doc).
Hériter d’une Ajoute ou remplace modify 1.0.0 Lien

étiquette du groupe l’étiquette et la valeur
de ressources indiquées du groupe
de ressources parent
lors de la création ou
de la mise à jour
d’une ressource. Il est
des ressources
existantes en
déclenchant une
Hériter d’une Ajoute l’étiquette modify 1.0.0 Lien

étiquette du groupe indiquée avec sa
de ressources en cas valeur du groupe de
d’absence ressources parent lors
de la création ou de la
cette étiquette
manque. Il est
des ressources
existantes en
déclenchant une
Hériter une étiquette Ajoute ou remplace modify 1.0.0 Lien

de l’abonnement l’étiquette spécifiée et
sa valeur de
l’abonnement
conteneur lors de la
à jour d’une
ressource. Il est
des ressources
existantes en
déclenchant une
Hériter une étiquette Ajoute l’étiquette modify 1.0.0 Lien

de l’abonnement si spécifiée avec sa
elle est manquante valeur de
l’abonnement
conteneur lors de la
à jour d’une ressource
qui n’a pas cette
étiquette. Il est
des ressources
existantes en
déclenchant une
Exiger une étiquette Applique une deny 1.0.0 Lien

et sa valeur sur les étiquette obligatoire
groupes de avec sa valeur aux
ressources groupes de
ressources.
Exiger une étiquette Applique une balise deny 1.0.1 Lien

et sa valeur sur les requise et sa valeur.
ressources Ne s’applique pas aux
groupes de
ressources.
Exiger une étiquette Applique l’existence deny 1.0.0 Lien

sur les groupes de d’une étiquette sur
ressources des groupes de
ressources.
Exiger une étiquette Applique l’existence deny 1.0.1 Lien

sur les ressources d’une étiquette. Ne
s’applique pas aux
groupes de
ressources.
Étapes suivantes
Définitions d’initiative Azure Policy intégrées
Cette page est un index de définitions d’initiative intégrées Azure Policy.

Le lien associé au nom de chaque définition intégrée mène à la source de définition de l’initiative dans le dépôt
GitHub Azure Policy. Les définitions intégrées sont regroupées par la propriété category dans metadata. Pour
accéder à une catégorie spécifique, utilisez le menu sur le côté droit de la page. Autrement, utilisez Ctrl-F pour
utiliser la fonctionnalité de recherche de votre navigateur.
Guest Configuration
NOM DESCRIPTION STRATÉGIES VERSION
Auditer les machines Cette initiative permet de 2 1.1.0

virtuelles Linux qui n’ont pas déployer les exigences de
les applications spécifiées stratégie et d’auditer les
installées machines virtuelles Linux sur
lesquelles les applications
spécifiées ne sont pas
stratégies Guest

virtuelles Linux qui ont les déployer les exigences de
applications spécifiées stratégie et d’auditer les
installées machines virtuelles Linux sur
lesquelles les applications
spécifiées sont installées.
Pour plus d’informations sur
les stratégies Guest
Auditer les machines Cette initiative permet de 18 1.1.0-preview

virtuelles avec des déployer les exigences de
paramètres de sécurité de stratégie et d’auditer les
mot de passe non sécurisés machines virtuelles avec des
paramètres de sécurité de
mot de passe non sécurisés.

virtuelles Windows Server déployer les exigences de
sur lesquelles la console série stratégie et d’auditer les
Windows n’est pas activée machines virtuelles Windows
Server sur lesquelles la
console série Windows n’est
pas activée. Pour plus
stratégies Guest

virtuelles Windows dans déployer les exigences de
lesquelles le groupe stratégie et d’auditer les
Administrateurs contient un machines virtuelles Windows
membre spécifié dans lesquelles le groupe
Administrateurs contient l’un
des membres spécifiés. Pour
plus d’informations sur les
stratégies Guest

Administrateurs ne contient machines virtuelles Windows
pas tous les membres dans lesquelles le groupe
spécifiés Administrateurs ne contient
pas tous les membres
stratégies Guest

Administrateurs ne contient machines virtuelles Windows
pas seulement les membres dans lesquelles le groupe
spécifiés Administrateurs ne contient
pas uniquement les
membres spécifiés. Pour plus
stratégies Guest

virtuelles Windows sur déployer les exigences de
lesquelles la configuration stratégie et d’auditer les
DSC n’est pas conforme machines virtuelles Windows
sur lesquelles la
configuration DSC (Desired
State Configuration) n’est
pas conforme. Cette
uniquement aux machines
dotées de WMF 4 et
versions ultérieures. Pour
stratégies Guest

lesquelles l’agent Log stratégie et d’auditer les
Analytics n’est pas connecté machines virtuelles Windows
comme prévu sur lesquelles l’agent Log
Analytics n’est pas connecté
aux espaces de travail
stratégies Guest

lesquelles l’état de connexion stratégie et d’auditer les
de l’hôte distant ne machines virtuelles Windows
correspond pas à celui sur lesquelles l’état de
spécifié connexion de l’hôte distant
ne correspond pas à celui
stratégies Guest

lesquelles les services stratégie et d’auditer les
spécifiés ne sont pas installés machines virtuelles Windows
ni « En cours d’exécution » sur lesquelles les services
spécifiés ne sont pas installés
ni « En cours d’exécution ».

lesquelles Windows stratégie et d’auditer les
Defender Exploit Guard n’est machines virtuelles Windows
pas activé sur lesquelles Windows
Defender Exploit Guard n’est
pas activé. Pour plus
stratégies Guest

virtuelles Windows qui ne déployer les exigences de
sont pas jointes au domaine stratégie et d’auditer les
spécifié machines virtuelles Windows
qui ne sont pas jointes au
domaine spécifié. Pour plus
stratégies Guest

sont pas définies dans le stratégie et d’auditer les
fuseau horaire spécifié machines virtuelles Windows
qui ne sont pas définies dans
le fuseau horaire spécifié.

virtuelles Windows qui déployer les exigences de
contiennent des certificats stratégie et d’auditer les
arrivant à expiration dans le machines virtuelles Windows
nombre spécifié de jours qui contiennent des
certificats arrivant à
expiration dans le nombre
de jours spécifié. Pour plus
stratégies Guest

contiennent pas les stratégie et d’auditer les
certificats spécifiés dans la machines virtuelles Windows
racine de confiance qui ne contiennent pas les
certificats spécifiés dans le
magasin de certificats des
autorités de certification
racines de confiance
(Cert:\LocalMachine\Root).

virtuelles Windows qui n’ont déployer les exigences de
pas les applications stratégie et d’auditer les
spécifiées installées machines virtuelles Windows
sur lesquelles les applications
spécifiées ne sont pas
stratégies Guest

pas la stratégie d’exécution stratégie et d’auditer les
Windows PowerShell machines virtuelles Windows
spécifiée où Windows PowerShell
n’est pas configuré pour
utiliser la stratégie
d’exécution PowerShell
spécifiée. Pour plus
stratégies Guest

pas les modules Windows stratégie et d’auditer les
PowerShell spécifiés installés machines virtuelles Windows
sur lesquelles les modules
Windows PowerShell
spécifiés ne sont pas
installés. Pour plus
stratégies Guest

correspondent pas aux stratégie et d’auditer les
paramètres de la base de machines virtuelles Windows
référence de sécurité Azure dont les configurations de
base de référence de sécurité
Azure ne sont pas
conformes. Pour plus
stratégies Guest

pas redémarré dans le stratégie et d’auditer les
nombre spécifié de jours machines virtuelles Windows
qui n’ont pas redémarré
dans le nombre de jours
stratégies Guest

virtuelles Windows qui ont déployer les exigences de
les applications spécifiées stratégie et d’auditer les
installées machines virtuelles Windows
sur lesquelles les applications
spécifiées sont installées.

virtuelles Windows avec un déployer les exigences de
redémarrage en attente stratégie et d’auditer les
machines virtuelles Windows
avec un redémarrage en
attente. Pour plus
stratégies Guest
Auditer les serveurs web Cette initiative permet de 2 1.0.0

Windows qui n’utilisent pas déployer les exigences de
de protocole de stratégie et d’auditer les
communication sécurisé serveurs web Windows qui
n’utilisent pas de protocoles
de communication sécurisée
(TLS 1.1 ou TLS 1.2). Pour
stratégies Guest
Surveillance
Activer Azure Monitor pour Activez Azure Monitor pour 6 1.0.0-preview

les groupes de machines les groupes de machines
virtuelles identiques virtuelles identiques dans
l’étendue spécifiée (groupe
d’administration,
abonnement ou groupe de
ressources). Utilise l’espace
de travail Log Analytics
comme paramètre.
Remarque : Si la valeur
upgradePolicy du groupe
identique est définie sur
Manuel, vous devez
toutes les machines
virtuelles du groupe en
appelant une mise à niveau.
Dans l’interface de ligne de
commande, cela se traduirait
par az vmss update-
instances.
Activer Azure Monitor pour Activez Azure Monitor pour 6 1.0.0-preview

machines virtuelles machines virtuelles dans
l’étendue spécifiée (groupe
d’administration,
abonnement ou groupe de
ressources). Utilise l’espace
de travail Log Analytics
comme paramètre.
Conformité réglementaire
[Préversion] : Auditer les Cette initiative inclut des 67 2.0.0-preview

contrôles Canada Federal stratégies d’audit et de
PBMM et déployer des déploiement d’extension de
extensions de machine machine virtuelle répondant
virtuelle spécifiques pour à une partie des contrôles
prendre en charge les Canada Federal PBMM. Des
exigences d’audit stratégies supplémentaires
seront ajoutées dans les
prochaines versions. Pour
plus d’informations, visitez
https://aka.ms/canadafederal
PBMM-blueprint

recommandations de CIS stratégies d’audit et de
Microsoft Azure Foundations déploiement d’extension de
Benchmark 1.1.0 et déployer machine virtuelle répondant
des extensions de machine à une partie des
virtuelle de prise en charge recommandations de CIS
spécifiques Microsoft Azure Foundations
Benchmark. Des stratégies
supplémentaires seront
ajoutées dans les prochaines
versions. Pour plus
d’informations, visitez
https://aka.ms/cisazure-
blueprint.

contrôles FedRAMP stratégies d’audit et de
Moderate et déployer des déploiement d’extension de
prendre en charge les FedRAMP M. Des stratégies
exigences d’audit supplémentaires seront
versions. Pour plus
https://aka.ms/fedrampm-
blueprint.

contrôles IRS1075 stratégies d’audit et de
(septembre 2016) et déploiement d’extension de
déployer des extensions de machine virtuelle répondant
machine virtuelle spécifiques à une partie des contrôles
pour prendre en charge les IRS1075 (septembre 2016).
exigences d’audit Des stratégies
versions. Pour plus
https://aka.ms/irs1075-
blueprint.

contrôles ISO 27001:2013 et stratégies d’audit et de
déployer des extensions de déploiement d’extension de
machine virtuelle spécifiques machine virtuelle répondant
pour prendre en charge les à une partie des contrôles
exigences d’audit ISO 27001:2013. Des
stratégies supplémentaires
https://aka.ms/iso27001-
blueprint.

contrôles NIST SP 800-53 R4 stratégies d’audit et de
et déployer des extensions déploiement d’extension de
de machine virtuelle machine virtuelle répondant
spécifiques pour prendre en à un sous-ensemble de
charge les exigences d’audit contrôles NIST SP 800-53
R4. Des stratégies
versions. Pour plus
https://aka.ms/nist80053-
blueprint.
[Préversion] : Auditer les Cette initiative comprend 39 1.0.0-preview

contrôles PCI v3.2.1:2018 v3 des stratégies d’audit et de
et déployer des extensions déploiement d’extension de
de machine virtuelle machine virtuelle répondant
spécifiques pour prendre en à un sous-ensemble de
charge les exigences d’audit contrôles PCI v3.2.1:2018.
Des stratégies
versions. Pour plus
https://aka.ms/pciv321-init.

contrôles SWIFT CSP-CSCF stratégies d’audit et de
v2020 et déployer des déploiement d’extension de
prendre en charge les SWIFT CSP-CSCF v2020. Des
exigences d’audit stratégies supplémentaires
https://aka.ms/SWIFT-
blueprint.
[Préversion] : Auditer les Cette initiative comprend 66 2.0.0-preview

contrôles UK OFFICIAL et des stratégies répondant à
UK NHS, et déployer des un sous-ensemble de
extensions de machine contrôles UK OFFICIAL et
virtuelle spécifiques pour UK NHS. Des stratégies
prendre en charge les supplémentaires seront
exigences de l’audit ajoutées dans les prochaines
versions. Pour plus
https://aka.ms/ukofficial-
blueprint et
https://aka.ms/uknhs-
blueprint
Auditer les Cette initiative inclut des 148 2.0.0-preview

recommandations d’Azure stratégies d’audit et de
Security Benchmark et déploiement d’extension de
déployer des extensions de machine virtuelle répondant
machine virtuelle de prise en à une partie des
charge spécifiques recommandations d’Azure
Security Benchmark. Des
https://aka.ms/azsecbm.
Auditer les contrôles Cette initiative inclut des 80 2.0.0-preview

FedRAMP High et déployer stratégies d’audit et de
des extensions de machine déploiement d’extension de
virtuelle spécifiques pour machine virtuelle répondant
prendre en charge les à une partie des contrôles
exigences d’audit FedRAMP H. Des stratégies
versions. Pour plus
https://aka.ms/fedramph-
blueprint.
Auditer les contrôles Cette initiative comprend 57 1.0.0

HITRUST/HIPAA et déployer des stratégies répondant à
des extensions de machine une partie des contrôles
virtuelle spécifiques pour HITRUST/HIPAA. Des
prendre en charge les stratégies supplémentaires
exigences d’audit seront ajoutées dans les
prochaines versions.
https://aka.ms/hipaa-
blueprint
Auditer les contrôles de la Cette initiative comprend 45 1.0.0-preview

MPAA (Motion Picture des stratégies répondant à
Association of America) et une partie des contrôles de
déployer des extensions de sécurité et de
machine virtuelle spécifiques recommandations de la
pour prendre en charge les MPAA (Motion Picture
exigences d’audit Association of America). Des
https://aka.ms/mpaa-
blueprint
DoD Impact Level 4 Attribue des stratégies pour 80 2.0.0-preview

répondre aux contrôles
spécifiques DoD IL4 (Impact
Level 4). En savoir plus :
https://aka.ms/DoDIL4-
blueprint.
Security Center
[Préversion] : Activer la suite Activez la protection des 1 1.0.0-preview

de protection des données données pour les serveurs
SQL. Cette initiative est
affectée automatiquement
par le niveau Standard
d’Azure Security Center.
Activer la supervision dans Supervise toutes les 96 2.0.1

Azure Security Center recommandations de
sécurité disponibles dans
Azure Security Center. Il
s’agit de la stratégie par
défaut pour Azure Security
Center.
Étapes suivantes
Une définition de stratégie peut contenir plusieurs instructions conditionnelles. Vous aurez peut-être besoin que
chaque instruction ait la valeur true ou que certaines d’entre elles aient la valeur true. Pour répondre à ces besoins,
le langage comprend des opérateurs logiques not, allOf et anyOf. Ils sont facultatifs et peuvent être imbriqués
pour créer des scénarios complexes.
Exemple 1 : Un opérateur logique

Cette définition de stratégie évalue les comptes CosmosDB pour voir si les basculements automatiques et les
emplacements à plusieurs écritures sont configurés. Si ce n’est pas le cas, l’audit crée une entrée de journal lorsque
la ressource non conforme est créée ou mise à jour.
{
"properties": {
"mode": "all",
"displayName": "Audit Automatic Failover for CosmosDB accounts",
"description": "This policy audits Automatic Failover for CosmosDB accounts",
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.DocumentDB/databaseAccounts"
},
{
"field": "Microsoft.DocumentDB/databaseAccounts/enableAutomaticFailover",
"equals": "false"
},
{
"field": "Microsoft.DocumentDB/databaseAccounts/enableMultipleWriteLocations",
"equals": "false"
}
]
},
"then": {
"effect": "audit"
}
},
"parameters": {},
"metadata": {}
}
}
Exemple 1 : Explication
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.DocumentDB/databaseAccounts"
},
{
"field": "Microsoft.DocumentDB/databaseAccounts/enableAutomaticFailover",
"equals": "false"
},
{
"field": "Microsoft.DocumentDB/databaseAccounts/enableMultipleWriteLocations",
"equals": "false"
}
]
},
"then": {
Le bloc policyRule.if utilise un seul allOf pour garantir que les trois conditions sont true. C’est uniquement
lorsque toutes ces conditions ont la valeur true que l’effet audit est déclenché.
Exemple 2 : Plusieurs opérateurs logiques

Cette définition de stratégie évalue les ressources à la recherche d’un modèle de nommage. Si une ressource ne
correspond pas, elle est refusée.
{
"properties": {
"displayName": "Match multiple name patterns.",
"description": "Allows one of multiple naming patterns for resources.",
"mode": "Indexed",
"policyRule": {
"if": {
"allOf": [{
"not": {
"field": "name",
"match": "contoso??????"
}
},
{
"not": {
"field": "name",
"match": "contoso-???-##"
}
}
]
},
"then": {
"effect": "deny"
}
}
}
}
"if": {
"allOf": [{
"not": {
"field": "name",
"match": "contoso??????"
}
},
{
"not": {
"field": "name",
"match": "contoso-???-##"
}
}
]
},
Ce bloc policyRule.if comprend également un allOf, mais chacune des conditions est wrappée avec l’opérateur
logique not. L’opérateur conditionnel à l’intérieur de l’opérateur logique not est évalué en premier, puis not est
évalué afin de déterminer si la clause entière est true ou false. Si les deux opérateurs logiques not ont la valeur
true, l’effet de stratégie est déclenché.
Étapes suivantes
Passez en revue les autres modèles et définitions intégrées.
L’opérateur field évalue l’alias ou la propriété spécifié(e) par rapport à une valeur fournie pour une condition
donnée.
Exemple de définition de stratégie

Cette définition de stratégie vous permet de définir des régions autorisées qui répondent aux exigences de
géolocalisation de votre organisation. Les ressources autorisées sont définies dans le paramètre
listOfAllowedLocations (array). Les ressources qui correspondent à la définition sont refusées.
{
"properties": {
"policyType": "BuiltIn",
deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups,
Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.",
"mode": "Indexed",
"parameters": {
"listOfAllowedLocations": {
"type": "Array",
"metadata": {
"description": "The list of locations that can be specified when deploying resources.",
}
}
},
"policyRule": {
"if": {
"allOf": [{
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"notEquals": "global"
},
{
"field": "type",
"notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
}
]
},
"then": {
"effect": "Deny"
}
}
}
}
Explication
"if": {
"allOf": [{
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"notEquals": "global"
},
{
"field": "type",
"notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
}
]
},
"then": {
"effect": "Deny"
}
}
L’opérateur field est utilisé trois fois dans l’opérateur logique allOf.
La première utilisation évalue la propriété location avec la condition notIn pour le paramètre
listOfAllowedLocations. notIn fonctionne, car elle attend un tableau (array) et le paramètre en est un. Si le
location de la ressource créée ou mise à jour ne figure pas dans la liste approuvée, cet élément prend la valeur
true.
La deuxième utilisation évalue également la propriété location , mais utilise la condition notEquals pour
vérifier si la ressource est globale. Si le location de la ressource créée ou mise à jour n’est pas global, cet
élément prend la valeur true.
La dernière utilisation évalue la propriété type et utilise la condition notEquals pour valider le fait que le type
de ressource n’est pas Microsoft. AzureActiveDirectory/b2cDirectories. Si ce n’est pas le cas, cet élément prend
la valeur true.
Si les trois instructions de condition de l’opérateur logique allOf sont évaluées à la valeur true, la création ou la
mise à jour de ressource est bloquée par Azure Policy.
Étapes suivantes
Une définition de stratégie peut être rendue dynamique afin de réduire le nombre de définitions de stratégie
nécessaires à l’aide des paramètres. Un paramètre est défini lors de l’attribution de la stratégie. Les paramètres ont
un ensemble de propriétés prédéfinies qui les décrivent, ainsi que la façon dont ils sont utilisés.
Exemple 1 : Paramètre de chaîne

Cette définition de stratégie utilise deux paramètres (tagName et tagValue) pour définir ce que l’attribution de
stratégie doit rechercher dans les ressources. Ce format permet à la stratégie d’être utilisée avec autant de
combinaisons nom-valeur d’étiquette que souhaité. Toutefois, il ne conserve qu’une seule définition de stratégie.
{
"properties": {
"displayName": "Require tag and its value",
"mode": "Indexed",
"description": "Enforces a required tag and its value. Does not apply to resource groups.",
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"description": "Name of the tag, such as costCenter"
}
},
"tagValue": {
"type": "String",
"metadata": {
"description": "Value of the tag, such as headquarter"
}
}
},
"policyRule": {
"if": {
"not": {
"field": "[concat('tags[', parameters('tagName'), ']')]",
"equals": "[parameters('tagValue')]"
}
},
"then": {
"effect": "deny"
}
}
}
}
"tagName": {
"type": "String",
"metadata": {
"description": "Name of the tag, such as costCenter"
}
},
Dans cette partie de la définition de stratégie, le paramètre tagName est défini en tant que chaîne et une
description est fournie pour son utilisation.
Le paramètre est ensuite utilisé dans le bloc policyRule.if pour rendre la stratégie dynamique. Ici, il est utilisé
pour définir le champ évalué, qui correspond à une étiquette ayant la valeur tagName.
"if": {
"not": {
"equals": "[parameters('tagValue')]"
}
},
Exemple 2 : Paramètres de tableau

Cette définition de stratégie utilise un seul paramètre (listOfBandwidthinMbps) pour vérifier si la ressource de
circuit ExpressRoute a configuré le paramètre de bande passante sur l’une des valeurs approuvées. Si ce n’est pas
le cas, la création ou la mise à jour de la ressource est refusée.
{
"properties": {
"displayName": "Allowed Express Route bandwidth",
"description": "This policy enables you to specify a set of express route bandwidths that your
organization can deploy.",
"parameters": {
"listOfBandwidthinMbps": {
"type": "Array",
"metadata": {
"description": "The list of SKUs that can be specified for express route.",
"displayName": "Allowed Bandwidth"
}
}
},
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Network/expressRouteCircuits"
},
{
"not": {
"field": "Microsoft.Network/expressRouteCircuits/serviceProvider.bandwidthInMbps",
"in": "[parameters('listOfBandwidthinMbps')]"
}
}
]
},
"then": {
"effect": "Deny"
}
}
}
}
"listOfBandwidthinMbps": {
"type": "Array",
"metadata": {
"description": "The list of SKUs that can be specified for express route.",
"displayName": "Allowed Bandwidth"
}
}
Dans cette partie de la définition de stratégie, le paramètre listOfBandwidthinMbps est défini en tant que
tableau et une description est fournie pour son utilisation. En tant que tableau, il comprend plusieurs valeurs à
rechercher.
Le paramètre est ensuite utilisé dans le bloc policyRule.if. En tant que paramètre de tableau, le in ou le notIn de
la condition d’un tableau doivent être utilisés. Ici, il est utilisé sur l’alias serviceProvider.bandwidthInMbps
comme l’une des valeurs définies.
"not": {
"field": "Microsoft.Network/expressRouteCircuits/serviceProvider.bandwidthInMbps",
"in": "[parameters('listOfBandwidthinMbps')]"
}
Étapes suivantes
Azure Policy a un certain nombre d’effets qui déterminent la façon dont le service réagit aux ressources non
conformes. Certains effets sont simples et ne nécessitent aucune propriété supplémentaire dans la définition de
stratégie, tandis que d’autres nécessitent plusieurs propriétés.
Exemple 1 : Effet simple

Cette définition de stratégie vérifie si l’étiquette définie dans le paramètre tagName existe sur la ressource
évaluée. Si l’étiquette n’existe pas encore, l’effetmodify est déclenché afin d’ajouter l’étiquette avec la valeur
spécifiée dans le paramètre tagValue.
{
"properties": {
"displayName": "Add a tag to resource groups",
"mode": "All",
"description": "Adds the specified tag and value when any resource group missing this tag is created or
updated. Existing resource groups can be remediated by triggering a remediation task. If the tag exists with a
different value it will not be changed.",
"metadata": {
"version": "1.0.0",
"category": "Tags"
},
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'environment'"
}
},
"tagValue": {
"type": "String",
"metadata": {
"displayName": "Tag Value",
"description": "Value of the tag, such as 'production'"
}
}
},
"policyRule": {
"if": {
"allOf": [{
"field": "type",
},
{
"exists": "false"
}
]
},
"then": {
"effect": "modify",
"details": {
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
20f7382dd24c"
],
"operations": [{
"operation": "add",
"value": "[parameters('tagValue')]"
}]
}
}
}
}
}
"field": "type",
},
{
Un effet modify exige le bloc policyRule.then.details qui définit roleDefinitionIds et operations. Ces
paramètres indiquent à Azure Policy quels rôles sont nécessaires pour ajouter l’étiquette et corriger la ressource, et
quelle opération modify effectuer. Dans cet exemple, operation est add, et les paramètres servent à définir
l’étiquette et sa valeur.
Exemple 2 : Effet complexe

Cette définition de stratégie audite chaque machine virtuelle afin de vérifier si une extension, définie dans les
paramètres publisher et type, n’existe pas. Elle utilise auditIfNotExists pour vérifier une ressource associée à la
machine virtuelle afin de déterminer s’il existe une instance qui correspond aux paramètres définis. Cet exemple
vérifie le type extensions.
{
"type": "Microsoft.Authorization/policyDefinitions",
"name": "audit-vm-extension",
"properties": {
"displayName": "Audit if extension does not exist",
"description": "This policy audits if a required extension doesn't exist.",
"parameters": {
"publisher": {
"type": "String",
"metadata": {
"description": "The publisher of the extension",
"displayName": "Extension Publisher"
}
},
"type": {
"type": "String",
"metadata": {
"description": "The type of the extension",
"displayName": "Extension Type"
}
}
},
"policyRule": {
"if": {
"allOf": [{
"field": "type",
},
{
"field": "Microsoft.Compute/imagePublisher",
"in": [
"MicrosoftWindowsServer"
]
},
{
"field": "Microsoft.Compute/imageOffer",
"in": [
"WindowsServer"
]
}
]
},
"then": {
"effect": "auditIfNotExists",
"details": {
"type": "Microsoft.Compute/virtualMachines/extensions",
"existenceCondition": {
"allOf": [{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "[parameters('publisher')]"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/type",
"equals": "[parameters('type')]"
}
]
}
}
}
}
}
}
"details": {
"allOf": [{
"equals": "[parameters('publisher')]"
},
{
"equals": "[parameters('type')]"
}
]
}
}
Un effet auditIfNotExists exige le bloc policyRule.then.details pour définir à la fois un type et

l’existenceCondition à rechercher. L’existenceCondition utilise des éléments de langage de stratégie, tels que
des opérateurs logiques, pour déterminer s’il existe une ressource associée correspondante. Dans cet exemple, les
valeurs vérifiées par rapport à chaque alias sont définies dans les paramètres.
Étapes suivantes
L’opérateur value évalue des paramètres, des fonctions de modèle prises en charge ou des littéraux par rapport à
une valeur fournie pour une condition donnée.
WARNING
Si le résultat d’une fonction de modèle est une erreur, la stratégie d’évaluation échoue. Une évaluation ayant échoué
correspond à un refus implicite. Pour plus d’informations, consultez Éviter les défaillances des modèles.

Cette définition de stratégie ajoute ou remplace l’étiquette spécifiée dans le paramètre tagName (string) sur des
ressources, et hérite de la valeur de tagName à partir du groupe de ressources dans lequel se trouve la ressource.
Cette évaluation se produit quand la ressource est créée ou mise à jour. En tant qu’effet modify, la correction peut
être exécutée sur des ressources existantes par le biais d’une tâche de correction.
{
"properties": {
"displayName": "Inherit a tag from the resource group",
"mode": "Indexed",
"description": "Adds or replaces the specified tag and value from the parent resource group when any
resource is created or updated. Existing resources can be remediated by triggering a remediation task.",
"metadata": {
"category": "Tags"
},
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'environment'"
}
}
},
"policyRule": {
"if": {
"allOf": [{
"notEquals": "[resourceGroup().tags[parameters('tagName')]]"
},
{
"value": "[resourceGroup().tags[parameters('tagName')]]",
"notEquals": ""
}
]
},
"then": {
"effect": "modify",
"details": {
20f7382dd24c"
],
"operations": [{
"value": "[resourceGroup().tags[parameters('tagName')]]"
}]
}
}
}
}
}
Explication
"if": {
"allOf": [{
"notEquals": "[resourceGroup().tags[parameters('tagName')]]"
},
{
"value": "[resourceGroup().tags[parameters('tagName')]]",
"notEquals": ""
}
]
},
L’opérateur value est utilisé dans le bloc policyRule.if dans properties. Dans cet exemple, l’opérateur logique
allOf est utilisé pour indiquer que les deux instructions conditionnelles doivent avoir la valeur true pour que l’effet,
modify, ait lieu.
value évalue le résultat de la fonction de modèle resourceGroup() à la condition notEquals d’une valeur vide. Si le
nom d’étiquette fourni dans tagName sur le groupe de ressources parent existe, la condition est évaluée à true.
Étapes suivantes
L’opérateur count évalue les membres d’un alias [*].

Cette définition de stratégie audite des groupes de sécurité réseau configurés pour autoriser le trafic entrant du
protocole RDP (Remote Desktop Protocol).
{
"properties": {
"mode": "all",
"displayName": "Audit Network Security Groups for RDP",
"description": "This policy audits NSGs with RDP ports enabled",
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Network/networkSecurityGroups"
},
{
"count": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*]",
"where": {
"allOf": [{
"field":
"Microsoft.Network/networkSecurityGroups/securityRules[*].direction",
"equals": "Inbound"
},
{
"field":
"Microsoft.Network/networkSecurityGroups/securityRules[*].access",
"equals": "Allow"
},
{
"field":
"Microsoft.Network/networkSecurityGroups/securityRules[*].destinationPortRange",
"equals": "3389"
}
]
}
},
"greater": 0
}
]
},
"then": {
"effect": "audit"
}
}
}
}
Explication
Les principaux composants de l’opérateur count sont field, where et la condition. Chacun est mis en surbrillance
dans l’extrait de code ci-dessous.
field indique à count de quel alias il faut évaluer les membres. Ici, nous examinons l’alias securityRules[*]
array du groupe de sécurité réseau.
where utilise le langage de stratégie pour définir quels membres d’array remplissent les critères. Dans cet
exemple, un opérateur logique allOf regroupe trois évaluations de condition différentes de propriétés d’alias
array : direction, access et destinationPortRange.
La condition count dans cet exemple est greater. Count prend la valeur true quand un ou plusieurs membres
de l’alias array correspondent à la clause where.
{
"count": {
"where": {
"allOf": [{
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].direction",
"equals": "Inbound"
},
{
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].access",
"equals": "Allow"
},
{
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].destinationPortRange",
"equals": "3389"
}
]
}
},
"greater": 0
}
Étapes suivantes
Une initiative est un groupe de définitions de stratégie. En groupant des définitions de stratégie associées dans un
objet unique, vous pouvez créer une seule affectation au lieu de plusieurs.
Exemple de définition d’initiative

Cette initiative déploie deux définitions de stratégie, chacune prenant les paramètres tagName et tagValue.
L’initiative elle-même a deux paramètres : costCenterValue et productNameValue. Ces paramètres d’initiative
sont fournis à chacune des définitions de stratégie groupées. Cette conception optimise la réutilisation des
définitions de stratégie existantes tout en limitant le nombre d’affectations créées pour les implémenter en fonction
des besoins.
{
"properties": {
"displayName": "Billing Tags Policy Initiative",
"description": "Specify cost Center tag and product name tag",
"parameters": {
"costCenterValue": {
"type": "String",
"metadata": {
"displayName": "required value for Cost Center tag"
}
},
"productNameValue": {
"type": "String",
"metadata": {
"displayName": "required value for product Name tag"
}
}
},
"policyDefinitions": [{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-
a204-c1c3969c6d62",
"parameters": {
"tagName": {
"value": "costCenter"
},
"tagValue": {
"value": "[parameters('costCenterValue')]"
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-
991a-187a4f81c498",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-
a204-c1c3969c6d62",
"parameters": {
"tagName": {
"value": "productName"
},
"tagValue": {
"value": "[parameters('productNameValue')]"
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-
991a-187a4f81c498",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
}
]
}
}
Explication
Paramètres d’initiative
Une initiative peut définir ses propres paramètres, qui sont ensuite transmis aux définitions de stratégie groupées.
Dans cet exemple, costCenterValue et productNameValue sont définis en tant que paramètres d’initiative. Les
valeurs sont fournies quand l’initiative est affectée.
"parameters": {
"type": "String",
"metadata": {
"displayName": "required value for Cost Center tag"
}
},
"type": "String",
"metadata": {
"displayName": "required value for product Name tag"
}
}
},
Définitions de stratégie incluses

Chaque définition de stratégie incluse doit fournir le policyDefinitionId et un tableau parameters si la définition
de stratégie accepte des paramètres. Dans l’extrait de code ci-dessous, la définition de stratégie incluse accepte
deux paramètres : tagName et tagValue. tagName est défini avec un littéral, mais tagValue utilise le paramètre
costCenterValue défini par l’initiative. Ce relais de valeurs améliore la réutilisation.
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-
187a4f81c498",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
},
Étapes suivantes
L’effet deployIfNotExists permet de déployer un modèle Azure Resource Manager lors de la création ou de la mise
à jour d’une ressource qui n’est pas conforme. Cette approche peut être préférable à l’utilisation de l’effet deny, car
elle permet de continuer à créer des ressources tout en garantissant que les modifications nécessaires sont
apportées afin de les rendre conformes.

Cette définition de stratégie utilise l’opérateur field pour évaluer le type de la ressource créée ou mise à jour.
Quand cette ressource est un Microsoft.Network/virtualNetworks, la stratégie recherche un observateur réseau à
l’emplacement de la ressource nouvelle ou mise à jour. Si aucun observateur réseau correspondant n’est trouvé, le
modèle Resource Manager est déployé pour créer la ressource manquante.
{
"properties": {
"displayName": "Deploy network watcher when virtual networks are created",
"mode": "Indexed",
"description": "This policy creates a network watcher resource in regions with virtual networks. You
need to ensure existence of a resource group named networkWatcherRG, which will be used to deploy network
watcher instances.",
"metadata": {
"category": "Network"
},
"parameters": {},
"policyRule": {
"if": {
"field": "type",
"equals": "Microsoft.Network/virtualNetworks"
},
"then": {
"effect": "DeployIfNotExists",
"details": {
"type": "Microsoft.Network/networkWatchers",
"resourceGroupName": "networkWatcherRG",
"equals": "[field('location')]"
},
"/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-
c67834d212e7"
],
"deployment": {
"properties": {
"mode": "incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json",
"parameters": {
"location": {
"type": "string"
}
},
"resources": [{
"apiVersion": "2016-09-01",
"name": "[concat('networkWacher_', parameters('location'))]",
"location": "[parameters('location')]"
}]
},
"parameters": {
"location": {
"value": "[field('location')]"
}
}
}
}
}
}
}
}
}
Explication
existenceCondition
"resourceGroupName": "networkWatcherRG",
"equals": "[field('location')]"
},
Le bloc properties.policyRule.then.details indique à Azure Policy ce qu’il faut rechercher en rapport avec la
ressource créée ou mise à jour dans le bloc properties.policyRule.if. Dans cet exemple, un observateur réseau
dans le groupe de ressources networkWatcherRG doit exister avec field location égal à l’emplacement de la
ressource nouvelle ou mise à jour. L’utilisation de la fonction field() permet à l’existenceCondition d’accéder
aux propriétés de la ressource nouvelle ou mise à jour, en particulier à la propriété location .
roleDefinitionIds
"/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
],
La propriété array roleDefinitionIds dans le bloc properties.policyRule.then.details indique à la définition de

stratégie les droits dont l’identité managée a besoin pour déployer le modèle Resource Manager inclus. Cette
propriété doit être définie pour inclure des rôles disposant des autorisations nécessaires au déploiement de
modèle, mais doit utiliser le concept de « principe des privilèges minimum » et n’avoir accès qu’aux opérations
nécessaires, et rien de plus.
Modèle de déploiement
La partie deployment de la définition de stratégie a un bloc de properties qui définit les trois composants
principaux :
mode : cette propriété définit le mode de déploiement du modèle.
template : cette propriété inclut le modèle lui-même. Dans cet exemple, le paramètre de modèle location
définit l’emplacement de la nouvelle ressource d’observateur réseau.
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
"parameters": {
"location": {
"type": "string"
}
},
"resources": [{
"apiVersion": "2016-09-01",
"name": "[concat('networkWacher_', parameters('location'))]",
"location": "[parameters('location')]"
}]
},
parameters : cette propriété définit les paramètres qui sont fournis au template. Les noms des paramètres
doivent correspondre à ce qui est défini dans template. Dans cet exemple, le paramètre se nomme
location afin qu’il y ait correspondance. La valeur de location utilise de nouveau la fonction field() pour
récupérer la valeur de la ressource évaluée, qui est le réseau virtuel dans le bloc policyRule.if.
"parameters": {
"location": {
"value": "[field('location')]"
}
}
Étapes suivantes
Azure Policy établit des conventions pour les ressources. Les définitions de stratégie décrivent les
conditions de la conformité des ressources et l’effet à exécuter si une condition est remplie. Une
condition compare un champ de propriété de ressource à une valeur requise. Les champs de propriétés
de ressources sont accessibles à l’aide d’alias. Un champ de propriété de ressource est un champ à
valeur unique ou un tableau de plusieurs valeurs. L’évaluation de la condition est différente sur les
tableaux. Apprenez-en davantage sur les conditions.
En définissant des conventions, vous pouvez contrôler les coûts et gérer plus facilement vos ressources.
Par exemple, vous pouvez spécifier que seuls certains types de machines virtuelles sont autorisés. Vous
pouvez aussi exiger que toutes les ressources soient marquées. Toutes les ressources enfants héritent
des stratégies. Une stratégie appliquée à un groupe de ressources s’applique à toutes les ressources
appartenant à ce groupe de ressources.
Le schéma de la définition de stratégie se trouve ici :
https://schema.management.azure.com/schemas/2019-06-01/policyDefinition.json
Vous devez utiliser JSON pour créer une définition de stratégie. La définition de stratégie contient des
éléments pour :
mode
parameters
le nom d’affichage
description
la règle de stratégie
évaluation logique
effet
Par exemple, le code JSON suivant illustre une stratégie qui limite les emplacements où les ressources
sont déployées :
{
"properties": {
"mode": "all",
"parameters": {
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying
resources",
},
"defaultValue": [ "westus2" ]
}
},
"description": "This policy enables you to restrict the locations your organization can
specify when deploying resources.",
"policyRule": {
"if": {
"not": {
}
},
"then": {
"effect": "deny"
}
}
}
}
Tous les exemples Azure Policy se trouvent dans Exemples de stratégies.
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 stratégie. Les modes pris en charge sont
les suivants :
all : évaluer les groupes de ressources 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 tous les 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 font figure d’exception. Les stratégies qui appliquent des emplacements ou des
balises à un groupe de ressources doivent définir mode sur all et cibler spécifiquement le type
Microsoft.Resources/subscriptions/resourceGroups . Pour exemple, consultez Appliquer des balises au
groupe de ressources. 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 (préversion)
Les modes Fournisseur de ressources suivants sont actuellement pris en charge pendant la préversion :
Microsoft.ContainerService.Data pour la gestion des règles d’admission de contrôleur sur Azure
Kubernetes Service. Les stratégies utilisant ce mode Fournisseur de ressources doivent utiliser
l’effet EnforceRegoPolicy.
Microsoft.Kubernetes.Data pour la gestion des clusters Kubernetes du moteur AKS auto-managés
sur Azure. Les stratégies utilisant ce mode Fournisseur de ressources doivent utiliser l’effet
EnforceOPAConstraint.
Microsoft.KeyVault.Data pour la gestion des coffres et des certificats dans Azure Key Vault.
NOTE
Les modes Fournisseur de ressources prennent uniquement en charge les définitions de stratégie intégrées et ne
prennent pas en charge les initiatives en préversion.
Paramètres
Les paramètres permettent de simplifier la gestion des stratégies en réduisant le nombre de définitions
de stratégies. Considérez les paramètres comme les champs d’un formulaire : name , address , city ,
state . Ces paramètres restent toujours les mêmes ; toutefois, leurs valeurs changent en fonction de la
personne qui remplit le formulaire. Les paramètres fonctionnent de manière identique durant la
création de stratégies. En incluant des paramètres dans une définition de stratégie, vous pouvez
réutiliser cette stratégie pour différents scénarios avec des valeurs différentes.
NOTE
Des paramètres peuvent être ajoutés à une définition existante et attribuée. Le nouveau paramètre doit inclure la
propriété defaultValue. Cela empêche les affectations de stratégie ou d’initiative déjà existantes d’être
indirectement invalidées.
Propriétés du paramètre
Un paramètre possède les propriétés suivantes qui sont utilisées dans la définition de la stratégie :
nom : Nom de votre paramètre. Utilisé par la fonction de déploiement parameters dans le cadre de
la règle de stratégie. Pour plus d’informations, consultez Utilisation d’une valeur de paramètre.
type : Détermine si le paramètre est une chaîne, un tableau, un objet, booléen, entier, flottant,
ou DateHeure.
metadata : Définit les sous-propriétés utilisées principalement par le portail Azure pour afficher des
informations conviviales :
description : Explication du rôle du paramètre. Utilisable pour fournir des exemples de
valeurs acceptables.
displayName : Nom convivial du paramètre visible dans le portail.
version : (Facultatif) Effectue le suivi des détails sur la version du contenu d’une définition
de stratégie.
NOTE
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.
category : (Facultatif) Détermine dans quelle catégorie du portail Azure la définition de

stratégie s’affiche.
strongType : (Facultatif) Utilisé lors de l’affectation de la définition de stratégie via le
portail. Fournit une liste prenant en compte le contexte. Pour plus d’informations, voir
strongType.
assignPermissions : (Facultatif) Définissez l’option sur True pour que le portail Azure crée
des attributions de rôles lors de l’attribution de stratégie. Cette propriété est utile si vous
souhaitez attribuer des autorisations en dehors de l’étendue d’attribution. Il existe une
attribution de rôle par définition de rôle dans la stratégie (ou par définition de rôle dans
toutes les stratégies dans l’initiative). La valeur du paramètre doit être une ressource ou
une étendue valide.
defaultValue : (Facultatif) Définit la valeur du paramètre dans une affectation si aucune valeur n’est
fournie. Obligatoire lors de la mise à jour d’une définition de stratégie existante qui est affectée.
allowedValues : ( Facultatif) Fournit le tableau des valeurs que le paramètre accepte pendant
l’attribution.
Par exemple, vous pouvez définir une définition de stratégie qui limite les emplacements sur lesquels les
ressources peuvent être déployées. Le paramètre allowedLocations pourrait s’appliquer à cette
définition de stratégie. Ce paramètre serait utilisé par chaque affectation de la définition de la stratégie
pour limiter les valeurs acceptées. L’utilisation de strongType permet d’améliorer l’expérience lors de
l’affectation via le portail :
"parameters": {
"type": "array",
"metadata": {
"description": "The list of allowed locations for resources.",
"strongType": "location"
},
"defaultValue": [ "westus2" ],
"allowedValues": [
"eastus2",
"westus2",
"westus"
]
}
}
Utiliser une valeur de paramètre

Dans la règle de stratégie, vous référencez des paramètres avec la syntaxe de fonction parameters
suivante :
{
}
Cet exemple fait référence au paramètre allowedLocations autorisé qui a été démontré dans les
propriétés du paramètre.
strongType
Dans la propriété metadata , vous pouvez utiliser strongType pour fournir une liste à choix multiple des
options dans le portail Azure. Les valeurs autorisées pour strongType incluent actuellement :
location
resourceTypes
storageSkus
vmSKUs
existingResourceGroups
omsWorkspace
Microsoft.EventHub/Namespaces/EventHubs
Microsoft.EventHub/Namespaces/EventHubs/AuthorizationRules
Microsoft.EventHub/Namespaces/AuthorizationRules
Microsoft.RecoveryServices/vaults
Microsoft.RecoveryServices/vaults/backupPolicies
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 assignées à la
stratégie.
Groupe d’administration : seules les ressources au sein des groupes d’administration enfants et
des abonnements enfants peuvent être assignées à la stratégie. Si vous voulez appliquer la définition
de stratégie à plusieurs abonnements, l’emplacement doit correspondre à un groupe
d’administration comportant ces abonnements.
Nom d’affichage et description

displayName et description permettent de distinguer la définition de stratégie et de préciser son
contexte d’utilisation. displayName a une longueur maximale de 128 caractères et description a une
longueur maximale de 512 caractères.
NOTE
Lors de la création ou de la mise à jour d’une définition de stratégie, id, type et name sont définis par des
propriétés externes non comprises dans le code JSON et qui ne sont pas nécessaires au fichier JSON. La
récupération de la définition de stratégie via le SDK permet de retourner les propriétés id, type et name dans le
code JSON, mais chacune d’elles correspond à des informations en lecture seule qui sont relatives à la définition
de stratégie.
Règle de stratégie
La règle de stratégie se compose de blocs if et then. Dans le bloc if, vous définissez une ou plusieurs
conditions qui spécifient à quel moment la stratégie est mise en œuvre. Vous pouvez appliquer des
opérateurs logiques à ces conditions pour définir avec précision le scénario d’une stratégie.
Dans le bloc then, vous définissez l’effet qui se produit lorsque les conditions de si sont remplies.
{
"if": {
<condition> | <logical operator>
},
"then": {
"effect": "deny | audit | append | auditIfNotExists | deployIfNotExists | disabled"
}
}
Les opérateurs logiques pris en charge sont les suivants :
"not": {condition or operator}
"allOf": [{condition or operator},{condition or operator}]
"anyOf": [{condition or operator},{condition or operator}]
La syntaxe not inverse le résultat de la condition. La syntaxe allOf (semblable à l’opération logique
And) nécessite que toutes les conditions soient remplies. La syntaxe anyOf (semblable à l’opération
logique Of) nécessite qu’au moins une des conditions soit remplie.
Vous pouvez imbriquer des opérateurs logiques. L’exemple suivant illustre une opération not
imbriquée dans une opération allOf.
"if": {
"allOf": [{
"not": {
"field": "tags",
"containsKey": "application"
}
},
{
"field": "type",
}
]
},
Conditions
Une condition évalue si un champ ou un accesseur de valeur répond à certains critères. Les conditions
prises en charge sont les suivantes :
"equals": "stringValue"
"notEquals": "stringValue"
"like": "stringValue"
"notLike": "stringValue"
"match": "stringValue"
"matchInsensitively": "stringValue"
"notMatch": "stringValue"
"notMatchInsensitively": "stringValue"
"contains": "stringValue"
"notContains": "stringValue"
"in": ["stringValue1","stringValue2"]
"notIn": ["stringValue1","stringValue2"]
"containsKey": "keyName"
"notContainsKey": "keyName"
"less": "value"
"lessOrEquals": "value"
"greater": "value"
"greaterOrEquals": "value"
"exists": "bool"
Avec les conditions like et notLike, un caractère générique * est indiqué dans la valeur. Celle-ci ne
doit pas en comporter plus d’un ( * ).
Si vous utilisez les conditions match et notMatch, entrez # pour trouver un chiffre, ? pour une
lettre, . pour un caractère et tout autre caractère pour représenter ce caractère réel. match et
notMatch sont sensibles à la casse. Cependant, toutes les autres conditions qui évaluent une
stringValue ne sont pas sensibles à la casse. Des alternatives non sensibles à la casse sont disponibles
dans matchInsensitively et notMatchInsensitively.
Dans une valeur de champ de tableau à alias [*] , chaque élément du tableau est évalué
individuellement avec un opérateur logique and entre les éléments. Pour plus d’informations, consultez
Évaluation de l’alias [*].
Champs
Les conditions sont formées à partir de champs. Un champ correspond à des propriétés de la charge
utile de la demande de ressource et décrit l’état de la ressource.
Les champs suivants sont pris en charge :
name
fullName
Retourne le nom complet de la ressource, soit le nom de la ressource précédé du nom de
toutes les ressources parentes (par exemple, « monServeur/maBaseDeDonnées »).
kind
type
location
Utilisez global pour les ressources indépendantes de l’emplacement.
identity.type
Renvoie le type d'identité managée activé sur la ressource.
tags
tags['<tagName>']
Cette syntaxe en crochet prend en charge les noms de balise contenant des signes de
ponctuation tels qu’un trait d’union, un point ou un espace.
Où <tagName> est le nom de l’étiquette pour laquelle vérifier la condition.
Exemples : tags['Acct.CostCenter'] où Acct.CostCenter est le nom de l’étiquette.
tags['''<tagName>''']
Cette syntaxe en crochet prend en charge les noms de balise contenant des apostrophes en
appliquant une séquence d’échappement entre apostrophes doubles.
Où '<tagName>' est le nom de l’étiquette pour laquelle vérifier la condition.
Exemple : tags['''My.Apostrophe.Tag'''] où 'My.Apostrophe.Tag est le nom de la balise.
alias de propriété : pour en obtenir la liste, consultez Alias.
NOTE
tags.<tagName> , tags[tagName] et tags[tag.with.dots] sont toujours des manières acceptables de
déclarer un champ de balises. Toutefois, les expressions préférées sont celles répertoriées ci-dessus.
Utiliser des balises avec des paramètres

Une valeur de paramètre peut être passée à un champ de balise. Le passage d’un paramètre à un champ
de balise augmente la flexibilité de la définition de stratégie lors de l’attribution de stratégie.
Dans l’exemple suivant, concat est utilisé pour créer une recherche dans le champ de balises pour la
balise nommée avec la valeur du paramètre tagName. Si cette balise n’existe pas, l’effetModifier est
utilisé pour ajouter la balise à l’aide de la valeur de la même balise nommée définie sur le groupe de
ressources parent des ressources auditées à l’aide de la fonction de recherche resourcegroup() .
{
"if": {
"exists": "false"
},
"then": {
"effect": "modify",
"details": {
"operations": [{
"operation": "add",
"value": "[resourcegroup().tags[parameters('tagName')]]"
}],
20f7382dd24c"
]
}
}
}
Valeur
Les conditions peuvent également être formées à l’aide de valeur. valeur vérifie les conditions selon les
paramètres, les fonctions de modèle supportées ou des littéraux. valeur est associée à n’importe quelle
condition prise en charge.
WARNING
Si le résultat d’une fonction de modèle est une erreur, la stratégie d’évaluation échoue. Une évaluation ayant
échoué correspond à un refus implicite. Pour plus d’informations, consultez Éviter les défaillances des modèles.
Définissez la propriété enforcementMode sur DoNotEnforce pour empêcher l’impact d’une évaluation qui a
échoué sur des ressources nouvelles ou mises à jour lors du test et de la validation d’une nouvelle définition de
stratégie.
Exemples de valeur
Cet exemple de règle de stratégie utilise valeur pour comparer le résultat de la fonction
resourceGroup() et la propriété nom renvoyée à une condition like de *netrg . La règle refuse toute
ressource qui n’est pas du type Microsoft.Network/* dans tout groupe de ressources dont le nom se
termine par *netrg .
{
"if": {
"allOf": [{
"value": "[resourceGroup().name]",
"like": "*netrg"
},
{
"field": "type",
"notLike": "Microsoft.Network/*"
}
]
},
"then": {
"effect": "deny"
}
}
Cet exemple de règle de stratégie utilise value pour vérifier si le résultat de plusieurs fonctions
imbriquées est égal à true . La règle refuse toute ressource qui n’a pas au moins trois balises.
{
"mode": "indexed",
"policyRule": {
"if": {
"value": "[less(length(field('tags')), 3)]",
"equals": true
},
"then": {
"effect": "deny"
}
}
}
Éviter les défaillances des modèles

L’utilisation de fonctions de modèle dans value (valeur) autorise de nombreuses fonctions imbriquées
complexes. Si le résultat d’une fonction de modèle est une erreur, la stratégie d’évaluation échoue. Une
évaluation ayant échoué correspond à un refus implicite. Voici un exemple d’une valeur qui échoue
dans certains scénarios :
{
"policyRule": {
"if": {
"value": "[substring(field('name'), 0, 3)]",
"equals": "abc"
},
"then": {
"effect": "audit"
}
}
}
L’exemple de règle de stratégie ci-dessus utilise substring() pour comparer les trois premiers caractères
du nom avec abc. Si le nom a moins de 3 caractères, la fonction substring() génère une erreur. Cette
erreur fait que la stratégie produit un effet deny (refuser) .
Au lieu de cela, utilisez la fonction if() pour vérifier si les 3 premiers caractères du nom sont égaux à abc
pour éviter qu’un nom contenant moins de 3caractères entraîne une erreur :
{
"policyRule": {
"if": {
"value": "[if(greaterOrEquals(length(field('name')), 3), substring(field('name'), 0, 3),
'not starting with abc')]",
"equals": "abc"
},
"then": {
"effect": "audit"
}
}
}
Avec la règle de stratégie révisée, if() vérifie la longueur du nom avant d’essayer d’obtenir une
substring() sur une valeur avec moins de 3 caractères. Si le nom est trop court, la valeur « ne
commence pas par abc » est retournée à la place et comparée à abc. Une ressource avec un nom court
qui ne commence pas par abc fait toujours échouer la règle de stratégie, mais ne provoque plus d’erreur
lors de l’évaluation.
Count
Les conditions qui comptent le nombre de membres d’un tableau dans la charge utile de la ressource
satisfaisant une expression de condition peuvent être formées à l’aide d’une expression count. Les
scénarios courants vérifient si « au moins un des », « un seul des », « tous les » ou « aucun des »
membres du tableau remplissent la condition. count évalue chaque membre du tableau [*] alias à la
recherche d’une expression de condition, et additionne les résultats true, qui sont ensuite comparés à
l’opérateur d’expression.
La structure de l’expression count est :
{
"count": {
"field": "<[*] alias>",
"where": {
/* condition expression */
}
},
"<condition>": "<compare the count of true condition expression array members to this value>"
}
Les propriétés suivantes sont utilisées avec count :
count.field (obligatoire) : contient le chemin du tableau et doit être un alias de tableau. Si le tableau
est manquant, l’expression est évaluée à false sans tenir compte de l’expression de condition.
count.where (facultatif) : l’expression de condition pour évaluer individuellement chaque membre
du tableau alias [*] de count.field. Si cette propriété n’est pas fournie, tous les membres du tableau
avec le chemin « field » sont évalués à true. Toute condition peut être utilisée à l’intérieur de cette
propriété. Il est possible d’utiliser des opérateurs logiques à l’intérieur de cette propriété pour créer
des exigences d’évaluation complexes.
<condition> (obligatoire) : la valeur est comparée au nombre d’éléments qui ont satisfait
l’expression de condition count.where. Une condition numérique doit être utilisée.
Exemples de comptage
Exemple 1 : Vérifier si un tableau est vide
{
"count": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*]"
},
"equals": 0
}
Exemple 2 : Rechercher un seul membre du tableau qui satisfait l’expression de condition
{
"count": {
"where": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].description",
"equals": "My unique description"
}
},
"equals": 1
}
Exemple 3 : Rechercher au moins un membre du tableau qui satisfait l’expression de condition
{
"count": {
"where": {
"equals": "My common description"
}
},
"greaterOrEquals": 1
}
Exemple 4 : Vérifier que tous les membres du tableau d’objets satisfont l’expression de condition
{
"count": {
"where": {
"equals": "description"
}
},
"equals": "[length(field('Microsoft.Network/networkSecurityGroups/securityRules[*]'))]"
}
Exemple 5 : Vérifier que tous les membres du tableau de chaînes satisfont l’expression de condition
{
"count": {
"field": "Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]",
"where": {
"like": "*@contoso.com"
}
},
"equals": "[length(field('Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]'))]"
}
Exemple 6 : Utiliser field à l’intérieur de value pour vérifier que tous les membres du tableau satisfont
l’expression de condition
{
"count": {
"where": {
"value": "
[last(split(first(field('Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]')), '@'))]",
"equals": "contoso.com"
}
},
"equals": "[length(field('Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]'))]"
}
Exemple 7 : Vérifier qu’au moins un membre du tableau correspond à plusieurs propriétés dans
l’expression de condition
{
"count": {
"where": {
"allOf": [
{
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].direction",
"equals": "Inbound"
},
{
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].access",
"equals": "Allow"
},
{
"field":
"Microsoft.Network/networkSecurityGroups/securityRules[*].destinationPortRange",
"equals": "3389"
}
]
}
},
"greater": 0
}
Résultat
Azure Policy prend en charge les types d’effet suivants :
append : ajoute l’ensemble de champs défini à la requête.
audit : génère un événement d’avertissement dans le journal d’activité, mais ne fait pas échouer la
requête.
AuditIfNotExists : génère un événement d’avertissement dans le journal d’activité si une ressource
connexe n’existe pas
deny : génère un événement dans le journal d’activité et fait échouer la requête.
DeployIfNotExists : déploie une ressource connexe si elle n’existe pas déjà
disabled : n’évalue pas la conformité des ressources à la règle de stratégie.
EnforceOPAConstraint (préversion) : configure le contrôleur des admissions de l’agent de stratégie
ouverte avec Gatekeeper V3 pour les clusters Kubernetes auto-managés sur Azure (préversion)
EnforceRegoPolicy (préversion) : configure le contrôleur des admissions de l’agent de stratégie
ouverte avec Gatekeeper v2 dans Azure Kubernetes Service
Modify : ajoute, met à jour ou supprime les étiquettes définies dans une ressource
Pour plus d’informations sur chaque effet, l’ordre d’évaluation, les propriétés et des exemples, consultez
Présentation des effets Azure Policy.
Fonctions de stratégie
Toutes les fonctions de modèle Resource Manager peuvent être utilisées dans une règle de stratégie, à
l’exception des fonctions et fonctions définies par l’utilisateur suivantes :
copyIndex()
deployment()
list*
newGuid()
pickZones()
providers()
reference()
resourceId()
variables()
Les fonctions suivantes sont disponibles pour utilisation dans une règle de stratégie, mais diffèrent de
l’utilisation dans un modèle Azure Resource Manager :
addDays(dateTime, numberOfDaysToAdd)
dateTime : [obligatoire] chaîne - chaîne au format date/heure universel ISO 8601 « yyyy-
MM -ddTHH:mm:ss.fffffffZ »
numberOfDaysToAdd : [obligatoire] nombre entier - nombre de jours à ajouter
utcNow() : contrairement à un modèle Resource Manager, cette fonction peut être utilisée en dehors
de defaultValue.
Retourne une chaîne qui est définie sur la date et l’heure actuelles au format de date/heure
universel ISO 8601 « yyyy-MM -ddTHH:mm:ss.fffffffZ »
Les fonctions suivantes sont disponibles uniquement dans les règles de stratégie :
field(fieldName)
fieldName : [Obligatoire] chaîne - Nom du champ à récupérer
Retourne la valeur de ce champ à partir de la ressource en cours d’évaluation par la
condition If
field est principalement utilisé avec AuditIfNotExists et DeployIfNotExists pour faire
référence aux champs actuellement évalués de la ressource. Vous pouvez en voir une
illustration dans l’exemple DeployIfNotExists.
requestContext().apiVersion
Retourne la version d’API de la requête qui a déclenché l’évaluation de la stratégie
(par exemple : 2019-09-01 ). Il s’agit de la version d’API qui a été utilisée dans la requête
PUT/PATCH pour les évaluations relatives à la création/mise à jour de ressources. La dernière
version de l’API est toujours utilisée lors de l’évaluation de la conformité sur des ressources
existantes.
Exemple de fonction de stratégie
Cet exemple de règle de stratégie utilise la fonction de ressource resourceGroup pour obtenir la
propriété name, combinée au tableau concat et à la fonction d’objet, pour créer une condition like
selon laquelle le nom de ressource commence par le nom du groupe de ressources.
{
"if": {
"not": {
"field": "name",
"like": "[concat(resourceGroup().name,'*')]"
}
},
"then": {
"effect": "deny"
}
}
Alias
Les alias de propriété permettent d’accéder aux propriétés spécifiques d’un type de ressource. Les alias
permettent de restreindre les valeurs ou les conditions autorisées pour la propriété d’une ressource.
Chaque alias correspond aux chemins des différentes versions d’API d’un type de ressource donné. Lors
de l’évaluation de la stratégie, le moteur de stratégie obtient le chemin de la propriété de cette version
de l’API.
La liste des alias augmente toujours. Pour trouver les alias actuellement pris en charge par Azure Policy,
utilisez l’une des méthodes suivantes :
Extension Azure Policy pour Visual Studio Code (recommandée)
Utilisez l’extension Azure Policy pour Visual Studio Code afin d’afficher et de découvrir les alias
des propriétés de ressources.

Utilisez l’opérateur project pour afficher l’alias d’une ressource.
Resources
| limit 1
| project aliases
az graph query -q "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1 |

project aliases"
Search-AzGraph -Query "Resources | where type=~'microsoft.storage/storageaccounts' | limit 1

| project aliases"
Azure PowerShell
# Use Get-AzPolicyAlias to list available providers

Get-AzPolicyAlias -ListAvailable
# Use Get-AzPolicyAlias to list aliases for a Namespace (such as Azure Compute --

Microsoft.Compute)
(Get-AzPolicyAlias -NamespaceMatch 'compute').Aliases
Azure CLI
# List namespaces
az provider list --query [*].namespace
# Get Azure Policy aliases for a specific Namespace (such as Azure Compute --
Microsoft.Compute)
az provider show --namespace Microsoft.Compute --expand "resourceTypes/aliases" --query
"resourceTypes[].aliases[].name"
API REST/ARMClient
GET https://management.azure.com/providers/?api-version=2017-08-
01&$expand=resourceTypes/aliases
Comprendre l’alias [*]

Plusieurs des alias disponibles ont une version qui s’affiche sous la forme d’un nom « normal » et une
autre avec [*] qui lui est attaché. Par exemple :
Microsoft.Storage/storageAccounts/networkAcls.ipRules
Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]
L’alias « normal » représente le champ sous la forme d’une valeur unique. Ce champ est réservé aux
scénarios de comparaison de correspondance exacte, lorsque l’ensemble de valeurs entier doit être
exactement tel que défini, ni plus ni moins.
L’alias [*] permet de comparer la valeur de chaque élément du tableau et des propriétés spécifiques de
chaque élément. Cette approche permet de comparer les propriétés d’élément pour les scénarios « if
none of », «if any of » ou « if all of ». Pour obtenir des scénarios plus complexes, utilisez l’expression de
condition count. Avec ipRules[*] , il s’agit, par exemple, de valider que chaque action est définie sur
Deny (Refuser), sans se préoccuper de savoir combien de règles existent ou quelle est la valeur
d’adresse IP. Cet exemple de règle vérifie toutes les correspondances de ipRules[*].value avec 10.0.4.1
et applique effectType uniquement s’il ne trouve pas au moins une correspondance :
"policyRule": {
"if": {
"allOf": [
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
"exists": "true"
},
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*].value",
"notEquals": "10.0.4.1"
}
]
},
"then": {
}
}
Pour plus d’informations, consultez l’évaluation de l’alias [*].
Initiatives
Les initiatives vous permettent de regrouper en un seul élément plusieurs définitions de stratégies
associées pour simplifier les affectations et la gestion. Par exemple, vous pouvez regrouper des
définitions de stratégies de balisage associées en une même initiative. Au lieu d’attribuer chaque
stratégie individuellement, vous appliquez l’initiative.
L’exemple suivant montre comment créer une initiative pour gérer deux balises : costCenter et
productName . Il utilise deux stratégies intégrées pour appliquer la valeur de balise par défaut.
{
"properties": {
"displayName": "Billing Tags Policy",
"policyType": "Custom",
"description": "Specify cost Center tag and product name tag",
"parameters": {
"parameters": {
"type": "String",
"metadata": {
"description": "required value for Cost Center tag"
}
},
"type": "String",
"metadata": {
"description": "required value for product Name tag"
}
}
},
"/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
},
{
"/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
},
{
"/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
},
{
"/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
"parameters": {
"tagName": {
},
"tagValue": {
}
}
}
]
}
}
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Découvrez comment créer des stratégies par programmation.
Découvrez comment obtenir des données de conformité.
Découvrez comment corriger des ressources non conformes.
Pour en savoir plus sur les groupes d’administration, consultez Organiser vos ressources avec des
groupes d’administration Azure.
Chaque définition de stratégie dans Azure Policy a un effet unique. Cet effet détermine ce qu’il 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.
Une définition de stratégie prend en charge ces effets :
Append
Audit
AuditIfNotExists
Deny
DeployIfNotExists
Désactivé
EnforceOPAConstraint (préversion)
EnforceRegoPolicy (préversion)
Modify
Ordre d’évaluation
Les requêtes pour créer ou mettre à jour une ressource via Azure Resource Manager sont évaluées en
premier par Azure Policy. Azure Policy répertorie toutes les affectations qui s’appliquent à la ressource,
puis évalue la ressource en fonction de chaque définition. Azure Policy traite plusieurs effets avant de
transmettre la requête au fournisseur de ressources approprié. Cela empêche un fournisseur de
ressources d’effectuer un traitement inutile de la ressource lorsque celle-ci ne satisfait pas aux contrôles
de gouvernance d’Azure Policy.
Désactivé 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. Puisque l’un comme l’autre peuvent modifier la requête,
une modification peut empêcher le déclenchement d’un effet Audit ou Deny.
Deny est ensuite évalué. L’évaluation de Deny avant Audit empêche la double journalisation d’une
ressource indésirable.
Audit est alors évalué avant que la requête ne soit envoyée au fournisseur de ressources.
Une fois que le fournisseur de ressources a retourné un code de réussite, AuditIfNotExists et
DeployIfNotExists déterminent si une journalisation de conformité ou une action supplémentaire est
requise.
Il n’existe pas actuellement d’ordre d’évaluation pour les effets EnforceOPAConstraint ou
EnforceRegoPolicy.
Désactivé
Cet effet peut s’avérer utile pour tester certaines situations ou lorsque la définition de stratégie a
paramétré l’effet. Cette flexibilité permet de désactiver une seule affectation plutôt que de désactiver
toutes les affectations de cette stratégie.
Une alternative à l’effet Désactivé est enforcementMode , qui est défini sur l’attribution de stratégie.
Lorsque enforcementMode est Désactivé, les ressources sont toujours évaluées. La journalisation,
notamment les journaux d’activité, et l’effet de stratégie ne se produisent pas. Pour plus d’informations,
consultez Attribution de stratégie - Mode de mise en conformité.
Ajouter
Append permet d’ajouter des champs supplémentaires à la ressource demandée lors de la création ou
de la mise à jour. Un exemple courant consiste à spécifier des adresses IP autorisées pour une ressource
de stockage.
IMPORTANT
Append est destiné à être utilisé avec des propriétés autres que des étiquettes. Même si Append peut ajouter des
étiquettes à une ressource dans le cadre d’une requête de création ou de mise à jour, il est recommandé d’utiliser
l’effet Modify pour les étiquettes.
Évaluation Append
L’évaluation Append se produit avant que la requête ne soit traitée par un fournisseur de ressources lors
de la création ou de la mise à jour d’une ressource. Append ajoute des champs à la ressource lorsque la
condition if de la règle de stratégie est remplie. Si l’effet Append remplace une valeur dans la requête
d’origine avec une valeur différente, il agit comme un effet Deny et rejette la demande. Pour ajouter une
nouvelle valeur à un tableau existant, utilisez la version [*] de l’alias.
Lorsqu’une définition de stratégie utilisant l’effet Append est exécutée dans le cadre d’un cycle
d’évaluation, elle n’apporte pas de modifications aux ressources qui existent déjà. Au lieu de cela, elle
marque comme non conforme toute ressource qui répond à la condition if.
Propriétés d’Append
Un effet Append prend en charge la propriété obligatoire details uniquement, laquelle est un tableau de
données. En tant que tableau, details peut contenir une ou plusieurs paires champ/valeur. Reportez-
vous à la structure de définition pour afficher la liste des champs autorisés.
Exemples Append
Exemple 1 : paire champ/valeur unique utilisant un alias non- [*] avec un tableau value afin de définir
des règles IP sur un compte de stockage. Lorsque l’alias non- [*] est un tableau, l’effet ajoute la value
comme tableau entier. Si le tableau existe déjà, un événement de refus se produit à partir du conflit.
"then": {
"effect": "append",
"details": [{
"value": [{
"action": "Allow",
"value": "134.5.0.0/21"
}]
}]
}
Exemple 2 : paire champ/valeur unique utilisant un alias [*] avec un tableau value afin de définir des
règles IP sur un compte de stockage. En utilisant l’alias [*] , l’effet ajoute la value à un tableau
potentiellement préexistant. Si le tableau n’existe pas déjà, il sera créé.
"then": {
"effect": "append",
"details": [{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
"value": {
"value": "40.40.40.40",
"action": "Allow"
}
}]
}
Modifier
Modify est utilisé pour ajouter, mettre à jour ou supprimer les étiquettes d’une ressource lors d’une
création ou d’une mise à jour. Un exemple courant consiste à mettre à jour les étiquettes des ressources
telles que costCenter. Une stratégie Modify doit toujours avoir mode défini sur Indexé, sauf si la
ressource cible est un groupe de ressources. Les ressources non conformes existantes peuvent être
corrigées à l’aide d’une tâche de correction. Une même règle Modify peut avoir autant d’opérations que
vous le souhaitez.
IMPORTANT
Modify s’utilise uniquement pour les étiquettes. Si vous gérez des étiquettes, il est recommandé d’utiliser Modify
plutôt que Append, car Modify fournit des types d’opérations supplémentaires, ainsi que la possibilité de corriger
les ressources existantes. Toutefois, Append est recommandé si vous n’êtes pas en mesure de créer une identité
managée.
Évaluation Modify
L’évaluation Modify a lieu avant que la requête ne soit traitée par un fournisseur de ressources lors de la
création ou de la mise à jour d’une ressource. Modify ajoute ou met à jour les étiquettes d’une ressource
lorsque la condition if de la règle de stratégie est remplie.
Lorsqu’une définition de stratégie utilisant l’effet Modify est exécutée dans le cadre d’un cycle
d’évaluation, elle n’apporte pas de modifications aux ressources qui existent déjà. Au lieu de cela, elle
marque comme non conforme toute ressource qui répond à la condition if.
Propriétés de Modify
La propriété details de l’effet Modify comporte toutes les sous-propriétés qui définissent les
autorisations nécessaires à la correction, ainsi que les opérations utilisées pour ajouter, mettre à jour ou
supprimer les valeurs des étiquettes.
roleDefinitionIds [obligatoire]
Cette propriété doit inclure un tableau de chaînes qui correspondent aux ID de rôle de
contrôle de l’accès en fonction du rôle accessibles par l’abonnement. Pour plus d’informations,
consultez Correction - Configurer une définition de stratégie.
Le rôle défini doit inclure toutes les opérations accordées au rôle Contributeur.
operations [obligatoire]
Tableau de toutes les opérations d’étiquette à effectuer sur les ressources correspondantes.
Propriétés :
operation [obligatoire]
Définit l’action à effectuer sur une ressource correspondante. Les options sont
les suivantes : addOrReplace, Add, Remove. Add a le même comportement que
l’effet Append.
field [obligatoire]
Étiquette à ajouter, remplacer ou supprimer.Les noms d’étiquette doivent
respecter la même convention de nommage que les autres champs.
value (facultatif)
Valeur à affecter à l’étiquette.
Cette propriété est obligatoire si l’opération est addOrReplace ou Add.
Opérations Modify
Le tableau de propriétés operations permet de modifier plusieurs étiquettes de différentes façons à
partir d’une même définition de stratégie. Chaque opération est constituée des propriétés operation,
field et value. La propriété operation détermine ce que fait la tâche de correction aux étiquettes, la
propriété field détermine l’étiquette qui est modifiée et la propriété value définit le nouveau paramètre
de l’étiquette. Voici des exemples de modifications d’étiquette :
Définit l’étiquette environment sur « Test », même si elle a déjà une valeur.
Supprime l’étiquette TempResource .
Définit l’étiquette Dept sur le paramètre de stratégie DeptName configuré pour l’attribution de
stratégie.
"details": {
...
"operations": [
{
"field": "tags['environment']",
"value": "Test"
},
{
"operation": "Remove",
"field": "tags['TempResource']",
},
{
"field": "tags['Dept']",
"value": "[parameters('DeptName')]"
}
]
}
La propriété operation comprend les options suivantes :
OPÉRATION DESCRIPTION
addOrReplace Ajoute l’étiquette et la valeur définies à la ressource,

même si l’étiquette a déjà une autre valeur.
Ajouter Ajoute l’étiquette et la valeur définies à la ressource.
Supprimer Supprime l’étiquette définie de la ressource.
Exemples Modify
Exemple 1 : Ajoutez l’étiquette environment et remplacez les étiquettes environment existantes par
« Test » :
"then": {
"effect": "modify",
"details": {
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
20f7382dd24c"
],
"operations": [
{
"value": "Test"
}
]
}
}
Exemple 2 : Supprimez l’étiquette env et ajoutez l’étiquette environment , ou remplacez les étiquettes
environment existantes par une valeur paramétrable :
"then": {
"effect": "modify",
"details": {
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
20f7382dd24c"
],
"operations": [
{
"operation": "Remove",
"field": "tags['env']"
},
{
"value": "[parameters('tagValue')]"
}
]
}
}
Deny
Deny empêche l’exécution d’une requête de ressource qui ne correspond pas aux normes définies via
une définition de stratégie et qui fait échouer la requête.
Évaluation Deny
Lors de la création ou de la mise à jour d’une ressource correspondante, Deny empêche l’envoi de la
requête au fournisseur de ressources. La requête renvoie une erreur 403 (Forbidden) . Dans le portail,
l’erreur 403 (Interdit) peut être considérée comme l’état du déploiement qui a été empêché par
l’affectation de stratégie.
Lors de l’évaluation des ressources existantes, les ressources qui correspondent à une définition de
stratégie Deny sont marquées comme non conformes.
Propriétés de Deny
L’effet Deny n’a pas d’autres propriétés utilisables dans la condition then de la définition de stratégie.
Exemple Deny
Exemple : utilisation de l’effet Deny.
"then": {
"effect": "deny"
}
Audit
Audit permet de créer un événement d’avertissement dans le journal d’activité lors de l’évaluation d’une
ressource non conforme, mais il n’arrête pas la requête.
Évaluation Audit
Audit est le dernier effet vérifié par Azure Policy pendant la création ou la mise à jour d’une ressource.
Azure Policy envoie ensuite la ressource au fournisseur de ressources. Audit fonctionne de la même
façon pour une requête de ressource et un cycle d’évaluation. Azure Policy ajoute une opération
Microsoft.Authorization/policies/audit/action dans le journal d’activité et marque la ressource comme
non conforme.
Propriétés d’Audit
L’effet Audit n’a pas d’autres propriétés utilisables dans la condition then de la définition de stratégie.
Exemple Audit
Exemple : utilisation de l’effet Audit.
"then": {
"effect": "audit"
}
AuditIfNotExists
AuditIfNotExists active l’audit sur des ressources qui satisfont à la condition if, mais dont les
composants ne sont pas spécifiés dans la propriété details de la condition then.
Évaluation AuditIfNotExists
AuditIfNotExists s’exécute après qu’un fournisseur de ressources a traité une requête de création ou de
mise à jour de ressource et a renvoyé un code d’état de réussite. L’effet Audit est déclenché s’il n’existe
pas de ressources connexes ou si les ressources définies par ExistenceCondition ne retournent pas de
valeur true. Azure Policy ajoute une opération Microsoft.Authorization/policies/audit/action au journal
d’activité de la même façon que l’effet Audit. Dans ce cas, la ressource qui a rempli la condition if est en
fait la ressource qui est marquée comme non conforme.
Propriétés d’AuditIfNotExists
La propriété details des effets AuditIfNotExists possède toutes les sous-propriétés qui définissent les
ressources connexes testées.
Type [obligatoire]
Spécifie le type de la ressource connexe à évaluer.
Si details.type est un type de ressource sous la ressource de condition if, la stratégie envoie
des requêtes pour les ressources de ce type dans l’étendue de la ressource évaluée. Sinon, la
stratégie envoie des requêtes dans le même groupe de ressources que la ressource évaluée.
Name (facultatif)
Spécifie le nom exact de la ressource à tester et amène la stratégie à extraire une ressource
spécifique au lieu de toutes les ressources du type spécifié.
Lorsque les valeurs de condition pour if.field.type et then.details.type correspondent,
Name devient required et doit être [field('name')] . Toutefois, un effet audit doit être
considéré à la place.
ResourceGroupName (facultatif)
Permet l’évaluation de la ressource connexe provenant d’un groupe de ressources différent.
Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
La valeur par défaut est le groupe de ressources de la ressource de condition if.
ExistenceScope (facultatif)
Les valeurs autorisées sont Subscription et ResourceGroup.
Définit la portée d’où la ressource connexe évaluée est extraite.
Pour ResourceGroup, le traitement se limiterait au groupe de ressources de la ressource de
condition if ou au groupe de ressources spécifié dans ResourceGroupName.
Pour Subscription, le traitement interroge l’abonnement entier pour la ressource associée.
La valeur par défaut est ResourceGroup.
ExistenceCondition (facultatif)
Si elle n’est pas spécifiée, toute ressource connexe du type remplit les conditions de l’effet et
ne déclenche pas l’audit.
Utilise la même langue que la règle de stratégie pour la condition if mais est évaluée
individuellement sur chaque ressource associée.
Si une ressource connexe correspondante renvoie true, l’effet est satisfait et ne déclenche pas
l’audit.
Peut utiliser [field()] pour vérifier l’équivalence des valeurs dans la condition if.
Par exemple, permet de vérifier que la ressource parent (dans la condition if) réside dans le
même emplacement de la ressource en tant que ressource connexe correspondante.
Exemple AuditIfNotExists
Exemple : évalue les Machines virtuelles Microsoft Azure pour déterminer si l’extension Antimalware
existe, puis effectue un audit si l’extension est absente.
{
"if": {
"field": "type",
},
"then": {
"effect": "auditIfNotExists",
"details": {
"allOf": [{
"equals": "Microsoft.Azure.Security"
},
{
"equals": "IaaSAntimalware"
}
]
}
}
}
}
DeployIfNotExists
Comme pour AuditIfNotExists, une définition de stratégie DeployIfNotExists exécute un déploiement de
modèle lorsque la condition est remplie.
NOTE
Les modèles imbriqués sont pris en charge avec deployIfNotExists, mais les modèles liés ne sont actuellement
pas pris en charge.
Évaluation DeployIfNotExists
DeployIfNotExists s’exécute environ 15 minutes après qu’un fournisseur de ressources a traité une
requête de création ou de mise à jour de ressource et a renvoyé un code d’état de réussite. Un
déploiement de modèle est déclenché s’il n’existe pas de ressources connexes ou si les ressources
définies par ExistenceCondition ne retournent pas de valeur true. La durée du déploiement dépend de
la complexité des ressources incluses dans le modèle.
Au cours d’un cycle d’évaluation, les définitions de stratégie ayant un effet DeployIfNotExists sur les
ressources sont marquées comme non conformes, mais aucune action n’est effectuée sur ces ressources.
Propriétés de DeployIfNotExists
La propriété details de l’effet DeployIfNotExists comprend toutes les sous-propriétés qui définissent les
ressources connexes testées, ainsi que le déploiement de modèle à exécuter.
Type [obligatoire]
Spécifie le type de la ressource connexe à évaluer.
Commence par tenter d’extraire une ressource sous la ressource de condition if, puis effectue
une requête dans le même groupe de ressources que la ressource de condition if.
Name (facultatif)
Spécifie le nom exact de la ressource à tester et amène la stratégie à extraire une ressource
spécifique au lieu de toutes les ressources du type spécifié.
Lorsque les valeurs de condition pour if.field.type et then.details.type correspondent,
Name devient required et doit être [field('name')] .
ResourceGroupName (facultatif)
Permet l’évaluation de la ressource connexe provenant d’un groupe de ressources différent.
La valeur par défaut est le groupe de ressources de la ressource de condition if.
L’exécution d’un déploiement de modèle s’effectue dans le groupe de ressources de cette
valeur.
ExistenceScope (facultatif)
Définit la portée d’où la ressource connexe évaluée est extraite.
Pour ResourceGroup, le traitement se limiterait au groupe de ressources de la ressource de
condition if ou au groupe de ressources spécifié dans ResourceGroupName.
Pour Subscription, le traitement interroge l’abonnement entier pour la ressource associée.
ExistenceCondition (facultatif)
Si elle n’est pas spécifiée, toute ressource connexe de type satisfait à l’effet en question et ne
déclenche pas le déploiement.
Utilise la même langue que la règle de stratégie pour la condition if mais est évaluée
individuellement sur chaque ressource associée.
Si une ressource connexe correspondante renvoie true, l’effet est satisfait et ne déclenche pas
le déploiement.
Peut utiliser [field()] pour vérifier l’équivalence des valeurs dans la condition if.
Par exemple, permet de vérifier que la ressource parent (dans la condition if) réside dans le
même emplacement de la ressource en tant que ressource connexe correspondante.
roleDefinitionIds [obligatoire]
Cette propriété doit inclure un tableau de chaînes qui correspondent aux ID de rôle de
contrôle de l’accès en fonction du rôle accessibles par l’abonnement. Pour plus d’informations,
consultez Correction - Configurer une définition de stratégie.
DeploymentScope (facultatif)
Définit le type de déploiement à déclencher. Subscription indique un déploiement au niveau de
l’abonnement, ResourceGroup indique un déploiement dans un groupe de ressources.
Une propriété location doit être spécifiée dans Deployment pour les déploiements au niveau
de l’abonnement.
Deployment [obligatoire]
Cette propriété doit inclure le déploiement de modèle complet, car elle est transmise à l’API
PUT Microsoft.Resources/deployments . Pour plus d’informations, consultez l’API REST
Deployments.
NOTE
Toutes les fonctions à l’intérieur de la propriété Deployment sont évaluées en tant que composants du
modèle, et non pas de la stratégie. La propriété parameters y fait exception car elle transmet les valeurs
de la stratégie au modèle. Dans cette section, la propriété value sous le nom de paramètre du modèle
permet d’effectuer la transmission de valeurs (voir fullDbName dans l’exemple DeployIfNotExists).
Exemple DeployIfNotExists
Exemple : évalue les bases de données SQL Server pour déterminer si transparentDataEncryption est
activée. Sinon, un déploiement destiné à l’activer est exécuté.
"if": {
"field": "type",
"equals": "Microsoft.Sql/servers/databases"
},
"then": {
"details": {
"type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
"name": "current",
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
"/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
],
"field": "Microsoft.Sql/transparentDataEncryption.status",
"equals": "Enabled"
},
"deployment": {
"properties": {
"mode": "incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"parameters": {
"fullDbName": {
"type": "string"
}
},
"resources": [{
"name": "[concat(parameters('fullDbName'), '/current')]",
"type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
"apiVersion": "2014-04-01",
"properties": {
"status": "Enabled"
}
}]
},
"parameters": {
"fullDbName": {
"value": "[field('fullName')]"
}
}
}
}
}
}
EnforceOPAConstraint
Cet effet est utilisé avec une définition de stratégie mode de Microsoft.Kubernetes.Data . Il est utilisé
pour transmettre les règles de contrôle d’admission de Gatekeeper v3 définies avec le Framework de
contraintes d’OPA à Open Policy Agent (OPA) aux clusters Kubernetes auto-gérés sur Azure.
NOTE
Le moteur Azure Policy pour Azure Kubernetes Service (AKS) est en préversion publique. Il ne prend charge que
les définitions de stratégie intégrées.
Évaluation d’EnforceOPAConstraint
Le contrôleur d’admission Open Policy Agent évalue les nouvelles requêtes du cluster en temps réel.
Toutes les 5 minutes, une analyse complète du cluster est réalisée, et les résultats sont renvoyés sur
Azure Policy.
Propriétés d’EnforceOPAConstraint
La propriété details de l’effet EnforceOPAConstraint contient les sous-propriétés qui décrivent la règle
de contrôle d’admission de Gatekeeper v3.
constraintTemplate [obligatoire]
Modèle de contrainte CustomResourceDefinition (CRD ) qui définit de nouvelles contraintes.
Le modèle définit la logique Rego, le schéma de contrainte et les paramètres de contrainte
transmis via des valeurs d’Azure Policy.
constraint [obligatoire]
Implémentation CRD du modèle de contrainte. Utilise des paramètres transmis via des
valeurs telles que {{ .Values.<valuename> }} . Dans l’exemple ci-dessous, il s’agirait de
{{ .Values.cpuLimit }} et {{ .Values.memoryLimit }} .
valeurs [facultatif]
Définit des paramètres et valeurs à transmettre à la contrainte. Chaque valeur doit exister dans
le modèle de contrainte CRD.
Exemple EnforceRegoPolicy
Exemple : Règle de contrôle d’admission de Gatekeeper v3 pour définir les limites de ressources de
mémoire et d’UC du conteneur dans le moteur AKS.
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.ContainerService/managedClusters",
"AKS Engine"
]
},
{
"equals": "westus2"
}
]
},
"then": {
"effect": "enforceOPAConstraint",
"details": {
"constraintTemplate": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-
references/Kubernetes/container-resource-limits/template.yaml",
"constraint": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-
references/Kubernetes/container-resource-limits/constraint.yaml",
"values": {
"cpuLimit": "[parameters('cpuLimit')]",
"memoryLimit": "[parameters('memoryLimit')]"
}
}
}
EnforceRegoPolicy
Cet effet est utilisé avec une définition de stratégie mode de Microsoft.ContainerService.Data . Il sert à
transmettre des règles de contrôle d’admission de Gatekeeper v2 définies avec Rego à Open Policy
Agent (OPA) sur Azure Kubernetes Service.
NOTE
Azure Policy pour AKS est en préversion limitée et prend uniquement en charge les définitions de stratégie
intégrées.
Évaluation d’EnforceRegoPolicy
Le contrôleur d’admission Open Policy Agent évalue les nouvelles requêtes du cluster en temps réel.
Toutes les 5 minutes, une analyse complète du cluster est réalisée, et les résultats sont renvoyés sur
Azure Policy.
Propriétés d’EnforceRegoPolicy
La propriété details de l’effet EnforceRegoPolicy contient les sous-propriétés qui décrivent la règle de
contrôle d’admission Gatekeeper v2.
policyId [required]
Nom unique transmis en tant que paramètre à la règle de contrôle d’admission Rego.
policy [required]
Spécifie l’URI de la règle de contrôle d’admission Rego.
policyParameters [optional]
Définit des paramètres et des valeurs à transmettre à la stratégie Rego.
Exemple EnforceRegoPolicy
Exemple : Règle de contrôle d’admission Gatekeeper v2 pour autoriser uniquement les images de
conteneur spécifiées dans AKS.
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.ContainerService/managedClusters"
},
{
"equals": "westus2"
}
]
},
"then": {
"effect": "EnforceRegoPolicy",
"details": {
"policyId": "ContainerAllowedImages",
"policy": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-
references/KubernetesService/container-allowed-images/limited-preview/gatekeeperpolicy.rego",
"policyParameters": {
"allowedContainerImagesRegex": "[parameters('allowedContainerImagesRegex')]"
}
}
}
Superposition de stratégies
Une ressource peut subir les effets de plusieurs affectations. Ces affectations peuvent se situer dans la
même portée ou dans des portées 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 comme 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 comme non conforme à la stratégie 1 si elle ne figure pas
dans 'westus'
Toute nouvelle ressource figurant dans l’abonnement A mais pas dans 'westus' est refusée par la
stratégie 1
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
Toute nouvelle ressource figurant dans l’abonnement A mais pas dans 'westus' est refusée par la
stratégie 1
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 stratégies ou le chevauchement
de stratégies est considéré comme cumulatif et le plus restrictif. Par exemple, si les stratégies 1 et 2
ont un effet Deny, une ressource est bloquée par les stratégies qui se chevauchent et qui sont en conflit.
Si vous avez toujours besoin que la ressource soit créée dans la portée cible, révisez les exclusions de
chaque affectation pour vérifier que les bonnes stratégies affectent les bonnes portées.
Étapes suivantes
Les attributions de stratégies sont utilisées par Azure Policy pour définir quelles stratégies ou initiatives sont
attribuées aux ressources. L’attribution de stratégie peut déterminer les valeurs des paramètres de ce groupe de
ressources au moment de l’attribution, ce qui permet de réutiliser les définitions de stratégie pour des mêmes
propriétés de ressource qui auraient des exigences de conformité différentes.
Vous devez utiliser du code JSON pour créer une attribution de stratégie. L’attribution de stratégie contient des
éléments pour :
le nom d’affichage
description
metadata
le mode d’application
la définition de la stratégie
parameters
Par exemple, le code JSON suivant montre une attribution de stratégie en mode DoNotEnforce avec des
paramètres dynamiques :
{
"properties": {
"displayName": "Enforce resource naming rules",
"description": "Force resource names to begin with DeptA and end with -LC",
"metadata": {
"assignedBy": "Cloud Center of Excellence"
},
"enforcementMode": "DoNotEnforce",
"/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyDefinitions/ResourceNaming",
"parameters": {
"prefix": {
"value": "DeptA"
},
"suffix": {
"value": "-LC"
}
}
}
}
Tous les exemples Azure Policy se trouvent dans Exemples de stratégies.
Nom d’affichage et description

Vous utilisez displayName et description pour identifier l’attribution de stratégie et fournir un contexte pour son
utilisation avec l’ensemble de ressources. displayName a une longueur maximale de 128 caractères et
description a une longueur maximale de 512 caractères.
Mode d’application
La propriété enforcementMode permet aux clients de tester le résultat d’une stratégie sur des ressources
existantes sans lancer l’effet de stratégie ni déclencher des entrées du journal d’activité Azure. Ce scénario est de
type « What If » et suit des pratiques de déploiement sécurisées. enforcementMode diffère de l’effet Disabled ,
car cet effet empêche l’évaluation des ressources de se produire.
Cette propriété a les valeurs suivantes :
ENTRÉE DU
CORRIGER JOURNAL
MODE VALEUR JSON TYPE MANUELLEMENT D’ACTIVITÉ DESCRIPTION
activé Default string Oui Oui L’effet de

stratégie est
appliqué pendant
la création ou la
ressource.
Désactivé DoNotEnforce string Oui Non L’effet de

stratégie n’est
pas appliqué
pendant la
création ou la
ressource.
Si enforcementMode n’est pas spécifié dans la définition d’une stratégie ou d’une initiative, la valeur Default est
utilisée. Les tâches de correction peuvent être démarrées pour les stratégies deployIfNotExists, même lorsque
enforcementMode est défini sur DoNotEnforce.
ID de définition de stratégie
Ce champ correspond au nom du chemin complet d’une définition de stratégie ou d’une définition d’initiative.
policyDefinitionId est une chaîne et non un tableau. Si plusieurs stratégies sont souvent attribuées ensemble, il
est recommandé d’utiliser une initiative.
Paramètres
Ce segment de l’attribution de stratégie fournit les valeurs des paramètres définis dans la définition de stratégie ou
d’initiative. Grâce à cette conception, il est possible de réutiliser une définition de stratégie ou d’initiative avec
différentes ressources. Toutefois, vous devez chercher à connaître les valeurs métiers et les résultats pour chaque
option.
"parameters": {
"prefix": {
"value": "DeptA"
},
"suffix": {
"value": "-LC"
}
}
Dans cet exemple, les paramètres précédemment définis dans la définition de stratégie sont prefix et suffix .
Cette attribution de stratégie définit prefix sur DeptA et suffix sur -LC. La même définition de stratégie peut
être réutilisée avec un autre ensemble de paramètres dans un autre service, ce qui réduit la duplication et la
complexité des définitions de stratégie tout en offrant une certaine flexibilité.
Étapes suivantes
En savoir plus sur la structure des définitions de stratégies
Pour en savoir plus sur les groupes d’administration, consultez Organiser vos ressources avec des groupes
d’administration Azure.
Azure Policy est un outil puissant qui permet de gérer vos ressources Azure en respectant les standards du secteur
et en répondant aux exigences de conformité. Lorsque des personnes, des processus ou des pipelines créent ou
mettent à jour des ressources, Azure Policy examine la requête impliquée. Lorsque l’effet de la définition de
stratégie est Append ou DeployIfNotExists, Azure Policy modifie la requête ou y ajoute des éléments. Lorsque
l’effet de la définition de stratégie est Audit ou AuditIfNotExists, Azure Policy provoque la création d’une entrée
dans le journal d’activité. Enfin, lorsque l’effet de la définition de stratégie est Deny, Azure Policy arrête la création
ou la modification de la requête.
Ces résultats sont exactement ceux que vous souhaitez lorsque vous savez que la stratégie est définie
correctement. Toutefois, il est important de vérifier qu’une nouvelle stratégie fonctionne comme prévu avant de
l’autoriser à modifier ou à bloquer un travail. Cette vérification vise à garantir que seules les ressources prévues
sont déterminées comme non conformes et qu’aucune ressource conforme n’a été incluse dans les résultats (c’est
ce qu’on appelle un faux positif).
L’approche recommandée pour vérifier une nouvelle définition de stratégie est la suivante :
Définir rigoureusement sa stratégie
Auditer les ressources existantes
Auditer les requêtes de ressources nouvelles ou mises à jour
Déployer la stratégie sur les ressources
Supervision continue
Définir rigoureusement sa stratégie

Il est important de comprendre comment la stratégie d’entreprise est implémentée en tant que définition de
stratégie, et comment sont liés les ressources Azure et les autres services Azure. Pour cela, vous devez comprendre
les exigences et déterminer les propriétés des ressources. Toutefois, il est également important de voir au-delà de
la définition de votre stratégie d’entreprise. Par exemple, votre stratégie indique-t-elle quelque chose comme
« Toutes les machines virtuelles doivent... » ? Qu’en est-il des autres services Azure qui utilisent des machines
virtuelles, tels que HDInsight ou AKS ? Lorsque vous définissez une stratégie, vous devez réfléchir à la façon dont
elle va impacter les ressources qui sont utilisées par d’autres services.
Pour cette raison, vos définitions de stratégie doivent être rigoureusement définies et focalisées sur les ressources
et les propriétés dont vous avez besoin pour évaluer la conformité.
Auditer les ressources existantes

Avant de chercher à gérer les ressources nouvelles ou mises à jour avec votre nouvelle définition de stratégie, il est
préférable de voir comment elle évalue un sous-ensemble limité de ressources existantes, comme un groupe de
ressources de test. Utilisez le mode d’application Désactivé (DoNotEnforce) dans votre attribution de stratégie afin
d’empêcher le déclenchement de l’effet ou la création d’entrées dans le journal d’activité.
Cette étape vous permet d’évaluer les résultats de conformité de la nouvelle stratégie sur les ressources existantes,
sans impacter le workflow. Vérifiez qu’aucune ressource conforme n’est marquée comme non conforme (faux
positif) et que toutes les ressources dont il est prévu qu’elles soient non conformes sont marquées correctement.
Une fois que le sous-ensemble de ressources d’origine est validé, étendez progressivement l’évaluation à toutes les
ressources existantes.
Le fait de procéder ainsi pour l’évaluation des ressources existantes permet de corriger les ressources
non conformes avant l’implémentation complète de la nouvelle stratégie. Ce nettoyage peut être effectué
manuellement ou par le biais d’une tâche de correction si l’effet de la définition de stratégie est DeployIfNotExists.
Auditer les ressources nouvelles ou mises à jour

Une fois que vous avez validé votre nouvelle définition de stratégie, vous pouvez vous intéresser à l’impact de la
stratégie lors de la création ou de la mise à jour des ressources. Si la définition de stratégie prend en charge le
paramétrage des effets, utilisez Audit. Cette configuration vous permet de superviser la création et la mise à jour
des ressources pour voir si la nouvelle définition de stratégie déclenche la création d’une entrée dans le journal
d’activité Azure en cas de ressource non conforme, sans impacter les tâches ou les requêtes existantes.
Il est recommandé de mettre à jour et de créer de nouvelles ressources correspondant à votre définition de
stratégie pour voir si l’effet Audit se déclenche comme prévu. Surveillez les requêtes de ressources qui ne doivent
pas être affectées par la nouvelle définition de stratégie qui déclenche l’effet Audit. Ces ressources impactées
constituent un autre exemple de faux positifs, et doivent être corrigées dans la définition de la stratégie avant
l’implémentation complète.
Si la définition de la stratégie est modifiée à cette phase du test, il est recommandé de commencer le processus de
validation par l’audit des ressources existantes. La modification d’une définition de stratégie en raison d’un faux
positif concernant des ressources nouvelles ou mises à jour est susceptible d’impacter les ressources existantes.
Déployer la stratégie sur les ressources

Une fois effectuée la validation de votre nouvelle définition de stratégie avec les ressources existantes et les
requêtes de ressources nouvelles ou mises à jour, vous pouvez commencer à implémenter la stratégie. Il est
recommandé de créer d’abord l’attribution de stratégie de la nouvelle définition de stratégie pour un sous-
ensemble de ressources, comme un groupe de ressources. Après avoir validé le déploiement initial, étendez la
stratégie à des niveaux de plus en plus larges, tels que des abonnements ou des groupes d’administration. Pour ce
faire, vous devez supprimer l’attribution et en créer une nouvelle pour les étendues cibles jusqu’à ce qu’elle soit
attribuée à l’étendue complète des ressources qui sont concernées par votre nouvelle définition de stratégie.
Pendant le déploiement, si des ressources qui doivent être exemptées de votre nouvelle définition de stratégie sont
détectées, traitez-les de l’une des manières suivantes :
Mettez à jour la définition de stratégie pour qu’elle soit plus explicite afin de réduire tout impact non voulu.
Modifiez l’étendue de l’attribution de stratégie (en supprimant et en créant une nouvelle attribution).
Ajoutez le groupe de ressources à la liste d’exclusion pour l’attribution de stratégie.
Toute modification apportée à l’étendue (niveau ou exclusions) doit être entièrement validée et communiquée à
vos organisations de sécurité et de conformité afin de garantir une couverture complète.
Superviser la stratégie et la conformité

L’implémentation et l’attribution de votre définition de stratégie ne constituent pas les dernières étapes. Supervisez
continuellement le niveau de conformité des ressources par rapport à votre nouvelle définition de stratégie, et
configurez des alertes et des notifications Azure Monitor pour les appareils non conformes qui sont détectés. Il est
également recommandé de planifier l’évaluation de la définition de stratégie et des attributions associées pour
vérifier que la définition de stratégie répond aux exigences de conformité et à la stratégie d’entreprise. Les
stratégies doivent être supprimées lorsque vous n’en avez plus besoin. Les stratégies doivent également être mises
à jour de temps en temps, à mesure que les ressources Azure sous-jacentes évoluent et que de nouvelles
propriétés et fonctionnalités leur sont ajoutées.
Étapes suivantes
En savoir plus sur la structure des attributions de stratégies
Au fil de votre progression dans la gouvernance cloud, vous allez chercher à passer de la gestion manuelle de
chacune des définitions de stratégies sur le Portail Azure ou à l’aide des différents kits de développement logiciel
(SDK) à un processus plus gérable et reproductible à l’échelle de l’entreprise. Voici deux des approches
prédominantes de la gestion des systèmes à grande échelle dans le cloud :
Infrastructure as Code : pratique consistant à traiter en tant que code source tout le contenu qui définit les
environnements, des modèles Resource Manager aux définitions Azure Policy en passant par Azure Blueprints.
DevOps : rassemblement des personnes, des processus et des produits qui permettent une livraison continue de
valeur ajoutée aux clients finaux.
Le Policy as Code (« stratégie sous forme de code ») est la combinaison de ces idées. Pour l’essentiel, vous
conservez vos définitions de stratégies dans le contrôle de code source, et testez et validez chaque modification
effectuée. Toutefois, l’implication des stratégies avec l’Infrastructure as Code ou le DevOps ne devrait pas s’arrêter
là.
L’étape de validation devrait également être un composant d’autres workflows d’intégration continue ou de
déploiement continu. Citons notamment le déploiement d’un environnement d’application ou d’une infrastructure
virtuelle. En faisant de la validation Azure Policy l’un des premiers composants du processus de build et de
déploiement, les équipes chargées des applications et des opérations détectent si leurs modifications ne sont pas
conformes bien avant qu’il ne soit trop tard et qu’il faille les déployer en production.
Vue d’ensemble du workflow

Le workflow Policy as Code général recommandé se présente comme ce diagramme :
Créer et mettre à jour des définitions de stratégies

Les définitions de stratégies sont créées avec des fichiers JSON et stockées dans le contrôle de code source.
Chaque stratégie possède son propre ensemble de fichiers (paramètres, règles et paramètres d’environnement) qui
doivent être stockés dans le même dossier. Nous vous recommandons la structure suivante pour conserver vos
définitions de stratégies dans le contrôle de code source.
.
|
|- policies/ ________________________ # Root folder for policies
| |- policy1/ ______________________ # Subfolder for a policy
| |- policy.json _________________ # Policy definition
| |- policy.parameters.json ______ # Policy definition of parameters
| |- policy.rules.json ___________ # Policy rule
| |- params.dev.json _____________ # Parameters for a Dev environment
| |- params.prd.json _____________ # Parameters for a Prod environment
| |- params.tst.json _____________ # Parameters for a Test environment
|
| |- policy2/ ______________________ # Subfolder for a policy
| |- policy.json _________________ # Policy definition
| |- policy.parameters.json ______ # Policy definition of parameters
| |- policy.rules.json ___________ # Policy rule
|
Lorsqu’une stratégie est mise à jour ou qu’une nouvelle est ajoutée, le workflow doit automatiquement mettre à
jour la définition de stratégie dans Azure. Le test de la définition de stratégie ajoutée ou mise à jour sera effectué
dans une étape ultérieure.
Créer et mettre à jour des définitions d’initiatives
De même, les initiatives ont leur propre fichier JSON et les fichiers associés qui doivent être stockés dans le même
dossier. La définition de l’initiative exige que la définition de stratégie existe déjà. Vous ne pouvez donc pas la créer
ni la mettre à jour tant que la source de la stratégie n’a pas été mise à jour dans le contrôle de code source, puis
dans Azure. Nous vous recommandons la structure suivante pour conserver vos définitions d’initiatives dans le
contrôle de code source :
.
|
|- initiatives/ ______________________ # Root folder for initiatives
| |- init1/ _________________________ # Subfolder for an initiative
| |- policyset.json ______________ # Initiative definition
| |- policyset.definitions.json __ # Initiative list of policies
| |- policyset.parameters.json ___ # Initiative definition of parameters
|
| |- init2/ _________________________ # Subfolder for an initiative
| |- policyset.json ______________ # Initiative definition
| |- policyset.definitions.json __ # Initiative list of policies
| |- policyset.parameters.json ___ # Initiative definition of parameters
|
Comme pour les définitions de stratégies, à l’ajout ou la mise à jour d’une initiative existante, le workflow doit
automatiquement mettre à jour la définition d’initiative dans Azure. Le test de la définition d’initiative ajoutée ou
mise à jour sera effectué dans une étape ultérieure.
Tester et valider la définition mise à jour
Maintenant que l’automatisation s’est occupée des définitions de stratégies ou d’initiatives créées ou mises à jour et
a effectué la mise à jour sur l’objet dans Azure, il est temps de tester les modifications apportées. La stratégie ou la
(ou les) initiative(s) à laquelle (auxquelles) elle appartient doit ensuite être affectée aux ressources de
l’environnement le plus éloigné de la production, généralement Dev.
L’affectation doit utiliser enforcementMode disabled afin que la création et la mise à jour des ressources ne soient
pas bloquées, mais que la conformité des ressources existantes à la définition de stratégie mise à jour soit toujours
auditée. Même avec enforcementMode, il est recommandé que l’étendue d’affectation soit un groupe de ressources
ou un abonnement servant spécialement à valider des stratégies.
NOTE
Si enforcementMode est utile, il ne remplace pas pour autant un test rigoureux d’une définition de stratégie dans différentes
conditions. La définition de stratégie doit être testée avec des appels d’API REST PUT et PATCH , des ressources conformes
et non conformes, ainsi que des cas limites comme une propriété manquantes dans la ressource.
Une fois l’affectation déployée, utilisez le kit SDK Policy pour récupérer ses données de conformité.
L’environnement servant à tester les stratégies et les affectations doit comporter à la fois des ressources
conformes et des ressources non conformes. À l’instar d’un bon test unitaire pour le code, il est important de
vérifier que les ressources sont bien celles escomptées et qu’il n’y a pas de faux positifs ou de faux négatifs. Si vous
vous contentez de tester et de valider ce que vous attendez, la stratégie risque d’avoir un impact imprévu et non
identifié. Pour plus d’informations, voir Évaluer l’impact d’une nouvelle stratégie Azure.
Activer les tâches de correction
Si la validation de l’affectation répond aux attentes, il s’agit ensuite de valider la correction. Les stratégies qui
utilisent deployIfNotExists ou modify peuvent être transformées en une tâche de correction des ressources non
conformes.
La première étape consiste à accorder à l’affectation de stratégie l’attribution de rôle définie dans la définition de
stratégie. Cette attribution de rôle accorde à l’identité managée de l’affectation de stratégie des droits suffisants
pour apporter les modifications permettant de rendre la ressource conforme.
Dès que l’affectation de stratégie dispose des autorisations nécessaires, utilisez le kit SDK Policy pour déclencher
une tâche de correction sur un ensemble de ressources connues pour être non conformes. Avant de continuer, trois
tests doivent être effectués sur ces tâches corrigées :
Vérifier que la tâche de correction a réussi
Exécuter l’évaluation de la stratégie pour voir si les résultats de conformité de la stratégie ont été mis à jour
comme prévu
Exécuter un test unitaire d’environnement directement sur les ressources pour vérifier que leurs propriétés ont
changé
Le fait de tester à la fois les résultats de l’évaluation de la stratégie mise à jour et l’environnement lui-même permet
de confirmer que les tâches de correction ont changé ce qui était attendu et que la définition de stratégie a constaté
la modification de conformité comme prévu.
Mettre à jour pour appliquer les affectations
Une fois toutes les épreuves de validation effectuées, mettez à jour l’affectation pour utiliser enforcementMode
enabled. Cette modification doit de préférence être effectuée au départ dans le même environnement éloigné de la
production. Après vérification que cet environnement fonctionne comme prévu, la modification doit être étendue
de façon à inclure l’environnement suivant, et ainsi de suite jusqu’à ce que la stratégie soit déployée sur les
ressources de production.
Traiter les évaluations intégrées

Le workflow Policy as Code général vise à développer et à déployer des stratégies et des initiatives dans un
environnement à grande échelle. Toutefois, l’évaluation de la stratégie doit faire partie du processus de
déploiement de tous les workflows qui déploient ou créent des ressources dans Azure, par exemple le déploiement
d’applications ou l’exécution de modèles Resource Manager dans le but de créer une infrastructure.
Dans ce cas, une fois le déploiement de l’application ou de l’infrastructure effectué sur un abonnement ou un
groupe de ressources de test, l’évaluation de la stratégie doit être effectuée pour cette validation de toutes les
stratégies et initiatives existantes. Bien qu’elles puissent être configurées comme enforcementMode disabled
dans un environnement de ce type, il est utile de savoir très vite si le déploiement d’une application ou d’une
infrastructure est contraire aux définitions de stratégies. Cette évaluation de stratégie doit donc constituer une
étape de ces workflows et faire échouer les déploiements qui créent des ressources non conformes.
Révision
Cet article traite du workflow Policy as Code général et explique que l’évaluation de la stratégie doit faire partie
d’autres workflows de déploiement. Ce workflow peut être utilisé dans n’importe quel environnement prenant en
charge les scripts et l’automatisation par déclencheurs.
Étapes suivantes
En savoir plus sur la structure des attributions de stratégies
Azure Policy s’intègre à Azure Kubernetes Service (AKS ) afin d’appliquer à grande échelle des mesures et des
protections sur vos clusters d’une manière centralisée et cohérente. En étendant l’utilisation de Gatekeeper v2, un
webhook de contrôleur d’admission pour Open Policy Agent (OPA), Azure Policy vous permet de gérer l’état de
conformité de vos ressources Azure et clusters AKS et de créer des rapports à partir d’un seul endroit.
NOTE
Azure Policy pour AKS est en préversion limitée et prend uniquement en charge les définitions de stratégie intégrées.
Vue d’ensemble
Pour activer et utiliser Azure Policy pour AKS avec votre cluster AKS, effectuez les étapes suivantes :
Adhérer aux fonctionnalités d’évaluation
Installer le module complémentaire Azure Policy
Affecter une définition de stratégie pour AKS
Attendre la validation
S’inscrire à la préversion
Avant d’installer le module Azure Policy ou d’activer toute fonctionnalité de service, votre abonnement doit activer
le fournisseurs de ressources Microsoft.ContainerService et Microsoft.PolicyInsights, puis être approuvé
pour adhérer à la préversion. Pour vous inscrire à la préversion, effectuez ces étapes dans le portail Azure ou avec
Azure CLI :
Portail Azure :
1. Inscrivez les fournisseurs de ressources Microsoft.ContainerService et Microsoft.PolicyInsights.
Pour connaître les étapes, consultez Types et fournisseurs de ressources.
2. Lancez le service Azure Policy dans le portail Azure en cliquant sur Tous les services, puis en
recherchant et en cliquant sur Stratégie.
3. Sélectionnez S’inscrire à la préversion sur le côté gauche de la page Azure Policy.

4. Sélectionnez la ligne de l’abonnement que vous souhaitez ajouter à la préversion.
5. Sélectionnez le bouton Abonnement en haut de la liste des abonnements.
Azure CLI :
# Log in first with az login if you're not using Cloud Shell
# Provider register: Register the Azure Kubernetes Services provider

az provider register --namespace Microsoft.ContainerService
# Provider register: Register the Azure Policy provider

az provider register --namespace Microsoft.PolicyInsights
# Feature register: enables installing the add-on

az feature register --namespace Microsoft.ContainerService --name AKS-AzurePolicyAutoApprove
# Use the following to confirm the feature has registered

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKS-
AzurePolicyAutoApprove')].{Name:name,State:properties.state}"
# Once the above shows 'Registered' run the following to propagate the update
az provider register -n Microsoft.ContainerService
# Feature register: enables the add-on to call the Azure Policy resource provider
az feature register --namespace Microsoft.PolicyInsights --name AKS-DataplaneAutoApprove
# Use the following to confirm the feature has registered

az feature list -o table --query "[?contains(name, 'Microsoft.PolicyInsights/AKS-
DataPlaneAutoApprove')].{Name:name,State:properties.state}"
# Once the above shows 'Registered' run the following to propagate the update
az provider register -n Microsoft.PolicyInsights
Module complémentaire Azure Policy

Le module complémentaire Azure Policy pour Kubernetes connecte le service Azure Policy au contrôleur
d’admission Gatekeeper. Le module complémentaire, qui est installé dans l’espace de noms azure-policy, effectue
les opérations suivantes :
Il vérifie auprès d’Azure Policy quelles sont les affectations au cluster AKS
Il télécharge et met en cache les détails de la stratégie, notamment la définition de stratégie rego, en tant que
configmaps
Il exécute une analyse complète afin de vérifier la conformité sur le cluster AKS
Il fournit des rapports d’audit et de conformité à Azure Policy
Installation du module complémentaire
Avant d’installer le module complémentaire dans votre cluster AKS, vous devez installer l’extension de préversion.
Vous pouvez effectuer cette étape avec Azure CLI :
1. Azure CLI 2.0.62 ou version ultérieure doit être installé et configuré. Exécutez az --version pour trouver la
version. Si vous devez effectuer une installation ou une mise à niveau, consultez Installer Azure CLI.
2. Le cluster AKS doit être de version 1.10 ou ultérieure. Utilisez le script suivant pour valider la version de
votre cluster AKS :
# Look for the value in kubernetesVersion

az aks list
3. Installez la version 0.4.0 de l’extension de préversion Azure CLI pour AKS, aks-preview :
# Install/update the preview extension

az extension add --name aks-preview
# Validate the version of the preview extension

az extension show --name aks-preview --query [version]
NOTE
Si vous avez installé précédemment l’extension aks-preview, installez toutes les mises à jour à l’aide de la commande
az extension update --name aks-preview .
Procédure d’installation :
Une fois les prérequis satisfaits, installez le module complémentaire Azure Policy dans le cluster AKS que vous
souhaitez gérer.
Portail Azure
1. Lancez le service AKS dans le portail Azure en cliquant sur Tous les services, puis en recherchant et
en cliquant sur services Kubernetes.
2. Sélectionnez l’un de vos clusters AKS.
3. Sélectionnez Stratégies (préversion) sur le côté gauche de la page du service Kubernetes.
4. Dans la page principale, sélectionnez le bouton Activer un module complémentaire.
NOTE
Si le bouton Activer un module complémentaire est grisé, l’abonnement n’a pas encore été ajouté à la
préversion. Pour connaître les étapes requises, consultez S’inscrire à la préversion.
Azure CLI
az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
Fréquence de la validation et des rapports

Le module complémentaire contacte Azure Policy toutes les cinq minutes pour vérifier si des modifications ont été
apportées aux affectations de stratégie. Pendant ce cycle d’actualisation, le module complémentaire supprime tous
les configmaps dans l’espace de noms azure-policy, puis recrée les configmaps pour une utilisation par
Gatekeeper.
NOTE
Bien qu’un administrateur de cluster puisse être autorisé à accéder à l’espace de noms azure-policy, les modifications de
l’espace de noms ne sont ni recommandées ni prises en charge. Toute modification manuelle apportée est perdue lors du
cycle d’actualisation.
Toutes les cinq minutes, le module complémentaire demande une analyse complète du cluster. Après la collecte
des détails de l’analyse complète et les évaluations en temps réel faites par Gatekeeper des tentatives de
modification du cluster, le module complémentaire renvoie les résultats à Azure Policy pour les inclure dans les
détails de conformité comme toute affectation Azure Policy. Seuls les résultats des affectations de stratégie actives
sont renvoyés au cours du cycle d’audit.
Langage de stratégie
La structure du langage Azure Policy pour la gestion d’AKS suit celle des stratégies existantes. L’effet
EnforceRegoPolicy est utilisé pour gérer vos clusters AKS et prend des propriétés details propres à l’utilisation
d’OPA et de Gatekeeper v2. Pour plus d’informations et pour obtenir des exemples, consultez l’effet
EnforceRegoPolicy.
Dans le cadre de la propriété details.policy dans la définition de stratégie, Azure Policy transmet l’URI d’une
stratégie rego au module complémentaire. Rego est le langage pris en charge par OPA et Gatekeeper pour valider
ou muter une requête au cluster Kubernetes. Grâce à la prise en charge d’une norme existante pour la gestion de
Kubernetes, Azure Policy permet de réutiliser des règles existantes et de les jumeler avec Azure Policy afin de
bénéficier d’une expérience de rapports de conformité du cloud unifiée. Pour plus d’informations, consultez What
is Rego?.
Pour rechercher les stratégies prédéfinies pour la gestion d’AKS à l’aide du portail Azure, effectuez les étapes
suivantes :
1. Démarrez le service Azure Policy dans le portail Azure. Sélectionnez Tous les services dans le volet
gauche, puis recherchez et sélectionnez Stratégie.
2. Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
3. Dans la zone de liste déroulante Catégorie, utilisez Sélectionner tout pour effacer le filtre, puis
sélectionnez service Kubernetes.
4. Sélectionnez la définition de stratégie, puis sélectionnez le bouton Affecter.
NOTE
Lors de l’affectation de la définition Azure Policy pour AKS, l’Étendue doit inclure la ressource de cluster AKS.
Vous pouvez également utiliser le guide de démarrage rapide Attribuer une stratégie - Portail pour rechercher et
attribuer une stratégie AKS. Recherchez une définition de stratégie Kubernetes au lieu de l’exemple « audit vms ».
IMPORTANT
Les stratégies intégrées de la catégorie service Kubernetes sont uniquement destinées à être utilisées avec AKS.
Journalisation
Journaux du module complémentaire Azure Policy
En tant que conteneur/contrôleur Kubernetes, le module complémentaire Azure Policy conserve des journaux
dans le cluster AKS. Les journaux sont exposés dans la page Insights du cluster AKS. Pour plus d’informations,
consultez Présentation des performances de cluster AKS avec Azure Monitor pour conteneurs.
Journaux Gatekeeper
Pour activer les journaux Gatekeeper pour les nouvelles demandes de ressources, suivez les étapes indiquées dans
l’article Activer et consulter les journaux du nœud principal Kubernetes dans AKS. Voici un exemple de requête
pour afficher les événements refusés sur les nouvelles demandes de ressources :
| where Category == "kube-audit"

| where log_s contains "admission webhook"
| limit 100
Pour afficher les journaux des conteneurs Gatekeeper, suivez les étapes indiquées dans l’article Activer et consulter
les journaux du nœud principal Kubernetes dans AKS et cochez l’option kube-apiserver dans le volet Paramètres
de diagnostic.
Supprimer le module complémentaire

Pour supprimer le module complémentaire Azure Policy de votre cluster AKS, utilisez le Portail Azure ou
Azure CLI :
Portail Azure
1. Lancez le service AKS dans le portail Azure en cliquant sur Tous les services, puis en recherchant et
en cliquant sur services Kubernetes.
2. Sélectionnez le cluster AKS dans lequel vous souhaitez désactiver le module complémentaire Azure
Policy.
3. Sélectionnez Stratégies (préversion) sur le côté gauche de la page du service Kubernetes.
4. Dans la page principale, sélectionnez le bouton Désactiver un module complémentaire.

Azure CLI
az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
Données de diagnostic collectées par le module complémentaire Azure

Policy
Le module complémentaire Azure Policy pour Kubernetes collecte une quantité limitée de données de diagnostics
de cluster. Ces données de diagnostic sont des données techniques vitales concernant les logiciels et le niveau de
performance. Elles sont utilisées de différentes manières :
Tenir à jour le module complémentaire Azure Policy
Maintenir la sécurité, la fiabilité et le niveau de performance du module complémentaire Azure Policy
Améliorer le module complémentaire Azure Policy à travers l’analyse globale de son utilisation
Les informations collectées par le module complémentaire ne sont pas des données personnelles. Les détails
suivants sont actuellement recueillis :
Version de l’agent du module complémentaire Azure Policy
Type de cluster
Région du cluster
Groupe de ressources de cluster
ID de la ressource de cluster
ID de l’abonnement du cluster
Système d’exploitation du cluster (exemple : Linux)
Ville du cluster (exemple : Seattle)
État ou province du cluster (exemple : Washington)
Pays ou région du cluster (exemple : États-Unis)
Exceptions/erreurs rencontrées par le module complémentaire Azure Policy lors de l’installation de l’agent
concernant l’évaluation de la stratégie
Nombre de stratégies Gatekeeper non installées par le module complémentaire Azure Policy
Étapes suivantes
Consultez la page Structure de définition Azure Policy.
Azure Policy s’intègre à AKS Engine, un système qui offre des outils pratiques permettant de démarrer rapidement
un cluster Kubernetes autogéré sur Azure. Cette intégration permet une mise en œuvre et une protection
centralisées et cohérentes à grande échelle sur des clusters autogérés AKS Engine. En étendant l’utilisation d’Open
Policy Agent (OPA) Gatekeeper v3 (bêta), un webhook contrôleur d’admission pour Kubernetes, Azure Policy vous
permet de gérer et de signaler l’état de conformité de vos ressources Azure et clusters autogérés AKS Engine en
un seul endroit.
NOTE
Azure Policy pour AKS Engine est en préversion publique et n’a pas de contrat SLA. Gatekeeper v3 est en version bêta et est
pris en charge par la communauté open source. Le service ne gère que les définitions de stratégies intégrées et un seul
cluster AKS Engine par groupe de ressources configuré avec un principal de service.
IMPORTANT
Pour obtenir un support sur Azure Policy pour AKS Engine, AKS Engine ou Gatekeeper v3, créez un nouveau problème dans
le référentiel GitHub AKS Engine.
Vue d’ensemble
Pour activer et utiliser Azure Policy pour AKS Engine avec votre cluster Kubernetes autogéré sur Azure, effectuez
les actions suivantes :
Composants requis
Installer le module complémentaire Azure Policy
Affecter une définition de stratégie pour AKS Engine
Attendre la validation

Avant d’installer le module complémentaire Azure Policy ou d’activer des fonctionnalités du service, vous devez
activer le fournisseur de ressources Microsoft.PolicyInsights et créer une attribution de rôle pour le principal de
service du cluster dans votre abonnement.
1. Pour activer le fournisseur de ressources, suivez les étapes décrites dans Fournisseurs de ressources et
types ou exécutez la commande Azure CLI ou Azure PowerShell :
Azure CLI

az provider register --namespace 'Microsoft.PolicyInsights'
Azure PowerShell
# Log in first with Connect-AzAccount if you're not using Cloud Shell

2. Créer une attribution de rôle pour le principal de service du cluster

Si vous ne connaissez pas l’ID de l’application du principal de service du cluster, cherchez-le avec la
commande suivante.
# Get the kube-apiserver pod name

kubectl get pods -n kube-system
# Find the aadClientID value

kubectl exec <kube-apiserver pod name> -n kube-system cat /etc/kubernetes/azure.json
Affectez l’attribution de rôle « Policy Insights Data Writer (Preview ) » à l’ID de l’application du
principal de service du cluster (valeur aadClientID de l’étape précédente) avec Azure CLI. Remplacez
<subscriptionId> par votre ID d’abonnement et <aks engine cluster resource group> par le groupe
de ressources dans lequel se trouve le cluster Kubernetes autogéré AKS Engine.
az role assignment create --assignee <cluster service principal app ID> --scope
"/subscriptions/<subscriptionId>/resourceGroups/<aks engine cluster resource group>" --role
"Policy Insights Data Writer (Preview)"
Module complémentaire Azure Policy

Le module complémentaire Azure Policy pour Kubernetes connecte le service Azure Policy au contrôleur
d’admission Gatekeeper. Ce module, installé dans l’espace de noms kube-system, exerce les fonctions suivantes :
Il vérifie auprès d’Azure Policy quelles sont les affectations au cluster AKS Engine
Il télécharge et installe les détails de la stratégie, les modèles de contrainte et les contraintes
Il exécute une analyse complète afin de vérifier la conformité sur le cluster AKS Engine
Il fournit des rapports d’audit et de conformité à Azure Policy
Installation du module complémentaire
Une fois les prérequis remplis, le module complémentaire Azure Policy peut être installé. L’installation peut être
effectuée pendant le cycle de création ou de mise à jour d’un moteur AKS Engine ou comme action indépendante
sur un cluster existant.
Effectuer l’installation pendant le cycle de création ou de mise à jour
Pour activer le module complémentaire Azure Policy lors de la création d’un cluster autogéré ou comme
mise à jour d’un cluster existant, ajoutez la définition du cluster de propriétés addons pour AKS Engine.
"addons": [{
"name": "azure-policy",
"enabled": true,
"config": {
"auditInterval": "30",
"constraintViolationsLimit": "20"
}
}]
Pour plus d’informations à ce sujet, voir le guide externe Définition du cluster AKS Engine.
Installer un cluster existant avec Helm Charts
Suivez les étapes ci-dessous pour préparer le cluster et installer le module complémentaire :
1. Installez Gatekeeper sur l’espace de noms gatekeeper-system.
kubectl apply -f https://raw.githubusercontent.com/open-policy-

agent/gatekeeper/master/deploy/gatekeeper.yaml
2. Ajoutez l’étiquette control-plane à kube-system. Elle exclut l’audit des pods et services Kube-System
par Gatekeeper et le module complémentaire Azure Policy.
kubectl label namespaces kube-system control-plane=controller-manager
3. Synchronisez les données Kubernetes (espace de noms, pod, entrée, service) avec OPA.
kubectl apply -f https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-

references/Kubernetes/gatekeeper-opa-sync.yaml
Pour plus d’informations, voir OPA – Répliquer des données.

4. Ajoutez le référentiel Azure Policy à Helm.
helm repo add azure-policy https://raw.githubusercontent.com/Azure/azure-

policy/master/extensions/policy-addon-kubernetes/helm-charts
Pour plus d’informations, voir Chart Helm – Guide de démarrage rapide.

5. Installez le module complémentaire avec un chart Helm. Remplacez <subscriptionId> par votre ID
d’abonnement et <aks engine cluster resource group> par le groupe de ressources dans lequel se
trouve le cluster Kubernetes autogéré AKS Engine.
helm install azure-policy/azure-policy-addon-aks-engine --name azure-policy-addon --set

azurepolicy.env.resourceid="/subscriptions/<subscriptionId>/resourceGroups/<aks engine cluster
resource group>"
Pour plus d’informations sur les composants installés par le module complémentaire Helm Chart,
voir la Définition du module complémentaire Helm Chart Azure Policy sur GitHub.
NOTE
En raison de la relation entre le module complémentaire Azure Policy et l’ID du groupe de ressources, Azure
Policy ne prend en charge qu’un seul cluster AKS Engine par groupe de ressources.
Pour vérifier que l’installation du module complémentaire a réussi et que le pod azure-policy est en cours
d’exécution, exécutez la commande suivante :
kubectl get pods -n kube-system
Fréquence de la validation et des rapports

Le module complémentaire contacte Azure Policy toutes les cinq minutes pour vérifier si des modifications ont été
apportées aux affectations de stratégie. Pendant ce cycle d’actualisation, le module complémentaire recherche
d’éventuelles modifications, qui déclenchent la création, la mise à jour ou la suppression des modèles de contrainte
et des contraintes.
NOTE
Si un administrateur de cluster peut avoir l’autorisation d’apporter des modifications aux modèles de contrainte et aux
contraintes, il n’est en revanche pas recommandé ni possible d’apporter des modifications aux modèles de contrainte ou aux
contraintes créés par Azure Policy. Toute modification manuelle apportée est perdue lors du cycle d’actualisation.
Toutes les cinq minutes, le module complémentaire demande une analyse complète du cluster. Après la collecte
des détails de l’analyse complète et les évaluations en temps réel faites par Gatekeeper des tentatives de
modification du cluster, le module complémentaire renvoie les résultats à Azure Policy pour les inclure dans les
détails de conformité comme toute affectation Azure Policy. Seuls les résultats des affectations de stratégie actives
sont renvoyés au cours du cycle d’audit. Les résultats d’audit peuvent également être considérés comme des
violations indiquées dans le champ d’état de la contrainte non réussie.
Langage de stratégie
La structure du langage Azure Policy pour la gestion d’AKS Engine suit celle des stratégies existantes. L’effet
EnforceOPAConstraint, qui permet de gérer les clusters AKS Engine, prend des propriétés details propres au
Framework de contraintes d’OPA et à Gatekeeper v3. Pour plus d’informations et pour obtenir des exemples, voir
l’effet EnforceOPAConstraint.
Au sein des propriétés details.constraintTemplate et details.constraint de la définition de stratégie, Azure Policy
transmet les URI de ces CustomResourceDefinitions (CRD ) au module complémentaire. Rego est le langage pris
en charge par OPA et Gatekeeper pour valider une requête au cluster Kubernetes. Grâce à la prise en charge d’une
norme existante pour la gestion de Kubernetes, Azure Policy permet de réutiliser des règles existantes et de les
jumeler avec Azure Policy afin de bénéficier d’une expérience de rapports de conformité du cloud unifiée. Pour
plus d’informations, consultez What is Rego?.
Pour rechercher les stratégies prédéfinies permettant de gérer un cluster AKS Engine avec le Portail Azure, suivez
les étapes ci-dessous :
1. Démarrez le service Azure Policy dans le portail Azure. Sélectionnez Tous les services dans le volet
gauche, puis recherchez et sélectionnez Stratégie.
2. Dans le volet gauche de la page Azure Policy, sélectionnez Définitions.
3. Dans la zone de liste déroulante Catégorie, utilisez Sélectionner tout pour effacer le filtre, puis
sélectionnez Kubernetes.
4. Sélectionnez la définition de stratégie, puis sélectionnez le bouton Affecter.
NOTE
Dans le cadre de l’affectation de la définition Azure Policy pour AKS Engine, l’Étendue doit être le groupe de ressources du
cluster AKS Engine.
Vous pouvez également utiliser le démarrage rapide Affecter une stratégie – Portail pour trouver et attribuer une
stratégie AKS Engine. Recherchez une définition de stratégie AKS Engine au lieu de l’exemple « audit vms ».
IMPORTANT
Les stratégies intégrées de la catégorie Kubernetes sont destinées à être utilisées exclusivement avec AKS Engine.
Journalisation
Journaux du module complémentaire Azure Policy
Le module complémentaire Azure Policy étant un contrôleur/conteneur Kubernetes, il conserve les journaux dans
le cluster AKS Engine.
Pour consulter les journaux du module complémentaire Azure Policy, utilisez kubectl :
# Get the Azure Policy Add-on pod name

kubectl -n kube-system get pods -l app=azure-policy --output=name
# Get the logs for the add-on

kubectl logs <Azure Policy Add-on pod name> -n kube-system
Journaux Gatekeeper
Le pod Gatekeeper, gatekeeper-controller-manager-0, se trouve généralement dans l’espace de noms
gatekeeper-system ou kube-system , mais il peut apparaître dans un autre espace de noms selon la façon dont il est
déployé.
Pour afficher les journaux Gatekeeper, utilisez kubectl :
NAMESPACE=<namespace of gatekeeper>
kubectl logs gatekeeper-controller-manager-0 -n $NAMESPACE
Pour plus d’informations, voir Déboguer Gatekeeper dans la documentation OPA.
Supprimer le module complémentaire

Pour supprimer le module complémentaire Azure Policy et Gatekeeper de votre cluster AKS Engine, utilisez la
méthode correspondant à la façon dont le module a été installé :
S’il a été installé en définissant la propriété addons dans la définition du cluster pour AKS Engine :
Redéployez la définition du cluster sur AKS Engine après avoir modifié la propriété addons pour azure-
policy en lui donnant la valeur false :
"addons": [{
"name": "azure-policy",
"enabled": false
}]
S’il a été installé avec Helm Charts :

1. Supprimez les anciennes contraintes.
Actuellement, le mécanisme de désinstallation supprime uniquement le système Gatekeeper, et non
les ressources ConstraintTemplate, _Constraint_et Config créées par l’utilisateur, ni les CRD qui les
accompagnent.
Lorsque Gatekeeper est en cours d’exécution, il est possible de supprimer les contraintes
indésirables :
Supprimez toutes les instances de la ressource de contrainte.
Supprimez la ressource ConstraintTemplate, ce qui devrait nettoyer automatiquement le CRD.
Le fait de supprimer la ressource Config a pour effet de supprimer les finaliseurs sur les
ressources synchronisées.
2. Désinstaller le module complémentaire Azure Policy
helm del --purge azure-policy-addon
3. Désinstaller Gatekeeper
kubectl delete -f https://raw.githubusercontent.com/open-policy-

agent/gatekeeper/master/deploy/gatekeeper.yaml
Données de diagnostic collectées par le module complémentaire Azure

Policy
Le module complémentaire Azure Policy pour Kubernetes collecte une quantité limitée de données de diagnostics
de cluster. Ces données de diagnostic sont des données techniques vitales concernant les logiciels et le niveau de
performance. Elles sont utilisées de différentes manières :
Tenir à jour le module complémentaire Azure Policy
Maintenir la sécurité, la fiabilité et le niveau de performance du module complémentaire Azure Policy
Améliorer le module complémentaire Azure Policy à travers l’analyse globale de son utilisation
Les informations collectées par le module complémentaire ne sont pas des données personnelles. Les détails
suivants sont actuellement recueillis :
Version de l’agent du module complémentaire Azure Policy
Type de cluster
Région du cluster
Groupe de ressources de cluster
ID de la ressource de cluster
ID de l’abonnement du cluster
Système d’exploitation du cluster (exemple : Linux)
Ville du cluster (exemple : Seattle)
État ou province du cluster (exemple : Washington)
Pays ou région du cluster (exemple : États-Unis)
Exceptions/erreurs rencontrées par le module complémentaire Azure Policy lors de l’installation de l’agent
concernant l’évaluation de la stratégie
Nombre de stratégies Gatekeeper non installées par le module complémentaire Azure Policy
Étapes suivantes
Consultez la page Structure de définition Azure Policy.
En plus de l’audit et de la correction des ressources Azure, Azure Policy peut auditer les paramètres internes d’une
machine. La validation est effectuée par le client et l’extension de configuration d’invité. L’extension, via le client,
valide des paramètres tels que :
La configuration du système d’exploitation
La configuration ou la présence de l’application
Paramètres d'environnement
À ce stade, la configuration d’invité Azure Policy effectue uniquement un audit des paramètres à l’intérieur de la
machine. Elle n’applique pas de configurations.
Extension et client
Pour auditer les paramètres à l’intérieur d’une machine, une extension de machine virtuelle est activée. L’extension
télécharge l’attribution de stratégie applicable et la définition de configuration correspondante.
Limites définies sur l’extension
Pour limiter l’impact de l’extension sur les applications qui s’exécutent à l’intérieur de la machine, la configuration
d’invité ne peut pas dépasser plus de 5 % de l’utilisation du processeur. Cette limitation existe à la fois pour les
définitions intégrées et personnalisées.
Inscrire le fournisseur de ressources de configuration d’invité

Avant de pouvoir utiliser la configuration d’invité, vous devez inscrire le fournisseur de ressources. Pour ce faire,
vous pouvez utiliser le portail ou PowerShell. Le fournisseur de ressources est inscrit automatiquement si
l’affectation d’une stratégie de configuration d’invité est effectuée via le portail.
Inscription - portail
Pour inscrire le fournisseur de ressources pour la configuration d’invité via le portail Azure, effectuez les étapes
suivantes :
1. Lancez le portail Azure et cliquez sur Tous les services. Recherchez et sélectionnez Abonnements.
2. Recherchez l’abonnement pour lequel vous souhaitez activer la configuration d’invité et cliquez dessus.
3. Dans le menu de gauche de la page Abonnement, cliquez sur Fournisseurs de ressources.
4. Filtrez ou faites défiler jusqu’à ce que vous localisiez Microsoft.GuestConfiguration, puis cliquez sur
Inscrire sur la même ligne.
Inscription - PowerShell
Pour inscrire le fournisseur de ressources pour la configuration d’invité via PowerShell, exécutez la commande
suivante :

Register-AzResourceProvider -ProviderNamespace 'Microsoft.GuestConfiguration'
Outils de validation
À l’intérieur de la machine, le client de configuration d’invité utilise des outils locaux pour exécuter l’audit.
Le tableau suivant affiche une liste des outils locaux utilisés sur chaque système d’exploitation pris en charge :
SYSTÈME D’EXPLOITATION OUTIL DE VALIDATION NOTES
Windows Configuration d’état souhaité Windows

PowerShell v2
Linux Chef InSpec Ruby et Python sont installés par

l’extension de configuration d’invité.
Fréquence de validation
Le client de configuration d'invité vérifie le nouveau contenu toutes les 5 minutes. Une fois l'affectation d'invité
reçue, les paramètres sont vérifiés à intervalle de 15 minutes. Les résultats sont envoyés au fournisseur de
ressources de configuration d’invité dès la fin de l’audit. Lorsqu'un déclencheur d’évaluation de stratégie
intervient, l'état de la machine est consigné dans le fournisseur de ressources de configuration d'invité. Avec cette
mise à jour, Azure Policy évalue alors les propriétés Azure Resource Manager. Une évaluation Azure Policy à la
demande récupère la valeur la plus récente du fournisseur de ressources de configuration d'invité. Cela étant, elle
ne déclenche pas de nouvel audit de la configuration de la machine.
Types de clients pris en charge

Le tableau suivant affiche une liste des systèmes d’exploitation pris en charge sur des images Azure :
SERVEUR DE PUBLICATION NOM VERSIONS
Canonical Serveur Ubuntu 14.04, 16.04, 18.04
Credativ Debian 8, 9
Microsoft Windows Server 2012 Datacenter, 2012 R2 Datacenter,

2016 Datacenter, 2019 Datacenter
Microsoft Client Windows Windows 10
OpenLogic CentOS 7.3, 7.4, 7.5
Red Hat Red Hat Enterprise Linux 7.4, 7.5
SUSE SLES 12 SP3
IMPORTANT
La configuration d’invité peut auditer les nœuds exécutant un système d’exploitation pris en charge. Si vous souhaitez
auditer des machines virtuelles qui utilisent une image personnalisée, vous devez dupliquer la définition DeployIfNotExists
et modifier la section If pour inclure les propriétés de votre image.
Types de clients non pris en charge

Windows Server Nano Server n’est pris en charge dans aucune version.
Configuration réseau requise pour l’extension de configuration d’invité

Pour communiquer avec le fournisseur de ressources de configuration d’invité dans Azure, les machines
nécessitent un accès sortant vers des centres de données Azure sur le port 443. Si vous utilisez un réseau privé
virtuel dans Azure sans autoriser le trafic sortant, vous devez configurer les exceptions à l’aide des règles du
groupe de sécurité réseau. L’étiquette de service « GuestAndHybridManagement » peut être utilisée pour
référencer le service Guest Configuration.
Exigences de définition de la configuration d’invité

Chaque audit exécuté par la configuration d’invité nécessite deux définitions de stratégies : une définition
DeployIfNotExists et une définition AuditIfNotExists. La définition DeployIfNotExists sert à préparer la
machine avec l’agent de configuration d’invité et d’autres composants pour prendre en charge les outils de
validation.
La définition de stratégie DeployIfNotExists valide et corrige les éléments suivants :
Validez qu’une configuration à évaluer a été attribuée à la machine. Si aucune attribution n’est actuellement
présente, procurez-vous cette attribution et préparez la machine en effectuant les opérations suivantes :
Authentification auprès de la machine en utilisant une identité managée
Installation de la dernière version de l’extension Microsoft.GuestConfiguration
Installation des outils de validation et des dépendances, si nécessaire
Si l’attribution de DeployIfNotExists n’est pas conforme, une tâche de correction peut être utilisée.
Une fois que l’attribution de DeployIfNotExists est conforme, l’attribution de la stratégie AuditIfNotExists
utilise les outils de validation locaux pour déterminer si l’attribution de configuration est conforme ou non
conforme. L’outil de validation fournit les résultats au client de configuration d’invité. Le client transmet à
l’extension invité les résultats pour les rendre disponibles via le fournisseur de ressources de la configuration
d’invité.
Azure Policy utilise la propriété complianceStatus des fournisseurs de ressources de configuration d’invité pour
signaler la conformité dans le nœud Conformité. Pour plus d’informations, consultez Obtention de données de
conformité.
NOTE
La stratégie DeployIfNotExists est requise pour que la stratégie AuditIfNotExists retourne des résultats. Sans la stratégie
DeployIfNotExists, la stratégie AuditIfNotExists affiche « 0 sur 0 » ressource comme état.
Toutes les stratégies intégrées pour la configuration d’invité sont incluses dans une initiative pour regrouper les
définitions à utiliser dans les attributions. L’initiative intégré nommée [Préversion] : Auditer les paramètres de
sécurité de mot de passe dans les machines Linux et Windows contient 18 stratégies. Il existe six paires
DeployIfNotExists et AuditIfNotExists pour Windows et trois paires pour Linux. La logique de définition de
stratégie valide que seul le système d’exploitation cible est évalué.
Audit des paramètres du système d’exploitation conformément aux lignes de base du secteur
L’une des initiatives disponibles dans Azure Policy permet d’auditer les paramètres du système d’exploitation à
l’intérieur des machines virtuelles en suivant une « ligne de base » de Microsoft. La définition, [Préversion] :
Auditer les machines virtuelles Windows qui ne correspondent pas aux paramètres de la base de référence de
sécurité Azure comprend un ensemble complet de règles d’audit basées sur les paramètres de stratégie de groupe
Active Directory.
La plupart des paramètres sont disponibles en tant que tels. Cette fonctionnalité vous permet de personnaliser ce
qui est audité afin d’aligner la stratégie sur les besoins de votre organisation, ou de mapper la stratégie à des
informations tierces, telles que des normes réglementaires sectorielles.
Certains paramètres prennent en charge une plage de valeurs entières. Par exemple, le paramètre Âge maximum
du mot de passe peut être défini à l’aide d’un opérateur de plage pour offrir de la flexibilité aux propriétaires
d’ordinateurs. Vous pouvez vérifier que le paramètre de stratégie de groupe effectif exigeant que les utilisateurs
modifient leur mot de passe ne soit pas supérieur à 70 jours ou inférieur à 1 jour. Comme décrit dans l’info-bulle
du paramètre, pour faire de cette stratégie d’entreprise la valeur d’audit effective, définissez la valeur sur « 1,70 ».
Si vous affectez la stratégie à l’aide d’un modèle de déploiement Azure Resource Manager, vous pouvez utiliser un
fichier de paramètres pour gérer ces paramètres à partir du contrôle de code source. L’utilisation d’un outil tel que
Git pour gérer les modifications des stratégies d’audit avec des commentaires à chaque enregistrement permet de
documenter les raisons pour lesquelles une affectation doit être en exception de la valeur attendue.
Application de configurations à l’aide de Guest Configuration
La dernière fonctionnalité d’Azure Policy configure les paramètres à l’intérieur des machines. La définition
Configurer le fuseau horaire sur les machines Windows apporte des modifications à la machine en configurant le
fuseau horaire.
Lorsque vous attribuez des définitions qui commencent par Configurer, vous devez également attribuer la
définition Déployer les composants requis pour activer la stratégie de configuration d’invité sur des machines
virtuelles Windows. Vous pouvez combiner ces définitions dans une initiative.
Attribution de stratégies à des machines en dehors d’Azure
Les stratégies d’audit disponibles pour Guest Configuration incluent le type de ressource
Microsoft.HybridCompute/machines. Toutes les machines intégrées à Azure Arc pour les serveurs qui se
trouvent dans l’étendue de l’attribution de stratégie sont automatiquement incluses.
Affectations multiples
Actuellement, les stratégies de configuration d’invité prennent en charge l’affectation d’une seule affectation
d’invité par machine, même si l’affectation de stratégie utilise des paramètres différents.
Modules de ressources intégrés

Lors de l’installation de l’extension Guest Configuration, le module PowerShell « GuestConfiguration » est inclus
dans la dernière version des modules de ressources DSC. Ce module peut être téléchargé à partir de la
PowerShell Gallery à l’aide du lien « Téléchargement manuel » dans la page du module GuestConfiguration. Le
format de fichier « .nupkg » peut être renommé en « .zip » pour le décompresser et le vérifier.
Fichiers journaux du client

L’extension de configuration d’invité écrit les fichiers journaux aux emplacements suivants :
Windows : C:\Packages\Plugins\Microsoft.GuestConfiguration.ConfigurationforWindows\<version>\dsc\logs\dsc.log
Linux : /var/lib/waagent/Microsoft.GuestConfiguration.ConfigurationforLinux-<version>/GCAgent/logs/dsc.log
Où <version> indique le numéro de la version actuelle.

Collecte des journaux à distance
La première étape de la résolution des problèmes liés aux configurations ou aux modules de Guest Configuration
consiste à utiliser l'applet de commande Test-GuestConfigurationPackage en suivant les étapes décrites dans Tester
un package Guest Configuration. Si cela ne réussit pas, la collecte des journaux des clients peut vous aider à
diagnostiquer les problèmes.
Windows
Pour utiliser la commande Run de la machine virtuelle Azure afin de capturer des informations à partir de fichiers
journaux sur des machines Windows, l’exemple de script PowerShell suivant peut être utile. Pour plus
d’informations, consultez Exécuter des scripts PowerShell dans votre machine virtuelle Windows avec la
commande Run.
$linesToIncludeBeforeMatch = 0
$linesToIncludeAfterMatch = 10
$latestVersion = Get-ChildItem -Path
'C:\Packages\Plugins\Microsoft.GuestConfiguration.ConfigurationforWindows\' | ForEach-Object {$_.FullName} |
Sort-Object -Descending | Select-Object -First 1
Select-String -Path "$latestVersion\dsc\logs\dsc.log" -pattern 'DSCEngine','DSCManagedEngine' -CaseSensitive -
Context $linesToIncludeBeforeMatch,$linesToIncludeAfterMatch | Select-Object -Last 10
Linux
Pour utiliser la commande Run de la machine virtuelle Azure afin de capturer des informations à partir de fichiers
journaux sur des machines Linux, l’exemple de script Bash suivant peut être utile. Pour plus d’informations,
consultez Exécuter des scripts shell dans votre machine virtuelle Linux avec la commande Run
linesToIncludeBeforeMatch=0
linesToIncludeAfterMatch=10
latestVersion=$(find /var/lib/waagent/ -type d -name "Microsoft.GuestConfiguration.ConfigurationforLinux-*" -
maxdepth 1 -print | sort -z | sed -n 1p)
egrep -B $linesToIncludeBeforeMatch -A $linesToIncludeAfterMatch 'DSCEngine|DSCManagedEngine'
"$latestVersion/GCAgent/logs/dsc.log" | tail
Exemples de la configuration d’invité

La source des initiatives intégrées de la configuration d’invité Azure Policy est disponible aux emplacements
suivants :
Définitions de stratégie intégrées - Configuration d’invité
Initiatives intégrées - Configuration d’invité
Exemples Azure Policy - Dépôt GitHub
Étapes suivantes
S’applique à l’extension Azure Policy 0.0.21 et aux versions ultérieures.
Découvrez comment utiliser l’extension Azure Policy pour Visual Studio Code afin de rechercher des alias et de
vérifier les ressources et les stratégies. Tout d’abord, nous décrirons comment installer l’extension Azure Policy
dans Visual Studio Code. Ensuite, nous étudierons comment rechercher des alias.
L’extension Azure Policy pour Visual Studio Code peut être installée sur toutes les plateformes prises en charge
par Visual Studio Code : Windows, Linux et macOS.
NOTE
Les modifications apportées localement aux stratégies qui s’affichent dans l’extension Azure Policy pour Visual Studio Code
ne sont pas synchronisées avec Azure.
Prérequis
Avant de poursuivre cet article, vérifiez que vous avez les éléments nécessaires suivants :
Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Visual Studio Code.
Installer l’extension Azure Policy

Une fois tous les prérequis remplis, vous pouvez installer l’extension Azure Policy pour Visual Studio Code en
suivant les étapes ci-dessous :
1. Ouvrez Visual Studio Code.
2. À partir de la barre de menus, accédez à Afficher > Extensions.
3. Dans la zone de recherche, entrez Azure Policy.
4. Sélectionnez Azure Policy dans les résultats de la recherche, puis sélectionnez Installer.
5. Sélectionnez Recharger si nécessaire.
Configurer l’environnement Azure

Dans le cas d’un utilisateur d’un cloud national, suivez d’abord ces étapes pour configurer l’environnement Azure :
1. Sélectionnez File\Preferences\Settings.
2. Recherchez la chaîne suivante : Azure : Cloud
3. Sélectionnez le cloud national dans la liste :
Se connecter à un compte Azure
Pour pouvoir évaluer des ressources et rechercher des alias, vous devez vous connecter à votre compte Azure.
Suivez ces étapes pour vous connecter à Azure à partir de Visual Studio Code :
1. Connectez-vous à Azure à partir de l’extension Azure Policy ou de la palette de commandes.
Extension Azure Policy
À partir de l’extension Azure Policy, sélectionnez Se connecter à Azure.
Palette de commandes
À partir de la barre de menus, accédez à Afficher > Palette de commandes, puis entrez Azure: Se
connecter.
2. Suivez les instructions de connexion pour vous connecter à Azure. Une fois que vous êtes connecté, le nom
de votre compte Azure s’affiche dans la barre d’état, en bas de la fenêtre Visual Studio Code.
Sélectionner des abonnements

Lors de la première connexion, seules les stratégies et les ressources d’abonnement par défaut sont chargées par
l’extension Azure Policy. Pour ajouter des abonnements aux ressources et aux stratégies qui s’affichent ou en
supprimer, suivez les étapes ci-dessous :
1. Démarrez la commande d’abonnement à partir de la palette de commandes ou du pied de page de la
fenêtre.
Palette de commandes :
Dans la barre de menus, accédez à Afficher > Palette de commandes, puis entrez Azure Policy :
Sélectionner des abonnements.
Pied de page de la fenêtre
Dans le pied de page de la fenêtre en bas de l’écran, sélectionnez le segment correspondant à
Azure : <votre compte> .
2. Utilisez la zone de filtre pour trouver rapidement des abonnements par leur nom. Ensuite, cochez ou
décochez les abonnements pour définir ceux qui seront affichés par l’extension Azure Policy. Une fois que
vous avez terminé d’ajouter ou de supprimer des abonnements, sélectionnez OK.
Rechercher et afficher des ressources

L’extension Azure Policy liste les ressources des abonnements sélectionnés par fournisseur de ressources et par
groupe de ressources dans le volet Ressources. L’arborescence comprend les regroupements de ressources
suivants au sein de l’abonnement sélectionné ou au niveau de l’abonnement :
Fournisseurs de ressources
Chacun des fournisseurs de ressources inscrits avec des ressources et les ressources enfants associées
qui possèdent des alias de stratégie
Groupes de ressources
Toutes les ressources suivant le groupe de ressources dans lequel elles se trouvent
Par défaut, l’extension filtre la partie « Fournisseur de ressources » sur les ressources existantes et les ressources
qui possèdent des alias de stratégie. Modifiez ce comportement dans Paramètres > Extensions > Azure Policy
pour voir tous les fournisseurs de ressources sans filtrage.
Les clients disposant de centaines ou de milliers de ressources dans un même abonnement préféreront
probablement un moyen de trouver leurs ressources avec possibilité de recherche. L’extension Azure Policy
permet de rechercher une ressource spécifique en suivant les étapes suivantes :
1. Lancez l’interface de recherche à partir de l’extension Azure Policy ou de la palette de commandes.
Dans l’extension Azure Policy, placez le curseur sur le panneau Ressources et sélectionnez les points
de suspension, puis Rechercher des ressources.
Dans la barre de menus, accédez à Afficher>Palette de commandes, puis entrez Ressources :
Rechercher des ressources.
2. Si plusieurs abonnements sont sélectionnés pour l’affichage, utilisez le filtre pour sélectionner celui dans
lequel la recherche devra être effectuée.
3. Utilisez le filtre pour sélectionner le groupe de ressources dans lequel la recherche devra être effectuée, au
sein de l’abonnement choisi.
4. Utilisez le filtre pour sélectionner la ressource à afficher. Le filtre fonctionne à la fois pour le nom et le type
de ressource.
Découvrir les alias des propriétés de ressources

Lorsqu’une ressource est sélectionnée, que ce soit par le biais de l’interface de recherche ou dans l’arborescence,
l’extension Azure Policy ouvre le fichier JSON représentant cette ressource et toutes ses valeurs de propriété
Resource Manager.
Lorsqu’une ressource est ouverte, pointez sur le nom ou la valeur de la propriété Resource Manager pour afficher
l’alias Azure Policy s’il en existe un. Dans cet exemple, la ressource a pour type Microsoft.Compute/virtualMachines
et le curseur est placé sur la propriété properties.storageProfile.imageReference.offer, ce qui affiche les alias
correspondants.
Rechercher et afficher des stratégies et des affectations

L’extension Azure Policy liste les types et les affectations de stratégie sous la forme d’une arborescence pour les
abonnements à afficher dans le volet Stratégies. Les clients disposant de centaines ou de milliers de stratégies ou
d’affectations dans un même abonnement préféreront probablement un moyen de trouver leurs stratégies ou
leurs affectations avec possibilité de recherche. L’extension Azure Policy permet de rechercher une stratégie ou
une affectation spécifique en suivant les étapes suivantes :
1. Lancez l’interface de recherche à partir de l’extension Azure Policy ou de la palette de commandes.
Dans l’extension Azure Policy, placez le curseur sur le panneau Stratégies et sélectionnez les points
de suspension, puis Rechercher des stratégies.
Dans la barre de menus, accédez à Afficher>Palette de commandes, puis entrez Stratégies :
Rechercher des stratégies.
2. Si plusieurs abonnements sont sélectionnés pour l’affichage, utilisez le filtre pour sélectionner celui dans
lequel la recherche devra être effectuée.
3. Utilisez le filtre pour sélectionner l’affectation ou le type de stratégie dans lequel la recherche devra être
effectuée, au sein de l’abonnement choisi.
4. Utilisez le filtre pour sélectionner la stratégie ou l’affectation à afficher. Le filtre fonctionne sur displayName
pour la définition ou l’affectation de stratégie.
Lorsqu’une stratégie ou une affectation est sélectionnée, que ce soit par le biais de l’interface de recherche ou dans
l’arborescence, l’extension Azure Policy ouvre le fichier JSON représentant la stratégie ou l’affectation et toutes ses
valeurs de propriété Resource Manager. L’extension peut valider le schéma JSON Azure Policy ouvert.
Se déconnecter
À partir de la barre de menus, accédez à Afficher > Palette de commandes, puis entrez Azure: Se
déconnecter.
Étapes suivantes
Cet article vous explique comment créer et gérer des stratégies par programmation. Les définitions de
stratégie Azure appliquent différentes règles et des différents effets sur vos ressources. Cette mise en
conformité permet de garantir que les ressources restent conformes à vos normes d’entreprise et contrats de
niveau de service.
Pour plus d’informations sur la conformité, consultez Obtention de données de conformité.

Avant de commencer, vérifiez que les conditions préalables suivantes sont remplies :
1. Si ce n’est pas déjà fait, installez ARMClient. C’est un outil qui envoie des requêtes HTTP aux API
Azure Resource Manager.
2. Procédez à la mise à jour de votre module Azure PowerShell vers la dernière version. Pour plus
d'informations, consultez Installer le module Azure PowerShell. Pour plus d’informations sur la
version la plus récente, voir Azure PowerShell.
3. Inscrivez le fournisseur de ressources Azure Policy Insights à l’aide d’Azure PowerShell pour vérifier
que votre abonnement fonctionne avec ce fournisseur de ressources. Pour inscrire un fournisseur de
ressources, vous devez être autorisé à exécuter l’opération d’inscription pour le fournisseur de
ressources. Cette opération est incluse dans les rôles de contributeur et de propriétaire. Exécutez la
commande suivante pour enregistrer le fournisseur de ressources :
4. Si ce n’est déjà fait, installez Azure CLI. Vous pouvez obtenir la dernière version sur la page Installer
Azure CLI sur Windows.
Créer et attribuer une définition de stratégie

Pour une meilleure visibilité de vos ressources, la première chose à faire est de créer et d’attribuer des
stratégies à vos ressources. L’étape suivante consiste à apprendre à créer et assigner une stratégie par
programmation. L’exemple de stratégie proposé réalise l’audit des comptes de stockage ouverts à tous les
réseaux publics à l’aide de PowerShell, d’Azure CLI et de requêtes HTTP.
Créer et assigner une définition de stratégie avec PowerShell
1. L’extrait de code JSON suivant permet de créer un fichier JSON nommé AuditStorageAccounts.json.
{
"if": {
"allOf": [{
"field": "type",
},
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
"equals": "Allow"
}
]
},
"then": {
"effect": "audit"
}
}
Pour plus d’informations sur la création d’une définition de stratégie, consultez la page Structure de
définition Azure Policy.
2. Exécutez la commande suivante pour créer une définition de stratégie en utilisant le fichier
AuditStorageAccounts.json.
New-AzPolicyDefinition -Name 'AuditStorageAccounts' -DisplayName 'Audit Storage Accounts Open to

Public Networks' -Policy 'AuditStorageAccounts.json'
La commande crée une définition de stratégie nommée Audit Storage Accounts Open to Public
Networks. Pour plus d'informations sur les autres paramètres que vous pouvez utiliser, consultez
New -AzPolicyDefinition.
Lorsqu’il est appelé sans paramètre d’emplacement, par défaut, New-AzPolicyDefinition enregistre la
définition de stratégie dans l’abonnement sélectionné du contexte de sessions. Pour enregistrer la
définition dans un autre emplacement, utilisez les paramètres suivants :
SubscriptionId : enregistrer dans un autre abonnement. Une valeur GUID est nécessaire.
ManagementGroupName : enregistrer dans un groupe d’administration. Une valeur de chaîne
est nécessaire.
3. Après avoir créé votre définition de stratégie, vous pouvez créer une attribution de stratégie en
exécutant les commandes suivantes :
$rg = Get-AzResourceGroup -Name 'ContosoRG'

$Policy = Get-AzPolicyDefinition -Name 'AuditStorageAccounts'
New-AzPolicyAssignment -Name 'AuditStorageAccounts' -PolicyDefinition $Policy -Scope
$rg.ResourceId
Remplacez ContosoRG par le nom de votre groupe de ressources prévu.

Le paramètre Scope sur New-AzPolicyAssignment peut être défini pour un groupe d’administration, un
abonnement, un groupe de ressources ou une seule ressource. Le paramètre utilise un chemin d’accès
de ressource complet, que la propriété ResourceId renvoie sur Get-AzResourceGroup . Pour chaque
conteneur, le modèle Étendue est le suivant. Remplacez {rName} , {rgName} , {subId} et {mgName}
par le nom de la ressource, le nom du groupe de ressources, l’ID de l’abonnement et le nom du
groupe d’administration, respectivement. {rType} est remplacé par le type de la ressource, comme
Microsoft.Compute/virtualMachines pour une machine virtuelle.
Ressource : /subscriptions/{subID}/resourceGroups/{rgName}/providers/{rType}/{rName}
Groupe de ressources : /subscriptions/{subId}/resourceGroups/{rgName}
Abonnement : /subscriptions/{subId}/
Groupe d'administration : /providers/Microsoft.Management/managementGroups/{mgName}
Pour plus d'informations sur la gestion des stratégies de ressources à l'aide du module Azure Resource
Manager PowerShell, consultez Az.Resources.
Créer et assigner une définition de stratégie avec ARMClient
Pour créer une définition de stratégie, procédez comme suit.
1. Copiez l’extrait de code JSON suivant pour créer un fichier JSON. Vous appellerez le fichier à l’étape
suivante.
"properties": {
"displayName": "Audit Storage Accounts Open to Public Networks",
"policyType": "Custom",
"mode": "Indexed",
"description": "This policy ensures that storage accounts with exposure to Public Networks are
audited.",
"parameters": {},
"policyRule": {
"if": {
"allOf": [{
"field": "type",
},
{
"equals": "Allow"
}
]
},
"then": {
"effect": "audit"
}
}
}
2. Créez la définition de stratégie à l’aide de l’un des appels suivants :
# For defining a policy in a subscription

armclient PUT
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/policyDefinitions/AuditStorageA
ccounts?api-version=2016-12-01" @<path to policy definition JSON file>
# For defining a policy in a management group

armclient PUT
"/providers/Microsoft.Management/managementgroups/{managementGroupId}/providers/Microsoft.Authoriz
ation/policyDefinitions/AuditStorageAccounts?api-version=2016-12-01" @<path to policy definition
JSON file>
Remplacez {subscriptionId} précédent par l’ID de votre abonnement ou {managementGroupId} par

l’ID de votre groupe d’administration.
Pour plus d’informations sur la structure de la requête, consultez Définitions de stratégie Azure –
Créer ou mettre à jour et Définitions de stratégie – Créer ou mettre à jour dans le groupe
d’administration
Utilisez la procédure suivante pour créer une attribution de stratégie et assigner la définition de stratégie au
niveau du groupe de ressources.
1. Copiez l’extrait de code JSON suivant pour créer un fichier d’attribution de stratégie JSON.
Remplacez les informations de l’exemple entre <> par vos propres valeurs.
{
"properties": {
"description": "This policy assignment makes sure that storage accounts with exposure to
Public Networks are audited.",
"displayName": "Audit Storage Accounts Open to Public Networks Assignment",
"parameters": {},
"/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/policyDefinitions/Audit Storage
Accounts Open to Public Networks",
"scope": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>"
}
}
2. Créez l’attribution de stratégie à l’aide de l’appel suivant :
armclient PUT
"/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Authorizat
ion/policyAssignments/Audit Storage Accounts Open to Public Networks?api-version=2017-06-01-
preview" @<path to Assignment JSON file>
Remplacez les informations de l’exemple entre <> par vos propres valeurs.
Pour plus d’informations sur les appels HTTP à l’API REST, consultez la page Ressources API REST
Azure.
Créer et attribuer une définition de stratégie avec Azure CLI
Pour créer une définition de stratégie, procédez comme suit :
1. Copiez l’extrait de code JSON suivant pour créer un fichier d’attribution de stratégie JSON.
{
"if": {
"allOf": [{
"field": "type",
},
{
"equals": "Allow"
}
]
},
"then": {
"effect": "audit"
}
}
Pour plus d’informations sur la création d’une définition de stratégie, consultez la page Structure de
définition Azure Policy.
2. Pour créer une définition de stratégie, exécutez la commande suivante :
az policy definition create --name 'audit-storage-accounts-open-to-public-networks' --display-name

'Audit Storage Accounts Open to Public Networks' --description 'This policy ensures that storage
accounts with exposures to public networks are audited.' --rules '<path to json file>' --mode All
La commande crée une définition de stratégie nommée Audit Storage Accounts Open to Public
Networks. Pour plus d’informations sur les autres paramètres utilisables, consultez az policy definition
create.
Lorsqu’il est appelé sans paramètre d’emplacement, par défaut, az policy definition creation
enregistre la définition de stratégie dans l’abonnement sélectionné du contexte de sessions. Pour
enregistrer la définition dans un autre emplacement, utilisez les paramètres suivants :
--subscription : enregistre dans un autre abonnement. Nécessite une valeur GUID pour l’ID
d’abonnement ou une valeur chaîne pour le nom de l’abonnement.
--management-group : enregistre dans un groupe d’administration. Une valeur de chaîne est
nécessaire.
3. Pour créer une attribution de stratégie, utilisez la commande suivante. Remplacez les informations de
l’exemple entre <> par vos propres valeurs.
az policy assignment create --name '<name>' --scope '<scope>' --policy '<policy definition ID>'
Le paramètre --scope sur az policy assignment create peut être défini pour un groupe
d’administration, un abonnement, un groupe de ressources ou une seule ressource. Le paramètre
utilise un chemin de ressource complet. Pour chaque conteneur, le modèle --scope est le suivant.
Remplacez {rName} , {rgName} , {subId} et {mgName} par le nom de la ressource, le nom du groupe
de ressources, l’ID de l’abonnement et le nom du groupe d’administration, respectivement. {rType}
est remplacé par le type de la ressource, comme Microsoft.Compute/virtualMachines pour une
machine virtuelle.
Ressource : /subscriptions/{subID}/resourceGroups/{rgName}/providers/{rType}/{rName}
Groupe de ressources : /subscriptions/{subID}/resourceGroups/{rgName}
Abonnement : /subscriptions/{subID}
Groupe d'administration : /providers/Microsoft.Management/managementGroups/{mgName}
Vous pouvez obtenir l’ID de définition de stratégie Azure à l’aide de PowerShell avec la commande suivante :
az policy definition show --name 'Audit Storage Accounts with Open Public Networks'
L’ID de définition de stratégie pour la définition de stratégie que vous avez créée doit ressembler à ce qui
suit :
"/subscription/<subscriptionId>/providers/Microsoft.Authorization/policyDefinitions/Audit Storage
Accounts Open to Public Networks"
Pour plus d’informations sur la façon dont vous pouvez gérer les stratégies de ressources avec Azure CLI,
consultez Stratégies de ressources Azure CLI.
Étapes suivantes
Pour plus d’informations sur les commandes et les requêtes de cet article, consultez les articles suivants.
Ressources API REST Azure
Modules Azure PowerShell
Commandes de stratégie Azure CLI
Informations de référence sur l’API REST du fournisseur de ressources Azure Policy Insights
Organiser vos ressources avec des groupes d’administration Azure.
Les propriétés Azure Resource Manager sont généralement définies comme des chaînes et des valeurs booléennes.
Lorsqu’il existe une relation un-à-plusieurs, des propriétés complexes sont plutôt définies comme des tableaux.
Dans Azure Policy, les tableaux sont utilisés de différentes manières :
Le type d’un paramètre de définition, pour fournir plusieurs options
Une partie d’une règle de stratégie utilisant les conditions In ou notIn
Il s’agit d’une partie d’une règle de stratégie qui évalue l’alias [*] pour évaluer ce qui suit :
Scénarios tels que None (Aucun), Any (N’importe lequel) ou All (Tout)
Scénarios complexes avec count
Dans l’effet Append pour remplacer ou ajouter à un tableau existant
Cet article traite chaque utilisation par Azure Policy et fournit plusieurs exemples de définitions.
Tableaux de paramètres
Définir un tableau de paramètres
La définition d’un paramètre sous forme de tableau permet une flexibilité de la stratégie lorsque plusieurs valeurs
sont nécessaires. Cette définition de stratégie permet de régler n’importe quel emplacement unique pour le
paramètre allowedLocations et les valeurs par défaut sur eastus2:
"parameters": {
"type": "string",
"metadata": {
},
"defaultValue": "eastus2"
}
}
Comme le type était chaîne, une seule valeur peut être définie lors de l’affectation de la stratégie. Si cette stratégie
est affectée, les ressources dans l’étendue sont autorisées uniquement dans une seule région Azure. La plupart des
définitions de stratégies doivent autoriser une liste des options approuvées, par exemple pour autoriser eastus2,
eastus, et westus2.
Pour créer la définition de stratégie visant à autoriser plusieurs options, utilisez le type tableau. La même stratégie
peut être réécrite comme suit :
"parameters": {
"type": "array",
"metadata": {
},
"defaultValue": "eastus2",
"allowedValues": [
"eastus2",
"eastus",
"westus2"
]
}
}
NOTE
Lorsqu’une définition de stratégie est enregistrée, la propriété type sur un paramètre ne peut pas être modifiée.
Cette nouvelle définition de paramètre accepte plusieurs valeurs lors de l’affectation de stratégie. Avec la propriété
de tableau allowedValues définie, les valeurs disponibles lors de l’affectation sont limitées à la liste prédéfinie de
choix. L’utilisation de allowedValues est facultative.
Passer des valeurs à un tableau de paramètres lors de l’attribution
Lors de l’affectation de la stratégie via le portail Azure, un paramètre de type tableau s’affiche sous la forme d’une
zone de texte unique. L’indicateur indique « Utiliser ’;’ pour séparer des valeurs. (par exemple, Londres;New York) ».
Pour passer les valeurs d’emplacement autorisées de eastus2, eastus et westus2 au paramètre, utilisez la chaîne
suivante :
eastus2;eastus;westus2
Le format de la valeur du paramètre est différent lorsque vous utilisez Azure CLI, Azure PowerShell ou l’API REST.
Les valeurs sont transmises via une chaîne JSON qui inclut également le nom du paramètre.
{
"value": [
"eastus2",
"eastus",
"westus2"
]
}
}
Pour utiliser cette chaîne avec chaque kit SDK, utilisez les commandes suivantes :
Azure CLI : Commande az policy assignment create avec le paramètre params
Azure PowerShell : Applet de commande New -AzPolicyAssignment avec le paramètre PolicyParameter
API REST : Dans l’opération PUT create en tant que partie intégrante du corps de la demande en tant que valeur
d’une propriété properties.parameters
Règles de stratégie et tableaux

Conditions de tableau
La règle de stratégie conditions avec laquelle un type tableau du paramètre peut être utilisé est limitée à in et
notIn . Prenez la définition de stratégie suivante avec la condition equals comme exemple :
{
"policyRule": {
"if": {
"not": {
"equals": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "audit"
}
},
"parameters": {
"type": "Array",
"metadata": {
}
}
}
}
Une tentative de création de cette définition de stratégie via le portail Azure entraîne une erreur telle que ce
message d’erreur :
« La stratégie '{GUID }' ne peut pas être paramétrée en raison d’erreurs de validation. Vérifiez si les paramètres
de stratégie sont correctement définis. L’exception interne « Résultat d’évaluation de l’expression de langage
'[parameters('allowedLocations')]' est de type « Tableau », le type attendu est « String ». »
Le type attendu de la condition equals est chaîne. Dans la mesure où allowedLocations est de type tableau, le
moteur de stratégie évalue l’expression de langage et affiche l’erreur. Avec les conditions in et notIn , le moteur
de stratégie attend le type tableau dans l’expression de langage. Pour résoudre ce message d’erreur, remplacez
equals par in ou notIn .
Évaluation de l’alias [*]

Les alias ayant [*] attaché à leur nom indiquent que le type est un tableau. Au lieu d’évaluer la valeur de
l’intégralité du tableau, [*] permet d’évaluer chacun des éléments qu’il contient, avec un ET logique entre eux. Il
existe trois scénarios standards au sein desquels cette évaluation par élément est utile : en cas de correspondance
avec aucun élément, n’importe quel élément ou tous les éléments. Pour les scénarios complexes, utilisez count.
Le moteur de stratégie déclenche l’effet dans then uniquement lorsque la règle if est évaluée comme True. Il est
important de comprendre ce point dans le contexte de la façon dont [*] évalue chaque élément individuel du
tableau.
L’exemple de règle de stratégie pour la table de scénario ci-dessous :
"policyRule": {
"if": {
"allOf": [
{
"exists": "true"
},
<-- Condition (see table below) -->
]
},
"then": {
}
}
Pour la table de scénario ci-dessous, le tableau des ipRules se présente de la façon suivante :
"ipRules": [
{
"value": "127.0.0.1",
"action": "Allow"
},
{
"value": "192.168.1.1",
"action": "Allow"
}
]
Pour chaque exemple de condition ci-dessous, remplacez <field> par

"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*].value" .
Les résultats suivants viennent de la combinaison de la condition et de l’exemple de règle de stratégie et le tableau
des valeurs existantes ci-dessus :
CONDITION RÉSULTAT SCÉNARIO EXPLICATION
Rien
{<field>,"notEquals":"127.0.0.1"} Aucun ne correspond Un élément du tableau est
évalué comme false
(127.0.0.1 ! = 127.0.0.1) et
un autre comme true
(127.0.0.1 ! = 192.168.1.1),
donc la condition notEquals
est false et l’effet n’est pas
déclenché.
Effet de la stratégie
{<field>,"notEquals":"10.0.4.1"} Aucun ne correspond Les éléments du tableau
sont évalués comme true
(10.0.4.1 != 127.0.0.1 et
10.0.4.1 != 192.168.1.1),
est true et l’effet est
déclenché.
CONDITION RÉSULTAT SCÉNARIO EXPLICATION
"not": Effet de la stratégie Un ou plusieurs Un élément du tableau est

{<field>,"notEquals":"127.0.0.1" correspondent évalué comme false
}
(127.0.0.1 != 127.0.0.1) et
un autre comme true
(127.0.0.1 != 192.168.1.1),
est false. L’opérateur logique
est évalué comme true (non
false), de sorte que l’effet est
déclenché.
"not": Rien Un ou plusieurs Les deux éléments du

{<field>,"notEquals":"10.0.4.1"} correspondent tableau sont évalués comme
false (10.0.4.1 != 127.0.0.1
et 10.0.4.1 != 192.168.1.1),
est true. L’opérateur logique
est évalué comme false (non
true), de sorte que l’effet
n’est pas déclenché.
"not": Effet de la stratégie Tous ne correspondent pas Un élément du tableau est

{<field>,"Equals":"127.0.0.1"} évalué comme true
(127.0.0.1 == 127.0.0.1) et
un autre comme false
(127.0.0.1 == 192.168.1.1),
donc la condition Equals est
false. L’opérateur logique est
évalué comme true (non
déclenché.
"not": Effet de la stratégie Tous ne correspondent pas Les deux éléments du

{<field>,"Equals":"10.0.4.1"} tableau sont évalués comme
false (10.0.4.1 == 127.0.0.1
et 10.0.4.1 == 192.168.1.1),
false. L’opérateur logique est
évalué comme true (non
déclenché.
Rien
{<field>,"Equals":"127.0.0.1"} Tous correspondent Un élément du tableau est
évalué comme true
(127.0.0.1 == 127.0.0.1) et
un autre comme true
(127.0.0.1 == 192.168.1.1),
false et l’effet n’est pas
déclenché.
{<field>,"Equals":"10.0.4.1"}Rien Tous correspondent Les deux éléments du

tableau sont évalués comme
false (10.0.4.1 == 127.0.0.1
et 10.0.4.1 == 192.168.1.1),
false et l’effet n’est pas
déclenché.
L’effet Append et les tableaux
L’effet Append se comporte différemment selon que details.field est un alias [*] ou non.
Lorsqu’il ne s’agit pas d’un alias [*] , Append remplace le tableau entier avec la propriété value
Lorsqu’il s’agit d’un alias [*] , Append ajoute la propriété value au tableau existant ou crée le nouveau tableau
Pour plus d’informations, consultez ces exemples Append.
Étapes suivantes
Guest Configuration utilise un module de ressources Desired State Configuration (DSC ) pour créer la
configuration pour l’audit de machines Azure. La configuration DSC définit la condition dans laquelle la machine
doit se trouver. Si l’évaluation de la configuration échoue, l’auditIfNotExists d’effet de stratégie est déclenché et la
machine est considérée comme non conforme.
La configuration d’invité Azure Policy peut être utilisée uniquement pour auditer les paramètres à l’intérieur des
machines. La correction des paramètres à l’intérieur des machines n’est pas encore disponible.
Utilisez les actions suivantes pour créer votre propre configuration pour la validation de l’état d’une machine
Azure.
IMPORTANT
Les stratégies personnalisées avec Guest Configuration sont une fonctionnalité en préversion.
Ajouter le module de ressource GuestConfiguration

Pour créer une stratégie Guest Configuration, le module de ressources doit être ajouté. Vous pouvez utiliser ce
module de ressources avec PowerShell installé localement, avec Azure Cloud Shell ou avec l’image Docker Azure
PowerShell Core.
NOTE
Tandis que le module GuestConfiguration fonctionne dans les environnements ci-dessus, les étapes de compilation d’une
configuration DSC doivent être effectuées dans Windows PowerShell 5.1.
Configuration de base requise

Le module de ressource Guest Configuration nécessite les logiciels suivants :
PowerShell. S’il n’est pas installé, suivez ces instructions.
Azure PowerShell 1.5.0 ou ultérieur. S’il n’est pas installé, suivez ces instructions.
Installer le module
Guest Configuration utilise le module de ressource GuestConfiguration pour la création de configurations DSC
et leur publication dans Azure Policy :
1. À partir d’une invite de commandes PowerShell, exécutez la commande suivante :
# Install the Guest Configuration DSC resource module from PowerShell Gallery
Install-Module -Name GuestConfiguration
2. Vérifiez que le module a été importé :
# Get a list of commands for the imported GuestConfiguration module

Get-Command -Module 'GuestConfiguration'
Créer une configuration et des ressources Guest Configuration
personnalisées
La première étape de création d’une stratégie personnalisée pour Guest Configuration consiste à créer la
configuration DSC. Pour obtenir une vue d’ensemble des concepts et de la terminologie DSC, consultez Vue
d’ensemble PowerShell DSC.
Si votre configuration nécessite uniquement des ressources qui sont intégrées à l’agent Guest Configuration, vous
avez seulement besoin de créer un fichier MOF de configuration. Si vous devez exécuter un script supplémentaire,
vous devez créer un module de ressource personnalisé.
Conditions requises pour les ressources personnalisées Guest Configuration
Quand Guest Configuration audite une machine, il exécute d’abord Test-TargetResource pour déterminer si son
état est approprié. La valeur booléenne retournée par la fonction détermine si l’état Azure Resource Manager de
l’affectation d’invité doit être conforme ou non conforme. Si la valeur booléenne est $false pour une ressource de
la configuration, le fournisseur exécutera Get-TargetResource . Si la valeur booléenne est $true , alors
Get-TargetResource n’est pas appelé.
Exigences de configuration
La seule exigence pour que la configuration d’invité utilise une configuration personnalisée est que le nom de la
configuration soit cohérent partout où il est utilisé. Cette exigence relative au nom inclut le nom du fichier .zip pour
le package de contenu, le nom de la configuration dans le fichier MOF stocké à l’intérieur du package de contenu et
le nom de configuration utilisé dans un modèle Resource Manager comme nom d’affectation d’invité.
Exigences Get-TargetResource
La fonction Get-TargetResource a des exigences pour Guest Configuration qu’elle n’a pas pour la configuration
d’état souhaité Windows.
La table de hachage qui est retournée doit inclure une propriété nommée Reasons.
La propriété Reasons doit être un tableau.
Chaque élément du tableau doit être une table de hachage avec les clés Code et Phrase.
La propriété Reasons est utilisée par le service pour normaliser la manière dont les informations sont présentées
quand un ordinateur n’est pas conforme. Vous pouvez considérer chaque élément de Reasons comme une
« raison » pour laquelle la ressource n’est pas conforme. La propriété est un tableau, car une ressource peut ne pas
être conforme pour plusieurs raisons.
Les propriétés Code et Phrase sont attendues par le service. Lorsque vous créez une ressource personnalisée,
définissez le texte (en général stdout) que vous souhaitez afficher pour expliquer pourquoi la ressource n’est pas
conforme à la valeur de Phrase. Code a des exigences de mise en forme spécifiques, visant à afficher clairement
les informations sur la ressource qui a été utilisée pour effectuer l’audit. Cette solution rend Guest Configuration
extensible. Vous pouvez exécuter n’importe quelle commande pour auditer une machine, tant que la sortie peut
être capturée et retournée sous la forme d’une valeur de chaîne pour la propriété Phrase.
Code (chaîne) : nom de la ressource, répété, puis un nom abrégé sans espaces comme identificateur de la
raison. Ces trois valeurs doivent être séparées par des points-virgules, sans espaces.
Par exemple, registry:registry:keynotpresent .
Phrase (chaîne) : texte lisible par l’utilisateur expliquant pourquoi le paramètre n’est pas conforme.
Par exemple, The registry key $key is not present on the machine. .
$reasons = @()
$reasons += @{
Code = 'Name:Name:ReasonIdentifer'
Phrase = 'Explain why the setting is not compliant'
}
return @{
reasons = $reasons
}
Structuration d’un projet Guest Configuration

Pour les développeurs qui souhaitent accélérer l’utilisation de l’exemple de code, il existe un projet de la
communauté nommé Guest Configuration Project qui se présente sous la forme d’un modèle pour le module
PowerShell Plaster. Cet outil peut être utilisé pour structurer un projet, (y compris une configuration de travail et
un exemple de ressource), ainsi qu’un ensemble de tests Pester pour valider le projet. Le modèle comprend
également des exécuteurs de tâches pour Visual Studio Code permettant d’automatiser la création et la validation
du package Guest Configuration. Pour plus d’informations, consultez le projet GitHub Guest Configuration Project.
Configuration Guest Configuration personnalisée sur Linux
La configuration DSC pour Guest Configuration sur Linux utilise la ressource ChefInSpecResource pour fournir au
moteur le nom de la définition Chef InSpec. Name est la seule propriété de ressource obligatoire.
L’exemple suivant crée une configuration nommée baseline, importe le module de ressources
GuestConfiguration et utilise la ressource ChefInSpecResource pour définir le nom de la définition InSpec sur
linux-patch-baseline :
# Define the DSC configuration and import GuestConfiguration

Configuration baseline
{
Import-DscResource -ModuleName 'GuestConfiguration'
ChefInSpecResource 'Audit Linux patch baseline'

{
Name = 'linux-patch-baseline'
}
}
# Compile the configuration to create the MOF files

baseline
Pour plus d’informations, consultez Écrire, compiler et appliquer une configuration.

Configuration Guest Configuration personnalisée sur Windows
La configuration DSC d’une configuration Guest Configuration d’Azure Policy est utilisée par l’agent Guest
Configuration uniquement. Elle n’est pas en conflit avec Windows PowerShell Desired State Configuration.
L’exemple suivant crée une configuration nommée AuditBitLocker, importe le module de ressources
GuestConfiguration et utilise la ressource Service pour faire l’audit d’un service en cours d’exécution :
# Define the DSC configuration and import GuestConfiguration
Configuration AuditBitLocker
{
Import-DscResource -ModuleName 'PSDscResources'
Service 'Ensure BitLocker service is present and running'

{
Name = 'BDESVC'
Ensure = 'Present'
State = 'Running'
}
}
# Compile the configuration to create the MOF files

AuditBitLocker
Pour plus d’informations, consultez Écrire, compiler et appliquer une configuration.
Créer un package de stratégies personnalisées Guest Configuration

Une fois la compilation du fichier MOF terminée, les fichiers de prise en charge doivent être regroupés en un
package. Le package obtenu est utilisé par Guest Configuration pour créer les définitions d’Azure Policy. Le
package comprend les éléments suivants :
La configuration DSC compilée au format MOF
Dossier Modules
Module GuestConfiguration
Module DscNativeResources
(Linux) Un dossier avec la définition Chef InSpec et du contenu supplémentaire
(Windows) Modules de ressources DSC non intégrés
La cmdlet New-GuestConfigurationPackage crée le package. Le format suivant est utilisé pour créer un package
personnalisé :
New-GuestConfigurationPackage -Name '{PackageName}' -Configuration '{PathToMOF}' `

-Path '{OutputFolder}' -Verbose
Paramètres de la cmdlet New-GuestConfigurationPackage :

Name : Nom du package Guest Configuration.
Configuration : Chemin d’accès complet au document de configuration DSC compilé.
Chemin d’accès : Chemin d’accès au dossier de sortie. Ce paramètre est facultatif. S’il n’est pas spécifié, le
package est créé dans le répertoire actif.
ChefProfilePath : Chemin d’accès complet au profil InSpec. Ce paramètre est pris en charge uniquement lors
de la création de contenu pour auditer Linux.
Le package terminé doit être stocké à un emplacement accessible par les machines virtuelles gérées. Exemples :
référentiels GitHub, référentiel Azure ou stockage Azure. Si vous préférez ne pas rendre le package public, vous
pouvez inclure un jeton SAS dans l’URL. Vous pouvez également implémenter le point de terminaison de service
pour les machines dans un réseau privé, bien que cette configuration s’applique uniquement à l’accès au package et
ne communique pas avec le service.
Tester un package Guest Configuration

Après avoir créé le package de configuration, et avant de le publier sur Azure, vous pouvez tester la fonctionnalité
du package à partir de votre station de travail ou de votre environnement d’intégration CI/CD. Le module
GuestConfiguration comprend une applet de commande Test-GuestConfigurationPackage qui charge le même
agent dans votre environnement de développement que celui utilisé dans les machines Azure. Via cette solution,
vous pouvez effectuer un test d’intégration en local avant la publication dans des environnements de
production/AQ/test facturés.
Test-GuestConfigurationPackage -Path .\package\AuditWindowsService\AuditWindowsService.zip -Verbose
Paramètres de la cmdlet Test-GuestConfigurationPackage :

Name : Nom de la stratégie Guest Configuration.
Paramètre : Paramètres de stratégie fournis au format Hashtable.
Chemin d’accès : Chemin d’accès complet du package Guest Configuration.
La cmdlet prend aussi en charge l’entrée depuis le pipeline PowerShell. Dirige la sortie de la cmdlet
New-GuestConfigurationPackage vers la cmdlet Test-GuestConfigurationPackage .
New-GuestConfigurationPackage -Name AuditWindowsService -Configuration .\DSCConfig\localhost.mof -Path

.\package -Verbose | Test-GuestConfigurationPackage -Verbose
Pour savoir comment tester avec des paramètres, consultez la section ci-dessous Utilisation des paramètres dans
des stratégies personnalisées Guest Configuration.
Créer la définition Azure Policy et les fichiers de déploiement d’initiative

Une fois qu’un package de stratégie personnalisée Guest Configuration a été créé et chargé dans un emplacement
accessible par les machines, créez la définition de la stratégie Guest Configuration pour Azure Policy. La cmdlet
New-GuestConfigurationPolicy prend un package de stratégie personnalisée Guest Configuration accessible
publiquement et crée une définition de stratégie auditIfNotExists et deployIfNotExists. Une définition
d’initiative de stratégie qui comprend les deux définitions de stratégie est également créée.
L’exemple suivant crée les définitions de stratégie et d’initiative dans un chemin d’accès spécifié à partir d’un
package de stratégie personnalisée Guest Configuration pour Windows et fournit un nom, une description et une
version :
New-GuestConfigurationPolicy
-ContentUri 'https://storageaccountname.blob.core.windows.net/packages/AuditBitLocker.zip?st=2019-07-
01T00%3A00%3A00Z&se=2024-07-01T00%3A00%3A00Z&sp=rl&sv=2018-03-
28&sr=b&sig=JdUf4nOCo8fvuflOoX%2FnGo4sXqVfP5BYXHzTl3%2BovJo%3D' `
-DisplayName 'Audit BitLocker Service.' `
-Description 'Audit if BitLocker is not enabled on Windows machine.' `
-Path '.\policyDefinitions' `
-Platform 'Windows' `
-Version 1.2.3.4 `
-Verbose
Paramètres de la cmdlet New-GuestConfigurationPolicy :

ContentUri : URI http(s) publique du package de contenu Guest Configuration.
DisplayName : Nom d'affichage de la stratégie.
Description : Description de la stratégie.
Paramètre : Paramètres de stratégie fournis au format Hashtable.
Version : Version de stratégie.
Chemin d’accès : Chemin de destination où les définitions de stratégie sont créées.
Plateforme : Plateforme cible (Windows/Linux) pour la stratégie et le package de contenu Guest Configuration.
Les fichiers suivants sont créés par New-GuestConfigurationPolicy :
auditIfNotExists.json
deployIfNotExists.json
Initiative.json
La sortie de la cmdlet retourne un objet contenant le nom complet de l’initiative et le chemin d’accès aux fichiers de
stratégie.
Si vous souhaitez utiliser cette commande pour structurer un projet de stratégie personnalisée, vous pouvez
effectuer les modifications à ces fichiers. Par exemple, vous pouvez modifier la section « if » pour évaluer si une
balise spécifique est présente pour les machines. Pour plus d’informations sur la création de stratégies, consultez
Créer des stratégies par programmation.
Utilisation de paramètres dans des stratégies personnalisées Guest Configuration
Guest Configuration prend en charge la substitution des propriétés d’une configuration lors d’une exécution. Cette
fonctionnalité signifie que les valeurs du fichier MOF dans le package n’ont pas à être considérées comme
statiques. Les valeurs de substitution sont fournies via Azure Policy et n’impactent pas la création ni la compilation
des configurations.
Les cmdlets New-GuestConfigurationPolicy et Test-GuestConfigurationPolicyPackage incluent un paramètre nommé
Paramètres. Ce paramètre prend une définition au format Hashtable qui comprend toutes les informations
concernant chaque paramètre et crée automatiquement toutes les sections nécessaires des fichiers utilisés pour
créer chaque définition Azure Policy.
L’exemple suivant crée une stratégie Azure Policy pour auditer un service, où l’utilisateur sélectionne depuis une
liste des services au moment de l’attribution de la stratégie.
$PolicyParameterInfo = @(
@{
Name = 'ServiceName' # Policy parameter name (mandatory)
DisplayName = 'windows service name.' # Policy parameter display name
(mandatory)
Description = "Name of the windows service to be audited." # Policy parameter description
(optional)
ResourceType = "Service" # DSC configuration resource type
(mandatory)
ResourceId = 'windowsService' # DSC configuration resource property
name (mandatory)
ResourcePropertyName = "Name" # DSC configuration resource property
name (mandatory)
DefaultValue = 'winrm' # Policy parameter default value
(optional)
AllowedValues = @('BDESVC','TermService','wuauserv','winrm') # Policy parameter allowed values
(optional)
}
)
New-GuestConfigurationPolicy
-ContentUri 'https://storageaccountname.blob.core.windows.net/packages/AuditBitLocker.zip?st=2019-07-
28&sr=b&sig=JdUf4nOCo8fvuflOoX%2FnGo4sXqVfP5BYXHzTl3%2BovJo%3D' `
-DisplayName 'Audit Windows Service.' `
-Description 'Audit if a Windows Service is not enabled on Windows machine.' `
-Path '.\policyDefinitions' `
-Parameters $PolicyParameterInfo `
-Platform 'Windows' `
-Version 1.2.3.4 `
-Verbose
Pour les stratégies Linux, ajoutez la propriété AttributesYmlContent à votre configuration et remplacez les
valeurs le cas échéant. L’agent Guest Configuration crée automatiquement le fichier YAML utilisé par InSpec pour
stocker les attributs. Reportez-vous à l’exemple ci-dessous.
Configuration FirewalldEnabled {
Import-DscResource -ModuleName 'GuestConfiguration'
Node FirewalldEnabled {
ChefInSpecResource FirewalldEnabled {
Name = 'FirewalldEnabled'
AttributesYmlContent = "DefaultFirewalldProfile: [public]"
}
}
}
Pour chaque paramètre supplémentaire, ajoutez une table de hachage au tableau. Dans les fichiers de stratégie,
vous verrez des propriétés ajoutées au nom de la configuration Guest Configuration qui identifient le type de
ressource, le nom, la propriété et la valeur.
{
"apiVersion": "2018-11-20",
"type": "Microsoft.Compute/virtualMachines/providers/guestConfigurationAssignments",
"name": "[concat(parameters('vmName'), '/Microsoft.GuestConfiguration/',
parameters('configurationName'))]",
"location": "[parameters('location')]",
"properties": {
"guestConfiguration": {
"name": "[parameters('configurationName')]",
"version": "1.*",
"configurationParameter": [{
"name": "[Service]windowsService;Name",
"value": "[parameters('ServiceName')]"
}]
}
}
}
Publier dans Azure Policy

Le module de ressources GuestConfiguration offre un moyen de créer des définitions de stratégie et la définition
d’initiative dans Azure en une étape via la cmdlet Publish-GuestConfigurationPolicy . La cmdlet ne dispose que du
paramètre Path qui pointe vers l’emplacement des trois fichiers JSON créés par New-GuestConfigurationPolicy .
Publish-GuestConfigurationPolicy -Path '.\policyDefinitions' -Verbose
La cmdlet Publish-GuestConfigurationPolicy accepte le chemin à partir du pipeline PowerShell. Cette fonctionnalité

signifie que vous pouvez créer les fichiers de stratégie et les publier dans un ensemble unique de commandes
redirigées.
New-GuestConfigurationPolicy -ContentUri
'https://storageaccountname.blob.core.windows.net/packages/AuditBitLocker.zip?st=2019-07-
28&sr=b&sig=JdUf4nOCo8fvuflOoX%2FnGo4sXqVfP5BYXHzTl3%2BovJo%3D' -DisplayName 'Audit BitLocker service.' -
Description 'Audit if the BitLocker service is not enabled on Windows machine.' -Path '.\policyDefinitions' -
Platform 'Windows' -Version 1.2.3.4 -Verbose | ForEach-Object {$_.Path} | Publish-GuestConfigurationPolicy -
Verbose
Avec les définitions de stratégie et d’initiative créées dans Azure, la dernière étape consiste à assigner l’initiative.
Découvrez comment assigner l’initiative avec le portail, Azure CLI et Azure PowerShell.
IMPORTANT
Les stratégies Guest Configuration doivent toujours être assignées via l’initiative qui combine les stratégies AuditIfNotExists
et DeployIfNotExists. Si seule la stratégie AuditIfNotExists est assignée, les prérequis ne sont pas déployés et la stratégie
montre toujours que « 0 » serveur est conforme.
Cycle de vie de la stratégie

Une fois que vous avez publié une stratégie Azure Policy personnalisée à l’aide de votre package de contenu
personnalisé, vous devez mettre à jour deux champs si vous souhaitez publier une nouvelle version.
Version : Lorsque vous exécutez l’applet de commande New-GuestConfigurationPolicy , vous devez spécifier un
numéro de version supérieur à celui actuellement publié. Cette propriété met à jour la version de l’attribution
Guest Configuration dans le nouveau fichier de stratégie pour que l’extension reconnaisse que le package a été
mis à jour.
contentHash : Cette propriété est automatiquement mise à jour par l’applet de commande
New-GuestConfigurationPolicy . Il s’agit d’une valeur de hachage du package créé par
New-GuestConfigurationPackage . Cette propriété doit être correcte pour le fichier .zip que vous publiez. Si seule
la propriété contentUri est mise à jour, par exemple si une personne peut apporter une modification manuelle
à la définition de stratégie à partir du portail, l’extension n’acceptera pas le package de contenu.
Le moyen le plus simple de publier un package mis à jour consiste à répéter le processus décrit dans cet article et à
fournir un numéro de version mis à jour. Ce processus garantit que toutes les propriétés ont été correctement
mises à jour.
Conversion de contenu de stratégie de groupe Windows en

configuration d’invité Azure Policy
La configuration d’invité, lors de l’audit de machines Windows, est une implémentation de la syntaxe de Desired
State Configuration PowerShell. La communauté DSC a publié des outils pour convertir les modèles de stratégie
de groupe exportés au format DSC. En utilisant cet outil avec les cmdlets de configuration d’invité décrites ci-
dessus, vous pouvez convertir du contenu de stratégie de groupe Windows et le compresser/publier pour Azure
Policy à des fins d’audit. Pour plus d’informations sur l’utilisation de l’outil, consultez l’article Démarrage rapide :
Convertir une stratégie de groupe en DSC. Une fois que le contenu a été converti, les étapes ci-dessus pour créer
un package et le publier en tant qu’Azure Policy sont les mêmes que pour tout contenu DSC.
FACULTATIF : Signature des packages Guest Configuration

Les stratégies personnalisées Guest Configuration utilisent par défaut le hachage SHA256 pour vérifier que le
package de stratégie n’a pas été modifié entre sa publication et sa lecture par le serveur qui est l’objet d’un audit. Si
vous le souhaitez, les clients peuvent également utiliser un certificat pour signer des packages et forcer l’extension
Guest Configuration à autoriser uniquement le contenu signé.
Pour activer ce scénario, vous devez effectuer deux étapes. Exécutez l’applet de commande pour signer le package
de contenu et ajoutez une balise aux machines qui doivent nécessiter du code pour être signées.
Pour utiliser la fonctionnalité de validation de signature, exécutez la cmdlet Protect-GuestConfigurationPackage
pour signer le package avant sa publication. Cette cmdlet nécessite un certificat de « signature du code ».
$Cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {($_.Subject-eq "CN=mycert") }

Protect-GuestConfigurationPackage -Path .\package\AuditWindowsService\AuditWindowsService.zip -Certificate
$Cert -Verbose
Paramètres de la cmdlet Protect-GuestConfigurationPackage :

Chemin d’accès : Chemin d’accès complet du package Guest Configuration.
Certificat : Certificat de signature de code pour signer le package. Ce paramètre est uniquement pris en charge
lors de la signature de contenu pour Windows.
PrivateGpgKeyPath : Chemin d'accès à la clé GPG privée. Ce paramètre est uniquement pris en charge lors de
la signature de contenu pour Linux.
PublicGpgKeyPath : Chemin d'accès à la clé GPG publique. Ce paramètre est uniquement pris en charge lors
de la signature de contenu pour Linux.
L’agent GuestConfiguration s’attend à trouver la clé publique du certificat dans « Autorités de certification racines
de confiance » sur des machines Windows et dans le chemin /usr/local/share/ca-certificates/extra sur des
machines Linux. Pour que le nœud vérifie le contenu signé, installez la clé publique du certificat sur la machine
avant d’appliquer la stratégie personnalisée. Ce processus peut être effectué à l’aide de n’importe quelle technique
à l’intérieur de la machine virtuelle, ou à l’aide d’Azure Policy. Vous trouverez un exemple modèle en suivant ce
lien. La stratégie d’accès Key Vault doit autoriser le fournisseur de ressources de calcul à accéder aux certificats lors
des déploiements. Pour les étapes détaillées, consultez Configurer Key Vault pour des machines virtuelles dans
Azure Resource Manager.
Voici un exemple d’exportation de la clé publique à partir d’un certificat de signature, à importer vers la machine.
$Cert = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {($_.Subject-eq "CN=mycert3") } | Select-

Object -First 1
$Cert | Export-Certificate -FilePath "$env:temp\DscPublicKey.cer" -Force
Vous trouverez une bonne référence de création de clés GPG à utiliser avec les machines Linux dans cet article sur
GitHub, Génération d’une clé GPG.
Une fois votre contenu publié, ajoutez une balise nommée GuestConfigPolicyCertificateValidation et avec une
valeur enabled à toutes les machines virtuelles où la signature du code doit être requise. Pour plus d'informations
sur la façon dont les balises peuvent être délivrées à grande échelle à l'aide d'Azure Policy, consultez les Exemples
de balises. Une fois cette balise en place, la définition de stratégie générée via la cmdlet
New-GuestConfigurationPolicy met en œuvre l’exigence via l’extension Guest Configuration.
Résolution des problèmes liés aux attributions de stratégie Guest

Configuration (préversion)
Un outil est disponible en préversion pour favoriser la résolution des problèmes liés aux attributions de
configuration d’invité Azure Policy. L’outil est en préversion et a été publié sur PowerShell Gallery avec le nom de
module Guest Configuration Troubleshooter.
Pour plus d’informations sur les applets de commande de cet outil, utilisez la commande Get-Help dans
PowerShell pour afficher les conseils intégrés. Comme l’outil fait l’objet de mises à jour fréquentes, c’est la meilleure
façon d’obtenir les informations les plus récentes.
Étapes suivantes
En savoir plus sur l’audit des machines virtuelles avec Guest Configuration.
Azure Policy offre, entre autres avantages, un insight et des contrôles sur les ressources d’un abonnement
ou un groupe d’administration d’abonnements. Ce contrôle peut être effectué de différentes façons,
notamment en empêchant la création de ressources au mauvais emplacement, en appliquant une
utilisation commune et cohérente des balises ou en auditant les ressources existantes pour vérifier
l’adéquation des configurations et paramètres. Dans tous les cas, les données générées par Azure Policy
vous permettent de comprendre l’état de conformité de votre environnement.
Il existe plusieurs façons d’accéder aux informations de conformité générées par votre stratégie et vos
affectations initiatives :
À l’aide du portail Azure
À l’aide de scripts de ligne de commande
Avant d’examiner les méthodes de rapport sur la conformité, voyons à quel moment les informations de
conformité sont mises à jour et passons en revue la fréquence et les événements qui déclenchent un cycle
d’évaluation.
WARNING
Si l’état de conformité indiqué est Non inscrit, vérifiez que le fournisseur de ressources Microsoft.PolicyInsights
est inscrit et que l’utilisateur dispose d’autorisations de contrôle d’accès en fonction du rôle (RBAC) appropriées,
comme décrit dans Contrôle d’accès en fonction du rôle (RBAC) dans Azure Policy.
Déclencheurs d’évaluation
Les résultats d’un cycle d’évaluation terminé sont disponibles dans le fournisseur de ressources
Microsoft.PolicyInsights via les opérations PolicyStates et PolicyEvents . Pour plus d’informations sur
les opérations de l’API REST Azure Policy Insights, consultez la page Azure Policy Insights.
Différents événements permettent d’évaluer les stratégies et initiatives assignées :
Affectation d’une nouvelle stratégie ou initiative à une étendue. Il faut environ 30 minutes pour que
l’affectation soit appliquée à l’étendue définie. Une fois celle-ci appliquée, le cycle d’évaluation
commence pour les ressources de cette étendue compte tenu de la nouvelle stratégie ou initiative ;
de plus, selon les effets utilisés par la stratégie ou l’initiative, les ressources sont marquées comme
conformes ou non conformes. Une stratégie ou une initiative volumineuse évaluée par rapport à
une grande étendue de ressources peut prendre du temps. Par conséquent, il n’existe aucun
moment prédéfini pour la fin du cycle d’évaluation. Une fois le cycle terminé, les résultats de
conformité à jour sont disponibles dans le portail et dans les kits de développement logiciel.
Mise à jour d’une stratégie ou initiative déjà assignée à une étendue. Dans ce scénario, le cycle et le
temps d’évaluation sont les mêmes que pour le cas d’une nouvelle affectation à une étendue.
Déploiement d’une ressource dans une étendue avec une assignation via le Gestionnaire des
ressources, REST, Azure CLI ou Azure PowerShell. Dans ce scénario, l’événement d’effet (ajout,
audit, refus, déploiement) et l’état de conformité deviennent disponibles dans le portail et les Kits de
développement logiciel (SDK) environ 15 minutes plus tard. Cet événement n’entraîne pas une
évaluation des autres ressources.
Cycle d’évaluation de conformité standard. Les affectations sont automatiquement réévaluées une
fois par tranche de 24 heures. L’évaluation d’une stratégie ou d’une initiative volumineuse peut
prendre un temps. Il est donc impossible de déterminer à l’avance à quel moment s’achèvera le
cycle d’évaluation. Une fois le cycle terminé, les résultats de conformité à jour sont disponibles dans
le portail et dans les kits de développement logiciel.
Le fournisseur de ressources Configuration d'invité est mis à jour avec les détails de conformité par
une ressource managée.
Analyse de la demande
Analyse d’évaluation à la demande
Une analyse d’évaluation d’un abonnement ou d’un groupe de ressources peut être démarrée avec un
appel à l’API REST. Il s’agit d’un processus asynchrone. Par conséquent, le point de terminaison REST
pour démarrer l’analyse n’attend pas la fin de l’analyse pour répondre. Au lieu de cela, il fournit un URI
pour interroger l’état de l’évaluation demandée.
Dans chaque URI d’API REST, vous devez remplacer les variables utilisées par vos propres valeurs :
{YourRG}- À remplacer par le nom de votre groupe de ressources
Remplacer {subscriptionId} par votre ID d’abonnement
L’analyse prend en charge l’évaluation des ressources dans un abonnement ou dans un groupe de
ressources. Lancez une analyse pour une étendue avec une commande POST d’API REST en utilisant les
structures d’URI suivantes :
Subscription
POST
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/p
olicyStates/latest/triggerEvaluation?api-version=2018-07-01-preview
Resource group
POST
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{YourRG}/providers/Mi
crosoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview
L’appel retourne un état 202 Accepté. Une propriété Emplacement est incluse dans l’en-tête de la
réponse avec le format suivant :
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/asyncOp
erationResults/{ResourceContainerGUID}?api-version=2018-07-01-preview
{ResourceContainerGUID} est généré de manière statique pour l’étendue demandée. Si une étendue
exécute déjà une analyse à la demande, aucune nouvelle analyse n’est démarrée. Au lieu de cela, le même
URI {ResourceContainerGUID} d’emplacement pour l’état est fourni à la nouvelle requête. Une commande
GET d’API REST à l’URI d’emplacement retourne un 202 Accepté tandis que l’évaluation est en cours.
Une fois l’analyse de l’évaluation terminée, elle retourne un état 200 OK. Le corps d’une analyse terminée
est une réponse JSON avec l’état :
{
"status": "Succeeded"
}
Principe de fonctionnement de la conformité
Dans une affectation, une ressource est dite Non conforme si elle ne respecte pas les règles de l’initiative
ou de la stratégie. Le tableau suivant montre comment les différents effets des stratégies fonctionnent avec
l’évaluation des conditions pour l’état de conformité résultant :
ÉVALUATION DE LA
ÉTAT DE LA RESSOURCE RÉSULTAT STRATÉGIE ÉTAT DE CONFORMITÉ
Exists Deny, Audit, Append*, True Non conforme

DeployIfNotExist*,
AuditIfNotExist*
Exists Deny, Audit, Append*, False Conforme

DeployIfNotExist*,
AuditIfNotExist*
Nouveau Audit, AuditIfNotExist* True Non conforme
Nouveau Audit, AuditIfNotExist* False Conforme
* Les effets Append, DeployIfNotExist et AuditIfNotExist nécessitent que l’instruction IF ait la valeur TRUE.
Les effets nécessitent également que la condition d’existence ait la valeur FALSE pour être non conformes.
Lorsque la valeur est TRUE, la condition IF déclenche l’évaluation de la condition d’existence pour les
ressources associées.
Supposons, par exemple, que vous disposiez d’un groupe de ressources (ContosoRG ), comprenant des
comptes de stockage (en rouge) qui sont exposés sur des réseaux publics.
Dans cet exemple, vous devez faire attention aux risques de sécurité. Maintenant que vous avez créé une
affectation de stratégie, elle est évaluée pour tous les comptes de stockage du groupe de ressources
ContosoRG. Elle effectue l’audit des trois comptes de stockage non conformes et en modifie l’état en
conséquence pour afficher un état Non conforme.
Outre les états Conforme et Non conforme, les stratégies et les ressources peuvent avoir trois autres
états :
En conflit : Il existe deux ou stratégies ou plus avec des règles en conflit. Par exemple, deux stratégies
ajoutent la même balise avec des valeurs différentes.
Non démarré : Le cycle d’évaluation n’a pas démarré pour la stratégie ou la ressource.
Non inscrit : Le fournisseur de ressources Azure Policy n’a pas été inscrit ou le compte connecté n’est
pas autorisé à lire les données de conformité.
La Azure Policy utilise les champs type et nom de la définition pour déterminer si une ressource
correspond. Lorsque la ressource correspond, elle est considérée comme applicable et présente l’état
Conforme ou Non conforme. Si le champ type ou nom est la seule propriété dans la définition de règle
de stratégie, toutes les ressources sont considérées comme applicables et sont évaluées.
Le pourcentage de conformité est déterminé en divisant le nombre de ressources conformes par le
nombre total de ressources. Le nombre total de ressources est défini comme étant la somme des
ressources conformes, non conformes et en conflit. La conformité globale est la somme des ressources
distinctes conformes divisée par la somme de toutes les ressources distinctes. Dans l’image ci-dessous, il
y a 20 ressources distinctes applicables et une seule non conforme. La conformité globale des ressources
est égale à 95 % (soit 19 sur 20).
Portail
Le portail Azure permet de visualiser et comprendre l’état de conformité de votre environnement selon
une représentation graphique. Sur la page Stratégie, l’option Vue d’ensemble fournit des détails sur les
étendues disponibles pour la conformité des stratégies et des initiatives. En complément de l’état de
conformité et du nombre par affectation, elle contient un graphique retraçant la conformité au cours des
sept derniers jours. La page Conformité regroupe essentiellement les mêmes informations (à l’exception
du graphique), mais avec également des options de tri et de filtrage supplémentaires.
Comme une stratégie ou une initiative peut être affectée à différentes étendues, le tableau comprend
l’étendue pour chaque affectation et le type de définition qui a été affecté. Le nombre de ressources et de
stratégies non conformes est aussi indiqué pour chaque affectation. En cliquant sur une stratégie ou une
initiative dans le tableau, vous obtenez davantage de détails sur la conformité de l’affectation concernée.
La liste des ressources dans l’onglet Resource compliance (Conformité des ressources) affiche l’état de
l’évaluation des ressources existantes pour l’affectation actuelle. Par défaut, l’onglet est défini sur Non
conforme, mais un filtre peut être appliqué. Les événements (ajouter, effectuer un audit, refuser, déployer)
déclenchés par la requête pour créer une ressource sont affichés dans l’onglet Événements.
NOTE
Pour une stratégie du moteur AKS, la ressource indiquée est le groupe de ressources.
Pour les ressources du mode Fournisseur de ressources, dans l’onglet Conformité des ressources, la
sélection de la ressource ou un clic droit sur la ligne et la sélection de l’option Afficher les détails de la
conformité ouvre les détails de conformité du composant. Cette page propose également des onglets
pour afficher les stratégies attribuées à cette ressource, les événements, les événements de composant et
l’historique des modifications.
Une fois de retour sur la page de conformité des ressources, cliquez avec le bouton droit sur la ligne de
l’événement pour lequel vous souhaitez obtenir plus de détails et sélectionnez Afficher les journaux
d’activité. La page Journal d’activité s’ouvre et les critères de recherche sont préfiltrés pour montrer les
détails de l’affectation et des événements. Le journal d’activité fournit davantage de contexte ainsi que des
informations supplémentaires sur ces événements.
Comprendre la non-conformité
Lorsque le système détermine qu’une ressource est non conforme, plusieurs raisons justifient cela. Pour
déterminer la raison d’une non conformité d’une ressource ou pour rechercher le ou la responsable de la
modification, veuillez consulter Déterminer une non-conformité.
Ligne de commande
Les informations disponibles dans le portail peuvent être récupérées à l’aide de l’API REST (y compris
avec ARMClient), d’Azure PowerShell ou d’Azure CLI (préversion). Pour plus d’informations sur l’API
REST, consultez la référence Azure Policy Insights. Les pages de référence de l’API REST contiennent,
pour chaque opération, un bouton vert qui vous permet de la tester directement dans votre navigateur.
Utilisez ARMClient ou un outil similaire pour gérer l’authentification auprès d’Azure pour les exemples de
l’API REST.
Synthétiser les résultats
Avec l’API REST, la synthèse peut être effectuée par conteneur, par définition ou par affectation. Voici un
exemple de synthèse obtenu au niveau de l’abonnement à l’aide de la fonction de résumé de l’abonnement
de Azure Policy Insights :
POST
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyS
tates/latest/summarize?api-version=2018-04-04
La sortie offre une synthèse de l’abonnement. Dans l’exemple de sortie ci-dessous, la conformité est
synthétisée sous value.results.nonCompliantResources et value.results.nonCompliantPolicies.
Cette requête fournit des détails supplémentaires, notamment sur chaque affectation concernée par la
non-conformité, fournit des informations sur la définition de chaque affectation. Chaque objet de stratégie
dans la hiérarchie fournit un queryResultsUri qui peut être utilisé pour obtenir des détails
supplémentaires à ce niveau.
{
"@odata.context":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
States/$metadata#summary",
"@odata.count": 1,
"value": [{
"@odata.id": null,
"@odata.context":
States/$metadata#summary/$entity",
"results": {
"queryResultsUri":
States/latest/queryResults?api-version=2018-04-04&$from=2018-05-18 04:28:22Z&$to=2018-05-19
04:28:22Z&$filter=IsCompliant eq false",
"nonCompliantResources": 15,
"nonCompliantPolicies": 1
},
"policyAssignments": [{
"policyAssignmentId": "/subscriptions/{subscriptionId}/resourcegroups/rg-
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77",
"policySetDefinitionId": "",
"results": {
"queryResultsUri":
04:28:22Z&$filter=IsCompliant eq false and PolicyAssignmentId eq
'/subscriptions/{subscriptionId}/resourcegroups/rg-
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77'",
"nonCompliantResources": 15,
"nonCompliantPolicies": 1
},
"policyDefinitionReferenceId": "",
"policyDefinitionId": "/providers/microsoft.authorization/policydefinitions/1e30110a-
5ceb-460c-a204-c1c3969c6d62",
"effect": "deny",
"results": {
"queryResultsUri":
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77' and
PolicyDefinitionId eq '/providers/microsoft.authorization/policydefinitions/1e30110a-5ceb-460c-a204-
c1c3969c6d62'",
"nonCompliantResources": 15
}
}]
}]
}]
}
Interroger des ressources

En reprenant l’exemple ci-dessus,
value.policyAssignments.policyDefinitions.results.queryResultsUri nous donne un exemple d’URI
pour toutes les ressources non conformes pour une définition de stratégie spécifique. Si l’on observe la
valeur $filteron remarque que IsCompliant est défini sur false, que PolicyAssignmentId est spécifié pour
la définition de stratégie, suivi de PolicyDefinitionId. Le PolicyAssignmentId est inclus dans le filtre car le
PolicyDefinitionId peut figurer dans plusieurs stratégies ou affectations initiatives avec une diversité
d’étendues. En spécifiant à la fois le PolicyAssignmentId et le PolicyDefinitionId, nous pouvons être
explicites dans les résultats que nous recherchons. Auparavant, nous utilisions la valeur latest (dernières)
pour PolicyStates : celle-ci définit automatiquement les paramètres from (depuis) et to ( jusqu’à) d’une
plage de temps dans les dernières 24 heures.
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyS
tates/latest/queryResults?api-version=2018-04-04&$from=2018-05-18 04:28:22Z&$to=2018-05-19
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77' and
PolicyDefinitionId eq '/providers/microsoft.authorization/policydefinitions/1e30110a-5ceb-460c-a204-
c1c3969c6d62'
L’exemple de réponse ci-dessous a été ramené à une seule ressource non conforme par souci de concision.
La réponse détaillée fournit plusieurs éléments de données sur la ressource, la stratégie ou initiative, et
l’affectation. Notez que vous pouvez également voir quels paramètres d’affectation ont été transmis à la
définition de la stratégie.
{
"@odata.context":
States/$metadata#latest",
"@odata.count": 15,
"value": [{
"@odata.id": null,
"@odata.context":
States/$metadata#latest/$entity",
"timestamp": "2018-05-19T04:41:09Z",
"resourceId": "/subscriptions/{subscriptionId}/resourceGroups/rg-
tags/providers/Microsoft.Compute/virtualMachines/linux",
"policyAssignmentId": "/subscriptions/{subscriptionId}/resourceGroups/rg-
tags/providers/Microsoft.Authorization/policyAssignments/37ce239ae4304622914f0c77",
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-
460c-a204-c1c3969c6d62",
"effectiveParameters": "",
"isCompliant": false,
"subscriptionId": "{subscriptionId}",
"resourceType": "/Microsoft.Compute/virtualMachines",
"resourceLocation": "westus2",
"resourceGroup": "RG-Tags",
"resourceTags": "tbd",
"policyAssignmentName": "37ce239ae4304622914f0c77",
"policyAssignmentOwner": "tbd",
"policyAssignmentParameters": "{\"tagName\":{\"value\":\"costCenter\"},\"tagValue\":
{\"value\":\"Contoso-Test\"}}",
"policyAssignmentScope": "/subscriptions/{subscriptionId}/resourceGroups/RG-Tags",
"policyDefinitionName": "1e30110a-5ceb-460c-a204-c1c3969c6d62",
"policyDefinitionAction": "deny",
"policyDefinitionCategory": "tbd",
"policySetDefinitionId": "",
"policySetDefinitionName": "",
"policySetDefinitionOwner": "",
"policySetDefinitionCategory": "",
"policySetDefinitionParameters": "",
"managementGroupIds": "",
"policyDefinitionReferenceId": ""
}]
}
Visualiser les événements

Lorsqu’une ressource est créée ou mise à jour, un résultat d’évaluation de stratégie est généré. Ces
résultats sont appelés événements de stratégie. L’URI suivant permet d’afficher les événements de
stratégie récents associés à l’abonnement.
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyE
vents/default/queryResults?api-version=2018-04-04
{
"@odata.context":
Events/$metadata#default",
"@odata.count": 1,
"value": [{
"@odata.id": null,
"@odata.context":
Events/$metadata#default/$entity",
"NumAuditEvents": 16
}]
}
Pour plus d’informations sur l’interrogation des événements de stratégie, consultez l’article de référence
intitulé Événements Azure Policy.
Azure PowerShell
Le module Azure PowerShell d’Azure Policy est disponible dans PowerShell Gallery sous le nom
Az.PolicyInsights. Vous pouvez utiliser PowerShellGet pour installer le module à l’aide de
Install-Module -Name Az.PolicyInsights (vérifiez que vous disposez de la dernière version d’Azure
PowerShell) :
# Install from PowerShell Gallery via PowerShellGet

Install-Module -Name Az.PolicyInsights
# Import the downloaded module

Import-Module Az.PolicyInsights
# Login with Connect-AzAccount if not using Cloud Shell

Connect-AzAccount
Le module comporte les cmdlets suivantes :

Get-AzPolicyStateSummary
Get-AzPolicyState
Get-AzPolicyEvent
Get-AzPolicyRemediation
Remove-AzPolicyRemediation
Start-AzPolicyRemediation
Stop-AzPolicyRemediation
Exemple : Obtenir le résumé d’état de la stratégie affectée au premier plan qui comporte le plus grand
nombre de ressources non conformes.
PS> Get-AzPolicyStateSummary -Top 1
NonCompliantResources : 15
NonCompliantPolicies : 1
PolicyAssignments : {/subscriptions/{subscriptionId}/resourcegroups/RG-Tags/providers/micros
oft.authorization/policyassignments/37ce239ae4304622914f0c77}
Exemple : Obtenir l’enregistrement de l’état pour la ressource évaluée la plus récemment (par défaut, selon
un horodatage dans l’ordre décroissant).
PS> Get-AzPolicyState -Top 1
Timestamp : 5/22/2018 3:47:34 PM

ResourceId : /subscriptions/{subscriptionId}/resourceGroups/RG-Tags/providers/Mi
crosoft.Network/networkInterfaces/linux316
PolicyAssignmentId : /subscriptions/{subscriptionId}/resourceGroups/RG-Tags/providers/Mi
crosoft.Authorization/policyAssignments/37ce239ae4304622914f0c77
PolicyDefinitionId : /providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-
a204-c1c3969c6d62
IsCompliant : False
ResourceType : /Microsoft.Network/networkInterfaces
ResourceLocation : westus2
ResourceGroup : RG-Tags
ResourceTags : tbd
PolicyAssignmentName : 37ce239ae4304622914f0c77
PolicyAssignmentParameters : {"tagName":{"value":"costCenter"},"tagValue":{"value":"Contoso-Test"}}
PolicyAssignmentScope : /subscriptions/{subscriptionId}/resourceGroups/RG-Tags
PolicyDefinitionName : 1e30110a-5ceb-460c-a204-c1c3969c6d62
PolicyDefinitionAction : deny
PolicyDefinitionCategory : tbd
Exemple : Obtenir des détails pour toutes les ressources non conformes du réseau virtuel.
PS> Get-AzPolicyState -Filter "ResourceType eq '/Microsoft.Network/virtualNetworks'"
Timestamp : 5/22/2018 4:02:20 PM

crosoft.Network/virtualNetworks/RG-Tags-vnet
a204-c1c3969c6d62
IsCompliant : False
ResourceType : /Microsoft.Network/virtualNetworks
ResourceLocation : westus2
ResourceTags : tbd
Exemple : Obtenir des événements liés aux ressources non conformes du réseau virtuel qui se sont
produits après une date spécifique.
PS> Get-AzPolicyEvent -Filter "ResourceType eq '/Microsoft.Network/virtualNetworks'" -From '2018-05-
19'
Timestamp : 5/19/2018 5:18:53 AM

crosoft.Network/virtualNetworks/RG-Tags-vnet
a204-c1c3969c6d62
IsCompliant : False
ResourceType : /Microsoft.Network/virtualNetworks
ResourceLocation : eastus
ResourceTags : tbd
TenantId : {tenantId}
PrincipalOid : {principalOid}
Le champ PrincipalOid peut être utilisé pour obtenir un utilisateur spécifique avec l’applet de commande
Get-AzADUser d’Azure PowerShell. Remplacez {principalOid} par la réponse que vous obtenez à partir de
l’exemple précédent.
PS> (Get-AzADUser -ObjectId {principalOid}).DisplayName

Trent Baker
Journaux d’activité Azure Monitor

Si vous avez un espace de travail Log Analytics dans lequel AzureActivity de la solution Activity Log
Analytics est liée à votre abonnement, vous pouvez également afficher les résultats non conformes à partir
du cycle d’évaluation en utilisant de simples Kusto et la table AzureActivity . Grâce aux informations des
journaux d’activité Azure Monitor, des alertes peuvent être configurées de manière à signaler les
problèmes de non-conformité.
Étapes suivantes
Déterminer les causes de non-conformité
Lorsqu'une ressource Azure est jugée non conforme par rapport à une règle de stratégie, il est important
d'identifier la partie de la règle concernée. Il est également important d'identifier la modification qui a transformé
une ressource conforme en ressource non conforme. Pour ce faire, il existe deux moyens :
Détails de conformité
Historique des changements (préversion)
Détails de conformité
Lorsqu’une ressource est non conforme, les détails de conformité de cette ressource sont disponibles sur la page
Conformité à la stratégie. Le volet relatif aux détails de conformité comprend les informations suivantes :
Détails de la ressource tels que son nom, son type, son emplacement et son ID
État de conformité et timestamp de la dernière évaluation ayant trait à l'attribution de stratégie actuelle
Liste des motifs de non-conformité de la ressource
IMPORTANT
Les détails de conformité d'une ressource non conforme affichant la valeur actuelle des propriétés qui s'y rapportent,
l’utilisateur doit pouvoir utiliser une opération en lecture pour le type de ressource. Par exemple, si la ressource non
conforme est Microsoft.Compute/virtualmachines, l’utilisateur doit pouvoir utiliser l'opération
Microsoft.Compute/virtualMachines/read. Dans le cas contraire, une erreur d'accès s'affiche.
Pour afficher les détails de conformité, procédez comme suit :

2. Sur la page Vue d'ensemble ou Conformité, sélectionnez une stratégie affichant un état de
conformitéNon conforme.
3. Sous l'onglet Conformité des ressources de la page Conformité à la stratégie, cliquez avec le bouton
droit ou sélectionnez les points de suspension d’une ressource affichant un état de conformiténon
conforme. Sélectionnez ensuite Afficher les détails de la conformité.
4. Le volet Détails de conformité affiche des informations issues de la dernière évaluation de la ressource
ayant trait à l'attribution de stratégie actuelle. Dans cet exemple, le champ Microsoft.Sql/servers/version
indique 12.0 alors que la définition de la stratégie attendait 14.0. Si la ressource est non conforme pour
plusieurs raisons, ces différentes raisons sont répertoriées dans ce volet.
Pour une définition de stratégie auditIfNotExists ou deployIfNotExists, les détails incluent la propriété
details.type et autres propriétés facultatives. Pour une liste, consultez Propriétés auditIfNotExists et
Propriétés deployIfNotExists. Dernière ressource évaluée correspond à une ressource liée dans la section
Détails de la définition.
Exemple de définition partielle deployIfNotExists :
{
"if": {
"field": "type",
"equals": "[parameters('resourceType')]"
},
"then": {
"details": {
"type": "Microsoft.Insights/metricAlerts",
"field": "name",
"equals": "[concat(parameters('alertNamePrefix'), '-', resourcegroup().name, '-',
field('name'))]"
},
"existenceScope": "subscription",
"deployment": {
...
}
}
}
}
NOTE
Pour protéger les données, lorsqu’une valeur de propriété correspond à un secret, la valeur actuelle est remplacée par des
astérisques.
Ces détails expliquent les raisons pour lesquelles une ressource est actuellement non conforme, mais n'indiquent
pas le moment où la modification apportée à la ressource l'a rendue non conforme. Pour plus d’informations,
consultez Historique des modifications (préversion) ci-dessous.
Motifs de conformité
La matrice suivante mappe chaque motif possible à la condition responsable dans la définition de stratégie :
MOTIF CONDITION
La valeur actuelle doit contenir la valeur cible en tant que clé. containsKey ou not notContainsKey
La valeur actuelle doit contenir la valeur cible. contains ou not notContains
La valeur actuelle doit être égale à la valeur cible. equals ou not notEquals
La valeur actuelle doit être inférieure à la valeur cible. less ou not greaterOrEquals
La valeur actuelle doit être supérieure ou égale à la valeur greaterOrEquals ou not less
cible.
La valeur actuelle doit être supérieure à la valeur cible. greater ou not lessOrEquals
La valeur actuelle doit être inférieure ou égale à la valeur cible. lessOrEquals ou not greater
La valeur actuelle doit exister. exists
La valeur actuelle doit être dans la valeur cible. in ou not notIn
La valeur actuelle doit être identique à la valeur cible. like ou not notLike
MOTIF CONDITION
La valeur actuelle doit correspondre à la valeur cible match ou not notMatch

(sensibilité à la casse).
La valeur actuelle doit correspondre à la valeur cible (non- matchInsensitively ou not notMatchInsensitively
sensibilité à la casse).
La valeur actuelle ne doit pas contenir la valeur cible en tant notContainsKey ou not containsKey
que clé.
La valeur actuelle ne doit pas contenir la valeur cible. notContains ou not contains
La valeur actuelle ne doit pas être égale à la valeur cible. notEquals ou not equals
La valeur actuelle ne doit pas exister. not exists
La valeur actuelle ne doit pas être dans la valeur cible. notIn ou not in
La valeur actuelle ne doit pas être identique à la valeur cible. notLike ou not like
La valeur actuelle ne doit pas correspondre à la valeur cible notMatch ou not match
(sensibilité à la casse).
La valeur actuelle ne doit pas correspondre à la valeur cible notMatchInsensitively ou not matchInsensitively
(non-sensibilité à la casse).
Aucune ressource associée ne correspond aux détails de l'effet Aucune ressource du type défini dans then.details.type n'est
dans la définition de stratégie. associée à la ressource définie dans la portion if.
Détails de conformité pour Guest Configuration

Pour les stratégies auditIfNotExists de la catégorie Guest Configuration, plusieurs paramètres peuvent être évalués
dans la machine virtuelle et vous devez examiner les détails par paramètre. Par exemple, si vous effectuez un audit
pour obtenir la liste des stratégies de mot de passe et qu’une seule d’entre-elles a l’état Non conforme, vous devez
connaître les stratégies de mot de passe spécifiques qui ne sont pas conformes et pourquoi.
Vous ne serez peut-être pas autorisé à vous connecter directement à la machine virtuelle, mais devrez indiquer
pourquoi la machine virtuelle est Non conforme.
Portail Azure
Commencez par suivre les étapes de la section ci-dessus pour afficher les détails de conformité à la stratégie.
Dans le volet Détails de conformité, cliquez sur le lien Dernière ressource évaluée.
La page Affectation d'invité affiche les détails de conformité disponibles. Chaque ligne de la vue représente une
évaluation effectuée au sein de la machine. Dans la colonne Raison, une phrase décrivant pourquoi l'attribution
d'invité est Non conforme s’affiche. Par exemple, si vous auditez les stratégies de mot de passe, la colonne Raison
affiche du texte, dont la valeur actuelle de chaque paramètre.
Azure PowerShell
Vous pouvez également afficher les détails de conformité à partir d'Azure PowerShell. Assurez-vous tout d’abord
que vous disposez bien du module Guest Configuration.
Install-Module Az.GuestConfiguration
Vous pouvez afficher l’état actuel de toutes les attributions d’invités pour une machine virtuelle à l’aide de la
commande suivante :
Get-AzVMGuestPolicyReport -ResourceGroupName <resourcegroupname> -VMName <vmname>
PolicyDisplayName ComplianceReasons
----------------- -----------------
Audit that an application is installed inside Windows VMs
{[InstalledApplication]bwhitelistedapp}
Audit that an application is not installed inside Windows VMs.
{[InstalledApplication]NotInstalledApplica...
Pour afficher uniquement sous forme de phrase la raison qui explique pourquoi la machine virtuelle est non
conforme, renvoyez uniquement la propriété enfant Raison.
Get-AzVMGuestPolicyReport -ResourceGroupName <resourcegroupname> -VMName <vmname> | % ComplianceReasons | %
Reasons | % Reason
The following applications are not installed: '<name>'.
Vous pouvez également générer un historique de conformité des attributions d’invités dans l’étendue de la
machine. La sortie de cette commande inclut les détails de chaque rapport portant sur la machine virtuelle.
NOTE
La sortie peut renvoyer un important volume de données. Il est recommandé de stocker la sortie dans une variable.
$guestHistory = Get-AzVMGuestPolicyStatusHistory -ResourceGroupName <resourcegroupname> -VMName <vmname>

$guestHistory
PolicyDisplayName ComplianceStatus ComplianceReasons

StartTime EndTime VMName LatestRepor
tId
----------------- ---------------- ----------------- -
-------- ------- ------ -----------
[Preview]: Audit that an application is installed inside Windows VMs NonCompliant
02/10/2019 12:00:38 PM 02/10/2019 12:00:41 PM VM01 ../17fg0...
<truncated>
Pour simplifier cet affichage, utilisez le paramètre ShowChanged. La sortie de cette commande inclut
uniquement les rapports faisant état d'une modification de l'état de conformité.
$guestHistory = Get-AzVMGuestPolicyStatusHistory -ResourceGroupName <resourcegroupname> -VMName <vmname> -

ShowChanged
$guestHistory
PolicyDisplayName ComplianceStatus ComplianceReasons

StartTime EndTime VMName LatestRepor
tId
----------------- ---------------- ----------------- -
-------- ------- ------ -----------
Audit that an application is installed inside Windows VMs NonCompliant
02/10/2019 10:00:38 PM 02/10/2019 10:00:41 PM VM01 ../12ab0...
Audit that an application is installed inside Windows VMs. Compliant
02/09/2019 11:00:38 AM 02/09/2019 11:00:39 AM VM01 ../e3665...
Audit that an application is installed inside Windows VMs NonCompliant
02/09/2019 09:00:20 AM 02/09/2019 09:00:23 AM VM01 ../15ze1...
Historique des modifications (préversion)

Dans le cadre d’une nouvelle préversion publique, l'historique des modifications des 14 derniers jours est
disponible pour toutes les ressources Azure prenant en charge la suppression du mode. L'historique des
modifications indique quand une modification a été détectée et fournit un différentiel visuel pour chaque
modification. Une détection de modification est déclenchée lorsque les propriétés Resource Manager sont
ajoutées, supprimées ou modifiées.
2. Sur la page Vue d'ensemble ou Conformité, sélectionnez une stratégie dans un état de conformité.
3. Sous l'onglet Conformité des ressources de la page Conformité à la stratégie, sélectionnez une
ressource.
4. Sélectionnez l'onglet Historique des modifications (préversion) de la page Conformité des
ressources. La liste des modifications détectées, le cas échéant, s'affiche.
5. Sélectionnez une des modifications détectées. Le différentiel visuel de la ressource est présenté sur la page
Historique des modifications.
Le différentiel visuel aide à identifier les modifications apportées à une ressource. Les modifications détectées
peuvent ne pas être liées à l’état de conformité actuel de la ressource.
Les données de l'historique des modifications sont fournies par Azure Resource Graph. Pour interroger ces
informations en dehors du portail Azure, consultez Obtenir les modifications des ressources.
Étapes suivantes
Les ressources qui ne sont pas conformes à une stratégie deployIfNotExists ou modify peuvent être
placées dans un état conforme par le biais d’une correction. Pour effectuer la correction, vous indiquez
à Azure Policy d’exécuter l’effet deployIfNotExists ou l’étiquette operations de la stratégie affectée
sur vos ressources existantes. Cet article explique les étapes nécessaires pour comprendre et exécuter
des corrections avec Azure Policy.
Fonctionnement de la sécurité de la correction

Lorsque le logiciel Azure Policy exécute le modèle dans la définition de stratégie deployIfNotExists, il
utilise une identité managée. Azure Policy crée automatiquement une identité managée pour chaque
affectation, mais doit obtenir des informations sur les rôles à accorder à l’identité managée. S’il manque
des rôles à l’identité managée, cette erreur est affichée durant l’affectation de la stratégie ou d’une
initiative. Lorsque vous utilisez le portail, une fois l’affectation lancée, Azure Policy accorde
automatiquement à l’identité managée les rôles répertoriés.
IMPORTANT
Si une ressource modifiée par deployIfNotExists ou modify est en dehors de l’étendue de l’affectation de
stratégie ou que le modèle accède à des propriétés sur des ressources en dehors de l’étendue de l’affectation de
stratégie, l’identité managée de l’affectation doit se voir manuellement accorder l’accès, sinon le déploiement de
la correction échoue.
Configurer une définition de stratégie

La première étape consiste à définir les rôles dont deployIfNotExists ou modify ont besoin dans la
définition de stratégie pour déployer le contenu du modèle inclus. Sous la propriété details, ajoutez une
propriété roleDefinitionIds. Il s’agit d’un tableau de chaînes qui correspondent à des rôles dans votre
environnement. Pour obtenir un exemple complet, consultez l’exemple deployIfNotExists ou les
exemples modify.
"details": {
...
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
"/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
]
}
La propriété roleDefinitionIds utilise l’identificateur de ressource complet et n’accepte pas le

roleName court du rôle. Pour obtenir l’ID du rôle « Contributeur » dans votre environnement, utilisez
le code suivant :
az role definition list --name 'Contributor'
Configurer manuellement l’identité managée

Lorsque vous créez une affectation à l’aide du portail, Azure Policy génère l’identité managée et lui
accorde les rôles définis dans roleDefinitionIds. Dans les conditions suivantes, les étapes permettant
de créer l’identité managée et de lui accorder des autorisations doivent être effectuées manuellement :
Durant l’utilisation du SDK (par exemple, Azure PowerShell)
Quand une ressource en dehors de l’étendue de l’affectation est modifiée par le modèle
Quand une ressource en dehors de l’étendue de l’affectation est lue par le modèle
NOTE
Azure PowerShell et .NET sont les seuls SDK qui prennent en charge cette fonctionnalité.
Créer une identité managée avec PowerShell

Pour créer une identité managée pendant l’affectation de la stratégie, vous devez définir Location et
utiliser AssignIdentity. L’exemple suivant obtient la définition de la stratégie intégrée Déployer
Transparent Data Encryption SQL DB, définit le groupe de ressources cible, puis crée l’affectation.
# Get the built-in "Deploy SQL DB transparent data encryption" policy definition
$policyDef = Get-AzPolicyDefinition -Id
'/providers/Microsoft.Authorization/policyDefinitions/86a912f6-9a06-4e26-b447-11b16ba8659f'
# Get the reference to the resource group

$resourceGroup = Get-AzResourceGroup -Name 'MyResourceGroup'
# Create the assignment using the -Location and -AssignIdentity properties

$assignment = New-AzPolicyAssignment -Name 'sqlDbTDE' -DisplayName 'Deploy SQL DB transparent data
encryption' -Scope $resourceGroup.ResourceId -PolicyDefinition $policyDef -Location 'westus' -
AssignIdentity
La $assignment variable contient à présent l’ID du principal de l’identité managée, ainsi que les valeurs
standard retournées au moment de la création d’une affectation de stratégie. Elle est accessible via
$assignment.Identity.PrincipalId .
Accorder des rôles définis avec PowerShell

La nouvelle identité managée doit effectuer la réplication par le biais d’Azure Active Directory pour
pouvoir obtenir les rôles nécessaires. Une fois la réplication terminée, l’exemple suivant parcourt la
définition de stratégie dans $policyDef à la recherche des ID roleDefinitionIds et utilise New -
AzRoleAssignment pour accorder les rôles à la nouvelle identité managée.
# Use the $policyDef to get to the roleDefinitionIds array

$roleDefinitionIds = $policyDef.Properties.policyRule.then.details.roleDefinitionIds
if ($roleDefinitionIds.Count -gt 0)
{
$roleDefinitionIds | ForEach-Object {
$roleDefId = $_.Split("/") | Select-Object -Last 1
New-AzRoleAssignment -Scope $resourceGroup.ResourceId -ObjectId
$assignment.Identity.PrincipalId -RoleDefinitionId $roleDefId
}
}
Accorder des rôles définis par le biais du portail

À l’aide du portail, vous pouvez accorder les rôles définis à l’identité managée d’une affectation de deux
façons : en utilisant la gestion des identités et des accès ou en modifiant l’affectation de la stratégie
ou d’une initiative et en cliquant sur Enregistrer.
Pour ajouter un rôle à l’identité managée de l’affectation, effectuez les étapes suivantes :
2. Sélectionnez Affectations du côté gauche de la page Azure Policy.
3. Recherchez l’affectation qui a une identité managée, puis cliquez sur le nom.
4. Rechercher la propriété ID de l’affectation dans la page de modification. L’ID d’affectation est
semblable à ceci :
/subscriptions/{subscriptionId}/resourceGroups/PolicyTarget/providers/Microsoft.Authorization
/policyAssignments/2802056bfc094dfb95d4d7a5
Le nom de l’identité managée est la dernière partie de l’ID de ressource d’affectation, c’est-à-dire
2802056bfc094dfb95d4d7a5 dans cet exemple. Copiez cette partie de l’ID de ressource
d’affectation.
5. Accédez à la ressource ou au conteneur de ressources parent (groupe de ressources,
abonnement, groupe d’administration) auquel la définition de rôle doit être ajoutée
manuellement.
6. Cliquez sur le lien Contrôle d’accès (IAM ) dans la page des ressources, puis cliquez sur +
Ajouter une attribution de rôle en haut de la page du contrôle d’accès.
7. Sélectionnez le rôle approprié qui correspond à un roleDefinitionIds dans la définition de
stratégie. Laissez Attribuer l’accès à sur la valeur par défaut « Utilisateur, groupe ou application
Azure AD ». Dans la zone Sélectionner, collez ou tapez la partie de l’ID de ressource
d’affectation trouvée plus haut. Une fois la recherche terminée, cliquez sur l’objet portant le
même nom pour sélectionner l’ID, puis cliquez sur Enregistrer.
Créer une tâche de correction

Créer une tâche de correction via le portail
Durant l’évaluation, l’affectation de stratégie avec les effets deployIfNotExists ou modify détermine
s’il existe des ressources non conformes. Quand des ressources non conformes sont trouvées, les détails
sont fournis dans la page Correction. Outre la liste des stratégies qui ont des ressources non
conformes se trouve l’option permettant de déclencher une tâche de correction. Cette option crée un
déploiement à partir du modèle deployIfNotExists ou des opérations modify.
Pour créer une tâche de correction, effectuez les étapes suivantes :
2. Sélectionnez Correction sur le côté gauche de la page Azure Policy.
3. Toutes les affectations de stratégie deployIfNotExists ou modify ayant des ressources

non conformes sont incluses sous l’onglet Stratégies à corriger et dans la table de données.
Cliquez sur une stratégie ayant des ressources non conformes. La page Nouvelle tâche de
correction s’ouvre.
NOTE
Pour ouvrir la page Tâche de correction, vous pouvez également rechercher la stratégie à partir de la
page Conformité, cliquer dessus, puis cliquer sur le bouton Créer une tâche de correction.
4. Dans la page Nouvelle tâche de correction, filtrez les ressources à corriger à l’aide des points
de suspension de la section Étendue pour sélectionner les ressources enfants à partir de
l’endroit où la stratégie est affectée (y compris jusqu’aux objets de ressource individuels). En
outre, utilisez la liste déroulante Emplacements pour filtrer davantage les ressources. Seules les
ressources répertoriées dans la table sont corrigées.
5. Lancez la tâche de correction une fois les ressources filtrées en cliquant sur Corriger. La page de
conformité à la stratégie s’ouvre sur l’onglet Tâches de correction, qui affiche l’état de la
progression des tâches. Les déploiements créés par la tâche de correction commencent
immédiatement.
6. Cliquez sur la tâche de correction dans la page de conformité à la stratégie pour obtenir plus
d’informations sur la progression. Le filtrage utilisé pour la tâche est affiché, ainsi qu’une liste des
ressources en cours de correction.
7. Dans la page Tâche de correction, cliquez avec le bouton droit sur une ressource pour afficher
le déploiement de la tâche de correction ou la ressource. À la fin de la ligne, cliquez sur
Événements associés pour voir des détails tels qu’un message d’erreur.
Les ressources déployées par le biais d’une tâche de correction sont ajoutées à l’onglet Ressources
déployées sur la page de conformité à la stratégie.
Créer une tâche de correction via Azure CLI
Pour créer un tâche de correction avec Azure CLI, utilisez les commandes az policy remediation .
Remplacez {subscriptionId} par votre ID d’abonnement et {myAssignmentId} par l’ID d’affectation de
stratégie deployIfNotExists ou modify.
# Create a remediation for a specific assignment

az policy remediation create --name myRemediation --policy-assignment
'/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/policyAssignments/{myAssignmentId
}'
Pour accéder à d’autres exemples et commandes de correction, consultez les commandes de correction
de stratégie az.
Créer une tâche de correction via Azure PowerShell
Pour créer un tâche de correction avec Azure PowerShell, utilisez les commandes
Start-AzPolicyRemediation . Remplacez {subscriptionId} par votre ID d’abonnement et
{myAssignmentId} par l’ID d’affectation de stratégie deployIfNotExists ou modify.
# Create a remediation for a specific assignment

Start-AzPolicyRemediation -Name 'myRemedation' -PolicyAssignmentId
'/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/policyAssignments/{myAssignmentId
}'
Pour accéder à d’autres cmdlets et exemples de correction, consultez le module Az.PolicyInsights.
Étapes suivantes
Intégrer Azure Key Vault à Azure Policy
Azure Policy est un outil de gouvernance qui permet aux utilisateurs d’auditer et de gérer leur environnement
Azure à grande échelle. Azure Policy offre la possibilité de placer des barrières sur les ressources Azure afin de
s’assurer que celles-ci sont conformes aux règles de stratégie affectées. Il permet aux utilisateurs d’effectuer des
audits, l’application en temps réel et la correction de leur environnement Azure. Les résultats des audits réalisés par
la stratégie sont mis à disposition des utilisateurs dans un tableau de bord de conformité qui présente une vue
détaillée des ressources et composants conformes et non conformes. Pour plus d’informations, reportez-vous à la
rubrique Présentation du service Azure Policy.
Exemples de scénarios d’utilisation :
Vous souhaitez améliorer la position de sécurité de votre entreprise en implémentant des exigences en matière
de taille de clé minimale et de durée de validité maximale des certificats présents dans les coffres de clés de
votre entreprise, mais vous ne savez pas quelles équipes sont conformes et lesquelles ne le sont pas.
Vous ne disposez actuellement d’aucune solution pour effectuer un audit au sein de votre organisation ou vous
effectuez des audits manuels de votre environnement en demandant à chaque équipe de votre organisation
d’établir un état de leur conformité. Vous recherchez un moyen d’automatiser cette tâche, d’effectuer des audits
en temps réel et de garantir l’exactitude de l’audit.
Vous voulez appliquer les stratégies de sécurité de votre entreprise et empêcher la création de certificats auto-
signés, mais vous ne disposez d’aucun moyen automatisé pour bloquer leur création.
Vous souhaitez assouplir certaines exigences pour vos équipes de test, tout en conservant des contrôles étroits
sur votre environnement de production. Vous recherchez une méthode automatisée simple pour séparer
l’application de vos ressources.
Vous voulez être sûr de pouvoir annuler l’application des nouvelles stratégies en cas de problème de site actif.
Vous recherchez une solution en un clic pour désactiver l’application de la stratégie.
Vous faites appel à une solution tierce pour réaliser l’audit de votre environnement et vous souhaitez utiliser
une offre Microsoft interne.
Types d’effets des stratégies et conseils

Audit : Lorsque l’effet d’une stratégie est défini sur audit, celle-ci n’entraînera aucun changement cassant sur votre
environnement. Elle vous informera simplement du fait que des composants tels que des certificats ne sont pas
conformes aux définitions de la stratégie au sein d’une étendue spécifiée, en les marquant comme non conformes
dans le tableau de bord de conformité aux stratégies. L’audit est le paramètre par défaut si aucun effet de stratégie
n’est sélectionné.
Refuser : Lorsque l’effet d’une stratégie est défini sur refuser, celle-ci bloque la création de nouveaux composants
tels que des certificats et bloque les nouvelles versions de composants existants qui ne sont pas conformes à la
définition de stratégie. Les ressources non conformes existantes au sein d’un coffre de clés ne sont pas affectées.
Les capacités « audit » continuent de fonctionner.
Définitions de stratégie « prédéfinies » disponibles

Key Vault a créé un ensemble de stratégies que vous pouvez attribuer pour que des scénarios courants gèrent les
certificats. Ces stratégies sont « prédéfinies », autrement dit elles peuvent être activées sans que vous n’ayez à
écrire de code JSON personnalisé et elles sont prêtes à être attribuées dans le portail Azure. Vous pouvez
cependant personnaliser certains paramètres pour répondre aux besoins de votre organisation.
Les huit stratégies d’évaluation disponibles sont les suivantes.
Gérer la durée de validité de certificat (préversion)
Cette stratégie vous permet de gérer la durée de validité maximale de vos certificats stockés dans le coffre de clés.
La limitation de la durée de validité maximale de vos certificats est une pratique de sécurité recommandée. Si une
clé privée de votre certificat devenait compromise sans que cela ne soit détecté, l’utilisation de certificats à durée de
vie limitée réduit le délai d’exécution des dégâts en cours et également la valeur du certificat pour un attaquant.
Gérer les types de clés de certificat autorisés (préversion)
Cette stratégie vous permet de restreindre le type de certificats acceptés dans votre coffre de clés. Vous pouvez
utiliser cette stratégie pour vous assurer que les clés privées de vos certificats sont RSA, ECC ou sauvegardées par
HSM. Vous pouvez choisir les types de certificats autorisés dans la liste suivante.
RSA
RSA - HSM
ECC
ECC - HSM
Gérer les déclencheurs d’action de durée de vie de certificat (préversion)
Cette stratégie vous permet de gérer l’action de durée de vie spécifiée pour les certificats qui expirent dans un
certain nombre de jours ou qui ont atteint un certain pourcentage de durée de vie.
Gérer les certificat émis par une autorité de certification intégrée (préversion)
Si vous utilisez une autorité de certification intégrée Key Vault (Digicert ou GlobalSign) et que vous voulez que les
utilisateurs fassent appel à l’un de ces deux fournisseurs, vous pouvez utiliser cette stratégie pour mener un audit
ou appliquer votre sélection. Cette stratégie peut également être utilisée pour auditer ou refuser la création de
certificats auto-signés dans le coffre de clés.
Gérer les certificat émis par une autorité de certification intégrée (préversion)
Si vous utilisez une autorité de certification interne ou non intégrée à Key Vault et que vous voulez que les
utilisateurs fassent appel à une autorité de certification figurant dans une liste que vous fournissez, vous pouvez
utiliser cette stratégie pour créer une liste autorisée d’autorités de certification par nom d’émetteur. Cette stratégie
peut également être utilisée pour auditer ou refuser la création de certificats auto-signés dans le coffre de clés.
Gérer les noms de courbe autorisés pour les certificats de chiffrement à courbe elliptique (préversion)
Si vous utilisez des certificats à courbe elliptique ou ECC, vous pouvez personnaliser une liste autorisée de noms de
courbe à partir de la liste ci-dessous. L’option par défaut autorise tous les noms de courbe suivants.
P -256
P -256K
P -384
P -521
Gérer la taille minimale de clé pour les certificats RSA (préversion)
Si vous utilisez des certificats RSA, vous pouvez choisir une taille de clé minimale requise pour vos certificats. Vous
pouvez sélectionner une option dans la liste ci-dessous.
2048 bits
3072 bits
4096 bits
Gérer les certificats arrivés à un nombre de jours spécifié avant expiration (préversion)
Votre service peut subir une panne si un certificat qui n’est pas surveillé correctement n’est pas pivoté avant son
expiration. Cette stratégie est critique pour vous assurer que vos certificats stockés dans un coffre de clés sont sous
surveillance. Nous vous recommandons d’appliquer cette stratégie plusieurs fois avec différents seuils d’expiration,
par exemple 180, 90, 60 et 30 jours. Cette stratégie peut être utilisée pour surveiller et trier l’expiration des
certificats dans votre organisation.
Exemple de scénario
Vous gérez un coffre de clés utilisé par plusieurs équipes qui contient 100 certificats et vous voulez être sûr
qu’aucun des certificats du coffre de clés n’est valide plus de 2 ans.
1. Vous attribuez la stratégie Gérer la durée de validité des certificats, spécifiez que la durée de validité maximale
d’un certificat est 24 mois, puis définissez l’effet de la stratégie sur « audit ».
2. En consultant le rapport de conformité sur le portail Azure, vous constatez que 20 certificats sont non
conformes et valides plus de 2 ans, et que les autres certificats sont conformes.
3. Vous contactez les propriétaires de ces certificats et les informez de la nouvelle exigence de sécurité spécifiant
que les certificats ne doivent pas être valides plus de 2 ans. Certaines équipes répondent et 15 des certificats
sont renouvelés avec une durée de validité maximale de 2 ans ou moins. Les autres équipes ne répondent pas et
il reste 5 certificats non conformes dans votre coffre de clés.
4. Vous remplacez l’effet de la stratégie attribuée par « refuser ». Les 5 certificats non conformes ne sont pas
révoqués et continuent à fonctionner. Toutefois, ils ne peuvent pas être renouvelés avec une durée de validité
supérieure à 2 ans.
Activer et gérer une stratégie Key Vault via le portail Azure

Sélectionner une définition de stratégie
1. Connectez-vous au portail Azure.
2. Recherchez « Stratégie » dans la barre de recherche et sélectionnez Stratégie.
3. Dans la fenêtre Stratégie, sélectionnez Définitions.

4. Dans le filtre Catégorie, désélectionnez Sélectionner tout et sélectionnez Key Vault.
5. Vous devriez maintenant voir toutes les stratégies disponibles pour la préversion publique, pour Azure Key
Vault. Veillez à lire et comprendre la section sur les conseils de stratégie ci-dessus et sélectionnez la stratégie
que vous voulez attribuer à une étendue.
Attribuer une stratégie à une étendue

1. Sélectionnez une stratégie à appliquer. Dans cet exemple, il s’agit de la stratégie Gérer la durée de validité
des certificats. Cliquez sur le bouton Attribuer dans le coin supérieur gauche.
2. Sélectionnez l’abonnement dans lequel vous voulez appliquer la stratégie. Vous pouvez choisir de
restreindre l’étendue à un seul groupe de ressources au sein d’un abonnement. Si vous souhaitez appliquer
la stratégie à l’ensemble de l’abonnement et exclure certains groupes de ressources, vous pouvez également
configurer une liste d’exclusions. Définissez le sélecteur d’application de stratégie sur Activé si vous voulez
que l’effet de la stratégie (audit ou refuser) se produise ou sur Désactivé pour désactiver l’effet (audit ou
refuser).
3. Cliquez sur l’onglet des paramètres en haut de l’écran pour indiquer la durée de validité maximale en mois
souhaitée. Sélectionnez audit ou refuser pour l’effet de la stratégie selon les conseils fournis dans les
sections précédentes. Sélectionnez ensuite le bouton Vérifier + Créer.
Afficher les résultats de conformité
1. Revenez au panneau Stratégie et sélectionnez l’onglet Conformité. Cliquez sur l’attribution de stratégie dont
vous voulez afficher les résultats de conformité.
2. Sur cette page, vous pouvez filtrer les résultats par coffres conformes et non conformes. Vous pouvez
consulter ici une liste des coffres de clés non conformes dans l’étendue de l’attribution de stratégie. Un
coffre est jugé non conforme si un ou plusieurs de ses composants (certificats) sont non conformes. Vous
pouvez sélectionner un coffre particulier pour afficher les composants (certificats) non conformes.
3. Afficher le nom des composants non conformes au sein d’un coffre
4. Si vous devez vérifier si les utilisateurs se voient refuser la possibilité de créer des ressources dans le coffre
de clés, vous pouvez cliquer sur l’onglet Événements des composants (préversion) pour afficher une
synthèse des opérations de refus de certificat indiquant le demandeur et le timestamp des requêtes.
Limitations des fonctionnalités

Après avoir attribué une stratégie avec un effet « refuser », la prise d’effet du refus de créer des ressources non
conformes peut prendre entre 30 minutes (en moyenne) et 1 heure (pire des cas). Une fois l’évaluation de stratégie
des composants existants d’un coffre effectuée, l’affichage des résultats de conformité dans l’interface utilisateur du
portail peut prendre entre 1 heure (en moyenne) et 2 heures (pire des cas). Si les résultats de conformité
présentent le statut « Non démarré », cela peut être dû aux raisons suivantes :
L’évaluation des stratégies n’est pas encore terminée. La latence de l’évaluation initiale peut atteindre 2 heures
dans le pire des cas.
Il n’y a pas de coffres de clés dans l’étendue de l’attribution de stratégie.
Il n’y a pas de coffres de clés avec des certificats dans l’étendue de l’attribution de stratégie.
Étapes suivantes
En savoir plus sur le service Azure Policy
Consultez des exemples Key Vault : Définitions de stratégies prédéfinies Key Vault
Déployer à grande échelle Azure Policy vers des
abonnements délégués
En tant que fournisseur de services, vous assurez peut-être la gestion des ressources déléguée Azure de plusieurs
locataires clients. Azure Lighthouse permet aux fournisseurs de services d’effectuer des opérations à grande échelle
sur plusieurs locataires à la fois, améliorant ainsi l'efficacité des tâches de gestion.
Cette rubrique montre comment utiliser Azure Policy pour déployer une définition et une affectation de stratégie
sur plusieurs locataires à l’aide de commandes PowerShell. Dans cet exemple, la définition de stratégie veille à ce
que les comptes de stockage soient sécurisés en n'autorisant que le trafic HTTPS.
Utiliser Azure Resource Graph pour interroger plusieurs locataires

clients
Vous pouvez utiliser Azure Resource Graph pour interroger tous les abonnements des locataires clients que vous
gérez. Dans cet exemple, nous allons identifier tous les comptes de stockage de ces abonnements qui n'exigent pas
encore le trafic HTTPS.
$MspTenant = "insert your managing tenantId here"
$subs = Get-AzSubscription
$ManagedSubscriptions = Search-AzGraph -Query "ResourceContainers | where type ==

'microsoft.resources/subscriptions' | where tenantId != '$($mspTenant)' | project name, subscriptionId,
tenantId" -subscription $subs.subscriptionId
Search-AzGraph -Query "Resources | where type =~ 'Microsoft.Storage/storageAccounts' | project name, location,

subscriptionId, tenantId, properties.supportsHttpsTrafficOnly" -subscription
$ManagedSubscriptions.subscriptionId | convertto-json
Déployer une stratégie sur plusieurs locataires clients

L’exemple ci-dessous illustre comment utiliser un modèle Azure Resource Manager pour déployer une définition
de stratégie et une affectation de stratégie sur des abonnements délégués dans plusieurs locataires clients. Cette
définition de stratégie exige que tous les comptes de stockage utilisent du trafic HTTPS. Elle empêche la création de
comptes de stockage non conformes et marquent comme non conformes les comptes de stockage existants qui
n'utilisent pas ce paramètre.
Write-Output "In total, there are $($ManagedSubscriptions.Count) delegated customer subscriptions to be
managed"
foreach ($ManagedSub in $ManagedSubscriptions)

{
Select-AzSubscription -SubscriptionId $ManagedSub.subscriptionId
New-AzDeployment -Name mgmt `

-Location eastus `
-TemplateUri "https://raw.githubusercontent.com/Azure/Azure-Lighthouse-
samples/master/Azure-Delegated-Resource-Management/templates/policy-enforce-https-
storage/enforceHttpsStorage.json" `
-AsJob
}
Valider le déploiement de la stratégie

Une fois que vous avez déployé le modèle Azure Resource Manager, vous pouvez vérifier la réussite de
l'application de la définition de stratégie en tentant de créer un compte de stockage avec EnableHttpsTrafficOnly
défini sur false dans l’un de vos abonnements délégués. En raison de l’affectation de la stratégie, vous ne devriez
pas pouvoir créer ce compte de stockage.
New-AzStorageAccount -ResourceGroupName (New-AzResourceGroup -name policy-test -Location eastus -

Force).ResourceGroupName `
-Name (get-random) `
-Location eastus `
-EnableHttpsTrafficOnly $false `
-SkuName Standard_LRS `
-Verbose

Lorsque vous avez terminé, supprimez la définition et l’affectation de stratégie créées par le déploiement.
foreach ($ManagedSub in $ManagedSubscriptions)

{
select-azsubscription -subscriptionId $ManagedSub.subscriptionId
Remove-AzDeployment -Name mgmt -AsJob
$Assignment = Get-AzPolicyAssignment | where-object {$_.Name -like "enforce-https-storage-assignment"}
if ([string]::IsNullOrEmpty($Assignment))
{
Write-Output "Nothing to clean up - we're done"
}
else
{
Remove-AzPolicyAssignment -Name 'enforce-https-storage-assignment' -Scope

"/subscriptions/$($ManagedSub.subscriptionId)" -Verbose
Write-Output "Deployment has been deleted - we're done"

}
}
Étapes suivantes
En savoir plus sur Azure Policy.
Découvrez les Expériences de gestion inter-locataire.
Azure Lighthouse permet aux fournisseurs de services de créer et de modifier des définitions de stratégies au sein
d’un abonnement délégué. Toutefois, pour déployer des stratégies qui utilisent une tâche de correction (autrement
dit, des stratégies avec l’effet deployIfNotExists ou modify), vous devez créer une identité managée dans le locataire
du client. Cette identité managée peut être utilisée par Azure Policy pour déployer le modèle dans la stratégie. Il
existe des étapes à suivre pour activer ce scénario, à la fois quand vous intégrez le client pour la gestion des
ressources déléguées Azure et quand vous déployez la stratégie elle-même.
Créer un utilisateur qui peut attribuer des rôles à une identité managée
dans le locataire du client
Quand vous intégrez un client pour la gestion des ressources déléguées Azure, vous utilisez un modèle Azure
Resource Manager avec un fichier de paramètres qui définit les utilisateurs, les groupes d’utilisateurs et les
principaux de service de votre locataire gestionnaire qui pourront accéder aux ressources déléguées dans le
locataire du client. Dans votre fichier de paramètres, chacun de ces utilisateurs (principalId) se voit attribuer un
rôle intégré (roleDefinitionId) qui définit le niveau d’accès.
Pour permettre à un principalId de créer une identité managée dans le locataire du client, vous devez définir son
roleDefinitionId sur Administrateur de l’accès utilisateur. Bien que ce rôle ne soit généralement pas pris en
charge, il peut être utilisé dans ce scénario spécifique, permettant aux utilisateurs disposant de cette autorisation
d’affecter un ou plusieurs rôles intégrés spécifiques à des identités managées. Ces rôles sont définis dans la
propriété delegatedRoleDefinitionIds. Vous pouvez inclure ici n’importe quel rôle intégré, sauf Administrateur
de l’accès utilisateur ou Propriétaire.
Une fois le client intégré, le principalId créé dans cette autorisation pourra affecter ces rôles intégrés à des
identités managées dans le locataire du client. Toutefois, il n’aura aucune autre autorisation normalement associée
au rôle Administrateur de l’accès utilisateur.
L’exemple ci-dessous montre un principalId qui aura le rôle Administrateur de l’accès utilisateur. Cet utilisateur
pourra attribuer deux rôles intégrés à des identités managées dans le locataire du client : Contributeur et
Contributeur Log Analytics.
{
"principalId": "3kl47fff-5655-4779-b726-2cf02b05c7c4",
"principalIdDisplayName": "Policy Automation Account",
"roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
"delegatedRoleDefinitionIds": [
"b24988ac-6180-42a0-ab88-20f7382dd24c",
"92aaf0da-9dab-42b6-94a3-d43ce8d16293"
]
}
Déployer des stratégies pouvant être corrigées

Une fois que vous avez créé l’utilisateur avec les autorisations nécessaires comme décrit ci-dessus, cet utilisateur
peut déployer des stratégies dans le locataire du client qui utilisent des tâches de correction.
Par exemple, supposez que vous souhaitez activer les diagnostics sur des ressources Azure Key Vault dans le
locataire du client, comme illustré dans cet exemple. Un utilisateur du client gestionnaire disposant des
autorisations appropriées (comme décrit ci-dessus) déploierait un modèle Azure Resource Manager pour activer ce
scénario.
Notez que la création de l’attribution de stratégie à utiliser avec un abonnement délégué doit être effectuée par le
biais d’API, et non dans le portail Azure. Dans ce cas, l’apiVersion doit être définie sur 2019-04-01-Preview, qui
comprend la nouvelle propriété delegatedManagedIdentityResourceId. Cette propriété vous permet d’inclure
une identité managée qui réside dans le locataire du client (dans un abonnement ou un groupe de ressources qui a
été intégré à la gestion des ressources déléguées Azure).
L’exemple suivant montre une attribution de rôle avec un delegatedManagedIdentityResourceId.
"type": "Microsoft.Authorization/roleAssignments",
"apiVersion": "2019-04-01-preview",
"name": "[parameters('rbacGuid')]",
"dependsOn": [
"[variables('policyAssignment')]"
],
"properties": {
"roleDefinitionId": "[concat(subscription().id,
'/providers/Microsoft.Authorization/roleDefinitions/', variables('rbacContributor'))]",
"principalType": "ServicePrincipal",
"delegatedManagedIdentityResourceId": "[concat(subscription().id,
'/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment'))]",
"principalId": "
[toLower(reference(concat('/providers/Microsoft.Authorization/policyAssignments/',
variables('policyAssignment')), '2018-05-01', 'Full' ).identity.principalId)]"
}
TIP
Un exemple similaire est disponible pour illustrer comment déployer une stratégie qui ajoute ou supprime une balise (à l’aide
de l’effet modify) à un abonnement délégué.
Étapes suivantes
En savoir plus sur Azure Policy.
En savoir plus sur les identités managées pour les ressources Azure.
Activer Azure Monitor pour machines virtuelles
(préversion) à l’aide d’Azure Policy
Cet article explique comment activer Azure Monitor pour machines virtuelles (préversion) sur des groupes de
machines virtuelles identiques ou des machines virtuelles Azure à l’aide d’Azure Policy. À la fin de ce processus,
vous aurez configuré correctement l’activation de l’agent Log Analytics et de l’agent de dépendances, et identifié les
machines virtuelles qui ne sont pas conformes.
Pour découvrir, gérer et activer Azure Monitor pour machines virtuelles pour l’ensemble de vos groupes de
machines virtuelles identiques ou machines virtuelles Azure, vous pouvez utiliser Azure Policy ou Azure
PowerShell. Azure Policy est la méthode que nous recommandons, car vous pouvez gérer des définitions de
stratégie pour régir efficacement vos abonnements afin de garantir la conformité cohérente et l’activation
automatique des machines virtuelles nouvellement mises en service. Ces définitions de stratégie :
Déployer Log Analytics Agent et Dependency Agent.
Créer un rapport sur les résultats de conformité.
Corriger les machines virtuelles non conformes.
Si vous souhaitez accomplir ces tâches avec Azure PowerShell ou un modèle Azure Resource Manager, consultez
Activer Azure Monitor pour machines virtuelles (préversion) à l’aide du modèle Azure PowerShell ou Resource
Manager.
Présentation de la fonctionnalité Gérer la couverture de stratégie

À l’origine, l’expérience avec Azure Policy visant à gérer et déployer les définitions de stratégie pour Azure Monitor
pour machines virtuelles était réalisée exclusivement à partir d’Azure Policy. La fonctionnalité Gérer la couverture
de stratégie simplifie et facilite la découverte, la gestion et l’activation à grande échelle de l’initiative Activer Azure
Monitor pour machines virtuelles, qui inclut les définitions de stratégie mentionnées précédemment. Vous
pouvez accéder à cette nouvelle fonctionnalité à partir de l’onglet Prise en main dans Azure Monitor pour
machines virtuelles. Sélectionnez Gérer la couverture de stratégie pour afficher la page Azure Monitor for
VMs Policy Coverage (Couverture de stratégie Azure Monitor pour machines virtuelles) .
À ce stade, vous pouvez vérifier et gérer la couverture pour l’initiative sur l’ensemble de vos groupes
d’administration et abonnements. Vous pouvez comprendre combien de machines virtuelles existent dans chacun
des groupes d’administration et des abonnements, ainsi que leur état de conformité.
Ces informations sont utiles pour vous aider à planifier et exécuter votre scénario de gouvernance pour Azure
Monitor pour machines virtuelles à partir d’un emplacement central. Alors qu’Azure Policy fournit une vue de
conformité lorsqu’une stratégie ou une initiative est affectée à une étendue, avec cette nouvelle page, vous pouvez
découvrir où la stratégie ou l’initiative n’est pas affectée et l’y assigner. Toutes les actions comme l’affectation,
l’affichage et la modification redirigent directement vers Azure Policy. La page Azure Monitor for VMs Policy
Coverage (Couverture de stratégie Azure Monitor pour machines virtuelles) est une expérience étendue et
intégrée pour l’initiative Activer Azure Monitor pour machines virtuelles uniquement.
À partir de cette page, vous pouvez également configurer votre espace de travail Log Analytics pour Azure Monitor
pour machines virtuelles, qui :
Installe la solution Service Map.
Active les compteurs de performances de système d’exploitation utilisés par les graphiques de performances, les
classeurs et vos alertes et requêtes de journal personnalisées.
Cette option n’est associée à aucune action de stratégie. Elle est disponible pour fournir un moyen simple de
satisfaire les conditions préalables nécessaires à l’activation d’Azure Monitor pour machines virtuelles.
Quelles sont les informations disponibles sur cette page ?
Le tableau suivant fournit le détail des informations présentées sur la page de couverture de stratégie et la façon de
les interpréter.
FONCTION DESCRIPTION
Portée Groupe d’administration et abonnements auxquels vous avez

accès ou vous avez hérité l’accès avec la possibilité de
descendre dans la hiérarchie du groupe d’administration.
FONCTION DESCRIPTION
Rôle Votre rôle dans l’étendue, qui peut être lecteur, propriétaire ou
contributeur. Dans certains cas, il peut apparaître vide pour
indiquer que vous pouvez avoir accès à l’abonnement, mais
pas au groupe d’administration auquel il appartient. Les
informations figurant dans les autres colonnes varient en
fonction de votre rôle. Le rôle est la clé permettant de
déterminer les données que vous pouvez voir et les actions
que vous pouvez effectuer quant à l’affectation des stratégies
ou des initiatives (propriétaire), leur modification ou l’affichage
de la conformité.
Nombre total de machines virtuelles Nombre de machines virtuelles figurant dans cette étendue.
Pour un groupe d’administration, il s’agit de la somme des
machines virtuelles imbriquées sous les abonnements ou le
groupe d’administration enfant.
Couverture d’attribution Pourcentage de machines virtuelles qui sont couvertes par la

stratégie ou l’initiative.
État de l’attribution Informations sur l’état de l’attribution de votre stratégie ou

initiative.
Machines virtuelles conformes Nombre de machines virtuelles conformes à la stratégie ou à

l’initiative. Pour l’initiative Activer Azure Monitor pour
machines virtuelles, il s’agit du nombre de machines
virtuelles qui ont à la fois l’agent Log Analytics et l’agent de
dépendances. Dans certains cas, il peut être vide en l’absence
d’attributions, de machines virtuelles ou d’un nombre
d’autorisations suffisant. Des informations sont fournies sous
État de conformité.
Conformité La conformité globale est la somme des ressources distinctes

conformes divisée par la somme de toutes les ressources
distinctes.
État de conformité Informations sur l’état de conformité de votre attribution de

stratégie ou d’initiative.
Lorsque vous attribuez la stratégie ou l’initiative, l’étendue sélectionnée dans l’attribution peut être l’étendue
répertoriée ou un sous-ensemble de celle-ci. Par exemple, vous avez peut-être créé une attribution pour un
abonnement (étendue de la stratégie) et non pas un groupe d’administration (étendue de la couverture). Dans ce
cas, la valeur de Couverture d’attribution indique les machines virtuelles dans l’étendue de stratégie ou
d’initiative divisée par les machines virtuelles dans l’étendue de couverture. Dans un autre cas, vous pouvez avoir
exclu des machines virtuelles, des groupes de ressources ou un abonnement de l’étendue de stratégie. Si la valeur
est vide, elle indique que la stratégie ou l’initiative n’existe pas ou que vous n’avez pas l’autorisation. Des
informations sont fournies sous État de l’attribution.
Activer à l’aide d’Azure Policy

Pour activer Azure Monitor pour machines virtuelles à l’aide d’Azure Policy dans votre tenant :
Attribuez l’initiative à une étendue : groupe d’administration, abonnement ou groupe de ressources.
Examinez et corrigez les résultats de conformité.
Pour plus d’informations sur l’affectation d’Azure Policy, consultez Vue d’ensemble d’Azure Policy et examinez la
présentation des groupes d’administration avant de continuer.
Stratégies pour les machines virtuelles Azure
Les définitions de stratégie pour une machine virtuelle Azure sont listées dans le tableau ci-dessous.
NOM DESCRIPTION TYPE
[Préversion] : Activer Azure Monitor Activez Azure Monitor pour machines Initiative
pour machines virtuelles virtuelles dans l’étendue spécifiée
(groupe d’administration, abonnement
ou groupe de ressources). Utilise
l’espace de travail Log Analytics comme
paramètre.
[Préversion] : Vérifier le déploiement de Présente les machines virtuelles comme Stratégie

l’agent de dépendances - Image de non conformes si l’image de machine
machine virtuelle (système virtuelle (système d’exploitation) n’est
d’exploitation) non listée pas définie dans la liste et si l’agent n’est
pas installé.
[Préversion] : Auditer le déploiement de Présente les machines virtuelles comme Stratégie

l’agent Log Analytics - Image de non conformes si l’image de machine
machine virtuelle (système virtuelle (système d’exploitation) n’est
d’exploitation) non listée pas définie dans la liste et si l’agent n’est
pas installé.
[Préversion] : Déployer l’agent de Déployez l’agent de dépendances pour Stratégie

dépendances pour les machines les machines virtuelles Linux si l'image
virtuelles Linux de machine virtuelle (système
d’exploitation) est définie dans la liste et
que l'agent n'est pas installé.

dépendances pour les machines les machines virtuelles Windows si
virtuelles Windows l’image de machine virtuelle (système
si l’agent n’est pas installé.
[Préversion] : Déployer l’agent Log Déployez l’agent Log Analytics pour les Stratégie
Analytics pour les machines virtuelles machines virtuelles Linux si l’image de
Linux machine virtuelle (système
Analytics pour les machines virtuelles machines virtuelles Windows si l’image
Windows de machine virtuelle (système
Stratégies pour les groupes de machines virtuelles identiques Azure

Les définitions de stratégie pour un groupe de machines virtuelles identiques Azure sont listées dans le tableau ci-
dessous.

[Préversion] : Activer Azure Monitor Activez Azure Monitor pour les groupes Initiative
pour les groupes de machines virtuelles de machines virtuelles identiques dans
identiques l’étendue spécifiée (groupe
d’administration, abonnement ou
groupe de ressources). Utilise l’espace
de travail Log Analytics comme
paramètre. Remarque : Si la stratégie de
mise à niveau du groupe identique est
définie sur Manuelle, appliquez
l’extension à toutes les machines
virtuelles du groupe en appelant une
mise à niveau. Dans l’interface de ligne
de commande, il s’agit de
az vmss update-instances .
[Préversion] : Auditer le déploiement de Présente le groupe de machines Stratégie

l’agent de dépendances dans des virtuelles identiques comme non
groupes de machines virtuelles conforme si l’image de machine virtuelle
identiques - Image de machine virtuelle (système d’exploitation) n’est pas définie
(système d’exploitation) non listée dans la liste et si l’agent n’est pas
installé.
[Préversion] : Auditer le déploiement de Présente le groupe de machines Stratégie

l’agent Log Analytics dans des groupes virtuelles identiques comme non
de machines virtuelles identiques - conforme si l’image de machine virtuelle
Image de machine virtuelle (système (système d’exploitation) n’est pas définie
d’exploitation) non listée dans la liste et si l’agent n’est pas
installé.

dépendances pour les groupes de les groupes de machines virtuelles
machines virtuelles identiques Linux identiques Linux si l’image de machine
virtuelle (système d’exploitation) est
définie dans la liste et si l’agent n’est pas
installé.

dépendances pour les groupes de les groupes de machines virtuelles
machines virtuelles identiques Windows identiques Linux si l’image de machine
installé.
Analytics pour les groupes de machines groupes de machines virtuelles
virtuelles identiques Linux identiques Linux si l’image de machine
installé.
Analytics pour les groupes de machines groupes de machines virtuelles
virtuelles identiques Windows identiques Windows si l’image de
machine virtuelle (système
La stratégie autonome (non incluse avec l’initiative) est décrite ici :

[Préversion] : Auditer les machines Signalez les machines virtuelles comme Stratégie
virtuelles de l’espace de travail Log non conformes si elles ne se connectent
Analytics - Signaler les incompatibilités pas à l’espace de travail Log Analytics
spécifié dans l’attribution de stratégie
ou d’initiative.
Assigner l’initiative Azure Monitor

Pour créer l’attribution de stratégie à partir de la page Azure Monitor for VMs Policy Coverage (Couverture
de stratégie Azure Monitor pour machines virtuelles) , procédez comme suit. Pour savoir comment effectuer
ces étapes, consultez Créer une affectation de stratégie à partir du portail Azure.
Lorsque vous attribuez la stratégie ou l’initiative, l’étendue sélectionnée dans l’attribution peut être l’étendue
répertoriée ici ou un sous-ensemble de celle-ci. Par exemple, vous avez peut-être créé une attribution pour
l’abonnement (étendue de la stratégie) et non pas le groupe d’administration (étendue de la couverture). Dans ce
cas, le pourcentage de couverture indique les machines virtuelles dans l’étendue de stratégie ou d’initiative divisée
par les machines virtuelles dans l’étendue de couverture. Dans un autre cas, vous pouvez avoir exclu des machines
virtuelles, des groupes de ressources ou un abonnement de l’étendue de stratégie. Si la valeur est vide, elle indique
que la stratégie ou l’initiative n’existe pas ou que vous n’avez pas d’autorisation. Des informations sont fournies
sous État de l’attribution.
1. Connectez-vous au portail Azure.
2. Dans le Portail Azure, sélectionnez Surveiller.
3. Choisissez Machines virtuelles (préversion) dans la section Insights.
4. Sélectionnez l’onglet Prise en main. Dans la page, sélectionnez Gérer la couverture de stratégie.
5. Sélectionnez un groupe d’administration ou un abonnement à partir du tableau. Sélectionnez Étendue en
sélectionnant les points de suspension (...). Dans cet exemple, une étendue limite l’attribution de stratégie à
un regroupement de machines virtuelles pour leur application.
6. Dans la page Attribution de stratégie Azure, elle est préremplie avec l’initiative Activer Azure Monitor
pour machines virtuelles. La zone Nom de l’attribution est automatiquement remplie avec le nom
d’initiative, mais vous pouvez le modifier. Vous pouvez également ajouter une description facultative. La
zone Attribué par est rempli automatiquement en fonction de l’utilisateur connecté. Cette valeur est
facultative.
7. (Facultatif) Pour supprimer une ou plusieurs ressources à partir de l’étendue, sélectionnez Exclusions.
8. Dans la liste déroulante Espace de travail Log Analytics de la région prise en charge, sélectionnez un
espace de travail.
NOTE
Si l’espace de travail se trouve en dehors de l’étendue de l’affectation, accordez des autorisations de Contributeur Log
Analytics à l’ID du principal de l’affectation de stratégie. Si vous ne le faites pas, vous risquez d’obtenir un message
d’échec de déploiement du type
The client '343de0fe-e724-46b8-b1fb-97090f7054ed' with object id '343de0fe-e724-46b8-b1fb-
97090f7054ed' does not have authorization to perform action
'microsoft.operationalinsights/workspaces/read' over scope ...
Pour accorder l’accès, consultez Configurer manuellement l’identité managée.
La case à cocher Identité managée est sélectionnée, car l’initiative en cours d’attribution inclut une stratégie avec
l’effet deployIfNotExists.
9. Dans la liste déroulante Gérer l’emplacement d’identité, sélectionnez la région appropriée.
10. Sélectionnez Attribuer.
Une fois que vous avez créé l’attribution, la page Azure Monitor for VMs Policy Coverage (Couverture de
stratégie Azure Monitor pour machines virtuelles) met à jour Couverture d’attribution, État de
l’attribution, Machines virtuelles conformes et État de conformité pour refléter les modifications.
La matrice suivante mappe chaque état de conformité possible pour l’initiative.
ÉTAT DE CONFORMITÉ DESCRIPTION
Conforme L’agent Log Analytics et l’agent de dépendances sont déployés

sur toutes les machines virtuelles dans l’étendue.
Non conforme L’agent Log Analytics et l’agent de dépendances ne sont pas

déployés sur toutes les machines virtuelles dans l’étendue et
certaines machines virtuelles peuvent nécessiter une
correction.
Non démarré Une nouvelle attribution a été ajoutée.
Verrouiller Vous ne disposez pas de privilèges suffisants sur le groupe

d'administration.1
Vide Aucune stratégie n’est attribuée.
1 Si vous n’avez pas accès au groupe d’administration, demandez à un propriétaire de vous fournir l’accès. Ou,
affichez la conformité et gérez les attributions via les abonnements ou les groupes d’administration enfants.
Le tableau suivant mappe chaque état d’attribution possible pour l’initiative.
ÉTAT DE L’ATTRIBUTION DESCRIPTION
Success L’agent Log Analytics et l’agent de dépendances sont déployés

sur toutes les machines virtuelles dans l’étendue.
Avertissement L’abonnement n’est pas sous un groupe d’administration.
Non démarré Une nouvelle attribution a été ajoutée.
Verrouiller Vous ne disposez pas de privilèges suffisants sur le groupe

d'administration.1
Vide Aucune machine virtuelle n’existe ou une stratégie n’est pas

attribuée.
Action Attribuez une stratégie ou modifiez une attribution.
1 Si vous n’avez pas accès au groupe d’administration, demandez à un propriétaire de vous fournir l’accès. Ou,
affichez la conformité et gérez les attributions via les abonnements ou les groupes d’administration enfants.
Examiner et corriger les résultats de conformité

L’exemple suivant est pour une machine virtuelle Azure, mais il s’applique également aux groupes de machines
virtuelles identiques. Pour savoir comment examiner les résultats de conformité, consultez Identifier les résultats
non conformes. Sur la page Azure Monitor for VMs Policy Coverage (Couverture de stratégie Azure
Monitor pour machines virtuelles) , sélectionnez un groupe d’administration ou un abonnement à partir du
tableau. Sélectionnez Afficher la conformité en sélectionnant les points de suspension (...).
Sur la base des résultats des stratégies incluses avec l’initiative, les machines virtuelles sont présentées comme
étant non conformes dans les scénarios suivants :
L’agent Log Analytics ou l’agent de dépendances n’est pas déployé.
Il s’agit d’un cas courant pour une étendue comportant des machines virtuelles existantes. Pour limiter ce
risque, déployez les agents requis en créant des tâches de correction sur une stratégie non conforme.
[Préversion] : Déployer l’agent de dépendances pour les machines virtuelles Linux
[Préversion] : Déployer l’agent de dépendances pour les machines virtuelles Windows
[Préversion] : Déployer l’agent Log Analytics pour les machines virtuelles Linux
[Préversion] : Déployer l’agent Log Analytics pour les machines virtuelles Windows
L’image de machine virtuelle (système d’exploitation) n’est pas identifiée dans la définition de stratégie.
Les critères de la stratégie de déploiement incluent uniquement les machines virtuelles qui sont déployées à
partir d’images de machine virtuelle Azure connues. Consultez la documentation pour savoir si le système
d’exploitation de la machine virtuelle est pris en charge. Si ce n’est pas le cas, dupliquez la stratégie de
déploiement et mettez-la à jour ou modifiez-la pour rendre l’image conforme.
[Préversion] : Vérifier le déploiement de l’agent de dépendances - Image de machine virtuelle (système
d’exploitation) non listée
[Préversion] : Auditer le déploiement de l’agent Log Analytics - Image de machine virtuelle (système
d’exploitation) non listée
Les machines virtuelles ne sont pas connectées à l’espace de travail Log Analytics spécifié.
Il est possible que certaines machines virtuelles de l’étendue de l’initiative soient connectées à un espace de
travail Log Analytics différent de celui spécifié dans l’affectation de stratégie. Cette stratégie est un outil qui
permet d’identifier les machines virtuelles qui relèvent d’un espace de travail non conforme.
[Préversion] : Auditer les machines virtuelles de l’espace de travail Log Analytics - Signaler les
incompatibilités
Modifier une attribution d’initiative
À tout moment après avoir attribué une initiative à un groupe d’administration ou un abonnement, vous pouvez en
modifier les propriétés suivantes :
Nom de l’attribution
Description
Attribué par
Espace de travail Log Analytics
Exceptions
Étapes suivantes
Une fois la supervision activée pour vos machines virtuelles, ces informations peuvent être analysées par Azure
Monitor pour machines virtuelles.
Pour afficher les dépendances des applications détectées, consultez Utilisation de la fonctionnalité Map
d’Azure Monitor pour machines virtuelles dans le but de comprendre les composants d’application.
Pour identifier les goulots d’étranglement et l’utilisation globale avec les performances de votre machine
virtuelle, consultez Consulter les performances des machines virtuelles Azure.

Azure Policy

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Azure Policy

Transféré par

Droits d'auteur :

Formats disponibles

Contents

Documentation Azure Policy

Quelle est la différence avec RBAC ?

STRATÉGIE NOM DE PARAMÈTRE TYPE DE PARAMÈTRE REMARQUE

policyA allowedLocations tableau Ce paramètre attend une

policyB allowedSingleLocation string Ce paramètre attend un mot

Nombre maximal d’objets Azure Policy

WHERE QUOI NOMBRE MAXIMAL

Étendue Définitions de stratégies 500

Étendue Définitions d’initiative 100

Locataire Définitions d’initiative 1 000

Étendue Affectations de stratégies et d'initiatives 100

Définition de stratégie parameters 20

Définition d’initiative Stratégies 100

Définition d’initiative parameters 100

Affectations de stratégies et d'initiatives Exclusion (notScopes) 400

Règle de stratégie Éléments conditionnels imbriqués 512

Recommandations pour la gestion des stratégies

Créer une affectation de stratégie

3. Sélectionnez Assigner une stratégie en haut de la pageStratégie - Affectations.

Identifier les ressources non conformes

Exists Deny, Audit, Append*, True Non conforme

Exists Deny, Audit, Append*, False Conforme

Nouveau Audit, AuditIfNotExist* True Non conforme

Nouveau Audit, AuditIfNotExist* False Conforme

Supprimer des ressources

Conditions préalables requises

# Register the resource provider if it's not already registered

Utiliser Azure Cloud Shell

Sélectionnez Essayer dans le coin supérieur droit d’un bloc de

Accédez à https://shell.azure.com ou sélectionnez le bouton

Sélectionnez le bouton Cloud Shell dans la barre de menus

Créer une affectation de stratégie

# Get a reference to the built-in policy definition that will be assigned

Les commandes précédentes utilisent les informations suivantes :

Identifier les ressources non conformes

Pour plus d’informations sur l’obtention de l’état de la stratégie, voir Get-AzPolicyState.

Nettoyer les ressources

# Removes the policy assignment

Conditions préalables requises

az provider register --namespace 'Microsoft.PolicyInsights'

Utiliser Azure Cloud Shell

Sélectionnez Essayer dans le coin supérieur droit d’un bloc de

Accédez à https://shell.azure.com ou sélectionnez le bouton

Sélectionnez le bouton Cloud Shell dans la barre de menus

Pour exécuter le code de cet article dans Azure Cloud Shell :

Créer une affectation de stratégie

La commande précédente utilise les informations suivantes :

Identifier les ressources non conformes

Vos résultats doivent ressembler à l’exemple suivant :

Nettoyer les ressources

az policy assignment delete --name 'audit-vm-manageddisks' --scope

Conditions préalables requises

Créer une affectation de stratégie

2. Sélectionnez ou entrez les valeurs suivantes :

Subscription Sélectionnez votre abonnement Azure.

Resource group Sélectionnez Créer, spécifiez un nom, puis sélectionnez

Location Sélectionnez une région. Par exemple, USA Centre.

Nom de l’affectation de stratégie Spécifiez un nom d’affectation de stratégie. Vous pouvez

Nom du groupe de ressources Spécifiez le nom du groupe de ressources auquel vous

ID de définition de stratégie Spécifiez

J’accepte les termes et conditions mentionnés ci-dessus (Sélectionner)

Identifier les ressources non conformes

Nettoyer les ressources