1. GİRİŞ

Gizli bilgi yönetimi (secret management) ve anahtar yönetimi (key management) modern altyapıların merkezinde yer alır. Bu alanda HashiCorp Vault, hem bulut hem de on‑prem ortamlarda esnek bir çözüm olarak yaygın şekilde tercih edilmektedir. Vault, sadece bir "secret store" değildir; dinamik credential üretimi, transit encryption, sealed‑key model, policy as code ve zengin authentication mekanizmalarıyla tedarik zincirinin güvenliğini güçlendirir.

Neden bugün önemli?

• Konteyner‑native, dağıtık ve multi‑cloud uygulamalar daha fazla short‑lived credential tüketiyor; Vault bu ihtiyaca yanıt verir.
• Supply chain saldırılarının artışı, artefaktın ve credential'ın kökenini ve doğrulanmasını kritik kılıyor.
• Regülasyon ve uyumluluk gereksinimleri (PCI, SOC2) auditlenebilir, merkezi secret politikalarını zorunlu kılıyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri — runtime secret distribution ve key lifecycle yönetimi için.
• Güvenlik mühendisleri — attestation, audit ve policy enforcement için.
• Uygulama geliştiriciler — application‑side secret retrieval, rotation ve least‑privilege erişim modellerine ihtiyaç duyanlar.

Hangi problemleri çözüyor?

• Hard‑coded secrets ve config leaks problemini ortadan kaldırır.
• Dynamic secret ile credential kompromisyonunda etki alanını kısıtlar.
• Transmission ve at‑rest encryption süreçlerini merkezi yönetimle kolaylaştırır.

2. KAVRAMSAL TEMELLER

2.1 HashiCorp Vault nedir? — kısa tanım

Vault, HashiCorp tarafından geliştirilen, anahtar/değer saklama, dinamik secret üretimi ve kriptografik işlemleri merkezi olarak yöneten, policy tabanlı erişim kontrolü sağlayan bir gizli bilgi yönetim sistemidir. Vault; auth, secrets engine, audit ve policy bileşenleriyle güvenli bir anahtar yönetim çözümü sunar.

2.2 Temel bileşenler

• Server: Vault process — secret engine'leri ve auth backend'leri çalıştırır.
• Storage backend: Vault verilerini saklayan backend (Consul, Postgres, Raft, S3). Depolanan veriler şifrelenir ve sealed key ile korunur.
• Auth methods: AppRole, Kubernetes, LDAP, OIDC, AWS IAM, Azure AD gibi kimlik doğrulama mekanizmaları.
• Secrets engines: KV, PKI, Database, AWS, Azure, GCP, Transit — farklı kullanım senaryoları için modüller.
• Policies: HCL veya JSON ile yazılmış ACL kuralları (Vault policy) — devlete benzer fine‑grained RBAC sağlar.
• Audit devices: Audit log'larının gönderildiği hedefler (file, syslog, socket).

2.3 Terminoloji

• Sealed / Unsealed: Vault başlatıldığında master key ile sealed durumdadır; unseal işlemi ile çalışma anahtarı açılır (Shamir's Secret Sharing sıklıkla kullanılır).
• Lease: Dynamiс secret'ların ömrü (time‑to‑live). Vault otomatik revoke desteği sağlar.
• Mount: Secrets engine veya auth method'un Vault'a eklendiği path.

3. NASIL ÇALIŞIR? — MİMARİ, BİLEŞENLER VE VERİ AKIŞI

3.1 Yüksek seviyeli mimari

Vault mimarisi üç ana katmandan oluşur: Storage backend, Vault server(s) ve clientler. Storage backend, tüm verinin şifreli bir biçimde tutulduğu yerdir; Vault server'lar bu veriyi yönetir ve istemci taleplerini işler. HA senaryolarında birden fazla Vault node'u Raft veya Consul gibi bir backing store ile birlikte çalışır.

3.2 Başlatma ve unseal süreci

Vault ilk kez başlatıldığında bir master key oluşturur. Bu anahtarın tamamı güvenli bir yerde saklanmaz; onun yerine Shamir's Secret Sharing ile parçalanır (unseal key shards). Operasyon sırasında belirli sayıda shard birleştirildiğinde Vault unseal olur. Auto‑unseal özellikleri (KMS tabanlı auto‑unseal) üretim ortamlarda tercih edilir; örneğin AWS KMS, Azure Key Vault veya GCP KMS ile auto‑unseal yapılandırılabilir.

3.3 Authentication (Auth methods)

Vault, çok çeşitli auth backend'leri destekler. En yaygın kullanım senaryoları:

• Kubernetes auth: Service account JWT'si kullanarak pod'ların Vault'tan token almasını sağlar; ideal self‑service secret injection için.
• AppRole: Machine‑to‑machine kimlik doğrulaması için politik tabanlı kimlik; role_id ve secret_id kombinasyonu ile çalışır.
• OIDC / LDAP: İnsan kullanıcılar için SSO entegrasyonu ve grup tabanlı policy atama.
• AWS IAM / Azure AD / GCP IAM: Bulut provider identity'leri ile entegre edilerek native kimlik doğrulama sağlar.

3.4 Secrets engines ve kullanım örnekleri

Secrets engines Vault'un gerçek gücünü oluşturan pluggable bileşenlerdir. Örnekler:

• KV (Key‑Value): Basit secret saklama; v1 veya v2 (versioned) modelleri vardır. v2 ile otomatik versioning ve rollback mümkün.
• Database secrets engine: Vault, veritabanı için dinamik kullanıcı hesabı oluşturabilir (örn. Postgres, MySQL). Bu hesaplar belirlenen lease süresi sonunda otomatik revoke edilir.
• Transit engine: Şifreleme için kullanılan bir servis; uygulamalar plain text'i Vault'un transit API'sine göndererek encrypt/decrypt, sign/verify işlemlerini gerçekleştirebilir — bu sayede anahtarlar uygulamadan ayrıştırılmış olur.
• PKI: Vault, internal CA rolü üstlenerek certificate issuing, rotation ve revocation işlevlerini yerine getirir.
• Cloud secrets (AWS, Azure, GCP): Cloud provider credential'ları için dynamic access credentials üretir veya provider API'lerini yönetir.

3.5 Lease ve revocation

Vault, dinamik oluşturulan credential'lara lease atar. Lease süresi dolduğunda Vault otomatik olarak credential'ı geri alır. Ayrıca manuel revoke işlemi de desteklenir. Bu model, credential exposure durumunda risk sınırını dramatik şekilde düşürür.

3.6 Audit ve policy enforcement

Vault policy'leri HCL veya JSON ile yazılır ve path bazlı erişimi kontrol eder. Audit devices ile tüm erişimler log'lanır; bu kayıtlar SIEM'e yönlendirilerek anomali detection yapılabilir. Policy'ler genelde least‑privilege ilkesiyle tasarlanır ve insan hatalarını azaltacak şekilde yazılır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Dinamik veritabanı credential'ları

Büyük ölçekli uygulamalarda sabit DB kullanıcıları yönetmek zordur. Vault'un database secrets engine'i, uygulamalar veya entegrasyonlar için kısa ömürlü DB kullanıcıları yaratır. Örneğin her CI job için ayrı kullanıcı, belirli TTL ile üretilebilir; job bittiğinde Vault otomatik revoke eder. Bu model, credential leakage riskini azaltır.

4.2 Transit encryption — uygulamadan anahtarı ayırmak

Uygulamalar hassas alanları (PII, payment data) kendi içinde şifrelemek yerine Vault'un transit api'sini kullanabilir: uygulama plain text'i Vault'a gönderir, Vault encrypt edilmiş değeri döndürür ve anahtarlar Vault içinde tutulur. Bu, anahtar yönetimini merkezi kılar ve anahtarların sızma riskini azaltır.

4.3 PKI ve sertifika otomasyonu

Vault PKI ile iç sertifika dağıtımı ve rotasyonu otomatikleştirilebilir. Örneğin internal service mesh mTLS sertifikaları Vault tarafından issue edilip, lifecycle otomasyonu ile düzenli olarak yenilenebilir.

4.4 CI/CD ve ephemeral environment entegrasyonları

CI/CD sistemleri Vault ile entegre edildiğinde, pipeline'lar ephemeral environment'lara otomatik olarak gerekli credential ve secrets'ı alabilir. Örneğin GitHub Actions OIDC ile Vault'a authenticate olup, pipeline run süresince kısa ömürlü secret'lara erişebilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Dynamic secrets ve automatic revocation ile risk yüzeyi küçülür.
• Transit engine ile anahtar yönetimi uygulamalardan ayrılır, anahtarlar Vault içinde korunur.
• Geniş auth backend desteği ile heterojen ortamlarda kimlik doğrulama kolaylaşır.
• Policy as code ile fine‑grained erişim kontrolü sağlanır ve auditlenebilirlik artar.

Sınırlamalar

• Vault operasyonel olarak kritik bir sistemdir; HA, snapshot/backup ve disaster recovery planı gerektirir.
• Karmaşık kullanım senaryolarında policy yönetimi zorlaşabilir; iyi tasarlanmış naming ve policy stratejisi gerekir.
• Storage backend ve auto‑unseal çözümleri için ek maliyet ve entegrasyon gereksinimleri olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Auto‑unseal için KMS tabanlı çözümler kullanın; manuel unseal operasyondan kaçının.
• HA ve disaster recovery: Vault cluster'ınızı Raft veya Consul backing ile yüksek erişilebilirlikte çalıştırın ve düzenli snapshot alın.
• Policy ve path naming standardı: net, küçük ve versionable policy setleri oluşturun; environment ve application scope'u açıkça belirtin.
• Secrets cache: uygulama tarafında kısa süreli caching stratejileri kullanın; fakat cache invalidation ve rotation senaryolarını işlemeyi unutmayın.

Performans optimizasyonu

• Transit ve encrypt/decrypt operasyonlarını asenkronize veya batch olarak kullanın; yüksek RPS senaryolarında rate limit ve queue mekanizmaları planlayın.
• Storage backend performansını izleyin; Consul veya Raft cluster boyutlandırmasını iş yüküne göre ayarlayın.

Güvenlik

• Least privilege ilkesiyle policy yazın; broad izinlerden kaçının.
• Audit log'ları merkezi SIEM'e yönlendirip retention ve forensics stratejisi oluşturun.
• Secret rotation'ı otomatikleştirin ve uygulama tarafında seamless rotation pattern'lerini uygulayın.

Ölçeklenebilirlik

• Raft backend kullanarak Vault'ı scale edin; global deploylarda replication stratejilerini değerlendirin.
• Region bazlı standby Vault cluster'ları ile latency ve operasyonel izolasyon sağlayın.

8. SIK YAPILAN HATALAR

• Vault'ı tek bir monolitik policy ile yönetmek — granüler politikalar eksik kalır ve risk artar.
• Manual unseal kullanmak — operasyonel gecikmeye ve güvenlik riskine yol açar.
• Secrets'ı uygulama içinde cache ederken invalidation planı yapmamak — rotated secrets uyumsuzluğu.
• Audit log'larını etkinleştirmemek veya merkezi sisteme göndermemek — forensics eksikliği.

9. GELECEK TRENDLER

1. Identity‑first secret access: Workload identity ve short‑lived credential modelinin daha da yaygınlaşması bekleniyor. Vault entegrasyonları daha sıkı OIDC/OAuth tabanlı olacaktır.
2. Platform as Data: Secret metadata'ları ML modelleriyle analiz edilip anomaliler otomatik tespit edilecek; gizli bilgi erişim anormallikleri daha hızlı saptanacak.
3. HSM ve tekil root of trust: Donanım tabanlı HSM çözümlerinin erişilebilirliği artacak; auto‑unseal + HSM kombinasyonları standart hale gelecek.
4. Edge ve IoT güvenliği: Hafif Vault client'lar ve offline attestation mekanizmaları IoT/Edge senaryolarında daha fazla kullanılacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Vault'ı hangi storage backend ile kullanmalıyım?

   Prod için Raft (Integrated Storage) veya Consul önerilir. Basit senaryolarda managed object storage (S3) da kullanılabilir ama HA/consistency ihtiyaçlarına göre seçim yapın.

2. 2. Auto‑unseal ne demek, neden önemlidir?

   Auto‑unseal, Vault'un başlatılırken otomatik olarak unseal olmasıdır; KMS tabanlı auto‑unseal operatör müdahalesini ortadan kaldırır ve CI/CD ile daha entegre çalışır.

3. 3. Vault ve KMS farkı nedir?

   KMS (AWS KMS, Azure Key Vault) genelde anahtar yönetimi sağlar; Vault ise secrets yönetimi, dynamic secrets, transit encryption ve policy yönetimini birleştirir. Birçok mimaride Vault KMS ile birlikte kullanılır (auto‑unseal, wrapping key).

4. 4. Dinamik credential neden önemli?

   Dinamik credential kısa ömürlü olduğu için credential compromise durumunda etki süreleri kısalır; ayrıca audit ve izlenebilirlik artar.

5. 5. Vault performans sorunları nasıl çözülür?

   Storage backend (Consul/Raft) performansını optimize edin; Vault node'larını scale edin; transit işlemler için batch veya asenkron modellere geçin.

6. 6. Vault policy iyi nasıl tasarlanır?

   Path bazlı en küçük izinleri verin; application scope ve environment ayrımı yapın; tekrar kullanılabilir policy modülleri oluşturun ve version kontrolünde tutun.

7. 7. Vault'u Kubernetes ile nasıl kullanırım?

   Kubernetes auth method ile pod'lara service account tabanlı token verip Vault'tan secret çekebilirsiniz. Ayrıca Vault Agent sidecar/CSI driver ile daha otomatik secret injection modelleri uygulanır.

8. 8. Vault backup stratejisi nasıl olmalı?

   Storage backend snapshot'ları düzenli alınmalı, snapshot test restore senaryoları uygulanmalı ve snapshot'ların güvenli şekilde saklanması sağlanmalıdır. Ayrıca disaster recovery runbook'ları olmalı.

Anahtar Kavramlar

Auto‑unseal

Vault'un KMS veya başka bir çözümle otomatik olarak unseal edilmesi.

Lease

Dinamik credential için verilen süre (TTL) — lease bitiminde credential revoke edilir.

Transit engine

Encrypt/decrypt ve sign/verify işlemlerini yapan, anahtarları Vault içinde tutan secrets engine.

KV v2

Versioning özelliği olan key‑value secrets engine; geçmiş sürümlere rollback sağlar.

Shamir's Secret Sharing

Master unseal key'in parçalanıp dağıtılması yöntemi; belirli sayıda shard birleşince unseal işlemi gerçekleşir.

Öğrenme Yol Haritası

1. 0–1 ay: Vault temel kavramları, auth methods ve KV engine kullanımını öğrenin; lokal dev ortamında Vault çalıştırın ve basic secret read/write yapın.
2. 1–3 ay: Kubernetes auth, Vault Agent, CSI driver ve dynamic database secrets entegrasyonlarını uygulayın.
3. 3–6 ay: Transit, PKI, auto‑unseal (KMS) ve HA/backup konularını hayata geçirin; policy ve audit konfigürasyonlarını olgunlaştırın.
4. 6–12 ay: Large scale operasyon, replication, multi‑region deploy, attestation ve SIEM entegrasyonları ile enterprise olgunluğa erişin.