Tryggingskopi av privat CA: kryptert arkiv eller HSM-nøkkelbackup

Spørsmålet som avgjer det meste av dette, er ikkje korleis du krypterer arkivet. Det er om din private CA-nøkkel i det heile kan forlate behaldaren sin. Viss nøkkelen er ei fil, kan du kopiere heile CA-katalogen til éin kryptert blob og vere ferdig på minutt. Viss han bur i ein HSM eller eit token som merkjer nøkkelen som ikkje-eksporterbar, finst ikkje den kopien, og planen din blir ein plan om innpaknings- og gjenopprettingsprosedyren til leverandøren. Begge modellane verkar, dei sviktar ulikt, og feilen du kan overleve, er den det er verdt å designe rundt.

Der dei to backupmodellane skil seg

Modell A er katalogkopi. Ei CA i OpenSSL-stil er ein arbeidskatalog, ikkje eitt sertifikat: ca.key eller cakey.pem, ca.crt, utstedingsdatabasen, serial- og crlnumber-teljarane og openssl.cnf. Forsegle den katalogen med ein symmetrisk chiffer, flytt resultatet til eit andre medium, og gjenoppretting tyder å pakke ut, verifisere, signere. Alt utstedaren treng, reiser saman, inkludert veker med tilbakekallingshistorikk som ingen hugsar å ha skrive.

Modell B er nøkkelinneslutning. Nøkkelen blir generert inne i ein PKCS#11-modul og merkt som ikkje-eksporterbar; modulen kan pakke han inn for backup, men ingen prosess les nokon gong dei rå byta. Tryggingskopien din er då to artefaktar som må gjenopprettast i rett rekkjefølgje: ein innpakka nøkkelblob som berre den modulfamilien kan pakke ut, pluss ein vanleg kopi av databasen, konfigurasjonen og sertifikata.

Samanlikninga handlar aldri om kva modell som er sterkast i abstrakt forstand. Ho handlar om kven teamet ditt kan gjenopprette klokka 2 om natta med menneska som faktisk er vakne. Eit arkiv ingen kan dekryptere, og ein HSM-blob ingen har testa, er like ubrukelege. Skilnaden er at arkivfeilen dukkar opp i ein passordhandsamar, og HSM-feilen gøymer seg i ein støttekontrakt.

Kva kvar CA-backup må innehalde

Begge modellane treng det same settet med postar. I ei OpenSSL-CA er desse filene index.txt med éi rad per utstedt sertifikat som dekkjer status, utløp, serial og subjekt, deretter index.txt.attr, serial som held neste serial som skal utstedast, crlnumber som held neste CRL-nummer, og openssl.cnf med den dir, policy og default_days som CA-en din faktisk køyrer med. openssl-ca-handboka forklarer kva kvar av desse teljarane styrer. easy-rsa held dei same dataa under pki/, med ei vars-fil som avgjer sertifikatfelta.

Nøkkelen og sertifikatet er delane du ikkje kan byggje på nytt. Databasen er delen du ikkje kan rekonstruere frå minnet. Å hoppe over index.txt lèt deg framleis signere nye sertifikat, og det er nettopp fella: du oppdagar at han manglar første gong ein klient spør om eit sertifikat vart tilbakekalla. Registrer fingeravtrykket til CA-en utanfor tryggingskopien, slik at ein gjenoppretting blir samanlikna med ein verdi du stolar på og ikkje med fila du nettopp gjenoppretta.

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

Gjenopprettingstestar som ikkje greinar ut utstedaren

To levande CA-ar med same subjekt og same nøkkel ser identiske ut for kvar klient som stolar på originalen. To CRL-ar med same nummer men ulikt innhald er måten klientar stille godtek eit sertifikat du tilbakekalla. Køyr gjenopprettinga på ein vert utan rute til klientane dine, eller i ein eingongs-VM, og publiser aldri CRL-en testen produserer.

Ein test som berre beviser at arkivet opnar, beviser ingenting om utsteding. Sekvensen som tel: samanlikn fingeravtrykket til den gjenoppretta ca.crt med verdien du registrerte, stadfest at serial stemmer med det ditt sist utstedte sertifikat tilseier, utsted eitt sertifikat for eit eingongs-CN og sjå index.txt få ei rad, tilbakekall deretter det sertifikatet og generer CRL-en på nytt.

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

Med ein HSM går same test gjennom modulen. Pakk ut bloben i erstatningseininga, stadfest at CA-sertifikatet modulen rapporterer svarar til ditt registrerte fingeravtrykk, og la han først deretter signere. Viss modulen har sitt eige objektlager, må innpakninga dekkje nøkkelobjektet og etiketten, fordi gjenoppretting av nøkkelen under ein annan etikett bryt konfigurasjonen som peikar på han.

Feilmodusar som avgjer valet

Fem feil forklarer dei fleste reelle tapa. Ein gløymd arkivpassfrase utan ein uavhengig kopi av løyndommen gjer arkivet til ein murstein. Éin kopi på éin disk døyr med den disken, og ein kontrollsum fortel deg aldri om dekrypteringa framleis verkar. Sertifikat tilbakekalla etter backupdatoen ser gyldige ut igjen etter ei gjenoppretting, så backupintervallet ditt er også den blinde flekken for tilbakekalling. Gjenoppretting av ein eldre serialteljar brukar serienummer på nytt og forvirrar cachear og CRL-oppslag nøkla på serial. Ein erstatnings-HSM som avviser den innpakka bloben, gjer ein maskinvarebyte til full utsteding på nytt.

Modell A handterer dei fire første dårleg, men synleg. Modell B handterer dei godt heilt til modulen eller leverandørprosessen sviktar. Viss nøklane dine er eksporterbare og teamet er lite, er det krypterte arkivet det ærlege valet, støtta av to medium og ein skriftleg passfraseprosedyre. Viss nøkkelen er ikkje-eksporterbar, har du ikkje noko val i det heile, og arbeidet flyttar seg til å bevise gjenopprettingsvegen til leverandøren før dagen du treng han.

Velje modellen og planleggje han

Tre vilkår avgjer avgjerda. Kan nøkkelen eksporterast utan ein leverandørprosess? Må ei gjenoppretting lande på maskinvare du ikkje alt eig? Kor lenge kan utstedinga stoppe medan du diskuterer med støtta? Svar på dei tre, og modellen er avgjord; alt etter det er planlegging.

Ta ein backup etter kvar signeringsseremoni og før kvar konfigurasjonsendring, fordi konfigurasjonen er ein del av tilstanden. Hald to kopiar på ulike medium på ulike stader, éin av dei offline, og hald dekrypteringsløyndommen i eit anna tillitsdomene enn kopiane. Skriv datoen for den siste vellukka gjenopprettinga på backupregisteret. Ein backup som aldri er gjenoppretta, er ein hypotese, ikkje ein kontroll.

Før du lukkar saka, stadfest desse fem punkta:

• Fingeravtrykket til ca.crt er registrert ein stad utanfor tryggingskopien.
• index.txt, serial, crlnumber og openssl.cnf er alle inne i arkivet eller blobsettet.
• Oppbevaringa av passfrasen eller den innpakka nøkkelen er dokumentert og halden av nokon andre enn eigaren av arkivet.
• Ei gjenoppretting vart testa på ein isolert vert med éi utsteding og éin tilbakekalling.
• Hòlet i tilbakekallinga som backupintervallet ditt tilseier, er skriftleg godteke eller forkorta.