Copie de siguranță a unei CA private: arhivă criptată versus copie a cheii HSM

Întrebarea care decide cea mai mare parte din asta nu este cum criptezi arhiva. Este dacă cheia ta privată CA poate părăsi deloc containerul ei. Dacă cheia este un fișier, poți copia întregul director CA într-un singur blob criptat și termina în câteva minute. Dacă locuiește într-un HSM sau într-un token care marchează cheia ca neextractibilă, acea copie nu există, iar planul tău devine un plan despre procedura de înfășurare și restaurare a furnizorului. Ambele modele funcționează, eșuează diferit, iar defecțiunea pe care o poți supraviețui este cea în jurul căreia merită să proiectezi.

Unde se despart cele două modele de copie

Modelul A este copia directorului. O CA în stil OpenSSL este un director de lucru, nu un singur certificat: ca.key sau cakey.pem, ca.crt, baza de date de emitere, contoarele serial și crlnumber, și openssl.cnf. Sigilează acel director cu un cifru simetric, mută rezultatul pe un al doilea mediu, iar restaurarea înseamnă despachetare, verificare, semnare. Tot ce are nevoie emitentul călătorește împreună, inclusiv săptămâni de istoric de revocare pe care nimeni nu-și amintește că l-a scris.

Modelul B este izolarea cheii. Cheia este generată în interiorul unui modul PKCS#11 și marcată ca neextractibilă; modulul o poate înfășura pentru copie, dar niciun proces nu citește vreodată octeții bruti. Copia ta este atunci două artefacte care trebuie restaurate în ordinea corectă: un blob de cheie înfășurată pe care doar acea familie de module îl poate deschide, plus o copie simplă a bazei de date, a configurației și a certificatelor.

Comparația nu este niciodată despre care model este mai puternic în abstract. Este despre care poate fi restaurat de echipa ta la ora 2 dimineața cu oamenii care sunt cu adevărat treji. O arhivă pe care nimeni nu o poate decripta și un blob HSM pe care nimeni nu l-a testat sunt la fel de inutile. Diferența este că defecțiunea arhivei apare într-un manager de parole, iar defecțiunea HSM se ascunde într-un contract de suport.

Ce trebuie să conțină fiecare copie de siguranță CA

Ambele modele au nevoie de același set de înregistrări. Într-o CA OpenSSL acele fișiere sunt index.txt cu o linie pentru fiecare certificat emis, acoperind starea, expirarea, serialul și subiectul, apoi index.txt.attr, serial care ține următorul serial de emis, crlnumber care ține următorul număr CRL, și openssl.cnf cu dir, policy și default_days cu care CA ta chiar rulează. Manualul openssl-ca explică ce controlează fiecare dintre acele contoare. easy-rsa păstrează aceleași date sub pki/, cu un fișier vars care decide câmpurile certificatului.

Cheia și certificatul sunt părțile pe care nu le poți reconstrui. Baza de date este partea pe care nu o poți reconstrui din memorie. Sărirea peste index.txt te lasă totuși să semnezi certificate noi, și exact aceasta este capcana: afli că lipsește prima dată când un client întreabă dacă un certificat a fost revocat. Înregistrează amprenta CA în afara copiei, ca o restaurare să fie comparată cu o valoare în care ai încredere, nu cu fișierul pe care tocmai l-ai restaurat.

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

Teste de restaurare care nu bifurcă emitentul

Două CA vii cu același subiect și aceeași cheie arată identic pentru fiecare client care are încredere în original. Două CRL cu același număr dar conținut diferit este modul în care clienții acceptă în liniște un certificat pe care l-ai revocat. Rulează restaurarea pe un host fără rută către clienții tăi, sau într-o VM de unică folosință, și nu publica niciodată CRL-ul pe care îl produce testul.

Un test care dovedește doar că arhiva se deschide nu dovedește nimic despre emitere. Secvența care contează: compară amprenta ca.crt restaurat cu valoarea pe care ai înregistrat-o, confirmă că serialul corespunde cu ce implică ultimul certificat emis, emite un certificat pentru un CN de unică folosință și urmărește cum index.txt câștigă o linie, apoi revocă acel certificat și regenerează CRL-ul.

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

Cu un HSM același test trece prin modul. Despachetează blobul în dispozitivul de înlocuire, confirmă că certificatul CA raportat de modul corespunde amprentei tale înregistrate, și abia apoi lasă-l să semneze. Dacă modulul are propriul depozit de obiecte, înfășurarea trebuie să acopere obiectul cheii și eticheta lui, pentru că restaurarea cheii sub altă etichetă strică configurația care indică spre ea.

Moduri de defecțiune care decid alegerea

Cinci defecțiuni explică majoritatea pierderilor reale. O frază de acces uitată, fără o copie independentă a secretului, transformă arhiva într-o cărămidă. O singură copie pe un disc moare cu acel disc, iar o sumă de control nu-ți spune niciodată dacă decriptarea încă funcționează. Certificatele revocate după data copiei arată din nou valide după o restaurare, așa că intervalul copiei este și punctul tău orb de revocare. Restaurarea unui contor serial mai vechi refolosește numere de serie și încurcă cache-urile și căutările CRL legate de serial. Un HSM de înlocuire care refuză blobul înfășurat transformă o schimbare de hardware într-o reemitere completă.

Modelul A se descurcă prost, dar vizibil, cu primele patru. Modelul B se descurcă bine cu ele până când modulul sau procesul furnizorului eșuează. Dacă cheile tale sunt exportabile și echipa este mică, arhiva criptată este alegerea onestă, susținută de două medii și o procedură scrisă a frazei de acces. Dacă cheia este neextractibilă nu ai nicio alegere, iar munca se mută pe dovedirea căii de restaurare a furnizorului înainte de ziua în care ai nevoie de ea.

Alegerea modelului și programarea lui

Trei condiții rezolvă decizia. Poate cheia fi exportată fără un proces al furnizorului? Trebuie o restaurare să ajungă pe hardware pe care încă nu îl deții? Cât timp poate sta emiterea în timp ce te cerți cu suportul? Răspunde la aceste trei și modelul este decis; tot restul este programare.

Fă o copie după fiecare ceremonie de semnare și înainte de orice schimbare de configurație, pentru că configurația face parte din stare. Ține două copii pe medii diferite în locuri diferite, una dintre ele offline, și ține secretul de decriptare într-un domeniu de încredere diferit de al copiilor. Scrie data ultimei restaurări reușite pe înregistrarea copiei. O copie care nu a fost niciodată restaurată este o ipoteză, nu un control.

Înainte să închizi tichetul, confirmă aceste cinci puncte:

• Amprenta ca.crt este înregistrată undeva în afara copiei.
• index.txt, serial, crlnumber și openssl.cnf sunt toate în arhivă sau în setul de bloburi.
• Păstrarea frazei de acces sau a cheii înfășurate este documentată și este la altcineva decât proprietarul arhivei.
• O restaurare a fost testată pe un host izolat cu o emitere și o revocare.
• Golul de revocare implicat de intervalul copiei este acceptat în scris sau scurtat.