Резервная копия частного 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 с одной строкой на каждый выпущенный сертификат, охватывающей статус, срок, serial и субъект, затем 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 с записанным значением, подтвердите, что serial соответствует тому, что подразумевает последний выпущенный сертификат, выпустите один сертификат для одноразового 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, который сообщает модуль, соответствует записанному отпечатку, и только затем разрешите ему подписывать. Если у модуля есть собственное хранилище объектов, обёртывание должно охватывать объект ключа и его метку, потому что восстановление ключа под другой меткой ломает конфигурацию, которая на него указывает.

Режимы отказа, определяющие выбор

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

Модель A справляется с первыми четырьмя плохо, но заметно. Модель B справляется с ними хорошо до отказа модуля или процесса поставщика. Если ваши ключи экспортируемы и команда небольшая, зашифрованный архив — честный выбор, подкреплённый двумя носителями и письменной процедурой парольной фразы. Если ключ неизвлекаем, выбора у вас нет вовсе, и работа смещается к доказательству пути восстановления у поставщика до того дня, когда он понадобится.

Выбор модели и планирование

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

Делайте копию после каждой церемонии подписания и перед любым изменением конфигурации, потому что конфигурация — часть состояния. Держите две копии на разных носителях в разных местах, одну из них офлайн, а секрет расшифровки — в другом домене доверия, чем копии. Запишите дату последнего успешного восстановления в запись о копии. Копия, которая никогда не восстанавливалась, — гипотеза, а не контроль.

Прежде чем закрыть заявку, подтвердите эти пять пунктов:

• Отпечаток ca.crt записан где-то вне резервной копии.
• index.txt, serial, crlnumber и openssl.cnf все находятся внутри архива или набора блоков.
• Хранение парольной фразы или обёрнутого ключа документировано и находится у кого-то другого, а не у владельца архива.
• Восстановление проверено на изолированном хосте с одним выпуском и одним отзывом.
• Пробел в отзыве, подразумеваемый интервалом копирования, принят письменно или сокращён.