Enkripsi data transparan Azure SQL dengan kunci yang dikelola pelanggan

BERLAKU UNTUK: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics

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

Dalam skenario ini, kunci yang digunakan untuk enkripsi Kunci Enkripsi Database (DEK), yang disebut pelindung TDE, adalah kunci asimetris yang dikelola pelanggan yang disimpan dalam Azure Key Vault (AKV)milik pelanggan dan dikelola pelanggan, sistem manajemen kunci eksternal berbasis cloud. Key Vault adalah penyimpanan aman yang sangat tersedia dan dapat diskalakan untuk kunci kriptografi RSA, yang secara opsional didukung oleh modul keamanan perangkat keras tervalidasi FIPS 140-2 Level 2 (HSM). Hal ini tidak memungkinkan akses langsung ke kunci yang disimpan, tetapi menyediakan layanan enkripsi / dekripsi menggunakan kunci ke entitas yang diotorisasi. Kunci dapat dihasilkan oleh key vault, diimpor, atau ditransfer ke key vault dari perangkat HSM on-prem.

Untuk Azure SQL Database dan Azure Synapse Analytics, pelindung TDE diatur di tingkat server dan diwarisi oleh semua database terenkripsi yang terkait dengan server tersebut. Untuk Azure SQL Managed Instance, pelindung TDE diatur pada tingkat instans dan diwarisi oleh semua database terenkripsi pada instans tersebut. Istilah server mengacu kepada server di SQL Database dan Azure Synapse dan ke instans terkelola di SQL Managed Instance di seluruh dokumen ini, kecuali dinyatakan berbeda.

Catatan

Artikel ini berlaku untuk Azure SQL Database, Azure SQL Managed Instance, dan Azure Synapse Analytics (kumpulan SQL khusus (sebelumnya SQL DW)). Untuk dokumentasi tentang enkripsi data transparan untuk kumpulan SQL khusus di dalam ruang kerja Synapse, lihat enkripsi Azure Synapse Analytics.

Penting

Bagi mereka yang menggunakan TDE yang dikelola layanan yang ingin mulai menggunakan TDE yang dikelola pelanggan, data tetap dienkripsi selama proses peralihan, 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.

Catatan

Untuk menyediakan pelanggan Azure SQL dengan dua lapisan enkripsi data tidak aktif, enkripsi infrastruktur (menggunakan algoritma enkripsi AES-256) dengan kunci yang dikelola platform sedang diluncurkan. Hal ini menyediakan lapisan enkripsi tambahan saat tidak aktif bersama dengan TDE dengan kunci yang dikelola pelanggan yang sudah tersedia. Untuk Microsoft Azure SQL Database dan Instans Terkelola, semua database, termasuk database master dan database sistem lainnya, akan dienkripsi saat enkripsi infrastruktur diaktifkan. Saat ini, pelanggan harus meminta akses ke kemampuan ini. Jika Anda tertarik dengan kemampuan ini, hubungi AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

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 melaksanakan pemisahan tugas dalam pengelolaan kunci dan data dalam organisasi;

  • Administrator Vault Kunci dapat mencabut izin akses kunci untuk membuat database terenkripsi tidak dapat diakses;

  • Manajemen pusat kunci dalam AKV;

  • Kepercayaan yang lebih besar dari pelanggan akhir Anda, karena AKV dirancang sedemikian rupa sehingga Microsoft tidak dapat melihat atau mengekstrak kunci enkripsi;

Cara kerja TDE yang dikelola pelanggan

Setup and functioning of the customer-managed TDE

Agar server Azure SQL menggunakan pelindung TDE yang disimpan di AKV untuk enkripsi DEK, administrator key vault perlu memberikan hak akses berikut ke server menggunakan identitas unik Azure Active Directory (Azure AD):

  • get - untuk mengambil bagian publik dan properti kunci di Key Vault

  • wrapKey - untuk dapat melindungi (mengenkripsi) DEK

  • unwrapKey - untuk dapat membuka proteksi (dekripsi) DEK

Administrator key vault juga dapat mengaktifkan pencatatan peristiwa audit key vault, sehingga dapat diaudit nanti.

Ketika server dikonfigurasi untuk menggunakan pelindung TDE dari AKV, server mengirimkan DEK dari setiap database yang diaktifkan TDE ke Key Vault untuk enkripsi. Key Vault mengembalikan DEK terenkripsi, yang kemudian disimpan dalam database pengguna.

Bila diperlukan, server mengirim DEK yang dilindungi ke key vault untuk dekripsi.

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

Catatan

Mungkin perlu waktu sekitar 10 menit agar perubahan izin berlaku untuk 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 TDE yang dikelola pelanggan

Persyaratan untuk mengonfigurasi AKV

  • Key vault dan SQL Database/instans terkelola harus dimiliki oleh penyewa Azure Active Directory yang sama. Key vault lintas-penyewa dan interaksi server tidak didukung. Untuk memindahkan sumber daya setelahnya, TDE dengan AKV harus dikonfigurasi ulang. Pelajari selengkapnya tentang memindahkan sumber daya.

  • Fitur Hapus lunak dan Perlindungan hapus menyeluruh harus diaktifkan pada key vault, untuk melindungi dari kehilangan data karena penghapusan kunci (atau key vault) secara tidak disengaja.

    • Sumber daya yang dihapus secara lunak dipertahankan selama 90 hari, kecuali dipulihkan atau dihapus seluruhnya oleh pelanggan. Tindakan recover dan purge memiliki izin sendiri yang terkait dalam kebijakan akses key vault. Fitur Hapus lunak dapat diaktifkan menggunakan portal Azure, PowerShell, atau Azure CLI.
    • Perlindungan hapus menyeluruh dapat diaktifkan menggunakan Azure CLI atau PowerShell. Saat perlindungan hapus menyeluruh aktif, vault atau objek dalam status terhapus tidak dapat dihapus menyeluruh hingga periode penyimpanan telah berlalu. Periode retensi default adalah 90 hari, tetapi dapat dikonfigurasi dari 7 hingga 90 hari melalui portal Azure.

Penting

Perlindungan Hapus lunak dan Hapus menyeluruh harus diaktifkan pada key vault untuk server yang dikonfigurasi dengan TDE yang dikelola pelanggan, serta server yang ada menggunakan TDE yang dikelola pelanggan.

  • Berikan server atau akses instans terkelola ke key vault (dapatkan, wrapKey, unwrapKey) menggunakan identitas Azure Active Directory. Identitas server dapat berupa identitas terkelola yang ditetapkan sistem atau identitas terkelola yang ditetapkan pengguna yang ditetapkan ke server. Saat menggunakan portal Azure, identitas Azure AD akan dibuat secara otomatis saat server dibuat. Saat menggunakan PowerShell atau CLI, identitas Azure Active Directory harus dibuat secara eksplisit dan penyelesaian harus diverifikasi. Lihat Mengonfigurasi TDE dengan BYOK dan Mengonfigurasi TDE dengan BYOK untuk Azure SQL Managed Instance untuk instruksi langkah demi langkah terperinci saat menggunakan PowerShell.

    • Bergantung pada model izin dari key vault (kebijakan akses atau Azure RBAC), akses key vault dapat diberikan baik dengan membuat kebijakan akses di lemari besi utama, atau dengan membuat tugas peran Azure RBAC baru dengan peran Key Vault Crypto Service Encryption User.
  • Saat menggunakan firewall dengan AKV, Anda harus mengaktifkan opsi Allow trusted Microsoft services to bypass the firewall.

Persyaratan untuk mengonfigurasi pelindung TDE

  • Pelindung TDE hanya dapat berupa kunci asimetris, RSA, atau RSA HSM. Panjang kunci yang didukung adalah 2048 byte dan 3072 byte.

  • Tanggal aktivasi kunci (jika ditetapkan) harus merupakan tanggal dan waktu yang sudah lalu. Tanggal kedaluwarsa (jika ditetapkan) harus merupakan tanggal dan waktu yang akan datang.

  • Kunci harus dalam status Diaktifkan.

  • Jika Anda mengimpor kunci yang ada ke dalam key vault, pastikan untuk menyediakannya dalam format file yang didukung (.pfx, .byok, atau .backup).

Catatan

Azure SQL kini mendukung penggunaan kunci RSA yang disimpan dalam Managed HSM sebagai TDE Protector. Azure Key Vault Managed HSM adalah layanan cloud yang dikelola penuh, sangat tersedia, penyewa tunggal, mematuhi standar yang memungkinkan Anda melindungi kunci kriptografi untuk aplikasi cloud Anda, menggunakan HSM tervalidasi FIPS 140-2 Tingkat 3. Pelajari lebih lanjut tentang Managed HSMs.

Rekomendasi saat mengonfigurasi TDE yang dikelola pelanggan

Rekomendasi saat mengonfigurasi AKV

  • Kaitkan paling banyak 500 database General Purpose atau 200 Business Critical secara total dengan key vault dalam satu langganan untuk memastikan ketersediaan tinggi saat server mengakses pelindung TDE di key vault. Angka-angka ini didasarkan pada pengalaman dan didokumentasikan dalam batas layanan key vault. Tujuan di sini adalah untuk mencegah masalah setelah kegagalan server, karena akan memicu sebanyak mungkin operasi kunci terhadap vault karena ada database di server itu.

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

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

  • Tautkan setiap server dengan dua key vault yang berada di berbagai wilayah dan memiliki materi kunci yang sama, untuk memastikan ketersediaan database terenkripsi yang tinggi. Tandai kunci dari salah satu key vault sebagai pelindung TDE. Sistem akan secara otomatis beralih ke key vault di wilayah kedua dengan materi kunci yang sama, jika ada pemadaman yang memengaruhi key vault di wilayah pertama.

Catatan

Untuk memungkinkan fleksibilitas yang lebih besar dalam mengonfigurasi TDE yang dikelola pelanggan, server Azure SQL Database dan Instans Terkelola di satu wilayah sekarang dapat dihubungkan ke key vault di wilayah lain. Server dan key vault tidak harus terletak bersama di wilayah yang sama.

Rekomendasi saat mengonfigurasi pelindung TDE

  • Simpan salinan pelindung TDE di tempat yang aman atau escrow ke layanan escrow.

  • Jika kunci dibuat di Key Vault, buat cadangan kunci sebelum menggunakan kunci di AKV untuk pertama kalinya. Pencadangan hanya dapat dipulihkan ke Azure Key Vault. Pelajari lebih lanjut tentang perintah Backup-AzKeyVaultKey.

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

  • Tetap menggunakan versi sebelumnya dari kunci pada key vault saat merotasi kunci, sehingga cadangan database yang lebih lama dapat dipulihkan. Ketika pelindung TDE diubah untuk database, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru. Pada waktu pemulihan, setiap cadangan membutuhkan pelindung TDE yang dienkripsi pada waktu pembuatan. Rotasi kunci dapat dilakukan dengan mengikuti petunjuk di Memutar Pelindung enkripsi data transparan Menggunakan PowerShell.

  • Simpan semua kunci yang sebelumnya digunakan di AKV bahkan setelah beralih ke kunci yang dikelola layanan. Hal ini memastikan cadangan database dapat dipulihkan dengan pelindung TDE yang disimpan di AKV. Pelindung TDE yang dibuat dengan Azure Key Vault harus dipertahankan sampai semua cadangan yang disimpan 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 dari Hapus kunci yang berpotensi disusupi.

Pelindung TDE yang 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 AKV, dalam waktu hingga 10 menit database akan mulai menolak semua koneksi dengan pesan kesalahan yang sesuai dan mengubah statusnya menjadi Tidak Dapat Diakses. Satu-satunya tindakan yang diizinkan pada database dalam keadaan Tidak Dapat Diakses adalah menghapusnya.

Catatan

Jika database tidak dapat diakses karena pemadaman jaringan terputus-terputus, tidak ada tindakan yang diperlukan dan database akan kembali online secara otomatis.

Setelah akses ke kunci dipulihkan, mengambil kembali database secara online memerlukan langkah tambahan, yang mungkin berbeda-beda berdasarkan waktu yang berlalu tanpa akses ke kunci dan ukuran database:

  • Jika akses kunci dipulihkan dalam waktu 30 menit, database akan dikembalikan secara otomatis dalam waktu satu jam ke depan.

  • Jika akses kunci dipulihkan setelah lebih dari 30 menit, pemulihan otomatis tidak dimungkinkan dan mengembalikan database membutuhkan langkah-langkah tambahan di portal dan dapat membutuhkan waktu yang cukup lama tergantung ukuran database. Setelah database kembali online, pengaturan tingkat server yang dikonfigurasi sebelumnya seperti konfigurasi grup failover, riwayat pemulihan waktu, dan tag akan hilang. Oleh karena itu, disarankan untuk menerapkan sistem pemberitahuan yang memungkinkan Anda mengidentifikasi dan mengatasi masalah akses utama yang mendasarinya dalam waktu 30 menit.

Di bawah ini adalah tampilan langkah-langkah tambahan yang diperlukan di portal untuk mengembalikan database yang tidak dapat diakses kembali online.

TDE BYOK Inaccessible Database

Pencabutan akses pelindung TDE yang tidak disengaja

Bisa jadi seseorang dengan hak akses yang memadai ke key vault secara tidak sengaja menonaktifkan akses server ke kunci dengan:

  • mencabut izin key vault get, wrapKey, unwrapKey dari server

  • menghapus kunci

  • menghapus key vault

  • mengubah aturan firewall key vault

  • menghapus identitas server yang dikelola di Azure Active Directory

Pelajari selengkapnya tentang penyebab umum database menjadi tidak dapat diakses.

Manfaat TDE yang dikelola pelanggan

Untuk memantau status database dan mengaktifkan peringatan hilangnya akses pelindung TDE, konfigurasikan fitur Azure berikut ini:

  • Kesehatan Sumber Daya Azure. Database yang tidak dapat diakses yang kehilangan akses ke pelindung TDE akan ditampilkan sebagai "Tidak Tersedia" setelah koneksi pertama ke database ditolak.
  • Log Aktivitas ketika akses ke pelindung TDE di key vault yang dikelola pelanggan gagal, entri ditambahkan ke log aktivitas. Membuat pemberitahuan untuk peristiwa ini akan memungkinkan Anda untuk mengembalikan akses sesegera mungkin.
  • Grup Tindakan dapat didefinisikan untuk mengirimkan Anda pemberitahuan dan peringatan berdasarkan preferensi Anda, misalnya, Email / SMS / Push / Voice, Aplikasi Logika, Webhook, ITSM, atau Automasi Runbook.

Pencadangan dan pemulihan database dengan TDE yang dikelola pelanggan

Setelah database dienkripsi dengan TDE menggunakan kunci dari Key Vault, cadangan yang baru dihasilkan juga dienkripsi dengan pelindung TDE yang sama. Ketika pelindung TDE diubah untuk database, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru.

Untuk memulihkan backup yang dienkripsi dengan pelindung TDE dari Key Vault, pastikan bahwa material kunci tersedia untuk server target. Oleh karena itu, kami menyarankan agar Anda menyimpan semua versi lama pelindung TDE di key vault, sehingga cadangan database dapat dipulihkan.

Penting

Kapan pun juga tidak boleh ada lebih dari satu pelindung TDE yang ditetapkan untuk sebuah server. Ini adalah kunci yang ditandai dengan "Make the key the default TDE protector" di bilah portal Microsoft Azure. Namun, beberapa kunci tambahan dapat ditautkan ke server tanpa menandainya sebagai pelindung TDE. Kunci ini tidak digunakan untuk melindungi DEK, tetapi dapat digunakan selama pemulihan dari backup, jika file backup dienkripsi dengan kunci dengan cap jempol yang sesuai.

Jika kunci yang diperlukan untuk memulihkan backup 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 yang dikelola 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 backup untuk SQL Database, lihat Memulihkan database di Database SQL. Untuk mempelajari selengkapnya tentang pemulihan backup untuk kumpulan SQL khusus di Azure Synapse Analytics, lihat Memulihkan kumpulan SQL khusus. Untuk backup/pemulihan asli SQL Server dengan Instans Terkelola SQL, lihat Quickstart: Memulihkan database ke Azure SQL Managed Instance

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

Ketersediaan tinggi dengan TDE yang dikelola pelanggan

Bahkan dalam kasus ketika tidak ada geo-redundansi yang dikonfigurasi untuk server, sangat disarankan untuk mengonfigurasi server agar menggunakan dua key vault yang berbeda di dua wilayah berbeda dengan materi kunci yang sama. Kunci di key vault sekunder di wilayah lain tidak boleh ditandai sebagai pelindung TDE, dan hal ini bahkan tidak diizinkan. Jika ada pemadaman yang memengaruhi key vault utama, dan hanya setelah itu, sistem akan secara otomatis beralih ke kunci lain yang ditautkan dengan sidik jari yang sama di key vault sekunder, jika ada. Perhatikan bahwa pergantian tidak akan terjadi jika pelindung TDE tidak dapat diakses karena hak akses yang dicabut, atau karena kunci atau key vault dihapus, karena mungkin menunjukkan bahwa pelanggan sengaja ingin membatasi server untuk mengakses kunci. Memberikan material kunci yang sama untuk dua key vault di berbagai wilayah dapat dilakukan dengan membuat kunci di luar key vault, dan mengimpornya ke dalam kedua key vault.

Atau, hal ini dapat dilakukan dengan membuat kunci menggunakan key vault utama di satu wilayah dan mengkloning kunci ke key vault di wilayah Azure yang berbeda. Gunakan cmdlet Backup-AzKeyVaultKey untuk mengambil kunci dalam format terenkripsi dari key vault utama dan kemudian gunakan cmdlet Restore-AzKeyVaultKey dan tentukan key vault di wilayah kedua untuk mengkloning kunci. Atau, gunakan portal Microsoft Azure untuk backup dan memulihkan kunci. Operasi backup/pemulihan kunci hanya diperbolehkan antara key vault dalam langganan Azure yang sama dan geografi Azure.

Single-Server HA

Geo-DR dan TDE yang dikelola pelanggan

Dalam skenario replikasi geografis aktif dan grup failover, server primer dan sekunder yang terlibat dapat ditautkan ke key vault yang sama (di wilayah mana pun) atau ke key vault yang terpisah. Jika key vault terpisah ditautkan ke server utama dan sekunder, pelanggan bertanggung jawab untuk menjaga konsistensi materi kunci di seluruh key vault, sehingga geo-sekunder sinkron dan dapat mengambil alih menggunakan kunci yang sama dari key vault yang ditautkan jika kunci primer menjadi tidak dapat diakses karena pemadaman di wilayah dan failover dipicu. Anda dapat mengonfigurasi hingga empat server sekunder, dan penautan (sekunder dari sekunder) tidak didukung.

Untuk menghindari masalah saat membuat atau selama replikasi-geo karena materi kunci yang tidak lengkap, penting untuk mengikuti aturan ini saat mengonfigurasi TDE yang dikelola pelanggan (jika key vault terpisah digunakan untuk server primer dan sekunder):

  • Semua key vault yang terlibat harus memiliki properti yang sama, dan hak akses yang sama untuk masing-masing server.

  • Semua key vault yang terlibat harus berisi material kunci yang identik. Hal ini tidak hanya berlaku untuk pelindung TDE saat ini, tetapi untuk semua pelindung TDE sebelumnya yang dapat digunakan dalam file backup.

  • Pengaturan awal dan rotasi terhadap pelindung TDE harus dilakukan pada sekunder terlebih dahulu, lalu pada primer.

Failover groups and geo-dr

Untuk menguji failover, ikuti langkah-langkah dalam ikhtisar geo-replikasi aktif. Pengujian failover harus dilakukan secara teratur untuk memvalidasi bahwa SQL Database telah mempertahankan izin akses ke kedua key vault.

Server Azure SQL Database dan Instans Terkelola di satu wilayah sekarang dapat dihubungkan ke brankas kunci di wilayah lain. Server dan key vault tidak harus terletak bersama di wilayah yang sama. Dengan ini, untuk kesederhanaan, server primer dan sekunder dapat dihubungkan ke key vault yang sama (di wilayah mana pun). Ini akan membantu menghindari skenario ketika bahan kunci mungkin tidak sinkron jika key vault terpisah digunakan untuk kedua server. Azure Key Vault memiliki beberapa lapisan redundansi untuk memastikan bahwa kunci dan key vault Anda tetap tersedia jika terjadi kegagalan layanan atau wilayah. Ketersediaan dan redundansi Azure Key Vault

Azure Policy untuk TDE yang dikelola pelanggan

Azure Policy dapat digunakan untuk menerapkan TDE yang dikelola pelanggan selama pembuatan atau pembaruan server Azure SQL Database atau Azure SQL Managed Instance. Dengan diterapkannya kebijakan ini, setiap upaya untuk membuat atau memperbarui server logis di Azure atau instans terkelola akan 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 SQL harus menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data yang tidak aktif

Kebijakan TDE yang dikelola pelanggan dapat dikelola dengan membuka portal Microsoft Azure, dan mencari layanan Kebijakan. Di bagian Definisi, cari kunci yang dikelola pelanggan.

Ada tiga efek untuk kebijakan ini:

  • Audit - Pengaturan default, dan hanya akan mengambil laporan audit dalam log aktivitas Azure Policy
  • Tolak - Mencegah server logis atau pembuatan atau pembaruan instans terkelola tanpa konfigurasi kunci yang dikelola pelanggan
  • Dinonaktifkan - Akan menonaktifkan kebijakan, dan tidak akan membatasi pengguna untuk membuat atau memperbarui server logis atau instans terkelola tanpa mengaktifkan TDE yang dikelola pelanggan

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

Penting

Versi sebelumnya dari kebijakan bawaan untuk TDE yang dikelola pelanggan yang berisi efek AuditIfNotExist tidak digunakan lagi. Penetapan kebijakan yang ada menggunakan kebijakan yang tidak digunakan lagi tidak terpengaruh dan akan terus berfungsi seperti sebelumnya.

Langkah berikutnya

Anda mungkin juga ingin memeriksa skrip sampel PowerShell berikut ini untuk operasi umum dengan TDE yang dikelola pelanggan: