Privātas CA dublējums: šifrēts arhīvs vai HSM atslēgas dublējums

Jautājums, kas nosaka lielāko daļu no šī, nav tas, kā jūs šifrējat arhīvu. Tas ir, vai jūsu CA privātā atslēga vispār var pamest savu konteineru. Ja atslēga ir fails, varat nokopēt visu CA direktoriju vienā šifrētā blobā un būt gatavs dažu minūšu laikā. Ja tā dzīvo HSM vai tokenā, kas atslēgu atzīmē kā neizvelkamu, šādas kopijas nav, un jūsu plāns pārvēršas par plānu par piegādātāja ietīšanas un atjaunošanas procedūru. Abi modeļi darbojas, tie sabojājas atšķirīgi, un kļūme, kuru varat pārdzīvot, ir tā, ap kuru ir vērts projektēt.

Kur abi dublēšanas modeļi atšķiras

Modelis A ir direktorijas kopija. OpenSSL stila CA ir darba direktorija, nevis viens sertifikāts: ca.key vai cakey.pem, ca.crt, izsniegšanas datubāze, serial un crlnumber skaitītāji un openssl.cnf. Aizzīmogojiet šo direktoriju ar simetrisku šifru, pārvietojiet rezultātu uz otru datu nesēju, un atjaunošana nozīmē izpakot, pārbaudīt, parakstīt. Viss, kas izsniedzējam vajadzīgs, ceļo kopā, tostarp nedēļām ilga atsaukšanas vēsture, kuru neviens neatceras esam rakstījis.

Modelis B ir atslēgas ieturēšana. Atslēga tiek ģenerēta PKCS#11 moduļa iekšienē un atzīmēta kā neizvelkama; modulis to var ietīt dublējumam, bet neviens process nekad nelasa neapstrādātos baitus. Jūsu dublējums tad ir divi artefakti, kas jāatjauno pareizajā secībā: ietīts atslēgas blobs, ko var atvērt tikai tā moduļu saime, plus vienkārša datubāzes, konfigurācijas un sertifikātu kopija.

Salīdzinājums nekad nav par to, kurš modelis ir stiprāks abstrakti. Tas ir par to, kuru jūsu komanda var atjaunot 2 naktī kopā ar cilvēkiem, kas patiešām ir nomodā. Arhīvs, kuru neviens nevar atšifrēt, un HSM blobs, kuru neviens nav pārbaudījis, ir vienlīdz bezjēdzīgi. Atšķirība ir tā, ka arhīva kļūme parādās paroļu pārvaldniekā, bet HSM kļūme slēpjas atbalsta līgumā.

Kas jābūt katrā CA dublējumā

Abiem modeļiem vajadzīgs tas pats ierakstu kopums. OpenSSL CA gadījumā tie faili ir index.txt ar vienu rindu katram izsniegtajam sertifikātam, aptverot statusu, derīgumu, serial un subjektu, tad index.txt.attr, serial, kurā tiek turēts nākamais izsniedzamais sērijas numurs, crlnumber, kurā tiek turēts nākamais CRL numurs, un openssl.cnf ar dir, policy un default_days, ar kuriem jūsu CA patiešām darbojas. openssl-ca rokasgrāmata izskaidro, ko kontrolē katrs no šiem skaitītājiem. easy-rsa glabā tos pašus datus zem pki/, un vars fails nosaka sertifikāta laukus.

Atslēga un sertifikāts ir daļas, ko nevarat pārbūvēt no jauna. Datubāze ir daļa, ko nevarat rekonstruēt no atmiņas. Izlaižot index.txt, jūs joprojām varat parakstīt jaunus sertifikātus, un tas ir tieši slazds: jūs uzzināsit, ka tā trūkst, pirmajā reizē, kad klients jautās, vai sertifikāts tika atsaukts. Ierakstiet CA pirksta nospiedumu ārpus dublējuma, lai atjaunošana tiktu salīdzināta ar vērtību, kurai uzticaties, nevis ar failu, kuru tikko atjaunojāt.

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

Atjaunošanas testi, kas nesazaro izsniedzēju

Divi darbojošies CA ar vienu un to pašu subjektu un vienu un to pašu atslēgu izskatās identiski ikvienam klientam, kas uzticas oriģinālam. Divi CRL ar vienu un to pašu numuru, bet atšķirīgu saturu ir veids, kā klienti klusi pieņem jūsu atsaukto sertifikātu. Palaidiet atjaunošanu uz resursdatora bez maršruta uz jūsu klientiem vai vienreizējā VM, un nekad nepublicējiet CRL, ko tests izveido.

Tests, kas pierāda tikai to, ka arhīvs atveras, neko nepierāda par izsniegšanu. Secība, kas svarīga: salīdziniet atjaunotā ca.crt pirksta nospiedumu ar ierakstīto vērtību, apstipriniet, ka serial atbilst tam, ko nozīmē jūsu pēdējais izsniegtais sertifikāts, izsniedziet vienu sertifikātu vienreizējam CN un vērojiet, kā index.txt iegūst rindu, pēc tam atsauciet šo sertifikātu un ģenerējiet CRL no jauna.

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

Ar HSM tas pats tests iet caur moduli. Izpakot blobu nomaiņas ierīcē, apstipriniet, ka moduļa ziņotais CA sertifikāts atbilst jūsu ierakstītajam pirksta nospiedumam, un tikai tad ļaujiet tam parakstīt. Ja modulim ir sava objektu krātuve, ietīšanai jāaptver atslēgas objekts un tā etiķete, jo atslēgas atjaunošana zem citas etiķetes salauž konfigurāciju, kas uz to norāda.

Kļūmju režīmi, kas nosaka izvēli

Piecas kļūmes izskaidro lielāko daļu reālo zaudējumu. Aizmirsta arhīva parole bez neatkarīgas noslēpuma kopijas pārvērš arhīvu ķieģelī. Viena kopija vienā diskā mirst kopā ar šo disku, un kontrolsumma nekad nepasaka, vai atšifrēšana vēl darbojas. Sertifikāti, kas atsaukti pēc dublējuma datuma, pēc atjaunošanas atkal izskatās derīgi, tāpēc jūsu dublēšanas intervāls ir arī jūsu atsaukšanas aklais punkts. Vecāka serial skaitītāja atjaunošana atkārtoti izmanto sērijas numurus un sajauc kešatmiņas un CRL meklēšanu, kas piesaistīta serial. Nomaiņas HSM, kas atsaka ietīto blobu, aparatūras nomaiņu pārvērš pilnīgā atkārtotā izsniegšanā.

Modelis A tiek galā ar pirmajām četrām slikti, bet redzami. Modelis B tiek galā ar tām labi, līdz sabojājas modulis vai piegādātāja process. Ja jūsu atslēgas ir eksportējamas un komanda ir maza, šifrētais arhīvs ir godīgā izvēle, ko atbalsta divi datu nesēji un rakstiska paroles procedūra. Ja atslēga ir neizvelkama, jums vispār nav izvēles, un darbs pārvietojas uz piegādātāja atjaunošanas ceļa pierādīšanu pirms dienas, kad tas būs vajadzīgs.

Modeļa izvēle un plānošana

Trīs nosacījumi izšķir lēmumu. Vai atslēgu var eksportēt bez piegādātāja procesa? Vai atjaunošanai jānokļūst aparatūrā, kuras jums vēl nav? Cik ilgi izsniegšana var apstāties, kamēr strīdaties ar atbalstu? Atbildiet uz šiem trim, un modelis ir izlemts; viss pēc tam ir plānošana.

Veiciet dublējumu pēc katras parakstīšanas ceremonijas un pirms jebkuras konfigurācijas izmaiņas, jo konfigurācija ir stāvokļa daļa. Turiet divas kopijas dažādos datu nesējos dažādās vietās, viena no tām bezsaistē, un turiet atšifrēšanas noslēpumu citā uzticības jomā nekā kopijas. Ierakstiet pēdējā veiksmīgā atjaunojuma datumu dublējuma ierakstā. Dublējums, kas nekad nav atjaunots, ir hipotēze, nevis kontrole.

Pirms biļetes aizvēršanas apstipriniet šos piecus punktus:

• ca.crt pirksta nospiedums ir ierakstīts kaut kur ārpus dublējuma.
• index.txt, serial, crlnumber un openssl.cnf visi ir arhīvā vai blobu kopumā.
• Paroles vai ietītās atslēgas glabāšana ir dokumentēta, un to tur kāds cits, nevis arhīva īpašnieks.
• Atjaunošana pārbaudīta izolētā resursdatorā ar vienu izsniegšanu un vienu atsaukšanu.
• Atsaukšanas plaisa, ko nosaka jūsu dublēšanas intervāls, ir rakstiski pieņemta vai saīsināta.