Enkripsi data transparan (TDE) dengan kunci yang dikelola pelanggan di tingkat database

  • Artikel

Berlaku untuk:Azure SQL Database

Artikel ini menjelaskan enkripsi data transparan (TDE) dengan kunci yang dikelola pelanggan di tingkat database untuk Azure SQL Database.

Catatan

CMK TDE Tingkat Database tersedia untuk Azure SQL Database (semua edisi SQL Database). Ini tidak tersedia untuk Azure SQL Managed Instance, SQL Server lokal, Azure VM, dan Azure Synapse Analytics (kumpulan SQL khusus (sebelumnya SQL DW)).

Catatan

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

Gambaran Umum

Azure SQL menawarkan kemampuan enkripsi saat tidak aktif kepada pelanggan melalui enkripsi data transparan (TDE). Memperluas TDE dengan kunci yang dikelola pelanggan (CMK) memungkinkan perlindungan data tidak aktif di mana pelindung TDE (kunci enkripsi) disimpan di Azure Key Vault yang mengenkripsi kunci enkripsi database. Saat ini, TDE dengan CMK diatur di tingkat server, dan diwarisi oleh semua database terenkripsi yang terkait dengan server tersebut. Fitur baru ini memungkinkan pengaturan pelindung TDE sebagai kunci yang dikelola pelanggan satu per satu untuk setiap database dalam server. Sumber daya apa pun Microsoft.Sql/servers/databases dengan properti yang valid dan tidak ada encryptionProtector dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database.

Dalam skenario ini, kunci asimetris yang disimpan dalam Azure Key Vault (AKV) milik pelanggan dan yang dikelola pelanggan dapat digunakan secara individual untuk setiap database dalam server untuk mengenkripsi kunci enkripsi database (DEK), yang disebut pelindung TDE. Ada opsi untuk menambahkan kunci, menghapus kunci, dan mengubah identitas terkelola (UMI) yang ditetapkan pengguna untuk setiap database. Untuk informasi selengkapnya tentang identitas, lihat Jenis identitas terkelola di Azure.

Fungsionalitas berikut tersedia:

  • Identitas terkelola yang ditetapkan pengguna: Anda dapat menetapkan satu identitas terkelola yang ditetapkan pengguna ke database. Identitas ini dapat digunakan untuk mengakses Azure Key Vault dan mengelola kunci enkripsi.
  • Manajemen kunci enkripsi: Anda dapat mengaktifkan satu atau beberapa kunci enkripsi untuk ditambahkan di tingkat database, dan mengatur salah satu kunci yang ditambahkan sebagai pelindung TDE. Kunci enkripsi yang ditambahkan menggunakan identitas terkelola yang ditetapkan pengguna yang sudah ditetapkan ke database untuk mengakses Azure Key Vault.
  • Identitas klien gabungan: Anda juga dapat mengaktifkan kunci yang dikelola pelanggan (CMK) dari Azure Key Vault di penyewa Microsoft Entra yang berbeda untuk ditetapkan sebagai pelindung TDE di tingkat database, dengan menggunakan identitas klien federasi yang ditetapkan pada Azure SQL Database. Ini memungkinkan Anda mengelola TDE dengan kunci yang disimpan di Azure Key Vault penyewa yang berbeda.

Catatan

Identitas terkelola yang ditetapkan sistem tidak didukung di tingkat database.

Manfaat TDE yang dikelola pelanggan di tingkat database

Sebagai lebih banyak penyedia layanan, juga dikenal sebagai vendor perangkat lunak independen (ISV), menggunakan Azure SQL Database untuk membangun layanan mereka, banyak yang beralih ke kumpulan elastis sebagai cara untuk mendistribusikan sumber daya komputasi secara efisien di beberapa database. Dengan memiliki masing-masing database pelanggan mereka di kumpulan elastis bersama, ISV dapat memanfaatkan kemampuan kumpulan untuk mengoptimalkan pemanfaatan sumber daya sambil tetap memastikan bahwa setiap database memiliki sumber daya yang memadai.

Namun, ada satu batasan signifikan untuk pendekatan ini. Ketika beberapa database dihosting di server logis Azure SQL yang sama, mereka berbagi pelindung TDE tingkat server. ISV tidak dapat menawarkan kemampuan kunci yang dikelola pelanggan (CMK) yang sebenarnya kepada pelanggan mereka. Tanpa kemampuan untuk mengelola kunci enkripsi mereka sendiri, pelanggan mungkin ragu untuk mempercayakan data sensitif ke layanan ISV, terutama jika peraturan kepatuhan mengharuskan mereka untuk mempertahankan kontrol penuh atas kunci enkripsi mereka.

Dengan CMK TDE tingkat database, ISV dapat menawarkan kemampuan CMK kepada pelanggan mereka dan mencapai isolasi keamanan, karena setiap pelindung TDE database berpotensi dimiliki oleh pelanggan ISV masing-masing dalam brankas kunci yang mereka miliki. Isolasi keamanan yang dicapai untuk pelanggan ISV adalah dalam hal kunci dan identitas yang digunakan untuk mengakses kunci.

Diagram di bawah ini meringkas fungsionalitas baru yang ditunjukkan di atas. Ini menyajikan dua penyewa Microsoft Entra terpisah. Penyewa Best Services yang berisi server logis Azure SQL dengan dua database, DB 1 dan DB 2, dan Azure Key Vault 1 dengan Key 1 mengakses database DB 1 menggunakan UMI 1. Keduanya UMI 1 dan Key 1 mewakili pengaturan tingkat server. Secara default, semua database yang dibuat awalnya di server ini mewarisi pengaturan ini untuk TDE dengan CMK. Penyewa Contoso mewakili penyewa klien yang berisi Azure Key Vault 2 dengan Key 2 penilaian database DB 2 di seluruh penyewa sebagai bagian dari dukungan lintas penyewa CMK tingkat database menggunakan Key 2 dan UMI 2 menyiapkan untuk database ini.

Setup and functioning of the customer-managed TDE at the database level

Untuk informasi selengkapnya tentang konfigurasi identitas lintas penyewa, lihat dokumen tingkat server Kunci terkelola pelanggan lintas penyewa dengan enkripsi data transparan.

Skenario manajemen kunci yang didukung

Untuk bagian berikut, mari kita asumsikan ada server yang terdiri dari tiga database (misalnya Database1, , Database2dan Database3).

Skenario yang ada

Key1 dikonfigurasi sebagai kunci yang dikelola pelanggan di tingkat server logis. Semua database di bawah server ini mewarisi kunci yang sama.

  • Server – Key1 ditetapkan sebagai CMK
  • Database1 – Key1 digunakan sebagai CMK
  • Database2 – Key1 digunakan sebagai CMK
  • Database3 – Key1 digunakan sebagai CMK

Skenario baru yang didukung: Server logis yang dikonfigurasi dengan kunci yang dikelola pelanggan

Key1 dikonfigurasi sebagai kunci yang dikelola pelanggan di tingkat server logis. Kunci yang dikelola pelanggan yang berbeda (Key2) dapat dikonfigurasi di tingkat database.

  • Server – Key1 ditetapkan sebagai CMK
  • Database1 – Key2 digunakan sebagai CMK
  • Database2 – Key1 digunakan sebagai CMK
  • Database3 – Key1 digunakan sebagai CMK

Catatan

Jika server logis dikonfigurasi dengan kunci yang dikelola pelanggan untuk TDE, database individual di server logis ini tidak dapat dipilih untuk menggunakan kunci yang dikelola layanan untuk enkripsi data transparan.

Skenario baru yang didukung: Server logis dikonfigurasi dengan kunci yang dikelola layanan

Server logis dikonfigurasi dengan kunci yang dikelola layanan (SMK) untuk TDE. Kunci yang dikelola pelanggan yang berbeda (Key2) dapat dikonfigurasi di tingkat database.

  • Server - Kunci yang dikelola layanan ditetapkan sebagai pelindung TDE
  • Database1 – Key2 ditetapkan sebagai CMK
  • Database2 – Kunci yang dikelola layanan ditetapkan sebagai pelindung TDE
  • Database3 – Kunci yang dikelola layanan ditetapkan sebagai pelindung TDE

Mengembalikan ke enkripsi tingkat server

Database1 dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database untuk TDE saat server logis dikonfigurasi dengan kunci yang dikelola layanan. Database1 dapat dikembalikan untuk menggunakan kunci yang dikelola layanan tingkat server logis.

Catatan

Jika server logis dikonfigurasi dengan CMK untuk TDE, database yang dikonfigurasi dengan CMK tingkat database tidak dapat dikembalikan ke enkripsi tingkat server.

Meskipun, operasi pengembalian hanya didukung jika server logis dikonfigurasi dengan kunci yang dikelola layanan saat menggunakan TDE, database yang dikonfigurasi dengan CMK tingkat database dapat dipulihkan ke server yang dikonfigurasi dengan CMK, asalkan server memiliki akses ke semua kunci yang digunakan oleh database sumber dengan identitas yang valid.

Brankas kunci dan persyaratan identitas terkelola

Persyaratan yang sama untuk mengonfigurasi kunci Azure Key Vault (AKV) dan identitas terkelola, termasuk pengaturan kunci dan izin yang diberikan ke identitas yang berlaku untuk fitur kunci yang dikelola pelanggan (CMK) tingkat server juga berlaku untuk CMK tingkat database. Untuk informasi selengkapnya, lihat Enkripsi Data Transparan (TDE) dengan CMK dan Identitas Terkelola dengan CMK.

Manajemen kunci

Memutar pelindung TDE untuk database berarti beralih ke kunci asimetris baru yang melindungi database. 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. Setelah identitas terkelola yang ditetapkan pengguna yang valid ditetapkan ke database, memutar kunci di tingkat database adalah operasi CRUD database yang melibatkan pembaruan properti pelindung enkripsi database. Set-AzSqlDatabase dan properti -EncryptionProtector dapat digunakan untuk memutar kunci. Untuk membuat database baru yang dikonfigurasi dengan CMK tingkat database, New-AzSqlDatabase dapat digunakan dengan -EncryptionProtectorparameter , , -AssignIdentitydan -UserAssignedIdentityId .

Kunci baru dapat ditambahkan dan kunci yang ada dapat dihapus dari database menggunakan permintaan serupa dan memodifikasi properti kunci untuk sumber daya database. Set-AzSqlDatabase dengan parameter -KeyList dan -KeysToRemove dapat digunakan untuk operasi ini. Untuk mengambil pengaturan pelindung, identitas, dan kunci enkripsi, Get-AzSqlDatabase dapat digunakan. Sumber daya Azure Resource Manager Microsoft.Sql/servers/database secara default hanya memperlihatkan pelindung TDE dan identitas terkelola yang dikonfigurasi pada database. Untuk memperluas daftar lengkap kunci, parameter lain seperti -ExpandKeyList diperlukan. Selain itu, -KeysFilter "current" dan nilai titik waktu (misalnya, 2023-01-01) dapat digunakan untuk mengambil kunci saat ini yang digunakan dan kunci yang digunakan di masa lalu pada titik waktu tertentu.

Rotasi kunci otomatis

Rotasi kunci otomatis tersedia di tingkat database dan dapat digunakan dengan kunci Azure Key Vault. Rotasi dipicu ketika versi baru kunci terdeteksi, dan akan secara otomatis diputar dalam waktu 24 jam. Untuk informasi tentang cara mengonfigurasi rotasi kunci otomatis menggunakan portal Azure, PowerShell, atau Azure CLI, lihat Rotasi kunci otomatis di tingkat database.

Izin untuk manajemen kunci

Bergantung pada model izin brankas kunci (kebijakan akses atau Azure RBAC), akses brankas kunci dapat diberikan baik dengan membuat kebijakan akses pada brankas kunci, atau dengan membuat penetapan peran Azure RBAC baru.

Model izin kebijakan akses

Agar database menggunakan pelindung TDE yang disimpan di AKV untuk enkripsi DEK, administrator brankas kunci perlu memberikan hak akses berikut ke identitas terkelola yang ditetapkan pengguna database menggunakan identitas Microsoft Entra uniknya:

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

Model izin Azure RBAC

Agar database dapat menggunakan pelindung TDE yang disimpan di AKV untuk enkripsi DEK, penetapan peran Azure RBAC baru dengan peran Pengguna Enkripsi Layanan Kripto Key Vault harus ditambahkan untuk identitas terkelola yang ditetapkan pengguna database menggunakan identitas Microsoft Entra yang unik.

Kunci lintas penyewa yang dikelola pelanggan

Kunci lintas penyewa yang dikelola pelanggan dengan enkripsi data transparan menjelaskan cara menyiapkan ID klien federasi untuk CMK tingkat server. Penyiapan serupa perlu dilakukan untuk CMK tingkat database dan ID klien federasi harus ditambahkan sebagai bagian dari permintaan API Set-AzSqlDatabase atau New-AzSqlDatabase .

Catatan

Jika aplikasi multi-penyewa belum ditambahkan ke kebijakan akses brankas kunci dengan izin yang diperlukan (Get, Wrap Key, Unwrap Key), menggunakan aplikasi untuk federasi identitas di portal Azure akan menampilkan kesalahan. Pastikan bahwa izin dikonfigurasi dengan benar sebelum mengonfigurasi identitas klien federasi.

Database yang dikonfigurasi dengan CMK tingkat database dapat dikembalikan ke enkripsi tingkat server jika server logis dikonfigurasi dengan kunci yang dikelola layanan menggunakan Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

Dalam kasus pelindung TDE yang tidak dapat diakses seperti yang dijelaskan dalam Enkripsi data transparan (TDE) dengan CMK, setelah akses kunci diperbaiki, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation dapat digunakan untuk membuat database dapat diakses.

Catatan

Manajemen identitas dan kunci untuk TDE dengan kunci yang dikelola pelanggan tingkat database menjelaskan identitas dan operasi manajemen kunci untuk CMK tingkat database secara rinci, bersama dengan contoh Powershell, Azure CLI, dan REST API.

Pertimbangan tambahan

  • Jika TDE dengan CMK sudah diaktifkan di tingkat server, atur CMK untuk database tertentu mengambil alih pengaturan CMK tingkat server (DEK database akan dienkripsi ulang dengan pelindung TDE tingkat database).
  • Setiap perubahan atau rotasi kunci tingkat server logis tidak memengaruhi pengaturan CMK tingkat database dan database terus menggunakan pengaturan CMK-nya sendiri.
  • CMK tingkat database tidak didukung melalui Transact-SQL (T-SQL).
  • Identitas terkelola yang ditetapkan pengguna (UMI) server logis dapat digunakan di tingkat database. Namun, disarankan untuk menggunakan UMI yang ditunjuk untuk CMK tingkat database.
  • Pengaturan CMK lintas penyewa tingkat server tidak memengaruhi database individual yang dikonfigurasi dengan CMK tingkat database, dan mereka terus menggunakan konfigurasi penyewa tunggal atau lintas penyewa mereka sendiri.
  • Hanya satu identitas terkelola yang ditetapkan pengguna yang dapat diatur di tingkat database.

Catatan

Identitas terkelola pada database harus ditetapkan ulang jika database diganti namanya.

Migrasi database yang ada ke CMK tingkat database

Database baru dapat dikonfigurasi dengan CMK tingkat database selama pembuatan dan database yang ada di server yang dikonfigurasi dengan kunci yang dikelola layanan dapat dimigrasikan ke CMK tingkat database menggunakan operasi yang dijelaskan dalam Identitas dan manajemen kunci untuk TDE dengan kunci yang dikelola pelanggan tingkat database. Untuk memigrasikan database yang dikonfigurasi dengan CMK tingkat server atau replikasi geografis, langkah-langkah lain diperlukan seperti yang dijelaskan di bagian berikut.

Database dikonfigurasi dengan CMK tingkat server tanpa replikasi geografis

  1. Gunakan sys.dm_db_log_info (Transact-SQL) - SQL Server untuk database Anda dan cari file log virtual (VLF) yang aktif.
  2. Untuk semua VLF aktif, rekam vlf_encryptor_thumbprint dari hasilnya sys.dm_db_log_info .
  3. Gunakan tampilan sys.dm_database_encryption_keys (Transact-SQL) - SQL Server untuk database Anda untuk encryptor_thumbprintmemeriksa . encryptor_thumbprintRekam .
  4. Gunakan cmdlet Get-AzSqlServerKeyVaultKey untuk mendapatkan semua kunci tingkat server yang dikonfigurasi di server logis. Dari hasilnya, pilih yang memiliki thumbprint yang sama yang cocok dengan daftar Anda dari hasil di atas.
  5. Lakukan panggilan API database pembaruan ke database yang ingin Anda migrasikan, bersama dengan pelindung identitas dan enkripsi. Teruskan kunci di atas sebagai kunci tingkat database menggunakan parameter Set-AzSqlDatabase menggunakan -UserAssignedIdentityIdparameter , , -AssignIdentity, -EncryptionProtector-KeyList(dan jika perlu, -FederatedClientId).

Penting

Identitas yang digunakan dalam permintaan database pembaruan harus memiliki akses ke semua kunci yang diteruskan sebagai input.

Database dikonfigurasi dengan CMK tingkat server dengan replikasi geografis

  1. Ikuti langkah-langkah (1) hingga (4) yang disebutkan di bagian sebelumnya untuk mengambil daftar kunci yang akan diperlukan untuk migrasi.
  2. Lakukan panggilan API database pembaruan ke database utama dan sekunder yang ingin Anda migrasikan, bersama dengan identitas dan kunci di atas sebagai kunci tingkat database menggunakan Set-AzSqlDatabase dan -KeyList parameter . Jangan atur pelindung enkripsi.
  3. Kunci tingkat database yang ingin Anda gunakan sebagai pelindung utama pada database harus terlebih dahulu ditambahkan ke database sekunder. Gunakan Set-AzSqlDatabase dengan -KeyList untuk menambahkan kunci ini pada database sekunder.
  4. Setelah kunci pelindung enkripsi ditambahkan ke database sekunder, gunakan Set-AzSqlDatabase untuk mengaturnya sebagai pelindung enkripsi pada database utama menggunakan -EncryptionProtector parameter .
  5. Atur kunci sebagai pelindung enkripsi pada database sekunder seperti yang dijelaskan dalam (4) untuk menyelesaikan migrasi.

Penting

Untuk memigrasikan database yang dikonfigurasi dengan kunci yang dikelola layanan tingkat server dan replikasi geografis, ikuti langkah-langkah (3), (4) dan (5) dari bagian ini.

Replikasi geografis dan ketersediaan tinggi

Dalam skenario replikasi geografis aktif dan grup failover, database utama dan sekunder yang terlibat dapat ditautkan baik ke brankas kunci yang sama (di wilayah mana pun), atau untuk memisahkan brankas kunci. Jika brankas kunci terpisah ditautkan ke server primer dan sekunder, pelanggan bertanggung jawab untuk menjaga konsistensi materi kunci di seluruh brankas kunci, sehingga geosekunder sinkron dan dapat mengambil alih menggunakan kunci yang sama dari brankas kunci 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 membuat replikasi geografis aktif untuk database yang telah dikonfigurasi dengan CMK tingkat database, replika sekunder harus dibuat dengan identitas terkelola yang ditetapkan pengguna yang valid dan daftar kunci saat ini yang digunakan oleh database utama. Daftar kunci saat ini dapat diambil dari database utama menggunakan filter dan parameter kueri yang diperlukan, atau menggunakan PowerShell dan Azure CLI. Langkah-langkah yang diperlukan untuk menyiapkan replika geografis database tersebut adalah:

  1. Siapkan daftar kunci yang digunakan oleh database utama menggunakan perintah Get-AzSqlDatabase , dan -ExpandKeyList parameter dan -KeysFilter "current" . Kecualikan -KeysFilter jika Anda ingin mengambil semua kunci.
  2. Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa).
  3. Buat database baru sebagai sekunder menggunakan New-AzSqlDatabaseSecondary dan berikan daftar kunci yang telah diisi sebelumnya yang diperoleh dari database sumber dan identitas di atas (dan klien federasi DI jika mengonfigurasi akses lintas penyewa) dalam panggilan API menggunakan -KeyListparameter , , -AssignIdentity, -EncryptionProtector-UserAssignedIdentityId(dan jika perlu, -FederatedClientId) .
  4. Gunakan New-AzSqlDatabaseCopy untuk membuat salinan database dengan parameter yang sama di langkah sebelumnya.

Penting

Database yang dikonfigurasi dengan CMK tingkat database harus memiliki replika (atau salinan) yang dikonfigurasi dengan CMK tingkat database. Replika tidak dapat menggunakan pengaturan enkripsi tingkat server.

Untuk menggunakan database yang dikonfigurasi dengan CMK tingkat database dalam grup failover, langkah-langkah di atas untuk membuat replika sekunder dengan nama yang sama dengan replika utama harus digunakan di server sekunder. Setelah replika sekunder ini dikonfigurasi, database dapat ditambahkan ke grup failover.

Database yang dikonfigurasi dengan CMK tingkat database tidak mendukung pembuatan sekunder otomatis saat ditambahkan ke grup failover.

Untuk informasi selengkapnya, Mengonfigurasi replikasi geografis dan pemulihan cadangan untuk enkripsi data transparan dengan kunci yang dikelola pelanggan tingkat database menjelaskan cara menyiapkan replikasi geografis dan grup failover menggunakan REST API, PowerShell, dan Azure CLI.

Catatan

Semua praktik terbaik mengenai replikasi geografis dan ketersediaan tinggi disorot dalam enkripsi data transparan (TDE) dengan CMK untuk CMK tingkat server berlaku untuk CMK tingkat database.

Pencadangan dan pemulihan untuk database menggunakan TDE dengan kunci yang dikelola pelanggan di tingkat database

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 yang dikonfigurasi di tingkat database, pastikan bahwa materi kunci disediakan untuk database target. Kami menyarankan agar Anda menyimpan semua versi lama pelindung TDE dalam brankas kunci, sehingga cadangan database dapat dipulihkan.

Penting

Hanya satu pelindung TDE yang dapat diatur untuk database. Namun, beberapa kunci tambahan dapat diteruskan ke database selama pemulihan 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.

Pemulihan Titik Waktu Tertentu

Langkah-langkah berikut diperlukan untuk pemulihan titik waktu database yang dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database:

  1. Siapkan daftar kunci yang digunakan oleh database utama menggunakan perintah Get-AzSqlDatabase , dan -ExpandKeyList parameter dan -KeysFilter "2023-01-01" . 2023-01-01 adalah contoh titik waktu yang ingin Anda pulihkan databasenya. Kecualikan -KeysFilter jika Anda ingin mengambil semua kunci.
  2. Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa).
  3. Gunakan Restore-AzSqlDatabase dengan -FromPointInTimeBackup parameter dan berikan daftar kunci yang telah diisi sebelumnya yang diperoleh dari langkah-langkah di atas, dan identitas di atas (dan ID klien federasi jika mengonfigurasi akses lintas penyewa) dalam panggilan API menggunakan -KeyListparameter , , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (dan jika perlu, -FederatedClientId).

Catatan

Memulihkan database tanpa -EncryptionProtector properti dengan semua kunci yang valid akan mengatur ulang untuk menggunakan enkripsi tingkat server. Ini dapat berguna untuk mengembalikan konfigurasi kunci yang dikelola pelanggan tingkat database ke konfigurasi kunci yang dikelola pelanggan tingkat server.

Pemulihan database yang dihilangkan

Langkah-langkah berikut diperlukan untuk pemulihan database database yang dihilangkan dari database yang dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database:

  1. Siapkan daftar kunci yang digunakan oleh database utama menggunakan Get-AzSqlDeletedDatabaseBackup dan -ExpandKeyList parameter . Disarankan untuk meneruskan semua kunci yang digunakan database sumber, tetapi sebagai alternatif, pemulihan juga dapat dicoba dengan kunci yang disediakan oleh waktu penghapusan sebagai -KeysFilter.
  2. Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa).
  3. Gunakan Restore-AzSqlDatabase dengan -FromDeletedDatabaseBackup parameter dan berikan daftar kunci yang telah diisi sebelumnya yang diperoleh dari langkah-langkah di atas dan identitas di atas (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa) dalam panggilan API menggunakan -KeyListparameter , , -AssignIdentity, -EncryptionProtector-UserAssignedIdentityId(dan jika perlu, -FederatedClientId).

Pemulihan geografis

Langkah-langkah berikut diperlukan untuk pemulihan geografis database yang dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database:

  • Siapkan daftar kunci yang digunakan oleh database utama menggunakan Get-AzSqlDatabaseGeoBackup dan -ExpandKeyList untuk mengambil semua kunci.
  • Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa).
  • Gunakan Restore-AzSqlDatabase dengan -FromGeoBackup parameter dan berikan daftar kunci yang telah diisi sebelumnya yang diperoleh dari langkah-langkah di atas dan identitas di atas (dan ID klien gabungan jika mengonfigurasi akses lintas penyewa) dalam panggilan API menggunakan -KeyListparameter , , -AssignIdentity, -EncryptionProtector-UserAssignedIdentityId(dan jika perlu, -FederatedClientId).

Penting

Disarankan agar semua kunci yang digunakan oleh database dipertahankan untuk memulihkan database. Disarankan juga untuk meneruskan semua kunci ini ke target pemulihan.

Catatan

cadangan retensi cadangan jangka panjang (LTR) tidak menyediakan daftar kunci yang digunakan oleh cadangan. Untuk memulihkan cadangan LTR, semua kunci yang digunakan oleh database sumber harus diteruskan ke target pemulihan LTR.

Untuk mempelajari selengkapnya tentang pemulihan cadangan untuk SQL Database dengan CMK tingkat database dengan contoh menggunakan Powershell, Azure CLI, dan REST API, lihat Mengonfigurasi replikasi geografis dan pemulihan cadangan untuk enkripsi data transparan dengan kunci yang dikelola pelanggan tingkat database.

Batasan

Fitur kunci yang dikelola pelanggan tingkat database tidak mendukung rotasi kunci ketika file log virtual database dienkripsi dengan kunci lama yang berbeda dari pelindung utama database saat ini. Kesalahan yang dilemparkan dalam kasus ini adalah:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Rotasi kunci untuk Pelindung TDE di tingkat database diblokir ketika transaksi aktif menahan log yang dienkripsi dengan kunci lama.

Untuk lebih memahami skenario ini, mari kita pertimbangkan garis waktu berikut:

An example timeline of key rotations on a database configured with database level customer-managed keys.

  • Waktu t0 = Database dibuat tanpa enkripsi
  • Waktu t1 = Database ini dilindungi oleh Thumbprint A, yang merupakan kunci yang dikelola pelanggan tingkat database.
  • Waktu t2 = Pelindung database diputar ke kunci yang dikelola pelanggan tingkat database baru, Thumbprint B.
  • Waktu t3 = Perubahan pelindung menjadi Thumbprint C diminta.
  • Jika VLF aktif menggunakan Thumbprint A, rotasi tidak diizinkan.
  • Jika VLF aktif tidak menggunakan Thumbprint A, rotasi diizinkan.

Anda dapat menggunakan tampilan sys.dm_db_log_info (Transact-SQL) - SQL Server untuk database Anda dan mencari file log virtual yang aktif. Anda akan melihat VLF aktif yang dienkripsi dengan kunci pertama (misalnya, Thumbprint A). Setelah log yang cukup dihasilkan oleh penyisipan data, VLF lama ini dibersihkan dan Anda harus dapat melakukan rotasi kunci lain.

Jika Anda yakin bahwa ada sesuatu yang menahan log Anda lebih lama dari yang diharapkan, lihat dokumentasi berikut untuk pemecahan masalah lebih lanjut:

Langkah berikutnya

Periksa dokumentasi berikut tentang berbagai operasi CMK tingkat database: