Secret; veritabanı parolası, API anahtarı, TLS private key, OAuth client secret veya encryption key gibi yetkisiz erişimde ciddi zarar doğurabilecek her türlü hassas yapılandırma değeridir. Secret'ları kaynak kodunda, düz metin config dosyasında veya CI log'larında bırakmak en yaygın ve en pahalı güvenlik hatalarından biridir. Secrets yönetimi, bu değerlerin yaşam döngüsünü — oluşturma, dağıtım, kullanım, rotasyon, iptal — merkezi ve denetlenebilir biçimde yönetme disiplinidir.
Secret anti-pattern'leri
- Git'te .env: History'den silmek yetmez; rotate şart.
- Base64 "şifreleme": Encoding güvenlik sağlamaz.
- ARG ile Docker build: Layer history'de kalır.
- Log'a yazdırma: Connection string exception mesajında sızar.
GitHub Secret Scanning ve gitleaks gibi araçlar repoda secret tespit eder; ancak önleyici mimari her zaman reaktif taramadan üstündür.
Merkezi secret store seçenekleri
HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager ve Kubernetes Secrets farklı operasyonel modeller sunar. Vault dynamic secret üretebilir: PostgreSQL için 1 saatlik geçici kullanıcı, süre dolunca otomatik iptal. Cloud-native manager'lar KMS ile envelope encryption kullanır; audit log ve IAM entegrasyonu hazırdır.
# Kubernetes External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: api-db
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: api-db-credentials
data:
- secretKey: password
remoteRef:
key: prod/api/db
property: password
Pod, Kubernetes Secret'ı volume veya env olarak mount eder; uygulama Vault SDK'sı ile doğrudan da okuyabilir. Sidecar injector pattern (Vault Agent) token yenilemeyi otomatikleştirir.
Least privilege ve erişim modeli
Her servis yalnızca ihtiyaç duyduğu secret'lara erişmelidir. Vault policy veya IAM role boundary ile api-service yalnızca secret/data/prod/api/* path'ini okuyabilir. İnsan erişimi break-glass prosedürü ile time-bound olmalıdır; JIT (just-in-time) erişim PagerDuty onayıyla açılır, 4 saat sonra kapanır.
Rotasyon stratejisi
Statik secret'lar periyodik rotate edilmelidir: API key 90 günde, DB parolası 30 günde, TLS sertifikası otomatik (Let's Encrypt, cert-manager). Zero-downtime rotasyon için dual-credential dönemi gerekir: yeni secret eklenir, tüm consumer'lar güncellenir, eski iptal edilir. Vault database secrets engine rotation'ı uygulama kodu değişmeden yönetir.
Signal vs noise
Her secret değişiminde deploy tetiklemek yerine, runtime secret refresh destekleyen SDK kullanın. .NET IOptionsMonitor veya sidecar reload ile uygulama yeniden başlatılmadan yeni değer alınır.
CI/CD entegrasyonu
Pipeline secret'ları platform secret store'da tutar; OIDC ile cloud'a kimlik doğrulama yapılır, uzun ömürlü access key kullanılmaz. Fork PR'da secret expose edilmez. Build-time secret gerekiyorsa BuildKit --secret mount kullanın:
RUN --mount=type=secret,id=nuget_token \
dotnet nuget add source ... --password $(cat /run/secrets/nuget_token)
Şifreleme ve key hierarchy
Envelope encryption: data encryption key (DEK) veriyi şifreler, key encryption key (KEK) DEK'yi şifreler. KEK HSM veya cloud KMS'te kalır. Master key rotasyonu DEK re-wrap ile yapılır. Uygulama seviyesinde field-level encryption hassas PII için ek katman sağlar.
Audit ve uyumluluk
Her secret erişimi loglanmalıdır: kim, ne zaman, hangi path, hangi IP. SIEM alert'leri anormal erişim desenlerini yakalar. PCI-DSS, SOC2 ve KVKK denetimlerinde secret yönetimi kanıtlanabilir olmalıdır. Log'ların kendisi secret içermemelidir; redaction middleware zorunludur.
Local development
Geliştiriciler üretim secret'ına asla erişmemelidir. Local override dosyaları (appsettings.Development.json, docker compose env) zayıf ama izole credential içerir. 1Password CLI veya direnv ile kişisel secret'lar şifreli vault'tan çekilir; repoya girmez.
Incident response
Secret sızıntısı tespit edildiğinde: derhal rotate, eski credential'ı invalidate, erişim loglarını incele, etkilenen sistemleri belirle, müşteri bildirimi gereksinimini değerlendir. Playbook önceden yazılmalıdır; panik anında aranacak kişi listesi ve komutlar hazır olmalıdır.
Kubernetes özel dikkat
Native Secret objesi base64 encoded'dır, encrypted at rest etcd yapılandırması gerektirir. RBAC ile Secret okuma yetkisi sınırlı olmalıdır. Sealed Secrets veya SOPS ile GitOps repo'da şifreli secret saklanabilir; cluster'ta controller decrypt eder.
Metrikler ve olgunluk
- Secret'ların yüzde kaçı merkezi store'da?
- Ortalama rotasyon süresi hedefe uygun mu?
- Hardcoded secret tarama sıfır mı?
- Break-glass erişim sayısı trendi?
Secrets yönetimi bir araç satın almakla bitmez; organizasyonel disiplin, otomasyon ve sürekli denetim gerektirir. Merkezi store, least privilege, otomatik rotasyon ve CI entegrasyonu bir araya geldiğinde secret kaynaklı incident olasılığı ölçülebilir biçimde düşer; geri kalan risk insan faktörüne indirgenir ve eğitimle yönetilir.
Zero trust ve workload identity
Pod'ların birbirine güvenmesi IP adresine dayanmamalıdır. SPIFFE/SPIRE ile her workload kısa ömürlü SVID sertifikası alır; mTLS otomatik kurulur. AWS IRSA, Azure Workload Identity ve GCP Workload Identity Federation, cloud API erişiminde kalıcı credential ihtiyacını ortadan kaldırır. Secret dağıtımı bu kimlik katmanı üzerine inşa edildiğinde lateral movement riski azalır.
Secret scanning pipeline entegrasyonu
Pre-commit hook (gitleaks, detect-secrets) yerel commit öncesi yakalar; CI'da trufflehog veya GitHub Advanced Security tüm branch geçmişini tarar. False positive yönetimi için allowlist dosyası versiyonlanır. Tespit edilen secret otomatik rotate ticket'ı açar; manuel müdahale SLA'si 1 saat olarak tanımlanabilir.
Secret sınıflandırması
Tüm secret'lar eşit kritiklikte değildir. Tier 1 (production DB master key, signing key) HSM veya dedicated Vault namespace gerektirir; erişim MFA ve dual control ile korunur. Tier 2 (API key, webhook secret) merkezi store'da rotate edilir. Tier 3 (development credential) izole ortamda kalır, production erişimi yasaktır. Sınıflandırma etiketi (confidentiality=tier1) IAM policy ve audit retention süresini belirler.
Vault operasyonel dayanıklılık
Vault cluster HA modunda en az üç node ile çalışır; Raft storage backend consensus sağlar. Unseal işlemi Shamir key veya auto-unseal (cloud KMS) ile yapılır. Disaster recovery için replication veya snapshot stratejisi tanımlanır. Vault outage durumunda uygulamalar cache'lenmiş secret ile sınırlı süre devam edebilir; bu süre SLA olarak dokümante edilmelidir. Düzenli restore tatbikatı, backup'ın çalıştığını kanıtlar.
Uygulama entegrasyon kalıpları
ASP.NET Core'da AddAzureKeyVault veya custom ConfigurationProvider ile secret'lar startup'ta yüklenir. Connection string'ler options pattern ile tip-güvenli erişilir. Secret değerini loglamamak için structured logging'de masking uygulanır. Health check endpoint'i secret varlığını doğrular ancak değeri asla döndürmez. Sidecar pattern'de uygulama process'i secret dosyasını volume'dan okur; ana uygulama binary'si secret store SDK'sı bilmez.
Üçüncü taraf ve vendor secret'ları
Stripe, SendGrid, Twilio gibi dış servis anahtarları ayrı namespace'te tutulur. Vendor compromise senaryosunda yalnızca ilgili key rotate edilir. Webhook signing secret'ları request doğrulaması için kullanılır; timing-safe comparison şarttır. OAuth refresh token'ları kullanıcı bazlı secret sayılır; encryption at rest ve kısa TTL ile korunur.
Secrets yönetimi olgunluğu zamanla inşa edilir: önce hardcoded değerleri temizleyin, ardından merkezi store'a taşıyın, sonra rotasyonu otomatikleştirin. Her adımda audit ve eğitim paralel yürütülmelidir; araç olmadan politika, politika olmadan araç sürdürülemez. Yıllık penetration test bulguları secret yönetimi gap'lerini ortaya çıkarır ve iyileştirme backlog'unu besler. Ekip genelinde secret hygiene eğitimi, en pahalı güvenlik aracından daha etkili olabilir. Yeni işe başlayan her geliştirici secret policy onboarding'inden geçmelidir. Bu küçük adım uzun vadede büyük fark yaratır.
