Bagikan melalui

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

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

Dengan enkripsi data dengan kunci yang dikelola pelanggan untuk server fleksibel Azure Database for MySQL, Anda dapat membawa kunci Anda sendiri (BYOK) untuk perlindungan data tidak aktif dan menerapkan pemisahan tugas untuk mengelola kunci dan data. Dengan kunci yang dikelola pelanggan (CMK), pelanggan bertanggung jawab dan pada akhirnya mengontrol manajemen siklus hidup utama (pembuatan kunci, pengunggahan, rotasi, penghapusan), izin penggunaan utama, dan operasi audit pada kunci.

Catatan

Azure Key Vault Managed HSM (Modul Keamanan Perangkat Keras) saat ini didukung untuk kunci yang dikelola pelanggan untuk Azure Database for MySQL Flexible Server.

Keuntungan

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

  • Anda sepenuhnya mengontrol akses data dengan kemampuan untuk menghapus kunci dan membuat database tidak dapat diakses
  • Kontrol penuh atas siklus hidup utama, termasuk rotasi kunci untuk menyelaraskan dengan kebijakan perusahaan
  • Manajemen pusat dan organisasi kunci di Azure Key Vault atau HSM Terkelola
  • Kemampuan untuk 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 layanan Azure alternatif untuk menyimpan kredensial dalam kode dengan menyediakan identitas yang ditetapkan secara otomatis yang dapat digunakan untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra, seperti Azure Key Vault (AKV). Server fleksibel Azure Database for MySQL saat ini hanya mendukung Identitas Terkelola (UMI) yang ditetapkan pengguna. Untuk informasi selengkapnya, lihat Jenis identitas terkelola di Azure.

Untuk mengonfigurasi kunci yang dikelola pelanggan untuk server fleksibel Azure Database for MySQL, Anda perlu mengaitkan UMI ke server dan menentukan brankas kunci dan kunci Azure yang akan digunakan.

UMI harus memiliki akses berikut ke brankas kunci:

  • Get: Untuk mengambil bagian publik dan properti kunci di brankas kunci.
  • List: Buat daftar versi dari kunci yang disimpan di Key Vault.
  • Wrap Key: Agar dapat mengenkripsi ke DEK. DEK terenkripsi disimpan di instans server fleksibel Azure Database for MySQL.
  • Unwrap Key: Agar dapat mendekripsi DEK. Server fleksibel Azure Database for MySQL memerlukan DEK yang didekripsi untuk mengenkripsi/mendekripsi data.

Jika RBAC diaktifkan, UMI juga harus diberi peran berikut:

  • Pengguna Enkripsi Layanan Kripto Key Vault 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 Pengguna Enkripsi Layanan Kripto HSM Terkelola

Terminologi dan deskripsi

Kunci enkripsi data (DEK): Kunci AES256 simetris yang digunakan untuk mengenkripsi partisi atau blok data. Mengenkripsi setiap blok data dengan berbagai kunci membuat serangan analisis kripto lebih sulit. Akses ke DEK diperlukan oleh penyedia sumber daya atau instans aplikasi yang mengenkripsi dan mendekripsi blok tertentu. Saat Anda mengganti DEK dengan kunci baru, hanya data di blok terkait yang harus dienkripsi ulang dengan kunci baru.

Kunci enkripsi kunci (KEK): Kunci enkripsi yang digunakan untuk mengenkripsi DEK. KEK yang tidak pernah meninggalkan Key Vault memungkinkan DEK itu sendiri dienkripsi dan dikendalikan. Entitas yang memiliki akses ke KEK mungkin berbeda dengan entitas yang memerlukan DEK. Karena KEK diperlukan untuk mendekripsi DEK, KEK secara efektif merupakan satu titik di mana DEK dapat dihapus secara efektif dengan menghapus KEK. DEK, dienkripsi dengan KEK, disimpan secara terpisah. Hanya entitas dengan akses ke KEK yang dapat mendekripsi DEK ini. Untuk mengetahui informasi selengkapnya, lihat Keamanan dalam enkripsi saat tidak aktif.

Cara kerjanya

Enkripsi data dengan kunci yang dikelola pelanggan diatur di tingkat server. Untuk server tertentu, CMK, yang disebut kunci enkripsi kunci (KEK), digunakan 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 sangat tersedia dan penyimpanan aman yang dapat diskalakan untuk kunci kriptografi RSA, yang didukung secara opsional oleh modul keamanan perangkat keras (HSM) yang divalidasi FIPS 140. Key Vault tidak memungkinkan akses langsung ke kunci yang disimpan, tetapi menyediakan layanan enkripsi/dekripsi menggunakan kunci ke entitas yang diotorisasi. Brankas kunci, yang diimpor dapat menghasilkan kunci, atau ditransfer 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 akan mengirim DEK yang dilindungi ke brankas kunci untuk dekripsi saat diperlukan.

Diagram cara kerja enkripsi data dengan kunci yang dikelola pelanggan.

Setelah pengelogan diaktifkan, auditor dapat menggunakan Azure Monitor untuk meninjau log kejadian audit Key Vault. Untuk mengaktifkan pengelogan peristiwa audit Key Vault, lihat Memantau layanan brankas kunci Anda dengan wawasan Key Vault.

Catatan

Perubahan izin dapat memakan waktu hingga 10 menit untuk memengaruhi brankas kunci. Ini termasuk mencabut izin akses ke pelindung TDE di Azure Key Vault, dan pengguna dalam jangka waktu ini mungkin masih memiliki izin akses.

Persyaratan untuk mengonfigurasi enkripsi data untuk server fleksibel 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 lintas penyewa dan interaksi server fleksibel perlu didukung. Anda harus 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 penghapusan sementara pada brankas kunci dengan periode retensi yang diatur ke 90 hari untuk melindungi dari kehilangan data jika terjadi penghapusan kunci yang tidak disengaja (atau Key Vault). Tindakan pemulihan dan penghapusan menyeluruh memiliki izin mereka sendiri dalam kebijakan akses Key Vault. Fitur penghapusan sementara dinonaktifkan secara default, tetapi Anda dapat mengaktifkannya melalui portal Microsoft Azure atau dengan menggunakan PowerShell atau Azure CLI.
  • Aktifkan fitur Perlindungan Penghapusan Menyeluruh di brankas kunci dan atur periode retensi ke 90 hari. Saat perlindungan penghapusan menyeluruh aktif, vault atau objek dalam status terhapus tidak dapat dihapus menyeluruh hingga periode penyimpanan telah berlalu. Anda dapat mengaktifkan fitur ini menggunakan PowerShell atau Azure CLI, dan hanya setelah Mengaktifkan penghapusan sementara.

Sebelum mencoba untuk mengonfigurasi kunci yang dikelola pelanggan, pastikan bahwa persyaratan berikut telah terpenuhi.

  • Kunci yang dikelola pelanggan untuk mengenkripsi DEK hanya dapat 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 penghapusan sementara dengan periode retensi yang diatur ke 90 hari. Ini secara implisit mengatur recoveryLevel atribut kunci yang diperlukan: "Dapat Dipulihkan."
  • Kunci harus memiliki perlindungan penghapusan menyeluruh yang diaktifkan.
  • Jika Anda mengimpor kunci yang ada ke brankas kunci, pastikan Anda menyediakannya dalam format file yang didukung (.pfx, .byok, .backup).

Catatan

Untuk instruksi langkah demi langkah terperinci tentang cara mengonfigurasi enkripsi tanggal untuk server fleksibel Azure Database for MySQL melalui portal Azure, lihat Mengonfigurasi enkripsi data untuk server fleksibel Azure Database for MySQL.

Rekomendasi untuk mengonfigurasi enkripsi data

Saat Anda mengonfigurasi Key Vault atau Managed HSM untuk menggunakan enkripsi data menggunakan 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. Azure Monitor Log Analytics adalah salah satu contoh layanan yang sudah terintegrasi.
  • 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.

Catatan

  • Disarankan untuk menggunakan brankas kunci dari wilayah yang sama, tetapi jika perlu, Anda dapat menggunakan brankas kunci dari wilayah lain dengan menentukan informasi "masukkan pengidentifikasi kunci". HSM yang dikelola brankas kunci harus berada di wilayah yang sama dengan server fleksibel MySQL.

Kondisi kunci yang dikelola pelanggan tidak dapat diakses

Saat Anda mengonfigurasi enkripsi data dengan kunci yang dikelola pelanggan di Key Vault, akses berkelanjutan ke kunci ini diperlukan agar server 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 brankas kunci, instans server fleksibel Azure Database for MySQL tidak akan dapat mengakses kunci dan akan pindah ke status Tidak dapat diakses . Pulihkan brankas kunci dan validasi ulang enkripsi data untuk membuat instans server fleksibel Azure Database for MySQL Tersedia.
  • Jika Anda menghapus kunci dari brankas kunci, instans server fleksibel Azure Database for MySQL tidak akan dapat mengakses kunci dan akan pindah ke status Tidak dapat diakses . Pulihkan kunci dan validasi ulang enkripsi data untuk membuat instans server fleksibel Azure Database for MySQL Tersedia.
  • Jika kunci yang disimpan di Azure Key Vault kedaluwarsa, kunci akan menjadi tidak valid, dan instans server fleksibel Azure Database for MySQL akan beralih ke status Tidak Dapat Diakses . Perpanjang tanggal kedaluwarsa kunci menggunakan CLI lalu validasi ulang enkripsi data untuk membuat instans server fleksibel Azure Database for MySQL Tersedia.

Pencabutan akses kunci yang tidak disengaja dari Key Vault

Mungkin saja seseorang dengan hak akses ke Key Vault yang memadai secara tidak sengaja menonaktifkan akses server fleksibel ke kunci dengan:

  • Mencabut izin mendapatkan, membuat daftar, mengunci, dan membuka kunci brankas kunci dari server
  • Menghapus kunci
  • Menghapus brankas kunci
  • Mengubah aturan firewall brankas kunci
  • 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 untuk mengaktifkan peringatan hilangnya akses pelindung enkripsi data transparan, konfigurasikan fitur Azure berikut ini:

  • 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 dalam Key Vault

Setelah instans server fleksibel Azure Database for MySQL dienkripsi dengan kunci terkelola pelanggan yang disimpan di Key Vault, salinan server yang baru dibuat juga dienkripsi. Saat mencoba mengenkripsi instans server fleksibel Azure Database for MySQL dengan kunci yang dikelola pelanggan yang sudah memiliki replika, sebaiknya konfigurasikan replika dengan menambahkan identitas dan kunci terkelola. Misalkan instans server fleksibel Azure Database for MySQL dikonfigurasi dengan cadangan geo-redundansi. Dalam hal ini, replika harus dikonfigurasi 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 mencoba memulihkan instans server fleksibel Azure Database for MySQL, Anda dapat memilih identitas dan kunci yang dikelola pengguna untuk mengenkripsi server pemulihan. Misalkan instans server fleksibel Azure Database for MySQL dikonfigurasi dengan cadangan geo-redundansi. Dalam hal ini, Anda harus mengonfigurasi server pemulihan dengan identitas terkelola dan kunci tempat identitas memiliki akses dan yang berada di wilayah server yang dipasangkan secara geografis.

Untuk menghindari masalah saat menyiapkan enkripsi data yang dikelola pelanggan selama pemulihan atau pembuatan replika baca, penting untuk mengikuti langkah-langkah ini pada server sumber dan yang dipulihkan/replika:

  • Mulai proses pemulihan atau pembuatan replika baca dari instans server fleksibel Azure Database for MySQL sumber.
  • Di server yang dipulihkan/server replika, validasi kembali kunci yang dikelola pelanggan dalam pengaturan enkripsi data untuk memastikan bahwa identitas yang dikelola pengguna telah diberikan izin Get, List, Wrap key dan Unwrap key ke kunci yang disimpan di Key Vault.

Catatan

Menggunakan identitas dan kunci yang sama seperti pada server sumber tidak wajib saat melakukan pemulihan.

Langkah berikutnya