Прашањето што го решава најголемиот дел од ова не е како го шифрирате архивот. Туку дали вашиот приватен клуч на CA воопшто може да го напушти својот контејнер. Ако клучот е датотека, можете да ја копирате целата директорија на CA во еден шифриран блок и да завршите за неколку минути. Ако живее во HSM или во токен што го означува клучот како неизвлечлив, таа копија не постои, и вашиот план станува план за постапката за обвиткување и враќање кај добавувачот. Двата модели работат, тие не успеваат на различен начин, а дефектот што можете да го преживеете е оној околу кој вреди да се проектира.

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

Моделот A е копија на директорија. CA во стил на OpenSSL е работна директорија, а не еден сертификат: ca.key или cakey.pem, ca.crt, базата на податоци за издавање, бројачите serial и crlnumber, и openssl.cnf. Запечатете ја таа директорија со симетрична шифра, преместете го резултатот на втор медиум, а враќањето значи отпакување, проверка, потпис. Сѐ што му треба на издавачот патува заедно, вклучително недели историја на отповикување за која никој не памети дека ја напишал.

Моделот B е задржување на клучот. Клучот се генерира внатре во модул PKCS#11 и се означува како неизвлечлив; модулот може да го обвитка за резервна копија, но ниту еден процес никогаш не ги чита сировите бајти. Вашата резервна копија тогаш е два артефакти што мора да се вратат во правилен редослед: обвиткан блок со клуч што само тоа семејство модули може да го отвори, плус обична копија од базата на податоци, конфигурацијата и сертификатите.

AttributeEncrypted archiveHSM key backup
What you storeone encrypted filewrapped blob plus CA records
Who can restore itanyone holding the passphraseholder of the module and the blob, often vendor support
If a copy leaksattacker with the passphrase becomes the CAblob is inert without the matching module
What usually breaks itforgotten passphrase, one damaged copyreplacement module rejects the blob, contract gap

Споредбата никогаш не е за тоа кој модел е посилен во апстрактна смисла. Таа е за тоа кој вашиот тим може да го врати во 2 часот по полноќ со луѓето што навистина се будни. Архива што никој не може да ја дешифрира и HSM блок што никој не го тестирал се подеднакво бескорисни. Разликата е што дефектот на архивата се појавува во менаџер на лозинки, а дефектот на HSM се крие во договор за поддршка.

Што мора да содржи секоја резервна копија на CA

Двата модели бараат истиот сет записи. Во CA на OpenSSL тие датотеки се index.txt со еден ред за секој издаден сертификат што покрива статус, истек, serial и субјект, потоа index.txt.attr, serial што го чува следниот 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 се сите внатре во архивата или множеството блокови.
  • Чувањето на лозинката или обвитканиот клуч е документирано и го држи некој друг освен сопственикот на архивата.
  • Враќањето е тестирано на изолиран домаќин со едно издавање и едно отповикување.
  • Празнината во отповикувањето што ја имплицира вашиот интервал на резервни копии е писмено прифатена или скратена.

Поврзани статии