Kunci yang dikelola pelanggan untuk enkripsi Azure Storage

Anda dapat menggunakan kunci enkripsi Anda sendiri untuk melindungi data di akun penyimpanan Anda. Saat Anda menentukan kunci yang dikelola pelanggan, kunci tersebut digunakan untuk melindungi dan mengontrol akses ke kunci yang mengenkripsi data Anda. Kunci yang dikelola pelanggan menawarkan fleksibilitas yang lebih besar untuk mengelola kontrol akses.

Anda harus menggunakan salah satu penyimpanan kunci Azure berikut ini untuk menyimpan kunci yang dikelola pelanggan Anda:

Anda dapat membuat kunci Anda sendiri dan menyimpannya di brankas kunci atau HSM terkelola, atau Anda dapat menggunakan API Azure Key Vault untuk membuat kunci. Akun penyimpanan dan brankas kunci atau HSM terkelola dapat berada di penyewa, wilayah, dan langganan Microsoft Entra yang berbeda.

Catatan

Azure Key Vault dan Azure Key Vault Managed HSM mendukung API dan antarmuka manajemen yang sama untuk konfigurasi kunci yang dikelola pelanggan. Tindakan apa pun yang didukung untuk Azure Key Vault juga didukung untuk Azure Key Vault Managed HSM.

Tentang kunci yang dikelola pelanggan

Diagram berikut menunjukkan bagaimana Azure Storage menggunakan ID Microsoft Entra dan brankas kunci atau HSM terkelola untuk membuat permintaan menggunakan kunci yang dikelola pelanggan:

Diagram showing how customer-managed keys work in Azure Storage

Daftar berikut ini menjelaskan langkah-langkah bernomor dalam diagram:

  1. Admin Azure Key Vault memberikan izin untuk memasukkan kunci enkripsi ke identitas terkelola. Identitas terkelola mungkin merupakan identitas terkelola yang ditetapkan pengguna yang Anda buat dan kelola, atau identitas terkelola yang ditetapkan sistem yang terkait dengan akun penyimpanan.
  2. Admin Azure Storage mengonfigurasi enkripsi dengan kunci yang dikelola pelanggan untuk akun penyimpanan.
  3. Azure Storage menggunakan identitas terkelola tempat admin Azure Key Vault memberikan izin di langkah 1 untuk mengautentikasi akses ke Azure Key Vault melalui ID Microsoft Entra.
  4. Azure Storage membungkus kunci enkripsi akun dengan kunci yan dikelola pelanggan di Azure Key Vault.
  5. Untuk operasi baca/tulis, Azure Storage mengirimkan permintaan ke Azure Key Vault untuk membongkar kunci enkripsi akun demi melakukan operasi enkripsi dan dekripsi.

Identitas terkelola yang terkait dengan akun penyimpanan harus memiliki izin ini minimal untuk mengakses kunci yang dikelola pelanggan di Azure Key Vault:

  • wrapkey
  • unwrapkey
  • get

Untuk informasi selengkapnya tentang izin kunci, lihat Jenis kunci, algoritma, dan operasi.

Azure Policy menyediakan kebijakan bawaan untuk mengharuskan akun penyimpanan menggunakan kunci yang dikelola pelanggan untuk beban kerja Azure Blob Storage dan Azure Files. Untuk informasi selengkapnya, lihat bagian Penyimpanan di definisi kebijakan bawaan Azure Policy.

Kunci yang dikelola pelanggan untuk antrean dan tabel

Data yang disimpan dalam penyimpanan Antrean dan Tabel tidak secara otomatis dilindungi oleh kunci yang dikelola pelanggan saat kuncinya diaktifkan untuk akun penyimpanan. Anda dapat secara opsional mengonfigurasi layanan ini untuk disertakan dalam perlindungan pada saat Anda membuat akun penyimpanan.

Untuk informasi selengkapnya tentang cara membuat akun penyimpanan yang mendukung kunci yang dikelola pelanggan untuk antrean dan tabel, lihat Membuat akun yang mendukung kunci yang dikelola pelanggan untuk tabel dan antrean.

Data dalam penyimpanan Blob dan File Azure selalu dilindungi oleh kunci yang dikelola pelanggan saat kuncinya dikonfigurasi untuk akun penyimpanan.

Aktifkan kunci yang dikelola pelanggan untuk akun penyimpanan

Saat Anda mengonfigurasi kunci yang dikelola pelanggan untuk akun penyimpanan, Azure Storage membungkus kunci enkripsi data akar untuk akun dengan kunci yang dikelola pelanggan di brankas kunci terkait atau HSM terkelola. Perlindungan kunci enkripsi akar berubah, tetapi data di akun Azure Storage Anda tetap dienkripsi setiap saat. Tidak ada tindakan tambahan yang diperlukan pada bagian Anda untuk memastikan bahwa data Anda tetap dienkripsi. Perlindungan oleh kunci yang dikelola pelanggan segera berlaku.

Anda dapat beralih antara kunci yang dikelola pelanggan dan kunci yang dikelola Microsoft kapan saja. Untuk informasi selengkapnya tentang kunci yang dikelola Microsoft, lihat Tentang manajemen kunci enkripsi.

Persyaratan brankas kunci

Brankas kunci atau HSM terkelola yang menyimpan kunci harus mengaktifkan penghapusan sementara dan perlindungan penghapusan menyeluruh. Enkripsi penyimpanan Azure mendukung kunci RSA dan RSA-HSM ukuran 2048, 3072 dan 4096. Untuk informasi selengkapnya tentang kunci, lihat Tentang kunci.

Menggunakan brankas kunci atau HSM terkelola memiliki biaya terkait. Untuk informasi selengkapnya, lihat harga Key Vault.

Kunci yang dikelola pelanggan dengan brankas kunci di penyewa yang sama

Anda dapat mengonfigurasi kunci yang dikelola pelanggan dengan brankas kunci dan akun penyimpanan di penyewa yang sama atau di penyewa Microsoft Entra yang berbeda. Untuk mempelajari cara mengonfigurasi enkripsi Azure Storage dengan kunci yang dikelola pelanggan saat brankas kunci dan akun penyimpanan berada di penyewa yang sama, lihat salah satu artikel berikut ini:

Saat Mengaktifkan kunci yang dikelola pelanggan dengan brankas kunci di penyewa yang sama, Anda harus menentukan identitas terkelola yang akan digunakan untuk mengotorisasi akses ke brankas kunci yang berisi kunci. Identitas terkelola mungkin berupa identitas terkelola yang ditetapkan pengguna atau yang ditetapkan sistem:

  • Saat Anda mengonfigurasi kunci yang dikelola oleh pelanggan pada saat Anda membuat akun penyimpanan, Anda harus menggunakan identitas terkelola yang ditetapkan oleh pengguna.
  • Saat Anda mengonfigurasi kunci terkelola pelanggan pada akun penyimpanan yang sudah ada, Anda dapat menggunakan identitas terkelola yang ditetapkan pengguna atau identitas terkelola yang ditetapkan sistem.

Untuk mempelajari lebih lanjut identitas terkelola yang ditetapkan sistem versus identitas terkelola yang ditetapkan pengguna, lihat Identitas terkelola untuk sumber daya Azure. Untuk mempelajari cara membuat dan mengelola identitas terkelola yang ditetapkan pengguna, lihat Mengelola identitas terkelola yang ditetapkan pengguna.

Kunci yang dikelola pelanggan dengan brankas kunci di penyewa yang berbeda

Untuk mempelajari cara mengonfigurasi enkripsi Azure Storage dengan kunci yang dikelola pelanggan saat brankas kunci dan akun penyimpanan berada di penyewa Microsoft Entra yang berbeda, lihat salah satu artikel berikut ini:

Kunci yang dikelola pelanggan dengan HSM terkelola

Anda dapat mengonfigurasi kunci yang dikelola pelanggan dengan Azure Key Vault Managed HSM untuk akun baru atau yang sudah ada. Dan Anda dapat mengonfigurasi kunci yang dikelola pelanggan dengan HSM terkelola yang berada di penyewa yang sama dengan akun penyimpanan, atau di penyewa yang berbeda. Proses untuk mengonfigurasi kunci yang dikelola pelanggan di HSM terkelola sama dengan untuk mengonfigurasi kunci yang dikelola pelanggan dalam brankas kunci, tetapi izinnya sedikit berbeda. Untuk informasi selengkapnya, lihat Mengonfigurasi enkripsi dengan kunci yang dikelola pelanggan yang disimpan di Azure Key Vault Managed HSM.

Perbarui versi kunci

Mengikuti praktik terbaik kriptografi berarti memutar kunci yang melindungi akun penyimpanan Anda pada jadwal reguler, biasanya setidaknya setiap dua tahun. Azure Storage tidak pernah memodifikasi kunci di brankas kunci, tetapi Anda dapat mengonfigurasi kebijakan rotasi kunci untuk memutar kunci sesuai dengan persyaratan kepatuhan Anda. Untuk informasi selengkapnya, lihat Mengonfigurasi rotasi otomatis kunci kriptografi di Azure Key Vault.

Setelah kunci diputar di brankas kunci, konfigurasi kunci yang dikelola pelanggan untuk akun penyimpanan Anda harus diperbarui untuk menggunakan versi kunci baru. Kunci yang dikelola pelanggan mendukung pembaruan otomatis dan manual versi kunci untuk kunci yang melindungi akun. Anda dapat memutuskan pendekatan mana yang ingin Anda gunakan saat mengonfigurasi kunci yang dikelola pelanggan, atau saat memperbarui konfigurasi.

Saat Anda memodifikasi kunci atau versi kunci, perlindungan kunci enkripsi akar berubah, tetapi data di akun Azure Storage Anda tetap dienkripsi setiap saat. Tidak ada tindakan tambahan yang diperlukan di bagian Anda untuk memastikan bahwa data Anda dilindungi. Memutar versi kunci tidak memengaruhi performa. Tidak ada waktu henti yang terkait dengan memutar versi kunci.

Penting

Untuk memutar kunci, buat versi baru kunci di brankas kunci atau HSM terkelola, sesuai dengan persyaratan kepatuhan Anda. Azure Storage tidak menangani rotasi kunci, jadi Anda harus mengelola rotasi kunci di brankas kunci.

Saat Anda memutar kunci yang digunakan untuk kunci yang dikelola pelanggan, tindakan tersebut saat ini tidak dicatat ke log Azure Monitor untuk Azure Storage.

Memperbarui versi kunci secara otomatis

Untuk memperbarui kunci yang dikelola pelanggan secara otomatis saat versi baru tersedia, hilangkan versi kunci saat Anda mengaktifkan enkripsi dengan kunci yang dikelola pelanggan untuk akun penyimpanan. Jika versi kunci dihilangkan, Azure Storage akan memeriksa Azure Key Vault atau HSM terkelola setiap hari demi kunci yang dikelola pelanggan versi baru. Jika versi kunci baru tersedia, Azure Storage akan otomatis menggunakan versi kunci terbaru.

Azure Storage memeriksa brankas kunci untuk versi kunci baru hanya sekali setiap hari. Saat Anda memutar kunci, pastikan untuk menunggu 24 jam sebelum menonaktifkan versi yang lebih lama.

Jika akun penyimpanan sebelumnya dikonfigurasi untuk pembaruan manual versi kunci dan Anda ingin mengubahnya untuk diperbarui secara otomatis, Anda mungkin perlu secara eksplisit mengubah versi kunci menjadi string kosong. Untuk detail tentang cara melakukannya, lihat Mengonfigurasi enkripsi untuk pembaruan otomatis versi kunci.

Memperbarui versi kunci secara manual

Untuk menggunakan versi kunci tertentu untuk enkripsi Azure Storage, tentukan versi kunci tersebut saat Anda mengaktifkan enkripsi dengan kunci yang dikelola pelanggan untuk akun penyimpanan. Jika Anda menentukan versi kunci, maka Azure Storage menggunakan versi tersebut untuk enkripsi hingga Anda memperbarui versi kunci secara manual.

Ketika versi kunci secara eksplisit ditentukan, maka Anda harus memperbarui akun penyimpanan secara manual untuk menggunakan URI versi kunci baru saat versi baru dibuat. Untuk mempelajari cara memperbarui akun penyimpanan demi menggunakan versi kunci baru, lihat Mengonfigurasi enkripsi dengan kunci yang dikelola pelanggan yang disimpan di Azure Key Vault atau Mengonfigurasi enkripsi dengan kunci yang dikelola pelanggan yang disimpan di Azure Key Vault Managed HSM.

Mencabut akses ke akun penyimpanan yang menggunakan kunci yang dikelola pelanggan

Untuk mencabut akses ke akun penyimpanan yang menggunakan kunci yang dikelola pelanggan, nonaktifkan kunci di brankas kunci. Untuk mempelajari cara menonaktifkan kunci, lihat Mencabut akses ke akun penyimpanan yang menggunakan kunci yang dikelola pelanggan.

Setelah kunci dinonaktifkan, klien tidak dapat memanggil operasi yang membaca dari atau menulis ke sumber daya atau metadatanya. Upaya untuk memanggil operasi ini akan gagal dengan kode kesalahan 403 (Terlarang) untuk semua pengguna.

Untuk memanggil operasi ini lagi, pulihkan akses ke kunci yang dikelola pelanggan.

Semua operasi data yang tidak tercantum di bagian berikut dapat dilanjutkan setelah kunci yang dikelola pelanggan dicabut atau setelah kunci dinonaktifkan atau dihapus.

Untuk mencabut akses ke kunci yang dikelola pelanggan, gunakan PowerShell atau Azure CLI.

Operasi Penyimpanan Blob yang gagal setelah kunci dicabut

Operasi Azure Files yang gagal setelah kunci dicabut

Kunci yang dikelola pelanggan untuk cakram yang dikelola Azure

Kunci yang dikelola pelanggan juga tersedia untuk mengelola enkripsi cakram yang dikelola Azure. Kunci yang dikelola pelanggan berperilaku berbeda untuk cakram terkelola alih-alih sumber daya Azure Storage. Untuk informasi selengkapnya, lihat Enkripsi sisi server cakram terkelola Azure untuk Windows atau Enkripsi sisi server dari cakram terkelola Azure untuk Linux.

Langkah berikutnya