PostgreSQL için Azure Veritabanı'nda bekleyen veri şifreleme

Azure Veritabanı için PostgreSQL esnek sunucu örneği tarafından yönetilen tüm veriler, her zaman, bekleme durumundayken şifrelenir. Bu veriler tüm sistem ve kullanıcı veritabanlarını, sunucu günlüklerini, önceden yazma günlük kesimlerini ve yedeklemeleri içerir. Şifreleme, Azure Disk Depolama'nın Sunucu tarafı şifrelemesi aracılığıyla temel depolama tarafından işlenir.

Bekleyen Hizmet (SMK) veya Müşteri Tarafından Yönetilen Anahtarlar (CMK) ile Şifreleme

PostgreSQL için Azure Veritabanı bekleyen iki veri şifreleme modunu destekler: hizmet tarafından yönetilen anahtarlar (SMK) ve müşteri tarafından yönetilen anahtarlar (CMK). Hizmet tarafından yönetilen anahtarlarla veri şifreleme, PostgreSQL için Azure Veritabanı esnek sunucusu için varsayılan moddur. Bu modda hizmet, verilerinizi şifrelemek için kullanılan şifreleme anahtarlarını otomatik olarak yönetir. Bu modda şifrelemeyi etkinleştirmek veya yönetmek için herhangi bir işlem yapmanız gerekmez.

Müşteri tarafından yönetilen anahtarlar modunda, verilerinizi şifrelemek için kendi şifreleme anahtarınızı getirebilirsiniz. Bu mod, şifreleme işlemi üzerinde daha fazla denetim sağlar, ancak şifreleme anahtarlarını kendiniz yönetmenizi de gerektirir. Kendi Azure Key Vault veya Azure Key Vault Yönetilen Donanım Güvenlik Modülü'nüzü (HSM) dağıtmanız ve PostgreSQL için Azure Veritabanı esnek sunucu örneğiniz tarafından kullanılan şifreleme anahtarlarını depolamak için yapılandırmanız gerekir.

Mod yalnızca sunucu oluşturma zamanında seçilebilir. Sunucunun ömrü boyunca bir moddan diğerine değiştirilemez.

Verilerinizin şifrelenmesini sağlamak için PostgreSQL için Azure Veritabanı bekleyen veriler için Azure Depolama şifrelemesini kullanır. CMK kullanırken müşteri, Blob Depolama ve Azure Dosyalar hizmetlerindeki verileri şifrelemek ve şifresini çözmek için anahtar sağlamakla sorumludur. Bu anahtarların Azure Key Vault veya Azure Key Vault Yönetilen Donanım Güvenlik Modülü'nde (HSM) depolanması gerekir. Daha fazla bilgi için bkz. Azure Depolama şifrelemesi için müşteri tarafından yönetilen anahtarlar.

Her mod (SMK veya CMK) tarafından sağlanan avantajlar

PostgreSQL için Azure Veritabanı için hizmet tarafından yönetilen anahtarlarla veri şifreleme aşağıdaki avantajları sağlar:

  • Hizmet, veri erişimini otomatik olarak ve tam olarak denetler.
  • Hizmet, anahtarın dönüşü de dahil olmak üzere anahtarınızın yaşam döngüsünü otomatik olarak ve tam olarak denetler.
  • Veri şifreleme anahtarlarını yönetme konusunda endişelenmeniz gerekmez.
  • Hizmet tarafından yönetilen anahtarlara dayalı veri şifrelemesi, iş yüklerinizin performansını olumsuz etkilemez.
  • Şifreleme anahtarlarının yönetimini (normal döndürmeleri dahil) ve bu anahtarlara erişmek için kullanılan kimliklerin yönetimini basitleştirir.

PostgreSQL için Azure Veritabanı için müşteri tarafından yönetilen anahtarlarla veri şifreleme aşağıdaki avantajları sağlar:

  • Veri erişimini tam olarak denetlersiniz. Veritabanına erişilemez hale getirmek için bir anahtarı kaldırabilirsiniz.
  • Şirket ilkeleriyle uyumlu hale getirmek için anahtarın döndürmesi de dahil olmak üzere bir anahtarın yaşam döngüsünü tam olarak denetlersiniz.
  • Tüm şifreleme anahtarlarınızı kendi Azure Key Vault örneklerinizde merkezi olarak yönetebilir ve düzenleyebilirsiniz.
  • Müşteri tarafından yönetilen anahtarlara dayalı veri şifrelemesi, iş yüklerinizin performansını olumsuz etkilemez.
  • Güvenlik görevlileri, veritabanı yöneticileri ve sistem yöneticileri arasında görev ayrımı uygulayabilirsiniz.

CMK gereksinimleri

Müşteri tarafından yönetilen şifreleme anahtarıyla sorumluluğu üstlenirsiniz. Bu nedenle, kendi Azure Key Vault'unuzu veya Azure Key Vault HSM'nizi dağıtmanız gerekir. Kendi anahtarınızı oluşturmanız veya içeri aktarmanız gerekir. PostgreSQL için Azure Veritabanı esnek sunucu örneğinizin anahtar üzerinde gerekli eylemleri gerçekleştirebilmesi için Key Vault üzerinde gerekli izinleri vermelisiniz. PostgreSQL için Azure Veritabanı esnek sunucu örneğinizin anahtara erişebilmesi için anahtarın tutulduğu Azure Key Vault'un tüm ağ özelliklerini yapılandırmaya dikkat edin. Anahtara erişimi denetlemek de sizin sorumluluğunuzdadır. Son olarak anahtarı döndürmek ve gerektiğinde PostgreSQL için Azure Veritabanı esnek sunucu örneğinizin yapılandırmasını anahtarın döndürülmüş sürümüne başvurması için güncelleştirmek sizin sorumluluğunuzdadır.

Depolama hesabı için müşteri tarafından yönetilen anahtarları yapılandırdığınızda Azure Depolama, hesabın kök veri şifreleme anahtarını (DEK) ilişkili anahtar kasasında veya yönetilen HSM'de bulunan müşteri tarafından yönetilen anahtarı kullanarak sarar. Kök şifreleme anahtarının koruması değişir, ancak Azure Depolama hesabınızdaki veriler her zaman şifrelenmiş olarak kalır. Verilerinizin şifrelenmesini sağlamak için ek bir işlem yapmanız gerekmez. Müşteri tarafından yönetilen anahtarlara göre koruma hemen geçerli olur.

Azure Key Vault bulut tabanlı bir dış anahtar yönetim sistemidir. Yüksek oranda kullanılabilir ve isteğe bağlı olarak FIPS 140 doğrulanmış donanım güvenlik modülleri (HSM) tarafından desteklenen RSA şifreleme anahtarları için ölçeklenebilir, güvenli depolama sağlar. Depolanan anahtara doğrudan erişime izin vermez, ancak yetkili varlıklara şifreleme ve şifre çözme hizmetleri sağlar. Key Vault, anahtarı oluşturabilir, içeri aktarabilir veya şirket içi HSM cihazından aktarılmasını sağlayabilir.

PostgreSQL için Azure Veritabanı için veri şifrelemeyi yapılandırma gereksinimlerinin listesi aşağıdadır:

  • Tek kiracılı CMK yapılandırmaları için Key Vault ve PostgreSQL için Azure Veri Tabanı esnek sunucu örneğiniz aynı Microsoft Entra kiracısına ait olmalıdır. Kiracılar arası senaryolar için bkz. Kiracılar arası müşteri tarafından yönetilen anahtarlar. Daha sonra Key Vault kaynağını taşımak için veri şifrelemesini yeniden yapılandırmanız gerekir.
  • Key Vault için Silinen kasaların saklanacağı gün sayısı yapılandırmasını 90 gün olarak ayarlamanızı öneririz. Mevcut bir Key Vault örneğini daha düşük bir sayıyla yapılandırdıysanız, yine de geçerli olmalıdır. Ancak, bu ayarı değiştirmek ve değeri artırmak istiyorsanız yeni bir Key Vault örneği oluşturmanız gerekir. Bir örnek oluşturulduktan sonra bu ayarı değiştirmek mümkün değildir.
  • Anahtar veya Key Vault örneği yanlışlıkla silinirse veri kaybından korunmanıza yardımcı olması için Key Vault'ta geçici olarak silinen özelliği etkinleştirin. Key Vault, kullanıcı kurtarmadığı veya temizlemediği sürece geçici olarak silinen kaynakları 90 gün boyunca saklar. Kurtarma ve temizleme eylemleri, bir Key Vault, bir RBAC rolü veya bir erişim ilkesi izni ile ilişkilendirilmiş kendilerine özgü izinlere sahiptir. Geçici olarak silinen özellik varsayılan olarak açıktır. Uzun süre önce oluşturulmuş bazı Key Vault'larınız varsa, geçici silme özelliği hâlâ devre dışı olabilir. Bu durumda Azure CLI kullanarak açabilirsiniz.
  • Silinmiş kasalar ve kasa nesneleri için zorunlu bir saklama süresi uygulanmasını sağlamak üzere silme korumasını etkinleştirin.
  • PostgreSQL için Azure Veritabanı esnek sunucu örneğinin kullanıcı tarafından atanan yönetilen kimlik erişimine şu şekilde izin verin:
  • Tercih edilen: Azure Key Vault RBAC izin modeliyle yapılandırılmalıdır ve yönetilen kimliğe Key Vault Şifreleme Hizmeti Şifreleme Kullanıcı rolü atanmalıdır.
  • Eski: Azure Key Vault Erişim ilkesi izin modeliyle yapılandırılmışsa yönetilen kimlik için aşağıdaki izinleri verin:
  • get: Key Vault'ta anahtarın özelliklerini ve ortak bölümünü almak için.
  • list: Key Vault'ta depolanan anahtarları listelemek ve yinelemek için.
  • wrapKey: Veri şifreleme anahtarını şifrelemek için.
  • unwrapKey: Veri şifreleme anahtarının şifresini çözmek için.
  • Veri şifreleme anahtarını şifrelemek için kullanılan anahtar yalnızca asimetrik, RSA veya RSA-HSM olabilir. 2.048, 3.072 ve 4.096 anahtar boyutları desteklenir. Daha iyi güvenlik için 4.096 bit anahtar kullanmanızı öneririz.
  • Anahtar etkinleştirme tarihi ve saati (ayarlandıysa) geçmişte olmalıdır. Süre sonu tarihi ve saati (ayarlandıysa) gelecekte olmalıdır.
  • Anahtar Etkin durumda olmalıdır.
  • Mevcut bir anahtarı Key Vault'a aktarıyorsanız, anahtarı desteklenen dosya biçimlerinde (.pfx, .byokveya .backup) sağlayın.

CMK anahtar sürümü güncelleştirmeleri

CMK, anahtarın el ile döndürülmesi ve güncellemelerle ya da Key Vault'ta anahtarın el ile veya otomatik döndürülmesinden sonra anahtar sürümünün otomatik güncellenmesiyle yapılandırılabilir.

Ayrıntılar için bkz. Sunucu sağlama sırasında müşteri tarafından yönetilen anahtarla veri şifrelemeyi yapılandırma.

Önemli

Anahtarı yeni bir sürüme döndürdüğünüzde, yeniden şifrelemenin başarılı olması için eski anahtarı kullanılabilir durumda tutmanız gerekir. Çoğu yeniden şifreleme 30 dakika içinde gerçekleşse de, eski anahtar sürümüne erişimi devre dışı bırakmadan önce en az 2 saat beklemenizi öneririz.

El ile anahtar döndürme ve güncelleştirmeler

CMK'yi manuel anahtar güncellemeleriyle yapılandırırken, Key Vault'ta bir manuel veya otomatik anahtar döndürme işleminden sonra, PostgreSQL için Azure Veritabanı esnek sunucu örneğinde anahtar sürümünü manuel olarak güncelleştirmeniz gerekmektedir. Sunucu, siz güncelleştirene kadar eski anahtar sürümünü kullanmaya devam eder. Bu modu, URI'deki sürüm GUID de dahil olmak üzere bir anahtar URI'si belirterek sağlarsınız. Örneğin, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Yakın zamana kadar bu tek seçenekti.

Anahtarı el ile döndürdüğünüzde veya AKV anahtarı döndürme ilkesine göre otomatik döndürdüğünüzde, PostgreSQL örneğinizdeki CMK özelliğini güncelleştirmeniz gerekiyordu. Bu yaklaşım, operatörler için hata yapmaya açık bir iş olduğunu gösterdi ya da özellikle Key Vault’un otomatik rotasyon özelliği kullanılırken rotasyonu yönetmek için özel bir betik gerektiriyordu.

Otomatik anahtar sürümü güncelleştirmeleri

Otomatik anahtar sürüm güncelleştirmelerini etkinleştirmek için sürümsüz anahtar URI'sini kullanın. Bu yaklaşım, bir anahtar döndürme sonrasında PostgreSQL örneğinizdeki CMK'nin sürüm özelliğini güncelleştirme gereksinimini ortadan kaldırır. PostgreSQL, yeni anahtar sürümünü otomatik olarak alır ve veri şifreleme anahtarını yeniden şifreler. Bu, özellikle Key Vault otomatik döndürme ile birlikte kullanıldığında, anahtar yaşam döngüsü yönetiminizi önemli ölçüde basitleştirir.

Azure Resource Manager, Bicep, Terraform, Azure PowerShell veya Azure CLI kullanarak uygulamak için, anahtar URI’sinden GUID sürümünü hariç tutun.

Portalda, etkileşimli seçim sırasında ve URI'yi doğrularken kullanıcı arabirimine sürüm GUID'lerini gizleme konusunda yol gösterecek onay kutusunu seçin.

Recommendations

Veri şifrelemesi için müşteri tarafından yönetilen anahtar kullanırken Key Vault'u yapılandırmak için şu önerileri izleyin:

  • Bu kritik kaynağın yanlışlıkla veya yetkisiz silinmesini önlemek için Key Vault'ta bir kaynak kilidi ayarlayın.
  • Tüm şifreleme anahtarlarında denetimi ve raporlamayı etkinleştirin. Key Vault, diğer güvenlik bilgileri ve olay yönetimi (SIEM) araçlarına kolayca aktarılabilen günlükler sunar. Azure İzleyici Günlükleri, zaten tümleştirilmiş bir hizmet örneğidir.
  • Genel erişimi devre dışı bırak ve Güvenilen Microsoft hizmetlerinin bu güvenlik duvarını atlamasına izin ver'i seçerek Key Vault'u kilitleyin.
  • Otomatik anahtar sürüm güncelleştirmelerini etkinleştirin.

Uyarı

Genel erişimi devre dışı bırak'ı ve Güvenilen Microsoft hizmetleri bu güvenlik duvarını atlamasına izin ver'i seçtikten sonra, portal aracılığıyla Key Vault'ı yönetmek için genel erişimi kullanmaya çalıştığınızda aşağıdakine benzer bir hata alabilirsiniz: "Ağ erişim denetimini etkinleştirdiniz. Bu anahtar kasasına yalnızca izin verilen ağlar erişebilir." Bu hata, müşteri tarafından yönetilen anahtar kurulumu sırasında anahtar sağlama veya sunucu işlemleri sırasında Anahtarları Key Vault'tan getirme özelliğini ortadan kaldırmaz.

  • Müşteri tarafından yönetilen anahtarın bir kopyasını güvenli bir yerde tutun veya emanet hizmetine emanet edin.
  • Anahtarı Key Vault oluşturuyorsa, anahtarı ilk kez kullanmadan önce bir anahtar yedeklemesi oluşturun. Yedeklemeyi yalnızca Key Vault'a geri yükleyebilirsiniz.

Dikkat edilmesi gereken özel noktalar

Azure Key Vault'tan yanlışlıkla anahtar erişimi kaldırılması

Key Vault'ta yeterli erişim haklarına sahip biri, anahtara sunucu erişimini yanlışlıkla şu şekilde devre dışı bırakabilir:

  • Anahtar Kasası'ndaki kimlikten anahtar almak için kullanılan Key Vault Crypto Service Encryption User RBAC rolünün atamasını kaldırma veya izinleri iptal etme.
  • Anahtar siliniyor.
  • Key Vault örneği siliniyor.
  • Key Vault güvenlik duvarı kurallarını değiştirme.
  • Microsoft Entra Id'de sunucunun yönetilen kimliğini silme.

Azure Key Vault'de tutulan anahtarları izleme

Veritabanı durumunu izlemek ve veri şifreleme koruyucusunun erişim kaybına yönelik uyarıları açmak için aşağıdaki Azure özelliklerini yapılandırın:

  • Kaynak durumu: CMK'ye erişimi kaybeden bir veritabanı, veritabanına ilk bağlantı reddedildikten sonra Erişilemez olarak görünür.
  • Etkinlik günlüğü: Müşteri tarafından yönetilen Key Vault örneğinde CMK'ye erişim başarısız olduğunda, girişler etkinlik günlüğüne eklenir. Bu olaylar için en kısa sürede uyarılar oluşturursanız erişimi yeniden devreye alabilirsiniz.
  • Eylem grupları: Tercihlerinize göre bildirim ve uyarı almak için bu grupları tanımlayın.

Müşteri tarafından yönetilen anahtarla yapılandırılmış bir sunucunun yedeklerini geri yükleme

PostgreSQL için Azure Veritabanı esnek sunucu örneğiniz Key Vault'ta depolanan müşteri tarafından yönetilen bir anahtarla şifrelendiğinde, yeni oluşturulan tüm sunucu kopyaları da şifrelenir. Bu yeni kopyayı zamana bağlı geri yükleme (PITR) işlemiyle veya okuma çoğaltmaları aracılığıyla oluşturabilirsiniz.

Müşteri tarafından yönetilen anahtarla veri şifrelemesi ayarlarken, yedekleme geri yükleme veya okuma amaçlı çoğaltma oluşturma gibi işlemler sırasında, birincil ve geri yüklenen veya çoğaltma sunucularında aşağıdaki adımları izleyerek sorunlardan kaçınabilirsiniz:

  • Birincil PostgreSQL için Azure Veri Tabanı Esnek Sunucu örneğinden geri yükleme işlemini veya okuma çoğaltması oluşturma sürecini başlatın.
  • Geri yüklenen veya çoğaltma sunucusunda, müşteri tarafından yönetilen anahtarı ve Key Vault'a erişmek için kullanılan kullanıcı tarafından atanan yönetilen kimliği değiştirebilirsiniz. Yeni oluşturulan sunucuda atanan kimliğin Key Vault üzerinde gerekli izinlere sahip olduğundan emin olun.
  • Geri yükledikten sonra özgün anahtarı iptal etmeyin. Şu anda, müşteri tarafından yönetilen anahtara sahip bir sunucuyu başka bir sunucuya geri yükledikten sonra anahtar iptalini desteklemiyoruz.

Yönetilen HSM'ler

Donanım güvenlik modülleri (HSM'ler), verileri şifrelemek, verilerin şifresini çözmek, dijital imzalar oluşturmak ve dijital sertifikalar oluşturmak için kullanılan anahtarları oluşturarak, koruyarak ve yöneterek şifreleme işlemlerinin güvenliğini sağlamaya yardımcı olan kurcalamaya dayanıklı donanım cihazlarıdır. HSM'ler FIPS 140 ve Ortak Ölçütler dahil olmak üzere en yüksek güvenlik standartlarına göre test edilir, doğrulanır ve onaylanır.

Azure Key Vault Yönetilen HSM, tam olarak yönetilen, yüksek oranda kullanılabilir, tek kiracılı, standartlara uyumlu bir bulut hizmetidir. FIPS 140-3 onaylı HSM'ler aracılığıyla bulut uygulamalarınız için şifreleme anahtarlarını korumak için kullanabilirsiniz.

Azure portalında müşteri tarafından yönetilen anahtarla yeni PostgreSQL için Azure Veritabanı esnek sunucu örnekleri oluştururken, Azure Key Vault'a alternatif olarak anahtar deposu olarak Azure Key Vault Yönetilen HSM'yi seçebilirsiniz. Kullanıcı tanımlı kimlik ve izinler açısından önkoşullar Azure Key Vault ile aynıdır ( bu makalenin önceki bölümlerinde listelendiği gibi). Yönetilen HSM örneği oluşturma, paylaşılan Key Vault tabanlı sertifika deposundan avantajları ve farkları ve anahtarları Yönetilen HSM'ye aktarma hakkında daha fazla bilgi için bkz. Azure Key Vault Yönetilen HSM nedir?.

Müşteri tarafından yönetilen anahtarın erişilemez olma koşulu

Key Vault'ta depolanan müşteri tarafından yönetilen bir anahtarla veri şifrelemeyi yapılandırdığınızda, sunucunun çevrimiçi kalması için bu anahtara sürekli erişim gerekir. Böyle bir durum söz konusu değilse, sunucu durumunu Erişilemez olarak değiştirir ve tüm bağlantıları reddetmeye başlar.

Sunucu durumunun erişilemez duruma gelmesinin olası nedenlerinden bazıları şunlardır:

Nedeni Çözüm
Sunucu tarafından işaret edilen şifreleme anahtarlarından herhangi birinin bitiş tarihi ve saati yapılandırılmıştır ve bu tarih ve saate ulaşılır. Anahtarın bitiş tarihini uzatmanız gerekir. Ardından hizmetin anahtarı yeniden doğrulamasını beklemeniz ve sunucu durumunu otomatik olarak Hazır'a aktarmanız gerekir. Yalnızca sunucu Hazır duruma geri döndüğünde anahtarı daha yeni bir sürüme döndürebilir veya yeni bir anahtar oluşturabilir ve sunucuyu aynı anahtarın yeni sürümüne veya yeni anahtara başvuracak şekilde güncelleştirebilirsiniz.
Anahtarı döndürür ve PostgreSQL için Azure Veri Tabanı Esnek Sunucu örneğini, anahtarın yeni sürümünü işaret edecek şekilde güncellemeyi unutursunuz. Sunucunun işaret ettiği eski anahtarın süresi dolar ve sunucu durumunu Erişilemez duruma getirir. Bu durumu önlemek için anahtarı her döndürdüğünüzde, sunucunuzun örneğini de yeni sürüme işaret eden şekilde güncelleştirdiğinizden emin olun. Bunu yapmak için şu örneği izleyerek kullanınaz postgres flexible-server update: "Veri şifrelemesi için anahtarı/kimliği değiştirme. Veri şifrelemesi sunucu oluşturma işleminden sonra etkinleştirilemiyor, bu yalnızca anahtarı/kimliği güncelleştirir." API'yi kullanarak güncelleştirmeyi tercih ederseniz, hizmetin Sunucular - Güncelleştirme uç noktasını çağırabilirsiniz.
Key Vault örneğini sildiğinizde PostgreSQL için Azure Veritabanı esnek sunucu örneği anahtara erişemez ve erişilemez duruma geçer. Key Vault örneğini kurtarın ve hizmetin anahtarın düzenli aralıklarla yeniden doğrulamasını çalıştırmasını bekleyin ve sunucu durumunu otomatik olarak Hazır durumuna geçin.
Key Vault'ta depolanan şifreleme anahtarlarından herhangi birini almak için kullanılan yönetilen kimliği Microsoft Entra Id'den silersiniz. Kimliği kurtarın ve hizmetin anahtarın düzenli aralıklarla yeniden doğrulamasını çalıştırmasını bekleyin ve sunucu durumunu otomatik olarak Hazır'a geçin.
Key Vault izin modeliniz rol tabanlı erişim denetimini kullanacak şekilde yapılandırılmıştır. Anahtarlardan herhangi birini almak üzere yapılandırılmış yönetilen kimliklerin Anahtar Kasası Kripto Hizmeti Şifreleme Kullanıcısı RBAC rol atamasını kaldırıyorsunuz. RBAC rolünü yönetilen kimliğe yeniden verin ve hizmetin anahtarın düzenli aralıklarla yeniden doğrulanmasını çalıştırmasını bekleyin ve sunucu durumunu otomatik olarak Hazır'a geçirin. Alternatif bir yaklaşım, Key Vault'ta rolü farklı bir yönetilen kimliğe vermek ve sunucuyu anahtara erişmek için bu diğer yönetilen kimliği kullanabilecek şekilde güncelleştirmektir.
Key Vault izin modeliniz erişim ilkelerini kullanacak şekilde yapılandırılmıştır. Yönetilen kimliklerden, liste, get, wrapKey veya unwrapKey erişim ilkelerini, anahtarlardan herhangi birini almak için yapılandırılmış olanlardan kaldırırsınız. RBAC rolünü yönetilen kimliğe yeniden verin ve hizmetin anahtarın düzenli aralıklarla yeniden doğrulanmasını çalıştırmasını bekleyin ve sunucu durumunu otomatik olarak Hazır'a geçirin. Alternatif bir yaklaşım, Key Vault'ta gerekli erişim ilkelerini farklı bir yönetilen kimliğe vermek ve sunucuyu anahtara erişmek için bu diğer yönetilen kimliği kullanabilecek şekilde güncelleştirmektir.
Azure Veritabanı PostgreSQL esnek sunucu örneğinizin Key Vault ile anahtarlarınızı almak için iletişim kurmasını engelleyen aşırı kısıtlayıcı Key Vault güvenlik duvarı kuralları ayarladınız. Bir Key Vault güvenlik duvarı yapılandırırken, PostgreSQL için Azure Veritabanı esnek sunucu örneğinizin güvenlik duvarını atlaması için güvenilen Microsoft hizmetlerine izin verme seçeneğini belirlediğinizden emin olun.

Uyarı

Bir anahtar devre dışı bırakıldığında, silindiğinde, süresi dolduğunda veya erişilemediğinde, bu anahtarla şifrelenmiş verileri olan bir sunucu, daha önce belirtildiği gibi Erişilemez duruma gelir. Sunucu durumu, şifreleme anahtarlarını yeniden doğrulayana kadar yeniden Hazır olarak değişmez.

Genellikle, bir anahtar devre dışı bırakıldıktan, silindikten, süresi dolduktan veya erişilemedikten sonra sunucuya 60 dakika içinde erişilemez duruma gelir. Anahtar kullanılabilir duruma geldikten sonra sunucunun yeniden Hazır duruma gelmesi 60 dakika kadar sürebilir.

Yönetilen kimlik silme işleminden kurtarma

Key Vault'ta depolanan şifreleme anahtarına erişmek için kullanılan kullanıcı tarafından atanan yönetilen kimlik Microsoft Entra Id'de silinirse, kurtarmak için şu adımları izlemeniz gerekir:

  1. Kimliği kurtarın veya yeni bir yönetilen Entra Kimliği kimliği oluşturun.
  2. Silinmeden önce tam olarak aynı ada sahip olsa bile yeni bir kimlik oluşturduysanız, şifreleme anahtarına erişmek için bu yeni kimliği kullanması gereken esnek sunucu örneği özellikleri için Azure Veritabanı'nı güncelleştirin.
  3. Bu kimliğin Azure Key Vault'taki (AKV) anahtar üzerindeki işlemler için uygun izinlere sahip olduğundan emin olun.
  4. Sunucu anahtarı yeniden düzenleyene kadar yaklaşık bir saat bekleyin.

Önemli

Silinmiş kimlikle aynı ada sahip yeni bir Entra ID kimliği oluşturmak, yönetilen bir kimliğin silinmesinden kurtulmayı sağlamaz.

Müşteri tarafından yönetilen anahtarlar ve coğrafi olarak yedekli iş sürekliliği özellikleriyle veri şifrelemeyi kullanma

PostgreSQL için Azure Veritabanı, çoğaltmalar ve coğrafi olarak yedekli yedekleme gibi gelişmiş veri kurtarma özelliklerini destekler. AŞAĞıDA, CMK'lerle veri şifrelemeyi ayarlama gereksinimleri ve CMK'lerle veri şifreleme için temel gereksinimlere ek olarak bu özellikler yer alır:

  • Coğrafi olarak yedekli yedekleme şifreleme anahtarının, coğrafi olarak yedekli yedeklemenin depolandığı bölgede mevcut olması gereken bir Key Vault örneğinde oluşturulması gerekir.
  • Coğrafi olarak yedekli CMK sunucularını desteklemeye yönelik Azure Resource Manager REST API sürümü 2022-11-01-preview'dır. Hem CMK'lerle şifreleme hem de coğrafi olarak yedekli yedekleme özellikleri kullanan sunucuların oluşturulmasını otomatikleştirmek için Azure Resource Manager şablonlarını kullanmak istiyorsanız, bu API sürümünü kullanın.
  • Birincil veritabanının Key Vault örneğinde ve coğrafi olarak yedekli yedekleme için şifreleme anahtarını barındıran Key Vault örneğinde kimlik doğrulaması yapmak için aynı kullanıcı tarafından yönetilen kimliği kullanamazsınız. Bölgesel dayanıklılığı korumak için, coğrafi olarak yedekli yedeklemelerle aynı bölgede kullanıcı tarafından yönetilen kimliği oluşturmanızı öneririz.
  • Oluşturma sırasında CMK'lerle şifrelenecek bir okuma amaçlı çoğaltma veritabanı ayarlarsanız, şifreleme anahtarının okuma amaçlı çoğaltma veritabanının bulunduğu bölgedeki bir Key Vault örneğinde olması gerekir. Bu Key Vault örneğinde kimlik doğrulaması yapmak için kullanıcı tarafından atanan kimliğin aynı bölgede oluşturulması gerekir.

Kiracılar arası müşteri tarafından yönetilen anahtarlar (CMK) (önizleme)

Müşteri tarafından yönetilen kiracılar arası anahtarlar, PostgreSQL için Azure Veri Tabanı esnek sunucu örneğinizin ait olduğundan farklı bir Microsoft Entra ID'ye ait olan bir Key Vault veya Yönetilen HSM örneğinde depolanan şifreleme anahtarlarını kullanmanıza olanak tanır. Kiracılar arası CMK kurulumu, kiracılar arasında ek yapılandırma ve koordinasyon gerektirir. Kiracılar arası senaryoda, PostgreSQL için Azure Veri Tabanı kaynağı hizmet sağlayıcısı olarak adlandırılan Bağımsız Yazılım Satıcısı (ISV) tarafından yönetilen bir kiracıda bulunur. PostgreSQL için Azure Veri Tabanı kaynağını şifrelemek için kullanılan anahtar, müşterinin yönettiği farklı bir kiracıdaki bir anahtar kasasında bulunur.

Kuruluma genel bakış

ISV kiracısı üzerinde

İstemci kiracıda

  1. Çok kiracılı uygulamayı yükleyin

  2. Oluşturun veya mevcut anahtar kasasını ya da yönetilen HSM'yi kullanın ve çok kiracılı uygulamaya anahtar izinleri verin

    1. Yeni anahtar oluşturma veya mevcut anahtarı kullanma

    2. Anahtarı Azure Key Vault veya Azure Yönetilen HSM'den alın ve Anahtar Tanımlayıcısı'nı kaydedin

ISV kiracısı üzerinde

Bu noktaya kadar, hizmet sağlayıcısının kiracısı üzerinde çok kiracılı uygulamayı yapılandırdınız. Uygulamayı müşterinin kiracısına yüklediniz ve anahtar kasasını ve anahtarı müşterinin kiracısında yapılandırdınız. Ardından hizmet sağlayıcısının kiracısı üzerinde bir PostgreSQL için Azure Veri Tabanı örneği oluşturabilir ve müşterinin kiracısından alınan anahtarla müşteri tarafından yönetilen anahtarları yapılandırabilirsiniz.

Müşteri tarafından yönetilen anahtarlarla bir PostgreSQL için Azure Veri Tabanı örneği oluşturduğunuzda, müşterinin kullandığı anahtarlara erişimi olduğundan emin olmanız gerekir. Tek kiracılı senaryolarda, PostgreSQL için Azure Veri Tabanı örneğinin kullanıcı tarafından yönetilen kimliğine Key Vault’a doğrudan erişim verirsiniz. Kiracılar arası bir senaryoda, anahtar kasası müşterinin yönettiği başka bir kiracıda bulunduğundan artık anahtar kasasına doğrudan erişime güvenemezsiniz. Bu kısıtlama nedeniyle, önceki bölümlerde kiracılar arası bir uygulama oluşturdunuz ve müşterinin anahtar kasasına erişim sağlamak üzere uygulama içinde bir yönetilen kimlik kaydettiniz. Kiracılar arası uygulama kimliğiyle birlikte bu yönetilen kimlik, PostgreSQL için Azure Veri Tabanı örneği için kiracılar arası CMK oluştururken kullandığınız kimliktir.

Anahtar kasasında anahtarın yeni bir sürümü kullanılabilir olduğunda, PostgreSQL için Azure Veri Tabanı örneği yeni sürümü otomatik olarak alır.

Azure portalını kullanma

Azure portalında yeni bir PostgreSQL için Azure Veri Tabanı örneği için kiracılar arası müşteri tarafından yönetilen anahtarları yapılandırmak üzere şu adımları izleyin:

  1. PostgreSQL için Azure Veri Tabanı oluşturma kaynağında, Azure portalındaGüvenlik sekmesini ve ardından Customer tarafından yönetilen anahtar seçin.

  2. Oluşturulan kullanıcı tarafından atanan yönetilen kimliği Kullanıcı tarafından atanan yönetilen kimlik olarak atayın.

  3. Uygulama adını kullanarak Çok kiracılı uygulamayı atayın.

  4. Müşterinin istemci kiracısından alınan Anahtar Tanımlayıcısını kullanarak Anahtar Seçimi yöntemine bir Anahtar tanımlayıcısı girin.

Azure Resource Manager JSON şablonlarını ve REST API'sini kullanma

Aşağıdaki belirli parametrelerle bir ARM şablonu dağıtın:

Uyarı

Bu örneği Azure Resource Manager şablonlarınızdan birinde yeniden oluşturıyorsanız, apiVersion veya daha yeni sürümlerin 2025-03-15-privatepreview kullanın.

Parametre Description Örnek değer
primaryKeyUri Hizmet sağlayıcısının anahtar kasasında bulunan müşteri tarafından yönetilen anahtarın tanımlayıcısı. https://my-vault.vault.azure.com/keys/my-key
primaryUserAssignedIdentity Yönetilen kimliğin PostgreSQL için Azure Veri Tabanı örneğine atanması gerektiğini belirten nesne. "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
primaryFederatedIdentityClientId Çok kiracılı Microsoft Entra uygulamasına ait istemci kimliği. application-client-id

Üç parametrenin yapılandırıldığı rest API örneği aşağıda verilmiştir:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

İstek gövdesi örneği:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Aşağıda anahtar döndürme için REST API örneği verilmiştir. PATCH örneği, sunucuyu yeniden oluşturmadan şifreleme anahtarını döndürmek için yalnızca CMK anahtarı URI'sini güncelleştirir.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

İstek gövdesi (anahtar döndürme örneği):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Önemli

Yalnızca primaryKeyUri'yi güncelleştirseniz bile, istek gövdesinde tüm veri şifreleme özelliklerini belirtmeniz gerekir. İstek gövdesinde primaryFederatedIdentityClientId belirtmezseniz, istek kiracılar arası olmayan bir CMK yapılandırması olarak değerlendirilir.

Kiracılar arası müşteri tarafından yönetilen anahtarlar (CMK) önizlemesinin sınırlamaları

  • Bu özellik henüz Azure PowerShell veya Azure CLI desteklenmez.
  • Coğrafi olarak yedekli yedeklemeler içeren bir sunucu oluşturulması ve uzun süreli saklama yedekleme işlemlerinin etkinleştirilmesi şu anda desteklenmemektedir.
  • Önizleme şu anda yalnızca şu bölgelerde desteklenmektedir:
    • Doğu ABD 2
    • Batı ABD 2
    • ABD Orta
    • Australia Southeast
    • Australia East
    • North Europe

Müşteri tarafından yönetilen anahtarların (CMK) sınırlamaları

PostgreSQL için Azure Veritabanı esnek sunucu örneğinde müşteri tarafından yönetilen anahtarı yapılandırmaya yönelik geçerli sınırlamalar şunlardır:

İlgili içerik

  • Last updated on