Keandalan pada Azure Key Vault Managed HSM

Azure Key Vault Managed HSM adalah layanan cloud yang dikelola sepenuhnya, sangat tersedia, penyewa tunggal, sesuai standar yang memungkinkan Anda melindungi kunci kriptografi untuk aplikasi cloud Anda dengan menggunakan modul keamanan perangkat keras (HSM) yang divalidasi ke 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 partisi, dan pemadaman wilayah. Ini juga menjelaskan cara menggunakan cadangan dan domain keamanan untuk pemulihan bencana, bagaimana fitur pemulihan melindungi dari penghapusan yang tidak disengaja, dan informasi utama tentang perjanjian tingkat layanan (SLA) HSM Terkelola.

Rekomendasi penyebaran produksi

Untuk beban kerja produksi, kami sarankan Anda:

  • Unduh dan simpan domain keamanan dengan aman segera setelah menyediakan HSM Terkelola Anda. Anda memerlukan domain keamanan untuk pemulihan bencana.
  • Tetapkan kuorum multi-pihak untuk domain keamanan dengan setidaknya tiga pemegang kunci.
  • Aktifkan perlindungan penghapusan menyeluruh untuk mencegah penghapusan yang tidak disengaja atau berbahaya.
  • Terapkan pencadangan reguler ke akun Azure Storage, dan gunakan penyimpanan geo-redundan di wilayah yang didukung.
  • Aktifkan replikasi multiregion untuk beban kerja misi penting yang memerlukan SLA yang lebih tinggi.

Gambaran umum arsitektur keandalan

Saat Anda menggunakan HSM Terkelola, Anda menyebarkan instans, yang terkadang disebut kumpulan.

Arsitektur HSM Terkelola dirancang untuk ketersediaan dan durabilitas tinggi.

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

  • Partisi redundan rangkap tiga: Pool HSM Terkelola terdiri atas tiga partisi HSM dengan penyeimbangan beban yang didistribusikan di rak-rak terpisah dalam satu 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. Microsoft personel, termasuk individu dengan 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 mempelajari bagaimana HSM Terkelola mengimplementasikan kemampuan ini, lihat Kedaulatan kunci, ketersediaan, performa, dan skalabilitas di HSM Terkelola.

Domain keamanan

Domain keamanan adalah komponen penting dari HSM Terkelola untuk tujuan 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 menyarankan agar Anda mengikuti praktik terbaik ini:

  • Buat kunci dengan aman: Untuk lingkungan produksi, buat pasangan kunci RSA yang melindungi domain keamanan dalam lingkungan yang terisolasi dari jaringan, seperti HSM lokal atau stasiun kerja yang 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.

  • Tetapkan kuorum multi-pihak: Gunakan setidaknya tiga pemegang kunci untuk mencegah satu orang memiliki akses ke semua kunci kuorum, dan untuk menghindari ketergantungan 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 lagi, termasuk backoff eksponensial, untuk kode apa pun yang berinteraksi langsung dengan HSM Terkelola.

  • Kurangi jumlah dependensi langsung pada HSM Terkelola. Cache hasil operasi kriptografi untuk mengurangi permintaan langsung ke HSM Terkelola jika memungkinkan. Lakukan operasi kunci publik, seperti enkripsi, pembungkusan, dan verifikasi, secara lokal dengan menyimpan material kunci publik dalam cache. Melakukan operasi secara lokal mengurangi dependensi pada HSM Terkelola Anda dan mengurangi kemungkinan kesalahan sementara yang mengganggu operasi ini.

Jika Anda menggunakan HSM Terkelola dalam skenario dengan throughput tinggi, HSM Terkelola tidak membatasi laju 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 untuk volume data besar, gunakan hierarki kunci. Simpan hanya kunci enkripsi kunci (KEK) di HSM Terkelola, dan gunakan untuk membungkus kunci enkripsi data tingkat bawah yang disimpan di tempat lain dalam penyimpanan kunci yang aman.

Untuk informasi selengkapnya tentang tolok ukur performa dan perencanaan kapasitas, lihat panduan penskalaan HSM Terkelola Azure.

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 dibangun ulang pada perangkat keras yang sehat menggunakan TLS yang diatestasi dan enklave Intel SGX untuk melindungi data rahasia selama pemulihan.

Biaya

Ketersediaan tinggi bawaan di Managed HSM tidak menambahkan biaya tambahan apa pun. Harga didasarkan pada jumlah kumpulan HSM dan jumlah operasi yang Anda lakukan. 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, ia secara transparan mendistribusikan permintaan di seluruh partisi.

  • Replikasi data: HSM terkelola secara sinkron mereplikasi semua data, termasuk kunci, penetapan peran, dan kebijakan kontrol akses, di ketiga partisi. Pendekatan 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 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, harus ada minimal atau 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

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

Untuk melindungi dari pemadaman di seluruh pusat data atau zona ketersediaan, gunakan salah satu pendekatan yang dijelaskan dalam 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 multiregion

HSM terkelola mendukung replikasi multiregion opsional, yang dapat Anda gunakan untuk memperluas kumpulan HSM Terkelola dari satu wilayah Azure (wilayah utama) ke wilayah Azure kedua (wilayah yang diperluas). Saat Anda mengonfigurasi fitur ini:

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

Requirements

  • Dukungan wilayah: Semua wilayah yang mendukung HSM Terkelola dapat digunakan 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 multiregion menimbulkan penagihan tambahan karena wilayah yang diperluas mengonsumsi kumpulan HSM kedua. Untuk informasi selengkapnya, lihat Harga Azure Managed HSM.

Mengonfigurasi replikasi multiregsi

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi replikasi multiregion, 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 Azure Private Link untuk mengakses HSM Terkelola, konfigurasikan titik akhir privat di kedua wilayah untuk perutean optimal selama failover. Untuk informasi selengkapnya, lihat Perilaku tautan privat dengan replikasi multiregion.

  • 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

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi replikasi multiregion, dan ada pemadaman di salah satu wilayah replika.

  • Deteksi dan respons: Azure Traffic Manager mendeteksi wilayah yang tidak sehat dan merutekan permintaan di masa mendatang ke wilayah yang sehat. Catatan DNS memiliki waktu hidup lima detik (TTL), 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: Perubahan yang dilakukan dalam waktu enam menit sebelum kegagalan wilayah mungkin tidak direplikasi ke wilayah yang diperluas. Perubahan tersebut dapat hilang jika wilayah utama tidak dapat dipulihkan.

  • 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. Azure 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 multiregion kustom untuk ketahanan

Jika replikasi multiregion tidak sesuai dengan kebutuhan Anda, Anda dapat menerapkan pemulihan bencana manual. Pendekatan ini memerlukan:

  • 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 geo-redundan (GRS).

HSM mengenkripsi cadangan dengan menggunakan kunci kriptografi yang terkait dengan domain keamanan HSM. Anda hanya dapat memulihkan cadangan 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 lunak: HSM dan kunci yang dihapus tidak langsung dihapus secara permanen. Mereka tetap dapat dipulihkan untuk periode retensi yang dapat 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 hapus permanen: Saat diaktifkan, fitur ini mencegah Managed HSM dan kunci-kuncinya dihapus secara permanen hingga masa retensi berakhir. 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:

  • Layanan mungkin untuk sementara membuat partisi tidak tersedia saat menerapkan pembaruan.
  • 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 layanan tidak pernah mengekspos rahasia 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 ketersediaan standar untuk penyebaran wilayah tunggal. Mengaktifkan replikasi multiregion meningkatkan waktu aktif yang diharapkan secara keseluruhan, karena permintaan dapat dilayani dari salah satu wilayah jika satu menjadi tidak tersedia.

Konten terkait

  • Last updated on