Sécurité d’Azure Key Vault

Article
01/30/2024

Azure Key Vault protège les clés de chiffrement, les certificats (et les clés privées associées aux certificats) et les secrets (tels que les chaînes de connexion et les mots de passe) dans le cloud. Toutefois, lors du stockage de données sensibles et critiques pour l’entreprise, vous devez prendre des mesures afin d’optimiser la sécurité de vos coffres et des données qui y sont stockées.

Cet article fournit une vue d’ensemble des fonctionnalités de sécurité et des meilleures pratiques pour Azure Key Vault.

Notes

Pour obtenir la liste complète des recommandations en matière de sécurité d'Azure Key Vault, consultez Base de référence de sécurité pour Azure Key Vault.

Sécurité du réseau

Vous pouvez réduire l’exposition de vos coffres en spécifiant les adresses IP qui y ont accès. Les points de terminaison de service de réseau virtuel pour Azure Key Vault permettent de restreindre l’accès à un réseau virtuel spécifié. Les points de terminaison vous permettent également de restreindre l’accès à une liste de plages d’adresses IPv4 (Internet Protocol version 4). L’accès est refusé à tout utilisateur se connectant à votre coffre de clés en dehors de ces sources. Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel pour Azure Key Vault.

Une fois que les règles de pare-feu sont effectives, les utilisateurs peuvent lire les données de Key Vault seulement quand leurs requêtes proviennent de réseaux virtuels ou de plages d’adresses IPv4 autorisés. Ceci s’applique également à l’accès au coffre de clés à partir du portail Azure. Si des utilisateurs peuvent accéder à un coffre de clés à partir du portail Azure, il ne peuvent pas lister les clés/secrets/certificats si leur ordinateur client ne figure pas dans la liste autorisée. Pour connaître les étapes d’implémentation, consultez Configurer les pare-feu et réseaux virtuels d’Azure Key Vault.

Le service Azure Private Link vous permet d’accéder à Azure Key Vault et aux services clients/partenaires hébergés sur Azure via un point de terminaison privé de votre réseau virtuel. Un point de terminaison privé Azure est une interface réseau qui vous connecte de façon privée et sécurisée à un service basé sur la technologie Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel, plaçant de fait le service dans votre réseau virtuel. Sachant que l’ensemble du trafic à destination du service peut être routé via le point de terminaison privé, il n’y a aucun besoin de passerelles, d’appareils NAT, de connexions ExpressRoute ou VPN ou d’adresses IP publiques. Le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft, éliminant ainsi toute exposition à l’Internet public. Vous pouvez vous connecter à une instance d’une ressource Azure, ce qui vous donne le plus haut niveau de granularité en matière de contrôle d’accès. Pour connaître les étapes d’implémentation, consultez Intégrer Key Vault à Azure Private Link.

TLS et HTTPS

Le serveur frontal Key Vault (plan de données) est un serveur multilocataire. Cela signifie que les coffres de clés de différents clients peuvent partager la même IP publique. À des fins d’isolement, chaque requête HTTP est authentifiée et autorisée indépendamment des autres requêtes.
Le protocole HTTPS permet au client de participer à la négociation TLS. Les clients peuvent appliquer la version de TLS et, chaque fois qu’un client le fait, l’ensemble de la connexion utilise le niveau de protection correspondant. Key Vault prend en charge les versions 1.2 et 1.3 du protocole TLS.

Remarque

Vous pouvez vérifier la version TLS utilisée par les clients en monitorant les journaux Key Vault avec un exemple de requête Kusto ici.

Options d’authentification Key Vault

Lorsque vous créez un coffre de clés dans un abonnement Azure, il est automatiquement associé au locataire Microsoft Entra de l’abonnement. Tous les appelants dans les deux plans doivent s’inscrire auprès de ce locataire et s’authentifier pour accéder au coffre de clés. Dans les deux cas, les applications peuvent accéder au coffre de clés de trois manières :

Application uniquement : l’application représente un principal du service ou une identité managée. Cette identité est le scénario le plus courant pour les applications qui doivent accéder régulièrement à des certificats, des clés ou des secrets à partir du coffre de clés. Pour que ce scénario fonctionne, la propriété objectId de l’application doit être spécifiée dans la stratégie d’accès et applicationId ne doit pas être spécifiée ou doit être null.
Utilisateur uniquement : l’utilisateur accède au coffre de clés à partir de n’importe quelle application inscrite dans le locataire. Azure PowerShell et le portail Azure sont des exemples de ce type d’accès. Pour que ce scénario fonctionne, la propriété objectId de l’utilisateur doit être spécifiée dans la stratégie d’accès et applicationId ne doit pas être spécifiée ou doit être null.
Application-plus-utilisateur (parfois appelé identité composée) : l’utilisateur est tenu d’accéder au coffre de clés à partir d’une application spécifique et l’application doit utiliser le flux OBO (Authentification On-Behalf-Of) pour emprunter l’identité de l’utilisateur. Pour que ce scénario fonctionne, l’applicationId et l’objectId doivent être spécifiés dans la stratégie d’accès. applicationId identifie l’application requise et objectId identifie l’utilisateur. Actuellement, cette option n’est pas disponible pour le plan de données Azure RBAC.

Pour tous les types d’accès, l’application s’authentifie auprès de Microsoft Entra ID. L’application utilise une méthode d’authentification prise en charge en fonction du type d’application. L’application acquiert un jeton pour une ressource dans le plan pour accorder l’accès. La ressource est un point de terminaison dans le plan de gestion ou de données, en fonction de l’environnement Azure. L’application utilise le jeton et envoie une demande d’API REST à Key Vault. Pour en savoir plus, passez en revue le flux d’authentification intégral.

Le modèle d’un mécanisme d’authentification unique auprès des deux plans présente plusieurs avantages :

Les organisations peuvent contrôler de manière centralisée l’accès à tous leurs coffres de clés.
Si un utilisateur part, il perd instantanément l’accès à tous les coffres de clés de l’organisation.
Les organisations peuvent personnaliser l’authentification à l’aide des options de Microsoft Entra ID (par exemple, pour activer l’authentification multifacteur afin de renforcer la sécurité).

Pour plus d’informations, consultez Concepts de base de l’authentification Key Vault.

Vue d’ensemble du modèle d’accès

L’accès à un coffre de clés est contrôlé par le biais de deux interfaces : le plan de gestion et le plan de données. Le plan de gestion vous permet de gérer le coffre de clés. Dans ce plan, vous pouvez notamment créer et supprimer des coffres de clés, récupérer des propriétés Key Vault et mettre à jour des stratégies d’accès. Le plan de données vous permet d’utiliser les données stockées dans un coffre de clés. Vous pouvez ajouter, supprimer et modifier des clés, des secrets et des certificats.

Les deux plans utilisent Microsoft Entra ID pour l’authentification. Pour l’autorisation, le plan de gestion utilise le contrôle d’accès en fonction du rôle (Azure RBAC) Azure et le plan de données utilise une stratégie d’accès Key Vault et Azure RBAC pour les opérations du plan de données Key Vault.

Pour accéder à un coffre de clés dans l’un ou l’autre de ces plans, tout appelant (utilisateur ou application) doit être authentifié et autorisé. L’authentification établit l’identité de l’appelant. L’autorisation détermine les opérations que l’appelant peut exécuter. L’authentification auprès de Key Vault fonctionne conjointement avec Microsoft Entra ID, qui est chargé d’authentifier l’identité de chaque principal de sécurité donné.

Un principal de sécurité est un objet qui représente un utilisateur, un groupe, un service ou une application demandant l’accès aux ressources Azure. Azure affecte un ID d’objet unique à chaque principal de sécurité.

Un principal de sécurité utilisateur identifie une personne disposant d’un profil dans Microsoft Entra ID.
Un principal de sécurité groupe identifie un ensemble d’utilisateurs créés dans Microsoft Entra ID. Tous les rôles et autorisations attribués au groupe sont accordés à tous les utilisateurs du groupe.
Un principal de service est un type de principal de sécurité qui identifie une application ou un service, c’est-à-dire un morceau de code plutôt qu’un utilisateur ou un groupe. L’ID d’objet d’un principal de service, appelé ID client, lui sert de nom d’utilisateur. La clé secrète client ou le certificat du principal de service fonctionne comme un mot de passe. De nombreux services Azure prennent en charge l’attribution de l’identité managée avec la gestion automatisée de l’ID client et du certificat. L’identité managée est l’option la plus sécurisée et recommandée pour l’authentification dans Azure.

Pour plus d’informations sur l’authentification sur Key Vault, consultez S’authentifier auprès d’Azure Key Vault.

Accès conditionnel

Key Vault prend en charge les stratégies d’accès conditionnel Microsoft Entra. En utilisant des stratégies d’accès conditionnel, vous pouvez appliquer les contrôles d’accès appropriés au Key Vault pour garantir la sécurité de votre organisation sans pour autant freiner inutilement votre utilisateur.

Pour plus d’informations, consultez Vue d’ensemble de l’accès conditionnel.

Accès privilégié

L’autorisation détermine les opérations que l’appelant peut exécuter. L’autorisation dans Key Vault utilise le contrôle d’accès en fonction du rôle Azure (Azure RBAC) sur le plan de gestion, et des stratégies d’accès Azure RBAC ou Azure Key Vault sur le plan de données.

L’accès aux coffres se produit via deux interfaces ou plans. Il s’agit du plan de gestion et du plan de données.

Le plan de gestion est l’endroit où vous gérez Key Vault lui-même. C’est l’interface utilisée pour créer et supprimer des coffres. Vous pouvez également lire les propriétés de coffre de clés et gérer les stratégies d’accès.
Le plan de données vous permet d’utiliser les données stockées dans un coffre de clés. Vous pouvez ajouter, supprimer et modifier des clés, des secrets et des certificats.

Les applications accèdent aux plans par le biais de points de terminaison. Les contrôles d’accès pour les deux plans fonctionnent indépendamment. Pour permettre à une application d’utiliser des clés dans un coffre de clés, vous accordez l’accès au plan de données en utilisant une stratégie d’accès Azure RBAC ou Key Vault. Pour permettre à un utilisateur de lire les propriétés et les étiquettes d’un coffre de clés, mais pas d’accéder aux données (clés, secrets ou certificats), vous accordez l’accès au plan de gestion avec Azure RBAC.

Le tableau suivant présente les points de terminaison pour les plans de gestion et de données.

Plan d’accès	Points de terminaison d’accès	Opérations	Mécanisme de contrôle d’accès
Plan de gestion	Mondial : management.azure.com:443 Microsoft Azure utilisé par 21Vianet : management.chinacloudapi.cn:443 Azure US Government : management.usgovcloudapi.net:443 Azure Germany : management.microsoftazure.de:443	Créer, lire, mettre à jour et supprimer des coffres de clés Définir des stratégies d’accès Key Vault Définir des étiquettes Key Vault	Azure RBAC
Plan de données	Mondial : <nom du coffre>.vault.azure.net:443 Microsoft Azure utilisé par 21Vianet : <nom du coffre>.vault.azure.cn:443 Azure US Government : <nom du coffre>.vault.usgovcloudapi.net:443 Azure Germany : <nom du coffre>.vault.microsoftazure.de:443	Clés : chiffrer, déchiffrer, wrapKey, unwrapKey, signer, vérifier, obtenir, lister, créer, mettre à jour, importer, supprimer, récupérer, sauvegarder, restaurer, purger, faire pivoter (préversion), getrotationpolicy (préversion), setrotationpolicy (préversion), mettre en production (préversion) Certificats : managecontacts, getissuers, listissuers, setissurs, deleteissuers, manageissuers, obtenir, lister, créer, importer, mettre à jour, supprimer, récupérer, sauvegarder, restaurer, purger Secrets : obtenir, lister, définir, supprimer, récupérer, sauvegarder, restaurer, purger	Stratégie d’accès Key Vault ou Azure RBAC

Gestion de l’accès administratif à Key Vault

Lorsque vous créez un coffre de clés dans un groupe de ressources, vous gérez l’accès à l’aide de Microsoft Entra ID. Vous autorisez des utilisateurs ou des groupes à gérer les coffres de clés dans un groupe de ressources. Vous pouvez accorder l’accès à un niveau d’étendue spécifique en attribuant les rôles Azure appropriés. Pour permettre à un utilisateur de gérer des coffres de clés, vous attribuez un rôle key vault Contributor prédéfini à l’utilisateur dans une étendue spécifique. Les niveaux d’étendue suivants peuvent être attribués à un rôle Azure :

Abonnement: Un rôle Azure attribué au niveau d’un abonnement s’applique à tous les groupes de ressources et à toutes les ressources au sein de cet abonnement.
Groupe de ressources : Un rôle Azure attribué au niveau d’un groupe de ressources s’applique à toutes les ressources de ce groupe de ressources.
Ressource spécifique : Un rôle Azure attribué pour une ressource spécifique s’applique à cette ressource. Dans ce cas, la ressource est un coffre de clés spécifique.

Il existe plusieurs rôles prédéfinis. Si un rôle prédéfini ne répond pas à vos besoins, vous pouvez définir votre propre rôle. Pour plus d’informations, consultez RBAC Azure : rôles intégrés.

Important

Lors de l’utilisation du modèle d’autorisation Stratégie d’accès, si un utilisateur dispose du rôle Contributor, Key Vault Contributor ou d’un autre rôle avec des autorisations Microsoft.KeyVault/vaults/write sur un plan de gestion de coffre de clés, il peut s’accorder à lui-même l’accès au plan de données en définissant une stratégie d’accès Key Vault. Vous devez contrôler étroitement qui a un accès du rôle Contributor à vos coffres de clés avec le modèle d’autorisation Stratégie d’accès pour garantir que seules les personnes autorisées peuvent gérer vos coffres de clés, vos clés, vos secrets et vos certificats. Il est recommandé d’utiliser le nouveau modèle d’autorisation RBAC (Role Based Access Control) pour éviter ce problème. Avec le modèle d’autorisation RBAC, la gestion des autorisations est limitée aux rôles « Propriétaire » et « Administrateur de l’accès utilisateur », ce qui permet la séparation des tâches entre les rôles pour les opérations de sécurité et les opérations d’administration générales.

Contrôle de l’accès aux données de Key Vault

Vous pouvez contrôler l’accès aux clés, aux certificats et aux secrets Key Vault en utilisant des stratégies d’accès Azure RBAC ou Key Vault.

Pour plus d'informations, consultez la rubrique

Enregistrement et surveillance

La journalisation de Key Vault enregistre les informations sur les activités effectuées sur votre coffre. Pour plus d’informations, consultez Journalisation de Key Vault.

Vous pouvez intégrer Key Vault à Event Grid pour être averti lorsque l’état d’une clé, d’un certificat ou d’un secret stocké dans le coffre de clés a changé. Pour plus d’informations, consultez Supervision de Key Vault avec Azure Event Grid.

Il est également important de surveiller l’intégrité de votre coffre de clés pour vous assurer que votre service fonctionne comme prévu. Pour savoir comment procéder, consultez Surveillance et alertes Azure Key Vault.

Sauvegarde et récupération

La suppression réversible et la protection contre la suppression définitive d’Azure Key Vault permettent de récupérer des coffres et des objets de coffre supprimés. Pour plus d’informations, consulter Vue d’ensemble de la suppression réversible d’Azure Key Vault.

Vous devez également effectuer des sauvegardes régulières de votre coffre, notamment lors de la mise à jour, de la suppression ou de la création d’objets au sein d’un coffre.