Záloha privátní CA: šifrovaný archiv versus záloha klíče v HSM

Otázka, která rozhoduje většinu tohoto, není, jak archiv šifrujete. Je to, zda váš privátní klíč CA může vůbec opustit svůj kontejner. Pokud je klíč soubor, můžete zkopírovat celý adresář CA do jednoho šifrovaného blobu a být hotovi během minut. Pokud žije v HSM nebo v tokenu, který klíč označí jako neexportovatelný, taková kopie neexistuje a váš plán se změní na plán o postupu zabalení a obnovení u dodavatele. Oba modely fungují, selhávají různě a porucha, kterou dokážete přežít, je ta, kvůli které se vyplatí navrhovat.

Kde se oba modely zálohy rozcházejí

Model A je kopie adresáře. CA ve stylu OpenSSL je pracovní adresář, ne jediný certifikát: ca.key nebo cakey.pem, ca.crt, databáze vydávání, čítače serial a crlnumber a openssl.cnf. Zapečeťte tento adresář symetrickou šifrou, přesuňte výsledek na druhé médium a obnovení znamená rozbalit, ověřit, podepsat. Vše, co vydavatel potřebuje, cestuje společně, včetně týdnů historie odvolání, o které si nikdo nepamatuje, že ji psal.

Model B je udržení klíče. Klíč se generuje uvnitř modulu PKCS#11 a označí se jako neexportovatelný; modul jej může zabalit pro zálohu, ale žádný proces nikdy nečte surové bajty. Vaše záloha je pak dva artefakty, které se musí obnovit ve správném pořadí: zabalený blob klíče, který dokáže rozbalit jen ta rodina modulů, plus obyčejná kopie databáze, konfigurace a certifikátů.

Srovnání nikdy není o tom, který model je silnější v abstraktu. Je o tom, který váš tým dokáže obnovit ve 2 ráno s lidmi, kteří skutečně bdí. Archiv, který nikdo nedokáže dešifrovat, a HSM blob, který nikdo netestoval, jsou stejně k ničemu. Rozdíl je v tom, že porucha archivu se objeví ve správci hesel a porucha HSM se skrývá ve smlouvě o podpoře.

Co musí každá záloha CA obsahovat

Oba modely potřebují stejnou sadu záznamů. V CA OpenSSL jsou těmito soubory index.txt s jedním řádkem na každý vydaný certifikát pokrývajícím stav, expiraci, sériové číslo a subjekt, poté index.txt.attr, serial držící další sériové číslo k vydání, crlnumber držící další číslo CRL a openssl.cnf s dir, policy a default_days, se kterými vaše CA skutečně běží. Manuál openssl-ca vysvětluje, co který z těchto čítačů řídí. easy-rsa drží stejná data pod pki/, přičemž soubor vars určuje pole certifikátu.

Klíč a certifikát jsou části, které nemůžete znovu postavit. Databáze je část, kterou nemůžete zrekonstruovat z paměti. Přeskočení index.txt vás stále nechá podepisovat nové certifikáty, a to je právě past: zjistíte, že chybí, poprvé, když se klient zeptá, zda byl certifikát odvolán. Zaznamenejte otisk CA mimo zálohu, aby se obnovení porovnávalo s hodnotou, které věříte, a ne se souborem, který jste právě obnovili.

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

Testy obnovení, které nevytvářejí druhého vydavatele

Dvě živé CA se stejným subjektem a stejným klíčem vypadají identicky pro každého klienta, který důvěřuje originálu. Dva CRL se stejným číslem, ale jiným obsahem jsou způsob, jakým klienti tiše přijmou certifikát, který jste odvolali. Spusťte obnovení na hostiteli bez trasy ke klientům nebo v jednorázovém VM a nikdy nezveřejňujte CRL, který test vytvoří.

Test, který dokazuje jen to, že se archiv otevře, nedokazuje nic o vydávání. Sekvence, na které záleží: porovnejte otisk obnoveného ca.crt se zaznamenanou hodnotou, potvrďte, že sériové číslo odpovídá tomu, co implikuje váš poslední vydaný certifikát, vystavte jeden certifikát pro jednorázový CN a sledujte, jak index.txt získá řádek, poté tento certifikát odvolejte a znovu vygenerujte CRL.

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

S HSM běží stejný test přes modul. Rozbalte blob do náhradního zařízení, potvrďte, že certifikát CA, který modul hlásí, odpovídá vašemu zaznamenanému otisku, a teprve potom mu dovolte podepisovat. Pokud má modul vlastní úložiště objektů, musí zabalení pokrýt objekt klíče a jeho označení, protože obnovení klíče pod jiným označením rozbije konfiguraci, která na něj ukazuje.

Režimy poruch, které rozhodují volbu

Pět poruch vysvětluje většinu skutečných ztrát. Zapomenuté heslo archivu bez nezávislé kopie tajemství promění archiv v cihlu. Jediná kopie na jednom disku umře s tím diskem a kontrolní součet vám nikdy neřekne, zda dešifrování stále funguje. Certifikáty odvolané po datu zálohy vypadají po obnovení znovu platné, takže interval zálohy je také vaše slepé místo odvolávání. Obnovení staršího čítače sériových čísel znovu použije sériová čísla a zmate cache a vyhledávání CRL klíčovaná podle sériového čísla. Náhradní HSM, který zabalený blob odmítne, promění výměnu hardwaru v plné nové vydání.

Model A zvládá první čtyři špatně, ale viditelně. Model B je zvládá dobře až do chvíle, kdy selže modul nebo proces dodavatele. Pokud jsou vaše klíče exportovatelné a tým je malý, šifrovaný archiv je poctivá volba, podložená dvěma médii a psaným postupem hesla. Pokud je klíč neexportovatelný, nemáte na výběr vůbec a práce se přesouvá k prokázání cesty obnovení u dodavatele dřív, než ji budete potřebovat.

Volba modelu a plánování

Tři podmínky rozhodují. Lze klíč exportovat bez procesu dodavatele? Musí obnovení přistát na hardwaru, který ještě nevlastníte? Jak dlouho může vydávání stát, zatímco se hádáte s podporou? Odpovězte na ty tři a model je rozhodnut; vše poté je plánování.

Pořiďte zálohu po každé podpisové ceremonii a před každou změnou konfigurace, protože konfigurace je součástí stavu. Držte dvě kopie na různých médiích na různých místech, jednu z nich offline, a tajemství dešifrování držte v jiné doméně důvěry než kopie. Napište datum posledního úspěšného obnovení na záznam zálohy. Záloha, která nebyla nikdy obnovena, je hypotéza, ne kontrola.

Než zavřete tiket, potvrďte těchto pět bodů:

• Otisk ca.crt je zaznamenán někde mimo zálohu.
• index.txt, serial, crlnumber a openssl.cnf jsou všechny uvnitř archivu nebo sady blobů.
• Úschova hesla nebo zabaleného klíče je zdokumentovaná a drží ji někdo jiný než vlastník archivu.
• Obnovení bylo otestováno na izolovaném hostiteli s jedním vydáním a jedním odvoláním.
• Mezera v odvolávání, kterou implikuje váš interval zálohy, je písemně přijata nebo zkrácena.