Partager via

Concepts de base d’Azure Key Vault

Azure Key Vault est un service cloud permettant de stocker et d’accéder en toute sécurité aux secrets. Un secret est tout ce que vous souhaitez contrôler étroitement l’accès, comme les clés API, les mots de passe, les certificats ou les clés de chiffrement. Le service Key Vault prend en charge deux types de conteneurs : les coffres et les pools de modules de sécurité matérielle gérés (HSM). Les coffres prennent en charge le stockage des clés logicielles et sauvegardées avec HSM, les secrets et les certificats. Les pools HSM managés prennent uniquement en charge les clés sauvegardées avec HSM. Pour plus d’informations, consultez la vue d’ensemble de l’API REST Azure Key Vault .

Voici d’autres termes importants :

  • Locataire : un locataire est l’organisation qui possède et gère une instance spécifique des services cloud Microsoft. Il est le plus souvent utilisé pour faire référence à l’ensemble des services Azure et Microsoft 365 pour une organisation.

  • Propriétaire du coffre : un propriétaire de coffre peut créer un coffre de clés et obtenir un accès et un contrôle complets sur celui-ci. Le propriétaire du coffre-fort peut également configurer l’audit pour enregistrer les personnes qui accèdent aux secrets et clés. Les administrateurs peuvent contrôler le cycle de vie des clés. Ils peuvent passer à une nouvelle version de la clé, la sauvegarder et effectuer des tâches associées.

  • Consommateur de coffre : un consommateur de coffre peut effectuer des actions sur les ressources à l’intérieur du coffre de clés lorsque le propriétaire du coffre accorde l'accès au consommateur. Les actions disponibles dépendent des autorisations accordées.

  • Administrateurs HSM managés : les utilisateurs auxquels le rôle Administrateur est attribué ont un contrôle total sur un pool HSM managé. Ils peuvent créer davantage d’attributions de rôles pour déléguer l’accès contrôlé à d’autres utilisateurs.

  • Agent/utilisateur de chiffrement HSM managé : rôles intégrés qui sont généralement attribués aux utilisateurs ou aux principaux de service qui effectuent des opérations de chiffrement à l’aide de clés dans Managed HSM. L’utilisateur de chiffrement peut créer de nouvelles clés, mais ne peut pas supprimer de clés.

  • Utilisateur du service de chiffrement HSM managé : rôle intégré qui est généralement affecté à une identité de service gérée (par exemple, compte de stockage) pour chiffrer les données au repos avec une clé contrôlée par le client.

  • Ressource : une ressource est un élément gérable disponible via Azure. Les exemples courants sont la machine virtuelle, le compte de stockage, l’application web, la base de données et le réseau virtuel. Il y en a beaucoup plus.

  • Groupe de ressources : un groupe de ressources est un conteneur qui contient les ressources associées pour une solution Azure. Le groupe de ressources peut inclure toutes les ressources de la solution, ou uniquement celles que vous souhaitez gérer en tant que groupe. Vous décidez de la façon dont vous souhaitez allouer des ressources à des groupes de ressources, en fonction de ce qui est le plus judicieux pour votre organisation.

  • Principal de sécurité : un principal de sécurité Azure est une identité de sécurité que les applications, services et outils d’automatisation créés par l’utilisateur utilisent pour accéder à des ressources Azure spécifiques. Considérez-le comme une « identité utilisateur » (nom d’utilisateur et mot de passe ou certificat) avec un rôle spécifique et des autorisations étroitement contrôlées. Un principal de sécurité doit uniquement avoir besoin d’effectuer des opérations spécifiques, contrairement à une identité d’utilisateur générale. Elle améliore la sécurité si vous lui accordez uniquement le niveau d’autorisation minimal dont il a besoin pour effectuer ses tâches de gestion. Un principal de sécurité utilisé avec une application ou un service est appelé principal de service. Pour plus d’informations, consultez Objets application et principal du service.

  • ID Microsoft Entra : l’ID Microsoft Entra est le service Active Directory d’un locataire. Chaque répertoire a un ou plusieurs domaines. Un répertoire peut avoir de nombreux abonnements associés, mais un seul locataire.

  • ID de locataire Azure : un ID de locataire est un moyen unique d’identifier une instance Microsoft Entra au sein d’un abonnement Azure.

  • Identités managées : Azure Key Vault permet de stocker en toute sécurité les informations d’identification et d’autres clés et secrets, mais votre code doit s’authentifier auprès de Key Vault pour les récupérer. L’utilisation d’une identité managée simplifie la résolution de ce problème en donnant aux services Azure une identité managée automatiquement dans Microsoft Entra ID. Vous pouvez utiliser cette identité pour vous authentifier auprès de Key Vault ou tout service prenant en charge l’authentification Microsoft Entra, sans avoir d’informations d’identification dans votre code. Pour plus d’informations, consultez l’image suivante et la vue d’ensemble des identités managées pour les ressources Azure.

Authentication

Pour effectuer des opérations avec Key Vault, vous devez d’abord vous y authentifier. Il existe trois façons de s’authentifier auprès de Key Vault :

  • Identités managées pour les ressources Azure : lorsque vous déployez une application sur une machine virtuelle dans Azure, vous pouvez affecter une identité à votre machine virtuelle qui a accès à Key Vault. Vous pouvez également affecter des identités à d’autres ressources Azure. L’avantage de cette approche est que l’application ou le service ne gère pas la rotation du premier secret. Azure renouvelle automatiquement l’identité. Nous vous recommandons cette approche en tant que meilleure pratique.
  • Principal de service et certificat : vous pouvez utiliser un principal de service et un certificat associé qui a accès à Key Vault. Nous vous déconseillons cette approche, car le propriétaire ou le développeur de l’application doit faire pivoter le certificat. Pour plus d’informations, consultez Créer un principal de service.
  • Principal de service et secret : bien que vous puissiez utiliser un principal de service et un secret pour vous authentifier auprès de Key Vault, nous ne le recommandons pas. Il est difficile de faire pivoter automatiquement le secret bootstrap utilisé pour s’authentifier auprès de Key Vault.

Pour obtenir des conseils d’authentification complets, consultez Authentification dans Azure Key Vault.

Chiffrement des données en transit

Azure Key Vault applique le protocole TLS (Transport Layer Security) pour protéger les données lorsqu’elles transitent entre Azure Key Vault et les clients. Les clients négocient une connexion TLS avec Azure Key Vault. TLS fournit une authentification forte, la confidentialité et l’intégrité des messages (activation de la détection de falsification et d’interception des messages), l’interopérabilité, la flexibilité des algorithmes, ainsi que la facilité de déploiement et d’utilisation.

Perfect Forward Secrecy (PFS) protège les connexions entre les systèmes clients des clients et les services cloud de Microsoft par des clés uniques. Les connexions utilisent également les longueurs de clés de chiffrement RSA de 2 048 bits. Cette combinaison rend difficile pour une personne l’interception et l’accès aux données en transit.

Rôles de Key Vault

Utilisez le tableau suivant pour mieux comprendre comment Key Vault peut aider à répondre aux besoins des développeurs et des administrateurs de sécurité.

Role Définition du problème Résolu par Azure Key Vault
Développeur pour une application Azure « Je souhaite écrire une application pour Azure qui utilise des clés pour la signature et le chiffrement. Mais je souhaite que ces clés soient externes à partir de mon application afin que la solution soit adaptée à une application distribuée géographiquement.

Je veux que ces clés et ces secrets soient protégés, sans avoir à écrire le code moi-même. Je veux également que ces clés et secrets soient faciles à utiliser à partir de mes applications, avec des performances optimales.		 √ Clés sont stockées dans un coffre et appelées par URI si nécessaire.

√ Clés sont protégées par Azure, à l’aide d’algorithmes standard, de longueurs de clés et de modules de sécurité matériels.

√ Clés sont traitées dans des modules HSM qui résident dans les mêmes centres de données Azure que les applications. Cette méthode offre une meilleure fiabilité et une latence réduite par rapport aux clés qui résident dans un emplacement distinct, comme sur site.
Développeur pour les logiciels en tant que service (SaaS) Je ne souhaite pas avoir la responsabilité ni le risque potentiel liés aux clés de locataire et aux secrets de mes clients.

Je veux que les clients possèdent et gèrent leurs clés afin que je puisse me concentrer sur la façon de faire ce que je fais le mieux, ce qui fournit les principales fonctionnalités logicielles.		 √ Clients peuvent importer leurs propres clés dans Azure et les gérer. Lorsqu’une application SaaS doit effectuer des opérations de chiffrement à l’aide des clés des clients, Key Vault effectue ces opérations pour le compte de l’application. L’application ne voit pas les clés des clients.
Directeur de la sécurité (CSO) « Je veux savoir que nos applications se conforment à FIPS 140 Niveau 3 HSM pour une gestion sécurisée des clés.

Je veux m’assurer que mon organisation contrôle le cycle de vie des clés et peut surveiller l’utilisation des clés.

Bien que nous utilisions plusieurs services et ressources Azure, je souhaite gérer les clés à partir d’un emplacement unique dans Azure.		 √ Choisissez des coffres ou des HSM managés pour les HSM validés FIPS 140.
√ Choisir des pools HSM managés pour les modules HSM validés FIPS 140-2 Niveau 3.

√ Key Vault est conçu afin que Microsoft ne voit pas ou n’extraye pas vos clés.
L'utilisation de la clé est enregistrée en quasi temps réel.

√ Le coffre fournit une interface unique, quel que soit le nombre de coffres que vous avez dans Azure, les régions prises en charge et les applications qui les utilisent.

Toute personne disposant d’un abonnement Azure peut créer et utiliser des coffres de clés. Bien que Key Vault bénéficie aux développeurs et aux administrateurs de sécurité, il peut être implémenté et géré par l’administrateur d’une organisation qui gère d’autres services Azure. Par exemple, cet administrateur peut se connecter avec un abonnement Azure, créer un coffre pour l’organisation dans laquelle stocker des clés, puis être responsable des tâches opérationnelles comme suit :

  • Créer ou importer une clé ou un secret
  • Révoquer ou supprimer une clé ou un secret
  • Autoriser les utilisateurs ou les applications à accéder au coffre de clés afin qu’ils puissent ensuite gérer ou utiliser ses clés et secrets
  • Configurer l’utilisation des clés (par exemple, signer ou chiffrer)
  • Surveiller l’utilisation des clés

Cet administrateur fournit ensuite aux développeurs les URI à appeler depuis leurs applications. Cet administrateur fournit également des informations de journalisation d’utilisation clés à l’administrateur de sécurité.

Vue d’ensemble du fonctionnement d’Azure Key Vault

Les développeurs peuvent également gérer les clés directement à l’aide d’API. Pour plus d’informations, consultez le guide du développeur Azure Key Vault.

Étapes suivantes

Azure Key Vault est disponible dans la plupart des régions. Pour plus d’informations, consultez la page de tarification de Key Vault.

  • Last updated on