Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Praktik terbaik untuk AWS CloudHSM
Lakukan praktik terbaik dalam topik ini untuk digunakan secara efektif AWS CloudHSM.
Manajemen klaster
Ikuti praktik terbaik di bagian ini saat membuat, mengakses, dan mengelola AWS CloudHSM klaster Anda.
Skala klaster Anda untuk menangani lalu lintas puncak
Beberapa faktor dapat memengaruhi throughput maksimum yang dapat ditangani klaster Anda, termasuk ukuran instans klien, ukuran cluster, topografi jaringan, dan operasi kriptografi yang Anda perlukan untuk kasus penggunaan Anda.
Sebagai titik awal, lihat topik AWS CloudHSM Kinerja untuk perkiraan kinerja pada ukuran dan konfigurasi cluster umum. Kami menyarankan Anda menguji beban klaster Anda dengan beban puncak yang Anda antisipasi untuk menentukan apakah arsitektur Anda saat ini tangguh dan pada skala yang tepat.
Arsitek cluster Anda untuk ketersediaan tinggi
Tambahkan redundansi ke akun untuk pemeliharaan: AWS dapat mengganti HSM Anda untuk pemeliharaan terjadwal atau jika mendeteksi masalah. Sebagai aturan umum, ukuran cluster Anda harus memiliki setidaknya +1 redundansi. Misalnya, jika Anda memerlukan dua HSM agar layanan Anda beroperasi pada waktu puncak, ukuran cluster ideal Anda akan menjadi tiga. Jika Anda mengikuti praktik terbaik terkait ketersediaan, penggantian HSM ini seharusnya tidak memengaruhi layanan Anda. Namun, operasi yang sedang berlangsung pada HSM yang diganti mungkin gagal dan harus dicoba ulang.
Sebarkan HSM Anda di banyak Availability Zone: Pertimbangkan bagaimana layanan Anda akan dapat beroperasi selama pemadaman Availability Zone. AWS merekomendasikan agar Anda menyebarkan HSM Anda di sebanyak mungkin Availability Zone. Untuk cluster dengan tiga HSM, Anda harus menyebarkan HSM di tiga Availability Zone. Tergantung pada sistem Anda, Anda mungkin memerlukan redundansi tambahan.
Memiliki setidaknya tiga HSM untuk memastikan daya tahan kunci yang baru dihasilkan
Untuk aplikasi yang membutuhkan daya tahan kunci yang baru dibuat, sebaiknya sedikitnya tiga HSM tersebar di Availability Zone yang berbeda di suatu wilayah.
Akses aman ke klaster Anda
Gunakan subnet pribadi untuk membatasi akses ke instans Anda: Luncurkan HSM dan instance klien Anda di subnet pribadi VPC Anda. Ini membatasi akses ke HSM Anda dari dunia luar.
Gunakan titik akhir VPC untuk mengakses API: Pesawat AWS CloudHSM data dirancang untuk beroperasi tanpa memerlukan akses ke internet atau AWS API. Jika instance klien Anda memerlukan akses ke AWS CloudHSM API, Anda dapat menggunakan titik akhir VPC untuk mengakses API tanpa memerlukan akses internet pada instance klien Anda. Untuk informasi selengkapnya, lihat AWS CloudHSM dan titik akhir VPC.
Konfigurasi ulang SSL untuk mengamankan komunikasi client-server: AWS CloudHSM menggunakan TLS untuk membuat koneksi ke HSM Anda. Setelah Anda menginisialisasi cluster Anda, Anda dapat mengganti sertifikat TLS default dan kunci yang digunakan untuk membuat koneksi TLS luar. Untuk informasi selengkapnya, lihat Tingkatkan keamanan server web Anda dengan pembongkaran SSL/TLS di AWS CloudHSM.
Kurangi biaya dengan menskalakan kebutuhan Anda
Tidak ada biaya dimuka untuk digunakan AWS CloudHSM. Anda membayar biaya per jam untuk setiap HSM yang Anda luncurkan sampai Anda mengakhiri HSM. Jika layanan Anda tidak memerlukan penggunaan terus-menerus AWS CloudHSM, Anda dapat mengurangi biaya dengan mengurangi (menghapus) HSM Anda menjadi nol ketika tidak diperlukan. Ketika HSM diperlukan lagi, Anda dapat memulihkan HSM Anda dari cadangan. Jika, misalnya, Anda memiliki beban kerja yang mengharuskan Anda menandatangani kode sebulan sekali, khususnya pada hari terakhir bulan itu, Anda dapat meningkatkan skala klaster Anda sebelumnya, menurunkannya dengan menghapus HSM Anda setelah pekerjaan selesai, dan kemudian memulihkan klaster Anda untuk melakukan operasi penandatanganan lagi di akhir bulan berikutnya.
AWS CloudHSM secara otomatis membuat cadangan berkala dari HSM di cluster. Saat menambahkan HSM baru di kemudian hari, AWS CloudHSM akan mengembalikan cadangan terbaru ke HSM baru sehingga Anda dapat melanjutkan penggunaan dari tempat yang sama dengan Anda meninggalkannya. Untuk menghitung biaya AWS CloudHSM arsitektur Anda, lihat AWS CloudHSM Harga
Sumber daya terkait:
Manajemen pengguna HSM
Ikuti praktik terbaik di bagian ini untuk mengelola pengguna secara efektif di AWS CloudHSM klaster Anda. Pengguna HSM berbeda dari pengguna IAM. Pengguna dan entitas IAM yang memiliki kebijakan berbasis identitas dengan izin yang sesuai dapat membuat HSM dengan berinteraksi dengan sumber daya melalui AWS API. Setelah HSM dibuat, Anda harus menggunakan kredensyal pengguna HSM untuk mengautentikasi operasi pada HSM. Untuk panduan rinci tentang pengguna HSM, lihatMengelola pengguna HSM di AWS CloudHSM.
Lindungi kredensi pengguna HSM Anda
Sangat penting untuk menjaga kredensyal pengguna HSM Anda terlindungi dengan aman karena pengguna HSM adalah entitas yang dapat mengakses dan melakukan operasi kriptografi dan manajemen pada HSM Anda. AWS CloudHSM tidak memiliki akses ke kredensyal pengguna HSM Anda, dan tidak akan dapat membantu Anda jika Anda kehilangan akses ke mereka.
Memiliki setidaknya dua admin untuk mencegah penguncian
Untuk menghindari terkunci dari klaster Anda, kami sarankan Anda memiliki setidaknya dua admin jika satu kata sandi admin hilang. Jika ini terjadi, Anda dapat menggunakan admin lain untuk mengatur ulang kata sandi.
catatan
Admin di Client SDK 5 identik dengan crypto officer (CO) di Client SDK 3.
Aktifkan kuorum untuk semua operasi manajemen pengguna
Kuorum memungkinkan Anda untuk menetapkan jumlah min admin yang harus menyetujui operasi manajemen pengguna sebelum operasi itu dapat dilakukan. Karena hak istimewa yang dimiliki admin, kami menyarankan Anda mengaktifkan kuorum untuk semua operasi manajemen pengguna. Ini dapat membatasi potensi dampak jika salah satu kata sandi admin Anda disusupi. Untuk informasi selengkapnya, lihat Mengelola Kuorum.
Buat beberapa pengguna crypto, masing-masing dengan izin terbatas
Dengan memisahkan tanggung jawab pengguna crypto, tidak ada satu pengguna yang memiliki kendali penuh atas seluruh sistem. Untuk alasan ini, kami sarankan Anda membuat beberapa pengguna kripto dan membatasi izin masing-masing. Biasanya, ini dilakukan dengan memberi pengguna crypto yang berbeda tanggung jawab dan tindakan yang berbeda yang mereka lakukan (misalnya, memiliki satu pengguna crypto yang bertanggung jawab untuk membuat dan berbagi kunci dengan pengguna kripto lain yang kemudian menggunakannya dalam aplikasi Anda).
Sumber daya terkait:
Manajemen kunci HSM
Ikuti praktik terbaik di bagian ini saat mengelola kunci AWS CloudHSM.
Pilih jenis tombol yang tepat
Saat menggunakan kunci sesi, transaksi per detik (TPS) Anda akan dibatasi pada satu HSM di mana kunci tersebut ada. HSM ekstra di cluster Anda tidak akan meningkatkan throughput permintaan untuk kunci itu. Jika Anda menggunakan kunci token untuk aplikasi yang sama, permintaan Anda akan diseimbangkan di semua HSM yang tersedia di klaster Anda. Untuk informasi selengkapnya, lihat Sinkronisasi kunci dan pengaturan daya tahan di AWS CloudHSM.
Kelola batas penyimpanan utama
HSM memiliki batasan jumlah maksimum token dan kunci sesi yang dapat disimpan pada HSM pada satu waktu. Untuk informasi tentang batas penyimpanan utama, lihatAWS CloudHSM kuota. Jika aplikasi Anda membutuhkan lebih dari batas, Anda dapat menggunakan satu atau beberapa strategi berikut untuk mengelola kunci secara efektif:
Gunakan pembungkus tepercaya untuk menyimpan kunci Anda di penyimpanan data eksternal: Menggunakan pembungkus kunci tepercaya, Anda dapat mengatasi batas penyimpanan kunci dengan menyimpan semua kunci Anda yang dibungkus di dalam penyimpanan data eksternal. Ketika Anda diminta untuk menggunakan kunci ini, Anda dapat membuka kunci ke HSM sebagai kunci sesi, menggunakan kunci untuk operasi yang Anda butuhkan, dan kemudian membuang kunci sesi. Data kunci asli tetap disimpan dengan aman di penyimpanan data Anda untuk digunakan kapan pun Anda membutuhkannya. Menggunakan kunci tepercaya untuk melakukan ini memaksimalkan perlindungan Anda.
Mendistribusikan kunci di seluruh cluster: Strategi lain untuk mengatasi batas penyimpanan kunci adalah menyimpan kunci Anda dalam beberapa cluster. Dalam pendekatan ini, Anda mempertahankan pemetaan kunci yang disimpan di setiap cluster. Gunakan pemetaan ini untuk merutekan permintaan klien Anda ke cluster dengan kunci yang diperlukan. Untuk informasi tentang cara menyambung ke beberapa cluster dari aplikasi klien yang sama, lihat topik berikut:
Mengelola dan mengamankan pembungkus kunci
Kunci dapat ditandai baik diekstraksi atau tidak dapat diekstraksi melalui atribut. EXTRACTABLE Secara default, kunci HSM ditandai sebagai dapat diekstraksi.
Kunci yang dapat diekstraksi adalah kunci yang diizinkan untuk diekspor dari HSM melalui pembungkus kunci. Kunci yang dibungkus dienkripsi, dan harus dibuka menggunakan kunci pembungkus yang sama sebelum dapat digunakan. Kunci yang tidak dapat diekstraksi tidak boleh diekspor dari HSM dalam keadaan apa pun. Tidak ada cara untuk membuat kunci yang tidak dapat diekstraksi dapat diekstraksi. Untuk alasan ini, penting untuk mempertimbangkan apakah Anda memerlukan kunci Anda untuk diekstraksi atau tidak dan untuk mengatur atribut kunci yang sesuai.
Jika Anda memerlukan pembungkus kunci dalam aplikasi Anda, Anda harus menggunakan pembungkus kunci tepercaya untuk membatasi kemampuan pengguna HSM Anda untuk hanya membungkus/membuka kunci yang telah secara eksplisit ditandai sebagai dipercaya oleh admin. Untuk informasi selengkapnya, lihat topik tentang pembungkus kunci tepercaya. Mengelola kunci di AWS CloudHSM
Sumber daya terkait
Integrasi aplikasi
Ikuti praktik terbaik di bagian ini untuk mengoptimalkan cara aplikasi Anda terintegrasi dengan AWS CloudHSM klaster Anda.
Bootstrap SDK Klien Anda
Sebelum SDK klien Anda dapat terhubung ke cluster Anda, itu harus di-bootstrap. Saat mem-bootstrapping alamat IP ke cluster Anda, sebaiknya gunakan --cluster-id parameter jika memungkinkan. Metode ini mengisi konfigurasi Anda dengan semua alamat IP HSM di cluster Anda tanpa perlu melacak setiap alamat individual. Melakukan hal ini menambah ketahanan ekstra pada inisialisasi aplikasi Anda jika HSM sedang menjalani pemeliharaan atau selama pemadaman Zona Ketersediaan. Untuk detail selengkapnya, lihat Bootstrap Klien SDK.
Otentikasi untuk melakukan operasi
Di AWS CloudHSM, Anda harus mengautentikasi ke cluster Anda sebelum Anda dapat melakukan sebagian besar operasi seperti operasi kriptografi.
Otentikasi dengan CloudHSM CLI : Anda dapat mengautentikasi dengan CloudHSM CLI menggunakan mode perintah tunggal atau mode interaktif. Gunakan login perintah untuk mengautentikasi dalam mode interaktif. Untuk mengautentikasi dalam mode perintah tunggal, Anda harus mengatur variabel lingkungan CLOUDHSM_ROLE danCLOUDHSM_PIN. Untuk detail tentang melakukan ini, lihatMode Perintah Tunggal. AWS CloudHSM merekomendasikan untuk menyimpan kredensyal HSM Anda dengan aman saat tidak digunakan oleh aplikasi Anda.
Otentikasi dengan PKCS #11: Di PKCS #11, Anda masuk menggunakan C_Login API setelah membuka sesi menggunakan C_. OpenSession Anda hanya perlu melakukan satu C_Login per slot (cluster). Setelah Anda berhasil masuk, Anda dapat membuka sesi tambahan menggunakan C_ OpenSession tanpa perlu melakukan operasi login tambahan. Untuk contoh tentang autentikasi ke PKCS #11, lihat. Contoh kode untuk pustaka PKCS #11
Otentikasi dengan JCE: Penyedia AWS CloudHSM JCE mendukung login implisit dan eksplisit. Metode yang bekerja untuk Anda tergantung pada kasus penggunaan Anda. Jika memungkinkan, sebaiknya gunakan Implicit Login karena SDK akan secara otomatis menangani otentikasi jika aplikasi Anda terputus dari cluster Anda dan perlu diautentikasi ulang. Menggunakan login implisit juga memungkinkan Anda untuk memberikan kredensyal untuk aplikasi Anda ketika menggunakan integrasi yang tidak memungkinkan Anda untuk memiliki kontrol atas kode aplikasi Anda. Untuk selengkapnya tentang metode login, lihatMemberikan kredensi kepada penyedia JCE.
Otentikasi dengan OpenSSL: Dengan OpenSSL Dynamic Engine, Anda memberikan kredensyal melalui variabel lingkungan. AWS CloudHSM merekomendasikan untuk menyimpan kredensyal HSM Anda dengan aman saat tidak digunakan oleh aplikasi Anda. Jika memungkinkan, Anda harus mengonfigurasi lingkungan Anda untuk mengambil dan mengatur variabel lingkungan ini secara sistematis tanpa entri manual. Untuk detail tentang otentikasi dengan OpenSSL, lihat. Memasang OpenSSL Dynamic Engine
Mengelola kunci secara efektif dalam aplikasi Anda
Gunakan atribut kunci untuk mengontrol apa yang dapat dilakukan kunci: Saat membuat kunci, gunakan atribut kunci untuk menentukan serangkaian izin yang akan mengizinkan atau menolak jenis operasi tertentu untuk kunci tersebut. Kami menyarankan agar kunci dibuat dengan jumlah atribut paling sedikit yang diperlukan untuk menyelesaikan tugasnya. Misalnya, kunci AES yang digunakan untuk enkripsi juga tidak boleh diizinkan untuk membungkus kunci dari HSM. Untuk informasi selengkapnya, lihat halaman atribut kami untuk SDK Klien berikut:
Jika memungkinkan, cache objek kunci untuk meminimalkan latensi: Operasi pencarian kunci akan menanyakan setiap HSM di cluster Anda. Operasi ini mahal dan tidak berskala dengan jumlah HSM di cluster Anda.
Dengan PKCS #11, Anda menemukan kunci menggunakan API.
C_FindObjectsDengan JCE, Anda menemukan kunci menggunakan. KeyStore
Untuk kinerja yang optimal, AWS merekomendasikan agar Anda menggunakan perintah pencarian kunci (seperti findKey dandaftar kunci) hanya sekali selama aplikasi Anda start-up dan cache objek kunci yang dikembalikan dalam memori aplikasi. Jika Anda memerlukan objek kunci ini nanti, Anda harus mengambil objek dari cache Anda alih-alih menanyakan objek ini untuk setiap operasi yang akan menambahkan overhead kinerja yang signifikan.
Gunakan multi-threading
AWS CloudHSM mendukung aplikasi multi-threaded, tetapi ada hal-hal tertentu yang perlu diingat dengan aplikasi multi-threaded.
Dengan PKCS #11, Anda harus menginisialisasi pustaka PKCS #11 (memanggil) hanya sekali. C_Initialize Setiap thread harus diberi session sendiri (C_OpenSession). Menggunakan sesi yang sama di beberapa utas tidak disarankan.
Dengan JCE, AWS CloudHSM penyedia harus diinisialisasi hanya sekali. Jangan berbagi contoh objek SPI di seluruh utas. Misalnya, Cipher, Signature, Digest, Mac, KeyFactory atau KeyGenerator objek hanya boleh digunakan dalam konteks thread mereka sendiri.
Menangani kesalahan pelambatan
Anda mungkin mengalami kesalahan pelambatan HSM dalam keadaan berikut:
Cluster Anda tidak diskalakan dengan benar untuk mengelola lalu lintas puncak.
Cluster Anda tidak berukuran dengan redundansi +1 selama acara pemeliharaan.
Pemadaman Zona Ketersediaan mengakibatkan berkurangnya jumlah HSM yang tersedia di klaster Anda.
Lihat Pelambatan HSM untuk informasi tentang cara terbaik menangani skenario ini.
Untuk memastikan cluster Anda berukuran cukup dan tidak akan dibatasi, AWS sarankan Anda memuat tes di lingkungan Anda dengan lalu lintas puncak yang Anda harapkan.
Integrasikan percobaan ulang pada operasi cluster
AWS dapat menggantikan HSM Anda untuk alasan operasional atau pemeliharaan. Agar aplikasi Anda tahan terhadap situasi seperti itu, AWS rekomendasikan agar Anda menerapkan logika coba lagi sisi klien pada semua operasi yang dirutekan ke klaster Anda. Percobaan ulang berikutnya pada operasi yang gagal karena penggantian diharapkan berhasil.
Menerapkan strategi pemulihan bencana
Menanggapi suatu peristiwa, mungkin perlu mengalihkan lalu lintas Anda dari seluruh cluster atau wilayah. Bagian berikut menjelaskan beberapa strategi untuk melakukan ini.
Gunakan peering VPC untuk mengakses klaster Anda dari akun atau wilayah lain: Anda dapat memanfaatkan peering VPC untuk mengakses klaster Anda AWS CloudHSM dari akun atau wilayah lain. Untuk informasi tentang cara mengaturnya, lihat Apa itu VPC peering? dalam Panduan Peering VPC. Setelah Anda membuat koneksi peering dan mengonfigurasi grup keamanan Anda dengan tepat, Anda dapat berkomunikasi dengan alamat IP HSM dengan cara yang sama seperti biasanya.
Connect ke beberapa cluster dari aplikasi yang sama: Penyedia JCE, pustaka PKCS #11, dan CloudHSM CLI di Client SDK 5 mendukung koneksi ke beberapa cluster dari aplikasi yang sama. Misalnya, Anda dapat memiliki dua cluster aktif, masing-masing di wilayah yang berbeda, dan aplikasi Anda dapat terhubung ke keduanya sekaligus dan keseimbangan beban antara keduanya sebagai bagian dari operasi normal. Jika aplikasi Anda tidak menggunakan Client SDK 5 (SDK terbaru), maka Anda tidak dapat terhubung ke beberapa cluster dari aplikasi yang sama. Atau, Anda dapat menjaga cluster lain tetap aktif dan berjalan dan, jika ada pemadaman regional, alihkan lalu lintas Anda ke cluster lain untuk meminimalkan waktu henti. Lihat halaman masing-masing untuk detailnya:
Memulihkan klaster dari cadangan: Anda dapat membuat Cluster baru dari cadangan Cluster yang ada. Untuk informasi selengkapnya, lihat Mengelola AWS CloudHSM cadangan.
Pemantauan
Bagian ini menjelaskan beberapa mekanisme yang dapat Anda gunakan untuk memantau klaster dan aplikasi Anda. Untuk detail tambahan tentang pemantauan, lihatPemantauan AWS CloudHSM.
Pantau log klien
Setiap SDK Klien menulis log yang dapat Anda pantau. Untuk informasi tentang pencatatan klien, lihatBekerja dengan log SDK klien.
Pada platform yang dirancang untuk bersifat fana, seperti Amazon ECS dan AWS Lambda, mengumpulkan log klien dari file bisa jadi sulit. Dalam situasi ini, merupakan praktik terbaik untuk mengonfigurasi logging SDK Klien Anda untuk menulis log ke konsol. Sebagian besar layanan akan secara otomatis mengumpulkan output ini dan mempublikasikannya ke CloudWatch log Amazon untuk Anda simpan dan lihat.
Jika Anda menggunakan integrasi pihak ketiga apa pun di atas SDK AWS CloudHSM Klien, Anda harus memastikan bahwa Anda mengonfigurasi paket perangkat lunak tersebut untuk mencatat outputnya ke konsol juga. Output dari SDK AWS CloudHSM Klien dapat ditangkap oleh paket ini dan ditulis ke file lognya sendiri jika tidak.
Lihat informasi tentang cara mengonfigurasi opsi pencatatan di aplikasi Anda. Alat konfigurasi SDK 5 klien
Pantau log audit
AWS CloudHSM menerbitkan log audit ke CloudWatch akun Amazon Anda. Log audit berasal dari HSM dan melacak operasi tertentu untuk tujuan audit.
Anda dapat menggunakan log audit untuk melacak perintah manajemen apa pun yang dipanggil di HSM Anda. Misalnya, Anda dapat memicu alarm ketika Anda melihat operasi manajemen yang tidak terduga sedang dilakukan.
Lihat Cara kerja pencatatan audit HSM untuk detail selengkapnya.
Monitor AWS CloudTrail
AWS CloudHSM terintegrasi dengan AWS CloudTrail, layanan yang menyediakan catatan tindakan yang diambil oleh pengguna, peran, atau AWS layanan di AWS CloudHSM. AWS CloudTrail menangkap semua panggilan API untuk AWS CloudHSM sebagai peristiwa. Panggilan yang diambil termasuk panggilan dari AWS CloudHSM konsol dan panggilan kode ke operasi AWS CloudHSM API.
Anda dapat menggunakan AWS CloudTrail untuk mengaudit panggilan API apa pun yang dibuat ke bidang AWS CloudHSM kontrol untuk memastikan bahwa tidak ada aktivitas yang tidak diinginkan yang terjadi di akun Anda.
Lihat Bekerja dengan AWS CloudTrail dan AWS CloudHSM untuk detail.
Pantau CloudWatch metrik Amazon
Anda dapat menggunakan CloudWatch metrik Amazon untuk memantau AWS CloudHSM klaster Anda secara real time. Metrik dapat dikelompokkan berdasarkan wilayah, ID cluster, atau ID HSM dan ID cluster.
Dengan menggunakan CloudWatch metrik Amazon, Anda dapat mengonfigurasi CloudWatch alarm Amazon untuk memberi tahu Anda tentang potensi masalah yang mungkin timbul yang dapat memengaruhi layanan Anda. Kami merekomendasikan untuk mengonfigurasi alarm untuk memantau hal-hal berikut:
Mendekati batas kunci Anda pada HSM
Mendekati batas hitungan sesi HSM pada HSM
Mendekati batas jumlah pengguna HSM pada HSM
Perbedaan pengguna HSM atau jumlah kunci untuk mengidentifikasi masalah sinkronisasi
HSM yang tidak sehat untuk meningkatkan skala cluster Anda hingga AWS CloudHSM dapat menyelesaikan masalah
Untuk detail selengkapnya, lihat Bekerja dengan CloudWatch Log Amazon dan Log AWS CloudHSM Audit.
