Резервно копие на частен CA: криптиран архив срещу резервно копие на ключ в HSM

Въпросът, който решава по-голямата част от това, не е как криптирате архива. А дали вашият частен ключ на CA може изобщо да напусне контейнера си. Ако ключът е файл, можете да копирате цялата директория на CA в един криптиран блок и да приключите за минути. Ако живее в HSM или в токен, който маркира ключа като неизвлекаем, това копие не съществува и планът ви се превръща в план за процедурата по обвиване и възстановяване на доставчика. И двата модела работят, провалят се по различен начин и повредата, която можете да преживеете, е тази, около която си струва да проектирате.

Къде се разделят двата модела на резервно копие

Модел A е копиране на директория. CA в стил OpenSSL е работна директория, а не един сертификат: ca.key или cakey.pem, ca.crt, базата данни за издаване, броячите serial и crlnumber и openssl.cnf. Запечатайте тази директория със симетричен шифър, преместете резултата на втори носител и възстановяването означава разопаковане, проверка, подписване. Всичко, от което се нуждае издателят, пътува заедно, включително седмици история на отзоваване, за която никой не помни, че я е писал.

Модел B е задържане на ключа. Ключът се генерира вътре в модул PKCS#11 и се маркира като неизвлекаем; модулът може да го обвие за резервно копие, но никой процес никога не чете суровите байтове. Тогава резервното ви копие е два артефакта, които трябва да се възстановят в правилния ред: обвит блок с ключ, който само това семейство модули може да разопакова, плюс обикновено копие на базата данни, конфигурацията и сертификатите.

Сравнението никога не е за това кой модел е по-силен в абстракция. А за това кой от тях екипът ви може да възстанови в 2 часа през нощта с хората, които наистина са будни. Архив, който никой не може да декриптира, и блок на HSM, който никой не е тествал, са еднакво безполезни. Разликата е, че повредата на архива се показва в мениджър на пароли, а повредата на HSM се крие в договор за поддръжка.

Какво трябва да съдържа всяко резервно копие на CA

И двата модела се нуждаят от един и същ набор записи. В CA на OpenSSL тези файлове са index.txt с един ред за всеки издаден сертификат, покриващ статус, срок, сериен номер и субект, след това index.txt.attr, serial, който държи следващия сериен номер за издаване, crlnumber, който държи следващия номер на CRL, и openssl.cnf с dir, policy и default_days, с които вашият CA наистина работи. Ръководството на openssl-ca обяснява какво контролира всеки от тези броячи. easy-rsa пази същите данни под pki/, като файл vars решава полетата на сертификата.

Ключът и сертификатът са частите, които не можете да изградите наново. Базата данни е частта, която не можете да възстановите по памет. Пропускането на index.txt все още ви оставя способност да подписвате нови сертификати и това е точно капанът: разбирате, че липсва, първия път, когато клиент попита дали сертификат е бил отзован. Запишете отпечатъка на CA извън резервното копие, за да се сравнява възстановяването със стойност, на която вярвате, а не с файла, който току-що сте възстановили.

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

Тестове за възстановяване, които не разклоняват издателя

Два живи CA с един и същ субект и един и същ ключ изглеждат идентични за всеки клиент, който се доверява на оригинала. Два CRL с еднакъв номер, но различно съдържание е начинът, по който клиентите тихо приемат сертификат, който сте отзовали. Пуснете възстановяването на хост без маршрут до клиентите си или във временна VM и никога не публикувайте CRL, който тестът произвежда.

Тест, който доказва само, че архивът се отваря, не доказва нищо за издаването. Последователността, която има значение: сравнете отпечатъка на възстановения ca.crt със записаната стойност, потвърдете, че серийният номер съответства на това, което предполага последният ви издаден сертификат, издайте един сертификат за временен CN и наблюдавайте как index.txt получава ред, след което отзовете този сертификат и генерирайте отново CRL.

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

С HSM същият тест минава през модула. Разопаковайте блока в резервното устройство, потвърдете, че сертификатът на CA, който модулът съобщава, съвпада със записания ви отпечатък, и само тогава го оставете да подписва. Ако модулът има собствено хранилище за обекти, обвиването трябва да покрива обекта на ключа и неговия етикет, защото възстановяването на ключа под различен етикет чупи конфигурацията, която сочи към него.

Режими на повреда, които решават избора

Пет повреди обясняват повечето реални загуби. Забравена парола на архива без независимо копие на тайната превръща архива в тухла. Едно копие на един диск умира с този диск, а контролната сума никога не ви казва дали декриптирането още работи. Сертификати, отзовани след датата на резервното копие, изглеждат отново валидни след възстановяване, така че интервалът на резервното ви копие е и вашата сляпа зона за отзоваване. Възстановяването на по-стар брояч на серийни номера използва повторно серийни номера и обърква кешове и справки в CRL, ключовани по сериен номер. Резервен HSM, който отказва обвития блок, превръща смяната на хардуер в пълно повторно издаване.

Модел A се справя с първите четири зле, но видимо. Модел B се справя с тях добре до момента, в който модулът или процесът на доставчика се провали. Ако ключовете ви са експортируеми и екипът е малък, криптираният архив е честният избор, подкрепен от два носителя и писмена процедура за паролата. Ако ключът е неизвлекаем, нямате никакъв избор и работата се измества към доказване на пътя за възстановяване на доставчика преди деня, в който ще ви потрябва.

Избор на модел и планиране

Три условия решават въпроса. Може ли ключът да се експортира без процес на доставчик? Трябва ли възстановяването да кацне на хардуер, който още не притежавате? Колко дълго може да спре издаването, докато спорите с поддръжката? Отговорете на тези три и моделът е решен; всичко след това е планиране.

Правете резервно копие след всяка церемония по подписване и преди всяка промяна на конфигурацията, защото конфигурацията е част от състоянието. Дръжте две копия на различни носители на различни места, едно от тях офлайн, и дръжте тайната за декриптиране в различен домейн на доверие от копията. Запишете датата на последното успешно възстановяване в записа за резервно копие. Резервно копие, което никога не е било възстановявано, е хипотеза, а не контрол.

Преди да затворите заявката, потвърдете тези пет точки:

• Отпечатъкът на ca.crt е записан някъде извън резервното копие.
• index.txt, serial, crlnumber и openssl.cnf са всички вътре в архива или набора от блокове.
• Съхранението на паролата или обвития ключ е документирано и се държи от някой друг, а не от собственика на архива.
• Възстановяване е тествано на изолиран хост с едно издаване и едно отзоваване.
• Прозорецът за отзоваване, който предполага интервалът на резервното ви копие, е приет писмено или е скъсен.