Share via

Müşteri tarafından yönetilen anahtarlarla veritabanı düzeyinde saydam veri şifrelemesi (TDE)

  • Makale

Şunlar için geçerlidir:Azure SQL Veritabanı

Bu makalede, Azure SQL Veritabanı için veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla saydam veri şifrelemesi (TDE) açıklanmaktadır.

Not

Veritabanı Düzeyi TDE CMK, Azure SQL Veritabanı (tüm SQL Veritabanı sürümleri) için kullanılabilir. Azure SQL Yönetilen Örneği, şirket içi SQL Server, Azure VM'leri ve Azure Synapse Analytics (ayrılmış SQL havuzları (eski adı SQL DW) için kullanılamaz.

Not

Microsoft Entra Id daha önce Azure Active Directory (Azure AD) olarak biliniyordu.

Genel bakış

Azure SQL, saydam veri şifrelemesi (TDE) aracılığıyla müşterilere bekleyen şifreleme özelliği sunar. TDE'yi müşteri tarafından yönetilen anahtar (CMK) ile genişletmek, TDE koruyucusunun (şifreleme anahtarı) veritabanı şifreleme anahtarlarını şifreleyen bir Azure Key Vault'ta depolandığı bekleyen veri korumasını etkinleştirir. Şu anda CMK ile TDE sunucu düzeyinde ayarlanmıştır ve bu sunucuyla ilişkili tüm şifrelenmiş veritabanları tarafından devralınır. Bu yeni özellik, TDE koruyucusunun sunucudaki her veritabanı için ayrı ayrı müşteri tarafından yönetilen anahtar olarak ayarlanmasına olanak tanır. Geçerli ve boş encryptionProtector olmayan bir özelliğe sahip tüm Microsoft.Sql/servers/databases kaynaklar, veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılır.

Bu senaryoda, müşteri tarafından yönetilen ve müşteri tarafından yönetilen bir Azure Key Vault'ta (AKV) depolanan asimetrik anahtar, TDE koruyucusu olarak adlandırılan veritabanı şifreleme anahtarını (DEK) şifrelemek için bir sunucudaki her veritabanı için ayrı ayrı kullanılabilir. Her veritabanı için anahtar ekleme, anahtarları kaldırma ve kullanıcı tarafından atanan yönetilen kimliği (UMI) değiştirme seçeneği vardır. Kimlikler hakkında daha fazla bilgi için bkz . Azure'da yönetilen kimlik türleri .

Aşağıdaki işlevler kullanılabilir:

  • Kullanıcı tarafından atanan yönetilen kimlik: Veritabanına tek bir kullanıcı tarafından atanan yönetilen kimlik atayabilirsiniz. Bu kimlik, Azure Key Vault'a erişmek ve şifreleme anahtarlarını yönetmek için kullanılabilir.
  • Şifreleme anahtarı yönetimi: Veritabanı düzeyinde bir veya daha fazla şifreleme anahtarının eklenmesini etkinleştirebilir ve eklenen anahtarlardan birini TDE koruyucusu olarak ayarlayabilirsiniz. Eklenen şifreleme anahtarları, Azure Key Vault'a erişmek için veritabanına zaten atanmış olan kullanıcı tarafından atanan yönetilen kimliği kullanır.
  • Federasyon istemci kimliği: ayrıca Azure SQL Veritabanı üzerinde ayarlanan federasyon istemci kimliğini kullanarak farklı bir Microsoft Entra kiracısında Bulunan Azure Key Vault'tan müşteri tarafından yönetilen anahtarın (CMK) veritabanı düzeyinde TDE koruyucusu olarak ayarlanmasını da etkinleştirebilirsiniz. Bu, TDE'yi farklı bir kiracının Azure Key Vault'unda depolanan anahtarlarla yönetmenizi sağlar.

Not

Sistem tarafından atanan yönetilen kimlik, veritabanı düzeyinde desteklenmez.

Müşteri tarafından yönetilen TDE'nin veritabanı düzeyinde avantajları

Bağımsız yazılım satıcıları (ISV) olarak da bilinen daha fazla hizmet sağlayıcısı, hizmetlerini oluşturmak için Azure SQL Veritabanı kullanırken, birçoğu işlem kaynaklarını birden çok veritabanına verimli bir şekilde dağıtmanın bir yolu olarak elastik havuzlara yönelmektedir. ISV'ler, müşterilerinin veritabanlarının her birinin paylaşılan elastik havuza alınmasıyla havuzun kaynak kullanımını iyileştirme özelliğinden yararlanabilir ve her veritabanının yeterli kaynağa sahip olduğundan emin olabilir.

Ancak bu yaklaşımın önemli bir sınırlaması vardır. Aynı Azure SQL mantıksal sunucusunda birden çok veritabanı barındırıldığında, sunucu düzeyinde TDE koruyucusu paylaşılır. ISV'ler müşterilerine gerçek müşteri tarafından yönetilen anahtarlar (CMK) özellikleri sunamaz. Müşteriler, kendi şifreleme anahtarlarını yönetme olanağı olmadan, özellikle uyumluluk düzenlemeleri şifreleme anahtarları üzerinde tam denetim sahibi olmalarını gerektiriyorsa hassas verileri ISV'nin hizmetine emanet etme konusunda tereddütlü olabilir.

Veritabanı düzeyinde TDE CMK ile, her veritabanının TDE koruyucusu sahip oldukları bir anahtar kasasında ilgili ISV müşterisine ait olabileceğinden, ISV'ler müşterilerine CMK özelliği sunabilir ve güvenlik yalıtımı sağlayabilir. ISV'nin müşterileri için elde edilen güvenlik yalıtımı hem anahtar hem de anahtara erişmek için kullanılan kimlik açısındandır.

Aşağıdaki diyagramda yukarıda belirtilen yeni işlevler özetlenmiştir. İki ayrı Microsoft Entra kiracısı sunar. Best Services azure DB 2Azure Key Vault 1DB 1 SQL mantıksal sunucusunu içeren ve ve kullanan UMI 1veritabanına DB 1 erişen kiracı.Key 1 Key 1 Hem hem de UMI 1 sunucu düzeyi ayarını temsil eder. Varsayılan olarak, başlangıçta bu sunucuda oluşturulan tüm veritabanları CMK ile TDE için bu ayarı devralır. Kiracı, Contoso bu veritabanının Azure Key Vault 2 kullanılması Key 2 ve UMI 2 ayarlanması için veritabanı düzeyinde CMK kiracılar arası desteğinin bir parçası olarak kiracı genelinde veritabanını DB 2 değerlendirme içeren bir Key 2 istemci kiracısını temsil eder.

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

Kiracılar arası kimlik yapılandırması hakkında daha fazla bilgi için, saydam veri şifrelemesi ile kiracılar arası müşteri tarafından yönetilen anahtarlar sunucu düzeyi belgesine bakın.

Desteklenen anahtar yönetimi senaryoları

Aşağıdaki bölümde üç veritabanından (örneğin Database1, Database2ve Database3) oluşan bir sunucu olduğunu varsayalım.

Mevcut senaryo

Key1 mantıksal sunucu düzeyinde müşteri tarafından yönetilen anahtar olarak yapılandırılır. Bu sunucu altındaki tüm veritabanları aynı anahtarı devralır.

  • Sunucu – Key1 CMK olarak ayarla
  • Database1 – Key1 CMK olarak kullanılır
  • Database2 – Key1 CMK olarak kullanılır
  • Database3 – Key1 CMK olarak kullanılır

Desteklenen yeni senaryo: Müşteri tarafından yönetilen anahtarla yapılandırılmış mantıksal sunucu

Key1 mantıksal sunucu düzeyinde müşteri tarafından yönetilen anahtar olarak yapılandırılır. Veritabanı düzeyinde farklı bir müşteri tarafından yönetilen anahtar (Key2) yapılandırılabilir.

  • Sunucu – Key1 CMK olarak ayarla
  • Database1 – Key2 CMK olarak kullanılır
  • Database2 – Key1 CMK olarak kullanılır
  • Database3 – Key1 CMK olarak kullanılır

Not

Mantıksal sunucu TDE için müşteri tarafından yönetilen anahtarlarla yapılandırılmışsa, bu mantıksal sunucudaki tek bir veritabanı saydam veri şifrelemesi için hizmet tarafından yönetilen anahtar kullanmayı kabul edilemez.

Yeni desteklenen senaryo: Hizmet tarafından yönetilen anahtarla yapılandırılmış mantıksal sunucu

Mantıksal sunucu, TDE için hizmet tarafından yönetilen anahtar (SMK) ile yapılandırılır. Veritabanı düzeyinde farklı bir müşteri tarafından yönetilen anahtar (Key2) yapılandırılabilir.

  • Sunucu - TDE koruyucusu olarak hizmet tarafından yönetilen anahtar kümesi
  • Database1 – Key2 CMK olarak ayarla
  • Database2 – TDE koruyucusu olarak hizmet tarafından yönetilen anahtar kümesi
  • Database3 – TDE koruyucusu olarak hizmet tarafından yönetilen anahtar kümesi

Sunucu düzeyinde şifrelemeye geri dönme

Database1 , mantıksal sunucu hizmet tarafından yönetilen anahtarla yapılandırılırken TDE için müşteri tarafından yönetilen veritabanı düzeyinde bir anahtarla yapılandırılır. Database1 mantıksal sunucu düzeyinde hizmet tarafından yönetilen anahtarı kullanmak için geri döndürülebilir.

Not

Mantıksal sunucu TDE için CMK ile yapılandırılmışsa, veritabanı düzeyinde CMK ile yapılandırılan veritabanı, sunucu düzeyinde şifrelemeye geri döndürülemez.

Geri döndürme işlemi yalnızca TDE kullanılırken mantıksal sunucu hizmet tarafından yönetilen anahtarla yapılandırıldığında desteklenir, ancak sunucunun kaynak veritabanı tarafından kullanılan tüm anahtarlara geçerli bir kimlikle erişimi olması koşuluyla, veritabanı düzeyinde CMK ile yapılandırılmış bir veritabanı CMK ile yapılandırılmış bir sunucuya geri yüklenebilir.

Anahtar kasası ve yönetilen kimlik gereksinimleri

Sunucu düzeyinde müşteri tarafından yönetilen anahtar (CMK) özelliği için geçerli olan kimlik için verilen anahtar ayarları ve izinler de dahil olmak üzere Azure Key Vault (AKV) anahtarlarını ve yönetilen kimlikleri yapılandırmak için aynı gereksinimler veritabanı düzeyinde CMK için de geçerlidir. Daha fazla bilgi için bkz. CMK ile Saydam Veri Şifrelemesi (TDE) ve CMK ile Yönetilen Kimlikler.

Anahtar yönetimi

Bir veritabanı için TDE koruyucusunun döndürülmesinin anlamı, veritabanını koruyan yeni bir asimetrik anahtara geçiş yapmaktır. Anahtar döndürme çevrimiçi bir işlemdir ve tamamlanması yalnızca birkaç saniye sürer. İşlem, veritabanının tamamını değil yalnızca veritabanı şifreleme anahtarının şifresini çözer ve yeniden şifreler. Veritabanına geçerli bir kullanıcı tarafından atanan yönetilen kimlik atandıktan sonra, anahtarı veritabanı düzeyinde döndürmek, veritabanının şifreleme koruyucu özelliğinin güncelleştirilmesini içeren bir veritabanı CRUD işlemidir. Set-AzSqlDatabase ve özelliği -EncryptionProtector anahtarları döndürmek için kullanılabilir. Veritabanı düzeyinde CMK ile yapılandırılmış yeni bir veritabanı oluşturmak için New-AzSqlDatabase , -AssignIdentityve -UserAssignedIdentityId parametreleriyle -EncryptionProtectorkullanılabilir.

Yeni anahtarlar eklenebilir ve var olan anahtarlar, benzer istekler kullanılarak ve veritabanı kaynağının keys özelliği değiştirerek veritabanından kaldırılabilir. parametresiyle -KeyList Set-AzSqlDatabase ve -KeysToRemove bu işlemler için kullanılabilir. Şifreleme koruyucusu, kimlik ve anahtarlar ayarını almak için Get-AzSqlDatabase kullanılabilir. Azure Resource Manager kaynağı Microsoft.Sql/servers/databases varsayılan olarak yalnızca veritabanında yapılandırılan TDE koruyucusu ve yönetilen kimliği gösterir. Anahtarların tam listesini genişletmek için, gibi -ExpandKeyList diğer parametreler gereklidir. Ayrıca, -KeysFilter "current" kullanılan geçerli anahtarları ve geçmişte belirli bir zamanda kullanılan anahtarları almak için zaman değeri (örneğin, 2023-01-01) içindeki bir nokta kullanılabilir.

Otomatik anahtar döndürme

Otomatik anahtar döndürme veritabanı düzeyinde kullanılabilir ve Azure Key Vault anahtarlarıyla kullanılabilir. Anahtarın yeni bir sürümü algılandığında döndürme tetiklenir ve 24 saat içinde otomatik olarak döndürülür. Azure portalı, PowerShell veya Azure CLI kullanarak otomatik anahtar döndürmeyi yapılandırma hakkında bilgi için bkz . Veritabanı düzeyinde otomatik anahtar döndürme.

Anahtar yönetimi izni

Anahtar kasasının izin modeline (erişim ilkesi veya Azure RBAC) bağlı olarak, anahtar kasasına erişim ilkesi oluşturularak veya yeni bir Azure RBAC rol ataması oluşturularak anahtar kasası erişimi verilebilir.

Erişim ilkesi izin modeli

Veritabanının DEK şifrelemesi için AKV'de depolanan TDE koruyucusunu kullanabilmesi için anahtar kasası yöneticisinin benzersiz Microsoft Entra kimliğini kullanarak veritabanı kullanıcı tarafından atanan yönetilen kimliğe aşağıdaki erişim haklarını vermesi gerekir:

  • get - Azure Key Vault'ta anahtarın ortak bölümünü ve özelliklerini almak için.
  • wrapKey - DEK'yi koruyabilmek (şifreleyebilmek) için.
  • unwrapKey - DEK korumasını kaldırabilmek (şifresini çözebilmek için).

Azure RBAC izin modeli

Veritabanının DEK şifrelemesi için AKV'de depolanan TDE koruyucusunu kullanabilmesi için, benzersiz Microsoft Entra kimliği kullanılarak veritabanı kullanıcı tarafından atanan yönetilen kimlik için Key Vault Şifreleme Hizmeti Şifreleme Kullanıcısı rolüne sahip yeni bir Azure RBAC rol ataması eklenmelidir.

Kiracılar arası müşteri tarafından yönetilen anahtarlar

Saydam veri şifrelemesi ile kiracılar arası müşteri tarafından yönetilen anahtarlar, sunucu düzeyinde CMK için federasyon istemci kimliğinin nasıl ayarlandığını açıklar. Veritabanı düzeyinde CMK için benzer bir kurulum yapılması ve federasyon istemci kimliğinin Set-AzSqlDatabase veya New-AzSqlDatabase API isteklerinin bir parçası olarak eklenmesi gerekir.

Not

Çok kiracılı uygulama gerekli izinlerle anahtar kasası erişim ilkesine eklenmemişse (Alma, Sarmalama Anahtarı, Anahtarı Kaldır), Azure portalında kimlik federasyonu için bir uygulama kullanıldığında hata gösterilir. Federasyon istemci kimliğini yapılandırmadan önce izinlerin doğru yapılandırıldığından emin olun.

Mantıksal sunucu Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert kullanılarak hizmet tarafından yönetilen bir anahtarla yapılandırılmışsa, veritabanı düzeyinde CMK ile yapılandırılmış bir veritabanı sunucu düzeyinde şifrelemeye geri döndürülebilir.

CMK ile Saydam veri şifrelemesi (TDE) bölümünde açıklandığı gibi erişilemez bir TDE koruyucusu söz konusu olduğunda, anahtar erişimi düzeltildikten sonra veritabanını erişilebilir hale getirmek için Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation kullanılabilir.

Not

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla TDE için kimlik ve anahtar yönetimi, powershell, Azure CLI ve REST API örnekleriyle birlikte veritabanı düzeyinde CMK için kimlik ve anahtar yönetimi işlemlerini ayrıntılı olarak açıklar.

Dikkat edilecek diğer noktalar

  • CMK ile TDE sunucu düzeyinde zaten etkinleştirilmişse, belirli bir veritabanı için CMK ayarı sunucu düzeyinde CMK ayarını geçersiz kılar (veritabanının DEK değeri veritabanı düzeyinde TDE koruyucusu ile yeniden şifrelenir).
  • Mantıksal sunucu düzeyindeki anahtar değişiklikleri veya döndürmeleri veritabanı düzeyi CMK ayarlarını etkilemez ve veritabanı kendi CMK ayarını kullanmaya devam eder.
  • Veritabanı düzeyinde CMK, Transact-SQL (T-SQL) aracılığıyla desteklenmez.
  • Kullanıcı tarafından atanan mantıksal sunucu yönetilen kimliği (UMI) veritabanı düzeyinde kullanılabilir. Ancak, veritabanı düzeyinde CMK için belirlenmiş bir UMI kullanılması önerilir.
  • Sunucu düzeyi kiracılar arası CMK ayarları, veritabanı düzeyi CMK ile yapılandırılmış tek veritabanlarını etkilemez ve kendi tek kiracılarını veya kiracılar arası yapılandırmalarını kullanmaya devam eder.
  • Veritabanı düzeyinde yalnızca tek bir kullanıcı tarafından atanan yönetilen kimlik ayarlanabilir.

Not

Veritabanı yeniden adlandırılırsa, veritabanındaki yönetilen kimlikler yeniden atanmalıdır.

Mevcut veritabanlarının veritabanı düzeyinde CMK'ye geçirilmesi

Yeni veritabanları oluşturma sırasında veritabanı düzeyinde CMK ile yapılandırılabilir ve hizmet tarafından yönetilen anahtarlarla yapılandırılmış sunuculardaki mevcut veritabanları, veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla TDE için kimlik ve anahtar yönetimi bölümünde açıklanan işlemler kullanılarak veritabanı düzeyinde CMK'ye geçirilebilir. Sunucu düzeyinde CMK veya coğrafi çoğaltma ile yapılandırılmış veritabanlarını geçirmek için, aşağıdaki bölümlerde açıklandığı gibi başka adımlar gerekir.

Coğrafi çoğaltma olmadan sunucu düzeyinde CMK ile yapılandırılan veritabanı

  1. Veritabanınız için sys.dm_db_log_info (Transact-SQL) - SQL Server'ı kullanın ve etkin olan sanal günlük dosyalarını (VLFs) arayın.
  2. Tüm etkin VLF'ler için sonucu kaydedin vlf_encryptor_thumbprintsys.dm_db_log_info .
  3. veritabanınızın denetlemek encryptor_thumbprintiçin sys.dm_database_encryption_keys (Transact-SQL) - SQL Server görünümünü kullanın. dosyasını encryptor_thumbprintkaydedin.
  4. Mantıksal sunucuda yapılandırılan tüm sunucu düzeyi anahtarlarını almak için Get-AzSqlServerKeyVaultKey cmdlet'ini kullanın. Sonuçlardan, yukarıdaki sonuçtan listenizle eşleşen parmak izine sahip olanları seçin.
  5. Kimlik ve şifreleme koruyucusuyla birlikte geçirmek istediğiniz veritabanına bir güncelleştirme veritabanı API çağrısı yapın. Yukarıdaki anahtarları, -KeyList-AssignIdentity-EncryptionProtector (ve gerekirse-FederatedClientId) parametrelerini kullanarak Set-AzSqlDatabase kullanarak -UserAssignedIdentityIdveritabanı düzeyi anahtarları olarak geçirin.

Önemli

Güncelleştirme veritabanı isteğinde kullanılan kimliğin giriş olarak geçirilen tüm anahtarlara erişimi olmalıdır.

Coğrafi çoğaltma ile sunucu düzeyinde CMK ile yapılandırılan veritabanı

  1. Geçiş için gerekli anahtarların listesini almak için önceki bölümde belirtilen (1) ile (4) arasında adımları izleyin.
  2. Set-AzSqlDatabase ve parametresini kullanarak veritabanı düzeyi anahtarları olarak kimlik ve yukarıdaki anahtarlarla birlikte geçirmek istediğiniz birincil ve -KeyList ikincil veritabanına bir güncelleştirme veritabanı API çağrısı yapın. Şifreleme koruyucusu henüz ayarlanmıyor.
  3. Veritabanlarında birincil koruyucu olarak kullanmak istediğiniz veritabanı düzeyi anahtarı önce ikincil veritabanına eklenmelidir. Bu anahtarı ikincil veritabanına eklemek için Set-AzSqlDatabase komutunu ile -KeyList kullanın.
  4. Şifreleme koruyucu anahtarı ikincil veritabanına eklendikten sonra Set-AzSqlDatabase komutunu kullanarak parametresini kullanarak -EncryptionProtector birincil veritabanında şifreleme koruyucusu olarak ayarlayın.
  5. Geçişi tamamlamak için anahtarı (4) içinde açıklandığı gibi ikincil veritabanında şifreleme koruyucusu olarak ayarlayın.

Önemli

Sunucu düzeyinde hizmet tarafından yönetilen anahtar ve coğrafi çoğaltma ile yapılandırılan veritabanlarını geçirmek için bu bölümdeki adımları (3), (4) ve (5) izleyin.

Coğrafi çoğaltma ve yüksek kullanılabilirlik

Hem etkin coğrafi çoğaltma hem de yük devretme grubu senaryolarında, söz konusu birincil ve ikincil veritabanları aynı anahtar kasasına (herhangi bir bölgede) veya anahtar kasalarını ayırmak için bağlanabilir. Birincil ve ikincil sunuculara ayrı anahtar kasaları bağlanırsa, anahtar kasaları arasında anahtar malzemesinin tutarlı kalmasını sağlamak müşterinin sorumluluğundadır. Böylelikle coğrafi olarak ikincil sunucu eşitlenmiş durumda olur ve bölgede bir kesinti olduğundan birincil sunucuya erişilememesi ve yük devretme işleminin tetiklenmesi durumunda ikincil sunucu bağlı anahtar kasasındaki aynı anahtarı kullanarak yükü devralabilir. En fazla dört ikincil yapılandırılabilir ve zincirleme (ikincillerin ikincilleri) desteklenmez.

Veritabanı düzeyinde CMK ile yapılandırılmış bir veritabanı için etkin coğrafi çoğaltma oluşturmak için, geçerli bir kullanıcı tarafından atanan yönetilen kimlik ve birincil veritabanı tarafından kullanılan geçerli anahtarların listesi ile ikincil çoğaltma oluşturulmalıdır. Geçerli anahtarların listesi, gerekli filtreler ve sorgu parametreleri kullanılarak veya PowerShell ve Azure CLI kullanılarak birincil veritabanından alınabilir. Böyle bir veritabanının coğrafi çoğaltmasını ayarlamak için gereken adımlar şunlardır:

  1. Get-AzSqlDatabase komutunu ve ve -KeysFilter "current" parametrelerini kullanarak birincil veritabanı tarafından kullanılan anahtarların -ExpandKeyList listesini önceden girin. Tüm anahtarları almak istiyorsanız hariç tutun -KeysFilter .
  2. Kullanıcı tarafından atanan yönetilen kimliği (ve kiracılar arası erişimi yapılandırıyorsanız federasyon istemci kimliğini) seçin.
  3. New-AzSqlDatabaseSecondary kullanarak ikincil olarak yeni bir veritabanı oluşturun ve , (ve gerekirse-FederatedClientId) parametrelerini kullanarak API çağrısında kaynak veritabanından ve yukarıdaki kimlikten (ve kiracılar arası erişimi yapılandırıyorsa federasyon istemcisi DI'den) elde edilen anahtarların -KeyList-EncryptionProtector-UserAssignedIdentityId-AssignIdentityönceden doldurulmuş listesini sağlayın.
  4. Önceki adımda aynı parametrelerle veritabanının bir kopyasını oluşturmak için New-AzSqlDatabaseCopy kullanın.

Önemli

Veritabanı düzeyinde CMK ile yapılandırılmış bir veritabanında, veritabanı düzeyinde CMK ile yapılandırılmış bir çoğaltma (veya kopya) olmalıdır. Çoğaltma, sunucu düzeyinde şifreleme ayarlarını kullanamaz.

Bir yük devretme grubunda veritabanı düzeyinde CMK ile yapılandırılmış bir veritabanını kullanmak için, birincil çoğaltmayla aynı ada sahip bir ikincil çoğaltma oluşturmak için yukarıdaki adımlar ikincil sunucuda kullanılmalıdır. Bu ikincil çoğaltma yapılandırıldıktan sonra veritabanları yük devretme grubuna eklenebilir.

Veritabanı düzeyinde CMK ile yapılandırılan veritabanları, yük devretme grubuna eklendiğinde otomatik ikincil oluşturmayı desteklemez.

Daha fazla bilgi için veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla saydam veri şifrelemesi için coğrafi çoğaltma ve yedekleme geri yüklemesini yapılandırma, REST API'leri, PowerShell ve Azure CLI kullanarak coğrafi çoğaltma ve yük devretme gruplarının nasıl ayarlandığı açıklanmaktadır.

Not

Sunucu düzeyinde CMK için CMK ile saydam veri şifrelemesinde (TDE) vurgulanan coğrafi çoğaltma ve yüksek kullanılabilirlik ile ilgili tüm en iyi yöntemler, veritabanı düzeyinde CMK için geçerlidir.

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarla TDE kullanan veritabanları için yedekleme ve geri yükleme

Veritabanı, Azure Key Vault'tan bir anahtar kullanılarak TDE ile şifrelendiğinde, yeni oluşturulan tüm yedeklemeler de aynı TDE koruyucusuyla şifrelenir. TDE koruyucusu değiştirildiğinde, veritabanının eski yedekleri en son TDE koruyucusu kullanılacak şekilde güncelleştirilmez . Veritabanı düzeyinde yapılandırılan Azure Key Vault'tan TDE koruyucusuyla şifrelenmiş bir yedeklemeyi geri yüklemek için anahtar malzemesinin hedef veritabanına sağlandığından emin olun. Veritabanı yedeklemelerinin geri yüklenebilmesi için TDE koruyucusunun tüm eski sürümlerini bir anahtar kasasında tutmanızı öneririz.

Önemli

Veritabanı için yalnızca bir TDE koruyucusu ayarlanabilir. Ancak, geri yükleme sırasında bir TDE koruyucusu işaretlemeden veritabanına birden çok ek anahtar geçirilebilir. Bu anahtarlar DEK'yi korumak için kullanılmaz, ancak yedekleme dosyası ilgili parmak iziyle anahtarla şifrelenirse yedeklemeden geri yükleme sırasında kullanılabilir.

Belirli bir noktaya geri yükleme

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılmış bir veritabanının belirli bir noktaya geri yüklenmesi için aşağıdaki adımlar gereklidir:

  1. Get-AzSqlDatabase komutunu ve ve -KeysFilter "2023-01-01" parametrelerini kullanarak birincil veritabanı tarafından kullanılan anahtarların -ExpandKeyList listesini önceden girin. 2023-01-01 , veritabanını geri yüklemek istediğiniz noktaya bir örnektir. Tüm anahtarları almak istiyorsanız hariç tutun -KeysFilter .
  2. Kullanıcı tarafından atanan yönetilen kimliği (ve kiracılar arası erişimi yapılandırıyorsanız federasyon istemci kimliğini) seçin.
  3. Restore-AzSqlDatabase komutunu parametresiyle -FromPointInTimeBackup kullanın ve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve , (ve gerekirse-FederatedClientId) parametrelerini kullanarak -KeyList-AssignIdentity-UserAssignedIdentityId-EncryptionProtector API çağrısında yukarıdaki kimliği (ve kiracılar arası erişimi yapılandırıyorsa federasyon istemci kimliği) sağlayın.

Not

Tüm geçerli anahtarlarla özelliği olmayan -EncryptionProtector bir veritabanının geri yüklenmesi, veritabanını sunucu düzeyinde şifreleme kullanacak şekilde sıfırlar. Bu, veritabanı düzeyinde müşteri tarafından yönetilen anahtar yapılandırmasını sunucu düzeyinde müşteri tarafından yönetilen anahtar yapılandırmasına geri döndürmek için yararlı olabilir.

Bırakılan veritabanı geri yüklemesi

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılmış bir veritabanının bırakılan veritabanı geri yüklemesi için aşağıdaki adımlar gereklidir:

  1. Get-AzSqlDeletedDatabaseBackup ve parametresini kullanarak birincil veritabanı tarafından kullanılan anahtarların -ExpandKeyList listesini önceden doldurma. Kaynak veritabanının kullandığı tüm anahtarların geçirilmesi önerilir, ancak alternatif olarak, silme zamanı -KeysFiltertarafından sağlanan anahtarlarla geri yükleme işlemi de denenebilir.
  2. Kullanıcı tarafından atanan yönetilen kimliği (ve kiracılar arası erişimi yapılandırıyorsanız federasyon istemci kimliğini) seçin.
  3. Parametresiyle -FromDeletedDatabaseBackup Restore-AzSqlDatabase kullanın ve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve api çağrısında , , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (ve gerekirse-FederatedClientId) parametrelerini kullanarak -KeyListyukarıdaki kimlik (ve kiracılar arası erişimi yapılandırıyorsa federasyon istemci kimliği) sağlayın.

Coğrafi geri yükleme

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılmış bir veritabanının coğrafi geri yüklemesi için aşağıdaki adımlar gereklidir:

  • Get-AzSqlDatabaseGeoBackup kullanarak birincil veritabanı tarafından kullanılan anahtarların listesini ve -ExpandKeyList tüm anahtarları almak için öğesini önceden girin.
  • Kullanıcı tarafından atanan yönetilen kimliği (ve kiracılar arası erişimi yapılandırıyorsanız federasyon istemci kimliğini) seçin.
  • Parametresiyle -FromGeoBackup Restore-AzSqlDatabase kullanın ve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve api çağrısında , , -AssignIdentity-UserAssignedIdentityId, -EncryptionProtector (ve gerekirse-FederatedClientId) parametrelerini kullanarak -KeyListyukarıdaki kimlik (ve kiracılar arası erişimi yapılandırıyorsa federasyon istemci kimliği) sağlayın.

Önemli

Veritabanını geri yüklemek için veritabanı tarafından kullanılan tüm anahtarların korunması önerilir. Ayrıca tüm bu anahtarların geri yükleme hedefine geçirilmesi önerilir.

Not

uzun süreli yedekleme saklama (LTR) yedeklemeleri, yedekleme tarafından kullanılan anahtarların listesini sağlamaz. BIR LTR yedeklemesini geri yüklemek için, kaynak veritabanı tarafından kullanılan tüm anahtarların LTR geri yükleme hedefine geçirilmesi gerekir.

PowerShell, Azure CLI ve REST API'lerini kullanan örneklerle veritabanı düzeyinde CMK ile SQL Veritabanı yedekleme kurtarma hakkında daha fazla bilgi edinmek için bkz. Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla saydam veri şifrelemesi için coğrafi çoğaltma ve yedekleme geri yüklemesini yapılandırma.

Sınırlamalar

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlar özelliği, veritabanı sanal günlük dosyaları veritabanının geçerli birincil koruyucusundan farklı eski bir anahtarla şifrelendiğinde anahtar döndürmelerini desteklemez. Bu durumda oluşturulan hata:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Etkin işlemler eski anahtarlarla şifrelenmiş günlüğü tuttuğunda veritabanı düzeyinde TDE Koruyucusu için anahtar döndürme engellenir.

Bu senaryoyu daha fazla anlamak için aşağıdaki zaman çizelgesini ele alalım:

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

  • Zaman t0 = Veritabanı şifreleme olmadan oluşturulur
  • Time t1 = Bu veritabanı, müşteri tarafından yönetilen veritabanı düzeyinde bir anahtar olan ile Thumbprint Akorunur.
  • Zaman t2 = Veritabanı koruyucusu, müşteri tarafından yönetilen yeni bir veritabanı düzeyi anahtarına Thumbprint Bdöndürülür.
  • Zaman t3 = bir koruyucu değişikliği Thumbprint C istendi.
  • Etkin VLF'ler kullanıyorsa Thumbprint A, döndürmeye izin verilmez.
  • Etkin VLF'ler kullanmıyorsaThumbprint A, döndürmeye izin verilir.

Veritabanınız için sys.dm_db_log_info (Transact-SQL) - SQL Server görünümünü kullanabilir ve etkin olan sanal günlük dosyalarını arayabilirsiniz. İlk anahtarla şifrelenmiş etkin bir VLF görmeniz gerekir (örneğin, Thumbprint A). Veri ekleme tarafından yeterli günlük oluşturulduktan sonra, bu eski VLF boşaltılır ve başka bir anahtar döndürme işlemi gerçekleştirebilmeniz gerekir.

Günlüğünüzü beklenenden uzun süre tutan bir şey olduğuna inanıyorsanız, daha fazla sorun giderme için aşağıdaki belgelere bakın:

Sonraki adımlar

Çeşitli veritabanı düzeyinde CMK işlemleriyle ilgili aşağıdaki belgeleri gözden geçirin: