Keandalan pada Azure Key Vault Managed HSM

Azure Key Vault Managed HSM adalah layanan cloud yang sepenuhnya dikelola, dengan ketersediaan tinggi, tenant tunggal, yang mematuhi standar, dan memungkinkan Anda melindungi kunci kriptografi untuk aplikasi cloud Anda dengan menggunakan modul keamanan perangkat keras (HSM) divalidasi FIPS 140-3 Level 3. HSM terkelola menyediakan berbagai fitur keandalan bawaan untuk membantu memastikan bahwa kunci Anda tetap tersedia.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan bagaimana HSM Terkelola tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, kegagalan perangkat keras, dan pemadaman wilayah. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan dan domain keamanan untuk memulihkan dari jenis masalah lain, fitur pemulihan untuk mencegah penghapusan yang tidak disengaja, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) HSM Terkelola.

Rekomendasi implementasi produksi untuk keandalan

Untuk beban kerja produksi, kami sarankan Anda:

Gambaran umum arsitektur keandalan

Saat Anda menggunakan HSM Terkelola, Anda menyebarkan instans, yang juga kadang-kadang disebut kumpulan.

HSM terkelola dirancang untuk ketersediaan dan durabilitas tinggi melalui arsitekturnya:

  • Isolasi penyewa tunggal: Setiap instans HSM Terkelola didedikasikan untuk satu pelanggan dan terdiri dari kluster beberapa partisi HSM yang terisolasi secara kriptografis.

  • Partisi dengan triple redundansi: Kumpulan HSM Terkelola terdiri dari tiga partisi HSM yang seimbang dalam pembagian beban yang didistribusikan di rak terpisah di dalam pusat data. Distribusi ini memberikan redundansi terhadap kegagalan perangkat keras dan memastikan bahwa hilangnya satu komponen (seperti catu daya rak atau sakelar jaringan) tidak memengaruhi semua partisi.

  • Komputasi rahasia: Setiap instans layanan berjalan di lingkungan eksekusi tepercaya (TEE) yang menggunakan enklave Intel SGX. Personel Microsoft, termasuk yang memiliki akses fisik ke server, tidak dapat mengakses materi kunci kriptografi Anda.

  • Penyembuhan otomatis: Jika kegagalan perangkat keras atau masalah lain memengaruhi salah satu dari tiga partisi, layanan secara otomatis membangun kembali partisi yang terpengaruh pada perangkat keras yang sehat tanpa intervensi pelanggan dan tanpa mengekspos rahasia.

Untuk informasi selengkapnya tentang bagaimana HSM Terkelola mengimplementasikan kemampuan ini, lihat Kedaulatan utama, ketersediaan, performa, dan skalabilitas di HSM Terkelola.

Domain keamanan

Domain keamanan adalah komponen penting untuk pemulihan bencana. Ini adalah blob terenkripsi yang berisi semua kredensial yang diperlukan untuk membangun kembali instans HSM Terkelola dari awal, termasuk kunci pemilik partisi, kredensial partisi, kunci pembungkus data, dan cadangan awal HSM.

Important

Tanpa domain keamanan, pemulihan bencana tidak dimungkinkan. Microsoft tidak memiliki cara untuk memulihkan domain keamanan dan tidak dapat mengakses kunci Anda tanpanya.

Domain keamanan adalah bagian penting dari keamanan dan keandalan HSM Terkelola Anda. Kami sarankan Anda mengikuti praktik terbaik ini:

  • Hasilkan kunci dengan aman: Untuk lingkungan produksi, hasilkan pasangan kunci RSA yang melindungi domain keamanan di lingkungan terisolasi (seperti sebuah HSM lokal atau sebuah stasiun kerja terisolasi).
  • Simpan offline: Simpan kunci domain keamanan pada drive USB terenkripsi atau penyimpanan offline lainnya, dengan setiap berbagi kunci pada perangkat terpisah di lokasi geografis terpisah.
  • Menetapkan kuorum multi-orang: Gunakan setidaknya tiga pemegang kunci untuk mencegah setiap orang memiliki akses ke semua kunci kuorum, dan untuk menghindari dependensi pada satu orang.

Untuk informasi selengkapnya, lihat Domain keamanan di Ringkasan HSM Terkelola.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Saat Anda menggunakan layanan Azure yang terintegrasi dengan HSM Terkelola, layanan tersebut menangani kesalahan sementara secara otomatis.

Jika Anda membangun aplikasi kustom yang terintegrasi dengan HSM Terkelola, pertimbangkan praktik terbaik berikut untuk menangani kesalahan sementara yang mungkin terjadi:

  • Gunakan SDK yang disediakan Microsoft untuk Azure Key Vault, yang mencakup mekanisme coba lagi bawaan. SDK tersedia untuk .NET, Python, dan JavaScript.

  • Terapkan logika coba ulang saat mereka berinteraksi langsung dengan HSM Terkelola, termasuk kebijakan coba ulang dengan penundaan eksponensial.

  • Kurangi jumlah dependensi langsung pada HSM Terkelola. Cache hasil operasi kriptografi untuk mengurangi permintaan langsung ke HSM Terkelola jika memungkinkan. Untuk operasi kunci publik seperti enkripsi, pembungkusan, dan verifikasi, lakukan operasi ini secara lokal dengan menyimpan materi kunci publik. Melakukan operasi secara lokal mengurangi dependensi pada HSM Terkelola Anda dan menghindari gangguan sementara yang dapat mengganggu operasi ini.

Jika Anda menggunakan HSM Terkelola dalam skenario throughput tinggi, perhatikan bahwa HSM Terkelola tidak membatasi operasi kriptografi. Ini menggunakan perangkat keras HSM-nya dengan kapasitas penuh. Setiap instans HSM Terkelola memiliki tiga partisi. Selama operasi pemeliharaan atau penyembuhan, satu partisi mungkin tidak tersedia. Untuk perencanaan kapasitas, asumsikan bahwa dua partisi tersedia. Jika Anda memerlukan throughput terjamin, rencanakan dengan mempertimbangkan satu partisi yang tersedia. Pantau metrik Ketersediaan HSM Terkelola untuk memahami kesehatan layanan.

Untuk menskalakan enkripsi data dalam jumlah besar, gunakan hierarki kunci di mana hanya kunci enkripsi kunci (KEK) yang disimpan di HSM Terkelola dan digunakan untuk membungkus kunci tingkat bawah yang disimpan di lokasi penyimpanan kunci aman lainnya.

Untuk tolak ukur kinerja terperinci dan panduan perencanaan kapasitas, silakan lihat Panduan Penskalaan Azure Managed HSM.

Ketahanan terhadap kegagalan partisi

HSM terkelola mencapai ketersediaan tinggi melalui arsitektur tiga-redundan, di mana setiap kumpulan HSM terdiri dari tiga partisi HSM yang didistribusikan di rak server terpisah dalam pusat data. Distribusi tingkat rak ini memberikan redundansi terhadap kegagalan perangkat keras yang dilokalkan.

Diagram yang memperlihatkan tiga partisi kumpulan HSM Terkelola, masing-masing di server fisik terpisah dan di rak server yang berbeda.

Ketika kegagalan perangkat keras atau pemadaman yang dilokalkan terjadi, HSM Terkelola secara otomatis mengalihkan permintaan Anda ke partisi yang sehat dan membangun kembali partisi yang terpengaruh melalui proses yang disebut penyembuhan layanan rahasia. Partisi yang gagal secara otomatis dibuat ulang menggunakan perangkat keras yang sehat dengan dukungan TLS yang dibuktikan dan enklave Intel SGX guna melindungi rahasia selama pemulihan.

Biaya

Tidak ada biaya tambahan yang terkait dengan ketersediaan tinggi bawaan di HSM Terkelola. Harga didasarkan pada jumlah kumpulan HSM dan jumlah operasi yang dilakukan. Untuk informasi selengkapnya, lihat Harga Azure Managed HSM.

Fungsi ketika semua partisi berfungsi dengan baik

Bagian ini menjelaskan apa yang diharapkan ketika kumpulan HSM Terkelola beroperasi dan tidak ada partisi yang tidak tersedia.

  • Perutean lalu lintas: HSM terkelola secara otomatis mengelola perutean lalu lintas di tiga partisinya. Selama operasi normal, permintaan didistribusikan di seluruh partisi secara transparan.

  • Replikasi data: Semua data, termasuk kunci, penetapan peran, dan kebijakan kontrol akses, direplikasi secara sinkron di ketiga partisi. Ini memastikan konsistensi dan ketersediaan meskipun partisi menjadi tidak tersedia.

Perilaku selama kegagalan partisi

Bagian ini menjelaskan apa yang diharapkan ketika satu atau beberapa partisi menjadi tidak tersedia.

  • Deteksi dan respons: Layanan HSM Terkelola bertanggung jawab untuk mendeteksi kegagalan partisi dan secara otomatis meresponsnya. Anda tidak perlu mengambil tindakan apa pun selama kegagalan partisi.

  • Permintaan aktif: Selama kegagalan partisi, permintaan dalam penerbangan ke partisi yang terpengaruh mungkin gagal dan mengharuskan aplikasi klien untuk mencobanya kembali. Untuk meminimalkan efek pemadaman partisi, aplikasi klien harus mengikuti praktik penanganan kesalahan sementara.

  • Kehilangan data yang diharapkan: Tidak ada kehilangan data yang diharapkan selama kegagalan partisi karena replikasi sinkron di seluruh partisi.

  • Waktu henti yang diharapkan: Untuk operasi baca dan sebagian besar operasi kriptografi, seharusnya ada minimal hingga tidak ada waktu henti selama kegagalan partisi. Partisi sehat yang tersisa tetap memproses permintaan.

  • Pengalihan lalu lintas: HSM terkelola secara otomatis mengalihkan lalu lintas dari partisi yang terpengaruh ke partisi yang sehat tanpa memerlukan intervensi pelanggan.

Pemulihan partisi

Ketika partisi yang terpengaruh pulih, Managed HSM secara otomatis memulihkan operasi melalui pemulihan layanan secara aman. Proses ini:

  1. Membuat instans layanan baru pada perangkat keras yang sehat.
  2. Membentuk koneksi TLS yang terverifikasi dengan partisi utama.
  3. Bertukar kredensial dan materi kriptografi dengan aman.
  4. Segel data layanan ke CPU baru.

Platform Azure sepenuhnya mengelola proses ini dan tidak memerlukan intervensi pelanggan.

Ketahanan terhadap kegagalan zona ketersediaan

Daya tahan tinggi Managed HSM bergantung pada distribusi tingkat rak di dalam pusat data, bukan pada penyebaran zona ketersediaan yang eksplisit. Setiap partisi berjalan pada server terpisah di rak yang berbeda, yang melindungi dari kegagalan tingkat rak seperti catu daya atau masalah sakelar jaringan.

Jika Anda harus tahan terhadap pemadaman di seluruh pusat data atau zona ketersediaan, pertimbangkan untuk menggunakan salah satu pendekatan untuk ketahanan terhadap kegagalan di seluruh wilayah.

Ketahanan terhadap kegagalan di seluruh wilayah

Sumber daya HSM terkelola disebarkan ke dalam satu wilayah Azure. Jika wilayah menjadi tidak tersedia, HSM Terkelola Anda juga tidak tersedia. Namun, ada pendekatan yang dapat Anda gunakan untuk membantu memastikan ketahanan terhadap pemadaman wilayah.

Replikasi multi-wilayah

HSM terkelola mendukung replikasi multi-wilayah opsional, yang memungkinkan Anda memperluas kumpulan HSM Terkelola dari satu wilayah Azure ( wilayah utama) ke wilayah Azure kedua ( wilayah yang diperluas). Setelah dikonfigurasi:

  • Kedua wilayah aktif dan dapat melayani permintaan.
  • Materi utama, peran, dan izin secara otomatis direplikasi antar wilayah.
  • Permintaan dirutekan ke wilayah terdekat yang tersedia menggunakan Azure Traffic Manager.
  • SLA gabungan meningkat.

Requirements

  • Dukungan wilayah: Semua wilayah Azure Managed HSM didukung sebagai wilayah utama. Tidak ada ketergantungan pada pengelompokan wilayah Azure.

    HSM terkelola tidak mendukung semua wilayah sebagai wilayah yang diperluas. Untuk informasi selengkapnya, lihat Dukungan wilayah Azure.

  • Jumlah maksimum wilayah: Anda dapat menambahkan satu wilayah yang diperluas, untuk maksimal dua wilayah secara total.

Biaya

Replikasi multi-wilayah menimbulkan penagihan tambahan karena kumpulan HSM kedua digunakan di wilayah yang diperluas. Untuk informasi selengkapnya, lihat Harga Azure Managed HSM.

Mengonfigurasi replikasi multi-wilayah

Perilaku ketika semua wilayah sehat

Ketika replikasi multi-wilayah diaktifkan dan kedua wilayah beroperasi:

  • Perutean lalu lintas: Semua wilayah dapat melayani permintaan. Azure Traffic Manager merutekan permintaan ke wilayah dengan kedekatan geografis terdekat atau latensi terendah.

    Jika Anda menggunakan Private Link, konfigurasikan titik akhir privat di kedua wilayah untuk perutean optimal saat failover. Untuk informasi selengkapnya, lihat Perilaku tautan privat dengan replikasi multi-wilayah.

  • Replikasi data: Semua perubahan pada kunci, definisi peran, dan penetapan peran direplikasi secara asinkron ke wilayah yang diperluas dalam waktu enam menit. Tunggu enam menit setelah membuat atau memperbarui kunci sebelum menggunakannya di wilayah yang diperluas.

Perilaku selama kegagalan wilayah

Ketika replikasi multi-wilayah diaktifkan dan satu wilayah mengalami pemadaman:

  • Deteksi dan respons: Azure Traffic Manager mendeteksi wilayah yang tidak sehat dan merutekan permintaan di masa mendatang ke wilayah yang sehat. Catatan DNS memiliki TTL lima detik, meskipun klien yang menyimpan cache pencarian DNS mungkin mengalami waktu failover yang sedikit lebih lama.
  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Permintaan dalam penerbangan ke wilayah yang terpengaruh mungkin gagal dan memerlukan coba lagi.

  • Kehilangan data yang diharapkan: Mungkin ada kehilangan data untuk perubahan yang dilakukan dalam waktu enam menit sebelum kegagalan wilayah jika perubahan tersebut belum menyelesaikan replikasi.

  • Waktu henti yang diharapkan: Operasi baca dan tulis tetap tersedia di wilayah yang sehat selama failover.

    Aplikasi klien yang dekat dengan wilayah yang tidak sehat mungkin terus diarahkan ke wilayah tersebut sampai rekaman DNS diperbarui, tetapi pembaruan ini terjadi dalam waktu sekitar lima detik. Untuk meminimalkan waktu failover, klien harus menghindari penyimpanan sementara pencarian DNS lebih lama dari waktu TTL rekaman DNS.

  • Perutean ulang: Azure Traffic Manager secara otomatis mengalihkan permintaan ke wilayah yang sehat.

Pemulihan wilayah

Ketika wilayah yang terpengaruh pulih, HSM Terkelola secara otomatis melanjutkan operasi. Traffic Manager mulai merutekan permintaan ke kedua wilayah lagi berdasarkan kedekatan.

Pengujian untuk mendeteksi kegagalan wilayah

HSM terkelola sepenuhnya mengelola perutean lalu lintas, failover, dan failback untuk kegagalan wilayah, sehingga Anda tidak perlu memvalidasi proses kegagalan wilayah atau memberikan input lebih lanjut.

Solusi multi-wilayah kustom untuk ketahanan

Jika replikasi multi-wilayah tidak cocok untuk kebutuhan Anda, Anda dapat menerapkan pemulihan bencana manual. Ini membutuhkan:

  • Domain keamanan sumber HSM.
  • Kunci privat (setidaknya nomor kuorum) yang mengenkripsi domain keamanan.
  • Cadangan penuh HSM terbaru dari HSM sumber.

Untuk melakukan pemulihan bencana:

  1. Buat instans HSM Terkelola baru di wilayah yang berbeda.
  2. Aktifkan mode pemulihan domain keamanan dan unggah domain keamanan.
  3. Ambil cadangan HSM baru (diperlukan sebelum pemulihan).
  4. Pulihkan cadangan dari sumber HSM.

Important

HSM baru memiliki nama dan URI titik akhir layanan yang berbeda. Anda harus memperbarui konfigurasi aplikasi untuk menggunakan lokasi baru.

Untuk prosedur pemulihan bencana terperinci, lihat Pemulihan bencana HSM terkelola.

Pencadangan dan pemulihan

HSM terkelola mendukung pencadangan dan pemulihan penuh semua kunci, versi, atribut, tag, dan penetapan peran. Cadangan disimpan di akun Azure Storage. Jika wilayah Anda mendukungnya, kami sarankan Anda mencadangkan HSM Terkelola ke akun Azure Storage yang mengaktifkan penyimpanan redundansi geografis (GRS).

Cadangan dienkripsi menggunakan kunci kriptografi yang terkait dengan domain keamanan HSM dan hanya dapat dipulihkan ke HSM dengan domain keamanan yang sama.

HSM terkelola tidak mendukung penjadwalan cadangan, tetapi Anda dapat membangun penjadwal Anda sendiri dengan menggunakan layanan seperti Azure Functions atau Azure Automation.

Saat pencadangan sedang berlangsung, HSM mungkin tidak beroperasi pada throughput penuh karena beberapa partisi sibuk melakukan operasi pencadangan.

Untuk prosedur pencadangan dan pemulihan terperinci, lihat Pencadangan dan pemulihan penuh.

Ketahanan terhadap penghapusan yang tidak disengaja

HSM terkelola menyediakan dua fitur pemulihan utama untuk mencegah penghapusan yang tidak disengaja atau berbahaya:

  • Penghapusan sementara: Saat Anda menghapus HSM atau kunci, data tersebut tetap dapat dipulihkan selama periode retensi yang bisa dikonfigurasi (7 hingga 90 hari, default 90 hari). Penghapusan sementara selalu diaktifkan dan tidak dapat dinonaktifkan.

    Note

    Sumber daya HSM Terkelola yang dihapus sementara terus dikenakan biaya hingga dihapus sepenuhnya.

  • Perlindungan penghapusan menyeluruh: Saat diaktifkan, mencegah penghapusan permanen HSM Terkelola Anda dan kuncinya hingga periode retensi berlalu. Perlindungan penghapusan tidak dapat dinonaktifkan atau dilangkahi oleh siapa pun, termasuk Microsoft.

Kami sangat menyarankan untuk mengaktifkan proteksi penghapusan untuk lingkungan produksi. Untuk informasi selengkapnya, lihat Perlindungan penghapusan sementara dan penghapusan menyeluruh HSM terkelola.

Ketahanan terhadap pemeliharaan layanan

HSM terkelola menangani pemeliharaan layanan, termasuk pembaruan firmware, patching, dan penyembuhan perangkat keras, tanpa intervensi pelanggan. Selama pemeliharaan:

  • Partisi mungkin sementara tidak tersedia saat pembaruan diterapkan.
  • Setidaknya dua dari tiga partisi tetap tersedia selama pemeliharaan rutin.
  • Aplikasi klien Anda harus menerapkan logika coba lagi untuk menangani gangguan singkat.

Proses penyembuhan layanan rahasia memastikan bahwa rahasia tidak pernah terekspos selama operasi pemeliharaan.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

HSM terkelola menyediakan SLA standar untuk penyebaran wilayah tunggal. Saat Anda mengaktifkan replikasi multi-wilayah, SLA gabungan untuk kedua wilayah akan meningkat.

Konten terkait

  • Last updated on