Azure Managed HSM’de Harici Anahtar Yönetimi: Public Preview

Bir soruyla başlayayım: Anahtarınızın Microsoft’un veri merkezinde durması sizi rahatsız ediyor mu? Bugüne kadar “Managed HSM zaten single-tenant, FIPS 140-3 Level 3, Microsoft görmüyor” dediğimizde kurumsal müşterilerin büyük çoğunluğu ikna oluyordu. Ama bazıları — özellikle regüle sektörlerde çalışanlar — hâlâ şu cümleyi kuruyordu: “Tamam ama fiziksel olarak da Microsoft’un binasında olmasın.”

İlginç olan şu ki, İşte tam da bu talebi karşılamak için Microsoft, External key management özelliğini Azure Key Vault Managed HSM için public preview’a aldı (bu konuda ikircikliyim). Bir yıl önce verilmiş bir sözün karşılığı yanı. Ve açık konuşayım, bu özellik sanıldığı kadar herkese hitap etmiyor —. Hitap ettiği kesim için gerçekten ciddi bir hamle.

Önce Managed HSM Zaten Ne Sunuyordu?

Harici anahtar yönetimine geçmeden önce bir durup bakmak lazım. Çünkü sahada sık gördüğüm bir şey var: Birçok kurum, Managed HSM’in hali hazırda ne kadar sağlam bir egemenlik (sovereignty) modeli sunduğunu tam bilmiyor; sonra da gereksiz yere “harici HSM” tarafına kayıyorlar, halbuki mesele çoğu zaman orada değil.

Çok konuştum, örnekle göstereyim.

Managed HSM tek kiracılı (single-tenant) bir servis. Yanı her müşteri için ayrı, adanmış bir küme kuruluyor — Marvell LiquidSecurity kartları üstünde çalışan, FIPS 140-3 Level 3 doğrulamalı HSM partition’lar bunlar — ve anahtarınız o donanımın içinde üretiliyor, düz metin olarak dışarı hiç çıkmıyor, Microsoft operatörleri de göremiyor; işin aslı biraz sert ama güven veren tarafı da bu.

Kontrolün Gerçekten Sizde Olduğunu Nereden Anlıyorsunuz?

Bak şimdi, burada dört tane temel nokta var:

• Security domain: Her HSM kümesi, sizin ürettiğiniz ve sahip olduğunuz bir kriptografik alanla izole ediliyor. Microsoft bu domain olmadan anahtarlarınızı çözemez, kümeyi de kurtaramaz. Domain’i korumak tamamen sizin işiniz — evet, bilerek böyle tasarlanmış.
• Quorum tabanlı çoklu kişi kontrolü: Security domain, offline tuttuğunuz RSA anahtar çiftlerinden oluşan bir quorum ile korunuyor. Tek bir kişi — ister sizden olsun ister Microsoft’tan — tek başına ilerleyemiyor. Bu da bazen uğraştırıyor ama açık konuşayım, iyi ki öyle.
• Local RBAC: Azure RBAC’ten ayrı duran data-plane seviyesinde başka bir yetkilendirme modeli var. Hangi kriptografik operasyonu kimin yapacağını burası belirliyor. Kısacası rol tanımı bulut portalında bitmiyor.
• Key attestation: Anahtarın gerçekten FIPS 140-3 Level 3 sınırları içinde üretildiğine ve kullanıldığına dair kriptografik kanıt alabiliyorsunuz. Kulağa teknik geliyor, ama sahada baya iş görüyor. — bunu es geçmeyin

Bunun üstüne Intel SGX tabanlı confidential computing katmanı eklenince — request handling, access control. Anahtar materyali donanım enclave’lerinde izole oluyor — ortaya şöyle bir tablo çıkıyor: Microsoft’un fiziksel olarak host’a erişimi olsa bile okuyamayacağı bir yapı kuruluyor; yanı kağıt üstünde değil, pratikte de epey sıkı dürüyor.

Yanı şunu net söyleyeyim: Managed HSM’in mevcut halini kullanan kurumların büyük çoğunluğu için “harici anahtar” ihtiyacı teknik değil, regülatif ya da biraz da psikolojik bir gerekliliktir. Bu ayrımı yapmak önemli.

Peki External Key Management Tam Olarak Ne Getiriyor?

Kısa cevap şu: anahtar materyalini, sizin sahip olduğunuz ve işlettiğiniz bir HSM üzerinde tutma seçeneği veriyor (ben de ilk duyduğumda şaşırmıştım). On-premises olabilir, güvendiğiniz bir üçüncü taraf sağlayıcıda da olabilir. Yeter ki Microsoft altyapısının dışında kalsın; işin özü bu.

Uzun tarafı biraz daha karışık, ama çok da büyütmeyelim. Azure servisleriyle entegrasyon devam ediyor, yanı Storage encryption, SQL TDE, Disk Encryption gibi senaryolar çalışmaya devam ediyor (evet, burada hayatı nokta bu), fakat root key fiziksel olarak sizin kontrolünüzdeki donanımda dürüyor (inanın bana). Managed HSM de bu harici anahtara referans veren bir proxy gibi davranıyor diyebiliriz; ilk bakışta garip geliyor ama pratikte baya iş görüyor.

Bunu biraz açayım.

Bu Model Kime Lazım?

Sahada en çok şu profilleri görüyorum; hani listeyi okuyunca “tamam, bunlar. Mecbur” diyorsunuz ya, aynen o tip işler. Bir tarafta regülatif zorunluluğu olan finansal kurumlar var (özellikle bazı Avrupa ülkeleri ve Ortadoğu tarafında), diğer tarafta kamu ve savunma var; ayrıca enerji ile telekom altyapısı da boş geçmiyor.

1. Regülatif zorunluluğu olan finansal kurumlar: Bilhassa bazı Avrupa ülkelerinde ve Ortadoğu’da, “hayatı kripto materyalinin yurt içinde ve kurumun fiziksel kontrolünde olması” şart koşuluyor.
2. Kamu ve savunma: Egemenlik konusunda sıfır esneklik olan sektörler. Bunlar için harici HSM zaten var olan bir standart; Azure sadece biraz geç gelmişti denebilir.
3. Enerji ve telekom altyapısı: Bazı ülkelerde kilit altyapı operatörleri için özel şartlar var, yanı mevzuat işi burada da kapıyı çalıyor.
4. Çoklu bulut stratejisi olan büyük gruplar: Aynı anahtarı hem Azure’da hem AWS’de hem de kendi veri merkezinde kullanmak isteyen holdingler için tek noktadan yönetim gerçekten cazip olabiliyor.

Şunu fark ettim: Eğer bu listedeki senaryolardan birine girmiyorsanız, açık konuşayım: harici HSM’e ihtiyacınız büyük ihtimalle yok. Yönetim yükü artıyor, maliyet artıyor, operasyonel karmaşıklık da cabası; yanı kağıt üstünde güzel duran şey sahada bazen insanın başını ağrıtıyor.

Peki neden herkes buna atlamıyor? Çünkü her ekstra güvenlik katmanı otomatik olarak rahatlık getirmiyor. Bazen tam tersi oluyor; ekipler anahtar yaşam döngüsünü yönetmekle uğraşırken asıl işlerini biraz ağırdan almak zorunda kalabiliyorlar.

Tam da öyle.

Türkiye Perspektifi: Bu Bize Ne İfade Ediyor?

Türkiye’deki kurumsal müşterilerde gördüğüm tablo biraz farklı ilerliyor. Şimdi, peki neden? Çünkü KVKK, BDDK. Benzeri düzenleyiciler için asıl mesele çoğu zaman verinin nerede durduğu oluyor; kripto anahtarının fiziksel konumu işe henüz o kadar ince bir seviyeye inmiş değil, en azından sahada ben öyle net görmüyorum.

Aslında, Bir de Azure’ın Türkiye bölgesi yok. Bu yüzden Türkiye trafiği çoğunlukla Kuzey Avrupa ya da Batı Avrupa üzerinden akıyor, bankalar da egemenlik hassasiyeti varsa zaten yıllardır on-prem HSM veya hibrit modellere yaslanıyor; yanı işin sırrı yeni değil, sadece bu yeni model bazı kapıları biraz aralıyor.

Hmm, bunu nasıl anlatsamdı…

İşte tam burada External Key Management devreye giriyor. Büyük bankalar. Kamu tarafında Azure’a geçişi tutan son teknik bariyeri kaldırabilir gibi dürüyor, ama açık konuşayım, bu işin bir de operasyon tarafı var: Kendi HSM’ınızı işletmeye hazır mısınız, SLA’yi kim taşıyacak, yedekleme nasıl olacak (quorum yönetimi dahil), bunların hepsi sizin masada dürüyor.

İnanın, Evet.

Yukarıda anlattığım şey şu aslında: Teknik olarak yol açılıyor, ama yolun kenarında duran bakım işleri de size bakıyor. Şey, ilk bakışta “tamamdır” diyorsunuz; sonra anahtar döngüsü, erişim politikaları ve kurtarma senaryoları çıkınca tablo biraz değişiyor. Sız ne dersiniz?

Enterprise mi, Küçük Ekip mi? Karar Matrisi

Bu tip işlerde bana en çok gelen soru şu oluyor: “Biz de bunu devreye alalım mı?” Cevap, ne yazık ki, tek satırlık değil. Hatta bazen ilk bakışta basit görünen konu, biraz kurcalayınca bambaşka yere gidiyor; özellikle anahtar yönetimi gibi alanlarda, teknik taraf kadar uyum. Operasyon yükü de oyuna giriyor.

?

Maliyet Tarafı: TL Bazında Düşününce

İnanın, Şimdi FinOps şapkasını takayım. External Key Management deyince mesele sadece “Azure’a ne kadar ödeyeceksiniz” olmuyor, iş biraz dağılıyor; HSM, ağ, ekip, denetim derken toplam fatura sessizce kabarıyor. Kısacası, ilk bakışta ucuz gibi duran şey bazen hiç de öyle çıkmıyor.

• HSM donanımı (satın alma veya kiralama — bir çift enterprise-grade HSM 6 haneli dolar bandında)
• Kolokasyon veya kendi DC maliyeti — bunu es geçmeyin
• Azure ile HSM arası özel network (ExpressRoute önerilir, kamu internetinden kaçının)
• Yetkin personel (bir HSM operatörünün maliyeti bilindik bir sistem yöneticisinden ciddi şekilde yukarıda) — ciddi fark yaratıyor
• Sertifikasyon ve denetim maliyetleri
• Managed HSM standart ücretlendirmesi (bu da devam ediyor, çünkü servis hâlâ çalışıyor)

Yanı “Anahtarımı ben tutayım daha ucuz olur” tuzağına düşmeyin. Ben açık konuşayım, çoğu senaryoda tam tersi oluyor; hele bir de işi regülasyon tarafına bağladıysanız, o maliyet zaten kaçacak yer bırakmıyor (ki bu çoğu kişinin gözünden kaçıyor). Peki neden? Çünkü burada sadece servis ücreti yok, operasyon yükü de var.

Bütçe Kısıtlıysa Alternatifler

Eğer bütçeniz sıkıysa ama egemenlik kaygınız da varsa, şu ara adımları düşünebilirsiniz: Önce Managed HSM’i standart modda kullanın, security domain’i baya sıkı yönetin (quorum üyelerini farklı fiziksel lokasyonlarda tutun, offline sakının). Attestation raporlarını düzenli alın. Regülatörle “single-tenant, FIPS 140-3 Level 3, Microsoft görmüyor, attestation ile ispatlanabilir” argümanını konuşun. Şey yanı, çoğu zaman bu kadarı yetiyor; özellikle karşı tarafta teknik detaydan anlayan biri varsa iş daha da kolaylaşıyor.

Pratik Uygulama: İlk Adımlarınız

Diyelim ki karar verdiniz, External Key Management tarafına bakacaksınız. İlk iş bence koşup prod’a dalmak değil; önce sakın sakın bir PoC kurun, çünkü işin tadı non-production ortamda biraz zorlayınca çıkıyor.

1. PoC ortamı kurun: Public preview olduğu için önce non-production ortamda deneyin. Latans, throughput ve failover davranışını gerçek senaryoyla test edin. Kâğıt üstünde iyi görünen şey, canlıda bazen tökezliyor, o yüzden bunu baştan görmek iyi oluyor.
2. Network mimarisini planlayın: HSM’ınız nerede duracak, Azure’a nasıl bağlanacak, bağlantı kesilirse ne olacak — bunları önceden çözün. Burada küçük bir detay gibi duran şeyler, sonra gece yarısı sizi aratıyor, açık konuşayım.
3. Runbook yazın: HSM arıza senaryoları, quorum kaybı, key rotation, DR — hepsi için yazılı prosedür lazım. Managed HSM’de bunları Microsoft yapıyordu, artık sız yapacaksınız. Evet, biraz yük artıyor ama en azından kontrol sizde oluyor.

Şunu söyleyeyim, Kod tarafında işe iş garip şekilde tanıdık geliyor. Managed HSM ile etkileşim, standart Key Vault SDK’sıyla neredeyse aynı;. Yeni bir dünya öğrenmiyorsunuz, daha çok arka plandaki düzen değişiyor gibi düşünün.

from azure.keyvault.keys import KeyClient
from azure.identity import DefaultAzureCredential
# Managed HSM endpoint (harici anahtara referans veren küme)
mhsm_url = "https://my-mhsm.managedhsm.azure.net"
client = KeyClient(vault_url=mhsm_url, credential=DefaultAzureCredential())
# Harici HSM'de tutulan anahtara referans
key = client.get_key("external-root-key")
print(f"Key ID: {key.id}")
print(f"Key type: {key.key_type}")

Şunu söyleyeyim, Uygulama tarafından bakıldığında büyük bir fark yok gibi dürüyor. Ama dur bir saniye — asıl fark kodda değil; güven zincirinde ve anahtarın fiziksel olarak nerede tutulduğunda ortaya çıkıyor. Yanı yüzey aynı kalıyor, alt katman epey değişiyor.

Ve işler burada ilginçleşiyor.

Yaygın Bir Hata: Attestation’ı Atlamak

Burada, sahada en çok gördüğüm şeylerden biri bu. Ekipler HSM’i kuruyor, anahtarları üretiyor, servisleri bağlıyor; (yanlış duymadınız). Attestation raporunu ya almıyorlar ya da bir köşeye atıp unutuyorlar. Sonra denetim kapıyı çalınca, “Bu anahtarın gerçekten HSM içinde üretildiğini nasıl göstereceksiniz?” sorusu geliyor. Ortalık bir anda sessizleşiyor.

Hani, İşin aslı, çözüm o kadar da karmaşık değil. Key attestation’ı CI/CD pipeline’ınıza koyun; her hayatı anahtar üretildiğinde rapor otomatik gelsin, immutable storage’a (WORM daha iyi olur) yazılsın, sonra da gerektiğinde tek yerden çekip gösterin. Küçük gibi dürüyor ama denetim günü geldiğinde baya iş görüyor.

Bu tarafı biraz daha açmak isterseniz Azure IaaS Maliyet Optimizasyonu: Sahadan FinOps Notları yazımdaki denetim izleri bölümünde benzer bir yaklaşımı anlattım; orada da aynı mantık var aslında, kayıt yoksa anlatacak hikâye de olmuyor.

Kişisel Değerlendirmem

Bence External Key Management, doğru tarafa atılmış bir adım. Microsoft’un “sizin anahtarınıza dokunmuyoruz” cümlesi var ya, işte bunun pratikte karşılığı gibi dürüyor. İşte, ama dur bir saniye — özellik hâlâ public preview, yanı biraz ham; production’a taşımak için ben şahsen biraz daha oturmasını beklerim, çünkü GA’ya gelince entegrasyon senaryoları, desteklenen 3. taraf HSM’ler ve regülasyon dokümantasyonu daha net olur.

Dürüst olmak gerekirse, Şu aşamada ilgilenen kurumların yapacağı iş aslında belli: PoC ortamlarında denemek, çıkan sonuçları not almak ve iç dokümantasyonu şimdiden hazırlamak (evet, doğru duydunuz). Evet, bu kadar basit. GA’dan sonra hemen migrasyona abanmayın; en az bir çeyrek gözlem süresi koymak bence daha akıllıca olur, yoksa aceleyle alınan kararlar sonra ufak ama can sıkan sürprizlere dönüyor.

Araya gireyim: Konu ile bağlantılı olarak Azure Storage Göçü: Planlamadan Kesime Sahadan Notlar yazısındaki egemenlik ve şifreleme değerlendirmeleri de bu başlıkla baya örtüşüyor (kendi tecrübem). Bir de Azure Files NFS ile Modern Linux İş Yükleri: Sahadan Bakış yazısında değindiğim “veri egemenliği” meselesi var ya, işte o tartışma da aynı zemine oturuyor; hani teknik olarak ayrı görünen konular bazen aynı kapıya çıkıyor, sız ne dersiniz?

Durun, bir saniye.

Sıkça Sorulan Sorular

External Key Management için mutlaka on-prem HSM mi şart?

Hayır, şart değil. Hani kendi veri merkezinizde bir HSM olabilir,. Aynı zamanda güvendiğiniz bir üçüncü taraf sağlayıcıda tuttuğunuz HSM de işi görüyor. Asıl önemli olan şu: Microsoft altyapısının dışında olması ve yönetim kontrolünün tamamen sizde kalması.

Managed HSM’den External Key Management’a geçmek zor mu?

Tuhaf ama, Açıkçası kolay değil, ama iyi planlanırsa yönetilebilir bir süreç. Anahtar rotasyonu ve re-encryption adımları kaçınılmaz. Kritik iş yüklerinde downtime istemiyorsanız mavi/yeşil yaklaşımı şart — bence bunu atlamamak lazım (bu beni çok şaşırttı). Yanı bunu küçük bir iş olarak değil, ciddi bir migrasyon projesi olarak ele alın.

Public preview’da SLA var mı?

Yok. Standart Azure preview şartları geçerli, yanı üretim SLA’i beklemiyorsunuz. Tecrübeme göre bu aşamada can alıcı iş yüklerini sürüye sokmak pek akıllıca değil — GA’yı bekleyin. Şimdilik PoC ve mimarı doğrulama için kullanın, o kadar.

External HSM’im çökerse Azure servislerime ne olur?

İşin en kritik noktası aslında bu. HSM’e erişim kesilirse, o anahtarla şifrelenmiş servislere erişim de gidebilir. Bu yüzden en az iki HSM ile HA/DR kurmanız, düzenli sağlık kontrolleri yapmanız. Failover prosedürünüzü gerçekten test etmeniz gerekiyor. Bence bu adımı es geçmek, kendinize tek nokta arıza tuzağı kurmak demek.

Managed HSM ile External Key Management arasındaki fiyat farkı ne kadar?

Azure tarafındaki ücretlendirme aşağı yukarı benzer gidiyor. Ama toplam maliyeti şişiren şey aslında sizin işlettiğiniz HSM’in donanım, network ve personel giderleri. Tahmin eder mısınız? Mesela gerçekçi bir tahmin yapmak istiyorsanız, ilk üç yılda 2-4 kat daha maliyetli olacağını varsayarak bütçenizi ona göre planlayın.

Kaynaklar ve İleri Okuma

External key management for Azure Managed HSM is now in public preview — Azure Blog (en azından benim deneyimim böyle)

İşin garibi, Azure Key Vault Managed HSM Resmî Dokümantasyonu

Managed HSM Security Domain — Microsoft Learn

FIPS 140-3 Standart Dokümantasyonu — NIST

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Koddan Buluta: azd ile AI Ajanınızı Microsoft Foundry’ye Dakikalar İçinde Taşıyın23 Mar 2026

Agentic Cloud Operations: İçgörüden Eyleme Geçen Bulut Devri26 Haz 2026

Azure Content Understanding ile Belgeleri Akıllı İş Akışına Çevirmek7 Haz 2026

AI Projelerinde Azure Blob’a Bağlanmak Hiç Bu Kadar Kolay Olmamıştı: adlfs Deneyimi18 Mar 2026