Enkripsi data transparan Azure SQL dengan kunci yang dikelola pelanggan

  • Artikel

Berlaku untuk:Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (hanya kumpulan SQL khusus)

Enkripsi data transparan (TDE) 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 dan dalam kendali penuh atas manajemen siklus hidup kunci (pembuatan kunci, unggah, 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 tersebut dapat dibuat oleh Key Vault, diimpor, atau ditransfer ke Key Vault dari perangkat HSM lokal.

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.

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.

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.
  • 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 Azure SQL Database dan Azure SQL Managed Instance, semua database, termasuk master database 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.

Catatan

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

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;

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.

Cara kerja TDE yang dikelola pelanggan

Penyiapan dan fungsi TDE yang dikelola pelanggan

Agar server logis di Azure menggunakan pelindung TDE yang disimpan di AKV untuk enkripsi DEK, administrator brankas kunci perlu memberikan hak akses berikut ke server menggunakan identitas Microsoft Entra yang unik:

  • 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

  • Fitur Penghapusan sementara dan perlindungan hapus menyeluruh harus diaktifkan pada brankas kunci, untuk melindungi dari kehilangan data karena penghapusan kunci (atau brankas kunci) secara tidak disengaja.

  • Berikan server atau akses instans terkelola ke brankas kunci (dapatkan, wrapKey, unwrapKey) menggunakan identitas Microsoft Entra-nya. Identitas server dapat berupa identitas terkelola yang ditetapkan sistem atau identitas terkelola yang ditetapkan pengguna yang ditetapkan ke server. Saat menggunakan portal Azure, identitas Microsoft Entra akan dibuat secara otomatis saat server dibuat. Saat menggunakan PowerShell atau CLI, identitas Microsoft Entra 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 Izinkan layanan Microsoft tepercaya melewati firewall. Untuk informasi selengkapnya, lihat Mengonfigurasi firewall Dan jaringan virtual Azure Key Vault.

Aktifkan perlindungan penghapusan sementara dan penghapusan menyeluruh untuk AKV

Penting

FItur penghapusan sementara dan perlindungan hapus menyeluruh harus diaktifkan di brankas kunci saat mengonfigurasi TDE yang dikelola pelanggan pada server atau instans terkelola baru atau yang sudah ada.

Penghapusan sementara dan Perlindungan hapus menyeluruh adalah fitur penting Azure Key Vault yang memungkinkan pemulihan brankas yang dihapus dan objek brankas kunci yang dihapus, mengurangi risiko pengguna menghapus kunci atau brankas kunci baik secara tidak sengaja atau dengan niat buruk.

  • 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 penghapusan sementara diaktifkan secara default untuk brankas kunci baru dan juga dapat diaktifkan menggunakan portal Azure, PowerShell, atau Azure CLI.

  • Perlindungan hapus menyeluruh dapat diaktifkan menggunakan Azure CLI atau PowerShell. Saat perlindungan penghapusan menyeluruh diaktifkan, vault atau objek dalam status terhapus tidak dapat dihapus menyeluruh hingga periode retensi telah terlampaui. Periode retensi default adalah 90 hari, tetapi dapat dikonfigurasi dari 7 hingga 90 hari melalui portal Azure.

  • Azure SQL memerlukan perlindungan penghapusan sementara dan penghapusan menyeluruh untuk diaktifkan pada brankas kunci yang berisi kunci enkripsi yang digunakan sebagai pelindung TDE untuk server atau instans terkelola. Tindakan ini membantu mencegah skenario penghapusan brankas kunci atau kunci yang tidak disengaja atau dengan niat buruk yang menyebabkan database memasuki status Tidak dapat diakses.

  • Saat mengonfigurasi pelindung TDE di server yang ada atau selama pembuatan server, Azure SQL memvalidasi bahwa brankas kunci yang digunakan memiliki perlindungan penghapusan sementara dan penghapusan menyeluruh diaktifkan. 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.

Persyaratan untuk mengonfigurasi pelindung TDE

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

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

  • Kunci harus dalam status Aktfkan.

  • 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 sekarang mendukung penggunaan kunci RSA yang disimpan dalam HSM Terkelola sebagai pelindung TDE. Azure Key Vault Managed HSM adalah layanan cloud yang sepenuhnya terkelola, dengan ketersediaan tingkat tinggi, penyewa tunggal, dan memenuhi standar layanan cloud yang memungkinkan Anda melindungi kunci kriptografi untuk aplikasi cloud Anda, menggunakan HSM tervalidasi FIPS 140-2 Tingkat 3. Pelajari lebih lanjut tentang Managed HSMs.

Catatan

Masalah dengan versi Thales CipherTrust Manager sebelum v2.8.0 adalah mencegah kunci yang baru diimpor ke Azure Key Vault digunakan dengan Azure SQL Database atau Azure SQL Managed Instance untuk skenario TDE yang dikelola pelanggan. Detail selengkapnya tentang masalah ini dapat ditemukan di sini. Untuk kasus seperti itu, harap tunggu 24 jam setelah mengimpor kunci ke brankas kunci untuk mulai menggunakannya sebagai pelindung TDE untuk server atau instans terkelola. Masalah ini telah diatasi di Thales CipherTrust Manager v2.8.0.

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, Azure SQL Database dan Azure SQL Managed Instance di satu wilayah sekarang dapat ditautkan ke brankas kunci 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 mengikuti instruksi 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.

Rotasi pelindung TDE

Memutar pelindung TDE untuk server berarti beralih ke kunci asimetris baru yang melindungi database di server. 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.

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. Ketika diaktifkan, server akan terus memeriksa brankas kunci untuk versi baru kunci yang digunakan sebagai pelindung TDE. Jika versi baru kunci terdeteksi, pelindung TDE di server atau database akan secara otomatis diputar ke versi kunci terbaru dalam waktu 24 jam.

Saat digunakan dengan rotasi kunci otomatis di Azure Key Vault, fitur ini memungkinkan rotasi tanpa sentuhan menyeluruh untuk pelindung TDE di Azure SQL Database dan Azure SQL Managed Instance.

Catatan

Mengatur TDE dengan CMK menggunakan rotasi kunci manual atau otomatis akan selalu menggunakan versi terbaru kunci yang didukung. Penyetelan tidak memperbolehkan 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 dalam kasus pencadangan 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 dalam brankas kunci yang sama 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, dan sistem akan 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 dalam brankas kunci yang sama 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 akan mencoba menambahkan kunci ke server sekunder.

  • Skenario replikasi geografis 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 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 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 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:

Catatan

  • Jika akses kunci dipulihkan dalam waktu 30 menit, database akan disembuhkan secara otomatis dalam satu jam berikutnya.
  • Jika akses kunci dipulihkan setelah lebih dari 30 menit, pemulihan otomatis database tidak dimungkinkan. Mengembalikan database memerlukan langkah tambahan pada portal Azure dan dapat memakan waktu yang signifikan tergantung pada ukuran database.
  • Setelah database kembali online, pengaturan tingkat server yang dikonfigurasi sebelumnya yang mungkin mencakup 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 akan hilang. Oleh karena itu, disarankan agar pelanggan menerapkan sistem pemberitahuan yang mengidentifikasi hilangnya akses kunci enkripsi dalam waktu 30 menit. Setelah jendela 30 menit kedaluwarsa, sebaiknya validasi semua pengaturan tingkat server dan database pada database yang dipulihkan.

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

Database TDE BYOK Tidak Dapat Diakses

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 terkelola di ID Microsoft Entra

Pelajari selengkapnya tentang penyebab umum database menjadi tidak dapat diakses.

Konektivitas yang diblokir antara SQL Managed Instance dan Key Vault

Pada SQL Managed Instance, kesalahan jaringan saat mencoba mengakses pelindung TDE di Azure Key Vault mungkin tidak menyebabkan database mengubah statusnya menjadi Tidak dapat diakses tetapi akan membuat instans tidak tersedia setelahnya. Ini sebagian besar terjadi ketika sumber daya brankas kunci ada tetapi titik akhirnya tidak dapat dicapai dari instans terkelola. Semua skenario di mana titik akhir brankas kunci dapat dicapai tetapi koneksi ditolak, izin yang hilang, dll., akan menyebabkan database mengubah statusnya menjadi Tidak dapat diakses.

Penyebab paling umum kurangnya konektivitas jaringan ke Key Vault adalah:

  • Key Vault diekspos melalui titik akhir privat dan alamat IP privat layanan AKV tidak diizinkan dalam aturan keluar Kelompok Keamanan Jaringan (NSG) yang terkait dengan subnet instans terkelola.
  • Resolusi DNS buruk, seperti ketika FQDN brankas kunci tidak diselesaikan atau diselesaikan ke alamat IP yang tidak valid.

Uji konektivitas dari SQL Managed Instance ke Key Vault 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 merupakan 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.
    • Konfirmasikan bahwa grup keamanan jaringan pada instans terkelola memiliki aturan keluar yang mencakup alamat IP yang diselesaikan pada port 443, terutama ketika alamat yang diselesaikan milik titik akhir privat brankas kunci.
    • Periksa konfigurasi jaringan lain seperti tabel rute, keberadaan appliance virtual dan konfigurasinya, dll.

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 memungkinkan Anda 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 "Jadikan kunci sebagai pelindung TDE default" di panel portal 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 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 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 cadangan untuk kumpulan SQL khusus di Azure Synapse Analytics, lihat Memulihkan kumpulan SQL khusus. Untuk pencadangan/pemulihan asli SQL Server dengan SQL Managed Instance, lihat Mulai Cepat: Memulihkan database ke 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.

Server tunggal 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.

Grup failover dan 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 SQL Managed Instance di satu wilayah sekarang dapat ditautkan ke brankas kunci di wilayah lain. Server dan brankas kunci tidak harus berada di wilayah yang sama. Dengan ini, untuk kesederhanaan, server primer dan sekunder dapat dihubungkan ke key vault yang sama (di wilayah mana pun). Ini membantu menghindari skenario di mana materi kunci mungkin tidak sinkron jika brankas kunci 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 harus menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data 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:

Selain itu, aktifkan Microsoft Defender untuk SQL guna mengamankan database Anda dan data database, dengan fungsionalitas untuk menemukan dan mengurangi potensi kerentanan database, dan mendeteksi aktivitas anomali yang dapat mengindikasikan ancaman terhadap database Anda.