Planification de la structure d'une hiérarchie d'autorité de certification

La meilleure pratique consiste à planifier une hiérarchie d'autorités de certification qui corresponde à la structure de votre organisation. En général, vous pouvez mettre en œuvre l'une des structures d'AC suivantes.

Deux niveaux: AC racine et AC subordonné

Utilisez cette option si votre charge de travail requiert la structure AC la plus simple. Dans ce scénario, vous créez une seule autorité de certification racine sécurisée. Ensuite, vous créez une autorité de certification subordonnée, par exemple un AC intermédiaire, pour émettre des certificats leaf à vos applications et services.

Trois niveaux : Autorité de certification racine et deux autorités de certification subordonnées

Utilisez cette option si votre charge de travail nécessite une couche supplémentaire entre l'autorité de certification racine et les opérations de AC de niveau inférieur. Dans ce scénario, l'autorité de certification subordonnée intermédiaire n'est utilisée que pour signer les autorités de certification subordonnées qui délivrent des certificats de feuilles à vos applications.

Définition de la profondeur de votre hiérarchie de AC

Lorsque vous créez une autorité de certification dans Secrets Manager, vous pouvez définir le paramètre Longueur maximale du chemin pour déterminer le nombre de certificats de AC pouvant exister dans sa chaîne d'autorité. Cette valeur permet de déterminer le nombre de certificats de AC pouvant exister dans le chemin de certification de votre autorité de certification.

En règle générale, vous pouvez configurer une autorité de certification racine qui ne limite pas le nombre d'autorités de certification subordonnées qu'elle peut créer dans son chemin de certification. Toutefois, la définition d'une longueur de chemin maximale pour les autorités de certification subordonnées est une mesure de sécurité importante qui permet d'éviter les erreurs de configuration des autorités de certification. En fonction du positionnement d'une autorité de certification subordonnée dans votre hiérarchie, veillez à spécifier une longueur de chemin maximale pour que sa puissance de signature soit limitée à la profondeur voulue.

La longueur de chemin maximale que vous définissez n'inclut pas les certificats leaf. Dans l'exemple précédent, l'autorité de certification subordonnée de niveau 4 peut émettre des certificats de feuilles mais ne peut pas avoir d'autres certificats d'autorité de certification sur son chemin d'accès.

Choix d'une période de validité pour vos certificats

La période de validité d'un certificat X.509 est une zone obligatoire qui détermine combien de temps le certificat est approuvé et reste valide. Lorsque vous planifiez votre hiérarchie d'autorité de certification, travaillez à rebours à partir de votre durée de vie préférentielle pour les certificats leaf que vous souhaitez émettre dans vos applications. Ensuite, déterminez la période de validité des certificats de l'AC.

La période de validité d'un certificat doit être inférieure ou égale à la période de validité de l'autorité de certification qui l'a délivré. Par exemple, si vous créez une autorité de certification racine avec une durée de vie de 10 ans, toutes les autorités de certification intermédiaires qui lui sont subordonnées doivent avoir une durée de vie égale ou inférieure à 10 ans. De même, si une AC intermédiaire a une durée de vie de 3 ans, tout certificat leaf doit avoir une durée de vie égale ou inférieure à 3 ans.

1. Choisissez une période de validité pour vos certificats leaf qui convient à votre cas d'utilisation.

   Les certificats privés que vous pouvez créer avec Secrets Manager sont considérés comme des certificats leaf qui peuvent être émis vers une entité finale, telle qu'une application client ou serveur. Avec Secrets Manager, vous pouvez créer des certificats avec une durée de validité maximale de trois ans ou 36 mois. Après avoir déterminé un TTL ou une période de validité pour les certificats feuilles, vous définissez la valeur à l'aide d'un modèle de certificat de sorte que le TTL que vous avez choisi soit appliqué chaque fois qu'un nouveau certificat feuille est généré.

   Plus le TTL de vos certificats de feuilles est court, plus vous êtes protégé contre l'exposition involontaire ou la compromission de votre certificat et de sa clé privée. Une période de validité plus courte pour vos certificats signifie que vous réduisez la probabilité de compromis, mais vous devez également programmer une rotation plus fréquente du certificat pour vous assurer qu'il reste valide. Pour éviter une indisponibilité involontaire, vous pouvez planifier une rotation automatique de vos certificats privés.

2. Choisissez une période de validité pour l'autorité de certification subordonnée.

   La meilleure pratique consiste à définir une période de validité pour un certificat d'autorité de certification subordonnée qui soit sensiblement plus longue que les périodes de validité des certificats qu'elle émet. Définissez une période de validité d'une autorité de certification parent qui est de deux à cinq fois la période de tout certificat de AC enfant ou certificat leaf qu'elle émet. Par exemple, si vous disposez d'une hiérarchie de l'AC à deux niveaux et que vous souhaitez émettre des certificats leaf avec une durée de vie d'un an, configurez l'autorité de certification émettrice subordonnée avec une durée de vie de trois ans. Vous pouvez toujours mettre à jour les certificats de AC subordonnés sans remplacer le certificat de l'autorité de certification racine.

3. Choisissez une période de validité pour votre autorité de certification racine.

   Lorsque vous mettez à jour un certificat de l'autorité de certification racine, la modification a une incidence sur l'ensemble de l'infrastructure clé publique. Pour minimiser l'impact, il est recommandé de définir une période de validité longue pour votre certificat d'autorité de certification racine. Dans Secrets Manager, la durée de vie par défaut des certificats racine est de 10 ans.

Choisir un service de gestion de clés

Avant de créer une autorité de certification sur Secrets Manager, vous devez choisir un service de gestion de clés (KMS) pour générer les clés publiques et privées de votre autorité de certification. Vous pouvez choisir le moteur de certificat privé KMS interne, dans ce cas les clés publiques et privées de l'autorité de certification sont créées dans le logiciel et gérées en interne par le service. Vous pouvez également choisir de gérer vos clés dans un module de sécurité matériel (HSM) externe. Secrets Manager prend en charge IBM Cloud Hyper Protect Crypto Services (HPCS) pour la gestion des clés de l'autorité de certification. Vous pouvez configurer une autorité de certification pour qu'elle utilise les clés existantes dans une base de données privée HPCS ou autoriser Secrets Manager à créer de nouvelles clés pour l'autorité de certification.

Le moteur de certificats privés Secrets Manager utilise l'API PKCS#11 pour communiquer avec le système HPCS. L'authentification et l'autorisation sont effectuées à l'aide d'une clé API IAM qui est gérée à l'aide d'un Secrets Manager IAM credentials secret. Les opérations de signature cryptographique sont effectuées dans le système HPCS, la clé privée de l'autorité de certification ne quittant jamais le dispositif de cryptographie.

Note : Secrets Manager ne contrôle pas les coûts ou les limites de taux associés à la création de certificats CA avec des clés dans HPCS.

Choix d'un algorithme pour la génération des clés

Avant de créer une autorité de certification dans Secrets Manager, vous devez choisir un algorithme de clé pour générer les clés publiques et privées de votre autorité de certification. La paire de clés publique et privée est utilisée pour authentifier une connexion SSL/TLS. Si vous ne savez pas où commencer, vous pouvez utiliser le guide suggéré ci-dessous pour sélectionner un algorithme de clé.

1. Choisissez une famille d'algorithmes.

   L'algorithme de clé que vous sélectionnez détermine l'algorithme de chiffrement et la taille de clé à utiliser pour générer des clés et signer des certificats. En tant que meilleure pratique, utilisez la même famille d'algorithmes pour tous les certificats appartenant à une chaîne de certificats. Secrets Manager prend en charge les familles d'algorithmes suivantes.

   Familles d'algorithmes et tailles de clés prises en charge

   Famille d'algorithmes	Description	Tailles des clés prises en charge
   RSA	Largement utilisé et compatible avec la plupart des navigateurs et serveurs, RSA est la norme de l'industrie pour la cryptographie de clé publique.	2048 bits 4096 bits
   Courbe elliptique (EC)	Génère des clés plus fortes et des certificats plus petits. Par exemple, une clé EC de 256 bits équivaut, en termes de puissance de cryptage, à une clé RSA de 3072 bits.	224 bits 256 bits 384 bits 521 bits

2. Choisissez une taille de clé.

   La taille ou la longueur de clé que vous sélectionnez détermine la puissance de chiffrement. Plus la taille de la clé est large pour une famille d'algorithmes, plus elle est difficile à percer. Gardez à l'esprit que des longueurs clés plus longues donnent lieu à un plus grand nombre de données à stocker et à transmettre, ce qui peut avoir une incidence sur les performances de votre certificat. En tant que meilleure pratique, choisissez une taille de clé appropriée pour la durée de vie ou la durée de validité de votre certificat.

   Pour les certificats à durée de vie plus longue, il est recommandé d'utiliser des longueurs de clé plus importantes afin d'assurer une meilleure protection du cryptage.

Lire la liste de révocation de certificat

Ce point d'accès vous permet de récupérer la CRL actuelle sous forme brute DER-encodée. Si /pem est ajouté au point de terminaison, la LCR est renvoyée au format PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

Pour vérifier que vos certificats d'autorité de certification feuille ou intermédiaire ne sont pas révoqués à partir du contexte d'un certificat feuille, vous pouvez configurer votre autorité de certification avec la propriété "crl_distribution_points_encoded": true. Cette configuration codifie le site URL utilisé pour télécharger la CRL de l'autorité de certification émettrice dans la propriété X509v3 CRL Distribution Points de chaque certificat d'autorité de certification feuille ou intermédiaire. Ensuite, le valideur de l'autorité de certification peut vérifier si les certificats de l'autorité de certification feuille ou intermédiaire sont révoqués.

Lire le certificat d'autorité de certification

Ce point d'accès permet de récupérer le certificat de l'autorité de certification sous forme brute DER-encodée. Si /pem est ajouté au point de terminaison, le certificat de l'autorité de certification est renvoyé au format PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

Lire la chaîne de certificats CA

Ce point d'accès permet de récupérer la chaîne de certificats de l'autorité de certification, qui comprend l'autorité de certification au format PEM. Ce noeud final est vide. Elle ne renvoie pas de structure de données Vault standard et l'interface de ligne de commande Vault ne peut pas la lire.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

Pour vérifier que la chaîne d'autorité de certification provient du contexte d'un certificat de feuille, vous pouvez configurer vos autorités de certification dans Secrets Manager avec la propriété "issuing_certificates_urls_encoded": true. Dans chaque certificat d'autorité de certification feuille ou intermédiaire, cette configuration codifie le site URL utilisé pour télécharger le certificat de l'autorité de certification émettrice dans la propriété Authority Information Access/CA Issuers. Ensuite, votre valideur d'autorité de certification peut valider chaque certificat d'autorité de certification.