Gérer les certificats, les secrets et les clés
La prise en charge des certificats Azure Key Vault vous permet de gérer vos certificats X.509 et les comportements suivants :
- Permet à un propriétaire de certificat de créer un certificat via un processus de création de coffre de clés ou l’importation d’un certificat existant. Le certificat importé comprend à la fois les certificats auto-signés et ceux qui sont générés par une autorité de certification (CA).
- Permet à un propriétaire de certificat Key Vault d’implémenter le stockage sécurisé et la gestion des certificats X.509 sans interagir avec des éléments de clé privée.
- Permet à un propriétaire de certificat de créer une stratégie qui spécifie comment Key Vault doit gérer le cycle de vie d’un certificat.
- Permet à un propriétaire de certificat de fournir des informations de contact utilisées pour l’envoi des notifications déclenchées par des événements de cycle de vie d’expiration et de renouvellement.
- Prend en charge le renouvellement automatique avec les émetteurs sélectionnés : fournisseurs de certificats X.509 et autorités de certification partenaires Key Vault.
Composition d’un certificat
Lorsqu’un certificat Key Vault est créé, une clé et un secret adressables sont également créés avec le même nom. La clé Key Vault permet d’exécuter des opérations sur les clés et le secret Key Vault permet de récupérer la valeur du certificat en tant que secret. Un certificat Key Vault contient également des métadonnées de certificat X.509 publiques.
L’identificateur et la version des certificats sont similaires à ceux des clés et secrets. Une version spécifique d’une clé et d’un secret adressables créés avec la version du certificat Key Vault est disponible dans la réponse de certificat Key Vault.
Clé exportable ou non exportable
Lorsqu’un certificat Key Vault est créé, il peut être récupéré dans le secret adressable avec la clé privée au format PFX ou PEM. La stratégie utilisée pour créer le certificat doit indiquer que la clé est exportable. Si la stratégie indique que la clé n’est pas exportable, la clé privée ne fait pas partie de la valeur quand elle est récupérée comme secret.
La clé adressable devient plus pertinente avec les certificats Key Vault non exportables. Les opérations de la clé Key Vault adressable sont mappées à partir du champ d’utilisation de la clé de la stratégie de certificat Key Vault utilisée pour créer le certificat Key Vault.
Le tableau suivant liste les types de clés pris en charge.
Type de clé | À propos | Sécurité |
---|---|---|
RSA | Clé RSA protégée par logiciel | FIPS 140-2 niveau 1 |
RSA-HSM | Clé RSA protégée par HSM (référence SKU Premium uniquement) | HSM FIPS 140-2 niveau 2 |
EC | Clé à courbe elliptique protégée par logiciel | FIPS 140-2 niveau 1 |
EC-HSM | Clé à courbe elliptique protégée par HSM (référence SKU Premium uniquement) | HSM FIPS 140-2 niveau 2 |
octet | Clé d’octets protégée par logiciel | FIPS 140-2 niveau 1 |
Les clés exportables sont autorisées uniquement avec RSA et EC. Les clés HSM ne sont pas exportables.
Attributs et balises de certificat
En plus des métadonnées de certificat, d’une clé adressable et d’un secret adressable, un certificat Key Vault contient également des attributs et des balises.
Attributs
Les attributs de certificat sont reproduits dans des attributs de la clé et du secret adressables qui sont créés au moment de la création du certificat Key Vault.
Un certificat Key Vault comporte l’attribut suivant :
enabled : cet attribut booléen est facultatif. La valeur par défaut est true. Peut être spécifié pour indiquer si les données du certificat sont récupérables en tant que secret ou utilisables en tant que clé.
- Cet attribut est également utilisé avec nbf et exp quand une opération se produit entre nbf et exp, mais uniquement si enabled est défini sur true. Les opérations en dehors de la fenêtre nbf et exp sont automatiquement interdites.
Une réponse inclut ces attributs supplémentaires en lecture seule :
- created : IntDate indique quand cette version du certificat a été créée.
- updated : IntDate indique quand cette version du certificat a été mise à jour.
- exp : IntDate contient la valeur de la date d’expiration du certificat X.509.
- nbf : IntDate contient la valeur de la date « pas avant » du certificat X.509.
Remarque
Si un certificat Key Vault arrive à expiration, vous pouvez toujours le récupérer. Toutefois, il peut devenir inutilisable dans des scénarios tels que la protection TLS (Transport Layer Security) où l’expiration du certificat est validée.
Balises
Les balises pour les certificats sont un dictionnaire de paires clé-valeur spécifié par le client, tout comme les balises dans les clés et les secrets.
Notes
Un appelant peut lire les balises s’il dispose de l’autorisation list ou get sur ce type d’objet (clés, secrets ou certificats).
Stratégie de certificat
Une stratégie de certificat contient des informations sur le processus de création et de gestion du cycle de vie d’un certificat Key Vault. Quand un certificat avec une clé privée est importé dans le coffre de clés, le service Key Vault crée une stratégie par défaut en lisant le certificat X.509.
Quand un certificat Key Vault est créé de zéro, une stratégie doit être fournie. La stratégie spécifie comment créer cette version du certificat Key Vault ou la prochaine version. Une fois qu’une stratégie a été définie, les opérations de création successives ne sont pas nécessaires pour les prochaines versions. Il n’existe qu’une seule instance d’une stratégie pour toutes les versions d’un certificat Key Vault.
Globalement, une stratégie de certificat contient les informations suivantes :
Propriétés du certificat X.509, dont le nom d’objet, les autres noms d’objet et d’autres propriétés qui sont utilisées pour créer une demande de certificat X.509.
Propriétés des clés, notamment les champs type de clé, longueur de clé, exportable et
ReuseKeyOnRenewal
. Ces champs indiquent à Key Vault comment générer une clé.- Les types de clés pris en charge sont RSA, RSA-HSM, EC, EC, EC-HSM et octet.
Propriétés du secret, comme le type de contenu d’un secret adressable pour générer la valeur du secret, dans le but de récupérer un certificat comme secret.
Actions de durée de vie pour le certificat Key Vault. Chaque action de la durée de vie contient :
Déclencheur : spécifié en nombre de jours avant l’expiration ou en pourcentage de la durée de vie.
Action :
emailContacts
ouautoRenew
.Type de validation des certificats : validation par l’organisation (OV-SSL, Organization Validated-Secure Socket Layer) et validation étendue (EV-SSL, Extended Validation-Secure Socket Layer) pour les émetteurs DigiCert et GlobalSign.
Paramètres de l’émetteur de certificat à utiliser pour l’émission des certificats X.509.
Attributs associés à la stratégie.
Mappage de l’utilisation de X.509 avec les opérations des clés
Le tableau suivant représente le mappage des stratégies d’utilisation de clés X.509 avec les opérations de clés effectives d’une clé qui est créée au moment de la création d’un certificat Key Vault.
Indicateurs d’utilisation de la clé X.509 | Opérations sur les clés Key Vault | Comportement par défaut |
---|---|---|
DataEncipherment | encrypt, decrypt | Non applicable |
DecipherOnly | decrypt | Non applicable |
DigitalSignature | sign, verify | Valeur par défaut de Key Vault sans spécification de l’utilisation au moment de la création du certificat |
EncipherOnly | encrypt | Non applicable |
KeyCertSign | sign, verify | Non applicable |
KeyEncipherment | wrapKey, unwrapKey | Valeur par défaut de Key Vault sans spécification de l’utilisation au moment de la création du certificat |
NonRepudiation | sign, verify | Non applicable |
crlsign | sign, verify | Non applicable |
Émetteur de certificat
Un objet certificat Key Vault a une configuration qui lui permet de communiquer avec un fournisseur émetteur de certificat sélectionné pour demander des certificats X.509.
Key Vault travaille en collaboration avec les émetteurs de certificats suivants pour les certificats TLS/SSL.
Nom du fournisseur | Emplacements |
---|---|
DigiCert | Pris en charge dans tous les emplacements de service Key Vault dans le cloud public et Azure Government |
GlobalSign | Pris en charge dans tous les emplacements de service Key Vault dans le cloud public et Azure Government |
Pour qu’un émetteur de certificat puisse être créé dans un coffre de clés, un administrateur doit effectuer les étapes préalables suivantes :
- Intégrer l’organisation avec au moins un fournisseur d’autorité de certification.
- Créer les informations d’identification du demandeur pour Key Vault pour inscrire (et renouveler) les certificats TLS/SSL. Cette étape fournit la configuration permettant de créer un objet émetteur du fournisseur dans le coffre de clés.
Key Vault permet de créer plusieurs objets émetteurs avec des configurations de fournisseur émetteur différentes. Après qu’un objet émetteur a été créé, son nom peut être référencé dans une ou plusieurs stratégies de certificat. Le référencement de l’objet émetteur indique à Key Vault d’utiliser la configuration telle que spécifiée dans l’objet émetteur quand une demande de certificat X.509 est envoyée au fournisseur d’autorité de certification au moment de la création ou du renouvellement du certificat.
Les objets émetteurs sont créés dans le coffre. Ils peuvent uniquement être utilisés avec des certificats Key Vault qui se trouvent dans le même coffre.
Contacts du certificat
Les contacts de certificat contiennent des informations de contact utilisées pour l’envoi des notifications déclenchées par des événements de durée de vie de certificat. Tous les certificats dans le coffre de clés partagent les informations de contact.
Une notification est envoyée à tous les contacts spécifiés pour un événement pour n’importe quel certificat dans le coffre de clés.
Contrôle d’accès aux certificats
Key Vault gère le contrôle d'accès pour les certificats. Le coffre de clés qui contient ces certificats fournit le contrôle d’accès. La stratégie de contrôle d’accès pour les certificats est différente des stratégies de contrôle d’accès pour les clés et les secrets dans le même coffre de clés.
Les utilisateurs peuvent créer un ou plusieurs coffres pour y stocker les certificats afin de maintenir une segmentation et une gestion des certificats appropriées au scénario.
Cas d’usage des certificats
Sécuriser les communications et l’authentification
Les certificats TLS peuvent aider à chiffrer les communications sur Internet et à établir l’identité des sites web. Ce chiffrement sécurise le point d’entrée et le mode de communication. En outre, un certificat chaîné qui est signé par une autorité de certification publique peut aider à vérifier que les entités détenant les certificats sont légitimes.
À titre d’exemple, voici quelques cas d’usage de certificats pour sécuriser la communication et activer l’authentification :
- Sites web intranet/Internet : protégez l’accès à votre site intranet et assurez le transfert de données chiffré sur Internet au moyen de certificats TLS.
- Appareils IoT et réseau : protégez et sécurisez vos appareils à l’aide de certificats pour l’authentification et la communication.
- Cloud/multicloud : sécurisez les applications cloud locales, multicloud ou dans le locataire de votre fournisseur de cloud.
Signature de code
Un certificat peut aider à sécuriser le code/script du logiciel, afin de garantir que l’auteur peut partager le logiciel sur Internet sans risquer des interférences par des entités malveillantes. Une fois que l’auteur a signé le code avec un certificat et utilisé la technologie de signature du code, le logiciel est marqué d’un tampon d’authentification qui indique l’auteur et son site web. Le certificat utilisé dans la signature du code permet de vérifier l’authenticité du logiciel, et ainsi de renforcer la sécurité de bout en bout.