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

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

TDE CMK pada 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)).

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 atau Azure Managed HSM yang mengenkripsi kunci enkripsi database. TDE dengan CMK dapat diatur di tingkat server, dan diwariskan oleh semua database terenkripsi yang terkait dengan server tersebut. Anda juga dapat mengatur pelindung TDE sebagai kunci yang dikelola pelanggan satu per satu untuk setiap database dalam server. Setiap sumber daya Microsoft.Sql/servers/databases dengan properti encryptionProtector yang valid dan tidak kosong dikonfigurasi dengan kunci yang dikelola pelanggan pada tingkat database. Kunci yang dikelola pelanggan mendukung kunci asimetris (RSA) dan simetris (AES), tergantung pada penyimpanan kunci yang dipilih.

Dalam skenario ini, kunci asimetris atau simetris yang disimpan dalam Azure Key Vault milik pelanggan dan dikelola pelanggan atau Azure HSM Terkelola 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 atau Azure Managed HSM 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 sedang ditambahkan menggunakan identitas terkelola yang ditetapkan oleh pengguna, yang sudah terhubung ke database, untuk mengakses Azure Key Vault atau Azure Managed HSM.
  • Identitas klien gabungan: Anda juga dapat mengaktifkan kunci yang dikelola pelanggan (CMK) dari Azure Key Vault atau Azure Managed HSM di penyewa Microsoft Entra yang berbeda untuk ditetapkan sebagai pelindung TDE di tingkat database, dengan menggunakan identitas klien federasi yang ditetapkan di Azure SQL Database. Ini memungkinkan Anda mengelola TDE dengan kunci yang disimpan di Azure Key Vault atau Azure Managed HSM penyewa lain.

Catatan

Identitas terkelola yang ditetapkan sistem tidak didukung di tingkat database.

Manfaat TDE yang dikelola pelanggan di tingkat database

Seiring semakin banyak penyedia layanan, yang juga dikenal sebagai vendor perangkat lunak independen (ISV), menggunakan Azure SQL Database untuk mengembangkan layanan mereka, banyak di antaranya beralih ke pool elastis sebagai cara untuk mendistribusikan sumber daya komputasi secara efisien ke berbagai 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 mengelola kunci enkripsi mereka sendiri, pelanggan mungkin ragu untuk mempercayakan data sensitif kepada layanan ISV, terutama jika regulasi kepatuhan mengharuskan mereka mempertahankan kontrol penuh atas kunci enkripsi mereka.

Dengan TDE CMK tingkat database, ISV dapat menawarkan kemampuan CMK kepada pelanggan mereka dan mencapai isolasi keamanan, karena pelindung TDE dari setiap database dapat dimiliki oleh pelanggan ISV masing-masing dalam brankas kunci atau HSM terkelola milik mereka. 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 menampilkan dua tenant Microsoft Entra yang terpisah. Tenant Best Services yang berisi server logis Azure SQL dengan dua database, DB 1 dan DB 2, serta Azure Key Vault 1 dengan Key 1 yang 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 merepresentasikan penyewa klien yang berisi Azure Key Vault 2 dengan Key 2 yang menilai database DB 2 di seluruh penyewa sebagai bagian dari dukungan lintas penyewa CMK tingkat database menggunakan penyiapan Key 2 dan UMI 2 untuk database ini.

Penyiapan dan fungsi TDE yang dikelola pelanggan di tingkat database

Untuk informasi selengkapnya tentang konfigurasi identitas lintas-penyewa, lihat dokumen tingkat server Kunci yang dikelola 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 yang dikonfigurasi dengan kunci yang dikelola oleh layanan

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

  • Server - Kunci yang dikelola oleh 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 pada tingkat database untuk TDE, sedangkan server logis dikonfigurasi dengan kunci yang dikelola layanan. Database1 dapat dikembalikan agar menggunakan kunci yang dikelola layanan pada tingkat server logis.

Catatan

Jika server logis dikonfigurasi dengan CMK untuk TDE, database yang dikonfigurasi dengan CMK pada tingkat database tidak dapat diubah kembali menjadi 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.

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

Jenis dan ukuran kunci yang didukung

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

  • Kunci asimetris (RSA atau RSA HSM)

    • Didukung di Azure Key Vault dan Azure Key Vault Managed HSM
    • Ukuran kunci yang didukung: 2048-bit dan 3072-bit
    • Didukung untuk Azure SQL Database, Azure SQL Managed Instance, dan Azure Synapse Analytics

  • Kunci simetris (AES)

    • Didukung di Azure Key Vault Premium (pratinjau) dan Azure Key Vault Managed HSM
    • Ukuran kunci yang didukung: 128-bit, 192-bit, dan 256-bit
    • Hanya didukung untuk Azure SQL Database, saat ini dalam pratinjau publik. Anda mungkin melihat kemampuan ini muncul dari waktu ke waktu tergantung pada wilayah dan status penyebaran layanan Anda.

Catatan

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

Batasan untuk kunci simetris (AES)

Saat menggunakan kunci simetris (AES) sebagai pelindung TDE, hanya kunci yang disimpan di Azure Key Vault Premium (pratinjau) atau Azure Key Vault Managed HSM yang didukung untuk operasi siklus hidup kunci yang sedang berjalan. Pelanggan dapat mengimpor kunci dari modul keamanan perangkat keras (HSM) lokal sekali ke Azure Key Vault Premium (pratinjau) atau Azure Key Vault Managed HSM. Setelah impor awal, semua operasi siklus hidup kunci berikutnya, termasuk pemulihan ke titik waktu tertentu, pemulihan bencana geografis, dan revalidasi kunci, harus mengandalkan infrastruktur Azure Key Vault Premium (pratinjau) atau Azure Key Vault Managed HSM. Pelanggan bertanggung jawab untuk mempertahankan cadangan lokal kunci yang diimpor untuk mendukung skenario pemulihan dan validasi ulang. Batasan ini hanya berlaku untuk kunci simetris (AES) dan tidak berlaku untuk kunci asimetris (RSA).

Persyaratan status dan validitas utama

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

Persyaratan impor utama

Jika Anda mengimpor kunci yang ada ke Azure Key Vault, kunci harus disediakan dalam salah satu format yang didukung berikut:

  • .pfx
  • .byok
  • .backup

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

Azure Key Vault dan Azure Managed HSM - persyaratan identitas terkelola

Persyaratan yang sama untuk mengonfigurasi kunci Azure Key Vault atau Azure Managed HSM 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.

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

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

Catatan

Transparent Data Encryption dengan kunci simetris (AES) saat ini hanya didukung untuk Azure SQL Database dan masih dalam pratinjau publik. Anda mungkin melihat kemampuan ini muncul dari waktu ke waktu tergantung pada wilayah dan status penyebaran layanan Anda.

Setelah identitas terkelola yang ditetapkan pengguna yang valid ditetapkan ke sebuah database, rotasi kunci pada tingkat database merupakan operasi CRUD pada database yang melibatkan pembaruan properti pelindung enkripsi pada database. Set-AzSqlDatabase dan properti -EncryptionProtector dapat digunakan untuk memutar kunci. Untuk membuat database baru yang dikonfigurasi dengan CMK pada tingkat database, New-AzSqlDatabase dapat digunakan dengan parameter -EncryptionProtector, -AssignIdentity, dan -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 atau Azure Managed HSM. Rotasi dipicu ketika versi kunci baru terdeteksi, dan pelindung TDE secara otomatis berputar dalam waktu 24 jam. Untuk informasi tentang cara mengonfigurasi rotasi kunci otomatis menggunakan PowerShell atau Azure CLI, lihat Rotasi kunci otomatis di tingkat basis data.

Izin untuk manajemen kunci

Pilih jenis brankas kunci yang ingin Anda gunakan.

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 dapat menggunakan pelindung TDE yang disimpan di Azure Key Vault untuk enkripsi DEK, administrator Azure Key Vault 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 Azure Key Vault 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 yang dikelola pelanggan lintas penyewa

Artikel "Kunci yang dikelola pelanggan lintas-penyewa dengan Enkripsi Data Transparan" menjelaskan cara menyiapkan ID klien terfederasi 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 multipenyewa belum ditambahkan ke brankas kunci atau HSM terkelola dengan izin yang diperlukan (Dapatkan, Bungkus Kunci, Lepaskan Bungkus Kunci), menggunakan aplikasi untuk federasi identitas di portal Azure akan menunjukkan kesalahan. Pastikan bahwa izin dikonfigurasi dengan benar sebelum mengonfigurasi identitas klien federasi.

Database yang dikonfigurasi dengan kunci CMK tingkat database dapat dikembalikan ke enkripsi tingkat server jika server logis dikonfigurasi dengan kunci yang dikelola oleh 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 pada tingkat database menjelaskan operasi manajemen identitas dan kunci untuk CMK pada 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 pada level database tidak didukung melalui Transact-SQL (T-SQL).
  • Identitas terkelola yang ditetapkan pengguna (UMI) pada server logikal dapat digunakan di tingkat database. Namun, disarankan untuk menggunakan UMI khusus untuk CMK tingkat database.
  • Pengaturan CMK lintas-penyewa level server tidak memengaruhi setiap database yang dikonfigurasi dengan CMK level database, dan tetap menggunakan konfigurasi penyewa tunggal atau lintas-penyewa masing-masing.
  • Hanya satu identitas terkelola yang ditetapkan pengguna yang dapat diatur di tingkat database.

Penting

Saat database diganti namanya, tentukan ulang identitas terkelola apa pun yang terkait dengan database:

  1. Hapus penetapan identitas terkelola dari database.
  2. Menetapkan kembali identitas terkelola ke database tersebut.

Untuk perintah, lihat Memperbarui Azure SQL Database yang ada dengan kunci yang dikelola pelanggan pada tingkat database.

Migrasi database yang sudah ada ke CMK pada tingkat database

Database baru dapat dikonfigurasi dengan CMK tingkat database saat dibuat, dan database yang ada di server yang dikonfigurasi dengan kunci yang dikelola layanan dapat dimigrasikan ke CMK tingkat database menggunakan operasi yang dijelaskan dalam Manajemen identitas dan 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, catat vlf_encryptor_thumbprint dari hasil sys.dm_db_log_info.
  3. Gunakan tampilan sys.dm_database_encryption_keys (Transact-SQL) - SQL Server untuk basis data Anda untuk memeriksa encryptor_thumbprint. encryptor_thumbprintRekam .
  4. Gunakan cmdlet Get-AzSqlServerKeyVaultKey untuk mendapatkan semua kunci tingkat server yang dikonfigurasi di server logis. Dari hasilnya, pilih yang memiliki sidik jari yang sama dengan daftar Anda dari langkah sebelumnya.
  5. Lakukan panggilan API database pembaruan ke database yang ingin Anda migrasikan, bersama dengan pelindung identitas dan enkripsi. Teruskan kunci sebelumnya sebagai kunci tingkat database dengan menggunakan Set-AzSqlDatabase dengan parameter -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (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 1 sampai 4 yang disebutkan di bagian sebelumnya untuk mengambil daftar kunci yang dibutuhkan untuk migrasi.
  2. Lakukan pemanggilan API pembaruan database ke database utama dan sekunder yang ingin Anda migrasikan, bersama dengan identitas dan kunci sebelumnya sebagai kunci tingkat database menggunakan Set-AzSqlDatabase dan parameternya -KeyList . Jangan atur protektor enkripsi dulu.
  3. Tambahkan kunci level database yang ingin Anda gunakan sebagai pelindung utama pada database ke database sekunder. Gunakan Set-AzSqlDatabase dengan -KeyList untuk menambahkan kunci ini pada database sekunder.
  4. Setelah Anda menambahkan kunci pelindung enkripsi ke database sekunder, gunakan Set-AzSqlDatabase untuk mengaturnya sebagai pelindung enkripsi pada basis data utama dengan menggunakan parameter tersebut -EncryptionProtector .
  5. Atur kunci sebagai pelindung enkripsi pada database sekunder seperti yang dijelaskan pada langkah 4 untuk menyelesaikan migrasi.

Penting

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

Replikasi geografis dan ketersediaan tinggi

Dalam skenario replikasi geografis aktif dan kelompok failover, database utama dan sekunder dapat ditautkan ke brankas kunci yang sama atau HSM terkelola (di wilayah mana pun), atau ke brankas kunci atau HSM terkelola yang terpisah. Jika brankas kunci terpisah atau HSM terkelola ditautkan ke server utama dan sekunder, pelanggan bertanggung jawab untuk menjaga konsistensi materi kunci di seluruh brankas kunci atau HSM terkelola, sehingga server geo-sekunder tetap sinkron dan dapat mengambil alih dengan menggunakan kunci yang sama dari brankas kunci atau HSM terkelola yang ditautkan, apabila server utama menjadi tidak dapat diakses karena pemadaman jaringan di wilayah tersebut dan failover dipicu. Anda dapat mengonfigurasi hingga empat sekunder, dan konfigurasi berantai (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. Isi terlebih dahulu daftar kunci yang digunakan oleh database utama dengan menggunakan perintah Get-AzSqlDatabase, serta parameter -ExpandKeyList dan -KeysFilter "current". Kecualikan -KeysFilter jika Anda ingin mengambil semua kunci.
  2. Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien federasi jika mengonfigurasi akses lintas tenant).
  3. Buat database baru sebagai database sekunder menggunakan New-AzSqlDatabaseSecondary dan berikan daftar kunci yang sudah diisi sebelumnya yang diperoleh dari database sumber serta identitas di atas (dan federated client DI jika mengonfigurasi akses lintas tenant) dalam panggilan API menggunakan parameter -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (dan jika perlu, -FederatedClientId).
  4. Gunakan New-AzSqlDatabaseCopy untuk membuat salinan database dengan parameter yang sama di langkah sebelumnya.

Penting

Basis data yang dikonfigurasi dengan CMK tingkat basis data harus memiliki replika (atau salinan) yang dikonfigurasi dengan CMK tingkat basis data. 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, Konfigurasi 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 atau Azure Managed HSM, cadangan yang baru dibuat juga dienkripsi dengan pelindung TDE yang sama. Saat pelindung TDE diubah, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru. Untuk memulihkan cadangan yang dienkripsi dengan pelindung TDE dari Azure Key Vault atau Azure Managed HSM yang dikonfigurasi di tingkat database, pastikan bahwa materi kunci disediakan ke database target. Kami menyarankan agar Anda menyimpan semua versi lama pelindung TDE di brankas kunci atau HSM terkelola, sehingga cadangan database dapat dipulihkan.

Penting

Hanya satu pelindung TDE yang dapat ditetapkan untuk sebuah 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 ke titik waktu tertentu untuk database yang dikonfigurasi dengan kunci yang dikelola pelanggan pada tingkat database:

  1. Isi terlebih dahulu daftar kunci yang digunakan oleh database utama dengan menggunakan perintah Get-AzSqlDatabase, serta parameter -ExpandKeyList 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 federasi jika mengonfigurasi akses lintas tenant).
  3. Gunakan Restore-AzSqlDatabase dengan parameter -FromPointInTimeBackup dan berikan daftar kunci yang sudah terisi sebelumnya yang diperoleh dari langkah-langkah di atas, serta identitas di atas (dan ID klien terfederasi jika mengonfigurasi akses lintas penyewa) dalam panggilan API menggunakan parameter -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (dan, jika perlu, -FederatedClientId).

Catatan

Jika Anda memulihkan database tanpa properti tersebut -EncryptionProtector tetapi menyertakan semua kunci yang valid, database akan direset untuk menggunakan enkripsi tingkat server. Pendekatan ini dapat berguna untuk mengembalikan konfigurasi kunci yang dikelola pelanggan di tingkat basis data ke konfigurasi kunci yang dikelola pelanggan di tingkat server.

Pemulihan basis data yang terhapus

Langkah-langkah berikut diperlukan untuk pemulihan database yang telah dihapus dan dikonfigurasi dengan kunci yang dikelola pelanggan pada tingkat database:

  1. Isi daftar kunci yang digunakan oleh database utama dengan menjalankan Get-AzSqlDeletedDatabaseBackup menggunakan parameter tersebut -ExpandKeyList . Berikan semua kunci yang digunakan oleh database sumber. Sebagai alternatif, Anda dapat mencoba pemulihan dengan menggunakan kunci yang diberikan pada waktu penghapusan sebagai .-KeysFilter
  2. Pilih identitas terkelola yang ditetapkan pengguna (dan ID klien federasi jika mengonfigurasi akses lintas tenant).
  3. Gunakan Restore-AzSqlDatabase dengan parameter -FromDeletedDatabaseBackup dan berikan daftar kunci praisi yang diperoleh dari langkah-langkah di atas serta identitas di atas (dan ID klien federasi jika mengonfigurasi akses lintas tenant) dalam panggilan API menggunakan parameter -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (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 federasi jika mengonfigurasi akses lintas tenant).
  • Gunakan Restore-AzSqlDatabase dengan parameter -FromGeoBackup dan berikan daftar kunci praisi yang diperoleh dari langkah-langkah di atas serta identitas di atas (dan ID klien federasi jika mengonfigurasi akses lintas tenant) dalam panggilan API menggunakan parameter -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (dan jika perlu, -FederatedClientId).

Penting

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

Catatan

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 terjadi dalam kasus ini adalah:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Rotasi kunci untuk Pelindung TDE pada tingkat database diblokir ketika transaksi aktif masih menggunakan log yang dienkripsi dengan kunci lama.

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

Contoh garis waktu rotasi kunci pada database yang dikonfigurasi dengan kunci yang dikelola pelanggan tingkat database.

  • Waktu t0 = Database dibuat tanpa enkripsi
  • Waktu t1 = Database ini dilindungi oleh Thumbprint A, yang merupakan kunci yang dikelola pelanggan pada tingkat database.
  • Waktu t2 = Pelindung basis data dirotasikan ke kunci yang dikelola pelanggan tingkat basis data yang baru, Thumbprint B.
  • Waktu t3 = Perubahan proteksi ke 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 cukup banyak log dihasilkan melalui penyisipan data, VLF lama ini dikosongkan dan Anda seharusnya dapat melakukan rotasi kunci lagi.

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

Konten terkait

Periksa dokumentasi berikut tentang berbagai operasi CMK tingkat database:

  • Terakhir diperbarui pada