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.
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 :
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.
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.
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.
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É
* 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.
É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
minutes to read • Edit Online
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.
Pour plus d’informations sur l’inscription et l’affichage des fournisseurs de ressources, consultez
Fournisseurs et types de ressources.
OPTION EXEMPLE/LIEN
# Get a reference to the resource group that will be the scope of the assignment
$rg = Get-AzResourceGroup -Name '<resourceGroupName>'
# 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
# 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'
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.
É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.
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
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.
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.
Pour plus d’informations sur l’inscription et l’affichage des fournisseurs de ressources, consultez
Fournisseurs et types de ressources.
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.
OPTION EXEMPLE/LIEN
az policy assignment create --name 'audit-vm-manageddisks' --display-name 'Audit VMs without managed disks
Assignment' --scope '<scope>' --policy '<policy definition ID>'
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":
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/
$metadata#latest/$entity",
"ResourceId":
"/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtual
machineId>"
},
{
"@odata.id": null,
"@odata.context":
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/
$metadata#latest/$entity",
"ResourceId":
"/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtual
machine2Id>"
},
{
"@odata.id": null,
"@odata.context":
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/
$metadata#latest/$entity",
"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.
É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.
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
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.
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 :
NAME VALEUR
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.
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é.
É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.
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
minutes to read • Edit Online
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.
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.
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.
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.
PUT
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.authorization/policydefinition
s/{policyDefinitionName}?api-version={api-version}
$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'
$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",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field": "location",
"in": "[parameters(''allowedLocations'')]"
}
}
]
},
"then": {
"effect": "Deny"
}
}'
$parameters = '{
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying storage accounts.",
"strongType": "location",
"displayName": "Allowed locations"
}
}
}'
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
az policy definition create --name 'denyCoolTiering' --description 'Deny cool access tiering for storage' --
rules '{
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "kind",
"equals": "BlobStorage"
},
{
"field": "Microsoft.Storage/storageAccounts/accessTier",
"equals": "cool"
}
]
},
"then": {
"effect": "deny"
}
}'
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 :
{
"description": "This policy enables you to restrict the locations your organization can specify when
deploying resources. Use to enforce your geo-compliance requirements.",
"displayName": "Allowed locations",
"id": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
"name": "e56962a6-4747-49cd-b67b-bf8b01975c4c",
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('listOfAllowedLocations')]"
}
},
"then": {
"effect": "Deny"
}
},
"policyType": "BuiltIn"
}
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 :
[
{
"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"
}
]
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.
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é.
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à.
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 :
Structure de définition Azure Policy
minutes to read • Edit Online
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
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.
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.
Comme avec Azure CLI, les résultats montrent un alias pris en charge par les comptes de stockage, nommé
supportsHttpsTrafficOnly.
Azure Resource Graph
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
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
| where type=~'microsoft.storage/storageaccounts'
| limit 1
| project aliases
"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,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
}
}
},
"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,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
},
"file": {
"enabled": true,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
}
},
"Microsoft.Storage/storageAccounts/encryption.services.blob": {
"enabled": true,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
},
"Microsoft.Storage/storageAccounts/encryption.services.blob.enabled": true,
"Microsoft.Storage/storageAccounts/encryption.services.file": {
"enabled": true,
"lastEnabledTime": "2018-06-04T17:59:14.4970000Z"
},
"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.
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.
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",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"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",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
"notEquals": "true"
}
]
},
"then": {
"effect": "[parameters('effectType')]"
}
}
}
}
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.
Révision
Dans ce didacticiel, vous avez effectué avec succès les tâches suivantes :
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
É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
minutes to read • Edit Online
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 :
Identifier vos exigences métier
Associer chaque spécification à une définition de stratégie
Regrouper les stratégies de balises dans une initiative
"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": {
"field": "tags['CostCenter']",
"exists": "false"
},
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"operations": [{
"operation": "add",
"field": "tags['CostCenter']",
"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.
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"field": "name",
"like": "prd-*"
}
]
},
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"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": [{
"field": "tags['Env']",
"notEquals": "[resourcegroup().tags['Env']]"
},
{
"field": "tags['Env']",
"exists": false
}
]
},
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"operations": [{
"operation": "addOrReplace",
"field": "tags['Env']",
"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.
Révision
Dans ce tutoriel, vous avez découvert les tâches suivantes :
Identifier vos exigences métier
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 :
Structure de définition Azure Policy
minutes to read • Edit Online
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 :
Opérateurs logiques
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
18/03/2020 • 226 minutes to read • Edit Online
Configuration d’application
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Plateforme d’application
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Automatisation
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Batch
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Cache
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Calcul
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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.
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Container Registry
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Cosmos DB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Fournisseur personnalisé
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Data Lake
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Event Hub
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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
Général
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Guest Configuration
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Key Vault
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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.
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Service Kubernetes
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Lighthouse
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Logic Apps
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Application managée
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Surveillance
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Réseau
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Event Hub doit utiliser Cette stratégie audite AuditIfNotExists, 1.0.0 Lien
un point de Event Hub 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.
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
virtuel terminaison de
service de réseau
virtuel.
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.
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.
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Recherche
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Security Center
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Service Bus
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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
Service Fabric
NOM DESCRIPTION EFFET(S) VERSION GITHUB
SQL
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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.
Stockage
NOM DESCRIPTION EFFET(S) VERSION GITHUB
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
Stream Analytics
NOM DESCRIPTION EFFET(S) VERSION GITHUB
Balises
NOM DESCRIPTION EFFET(S) VERSION GITHUB
NOM DESCRIPTION EFFET(S) VERSION GITHUB
É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 d’initiative Azure Policy intégrées
18/03/2020 • 21 minutes to read • Edit Online
Guest Configuration
NOM DESCRIPTION STRATÉGIES VERSION
Conformité réglementaire
NOM DESCRIPTION STRATÉGIES VERSION
Security Center
NOM DESCRIPTION STRATÉGIES VERSION
É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.
minutes to read • Edit Online
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.
{
"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é.
{
"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"
}
}
}
}
Exemple 2 : Explication
"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.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
L’opérateur field évalue l’alias ou la propriété spécifié(e) par rapport à une valeur fournie pour une condition
donnée.
{
"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. 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.",
"strongType": "location",
"displayName": "Allowed locations"
}
}
},
"policyRule": {
"if": {
"allOf": [{
"field": "location",
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"field": "location",
"notEquals": "global"
},
{
"field": "type",
"notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
}
]
},
"then": {
"effect": "Deny"
}
}
}
}
Explication
"if": {
"allOf": [{
"field": "location",
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"field": "location",
"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
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
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.
{
"properties": {
"displayName": "Require tag and its value",
"policyType": "BuiltIn",
"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"
}
}
}
}
Exemple 1 : Explication
"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": {
"field": "[concat('tags[', parameters('tagName'), ']')]",
"equals": "[parameters('tagValue')]"
}
},
{
"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"
}
}
}
}
Exemple 2 : Explication
"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
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
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 : Explication
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"field": "[concat('tags[', parameters('tagName'), ']')]",
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 : Explication
"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')]"
}
]
}
}
Étapes suivantes
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
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.
Explication
"if": {
"allOf": [{
"field": "[concat('tags[', parameters('tagName'), ']')]",
"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
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
{
"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": {
"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
}
Étapes suivantes
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
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.
{
"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": {
"value": "costCenter"
},
"tagValue": {
"value": "[parameters('costCenterValue')]"
}
}
},
{
"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": {
"value": "productName"
},
"tagValue": {
"value": "[parameters('productNameValue')]"
}
}
}
]
}
}
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": {
"costCenterValue": {
"type": "String",
"metadata": {
"displayName": "required value for Cost Center tag"
}
},
"productNameValue": {
"type": "String",
"metadata": {
"displayName": "required value for product Name tag"
}
}
},
Étapes suivantes
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
minutes to read • Edit Online
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.
Explication
existenceCondition
"type": "Microsoft.Network/networkWatchers",
"resourceGroupName": "networkWatcherRG",
"existenceCondition": {
"field": "location",
"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
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
],
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
"contentVersion": "1.0.0.0",
"parameters": {
"location": {
"type": "string"
}
},
"resources": [{
"apiVersion": "2016-09-01",
"type": "Microsoft.Network/networkWatchers",
"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
Passez en revue les autres modèles et définitions intégrées.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Structure de définition Azure Policy
04/03/2020 • 38 minutes to read • Edit Online
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": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of locations that can be specified when deploying
resources",
"strongType": "location",
"displayName": "Allowed locations"
},
"defaultValue": [ "westus2" ]
}
},
"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"
}
}
}
}
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.
"parameters": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of allowed locations for resources.",
"displayName": "Allowed locations",
"strongType": "location"
},
"defaultValue": [ "westus2" ],
"allowedValues": [
"eastus2",
"westus2",
"westus"
]
}
}
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.
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"
}
}
Opérateurs logiques
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",
"equals": "Microsoft.Storage/storageAccounts"
}
]
},
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.
{
"if": {
"field": "[concat('tags[', parameters('tagName'), ']')]",
"exists": "false"
},
"then": {
"effect": "modify",
"details": {
"operations": [{
"operation": "add",
"field": "[concat('tags[', parameters('tagName'), ']')]",
"value": "[resourcegroup().tags[parameters('tagName')]]"
}],
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
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"
}
}
}
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
}
{
"count": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*]",
"where": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].description",
"equals": "My unique description"
}
},
"equals": 1
}
{
"count": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*]",
"where": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].description",
"equals": "My common description"
}
},
"greaterOrEquals": 1
}
Exemple 4 : Vérifier que tous les membres du tableau d’objets satisfont l’expression de condition
{
"count": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*]",
"where": {
"field": "Microsoft.Network/networkSecurityGroups/securityRules[*].description",
"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": {
"field": "Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]",
"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": {
"field": "Microsoft.Sql/servers/securityAlertPolicies/emailAddresses[*]",
"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": {
"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
}
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.
Resources
| where type=~'microsoft.storage/storageaccounts'
| limit 1
| project aliases
Azure PowerShell
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
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": {
"effect": "[parameters('effectType')]"
}
}
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": {
"costCenterValue": {
"type": "String",
"metadata": {
"description": "required value for Cost Center tag"
}
},
"productNameValue": {
"type": "String",
"metadata": {
"description": "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": {
"value": "costCenter"
},
"tagValue": {
"value": "[parameters('costCenterValue')]"
}
}
},
{
"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": {
"value": "productName"
},
"tagValue": {
"value": "[parameters('productNameValue')]"
}
}
}
]
}
}
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la page Compréhension des effets de 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.
minutes to read • Edit Online
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": [{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
"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": [
{
"operation": "addOrReplace",
"field": "tags['environment']",
"value": "Test"
},
{
"operation": "Remove",
"field": "tags['TempResource']",
},
{
"operation": "addOrReplace",
"field": "tags['Dept']",
"value": "[parameters('DeptName')]"
}
]
}
OPÉRATION DESCRIPTION
Exemples Modify
Exemple 1 : Ajoutez l’étiquette environment et remplacez les étiquettes environment existantes par
« Test » :
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
20f7382dd24c"
],
"operations": [
{
"operation": "addOrReplace",
"field": "tags['environment']",
"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": {
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-
20f7382dd24c"
],
"operations": [
{
"operation": "Remove",
"field": "tags['env']"
},
{
"operation": "addOrReplace",
"field": "tags['environment']",
"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.
Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
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",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "auditIfNotExists",
"details": {
"type": "Microsoft.Compute/virtualMachines/extensions",
"existenceCondition": {
"allOf": [{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "Microsoft.Azure.Security"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/type",
"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.
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.
L’exécution d’un déploiement de modèle s’effectue dans le groupe de ressources de cette
valeur.
ExistenceScope (facultatif)
Les valeurs autorisées sont Subscription et ResourceGroup.
Définit la portée d’où la ressource connexe évaluée est extraite.
Ne s’applique pas si type est une ressource qui serait située sous la ressource de condition if.
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 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)
Les valeurs autorisées sont Subscription et ResourceGroup.
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.
La valeur par défaut est ResourceGroup.
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": {
"effect": "DeployIfNotExists",
"details": {
"type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
"name": "current",
"roleDefinitionIds": [
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
"/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
],
"existenceCondition": {
"field": "Microsoft.Sql/transparentDataEncryption.status",
"equals": "Enabled"
},
"deployment": {
"properties": {
"mode": "incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"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"
]
},
{
"field": "location",
"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"
},
{
"field": "location",
"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
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition 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.
minutes to read • Edit Online
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",
"policyDefinitionId":
"/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyDefinitions/ResourceNaming",
"parameters": {
"prefix": {
"value": "DeptA"
},
"suffix": {
"value": "-LC"
}
}
}
}
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
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
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.
minutes to read • Edit Online
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
Étapes suivantes
En savoir plus sur la structure des définitions de stratégies
En savoir plus sur la structure des attributions de stratégies
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.
minutes to read • Edit Online
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.
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
| |- params.dev.json _____________ # Parameters for a Dev environment
| |- params.prd.json _____________ # Parameters for a Prod environment
| |- params.tst.json _____________ # Parameters for a Test environment
|
| |- init2/ _________________________ # Subfolder for an initiative
| |- policyset.json ______________ # Initiative definition
| |- policyset.definitions.json __ # Initiative list of policies
| |- policyset.parameters.json ___ # Initiative definition of parameters
| |- params.dev.json _____________ # Parameters for a Dev environment
| |- params.prd.json _____________ # Parameters for a Prod environment
| |- params.tst.json _____________ # Parameters for a Test environment
|
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.
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 définitions de stratégies
En savoir plus sur la structure des attributions de stratégies
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.
minutes to read • Edit Online
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.
# 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
# Once the above shows 'Registered' run the following to propagate the update
az provider register -n Microsoft.PolicyInsights
3. Installez la version 0.4.0 de l’extension de préversion Azure CLI pour AKS, aks-preview :
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
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?.
Stratégies prédéfinies
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 :
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.
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la page Structure de définition Azure Policy.
Consultez la page Compréhension des effets de 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.
minutes to read • Edit Online
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
Azure PowerShell
# Log in first with Connect-AzAccount if you're not using Cloud Shell
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)"
"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.
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.
3. Synchronisez les données Kubernetes (espace de noms, pod, entrée, service) avec OPA.
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 :
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?.
Stratégies prédéfinies
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 :
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
"addons": [{
"name": "azure-policy",
"enabled": false
}]
3. Désinstaller Gatekeeper
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la page Structure de définition Azure Policy.
Consultez la page Compréhension des effets de 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.
minutes to read • Edit Online
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.
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 :
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.
Credativ Debian 8, 9
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.
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.
Linux : /var/lib/waagent/Microsoft.GuestConfiguration.ConfigurationforLinux-<version>/GCAgent/logs/dsc.log
$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
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de 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.
minutes to read • Edit Online
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.
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.
Se déconnecter
À partir de la barre de menus, accédez à Afficher > Palette de commandes, puis entrez Azure: Se
déconnecter.
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Découvrez comment créer des stratégies par programmation.
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.
minutes to read • Edit Online
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é.
Pour plus d’informations sur l’inscription et l’affichage des fournisseurs de ressources, consultez
Fournisseurs et types 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.
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.
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 :
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": "Microsoft.Storage/storageAccounts"
},
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
"equals": "Allow"
}
]
},
"then": {
"effect": "audit"
}
}
}
{
"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": {},
"policyDefinitionId":
"/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/policyDefinitions/Audit Storage
Accounts Open to Public Networks",
"scope": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>"
}
}
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": "Microsoft.Storage/storageAccounts"
},
{
"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. Pour créer une définition de stratégie, exécutez la commande suivante :
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.
minutes to read • Edit Online
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": {
"allowedLocations": {
"type": "string",
"metadata": {
"description": "The list of allowed locations for resources.",
"displayName": "Allowed locations",
"strongType": "location"
},
"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": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of allowed locations for resources.",
"displayName": "Allowed locations",
"strongType": "location"
},
"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.
{
"allowedLocations": {
"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
{
"policyRule": {
"if": {
"not": {
"field": "location",
"equals": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "audit"
}
},
"parameters": {
"allowedLocations": {
"type": "Array",
"metadata": {
"description": "The list of allowed locations for resources.",
"displayName": "Allowed locations",
"strongType": "location"
}
}
}
}
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 .
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"
}
]
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),
donc la condition notEquals
est true et l’effet est
déclenché.
CONDITION RÉSULTAT SCÉNARIO EXPLICATION
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),
donc la condition Equals est
false et l’effet n’est pas
déclenché.
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Découvrez comment créer des stratégies par programmation.
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.
minutes to read • Edit Online
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.
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.
# Install the Guest Configuration DSC resource module from PowerShell Gallery
Install-Module -Name GuestConfiguration
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
}
La cmdlet New-GuestConfigurationPackage crée le package. Le format suivant est utilisé pour créer un package
personnalisé :
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.
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
$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-
01T00%3A00%3A00Z&se=2024-07-01T00%3A00%3A00Z&sp=rl&sv=2018-03-
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 {
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')]"
}]
}
}
}
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.
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.
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É
* 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":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
States/$metadata#summary/$entity",
"results": {
"queryResultsUri":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
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":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
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 and PolicyAssignmentId eq
'/subscriptions/{subscriptionId}/resourcegroups/rg-
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77'",
"nonCompliantResources": 15,
"nonCompliantPolicies": 1
},
"policyDefinitions": [{
"policyDefinitionReferenceId": "",
"policyDefinitionId": "/providers/microsoft.authorization/policydefinitions/1e30110a-
5ceb-460c-a204-c1c3969c6d62",
"effect": "deny",
"results": {
"queryResultsUri":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
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 and PolicyAssignmentId eq
'/subscriptions/{subscriptionId}/resourcegroups/rg-
tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77' and
PolicyDefinitionId eq '/providers/microsoft.authorization/policydefinitions/1e30110a-5ceb-460c-a204-
c1c3969c6d62'",
"nonCompliantResources": 15
}
}]
}]
}]
}
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
04:28:22Z&$filter=IsCompliant eq false and PolicyAssignmentId eq
'/subscriptions/{subscriptionId}/resourcegroups/rg-
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":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
States/$metadata#latest",
"@odata.count": 15,
"value": [{
"@odata.id": null,
"@odata.context":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
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": ""
}]
}
{
"@odata.context":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
Events/$metadata#default",
"@odata.count": 1,
"value": [{
"@odata.id": null,
"@odata.context":
"https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policy
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) :
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).
Exemple : Obtenir des détails pour toutes les ressources non conformes du réseau virtuel.
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'
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.
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.
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": {
"effect": "DeployIfNotExists",
"details": {
"type": "Microsoft.Insights/metricAlerts",
"existenceCondition": {
"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 ê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 être identique à la valeur cible. like ou not notLike
MOTIF CONDITION
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 ê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.
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 :
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
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.
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é.
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...
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
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de 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.
minutes to read • Edit Online
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.
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.
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
"/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
]
}
NOTE
Azure PowerShell et .NET sont les seuls SDK qui prennent en charge cette fonctionnalité.
# 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'
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 .
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
}
}
/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.
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.
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.
Étapes suivantes
Consultez des exemples à la page Exemples Azure Policy.
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Découvrez comment créer des stratégies par programmation.
Découvrez comment obtenir des données de conformité.
Pour en savoir plus sur les groupes d’administration, consultez Organiser vos ressources avec des
groupes d’administration Azure.
Intégrer Azure Key Vault à Azure Policy
05/03/2020 • 17 minutes to read • Edit Online
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.
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.
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.
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.
É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
02/03/2020 • 3 minutes to read • Edit Online
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.
$subs = Get-AzSubscription
if ([string]::IsNullOrEmpty($Assignment))
{
Write-Output "Nothing to clean up - we're done"
}
else
{
Étapes suivantes
En savoir plus sur Azure Policy.
Découvrez les Expériences de gestion inter-locataire.
minutes to read • Edit Online
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"
]
}
"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
05/03/2020 • 27 minutes to read • Edit Online
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.
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
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.
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.
[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] : 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
d’exploitation) est définie dans la liste et
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 Windows si l’image
Windows de machine virtuelle (système
d’exploitation) est définie dans la liste et
si l’agent n’est pas installé.
[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] : Déployer l’agent Log Déployez l’agent Log Analytics pour les Stratégie
Analytics pour les groupes de machines groupes de machines virtuelles
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é.
[Préversion] : Déployer l’agent Log Déployez l’agent Log Analytics pour les Stratégie
Analytics pour les groupes de machines groupes de machines virtuelles
virtuelles identiques Windows identiques Windows si l’image de
machine virtuelle (système
d’exploitation) est définie dans la liste et
si l’agent n’est pas installé.
[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.
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.
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.
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.
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.