Sandaran CA peribadi: arkib disulitkan berbanding sandaran kunci HSM
Arkib disulitkan atau kunci dibalut HSM: bagaimana setiap model sandaran CA VPN dipulihkan, apa yang mesti terkandung di dalamnya dan kegagalan mana yang benar-benar boleh anda harungi.
Soalan yang menentukan sebahagian besar perkara ini bukanlah bagaimana anda menyulitkan arkib. Ia ialah sama ada kunci peribadi CA anda boleh keluar dari bekasnya sama sekali. Jika kunci ialah fail, anda boleh menyalin seluruh direktori CA ke dalam satu blob tersulit dan selesai dalam beberapa minit. Jika ia tinggal dalam HSM atau token yang menandakan kunci sebagai tidak boleh diekstrak, salinan itu tidak wujud, dan rancangan anda menjadi rancangan tentang prosedur balutan dan pemulihan vendor. Kedua-dua model berfungsi, ia gagal secara berbeza, dan kegagalan yang boleh anda harungi ialah yang wajar direka bentuk.
Di mana kedua-dua model sandaran berpisah
Model A ialah salinan direktori. CA gaya OpenSSL ialah direktori kerja, bukan satu sijil: ca.key atau cakey.pem, ca.crt, pangkalan data pengeluaran, pembilang serial dan crlnumber, dan openssl.cnf. Meterai direktori itu dengan sifer simetri, pindahkan hasilnya ke medium kedua, dan pemulihan bermaksud membuka bungkusan, mengesahkan, menandatangani. Semua yang diperlukan pengeluar bergerak bersama, termasuk minggu-minggu sejarah pembatalan yang tiada siapa ingat telah menulisnya.
Model B ialah pengawalan kunci. Kunci dijana di dalam modul PKCS#11 dan ditandakan sebagai tidak boleh diekstrak; modul boleh membalutnya untuk sandaran, tetapi tiada proses pernah membaca bait mentah. Sandaran anda kemudiannya dua artifak yang mesti dipulihkan dalam susunan yang betul: blob kunci terbalut yang hanya keluarga modul itu boleh membukanya, serta salinan biasa pangkalan data, konfigurasi dan sijil.
| Attribute | Encrypted archive | HSM key backup |
|---|---|---|
| What you store | one encrypted file | wrapped blob plus CA records |
| Who can restore it | anyone holding the passphrase | holder of the module and the blob, often vendor support |
| If a copy leaks | attacker with the passphrase becomes the CA | blob is inert without the matching module |
| What usually breaks it | forgotten passphrase, one damaged copy | replacement module rejects the blob, contract gap |
Perbandingan tidak pernah tentang model mana yang lebih kuat secara abstrak. Ia tentang mana yang pasukan anda boleh pulihkan pada pukul 2 pagi bersama orang yang benar-benar terjaga. Arkib yang tiada siapa boleh menyahsulit dan blob HSM yang tiada siapa telah uji sama-sama tidak berguna. Bezanya ialah kegagalan arkib muncul dalam pengurus kata laluan, dan kegagalan HSM bersembunyi dalam kontrak sokongan.
Apa yang mesti terkandung dalam setiap sandaran CA
Kedua-dua model memerlukan set rekod yang sama. Dalam CA OpenSSL, fail-fail itu ialah index.txt dengan satu baris bagi setiap sijil yang dikeluarkan meliputi status, tamat tempoh, serial dan subjek, kemudian index.txt.attr, serial yang menyimpan serial seterusnya untuk dikeluarkan, crlnumber yang menyimpan nombor CRL seterusnya, dan openssl.cnf dengan dir, policy dan default_days yang benar-benar digunakan oleh CA anda. Manual openssl-ca menerangkan apa yang dikawal oleh setiap pembilang itu. easy-rsa menyimpan data yang sama di bawah pki/, dengan fail vars menentukan medan sijil.
Kunci dan sijil ialah bahagian yang tidak boleh anda bina semula. Pangkalan data ialah bahagian yang tidak boleh anda bina semula daripada ingatan. Melangkau index.txt masih membolehkan anda menandatangani sijil baharu, dan itulah tepat perangkapnya: anda mengetahui ia hilang pada kali pertama pelanggan bertanya sama ada sesuatu sijil telah dibatalkan. Rekodkan cap jari CA di luar sandaran, supaya pemulihan dibandingkan dengan nilai yang anda percayai, bukan dengan fail yang baru 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
Ujian pemulihan yang tidak mencabangkan pengeluar
Dua CA hidup dengan subjek dan kunci yang sama kelihatan serupa kepada setiap pelanggan yang mempercayai yang asal. Dua CRL dengan nombor yang sama tetapi kandungan berbeza ialah cara pelanggan secara senyap menerima sijil yang anda batalkan. Jalankan pemulihan pada hos tanpa laluan ke pelanggan anda, atau dalam VM sekali guna, dan jangan sekali-kali menerbitkan CRL yang dihasilkan oleh ujian itu.
Ujian yang hanya membuktikan arkib boleh dibuka tidak membuktikan apa-apa tentang pengeluaran. Urutan yang penting: bandingkan cap jari ca.crt yang dipulihkan dengan nilai yang anda rekodkan, sahkan serial sepadan dengan apa yang tersirat oleh sijil terakhir yang anda keluarkan, keluarkan satu sijil untuk CN sekali guna dan perhatikan index.txt mendapat satu baris, kemudian batalkan sijil itu dan jana semula CRL.
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdate
Dengan HSM, ujian yang sama berjalan melalui modul. Buka blob ke dalam peranti pengganti, sahkan sijil CA yang dilaporkan oleh modul sepadan dengan cap jari yang anda rekodkan, dan barulah benarkannya menandatangani. Jika modul mempunyai stor objeknya sendiri, balutan mesti meliputi objek kunci dan labelnya, kerana memulihkan kunci di bawah label berbeza memecahkan konfigurasi yang menunjuk kepadanya.
Mod kegagalan yang menentukan pilihan
Lima kegagalan menjelaskan sebahagian besar kerugian sebenar. Frasa laluan arkib yang terlupa tanpa salinan rahsia yang bebas menjadikan arkib itu bata. Satu salinan pada satu cakera mati bersama cakera itu, dan checksum tidak pernah memberitahu anda sama ada penyahsulitan masih berfungsi. Sijil yang dibatalkan selepas tarikh sandaran kelihatan sah semula selepas pemulihan, jadi selang sandaran anda juga titik buta pembatalan anda. Memulihkan pembilang serial yang lebih lama menggunakan semula nombor serial dan mengelirukan cache serta carian CRL yang dikunci pada serial. HSM pengganti yang menolak blob terbalut menjadikan penukaran perkakasan sebagai pengeluaran semula penuh.
Model A mengendalikan empat yang pertama dengan teruk tetapi kelihatan. Model B mengendalikannya dengan baik sehingga modul atau proses vendor gagal. Jika kunci anda boleh dieksport dan pasukan kecil, arkib tersulit ialah pilihan jujur, disokong oleh dua medium dan prosedur frasa laluan bertulis. Jika kunci tidak boleh diekstrak, anda tiada pilihan sama sekali, dan kerja beralih kepada membuktikan laluan pemulihan vendor sebelum hari anda memerlukannya.
Memilih model dan menjadualkannya
Tiga syarat menyelesaikan keputusan. Bolehkah kunci dieksport tanpa proses vendor? Perlukah pemulihan mendarat pada perkakasan yang belum anda miliki? Berapa lama pengeluaran boleh berhenti semasa anda berdebat dengan sokongan? Jawab ketiga-tiganya dan model itu ditentukan; segala-galanya selepas itu ialah penjadualan.
Ambil sandaran selepas setiap upacara menandatangani dan sebelum sebarang perubahan konfigurasi, kerana konfigurasi ialah sebahagian daripada keadaan. Simpan dua salinan pada medium berbeza di tempat berbeza, satu daripadanya luar talian, dan simpan rahsia penyahsulitan dalam domain kepercayaan berbeza daripada salinan. Tulis tarikh pemulihan berjaya terakhir pada rekod sandaran. Sandaran yang tidak pernah dipulihkan ialah hipotesis, bukan kawalan.
Sebelum menutup tiket, sahkan lima perkara ini:
- Cap jari ca.crt direkodkan di suatu tempat di luar sandaran.
- index.txt, serial, crlnumber dan openssl.cnf semuanya di dalam arkib atau set blob.
- Penjagaan frasa laluan atau kunci terbalut didokumenkan dan dipegang oleh orang lain daripada pemilik arkib.
- Pemulihan diuji pada hos terasing dengan satu pengeluaran dan satu pembatalan.
- Jurat pembatalan yang tersirat oleh selang sandaran anda diterima secara bertulis atau dipendekkan.