Còpia de seguretat d'una CA privada: arxiu xifrat enfront de còpia de clau HSM

La pregunta que decideix la major part d'això no és com xifreu l'arxiu. És si la vostra clau privada de CA pot sortir del seu contenidor. Si la clau és un fitxer, podeu copiar tot el directori de CA en un sol blob xifrat i acabar en minuts. Si viu en un HSM o en un testimoni que marca la clau com a no extretable, aquesta còpia no existeix, i el vostre pla es converteix en un pla sobre el procediment d'embolcall i restauració del proveïdor. Els dos models funcionen, fallen de maneres diferents, i la fallada que podeu sobreviure és la que val la pena dissenyar al voltant.

On es separen els dos models de còpia de seguretat

El model A és la còpia de directori. Una CA a l'estil OpenSSL és un directori de treball, no un sol certificat: ca.key o cakey.pem, ca.crt, la base de dades d'emissió, els comptadors serial i crlnumber, i openssl.cnf. Segelleu aquest directori amb un xifrador simètric, moveu el resultat a un segon mitjà, i restaurar vol dir desempaquetar, verificar, signar. Tot el que l'emissor necessita viatja junt, incloent-hi setmanes d'historial de revocació que ningú recorda haver escrit.

El model B és la contenció de la clau. La clau es genera dins d'un mòdul PKCS#11 i es marca com a no extretable; el mòdul la pot embolcallar per a la còpia, però cap procés llegeix mai els bytes en brut. La vostra còpia és llavors dos artefactes que s'han de restaurar en l'ordre correcte: un blob de clau embolcallada que només aquella família de mòduls pot desembolcallar, més una còpia plana de la base de dades, la configuració i els certificats.

La comparació no va mai de quin model és més fort en abstracte. Va de quin pot restaurar el vostre equip a les 2 de la matinada amb les persones que realment estan despertes. Un arxiu que ningú pot desxifrar i un blob HSM que ningú ha provat són igualment inútils. La diferència és que la fallada de l'arxiu apareix en un gestor de contrasenyes, i la fallada de l'HSM s'amaga en un contracte de suport.

Què ha de contenir tota còpia de seguretat de CA

Els dos models necessiten el mateix conjunt de registres. En una CA OpenSSL aquests fitxers són index.txt amb una fila per certificat emès que cobreix estat, caducitat, serial i subjecte, després index.txt.attr, serial que guarda el següent serial a emetre, crlnumber que guarda el següent número de CRL, i openssl.cnf amb el dir, la policy i els default_days amb què la vostra CA realment funciona. El manual d'openssl-ca explica què controla cada un d'aquests comptadors. easy-rsa guarda les mateixes dades sota pki/, amb un fitxer vars que decideix els camps del certificat.

La clau i el certificat són les parts que no podeu reconstruir. La base de dades és la part que no podeu reconstruir de memòria. Saltar-vos index.txt encara us deixa signar certificats nous, i aquest és exactament el parany: descobriu que falta la primera vegada que un client pregunta si un certificat va ser revocat. Enregistreu l'empremta de la CA fora de la còpia, perquè una restauració es compari amb un valor en què confieu i no amb el fitxer que acabeu 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

Proves de restauració que no bifurquen l'emissor

Dues CA vives amb el mateix subjecte i la mateixa clau semblen idèntiques a tot client que confia en l'original. Dues CRL amb el mateix número però contingut diferent és com els clients accepten en silenci un certificat que heu revocat. Executeu la restauració en un amfitrió sense ruta als vostres clients, o en una VM d'un sol ús, i no publiqueu mai la CRL que produeix la prova.

Una prova que només demostra que l'arxiu s'obre no demostra res sobre l'emissió. La seqüència que compta: compareu l'empremta del ca.crt restaurat amb el valor que vau enregistrar, confirmeu que el serial coincideix amb el que implica el vostre darrer certificat emès, emeteu un certificat per a un CN d'un sol ús i observeu com index.txt guanya una fila, després revoqueu aquell certificat i regenereu la CRL.

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

Amb un HSM la mateixa prova passa pel mòdul. Desembolcalleu el blob al dispositiu de substitució, confirmeu que el certificat de CA que reporta el mòdul coincideix amb la vostra empremta enregistrada, i només llavors deixeu-lo signar. Si el mòdul té el seu propi magatzem d'objectes, l'embolcall ha de cobrir l'objecte de clau i la seva etiqueta, perquè restaurar la clau sota una etiqueta diferent trenca la configuració que hi apunta.

Maneres de fallar que decideixen l'elecció

Cinc fallades expliquen la majoria de pèrdues reals. Una contrasenya d'arxiu oblidada sense cap còpia independent del secret converteix l'arxiu en un maó. Una sola còpia en un disc mor amb aquell disc, i una suma de verificació no us diu mai si el desxifrat encara funciona. Els certificats revocats després de la data de la còpia tornen a semblar vàlids després d'una restauració, així que el vostre interval de còpia és també el vostre punt cec de revocació. Restaurar un comptador de serial més antic reutilitza números de sèrie i confon les memòries cau i les consultes de CRL indexades per serial. Un HSM de substitució que rebutja el blob embolcallat converteix un canvi de maquinari en una reemissió completa.

El model A gestiona les quatre primeres malament però de manera visible. El model B les gestiona bé fins que el mòdul o el procés del proveïdor fallen. Si les vostres claus són exportables i l'equip és petit, l'arxiu xifrat és l'elecció honesta, recolzada per dos mitjans i un procediment escrit de contrasenya. Si la clau no és extretable no teniu cap elecció, i la feina es desplaça a demostrar el camí de restauració del proveïdor abans del dia que el necessiteu.

Triar el model i programar-lo

Tres condicions resolen la decisió. Es pot exportar la clau sense un procés del proveïdor? Ha d'aterrar una restauració en maquinari que ja no teniu? Quant de temps pot aturar-se l'emissió mentre discutiu amb el suport? Responeu aquestes tres i el model queda decidit; tot després és planificació.

Feu una còpia després de cada cerimònia de signatura i abans de qualsevol canvi de configuració, perquè la configuració forma part de l'estat. Mantingueu dues còpies en mitjans diferents en llocs diferents, una fora de línia, i guardeu el secret de desxifrat en un domini de confiança diferent del de les còpies. Escriviu la data de l'última restauració correcta al registre de la còpia. Una còpia que mai s'ha restaurat és una hipòtesi, no un control.

Abans de tancar el tiquet, confirmeu aquests cinc punts:

• L'empremta del ca.crt està enregistrada en algun lloc fora de la còpia.
• index.txt, serial, crlnumber i openssl.cnf són tots dins de l'arxiu o del conjunt de blobs.
• La custòdia de la contrasenya o de la clau embolcallada està documentada i la té algú altre que el propietari de l'arxiu.
• S'ha provat una restauració en un amfitrió aïllat amb una emissió i una revocació.
• La bretxa de revocació que implica el vostre interval de còpia s'accepta per escrit o s'escurça.