Backup di una CA privata: archivio cifrato o backup della chiave HSM

La domanda che decide la maggior parte di questo non è come cifrate l'archivio. È se la vostra chiave privata CA può uscire dal suo contenitore. Se la chiave è un file, potete copiare l'intera directory CA in un unico blob cifrato ed essere finiti in pochi minuti. Se vive in un HSM o in un token che contrassegna la chiave come non estraibile, quella copia non esiste, e il vostro piano diventa un piano sulla procedura di incapsulamento e ripristino del fornitore. Entrambi i modelli funzionano, falliscono in modo diverso, e il guasto che potete sopravvivere è quello attorno a cui vale la pena progettare.

Dove i due modelli di backup si separano

Il modello A è la copia di directory. Una CA in stile OpenSSL è una directory di lavoro, non un singolo certificato: ca.key o cakey.pem, ca.crt, il database di emissione, i contatori serial e crlnumber, e openssl.cnf. Sigillate quella directory con un cifrario simmetrico, spostate il risultato su un secondo supporto, e ripristinare significa scompattare, verificare, firmare. Tutto ciò che serve all'emittente viaggia insieme, comprese settimane di cronologia di revoca che nessuno ricorda di aver scritto.

Il modello B è il contenimento della chiave. La chiave viene generata all'interno di un modulo PKCS#11 e contrassegnata come non estraibile; il modulo può incapsularla per il backup, ma nessun processo legge mai i byte grezzi. Il vostro backup è quindi due artefatti che devono essere ripristinati nell'ordine corretto: un blob di chiave incapsulata che solo quella famiglia di moduli può aprire, più una copia semplice del database, della configurazione e dei certificati.

Il confronto non riguarda mai quale modello sia più forte in astratto. Riguarda quale il vostro team può ripristinare alle 2 di notte con le persone che sono davvero sveglie. Un archivio che nessuno può decifrare e un blob HSM che nessuno ha testato sono ugualmente inutili. La differenza è che il guasto dell'archivio emerge in un gestore di password, e il guasto dell'HSM si nasconde in un contratto di supporto.

Cosa deve contenere ogni backup CA

Entrambi i modelli hanno bisogno dello stesso insieme di record. In una CA OpenSSL quei file sono index.txt con una riga per certificato emesso che copre stato, scadenza, serial e soggetto, poi index.txt.attr, serial che tiene il prossimo serial da emettere, crlnumber che tiene il prossimo numero CRL, e openssl.cnf con il dir, la policy e i default_days con cui la vostra CA funziona davvero. Il manuale openssl-ca spiega cosa controlla ciascuno di quei contatori. easy-rsa conserva gli stessi dati sotto pki/, con un file vars che decide i campi del certificato.

La chiave e il certificato sono le parti che non potete ricostruire. Il database è la parte che non potete ricostruire a memoria. Saltare index.txt vi lascia comunque in grado di firmare nuovi certificati, ed è esattamente la trappola: scoprite che manca la prima volta che un cliente chiede se un certificato è stato revocato. Registrate l'impronta della CA fuori dal backup, così un ripristino viene confrontato con un valore di cui vi fidate e non con il file appena ripristinato.

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

Test di ripristino che non duplicano l'emittente

Due CA attive con lo stesso soggetto e la stessa chiave sembrano identiche a ogni client che si fida dell'originale. Due CRL con lo stesso numero ma contenuto diverso è il modo in cui i client accettano in silenzio un certificato che avete revocato. Eseguite il ripristino su un host senza percorso verso i vostri client, o in una VM usa e getta, e non pubblicate mai la CRL prodotta dal test.

Un test che dimostra solo che l'archivio si apre non dimostra nulla sull'emissione. La sequenza che conta: confrontate l'impronta del ca.crt ripristinato con il valore registrato, confermate che il serial corrisponda a ciò che implica il vostro ultimo certificato emesso, emettete un certificato per un CN usa e getta e osservate index.txt guadagnare una riga, poi revocate quel certificato e rigenerate 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 lo stesso test passa attraverso il modulo. Aprite il blob nel dispositivo sostitutivo, confermate che il certificato CA riportato dal modulo corrisponda all'impronta registrata, e solo allora lasciatelo firmare. Se il modulo ha un proprio archivio oggetti, l'incapsulamento deve coprire l'oggetto chiave e la sua etichetta, perché ripristinare la chiave sotto un'etichetta diversa rompe la configurazione che punta a essa.

Modalità di guasto che decidono la scelta

Cinque guasti spiegano la maggior parte delle perdite reali. Una passphrase d'archivio dimenticata senza copia indipendente del segreto trasforma l'archivio in un mattone. Una singola copia su un disco muore con quel disco, e un checksum non vi dice mai se la decifratura funziona ancora. I certificati revocati dopo la data del backup sembrano di nuovo validi dopo un ripristino, quindi il vostro intervallo di backup è anche il vostro punto cieco di revoca. Ripristinare un contatore serial più vecchio riutilizza numeri seriali e confonde cache e ricerche CRL indicizzate sul serial. Un HSM sostitutivo che rifiuta il blob incapsulato trasforma una sostituzione hardware in una riemissione completa.

Il modello A gestisce male i primi quattro, ma in modo visibile. Il modello B li gestisce bene finché il modulo o il processo del fornitore non fallisce. Se le vostre chiavi sono esportabili e il team è piccolo, l'archivio cifrato è la scelta onesta, sostenuta da due supporti e da una procedura scritta della passphrase. Se la chiave non è estraibile non avete alcuna scelta, e il lavoro si sposta nel dimostrare il percorso di ripristino del fornitore prima del giorno in cui vi servirà.

Scegliere il modello e pianificarlo

Tre condizioni chiudono la decisione. La chiave può essere esportata senza un processo del fornitore? Un ripristino deve atterrare su hardware che non possedete già? Quanto può fermarsi l'emissione mentre discutete con il supporto? Rispondete a quelle tre e il modello è deciso; tutto il resto è pianificazione.

Fate un backup dopo ogni cerimonia di firma e prima di ogni modifica di configurazione, perché la configurazione fa parte dello stato. Tenete due copie su supporti diversi in luoghi diversi, una delle quali offline, e custodite il segreto di decifratura in un dominio di fiducia diverso da quello delle copie. Scrivete la data dell'ultimo ripristino riuscito sul record del backup. Un backup che non è mai stato ripristinato è un'ipotesi, non un controllo.

Prima di chiudere il ticket, confermate questi cinque punti:

• L'impronta del ca.crt è registrata da qualche parte fuori dal backup.
• index.txt, serial, crlnumber e openssl.cnf sono tutti dentro l'archivio o l'insieme di blob.
• La custodia della passphrase o della chiave incapsulata è documentata ed è in mano a qualcuno diverso dal proprietario dell'archivio.
• Un ripristino è stato testato su un host isolato con un'emissione e una revoca.
• La lacuna di revoca implicata dal vostro intervallo di backup è accettata per iscritto o accorciata.