Azure Key Vault Nedir ve Ne İşe Yarar?

Repo’nun bir köşesinde, orada olmasını istemediğin bir connection string muhtemelen duruyor. Belki appsettings.json içinde, belki yoğun bir günde commit’lenmiş bir .env dosyasında. Azure Key Vault nedir sorusunun kısa cevabı, uygulamaların gizli bilgilerini bu şekilde taşımak zorunda kalmaması için üretilmiş yönetilen bir kasa olması.

Bu yazıda Azure Key Vault’un ne olduğunu, hangi sorunlar için üretildiğini, bir uygulamanın içinden secret’ı nasıl çektiğini ve AWS, Google Cloud ile HashiCorp tarafındaki alternatiflerle nasıl kıyaslandığını anlatıyorum. İki tablo, erişim akışını gösteren bir animasyon ve kopyalayıp kullanabileceğin kısa bir .NET örneği var.

Yazılımcılar için hazırladım, o yüzden satış dili yok. Odak, Key Vault’un gerçek projelerde nasıl davrandığı.

Azure Key Vault nedir

Azure Key Vault, secret’ları, şifreleme anahtarlarını ve sertifikaları saklayan, bunları kimlerin kullanabileceğini denetleyen yönetilen bir Azure servisidir. Kimlik doğrulama Microsoft Entra ID ile yapılır, her vault donanım güvenlik modüllerinde (HSM) tutulan anahtarlarla at rest şifrelenir ve altyapıyı kendin işletmen ya da güncellemen gerekmez.

Hangi sorunu çözer

Merkezi bir depo olmayınca secret’lar tahmin edilebilir bir şekilde dağılır.

• Config dosyalarında, ortam değişkenlerinde ve CI ayarlarında durur. Her kopya sızabilecek bir yer daha demektir.
• Bir secret’ı döndürmek, eski değeri tutan her uygulamayı yeniden deploy etmeyi gerektirir.
• Bir secret’ı kimin ne zaman okuduğu bilinmez.
• Şifreleme anahtarları, korudukları verinin hemen yanında durur.
• Bir sertifikanın süresi hafta sonu dolar ve production’ı da beraberinde götürür.

Key Vault ile uygulama yalnızca vault’un adresini bilir. Değer çalışma anında Azure’ın yönettiği bir kimlik tarafından çekilir, her okuma yetkilendirilir ve loglanabilir, rotasyon da tek yerde yapılır.

Secret, key ve certificate

Key Vault üç tür nesne saklar. Hangisinin doğru olduğu, uygulamanın değerin kendisine mi yoksa bir işlemin sonucuna mı ihtiyaç duyduğuna bağlıdır.

Sertifikalar özel bir durumdur. Tek bir isim altında vault sertifikayı, bir key’i ve bir secret’ı birlikte tutar. Böylece ya PFX indirilir ya da özel anahtar açığa çıkmadan kriptografi işlemleri vault’a yaptırılır.

Azure Key Vault nasıl çalışır

Uygulama hiçbir kimlik bilgisi saklamaz. Microsoft Entra ID’ye kim olduğunu kanıtlar, bir token alır ve bu token’ı vault’a sunar.

1. Uygulama, managed identity’sini kullanarak Microsoft Entra ID’den token ister.
2. Entra ID, Key Vault için bir access token verir.
3. Uygulama bu token ile vault’u çağır, örneğin https://<vault-name>.vault.azure.net/secrets/<name> adresindeki secret’ı okumak için.
4. Vault çağıranın rolünü kontrol eder (örneğin Key Vault Secrets User), rol yoksa çağrıyı reddeder.
5. Vault secret’ı döndürür, uygulama onu bellekte tutar.
6. Loglama açıksa vault erişimi denetim günlüğüne yazar.

Her istek ayrı ayrı doğrulanır ve client’ların TLS 1.2 ya da 1.3 ile bağlanması gerekir.

Bilinmesi gereken temel kavramlar

Kim neyi yapabilir

Key Vault’ta iki düzlem (plane) vardır. Control plane vault’un kendisini yönetir ve her zaman Azure RBAC kullanır. Data plane secret, key ve sertifikaları kapsar, Azure RBAC ya da eski access policy’lerle çalışabilir. Microsoft RBAC’i önerir. API sürümü 2026-02-01 ve sonrasında yeni oluşturulan vault’larda varsayılan model de RBAC’tir.

Birkaç yerleşik rol çoğu uygulamaya yeter.

• Key Vault Secrets User secret değerlerini okur. Bir uygulamanın normalde ihtiyaç duyduğu rol budur.
• Key Vault Secrets Officer secret’ları yönetir.
• Key Vault Crypto User key’lerle kriptografik işlemler yapar.
• Key Vault Certificates Officer sertifikaları yönetir.
• Key Vault Reader yalnızca metadata görür, değerleri asla.

Mevcut bir vault’u RBAC’e geçirmek tüm access policy’leri düşürür, bu yüzden roller önce atanmalıdır.

Uygulamalar nasıl kimlik doğrular

Managed identity (yönetilen kimlik) kullanılır. Azure kimliği senin yerine döndürür ve kodda hiçbir kimlik bilgisi durmaz. Secret ya da sertifikayla çalışan bir service principal de işe yarar ama bu kez korunması ve döndürülmesi gereken bir başlangıç secret’ı olur. Kaldırmak istediğin sorun bir seviye yukarıda yeniden ortaya çıkar.

Standard, Premium ve Managed HSM

Soft delete ve purge protection

• Soft delete yeni vault’larda varsayılan olarak açıktır ve kapatılamaz. Silinen vault’lar ve nesneler 7 ile 90 gün arasında geri alınabilir, varsayılan 90 gündür. Süre vault oluşturulurken belirlenir ve sonradan değiştirilemez.
• Purge protection isteğe bağlıdır. Açıkken saklama süresi dolmadan hiçbir şey kalıcı olarak silinemez. Müşteri tarafından yönetilen anahtar kullanan servislerin çoğu, örneğin Storage, bunu zorunlu tutar.
• Soft delete durumundaki bir vault’un adı, saklama süresi bitmeden yeniden kullanılamaz.

Nerelerde kullanılır

Çoğu Azure projesinde Key Vault birkaç tekrar eden yerde devreye girer.

• Uygulama secret’ları. Connection string, API anahtarı ve parolalar, SDK ile çalışma anında okunur.
• App Service ve Functions. @Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret) gibi bir app setting, kod değişikliği olmadan secret’a çözülür. Değerler 24 saatte bir yeniden çekilir, yani bir rotasyon uygulamaya en geç bir gün içinde ulaşır.
• AKS. Secrets Store CSI driver secret, key ve sertifikaları pod’lara volume olarak bağlar ve Kubernetes secret’larıyla senkronize edebilir. Otomatik rotasyon varsayılan olarak kapalıdır (enableSecretRotation), açıldığında 2 dakikada bir kontrol eder.
• TLS sertifikaları. Vault’ta oluşturulur ya da içe aktarılır, DigiCert veya GlobalSign üzerinden otomatik yenilenir ve App Service ile kullanılır.
• Müşteri tarafından yönetilen anahtarlar. Storage, Azure SQL ve Azure Disk Encryption gibi servisler, vault’ta tutulan bir anahtarla şifreleme yapabilir. Purge protection genellikle zorunludur.
• Kendi kodunda imzalama ve şifreleme. Vault’un hiç dışarı vermediği bir key ile imzalama, doğrulama, wrap ve unwrap yapılır.
• CI/CD pipeline’ları. Secret’lar pipeline değişkenlerinde tutulmak yerine deploy anında okunur. Azure DevOps güvenilen servisler listesinde olmadığı için vault firewall’u açıkken bir IP kuralı, sanal ağ kuralı ya da private endpoint gerekir.

Diğer platformlardaki karşılıkları

Azure secret, key ve sertifikaları tek serviste tutar. AWS ve Google Cloud ise secret ile key’leri ayrı servislere böler.

Bilinmesi gereken birkaç fark var.

• Rotasyon. AWS Secrets Manager rotasyonu bir Lambda fonksiyonuyla yapar, Google Secret Manager rotasyon zamanlamaları kullanır. Key Vault key’leri bir politika ile döndürür, sertifikaları lifetime action’larla yeniler, secret’lar için ise rotasyon rehberleri ve Event Grid bildirimleri sunar.
• Sürümler. Google sürümleri alias’larla sabitlemeye izin verir. Key Vault sürümleri URI ile adresler, App Service de sürüm belirtilmediğinde en güncel olanı alır.
• HashiCorp Vault. Bulut bağımsızdır, veritabanları için dinamik credential üretir ve her isteği denetler. Kendi altyapında işletilebilir ya da HCP Vault Dedicated olarak kullanılabilir. İlk seçenekte işletmek ve güvenliğini sağlamak sana kalır.

.NET ile Key Vault kullanımı

Bir secret’ı okumak birkaç satır tutar ve aynı kod hem makinende hem Azure’da çalışır.

Vault’u oluşturma ve uygulamaya erişim verme

az keyvault create --name <vault-name> --resource-group <rg> --enable-rbac-authorization true
az keyvault secret set --vault-name <vault-name> --name Db-ConnectionString --value "<value>"

az webapp identity assign --name <app-name> --resource-group <rg>
az role assignment create --role "Key Vault Secrets User" \
  --assignee <principal-id> \
  --scope $(az keyvault show --name <vault-name> --query id -o tsv)

Secret’ı yazmak için kendi hesabına Key Vault Secrets Officer gibi bir rol gerekir. Uygulamaya yalnızca Key Vault Secrets User yeter.

Kodda secret okuma

dotnet add package Azure.Identity
dotnet add package Azure.Security.KeyVault.Secrets

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

// Uygulama başına tek bir client yeterli, thread-safe çalışır.
var client = new SecretClient(
    new Uri("https://<vault-name>.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("Db-ConnectionString");
string connectionString = secret.Value;

DefaultAzureCredential Azure’da managed identity’yi, kendi makinende geliştirici oturumunu kullanır. Bu yüzden ortamlar arasında kod değişmez.

Ya da secret’ları IConfiguration’a yükleme

builder.Configuration.AddAzureKeyVault(
    new Uri("https://<vault-name>.vault.azure.net/"),
    new DefaultAzureCredential());

Bu yöntem Azure.Extensions.AspNetCore.Configuration.Secrets paketiyle gelir. Kimliğe secret’ları listelemek için Key Vault Reader, okumak için Key Vault Secrets User rolü gerekir. Secret adlarında iki nokta kullanılamaz, bu yüzden ConnectionStrings--Default adlı secret ConnectionStrings:Default anahtarı olarak okunur.

Kaçınılması gereken hatalar

• Her şey için tek ortak vault. Uygulama, ortam ve bölge başına bir vault kullanılır, roller vault kapsamında atanır.
• Vault’a ulaşmak için client secret. Managed identity kullanılır. Aksi halde sorun bir seviye yukarı taşınır.
• Eski access policy’ler. Azure RBAC kullanılır. RBAC aynı zamanda just-in-time erişim için Privileged Identity Management’ı destekler.
• Güvenlik ağı olmaması. Soft delete açık tutulur, purge protection etkinleştirilir, yeniden oluşturulamayan nesnelerin yedeği alınır ve geri yükleme denenir.
• Açık bırakılan public ağ erişimi. Private endpoint ya da vault firewall’u kullanılır, client’lar TLS 1.2 veya 1.3’e sabitlenir.
• Her istekte secret okumak. Limitler vault ve bölge başına 10 saniyelik pencerelerde uygulanır. Çoğu işlemde 4.000 istek, secret oluşturma ile sertifika ya da key içe aktarmada 300 istek hakkı vardır. Değerler bellekte önbelleğe alınır, tek bir client yeniden kullanılır ve SDK’nın üstel geri çekilmeli (exponential backoff) retry’ları açık bırakılır.
• Vault’u veritabanı gibi kullanmak. Ayarlar Azure App Configuration’da, müşteri verisi Storage ya da Cosmos DB’de tutulur.
• Körlemesine çalışmak. Audit logging ve Microsoft Defender for Key Vault açılır, erişim hataları ve secret silmeleri için alarm kurulur.

Sonuç

Azure Key Vault gösterişli bir servis değil. Sızmaması gereken şeyler için merkezi ve denetlenen bir yer, Azure projelerinin neredeyse hepsinde yerini bu yüzden buluyor. Bu hafta bir connection string’i Key Vault’a taşıyıp uygulamaya bir managed identity vermek, kalıbı oturtmak için yeterli.

Tüm projelerim ve üzerinde çalıştığım konuları incelemek istersen https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.

Kaynaklar

• About Azure Key Vault
• Key Vault basic concepts
• Key Vault best practices
• Key Vault service limits
• Azure RBAC for Key Vault data plane
• Soft delete and purge protection
• Key Vault security features
• About keys
• About secrets
• About certificates
• Managed HSM overview
• App Service Key Vault references
• Azure Key Vault provider for Secrets Store CSI Driver
• Azure Key Vault Secrets client library for .NET
• Azure Key Vault configuration provider for .NET
• AWS Secrets Manager
• AWS KMS
• AWS CloudHSM
• AWS Certificate Manager
• Google Cloud Secret Manager
• Google Cloud HSM
• Google Cloud Certificate Manager
• HashiCorp Vault