Aracılığıyla paylaş

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

Ş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. Müşteri tarafından yönetilen anahtar (CMK) ile TDE'nin genişletilmesi, TDE koruyucusunun (şifreleme anahtarı) veritabanı şifreleme anahtarlarını şifreleyen bir Azure Key Vault veya Azure Yönetilen HSM'de depolandığı bekleyen veri korumasını etkinleştirir. CMK ile TDE, sunucu düzeyinde ayarlanabilir ve bu sunucuyla ilişkili tüm şifrelenmiş veritabanları tarafından devralınır. TDE koruyucusunu, sunucudaki her veritabanı için ayrı ayrı müşteri tarafından yönetilen bir anahtar olarak da ayarlayabilirsiniz. Geçerli ve boş Microsoft.Sql/servers/databases olmayan bir özelliğe sahip tüm encryptionProtector kaynaklar, veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılır.

Bu senaryoda, TDE koruyucusu olarak adlandırılan veritabanı şifreleme anahtarını (DEK) şifrelemek üzere bir sunucu içindeki her veritabanı için, müşteriye ait ve müşteri tarafından yönetilen bir Azure Key Vault veya Azure Yönetilen HSM'de depolanan asimetrik anahtar 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 veya Azure Yönetilen HSM'ye 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 veya Azure Yönetilen HSM'ye erişmek için veritabanına zaten atanmış olan kullanıcı tarafından atanan yönetilen kimliği kullanır.
  • Federasyon istemci kimliği: Azure SQL Veritabanı'nda ayarlanan federasyon istemci kimliğini kullanarak farklı bir Microsoft Entra kiracısında bulunan ve Azure Key Vault'tan veya Azure Yönetilen HSM'den müşteri tarafından yönetilen anahtarı (CMK) veritabanı düzeyinde TDE koruyucusu olarak ayarlamayı da etkinleştirebilirsiniz. Bu, TDE'yi farklı bir kiracının Azure Key Vault veya Azure Yönetilen HSM'sinde depolanan anahtarlarla yönetmenize olanak tanır.

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, ISV'ler, her bir veritabanının TDE koruyucusunun, müşterinin sahip olduğu bir anahtar kasası veya yönetilen HSM'de bulunabilmesi sayesinde 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 1DB 2Azure Key Vault 1 SQL mantıksal sunucusunu içeren ve ve kullanan Key 1veritabanına DB 1 erişen kiracı.UMI 1 UMI 1 Hem hem de Key 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 DB 2 ayarlanması için veritabanı düzeyinde CMK kiracılar arası desteğinin bir parçası olarak kiracı genelinde veritabanını Key 2 değerlendirme içeren bir UMI 2 istemci kiracısını temsil eder.

Müşteri tarafından yönetilen TDE'nin veritabanı düzeyinde kurulumu ve çalışması

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 destekleniyor olsa da, sunucunun geçerli bir kimlikle kaynak veritabanı tarafından kullanılan tüm anahtarlara 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.

Azure Anahtar Kasası ve Azure Yönetilen HSM - 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 veya Azure Yönetilen HSM 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 , -EncryptionProtectorve -AssignIdentity parametreleriyle -UserAssignedIdentityIdkullanı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. ve -KeyList 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 veya Azure Yönetilen HSM anahtarları ile 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

Kullanmak istediğiniz anahtar kasası türünü seçin.

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 Azure Key Vault'ta depolanan TDE koruyucusunu kullanabilmesi için Azure Key Vault 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 Azure Key Vault'ta 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, anahtar kasasına veya yönetilen HSM'ye gerekli izinlerle (Get, Anahtarı Sarmalama, Anahtarı Açma) eklenmemişse, Azure portalında kimlik federasyonu için bir uygulama kullanılırken bir 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 , veritabanı düzeyinde CMK için kimlik ve anahtar yönetimi işlemlerinin yanı sıra PowerShell, Azure CLI ve REST API örneklerini 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. 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ı, -UserAssignedIdentityId-AssignIdentity (ve gerekirse-KeyList) parametrelerini kullanarak -EncryptionProtector kullanarak -FederatedClientIdveritabanı 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.
  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 veya yönetilen HSM'ye (herhangi bir bölgede) ya da ayrı anahtar kasalarına veya yönetilen HSM'lere bağlanabilir. Birincil ve ikincil sunuculara ayrı anahtar kasaları veya yönetilen HSM'ler bağlıysa, müşteri, anahtar malzemesini bu anahtar kasaları veya yönetilen HSM'ler arasında tutarlı şekilde korumaktan sorumludur. Böylece, coğrafi ikincil sunucu eşitlenmiş olur ve bölgede bir kesinti nedeniyle birincil sunucu erişilemez hale gelir ve yük devretme tetiklenirse, bağlantılı anahtar kasasından veya yönetilen HSM'den aynı anahtarı kullanarak 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-AzSqlDatabasebirincil 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
  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 şeffaf 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 kurulacağını açıklar.

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 veya Azure Yönetilen HSM'den 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 veya Azure Yönetilen HSM'den TDE koruyucusuyla şifrelenmiş bir yedeklemeyi geri yüklemek için anahtar malzemenin hedef veritabanına sağlandığından emin olun. Veritabanı yedeklemelerinin geri yüklenebilmesi için TDE koruyucusunun tüm eski sürümlerini anahtar kasasında veya yönetilen HSM'de 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-AzSqlDatabasebirincil 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-AzSqlDatabaseve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve , (ve gerekirse-FromPointInTimeBackup) 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. kullanın ve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve api çağrısında , , -FromDeletedDatabaseBackup-KeyList, -AssignIdentity (ve gerekirse-UserAssignedIdentityId) parametrelerini kullanarak -EncryptionProtectoryukarı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.
  • kullanın ve yukarıdaki adımlardan elde edilen anahtarların önceden doldurulmuş listesini ve api çağrısında , , -FromGeoBackup-KeyList, -AssignIdentity (ve gerekirse-UserAssignedIdentityId) parametrelerini kullanarak -EncryptionProtectoryukarı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, yedeklemede kullanılan anahtarlar 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ı için 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:

Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla yapılandırılmış bir veritabanındaki anahtar döndürmelerinin örnek zaman çizelgesi.

  • 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:

  • 9002 tam işlem günlüğü hatasıyla ilgili sorunları giderme.

Sonraki adımlar

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

  • Last updated on