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

Spørsmålet som avgjør det meste av dette, er ikke hvordan du krypterer arkivet. Det er om din private CA-nøkkel i det hele tatt kan forlate beholderen sin. Hvis nøkkelen er en fil, kan du kopiere hele CA-katalogen til én kryptert blob og være ferdig på minutter. Hvis den bor i en HSM eller et token som markerer nøkkelen som ikke-eksporterbar, finnes ikke den kopien, og planen din blir en plan om leverandørens innpaknings- og gjenopprettingsprosedyre. Begge modellene virker, de svikter ulikt, og feilen du kan overleve, er den det er verdt å designe rundt.

Der de to backupmodellene skilles

Modell A er katalogkopi. En CA i OpenSSL-stil er en arbeidskatalog, ikke ett sertifikat: ca.key eller cakey.pem, ca.crt, utstedelsesdatabasen, serial- og crlnumber-tellerne og openssl.cnf. Forsegle den katalogen med en symmetrisk chiffer, flytt resultatet til et andre medium, og gjenoppretting betyr å pakke ut, verifisere, signere. Alt utstederen trenger, reiser sammen, inkludert uker med tilbakekallingshistorikk som ingen husker å ha skrevet.

Modell B er nøkkelinneslutning. Nøkkelen genereres inne i en PKCS#11-modul og merkes som ikke-eksporterbar; modulen kan pakke den inn for backup, men ingen prosess leser noen gang de rå bytene. Backupen din er da to artefakter som må gjenopprettes i riktig rekkefølge: en innpakket nøkkelblob som bare den modulfamilien kan pakke ut, pluss en vanlig kopi av databasen, konfigurasjonen og sertifikatene.

Sammenligningen handler aldri om hvilken modell som er sterkest i abstrakt forstand. Den handler om hvilken teamet ditt kan gjenopprette klokken 2 om natten med menneskene som faktisk er våkne. Et arkiv ingen kan dekryptere, og en HSM-blob ingen har testet, er like ubrukelige. Forskjellen er at arkivfeilen dukker opp i en passordbehandler, og HSM-feilen gjemmer seg i en støttekontrakt.

Hva enhver CA-backup må inneholde

Begge modellene trenger det samme settet med poster. I en OpenSSL-CA er disse filene index.txt med én rad per utstedt sertifikat som dekker status, utløp, serial og subjekt, deretter index.txt.attr, serial som holder neste serial som skal utstedes, crlnumber som holder neste CRL-nummer, og openssl.cnf med den dir, policy og default_days som CA-en din faktisk kjører med. openssl-ca-håndboken forklarer hva hver av disse tellerne styrer. easy-rsa holder de samme dataene under pki/, med en vars-fil som bestemmer sertifikatfeltene.

Nøkkelen og sertifikatet er delene du ikke kan bygge på nytt. Databasen er delen du ikke kan rekonstruere fra hukommelsen. Å hoppe over index.txt lar deg fortsatt signere nye sertifikater, og det er nettopp fellen: du oppdager at den mangler første gang en klient spør om et sertifikat ble tilbakekalt. Registrer CA-ens fingeravtrykk utenfor backupen, slik at en gjenoppretting sammenlignes med en verdi du stoler på og ikke med filen du nettopp gjenopprettet.

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

Gjenopprettingstester som ikke forgrener utstederen

To levende CA-er med samme subjekt og samme nøkkel ser identiske ut for enhver klient som stoler på originalen. To CRL-er med samme nummer men ulikt innhold er måten klienter stille godtar et sertifikat du tilbakekalte. Kjør gjenopprettingen på en vert uten rute til klientene dine, eller i en engangs-VM, og publiser aldri CRL-en testen produserer.

En test som bare beviser at arkivet åpnes, beviser ingenting om utstedelse. Sekvensen som teller: sammenlign fingeravtrykket til den gjenopprettede ca.crt med verdien du registrerte, bekreft at serial stemmer med det ditt sist utstedte sertifikat tilsier, utsted ett sertifikat for et engangs-CN og se index.txt få en 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 en HSM går samme test gjennom modulen. Pakk ut bloben i erstatningsenheten, bekreft at CA-sertifikatet modulen rapporterer samsvarer med ditt registrerte fingeravtrykk, og la den først deretter signere. Hvis modulen har sitt eget objektlager, må innpakningen dekke nøkkelobjektet og etiketten, fordi gjenoppretting av nøkkelen under en annen etikett bryter konfigurasjonen som peker på den.

Feilmoduser som avgjør valget

Fem feil forklarer de fleste reelle tap. En glemt arkivpassfrase uten en uavhengig kopi av hemmeligheten gjør arkivet til en murstein. En enkelt kopi på én disk dør med den disken, og en kontrollsum forteller deg aldri om dekrypteringen fortsatt virker. Sertifikater tilbakekalt etter backupdatoen ser gyldige ut igjen etter en gjenoppretting, så backupintervallet ditt er også den blinde flekken for tilbakekalling. Gjenoppretting av en eldre serialteller bruker serienumre på nytt og forvirrer cacher og CRL-oppslag nøklet på serial. En erstatnings-HSM som avviser den innpakkede bloben, gjør en maskinvareutskifting til full utstedelse på nytt.

Modell A håndterer de fire første dårlig, men synlig. Modell B håndterer dem godt helt til modulen eller leverandørprosessen svikter. Hvis nøklene dine er eksporterbare og teamet er lite, er det krypterte arkivet det ærlige valget, støttet av to medier og en skriftlig passfraseprosedyre. Hvis nøkkelen er ikke-eksporterbar, har du ikke noe valg i det hele tatt, og arbeidet flyttes til å bevise leverandørens gjenopprettingsvei før dagen du trenger den.

Velge modellen og planlegge den

Tre betingelser avgjør beslutningen. Kan nøkkelen eksporteres uten en leverandørprosess? Må en gjenoppretting lande på maskinvare du ikke allerede eier? Hvor lenge kan utstedelsen stoppe mens du diskuterer med støtten? Svar på de tre, og modellen er bestemt; alt etter det er planlegging.

Ta en backup etter hver signeringsseremoni og før enhver konfigurasjonsendring, fordi konfigurasjonen er en del av tilstanden. Hold to kopier på ulike medier på ulike steder, én av dem offline, og hold dekrypteringshemmeligheten i et annet tillitsdomene enn kopiene. Skriv datoen for den siste vellykkede gjenopprettingen på backupregistret. En backup som aldri er gjenopprettet, er en hypotese, ikke en kontroll.

Før du lukker saken, bekreft disse fem punktene:

• Fingeravtrykket til ca.crt er registrert et sted utenfor backupen.
• index.txt, serial, crlnumber og openssl.cnf er alle inne i arkivet eller blobsettet.
• Oppbevaringen av passfrasen eller den innpakkede nøkkelen er dokumentert og holdes av noen andre enn arkivets eier.
• En gjenoppretting ble testet på en isolert vert med én utstedelse og én tilbakekalling.
• Hullet i tilbakekallingen som backupintervallet ditt antyder, er skriftlig akseptert eller forkortet.