Backup ng pribadong CA: naka-encrypt na archive o HSM key backup

Ang tanong na nagpapasya sa karamihan nito ay hindi kung paano mo ini-encrypt ang archive. Ito ay kung makakaalis ba talaga ang pribadong key ng CA mo sa lalagyan nito. Kung ang key ay isang file, makokopya mo ang buong direktoryo ng CA sa isang naka-encrypt na blob at matatapos sa ilang minuto. Kung nakatira ito sa isang HSM o token na nagmamarka sa key bilang hindi maaaring ilabas, wala ang kopyang iyon, at ang plano mo ay nagiging plano tungkol sa pamamaraan ng pagbabalot at pagbabalik ng vendor. Gumagana ang dalawang modelo, nabigo sila nang iba, at ang pagkabigong matatagalan mo ang siyang sulit na idisenyo.

Saan naghihiwalay ang dalawang modelo ng backup

Ang modelo A ay kopya ng direktoryo. Ang CA sa istilong OpenSSL ay isang direktoryo ng trabaho, hindi isang sertipiko: ca.key o cakey.pem, ca.crt, ang database ng pag-isyu, ang mga counter na serial at crlnumber, at openssl.cnf. Isealed mo ang direktoryong iyon gamit ang simetriko sipher, ilipat ang resulta sa ikalawang midyum, at ang pagbabalik ay nangangahulugang magbukas, mag-verify, pumirma. Lahat ng kailangan ng nag-isyu ay naglalakbay nang sama-sama, kasama ang mga linggong kasaysayan ng pagbawi na walang nakaaalala na isinulat iyon.

Ang modelo B ay pagpigil sa key. Ang key ay nalilikha sa loob ng isang module ng PKCS#11 at minamarkahan bilang hindi maaaring ilabas; maaaring balutin ito ng module para sa backup, ngunit walang prosesong kailanman nagbabasa ng hilaw na byte. Ang backup mo ay dalawang artepaktong dapat ibalik sa tamang pagkakasunod-sunod: isang binalot na key blob na tanging ang pamilya ng module na iyon ang makakabukas, at isang ordinaryong kopya ng database, konfigurasyon at mga sertipiko.

Ang paghahambing ay hindi kailanman tungkol sa kung aling modelo ang mas malakas sa abstrakto. Ito ay tungkol sa kung alin ang kayang ibalik ng team mo sa alas-2 ng madaling-araw kasama ang mga taong talagang gising. Ang archive na walang makakadecrypt at ang HSM blob na walang nakasubok ay parehong walang silbi. Ang pagkakaiba ay lumilitaw ang pagkabigo ng archive sa isang password manager, at nagtatago ang pagkabigo ng HSM sa isang kontrata ng suporta.

Ano ang dapat taglayin ng bawat CA backup

Kailangan ng dalawang modelo ang parehong set ng rekord. Sa isang CA na OpenSSL, ang mga file na iyon ay index.txt na may isang hilera bawat naisyung sertipiko na sumasaklaw sa estado, pag-expire, serial at paksa, pagkatapos ay index.txt.attr, serial na nagtatago ng susunod na isyuhing serial, crlnumber na nagtatago ng susunod na numero ng CRL, at openssl.cnf na may dir, policy at default_days na aktwal na ginagamit ng CA mo. Ipinapaliwanag ng manual ng openssl-ca kung ano ang kinokontrol ng bawat isa sa mga counter na iyon. Itinatago ng easy-rsa ang parehong datos sa ilalim ng pki/, kung saan ang file na vars ang nagpapasya sa mga field ng sertipiko.

Ang key at sertipiko ang mga bahaging hindi mo maaaring buuin muli. Ang database ang bahaging hindi mo maaaring buuin muli mula sa alaala. Ang laktawan ang index.txt ay nag-iiwan pa rin sa iyong makapirma ng mga bagong sertipiko, at iyon mismo ang bitag: malalaman mo na kulang ito sa unang pagkakataong magtanong ang kliyente kung na-revoke ang isang sertipiko. Itala ang fingerprint ng CA sa labas ng backup, upang ang pagbabalik ay ihambing sa isang halagang pinagkakatiwalaan mo at hindi sa file na kababalik mo lang.

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

Mga pagsubok sa pagbabalik na hindi nagsasanga sa nag-isyu

Dalawang buhay na CA na may parehong paksa at parehong key ay magkamukha sa bawat kliyenteng nagtitiwala sa orihinal. Dalawang CRL na may parehong numero ngunit magkaibang nilalaman ang paraang tahimik na tinatanggap ng mga kliyente ang isang sertipikong ni-revoke mo. Patakbuhin ang pagbabalik sa isang host na walang ruta sa mga kliyente mo, o sa isang one-time na VM, at huwag kailanman i-publish ang CRL na ginagawa ng pagsubok.

Ang pagsubok na nagpapatunay lamang na bumubukas ang archive ay walang pinatutunayan tungkol sa pag-isyu. Ang tamang pagkakasunod-sunod: ihambing ang fingerprint ng naibalik na ca.crt sa halagang naitala mo, kumpirmahin na tumutugma ang serial sa ipinahihiwatig ng huling naisyung sertipiko mo, mag-isyu ng isang sertipiko para sa one-time na CN at panoorin ang index.txt na magkaroon ng hilera, pagkatapos ay i-revoke ang sertipikong iyon at muling likhain ang CRL.

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

Sa HSM dumadaan ang parehong pagsubok sa module. Buksan ang blob sa kapalit na device, kumpirmahin na tumutugma ang sertipiko ng CA na iniuulat ng module sa naitala mong fingerprint, at doon lamang hayaang pumirma. Kung ang module ay may sariling imbakan ng bagay, dapat saklawin ng pagbabalot ang bagay ng key at ang label nito, dahil ang pagbabalik ng key sa ilalim ng ibang label ay sumisira sa konfigurasyong tumuturo doon.

Mga mode ng pagkabigo na nagpapasya sa pagpili

Limang pagkabigo ang nagpapaliwanag sa karamihan ng tunay na pagkalugi. Ang nakalimutang passphrase ng archive na walang malayang kopya ng sikreto ay ginagawang ladrilyo ang archive. Ang isang kopya sa isang disk ay namamatay kasama ng disk na iyon, at hindi kailanman sinasabi ng checksum kung gumagana pa ang decryption. Ang mga sertipikong ni-revoke pagkatapos ng petsa ng backup ay mukhang valid muli pagkatapos ng pagbabalik, kaya ang interval ng backup mo rin ang bulag na bahagi ng pag-revoke. Ang pagbabalik ng lumang serial counter ay muling gumagamit ng serial number at ginugulo ang cache at paghahanap ng CRL na naka-key sa serial. Ang kapalit na HSM na tumatanggap ng binalot na blob ay nagpapalit ng hardware swap tungo sa buong muling pag-isyu.

Ang modelo A ay humaharap nang mahina ngunit nakikita sa unang apat. Ang modelo B ay humaharap nang maayos hanggang mabigo ang module o proseso ng vendor. Kung ang mga key mo ay maaaring i-export at maliit ang team, ang naka-encrypt na archive ang tapat na pagpipilian, na sinusuportahan ng dalawang midyum at nakasulat na pamamaraan ng passphrase. Kung ang key ay hindi maaaring ilabas wala kang anumang pagpipilian, at ang trabaho ay lumilipat sa pagpapatunay ng landas ng pagbabalik ng vendor bago ang araw na kakailanganin mo ito.

Pagpili ng modelo at pag-iskedyul

Tinatapos ng tatlong kondisyon ang desisyon. Maaari bang i-export ang key nang walang proseso ng vendor? Dapat bang lumapag ang pagbabalik sa hardware na wala ka pa? Gaano katagal makapaghintay ang pag-isyu habang nakikipagtalo ka sa suporta? Sagutin ang tatlong iyon at ang modelo ay napagpasyahan; lahat pagkatapos ay pagpaplano.

Kumuha ng backup pagkatapos ng bawat seremonya ng pagpirma at bago ang anumang pagbabago sa konfigurasyon, dahil bahagi ng estado ang konfigurasyon. Panatilihin ang dalawang kopya sa magkaibang midyum sa magkaibang lugar, ang isa ay offline, at itago ang sikreto ng decryption sa ibang domain ng pagtitiwala kaysa sa mga kopya. Isulat ang petsa ng huling matagumpay na pagbabalik sa rekord ng backup. Ang backup na hindi kailanman naibalik ay isang haypotesis, hindi kontrol.

Bago isara ang ticket, kumpirmahin ang limang puntong ito:

• Ang fingerprint ng ca.crt ay naitala sa isang lugar sa labas ng backup.
• index.txt, serial, crlnumber at openssl.cnf ay lahat nasa loob ng archive o set ng blob.
• Ang pangangalaga sa passphrase o sa binalot na key ay nakadokumento at hawak ng iba kaysa sa may-ari ng archive.
• Nasubok ang isang pagbabalik sa isang hiwalay na host na may isang pag-isyu at isang pag-revoke.
• Ang puwang sa pag-revoke na ipinahihiwatig ng interval ng backup mo ay tinanggap nang nakasulat o pinaikli.