Azure SQL Transparent Data Encryption dengan kunci yang dikelola pelanggan

Berlaku untuk:Azure SQL DatabaseAzure SQL Managed Instance

Enkripsi data transparan (TDE) di Azure SQL dengan kunci yang dikelola pelanggan (CMK) memungkinkan skenario Bring Your Own Key (BYOK) untuk perlindungan data tidak aktif, dan memungkinkan organisasi menerapkan pemisahan tugas dalam pengelolaan kunci dan data. Dengan TDE yang dikelola pelanggan, pelanggan bertanggung jawab atas dan memiliki kontrol penuh atas manajemen siklus hidup kunci (pembuatan kunci, pengunggahan, rotasi, penghapusan), izin penggunaan kunci, dan audit operasi pada kunci.

Dalam skenario ini, Transparent Data Encryption (TDE) protector adalah kunci yang dikelola pelanggan yang mengamankan Database Encryption Key (DEK). Anda menyimpan pelindung TDE di Azure Key Vault atau Azure Key Vault Managed HSM, yang merupakan layanan manajemen kunci berbasis cloud yang aman dan dirancang untuk ketersediaan tinggi dan skalabilitas. Kedua layanan mendukung kunci kriptografi yang dilindungi oleh perangkat keras yang telah divalidasi FIPS 140-2: Azure Key Vault mendukung FIPS 140-2 Level 2, dan Azure Key Vault Managed HSM mendukung FIPS 140-2 Level 3. Kedua layanan juga mendukung tipe kunci asimetris dan simetris, dan algoritma serta penggunaan yang didukung bergantung pada model penerapan TDE. Anda dapat menghasilkan kunci di layanan, mengimpornya, atau mentransfernya secara aman dari HSM lokal. Akses langsung ke kunci dibatasi, sehingga layanan yang diotorisasi melakukan operasi kriptografi tanpa mengekspos materi kunci.

Untuk Azure SQL Database, Anda mengatur pelindung TDE di tingkat server, dan semua database terenkripsi yang terkait dengan server tersebut mewarisinya. Untuk Azure SQL Managed Instance, Anda mengatur pelindung TDE pada tingkat instance, dan semua database terenkripsi pada instance tersebut mewarisinya. Istilah server merujuk baik pada server logis di Azure SQL Database maupun pada instance yang dikelola di SQL Managed Instance sepanjang artikel ini, kecuali dinyatakan secara berbeda.

Mengelola pelindung TDE di tingkat database di Azure SQL Database tersedia. Untuk informasi selengkapnya, lihat Enkripsi data transparan (TDE) dengan kunci yang dikelola pelanggan di tingkat database.

Nota

MICROSOFT Entra ID sebelumnya dikenal sebagai Azure Active Directory (Azure AD).

Kunci yang Dikelola Pelanggan (CMK) dan Bring Your Own Key (BYOK)

Dalam artikel ini, istilah Customer Managed Key (CMK) dan Bring Your Own Key (BYOK) digunakan secara bergantian, tetapi mewakili beberapa perbedaan.

  • Customer Managed Key (CMK) - Pelanggan mengelola siklus hidup utama, termasuk pembuatan kunci, rotasi, dan penghapusan. Kunci disimpan di Azure Key Vault atau Azure Managed HSM dan digunakan untuk enkripsi Kunci Enkripsi Database (DEK) di Azure SQL, SQL Server di Azure VM, dan SQL Server lokal.

  • Bring Your Own Key (BYOK) - Pelanggan dengan aman membawa atau mengimpor kunci mereka sendiri dari modul keamanan perangkat keras (HSM) lokal ke Azure Key Vault atau Azure Managed HSM. Kunci yang diimpor tersebut dapat digunakan sebagai kunci lain di Azure Key Vault, termasuk sebagai Kunci yang Dikelola Pelanggan untuk enkripsi DEK. Untuk informasi selengkapnya, lihat Mengimpor kunci yang dilindungi HSM ke Managed HSM (BYOK).

Manfaat TDE yang dikelola pelanggan

TDE yang dikelola pelanggan memberikan manfaat berikut kepada pelanggan:

  • Kontrol penuh dan terperinci atas penggunaan dan manajemen pelindung TDE.

  • Transparansi penggunaan pelindung TDE.

  • Kemampuan untuk menerapkan pemisahan tugas dalam pengelolaan kunci dan data dalam organisasi.

  • Administrator Azure Key Vault dapat mencabut izin akses kunci untuk membuat database terenkripsi tidak dapat diakses.

  • Manajemen pusat kunci di Azure Key Vault.

  • Kepercayaan yang lebih besar dari pelanggan akhir Anda, karena Azure Key Vault dirancang sed sehingga Microsoft tidak dapat melihat atau mengekstrak kunci enkripsi.

Penting

Bagi mereka yang menggunakan TDE yang dikelola layanan yang ingin mulai menggunakan TDE yang dikelola pelanggan, data tetap dienkripsi selama proses pengalihan, dan tidak ada waktu henti atau enkripsi ulang file database. Beralih dari kunci yang dikelola layanan ke kunci yang dikelola pelanggan hanya memerlukan enkripsi ulang DEK, yang merupakan operasi cepat dan online.

Izin untuk mengonfigurasi TDE yang dikelola pelanggan

Diagram memperlihatkan penyiapan dan fungsi TDE yang dikelola pelanggan.

Pilih jenis Azure Key Vault yang ingin Anda gunakan.

Agar server logis di Azure dapat menggunakan pelindung TDE yang disimpan di Azure Key Vault untuk enkripsi DEK, Administrator Key Vault perlu memberikan hak akses ke server menggunakan identitas Microsoft Entra uniknya. Identitas server dapat berupa identitas terkelola yang ditetapkan oleh sistem atau identitas terkelola yang ditetapkan oleh pengguna ke server. Ada dua model akses untuk memberikan akses server ke brankas kunci:

  • Kontrol akses berbasis peran Azure (RBAC) - Gunakan Azure RBAC untuk memberikan akses pengguna, grup, atau aplikasi ke brankas kunci. Metode ini direkomendasikan karena fleksibilitas dan granularitasnya. Peran Pengguna Enkripsi Layanan Kripto Key Vault diperlukan oleh identitas server untuk dapat menggunakan kunci untuk operasi enkripsi dan dekripsi.

  • Kebijakan akses vault - Gunakan kebijakan akses brankas kunci untuk memberikan akses server ke brankas kunci. Metode ini lebih sederhana dan lebih mudah, tetapi kurang fleksibel. Identitas server harus memiliki izin berikut pada brankas kunci:

    • get - untuk memperoleh bagian publik dan properti kunci di Azure Key Vault
    • wrapKey - untuk dapat melindungi (mengenkripsi) DEK
    • unwrapKey - untuk dapat membuka proteksi (dekripsi) DEK

Di menu portal Microsoft Azure Konfigurasi akses dari brankas kunci, Anda memiliki opsi untuk memilih kontrol akses berbasis peran Azure atau kebijakan akses Vault. Untuk instruksi langkah demi langkah tentang menyiapkan konfigurasi akses Azure Key Vault untuk TDE, lihat Menyiapkan SQL Server TDE Extensible Key Management dengan menggunakan Azure Key Vault. Untuk informasi selengkapnya tentang model akses, lihat Keamanan Azure Key Vault.

Administrator Key Vault juga dapat mengaktifkan pengelogan peristiwa audit brankas kunci, sehingga dapat diaudit nanti.

Saat server dikonfigurasi untuk menggunakan pelindung TDE dari Azure Key Vault, server mengirim DEK dari setiap database berkemampuan TDE ke brankas kunci untuk enkripsi. Brankas kunci mengembalikan DEK terenkripsi, yang kemudian disimpan dalam database pengguna.

Jika diperlukan, server mengirim DEK yang dilindungi ke brankas kunci untuk dekripsi.

Auditor dapat menggunakan Azure Monitor untuk meninjau log AuditEvent key vault, jika pencatatan diaktifkan.

Nota

Mungkin perlu waktu sekitar 10 menit agar perubahan izin berlaku untuk brankas kunci. Ini termasuk mencabut izin akses ke pelindung TDE di AKV, dan pengguna dalam jangka waktu ini mungkin masih memiliki izin akses.

Persyaratan untuk mengonfigurasi TDE yang dikelola pelanggan

  • Fitur perlindungan penghapusan sementara dan penghapusan menyeluruh harus diaktifkan pada Azure Key Vault. Ini membantu mencegah skenario brankas kunci atau penghapusan kunci yang tidak disengaja atau berbahaya yang dapat menyebabkan database masuk ke status Tidak Dapat Diakses . Saat mengonfigurasi pelindung TDE di server yang ada atau selama pembuatan server, Azure SQL memvalidasi bahwa brankas kunci yang digunakan telah mengaktifkan penghapusan sementara dan perlindungan pembersihan total. Jika perlindungan penghapusan sementara dan penghapusan menyeluruh tidak diaktifkan pada brankas kunci, penyiapan pelindung TDE gagal dengan kesalahan. Dalam hal ini, perlindungan penghapusan sementara dan penghapusan menyeluruh harus terlebih dahulu diaktifkan pada brankas kunci dan kemudian penyiapan pelindung TDE harus dilakukan.

  • Saat menggunakan firewall dengan Azure Key Vault, Anda harus mengaktifkan opsi Izinkan layanan Microsoft tepercaya untuk melewati firewall, kecuali Anda menggunakan titik akhir privat untuk Azure Key Vault. Untuk informasi selengkapnya, lihat Mengonfigurasi firewall dan jaringan virtual di Azure Key Vault.

Persyaratan utama untuk mengonfigurasi pelindung TDE

Transparent Data Encryption dengan kunci yang dikelola pelanggan menggunakan kunci eksternal, yang disebut pelindung TDE, yang disimpan di Azure Key Vault atau Azure Managed HSM untuk melindungi kunci enkripsi basis data (DEK).

Persyaratan berikut berlaku.

Jenis dan ukuran kunci yang didukung

Bergantung pada penawaran Azure SQL dan konfigurasi TDE, pelindung TDE dapat didukung oleh kunci asimetris atau simetris yang disimpan di Azure Key Vault atau Azure Key Vault Managed HSM.

  • Kunci asimetris (RSA atau RSA HSM)

    • Didukung di Azure Key Vault dan Azure Key Vault Managed HSM
    • Ukuran kunci yang didukung: 2.048-bit dan 3.072-bit
    • Didukung untuk Azure SQL Database dan Azure SQL Managed Instance

  • Kunci simetris (AES)

    • Didukung di Azure Key Vault Premium (pratinjau) dan Azure Key Vault Managed HSM
    • Ukuran kunci yang didukung: 128-bit, 192-bit, dan 256-bit
    • Hanya didukung untuk Azure SQL Database dan saat ini dalam pratinjau publik

Nota

Transparent Data Encryption with symmetric keys (AES) saat ini sedang dalam tahap pratinjau. Fitur pratinjau dirilis dengan kemampuan terbatas, tetapi Microsoft membuatnya tersedia secara pratinjau agar pelanggan dapat mendapatkan akses awal dan memberikan masukan. Fitur pratinjau tunduk pada istilah pratinjau tambahan yang terpisah, dan tidak tunduk pada SLA. Dukungan diberikan sebagai upaya terbaik dalam kasus tertentu. Namun, Dukungan Microsoft sangat ingin mendapatkan umpan balik Anda tentang fungsionalitas pratinjau, dan mungkin memberikan dukungan upaya terbaik dalam kasus tertentu. Fitur pratinjau mungkin memiliki fungsionalitas terbatas atau terbatas, dan mungkin hanya tersedia di area geografis yang dipilih.

Perilaku manajemen kunci untuk kunci simetris (AES)

Anda dapat menggunakan kunci simetris (AES) yang disimpan di Azure Key Vault Premium (pratinjau) atau Azure Key Vault Managed HSM sebagai pelindung TDE. Untuk memulai dengan kunci dari modul keamanan perangkat keras (HSM) on-premises, impor kunci tersebut ke salah satu layanan. Setelah impor awal, semua operasi siklus hidup kunci selanjutnya dilakukan di Azure Key Vault Premium (pratinjau) atau Azure Key Vault Managed HSM. Pemulihan ke titik waktu tertentu, pemulihan bencana geografis, dan revalidasi kunci semuanya bergantung pada kunci yang tetap tersedia di sana. Simpan cadangan lokal untuk kunci yang diimpor untuk mendukung skenario pemulihan dan revalidasi. Perilaku ini hanya berlaku untuk kunci simetris (AES), bukan untuk kunci asimetris (RSA).

Persyaratan status dan validitas utama

  • Jika tanggal aktivasi kunci ditentukan, tanggal tersebut harus diatur ke tanggal dan waktu di masa lalu.
  • Jika tanggal kedaluwarsa kunci ditentukan, tanggal tersebut harus ditetapkan pada tanggal dan waktu di masa mendatang.
  • Kunci harus dalam status Aktfkan.

Persyaratan impor utama

Jika Anda mengimpor kunci yang sudah ada ke Azure Key Vault, berikan kunci tersebut dalam salah satu format yang didukung berikut:

  • .pfx
  • .byok
  • .backup

Untuk mengimpor kunci yang dilindungi HSM ke Azure Managed HSM, lihat Mengimpor kunci yang dilindungi HSM ke Managed HSM (BYOK).

Nota

Masalah dengan versi Thales CipherTrust Manager sebelum v2.8.0 mencegah kunci yang baru diimpor ke Azure Key Vault digunakan dengan Azure SQL Database atau Azure SQL Managed Instance untuk skenario TDE yang dikelola oleh pelanggan. Untuk detail selengkapnya tentang masalah ini, lihat Catatan rilis CipherTrust Cloud Key Manager. Untuk kasus seperti itu, tunggu 24 jam setelah mengimpor kunci ke Azure Key Vault untuk mulai menggunakannya sebagai pelindung TDE untuk server atau instans terkelola. Masalah ini diselesaikan di Thales CipherTrust Manager v2.8.0.

Rekomendasi untuk mengonfigurasi TDE yang dikelola pelanggan

  • Untuk memastikan performa dan keandalan optimal, gunakan Azure Key Vault khusus untuk Azure SQL. Jangan berbagi brankas kunci ini dengan layanan lain. Jika key vault berada di bawah beban berat akibat penggunaan bersama atau operasi kunci yang berlebihan, hal ini dapat berdampak negatif pada kinerja basis data, terutama selama akses kunci enkripsi. Azure Key Vault menerapkan batas pengendalian. Ketika batas ini terlampaui, operasi mungkin tertunda atau gagal. Risiko ini paling tinggi selama failover server, yang memicu operasi kunci untuk setiap database di server.

    Untuk informasi selengkapnya tentang perilaku pembatasan, lihat Panduan pembatasan Azure Key Vault.

    Untuk mempertahankan ketersediaan tinggi dan menghindari masalah pembatasan, ikuti panduan ini per langganan:

    • Gunakan Azure Key Vault khusus untuk sumber daya Azure SQL.

    • Kaitkan tidak lebih dari 500 database Tujuan Umum dengan satu Azure Key Vault.

    • Kaitkan tidak lebih dari 200 database Business Critical dengan satu Azure Key Vault.

    • Jumlah database Hyperscale yang dapat dikaitkan dengan satu Azure Key Vault ditentukan oleh jumlah server halaman. Setiap server halaman ditautkan ke file data logis. Untuk menemukan jumlah server halaman, jalankan kueri berikut.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Jangan mengaitkan lebih dari 500 server halaman dengan satu Azure Key Vault. Seiring bertambahnya database, jumlah server halaman meningkat secara otomatis, jadi penting untuk memantau ukuran database secara teratur. Jika jumlah server halaman melebihi 500, gunakan Azure Key Vault khusus untuk setiap database Hyperscale, dan jangan bagikan key vault tersebut dengan sumber daya Azure SQL lainnya.

    • Memantau dan mengonfigurasi alert Azure Key Vault. Untuk informasi selengkapnya tentang pemantauan dan pemberitahuan, lihat Memantau Azure Key Vault dan Mengonfigurasi pemberitahuan Azure Key Vault.

  • Untuk selaras dengan perencanaan ketahanan kriptografi jangka panjang, pertimbangkan menggunakan kunci simetris AES-256 sebagai pelindung TDE.

    Komputasi kuantum skala besar diperkirakan akan merusak algoritma kriptografi kunci publik seperti RSA. Kriptografi simetris, termasuk AES, dianggap tahan kuantum pada ukuran kunci yang cukup besar.

    Strategi keamanan aman kuantum Microsoft yang lebih luas menekankan kelincahan kripto. Adopsi algoritma simetris yang lebih kuat jika didukung, dan rencanakan transisi kriptografi di masa depan seiring perkembangan panduan dan standar.

    Penting

    Transparent Data Encryption dengan kunci simetris (AES) saat ini hanya didukung untuk Azure SQL Database dan masih dalam pratinjau publik.

  • Atur kunci sumber daya pada brankas kunci untuk mengontrol siapa yang dapat menghapus sumber daya penting ini dan mencegah penghapusan yang tidak disengaja atau tidak sah. Pelajari selengkapnya tentang kunci sumber daya.

  • Aktifkan audit dan pelaporan pada semua kunci enkripsi: Azure Key Vault menyediakan log yang mudah disuntikkan ke informasi keamanan dan alat manajemen peristiwa lainnya. Operations Management Suite Log Analytics adalah salah satu contoh layanan yang sudah terintegrasi.

  • Gunakan brankas kunci dari wilayah Azure yang dapat mereplikasi kontennya ke wilayah berpasangan untuk ketersediaan maksimum. Untuk informasi selengkapnya, lihat praktik terbaik untuk menggunakan Azure Key Vault dan ketersediaan dan redundansi Azure Key Vault.

Nota

Untuk memungkinkan fleksibilitas yang lebih besar dalam mengonfigurasi TDE yang dikelola pelanggan, Azure SQL Database dan Azure SQL Managed Instance di satu wilayah sekarang dapat ditautkan ke Azure Key Vault di wilayah lain. Server dan brankas kunci tidak harus dikolokasikan di wilayah yang sama.

Rekomendasi untuk mengonfigurasi pelindung TDE

  • Simpan salinan pelindung TDE di tempat yang aman atau simpan di layanan penjaminan.

  • Jika kunci dihasilkan di brankas kunci, buat cadangan kunci sebelum menggunakan kunci di Azure Key Vault untuk pertama kalinya. Pencadangan hanya dapat dipulihkan ke Azure Key Vault. Pelajari selengkapnya tentang perintah Backup-AzKeyVaultKey . Azure Managed HSM mendukung pembuatan cadangan penuh seluruh konten HSM termasuk semua kunci, versi, atribut, tag, dan penetapan peran. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan penuh dan pemulihan kunci selektif.

  • Buat cadangan baru setiap kali perubahan dilakukan pada kunci (misalnya, atribut kunci, tag, ACL).

  • Pertahankan versi kunci sebelumnya di brankas kunci atau Managed HSM saat merotasi kunci, sehingga Anda dapat memulihkan cadangan basis data yang lebih lama. Ketika protektor TDE berubah untuk database, cadangan lama dari database tidak diperbarui untuk menggunakan pelindung TDE terbaru. Pada waktu pemulihan, setiap cadangan membutuhkan pelindung TDE yang dienkripsi pada waktu pembuatan. Untuk memutar tombol, ikuti instruksi dalam artikel Putar pelindung enkripsi data transparan (TDE).

  • Simpan semua kunci yang digunakan sebelumnya di Azure Key Vault atau Azure Managed HSM bahkan setelah beralih ke kunci yang dikelola layanan. Ini memastikan cadangan database dapat dipulihkan dengan pelindung TDE yang disimpan di Azure Key Vault atau Azure Managed HSM. Pelindung TDE yang dibuat dengan Azure Key Vault atau Azure Managed HSM harus dipertahankan hingga semua cadangan tersimpan yang tersisa telah dibuat dengan kunci yang dikelola layanan. Buat salinan cadangan yang dapat dipulihkan dari kunci ini menggunakan Backup-AzKeyVaultKey.

  • Untuk menghapus kunci yang berpotensi disusupi selama insiden keamanan tanpa risiko kehilangan data, ikuti langkah-langkah dalam artikel Menghapus pelindung Enkripsi Data Transparan (TDE) menggunakan PowerShell. Selalu putar ke pelindung TDE baru dan verifikasi bahwa semua database menggunakan kunci baru sebelum menghapus atau menonaktifkan kunci yang disusupi. Menghapus atau menonaktifkan kunci tanpa merotasinya terlebih dahulu menyebabkan semua basis data terenkripsi menjadi tidak dapat diakses, dan tidak membuat salinan kunci yang sebelumnya dicadangkan dan dipulihkan ke brankas lain menjadi tidak valid.

Petunjuk / Saran

Menggunakan kunci Azure Key Vault berstatus versi dan tanpa versi untuk TDE

Saat mengatur pelindung TDE, Anda dapat mereferensikan kunci Azure Key Vault menggunakan versi kunci tertentu atau pengidentifikasi kunci tanpa versi.

Dalam kedua kasus, Azure SQL Database selalu menyelesaikan dan menggunakan versi kunci terbaru yang diaktifkan di Azure Key Vault atau Azure Key Vault Managed HSM. Gunakan pengidentifikasi kunci tanpa versi untuk menghindari penyematan versi kunci tertentu dalam konfigurasi pelindung TDE.

Pengidentifikasi kunci tanpa versi saat ini hanya didukung untuk Azure SQL Database.

Examples:

  • Pengidentifikasi kunci yang menyertakan versi tertentu

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Pengidentifikasi kunci tanpa versi

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Rotasi pelindung TDE

Memutar pelindung TDE memungkinkan Anda mengganti kunci yang digunakan untuk melindungi kunci enkripsi database (DEK). Rotasi kunci adalah operasi online dan hanya perlu beberapa detik untuk diselesaikan. Operasi ini hanya mendekripsi dan mengenkripsi ulang kunci enkripsi database, bukan seluruh database.

Anda dapat memutar pelindung TDE dengan mengalihkan konfigurasi untuk menggunakan kunci baru yang disimpan di Azure Key Vault atau Azure Key Vault Managed HSM. Bergantung pada penawaran Azure SQL dan konfigurasi yang didukung, ini dapat mencakup:

  • Beralih ke versi kunci baru dari kunci yang sama
  • Beralih ke kunci lain
  • Beralih antara jenis kunci yang didukung, seperti kunci asimetris (RSA) dan simetris (AES)

Nota

Transparent Data Encryption dengan kunci simetris (AES) saat ini hanya didukung untuk Azure SQL Database dan masih dalam pratinjau publik.

Rotasi pelindung TDE dapat dilakukan secara manual atau dengan menggunakan fitur rotasi otomatis.

Rotasi otomatis pelindung TDE dapat diaktifkan saat mengonfigurasi pelindung TDE untuk server. Rotasi otomatis dinonaktifkan secara default. Saat diaktifkan, server terus memeriksa gudang kunci atau HSM Terkelola untuk semua versi baru dari kunci yang digunakan sebagai pelindung TDE. Jika versi baru kunci terdeteksi, pelindung TDE di server atau database secara otomatis diputar ke versi kunci terbaru dalam waktu 24 jam.

Saat digunakan dengan rotasi kunci otomatis di Azure Key Vault atau autorotasi di Azure Managed HSM, fitur ini memungkinkan rotasi tanpa sentuh dari awal hingga akhir untuk protektor TDE di Azure SQL Database, dan Azure SQL Managed Instance.

Nota

Mengatur TDE dengan CMK menggunakan rotasi kunci manual atau otomatis selalu menggunakan versi terbaru kunci yang didukung. Pengaturan tidak memungkinkan penggunaan versi kunci sebelumnya atau yang lebih rendah. Selalu gunakan versi kunci terbaru sesuai dengan kebijakan keamanan Azure SQL yang melarang versi kunci sebelumnya yang mungkin disusupi. Versi kunci sebelumnya mungkin diperlukan untuk tujuan pencadangan atau pemulihan database, terutama untuk cadangan retensi jangka panjang, di mana versi kunci yang lebih lama harus dipertahankan. Untuk penyiapan replikasi geografis, semua kunci yang diperlukan oleh server sumber perlu ada di server target.

Pertimbangan replikasi geografis saat mengonfigurasi rotasi otomatis pelindung TDE

Untuk menghindari masalah saat membuat atau selama replikasi geografis, ketika rotasi otomatis pelindung TDE diaktifkan di server utama atau sekunder, penting untuk mengikuti aturan ini saat mengonfigurasi replikasi geografis:

  • Server utama dan sekunder harus memiliki izin Get, wrapKey , dan unwrapKey ke brankas kunci server utama (brankas kunci yang menyimpan kunci pelindung TDE server utama).

  • Untuk server dengan rotasi kunci otomatis diaktifkan, sebelum memulai replikasi geografis, tambahkan kunci enkripsi yang digunakan sebagai pelindung TDE di server utama ke server sekunder. Server sekunder memerlukan akses ke kunci di brankas kunci yang sama atau HSM terkelola yang digunakan dengan server utama (dan bukan kunci lain dengan materi kunci yang sama). Atau, sebelum memulai replikasi geografis, pastikan bahwa identitas terkelola server sekunder (ditetapkan pengguna atau ditetapkan sistem) memiliki izin yang diperlukan pada brankas kunci server utama atau HSM terkelola, dan sistem mencoba menambahkan kunci ke server sekunder.

  • Untuk penyiapan replikasi geografis yang ada, sebelum mengaktifkan rotasi kunci otomatis di server utama, tambahkan kunci enkripsi yang digunakan sebagai pelindung TDE di server utama ke server sekunder. Server sekunder memerlukan akses ke kunci di brankas kunci yang sama atau HSM terkelola yang digunakan dengan server utama (dan bukan kunci lain dengan materi kunci yang sama). Atau, sebelum mengaktifkan kunci otomatis, pastikan bahwa identitas terkelola server sekunder (ditetapkan pengguna atau ditetapkan sistem) memiliki izin yang diperlukan pada brankas kunci server utama, dan sistem mencoba menambahkan kunci ke server sekunder.

  • Skenario geo-replikasi yang menggunakan kunci yang dikelola pelanggan (CMK) untuk TDE didukung. TDE dengan rotasi kunci otomatis harus dikonfigurasi di semua server jika Anda mengonfigurasi TDE di portal Microsoft Azure. Untuk informasi selengkapnya tentang menyiapkan rotasi kunci otomatis untuk konfigurasi replikasi geografis dengan TDE, lihat Rotasi kunci otomatis untuk konfigurasi replikasi geografis.

Pelindung TDE tidak dapat diakses

Ketika TDE dikonfigurasi untuk menggunakan kunci yang dikelola pelanggan, akses berkelanjutan ke pelindung TDE diperlukan agar database tetap online. Jika server kehilangan akses ke pelindung TDE yang dikelola pelanggan di Azure Key Vault atau Azure Managed HSM, dalam waktu hingga 10 menit database mulai menolak semua koneksi dengan pesan kesalahan yang sesuai dan mengubah statusnya menjadi Tidak Dapat Diakses. Satu-satunya tindakan yang diizinkan pada database dalam status Tidak Dapat Diakses adalah menghapusnya.

Status tidak dapat diakses

Jika database tidak dapat diakses karena pemadaman jaringan terputus-terputus (seperti kesalahan 5XX), tidak ada tindakan yang diperlukan, karena database kembali online secara otomatis. Untuk mengurangi efek kesalahan jaringan atau pemadaman saat mengakses pelindung TDE di Azure Key Vault atau Azure Managed HSM, buffer 24 jam diperkenalkan sebelum layanan mencoba memindahkan database ke status yang tidak dapat diakses. Jika failover terjadi sebelum mencapai status tidak dapat diakses, database menjadi tidak tersedia karena hilangnya cache enkripsi.

Jika server kehilangan akses ke pelindung TDE yang dikelola pelanggan di Azure Key Vault atau Azure Managed HSM karena kesalahan Azure Key Vault (seperti kesalahan 4XX), database dipindahkan ke status yang tidak dapat diakses setelah 30 menit.

Memulihkan akses database setelah kesalahan Azure Key Vault atau Azure Managed HSM

Setelah akses ke kunci dipulihkan, membawa database kembali online memerlukan waktu dan langkah tambahan, yang mungkin bervariasi berdasarkan durasi tidak tersedianya kunci dan ukuran data dalam database.

Jika akses kunci dipulihkan dalam waktu 30 menit, database akan dipulihkan secara otomatis dalam satu jam berikutnya. Namun, jika akses kunci dipulihkan setelah lebih dari 30 menit, penyembuhan otomatis database tidak dimungkinkan. Dalam kasus seperti itu, memulihkan database melibatkan prosedur tambahan melalui portal Microsoft Azure dan dapat memakan waktu, tergantung pada ukuran database.

Setelah database kembali online, pengaturan tingkat server yang dikonfigurasi sebelumnya, termasuk konfigurasi grup failover, tag, dan pengaturan tingkat database seperti konfigurasi kumpulan elastis, skala baca, jeda otomatis, riwayat pemulihan titik waktu, kebijakan penyimpanan jangka panjang, dan lainnya hilang. Oleh karena itu, disarankan agar pelanggan menerapkan sistem pemberitahuan untuk mendeteksi hilangnya akses kunci enkripsi dalam waktu 30 menit. Setelah jendela 30 menit kedaluwarsa, kami menyarankan untuk memvalidasi semua pengaturan tingkat server dan database pada database yang dipulihkan.

Berikut ini adalah tampilan langkah-langkah tambahan yang diperlukan di portal untuk membawa database yang tidak dapat diakses kembali online.

Cuplikan layar database TDE BYOK yang tidak dapat diakses.

Pencabutan akses pelindung TDE yang tidak disengaja

Mungkin saja seseorang yang memiliki akses memadai ke brankas kunci atau HSM terkelola secara tidak sengaja menonaktifkan akses server ke kunci dengan:

  • mencabut izin get, wrapKey, unwrapKey dari key vault atau HSM terkelola dari server

  • menghapus kunci

  • menghapus key vault atau HSM (Hardware Security Module) terkelola

  • mengubah aturan firewall key vault atau HSM terkelola

  • menghapus identitas server terkelola di ID Microsoft Entra

Pelajari selengkapnya tentang penyebab umum database menjadi tidak dapat diakses.

Konektivitas yang diblokir antara SQL Managed Instance dan Azure Key Vault atau Azure Managed HSM

Blok konektivitas jaringan antara SQL Managed Instance dan brankas kunci atau HSM terkelola sebagian besar terjadi ketika brankas kunci atau sumber daya HSM terkelola ada tetapi titik akhirnya tidak dapat dicapai dari instans terkelola. Semua skenario di mana brankas kunci atau titik akhir HSM terkelola dapat dicapai tetapi koneksi ditolak, izin yang hilang, dll., menyebabkan database mengubah statusnya menjadi Tidak Dapat Diakses.

Penyebab paling umum untuk kurangnya konektivitas jaringan ke Azure Key Vault atau Azure Managed HSM adalah:

  • Azure Key Vault atau Azure Managed HSM diekspos melalui titik akhir privat dan alamat IP privat layanan Azure Key Vault atau Azure Managed HSM tidak diizinkan dalam aturan keluar Grup Keamanan Jaringan (NSG) yang terkait dengan subnet instans terkelola.

  • Resolusi DNS buruk, seperti ketika Key Vault atau HSM Terkelola FQDN tidak dapat diselesaikan atau mengarah ke IP yang tidak valid.

Uji konektivitas dari SQL Managed Instance ke Azure Key Vault atau Azure Managed HSM yang menghosting pelindung TDE.

  • Titik akhir adalah FQDN vault Anda, seperti <vault_name.vault.azure.net> (tanpa https://).
  • Port yang akan diuji adalah 443.
  • Hasil untuk RemoteAddress harus ada dan menjadi alamat IP yang benar
  • Hasil untuk pengujian TCP harus TcpTestSucceeded: True.

Jika pengujian menampilkan TcpTestSucceeded: False, tinjau konfigurasi jaringan:

  • Periksa alamat IP yang ditetapkan dan konfirmasikan apakah alamat tersebut valid. Nilai yang hilang berarti ada masalah dengan resolusi DNS.

    • Pastikan bahwa grup keamanan jaringan pada instans terkelola memiliki aturan keluar yang mencakup alamat IP yang dipecahkan pada port 443, terutama ketika alamat yang dipecahkan termasuk dalam key vault atau titik akhir privat HSM terkelola.

    • Periksa konfigurasi jaringan lain seperti tabel rute, keberadaan appliance virtual dan konfigurasinya, dll.

Memantau TDE yang dikelola pelanggan

Untuk memantau status database dan mengaktifkan pemberitahuan kehilangan akses pelindung TDE, konfigurasikan fitur Azure berikut:

  • Azure Resource Health. Database yang tidak dapat diakses yang kehilangan akses ke pelindung TDE ditampilkan sebagai "Tidak Tersedia" setelah koneksi pertama ke database ditolak.

  • Log Aktivitas saat akses ke pelindung TDE di brankas kunci yang dikelola pelanggan gagal, entri ditambahkan ke log aktivitas. Membuat pemberitahuan untuk peristiwa ini memungkinkan Anda mengembalikan akses sesegera mungkin.

  • Grup Tindakan dapat didefinisikan untuk mengirimi Anda pemberitahuan dan pemberitahuan berdasarkan preferensi Anda, misalnya, Email/SMS/Push/Voice, Logic App, Webhook, ITSM, atau Automation Runbook.

Database backup dan restore dengan TDE yang dikelola pelanggan

Setelah database dienkripsi dengan TDE menggunakan kunci dari Azure Key Vault atau Azure Managed HSM, cadangan yang baru dibuat juga dienkripsi dengan pelindung TDE yang sama. Saat pelindung TDE diubah, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru.

Untuk memulihkan cadangan yang dienkripsi dengan pelindung TDE dari Azure Key Vault atau Azure Managed HSM, pastikan bahwa materi kunci tersedia untuk server target. Oleh karena itu, kami sarankan Anda menyimpan semua versi lama pelindung TDE di brankas kunci atau HSM terkelola, sehingga cadangan database dapat dipulihkan.

Penting

Tidak boleh ada lebih dari satu pelindung TDE yang ditetapkan untuk server pada satu waktu. Kunci yang ditandai dengan Jadikan kunci sebagai pelindung TDE default di panel portal Microsoft Azure adalah pelindung TDE. Namun, beberapa kunci dapat ditautkan ke server tanpa menandainya sebagai pelindung TDE. Kunci ini tidak digunakan untuk melindungi DEK, tetapi dapat digunakan selama pemulihan dari cadangan, jika file cadangan dienkripsi dengan kunci dengan thumbprint yang sesuai.

Jika kunci yang diperlukan untuk memulihkan cadangan tidak lagi tersedia untuk server target, pesan kesalahan berikut dikembalikan pada pemulihan coba: "Server target <Servername> tidak memiliki akses ke semua URI AKV yang dibuat antara <Tanda Waktu #1> dan <Tanda Waktu #2>. Coba lagi operasi setelah memulihkan semua URI AKV."

Untuk menguranginya, jalankan cmdlet Get-AzSqlServerKeyVaultKey untuk server target atau Get-AzSqlInstanceKeyVaultKey untuk instans terkelola target untuk mengembalikan daftar kunci yang tersedia dan mengidentifikasi yang hilang. Untuk memastikan semua cadangan dapat dipulihkan, pastikan server target untuk pemulihan memiliki akses ke semua kunci yang diperlukan. Kunci ini tidak perlu ditandai sebagai pelindung TDE.

Untuk mempelajari selengkapnya tentang pemulihan cadangan untuk SQL Database, lihat Memulihkan database dari cadangan di Azure SQL Database. Untuk pencadangan/pemulihan asli SQL Server dengan SQL Managed Instance, lihat Panduan Cepat: Memulihkan database ke Azure SQL Managed Instance dengan SQL Server Management Studio (SSMS).

Pertimbangan lain untuk file log: File log yang dicadangkan tetap dienkripsi dengan pelindung TDE asli, bahkan jika diputar dan database sekarang menggunakan pelindung TDE baru. Pada waktu pemulihan, kedua kunci diperlukan untuk memulihkan database. Jika file log menggunakan pelindung TDE yang disimpan di Azure Key Vault atau Azure Managed HSM, kunci ini diperlukan pada waktu pemulihan, bahkan jika database diubah untuk menggunakan TDE yang dikelola layanan sementara itu.

Ketersediaan tinggi dengan TDE yang pelanggan kelola

Dengan Azure Key Vault atau Azure Managed HSM yang menyediakan beberapa lapisan redundansi, TDE menggunakan kunci yang dikelola pelanggan dapat memanfaatkan ketersediaan dan ketahanan Azure Key Vault atau Azure Managed HSM, dan mengandalkan sepenuhnya pada solusi redundansi Azure Key Vault atau Azure Managed HSM.

Beberapa lapisan redundansi Azure Key Vault memastikan akses kunci meskipun komponen layanan individual gagal atau wilayah Azure atau zona ketersediaan tidak berfungsi. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault.

Azure Key Vault menawarkan komponen ketersediaan dan ketahanan berikut yang disediakan secara otomatis tanpa intervensi pengguna:

Nota

Untuk semua wilayah pasangan, kunci Azure Key Vault direplikasi ke kedua wilayah dan ada Modul Keamanan Perangkat Keras (HSM) di kedua wilayah yang dapat beroperasi pada kunci tersebut. Untuk informasi selengkapnya, lihat Replikasi data. Ini berlaku untuk tingkat layanan Azure Key Vault Standar dan Premium, dan kunci perangkat lunak atau perangkat keras.

Replikasi multi-wilayah Azure Managed HSM memungkinkan Anda memperluas kumpulan Azure Managed HSM dari satu wilayah Azure (disebut wilayah utama) ke wilayah Azure lain (disebut wilayah yang diperluas). Setelah dikonfigurasi, kedua wilayah aktif, dapat melayani permintaan dan, dengan replikasi otomatis, berbagi materi kunci, peran, dan izin yang sama. Untuk informasi selengkapnya, lihat Mengaktifkan replikasi multi-wilayah di Azure Managed HSM.

Pemulihan bencana geografis dengan TDE yang dikelola pelanggan

Replikasi geografis aktif dan grup failover mendukung TDE yang dikelola pelanggan. Server utama dan sekunder dapat menggunakan Azure Key Vault atau Azure Managed HSM di wilayah mana pun yang didukung. Server dan penyimpanan kunci tidak harus berada di wilayah yang sama.

Untuk failover yang berhasil, kedua server harus memiliki akses ke setiap Azure Key Vault atau Azure Managed HSM yang berisi kunci yang diperlukan.

Pertimbangan konfigurasi

Pertimbangan berikut berlaku saat Anda mengonfigurasi geo-replikasi aktif atau grup failover di portal Azure:

  • Lokasi pelindung TDE: Server utama dan sekunder dapat menggunakan Azure Key Vault atau Azure Managed HSM yang sama. Menggunakan penyimpanan kunci yang sama mengurangi risiko materi kunci menjadi tidak sinkron. Jika Anda menggunakan brankas kunci terpisah di beberapa wilayah, Anda harus menjaga materi kunci yang dibutuhkan tetap sinkron. Untuk informasi tentang ketahanan penyimpanan kunci, lihat ketersediaan dan redundansi Azure Key Vault serta replikasi multi-wilayah di Managed HSM.

  • Redundansi zona: Jika tersedia, redundansi zona untuk Azure SQL Database atau Azure SQL Managed Instance memberikan ketahanan ekstra dalam suatu wilayah. Untuk informasi selengkapnya, lihat Apa itu zona ketersediaan Azure?.

  • Izin kunci: Baik server utama maupun sekunder harus memiliki izin yang diperlukan pada setiap Azure Key Vault atau Azure Managed HSM yang memiliki pelindung TDE yang diperlukan.

  • Ketersediaan kunci: Pastikan kunci yang dibutuhkan tersedia di server utama dan sekunder. Server tidak perlu menggunakan pelindung TDE yang identik, tetapi setiap server harus memiliki material kunci yang sama. Anda dapat menambahkan kunci ke server dengan menggunakan portal Azure, PowerShell, Azure CLI, atau Azure SQL REST API. Jika kunci yang dibutuhkan tidak tersedia saat failover, database mungkin menjadi tidak dapat diakses.

  • Endpoint privat: Konfigurasi ini mungkin memerlukan zona DNS yang lebih kompleks jika Anda menggunakan endpoint privat di Azure SQL (misalnya, tidak dapat membuat dua endpoint privat ke sumber daya yang sama di zona DNS yang sama).

  • Konektivitas aplikasi: Aplikasi harus menggunakan logika percobaan ulang untuk menangani kegagalan sementara selama failover.

Untuk informasi tentang mengonfigurasi sumber daya pemulihan geo-bencana Azure SQL, lihat Active geo-replication atau Failover groups overview and best practices.

Penting

Saat Anda membuat tautan geo-replikasi atau grup failover, Azure SQL memastikan bahwa kedua server dapat mengakses semua kunci yang dikelola pelanggan yang diperlukan. Jika salah satu server tidak dapat mengakses kunci yang diperlukan, operasi pembuatan gagal. Misalnya, jika server utama dan sekunder menggunakan Key A dan Key B, masing-masing, tambahkan kedua key tersebut ke kedua server sebelum membuat geo-replication link atau failover group.

Diagram berikut menunjukkan geo-replikasi Azure SQL dengan grup failover serta failover lintas wilayah pada Azure Key Vault dalam konfigurasi wilayah berpasangan:

Diagram memperlihatkan dukungan failover lintas wilayah Azure Key Vault untuk wilayah yang dipasangkan.

Perilaku Azure Key Vault selama failover

  • Azure Key Vault yang memulai failover, bukan Anda.
  • Meskipun brankas kunci di wilayah utama tidak tersedia, brankas kunci hanya bisa dibaca.
  • Anda hanya dapat membuat, mengimpor, dan memutar kunci selama brankas kunci di wilayah utama tersedia. Setelah failover, rotasi kunci tetap terblokir sampai wilayah utama dapat dijangkau kembali.
  • Anda tidak bisa memilih atau memeriksa wilayah mana penyimpanan kunci saat ini, dan Anda tidak bisa terhubung ke wilayah sekunder secara manual.

Pemulihan dari pelindung TDE yang tidak dapat diakses

Jika sebuah database dalam hubungan geo-replikasi aktif atau grup failover menjadi tidak dapat diakses, control plane Azure SQL akan memutuskan tautan dan mengubah database menjadi database mandiri.

Setelah Anda mengembalikan izin kunci, biasanya Anda dapat mengaktifkan kembali database utama. Anda tidak bisa mengembalikan database sekunder ke online karena Azure SQL tidak menerima backup penuh dari database sekunder. Hapus database sekunder, lalu buat kembali tautan geo-replikasi atau grup failover.

Azure Policy untuk TDE yang dikelola oleh pelanggan

Azure Policy dapat digunakan untuk memberlakukan TDE yang dikelola pelanggan selama pembuatan atau pembaruan server Azure SQL Database atau Azure SQL Managed Instance. Dengan kebijakan ini, setiap upaya untuk membuat atau memperbarui server logis di Azure atau instans terkelola gagal jika tidak dikonfigurasi dengan kunci yang dikelola pelanggan. Azure Policy dapat diterapkan ke seluruh langganan Azure, atau hanya dalam grup sumber daya.

Untuk informasi selengkapnya tentang Azure Policy, lihat Apa itu Azure Policy dan struktur definisi Azure Policy .

Dua kebijakan bawaan berikut ini didukung untuk TDE yang dikelola pelanggan di Azure Policy:

  • Server SQL harus menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data saat tidak aktif
  • Instans terkelola harus menggunakan kunci yang dikelola oleh pelanggan untuk mengenkripsi data yang disimpan

Kebijakan TDE yang dikelola pelanggan dapat dikelola dengan masuk ke portal Microsoft Azure, dan mencari layanan Kebijakan . Di bawah Definisi, cari kunci yang dikelola pelanggan.

Ada tiga efek untuk kebijakan ini:

  • Audit - Pengaturan default, dan hanya mengambil laporan audit di log aktivitas Azure Policy

  • Tolak - Mencegah pembuatan atau pembaruan server logis atau instans terkelola jika kunci yang dikelola pelanggan belum dikonfigurasi

  • Dinonaktifkan - Menonaktifkan kebijakan dan tidak membatasi pengguna untuk membuat atau memperbarui server logis atau instans terkelola tanpa mengaktifkan TDE yang dikelola pelanggan

Jika peraturan Azure Policy untuk TDE yang dikelola pelanggan diatur ke Tolak, pembuatan server logis Azure SQL atau instans terkelola akan gagal. Detail kegagalan ini dicatat dalam log Aktivitas grup sumber daya.

Penting

Versi kebijakan terintegrasi yang lebih lama untuk TDE yang dikelola oleh pelanggan dan berisi AuditIfNotExists efek tidak digunakan lagi. Penetapan kebijakan yang ada menggunakan kebijakan yang tidak digunakan lagi tidak terpengaruh dan terus berfungsi seperti sebelumnya.

TDE in Azure Synapse Analytics

Untuk informasi tentang TDE dengan kunci yang dikelola pelanggan di Azure Synapse Analytics, lihat TDE dengan kunci yang dikelola pelanggan. Untuk mempelajari selengkapnya tentang pemulihan cadangan untuk kumpulan SQL khusus di Azure Synapse Analytics, lihat Memulihkan kumpulan SQL khusus.

Konten terkait

  • Terakhir diperbarui pada