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

  • Makale

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

Müşteri tarafından yönetilen anahtar (CMK) ile Azure SQL 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, TDE koruyucusu olarak adlandırılan Veritabanı Şifreleme Anahtarının (DEK) şifrelenmesi için kullanılan anahtar, bulut tabanlı bir dış anahtar yönetim sistemi olan müşteriye ait ve müşteri tarafından yönetilen Azure Anahtar Kasası'nda (AKV) depolanan müşteri tarafından yönetilen asimetrik anahtardır. Key Vault, isteğe bağlı olarak FIPS 140-2 Düzey 2 doğrulanmış donanım güvenlik modülleri (HSM) tarafından desteklenen RSA şifreleme anahtarları için yüksek oranda kullanılabilir ve ölçeklenebilir güvenli depolama alanıdır. Depolanan anahtara doğrudan erişime izin vermez, ancak yetkili varlıklara anahtarı kullanarak şifreleme/şifre çözme hizmetleri sağlar. Anahtar, anahtar kasası tarafından oluşturulabilir, içeri aktarılabilir veya şirket içi HSM cihazından anahtar kasasına aktarılabilir.

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ı hem de Azure Synapse'teki bir sunucuya ve bu belgenin tamamında SQL Yönetilen Örneği yönetilen bir ö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).

Not

  • Bu makale Azure SQL Veritabanı, Azure SQL Yönetilen Örneği ve Azure Synapse Analytics (ayrılmış SQL havuzları (eski adı SQL DW) için geçerlidir. Synapse çalışma alanlarındaki ayrılmış SQL havuzları için saydam veri şifrelemesi belgeleri için bkz . Azure Synapse Analytics şifrelemesi.
  • Azure SQL müşterilerine bekleyen verilerin iki katmanını şifreleme olanağı sağlamak için platform tarafından yönetilen anahtarlarla altyapı şifrelemesi (AES-256 şifreleme algoritması kullanılarak) kullanıma sunuluyor. Bu, müşteri tarafından yönetilen anahtarlarla birlikte bekleyen şifreleme katmanını ve zaten kullanılabilir olan TDE'yi sağlar. Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için, altyapı şifrelemesi etkinleştirildiğinde veritabanı ve diğer sistem veritabanları dahil olmak üzere master tüm veritabanları şifrelenir. Şu anda müşterilerin bu özelliğe erişim istemesi gerekir. Bu özellik ilginizi çekiyorsa, ile iletişime geçin AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Not

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

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ı yapabilme;

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

  • AKV'de anahtarların merkezi yönetimi;

  • AKV, Microsoft'un şifreleme anahtarlarını göremeyecek veya ayıklayamaz şekilde tasarlandığından, son müşterilerinizden daha fazla güven;

Önemli

Hizmet tarafından yönetilen TDE kullanan ancak müşteri tarafından yönetilen TDE kullanmaya başlamak isteyen müşteriler için veriler geçiş sürecinde şifrelenmiş durumda kalır ve veritabanı dosyaları kapalı kalmaz veya yeniden şifrelenmez. 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 nasıl çalışır?

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

Azure'daki mantıksal sunucunun DEK şifrelemesi için AKV'de depolanan TDE koruyucusunu kullanabilmesi için anahtar kasası yöneticisinin benzersiz Microsoft Entra kimliğini kullanarak sunucuya aşağıdaki erişim haklarını vermesi gerekir:

  • get - 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ı yöneticisi, anahtar kasası denetim olaylarının günlüğe kaydedilmesini de etkinleştirerek daha sonra denetlenebilir.

Sunucu AKV'den 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 ve 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.

Not

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 yapılandırmasıyla ilgili gereksinimler

AKV'yi yapılandırma gereksinimleri

  • Geçici silme ve temizleme koruma özellikleri, yanlışlıkla anahtar (veya anahtar kasası) silinmesi nedeniyle veri kaybından korunmak için anahtar kasasında etkinleştirilmelidir.

  • Sunucuya veya yönetilen örneğe Microsoft Entra kimliğini kullanarak anahtar kasasına (get, wrapKey, unwrapKey) erişim verin. Sunucu kimliği, sistem tarafından atanan yönetilen kimlik veya sunucuya atanan kullanıcı tarafından atanan yönetilen kimlik olabilir. Azure portal kullandığınızda sunucu oluşturulduğunda Microsoft Entra kimliği otomatik olarak oluşturulur. PowerShell veya Azure CLI kullandığınızda, Microsoft Entra kimliği açıkça oluşturulmalı ve doğrulanmalıdır. PowerShell kullanırken ayrıntılı adım adım yönergeler için SQL Yönetilen Örneği için bkz. BYOK ile TDE'yi yapılandırma ve BYOK ile TDE'yi yapılandırma.

    • Anahtar kasasının izin modeline bağlı olarak (erişim ilkesi veya Azure RBAC), anahtar kasası erişimi anahtar kasasında bir erişim ilkesi oluşturularak veya Key Vault Şifreleme Hizmeti Şifreleme Kullanıcısı rolüyle yeni bir Azure RBAC rol ataması oluşturularak verilebilir.

  • AKV ile güvenlik duvarı kullanırken Güvenilen Microsoft hizmetleri 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.

AKV için geçici silme ve temizleme korumasını etkinleştirme

Önemli

Müşteri tarafından yönetilen TDE yeni veya mevcut bir sunucuda ya da yönetilen örnekte yapılandırılırken anahtar kasasında hem geçici silmehem de temizleme koruması etkinleştirilmelidir.

Geçici silme ve temizleme koruması , Azure Key Vault'un silinen kasaların ve silinen anahtar kasası nesnelerinin kurtarılmasını sağlayarak kullanıcının yanlışlıkla veya kötü amaçlı olarak bir anahtarı veya anahtar kasasını silme riskini azaltan önemli özellikleridir.

  • Geçici olarak silinen kaynaklar, müşteri tarafından kurtarılmadığı veya temizlenmediği sürece 90 gün boyunca saklanır. Kurtarma ve temizleme eylemlerinin bir anahtar kasası erişim ilkesiyle ilişkili kendi izinleri vardır. Geçici silme özelliği yeni anahtar kasaları için varsayılan olarak açıktır ve Azure portalı, PowerShell veya Azure CLI kullanılarak da etkinleştirilebilir.

  • Temizleme koruması Azure CLI veya PowerShell kullanılarak açılabilir. Temizleme koruması etkinleştirildiğinde silinmiş durumdaki bir kasa veya nesne saklama süresi geçene kadar temizlenemez. Varsayılan saklama süresi 90 gündür, ancak Azure portalı üzerinden 7 ile 90 gün arasında yapılandırılabilir.

  • Azure SQL, sunucu veya yönetilen örnek için TDE koruyucusu olarak kullanılan şifreleme anahtarını içeren anahtar kasasında geçici silme ve temizleme korumasının etkinleştirilmesini gerektirir. Bu, yanlışlıkla veya kötü amaçlı anahtar kasası veya veritabanının Erişilemez duruma geçmesini sağlayabileceğiniz anahtar silme senaryolarını ö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.

TDE koruyucusunu yapılandırma gereksinimleri

  • TDE koruyucusu yalnızca asimetrik, RSA veya RSA HSM anahtarı olabilir. Desteklenen anahtar uzunlukları 2048 bit ve 3072 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 anahtarı anahtar kasasına aktarıyorsanız, desteklenen dosya biçimlerinde (.pfx, .byokveya .backup) sağladığından emin olun.

Not

Azure SQL artık Yönetilen HSM'de TDE koruyucusu olarak depolanan bir RSA anahtarının kullanılmasını destekliyor. Azure Key Vault Yönetilen HSM, FIPS 140-2 Düzey 3 doğrulanmış HSM'leri kullanarak bulut uygulamalarınız için şifreleme anahtarlarını korumanızı sağlayan, tam olarak yönetilen, yüksek oranda kullanılabilir, tek kiracılı, standartlara uyumlu bir bulut hizmetidir. Yönetilen HSM'ler hakkında daha fazla bilgi edinin.

Not

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 sorunla ilgili daha fazla ayrıntıya buradan ulaşabilirsiniz. Bu gibi durumlarda, anahtarı anahtar kasasına aktardıktan sonra sunucu veya yönetilen örnek için TDE koruyucusu olarak kullanmaya başlamak için lütfen 24 saat bekleyin. 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

AKV yapılandırırken Öneriler

  • Sunucu anahtar kasasında TDE koruyucusunun erişimine eriştiğinde yüksek kullanılabilirlik sağlamak için toplamda en fazla 500 Genel Amaçlı veya 200 İş Açısından Kritik veritabanını tek bir abonelikteki bir anahtar kasasıyla ilişkilendirin. Bu rakamlar deneyime dayalıdır ve anahtar kasası hizmet sınırları içinde belgelenmiştir. Burada amaç, sunucu yük devretmesi sonrasındaki sorunları önlemektir, bu nedenle bu sunucuda veritabanları olduğu kadar kasa üzerinde de çok sayıda anahtar işlemi tetikler.

  • 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: Anahtar kasası, diğer güvenlik bilgilerine ve olay yönetimi araçlarına kolayca eklenen günlükler sağlar. Operations Management Suite Log Analytics , zaten tümleştirilmiş bir hizmet örneğidir.

  • Şifrelenmiş veritabanlarının yüksek kullanılabilirliğini sağlamak için her sunucuyu farklı bölgelerde bulunan ve aynı anahtar malzemesini tutan iki anahtar kasasına bağlayın. Anahtar kasalarından birinin anahtarını TDE koruyucusu olarak işaretleyin. İlk bölgedeki anahtar kasasını etkileyen bir kesinti olması durumunda sistem ikinci bölgedeki anahtar kasasına otomatik olarak aynı anahtar malzemesiyle geçiş yapacaktır.

Not

Müşteri tarafından yönetilen TDE'yi yapılandırma konusunda daha fazla esneklik sağlamak için, artık bir bölgedeki Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği başka bir bölgedeki anahtar kasasına bağlanabilir. Sunucu ile 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ı AKV'de 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.

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

  • Eski veritabanı yedeklemelerinin geri yüklenebilmesi için anahtarları döndürürken anahtarın önceki sürümlerini anahtar kasasında tutun. 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 zamanında her yedeklemenin oluşturma sırasında şifrelendiği TDE koruyucunun olması gerekir. Anahtar döndürme işlemleri, PowerShell kullanarak saydam veri şifreleme koruyucusu döndürme başlığındaki yönergelere uyularak gerçekleştirilebilir.

  • Hizmet tarafından yönetilen anahtarlara geçiş yaptıktan sonra bile daha önce kullanılan tüm anahtarları AKV’de tutun. Bu yaklaşım, veritabanı yedeklemelerinin AKV’de depolanan TDE koruyucularıyla geri yüklenebilmesini sağlar. Azure Key Vault 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.

  • Güvenlik olayı sırasında güvenliği aşılmış olabilecek bir anahtarı veri kaybı riski olmadan kaldırmak için, Güvenliği aşılmış olabilecek anahtarı kaldırma başlığı altındaki adımları izleyin.

TDE koruyucusunun döndürmesi

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ı sürekli olarak 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 ile kullanıldığında, bu özellik Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği TDE koruyucusu için uçtan uca sıfır dokunma döndürmeyi etkinleştirir.

Not

Anahtarların el ile veya otomatik döndürme kullanılarak 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 söz konusu olduğunda 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 gerekenler

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 (aynı anahtar malzemesine sahip başka bir anahtarla değil) kullanılan aynı anahtar kasasındaki anahtara erişim gerektirir. 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ında gerekli izinlere sahip olduğundan ve sistemin anahtarı ikincil sunucuya eklemeye çalışacağı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 (aynı anahtar malzemesine sahip başka bir anahtarla değil) kullanılan aynı anahtar kasasındaki anahtara erişim gerektirir. 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ışacağı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 AKV'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.

Not

Aralıklı ağ kesintisi nedeniyle veritabanına erişilemiyorsa herhangi bir eylem gerekmez ve veritabanları otomatik olarak yeniden çevrimiçi olur.

Anahtara erişim geri yüklendikten sonra veritabanını yeniden çevrimiçi yapmak için fazladan zaman ve adımlar gerekir. Bu süre, anahtara erişim olmadan geçen süreye ve veritabanındaki verilerin boyutuna bağlı olarak değişebilir:

Not

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 almaktadır.

TDE BYOK Erişilemez Veritabanı

Yanlışlıkla TDE koruyucusu erişim iptali

Anahtar kasasına yeterli erişim haklarına sahip biri, anahtara sunucu erişimini yanlışlıkla şu şekilde devre dışı bırakabilir:

  • anahtar kasasının sunucudan get, wrapKey, unwrapKey izinlerini iptal etme

  • anahtarı silme

  • anahtar kasasını silme

  • anahtar kasasının 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 Key Vault arasındaki bağlantı engellendi

SQL Yönetilen Örneği, Azure Key Vault'ta TDE koruyucusunun erişmeye çalışılırken oluşan ağ hataları veritabanlarının durumunu Erişilemez olarak değiştirmesine neden olmayabilir, ancak daha sonra örneği kullanılamaz duruma getirir. Bu durum çoğunlukla anahtar kasası kaynağı mevcut olduğunda ancak uç noktasına yönetilen örnekten erişilemiyorsa gerçekleşir. Anahtar kasası uç noktasına ulaşılabildiği ancak bağlantının reddedildiği, eksik izinlerin vb. bulunduğu tüm senaryolar veritabanlarının durumunu Erişilemez olarak değiştirmesine neden olur.

Key Vault ağ bağlantısı olmamasının en yaygın nedenleri şunlardır:

  • Key Vault özel uç nokta aracılığıyla kullanıma sunulur ve yönetilen örnek alt ağıyla ilişkili Ağ Güvenlik Grubunun (NSG) giden kurallarında AKV hizmetinin özel IP adresine izin verilmez.
  • Anahtar kasası FQDN'sinin çözümlenmemiş olması veya geçersiz bir IP adresine çözümlenmesi gibi hatalı DNS çözümlemesi.

SQL Yönetilen Örneği'den TDE koruyucuyu barındıran Key Vault'a bağlantıyı test edin.

  • Uç nokta, vault_name.vault.azure.net (https://> olmadan) gibi <kasa FQDN'nizdir.
  • 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 ö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 Durumu. TDE koruyucusunun erişimini kaybeden erişilemez bir veritabanı, veritabanına ilk bağlantı reddedildikten sonra "Kullanılamaz" olarak gösterilir.
  • Müşteri tarafından yönetilen anahtar kasasındaki TDE koruyucusunun erişimi başarısız olduğunda etkinlik günlüğü girdileri 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 tarafından yönetilen TDE ile veritabanını yedekleme ve geri yükleme

Bir veritabanı Key Vault'tan bir anahtar kullanılarak TDE ile şifrelendiğinde, yeni oluşturulan tüm yedeklemeler de aynı TDE koruyucusuyla şifrelenir. TDE koruyucusu değiştirildiğinde, veritabanının eski yedeklemeleri en son TDE koruyucusu kullanılacak şekilde güncelleştirilmez .

Key Vault'tan TDE koruyucusuyla şifrelenmiş bir yedeklemeyi geri yüklemek için anahtar malzemesinin hedef sunucuda kullanılabilir olduğundan emin olun. Bu nedenle TDE koruyucusunun tüm eski sürümlerini anahtar kasasında tutmanızı öneririz; böylelikle veritabanı yedeklemeleri geri yüklenebilir.

Önemli

Herhangi bir anda bir sunucu için birden fazla TDE koruyucusu ayarlanamaz. Azure portalı bölmesinde "Anahtarı varsayılan TDE koruyucusu yap" ile işaretlenmiş anahtardır. Ancak, birden çok ek anahtar, bir sunucuya TDE koruyucusu olarak işaretlemeden 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ı yedekleme kurtarma hakkında daha fazla bilgi edinmek için bkz. SQL Veritabanı'da veritabanını kurtarma. 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ıç: Veritabanını SQL Yönetilen Örneği 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'ta depolanan bir TDE koruyucusu kullanıyorsa, bu sırada veritabanı hizmet tarafından yönetilen TDE kullanacak şekilde değiştirilmiş olsa bile geri yükleme zamanında bu anahtar gerekir.

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

Sunucu için coğrafi olarak yedeklilik yapılandırılmamış olsa bile, sunucunun aynı anahtar malzemeyle iki farklı bölgede iki farklı anahtar kasası kullanacak şekilde yapılandırılması kesinlikle önerilir. Diğer bölgedeki ikincil anahtar kasasındaki anahtar TDE koruyucusu olarak işaretlenmemelidir ve buna izin verilmez. Birincil anahtar kasasını etkileyen bir kesinti varsa ve yalnızca o zaman sistem varsa, ikincil anahtar kasasında aynı parmak izine sahip diğer bağlantılı anahtara otomatik olarak geçer. TDE koruyucusunun erişim hakları iptal edildiğinden veya anahtar veya anahtar kasası silindiğinden erişim engellendiğinde anahtarın gerçekleşmeyeceğini unutmayın çünkü bu durum müşterinin sunucunun anahtara erişmesini kasıtlı olarak kısıtlamak istediğini gösterebilir. Anahtarı farklı bölgelerdeki iki anahtar kasasına aynı anahtar malzemesini sağlamak, anahtarı anahtar kasasının dışında oluşturup her iki anahtar kasasına da içeri aktararak yapılabilir.

Alternatif olarak, bir bölgede birincil anahtar kasası kullanılarak anahtar oluşturularak ve anahtarı farklı bir Azure bölgesindeki bir anahtar kasasına kopyalayarak gerçekleştirilebilir. Anahtarı birincil anahtar kasasından şifrelenmiş biçimde almak için Backup-AzKeyVaultKey cmdlet'ini kullanın ve ardından Restore-AzKeyVaultKey cmdlet'ini kullanın ve anahtarı kopyalamak için ikinci bölgede bir anahtar kasası belirtin. Alternatif olarak, anahtarı yedeklemek ve geri yüklemek için Azure portalını kullanın. Anahtar yedekleme/geri yükleme işlemine yalnızca aynı Azure aboneliği ve Azure coğrafyası içindeki anahtar kasaları arasında izin verilir.

Tek Sunuculu HA

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 aynı anahtar kasasına (herhangi bir bölgede) veya anahtar kasalarını ayırmak için bağlanabilir. Birincil ve ikincil sunuculara ayrı anahtar kasaları bağlıysa, müşteri anahtar kasalarındaki anahtar malzemesini tutarlı tutmaktan sorumludur; böylece coğrafi ikincil eşitlenmiş olur ve bölgede bir kesinti nedeniyle birincil kasaya erişilemez hale gelirse ve yük devretme tetiklenirse aynı anahtarı bağlı anahtar kasasından devralabilir. En fazla dört ikincil yapılandırılabilir ve zincirleme (ikincillerin ikincilleri) desteklenmez.

Eksik anahtar malzemesi nedeniyle coğrafi çoğaltma sırasında veya oluşturulurken oluşan sorunları önlemek için müşteri tarafından yönetilen TDE yapılandırılırken (birincil ve ikincil sunucular için ayrı anahtar kasaları kullanılıyorsa) bu kurallara uyulması önemlidir:

  • İlgili tüm anahtar kasalarının aynı özelliklere ve ilgili sunucular için aynı erişim haklarına sahip olması gerekir.

  • İlgili tüm anahtar kasaları aynı anahtar malzemelerini içermelidir. Yalnızca geçerli TDE koruyucusu için değil, yedekleme dosyalarında kullanılabilecek tüm önceki TDE koruyucuları için de geçerlidir.

  • TDE koruyucusunun hem ilk kurulumu hem de döndürmesi önce ikincil ve ardından birincilde yapılmalıdır.

Yük devretme grupları ve coğrafi dr

Yük devretmeyi test etmek için Etkin coğrafi çoğaltmaya genel bakış sayfasındaki adımları izleyin. SQL Veritabanı her iki anahtar kasasına da erişim izninin korunduğunu doğrulamak için yük devretme testi düzenli olarak yapılmalıdır.

Azure SQL Veritabanı sunucu ve bir bölgedeki SQL Yönetilen Örneği artık başka bir bölgedeki anahtar kasasına bağlanabilir. Sunucu ve anahtar kasasının aynı bölgede birlikte bulunması gerekmez. Bu şekilde, kolaylık sağlamak için birincil ve ikincil sunucular aynı anahtar kasasına (herhangi bir bölgede) bağlanabilir. Bu, her iki sunucu için de ayrı anahtar kasaları kullanılıyorsa anahtar malzemesinin eşitlenmemiş olabileceği senaryoları önlemeye yardımcı olur. Azure Key Vault'ta, hizmet veya bölge sorunları yaşandığında anahtarlarınızın ve anahtar kasalarınızın kullanılabilir durumda kaldığından emin olmak için birden çok yedeklilik katmanı vardır. Azure Key Vault kullanılabilirliği ve yedekliliği

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ılmamışsa 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 bekleyen 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

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

Sonraki adımlar

Müşteri tarafından yönetilen TDE ile ortak işlemler için aşağıdaki PowerShell örnek betiklerini de denetlemek isteyebilirsiniz:

Ayrıca, olası veritabanı güvenlik açıklarını bulma ve azaltma ve veritabanlarınız için tehdit oluşturabilecek anormal etkinlikleri algılama işlevleriyle sql için Microsoft Defender'ın veritabanlarınızı ve verilerinin güvenliğini sağlamasını sağlayın.