Résoudre des problèmes d’implémentation de la stratégie Azure sur Key Vault
Cet article vous explique comment résoudre les erreurs générales qui peuvent se produire lorsque vous configurez Azure Policy pour Key Vault et donne des suggestions de résolution.
À propos d’Azure Policy pour Key Vault
Azure Policy est un outil de gouvernance qui permet aux utilisateurs d’auditer et de gérer leur environnement Azure à grande échelle. Azure Policy permet 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.
Journalisation
Pour effectuer un monitoring des évaluations de stratégie, vous pouvez consulter les journaux Key Vault. Activation de la journalisation d’Azure Key Vault, qui enregistre les informations dans un compte de stockage Azure que vous fournissez. Pour obtenir des instructions pas à pas, consultez Guide pratique pour activer la journalisation de Key Vault.
Lorsque la journalisation est activée, un nouveau conteneur appelé AzurePolicyEvaluationDetails est automatiquement créé pour collecter les informations de journalisation relatives à la stratégie dans le compte de stockage spécifié.
Notes
Vous devez réglementer strictement l’accès aux données de monitoring, et en particulier les fichiers journaux, car ils peuvent contenir des informations sensibles. Découvrez comment appliquer le rôle Azure de monitoring intégré et limiter l’accès.
Les objets blob individuels sont stockés sous forme de texte en tant qu’objet blob JSON.
Examinons un exemple d’entrée du journal pour une stratégie de clé : une date d’expiration doit être définie pour les clés. Cette stratégie évalue toutes les clés de vos coffres de clés et signale comme non conformes celles qui n’ont pas de date d’expiration.
{
"ObjectName": "example",
"ObjectType": "Key",
"IsComplianceCheck": false,
"EvaluationDetails": [
{
"AssignmentId": "<subscription ID>",
"AssignmentDisplayName": "[Preview]: Key Vault keys should have an expiration date",
"DefinitionId": "<definition ID>",
"DefinitionDisplayName": "[Preview]: Key Vault keys should have an expiration date",
"Outcome": "NonCompliant",
"ExpressionEvaluationDetails": [
{
"Result": "True",
"Expression": "type",
"ExpressionKind": "Field",
"ExpressionValue": "Microsoft.KeyVault.Data/vaults/keys",
"TargetValue": "Microsoft.KeyVault.Data/vaults/keys",
"Operator": "Equals"
},
{
"Result": "True",
"Expression": "Microsoft.KeyVault.Data/vaults/keys/attributes.expiresOn",
"ExpressionKind": "Field",
"ExpressionValue": "******",
"TargetValue": "False",
"Operator": "Exists"
}
]
}
]
}
Le tableau ci-après répertorie les noms de champ et leurs descriptions :
| Nom du champ | Description |
|---|---|
| ObjectName | Nom de l’objet |
| ObjectType | Type d’objet de coffre de clés : certificat, secret ou clé |
| IsComplianceCheck | True si l’évaluation s’est produite pendant l’audit nocturne, false si elle s’est produite pendant la création ou la mise à jour de la ressource |
| AssignmentId | ID de l’attribution de stratégie |
| AssignmentDisplayName | Nom convivial de l’attribution de stratégie |
| DefinitionId | ID de la définition de stratégie pour l’affectation |
| DefinitionDisplayName | Nom convivial de la définition de stratégie pour l’affectation |
| Résultat | Résultat de l’évaluation de la stratégie |
| ExpressionEvaluationDetails | Détails sur les évaluations effectuées pendant l’évaluation de la stratégie |
| ExpressionValue | Valeur réelle du champ spécifié pendant l’évaluation de la stratégie |
| TargetValue | Valeur attendue du champ spécifié |
Forum aux questions
Récupération de Key Vault bloquée par Azure Policy
L’une des raisons peut être que votre abonnement (ou votre groupe d’administration) comporte une stratégie qui bloque la récupération. Le correctif consiste à ajuster la stratégie afin qu’elle ne s’applique pas quand un coffre est en cours de récupération.
Si le type d’erreur RequestDisallowedByPolicy s’affiche pour la récupération en raison de la stratégie intégrée, assurez-vous que vous utilisez la dernière version.
Si vous avez créé une stratégie personnalisée avec votre propre logique, voici un exemple de partie de stratégie qui peut être utilisée pour exiger une suppression réversible. La récupération d’un coffre supprimé de manière réversible exploite la même API que la création et la mise à jour d’un coffre. Toutefois, au lieu de spécifier les propriétés du coffre, elle comporte une seule propriété « createMode » avec la valeur « recover ». Le coffre est restauré avec toutes les propriétés qu’il avait lors de sa suppression. Les stratégies qui bloquent les demandes à moins que des propriétés spécifiques ne soient configurées bloquent également la récupération des coffres supprimés de manière réversible. Le correctif consiste à inclure une clause prévoyant que la stratégie ignore les demandes pour lesquelles « createMode » possède la valeur « Recover » :
Comme vous pouvez le constater, elle comporte une clause qui limite l’application de la stratégie aux cas où « createMode » n’est pas égal à « Recover » :
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.KeyVault/vaults"
},
{
"not": {
"field": "Microsoft.Keyvault/vaults/createMode",
"equals": "recover"
}
},
{
"anyOf": [
{
"field": "Microsoft.KeyVault/vaults/enableSoftDelete",
"exists": "false"
},
{
"field": "Microsoft.KeyVault/vaults/enableSoftDelete",
"equals": "false"
}
]
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
}
Latence de suppression d’une attribution de stratégie Azure sur Key Vault
Microsoft.KeyVault.Data : Une attribution de stratégie supprimée peut mettre jusqu’à 24 heures à cesser de s’appliquer.
Atténuation : Mettez à jour l’effet de l’attribution de stratégie sur « Désactivé ».
Absence d’évaluation de stratégie dans la création de secrets par le biais du modèle ARM
Les stratégies de plan de données qui évaluent la création de secrets ne s’appliquent pas aux secrets créés par le biais d’un modèle ARM au moment de la création du secret. Au bout de 24 heures, lorsque la vérification de conformité automatisée se produit, les résultats de conformité peuvent être revus.