Sekurkopio de privata CA: ĉifrita arkivo kontraŭ HSM-ŝlosila sekurkopio
Ĉifrita arkivo aŭ HSM-envolvita ŝlosilo: kiel ĉiu VPN-CA-sekurkopia modelo restarigatas, kion ĝi devas enhavi, kaj kiun fiaskon vi efektive povas postvivi.
La demando, kiu decidas la plejparton de ĉi tio, ne estas kiel vi ĉifras la arkivon. Ĝi estas ĉu via privata CA-ŝlosilo povas entute forlasi sian ujon. Se la ŝlosilo estas dosiero, vi povas kopii la tutan CA-dosierujon en unu ĉifritan blob kaj fini en minutoj. Se ĝi loĝas en HSM aŭ ĵetono, kiu markas la ŝlosilon neeltirebla, tiu kopio ne ekzistas, kaj via plano fariĝas plano pri la envolva kaj restariga proceduro de la vendisto. Ambaŭ modeloj funkcias, ili fiaskas malsame, kaj la fiasko, kiun vi povas postvivi, estas tiu, ĉirkaŭ kiu indas dezajni.
Kie la du sekurkopiaj modeloj disiĝas
Modelo A estas dosieruja kopio. CA laŭ OpenSSL-stilo estas labordosierujo, ne unu certifikato: ca.key aŭ cakey.pem, ca.crt, la eldona datumbazo, la nombriloj serial kaj crlnumber, kaj openssl.cnf. Sigelu tiun dosierujon per simetria ĉifro, movu la rezulton al dua medio, kaj restarigo signifas malpaki, kontroli, subskribi. Ĉio, kion la eldoninto bezonas, vojaĝas kune, inkluzive semajnoj da revoka historio, kiun neniu memoras esti skribinta.
Modelo B estas ŝlosila retenado. La ŝlosilo estas generita ene de PKCS#11-modulo kaj markita kiel neeltirebla; la modulo povas envolvi ĝin por sekurkopio, sed neniu procezo iam legas la krudajn bajtojn. Via sekurkopio tiam estas du artefaktoj, kiuj devas esti restarigitaj en la ĝusta ordo: envolva ŝlosilblob, kiun nur tiu modulfamilio povas malvolvi, plus ordinara kopio de la datumbazo, agordo kaj certifikatoj.
| Attribute | Encrypted archive | HSM key backup |
|---|---|---|
| What you store | one encrypted file | wrapped blob plus CA records |
| Who can restore it | anyone holding the passphrase | holder of the module and the blob, often vendor support |
| If a copy leaks | attacker with the passphrase becomes the CA | blob is inert without the matching module |
| What usually breaks it | forgotten passphrase, one damaged copy | replacement module rejects the blob, contract gap |
La komparo neniam temas pri tio, kiu modelo estas pli forta en abstrakto. Ĝi temas pri tio, kiun via teamo povas restarigi je la 2-a matene kun la homoj, kiuj efektive estas maldormaj. Arkivo, kiun neniu povas malĉifri, kaj HSM-blob, kiun neniu testis, estas same senutilaj. La diferenco estas, ke la arkiva fiasko aperas en pasvorta administrilo, kaj la HSM-fiasko kaŝiĝas en subtena kontrakto.
Kion ĉiu CA-sekurkopio devas enhavi
Ambaŭ modeloj bezonas la saman rikordan aron. En OpenSSL-CA tiuj dosieroj estas index.txt kun unu vico por ĉiu eldonita certifikato kovranta staton, limdaton, serial kaj subjekton, poste index.txt.attr, serial tenanta la sekvan serialon eldonotan, crlnumber tenanta la sekvan CRL-numeron, kaj openssl.cnf kun la dir, policy kaj default_days, per kiuj via CA efektive funkcias. La openssl-ca-manlibro klarigas, kion ĉiu el tiuj nombriloj regas. easy-rsa tenas la samajn datumojn sub pki/, kun vars-dosiero decidanta la certifikatajn kampojn.
La ŝlosilo kaj certifikato estas la partoj, kiujn vi ne povas rekonstrui. La datumbazo estas la parto, kiun vi ne povas rekonstrui el memoro. Preterlasi index.txt lasas vin ankoraŭ povi subskribi novajn certifikatojn, kaj tio estas ĝuste la kaptilo: vi malkovras, ke ĝi mankas, la unuan fojon, kiam kliento demandas, ĉu certifikato estis revokita. Registru la CA-fingrospuron ekster la sekurkopio, por ke restarigo kompariĝu kun valoro, kiun vi fidas, prefere ol kun la dosiero, kiun vi ĵus restarigis.
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
Restarigaj testoj, kiuj ne disbranĉigas la eldoninton
Du vivantaj CA-oj kun la sama subjekto kaj la sama ŝlosilo aspektas identaj al ĉiu kliento, kiu fidas la originalon. Du CRL-oj portantaj la saman numeron sed malsamajn enhavojn estas kiel klientoj trankvile akceptas certifikaton, kiun vi revokis. Rulu la restarigon sur gastiganto sen itinero al viaj klientoj, aŭ en forĵetebla VM, kaj neniam publikigu la CRL-on, kiun la testo produktas.
Testo, kiu pruvas nur, ke la arkivo malfermiĝas, pruvas nenion pri eldonado. La sinsekvo, kiu gravas: komparu la fingrospuron de la restarigita ca.crt kun la valoro, kiun vi registris, konfirmu, ke la serialo kongruas kun tio, kion implicas via laste eldonita certifikato, eldonu unu certifikaton por forĵetebla CN kaj observu, ke index.txt gajnas vicon, poste revoku tiun certifikaton kaj regeneru la CRL-on.
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate
Kun HSM la sama testo iras tra la modulo. Malvolvu la blob-on en la anstataŭan aparaton, konfirmu, ke la CA-certifikato, kiun la modulo raportas, kongruas kun via registrita fingrospuro, kaj nur tiam lasu ĝin subskribi. Se la modulo havas sian propran objektan konservejon, la envolvo devas kovri la ŝlosilan objekton kaj ĝian etikedon, ĉar restarigi la ŝlosilon sub malsama etikedo rompas la agordon, kiu montras al ĝi.
Fiaskmanieroj, kiuj decidas la elekton
Kvin fiaskoj klarigas la plejmulton de realaj perdoj. Forgesita arkiva pasfrazo sen sendependa kopio de la sekreto faras la arkivon briko. Unu sola kopio sur unu disko mortas kun tiu disko, kaj kontrolsumo neniam diras al vi, ĉu malĉifrado ankoraŭ funkcias. Certifikatoj revokitaj post la sekurkopia dato denove aspektas validaj post restarigo, do via sekurkopia intervalo ankaŭ estas via revoka blindmakulo. Restarigi pli malnovan serian nombrilon reuzas seriajn numerojn kaj konfuzas kaŝmemorojn kaj CRL-serĉojn ŝlositajn laŭ serialo. Anstataŭa HSM, kiu rifuzas la envolvitan blob-on, igas aparatan anstataŭigon plena reeldonado.
Modelo A traktas la unuajn kvar malbone sed videble. Modelo B traktas ilin bone ĝis la modulo aŭ la vendista procezo fiaskas. Se viaj ŝlosiloj estas elporteblaj kaj la teamo estas malgranda, la ĉifrita arkivo estas la honesta elekto, apogita de du medioj kaj skriba pasfraza proceduro. Se la ŝlosilo estas neeltirebla, vi tute ne havas elekton, kaj la laboro moviĝas al pruvado de la vendista restariga vojo antaŭ la tago, kiam vi bezonos ĝin.
Elekti la modelon kaj plani ĝin
Tri kondiĉoj decidas la decidon. Ĉu la ŝlosilo povas esti elportita sen vendista procezo? Ĉu restarigo devas surteriĝi sur aparataron, kiun vi ankoraŭ ne posedas? Kiom longe eldonado povas halti, dum vi disputas kun subteno? Respondu tiujn tri kaj la modelo estas decidita; ĉio poste estas planado.
Prenu sekurkopion post ĉiu subskriba ceremonio kaj antaŭ ajna agorda ŝanĝo, ĉar la agordo estas parto de la stato. Tenu du kopiojn sur malsamaj medioj en malsamaj lokoj, unu el ili eksterrete, kaj tenu la malĉifran sekreton en malsama fida domajno ol la kopioj. Skribu la daton de la lasta sukcesa restarigo sur la sekurkopian rikordon. Sekurkopio, kiu neniam estis restarigita, estas hipotezo, ne kontrolo.
Antaŭ ol vi fermos la bileton, konfirmu ĉi tiujn kvin punktojn:
- La fingrospuro de ca.crt estas registrita ie ekster la sekurkopio.
- index.txt, serial, crlnumber kaj openssl.cnf ĉiuj estas ene de la arkivo aŭ de la blob-aro.
- La gardo de la pasfrazo aŭ de la envolvita ŝlosilo estas dokumentita kaj tenata de iu alia ol la posedanto de la arkivo.
- Restarigo estis testita sur izolita gastiganto kun unu eldono kaj unu revoko.
- La revoka breĉo implicita de via sekurkopia intervalo estas skribe akceptita aŭ mallongigita.