Enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for MySQL

Dengan menggunakan enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for MySQL, Anda dapat menggunakan kunci Anda sendiri (BYOK) untuk perlindungan data saat disimpan guna menerapkan pemisahan tugas dalam pengelolaan kunci dan data. Saat Anda menggunakan kunci yang dikelola pelanggan (CMK), Anda mengontrol:

  • Manajemen siklus hidup utama, termasuk pembuatan kunci, unggahan, rotasi, dan penghapusan
  • Izin penggunaan utama
  • Mengaudit operasi pada kunci

Manfaat kunci yang dikelola pelanggan (CMK)

Enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for MySQL memberikan manfaat berikut:

  • Anda sepenuhnya mengontrol akses data dengan menghapus kunci dan membuat database tidak dapat diakses.
  • Anda memiliki kontrol penuh atas siklus hidup utama, termasuk rotasi kunci untuk menyelaraskan dengan kebijakan perusahaan.
  • Anda dapat mengelola dan mengatur kunci secara terpusat di Azure Key Vault atau HSM Terkelola.
  • Anda dapat menerapkan pemisahan tugas antara petugas keamanan, DBA, dan administrator sistem.

Bagaimana cara kerja enkripsi data dengan kunci yang dikelola pelanggan?

Identitas terkelola di MICROSOFT Entra ID menyediakan cara yang lebih aman untuk mengautentikasi klien ke layanan. Enkripsi CMK menggunakan identitas terkelola server Azure Database for MySQL untuk menyambungkan ke Azure Key Vault yang menyimpan CMK. Azure Database for MySQL saat ini hanya mendukung identitas terkelola yang ditetapkan pengguna (UAMI) untuk akses ke Key Vault. Untuk informasi selengkapnya, lihat Jenis identitas terkelola di Azure.

Untuk mengonfigurasi CMK untuk Azure Database for MySQL, tautkan UAMI ke server dan tentukan Azure Key Vault dan kunci yang akan digunakan.

UAMI memerlukan akses berikut ke Key Vault:

  • Get: Untuk mengambil bagian publik dan properti kunci di brankas kunci.
  • Daftar: Untuk mencantumkan versi kunci yang disimpan dalam Key Vault.
  • Kunci Bungkus: Untuk mengenkripsi DEK. DEK terenkripsi disimpan di instans server fleksibel Azure Database for MySQL.
  • Buka bungkus Kunci: Untuk mendekripsi DEK. Azure Database for MySQL memerlukan DEK yang didekripsi untuk mengenkripsi atau mendekripsi data.

Jika RBAC Azure diaktifkan, tetapkan peran ke UAMI alih-alih akses individual.

  • Key Vault Crypto Service Encryption User atau peran dengan izin:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read seperti "Pengguna Enkripsi Layanan Kripto Key Vault"
  • Untuk HSM Terkelola, tetapkan peran Managed HSM Crypto Service Encryption User

Atur enkripsi data dengan CMK di tingkat server. Untuk server tertentu, gunakan CMK, yang disebut kunci enkripsi kunci (KEK), untuk mengenkripsi kunci enkripsi data (DEK) layanan. KEK adalah kunci asimetris yang disimpan dalam instans Azure Key Vault milik pelanggan dan dikelola pelanggan. Key Vault adalah penyimpanan aman dengan ketersediaan tinggi dan skalabilitas untuk kunci kriptografi RSA, dengan dukungan opsional dari modul keamanan perangkat keras (HSM) yang tervalidasi FIPS 140. Key Vault tidak mengizinkan akses langsung ke kunci yang disimpan, tetapi sebaliknya menyediakan layanan enkripsi dan dekripsi dengan menggunakan kunci untuk entitas yang berwenang. Brankas kunci dapat menghasilkan kunci atau mentransfernya ke brankas kunci dari perangkat HSM lokal.

Saat Anda mengonfigurasi server fleksibel untuk menggunakan CMK yang disimpan di brankas kunci, server mengirimkan DEK ke brankas kunci untuk enkripsi. Key Vault mengembalikan DEK terenkripsi yang disimpan dalam database pengguna. Demikian pula, server fleksibel mengirimkan DEK yang dilindungi ke brankas kunci untuk dekripsi saat diperlukan.

Diagram cara kerja enkripsi data dengan kunci yang dikelola pelanggan.

Setelah Anda mengaktifkan pengelogan, auditor dapat menggunakan Azure Monitor untuk meninjau log peristiwa audit Key Vault. Untuk mengaktifkan pencatatan peristiwa audit Key Vault, lihat Memantau layanan Key Vault Anda dengan Key Vault insights.

Note

Perubahan izin dapat memakan waktu hingga 10 menit untuk memengaruhi brankas kunci.

Persyaratan untuk mengonfigurasi enkripsi data Azure Database for MySQL

Sebelum Anda mencoba mengonfigurasi Key Vault atau Managed HSM, pastikan untuk memenuhi persyaratan berikut.

  • Instans server fleksibel Key Vault dan Azure Database for MySQL harus milik penyewa Microsoft Entra yang sama. Key Vault antar-tenant dan interaksi server yang fleksibel perlu didukung. Anda perlu mengonfigurasi ulang enkripsi data jika memindahkan sumber daya Key Vault setelah melakukan konfigurasi.
  • Instans server fleksibel Key Vault dan Azure Database for MySQL harus berada di wilayah yang sama.
  • Aktifkan fitur Soft Delete pada key vault.
  • Aktifkan Perlindungan Penghapusan Menyeluruh.
  • Atur periode retensi menjadi 90 hari.
    • Tindakan pemulihan dan pembersihan permanen memiliki izin tersendiri dalam kebijakan akses Key Vault.
    • Fitur penghapusan sementara nonaktif secara default.

Sebelum mengonfigurasi CMK, pastikan persyaratan berikut telah dipenuhi.

  • Kunci yang dikelola pelanggan untuk mengenkripsi DEK hanya dapat berupa asimetris, RSA\RSA-HSM(Vaults dengan SKU Premium) 2048, 3072, atau 4096.
  • Tanggal aktivasi kunci (jika ditetapkan) harus berupa tanggal dan waktu di masa lalu. Tanggal kedaluwarsa tidak ditetapkan.
  • Kunci harus dalam status Aktfkan.
  • Kunci harus memiliki soft delete dengan periode retensi diatur ke 90 hari. Pengaturan ini secara implisit mengatur atribut recoveryLevel kunci yang diperlukan ke Recoverable.
  • Kunci harus memiliki proteksi hapus permanen yang diaktifkan.
  • Jika Anda mengimpor kunci yang ada ke dalam key vault, pastikan untuk menyediakannya dalam format file yang didukung (.pfx, .byok, .backup).

Note

Untuk instruksi langkah demi langkah terperinci tentang cara mengonfigurasi enkripsi data, lihat Enkripsi data untuk Azure Database for MySQL dengan portal Microsoft Azure, atau Enkripsi data untuk Azure Database for MySQL - Server Fleksibel dengan Azure CLI.

Rekomendasi untuk mengonfigurasi enkripsi data

Saat Anda mengonfigurasi Key Vault atau HSM Terkelola untuk menggunakan enkripsi data dengan kunci yang dikelola pelanggan, ingatlah rekomendasi berikut:

  • Tetapkan kunci sumber daya di Key Vault untuk mengontrol siapa yang dapat menghapus sumber daya penting ini dan mencegah penghapusan yang tidak disengaja atau tidak sah.
  • Aktifkan audit dan pelaporan pada semua kunci enkripsi. Key Vault menyediakan log yang mudah dimasukkan ke dalam informasi keamanan dan alat manajemen peristiwa lainnya.
  • Simpan salinan kunci yang dikelola pelanggan di tempat yang aman atau escrow ke layanan escrow.
  • Jika Key Vault membuat kunci, buat cadangan kunci sebelum menggunakan kunci untuk pertama kali. Anda hanya dapat memulihkan cadangan ke Key Vault. Untuk informasi selengkapnya tentang perintah pencadangan, lihat Backup-AzKeyVaultKey.

Note

Brankas kunci yang Anda gunakan harus berasal dari wilayah yang sama dengan server database.

Kondisi kunci yang dikelola pelanggan tidak dapat diakses

Saat Anda mengonfigurasi enkripsi data dengan CMK di Key Vault, server memerlukan akses berkelanjutan ke kunci ini untuk tetap online. Jika server fleksibel kehilangan akses ke kunci yang dikelola pelanggan dalam Key Vault, server mulai menolak semua koneksi dalam waktu 10 menit. Server fleksibel mengeluarkan pesan kesalahan yang sesuai, dan mengubah status server menjadi Tidak dapat diakses. Server dapat mencapai status ini karena berbagai alasan.

Jika Anda menghapus Key Vault, instans Azure Database for MySQL Flexible Server tidak dapat mengakses kunci dan beralih ke status Inaccessible. Untuk membuat instans server Available:

  • Pulihkan key vault.
  • Validasi ulang enkripsi data.

Jika Anda menghapus kunci dari brankas kunci, instans server fleksibel Azure Database for MySQL tidak dapat mengakses kunci dan berpindah ke Inaccessible status. Untuk membuat instans server Available:

  • Pulihkan kuncinya.
  • Validasi ulang enkripsi data.

Note

Bahkan jika kunci kedaluwarsa, server tetap dapat diakses sesuai rancangan untuk mencegah gangguan layanan.

Pencabutan akses kunci yang tidak disengaja dari Key Vault

Seseorang dengan hak akses yang memadai untuk Key Vault mungkin secara tidak sengaja menonaktifkan akses server fleksibel ke kunci dengan:

  • Mencabut izin kunci get, list, wrap key, dan unwrapping key dari server
  • Menghapus kunci
  • Menghapus Key Vault
  • Mengubah aturan firewall Key Vault
  • Menghapus identitas terkelola pengguna yang digunakan untuk enkripsi di server fleksibel dengan kunci yang dikelola pelanggan di ID Microsoft Entra

Memantau kunci yang dikelola pelanggan di Key Vault

Untuk memantau status database dan mengaktifkan pemberitahuan atas hilangnya akses pelindung enkripsi data transparan, konfigurasikan fitur Azure berikut:

  • Log aktivitas: Saat akses ke Kunci Pelanggan di Key Vault yang dikelola pengguna gagal, entri ditambahkan ke log aktivitas. Anda dapat memulihkan akses sesegera mungkin jika Anda membuat peringatan untuk peristiwa ini.
  • Grup tindakan: Tentukan grup ini untuk mengirim pemberitahuan dan pemberitahuan berdasarkan preferensi Anda.

Replika dengan kunci yang dikelola pelanggan di Key Vault

Saat Anda mengenkripsi instans server fleksibel Azure Database for MySQL dengan kunci terkelola pelanggan yang disimpan di Key Vault, salinan server yang baru dibuat juga dienkripsi. Ketika Anda mencoba mengenkripsi instans server fleksibel Azure Database for MySQL dengan kunci yang dikelola pelanggan yang sudah memiliki replika, konfigurasikan satu atau beberapa replika dengan menambahkan identitas dan kunci terkelola. Jika Anda mengonfigurasi instans server fleksibel Azure Database for MySQL dengan cadangan geo-redundansi, Anda harus mengonfigurasi replika dengan identitas terkelola dan kunci tempat identitas memiliki akses dan yang berada di wilayah server yang dipasangkan secara geografis.

Pulihkan dengan kunci yang dikelola pelanggan dalam Key Vault

Saat Anda memulihkan instans server Azure Database for MySQL fleksibel, pilih identitas dan kunci yang dikelola pengguna untuk mengenkripsi server pemulihan. Jika instans Flexible Server Azure Database for MySQL dikonfigurasi dengan pencadangan geo-redundan, Anda harus mengonfigurasi server hasil pemulihan dengan identitas terkelola dan kunci yang dapat diakses oleh identitas tersebut, serta yang berada di region pasangan geografis server tersebut.

Selama proses pemulihan atau pembuatan replika baca, ikuti langkah-langkah berikut pada server sumber dan server yang dipulihkan atau server replika:

  • Mulai proses pemulihan atau pembuatan replika baca dari instans sumber server fleksibel Azure Database for MySQL.
  • Pada server yang dipulihkan atau replika, validasi ulang CMK dalam pengaturan enkripsi data untuk memvalidasi izin UAMI ke kunci.

Note

Anda tidak perlu menggunakan identitas dan kunci yang sama (UAMI) seperti pada server sumber saat Anda melakukan pemulihan.

Konten terkait

  • Terakhir diperbarui pada