Certificats serveur TLS
Sécurisez le trafic web à grande échelle
Inventaire des certificats
Découvrez et suivez tous vos certificats
Certificats DevOps
Automatisez pour les pipelines CI/CD
Chiffrement d'e-mails
S/MIME pour la messagerie d'entreprise
Directive NIS2
Obligations européennes en cybersécurité
DORA
Résilience opérationnelle numérique
eIDAS 2.0
Identification électronique et services de confiance
RGPD
Protection des données et vie privée
Cyber Resilience Act
Règlement européen sur la sécurité des produits
Azure Key Vault gère nativement les clés et les certificats au sein du cloud Azure. Ce guide présente ses fonctionnalités, les workflows BYOK, les intégrations avec les CA, les limites en environnement multi-cloud et les bonnes pratiques pour intégrer Key Vault dans une stratégie de gestion du cycle de vie des certificats à l'échelle de l'entreprise.
Azure Key Vault est le service cloud natif de Microsoft pour gérer les clés cryptographiques, les secrets et les certificats au sein de l'écosystème Azure. Il fournit un stockage de clés adossé à un HSM, des opérations automatisées de cycle de vie des certificats et une intégration étroite avec les services Azure tels qu'App Service, Azure Kubernetes Service et Azure DevOps. Pour les organisations qui exécutent leurs charges de travail sur Azure, Key Vault est la réponse par défaut à la question du stockage du matériel cryptographique sensible.
Cependant, les environnements d'entreprise reposent rarement sur un seul cloud. À mesure que les organisations s'étendent sur Azure, AWS, Google Cloud et leurs infrastructures on-premises, s'appuyer exclusivement sur Azure Key Vault crée des angles morts de visibilité et des silos opérationnels qui compliquent la gestion du cycle de vie des certificats. Ce guide examine ce qu'Azure Key Vault fait bien, comment il se compare aux autres solutions de KMS cloud, et où des outils complémentaires sont nécessaires pour gérer les clés et les certificats dans une entreprise hybride et multi-cloud.
Azure Key Vault est un service cloud managé qui centralise le stockage et le contrôle d'accès de trois catégories de matériel sensible : les clés cryptographiques, les secrets (clés d'API, mots de passe, chaînes de connexion) et les certificats X.509. Il est disponible en deux niveaux : Standard (clés protégées logiciellement) et Premium (clés protégées par des HSM validés FIPS 140-2 niveau 2). Pour les charges de travail nécessitant le niveau FIPS 140-2 niveau 3, Microsoft propose Azure Managed HSM, un service HSM dédié à locataire unique.
Key Vault s'intègre nativement à Azure Active Directory (Entra ID) pour l'authentification et utilise le contrôle d'accès basé sur les rôles (RBAC) ou des politiques d'accès au coffre pour gouverner qui peut effectuer quelles opérations sur quels objets. Chaque opération est journalisée dans Azure Monitor, fournissant une piste d'audit qui satisfait la plupart des cadres de conformité.
Le service prend en charge les tâches courantes de gestion des clés via une API REST et des SDK pour .NET, Java, Python, JavaScript et Go. Vous pouvez générer des clés à l'intérieur du coffre, importer des clés existantes, effectuer des opérations de signature et de vérification sans exposer le matériel de clé, et configurer des politiques de rotation automatique. Pour les certificats, Key Vault peut générer des CSR, s'intégrer à certaines CA publiques (DigiCert et GlobalSign) et automatiser le renouvellement.
Azure Key Vault n'évolue pas isolément. Chaque grand fournisseur cloud propose un service de gestion des clés, et comprendre les différences est essentiel pour prendre des décisions d'architecture éclairées.
Les trois fournisseurs offrent une protection robuste des clés au sein de leurs propres écosystèmes. Le défi apparaît lorsque votre infrastructure s'étend sur plusieurs d'entre eux, ce qui est la réalité de la plupart des entreprises au-delà d'une certaine taille.
L'offre de Microsoft prend en charge les clés, les secrets et les certificats dans un service unifié. Sa force réside dans son intégration profonde à l'écosystème Azure : Azure Disk Encryption, Azure Storage Service Encryption, Azure SQL TDE et les liaisons de certificats App Service se connectent tous nativement. Le niveau Premium utilise des HSM Thales Luna (FIPS 140-2 niveau 2), tandis que Managed HSM utilise des HSM Marvell LiquidSecurity (FIPS 140-2 niveau 3). La gestion des certificats est intégrée, avec renouvellement automatique pour les CA prises en charge.
Amazon sépare la gestion des clés (AWS KMS) et la gestion des certificats (AWS Certificate Manager) en services distincts. KMS prend en charge les clés gérées par le client adossées par défaut à des HSM FIPS 140-2 niveau 3, avec CloudHSM disponible pour du matériel dédié à locataire unique. ACM fournit gratuitement des certificats TLS publics avec renouvellement automatique pour les ressources AWS, mais les opérations de CA privée nécessitent le service AWS Private CA facturé séparément.
Google Cloud KMS fournit la gestion des clés avec Cloud HSM (FIPS 140-2 niveau 3) et Cloud External Key Manager pour les clés détenues en dehors de l'infrastructure de Google. Le service d'autorité de certification (CAS) de Google est une offre de CA privée managée qui prend en charge des hiérarchies de CA complexes. L'approche de GCP est modulaire, chaque fonction étant un service distinct.
La fonctionnalité de certificat d'Azure Key Vault va au-delà du simple stockage. Elle peut servir de gestionnaire de certificats léger pour les charges de travail hébergées sur Azure, en orchestrant l'émission, le renouvellement et le déploiement via une interface unique.
Cette gestion intégrée des certificats est réellement utile pour les équipes qui opèrent principalement sur Azure et utilisent les CA publiques prises en charge. Elle supprime la charge du renouvellement manuel et réduit le risque d'incidents liés à l'expiration des certificats pour les services hébergés sur Azure.
Vous pouvez créer des certificats auto-signés directement dans Key Vault ou générer un CSR à soumettre à une autorité de certification externe. Key Vault stocke le certificat, sa clé privée et la chaîne complète sous la forme d'un objet géré unique.
Key Vault dispose d'intégrations natives avec DigiCert et GlobalSign. Une fois configuré, il peut soumettre automatiquement les CSR, récupérer les certificats émis et les renouveler avant leur expiration, sans intervention manuelle.
Pour les certificats émis via les CA intégrées ou les certificats auto-signés, Key Vault prend en charge le renouvellement automatique à un pourcentage configurable de la durée de vie du certificat. Cela réduit le risque d'interruption de service causé par des certificats TLS/SSL expirés.
Les certificats stockés dans Key Vault peuvent être référencés directement par Azure App Service, Application Gateway, Front Door et Azure Kubernetes Service. Lorsque le certificat est renouvelé dans Key Vault, ces services récupèrent automatiquement le nouveau certificat, selon la configuration.
Key Vault peut déclencher des notifications Event Grid lorsque des certificats approchent de leur expiration ou sont renouvelés. Ces événements peuvent alimenter Azure Logic Apps, Functions ou des systèmes externes pour des workflows d'automatisation personnalisés.
Pour les organisations soumises à des exigences réglementaires strictes ou disposant d'investissements HSM existants, Azure Key Vault prend en charge le Bring Your Own Key (BYOK), qui vous permet de générer des clés dans votre HSM on-premises et de les transférer en toute sécurité vers Key Vault.
Le BYOK vous donne l'assurance que votre matériel de clé est né dans du matériel que vous contrôlez et qu'il n'a jamais été exposé en clair pendant le transfert. Azure Managed HSM prend également en charge un mécanisme de Key Release avec attestation Confidential Computing, ajoutant une couche d'assurance supplémentaire pour les charges de travail les plus sensibles.
Cependant, une fois qu'une clé est importée dans Azure Key Vault, elle est liée à Azure. Vous ne pouvez pas l'exporter vers le KMS d'un autre fournisseur cloud ou vers un autre HSM on-premises. Le caractère unidirectionnel du BYOK est une considération importante pour les stratégies multi-cloud.
À l'aide de votre HSM validé FIPS existant (Thales Luna, Entrust nShield ou un autre fournisseur pris en charge), générez la paire de clés à l'intérieur du périmètre inviolable. La clé n'existe jamais en clair en dehors du HSM.
Azure génère une Key Exchange Key au sein de son infrastructure HSM. Vous téléchargez la clé publique de la KEK, accompagnée d'un certificat d'attestation prouvant qu'elle a été générée dans un véritable HSM Azure.
À l'aide de votre HSM on-premises et de l'outillage spécifique au fournisseur, vous wrappez (chiffrez) votre clé cible avec la clé publique de la KEK. Le blob de clé wrappée ne peut être déchiffré qu'à l'intérieur du HSM d'Azure, garantissant que la clé n'est jamais exposée pendant le transit.
Importez le blob de clé wrappée dans Azure Key Vault via l'API REST ou l'Azure CLI. Key Vault importe la clé dans son HSM et la rend disponible pour les opérations cryptographiques. Vous pouvez vérifier l'import en contrôlant les attributs de la clé et en effectuant une opération de signature de test.
Azure Key Vault est un service solide dans son périmètre, mais les déploiements de PKI d'entreprise rencontrent fréquemment des limites qui nécessitent des outils complémentaires.
Ces limites ne font pas d'Azure Key Vault un mauvais choix. Elles en font un choix incomplet pour les organisations qui doivent gérer les clés et les certificats sur l'ensemble de leur infrastructure, pas seulement sur la portion Azure.
Key Vault gère les clés et les certificats au sein d'Azure. Il n'a aucune capacité native à découvrir, surveiller ou gérer les certificats déployés sur AWS, GCP, des serveurs on-premises, des équipements réseau ou des appareils IoT. Pour les organisations dont l'infrastructure est hybride ou multi-cloud, cela crée des angles morts dans la visibilité des certificats.
Les intégrations CA natives sont restreintes à DigiCert et GlobalSign. Si votre organisation utilise une CA privée (Microsoft AD CS, EJBCA, Evertrust PKI ou autre), vous devez gérer l'émission des certificats en dehors de Key Vault et importer manuellement les résultats. Il n'existe aucune intégration native avec l'infrastructure PKI interne.
Key Vault ne scanne pas votre infrastructure pour identifier les certificats déployés en dehors d'Azure. Il ne connaît que les certificats qui ont été explicitement stockés dans un coffre. Les certificats inconnus ou oubliés sur les systèmes hérités, les environnements de développement ou les services tiers restent invisibles.
Key Vault prend en charge des politiques d'accès et des contraintes de taille de clé, mais il n'applique pas les politiques de certificats à l'échelle de l'organisation telles que les conventions de nommage, les exigences de SAN, les standards d'algorithmes de clé ou les workflows d'approbation. La PKI d'entreprise exige généralement des moteurs de politique plus riches.
Key Vault ne gère pas la révocation des certificats. Il ne publie pas de CRL et n'exploite pas de répondeurs OCSP. La révocation reste de la responsabilité de la CA émettrice, et coordonner la révocation entre plusieurs CA et environnements cloud nécessite une couche d'orchestration distincte.
Les clés importées ou générées dans Key Vault ne peuvent pas être exportées. Si vous devez migrer vers un autre cloud ou rapatrier des clés on-premises, vous devez générer de nouvelles paires de clés et réémettre les certificats associés. Pour les déploiements de grande taille, cela crée une friction de migration significative.
La réalité de l'infrastructure d'entreprise est l'hétérogénéité. Une organisation de taille importante exécute typiquement des charges de travail sur Azure, AWS et GCP, exploite des datacenters on-premises, déploie des certificats sur des équipements réseau Citrix, F5 et Palo Alto, et gère le provisionnement automatisé des certificats via des protocoles comme ACME et EST.
Gérer cet environnement uniquement avec des outils cloud natifs implique d'exploiter trois systèmes de gestion des clés distincts (Key Vault, AWS KMS, GCP Cloud KMS), plusieurs gestionnaires de certificats (ACM, certificats Key Vault, GCP CAS), tout en n'ayant aucune visibilité sur les déploiements on-premises ou tiers. Chaque système possède sa propre API, son propre modèle d'accès, son propre format de journal d'audit et ses propres limites.
Une plateforme centralisée de gestion du cycle de vie des certificats (CLM) répond à cette fragmentation en offrant un point d'observation unique qui :
- Découvre les certificats sur tous les environnements, via le scan réseau, les intégrations API avec les fournisseurs cloud et la collecte par agents sur les endpoints. - Inventorie chaque certificat avec ses métadonnées : émetteur, sujet, SAN, date d'expiration, algorithme de clé, localisation de déploiement et référence Key Vault ou KMS associée. - Automatise le renouvellement et le provisionnement via des intégrations directes avec les CA (publiques et privées) et les cibles de déploiement, quel que soit l'endroit où elles s'exécutent. - Applique des politiques cohérentes sur tous les environnements : exigences d'algorithmes de clé, durées de validité maximales, SAN requis et workflows d'approbation. - Alerte sur les certificats approchant de leur expiration, les violations de politique, les algorithmes faibles ou les certificats émis par des CA inconnues.
Ce n'est pas un remplacement d'Azure Key Vault. C'est une couche qui se place au-dessus, consommant Key Vault comme l'un des nombreux endpoints managés, tout en fournissant la visibilité multi-plateforme et l'application de politique qu'aucun fournisseur cloud ne peut offrir seul.
Construire une architecture robuste de gestion des clés et des certificats incluant Azure Key Vault exige des choix de conception délibérés.
Laissez Key Vault faire ce qu'il fait de mieux : stocker les clés et les certificats que les services Azure consomment directement. Les liaisons App Service, les certificats Application Gateway et les clés Azure SQL TDE doivent référencer Key Vault nativement. Ne luttez pas contre la plateforme.
Créez des Key Vaults distincts pour la production, la préproduction et le développement. Utilisez Azure Managed HSM pour vos clés les plus sensibles (clés de signature de CA, clés de traitement des paiements) et les Key Vaults standard pour les secrets applicatifs. Appliquez le principe du moindre privilège via RBAC, et non par des politiques d'accès partagées.
Connectez Key Vault à une plateforme CLM centralisée afin que les certificats stockés dans Key Vault apparaissent dans votre inventaire global aux côtés des certificats provenant d'AWS, de GCP et des systèmes on-premises. Cela élimine les angles morts liés à la gestion isolée de chaque environnement.
Pour les certificats émis par des CA prises en charge nativement par Key Vault (DigiCert, GlobalSign), activez le renouvellement automatique dans Key Vault. Pour tous les autres certificats, utilisez votre plateforme CLM pour automatiser le workflow complet : vérification de politique, génération de CSR, soumission à la CA, récupération du certificat et déploiement dans Key Vault via l'API REST Azure.
Si vos exigences de conformité imposent que les clés cryptographiques soient nées dans du matériel que vous contrôlez, utilisez le workflow BYOK pour transférer les clés de votre HSM on-premises vers Key Vault. Documentez la cérémonie des clés, conservez les enregistrements de chaîne de garde et stockez le matériel de sauvegarde de manière sécurisée.
Azure Key Vault prend en charge aujourd'hui les clés RSA et à courbe elliptique. À mesure que les standards de cryptographie post-quantique mûriront, vous devrez tourner vos clés vers de nouveaux algorithmes. Concevez votre architecture de manière à pouvoir réaliser la rotation des clés et la réémission des certificats à l'échelle par l'automatisation, et non par des processus manuels.
Agrégez les journaux de diagnostic Key Vault avec les données d'audit d'autres systèmes de gestion des clés dans un SIEM unique ou un outil de reporting de conformité. Cela fournit la piste d'audit unifiée que les auditeurs attendent et que les outils cloud natifs ne peuvent produire seuls.
Découverte multi-cloud des certificats — Evertrust CLM se connecte à Azure Key Vault, AWS ACM, GCP Certificate Manager et à l'infrastructure on-premises pour construire un inventaire complet et en temps réel de tous les certificats de votre organisation, éliminant les angles morts de visibilité propres aux outils cloud natifs.
Application unifiée des politiques — Définissez vos politiques de certificats une seule fois et appliquez-les partout, sur Azure, AWS, GCP et les environnements on-premises, en garantissant des algorithmes de clé, des durées de validité et des conventions de nommage cohérents, quel que soit l'endroit où les certificats sont émis ou déployés.
Orchestration automatisée du cycle de vie — Evertrust CLM automatise l'intégralité du cycle de vie des certificats, de l'émission au renouvellement jusqu'à la révocation, en s'intégrant à n'importe quelle CA et en déployant les certificats sur n'importe quelle cible, y compris Azure Key Vault, via des intégrations API natives.
Gouvernance des clés indépendante du fournisseur — Évitez l'enfermement dans l'écosystème de gestion des clés d'un fournisseur cloud unique. Evertrust fournit un plan de contrôle qui fonctionne sur toutes les plateformes, vous donnant la liberté de faire évoluer votre infrastructure sans reconstruire votre stratégie de gestion des certificats.