Cadangan CA privat: arsip terenkripsi versus cadangan kunci HSM

Pertanyaan yang menentukan sebagian besar hal ini bukanlah bagaimana Anda mengenkripsi arsip. Melainkan apakah kunci privat CA Anda dapat keluar dari wadahnya sama sekali. Jika kunci berupa file, Anda dapat menyalin seluruh direktori CA ke satu blob terenkripsi dan selesai dalam hitungan menit. Jika kunci hidup di HSM atau token yang menandai kunci sebagai tidak dapat diekstrak, salinan itu tidak ada, dan rencana Anda berubah menjadi rencana tentang prosedur pembungkusan dan pemulihan vendor. Kedua model berfungsi, keduanya gagal dengan cara berbeda, dan kegagalan yang bisa Anda lewati adalah yang layak dirancang.

Di mana kedua model cadangan berpisah

Model A adalah salinan direktori. CA bergaya OpenSSL adalah direktori kerja, bukan satu sertifikat: ca.key atau cakey.pem, ca.crt, basis data penerbitan, penghitung serial dan crlnumber, dan openssl.cnf. Segel direktori itu dengan sandi simetris, pindahkan hasilnya ke media kedua, dan pemulihan berarti membongkar, memverifikasi, menandatangani. Semua yang dibutuhkan penerbit berjalan bersama, termasuk riwayat pencabutan berminggu-minggu yang tak seorang pun ingat telah menulisnya.

Model B adalah penahanan kunci. Kunci dihasilkan di dalam modul PKCS#11 dan ditandai tidak dapat diekstrak; modul dapat membungkusnya untuk cadangan, tetapi tidak ada proses yang pernah membaca byte mentahnya. Cadangan Anda kemudian menjadi dua artefak yang harus dipulihkan dalam urutan yang benar: blob kunci terbungkus yang hanya dapat dibuka oleh keluarga modul itu, ditambah salinan biasa basis data, konfigurasi, dan sertifikat.

Perbandingannya tidak pernah tentang model mana yang lebih kuat secara abstrak. Ini tentang mana yang dapat dipulihkan tim Anda pada pukul 2 pagi bersama orang-orang yang benar-benar terjaga. Arsip yang tidak dapat didekripsi siapa pun dan blob HSM yang belum diuji siapa pun sama-sama tidak berguna. Bedanya, kegagalan arsip muncul di pengelola kata sandi, dan kegagalan HSM bersembunyi di kontrak dukungan.

Apa yang harus dimuat setiap cadangan CA

Kedua model memerlukan kumpulan catatan yang sama. Dalam CA OpenSSL, file-file itu adalah index.txt dengan satu baris per sertifikat yang diterbitkan mencakup status, kedaluwarsa, serial, dan subjek, lalu index.txt.attr, serial yang menyimpan serial berikutnya untuk diterbitkan, crlnumber yang menyimpan nomor CRL berikutnya, dan openssl.cnf dengan dir, policy, dan default_days yang benar-benar dipakai CA Anda. Manual openssl-ca menjelaskan apa yang dikendalikan setiap penghitung itu. easy-rsa menyimpan data yang sama di bawah pki/, dengan file vars yang menentukan bidang sertifikat.

Kunci dan sertifikat adalah bagian yang tidak dapat Anda bangun ulang. Basis data adalah bagian yang tidak dapat Anda rekonstruksi dari ingatan. Melewatkan index.txt tetap membuat Anda dapat menandatangani sertifikat baru, dan itulah tepatnya jebakannya: Anda baru tahu file itu hilang saat klien pertama kali bertanya apakah sebuah sertifikat dicabut. Catat sidik jari CA di luar cadangan, agar pemulihan dibandingkan dengan nilai yang Anda percayai, bukan dengan file yang baru saja Anda pulihkan.

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

Uji pemulihan yang tidak mencabangkan penerbit

Dua CA hidup dengan subjek dan kunci yang sama tampak identik bagi setiap klien yang memercayai yang asli. Dua CRL dengan nomor sama tetapi isi berbeda adalah cara klien diam-diam menerima sertifikat yang Anda cabut. Jalankan pemulihan pada host tanpa rute ke klien Anda, atau di VM sekali pakai, dan jangan pernah menerbitkan CRL yang dihasilkan pengujian.

Uji yang hanya membuktikan arsip dapat dibuka tidak membuktikan apa pun tentang penerbitan. Urutan yang penting: bandingkan sidik jari ca.crt yang dipulihkan dengan nilai yang Anda catat, pastikan serial cocok dengan yang tersirat dari sertifikat terakhir yang Anda terbitkan, terbitkan satu sertifikat untuk CN sekali pakai dan lihat index.txt bertambah satu baris, lalu cabut sertifikat itu dan buat ulang CRL.

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

Dengan HSM, uji yang sama berjalan melalui modul. Buka blob ke perangkat pengganti, pastikan sertifikat CA yang dilaporkan modul cocok dengan sidik jari yang Anda catat, dan baru setelah itu biarkan menandatangani. Jika modul memiliki penyimpanan objeknya sendiri, pembungkusan harus mencakup objek kunci dan labelnya, karena memulihkan kunci di bawah label berbeda merusak konfigurasi yang menunjuk ke sana.

Mode kegagalan yang menentukan pilihan

Lima kegagalan menjelaskan sebagian besar kerugian nyata. Frasa sandi arsip yang terlupakan tanpa salinan rahasia yang independen mengubah arsip menjadi bata. Satu salinan pada satu disk mati bersama disk itu, dan checksum tidak pernah memberi tahu apakah dekripsi masih berfungsi. Sertifikat yang dicabut setelah tanggal cadangan tampak valid lagi setelah pemulihan, jadi interval cadangan Anda juga titik buta pencabutan Anda. Memulihkan penghitung serial lama memakai ulang nomor serial dan membingungkan cache serta pencarian CRL yang dikunci pada serial. HSM pengganti yang menolak blob terbungkus mengubah penggantian perangkat keras menjadi penerbitan ulang penuh.

Model A menangani empat yang pertama dengan buruk tetapi terlihat. Model B menanganinya dengan baik sampai modul atau proses vendor gagal. Jika kunci Anda dapat diekspor dan timnya kecil, arsip terenkripsi adalah pilihan jujur, didukung dua media dan prosedur frasa sandi tertulis. Jika kunci tidak dapat diekstrak, Anda tidak punya pilihan sama sekali, dan pekerjaannya bergeser ke pembuktian jalur pemulihan vendor sebelum hari Anda membutuhkannya.

Memilih model dan menjadwalkannya

Tiga kondisi menyelesaikan keputusan. Dapatkah kunci diekspor tanpa proses vendor? Haruskah pemulihan mendarat di perangkat keras yang belum Anda miliki? Berapa lama penerbitan dapat berhenti saat Anda berdebat dengan dukungan? Jawab ketiganya dan modelnya diputuskan; semua setelah itu adalah penjadwalan.

Ambil cadangan setelah setiap upacara penandatanganan dan sebelum setiap perubahan konfigurasi, karena konfigurasi adalah bagian dari keadaan. Simpan dua salinan pada media berbeda di tempat berbeda, satu di antaranya offline, dan simpan rahasia dekripsi di domain kepercayaan yang berbeda dari salinannya. Tulis tanggal pemulihan sukses terakhir pada catatan cadangan. Cadangan yang tidak pernah dipulihkan adalah hipotesis, bukan kontrol.

Sebelum menutup tiket, pastikan lima hal ini:

• Sidik jari ca.crt tercatat di suatu tempat di luar cadangan.
• index.txt, serial, crlnumber, dan openssl.cnf semuanya di dalam arsip atau kumpulan blob.
• Penitipan frasa sandi atau kunci terbungkus terdokumentasi dan dipegang orang selain pemilik arsip.
• Pemulihan diuji pada host terisolasi dengan satu penerbitan dan satu pencabutan.
• Celah pencabutan yang tersirat dari interval cadangan Anda diterima secara tertulis atau dipersingkat.