Intégrer Azure Key Vault à Azure Policy

Article
08/08/2024

Azure Policy est un outil de gouvernance qui donne aux utilisateurs la possibilité d'auditer et de gérer leur environnement Azure à grande échelle, en leur permettant de placer des garde-fous sur les ressources Azure pour s'assurer qu'elles sont conformes aux règles de stratégie assigné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 effectués par la stratégie sont disponibles pour les utilisateurs dans un tableau de bord de conformité où ils peuvent voir pour explorer les ressources et les composants qui sont conformes et ceux qui ne le sont pas. Pour plus d’informations, consultez 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 restaurer l'application des nouvelles stratégies en cas de problème sur site. Vous recherchez une solution en un clic pour désactiver l’application de la stratégie.
Vous vous fiez à une solution tierce pour l'audit de votre environnement et vous souhaitez utiliser une offre interne de Microsoft.

Types d’effets des stratégies et conseils

Lors de l’application d’une stratégie, vous pouvez déterminer son effet sur l’évaluation obtenue. Pour chaque définition de stratégie, vous pouvez choisir l’un des multiples effets. Par conséquent, l’application de la stratégie peut entraîner des comportements différents selon le type d’opération que vous évaluez. Voici généralement les effets des stratégies qui s’intègrent à Key Vault :

Audit : quand l’effet d’une stratégie est défini sur Audit, celle-ci n’entraîne aucun changement cassant sur votre environnement. Elle vous signalera uniquement les composants, tels que les certificats, qui ne sont pas conformes aux définitions de la stratégie dans un périmètre spécifié, en marquant ces composants comme non conformes dans le tableau de bord de la conformité de la stratégie. L’audit est le paramètre par défaut si aucun effet de stratégie n’est sélectionné.
Refuser : lorsque l'effet d'une stratégie est défini sur Deny, la stratégie bloque la création de nouveaux composants (tels que les certificats) et bloque les nouvelles versions des composants existants qui ne sont pas conformes à la définition de la stratégie. Les ressources non conformes existantes dans un Key Vault ne sont pas affectées. Les fonctions d'audit continuent de fonctionner.
Désactivé : quand l’effet d’une stratégie est défini sur Disabled, la stratégie est toujours évaluée, mais elle n’est pas appliquée, ce qui est conforme à la condition avec effet Disabled. Cela est utile pour désactiver la stratégie pour une condition spécifique mais pas pour toutes les conditions.
Modifier : quand l’effet d’une stratégie est défini sur Modify, vous pouvez ajouter des étiquettes de ressource, par exemple ajouter l’étiquette Deny à un réseau. Cela est utile pour désactiver l’accès à un réseau public pour HSM managé Azure Key Vault. Il est nécessaire de configurer une identité de gestion pour la définition de stratégie via le paramètre roleDefinitionIds pour utiliser l’effet Modify.
DeployIfNotExists : quand l’effet d’une stratégie est défini sur DeployIfNotExists, un modèle de déploiement est exécuté lorsque la condition est remplie. Cela permet de configurer les paramètres de diagnostic de Key Vault dans l’espace de travail d’analytique des journaux d’activité. Il est nécessaire de configurer une identité de gestion pour la définition de stratégie via le paramètre roleDefinitionIds pour utiliser l’effet DeployIfNotExists.
AuditIfNotExists : quand l’effet d’une stratégie est défini sur AuditIfNotExists, vous pouvez identifier les ressources qui n’ont pas les propriétés spécifiées dans les détails de la condition de stratégie. Cela est utile pour identifier les coffres de clés sur lesquels les journaux de ressources ne sont pas activés. Il est nécessaire de configurer une identité de gestion pour la définition de stratégie via le paramètre roleDefinitionIds pour utiliser l’effet DeployIfNotExists.

Définitions de stratégie intégrée disponibles

Les stratégies prédéterminées, appelées « intégrées », facilitent la gouvernance de vos coffres de clés. Il n’est ainsi pas nécessaire d’écrire de stratégies personnalisées au format JSON pour appliquer les règles couramment utilisées qui sont associées aux meilleures pratiques de sécurité. Bien que les stratégies intégrées soient prédéterminées, vous devez parfois définir des paramètres. En définissant l’effet de la stratégie par exemple, vous pouvez auditer le coffre de clés et ses objets avant d’appliquer une opération de refus pour éviter les pannes. Les éléments intégrés actuels pour Azure Key Vault sont classés en quatre groupes principaux : coffre de clés, certificats, clés et gestion des secrets. Dans chaque catégorie, les stratégies sont regroupées pour atteindre des objectifs de sécurité spécifiques.

Key Vaults

Contrôle d’accès

Grâce au service Azure Policy, vous pouvez régir la migration du modèle d’autorisation RBAC au sein de vos coffres. Pour en savoir plus, consultez Migrer d’une stratégie d’accès de coffre vers un modèle d’autorisation de type contrôle d’accès en fonction du rôle Azure

Stratégie	Effets
Azure Key Vault doit utiliser le modèle d’autorisation RBAC	Audit (par défaut), Refuser, Désactivé

Accès réseau

Réduisez le risque de fuite de données en limitant l’accès au réseau public, en activant les connexions Azure Private Link, en créant des zones DNS privées pour remplacer la résolution DNS pour un point de terminaison privé et en activant la protection du pare-feu afin que le coffre de clés ne soit pas accessible par défaut à une adresse IP publique.

Stratégie	Effets
Azure Key Vault doit désactiver l’accès réseau public	Audit (par défaut), Refuser, Désactivé
[Préversion] : HSM géré par Azure Key Vault doit désactiver l’accès réseau public	Audit (par défaut), Refuser, Désactivé
[Préversion] : configurer les HSM gérés par Azure Key pour désactiver l’accès réseau public	Modifier (par défaut), Désactivé
[Préversion] : les coffres Azure Key Vault doivent utiliser la liaison privée	Audit (par défaut), Refuser, Désactivé
[Préversion] : les HSM gérés par Azure Key Vault doivent utiliser une liaison privée	Audit (par défaut), désactivé
[Préversion] : configurer les coffres Azure Key Vault avec des points de terminaison privés	DeployIfNotExists (par défaut), Désactivé
[Préversion] : configurer un HSM managé par Azure Key Vault avec des points de terminaison privés	DeployIfNotExists (par défaut), Désactivé
[Préversion] : configurer les coffres Azure Key Vault pour utiliser des zones DNS privées	DeployIfNotExists (par défaut), Désactivé
Le pare-feu doit être activé sur les coffres Key Vault	Audit (par défaut), Refuser, Désactivé
Configurer les coffres de clés Key Vault pour activer le pare-feu	Modifier (par défaut), Désactivé

Protection contre la suppression

Évitez la perte permanente de données de votre coffre de clés et de ses objets en activant la suppression réversible et la protection contre la suppression définitive. La suppression réversible permet de récupérer un coffre de clés supprimé accidentellement pendant une période de rétention configurable, tandis que la protection contre la suppression définitive vous protège contre les attaques internes en appliquant une période de rétention obligatoire aux coffres de clés supprimés de manière réversible. La protection contre le vidage ne peut être activée qu’une fois que la suppression réversible est activée. Personne au sein de votre organisation ou de Microsoft ne peut purger vos coffres-forts de clés pendant la période de conservation de la suppression logicielle.

Policy	Effets
La suppression réversible doit être activée sur les coffres Key Vault	Audit (par défaut), Refuser, Désactivé
La protection contre la suppression définitive doit être activée sur les coffres Key Vault	Audit (par défaut), Refuser, Désactivé
La protection contre la suppression définitive doit être activée pour un HSM managé Azure Key Vault	Audit (par défaut), Refuser, Désactivé

Diagnostics

Exécutez l’activation des journaux de ressource pour recréer les pistes d’activité à des fins d’investigation en cas d’incident de sécurité ou de compromission du réseau.

Stratégie	Effets
Déployer les paramètres de diagnostic pour les Key Vault vers les Event Hubs	DeployIfNotExists (par défaut)
Déployer - Configurer les paramètres de diagnostic des HSM managés par Key Vault vers les concentrateurs d'événements	DeployIfNotExists (par défaut), Désactivé
Déployer – Configurer les paramètres de diagnostic pour les coffres Key Vault dans l’espace de travail Log Analytics	DeployIfNotExists (par défaut), Désactivé
Les journaux de ressources dans les coffres Key Vault doivent être activés	AuditIfNotExists (par défaut), désactivé
Les journaux de ressource doivent être activés dans les HSM managés par Key Vault	AuditIfNotExists (par défaut), désactivé

Certificats

Cycle de vie des certificats

Promouvez l’utilisation de certificats à courte durée de vie pour atténuer les attaques non détectées, en réduisant la durée des dommages et en réduisant la valeur du certificat pour les attaquants. Lors de l’implémentation de certificats de courte durée, il est recommandé de superviser régulièrement la date d’expiration afin d’éviter toute interruption et de permettre une rotation adéquate avant l’expiration. Vous pouvez également gérer l’action de durée de vie spécifiée pour les certificats qui expirent dans un certain nombre de jours ou qui ont atteint un certain pourcentage de leur durée de vie.

Policy	Effets
[Préversion] : la période de validité maximale des certificats doit être spécifiée	Effets : Audit (par défaut), Refuser, Désactivé
[Préversion] : les certificats ne doivent pas expirer pendant le nombre de jours spécifié	Effets : Audit (par défaut), Refuser, Désactivé
Les certificats doivent avoir les déclencheurs d’action de durée de vie spécifiés	Effets : Audit (par défaut), Refuser, Désactivé

Notes

Nous vous recommandons d’appliquer cette stratégie d’expiration du certificat plusieurs fois avec différents seuils d’expiration, par exemple 180, 90, 60 et 30 jours.

Autorité de certification

Auditer ou imposer la sélection d'une autorité de certification spécifique pour émettre vos problèmes en s'appuyant sur l'une des autorités de certification intégrées à Azure Key Vault (Digicert ou GlobalSign) ou sur une autorité de certification non intégrée de votre choix. Vous pouvez également auditer ou refuser la création des certificats auto-signés.

Policy	Effets
Les certificats doivent être émis par l’autorité de certification intégrée spécifiée	Audit (par défaut), Refuser, Désactivé
Les certificats doivent être délivrés par l'autorité de certification non intégrée spécifiée	Audit (par défaut), Refuser, Désactivé

Attributs de certificat

Limitez le type de vos certificats de coffre de clés à sauvegarde RSA, ECC ou HSM. Si vous utilisez des certificats à chiffrement à courbe elliptique ou ECC, vous pouvez personnaliser et sélectionner des noms de courbes comme que P-256, P-256K, P-384 et P-521. Si vous utilisez des certificats RSA, vous pouvez choisir une taille de clé minimale de 2048 bits, 3072 bits ou 4096 bits.

Policy	Effets
Les certificats doivent utiliser des types de clés autorisés	Audit (par défaut), Refuser, Désactivé
Les certificats utilisant le chiffrement à courbe elliptique doivent avoir des noms de courbe autorisés	Audit (par défaut), Refuser, Désactivé
La taille de clé minimale doit être spécifiée pour les certificats utilisant le chiffrement RSA	Audit (par défaut), Refuser, Désactivé

Keys

Clés sauvegardées par HSM

Un HSM est un module de sécurité matériel qui stocke des clés. Un HSM fournit une couche physique de protection des clés de chiffrement. La clé de chiffrement ne peut pas quitter un HSM physique, ce qui offre un niveau de sécurité supérieur à celui d’une clé logicielle. Certaines organisations ont des exigences de conformité qui rendent obligatoire l’utilisation de clés HSM. Utilisez cette stratégie pour auditer les clés stockées dans votre coffre Key Vault qui ne sont pas sauvegardées par HSM. Vous pouvez également utiliser cette stratégie pour bloquer la création de clés non sauvegardées par HSM. Cette stratégie s’applique à tous les types de clés, notamment RSA et ECC.

Policy	Effets
Les clés doivent être adossées à un module de sécurité matériel ou HSM	Audit (par défaut), Refuser, Désactivé

Cycle de vie des clés

Avec les fonctionnalités intégrées de gestion du cycle de vie, vous pouvez marquer ou bloquer les clés qui n’ont pas de date d’expiration, recevoir des alertes chaque fois que des retards de rotation des clés risquent d’entraîner une interruption, empêcher la création de clés proches de la date d’expiration, limiter la durée de vie et l’état actif des clés pour favoriser la rotation des clés, et empêcher les clés d’être actives plus longtemps qu’un nombre de jours maximum spécifié.

Stratégie	Effets
Les clés doivent avoir une stratégie de pivotement qui veille à ce que leur pivotement soit planifié dans le nombre de jours spécifié après leur création	Audit (par défaut), désactivé
Les clés Key Vault doivent avoir une date d’expiration	Audit (par défaut), Refuser, Désactivé
[Préversion] : les clés HSM managées doivent avoir une date d’expiration	Audit (par défaut), Refuser, Désactivé
Les clés doivent avoir une durée de vie supérieure au nombre spécifié de jours avant l’expiration	Audit (par défaut), Refuser, Désactivé
[Préversion] : les clés HSM managées Azure Key Vault doivent avoir plus de jours que le nombre spécifié de jours avant l’expiration	Audit (par défaut), Refuser, Désactivé
La période de validité maximale doit être spécifiée pour les clés	Audit (par défaut), Refuser, Désactivé
Les clés ne doivent pas être actives pendant une durée supérieure au nombre de jours spécifié	Audit (par défaut), Refuser, Désactivé

Important

Si votre clé a une date d’activation définie, la stratégie ci-dessus calcule le nombre de jours écoulés depuis la date d’activation de la clé jusqu’à la date actuelle. Si le nombre de jours dépasse le seuil que vous définissez, la clé est marquée comme non conforme à la stratégie. Si votre clé n’a pas de date d’activation définie, cette stratégie calcule le nombre de jours écoulés depuis la date de création de la clé jusqu’à la date actuelle. Si le nombre de jours dépasse le seuil que vous définissez, la clé est marquée comme non conforme à la stratégie.

Attributs clés

Limitez le type de clés de vos clés Key Vault à sauvegarde RSA, ECC ou HSM. Si vous utilisez des clés à chiffrement à courbe elliptique ou ECC, vous pouvez personnaliser et sélectionner des noms de courbes comme que P-256, P-256K, P-384 et P-521. Si vous utilisez des clés RSA, vous pouvez exiger l’utilisation d’une taille de clé minimale pour les clés actuelles et nouvelles de 2048 bits, 3072 bits ou 4096 bits. N’oubliez pas que l’utilisation de clés RSA avec des tailles de clé plus petites n’est pas une pratique de conception sécurisée. Il est donc recommandé de bloquer la création de nouvelles clés qui ne répondent pas aux exigences de taille minimale.

Stratégie	Effets
Les clés doivent être du type de chiffrement spécifié, RSA ou EC	Audit (par défaut), Refuser, Désactivé
Les clés utilisant un chiffrement à courbe elliptique doivent avoir les noms de courbes spécifiés	Audit (par défaut), Refuser, Désactivé
[Préversion] : les clés HSM managées Azure Key Vault utilisant le chiffrement à courbe elliptique doivent avoir les noms de courbe spécifiés	Audit (par défaut), Refuser, Désactivé
Les clés utilisant le chiffrement RSA doivent avoir une taille minimale spécifiée	Audit (par défaut), Refuser, Désactivé
[Préversion] : les clés HSM managées Azure Key Vault utilisant le chiffrement RSA doivent avoir une taille de clé minimale spécifiée	Audit (par défaut), Refuser, Désactivé

Secrets

Cycle de vie des secrets

Avec les fonctionnalités intégrées de gestion du cycle de vie, vous pouvez marquer ou bloquer les secrets qui n’ont pas de date d’expiration, recevoir des alertes chaque fois que des retards de rotation des secrets risquent d’entraîner une interruption, empêcher la création de clés proches de la date d’expiration, limiter la durée de vie et l’état actif des clés pour favoriser la rotation des clés, et empêcher les clés d’être actives plus longtemps qu’un nombre de jours maximum spécifié.

Stratégie	Effets
Les secrets doivent avoir une date d’expiration	Audit (par défaut), Refuser, Désactivé
Les secrets doivent avoir une durée de vie supérieure au nombre spécifié de jours avant l’expiration	Audit (par défaut), Refuser, Désactivé
La période de validité maximale doit être spécifiée pour les secrets	Audit (par défaut), Refuser, Désactivé
Les secrets ne doivent pas être actifs pendant une période plus longue que le nombre spécifié de jours	Audit (par défaut), Refuser, Désactivé

Important

Si votre secret a une date d’activation définie, la stratégie ci-dessus calcule le nombre de jours écoulés depuis la date d’activation du secret jusqu’à la date actuelle. Si le nombre de jours dépasse le seuil que vous définissez, le secret est marqué comme non conforme à la stratégie. Si votre secret n’a pas de date d’activation définie, cette stratégie calcule le nombre de jours écoulés depuis la date de création du secret jusqu’à la date actuelle. Si le nombre de jours dépasse le seuil que vous définissez, le secret est marqué comme non conforme à la stratégie.

Attributs de secret

Tout fichier de texte brut ou encodé peut être stocké en tant que secret de coffre de clés Azure. Toutefois, votre organisation peut définir différentes stratégies de rotation et restrictions sur les mots de passe, les chaînes de connexion ou les certificats stockés en tant que clés. Une balise de type de contenu peut aider un utilisateur à voir ce qui est stocké dans un objet secret sans lire la valeur du secret. Vous pouvez auditer les secrets qui n’ont pas d’étiquette de type de contenu défini ou empêcher la création de secrets qui ne disposent d’aucune d’étiquette de type de contenu.

Policy	Effets
Les secrets doivent avoir un type de contenu défini	Audit (par défaut), Refuser, Désactivé

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.

Vous attribuez la stratégie La période de validité maximale des certificats doit être spécifiée, 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 ».
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.
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.
Vous remplacez l’effet de la stratégie attribuée par « refuser ». Les 5 certificats non conformes ne sont pas révoqués et continuent à fonctionner. Toutefois, ils ne peuvent pas être renouvelés avec une durée de validité supérieure à 2 ans.

Activer et gérer une stratégie Key Vault via le portail Azure

Sélectionner une définition de stratégie

Connectez-vous au portail Azure.
Recherchez « Stratégie » dans la barre de recherche et sélectionnez Stratégie.
Dans la fenêtre Stratégie, sélectionnez Définitions.
Dans le filtre Catégorie, désélectionnez Sélectionner tout et sélectionnez Key Vault.
Vous devriez maintenant voir toutes les stratégies disponibles pour la préversion publique, pour Azure Key Vault. Veillez à lire et comprendre la section sur les conseils de stratégie ci-dessus et sélectionnez la stratégie que vous voulez attribuer à une étendue.

Attribuer une stratégie à une étendue

Sélectionnez une stratégie à appliquer. Dans cet exemple, il s’agit de la stratégie Gérer la durée de validité des certificats. Cliquez sur le bouton Attribuer dans le coin supérieur gauche.
Sélectionnez l’abonnement dans lequel vous voulez appliquer la stratégie. Vous pouvez choisir de restreindre l’étendue à un seul groupe de ressources au sein d’un abonnement. Si vous souhaitez appliquer la stratégie à l’ensemble de l’abonnement et exclure certains groupes de ressources, vous pouvez également configurer une liste d’exclusions. Définissez le sélecteur d’application de stratégie sur Activé si vous voulez que l’effet de la stratégie (audit ou refuser) se produise ou sur Désactivé pour désactiver l’effet (audit ou refuser).
Cliquez sur l’onglet des paramètres en haut de l’écran pour indiquer la durée de validité maximale en mois souhaitée. Si vous devez entrer les paramètres, vous pouvez décocher l’option « Afficher uniquement les paramètres qui ont besoin d’une entrée ou d’une révision ». 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é

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é.
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.
Afficher le nom des composants non conformes au sein d’un coffre
Pour vérifier si les utilisateurs se voient refuser la possibilité de créer des ressources dans le coffre de clés, vous pouvez cliquer sur l’onglet Événements des composants (préversion) pour afficher une synthèse des opérations de refus de certificat indiquant le demandeur et le timestamp des requêtes.

Limitations des fonctionnalités

Après avoir attribué une stratégie avec un effet « refuser », la prise d’effet du refus de créer des ressources non conformes peut prendre entre 30 minutes (en moyenne) et 1 heure (pire des cas). Le retard fait référence aux scénarios suivants :

Une nouvelle stratégie est attribuée.
Une attribution de stratégie existante est modifiée.
un nouveau Key Vault (ressource) est créé dans une étendue avec des stratégies existantes.

Une fois l’évaluation de stratégie des composants existants d’un coffre effectuée, l’affichage des résultats de conformité dans l’interface utilisateur du portail peut prendre entre 1 heure (en moyenne) et 2 heures (pire des cas).

Si les résultats de conformité présentent le statut « Non démarré », cela peut être dû aux raisons suivantes :

L’évaluation des stratégies n’est pas encore terminée. La latence de l’évaluation initiale peut atteindre 2 heures dans le pire des cas.
Il n’y a pas de coffres de clés dans l’étendue de l’attribution de stratégie.
Il n’y a pas de coffres de clés avec des certificats dans l’étendue de l’attribution de stratégie.