Müşteri tarafından yönetilen anahtarla Azure SQL saydam veri şifrelemesi

Şunlar için geçerlidir:Azure SQL VeritabanıAzure SQL Yönetilen ÖrneğiAzure Synapse Analytics (yalnızca ayrılmış SQL havuzları için)

Azure SQL'de müşteri tarafından yönetilen anahtar (CMK) ile saydam veri şifrelemesi (TDE), bekleyen veri koruması için Kendi Anahtarını Getir (BYOK) senaryosuna olanak tanır ve kuruluşların anahtarların ve verilerin yönetiminde görev ayrımı gerçekleştirmesine olanak tanır. Müşteri tarafından yönetilen TDE senaryosunda müşteri, anahtar yaşam döngüsü yönetiminden (anahtar oluşturma, karşıya yükleme, döndürme, silme), anahtar kullanım izinlerinden ve anahtarlarla ilgili işlemlerin denetiminden sorumlu olur.

Bu senaryoda, Saydam Veri Şifrelemesi (TDE) koruyucusu, Veritabanı Şifreleme Anahtarı (DEK)'i güvence altına alan müşteri tarafından yönetilen bir anahtardır. TDE koruyucusunu Azure Key Vault veya Azure Key Vault Managed HSM'de saklarsınız; bunlar yüksek erişilebilirlik ve ölçeklenebilirlik için tasarlanmış güvenli bulut tabanlı anahtar yönetim hizmetleridir. Her iki hizmet de FIPS 140-2 doğrulu donanım tarafından korunan kriptografik anahtarları destekler: Azure Key Vault FIPS 140-2 Seviye 2'yi destekler ve Azure Key Vault Managed HSM FIPS 140-2 Seviye 3'ü destekler. Her iki hizmet de asimetrik ve simetrik anahtar türlerini destekler ve desteklenen algoritmalar ile kullanım TDE dağıtım modeline bağlıdır. Anahtarı hizmette oluşturabilir, içe aktarabilir veya yerel HSM'lerden güvenli bir şekilde aktarabilirsiniz. Anahtarlara doğrudan erişim kısıtlıdır, bu nedenle yetkili servisler anahtar materyalini açığa çıkarmadan kriptografik işlemler gerçekleştirir.

Azure SQL Veritabanı ve Azure Synapse Analytics için TDE koruyucusu sunucu düzeyinde ayarlanır ve bu sunucuyla ilişkili tüm şifrelenmiş veritabanları tarafından devralınır. Azure SQL Yönetilen Örneği için TDE koruyucusu örnek düzeyinde ayarlanır ve bu örnekteki tüm şifrelenmiş veritabanları tarafından devralınır. Sunucu terimi, farklı belirtilmediği sürece hem SQL Veritabanı'ndaki hem de Azure Synapse'teki bir sunucuya ve bu makale boyunca SQL Yönetilen Örneği'ndeki yönetilen örneğe başvurur.

TDE koruyucusunun Azure SQL Veritabanı veritabanı düzeyinde yönetilmesi kullanılabilir. Daha fazla bilgi için bkz . Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlarla saydam veri şifrelemesi (TDE).

Uyarı

Bu makale, Azure SQL Veritabanı, Azure SQL Yönetilen Örneği ve Azure Synapse Analytics (önceden SQL DW olarak bilinen ayrılmış SQL havuzları) için geçerlidir. Synapse çalışma alanlarındaki ayrılmış SQL havuzları için saydam veri şifrelemesi hakkında daha fazla bilgi için bkz. Azure Synapse Analytics şifrelemesi.

Uyarı

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

Müşteri Yönetimli Anahtar (CMK) ve Kendi Anahtarını Getir (BYOK)

Bu makalede, Müşteri Tarafından Yönetilen Anahtar (CMK) ve Kendi Anahtarını Getir (BYOK) terimleri birbirinin yerine kullanılır, ancak bazı farklılıkları temsil ederler.

  • Müşteri Tarafından Yönetilen Anahtar (CMK) - Müşteri anahtar oluşturma, döndürme ve silme dahil olmak üzere anahtar yaşam döngüsünü yönetir. Anahtar Azure Key Vault'ta veya Azure Yönetilen HSM'de depolanır ve Azure SQL'de Veritabanı Şifreleme Anahtarının (DEK), Azure VM'de SQL Server'ın ve şirket içi SQL Server'ın şifrelenmesini sağlar.

  • Kendi Anahtarını Getir (BYOK) - Müşteri kendi anahtarını bir şirket içi donanım güvenlik modülünden (HSM) Azure Key Vault'a veya Azure Yönetilen HSM'ye güvenli bir şekilde getirir veya içeri aktarır. Bu tür içeri aktarılan anahtarlar, DEK şifrelemesi için Müşteri Tarafından Yönetilen Anahtar da dahil olmak üzere Azure Key Vault'taki diğer anahtarlar olarak kullanılabilir. Daha fazla bilgi için bkz. HSM korumalı anahtarları Yönetilen HSM'ye (BYOK) aktarma.

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

Müşteri tarafından yönetilen TDE müşteriye aşağıdaki avantajları sağlar:

  • TDE koruyucusunun kullanımı ve yönetimi üzerinde tam ve ayrıntılı denetim.

  • TDE koruyucusu kullanımının saydamlığı.

  • Kuruluş içindeki anahtarların ve verilerin yönetiminde görev ayrımını uygulama becerisi.

  • Azure Key Vault yöneticisi, şifrelenmiş veritabanına erişilemez hale getirmek için anahtar erişim izinlerini iptal edebilir.

  • Azure Key Vault'ta anahtarların merkezi yönetimi.

  • Azure Key Vault, Microsoft'un şifreleme anahtarlarını görmemesi veya ayıklayamaması için tasarlandığından, nihai müşterilerinizin güveni artar.

Önemli

Müşteri tarafından yönetilen TDE'yi kullanmaya başlamak isteyen hizmet tarafından yönetilen TDE kullananlar için veriler geçiş işlemi sırasında şifrelenmiş olarak kalır ve veritabanı dosyalarının kapalı kalma süresi veya yeniden şifrelemesi yoktur. Hizmet tarafından yönetilen anahtardan müşteri tarafından yönetilen anahtara geçiş yapmak için yalnızca DEK'in yeniden şifrelenmesi gerekir ve bu da hızlı ve çevrimiçi olarak gerçekleştirilen bir işlemdir.

Müşteri tarafından yönetilen TDE'yi yapılandırma izinleri

Müşteri tarafından yönetilen TDE'nin kurulumunu ve çalışmasını gösteren diyagram.

Kullanmak istediğiniz Azure Key Vault türünü seçin.

Azure'daki mantıksal sunucunun, DEK'in şifrelenmesi için Azure Key Vault'ta depolanan TDE koruyucusunu kullanabilmesi için, Key Vault Yöneticisi'nin sunucuya benzersiz Microsoft Entra kimliğini kullanarak erişim hakkı vermesi gerekir. Sunucu kimliği, sistem tarafından atanan yönetilen kimlik veya sunucuya atanan kullanıcı tarafından atanan yönetilen kimlik olabilir. Anahtar kasasına sunucu erişimi sağlamak için iki erişim modeli vardır.

  • Azure rol tabanlı erişim denetimi (RBAC) - Bir kullanıcıya, gruba veya uygulamaya anahtar kasasına erişim vermek için Azure RBAC kullanın. Bu yöntem, esnekliği ve ayrıntı düzeyi için önerilir. Anahtar Kasası Şifreleme Hizmeti Şifreleme Kullanıcı rolü, şifreleme ve şifre çözme işlemleri için anahtarı kullanabilmek için sunucu kimliği tarafından gereklidir.

  • Kasa erişim ilkesi - Sunucunun anahtar kasasına erişimini sağlamak için bu ilkeyi kullanın. Bu yöntem daha basit ve daha anlaşılır, ancak daha az esnektir. Sunucu kimliğinin anahtar kasası üzerinde aşağıdaki izinlere sahip olması gerekir:

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

Anahtar kasasının Erişim yapılandırması Azure portalı menüsünde Azure rol tabanlı erişim denetimini veya Kasa erişim ilkesini seçme seçeneğiniz vardır. TDE için Azure Key Vault erişim yapılandırmasını ayarlama hakkında adım adım yönergeler için bkz . Azure Key Vault kullanarak SQL Server TDE Genişletilebilir Anahtar Yönetimi'ni ayarlama. Erişim modelleri hakkında daha fazla bilgi için bkz . Azure Key Vault güvenliği.

Key Vault Yöneticisi, anahtar kasası denetim olaylarının günlüğe kaydedilmesini etkinleştirebilir, böylece daha sonra denetlenebilirler.

Bir sunucu Azure Key Vault'tan bir TDE koruyucusu kullanacak şekilde yapılandırıldığında, sunucu şifreleme için TDE özellikli her veritabanının DEK'sini anahtar kasasına gönderir. Anahtar kasası, şifrelenmiş DEK'yi döndürür. Ardından bu DEK, kullanıcı veritabanında depolanır.

Gerektiğinde, sunucu şifre çözme için anahtar kasasına korumalı DEK gönderir.

Denetçiler, günlüğe kaydetme etkinleştirildiyse Key Vault AuditEvent günlüklerini gözden geçirmek için Azure İzleyici'yi kullanabilir.

Uyarı

Tüm izin değişikliklerinin anahtar kasası için geçerli olması yaklaşık 10 dakika sürebilir. Buna AKV'de TDE koruyucusunun erişim izinlerinin iptali dahildir ve bu zaman dilimi içindeki kullanıcıların erişim izinleri hala olabilir.

Müşteri tarafından yönetilen TDE'yi yapılandırma gereksinimleri

  • Geçici silme ve temizleme koruma özellikleri Azure Key Vault'ta etkinleştirilmelidir. Bu, veritabanının Erişilemez duruma geçmesine yol açabilecek, yanlışlıkla veya kötü niyetli şekilde anahtar kasası veya anahtarın silinmesi senaryosunu önlemeye yardımcı olur. Mevcut bir sunucuda veya sunucu oluşturma sırasında TDE koruyucusu yapılandırılırken Azure SQL, kullanılan anahtar kasasının geçici silme ve temizleme korumasının açık olduğunu doğrular. Anahtar kasasında geçici silme ve temizleme koruması etkinleştirilmediyse, TDE koruyucusu kurulumu bir hatayla başarısız olur. Bu durumda, önce anahtar kasasında geçici silme ve temizleme koruması etkinleştirilmelidir ve ardından TDE koruyucusu kurulumu gerçekleştirilmelidir.

  • Azure Key Vault ile güvenlik duvarı kullanırken, Azure Key Vault için özel uç noktalar kullanmıyorsanız Güvenilen Microsoft hizmetlerinin güvenlik duvarını atlamasına izin ver seçeneğini etkinleştirmeniz gerekir. Daha fazla bilgi için bkz . Azure Key Vault güvenlik duvarlarını ve sanal ağları yapılandırma.

TDE koruyucusu yapılandırmaya yönelik temel gereksinimler

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.

Aşağıdaki gereksinimler geçerlidir.

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ı: 2.048-bit ve 3.072-bit
    • Azure SQL Veritabanı, Azure SQL Yönetilen Örneği ve Azure Synapse Analytics için destekleniyor

  • 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
    • Sadece Azure SQL Veritabanı için destekleniyor, şu anda public preview aşamasında

Uyarı

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 anahtar yönetim davranışı

Azure Key Vault Premium (önizleme) veya Azure Key Vault Managed HSM'de saklanan simetrik (AES) anahtarları TDE koruyucusu olarak kullanabilirsiniz. Şirket içi bir donanım güvenlik modülündeki (HSM) bir anahtarı kullanmaya başlamak için, anahtarı iki hizmetten birine içe aktarın. İlk içe aktarmadan sonra, tüm devam eden anahtar yaşam döngüsü işlemleri Azure Key Vault Premium (önizleme) veya Azure Key Vault Managed HSM'de gerçekleşir. Belirli bir zamandaki duruma kurtarma, coğrafi felaket kurtarma ve anahtarın yeniden doğrulanması, anahtarın orada kullanılabilir olmaya devam etmesine bağlıdır. Kurtarma ve yeniden doğrulama senaryolarını desteklemek için ithal anahtarların yerel yedeklemelerini sürdürün. Bu davranış yalnızca simetrik (AES) anahtarlar için geçerlidir, asimetrik (RSA) anahtarlar için değil.

Ö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'a aktarırsanız, anahtarı aşağıdaki desteklenen formatlardan birinde verin:

  • .pfx
  • .byok
  • .backup

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

Uyarı

v2.8.0'dan önceki Thales CipherTrust Manager sürümleriyle ilgili bir sorun, Azure Key Vault'a yeni aktarılan anahtarların müşteri tarafından yönetilen TDE senaryoları için Azure SQL Veritabanı veya Azure SQL Yönetilen Örneği ile kullanılmasını engeller. Bu sorun hakkında daha fazla ayrıntı için bkz. CipherTrust Cloud Key Manager sürüm notları. Bu gibi durumlarda, anahtarı Azure Key Vault'a aktardıktan sonra 24 saat bekleyin ve bunu sunucu veya yönetilen örnek için TDE koruyucusu olarak kullanmaya başlayın. Bu sorun Thales CipherTrust Manager v2.8.0'da giderilmiştir.

Müşteri tarafından yönetilen TDE'yi yapılandırma önerileri

  • Optimum performans ve güvenilirlik sağlamak için, Azure SQL için özel bir Azure Key Vault kullanın. Bu anahtar kasayı diğer servislerle paylaşmayın. Anahtar kasası paylaşılan kullanım veya aşırı anahtar işlemleri nedeniyle ağır yük altındaysa, özellikle şifreleme anahtar erişimi sırasında veritabanı performansını olumsuz etkileyebilir. Azure Key Vault kısıtlama sınırlarını zorlar. Bu sınırlar aşıldığında işlemler gecikebilir veya başarısız olabilir. Bu risk, sunucu yük devretmeleri sırasında en yüksektir; bu durum, sunucudaki her veritabanı için kritik işlemleri tetikler.

    Azaltma davranışı hakkında daha fazla bilgi için bkz. Azure Key Vault azaltma kılavuzu.

    Yüksek erişilebilirlik sağlamak ve kısıtlama sorunlarını önlemek için her bir abonelik için şu yönergeleri izleyin:

    • Azure SQL kaynakları için ayrılmış bir Azure Key Vault kullanın.

    • En fazla 500 Genel Amaçlı veritabanını tek bir Azure Key Vault ile ilişkilendirin.

    • En fazla 200 İş Açısından Kritik veritabanını tek bir Azure Key Vault ile ilişkilendirin.

    • Tek bir Azure Key Vault ile ilişkilendirilebilen Hiper Ölçek veritabanı sayısı, sayfa sunucusu sayısına göre belirlenir. Her sayfa sunucusu bir mantıksal veri dosyasına bağlanır. Sayfa sunucularının sayısını bulmak için aşağıdaki sorguyu yürütür.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Tek bir Azure Key Vault'a 500'den fazla sayfa sunucusu ilişkilendirmeyin. Veritabanı büyüdükçe sayfa sunucusu sayısı otomatik olarak artar, bu nedenle veritabanı boyutunu düzenli olarak izlemek önemlidir. Sayfa sunucu sayısı 500'ü aşarsa, her Hyperscale veritabanı için özel bir Azure Key Vault kullanın ve bu anahtar kasayı diğer Azure SQL kaynaklarıyla paylaşmayın.

    • Azure Key Vault uyarılarınıizleyin ve yapılandırın. İzleme ve uyarı alma hakkında daha fazla bilgi için bkz. Azure Key Vault'u izleme ve Azure Key Vault uyarılarını yapılandırma.

  • Uzun vadeli kriptografik dayanıklılık planlamasıyla uyumlu olmak için, TDE koruyucu olarak AES-256 simetrik anahtarlar kullanmayı düşünün.

    Büyük ölçekli kuantum hesaplamaların, RSA gibi açık anahtarlı kriptografik algoritmaları kırması beklenmektedir. AES dahil simetrik kriptografi, yeterince büyük anahtar boyutlarında kuantum dayanıklı kabul edilir.

    Microsoft'un daha geniş kuantum güvenli güvenlik stratejisi kripto-çevikliğe vurgu yapıyor. Daha güçlü simetrik algoritmaları desteklendiklerinde benimseyin ve rehberlik ile standartlar geliştikçe gelecekteki kriptografik geçişleri planlayın.

    Önemli

    Simetrik anahtarlarla (AES) Saydam Veri Şifrelemesi şu anda yalnızca Azure SQL Veritabanı için desteklenmektedir ve genel önizleme aşamasındadır.

  • Bu kritik kaynağı kimlerin silebileceğini denetlemek ve yanlışlıkla veya yetkisiz silme işlemlerini önlemek için anahtar kasasında bir kaynak kilidi ayarlayın. Kaynak kilitleri hakkında daha fazla bilgi edinin.

  • Tüm şifreleme anahtarlarında denetimi ve raporlamayı etkinleştirin: Azure Key Vault, diğer güvenlik bilgilerine ve olay yönetimi araçlarına kolayca eklenmesi kolay günlükler sağlar. Operations Management Suite Log Analytics , zaten tümleştirilmiş bir hizmet örneğidir.

  • Maksimum kullanılabilirlik için, bir Azure bölgesinden, içeriğini eşleştirilmiş bir bölgeye çoğaltabilen bir anahtar kasası kullanın. Daha fazla bilgi için bkz. Azure Key Vault kullanmaya yönelik en iyi yöntemler ve Azure Key Vault kullanılabilirliği ve yedekliliği.

Uyarı

Müşteri tarafından yönetilen TDE'yi yapılandırma konusunda daha fazla esneklik sağlamak için Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği artık başka bir bölgedeki Azure Key Vault'a bağlanabilir. Sunucu ve anahtar kasasının aynı bölgede birlikte bulunması gerekmez.

TDE koruyucusu yapılandırma önerileri

  • TDE koruyucusunun bir kopyasını güvenli bir yerde tutun veya emanet hizmetine emanet edin.

  • Anahtar kasasında oluşturulduysa, anahtarı Azure Key Vault'ta ilk kez kullanmadan önce bir anahtar yedeklemesi oluşturun. Yedekleme yalnızca Azure Key Vault'a geri yüklenebilir. Backup-AzKeyVaultKey komutu hakkında daha fazla bilgi edinin. Azure Yönetilen HSM, tüm anahtarlar, sürümler, öznitelikler, etiketler ve rol atamaları dahil olmak üzere HSM'nin tüm içeriğinin tam yedeğini oluşturmayı destekler. Daha fazla bilgi için bkz . Tam yedekleme ve geri yükleme ve seçmeli anahtar geri yükleme.

  • Anahtarda her değişiklik yapıldığında yeni bir yedekleme oluşturun (örneğin, anahtar öznitelikleri, etiketler, ACL'ler).

  • Anahtarları döndürürken anahtarın önceki sürümlerini anahtar kasasında veya Yönetilen HSM'de tutun, böylece eski veritabanı yedeklemelerini geri kazanabilirsiniz. Bir veritabanı için TDE koruyucusu değiştiğinde, veritabanının eski yedeklemeleri en son TDE koruyucusunu kullanmak üzere güncellenmez . Geri yükleme anında, her yedeklemenin, oluşturulduğu sırada şifrelendiği TDE koruyucusuna sahip olması gerekir. Anahtarları döndürmek için, Şeffaf veri şifreleme (TDE) koruyucusunu döndür makalesindeki talimatları takip edin.

  • Hizmet tarafından yönetilen anahtarlara geçtikten sonra bile Azure Key Vault veya Azure Yönetilen HSM'de daha önce kullanılan tüm anahtarları saklayın. Veritabanı yedeklemelerinin Azure Key Vault veya Azure Yönetilen HSM'de depolanan TDE koruyucularıyla geri yüklenebilmesini sağlar. Azure Key Vault veya Azure Yönetilen HSM ile oluşturulan TDE koruyucularının, kalan tüm depolanan yedeklemeler hizmet tarafından yönetilen anahtarlarla oluşturulana kadar korunması gerekir. Backup-AzKeyVaultKey kullanarak bu anahtarların kurtarılabilir yedek kopyalarını alın.

  • Veri kaybı riski olmadan güvenlik olayı sırasında güvenliği aşılmış olabilecek bir anahtarı kaldırmak için , PowerShell kullanarak Saydam Veri Şifrelemesi (TDE) koruyucusu kaldırma makalesindeki adımları izleyin. Her zaman yeni bir TDE koruyucusuna geçin ve tüm veritabanlarının yeni anahtarı kullandığını doğrulayın; ardından, sızdırılmış anahtarı silmeden veya devre dışı bırakmadan önce bunu yapmalısınız. Anahtarı önce döndürmeden silmek veya devre dışı bırakmak tüm şifrelenmiş veritabanlarının erişilmez hale gelmesine neden olur ve daha önce yedeklenip başka bir kasaya geri getirilen anahtar kopyalarını geçersiz kılmaz.

Tavsiye

TDE için sürümlenmiş ve sürümsüz Azure Key Vault anahtarlarını kullanma

TDE koruyucusu ayarladığınızda, belirli bir anahtar sürümünü veya sürümsüz anahtar tanımlayıcısını kullanarak Azure Key Vault anahtarına başvurabilirsiniz.

Her iki durumda da Azure SQL Veritabanı her zaman Azure Key Vault veya Azure Key Vault Yönetilen HSM'de anahtarın en son etkin sürümünü çözümler ve kullanır. TDE koruyucu yapılandırmasına belirli bir anahtar sürümünü eklemekten kaçınmak için sürümsüz anahtar tanımlayıcılarını kullanın.

Sürümsüz anahtar tanımlayıcıları şu anda yalnızca Azure SQL Veritabanı için desteklenmektedir.

Examples:

  • Belirli bir sürümü içeren anahtar tanımlayıcısı

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Sürümsüz anahtar tanımlayıcısı

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

TDE koruyucunun döndürülmesi

TDE koruyucusu döndürülürken, veritabanı şifreleme anahtarını (DEK) korumak için kullanılan anahtarı değiştirmenize olanak tanı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

Uyarı

Simetrik anahtarlarla (AES) Saydam Veri Şifrelemesi şu anda yalnızca Azure SQL Veritabanı için desteklenmektedir ve genel önizleme aşamasındadır.

TDE koruyucusunun döndürme işlemi el ile veya otomatik döndürme özelliği kullanılarak yapılabilir.

Sunucu için TDE koruyucusu yapılandırıldığında TDE koruyucusunun otomatik döndürmesi etkinleştirilebilir. Otomatik döndürme varsayılan olarak devre dışıdır. Etkinleştirildiğinde, sunucu TDE koruyucusu olarak kullanılan anahtarın yeni sürümleri için anahtar kasasını veya Yönetilen HSM'yi sürekli denetler. Anahtarın yeni bir sürümü algılanırsa, sunucu veya veritabanındaki TDE koruyucusu 24 saat içinde otomatik olarak en son anahtar sürümüne döndürülür.

Azure Key Vault'ta otomatik anahtar döndürme veya Azure Yönetilen HSM'de otomatik döndürme ile kullanıldığında, bu özellik Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nde TDE koruyucusu için uçtan uca sıfır dokunma döndürmeyi etkinleştirir.

Uyarı

Anahtarların el ile veya otomatik olarak döndürülerek CMK ile TDE ayarlanması her zaman desteklenen anahtarın en son sürümünü kullanır. Kurulum, anahtarların önceki veya daha düşük bir sürümünün kullanılmasına izin vermez. Her zaman en son anahtar sürümünü kullanmak, güvenliği aşılmış olabilecek önceki anahtar sürümlerine izin vermeyen Azure SQL güvenlik ilkesiyle uyumlu olur. Anahtarın önceki sürümleri, özellikle eski anahtar sürümlerinin korunması gereken uzun süreli saklama yedeklemeleri için veritabanı yedekleme veya geri yükleme amacıyla gerekli olabilir. Coğrafi çoğaltma kurulumları için, kaynak sunucu tarafından gereken tüm anahtarların hedef sunucuda mevcut olması gerekir.

TDE koruyucusunun otomatik döndürmesini yapılandırırken coğrafi çoğaltmayla ilgili dikkat edilmesi gereken hususlar

Coğrafi çoğaltmayı oluştururken veya sırasında oluşan sorunları önlemek için, birincil veya ikincil sunucuda TDE koruyucusunun otomatik döndürmesi etkinleştirildiğinde, coğrafi çoğaltmayı yapılandırırken şu kurallara uymak önemlidir:

  • Hem birincil hem de ikincil sunucuların birincil sunucunun anahtar kasasına (birincil sunucunun TDE koruyucu anahtarını barındıran anahtar kasası) Get, wrapKey ve unwrapKey izinlerine sahip olması gerekir.

  • Otomatik anahtar döndürmesi etkinleştirilmiş bir sunucu için, coğrafi çoğaltmayı başlatmadan önce birincil sunucuda TDE koruyucusu olarak kullanılan şifreleme anahtarını ikincil sunucuya ekleyin. İkincil sunucu, birincil sunucuyla kullanılan aynı anahtar kasasındaki veya yönetilen HSM'deki anahtara erişim gerektirir (ve aynı anahtar malzemesine sahip başka bir anahtar değil). Alternatif olarak, coğrafi çoğaltmayı başlatmadan önce, ikincil sunucunun yönetilen kimliğinin (kullanıcı tarafından atanan veya sistem tarafından atanan) birincil sunucunun anahtar kasası veya yönetilen HSM üzerinde gerekli izinlere sahip olduğundan ve sistemin anahtarı ikincil sunucuya eklemeye çalıştığından emin olun.

  • Mevcut bir coğrafi çoğaltma kurulumu için, birincil sunucuda otomatik anahtar döndürmeyi etkinleştirmeden önce birincil sunucuda TDE koruyucusu olarak kullanılan şifreleme anahtarını ikincil sunucuya ekleyin. İkincil sunucu, birincil sunucuyla kullanılan aynı anahtar kasasındaki veya yönetilen HSM'deki anahtara erişim gerektirir (ve aynı anahtar malzemesine sahip başka bir anahtar değil). Alternatif olarak, otomatik anahtarı etkinleştirmeden önce ikincil sunucunun yönetilen kimliğinin (kullanıcı tarafından atanan veya sistem tarafından atanan) birincil sunucunun anahtar kasası üzerinde gerekli izinlere sahip olduğundan ve sistemin anahtarı ikincil sunucuya eklemeye çalıştığından emin olun.

  • TDE için müşteri tarafından yönetilen anahtarlar (CMK) kullanılarak geo-replikasyon senaryoları desteklenmektedir. Azure portalında TDE yapılandırıyorsanız, otomatik anahtar döndürmeli TDE tüm sunucularda yapılandırılmalıdır. TDE ile coğrafi çoğaltma yapılandırmaları için otomatik anahtar döndürmeyi ayarlama hakkında daha fazla bilgi için bkz . Coğrafi çoğaltma yapılandırmaları için otomatik anahtar döndürme.

Erişilemeyen TDE koruyucusu

TDE müşteri tarafından yönetilen bir anahtarı kullanacak şekilde yapılandırıldığında, veritabanının çevrimiçi olarak kalması için gereken TDE koruyucusuna sürekli erişim gerekir. Sunucu Azure Key Vault veya Azure Yönetilen HSM'de müşteri tarafından yönetilen TDE koruyucusunun erişimini kaybederse, veritabanı 10 dakikaya kadar ilgili hata iletisiyle tüm bağlantıları reddetmeye başlar ve durumunu Erişilemez olarak değiştirir. Erişilemez durumdaki bir veritabanında izin verilen tek eylem, veritabanını silmektir.

Erişilemez durum

Aralıklı ağ kesintisi (5XX hatası gibi) nedeniyle veritabanına erişilemiyorsa, veritabanları otomatik olarak yeniden çevrimiçi olduğundan hiçbir eylem gerekmez. Azure Key Vault veya Azure Yönetilen HSM'de TDE koruyucusunun erişimi sırasında ağ hatalarının veya kesintilerinin etkisini azaltmak için, hizmet veritabanını erişilemez duruma taşımaya çalışmadan önce 24 saatlik bir arabelleğe geçilir. Erişilemez duruma ulaşmadan önce bir yük devretme gerçekleşirse, şifreleme önbelleğinin kaybolması nedeniyle veritabanı kullanılamaz duruma gelir.

Herhangi bir Azure Key Vault hatası (4XX hatası gibi) nedeniyle sunucu Azure Key Vault veya Azure Yönetilen HSM'de müşteri tarafından yönetilen TDE koruyucusunun erişimini kaybederse, veritabanı 30 dakika sonra erişilemez duruma taşınır.

Azure Key Vault veya Azure Yönetilen HSM hatasının ardından veritabanı erişimini geri yükleme

Anahtara erişim geri yüklendikten sonra veritabanını yeniden çevrimiçi duruma getirmek için ek süre ve adımlar gerekir. Bu süre, anahtarın kullanılamama süresine ve veritabanındaki verilerin boyutuna bağlı olarak değişebilir.

Anahtar erişimi 30 dakika içinde geri yüklenirse veritabanı sonraki bir saat içinde otomatik olarak iyileşir. Ancak, anahtar erişimi 30 dakikadan uzun bir süre sonra geri yüklenirse veritabanının otomatik olarak onarılmış olması mümkün değildir. Bu gibi durumlarda veritabanının geri yüklenmesi, Azure portalı aracılığıyla ek yordamlar içerir ve veritabanının boyutuna bağlı olarak zaman alabilir.

Veritabanı yeniden çevrimiçi olduktan sonra yük devretme grubu yapılandırmaları, etiketler ve elastik havuz yapılandırmaları, okuma ölçeği, otomatik duraklatma, belirli bir noktaya geri yükleme geçmişi, uzun süreli saklama ilkesi ve diğerleri gibi veritabanı düzeyinde ayarlar da dahil olmak üzere önceden yapılandırılmış sunucu düzeyinde ayarlar kaybolur. Bu nedenle, müşterilerin 30 dakika içinde şifreleme anahtarı erişimi kaybını algılamak için bir bildirim sistemi uygulaması önerilir. 30 dakikalık süre dolduktan sonra kurtarılan veritabanındaki tüm sunucu ve veritabanı düzeyi ayarlarını doğrulamayı öneririz.

Aşağıda, erişilemeyen bir veritabanını yeniden çevrimiçi hale getirmek için portalda gereken ek adımların bir görünümü yer alır.

TDE BYOK erişilemez veritabanının ekran görüntüsü.

Yanlışlıkla TDE koruyucu erişimi iptal etme işlemi

Anahtar kasasına veya yönetilen HSM'ye yeterli erişim haklarına sahip birinin anahtara sunucu erişimini yanlışlıkla devre dışı bırakması mümkündür:

  • anahtar kasasının veya yönetilen HSM'nin get, wrapKey, unwrapKey izinlerini sunucudan iptal etme

  • anahtarı silme

  • anahtar kasası veya yönetilen HSM'yi silme

  • anahtar kasasının veya yönetilen HSM güvenlik duvarı kurallarını değiştirme

  • Microsoft Entra ID'de sunucunun yönetilen kimliğini silme

Veritabanının erişilemez duruma gelmesinin yaygın nedenleri hakkında daha fazla bilgi edinin.

SQL Yönetilen Örneği ile Azure Key Vault veya Azure Yönetilen HSM arasında engellenen bağlantı

SQL Yönetilen Örneği ile anahtar kasası veya yönetilen HSM arasındaki ağ bağlantı bloğu çoğunlukla anahtar kasası veya yönetilen HSM kaynağı mevcut olduğunda gerçekleşir, ancak uç noktasına yönetilen örnekten ulaşılamaz. Anahtar kasasına veya yönetilen HSM uç noktasına ulaşılabildiği ancak bağlantının reddedildiği, eksik izinlerin vb. bulunduğu tüm senaryolar veritabanlarının durumlarını Erişilemez olarak değiştirmesine neden olur.

Azure Key Vault veya Azure Yönetilen HSM'ye ağ bağlantısı olmamasının en yaygın nedenleri şunlardır:

  • Azure Key Vault veya Azure Yönetilen HSM özel uç nokta aracılığıyla kullanıma sunulur ve yönetilen örnek alt ağıyla ilişkili Ağ Güvenlik Grubu'nun (NSG) giden kurallarında Azure Key Vault veya Azure Yönetilen HSM hizmetinin özel IP adresine izin verilmez.

  • Anahtar kasası veya yönetilen HSM FQDN'sinin çözümlenmemiş olması veya geçersiz bir IP adresine çözümlenmesi gibi hatalı DNS çözümlemesi.

SQL Yönetilen Örneği'nden Azure Key Vault'a veya TDE koruyucusunu barındıran Azure Yönetilen HSM'ye bağlantıyı test edin.

  • Uç nokta, <vault_name>.vault.azure.net (https:// olmaksızın) gibi bir kasanın FQDN'si olacaktır.
  • Test edilecek bağlantı noktası 443'tür.
  • RemoteAddress için sonuç mevcut ve IP adresi doğru olmalıdır
  • TCP testi için sonuç TcpTestSucceeded : True olmalıdır.

Testin sonucu TcpTestSucceeded: False olarak dönerse ağ yapılandırmasını gözden geçirin:

  • Çözümlenen IP adresini kontrol edin, geçerli olduğundan emin olun. Eksik bir değer, DNS çözümlemesiyle ilgili sorunlar olduğu anlamına gelir.

    • Yönetilen örnekteki ağ güvenlik grubunun, özellikle çözümlenen adres anahtar kasasının veya yönetilen HSM özel uç noktasına ait olduğunda, 443 numaralı bağlantı noktasında çözümlenen IP adresini kapsayan bir giden kuralı olduğunu onaylayın.

    • Yönlendirme tablosu, sanal gerecin varlığı ve yapılandırması gibi diğer ağ yapılandırmalarını denetleyin.

Müşteri tarafından yönetilen TDE'yi izleme

Veritabanı durumunu izlemek ve TDE koruyucusu erişimi kaybıyla ilgili uyarıyı etkinleştirmek için aşağıdaki Azure özelliklerini yapılandırın:

  • Azure Kaynak Sağlığı. TDE koruyucusunun erişimini kaybeden erişilemez bir veritabanı, veritabanına ilk bağlantı reddedildikten sonra "Kullanılamıyor" olarak gösterilir.

  • Etkinlik Günlüğü, müşteri tarafından yönetilen anahtar kasasındaki TDE koruyucusuna erişim başarısız olduğunda kayıtlar etkinlik günlüğüne eklenir. Bu olaylar için uyarılar oluşturmak, erişimi en kısa sürede yeniden devreye almanızı sağlar.

  • Eylem Grupları , e-posta/SMS/Anında İletme/Ses, Mantıksal Uygulama, Web Kancası, ITSM veya Otomasyon Runbook'u gibi tercihlerinize göre size bildirim ve uyarı göndermek için tanımlanabilir.

Müşteri yönetimli TDE ile backup ve restore veritabanları

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 .

Azure Key Vault veya Azure Yönetilen HSM'den TDE koruyucusu ile şifrelenmiş bir yedeklemeyi geri yüklemek için anahtar malzemesinin hedef sunucuda kullanılabilir olduğundan emin olun. Bu nedenle, veritabanı yedeklerinin 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

Bir sunucu için herhangi bir anda birden fazla TDE koruyucusu ayarlanamaz. Azure portalı bölmesinde varsayılan TDE koruyucusu yap ile işaretlemiş olan anahtar, TDE koruyucusudur. Ancak, birden çok anahtar, TDE koruyucusu olarak tanımlanmadan bir sunucuya bağlanabilir. 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.

Yedeklemeyi geri yüklemek için gereken anahtar artık hedef sunucuda kullanılamıyorsa, geri yükleme denemesinde şu hata iletisi döndürülür: "Hedef sunucunun <Servername> Zaman Damgası #1< ile >Zaman Damgası #2< arasında >oluşturulan tüm AKV URI'lerine erişimi yok. Tüm AKV URI'lerini geri yükledikten sonra işlemi yeniden deneyin."

Bunu azaltmak için, hedef sunucu için Get-AzSqlServerKeyVaultKey cmdlet'ini veya hedef yönetilen örneğin kullanılabilir anahtarların listesini döndürmek ve eksik anahtarları tanımlamak için Get-AzSqlInstanceKeyVaultKey cmdlet'ini çalıştırın. Tüm yedeklemelerin geri yüklenebilmesini sağlamak için, geri yükleme için hedef sunucunun gereken tüm anahtarlara erişimi olduğundan emin olun. Bu anahtarların TDE koruyucusu olarak işaretlenmesi gerekmez.

SQL Veritabanı için yedekleme kurtarma hakkında daha fazla bilgi edinmek için bkz. Azure SQL Veritabanı'nda bir veritabanını yedekten geri yükleme. Azure Synapse Analytics'te ayrılmış SQL havuzları için yedekleme kurtarma hakkında daha fazla bilgi edinmek için bkz . Ayrılmış SQL havuzunu kurtarma. SQL Server'ın SQL Yönetilen Örneği ile yerel yedekleme/geri yükleme işlemi için bkz . Hızlı Başlangıç: SSMS ile Azure SQL Yönetilen Örneği'ne veritabanı geri yükleme.

Günlük dosyaları için dikkat edilmesi gereken bir diğer nokta: Yedeklenen günlük dosyaları, döndürülmüş olsa ve veritabanı artık yeni bir TDE koruyucusu kullanıyor olsa bile özgün TDE koruyucusuyla şifrelenmiş olarak kalır. Geri yükleme zamanında veritabanını geri yüklemek için her iki anahtar da gerekir. Günlük dosyası Azure Key Vault veya Azure Yönetilen HSM'de depolanan bir TDE koruyucusu kullanıyorsa, bu sırada veritabanı hizmet tarafından yönetilen TDE kullanacak şekilde değiştirilse bile geri yükleme zamanında bu anahtar gereklidir.

Müşteri tarafından yönetilen TDE ile yüksek kullanılabilirlik

Azure Key Vault veya Azure Yönetilen HSM'nin birden çok yedeklilik katmanı sağlamasıyla, müşteri tarafından yönetilen anahtar kullanan TDE'ler Azure Key Vault veya Azure Yönetilen HSM kullanılabilirliği ve dayanıklılığından yararlanabilir ve Azure Key Vault veya Azure Yönetilen HSM yedeklilik çözümünden tam olarak yararlanabilir.

Azure Key Vault birden çok yedeklilik katmanı, tek tek hizmet bileşenleri başarısız olsa veya Azure bölgeleri veya kullanılabilirlik alanları çalışmıyor olsa bile anahtar erişimi sağlar. Daha fazla bilgi için bkz . Azure Key Vault kullanılabilirliği ve yedekliliği.

Azure Key Vault, kullanıcı müdahalesi olmadan otomatik olarak sağlanan aşağıdaki kullanılabilirlik ve dayanıklılık bileşenlerini sunar:

Uyarı

Tüm çift bölgeler için Azure Key Vault anahtarları her iki bölgeye de çoğaltılır ve her iki bölgede de bu anahtarlar üzerinde çalışabilen Donanım Güvenlik Modülleri (HSM) vardır. Daha fazla bilgi için bkz . Veri çoğaltma. Bu, hem Standart hem de Premium Azure Key Vault hizmet katmanları ve yazılım veya donanım anahtarları için geçerlidir.

Azure Yönetilen HSM çok bölgeli çoğaltma, Azure Yönetilen HSM havuzunu bir Azure bölgesinden (birincil bölge olarak adlandırılır) başka bir Azure bölgesine (genişletilmiş bölge olarak adlandırılır) genişletmenize olanak tanır. Yapılandırıldıktan sonra her iki bölge de etkin olur, isteklere hizmet eder ve otomatik çoğaltma ile aynı anahtar malzemeyi, rolleri ve izinleri paylaşır. Daha fazla bilgi için bkz. Azure Yönetilen HSM'de çok bölgeli çoğaltmayı etkinleştirme.

Müşteri tarafından yönetilen TDE ile coğrafi felaket kurtarma

Aktif coğrafi çoğaltma ve failover grupları müşteri tarafından yönetilen TDE'yi destekler. Birincil ve ikincil sunucular, desteklenen herhangi bir bölgede Azure Key Vault veya Azure Managed HSM kullanabilir. Sunucular ve anahtar mağazasının aynı bölgede olması gerekmiyor.

Başarılı bir failover için, her iki sunucunun da gerekli anahtarı içeren her Azure Key Vault veya Azure Managed HSM'ye erişimi olmalıdır.

Yapılandırmayla ilgili dikkat edilmesi gerekenler

Azure portalında aktif jeo-replikasyon veya bir yedek grup yapılandırırken aşağıdaki hususlar geçerlidir:

  • TDE koruyucu konumu: Birincil ve ikincil sunucular aynı Azure Key Vault veya Azure Managed HSM'yi kullanabilir. Aynı anahtar deposunu kullanmak, anahtar materyalinin senkronizasyonun bozulma riskini azaltır. Ayrı anahtar kasalarını birden fazla bölgede kullanıyorsanız, gerekli anahtar materyali senkronize tutmalısınız. Anahtar deposu dayanıklılığı hakkında bilgi için bkz. Azure Key Vault erişilebilirlik ve yedeklik ile Yönetilen HSM'de Multi-region replikasyonu.

  • Bölge yedekliği: Mevcut olduğunda, Azure SQL Veritabanı veya Azure SQL Yönetilen Örneği için bölge yedekliliği bir bölge içinde ekstra dayanıklılık sağlar. Daha fazla bilgi için bkz. Azure kullanılabilirlik alanları nelerdir?.

  • Anahtar izinleri: Hem birincil hem de ikincil sunucular, gerekli bir TDE koruyucusu içeren her Azure Key Vault veya Azure Managed HSM için gerekli izinlere sahip olmalıdır.

  • Anahtar erişilebilirliği: Gerekli anahtarların hem birincil hem de ikincil sunucularda mevcut olduğundan emin olun. Sunucuların aynı TDE koruyucularını kullanması gerekmez, ancak her sunucu aynı anahtar malzemeye sahip olmalıdır. Azure portalı, PowerShell, Azure CLI veya Azure SQL REST API'si kullanarak sunucuya anahtar ekleyebilirsiniz. Gerekli anahtarlar failover sırasında mevcut değilse, veritabanı erişilmez hale gelebilir.

  • Özel uç noktalar: Azure SQL'de özel uç noktaları kullanıyorsanız, yapılandırma daha karmaşık bir DNS bölgesi gerektirebilir (örneğin, aynı DNS bölgesinde aynı kaynağa iki özel uç noktası oluşturamaz).

  • Uygulama bağlantısı: Uygulamalar, geçici hataları devre sırasında yönetmek için yeniden deneme mantığı kullanmalıdır.

Azure SQL coğrafi felaket kurtarma kaynağının yapılandırılması hakkında bilgi için Aktif jeo-replikasyon veya Failover grupları genel bakış ve en iyi uygulamalara bakınız.

Önemli

Bir coğrafi replikasyon bağlantısı veya geçici bir grup oluşturduğunuzda, Azure SQL her iki sunucunun da gerekli müşteri tarafından yönetilen anahtarlara erişebileceğini doğrular. Herhangi bir sunucu gerekli anahtara erişemezse, oluşturma işlemi başarısız olur. Örneğin, birincil ve ikincil sunucular sırasıyla Anahtar A ve Anahtar B'yi kullanıyorsa, her iki sunucuya da her iki anahtarı ekleyin, ardından coğrafi replikasyon bağlantısı veya failover grubu oluşturulur.

Aşağıdaki diyagram, bir failover grubu ile Azure SQL coğrafi çoğaltmasını ve eşleştirilmiş bölge yapılandırmasında Azure Key Vault için bölgeler arası yük devretmeyi gösterir:

Azure Key Vault'un eşleştirilmiş bir bölge için bölgeler arası yük devretme desteğini gösteren Diagram.

Azure Key Vault failover sırasında davranış

  • Azure Key Vault failover'ı başlatıyor, siz değil.
  • Ana bölgedeki anahtar kasası mevcut olmasa da, anahtar kasası yalnızca okunabilir.
  • Anahtarları yalnızca birincil bölgedeki anahtar kasası kullanılabilir durumdayken oluşturabilir, içe aktarabilir ve yenileyebilirsiniz. Bir failover sonrasında anahtar rotasyonu, birincil bölgeye yeniden erişilebilene kadar engelli kalır.
  • Anahtar kasasının şu anda hangi bölgede bulunduğunu seçemez veya denetleyemezsiniz ve ikincil bölgeye el ile bağlanamazsınız.

Erişilemeyen bir TDE koruyucusundan kurtul

Aktif bir coğrafi replikasyon ilişkisi veya failover grubundaki bir veritabanı erişilemez hale gelirse, Azure SQL kontrol düzlemi bağlantıyı koparır ve veritabanını bağımsız bir veritabanına dönüştürür.

Anahtar izinlerini geri kazandıktan sonra, genellikle birincil veritabanını tekrar çevrimiçi hale getirebilirsiniz. İkincil veritabanını tekrar çevrimiçi hale getiremezsiniz çünkü Azure SQL ikincil veritabanlarının tam yedeklemesini almıyor. İkincil veritabanını bırakın ve ardından coğrafi replikasyon bağlantısını veya failover grubunu yeniden kurun.

Müşteri tarafından yönetilen TDE için Azure İlkesi

Azure İlkesi, bir Azure SQL Veritabanı sunucusu veya Azure SQL Yönetilen Örneği oluşturma veya güncelleştirme sırasında müşteri tarafından yönetilen TDE'yi zorlamak için kullanılabilir. Bu ilke uygulandığında, Azure'da veya yönetilen örnekte mantıksal sunucu oluşturma veya güncelleştirme girişimleri, müşteri tarafından yönetilen bir anahtarla yapılandırılmadıysa başarısız olur. Azure İlkesi tüm Azure aboneliğine veya yalnızca bir kaynak grubu içinde uygulanabilir.

Azure İlkesi hakkında daha fazla bilgi için bkz. Azure İlkesi nedir ve Azure İlkesi tanım yapısı.

Aşağıdaki iki yerleşik ilke, Azure İlkesi'de müşteri tarafından yönetilen TDE için desteklenir:

  • SQL sunucuları bekleyen verileri şifrelemek için müşteri tarafından yönetilen anahtarları kullanmalıdır
  • Yönetilen örnekler durağan verileri şifrelemek için müşteri tarafından yönetilen anahtarları kullanmalıdır.

Müşteri tarafından yönetilen TDE ilkesi, Azure portalına gidip İlke hizmeti aranarak yönetilebilir. Tanımlar'ın altında müşteri tarafından yönetilen anahtarı arayın.

Bu ilkelerin üç etkisi vardır:

  • Denetim - Varsayılan ayardır ve yalnızca Azure İlkesi etkinlik günlüklerinde bir denetim raporu yakalar

  • Reddet - Müşteri tarafından yönetilen anahtar yapılandırılmadan mantıksal sunucu veya yönetilen örnek oluşturulmasını veya güncelleştirilmesini engeller

  • Devre dışı - İlkeyi devre dışı bırakır ve kullanıcıların müşteri tarafından yönetilen TDE etkinleştirilmeden mantıksal sunucu veya yönetilen örnek oluşturmasını veya güncelleştirmesini kısıtlamaz

Müşteri tarafından yönetilen TDE için Azure İlkesi Reddet olarak ayarlanırsa, Azure SQL mantıksal sunucusu veya yönetilen örnek oluşturma başarısız olur. Bu hatanın ayrıntıları kaynak grubunun Etkinlik günlüğüne kaydedilir.

Önemli

Müşteri tarafından yönetilen TDE için AuditIfNotExists etkisini içeren yerleşik kuralların önceki sürümleri kullanımdan kaldırılmıştır. Kullanım dışı bırakılan ilkeleri kullanan mevcut ilke atamaları etkilenmez ve önceki gibi çalışmaya devam eder.

İlgili içerik

  • Last updated on