Sauvegarde d'une CA privée : archive chiffrée ou sauvegarde de clé HSM

La question qui décide de l'essentiel n'est pas comment vous chiffrez l'archive. C'est si votre clé privée de CA peut quitter son conteneur. Si la clé est un fichier, vous pouvez copier tout le répertoire CA dans un seul blob chiffré et en avoir fini en quelques minutes. Si elle vit dans un HSM ou un token qui marque la clé comme non extractible, cette copie n'existe pas, et votre plan devient un plan sur la procédure d'enveloppement et de restauration du fournisseur. Les deux modèles fonctionnent, ils échouent différemment, et la panne que vous pouvez survivre est celle autour de laquelle il vaut la peine de concevoir.

Où les deux modèles de sauvegarde se séparent

Le modèle A est la copie de répertoire. Une CA de style OpenSSL est un répertoire de travail, pas un certificat unique : ca.key ou cakey.pem, ca.crt, la base de données d'émission, les compteurs serial et crlnumber, et openssl.cnf. Scellez ce répertoire avec un chiffrement symétrique, déplacez le résultat vers un second support, et restaurer signifie décompresser, vérifier, signer. Tout ce dont l'émetteur a besoin voyage ensemble, y compris des semaines d'historique de révocation dont personne ne se souvient avoir écrit.

Le modèle B est le confinement de la clé. La clé est générée dans un module PKCS#11 et marquée non extractible ; le module peut l'envelopper pour la sauvegarde, mais aucun processus ne lit jamais les octets bruts. Votre sauvegarde est alors deux artefacts qui doivent être restaurés dans le bon ordre : un blob de clé enveloppée que seule cette famille de modules peut déballer, plus une copie simple de la base de données, de la configuration et des certificats.

La comparaison ne porte jamais sur le modèle le plus fort dans l'abstrait. Elle porte sur celui que votre équipe peut restaurer à 2 heures du matin avec les personnes réellement éveillées. Une archive que personne ne peut déchiffrer et un blob HSM que personne n'a testé sont également inutiles. La différence, c'est que la panne de l'archive apparaît dans un gestionnaire de mots de passe, et la panne du HSM se cache dans un contrat de support.

Ce que toute sauvegarde de CA doit contenir

Les deux modèles ont besoin du même ensemble d'enregistrements. Dans une CA OpenSSL, ces fichiers sont index.txt avec une ligne par certificat émis couvrant statut, expiration, serial et sujet, puis index.txt.attr, serial qui détient le prochain numéro de série à émettre, crlnumber qui détient le prochain numéro de CRL, et openssl.cnf avec le dir, la policy et les default_days avec lesquels votre CA fonctionne réellement. Le manuel openssl-ca explique ce que contrôle chacun de ces compteurs. easy-rsa conserve les mêmes données sous pki/, avec un fichier vars qui décide des champs du certificat.

La clé et le certificat sont les parties que vous ne pouvez pas reconstruire. La base de données est la partie que vous ne pouvez pas reconstruire de mémoire. Sauter index.txt vous laisse encore capable de signer de nouveaux certificats, et c'est exactement le piège : vous découvrez qu'il manque la première fois qu'un client demande si un certificat a été révoqué. Enregistrez l'empreinte de la CA en dehors de la sauvegarde, pour qu'une restauration soit comparée à une valeur à laquelle vous faites confiance et non au fichier que vous venez de restaurer.

openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pem

Des tests de restauration qui ne dédoublent pas l'émetteur

Deux CA actives avec le même sujet et la même clé paraissent identiques à tout client qui fait confiance à l'originale. Deux CRL portant le même numéro mais un contenu différent, c'est ainsi que les clients acceptent silencieusement un certificat que vous avez révoqué. Exécutez la restauration sur un hôte sans route vers vos clients, ou dans une VM jetable, et ne publiez jamais la CRL que le test produit.

Un test qui prouve seulement que l'archive s'ouvre ne prouve rien sur l'émission. La séquence qui compte : comparez l'empreinte du ca.crt restauré avec la valeur que vous avez enregistrée, confirmez que le serial correspond à ce qu'implique votre dernier certificat émis, émettez un certificat pour un CN jetable et regardez index.txt gagner une ligne, puis révoquez ce certificat et régénérez la CRL.

openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate

Avec un HSM, le même test passe par le module. Déballez le blob dans l'appareil de remplacement, confirmez que le certificat de CA rapporté par le module correspond à votre empreinte enregistrée, et seulement alors laissez-le signer. Si le module a son propre magasin d'objets, l'enveloppement doit couvrir l'objet clé et son étiquette, car restaurer la clé sous une autre étiquette casse la configuration qui pointe vers elle.

Des modes de défaillance qui décident du choix

Cinq défaillances expliquent la plupart des pertes réelles. Une phrase secrète d'archive oubliée sans copie indépendante du secret transforme l'archive en brique. Une copie unique sur un disque meurt avec ce disque, et une somme de contrôle ne vous dit jamais si le déchiffrement fonctionne encore. Les certificats révoqués après la date de sauvegarde redeviennent valides après une restauration, donc votre intervalle de sauvegarde est aussi votre angle mort de révocation. Restaurer un compteur de serial plus ancien réutilise des numéros de série et brouille les caches et les recherches de CRL indexées sur le serial. Un HSM de remplacement qui refuse le blob enveloppé transforme un changement de matériel en réémission complète.

Le modèle A gère mal les quatre premiers, mais de façon visible. Le modèle B les gère bien jusqu'à ce que le module ou le processus du fournisseur échoue. Si vos clés sont exportables et que l'équipe est petite, l'archive chiffrée est le choix honnête, appuyé par deux supports et une procédure écrite de phrase secrète. Si la clé n'est pas extractible, vous n'avez aucun choix, et le travail se déplace vers la preuve du chemin de restauration du fournisseur avant le jour où vous en aurez besoin.

Choisir le modèle et le planifier

Trois conditions tranchent. La clé peut-elle être exportée sans processus du fournisseur ? Une restauration doit-elle atterrir sur du matériel que vous ne possédez pas déjà ? Combien de temps l'émission peut-elle s'arrêter pendant que vous discutez avec le support ? Répondez à ces trois questions et le modèle est décidé ; tout le reste est de la planification.

Faites une sauvegarde après chaque cérémonie de signature et avant tout changement de configuration, car la configuration fait partie de l'état. Gardez deux copies sur des supports différents à des endroits différents, l'une hors ligne, et conservez le secret de déchiffrement dans un domaine de confiance différent de celui des copies. Écrivez la date de la dernière restauration réussie sur l'enregistrement de sauvegarde. Une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas un contrôle.

Avant de fermer le ticket, confirmez ces cinq points :

• L'empreinte du ca.crt est enregistrée quelque part en dehors de la sauvegarde.
• index.txt, serial, crlnumber et openssl.cnf sont tous dans l'archive ou dans le jeu de blobs.
• La garde de la phrase secrète ou de la clé enveloppée est documentée et confiée à quelqu'un d'autre que le propriétaire de l'archive.
• Une restauration a été testée sur un hôte isolé avec une émission et une révocation.
• L'écart de révocation qu'implique votre intervalle de sauvegarde est accepté par écrit ou raccourci.