Aracılığıyla paylaş

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, Veritabanı Şifreleme Anahtarının (DEK) güvenliğini sağlamak için kullanılan müşteri tarafından yönetilen asimetrik anahtar olan Saydam Veri Şifrelemesi (TDE) koruyucusu , Azure Key Vault veya Azure Key Vault Yönetilen HSM'de depolanır. Bunlar, yüksek kullanılabilirlik ve ölçeklenebilirlik için tasarlanmış güvenli, bulut tabanlı anahtar yönetim hizmetleridir. Azure Key Vault RSA anahtarlarını destekler ve FIPS 140-2 Düzey 2 doğrulanmış HSM'ler tarafından desteklenebilir. Daha yüksek güvence gerektiren müşteriler için Azure Key Vault Yönetilen HSM, FIPS 140-2 Düzey 3 doğrulanmış donanım sunar. Anahtar hizmette oluşturulabilir, içeri aktarılabilir veya şirket içi HSM'lerden güvenli bir şekilde aktarılabilir. Anahtarlara doğrudan erişim kısıtlanmıştır; yetkili hizmetler anahtar malzemesini göstermeden şifreleme işlemleri 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 şifrelemesi için Azure Key Vault'ta depolanan TDE koruyucusunu kullanabilmesi için Key Vault Yöneticisinin benzersiz Microsoft Entra kimliğini kullanarak sunucuya erişim hakları 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 koruyucusunu yapılandırma gereksinimleri

  • TDE koruyucusu yalnızca asimetrik, RSA veya RSA HSM anahtarı olabilir. Desteklenen anahtar uzunlukları 2.048 bit ve 3.072 bittir.

  • Anahtar etkinleştirme tarihi (ayarlandıysa) geçmişe ait bir tarih ve saat olmalıdır. Son kullanma tarihi (ayarlandıysa) gelecekteki bir tarih ve saat olmalıdır.

  • Anahtar Etkin durumda olmalıdır.

  • Mevcut bir anahtarı anahtar kasasına aktarıyorsanız, bunun desteklenen dosya biçimlerinden birinde sağlanmış olduğundan emin olun: .pfx, .byokveya .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'nin yapılandırılmasına yönelik öneriler

  • En iyi performansı ve güvenilirliği sağlamak için Azure SQL için ayrılmış bir Azure Key Vault kullanılması kesinlikle önerilir. Bu anahtar kasası diğer hizmetlerle paylaşılmamalıdır. 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, sunucudaki her veritabanı için anahtar işlemlerini tetikleyen sunucu yük devretmeleri sırasında kritik önem taşır.

    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';

      500'den fazla sayfa sunucusunu tek bir Azure Key Vault ile ilişkilendirmayın. Veritabanı büyüdükçe sayfa sunucusu sayısı otomatik olarak artar, bu nedenle veritabanı boyutunu düzenli olarak izlemek önemlidir. Sayfa sunucusu sayısı 500'ü aşarsa, diğer Azure SQL kaynaklarıyla paylaşılmayan her Hiper Ölçek veritabanı için ayrılmış bir Azure Key Vault kullanı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.

  • 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ırırken öneriler

  • 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 tutarak eski veritabanı yedeklerinin geri yüklenebilmesini sağlayın. Bir veritabanı için TDE koruyucusu değiştirildiğinde, veritabanının eski yedekleri en son TDE koruyucusu kullanılacak şekilde güncelleştirilmez . Geri yükleme anında, her yedeklemenin, oluşturulduğu sırada şifrelendiği TDE koruyucusuna sahip olması gerekir. Anahtar döndürme işlemleri , Saydam veri şifrelemesi (TDE) koruyucusu döndürme makalesindeki yönergelere uyularak gerçekleştirilebilir.

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

TDE koruyucunun döndürülmesi

Bir sunucu için TDE koruyucusunun döndürülmesinin anlamı, sunucudaki veritabanları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.

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ın (CMK) kullanıldığı coğrafi çoğaltma senaryoları desteklenir. 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 yedeklemeleri 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.

Coğrafi DR veya müşteri tarafından yönetilen TDE

Hem etkin coğrafi çoğaltma hem de yük devretme grubu senaryolarında, söz konusu birincil ve ikincil sunucular herhangi bir bölgede bulunan Azure Key Vault veya Azure Yönetilen HSM'ye bağlanabilir. Sunucu ve anahtar kasasının veya yönetilen HSM'nin aynı bölgede birlikte bulunması gerekmez. Bununla, kolaylık sağlamak için birincil ve ikincil sunucular aynı anahtar kasasına veya yönetilen HSM'ye bağlanabilir (herhangi bir bölgede). Bu, her iki sunucu için de ayrı anahtar kasaları veya yönetilen HSM'ler kullanılıyorsa anahtar materyalin senkronize olmayabileceği senaryoları önlemeye yardımcı olur.

Azure Key Vault ve Azure Yönetilen HSM,hizmet veya bölge hatalarında anahtarların ve anahtar kasalarının kullanılabilir durumda kaldığından emin olmak için birden çok yedeklilik katmanına sahiptir. Yedeklilik, eşlenmemiş ve eşlenmiş bölgeler tarafından desteklenir. Daha fazla bilgi için bkz . Azure Key Vault kullanılabilirliği ve yedekliliği.

TDE koruyucu anahtarını müşterilerin gereksinimlerine göre depolamak için çeşitli seçenekler vardır:

  • Azure Key Vault'u ve yerel eşleştirilmiş bölge dayanıklılığını veya eşleştirilmemiş bölge dayanıklılığını kullanın.

  • Müşteri HSM'sini kullanın ve anahtarları Azure Key Vault'ta birden çok bölgede ayrı Azure Key Vault'ta yükleyin.

  • Azure Yönetilen HSM'yi ve bölgeler arası çoğaltma seçeneğini kullanın.

    • Bu seçenek, müşterinin anahtarların çoğaltıldığı istenen bölgeyi seçmesine olanak tanır.

Aşağıdaki diyagram, bir yük devretme grubu kullanılarak coğrafi çoğaltma için Azure SQL kurulumu ile Azure Key Vault çapraz yük devretme yapılandırmasında eşleştirilmiş bölge (birincil ve ikincil) tasarımını temsil eder.

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

Geo-DR için Azure Key Vault açıklamaları

  • Azure SQL'deki hem birincil hem de ikincil sunucular, birincil bölgedeki Azure Key Vault'a erişer.

  • Azure Key Vault yük devretme işlemi müşteri tarafından değil Azure Key Vault hizmeti tarafından başlatılır.

  • Azure Key Vault yedek bölgeye geçerse, Azure SQL'deki sunucu yine aynı Azure Key Vault'a erişebilir. Dahili olarak Azure Key Vault bağlantısı ikincil bölgedeki Azure Key Vault'a yönlendirilir.

  • Yeni anahtar oluşturma, içeri aktarma ve anahtar döndürme işlemleri yalnızca birincil anahtar kasasında Azure Key Vault kullanılabilir durumdayken mümkündür.

  • Yük devretme gerçekleştikten sonra, eşlenmiş bölgenin birincil konumundaki Azure Key Vault'a yeniden erişilene kadar anahtar rotasyonuna izin verilmez.

  • Müşteri ikincil bölgeye el ile bağlanamıyor.

  • Azure Key Vault salt okunur durumdayken birincil bölgedeki Azure Key Vault kullanılamıyor

  • Müşteri, Azure Key Vault'un şu anda hangi bölgede olduğunu seçemiyor veya denetleyemiyor.

  • Eşleştirilmeyen bölge için her iki Azure SQL sunucusu da ilk bölgedeki Azure Key Vault'a erişir (grafikte belirtildiği gibi) ve Azure Key Vault da bölge içindeki verileri aynı bölgenin bağımsız kullanılabilirlik alanları arasında çoğaltmak için alanlar arası yedekli depolama kullanır.

Daha fazla bilgi için bkz. Azure Key Vault kullanılabilirliği ve yedekliliği, Azure bölge çiftleri ve eşleşmemiş bölgelerve Azure Key Vault için hizmet düzeyi sözleşmeleri.

Geo-DR için Azure SQL açıklamaları

  • Azure SQL Yönetilen Örnek ve Azure SQL Veritabanı'nın bölge yedekliliği seçeneğini kullanarak dayanıklılığı artırın. Daha fazla bilgi için bkz. Azure kullanılabilirlik alanları nelerdir?.

  • Azure SQL Yönetilen Örneği ve Azure SQL Veritabanı’nda ikincil bir bölgeye felaket kurtarma amacıyla aktarım gruplarını kullanın. Daha fazla bilgi için bkz. yük devretme gruplarına genel bakış & en iyi yöntemler.

  • Veritabanı etkin coğrafi çoğaltma veya yük devretme gruplarının parçası olduğunda ve erişilemez hale geldiğinde, SQL denetim düzlemi bağlantıyı keser ve veritabanını tek başına bir veritabanına dönüştürür. Temel izinler düzeltildikten sonra birincil veritabanı genellikle yeniden çevrimiçi yapılabilir. Azure SQL tasarım gereği ikincil veritabanları için tam yedeklemeler almadığından ikincil veritabanı yeniden çevrimiçine getirilemiyor. İkincil veritabanlarını bırakma ve bağlantıyı yeniden oluşturma önerisinde bulunur.

  • Azure SQL'de özel uç noktalar kullanılıyorsa yapılandırma daha karmaşık bir DNS bölgesi gerektirebilir (örneğin, aynı DNS bölgesinde aynı kaynak için iki özel uç nokta oluşturamaz).

  • Uygulamaların yeniden deneme mantığını kullandığına emin olun.

Müşterilerin Azure Key Vault yerine Azure Yönetilen HSM çözümünü seçmek isteyebileceği birkaç senaryo vardır:

  • İkincil kasaya manuel bağlantı gerekiyor.

  • Bir hata oluştuğunda bile kasaya okuma erişimi gereklidir.

  • Anahtar verilerinin hangi bölgeye kopyalandığını seçme esnekliği

    • Bölgeler arası çoğaltmayı etkinleştirmeyi gerektirir, bu da ikinci bölgede ikinci bir Azure Yönetilen HSM havuzu oluşturur.

  • Azure Yönetilen Donanım Güvenlik Modülü'nün (HSM) kullanılması, orijinal HSM kaybolur veya kullanılamaz duruma gelirse müşterilerin HSM için tam bir kopya oluşturmasına olanak tanır.

  • Güvenlik veya mevzuat gereksinimleri için Azure Yönetilen HSM'nin kullanımı.

  • Tüm kasayı yedekleme yerine tek tek anahtarları yedekleme olanağına sahip olma.

Daha fazla bilgi için bkz. Azure Yönetilen HSM'de çok bölgeli çoğaltmayı etkinleştirme ve Yönetilen HSM olağanüstü durum kurtarma.

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