Bagikan melalui

Enkripsi data Azure Database for MySQL dengan kunci yang dikelola pelanggan

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Tunggal

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for MySQL memungkinkan Anda membawa kunci Anda sendiri (BYOK) untuk perlindungan data saat tidak digunakan. Ini juga memungkinkan organisasi menerapkan pemisahan tugas dalam pengelolaan kunci dan data. Dengan enkripsi yang dikelola pelanggan, Anda bertanggung jawab untuk, dan memiliki kendali penuh pada siklus hidup kunci, izin penggunaan kunci, dan audit operasi pada kunci.

Enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for MySQL, diatur di tingkat server. Untuk server tertentu, kunci yang dikelola pelanggan, yang disebut kunci enkripsi kunci (KEK), digunakan untuk mengenkripsi kunci enkripsi data (DEK) yang digunakan oleh layanan. KEK adalah kunci asimetris yang disimpan dalam instans Azure Key Vault milik pelanggan dan dikelola pelanggan. Kunci Enkripsi Kunci (KEK) dan Kunci Enkripsi Data (DEK) dijelaskan secara lebih rinci nanti di artikel ini.

Key Vault adalah sistem manajemen kunci eksternal berbasis cloud. Ini sangat tersedia dan menyediakan penyimpanan yang dapat diskalakan dan aman untuk kunci kriptografi RSA, yang didukung secara opsional oleh modul keamanan perangkat keras (HSM) yang divalidasi FIPS 140. Ini tidak memungkinkan akses langsung ke kunci yang disimpan, tetapi menyediakan layanan enkripsi dan dekripsi ke entitas yang berwenang. Key Vault dapat membuat kunci, mengimpornya, atau mentransfernya dari perangkat HSM lokal.

Catatan

Fitur ini hanya didukung pada penyimpanan "Penyimpanan Tujuan Umum v2 (dukungan hingga 16 TB)" yang tersedia dalam tingkatan harga Tujuan Umum dan Memori yang Dioptimalkan. Lihat Konsep penyimpanan untuk detail selengkapnya. Untuk batasan lainnya, lihat bagian pembatasan.

Keuntungan

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

  • Akses data sepenuhnya dikontrol oleh Anda dengan kemampuan untuk menghapus kunci dan membuat database tidak dapat diakses
  • Kontrol penuh atas siklus hidup kunci, termasuk rotasi kunci agar selaras dengan kebijakan perusahaan
  • Manajemen pusat dan organisasi kunci di Azure Key Vault
  • Kemampuan untuk menerapkan pemisahan tugas antara petugas keamanan, serta DBA dan administrator sistem

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 informasi selengkapnya, lihat Keamanan dalam enkripsi saat tidak aktif.

Cara kerja enkripsi data dengan kunci yang dikelola pelanggan

Agar server MySQL menggunakan kunci terkelola pelanggan yang disimpan di Key Vault untuk enkripsi DEK, administrator Key Vault memberikan hak akses berikut ke server:

  • get: Untuk mengambil bagian publik dan properti kunci di brankas kunci.
  • wrapKey: Untuk dapat mengenkripsi DEK. DEK terenkripsi disimpan di Azure Database for MySQL.
  • unwrapKey: Untuk dapat mendekripsi DEK. Azure Database for MySQL membutuhkan DEK yang didekripsi untuk mengenkripsi/mendekripsi data

Administrator key vault juga dapat mengaktifkan pengelogan peristiwa audit Key Vault, sehingga dapat diaudit nanti.

Ketika server dikonfigurasi untuk menggunakan kunci terkelola pelanggan yang disimpan di brankas kunci, server mengirimkan DEK ke brankas kunci untuk enkripsi. Key Vault menampilkan DEK terenkripsi, yang disimpan dalam database pengguna. Demikian pula, jika diperlukan, server mengirimkan DEK yang dilindungi ke brankas kunci untuk dekripsi. Auditor dapat menggunakan Azure Monitor untuk meninjau log peristiwa audit Azure Key Vault, jika pembuatan log diaktifkan.

Persyaratan untuk mengonfigurasi enkripsi data Azure Database for MySQL

Berikut ini adalah persyaratan untuk mengonfigurasi Key Vault:

  • Key Vault dan Azure Database for MySQL harus milik penyewa Microsoft Entra yang sama. Key Vault lintas-penyewa dan interaksi server tidak didukung. Memindahkan sumber daya Key Vault setelahnya mengharuskan Anda untuk mengonfigurasi ulang enkripsi data.
  • Aktifkan fitur penghapusan sementara di brankas kunci dengan periode penyimpanan ditetapkan ke 90 hari, untuk melindungi dari kehilangan data jika terjadi penghapusan kunci (atau Key Vault) yang tidak disengaja. Sumber daya yang dihapus sementara dipertahankan selama 90 hari secara default, kecuali periode retensi secara eksplisit disetel ke <=90 hari. Tindakan memulihkan dan menghapus memiliki izin sendiri yang terkait dalam kebijakan akses Azure Key Vault. Fitur penghapusan sementara dinonaktifkan secara default, tetapi Anda dapat mengaktifkannya melalui PowerShell atau Azure CLI (perhatikan bahwa Anda tidak dapat mengaktifkannya melalui portal Azure).
  • Aktifkan fitur Perlindungan Penghapusan Menyeluruh di brankas kunci dengan periode penyimpanan ditetapkan ke 90 hari. Perlindungan penghapusan menyeluruh hanya dapat diaktifkan setelah penghapusan sementara diaktifkan. Hal ini dapat diaktifkan melalui Azure CLI atau PowerShell. Saat perlindungan penghapusan menyeluruh menyala, vault atau objek dalam keadaan dihapus tidak dapat dihapus secara menyeluruh hingga periode penyimpanan berlalu. Vault dan objek yang dihapus sementara masih dapat dipulihkan, memastikan bahwa kebijakan penyimpanan akan diikuti.
  • Berikan akses Azure Database for MySQL ke brankas kunci dengan izin get, wrapKey, dan unwrapKey menggunakan identitas terkelola yang unik. Di portal Azure, identitas 'Layanan' yang unik secara otomatis dibuat saat enkripsi data diaktifkan di MySQL. Lihat Mengonfigurasi enkripsi data untuk MySQL untuk petunjuk detail langkah demi langkah saat Anda menggunakan portal Azure.

Berikut ini adalah persyaratan untuk mengonfigurasi kunci yang dikelola pelanggan:

  • Kunci terkelola pelanggan yang akan digunakan untuk mengenkripsi DEK hanya boleh asimetris, RSA 2048.
  • 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 penyimpanan yang ditetapkan ke 90 hari. Hal ini secara implisit menetapkan tingkat pemulihan atribut kunci yang diperlukan: “Dapat dipulihkan”. Jika retensi disetel ke < 90 hari, tingkat pemulihan: "CustomizedRecoverable", yang bukan merupakan persyaratan, jadi pastikan untuk menyetel periode retensi disetel ke 90 hari.
  • Kunci harus memiliki perlindungan penghapusan menyeluruh yang diaktifkan.
  • Jika Anda mengimpor kunci yang ada ke dalam key vault, pastikan untuk menyediakannya dalam format file yang didukung (.pfx, .byok, .backup).

Rekomendasi

Saat Anda menggunakan enkripsi data dengan menggunakan kunci yang dikelola pelanggan, berikut adalah rekomendasi untuk mengonfigurasi Key Vault:

  • 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.
  • Pastikan bahwa Key Vault dan Azure Database for MySQL berada di wilayah yang sama, untuk memastikan akses yang lebih cepat untuk DEK wrap, dan operasi unwrap.
  • Kunci KeyVault Azure hanya ke titik akhir pribadi dan jaringan yang dipilih dan izinkan hanya layanan Microsoft tepercaya untuk mengamankan sumber daya.

Berikut adalah rekomendasi untuk mengonfigurasi kunci yang dikelola pelanggan:

  • 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.

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 kehilangan akses ke kunci yang dikelola pelanggan di Key Vault, server mulai menolak semua koneksi dalam waktu 10 menit. Server mengeluarkan pesan kesalahan yang sesuai, dan mengubah status server menjadi Tidak dapat diakses. Beberapa alasan mengapa server dapat mencapai status ini adalah:

  • Jika kami membuat server Pemulihan Point In Time untuk Azure Database for MySQL Anda, yang enkripsi datanya diaktifkan, server yang baru dibuat akan berada dalam status Tidak dapat diakses. Anda dapat memperbaikinya melalui portal Azure atau CLI.
  • Jika kami membuat replika baca untuk Azure Database for MySQL Anda, yang enkripsi datanya diaktifkan, server replika akan berada dalam status Tidak dapat diakses. Anda dapat memperbaikinya melalui portal Azure atau CLI.
  • Jika Anda menghapus KeyVault, Azure Database for MySQL tidak akan dapat mengakses kunci dan akan berpindah ke status Tidak dapat diakses. Pulihkan Key Vault dan validasi ulang enkripsi data untuk membuat server Tersedia.
  • Jika kami menghapus kunci dari KeyVault, Azure Database for MySQL tidak akan dapat mengakses kunci dan akan berpindah ke status Tidak dapat diakses. Pulihkan Kunci dan validasi ulang enkripsi data untuk membuat server Tersedia.
  • Jika kunci yang disimpan di Azure KeyVault kedaluwarsa, kunci tersebut akan menjadi tidak valid dan Azure Database for MySQL akan beralih ke status Tidak dapat diakses. Perpanjang tanggal kedaluwarsa utama menggunakan CLI lalu validasi ulang enkripsi data untuk membuat server Tersedia.

Pencabutan akses kunci yang tidak disengaja dari Key Vault

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

  • Mencabut izin brankas kunci get, wrapKey, dan unwrapKey dari server.
  • Menghapus kunci.
  • Menghapus brankas kunci.
  • Mengubah aturan firewall brankas kunci.
  • Menghapus identitas server terkelola 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:

  • Azure Resource Health: Database yang tidak dapat diakses yang telah kehilangan akses ke kunci pelanggan ditampilkan sebagai "Tidak dapat diakses" setelah koneksi pertama ke basis data ditolak.

  • Log aktivitas: Saat akses ke kunci pelanggan di Key Vault yang dikelola pelanggan 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 mengirimi Anda pemberitahuan dan peringatan berdasarkan preferensi Anda.

Memulihkan dan mereplikasi dengan kunci yang dikelola pelanggan di Azure Key Vault

Setelah Azure Database for MySQL dienkripsi dengan kunci yang dikelola pelanggan yang disimpan di Azure Key Vault, salinan server yang baru dibuat juga dienkripsi. Anda dapat membuat salinan baru ini baik melalui operasi lokal atau geo-restore, atau melalui replika baca. Namun, salinan dapat diubah guna mencerminkan kunci yang dikelola pelanggan baru untuk enkripsi. Saat kunci yang dikelola pelanggan diubah, cadangan lama server mulai menggunakan kunci terbaru.

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

  • Memulai pemulihan atau membaca proses pembuatan replika dari sumber Azure Database for MySQL.
  • Menjaga server yang baru dibuat (dipulihkan/replika) dalam keadaan tidak dapat diakses, karena identitas uniknya belum diberikan izin ke Key Vault.
  • Di server yang dipulihkan/replika, validasi ulang kunci yang dikelola pelanggan dalam pengaturan enkripsi data untuk memastikan bahwa server yang baru dibuat diberi izin wrap dan unwrap ke kunci yang disimpan di Key Vault.

Batasan

Untuk Azure Database for MySQL, dukungan untuk enkripsi data tidak aktif yang menggunakan kunci yang dikelola pelanggan (CMK) memiliki beberapa batasan -

  • Dukungan untuk fungsi ini terbatas pada tingkat harga Tujuan Umum dan Memori yang Dioptimalkan.

  • Fitur ini hanya didukung di wilayah dan server, yang mendukung penyimpanan tujuan umum v2 (hingga 16 TB). Untuk daftar wilayah Azure yang mendukung penyimpanan hingga 16 TB, lihat bagian penyimpanan dalam dokumentasi di sini

    Catatan

    • Semua server MySQL baru dibuat di wilayah Azure yang mendukung penyimpanan tujuan umum v2, dukungan untuk enkripsi dengan kunci manajer pelanggan tersedia. Server Point In Time Restored (PITR) atau replika baca tidak akan memenuhi syarat meskipun secara teori mereka 'baru'.
    • Untuk memvalidasi apakah server yang disediakan mendukung penyimpanan tujuan umum v2, Anda dapat membuka blade tingkat harga di portal dan melihat ukuran penyimpanan maksimum yang didukung oleh server yang disediakan. Jika Anda dapat memindahkan penggeser hingga 4 TB, server Anda berarti menggunakan penyimpanan tujuan umum v1 dan tidak akan mendukung enkripsi dengan kunci yang dikelola pelanggan. Namun, data dienkripsi menggunakan kunci yang dikelola layanan setiap saat.

  • Enkripsi hanya didukung dengan kunci kriptografi RSA 2048.

Langkah berikutnya