Copia de seguridad de una CA privada: archivo cifrado frente a copia de clave HSM

La pregunta que decide la mayor parte de esto no es cómo cifra el archivo. Es si su clave privada de CA puede salir de su contenedor. Si la clave es un archivo, puede copiar todo el directorio de CA en un solo blob cifrado y terminar en minutos. Si vive en un HSM o en un token que marca la clave como no extraíble, esa copia no existe, y su plan se convierte en un plan sobre el procedimiento de envoltura y restauración del proveedor. Ambos modelos funcionan, fallan de forma distinta, y el fallo que puede sobrevivir es el que merece la pena diseñar.

Dónde se separan los dos modelos de copia

El modelo A es copia de directorio. Una CA al estilo OpenSSL es un directorio de trabajo, no un solo certificado: ca.key o cakey.pem, ca.crt, la base de datos de emisión, los contadores serial y crlnumber, y openssl.cnf. Selle ese directorio con un cifrado simétrico, mueva el resultado a un segundo medio, y restaurar significa desempaquetar, verificar, firmar. Todo lo que el emisor necesita viaja junto, incluidas semanas de historial de revocación que nadie recuerda haber escrito.

El modelo B es contención de la clave. La clave se genera dentro de un módulo PKCS#11 y se marca como no extraíble; el módulo puede envolverla para la copia, pero ningún proceso lee nunca los bytes en bruto. Su copia es entonces dos artefactos que deben restaurarse en el orden correcto: un blob de clave envuelta que solo esa familia de módulos puede desenvolver, más una copia simple de la base de datos, la configuración y los certificados.

La comparación nunca trata de qué modelo es más fuerte en abstracto. Trata de cuál puede restaurar su equipo a las 2 de la madrugada con las personas que de verdad están despiertas. Un archivo que nadie puede descifrar y un blob de HSM que nadie ha probado son igual de inútiles. La diferencia es que el fallo del archivo aparece en un gestor de contraseñas, y el fallo del HSM se esconde en un contrato de soporte.

Qué debe contener toda copia de seguridad de CA

Ambos modelos necesitan el mismo conjunto de registros. En una CA OpenSSL esos archivos son index.txt con una fila por certificado emitido que cubre estado, caducidad, serial y sujeto, luego index.txt.attr, serial que guarda el siguiente serial a emitir, crlnumber que guarda el siguiente número de CRL, y openssl.cnf con el dir, la policy y los default_days con los que su CA realmente funciona. El manual de openssl-ca explica qué controla cada uno de esos contadores. easy-rsa guarda los mismos datos bajo pki/, con un archivo vars que decide los campos del certificado.

La clave y el certificado son las partes que no puede reconstruir. La base de datos es la parte que no puede reconstruir de memoria. Saltarse index.txt todavía le deja firmar certificados nuevos, y esa es exactamente la trampa: descubre que falta la primera vez que un cliente pregunta si se revocó un certificado. Registre la huella de la CA fuera de la copia, para que una restauración se compare con un valor en el que confía y no con el archivo que acaba de restaurar.

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

Pruebas de restauración que no bifurcan al emisor

Dos CA en vivo con el mismo sujeto y la misma clave parecen idénticas a todo cliente que confía en la original. Dos CRL con el mismo número pero contenido distinto es como los clientes aceptan en silencio un certificado que usted revocó. Ejecute la restauración en un host sin ruta a sus clientes, o en una VM desechable, y nunca publique la CRL que produce la prueba.

Una prueba que solo demuestra que el archivo se abre no demuestra nada sobre la emisión. La secuencia que cuenta: compare la huella del ca.crt restaurado con el valor que registró, confirme que el serial coincide con lo que implica su último certificado emitido, emita un certificado para un CN desechable y observe cómo index.txt gana una fila, luego revoque ese certificado y regenere la CRL.

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

Con un HSM la misma prueba pasa por el módulo. Desenvuelva el blob en el dispositivo de reemplazo, confirme que el certificado de CA que reporta el módulo coincide con su huella registrada, y solo entonces déjelo firmar. Si el módulo tiene su propio almacén de objetos, la envoltura debe cubrir el objeto de clave y su etiqueta, porque restaurar la clave con una etiqueta distinta rompe la configuración que apunta a ella.

Modos de fallo que deciden la elección

Cinco fallos explican la mayoría de las pérdidas reales. Una contraseña de archivo olvidada sin copia independiente del secreto convierte el archivo en un ladrillo. Una sola copia en un disco muere con ese disco, y una suma de comprobación nunca le dice si el descifrado sigue funcionando. Los certificados revocados después de la fecha de la copia vuelven a parecer válidos tras una restauración, así que su intervalo de copia es también su punto ciego de revocación. Restaurar un contador de serial antiguo reutiliza números de serie y confunde las cachés y las consultas de CRL indexadas por serial. Un HSM de reemplazo que rechaza el blob envuelto convierte un cambio de hardware en una reemisión completa.

El modelo A maneja mal los cuatro primeros, pero de forma visible. El modelo B los maneja bien hasta que falla el módulo o el proceso del proveedor. Si sus claves son exportables y el equipo es pequeño, el archivo cifrado es la elección honesta, respaldada por dos medios y un procedimiento escrito de contraseña. Si la clave no es extraíble no tiene ninguna elección, y el trabajo pasa a demostrar la ruta de restauración del proveedor antes del día en que la necesite.

Elegir el modelo y programarlo

Tres condiciones resuelven la decisión. ¿Se puede exportar la clave sin un proceso del proveedor? ¿Debe aterrizar una restauración en hardware que aún no posee? ¿Cuánto puede detenerse la emisión mientras discute con el soporte? Responda esas tres y el modelo queda decidido; todo lo demás es planificación.

Haga una copia después de cada ceremonia de firma y antes de cualquier cambio de configuración, porque la configuración es parte del estado. Mantenga dos copias en medios distintos en lugares distintos, una de ellas sin conexión, y guarde el secreto de descifrado en un dominio de confianza distinto al de las copias. Escriba la fecha de la última restauración correcta en el registro de la copia. Una copia que nunca se ha restaurado es una hipótesis, no un control.

Antes de cerrar el ticket, confirme estos cinco puntos:

• La huella del ca.crt está registrada en algún lugar fuera de la copia.
• index.txt, serial, crlnumber y openssl.cnf están todos dentro del archivo o del conjunto de blobs.
• La custodia de la contraseña o de la clave envuelta está documentada y la tiene alguien distinto del propietario del archivo.
• Se probó una restauración en un host aislado con una emisión y una revocación.
• La brecha de revocación que implica su intervalo de copia se acepta por escrito o se acorta.