Sikkerhedskopi af privat CA: krypteret arkiv kontra HSM-nøglebackup

Spørgsmålet, der afgør det meste af dette, er ikke, hvordan du krypterer arkivet. Det er, om din private CA-nøgle overhovedet kan forlade sin container. Hvis nøglen er en fil, kan du kopiere hele CA-mappen til én krypteret blob og være færdig på minutter. Hvis den bor i en HSM eller et token, der markerer nøglen som ikke-eksporterbar, findes den kopi ikke, og din plan bliver en plan om leverandørens indpaknings- og gendannelsesprocedure. Begge modeller virker, de fejler forskelligt, og det svigt, du kan overleve, er det, der er værd at designe omkring.

Hvor de to backupmodeller skilles

Model A er mappekopiering. En CA i OpenSSL-stil er en arbejdsmappe, ikke ét certifikat: ca.key eller cakey.pem, ca.crt, udstedelsesdatabasen, serial- og crlnumber-tællerne og openssl.cnf. Forsegl den mappe med en symmetrisk cipher, flyt resultatet til et andet medie, og gendannelse betyder udpak, verificer, signer. Alt, hvad udstederen har brug for, rejser sammen, inklusive ugers tilbagekaldelseshistorik, som ingen husker at have skrevet.

Model B er nøgleindeslutning. Nøglen genereres inde i et PKCS#11-modul og markeres som ikke-eksporterbar; modulet kan pakke den ind til backup, men ingen proces læser nogensinde de rå bytes. Din backup er så to artefakter, der skal gendannes i den rigtige rækkefølge: en indpakket nøgleblob, som kun den modulfamilie kan pakke ud, plus en almindelig kopi af databasen, konfigurationen og certifikaterne.

Sammenligningen handler aldrig om, hvilken model der er stærkest i abstrakt forstand. Den handler om, hvilken din team kan gendanne klokken 2 om natten med de mennesker, der faktisk er vågne. Et arkiv, ingen kan dekryptere, og en HSM-blob, ingen har testet, er lige ubrugelige. Forskellen er, at arkivfejlen dukker op i en password manager, og HSM-fejlen gemmer sig i en supportkontrakt.

Hvad enhver CA-backup skal indeholde

Begge modeller har brug for det samme sæt poster. I en OpenSSL-CA er disse filer index.txt med én række per udstedt certifikat, der dækker status, udløb, serienummer og emne, derefter index.txt.attr, serial der holder det næste serienummer til udstedelse, crlnumber der holder det næste CRL-nummer, og openssl.cnf med den dir, policy og default_days, som din CA faktisk kører med. openssl-ca-manualen forklarer, hvad hver af disse tællere styrer. easy-rsa holder de samme data under pki/, hvor en vars-fil bestemmer certifikatfelterne.

Nøglen og certifikatet er de dele, du ikke kan genopbygge. Databasen er den del, du ikke kan rekonstruere fra hukommelsen. At springe index.txt over efterlader dig stadig i stand til at signere nye certifikater, og det er præcis fælden: du opdager, at den mangler, første gang en klient spørger, om et certifikat blev tilbagekaldt. Registrer CA-fingeraftrykket uden for backuppen, så en gendannelse sammenlignes med en værdi, du stoler på, i stedet for med den fil, du lige har gendannet.

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

Gendannelsestests, der ikke forgrener udstederen

To levende CA'er med samme emne og samme nøgle ser identiske ud for enhver klient, der stoler på originalen. To CRL'er med samme nummer men forskelligt indhold er måden, hvorpå klienter stille accepterer et certifikat, du tilbagekaldte. Kør gendannelsen på en vært uden rute til dine klienter eller i en engangs-VM, og offentliggør aldrig den CRL, testen producerer.

En test, der kun beviser, at arkivet åbner, beviser intet om udstedelse. Den sekvens, der tæller: sammenlign fingeraftrykket på det gendannede ca.crt med den værdi, du registrerede, bekræft at serienummeret matcher det, dit sidst udstedte certifikat antyder, udsted ét certifikat til et engangs-CN, og se index.txt få en række, tilbagekald derefter det certifikat og generer CRL'en igen.

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

Med en HSM kører samme test gennem modulet. Pak blobben ud i erstatningsenheden, bekræft at det CA-certifikat, modulet rapporterer, matcher dit registrerede fingeraftryk, og lad den først derefter signere. Hvis modulet har sit eget objektlager, skal indpakningen dække nøgleobjektet og dets label, fordi gendannelse af nøglen under en anden label bryder den konfiguration, der peger på den.

Fejltyper, der afgør valget

Fem fejl forklarer de fleste reelle tab. En glemt arkivadgangsfrase uden en uafhængig kopi af hemmeligheden gør arkivet til en mursten. En enkelt kopi på én disk dør med den disk, og en kontrolsum fortæller aldrig, om dekryptering stadig virker. Certifikater tilbagekaldt efter backupdatoen ser gyldige ud igen efter en gendannelse, så dit backupinterval er også dit blinde punkt for tilbagekaldelser. Gendannelse af en ældre serietæller genbruger serienumre og forvirrer caches og CRL-opslag, der er nøglet på serienummer. En erstatnings-HSM, der afviser den indpakkede blob, gør en hardwareudskiftning til fuld genudstedelse.

Model A håndterer de første fire dårligt, men synligt. Model B håndterer dem godt lige indtil modulet eller leverandørprocessen fejler. Hvis dine nøgler er eksporterbare, og teamet er lille, er det krypterede arkiv det ærlige valg, bakket op af to medier og en skriftlig adgangsfraseprocedure. Hvis nøglen er ikke-eksporterbar, har du slet intet valg, og arbejdet flytter til at bevise leverandørens gendannelsesvej før den dag, du får brug for den.

Valg af model og planlægning

Tre betingelser afgør beslutningen. Kan nøglen eksporteres uden en leverandørproces? Skal en gendannelse lande på hardware, du ikke allerede ejer? Hvor længe kan udstedelse stoppes, mens du diskuterer med support? Svar på de tre, og modellen er besluttet; alt derefter er planlægning.

Tag en backup efter hver signeringsceremoni og før enhver konfigurationsændring, fordi konfigurationen er en del af tilstanden. Hold to kopier på forskellige medier på forskellige steder, en af dem offline, og hold dekrypteringshemmeligheden i et andet tillidsdomæne end kopierne. Skriv datoen for den sidste vellykkede gendannelse på backupregistret. En backup, der aldrig er gendannet, er en hypotese, ikke en kontrol.

Før du lukker sagen, bekræft disse fem punkter:

• Fingeraftrykket af ca.crt er registreret et sted uden for backuppen.
• index.txt, serial, crlnumber og openssl.cnf er alle inde i arkivet eller blobsættet.
• Opbevaringen af adgangsfrasen eller den indpakkede nøgle er dokumenteret og ligger hos en anden end arkivets ejer.
• En gendannelse blev testet på en isoleret vært med én udstedelse og én tilbagekaldelse.
• Tilbagekaldelsesgapet, som dit backupinterval antyder, er accepteret skriftligt eller forkortet.