Copia de seguridade dunha CA privada: arquivo cifrado fronte a copia de clave HSM

A pregunta que decide a maior parte disto non é como cifra o arquivo. É se a súa clave privada de CA pode saír do seu contedor. Se a clave é un ficheiro, pode copiar todo o directorio de CA nun só blob cifrado e rematar en minutos. Se vive nun HSM ou nun token que marca a clave como non extraíble, esa copia non existe, e o seu plan convértese nun plan sobre o procedemento de envoltura e restauración do provedor. Ambos os modelos funcionan, fallan de forma distinta, e o fallo que pode sobrevivir é o que merece a pena deseñar.

Onde se separan os dous modelos de copia

O modelo A é copia de directorio. Unha CA ao estilo OpenSSL é un directorio de traballo, non un só certificado: ca.key ou cakey.pem, ca.crt, a base de datos de emisión, os contadores serial e crlnumber, e openssl.cnf. Selle ese directorio cun cifrado simétrico, mova o resultado a un segundo medio, e restaurar significa desempaquetar, verificar, asinar. Todo o que o emisor necesita viaxa xunto, incluídas semanas de historial de revocación que ninguén recorda ter escrito.

O modelo B é contención da clave. A clave xérase dentro dun módulo PKCS#11 e márcase como non extraíble; o módulo pode envolvela para a copia, pero ningún proceso le nunca os bytes en bruto. A súa copia é entón dous artefactos que deben restaurarse na orde correcta: un blob de clave envolta que só esa familia de módulos pode desembrulhar, máis unha copia simple da base de datos, a configuración e os certificados.

A comparación nunca trata de que modelo é máis forte en abstracto. Trata de cal pode restaurar o seu equipo ás 2 da madrugada coas persoas que de verdade están espertas. Un arquivo que ninguén pode descifrar e un blob de HSM que ninguén probou son igual de inútiles. A diferenza é que o fallo do arquivo aparece nun xestor de contrasinais, e o fallo do HSM agáchase nun contrato de soporte.

Que debe conter toda copia de seguridade de CA

Ambos os modelos necesitan o mesmo conxunto de rexistros. Nunha CA OpenSSL eses ficheiros son index.txt cunha fila por certificado emitido que cobre estado, caducidade, serial e suxeito, logo index.txt.attr, serial que garda o seguinte serial a emitir, crlnumber que garda o seguinte número de CRL, e openssl.cnf co dir, a policy e os default_days cos que a súa CA realmente funciona. O manual de openssl-ca explica que controla cada un deses contadores. easy-rsa garda os mesmos datos baixo pki/, cun ficheiro vars que decide os campos do certificado.

A clave e o certificado son as partes que non pode reconstruír. A base de datos é a parte que non pode reconstruír de memoria. Saltar index.txt aínda lle deixa asinar certificados novos, e esa é exactamente a trampa: descóbreo que falta a primeira vez que un cliente pregunta se se revogou un certificado. Rexistre a pegada da CA fóra da copia, para que unha restauración se compare cun valor no que confía e non co ficheiro 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

Probas de restauración que non bifurcan o emisor

Dúas CA en vivo co mesmo suxeito e a mesma clave parecen idénticas a todo cliente que confía na orixinal. Dúas CRL co mesmo número pero contido distinto é como os clientes aceptan en silencio un certificado que vostede revogou. Execute a restauración nun host sen ruta aos seus clientes, ou nunha VM desbotable, e nunca publique a CRL que produce a proba.

Unha proba que só demostra que o arquivo se abre non demostra nada sobre a emisión. A secuencia que conta: compare a pegada do ca.crt restaurado co valor que rexistrou, confirme que o serial coincide co que implica o seu último certificado emitido, emita un certificado para un CN desbotable e observe como index.txt gaña unha fila, logo revogue ese certificado e rexenere a CRL.

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

Cun HSM a mesma proba pasa polo módulo. Desenvolva o blob no dispositivo de substitución, confirme que o certificado de CA que reporta o módulo coincide coa súa pegada rexistrada, e só entón déixeo asinar. Se o módulo ten o seu propio almacén de obxectos, a envoltura debe cubrir o obxecto de clave e a súa etiqueta, porque restaurar a clave baixo outra etiqueta rompe a configuración que apunta a ela.

Modos de fallo que deciden a elección

Cinco fallos explican a maioría das perdas reais. Un contrasinal de arquivo esquecido sen copia independente do segredo converte o arquivo nun ladrillo. Unha soa copia nun disco morre con ese disco, e unha suma de comprobación nunca lle di se o descifrado segue funcionando. Os certificados revogados despois da data da copia volven parecer válidos tras unha restauración, así que o seu intervalo de copia é tamén o seu punto cego de revogación. Restaurar un contador de serial antigo reutiliza números de serie e confunde as cachés e as consultas de CRL indexadas por serial. Un HSM de substitución que rexeita o blob envolto converte un cambio de hardware nunha reemisión completa.

O modelo A manexa mal os catro primeiros, pero de forma visible. O modelo B manéxaos ben ata que falla o módulo ou o proceso do provedor. Se as súas claves son exportables e o equipo é pequeno, o arquivo cifrado é a elección honesta, respaldada por dous medios e un procedemento escrito de contrasinal. Se a clave non é extraíble non ten ningunha elección, e o traballo pasa a demostrar a ruta de restauración do provedor antes do día en que a necesite.

Elixir o modelo e programalo

Tres condicións resolven a decisión. Pódese exportar a clave sen un proceso do provedor? Debe aterrar unha restauración en hardware que aínda non posúe? Canto pode deterse a emisión mentres discute co soporte? Responda esas tres e o modelo queda decidido; todo o demais é planificación.

Faga unha copia despois de cada cerimonia de sinatura e antes de calquera cambio de configuración, porque a configuración forma parte do estado. Manteña dúas copias en medios distintos en lugares distintos, unha delas sen conexión, e garde o segredo de descifrado nun dominio de confianza distinto ao das copias. Escriba a data da última restauración correcta no rexistro da copia. Unha copia que nunca se restaurou é unha hipótese, non un control.

Antes de pechar o ticket, confirme estes cinco puntos:

• A pegada do ca.crt está rexistrada nalgún lugar fóra da copia.
• index.txt, serial, crlnumber e openssl.cnf están todos dentro do arquivo ou do conxunto de blobs.
• A custodia do contrasinal ou da clave envolta está documentada e tena alguén distinto do propietario do arquivo.
• Probouse unha restauración nun host illado cunha emisión e unha revogación.
• A fenda de revogación que implica o seu intervalo de copia acéptase por escrito ou acúrtase.