Back-up fan privee CA: fersifere argyf tsjin HSM-kaaiback-up

De fraach dy't it measte hjirfan beslist is net hoe't jo it argyf fersiferje. It is oft jo privee CA-kaai syn kontener wol ferlitte kin. As de kaai in bestân is, kinne jo de hiele CA-map nei ien fersifere blob kopiearje en binne jo yn minuten klear. As er yn in HSM of in token wennet dy't de kaai as net-útlûkber markearret, bestiet dy kopy net, en jo plan wurdt in plan oer de omwuol- en weromsetproseduere fan de leveransier. Beide modellen wurkje, se mislearje oars, en de fout dy't jo oerlibje kinne is dejinge dêr't it wurdich is om omhinne te ûntwerpen.

Dêr't de twa back-upmodellen skiede

Model A is mapkopy. In CA yn OpenSSL-styl is in wurkmap, net ien sertifikaat: ca.key of cakey.pem, ca.crt, de útjefte-databank, de tellers serial en crlnumber, en openssl.cnf. Fersegelje dy map mei in symmetryske sifer, ferpleats it resultaat nei in twadde medium, en weromsette betsjut útpakke, ferifiearje, ûndertekenje. Alles wat de útjouwer nedich hat reizget tegearre, ynklusyf wiken skiednis fan ynlûken dy't nimmen him betinkt skreaun te hawwen.

Model B is kaaibeskerming. De kaai wurdt yn in PKCS#11-module generearre en as net-útlûkber markearre; de module kin him foar back-up omwuolje, mar gjin proses lêst ea de rauwe bytes. Jo back-up is dan twa artefakten dy't yn de goede folchoarder weromset wurde moatte: in omwuolle kaaiblob dy't allinnich dy modulefamylje iepenje kin, plus in gewoane kopy fan de databank, konfiguraasje en sertifikaten.

De ferliking giet nea oer hokker model abstrakt sterker is. It giet oer hokker jo team om 2 oere nachts weromsette kin mei de minsken dy't echt wekker binne. In argyf dat nimmen ûntsiferje kin en in HSM-blob dy't nimmen test hat binne like nutteleas. It ferskil is dat de argyffout yn in wachtwurdbehearder opdûkt, en de HSM-fout him yn in stipekontrakt ferskûlet.

Wat elke CA-back-up befetsje moat

Beide modellen hawwe deselde recordset nedich. Yn in OpenSSL-CA binne dy bestannen index.txt mei ien rige per útjûn sertifikaat dy't status, ferfal, serial en subjekt beslacht, dan index.txt.attr, serial dat de folgjende serial hâldt om út te jaan, crlnumber dat it folgjende CRL-nûmer hâldt, en openssl.cnf mei de dir, policy en default_days dêr't jo CA echt mei wurket. De openssl-ca-hânlieding ferklearret wat elk fan dy tellers regelet. easy-rsa hâldt deselde data ûnder pki/, mei in vars-bestân dat de sertifikaatfjilden beslist.

De kaai en it sertifikaat binne de dielen dy't jo net opnij bouwe kinne. De databank is it diel dat jo net út it ûnthâld rekonstruearje kinne. index.txt oerslaan lit jo noch altyd nije sertifikaten ûndertekenje, en dat is krekt de falstrik: jo ûntdekke dat it mist de earste kear dat in klant freget oft in sertifikaat ynlutsen is. Registrearje de CA-fingerprint bûten de back-up, sadat in weromset ferlike wurdt mei in wearde dêr't jo op fertrouwe, net mei it bestân dat jo krekt weromset hawwe.

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

Weromsettests dy't de útjouwer net forksje

Twa libbene CA's mei itselde subjekt en deselde kaai lykje identyk foar elke klant dy't it orizjineel fertrout. Twa CRL's mei itselde nûmer mar ferskate ynhâld is hoe't klanten stil in sertifikaat akseptearje dat jo ynlutsen hawwe. Rin de weromset op in host sûnder rûte nei jo klanten, of yn in weismyt-VM, en publisearje nea de CRL dy't de test produsearret.

In test dy't allinnich bewiist dat it argyf iepengiet, bewiist neat oer útjefte. De folchoarder dy't telt: ferlykje de fingerprint fan de weromsette ca.crt mei de wearde dy't jo registrearre hawwe, befêstigje dat de serial oerienkomt mei wat jo lêst útjûne sertifikaat ymplisearret, jou ien sertifikaat út foar in weismyt-CN en sjoch index.txt in rige winne, lûk dan dat sertifikaat yn en generearje de CRL opnij.

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

Mei in HSM rint deselde test troch de module. Pak de blob út yn it ferfangende apparaat, befêstigje dat it CA-sertifikaat dat de module rapporteart oerienkomt mei jo registrearre fingerprint, en lit it dan earst ûndertekenje. As de module syn eigen objektopslach hat, moat it omwuoljen it kaaiobjekt en syn label dekke, want de kaai weromsette ûnder in oar label brekt de konfiguraasje dy't dêrnei wiist.

Mislearringsmodi dy't de kar beslisje

Fiif flaten ferklearje de measte echte ferliezen. In fergetten argyfwachtwurd sûnder ûnôfhinklike kopy fan it geheim makket it argyf in bakstien. Ien kopy op ien skiif stjert mei dy skiif, en in kontrôlesom fertelt jo nea oft ûntsiferjen noch wurket. Sertifikaten dy't nei de back-updatum ynlutsen binne, lykje nei in weromset wer jildich, dus jo back-upinterval is ek jo bline plak foar ynlûken. In âlder serialteller weromsette brûkt serialnûmers opnij en ferbjusteret caches en CRL-opskoppen dy't op serial basearre binne. In ferfangende HSM dy't de omwuolle blob wegeret, makket fan in hardwareferwikseling in folsleine nije útjefte.

Model A behannelt de earste fjouwer min mar sichtber. Model B behannelt se goed oant de module of it leveransiersproses falt. As jo kaaien eksportearber binne en it team is lyts, is it fersifere argyf de earlike kar, stipe troch twa media en in skriftlike wachtwurdproseduere. As de kaai net-útlûkber is, hawwe jo hielendal gjin kar, en it wurk ferskoot nei it bewizen fan it weromsetpaad fan de leveransier foar de dei dat jo it nedich hawwe.

It model kieze en ynplenje

Trije betingsten beslisje it. Kin de kaai eksportearre wurde sûnder leveransiersproses? Moat in weromset op hardware lânje dy't jo noch net hawwe? Hoe lang kin útjefte stilstean wylst jo mei stipe debatearje? Beäntwurdzje dy trije en it model is besletten; alles dêrnei is planning.

Nim in back-up nei elke ûndertekeningseremoanje en foar elke konfiguraasjeferoaring, want de konfiguraasje is diel fan de tastân. Hâld twa kopyen op ferskate media op ferskate plakken, ien dêrfan offline, en hâld it ûntsiferingsgeheim yn in oar fertrouwensdomein as de kopyen. Skriuw de datum fan de lêste slagge weromset op it back-uprecord. In back-up dy't nea weromset is, is in hypoteze, gjin kontrôle.

Foardat jo it ticket slute, befêstigje dizze fiif punten:

• De fingerprint fan ca.crt is earne bûten de back-up fêstlein.
• index.txt, serial, crlnumber en openssl.cnf binne allegear yn it argyf of de blobset.
• It bewarjen fan it wachtwurd of de omwuolle kaai is dokumintearre en by immen oars as de eigner fan it argyf.
• In weromset waard teste op in isolearre host mei ien útjefte en ien ynlûken.
• De ynlûkskloft dy't jo back-upinterval ymplisearret is skriftlik akseptearre of ferkoarte.