Privát CA biztonsági mentése: titkosított archívum vagy HSM-kulcsmentés

A legtöbbet eldöntő kérdés nem az, hogyan titkosítja az archívumot. Hanem az, hogy a CA privát kulcsa egyáltalán elhagyhatja-e a tárolóját. Ha a kulcs fájl, az egész CA-könyvtárat átmásolhatja egyetlen titkosított blobba, és percek alatt kész. Ha HSM-ben vagy olyan tokenben él, amely a kulcsot nem kinyerhetőnek jelöli, az a másolat nem létezik, és a terve a beszállító becsomagolási és helyreállítási eljárásáról szóló tervvé válik. Mindkét modell működik, másképp hibázik, és az a hiba, amelyet túlélhet, az, amely köré érdemes tervezni.

Ahol a két mentési modell szétválik

Az A modell könyvtármásolás. Az OpenSSL-stílusú CA munkakönyvtár, nem egyetlen tanúsítvány: ca.key vagy cakey.pem, ca.crt, a kibocsátási adatbázis, a serial és crlnumber számlálók, valamint az openssl.cnf. Pecsételje le ezt a könyvtárat szimmetrikus rejtjellel, vigye át az eredményt egy második hordozóra, és a helyreállítás jelentése: kicsomagolás, ellenőrzés, aláírás. Minden, amire a kibocsátónak szüksége van, együtt utazik, beleértve a hetekig tartó visszavonási előzményeket, amelyekre senki sem emlékszik, hogy írta.

A B modell kulcsvisszatartás. A kulcs egy PKCS#11 modulon belül jön létre, és nem kinyerhetőnek van jelölve; a modul becsomagolhatja biztonsági mentéshez, de egyetlen folyamat sem olvassa soha a nyers bájtokat. A biztonsági mentése ekkor két összetevő, amelyeket a helyes sorrendben kell helyreállítani: egy becsomagolt kulcsblob, amelyet csak az a modulcsalád tud kicsomagolni, plusz az adatbázis, a konfiguráció és a tanúsítványok egyszerű másolata.

Az összehasonlítás soha nem arról szól, melyik modell erősebb elvontan. Arról szól, melyiket tudja a csapata hajnali 2-kor helyreállítani azokkal az emberekkel, akik valóban ébren vannak. Egy archívum, amelyet senki sem tud visszafejteni, és egy HSM-blob, amelyet senki sem tesztelt, egyformán hasznavehetetlen. A különbség az, hogy az archívum hibája egy jelszókezelőben jelenik meg, a HSM hibája pedig egy támogatási szerződésben rejtőzik.

Mit kell tartalmaznia minden CA-mentésnek

Mindkét modellnek ugyanaz a rekordkészlet kell. Egy OpenSSL CA-ban ezek a fájlok: index.txt, minden kiadott tanúsítványhoz egy sor, amely lefedi az állapotot, lejáratot, a serialt és a tárgyat, majd index.txt.attr, a serial, amely a következő kiadandó sorszámot tartja, a crlnumber, amely a következő CRL-számot tartja, és az openssl.cnf azzal a dir, policy és default_days értékkel, amellyel a CA valóban fut. Az openssl-ca kézikönyv kifejti, hogy e számlálók közül melyik mit vezérel. Az easy-rsa ugyanezeket az adatokat a pki/ alatt tartja, és egy vars fájl dönti el a tanúsítvány mezőit.

A kulcs és a tanúsítvány azok a részek, amelyeket nem lehet újraépíteni. Az adatbázis az a rész, amelyet nem lehet emlékezetből rekonstruálni. Az index.txt kihagyása még mindig lehetővé teszi új tanúsítványok aláírását, és pontosan ez a csapda: akkor derül ki, hogy hiányzik, amikor egy ügyfél először kérdezi meg, visszavontak-e egy tanúsítványt. Rögzítse a CA ujjlenyomatát a mentésen kívül, hogy a helyreállítást egy megbízható értékhez hasonlítsák, ne pedig az imént helyreállított fájlhoz.

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

Helyreállítási tesztek, amelyek nem iktatják ketté a kibocsátót

Két élő CA ugyanazzal a tárggyal és ugyanazzal a kulccsal azonosnak tűnik minden ügyfél számára, aki az eredetiben bízik. Két CRL ugyanazzal a számmal, de eltérő tartalommal: így fogadják el az ügyfelek csendben a visszavont tanúsítványt. Futtassa a helyreállítást olyan hoszton, amelyről nincs útvonal az ügyfeleihez, vagy eldobható VM-ben, és soha ne tegye közzé a teszt által előállított CRL-t.

Egy teszt, amely csak azt bizonyítja, hogy az archívum megnyílik, semmit sem bizonyít a kibocsátásról. A számító sorrend: hasonlítsa össze a helyreállított ca.crt ujjlenyomatát a rögzített értékkel, erősítse meg, hogy a serial megfelel annak, amit az utoljára kiadott tanúsítványa sugall, adjon ki egy tanúsítványt egy eldobható CN-hez, és figyelje, ahogy az index.txt egy sort kap, majd vonja vissza azt a tanúsítványt, és generálja újra a CRL-t.

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

HSM-mel ugyanez a teszt a modulon keresztül fut. Csomagolja ki a blobot a csereeszközbe, erősítse meg, hogy a modul által jelentett CA-tanúsítvány megfelel a rögzített ujjlenyomatának, és csak ezután engedje aláírni. Ha a modulnak saját objektumtára van, a becsomagolásnak le kell fednie a kulcsobjektumot és annak címkéjét, mert a kulcs más címke alatti helyreállítása megtöri a rá mutató konfigurációt.

A választást eldöntő hiba módok

Öt hiba magyarázza a legtöbb valódi veszteséget. Egy elfelejtett archívum-jelszó, amelyhez nincs független másolat a titokról, téglává változtatja az archívumot. Egyetlen példány egy lemezen meghal azzal a lemezzel, és az ellenőrző összeg soha nem mondja meg, működik-e még a visszafejtés. A mentés dátum után visszavont tanúsítványok helyreállítás után újra érvényesnek látszanak, tehát a mentési időköz egyben a visszavonási vakfoltja. Egy régebbi serial-számláló helyreállítása újrahasználja a sorszámokat, és összezavarja a serialra kulcsolt gyorsítótárakat és CRL-kereséseket. Egy csere-HSM, amely elutasítja a becsomagolt blobot, hardvercserét teljes újrakibocsátássá tesz.

Az A modell az első négyet rosszul, de láthatóan kezeli. A B modell jól kezeli őket egészen addig, amíg a modul vagy a beszállító folyamata meg nem hibázik. Ha a kulcsai exportálhatók és a csapat kicsi, a titkosított archívum az őszinte választás, két adathordozóval és írásos jelszóeljárással megtámogatva. Ha a kulcs nem kinyerhető, egyáltalán nincs választása, és a munka a beszállító helyreállítási útvonalának bizonyítására tolódik a nap előtt, amikor szüksége lesz rá.

A modell kiválasztása és ütemezése

Három feltétel dönti el. Exportálható-e a kulcs beszállítói folyamat nélkül? Olyan hardverre kell-e érkeznie a helyreállításnak, amellyel még nem rendelkezik? Meddig állhat le a kibocsátás, míg a támogatással vitatkozik? Válaszoljon erre a háromra, és a modell eldőlt; minden ezután ütemezés.

Készítsen mentést minden aláírási ceremónia után és minden konfigurációváltozás előtt, mert a konfiguráció az állapot része. Tartson két példányt különböző hordozókon, különböző helyeken, az egyiket offline, és a visszafejtési titkot a példányoktól eltérő bizalmi tartományban tartsa. Írja fel az utolsó sikeres helyreállítás dátumát a mentési rekordra. Egy mentés, amelyet soha nem állítottak helyre, hipotézis, nem kontroll.

Mielőtt lezárja a jegyet, erősítse meg ezt az öt pontot:

• A ca.crt ujjlenyomata valahol a mentésen kívül van rögzítve.
• Az index.txt, a serial, a crlnumber és az openssl.cnf mind az archívumban vagy a blobkészletben van.
• A jelszó vagy a becsomagolt kulcs őrzése dokumentált, és nem az archívum tulajdonosa tartja.
• Helyreállítást teszteltek izolált hoszton egy kibocsátással és egy visszavonással.
• A mentési időköz által implikált visszavonási rést írásban elfogadták vagy lerövidítették.