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üzeyinde 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ıyla SQL DW)) için kullanılamaz.

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. Müşteri tarafından yönetilen anahtarlar, seçilen anahtar deposuna bağlı olarak hem asimetrik (RSA) hem de simetrik (AES) anahtarları destekler.

Bu senaryoda, müşteri tarafından yönetilen ve müşteri tarafından yönetilen bir Azure Key Vault veya Azure Yönetilen HSM'de depolanan asimetrik veya simetrik 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 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. Kendi şifreleme anahtarlarını yönetebilme imkanı olmadan, müşteriler hassas verileri ISV'nin hizmetine emanet etmekte tereddüt edebilir, özellikle uyumluluk düzenlemeleri şifreleme anahtarları üzerinde tam kontrolü korumalarını gerektiriyorsa.

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 sağlanan güvenlik yalıtımı, hem anahtar hem de anahtara erişmek için kullanılan kimlik açısından elde edilir.

Aşağıdaki diyagramda yukarıda belirtilen yeni işlevler özetlenmiştir. İki ayrı Microsoft Entra kiracı gösterir. Best Services, iki veritabanı (DB 1 ve DB 2) içeren Azure SQL mantıksal sunucusunu ve Azure Key Vault 1 kullanarak Key 1 veritabanına erişen bir DB 1 içeren UMI 1 öğesini barındıran kiracı. 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. Contoso kiracısı, bu veritabanı için Azure Key Vault 2 ve Key 2 yapılandırması kullanılarak veritabanı düzeyindeki CMK kiracılar arası desteğinin bir parçası olarak kiracı genelinde veritabanı DB 2 değerlendiren bir Key 2 ile UMI 2 içeren bir 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 bir anahtarla yapılandırılmışken, TDE için veritabanı düzeyinde müşteri tarafından yönetilen bir anahtarla yapılandırılmıştı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.

Saydam Veri Şifrelemesi with Customer Managed Key, veritabanı şifreleme anahtarını (DEK) korumak için Azure Key Vault veya Azure Managed HSM'de depolanan harici bir anahtar olan TDE koruyucusunu kullanır.

Desteklenen anahtar türleri ve boyutları

Azure SQL seçeneğine ve TDE yapılandırmasına bağlı olarak, TDE koruyucusu Azure Key Vault veya Azure Key Vault Managed HSM’de depolanan asimetrik ya da simetrik anahtarlarla desteklenebilir.

  • Asimetrik anahtarlar (RSA veya RSA HSM)

    • Azure Key Vault ve Azure Key Vault Yönetilen HSM'de desteklenir
    • Desteklenen anahtar boyutları: 2048-bit ve 3072-bit
    • Azure SQL Veritabanı, Azure SQL Yönetilen Örneği ve Azure Synapse Analytics için desteklenir

  • Simetrik anahtarlar (AES)

    • Azure Key Vault Premium (preview) ve Azure Key Vault Managed HSM de destekleniyor
    • Desteklenen anahtar boyutları: 128-bit, 192-bit ve 256-bit
    • Şu anda genel önizleme aşamasında olan Azure SQL Veritabanı için desteklenir. Bölgenize ve hizmet dağıtım durumunuz bağlı olarak bu özelliğin zaman içinde göründüğünü görebilirsiniz.

Not

Saydam Veri Şifrelemesi with symmetric keys (AES) şu anda önizleme aşamasında. Önizleme özellikleri sınırlı yeteneklerle yayınlanıyor, ancak Microsoft bunları önizleme temelinde sunuyor, böylece müşteriler erken erişim ve geri bildirim verebilir. Önizleme özellikleri ayrı ek önizleme koşullarına tabidir ve SLA'lara tabi değildir. Destek, belirli durumlarda en iyi çaba olarak sağlanır. Ancak Microsoft Desteği önizleme işlevselliğiyle ilgili geri bildirimlerinizi almak için sabırsızlanıyor ve bazı durumlarda en iyi desteği sağlayabilir. Önizleme özellikleri sınırlı veya kısıtlanmış işlevlere sahip olabilir ve yalnızca seçili coğrafi bölgelerde kullanılabilir.

Simetrik (AES) anahtarları için sınırlamalar

TDE koruyucusu olarak simetrik (AES) anahtarlar kullanıldığında, yalnızca Azure Key Vault Premium (önizleme) veya Azure Key Vault Managed HSM'de saklanan anahtarlar devam eden anahtar yaşam döngüsü işlemleri için desteklenir. Müşteriler, bir anahtarı yeraltı donanım güvenlik modülünden (HSM) bir kez Azure Key Vault Premium (önizleme) veya Azure Key Vault Managed HSM'ye aktarabilirler. İlk içe aktarmadan sonra, nokta-zamanında kurtarma, jeo-felaket kurtarma ve anahtar yeniden doğrulama dahil olmak üzere tüm sonraki anahtar yaşam döngüsü işlemleri, Azure Key Vault Premium (önizleme) veya Azure Key Vault Managed HSM altyapısına dayanmalıdır. Müşteriler, kurtarma ve yeniden doğrulama senaryolarını desteklemek için içeri aktarılan anahtarların yerel yedeklemelerini korumakla sorumludur. Bu sınırlamalar yalnızca simetrik (AES) anahtarlar için geçerlidir ve asimetrik (RSA) anahtarlar için geçerli değildir.

Önemli durum ve geçerlilik gereksinimleri

  • Anahtar etkinleştirme tarihi belirtilirse, geçmişteki bir tarih ve saat olarak ayarlanmalıdır.
  • Anahtar son kullanma tarihi belirtilirse, gelecekte bir tarih ve saat olarak ayarlanmalıdır.
  • Anahtar Etkin durumda olmalıdır.

Önemli içeri aktarma gereksinimleri

Mevcut bir anahtarı Azure Key Vault içeri aktarırsanız, anahtar aşağıdaki desteklenen biçimlerden birinde sağlanmalıdır:

  • .pfx
  • .byok
  • .Yedekleme

HSM korumalı anahtarları Azure Yönetilen HSM'ye aktarmak için bkz. HSM korumalı anahtarları Yönetilen HSM'ye (BYOK) içeri aktarma.

Azure Key Vault ve Azure Managed 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.

Yapılandırmayı, Azure Key Vault’ta veya Azure Key Vault Managed HSM’de depolanan yeni bir anahtarı kullanacak şekilde değiştirerek TDE koruyucusunu değiştirebilirsiniz. Azure SQL teklifine ve desteklenen yapılandırmaya bağlı olarak şunlar olabilir:

  • Aynı anahtarın yeni bir anahtar sürümüne geçme
  • Farklı bir tuşa geçme
  • Asimetrik (RSA) ve simetrik (AES) anahtarları gibi desteklenen anahtar türleri arasında geçiş yapma

Not

Simetrik anahtarlarla (AES) Saydam Veri Şifrelemesi şu anda yalnızca Azure SQL Veritabanı için desteklenmektedir ve genel önizleme aşamasındadır. Bölgenize ve hizmet dağıtım durumunuz bağlı olarak bu özelliğin zaman içinde göründüğünü görebilirsiniz.

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. Set-AzSqlDatabase, -KeyList ve -KeysToRemove parametreleriyle 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" ve belirli bir zaman noktası değeri (örneğin, 2023-01-01), o anda kullanılan geçerli anahtarları ve geçmişte belirli bir zaman noktasında kullanılmış anahtarları almak için 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. Tuşun yeni bir versiyonu tespit edildiğinde döndürme tetiklenir ve TDE koruyucusu 24 saat içinde otomatik olarak döner. PowerShell veya Azure CLI kullanılarak otomatik anahtar rotasyonu nasıl yapılandırılacağı hakkında bilgi için veritabanı düzeyinde Otomatik anahtar rotasyonu sayfasına bakınız.

Anahtar yönetme 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 yönetimli anahtarlar

Saydam veri şifrelemesi ile kiracılar arası müşteri tarafından yönetilen anahtarlar, sunucu düzeyindeki CMK için federe istemci kimliğinin nasıl ayarlanacağı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.
  • Mantıksal sunucunun kullanıcı tarafından atanan 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üzeyindeki kiracılar arası CMK ayarları, veritabanı düzeyinde CMK ile yapılandırılmış ayrı veritabanlarını etkilemez; bu veritabanları kendi tek kiracılı 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.

Önemli

Bir veritabanı yeniden adlandırıldığında, veritabanıyla ilişkili tüm yönetilen kimlikleri yeniden atayın:

  1. Yönetilen kimliğin atamasını veritabanından kaldırın.
  2. Yönetilen kimliği veritabanına yeniden atayın.

Komutlar için bkz. Mevcut bir Azure SQL Veritabanı’i veritabanı düzeyindeki müşteri tarafından yönetilen anahtarlarla güncelleştirme.

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 vlf_encryptor_thumbprint sonucundaki sys.dm_db_log_info değerini kaydedin.
  3. Veritabanınız için sys.dm_database_encryption_keys (Transact-SQL) - SQL Server görünümünü kullanarak encryptor_thumbprint denetleyin. 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, önceki adımdaki listenizle aynı parmak izine sahip olanları seçin.
  5. Kimlik ve şifreleme koruyucusuyla birlikte, taşımak istediğiniz veritabanına veritabanını güncelleştirme API çağrısı yapın. Önceki anahtarları Set-AzSqlDatabase ile , -UserAssignedIdentityId-AssignIdentity, -KeyList, -EncryptionProtector (ve gerekirse ) -FederatedClientIdparametreleriyle veritabanı düzeyinde anahtarlar olarak aktarın.

Önemli

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

Sunucu düzeyinde CMK ile yapılandırılmış, coğrafi çoğaltmalı veritabanı

  1. Göç için gereken anahtar listesini almak için önceki bölümde belirtilen 1'den 4'e kadar olan adımları takip edin.
  2. Set-AzSqlDatabase ve -KeyList parametreyi kullanarak geçiş yapmak istediğiniz birincil ve ikincil veritabanına güncelleme veritabanı API çağrısı yapın; kimlik ve önceki anahtarları veritabanı seviyesi anahtarlar olarak da kullanın. Şifreleme koruyucusu henüz ayarlanmıyor.
  3. Veritabanlarında birincil koruyucu olarak kullanmak istediğiniz veritabanı seviyesindeki anahtarı ikincil veritabanına ekleyin. Bu anahtarı ikincil veritabanına eklemek için Set-AzSqlDatabase komutunu -KeyList ile kullanın.
  4. Şifreleme koruyucu anahtarını ikincil veritabanına ekledikten sonra, parametreyi -EncryptionProtector kullanarak Set-AzSqlDatabase kullanarak onu birincil veritabanında şifreleme koruyucusu olarak ayarlayın.
  5. Anahtarı, adımda 4'te tanımlandığı gibi ikincil veritabanında şifreleme koruyucusu olarak ayarlayarak geçişi tamamlayın.

Önemli

Sunucu düzeyinde hizmet yönetimli anahtar ve coğrafi çoğaltma ile yapılandırılmış veritabanlarını taşımak için bu bölümdeki 3, 4 ve 5. adımları takip edin.

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 öğe yapılandırılabilir ve zincirleme kullanım (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. Birincil veritabanının kullandığı anahtar listesini Get-AzSqlDatabase komutunu ve -ExpandKeyList ile -KeysFilter "current" parametrelerini kullanarak önceden doldurun. Tüm anahtarları almak istiyorsanız -KeysFilter öğesini hariç tutun.
  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 yeni bir veritabanını ikincil olarak oluşturun ve -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (ve gerekirse -FederatedClientId) parametrelerini kullanarak API çağrısında kaynak veritabanından alınan önceden doldurulmuş anahtar listesini ve yukarıdaki kimliği (ve kiracılar arası erişim yapılandırılıyorsa federasyonlu istemci DI'yi) 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ının, veritabanı düzeyinde CMK ile yapılandırılmış bir çoğaltması (veya kopyası) olması gerekir. Replika, 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 üzere yukarıda belirtilen adımların ikincil sunucuda uygulanması gerekir. Bu ikincil replika 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. Birincil veritabanının kullandığı anahtar listesini Get-AzSqlDatabase komutunu ve -ExpandKeyList ile -KeysFilter "2023-01-01" parametrelerini kullanarak önceden doldurun. 2023-01-01 , veritabanını geri yüklemek istediğiniz noktaya bir örnektir. Tüm anahtarları almak istiyorsanız -KeysFilter öğesini hariç tutun.
  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 -FromPointInTimeBackup parametresiyle kullanın ve API çağrısında -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (ve gerekirse -FederatedClientId) parametrelerini kullanarak, yukarıdaki adımlardan elde edilen önceden doldurulmuş anahtar listesini ve yukarıdaki kimliği (kiracılar arası erişim yapılandırılıyorsa federe istemci kimliğini de) sağlayın.

Not

Eğer bir veritabanını bu -EncryptionProtector özellik olmadan geri getirirseniz ama tüm geçerli anahtarları içeriyorsanız, veritabanı sunucu seviyesinde şifreleme kullanmaya başlar. Bu yaklaşım, 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önüştürmek için faydalı olabilir.

Silinen veritabanını geri yükleme

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

  1. Birincil veritabanı tarafından kullanılan anahtarlar listesini Get-AzSqlDeletedDatabaseBackup parametresiyle -ExpandKeyList çalıştırarak önceden doldurun. Kaynak veritabanının kullandığı tüm anahtarları paylaş. Alternatif olarak, silme sırasında verilen anahtarları kullanarak geri yükleme deneyebilirsiniz.-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 -FromDeletedDatabaseBackup parametresiyle kullanın ve API çağrısında -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (ve gerekirse -FederatedClientId) parametrelerini kullanarak, yukarıdaki adımlardan elde edilen önceden doldurulmuş anahtar listesini ve yukarıdaki kimliği (ve kiracılar arası erişim yapılandırılıyorsa federe istemci kimliğini) 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:

  • Birincil veritabanı tarafından kullanılan anahtarlar listesini, tüm anahtarları almak için Get-AzSqlDatabaseGeoBackup ve -ExpandKeyList kullanarak önceden doldurun.
  • 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.
  • Restore-AzSqlDatabase komutunu -FromGeoBackup parametresiyle kullanın ve API çağrısında -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (ve gerekirse -FederatedClientId) parametrelerini kullanarak, yukarıdaki adımlardan elde edilen önceden doldurulmuş anahtar listesini ve yukarıdaki kimliği (ve kiracılar arası erişim yapılandırılıyorsa federe istemci kimliğini) 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 iletilmesi ö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 fırlatılan hata şudur:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Etkin işlemler eski anahtarlarla şifrelenmiş işlem günlüğünü beklettiğinde, veritabanı düzeyinde TDE Koruyucusu için anahtar rotasyonu 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.
  • t3 zamanı = koruyucunun Thumbprint C olarak değiştirilmesi istendi.
  • Etkin VLF'ler Thumbprint A kullanıyorsa, rotasyona izin verilmez.
  • Etkin VLF'ler Thumbprint A kullanmıyorsa, 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 işlemiyle yeterli işlem günlüğü oluşturulduktan sonra, bu eski VLF temizlenir ve başka bir anahtar rotasyonu gerçekleştirebilmeniz gerekir.

Günlüğünüzün beklenenden daha uzun süre gecikmesine neden olan bir durum olduğunu düşünüyorsanız, ek sorun giderme adımları için aşağıdaki belgelere başvurun:

İlgili içerik

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

  • Son güncelleştirme: