Резервна копія приватного 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 усі всередині архіву або набору блоків.
• Зберігання парольної фрази або обгорнутого ключа задокументоване й перебуває в когось іншого, ніж власник архіву.
• Відновлення перевірено на ізольованому хості з однією видачею та одним відкликанням.
• Прогалину у відкликанні, яку передбачає інтервал копіювання, прийнято письмово або скорочено.