Akses HSM Mitra melalui VPN: Tetapkan Operasi Kunci

Seseorang di mitra harus menandatangani dokumen dengan satu kunci yang ditunjuk, dan permintaannya datang sebagai urusan jaringan: mereka perlu mencapai HSM. Perlakukan kalimat itu sebagai gejala kontrak layanan yang belum ditetapkan, bukan masalah perutean, karena terowongan yang mencapai perangkat tidak memberi apa pun dengan sendirinya. Tiga gerbang berada di balik permintaan itu: keterjangkauan, identitas HSM, dan kebijakan kunci, dan masing-masing dikelola di tempat berbeda oleh tim berbeda. Catat satu per satu, atau Anda akan berakhir memberi rute karena percakapan tentang sertifikat lebih sulit.

Ingat kasus konkretnya: mitra mengirimkan dokumen yang disetujui untuk ditandatangani dengan satu kunci bernama, dan tidak ada yang lain. Semua di bawah ini mengikuti dari satu kalimat itu.

Keterjangkauan, identitas, dan kebijakan kunci adalah tiga gerbang

Konsentrator VPN memutuskan siapa yang boleh membuka terowongan dan alamat mana yang boleh mereka sentuh. HSM memutuskan sendiri catatan pengguna mana yang diajukan kepadanya boleh masuk. Kebijakan kunci lalu memutuskan apa yang boleh dilakukan catatan pengguna itu dengan satu kunci tertentu. Melewati gerbang pertama membiarkan dua gerbang lain persis seperti semula, itulah sebabnya jabat tangan yang berhasil membuktikan sangat sedikit dan mitra bisa mencapai perangkat tetapi tetap gagal di setiap operasi.

Petakan setiap gerbang ke pemilik sebelum menulis persyaratan. Ketika tidak ada yang memiliki gerbang kedua, hasil biasanya identitas administrator HSM yang luas diberikan karena itulah satu-satunya kredensial yang berfungsi.

Gerbang satu: jalur jaringan yang diberikan kepada mitra

Sebutkan klien atau layanan yang disetujui, tujuan yang dibutuhkannya, serta protokol dan port tempat layanan itu mendengarkan. Lalu batasi akses dari sisi VPN ke pasangan itu di kedua arah, termasuk jalur balik, sehingga kebijakannya menjadi kalimat yang bisa Anda bacakan kepada mitra. Administrasi gateway, antarmuka manajemen HSM, dan sistem internal yang tidak terkait harus berada di luar akses mitra biasa, bukan hanya di luar rute default.

Segmen khusus membuat penyeberangan itu terlihat, tetapi nama segmen tidak menegakkan apa pun. Lalu lintas harus melewati kendali yang Anda anggap dilewatinya. Menerima koneksi dari mitra juga bukan pernyataan bahwa setiap mesin di mitra dapat dipercaya.

Gerbang dua: apa yang benar-benar mengautentikasi ke HSM

Identitas VPN dan identitas HSM adalah objek terpisah kecuali integrasi yang didukung sengaja menghubungkannya. Dengan klien PKCS#11, aplikasi melakukan login ke slot dengan kredensial yang disimpan di suatu tempat pada host mitra, dan login itulah yang dinilai HSM.

AWS CloudHSM adalah referensi berguna karena dokumentasinya memisahkan keduanya: pengguna HSM berbeda dari pengguna IAM, dan jenis pengguna menentukan apa yang boleh dilakukan akun. Petugas kripto mengelola pengguna dan kunci tetapi bukan identitas yang melakukan operasi kriptografi, sedangkan pengguna kripto dapat memakai kunci tanpa bisa mengelolanya. Pemisahan itu adalah bentuk yang Anda inginkan bahkan pada perangkat vendor lain, tempat nama peran akan berbeda.

Identitas apa pun yang Anda terbitkan harus dapat dicabut dan dapat diatribusikan pada tingkat kedetailan yang Anda perlukan nanti. Satu kredensial operasional bersama di beberapa mitra membuat pembatasan dan akuntabilitas lebih sulit justru pada insiden ketika keduanya paling penting.

Gerbang tiga: kunci mana, dan operasi mana

Penandatanganan, dekripsi, pembuatan kunci, pembungkusan kunci, dan administrasi pengguna adalah izin terpisah dan harus didaftarkan secara terpisah. Dalam istilah PKCS#11, atribut seperti CKA_SENSITIVE dan CKA_EXTRACTABLE menjelaskan apakah materi kunci dapat keluar dari modul dalam bentuk yang dapat dipakai, dan atribut itu ditetapkan per kunci, bukan per perangkat. Baca kebijakan sebenarnya pada kunci alih-alih menyimpulkan ketidakdapatdieksporan dari kata perangkat keras atau dari keberadaan terowongan.

Lalu temukan persetujuan bisnis. Jika hanya dokumen yang disetujui yang boleh ditandatangani, komponen mana yang menetapkan persetujuan itu sebelum permintaan mencapai HSM? Antarmuka kriptografi yang menerima permintaan yang diotorisasi tidak tahu apakah dokumen telah ditinjau, jadi pemeriksaan itu milik layanan di depannya.

Klien yang diizinkan yang dikompromikan juga dapat menyalahgunakan operasi yang diotorisasi secara sah oleh kredensialnya tanpa pernah mengekstrak kunci privat. Melindungi materi kunci yang tersimpan dan mengendalikan penggunaan kunci karena itu adalah dua syarat penerimaan, bukan satu.

Penolakan adalah bagian dari uji penerimaan

Terima permintaan penandatanganan yang diizinkan, dan terima juga penolakannya: identitas tidak sah, kunci yang tidak terkait, dan operasi manajemen dari jalur mitra. Catat pemanggil, operasi, pengenal kunci, waktu, dan hasilnya, dan jauhkan materi kunci privat, kredensial, serta isi dokumen dari log diagnostik umum.

Tetapkan pemilik untuk pengeluaran mitra, untuk dugaan kompromi di sisi mitra, dan untuk perubahan kebijakan serta pemulihan. Mengubah rute tidak memulihkan kepercayaan pada host yang mungkin sudah dikompromikan, jadi pencabutan harus mencapai identitas HSM juga.

Jabat tangan VPN yang selesai termasuk dalam catatan itu. Itu tidak dapat menggantikan satu pun hasil khusus HSM.