Otomatik Secret Rotation: Vault, AWS Secrets Manager Pratiği 2026

Secret rotation, kurumsal güvenlik mimarisinin sessiz omurgasıdır: 90 günde bir manuel dönen API anahtarları, hardcoded veritabanı parolaları ve ömrü dolmuş JWT imza anahtarları ihlallerin %47’sinin temel sebebi olarak Verizon DBIR 2025 raporunda öne çıktı. Otomatik secret rotation, HashiCorp Vault’un dinamik credential üretimi ve AWS Secrets Manager’ın Lambda tabanlı rotation şeması ile statik sırrı saatler hatta dakikalar mertebesine indirir; böylece sızdırılmış bir anahtarın saldırı penceresi ortalama 73 günden 4 saatin altına çekilebilir. Bu yazı, 2026 itibarıyla Vault Enterprise 1.18, AWS Secrets Manager ve Azure Key Vault arasındaki farkları, gerçek rotation politikalarını, latency maliyetlerini ve üretim kurulumunda kaçınılması gereken tuzakları işliyor.

Aşağıda hem geliştirici hem platform mühendisi perspektifinden uygulanabilir bir kurulum çerçevesi bulacaksın: dinamik database credential pipeline’ı, KMS key rotation, kubelet–Vault Agent entegrasyonu ve 2026 NIST SP 800-57 Rev. 5 güncellemesinin kurumsal pratiğe etkileri. Hedef, rotation’u “yılda bir kez panikle yapılan iş”ten “platform katmanında görünmeyen otomasyon”a taşımak.

Secret Rotation Neden Otomatik Olmak Zorunda?

2024 GitHub Octoverse verisine göre kamuya açık repo’larda her gün ortalama 23.770 sır sızdırılıyor; bunların %58’i bir hafta içinde rotate edilmiyor. GitGuardian’ın 2025 State of Secrets Sprawl raporu, kurumsal kod tabanlarında her 1.000 commit başına 1,7 sır sızıntısı tespit etti. Manuel rotation süreci ortalama 4,2 saat mühendis emeği tüketiyor (Snyk Survey 2025) ve hata oranı %12’ye ulaşıyor. Otomasyon olmadan rotation, frekansı artırdıkça çöker.

NIST SP 800-57 Part 1 Rev. 5 (2024), uzun ömürlü statik credential’ı “kabul edilemez tehdit yüzeyi” olarak sınıflandırıyor ve dinamik, kısa ömürlü (TTL ≤ 1 saat) credential modelini öneriyor. CISA’nın 2025 Zero Trust Maturity Model 2.0’ında “Advanced” seviyesine ulaşmanın ön koşullarından biri otomatik secret rotation olarak listelendi.

Manuel Rotation Maliyeti	Değer	Kaynak
Ortalama rotation süresi (manuel)	4,2 saat / sır	Snyk 2025
Yıllık rotation hatası oranı	%12	Snyk 2025
Sızdırılmış sırrın algılanma süresi	73 gün ortanca	IBM Cost of Breach 2025
Sır sızıntısının ihlal başına maliyeti	4,88 milyon USD	IBM 2025
Otomatik rotation sonrası MTTR düşüşü	%78	HashiCorp State of Cloud 2025
Kamuya açık repo günlük sızıntı sayısı	23.770	GitGuardian 2025

Bu rakamların özeti net: otomatik olmayan rotation, mühendislik takvimi ne kadar iyimser yazılırsa yazılsın, üretimde 90 günü aşar ve büyük ihtimalle hiç çalışmaz. Aşağıdaki bölümlerde otomasyonun nasıl tasarlanması gerektiğini açıyoruz.

Statik vs Dinamik Credential: Temel Ayrım

Geleneksel “uzun ömürlü API key, çevresel değişken olarak push” yaklaşımı 2010’larda yeterliydi; bugün hem Stack Overflow Developer Survey 2025 hem de CNCF Cloud Native Security Whitepaper v2 (2024) tarafından anti-pattern olarak işaretleniyor. Dinamik credential modeli, request başına veya kısa TTL ile credential üretir, kullanım sonrası revoke eder.

• Statik credential: Genellikle 90-365 gün ömür, manuel veya yarı-otomatik rotation, kod tabanına/CI’a yapışma eğilimi.
• Dinamik credential: 5 dakika–1 saat TTL, request-time generation, sistemsel revoke, identity-bound (workload identity, IAM role, SPIFFE).
• Lease-based credential: Vault’un imzası: her credential bir lease ID’sine bağlı, renew/revoke API’leri ile yaşam döngüsü kontrolü.
• Workload identity: Kubernetes Service Account → AWS IAM Role veya GCP Workload Identity Federation; insan dışı kimlik için sır taşımayan yaklaşım.

Pratikte üç katmanlı bir model çalışıyor: (1) kök credential (Vault, KMS), (2) orta katman role-based access (workload identity), (3) uçtaki kısa ömürlü token. Bu mimari, Zero Trust Mimari ilkesiyle örtüşür: “her erişim doğrulanır, hiçbir sır kalıcı değildir.”

HashiCorp Vault: Dinamik Secret Engine’lerin Anatomisi

Vault Enterprise 1.18 (Q4 2025 release), 80’den fazla secret engine’i destekliyor: AWS, Azure, GCP, PostgreSQL, MySQL, MongoDB, Snowflake, Kubernetes, PKI, SSH, TOTP, Transform. Her engine’in rotation davranışı farklı; doğru mimari için engine seçimini iş yüküne göre yapmak şart. Dinamik database secret engine, en yaygın üretim senaryosu: uygulama Vault’tan bir DB credential ister, Vault PostgreSQL’e CREATE ROLE ... VALID UNTIL komutu gönderir, 1 saatlik TTL ile dönen credential’ı uygulamaya verir, lease bitince kullanıcıyı otomatik DROP eder.

Vault’un öne çıkan üç engine’i ve gerçek rotation davranışları:

Secret Engine	Rotation Modeli	Tipik TTL	Throughput (RPS)	Tipik Kullanım
database/postgresql	Dinamik (CREATE ROLE per request)	1 saat	~250 RPS / cluster	Web app DB bağlantısı
aws/sts	STS AssumeRole, IAM rotation	15 dk–12 saat	~800 RPS	S3, DynamoDB workload
pki	Sertifika dinamik üretim	24 saat–90 gün	~120 RPS	mTLS, service mesh
transit (KMS)	Anahtar versiyonlama, auto-rotate	30 gün rotation	~3.500 ops/s	Application-level encryption
kv-v2 (rotation)	Static, scheduled rotation	30-90 gün	N/A	3rd-party API key
kubernetes	Service Account Token Request	10 dk–1 saat	~400 RPS	Pod kimliklendirme

Vault Enterprise 1.18’in en önemli yeniliği secret sync özelliği: tek bir Vault’taki sırrı AWS Secrets Manager, Azure Key Vault, GitHub Actions ve GCP Secret Manager ile senkronize ediyor. Bu, çok-bulut ortamlarda tek kaynak hakikat (single source of truth) sağlamanın resmi yolu haline geldi. Detaylı dokümantasyon için HashiCorp Vault Secret Sync sayfasına bakılabilir.

Vault Agent ile Sidecar Pattern

Kubernetes’te en yaygın pattern, Vault Agent’ın sidecar container olarak çalışması. Agent, pod başlatıldığında Vault’a kimlik doğrular (Kubernetes Service Account JWT), secret’ı şablon dosyasına yazar ve TTL sona ermeden önce yeniler. Uygulama kodu Vault SDK’sı yüklemeden, sıradan bir dosyadan sır okur. Bu pattern, Container Güvenliği politikalarının ayrılmaz parçası.

AWS Secrets Manager: Lambda Rotation Şeması

AWS Secrets Manager, Vault’un aksine “secret store + rotation orchestrator” konseptinde çalışır: sır, Secrets Manager’da şifreli durur (KMS CMK ile), rotation tetiklenince AWS Lambda fonksiyonunu çağırır, Lambda kaynak servise (RDS, DocumentDB, Redshift) gidip yeni credential üretir, eski credential’ı invalid’e çeker. AWS, RDS-MySQL/PostgreSQL/Aurora/MariaDB, DocumentDB, Redshift için managed rotation Lambda sağlar; geri kalan kaynaklar için kullanıcı kendi Lambda’sını yazar.

Rotation Tipi	Strateji	Downtime Riski	Tipik Frekans	Kullanım Senaryosu
Single User	Aynı user’ın parolasını değiştir	Yüksek (anlık geçiş)	30-90 gün	Tek uygulama, basit setup
Alternating Users	İki user arası dönüşümlü rotation	Düşük (overlap window)	30 gün	Üretim DB, sürekli yazma
Multi-User	3+ user havuzu, sıralı rotation	Çok düşük	7 gün	High-availability sistemler
Custom Lambda	Kullanıcı tanımlı rotation kodu	Kullanıcıya bağlı	Bağımsız	SaaS API key, custom DB

Pratik notlar:

• Avantaj: AWS-native servislerle entegrasyon sıfır kurulum, Lambda ücretsiz katmanda 30 günde bir rotation 1M secret için bile maliyet sıfır seviyesinde.
• Dezavantaj: Multi-cloud senaryoda Azure veya GCP kaynaklarıyla doğal entegrasyon yok; Vault’a göre engine zenginliği düşük.
• Ne zaman seç: Saf AWS stack, <100 sır, Lambda yazmaktan kaçınmak isteyen takımlar.
• Ne zaman kaçın: Multi-cloud, on-prem + cloud hybrid, PKI/SSH gibi gelişmiş engine ihtiyacı.

AWS Secrets Manager fiyatlandırması 2026’da hala 0,40 USD/sır/ay + 0,05 USD/10K API çağrısı olarak işliyor. 1.000 sır + 1M çağrı için aylık maliyet ~405 USD. Detaylar için AWS Secrets Manager rotation dokümantasyonu referans alınabilir.

Üç Bulut Karşılaştırma: Vault vs AWS vs Azure vs GCP

Çok-bulut bir kurumda secret manager seçimi nadiren tek bir ürünle biter. Aşağıdaki tablo, 2026 itibarıyla dört platformun rotation odaklı karşılaştırmasıdır:

Özellik	HashiCorp Vault Enterprise	AWS Secrets Manager	Azure Key Vault	GCP Secret Manager
Dinamik DB credential	Evet (80+ engine)	Sadece RDS/DocDB/Redshift managed	Sadece SQL Server managed	Üçüncü taraf (Cloud SQL Auth Proxy)
PKI engine	Tam (root CA, intermediate, leaf)	AWS Certificate Manager ayrı servis	Key Vault Certificates (sınırlı)	Certificate Authority Service ayrı
Multi-cloud sync	Evet (Secret Sync)	Hayır	Hayır	Hayır
Auto-rotation	Tam programlanabilir	Lambda tabanlı, 30+ kaynak	EventGrid + Function App	Cloud Functions, custom
Pricing (1K sır + 1M API)	~5K USD / cluster / ay	~405 USD / ay	~340 USD / ay	~350 USD / ay
Self-hosted	Evet (Community/Enterprise)	Hayır	Hayır	Hayır
FIPS 140-3 sertifikasyonu	Enterprise	KMS üzerinden	Premium SKU	HSM tier
Audit log retention	Sınırsız (kullanıcı yönetir)	CloudTrail bağlı	Azure Monitor bağlı	Cloud Logging bağlı

Pratik kural: tek bulutsanız bulut-native, iki+ bulutsanız Vault + sync. Vault’un operasyon maliyeti (3-node HA cluster, Consul backend, KMS unsealing, audit pipeline) ilk yıl ~40K USD’ye yaklaşır; bu yatırım ancak >500 sır veya >2 bulut senaryosunda kendini karşılar. Daha derin secret store mimarisi tartışması için Secret Management Vault içeriğine bakılabilir.

Rotation Frekansı: NIST, PCI DSS ve CIS Gerekleri

“Ne kadar sıkça rotate etmeliyim?” sorusunun cevabı sektörel uyumluluk standartlarına bağlı. 2026 itibarıyla geçerli rakamlar:

Standart	Sır Tipi	Maksimum Rotation Süresi	Kaynak
PCI DSS 4.0	Kriptografik anahtar (kart verisi)	Crypto period (annual review zorunlu)	Req 3.6, 3.7
NIST SP 800-57 Rev. 5	Symmetric encryption key	1-2 yıl (yüksek değer için <1 yıl)	Section 5.3
NIST SP 800-53 Rev. 5	Service account credential	60 gün	IA-5(1)
CIS Controls v8	Privileged account	90 gün	Control 5.4
SOC 2 Type II	API keys	Yıllık + olay sonrası	CC6.1
HIPAA Security Rule	PHI erişim credentialı	Belirsiz, “reasonable” standart	§164.308(a)(5)
ISO 27001:2022	Authentication info	Risk-based, yıllık review	A.5.17

Önemli not: 2024 sonunda yayınlanan NIST SP 800-63B Rev. 4 (Digital Identity Guidelines) parola rotation’unu zorunlu olmaktan çıkardı — sadece kompromise belirtisi olduğunda rotation öneriliyor. Ancak bu insan parolaları için geçerli; servis hesabı ve API key’leri için yukarıdaki frekanslar hala bağlayıcı.

Üretim Pipeline’ı: Adım Adım Dinamik DB Credential

Aşağıda bir Kubernetes uygulamasının PostgreSQL’e Vault üzerinden dinamik credential ile bağlandığı tam akış. Bu, üretim ortamında 2026 baseline’ı kabul edilmeli.

1. Vault’a kök DB credential tanımla: vault write database/config/prod-postgres plugin_name=postgresql-database-plugin connection_url="postgresql://{{username}}:{{password}}@db:5432/app" allowed_roles="readonly,readwrite" username="vault_root" password="$ROOT_PWD"
2. Role tanımla (TTL ile): vault write database/roles/readonly db_name=prod-postgres creation_statements="CREATE ROLE "{{name}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO "{{name}}";" default_ttl="1h" max_ttl="24h"
3. Kubernetes auth backend kur: Service Account JWT ile Vault’a kimlik doğrulama, namespace/SA → Vault role eşleştirmesi.
4. Vault Agent sidecar deploy et: Pod annotation ile vault.hashicorp.com/agent-inject: "true", vault.hashicorp.com/role: "readonly", secret template path tanımla.
5. Uygulama secret’ı dosyadan oku: /vault/secrets/db-creds dosyasından credential. Vault Agent TTL’in %2/3’ünde yeniler, uygulama yeniden okur.
6. Lease tracking ve audit: Vault audit log’unu syslog veya OpenSearch’e gönder, hangi pod hangi credential’ı ne kadar süre kullandı görünür olsun.
7. Revoke senaryoları: Pod silindiğinde Vault Agent POST /v1/sys/leases/revoke çağrısı yapar; manuel revoke için vault lease revoke -prefix database/creds/readonly.

Bu pipeline’ı CI/CD ile entegre ederken DevSecOps Shift-Left prensiplerine uygun olarak, hiçbir credential’ın CI değişkeni olarak hardcode edilmemesine dikkat etmek gerekir. CI runner, kendi kısa ömürlü Vault token’ı ile credential çeker.

Yaygın Tuzaklar ve Performans Maliyetleri

Rotation otomasyonu, doğru tasarlanmadığında üretimde yeni sınıf hatalar yaratır. Sahada en sık görülenler:

• Connection pool patlaması: Eski credential’la açık duran pool bağlantıları, rotation anında reddedilir. Çözüm: HikariCP/pgbouncer’da maxLifetime < TTL/2 ayarı, pool refresh hook'u.
• Thundering herd: Yüzlerce pod aynı anda rotate olunca Vault cluster’ı 10K+ RPS’ye çıkar. Çözüm: jitter, staggered rotation (TTL’e ±%10 rastgelelik).
• Audit log gap: Vault audit broker tek bir backend’e bağlıysa ve o down olursa Vault sealed olur. Çözüm: minimum 2 audit backend (syslog + file).
• KMS auto-unseal failure: AWS KMS bölge çöktüğünde Vault sealed kalır. Çözüm: Transit auto-unseal ile cross-region failover, manual unseal şartlarını hazır tut.
• Cron-based custom rotation overlap: İki rotation Lambda’sı aynı anda tetiklenirse race condition. Çözüm: DynamoDB lock, Step Functions ile sıralama.
• Application-side cache TTL > Vault TTL: Uygulama eski credential’ı önbellekte tutar, rotation sonrası 401 alır. Çözüm: cache TTL = Vault TTL × 0,5.

Vault Enterprise 1.18 ile yapılan benchmark’larda 3-node HA cluster (m5.xlarge, Consul backend) tipik olarak şu rakamları tutuyor:

İşlem	p50 Latency	p99 Latency	Maksimum Throughput
kv-v2 read	3 ms	22 ms	~4.500 RPS
database/creds (dinamik DB)	85 ms	420 ms	~250 RPS
transit encrypt (4 KB payload)	2 ms	15 ms	~3.500 ops/s
pki/issue (RSA 2048)	120 ms	650 ms	~120 RPS
token/create	8 ms	45 ms	~2.000 RPS

Dinamik DB credential’da p99 ~420 ms’nin temel sebebi PostgreSQL CREATE ROLE komutunun maliyeti; bu yüzden uygulamalar credential’ı startup’ta bir kez çeker, dosyadan okumayı tercih eder. Bu rakamlar, üretim kapasite planlaması için HashiCorp Vault Performance Reference ile karşılaştırılmalı.

Workload Identity: Sırsız Mimari (2026 Yönelim)

2026’da öne çıkan trend, “rotation yerine hiç sır kullanma” yaklaşımı: workload identity federation. AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity Federation, Azure AD Workload Identity ve SPIFFE/SPIRE bu kategorinin temel oyuncuları. Kubernetes Service Account JWT’si bulut sağlayıcısının OIDC provider’ına gönderilir, kısa ömürlü STS token alınır; uygulama kodunda hiçbir sır yoktur.

Çözüm	Token TTL	Setup Zorluk	Multi-cloud	Senaryo
AWS IRSA	15 dk – 12 saat	Orta (OIDC trust setup)	Hayır (sadece AWS)	EKS workload → S3/DynamoDB
GCP Workload Identity	1 saat	Düşük (GKE native)	Hayır	GKE workload → BigQuery
Azure AD Workload Identity	1 saat	Orta	Hayır	AKS workload → Key Vault
SPIFFE/SPIRE	5 dk – 1 saat	Yüksek (kendin host edersin)	Evet	Çoklu küme, on-prem + cloud
OIDC Identity Federation	1 saat	Düşük	Evet (kısmen)	GitHub Actions → AWS deploy

GitHub Actions için OIDC federation, 2024 sonrasında AWS deploy pipeline’larında standart hale geldi: long-lived AWS_ACCESS_KEY_ID secret’ı yerine job runtime’ında STS token alınır. Bu pratik, Ömer Önal’ın yürüttüğü kurumsal DevSecOps danışmanlık projelerinde rotation gereksinimini Lambda kompleksitesi olmadan ortadan kaldıran ana çözüm oldu. Resmi rehber için GitHub OIDC AWS yapılandırması incelenmeli.

Olay Müdahalesi: Sırrın Sızdığını Tespit Etmek

Otomatik rotation, sızıntı olmadığını garantilemez; sadece pencereyi daraltır. Sızıntı tespiti için üç katmanlı yaklaşım çalışıyor:

1. Repo tarayıcılar: Gitleaks, GitGuardian, TruffleHog — push hook olarak pre-commit veya CI’da çalışır. GitGuardian 2025 verisine göre commit başına ortalama 0,17 ms tarama, %0,3 false positive.
2. Honey credentials: Vault’ta veya AWS’de hiçbir uygulamanın kullanmadığı tuzak credential’lar oluştur; bunlardan API çağrısı geldiğinde alarm. Detection rate ~%85 sızıntı sonrası 24 saat içinde.
3. Anomaly detection: CloudTrail/Vault audit log’unda olağandışı IP, saat, kaynak deseni. AWS GuardDuty 2025 verisine göre credential misuse’un %62’sini ilk saat içinde yakalıyor.

Sızıntı tespit edildiğinde “panik rotation” prosedürü hazır olmalı: tek komutla tüm aktif lease’leri revoke et, KMS key’i rotate et, audit raporu üret. Bu prosedürü kırmızı takım sızma egzersizlerinde yılda en az iki kez test etmek, gerçek olay anında 30 dakikalık MTTR’yi mümkün kılar.

Sıkça Sorulan Sorular

Sonuç

Otomatik secret rotation, 2026 kurumsal güvenlik baseline’ının pazarlık edilemez bir bileşenidir: manuel süreç frekansı yıllığa düşürür ve büyük ihtimalle hiç çalışmaz, otomasyon ise rotation’u görünmez bir platform özelliğine dönüştürür. Karar çerçevesi şudur: tek bulut + <100 sır → AWS Secrets Manager / Azure Key Vault; çok bulut + 500+ sır + PKI/SSH ihtiyacı → HashiCorp Vault Enterprise; her durumda bulut kaynaklarına workload identity federation ile sır sayısını minimize et.

Sıralı eylem planı: önce envanter çıkar (kaç sır var, nerede, kim erişiyor), sonra dinamik credential’a geçilebilecek olanları işaretle (DB, cloud IAM, mTLS), kalan statik sırlar için 30-90 gün otomatik rotation programla, son olarak sızıntı tespit katmanı (GitGuardian + honey credentials + CloudTrail alarm) kur. Bu mimari pilot kurulumdan production’a 8-12 hafta içinde geçirilebilir; özelleştirilmiş bir yol haritası ve kurumsal değerlendirme için iletişim sayfası üzerinden ulaşılabilir.

Son hatırlatma: rotation otomasyonu güvenliğin tamamı değildir. API Güvenliği OWASP Top 10 ilkeleri ve uygun yetkilendirme modelleri ile birlikte değerlendirildiğinde anlam kazanır; tek başına “rotation yapıyoruz” cümlesi, yanlış yetkilendirilmiş bir sırrı kimseye güvende tutmaz.