Model enkripsi data

Untuk memahami bagaimana penyedia sumber daya Azure menerapkan enkripsi saat tidak aktif, Anda perlu memahami model enkripsi yang berbeda dan kelebihan dan kekurangannya. Untuk memastikan bahasa umum dan taksonomi, penyedia sumber daya Azure berbagi definisi ini.

Azure secara otomatis mengenkripsi data saat tidak digunakan dengan menggunakan kunci yang dikelola oleh platform Azure. Anda dapat secara opsional memilih pendekatan manajemen kunci lainnya berdasarkan persyaratan keamanan dan kepatuhan Anda. Ada tiga skenario untuk enkripsi sisi server:

• Enkripsi sisi server menggunakan kunci yang dikelola platform (default)

  • Penyedia sumber daya Azure melakukan operasi enkripsi dan dekripsi.
  • Microsoft mengelola kunci secara otomatis.
  • Diaktifkan secara default tanpa konfigurasi yang diperlukan.
  • Fungsionalitas cloud penuh.

• Enkripsi sisi server menggunakan kunci yang dikelola pelanggan di Azure Key Vault (opsional)

  • Penyedia sumber daya Azure melakukan operasi enkripsi dan dekripsi.
  • Anda mengontrol kunci melalui Azure Key Vault.
  • Memerlukan konfigurasi dan manajemen pelanggan.
  • Fungsionalitas cloud penuh.

• Enkripsi sisi server menggunakan kunci yang dikelola pelanggan pada perangkat keras yang dikontrol pelanggan (opsi tingkat lanjut)

  • Penyedia sumber daya Azure melakukan operasi enkripsi dan dekripsi.
  • Anda mengontrol kunci pada perangkat keras yang dikendalikan pelanggan.
  • Konfigurasi kompleks dan dukungan layanan Azure terbatas.
  • Fungsionalitas cloud penuh.

Model enkripsi sisi server mengacu pada enkripsi yang dilakukan layanan Azure. Dalam model itu, penyedia sumber daya melakukan operasi enkripsi dan dekripsi. Misalnya, Azure Storage mungkin menerima data dalam operasi teks biasa dan melakukan enkripsi dan dekripsi secara internal. Penyedia sumber daya mungkin menggunakan kunci enkripsi yang dikelola Microsoft atau pelanggan, tergantung pada konfigurasi yang disediakan.

Masing-masing model enkripsi saat istirahat sisi server memiliki karakteristik manajemen kunci yang khas. Karakteristik ini mencakup di mana dan bagaimana Anda membuat dan menyimpan kunci enkripsi, serta model akses dan prosedur rotasi kunci.

Untuk enkripsi sisi klien, pertimbangkan:

• Layanan Azure tidak dapat melihat data yang didekripsi.
• Pelanggan mengelola dan menyimpan kunci secara lokal (atau di toko aman lainnya). Layanan Azure tidak memiliki akses ke kunci.
• Mengurangi fungsionalitas cloud.

Model enkripsi yang didukung di Azure dibagi menjadi dua grup utama: Enkripsi Klien dan Enkripsi Sisi Server. Terlepas dari model enkripsi saat istirahat yang Anda gunakan, layanan Azure selalu merekomendasikan penggunaan transportasi aman seperti TLS atau HTTPS. Oleh karena itu, enkripsi dalam transportasi harus diatasi oleh protokol transportasi dan tidak boleh menjadi faktor utama dalam menentukan model enkripsi saat istirahat mana yang akan digunakan.

Model enkripsi klien

Model enkripsi klien mengacu pada enkripsi yang dilakukan layanan atau aplikasi panggilan di luar Penyedia Sumber Daya atau Azure. Aplikasi layanan di Azure atau aplikasi yang berjalan di pusat data pelanggan dapat melakukan enkripsi. Dalam kedua kasus, ketika Anda menggunakan model enkripsi ini, Azure Resource Provider menerima blob data terenkripsi tanpa kemampuan untuk mendekripsi data dengan cara apa pun atau mengakses kunci enkripsi. Dalam model ini, layanan panggilan atau aplikasi menangani manajemen kunci dan membuatnya tidak terlihat oleh layanan Azure.

Enkripsi sisi server menggunakan kunci yang dikelola platform (default)

Bagi sebagian besar pelanggan, persyaratan pentingnya adalah memastikan bahwa data dienkripsi setiap kali tidak aktif. Enkripsi sisi server menggunakan kunci yang dikelola platform (sebelumnya disebut kunci yang dikelola layanan) memenuhi persyaratan ini dengan menyediakan enkripsi otomatis secara default. Pendekatan ini memungkinkan enkripsi tidak aktif tanpa mengharuskan pelanggan untuk mengonfigurasi atau mengelola kunci enkripsi apa pun, meninggalkan semua aspek manajemen utama seperti penerbitan kunci, rotasi, dan pencadangan ke Microsoft.

Sebagian besar layanan Azure menerapkan model ini sebagai perilaku default, secara otomatis mengenkripsi data tidak aktif dengan menggunakan kunci yang dikelola platform tanpa memerlukan tindakan pelanggan. Penyedia sumber daya Azure membuat kunci, menempatkannya di penyimpanan yang aman, dan mengambilnya saat diperlukan. Layanan ini memiliki akses penuh ke kunci dan mempertahankan kontrol penuh atas manajemen siklus hidup kredensial, memberikan perlindungan enkripsi yang kuat dengan overhead manajemen nol untuk pelanggan.

Enkripsi sisi server dengan menggunakan kunci yang dikelola platform mengatasi kebutuhan enkripsi saat tidak aktif dengan overhead nol kepada pelanggan. Enkripsi ini diaktifkan secara default di seluruh layanan Azure, memberikan perlindungan data otomatis tanpa memerlukan konfigurasi atau manajemen pelanggan apa pun. Pelanggan mendapat manfaat dari perlindungan enkripsi yang kuat segera setelah menyimpan data di layanan Azure, tanpa langkah tambahan, biaya, atau manajemen berkelanjutan yang diperlukan.

Enkripsi sisi server dengan kunci yang dikelola platform menyiratkan layanan memiliki akses penuh untuk menyimpan dan mengelola kunci. Meskipun beberapa pelanggan mungkin ingin mengelola kunci karena mereka merasa mereka mendapatkan keamanan yang lebih besar, pertimbangkan biaya dan risiko yang terkait dengan solusi penyimpanan kunci kustom saat mengevaluasi model ini. Dalam banyak kasus, organisasi mungkin menentukan bahwa batasan sumber daya atau risiko solusi lokal lebih besar dari risiko manajemen cloud enkripsi saat kunci tidak aktif. Namun, model ini mungkin tidak cukup bagi organisasi yang memiliki persyaratan untuk mengontrol pembuatan atau siklus hidup kunci enkripsi atau memiliki personel yang berbeda mengelola kunci enkripsi layanan daripada yang mengelola layanan (yaitu, pemisahan manajemen kunci dari model manajemen keseluruhan untuk layanan).

Akses kunci

Saat Anda menggunakan enkripsi sisi server dengan kunci yang dikelola platform, layanan mengelola pembuatan kunci, penyimpanan, dan akses layanan. Biasanya, penyedia sumber daya Azure dasar menyimpan Kunci Enkripsi Data di penyimpanan yang dekat dengan data dan dapat diakses dengan cepat, sementara Kunci Enkripsi Kunci disimpan di penyimpanan internal yang aman.

Kelebihan

• Penyiapan sederhana.
• Microsoft mengelola rotasi kunci, pencadangan, dan redundansi.
• Anda tidak dikenakan biaya atau risiko yang terkait dengan penerapan skema manajemen kunci kustom.

Pertimbangan

• Tidak ada kontrol pelanggan atas kunci enkripsi (spesifikasi kunci, siklus hidup, pencabutan, dll.). Opsi ini cocok untuk sebagian besar kasus penggunaan tetapi mungkin tidak memenuhi persyaratan kepatuhan khusus.
• Tidak ada kemampuan untuk memisahkan manajemen kunci dari model manajemen keseluruhan untuk layanan. Organisasi yang memerlukan pemisahan tugas mungkin memerlukan kunci yang dikelola pelanggan.

Enkripsi sisi server menggunakan kunci yang dikelola pelanggan di Azure Key Vault dan Azure Managed HSM (opsional)

Untuk skenario di mana organisasi memiliki persyaratan khusus untuk mengontrol kunci enkripsi mereka di luar enkripsi yang dikelola platform default, pelanggan dapat secara opsional memilih enkripsi sisi server dengan menggunakan kunci yang dikelola pelanggan di Key Vault atau Azure Managed HSM. Pendekatan ini dibangun di atas enkripsi default saat tidak aktif, memungkinkan pelanggan untuk menggunakan kunci mereka sendiri sementara Azure terus menangani operasi enkripsi dan dekripsi.

Beberapa layanan mungkin hanya menyimpan Kunci Enkripsi Kunci akar di Azure Key Vault dan menyimpan Kunci Enkripsi Data terenkripsi di lokasi internal yang lebih dekat dengan data. Dalam skenario ini, pelanggan dapat membawa kunci mereka sendiri ke Key Vault (BYOK – Bring Your Own Key) atau membuat kunci baru, dan menggunakannya untuk mengenkripsi sumber daya yang diinginkan. Meskipun Penyedia Sumber Daya melakukan operasi enkripsi dan dekripsi, Penyedia Sumber Daya menggunakan kunci enkripsi kunci yang dikonfigurasi pelanggan sebagai kunci akar untuk semua operasi enkripsi.

Kehilangan kunci enkripsi utama berarti kehilangan data. Untuk alasan ini, jangan hapus kunci. Selalu cadangkan kunci saat Anda membuat atau memutarnya. Untuk melindungi dari penghapusan kriptografi yang tidak disengaja atau berbahaya, perlindungan Soft-Delete dan perlindungan pemusnahan harus diaktifkan pada brankas apa pun yang menyimpan kunci enkripsi kunci. Alih-alih menghapus kunci, atur status diaktifkan menjadi false pada kunci enkripsi utama. Gunakan kontrol akses untuk mencabut akses ke setiap pengguna atau layanan di Azure Key Vault atau HSM Terkelola.

Catatan

Untuk daftar layanan yang mendukung kunci yang dikelola pelanggan di Azure Key Vault dan Azure Managed HSM, lihat Layanan yang mendukung CMK di Azure Key Vault dan Azure Managed HSM.

Akses kunci

Model enkripsi sisi server dengan kunci yang dikelola pelanggan di Azure Key Vault melibatkan layanan yang mengakses kunci untuk mengenkripsi dan mendekripsi sesuai kebutuhan. Anda membuat enkripsi saat tidak aktif dapat diakses oleh layanan melalui kebijakan kontrol akses. Kebijakan ini memberikan akses identitas layanan untuk menerima kunci. Anda dapat mengonfigurasi layanan Azure yang berjalan atas nama langganan terkait dengan identitas dalam langganan tersebut. Layanan ini dapat melakukan autentikasi Microsoft Entra dan menerima token autentikasi yang mengidentifikasi dirinya sebagai layanan yang bertindak atas nama langganan. Layanan kemudian menyajikan token ke Key Vault untuk mendapatkan kunci yang telah diberi akses.

Untuk operasi yang menggunakan kunci enkripsi, Anda dapat memberikan akses identitas layanan ke salah satu operasi berikut: mendekripsi, mengenkripsi, membukaKunci, membungkusKunci, memverifikasi, menandatangani, mendapatkan, mendaftar, memperbarui, membuat, mengimpor, menghapus, mencadangkan, dan memulihkan.

Untuk mendapatkan kunci yang digunakan untuk mengenkripsi atau mendekripsi data saat disimpan, identitas layanan yang menjalankan instans layanan Resource Manager harus memiliki UnwrapKey (untuk mendapatkan kunci untuk dekripsi) dan WrapKey (untuk memasukkan kunci ke dalam brankas kunci saat membuat kunci baru).

Catatan

Untuk detail selengkapnya tentang otorisasi Key Vault, lihat halaman amankan brankas kunci Anda di dokumentasi Azure Key Vault.

Kelebihan

• Kontrol penuh atas kunci yang digunakan - kunci enkripsi dikelola di Key Vault Anda di bawah kontrol Anda.
• Kemampuan untuk mengenkripsi beberapa layanan ke satu master.
• Dapat memisahkan manajemen kunci dari model manajemen keseluruhan untuk layanan.
• Dapat menentukan layanan dan lokasi utama di seluruh wilayah.

Kerugian

• Anda memiliki tanggung jawab penuh untuk manajemen akses kunci.
• Anda memiliki tanggung jawab penuh untuk manajemen siklus hidup utama.
• Overhead tambahan untuk penyiapan dan konfigurasi.

Enkripsi sisi server menggunakan kunci yang dikelola pelanggan dalam perangkat keras yang dikontrol pelanggan (opsi khusus)

Beberapa layanan Azure mengaktifkan model manajemen kunci Host Your Own Key (HYOK) untuk organisasi dengan persyaratan keamanan khusus. Mode manajemen ini berguna dalam skenario yang sangat diatur di mana ada persyaratan untuk mengenkripsi data dalam keadaan diam dan mengelola kunci dalam repositori milik sendiri sepenuhnya di luar kendali Microsoft, di luar enkripsi yang secara default dikelola platform dan kunci opsional yang dikelola pelanggan di Azure Key Vault.

Dalam model ini, layanan harus menggunakan kunci dari situs eksternal untuk mendekripsi Kunci Enkripsi Data (DEK). Jaminan performa dan ketersediaan terpengaruh, dan konfigurasi secara signifikan lebih kompleks. Selain itu, karena layanan tidak memiliki akses ke DEK selama operasi enkripsi dan dekripsi, jaminan keamanan keseluruhan model ini mirip dengan ketika kunci dikelola pelanggan di Azure Key Vault. Akibatnya, model ini tidak sesuai untuk sebagian besar organisasi kecuali mereka memiliki persyaratan peraturan atau keamanan yang sangat spesifik yang tidak dapat dipenuhi dengan kunci yang dikelola platform atau kunci yang dikelola pelanggan di Azure Key Vault. Karena keterbatasan ini, sebagian besar layanan Azure tidak mendukung enkripsi sisi server menggunakan kunci yang dikelola pelanggan di perangkat keras yang dikontrol pelanggan. Salah satu dari dua kunci dalam Enkripsi Kunci Ganda mengikuti model ini.

Akses kunci

Saat Anda menggunakan enkripsi sisi server dengan kunci yang dikelola pelanggan di perangkat keras yang dikontrol pelanggan, Anda mempertahankan kunci enkripsi kunci pada sistem yang Anda konfigurasikan. Layanan Azure yang mendukung model ini menyediakan cara untuk membuat koneksi aman ke penyimpanan kunci yang disediakan pelanggan.

Kelebihan

• Anda memiliki kontrol penuh atas kunci akar yang digunakan, karena kunci enkripsi dikelola oleh penyimpanan yang disediakan pelanggan.
• Kemampuan mengenkripsi beberapa layanan ke satu master.
• Dapat memisahkan manajemen kunci dari model manajemen keseluruhan untuk layanan.
• Dapat menentukan layanan dan lokasi utama di seluruh wilayah.

Kerugian

• Anda memiliki tanggung jawab penuh atas penyimpanan utama, keamanan, performa, dan ketersediaan.
• Anda memiliki tanggung jawab penuh untuk manajemen akses kunci.
• Anda memiliki tanggung jawab penuh untuk manajemen siklus hidup utama.
• Anda dikenakan biaya pengaturan, konfigurasi, dan pemeliharaan yang berkelanjutan yang signifikan.
• Ada peningkatan dependensi pada ketersediaan jaringan antara pusat data pelanggan dan pusat data Azure.

Konten terkait

• Layanan yang mendukung CMK di Azure Key Vault dan Azure Managed HSM
• Cara enkripsi digunakan di Azure
• Enkripsi ganda