Akses HSM Rakan Kongsi melalui VPN: Tetapkan Operasi Kunci

Seseorang di pihak rakan kongsi perlu menandatangani dokumen dengan satu kunci yang ditetapkan, dan permintaan itu datang sebagai urusan rangkaian: mereka perlu sampai ke HSM. Anggap ayat itu sebagai gejala kontrak perkhidmatan yang tidak ditakrifkan, bukan masalah penghalaan, kerana terowong yang sampai ke perkakas tidak memberikan apa-apa dengan sendirinya. Tiga pintu pagar berada di belakang permintaan itu: kebolehcapaian, identiti HSM dan dasar kunci, dan setiap satunya ditadbir di tempat berbeza oleh pasukan berbeza. Catat satu demi satu, jika tidak anda akan memberi laluan kerana perbualan tentang sijil lebih sukar.

Ingat kes konkritnya: rakan kongsi menyerahkan dokumen yang diluluskan untuk ditandatangani dengan satu kunci bernama, dan tiada apa-apa lagi. Semua di bawah berpunca daripada ayat tunggal itu.

Kebolehcapaian, identiti dan dasar kunci ialah tiga pintu pagar

Konsentrator VPN menentukan siapa boleh membuka terowong dan alamat mana yang boleh disentuh. HSM menentukan sendiri rekod pengguna mana yang dikemukakan kepadanya boleh log masuk. Dasar kunci kemudian menentukan apa yang boleh dilakukan oleh rekod pengguna itu dengan satu kunci tertentu. Melepasi pintu pertama membiarkan dua lagi kekal seperti asal, sebab itulah jabat tangan yang berjaya membuktikan begitu sedikit dan sebab itulah rakan kongsi boleh sampai ke perkakas tetapi masih gagal dalam setiap operasi.

Petakan setiap pintu kepada pemilik sebelum menulis keperluan. Apabila tiada siapa memiliki pintu kedua, hasil biasa ialah identiti pentadbir HSM yang luas diberikan kerana itulah satu-satunya kelayakan yang berfungsi.

Pintu satu: laluan rangkaian yang diberikan kepada rakan kongsi

Namakan klien atau perkhidmatan yang diluluskan, destinasi yang diperlukannya, serta protokol dan port tempat perkhidmatan itu mendengar. Kemudian hadkan akses dari bahagian VPN kepada pasangan itu dalam kedua-dua arah, termasuk laluan balik, supaya dasar itu menjadi ayat yang boleh anda baca semula kepada rakan kongsi. Pentadbiran get laluan, antara muka pengurusan HSM dan sistem dalaman yang tidak berkaitan harus berada di luar akses rakan kongsi biasa, bukan hanya di luar laluan lalai.

Segmen khusus menjadikan lintasan itu kelihatan, tetapi nama segmen tidak menguatkuasakan apa-apa. Trafik mesti melalui kawalan yang anda fikir dilaluinya. Menerima sambungan daripada rakan kongsi juga bukan pernyataan bahawa setiap mesin di pihak rakan kongsi boleh dipercayai.

Pintu dua: apa yang benar-benar mengesahkan diri kepada HSM

Identiti VPN dan identiti HSM ialah objek berasingan kecuali integrasi yang disokong sengaja menggabungkannya. Dengan klien PKCS#11, aplikasi melakukan log masuk ke slot dengan kelayakan yang disimpan di suatu tempat pada hos rakan kongsi, dan log masuk itulah yang dinilai oleh HSM.

AWS CloudHSM ialah rujukan berguna kerana dokumentasinya memisahkan kedua-duanya: pengguna HSM berbeza daripada pengguna IAM, dan jenis pengguna menentukan apa yang boleh dilakukan oleh akaun. Pegawai kripto mengurus pengguna dan kunci tetapi bukan identiti yang melakukan operasi kriptografi, manakala pengguna kripto boleh menggunakan kunci tanpa mampu mengurusnya. Pemisahan itu ialah bentuk yang anda mahu walaupun pada perkakas vendor lain, di mana nama peranan akan berbeza.

Apa jua identiti yang anda keluarkan, ia mesti boleh dibuang dan boleh diatribusikan pada butiran yang anda perlukan kemudian. Satu kelayakan operasi yang dikongsi merentas beberapa rakan kongsi menyukarkan pembendungan dan kebertanggungjawaban tepat pada insiden yang kedua-duanya paling penting.

Pintu tiga: kunci mana, dan operasi mana

Penandatanganan, penyahsulitan, penjanaan kunci, pembalutan kunci dan pentadbiran pengguna ialah kebenaran berasingan dan mesti disenaraikan secara berasingan. Dalam istilah PKCS#11, atribut seperti CKA_SENSITIVE dan CKA_EXTRACTABLE menerangkan sama ada bahan kunci boleh keluar dari modul dalam bentuk yang boleh digunakan, dan ia ditetapkan bagi setiap kunci bukan setiap perkakas. Baca dasar sebenar pada kunci itu dan bukannya membuat kesimpulan tentang ketidakbolehdieksportan daripada perkataan perkakasan atau daripada kehadiran terowong.

Kemudian cari kelulusan perniagaan. Jika hanya dokumen yang diluluskan boleh ditandatangani, komponen mana yang menetapkan kelulusan itu sebelum permintaan sampai ke HSM? Antara muka kriptografi yang menerima permintaan yang dibenarkan tidak tahu sama ada dokumen itu telah disemak, jadi semakan itu milik perkhidmatan di hadapannya.

Klien yang dibenarkan yang diceroboh juga boleh menyalahgunakan operasi yang dibenarkan secara sah oleh kelayakannya tanpa pernah mengeluarkan kunci peribadi. Oleh itu, melindungi bahan kunci yang disimpan dan mengawal penggunaan kunci ialah dua syarat penerimaan, bukan satu.

Penolakan ialah sebahagian daripada ujian penerimaan

Terima permintaan tandatangan yang dibenarkan, dan terima juga penolakan: identiti tidak dibenarkan, kunci yang tidak berkaitan, dan operasi pengurusan dari laluan rakan kongsi. Rekodkan pemanggil, operasi, pengecam kunci, masa dan hasil, dan jauhkan bahan kunci peribadi, kelayakan dan kandungan dokumen daripada log diagnostik umum.

Tetapkan pemilik untuk pengeluaran rakan kongsi, untuk syak wasangka pencabulan di pihak rakan kongsi, dan untuk perubahan dasar serta pemulihan. Menukar laluan tidak memulihkan kepercayaan pada hos yang mungkin sudah diceroboh, jadi pembatalan mesti sampai ke identiti HSM juga.

Jabat tangan VPN yang selesai termasuk dalam rekod itu. Ia tidak boleh menggantikan satu pun hasil khusus HSM.