Kopia zapasowa prywatnego CA: zaszyfrowane archiwum czy kopia klucza HSM

Pytanie, które rozstrzyga większość tego, nie brzmi, jak szyfrujesz archiwum. Brzmi, czy twój prywatny klucz CA może w ogóle opuścić swój kontener. Jeśli klucz jest plikiem, możesz skopiować cały katalog CA do jednego zaszyfrowanego bloba i skończyć w kilka minut. Jeśli mieszka w HSM albo w tokenie oznaczającym klucz jako nieeksportowalny, taka kopia nie istnieje, a twój plan staje się planem dotyczącym procedury opakowania i odtworzenia u dostawcy. Oba modele działają, zawodzą inaczej, a awaria, którą możesz przetrwać, jest tą, wokół której warto projektować.

Gdzie rozchodzą się dwa modele kopii

Model A to kopia katalogu. CA w stylu OpenSSL to katalog roboczy, a nie jeden certyfikat: ca.key lub cakey.pem, ca.crt, baza wydawania, liczniki serial i crlnumber oraz openssl.cnf. Zapieczętuj ten katalog szyfrem symetrycznym, przenieś wynik na drugi nośnik, a odtworzenie oznacza rozpakowanie, weryfikację i podpisanie. Wszystko, czego potrzebuje wystawca, podróżuje razem, w tym tygodnie historii unieważnień, o których nikt nie pamięta, że je zapisał.

Model B to zamknięcie klucza. Klucz jest generowany wewnątrz modułu PKCS#11 i oznaczany jako nieeksportowalny; moduł może go opakować na potrzeby kopii, ale żaden proces nigdy nie czyta surowych bajtów. Twoja kopia to wtedy dwa artefakty, które trzeba odtworzyć we właściwej kolejności: opakowany blob klucza, który może otworzyć tylko ta rodzina modułów, oraz zwykła kopia bazy, konfiguracji i certyfikatów.

Porównanie nigdy nie dotyczy tego, który model jest silniejszy w abstrakcji. Dotyczy tego, który twój zespół potrafi odtworzyć o 2 w nocy z ludźmi, którzy naprawdę nie śpią. Archiwum, którego nikt nie potrafi odszyfrować, i blob HSM, którego nikt nie przetestował, są równie bezużyteczne. Różnica polega na tym, że awaria archiwum pojawia się w menedżerze haseł, a awaria HSM ukrywa się w umowie serwisowej.

Co musi zawierać każda kopia zapasowa CA

Oba modele potrzebują tego samego zestawu rekordów. W CA OpenSSL tymi plikami są index.txt z jednym wierszem na każdy wydany certyfikat obejmującym status, wygaśnięcie, serial i podmiot, potem index.txt.attr, serial przechowujący następny numer seryjny do wydania, crlnumber przechowujący następny numer CRL oraz openssl.cnf z dir, policy i default_days, z którymi twoje CA naprawdę działa. Podręcznik openssl-ca wyjaśnia, czym steruje każdy z tych liczników. easy-rsa trzyma te same dane pod pki/, a plik vars decyduje o polach certyfikatu.

Klucz i certyfikat to części, których nie można odbudować. Baza danych to część, której nie można odtworzyć z pamięci. Pominięcie index.txt nadal pozwala podpisywać nowe certyfikaty i to jest właśnie pułapka: dowiadujesz się, że go brakuje, gdy klient po raz pierwszy pyta, czy certyfikat został unieważniony. Zapisz odcisk CA poza kopią, aby odtworzenie było porównywane z wartością, której ufasz, a nie z plikiem, który właśnie odtworzyłeś.

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

Testy odtworzenia, które nie rozgałęziają wystawcy

Dwa działające CA z tym samym podmiotem i tym samym kluczem wyglądają identycznie dla każdego klienta, który ufa oryginałowi. Dwa CRL z tym samym numerem, ale inną treścią to sposób, w jaki klienci po cichu akceptują unieważniony przez ciebie certyfikat. Uruchom odtworzenie na hoście bez trasy do twoich klientów albo w jednorazowej VM i nigdy nie publikuj CRL, który wytworzy test.

Test, który dowodzi tylko, że archiwum się otwiera, nie dowodzi niczego o wydawaniu. Kolejność, która się liczy: porównaj odcisk odtworzonego ca.crt z zapisaną wartością, potwierdź, że serial odpowiada temu, co wynika z ostatniego wydanego certyfikatu, wydaj jeden certyfikat dla jednorazowego CN i patrz, jak index.txt zyskuje wiersz, następnie unieważnij ten certyfikat i wygeneruj CRL ponownie.

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

Z HSM ten sam test przechodzi przez moduł. Rozpakuj blob w urządzeniu zastępczym, potwierdź, że certyfikat CA raportowany przez moduł odpowiada zapisanemu odciskowi, i dopiero wtedy pozwól mu podpisywać. Jeśli moduł ma własny magazyn obiektów, opakowanie musi obejmować obiekt klucza i jego etykietę, bo odtworzenie klucza pod inną etykietą psuje konfigurację, która na niego wskazuje.

Tryby awarii, które decydują o wyborze

Pięć awarii wyjaśnia większość rzeczywistych strat. Zapomniane hasło archiwum bez niezależnej kopii sekretu zamienia archiwum w cegłę. Jedna kopia na jednym dysku umiera wraz z tym dyskiem, a suma kontrolna nigdy nie mówi, czy odszyfrowanie nadal działa. Certyfikaty unieważnione po dacie kopii znów wyglądają na ważne po odtworzeniu, więc interwał kopii jest także twoim martwym punktem unieważnień. Odtworzenie starszego licznika serial ponownie używa numerów seryjnych i miesza pamięci podręczne oraz wyszukiwania CRL oparte na serial. Zastępczy HSM, który odrzuca opakowany blob, zamienia wymianę sprzętu w pełne ponowne wydanie.

Model A radzi sobie z pierwszymi czterema źle, ale widocznie. Model B radzi sobie z nimi dobrze aż do awarii modułu lub procesu dostawcy. Jeśli twoje klucze są eksportowalne, a zespół mały, zaszyfrowane archiwum jest uczciwym wyborem, wspartym dwoma nośnikami i pisaną procedurą hasła. Jeśli klucz jest nieeksportowalny, nie masz żadnego wyboru, a praca przenosi się na udowodnienie ścieżki odtworzenia u dostawcy przed dniem, w którym będzie potrzebna.

Wybór modelu i planowanie

Trzy warunki rozstrzygają decyzję. Czy klucz można wyeksportować bez procesu dostawcy? Czy odtworzenie musi trafić na sprzęt, którego jeszcze nie masz? Jak długo wydawanie może stać, gdy kłócisz się z pomocą techniczną? Odpowiedz na te trzy, a model jest rozstrzygnięty; wszystko potem to planowanie.

Rób kopię po każdej ceremonii podpisywania i przed każdą zmianą konfiguracji, bo konfiguracja jest częścią stanu. Trzymaj dwie kopie na różnych nośnikach w różnych miejscach, jedną offline, a sekret odszyfrowania trzymaj w innej domenie zaufania niż kopie. Zapisz datę ostatniego udanego odtworzenia w rekordzie kopii. Kopia, której nigdy nie odtworzono, jest hipotezą, nie kontrolą.

Przed zamknięciem zgłoszenia potwierdź te pięć punktów:

• Odcisk ca.crt jest zapisany gdzieś poza kopią.
• index.txt, serial, crlnumber i openssl.cnf są wszystkie w archiwum lub zestawie blobów.
• Przechowywanie hasła lub opakowanego klucza jest udokumentowane i ma je ktoś inny niż właściciel archiwum.
• Odtworzenie przetestowano na izolowanym hoście z jednym wydaniem i jednym unieważnieniem.
• Luka w unieważnieniach wynikająca z interwału kopii została zaakceptowana pisemnie lub skrócona.