Yönetilen HSM'de temel egemenlik, kullanılabilirlik, performans ve ölçeklenebilirlik
Şifreleme anahtarları, ister şirket içinde ister bulutta olsun modern bilgisayar sistemlerinin güvenliğini sağlamaya yönelik güvenin kökü olur. Bu nedenle, bu anahtarlar üzerinde kimlerin yetki sahibi olduğunu denetlemek, güvenli ve uyumlu uygulamalar oluşturmak için kritik öneme sahiptir.
Azure'da, bulutta anahtar yönetiminin nasıl yapılması gerektiğine ilişkin vizyonumuz temel egemenliktir. Anahtar hakimiyeti, bir müşterinin kuruluşunun anahtarlara kimlerin erişebileceği ve anahtar yönetimi ilkelerini değiştirebileceği ve Bu anahtarları hangi Azure hizmetlerinin kullanabileceği üzerinde tam ve özel denetime sahip olduğu anlamına gelir. Müşteri bu kararlar verdikten sonra Microsoft personelinin bu kararları değiştirmesi teknik yollarla engellenir. Anahtar yönetimi hizmet kodu, müşteri aksini söyleyene ve Microsoft personeli müdahale edinceye kadar müşterinin kararlarını yürütür.
Aynı zamanda, buluttaki her hizmetin tam olarak yönetilmesi gerektiğine inancımız tamdır. Hizmet, hizmet düzeyi sözleşmeleri (SLA) tarafından desteklenerek gerekli kullanılabilirlik, dayanıklılık, güvenlik ve bulut temel vaatlerini sağlamalıdır. Yönetilen hizmet sunmak için Microsoft'un anahtar yönetimi sunucularına düzeltme eki uygulamalı, donanım güvenlik modülü (HSM) üretici yazılımını yükseltmesi, başarısız olan donanımı iyileştirmesi, yük devretme gerçekleştirmesi ve diğer yüksek ayrıcalıklı işlemleri yapması gerekir. Çoğu güvenlik uzmanının bildiği gibi, sistem içindeki verilere yüksek ayrıcalıklı veya fiziksel erişimi olan birini reddetmek zor bir sorundur.
Bu makalede, Azure Key Vault Yönetilen HSM hizmetinde bu sorunu nasıl çözdüğümiz açıklanır ve müşterilere HSM'lerle eşleştirilmiş gizli bilgi işlem teknolojisini kullanarak hem tam anahtar hakimiyeti hem de tam olarak yönetilen hizmet SLA'ları sağlanır.
Yönetilen HSM donanım ortamı
Herhangi bir Azure bölgesindeki müşterinin Yönetilen HSM havuzu güvenli bir Azure veri merkezindedir. Üç örnek birkaç sunucuya yayılır. Yedeklilik sağlamak için her örnek farklı bir rafa dağıtılır. Her sunucunun birden çok şifreleme çekirdeğine sahip bir FIPS 140-2 Düzey 3 onaylı Marvell LiquidSecurity HSM Bağdaştırıcısı vardır. Çekirdekler, tamamen yalıtılmış kimlik bilgileri, veri depolama ve erişim denetimi dahil olmak üzere tamamen yalıtılmış HSM bölümleri oluşturmak için kullanılır.
Veri merkezi içindeki örneklerin fiziksel ayrımı, tek bir bileşenin (örneğin, raf üstü anahtarı veya bir raftaki güç yönetimi birimi) kaybının havuzun tüm örneklerini etkilemediğinden emin olmak için kritik önem taşır. Bu sunucular Azure Güvenlik HSM ekibine ayrılmıştır. Sunucular diğer Azure ekipleriyle paylaşılmaz ve bu sunuculara hiçbir müşteri iş yükü dağıtılmaz. Kilitli raflar dahil olmak üzere fiziksel erişim denetimleri, sunuculara yetkisiz erişimi önlemek için kullanılır. Bu denetimler FedRAMP-High, PCI, SOC 1/2/3, ISO 270x ve diğer güvenlik ve gizlilik standartlarını karşılar ve Azure uyumluluk programının bir parçası olarak düzenli olarak bağımsız olarak doğrulanır. HSM'ler, FIPS 140-2 Düzey 3 gereksinimlerini karşılayacak şekilde doğrulanmış gelişmiş fiziksel güvenliğe sahiptir. Yönetilen HSM hizmetinin tamamı, gelişmiş kalıcı tehditlere karşı koruma sağlayan güvenilir başlatma dahil olmak üzere standart güvenli Azure platformunun üzerine kurulmuştur.
HSM bağdaştırıcıları onlarca yalıtılmış HSM bölümünü destekleyebilir. Her sunucuda çalıştırmak Node Service adlı bir denetim işlemidir. Node Service, her bağdaştırıcının sahipliğini alır ve bağdaştırıcı sahibi için kimlik bilgilerini (bu durumda Microsoft) yükler. HSM, bağdaştırıcının sahipliğinin Microsoft'a müşteri bölümlerinde depolanan verilere erişim sağlamaması için tasarlanmıştır. Yalnızca Microsoft'un müşteri bölümleri oluşturmasına, yeniden boyutlandırmasına ve silmesine izin verir. Müşteri için herhangi bir bölümün gizli yedeklerini almayı destekler. Kör yedeklemede yedekleme, hizmet kodu tarafından yalnızca müşteriye ait olan ve içeriği Microsoft tarafından okunamayan Yönetilen HSM örneğinin içinde geri yüklenebilen, müşteri tarafından sağlanan bir anahtarla sarmalanır.
Yönetilen HSM havuzunun mimarisi
Şekil 1'de kullanılabilirliği desteklemek için her biri kendi veri merkezi rafında bir HSM sunucusunda çalışan üç Linux VM'lerinden oluşan bir HSM havuzunun mimarisi gösterilmektedir. Önemli bileşenler şunlardır:
- HSM doku denetleyicisi (HFC), hizmetin kontrol düzlemidir. HFC, havuz için otomatik düzeltme eki uygulama ve onarım işlemleri gerçekleştirir.
- Her biri bir HSM örneğine bağlı üç Intel Secure Guard Uzantısı (Intel SGX) gizli kuşatması da dahil olmak üzere her müşteriye özel FIPS 140-2 Düzey 3 uyumlu şifreleme sınırı. Bu sınırın kök anahtarları oluşturulur ve üç HSM'de depolanır. Bu makalenin devamında açıkladığımız gibi, Microsoft ile ilişkilendirilmiş hiçbir kişi bu sınırın içindeki verilere erişemiyor. Yalnızca Müşteri adına hareket eden Intel SGX kapanımında (Node Service aracısı dahil) çalışan hizmet koduna erişim sağlanır.
Güvenilen yürütme ortamı (TEE)
Yönetilen HSM havuzu üç hizmet örneğinden oluşur. Her hizmet örneği, Intel SGX özelliklerini ve Açık Kapanım SDK'sını kullanan güvenilir bir yürütme ortamı (TEE) olarak uygulanır. TEE içinde yürütme, hizmeti barındıran sanal makinede (VM) veya VM'nin konak sunucusundaki hiçbir kişinin müşteri gizli dizilerine, verilerine veya HSM bölümüne erişimi olmamasını sağlar. Her TEE belirli bir müşteriye ayrılmıştır ve HSM bölümüne TLS yönetimi, istek işleme ve erişim denetimi çalıştırır. Güvenlik etki alanı paketinin bir parçası dışında, bu TEE'nin dışındaki düz metinde hiçbir kimlik bilgisi veya müşteriye özgü veri şifreleme anahtarı yoktur. Bu paket müşteri tarafından sağlanan bir anahtarla şifrelenir ve havuzu ilk oluşturulduğunda indirilir.
TEE'ler, tasdikli TLS kullanarak kendi aralarında iletişim kurar. Attested TLS, Intel SGX platformunun uzaktan kanıtlama özelliklerini TLS 1.2 ile birleştirir. Bu, ORTAdaki adam saldırılarını önlemek için TEE'deki Yönetilen HSM kodunun iletişimini yalnızca aynı Yönetilen HSM hizmeti kod imzalama anahtarı tarafından imzalanan diğer kodlarla sınırlamasına olanak tanır. Yönetilen HSM hizmetinin kod imzalama anahtarı Microsoft Ürün Sürümü ve Güvenlik Hizmeti'nde (örneğin, Windows kod imzalama anahtarını depolamak için de kullanılır) depolanır. Anahtar, Yönetilen HSM ekibi tarafından denetlenmektedir. Değişiklik yönetimine yönelik mevzuat ve uyumluluk yükümlülüklerimizin bir parçası olarak, bu anahtar başka bir Microsoft ekibi tarafından kodunu imzalamak için kullanılamaz.
TEE-TEE iletişimi için kullanılan TLS sertifikaları, TEE içindeki hizmet kodu tarafından kendi kendine verilir. Sertifikalar, sunucudaki Intel SGX kapanım tarafından oluşturulan bir platform raporu içerir. Platform raporu, Intel tarafından üretilen CPU'ya birleştirilmiş anahtarlardan türetilen anahtarlarla imzalanır. Rapor, kod imzalama anahtarı ve ikili karması ile Intel SGX kapanıma yüklenen kodu tanımlar. Bu platform raporundan hizmet örnekleri, yönetilen HSM hizmeti kod imzalama anahtarı tarafından da bir eş imzalandığını belirleyebilir ve platform raporu aracılığıyla bazı şifreleme dolanıklığıyla, dış kimliğe bürünmeyi önlemek için kendi kendine verilen sertifika imzalama anahtarının da TEE içinde oluşturulmuş olması gerektiğini belirleyebilir.
Müşteri tarafından yönetilen tam anahtar denetimine sahip kullanılabilirlik SLA'ları sunma
Yüksek kullanılabilirlik sağlamak için HFC hizmeti, müşteri tarafından seçilen Azure bölgesinde üç havuz oluşturur.
Yönetilen HSM havuzu oluşturma
Yönetilen HSM havuzlarının yüksek kullanılabilirlik özellikleri, her zaman eşitlenmiş durumda tutulan otomatik olarak yönetilen, üçlü yedekli HSM örneklerinden gelir (veya çok bölgeli çoğaltma kullanıyorsanız, altı örneğin tümünü eşitlenmiş durumda tutmaktan). Havuz oluşturma, müşterinin seçtiği Azure bölgesindeki kullanılabilir donanımlar arasında havuzları ayıran HFC hizmeti tarafından yönetilir.
Yeni bir havuz istendiğinde HFC, HSM bağdaştırıcılarında kullanılabilir alanı olan çeşitli raflarda üç sunucu seçer ve ardından havuzu oluşturmaya başlar:
HFC, üç TEE'nin her birinde Node Service aracılarına bir dizi parametre kullanarak hizmet kodunun yeni bir örneğini başlatmalarını sağlar. Parametreler müşterinin Microsoft Entra kiracısını, üç örneğin de iç sanal ağ IP adreslerini ve diğer bazı hizmet yapılandırmalarını tanımlar. Bir bölüm rastgele birincil olarak atanır.
Üç örnek başlar. Her örnek, yerel HSM bağdaştırıcısındaki bir bölüme bağlanır ve ardından rastgele oluşturulan kullanıcı adları ve kimlik bilgilerini kullanarak bölümü sıfırlar ve başlatır (bölüme bir insan işleci veya başka bir TEE örneği tarafından erişilememesini sağlamak için).
Birincil örnek, HSM'de oluşturulan özel anahtarı kullanarak bir bölüm sahibi kök sertifikası oluşturur. Bu kök sertifikayı kullanarak HSM bölümü için bölüm düzeyi sertifika imzalayarak havuzun sahipliğini oluşturur. Birincil, hizmet içindeki bekleyen tüm müşteri verilerini korumak için kullanılan bir veri şifreleme anahtarı da oluşturur. Anahtar malzeme için, HSM anahtar malzemenin kendisini de koruduğundan çift sarmalama kullanılır.
Ardından, bu sahiplik verileri iki ikincil örnekle eşitlenir. Her ikincil, tasdikli TLS kullanarak birincil ile iletişim kurar. Birincil, bölüm sahibi kök sertifikasını özel anahtar ve veri şifreleme anahtarıyla paylaşır. İkinciller artık kendi HSM bölümlerine bölüm sertifikası vermek için bölüm kök sertifikasını kullanır. Bu işlem tamamlandıktan sonra, aynı bölüm kök sertifikasına sahip olan üç ayrı sunucuda HSM bölümleriniz vardır.
Doğrulanmış TLS bağlantısı üzerinden, birincilin HSM bölümü, HSM satıcısı tarafından sağlanan güvenli bir API'yi kullanarak oluşturulan veri sarmalama anahtarıyla (üç HSM arasındaki iletileri şifrelemek için kullanılır) ikincillerle paylaşır. Bu değişim sırasında, HSM'ler aynı bölüm sahibi sertifikasına sahip olduklarını onaylar ve ardından iletileri şifrelemek için Diffie-Hellman şemasını kullanırlar, böylece Microsoft hizmet kodu bunları okuyamaz. Hizmet kodunun tek yaptığı HSM'ler arasında opak blobları taşımaktır.
Bu noktada üç örnek de müşterinin sanal ağında havuz olarak kullanıma sunulmaya hazırdır. Aynı bölüm sahibi sertifikasını ve özel anahtarı, aynı veri şifreleme anahtarını ve ortak bir veri sarmalama anahtarını paylaşırlar. Ancak, her örneğin kendi HSM bölümleri için benzersiz kimlik bilgileri vardır. Artık son adımlar tamamlanmıştır.
Her örnek, genel kullanıma yönelik TLS sertifikası için bir RSA anahtar çifti ve bir sertifika imzalama isteği (CSR) oluşturur. CSR, Microsoft ortak anahtar altyapısı (PKI) sistemi tarafından bir Microsoft ortak kökü kullanılarak imzalanır ve sonuçta elde edilen TLS sertifikası örneğe döndürülür.
Üç örnek de kendi Intel SGX sızdırmazlık anahtarını yerel CPU'larından alır. Anahtar, CPU'nun kendi benzersiz anahtarı ve TEE'nin kod imzalama anahtarı kullanılarak oluşturulur.
Havuz, Intel SGX sızdırmazlık anahtarlarından benzersiz bir havuz anahtarı türetir, bu havuz anahtarını kullanarak tüm gizli dizilerini şifreler ve ardından şifrelenmiş blobları diske yazar. Bu blobların şifresi yalnızca aynı fiziksel CPU üzerinde çalışan aynı Intel SGX sızdırmazlık anahtarı tarafından kod imzalanarak çözülebilir. Gizli diziler bu örneğe bağlıdır.
Güvenli önyükleme işlemi tamamlandı. Bu işlem hem üçlü yedekli HSM havuzu oluşturulmasına hem de müşteri verilerinin egemenliğini şifreleme garantisinin oluşturulmasına olanak sağlamıştır.
Gizli hizmet düzeltme kullanarak çalışma zamanında kullanılabilirlik SLA'larını koruma
Bu makalede açıklanan havuz oluşturma hikayesi, Yönetilen HSM hizmetinin hizmeti temel alan sunucuları güvenli bir şekilde yöneterek yüksek kullanılabilirlik SLA'larını nasıl sunabildiğini açıklayabilir. Bir sunucunun, HSM bağdaştırıcısının, hatta rafın güç kaynağının başarısız olduğunu düşünün. Yönetilen HSM hizmetinin amacı, müşteri müdahalesi olmadan veya gizli dizilerin TEE dışında net bir metinde kullanıma sunulma olasılığı olmadan havuzu üç iyi durumda örneğe geri döndürmektir. Bu, gizli hizmet iyileştirmesi ile gerçekleştirilir.
HFC'nin başarısız sunucuda örnekleri olan havuzları algılamasıyla başlar. HFC, yeni örneklerin dağıtılacağı havuzun bölgesindeki yeni ve iyi durumdaki sunucuları bulur. İlk sağlama adımı sırasında tam olarak ikincil olarak kabul edilen yeni örnekler başlatır: HSM'yi başlatın, birincil anahtarını bulun, doğrulanmış TLS üzerinden gizli dizileri güvenli bir şekilde değiştirin, HSM'yi sahiplik hiyerarşisinde imzalayın ve ardından hizmet verilerini yeni CPU'suna mühürleyin. Hizmet artık tamamen otomatik ve tamamen gizli olarak iyileştirilmiştir.
Güvenlik etki alanını kullanarak olağanüstü durumdan kurtarma
Güvenlik etki alanı, HSM bölümünü sıfırdan yeniden oluşturmak için gereken tüm kimlik bilgilerini içeren güvenli bir blobdur: bölüm sahibi anahtarı, bölüm kimlik bilgileri, veri sarmalama anahtarı ve HSM'nin ilk yedeklemesi. Hizmet canlı hale gelmeden önce müşterinin güvenlik etki alanını güvenli hale getirmek için bir dizi RSA şifreleme anahtarı sağlayarak indirmesi gerekir. Güvenlik etki alanı verileri TEE'lerden kaynaklanır ve oluşturulan bir simetrik anahtar ve anahtar paylaşımlarını müşteri tarafından seçilen çekirdek parametrelerine göre müşteri tarafından sağlanan RSA ortak anahtarları arasında bölen Shamir Gizli Dizi Paylaşımı algoritması uygulamasıyla korunur. Bu işlem sırasında hiçbir hizmet anahtarı veya kimlik bilgisi, TEE'lerde çalışan hizmet kodunun dışında düz metin olarak gösterilmez. Yalnızca müşteri, RSA anahtarlarının bir çekirdeğini TEE'ye sunarak bir kurtarma senaryosu sırasında güvenlik etki alanının şifresini çözebilir.
Güvenlik etki alanı yalnızca bir felaket nedeniyle azure bölgesinin tamamı kaybolduğunda ve Microsoft havuzun üç örneğini aynı anda kaybettiğinde gereklidir. Yalnızca bir örnek, hatta iki örnek kaybolursa, gizli hizmet iyileştirmesi müşteri müdahalesi olmadan sessizce üç iyi durumdaki örneğe kurtarılır. Intel SGX sızdırmazlık anahtarları her CPU için benzersiz olduğundan bölgenin tamamı kaybolursa, Microsoft'un HSM kimlik bilgilerini ve bölüm sahibi anahtarlarını kurtarma yolu yoktur. Bunlar yalnızca örnekler bağlamında bulunur.
Bu felaketin son derece olası olmayan bir durumda, müşteri yeni bir boş havuz oluşturarak, bunu güvenlik etki alanına ekleyerek ve ardından güvenlik etki alanının sahipliğini kanıtlamak için RSA anahtarı çekirdeğini sunarak önceki havuz durumunu ve verilerini kurtarabilir. Bir müşteri çok bölgeli çoğaltmayı etkinleştirdiyse, havuzu güvenlik etki alanından kurtarmak için müşteri müdahalesi gerekmeden önce her iki bölgenin de aynı anda karşılaşma olasılığı daha düşük olan bir felaket, tam hatanın gerçekleşmesi gerekir.
Hizmete erişimi denetleme
Açıklandığı gibi, gerekli kimlik bilgileri müşteriye veya başka birine verilmediğinden, TEE'deki hizmet kodumuz HSM'nin kendisine erişimi olan tek varlıktır. Bunun yerine, müşterinin havuzu Kendi Microsoft Entra örneğine bağlıdır ve bu kimlik doğrulaması ve yetkilendirme için kullanılır. İlk sağlama sırasında müşteri, havuz için Yönetici istrator rolünü atamak üzere bir ilk çalışan kümesi seçebilir. Bu kişiler ve müşterinin Microsoft Entra kiracısı Genel Yönetici istrator rolündeki çalışanlar, havuz içinde erişim denetimi ilkeleri ayarlayabilir. Tüm erişim denetimi ilkeleri, hizmet tarafından maskelenmiş anahtarlar ile aynı veritabanında depolanır ve bunlar da şifrelenir. Yalnızca TEE'deki hizmet kodu bu erişim denetimi ilkelerine erişebilir.
Özet
Yönetilen HSM, son teknoloji, donanım destekli, gizli kapanım teknolojisini kullanarak müşterilerin kullanılabilirlik ile şifreleme anahtarları üzerinde denetim arasında denge kurma gereksinimini ortadan kaldırır. Bu makalede açıklandığı gibi, bu uygulamada hiçbir Microsoft personeli veya temsilcisi, Yönetilen HSM konak makinelerine ve HSM'lere fiziksel erişimle bile müşteri tarafından yönetilen anahtar materyallerine veya ilgili gizli dizilere erişemez. Bu güvenlik finansal hizmetler, üretim, kamu sektörü, savunma ve diğer dikey sektörlerdeki müşterilerimizin buluta geçişlerini tam güvenle hızlandırmalarına olanak sağlamıştır.