Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk: Kumpulan SQL khusus Azure Synapse Analytics (sebelumnya SQL DW)
Tip
Microsoft Fabric Data Warehouse adalah gudang relasional skala perusahaan pada fondasi data lake, dengan arsitektur siap masa depan, AI bawaan, dan fitur baru. Jika Anda baru menggunakan pergudangan data, mulailah dengan Fabric Data Warehouse. Beban kerja kumpulan SQL terdedikasi yang ada dapat ditingkatkan ke Fabric untuk mengakses kemampuan baru di seluruh ilmu data, analitik waktu nyata, dan pelaporan.
Enkripsi data transparan (TDE) 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 menggunakan TDE yang dikelola oleh pelanggan, Anda memikul tanggung jawab atas dan memiliki kendali penuh atas manajemen siklus hidup kunci (pembuatan, pengunggahan, rotasi, penghapusan kunci), izin penggunaan kunci, dan pengauditan 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.
Note
Artikel ini membahas pool SQL khusus mandiri (sebelumnya SQL DW).
- Untuk pool SQL khusus Azure Synapse Analytics (sebelumnya SQL DW), atur pelindung TDE di tingkat server. Semua database terenkripsi yang terkait dengan server tersebut mewarisi pelindung TDE.
- Enkripsikan data dalam pool SQL khusus dan pool SQL tanpa server di workspace Synapse dengan menggunakan kunci yang dikelola pelanggan yang dikonfigurasi di tingkat workspace. Untuk informasi selengkapnya tentang enkripsi data transparan untuk kumpulan SQL khusus di dalam ruang kerja Synapse, lihat Enkripsi Azure Synapse Analytics.
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) - Anda mengelola siklus hidup kunci, termasuk pembuatan, rotasi, dan penghapusan kunci. Simpan kunci tersebut di Azure Key Vault atau Azure Managed HSM dan gunakan untuk enkripsi Database Encryption Key (DEK).
Bawa Kunci Anda Sendiri (BYOK) - Anda dengan aman membawa atau mengimpor kunci Anda sendiri dari modul keamanan perangkat keras (HSM) on-premises ke Azure Key Vault. 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:
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.
Important
Bagi mereka yang menggunakan TDE yang dikelola oleh layanan dan ingin mulai menggunakan TDE yang dikelola oleh pelanggan, data tetap terenkripsi selama proses peralihan, dan tidak memerlukan waktu henti maupun enkripsi ulang pada 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 di Azure Key Vault
Pilih jenis Azure Key Vault yang ingin Anda gunakan.
Agar SQL logical server di Azure dapat menggunakan pelindung TDE yang disimpan di Azure Key Vault untuk enkripsi DEK, Key Vault Administrator perlu memberikan hak akses ke server dengan 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. Identitas server memerlukan peran Key Vault Crypto Service Encryption User untuk menggunakan kunci bagi 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 membutuhkan izin berikut pada key vault:
- 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 petunjuk langkah demi langkah untuk menyiapkan konfigurasi akses Azure Key Vault untuk TDE, lihat Siapkan Extensible Key Management TDE SQL Server 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.
Ketika Anda mengonfigurasi server untuk menggunakan pelindung TDE dari Azure Key Vault, server mengirimkan DEK dari setiap database yang diaktifkan TDE ke key vault untuk enkripsi. Key vault mengembalikan DEK terenkripsi, yang disimpan server di database pengguna.
Jika diperlukan, server mengirim DEK yang dilindungi ke vault kunci untuk didekripsi.
Auditor dapat menggunakan Azure Monitor untuk meninjau log AuditEvent Key Vault jika pengelogan diaktifkan.
Note
Mungkin butuh sekitar 10 menit agar perubahan izin berlaku untuk Key Vault. Proses ini mencakup pencabutan izin akses ke pelindung TDE di AKV, dan pengguna mungkin masih memiliki izin akses.
Persyaratan untuk mengonfigurasi TDE yang dikelola pelanggan di Azure Key Vault
Aktifkan fitur soft-delete dan perlindungan purge pada Azure Key Vault. Konfigurasi ini membantu mencegah penghapusan key vault atau key secara tidak sengaja atau berbahaya yang dapat menyebabkan database masuk ke status Tidak Dapat Diakses. Saat Anda mengonfigurasi pelindung TDE pada server yang sudah ada atau selama pembuatan server, Azure SQL memvalidasi bahwa key vault yang Anda gunakan mengaktifkan soft-delete dan perlindungan purge. Jika perlindungan penghapusan sementara dan penghapusan menyeluruh tidak diaktifkan pada brankas kunci, penyiapan pelindung TDE gagal dengan kesalahan. Dalam hal ini, aktifkan soft-delete dan perlindungan purge pada key vault, lalu lakukan penyiapan pelindung TDE.
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 protektor TDE, yang disimpan di Azure Key Vault untuk melindungi kunci enkripsi basis data (DEK).
Persyaratan berikut berlaku.
Jenis dan ukuran kunci yang didukung
Pelindung TDE dapat menggunakan kunci asimetris yang disimpan di Azure Key Vault. Ukuran kunci yang didukung adalah 2.048-bit dan 3.072-bit.
Persyaratan status dan validitas utama
- Jika Anda menentukan tanggal aktivasi kunci, atur tanggal dan waktu tersebut ke waktu di masa lalu.
- Jika Anda menentukan tanggal kedaluwarsa kunci, atur ke tanggal dan waktu di masa depan.
- 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
Rekomendasi untuk mengonfigurasi TDE yang dikelola pelanggan di Azure Key Vault
Untuk mempertahankan ketersediaan tinggi dan menghindari masalah pembatasan, ikuti panduan ini per langganan:
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 lebih lanjut tentang perilaku throttling, lihat panduan throttling Azure Key Vault.
Jumlah database Hyperscale yang dapat Anda kaitkan dengan satu Azure Key Vault tergantung pada jumlah server halaman. Setiap server halaman ditautkan ke file data logis. Untuk menemukan jumlah page server, 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 lebih lanjut tentang pemantauan dan pemberitahuan, lihat Pantau Azure Key Vault dan Konfigurasikan peringatan Azure Key Vault.
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. Untuk mempelajari lebih lanjut tentang penguncian 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.
Rekomendasi untuk mengonfigurasi pelindung TDE
Simpan salinan pelindung TDE di lokasi yang aman atau tempatkan salinan pelindung TDE tersebut dalam escrow pada layanan escrow.
Jika Anda menghasilkan kunci di Key Vault, buat cadangan kunci sebelum menggunakan kunci tersebut di Azure Key Vault untuk pertama kalinya. Anda hanya dapat mengembalikan cadangan ke Azure Key Vault. Untuk mempelajari lebih lanjut, lihat perintah Backup-AzKeyVaultKey. Azure Managed HSM mendukung pembuatan backup penuh dari seluruh isi HSM, termasuk semua kunci, versi, atribut, tag, dan penugasan peran. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan penuh dan pemulihan kunci selektif.
Buat cadangan baru setiap kali Anda melakukan perubahan 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 pernah digunakan sebelumnya di Azure Key Vault bahkan setelah beralih ke kunci yang dikelola layanan. Ini memastikan cadangan basis data dapat dipulihkan dengan protector TDE yang disimpan di Azure Key Vault. Pelindung TDE yang dibuat dengan Azure Key Vault harus dipelihara sampai semua cadangan yang tersisa dibuat dengan kunci yang dikelola layanan. Buat salinan cadangan yang dapat dipulihkan dari kunci ini dengan 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.
Rotasi pelindung TDE
Saat Anda memutar pelindung TDE, Anda mengganti kunci yang melindungi kunci enkripsi database (DEK). Rotasi kunci adalah operasi online dan hanya memakan waktu beberapa detik. Operasi ini hanya mendekripsi dan mengenkripsi ulang kunci enkripsi basis data, bukan seluruh basis data.
Anda dapat merotasi pelindung TDE dengan mengalihkan konfigurasi untuk menggunakan kunci baru yang disimpan di Azure Key Vault. Tergantung pada penawaran dan konfigurasi yang didukung, kunci ini dapat berupa:
- Beralih ke versi kunci baru dari kunci yang sama
- Beralih ke kunci lain
Rotasi pelindung TDE dapat dilakukan secara manual atau menggunakan fitur rotasi otomatis.
Anda dapat mengaktifkan rotasi otomatis pelindung TDE saat mengonfigurasi pelindung TDE untuk server. Rotasi otomatis dinonaktifkan secara default. Saat diaktifkan, server secara terus-menerus memeriksa Key Vault untuk versi baru dari kunci yang digunakan sebagai pelindung TDE. Jika server mendeteksi versi baru dari kunci, server akan secara otomatis merotasi pelindung TDE di server atau database ke versi kunci terbaru dalam waktu 24 jam.
Note
Ketika Anda mengatur TDE dengan CMK menggunakan rotasi kunci secara manual atau otomatis, Anda selalu menggunakan versi terbaru dari kunci yang didukung oleh sistem. 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.
Pelindung TDE tidak dapat diakses
Ketika Anda mengonfigurasi TDE untuk menggunakan kunci yang dikelola pelanggan, basis data membutuhkan akses terus-menerus ke protector TDE agar tetap online. Jika server kehilangan akses ke pelindung TDE yang dikelola pelanggan di Azure Key Vault, basis data mulai menolak semua koneksi dalam waktu 10 menit, menampilkan pesan kesalahan, 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 gangguan saat mengakses pelindung TDE di Azure Key Vault, layanan memperkenalkan buffer 24 jam sebelum mencoba memindahkan database ke status 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 karena kesalahan Azure Key Vault (seperti kesalahan 4XX), basis data akan berpindah ke status tidak dapat diakses setelah 30 menit.
Pulihkan akses database setelah terjadi kesalahan Azure Key Vault
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.
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 terblokir antara SQL Managed Instance dan Azure Key Vault
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 kurangnya konektivitas jaringan ke Azure Key Vault adalah:
Azure Key Vault terekspos melalui endpoint privat dan alamat IP privat layanan Azure Key Vault tidak diizinkan dalam aturan outbound Network Security Group (NSG) yang terkait dengan subnet instance yang dikelola.
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 yang menjadi host 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 dan kehilangan akses ke pelindung TDE akan muncul sebagai "Tidak Tersedia" setelah upaya koneksi pertama ke database ditolak.
Log Aktivitas saat akses ke pelindung TDE di brankas kunci yang dikelola pelanggan gagal, entri ditambahkan ke log aktivitas. Dengan membuat peringatan untuk peristiwa ini, Anda dapat mengaktifkan kembali akses secepat mungkin.
Action Group dapat didefinisikan untuk mengirimkan notifikasi dan peringatan berdasarkan preferensi Anda, misalnya, Email, SMS, Push, Voice, Logic App, Webhook, ITSM, atau Automation Runbook.
Pencadangan dan pemulihan basis data dengan TDE yang dikelola pelanggan
Setelah database dienkripsi dengan TDE menggunakan kunci dari Azure Key Vault, 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, pastikan material kunci tersedia untuk server target. Oleh karena itu, simpan semua versi lama dari protektor TDE di Key Vault atau HSM yang dikelola, sehingga cadangan basis data dapat dipulihkan.
Important
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-kunci ini tidak digunakan untuk melindungi DEK, tetapi dapat digunakan saat pemulihan dari cadangan jika file cadangan dienkripsi dengan kunci yang memiliki 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 backup 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 kumpulan SQL khusus di Azure Synapse Analytics, lihat Memulihkan kumpulan SQL khusus.
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, kunci ini diperlukan saat pemulihan, meskipun database telah diubah untuk menggunakan TDE yang dikelola layanan sementara itu.
Ketersediaan tinggi dengan TDE yang pelanggan kelola
Dengan menggunakan berbagai lapisan redundansi Azure Key Vault, TDE yang menggunakan kunci yang dikelola pelanggan dapat memperoleh manfaat dari ketersediaan dan ketahanan Azure Key Vault. Mereka dapat sepenuhnya mengandalkan solusi redundansi Azure Key Vault.
Beberapa lapisan redundansi Azure Key Vault memastikan akses kunci meskipun komponen layanan individu gagal atau wilayah Azure atau zona ketersediaan mengalami gangguan. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault.
Azure Key Vault menawarkan komponen ketersediaan dan ketahanan berikut secara otomatis tanpa intervensi pengguna: