Säkerhetskopiering av en privat CA: krypterat arkiv eller HSM-nyckelbackup

Frågan som avgör det mesta av detta är inte hur du krypterar arkivet. Det är om din privata CA-nyckel överhuvudtaget kan lämna sin container. Om nyckeln är en fil kan du kopiera hela CA-katalogen till en enda krypterad blob och vara klar på minuter. Om den bor i en HSM eller en token som markerar nyckeln som icke-exporterbar finns den kopian inte, och din plan blir en plan om leverantörens inlindnings- och återställningsprocedur. Båda modellerna fungerar, de misslyckas olika, och felet du kan överleva är det som det är värt att designa kring.

Där de två backupmodellerna skiljs åt

Modell A är katalogkopia. En CA i OpenSSL-stil är en arbetskatalog, inte ett enda certifikat: ca.key eller cakey.pem, ca.crt, utfärdandedatabasen, serial- och crlnumber-räknarna och openssl.cnf. Försegla den katalogen med ett symmetriskt chiffer, flytta resultatet till ett andra medium, och återställning betyder packa upp, verifiera, signera. Allt utställaren behöver reser tillsammans, inklusive veckor av återkallningshistorik som ingen minns att de skrev.

Modell B är nyckelinneslutning. Nyckeln genereras inuti en PKCS#11-modul och markeras som icke-exporterbar; modulen kan linda in den för backup, men ingen process läser någonsin de råa byten. Din backup är då två artefakter som måste återställas i rätt ordning: en inlindad nyckelblob som bara den modulfamiljen kan packa upp, plus en vanlig kopia av databasen, konfigurationen och certifikaten.

Jämförelsen handlar aldrig om vilken modell som är starkast i abstrakt mening. Den handlar om vilken ditt team kan återställa klockan 2 på natten med människorna som faktiskt är vakna. Ett arkiv som ingen kan dekryptera och en HSM-blob som ingen har testat är lika oanvändbara. Skillnaden är att arkivfelet dyker upp i en lösenordshanterare, och HSM-felet gömmer sig i ett supportavtal.

Vad varje CA-backup måste innehålla

Båda modellerna behöver samma postuppsättning. I en OpenSSL-CA är dessa filer index.txt med en rad per utfärdat certifikat som täcker status, utgång, serial och subjekt, sedan index.txt.attr, serial som håller nästa serial att utfärda, crlnumber som håller nästa CRL-nummer, och openssl.cnf med den dir, policy och default_days som din CA faktiskt körs med. openssl-ca-handboken förklarar vad var och en av dessa räknare styr. easy-rsa håller samma data under pki/, med en vars-fil som bestämmer certifikatfälten.

Nyckeln och certifikatet är de delar du inte kan bygga om. Databasen är den del du inte kan rekonstruera ur minnet. Att hoppa över index.txt låter dig fortfarande signera nya certifikat, och det är just fällan: du upptäcker att den saknas första gången en klient frågar om ett certifikat har återkallats. Registrera CA:ns fingeravtryck utanför backupen, så att en återställning jämförs med ett värde du litar på och inte med filen du just återställde.

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

Återställningstester som inte förgrenar utställaren

Två levande CA:er med samma subjekt och samma nyckel ser identiska ut för varje klient som litar på originalet. Två CRL:er med samma nummer men olika innehåll är hur klienter tyst accepterar ett certifikat du återkallade. Kör återställningen på en värd utan väg till dina klienter, eller i en engångs-VM, och publicera aldrig den CRL som testet producerar.

Ett test som bara bevisar att arkivet öppnas bevisar ingenting om utfärdandet. Sekvensen som räknas: jämför fingeravtrycket på den återställda ca.crt med värdet du registrerade, bekräfta att serial stämmer med vad ditt senast utfärdade certifikat antyder, utfärda ett certifikat för ett engångs-CN och se index.txt få en rad, återkalla sedan det certifikatet och generera om CRL:en.

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 samma test genom modulen. Packa upp bloben i ersättningsenheten, bekräfta att det CA-certifikat modulen rapporterar motsvarar ditt registrerade fingeravtryck, och låt den först därefter signera. Om modulen har ett eget objektlager måste inlindningen täcka nyckelobjektet och dess etikett, eftersom återställning av nyckeln under en annan etikett bryter konfigurationen som pekar på den.

Fellägen som avgör valet

Fem fel förklarar de flesta verkliga förluster. En glömd arkivlösenfras utan en oberoende kopia av hemligheten gör arkivet till en tegelsten. En enda kopia på en disk dör med den disken, och en kontrollsumma berättar aldrig om dekrypteringen fortfarande fungerar. Certifikat som återkallats efter backupdatumet ser giltiga ut igen efter en återställning, så ditt backupintervall är också din blinda fläck för återkallning. Återställning av en äldre serialräknare återanvänder serienummer och förvirrar cachar och CRL-sökningar som nycklats på serial. En ersättnings-HSM som avvisar den inlindade bloben gör ett hårdvarubyte till fullständig nyutfärdning.

Modell A hanterar de fyra första dåligt men synligt. Modell B hanterar dem bra ända tills modulen eller leverantörsprocessen fallerar. Om dina nycklar är exporterbara och teamet är litet är det krypterade arkivet det ärliga valet, stött av två medier och en skriftlig lösenfrasprocedur. Om nyckeln är icke-exporterbar har du inget val alls, och arbetet flyttas till att bevisa leverantörens återställningsväg före den dag du behöver den.

Att välja modellen och planera den

Tre villkor avgör beslutet. Kan nyckeln exporteras utan en leverantörsprocess? Måste en återställning landa på hårdvara du inte redan äger? Hur länge kan utfärdandet stå stilla medan du diskuterar med supporten? Svara på de tre och modellen är avgjord; allt därefter är planering.

Ta en backup efter varje signeringsceremoni och före varje konfigurationsändring, eftersom konfigurationen är en del av tillståndet. Håll två kopior på olika medier på olika platser, en av dem offline, och håll dekrypteringshemligheten i en annan förtroendedomän än kopiorna. Skriv datumet för den senaste lyckade återställningen på backupregistret. En backup som aldrig har återställts är en hypotes, inte en kontroll.

Innan du stänger ärendet, bekräfta dessa fem punkter:

• Fingeravtrycket för ca.crt är registrerat någonstans utanför backupen.
• index.txt, serial, crlnumber och openssl.cnf finns alla i arkivet eller blobuppsättningen.
• Förvaringen av lösenfrasen eller den inlindade nyckeln är dokumenterad och innehas av någon annan än arkivets ägare.
• En återställning testades på en isolerad värd med en utfärdning och en återkallning.
• Luckan i återkallningen som ditt backupintervall antyder är skriftligen accepterad eller förkortad.