Gizli Veri (Secret) Yönetimi: HashiCorp Vault ve AWS Secrets

Bir API anahtarının yanlışlıkla Git deposuna gönderilmesi, yıllardır değiştirilmeyen bir veritabanı parolasının onlarca uygulama tarafından paylaşılması veya production erişim bilgisinin CI/CD loglarında görünmesi, iyi çalışan bir sistemi birkaç dakika içinde güvenlik problemine dönüştürebilir. On yıllık yazılım ve altyapı deneyimimde secret yönetiminde en sık gördüğüm hata, ekiplerin yalnızca “parolayı nerede saklayalım?” sorusuna odaklanmasıdır. Oysa güçlü bir yaklaşım secret'ın nasıl üretildiğini, hangi kimliğin onu okuyabildiğini, uygulamaya nasıl ulaştığını, ne zaman değiştirildiğini ve bir olay anında ne kadar hızlı iptal edilebildiğini birlikte ele alır. Gizli Veri (Secret) Yönetimi: HashiCorp Vault ve AWS Secrets konusu da tam olarak bu noktada önem kazanır çünkü iki çözüm benzer ihtiyaçlara temas etse de çalışma modelleri, operasyon sorumlulukları ve güçlü oldukları kullanım alanları farklıdır. Bu rehberde HashiCorp Vault ve AWS Secrets Manager ile secret yönetimi nasıl yapılır, HashiCorp Vault mı AWS Secrets Manager mı kullanılmalı, Kubernetes ve CI/CD pipeline içinde Vault secret yönetimi nasıl yapılır ve kurumsal sistemlerde API key parola sertifika ve secret rotation nasıl otomatikleştirilir gibi pratik sorulara doğrudan yanıt vereceğiz.

Secret Management Nedir?

Secret management, API key, parola, token, private key ve benzeri hassas erişim bilgilerinin yalnızca güvenli bir yerde tutulması değil, bütün yaşam döngüsü boyunca kontrollü biçimde yönetilmesidir. Sağlıklı bir sistemde secret oluşturma, erişim yetkilendirmesi, dağıtım, kullanım, yenileme, rotation, revocation, expiration, deletion ve audit aynı güvenlik modelinin parçalarıdır. Bir uygulamanın production veritabanı parolasını dosyadan okuması ile çalışma anında kendi workload identity'si üzerinden kısa ömürlü credential alması arasında ciddi güvenlik farkı vardır. Bu nedenle secret management mimarisi kurulurken “hangi kasayı kullanalım?” sorusundan önce “hangi secret'ı tamamen ortadan kaldırabiliriz?” sorusu sorulmalıdır. İyi tasarlanmış bir yapı geliştiricinin işini zorlaştırmaz, tam tersine güvenli erişim yöntemlerini standartlaştırarak ekiplerin daha az manuel işlem yapmasını sağlar.

Secret Nedir?

Secret, yetkisiz bir kişi veya süreç tarafından ele geçirildiğinde sisteme erişim, işlem yapma veya başka kaynaklara ulaşma imkânı verebilecek hassas bilgidir. Veritabanı kullanıcı adı ve parolası, API key, OAuth refresh token, service account credential, SSH private key ve TLS private key bu gruba girer. Bir bilginin secret olarak değerlendirilmesinde temel soru, bu değerin açığa çıkmasının güvenlik sınırlarını aşmaya yarayıp yaramadığıdır. Örneğin herkese açık TLS sertifikası secret değildir, ancak sertifikaya ait private key kesinlikle secret olarak ele alınmalıdır. Doğru sınıflandırma yapılmadığında rotation sıklığı, erişim politikası ve audit gereksinimleri de yanlış tasarlanabilir.

API Key

API key, bir uygulamanın harici veya dahili servise erişirken kullandığı kimlik doğrulama bilgisidir. Kaynak kod içine yazıldığında repository erişimi olan kişiler, CI sistemleri ve farklı build ortamları bu değeri görebilir. API key mümkünse yalnızca ihtiyaç duyan workload tarafından runtime sırasında secret manager üzerinden alınmalıdır. Sağlayıcı izin veriyorsa kullanım kapsamı, kaynak IP, erişilebilecek API operasyonları ve kota gibi ek sınırlar uygulanmalıdır. Kalıcı API key yerine workload identity veya kısa ömürlü token modeli destekleniyorsa bunu tercih etmek daha güçlü bir güvenlik yaklaşımıdır.

Database Credential

Database credential çoğunlukla kullanıcı adı ve paroladan oluşur, ancak token veya sertifika tabanlı bağlantı bilgileri de aynı başlık altında değerlendirilebilir. Onlarca mikroservisin tek bir ortak database kullanıcısını paylaşması hem audit hem de olay müdahalesi açısından sorun yaratır. Bir uygulama compromise olduğunda paylaşılan hesabın bütün yetkileri risk altına girer ve credential değiştirildiğinde diğer uygulamalar da etkilenir. Vault Database Secrets Engine gibi çözümler uygulama başına kısa ömürlü ve benzersiz database credential üretme imkânı sunabilir. AWS tarafında ise Secrets Manager rotation veya desteklenen database servislerinde identity tabanlı bağlantı seçenekleri değerlendirilerek uzun ömürlü parola bağımlılığı azaltılabilir.

OAuth Token

OAuth token, kullanıcının veya workload'un belirli kaynaklara erişimini temsil eden yetkilendirme bilgisidir. Access token değerlerinin kısa ömürlü tutulması riski azaltır, ancak refresh token gibi daha uzun yaşayan değerler güçlü biçimde korunmalıdır. Token'ın loglara, hata mesajlarına veya telemetry verisine yanlışlıkla yazılması ciddi sızıntı kaynağı olabilir. Scope mümkün olduğunca dar tutulmalı ve gereksiz erişim yetkileri kaldırılmalıdır. Revocation mekanizmasının nasıl çalıştığı da önceden bilinmelidir çünkü bir güvenlik olayında yalnızca secret manager kaydını silmek aktif token'ı her zaman geçersiz hale getirmez.

Service Account Credential

Service account credential, insan kullanıcı yerine uygulama, servis veya otomasyonun kullandığı erişim bilgisidir. Geleneksel yapılarda uzun ömürlü anahtar dosyaları veya parolalar kullanılsa da modern sistemlerde workload identity daha güvenli bir model sunar. Static service account key zorunluysa her workload için ayrı değer kullanılmalı ve düzenli rotation uygulanmalıdır. Aynı credential'ın birden fazla sistemde paylaşılması audit kabiliyetini düşürür ve blast radius alanını büyütür. Mümkünse servis hesabı credential saklamak yerine platformun kendi federated identity mekanizmasına geçmek daha doğru sonuç verir.

SSH Credential

SSH credential, sunuculara uzaktan erişim için kullanılan parola, private key veya kısa ömürlü sertifika olabilir. Ortak bir private key'in onlarca sunucuda yıllarca kullanılması çalışan değişikliği, anahtar sızıntısı ve erişim takibi açısından büyük risk oluşturur. Kullanıcı veya otomasyon için kısa ömürlü SSH certificate üretmek kalıcı private key dağıtımını azaltabilir. Erişim kimlik bazlı hale geldiğinde hangi kişinin hangi sunucuya ne zaman bağlandığı daha açık biçimde izlenebilir. SSH credential yönetimi yalnızca key saklamak değil, erişim süresi, hedef kapsamı, revocation ve audit süreçlerini birlikte tasarlamak anlamına gelir.

TLS Private Key

TLS private key, sertifika sahibinin kimliğini kriptografik olarak kanıtlayan hassas anahtar materyalidir. Sertifika public olabilir, ancak private key yalnızca yetkili servis tarafından erişilebilir olmalıdır. Private key ele geçirildiğinde saldırgan ilgili servis kimliğini taklit edebilir veya belirli koşullarda şifreli iletişim güvenliğini etkileyebilir. Vault PKI Secrets Engine gibi çözümler kısa ömürlü sertifika üretimi ve otomatik yenileme süreçlerinde kullanılabilir. Sertifika yaşam süresini kısaltmak, private key'leri merkezi biçimde yönetmek ve otomatik yenileme kullanmak manuel sertifika operasyonuna göre daha güvenli bir model oluşturur.

Secret, Encryption Key ve Certificate Arasındaki Fark

Secret, erişimi kısıtlanması gereken hassas veriler için kullanılan genel kavramdır ve parola, token veya private key gibi farklı değerleri kapsar. Encryption key, veriyi şifrelemek veya çözmek için kullanılan kriptografik anahtardır ve çoğu zaman normal application secret'larından farklı bir yaşam döngüsüne sahiptir. Certificate ise bir public key ile kimliği ilişkilendiren imzalı yapıdır ve çoğu senaryoda gizli tutulması gerekmez. Sertifikanın karşılığı olan private key ise yüksek hassasiyetli secret olarak değerlendirilmelidir. Bu ayrımı doğru yapmak Secrets Manager, KMS ve PKI servislerinin görevlerini birbirine karıştırmadan doğru teknoloji seçmenizi sağlar.

Machine Secret ve Human Credential Arasındaki Fark

Machine secret, uygulama, container, servis, agent veya otomasyon tarafından kullanılan erişim bilgisidir. Human credential ise bir kişinin sisteme giriş yapmasını sağlayan parola, token veya benzeri kimlik doğrulama bilgisidir. Büyük altyapılarda machine identity sayısı insan kullanıcı sayısından kat kat hızlı büyüdüğü için otomasyon burada çok daha önemli hale gelir. İnsan erişiminde SSO ve MFA öne çıkarken machine identity tarafında IAM Role, OIDC federation, Kubernetes Service Account ve kısa ömürlü credential daha uygun olabilir. İki grubu aynı yöntemle yönetmeye çalışmak çoğu zaman gereksiz static secret üretimine ve geniş yetkilere yol açar.

Secrets Management Neden Gereklidir?

Secret management olmadığı zaman ekipler hassas değerleri configuration file, environment variable, CI variable, repository veya geliştirici bilgisayarları gibi farklı noktalara dağıtmaya başlar. Bir süre sonra hangi secret'ın nerede kullanıldığı, kimin sahibi olduğu ve ne zaman değiştirilmesi gerektiği bilinmez hale gelir. Merkezi yönetim access policy, rotation, audit ve incident response süreçlerini standartlaştırır. Bir credential sızdığında hangi uygulamaların etkilendiğinin hızlıca görülebilmesi müdahale süresini ciddi biçimde azaltır. Bu nedenle secret management yalnızca güvenlik kasası değil, aynı zamanda kimlik, yetki ve operasyon disiplini sağlayan bir platform yaklaşımıdır.

Secret'ların Kaynak Kodda Saklanması Neden Tehlikelidir?

Kaynak kod uzun süre yaşayan, kopyalanan, farklı bilgisayarlara indirilen ve çeşitli otomasyon sistemlerinden geçen bir varlıktır. Secret bu yapının içine eklendiğinde yalnızca repository değil, geliştirici makineleri, CI runner'ları, cache sistemleri ve yedekler de hassas veriyi taşımaya başlar. Repository private olsa bile erişim kapsamı secret manager'a göre çok daha geniş olabilir. Daha önemlisi, secret sonraki commit'te silinse bile Git history içinde yaşamaya devam edebilir. Kaynak kod ile hassas değeri başlangıçtan itibaren ayırmak bu nedenle secret yönetiminin en temel kurallarından biridir.

Hard-Coded Password Problemi

Hard-coded password, uygulamanın kaynak kodu içine doğrudan yazılmış paroladır. Bu yöntem başlangıçta kolay görünse de rotation gerektiğinde kodun yeniden build edilmesini ve deployment yapılmasını gerektirir. Kod erişimi olan herkes credential'ı da görebilir ve aynı değer yanlışlıkla development, staging ve production ortamlarına taşınabilir. Static analysis veya repository scanning bu tür değerleri tespit etmeye yardımcı olsa da esas çözüm secret'ı koddan tamamen ayırmaktır. Uygulama mümkünse runtime sırasında kendi workload identity'si ile yetkili secret kaynağından güncel değeri almalıdır.

Git Repository'ye API Key Göndermek

Bir API key Git repository'ye commit edildiğinde yalnızca tek dosyada değil repository geçmişinde de kalıcı iz bırakabilir. Public repository'de otomatik scanner'lar bu değeri kısa sürede tespit edebilir ve kötüye kullanım başlayabilir. Private repository de tamamen güvenli değildir çünkü CI sistemleri, developer cihazları ve üçüncü taraf entegrasyonlar repository içeriğine erişebilir. Böyle bir durumda yalnızca commit'i silmek yeterli değildir ve key sızmış kabul edilmelidir. Önce credential revoke edilmeli, yenisi üretilmeli ve ardından repository history temizliğiyle secret'ın gereksiz kopyaları azaltılmalıdır.

Git History'de Secret Kalması

Git önceki commit'leri tuttuğu için bir secret'ın sonraki commit'te silinmesi geçmişteki değeri ortadan kaldırmaz. Repository clone edilmişse eski commit farklı bilgisayarlarda da bulunabilir. Bu nedenle secret history'ye girdikten sonra artık güvenilir kabul edilmemelidir. İlk adım credential'ı geçersiz hale getirmek ve yeni bir değer üretmektir. History rewrite işlemi ek temizlik sağlar, ancak rotation yerine geçmez ve daha önce alınmış kopyaları otomatik olarak ortadan kaldırmaz.

Configuration File İçinde Secret

Configuration file kaynak koddan ayrı tutulsa bile güvenli bir secret store değildir. Dosya yanlışlıkla container image içine eklenebilir, backup sistemlerinde kalabilir veya geniş filesystem izinleriyle okunabilir hale gelebilir. Normal configuration değerleri ile hassas credential'ların aynı dosyada tutulması erişim sınırlarını belirsizleştirir. Secret gerekiyorsa runtime mount veya güvenli API retrieval yöntemi tercih edilmelidir. Dosya tabanlı kullanım zorunluysa izinler dar tutulmalı, dosyanın kalıcı disk üzerinde gereksiz süre yaşamaması sağlanmalı ve rotation davranışı test edilmelidir.

CI/CD Log'larına Secret Yazılması

CI/CD pipeline'larında debug modu, shell trace veya yanlış yazılmış bir echo komutu secret değerini loglara çıkarabilir. Bu loglar çoğu zaman geliştirici ve operasyon ekiplerinin geniş bir bölümü tarafından erişilebilir durumdadır. Masking mekanizması yardımcı olur, ancak encoded veya dönüştürülmüş secret her durumda doğru biçimde maskelenmeyebilir. Bu nedenle hassas değerler bilinçli olarak stdout veya stderr'e yazılmamalıdır. Pipeline'ın uzun ömürlü credential yerine kısa süreli OIDC veya federated identity kullanması, log sızıntısının etkisini de önemli ölçüde azaltır.

Docker Image İçine Secret Gömülmesi

Docker build sırasında kullanılan secret son image katmanında görünmese bile önceki layer içinde kalabilir. Image registry erişimi olan bir kullanıcı katmanları inceleyerek değere ulaşabilir. Build-time secret ve runtime secret kavramları bu nedenle birbirinden ayrılmalıdır. Build için özel package repository token gerekiyorsa geçici mount gibi mekanizmalar kullanılabilir, ancak production database password image içine gömülmemelidir. Runtime uygulama kendi identity'siyle secret manager'a eriştiğinde image farklı environment'larda aynı şekilde güvenle kullanılabilir.

Terraform State İçinde Hassas Veriler

Terraform'da bir değeri sensitive olarak işaretlemek terminal çıktısında görünürlüğü azaltabilir, ancak değer state dosyasında bulunmaya devam edebilir. Bu nedenle state backend yüksek hassasiyetli bir sistem olarak değerlendirilmelidir. Encryption, minimum IAM yetkisi, access logging ve kontrollü backup gibi önlemler uygulanmalıdır. Mümkünse Terraform yalnızca secret container, metadata, policy ve rotation configuration oluşturmalı, gerçek secret değeri ayrı yaşam döngüsüyle yönetilmelidir. Bu yaklaşım state dosyasının zamanla dev bir credential deposuna dönüşmesini engeller.

Environment Variable Kullanımının Riskleri

Environment variable uygulama entegrasyonunu kolaylaştırdığı için yaygın biçimde kullanılır, ancak tek başına güvenli bir secret yönetim modeli değildir. Process inspection, crash dump, debug çıktısı veya yanlış loglama hassas değerin görünmesine neden olabilir. Ayrıca uygulama startup anında aldığı environment değerini process ömrü boyunca değiştirmediği için rotation sonrasında eski credential kullanılabilir. File mount veya runtime retrieval sık rotation gereken workload'larda daha esnek olabilir. Hangi yöntemin seçileceği uygulamanın threat model'i, framework davranışı ve secret yaşam süresine göre belirlenmelidir.

Secret Lifecycle Nasıl Tasarlanır?

Secret lifecycle bir credential'ın oluşturulmasından kalıcı olarak kaldırılmasına kadar geçen bütün aşamaları kapsar. Güvenli depolama bu sürecin yalnızca küçük bir bölümüdür. Kurumsal bir yapıda owner, risk sınıfı, TTL, rotation sıklığı, revocation yöntemi ve audit gereksinimi secret oluşturulurken tanımlanmalıdır. Böylece yıllarca unutulan veya kime ait olduğu bilinmeyen credential sayısı azalır. Benim tercih ettiğim model, her secret'ın teknik sahibi, kullanım amacı, environment bilgisi ve sona erme davranışının mümkün olduğunca metadata üzerinden izlenebilmesidir.

Secret Creation

Secret oluşturma aşamasında yeterli entropy kullanılmalı ve insan tarafından kolay tahmin edilebilen değerlerden kaçınılmalıdır. Mümkünse credential uygulama geliştiricisi tarafından elle değil, güvenilir platform veya hedef servis tarafından otomatik üretilmelidir. Secret oluşturulduğu anda owner, environment ve kullanım amacı belirlenmelidir. Development ile production için aynı değer kesinlikle kullanılmamalıdır. Otomatik creation mekanizması hem insan hatasını azaltır hem de kurum genelinde ortak güvenlik standardı oluşturur.

Distribution

Distribution secret'ın onu kullanacak workload'a güvenli biçimde ulaştırılmasıdır. İdeal yaklaşım hassas değerin mümkün olduğunca az aracı sistemden geçmesidir. Uygulamanın kendi workload identity'si ile doğrudan secret manager'dan değer alması güçlü bir modeldir. CI sistemi üzerinden secret'ı dosyaya yazıp daha sonra uygulama sunucusuna taşımak gereksiz kopyalar oluşturabilir. Secret'ın geçtiği her yeni sistem ek policy, loglama, storage ve incident response sorumluluğu getirdiği için dağıtım yolu mümkün olduğunca kısa tutulmalıdır.

Consumption

Consumption, uygulamanın secret değerini gerçekten kullandığı aşamadır. Secret gereksiz yere global değişkende tutulmamalı, loglanmamalı ve başka component'lere aktarılmamalıdır. Uygulama yalnızca işini yapmak için gereken credential'a erişebilmelidir. Rotation sonrası güncel değeri alabilecek cache refresh veya reconnect davranışı bulunmalıdır. Secret manager entegrasyonunun güvenliği kadar application code içindeki secret handling kalitesi de bu aşamada belirleyici olur.

Rotation

Rotation mevcut credential'ın yeni bir değerle değiştirilmesidir. Sadece secret manager içindeki değeri değiştirmek rotation'ın tamamlandığı anlamına gelmez çünkü hedef sistem ve tüketici uygulama da yeni değere geçmelidir. Database connection pool, uzun yaşayan process ve cache mekanizmaları özellikle test edilmelidir. Otomatik rotation insan takvimine bağlı unutkanlığı azaltır. Bunun yanında sızıntı anında schedule beklemeden çalışabilecek ayrı emergency rotation prosedürü de hazırlanmalıdır.

Renewal

Renewal belirli süre için verilmiş credential veya lease'in kontrollü biçimde uzatılmasıdır. Vault gibi sistemlerde bazı token ve dynamic credential yaşam süreleri policy sınırları içinde yenilenebilir. Ancak renewal süresiz hale gelirse kısa ömürlü credential modelinin güvenlik avantajı azalır. Maksimum TTL veya toplam yaşam süresi belirlemek bu nedenle önemlidir. Workload sona erdiğinde renewal işleminin de durması ve credential'ın gereksiz yere aktif kalmaması gerekir.

Revocation

Revocation bir credential'ın normal expiration zamanını beklemeden geçersiz hale getirilmesidir. Secret sızıntısı şüphesinde ilk yapılacak işlemlerden biri budur. Dynamic secret modelinde lease üzerinden merkezi revocation önemli avantaj sağlar. Static credential modelinde hedef database, API veya servis üzerinde ayrıca password veya key değişikliği gerekebilir. Kurumun Mean Time to Revoke metriğini ölçmesi olay müdahalesi seviyesini anlamak açısından çok değerlidir.

Expiration

Expiration secret'ın belirlenen süre sonunda otomatik olarak geçersiz hale gelmesidir. Süresiz credential saldırgan tarafından ele geçirildiğinde risk teorik olarak yıllarca devam edebilir. Kısa expiration penceresi bu etkiyi önemli ölçüde sınırlar. Bunun karşılığında uygulamanın yeni credential alma veya renewal davranışının güvenilir biçimde çalışması gerekir. TTL seçimi güvenlik gereksinimi ile uygulama dayanıklılığı arasında dengeli yapılmalıdır.

Deletion

Artık kullanılmayan secret'ın silinmesi secret sprawl sorununu azaltır. Silmeden önce ilgili credential'ın hiçbir workload tarafından kullanılmadığı loglar ve sahiplik bilgisiyle doğrulanmalıdır. Bazı platformlarda recovery window yanlış silme riskine karşı ek güvence sağlar. Kalıcı deletion yapıldığında hedef sistemdeki kullanıcı, API key veya token'ın da gerçekten kapatıldığı kontrol edilmelidir. Sadece secret manager kaydını silmek aktif downstream credential'ı otomatik olarak geçersiz hale getirmeyebilir.

Audit

Audit hangi identity'nin hangi secret'a ne zaman eriştiğini görmenizi sağlar. Başarılı retrieval kadar reddedilen denemeler de güvenlik açısından değerlidir. Audit logları uygulama loglarından ayrı, erişim kontrollü ve değiştirilmeye karşı korunan sistemde tutulmalıdır. SIEM entegrasyonu olağandışı erişim pattern'lerinin daha hızlı fark edilmesini sağlayabilir. Bir secret platformu seçerken audit özelliklerini sonradan eklenecek detay değil temel seçim kriterlerinden biri olarak görmek gerekir.

Incident Response

Incident response secret sızıntısı fark edildiğinde hangi işlemlerin hangi sırayla yapılacağını tanımlar. İlk hedef kötüye kullanılabilecek erişimi durdurmak olduğu için revocation veya rotation geciktirilmemelidir. Ardından audit logları, application erişimleri ve downstream credential bağlantıları incelenerek blast radius belirlenir. Gerekirse ilgili session ve access token değerleri de iptal edilir. Olay sonrasında kök neden analiz edilip aynı sızıntı kanalının başka ekiplerde de bulunup bulunmadığı kontrol edilmelidir.

Static Secret ve Dynamic Secret Arasındaki Fark

Static secret önceden oluşturulan ve rotation yapılana kadar aynı kalan credential'dır, dynamic secret ise çoğunlukla ihtiyaç anında üretilen ve sınırlı süre yaşayan erişim bilgisidir. İki model arasındaki fark yalnızca parola değiştirme sıklığı değildir. Dynamic model credential üretimini workload identity, role ve belirli bir TTL ile ilişkilendirir. Bu sayede her application veya oturum ayrı erişim bilgisine sahip olabilir. Özellikle database ve cloud credential senaryolarında dynamic secret kullanımı paylaşılan uzun ömürlü hesapların yarattığı blast radius'u ciddi biçimde azaltabilir.

Static Secret Nedir?

Static secret önceden oluşturulan ve farklı tüketicilere dağıtılan sabit credential'dır. Bir database kullanıcısının parolasının aylarca değişmeden kalması klasik örnektir. Merkezi secret manager static değeri güvenli saklayabilir, ancak credential'ın uzun ömürlü olma problemini tek başına çözmez. Rotation takvimi, application refresh davranışı ve owner bilgisi ayrıca yönetilmelidir. Mümkün olan sistemlerde static credential kullanımını azaltmak güvenlik operasyonunun temel hedeflerinden biri olmalıdır.

Dynamic Secret Nedir?

Dynamic secret uygulama ihtiyaç duyduğunda üretilen ve çoğunlukla benzersiz olan kısa ömürlü credential'dır. Vault Database Secrets Engine bu modelin güçlü örneklerinden biridir. Uygulama kimliğini doğruladıktan sonra belirli role göre yeni database kullanıcısı alabilir. Credential TTL boyunca geçerli olur ve lease sona erdiğinde revoke edilebilir. Böylece onlarca servis tek production password paylaşmak yerine kendi sınırlı ömürlü erişim bilgilerini kullanır.

Secret Rotation ile Dynamic Secret Arasındaki Fark

Rotation static credential değerini belirli aralıklarla yenisiyle değiştirmeyi ifade eder. Dynamic secret modelinde ise her workload veya belirli kullanım dönemi için yeni credential üretilebilir. Haftada bir değiştirilen ortak database parolası ile her instance için bir saatlik kullanıcı oluşturmak aynı güvenlik seviyesini sağlamaz. Rotation static secret riskini azaltır, ancak shared credential problemi devam edebilir. Dynamic model kullanım süresini, paylaşımı ve revocation kapsamını daha dar hale getirir.

TTL Nedir?

TTL, Time To Live ifadesinin kısaltmasıdır ve credential'ın ne kadar süre geçerli olacağını belirtir. Kısa TTL ele geçirilen bir secret'ın kullanılabileceği zaman penceresini doğal olarak sınırlar. Çok kısa TTL ise application'ın sık renewal veya retrieval yapmasını gerektirerek operasyon yükü oluşturabilir. Kullanım senaryosuna göre birkaç dakika, saat veya daha uzun süre belirlenebilir. Doğru TTL güvenlik risk seviyesi, application çalışma süresi ve outage toleransı birlikte değerlendirilerek seçilmelidir.

Lease Nedir?

Lease Vault tarafından üretilen bazı dynamic secret ve token değerlerinin yaşam döngüsünü takip eden mekanizmadır. Lease ID üzerinden credential'ın ne zaman üretildiği, ne kadar süre geçerli olduğu ve revoke edilip edilmediği yönetilebilir. Uygulama izin veriliyorsa lease'i yenileyebilir. Workload sona erdiğinde veya güvenlik problemi oluştuğunda lease normal expiration zamanından önce iptal edilebilir. Bu yaklaşım manuel password listeleriyle yapılan credential yönetiminden çok daha kontrollü bir model sunar.

Lease Renewal

Lease renewal mevcut lease süresinin belirlenen policy sınırları içinde uzatılmasıdır. Uzun süren workload'lar credential süresi dolmadan erişime devam etmek için renewal kullanabilir. Her lease'in yenilenebilir olması gerekmez ve maksimum TTL ile toplam yaşam süresi sınırlandırılabilir. Renewal başarısız olduğunda uygulama yeni credential alabilecek biçimde tasarlanmalıdır. Bu davranış doğru test edilmezse kısa TTL kullanımı production kesintisine dönüşebilir.

Lease Expiration

Lease expiration tanımlanan kullanım süresinin sona erdiği anı ifade eder. Süre tamamlandığında credential'ın yeni erişimler için geçersiz hale gelmesi beklenir. Bu özellik saldırganın ele geçirdiği değeri uzun süre kullanmasını engellemeye yardımcı olur. Uygulama expiration zamanını bilerek önceden renewal veya yeni credential retrieval yapabilir. Böylece kısa ömürlü erişim kullanılırken uygulama sürekliliği korunabilir.

Lease Revocation

Lease revocation credential'ın normal expiration süresini beklemeden iptal edilmesidir. Workload kaldırıldığında, çalışan erişimi sonlandığında veya güvenlik olayı yaşandığında kullanışlıdır. Merkezi revocation tek tek database hesaplarını manuel bulma ihtiyacını azaltabilir. Audit logları hangi identity'nin hangi lease ile ilişkilendirildiğini gösterdiğinde olay analizi kolaylaşır. Emergency procedure içinde toplu lease revoke veya role bazlı revocation senaryoları önceden test edilmelidir.

Short-Lived Credentials Neden Daha Güvenlidir?

Short-lived credential ele geçirildiğinde saldırganın onu kullanabileceği zaman aralığı sınırlıdır. Kalıcı olmadığı için çalışan değişikliği, unutulmuş hesap ve yıllardır rotate edilmeyen access key gibi problemler azalır. Workload identity ile birlikte kullanıldığında credential belirli application, role ve kısa süreyle ilişkilendirilebilir. Audit kayıtları da ortak kullanıcı yerine gerçek workload kimliğine daha kolay bağlanır. Modern secret management mimarilerinin uzun ömürlü static credential'lardan uzaklaşmasının en önemli nedenlerinden biri bu daraltılmış risk penceresidir.

Secret Zero Problemi Nedir?

Secret zero, uygulamanın secret manager'a ilk kez erişirken hangi güvenilir kimlik bilgisini kullanacağı problemidir. Secret manager içindeki database password'u korumak için uygulamaya başka bir uzun ömürlü password vermek sorunu yalnızca başka bir noktaya taşır. Modern mimariler bu ilk güven ilişkisini workload'un bulunduğu platformun native identity'si üzerinden kurmaya çalışır. IAM Role, Kubernetes Service Account ve OIDC federation bu yaklaşımın güçlü örnekleridir. Hedef secret manager'a erişmek için yeni bir static secret üretmek değil, zaten doğrulanabilen machine identity'yi kullanmaktır.

Secret Manager'a İlk Kimlik Doğrulaması Nasıl Yapılır?

İlk authentication mümkünse workload'un çalıştığı platformun doğal kimliği üzerinden yapılmalıdır. AWS üzerindeki application IAM Role ile, Kubernetes pod'u Service Account ile ve CI pipeline OIDC token ile kendisini doğrulayabilir. Vault uygun authentication method üzerinden bu kimlikleri policy'lerle eşleştirebilir. AWS Secrets Manager tarafında ise IAM authorization hangi workload'un hangi secret'a erişebileceğini belirler. Böylece application içine ayrı master password, static access key veya uzun ömürlü Vault token yerleştirme ihtiyacı büyük ölçüde ortadan kalkar.

Bir Secret'ı Başka Bir Secret ile Korumak Problemi

Application'ın ana secret'a ulaşabilmek için ikinci bir password saklaması güvenlik problemini çözmez. İkinci değerin nerede tutulacağı sorusu yeniden ortaya çıkar ve bu zincir teorik olarak devam eder. Bu nedenle güven kökü credential değil, platform tarafından doğrulanabilen identity olmalıdır. Cloud metadata, Kubernetes identity, OIDC token veya HSM gibi mekanizmalar bu döngüyü kırabilir. Secret zero tasarımının amacı ilk erişimi mümkün olduğunca otomatik, kısa ömürlü ve identity tabanlı hale getirmektir.

Workload Identity

Workload identity bir application veya servis instance'ının kendi kimliğiyle authentication yapmasını sağlar. Böylece insan tarafından oluşturulan access key veya password application config içine kopyalanmaz. Platform identity'yi doğruladıktan sonra belirli resource'lara sınırlı yetki verir. Kubernetes, AWS ve OIDC tabanlı sistemlerde bu yaklaşım giderek daha yaygın hale gelmektedir. Workload identity secret manager'ı tamamen gereksiz hale getirmez, ancak birçok static cloud credential ihtiyacını ortadan kaldırdığı için secret inventory'sini ciddi biçimde küçültebilir.

IAM Role

IAM Role AWS workload'larının temporary credential kullanarak AWS servislerine erişmesini sağlar. EC2, Lambda, ECS ve EKS gibi servislerde application içine kalıcı access key koymaya gerek kalmaz. Secrets Manager erişimi ilgili role policy'si üzerinden belirli secret ARN'leriyle sınırlandırılabilir. Bu nedenle AWS workload'un AWS API'ye erişmek için kullandığı access key'i ayrıca Secrets Manager'a koymak çoğu senaryoda doğru tasarım değildir. Role tabanlı temporary credential hem secret zero hem de rotation yükünü önemli ölçüde azaltır.

OIDC Federation

OIDC federation bir sistemin oluşturduğu kısa ömürlü identity token'ının başka platform tarafından güvenilir biçimde kabul edilmesini sağlar. CI/CD sistemlerinin AWS'ye uzun ömürlü access key olmadan erişmesi yaygın kullanım örneğidir. Vault JWT veya OIDC authentication ile benzer biçimde pipeline identity'sini doğrulayabilir. Trust relationship repository, branch, audience veya subject claim'leriyle daraltılmalıdır. Geniş wildcard tanımları federation modelinin sağladığı güvenlik avantajını zayıflatabileceği için policy tasarımı dikkatle yapılmalıdır.

Kubernetes Service Account Identity

Kubernetes Service Account pod veya workload'un cluster içindeki identity'sini temsil eder. Vault Kubernetes Auth bu identity ile ilişkili token'ı doğrulayarak uygun policy verebilir. AWS EKS üzerinde IRSA veya EKS Pod Identity gibi mekanizmalar Kubernetes workload'unu IAM Role ile ilişkilendirebilir. Böylece pod içine static Vault token veya AWS access key yazılmaz. Namespace ve Service Account kapsamlarının dar tutulması aynı cluster içindeki başka workload'ların yanlış yetkiye ulaşmasını önlemek açısından önemlidir.

AppRole

AppRole Vault'un özellikle machine ve automation authentication için kullanılan yöntemlerinden biridir. RoleID ve SecretID bileşenleri üzerinden application kontrollü biçimde Vault token alabilir. Bununla birlikte SecretID'nin nasıl dağıtıldığı iyi tasarlanmazsa yeni bir secret zero problemi oluşabilir. Platformun Kubernetes, AWS veya OIDC gibi native identity seçeneği varsa öncelikle o model değerlendirilmelidir. AppRole native workload identity bulunmayan legacy server veya özel automation senaryolarında yine de yararlı ve uygulanabilir bir seçenektir.

Secretless Architecture

Secretless architecture application katmanında uzun ömürlü credential tutma ihtiyacını mümkün olduğunca azaltmayı hedefler. Application ayrı password veya access key taşımak yerine identity'si üzerinden yetki alır. Tam anlamıyla hiçbir kriptografik secret'ın bulunmadığı sistem pratikte her zaman mümkün değildir çünkü altyapının bazı katmanlarında key materyali yaşamaya devam eder. Hedef özellikle developer ve application seviyesindeki static credential kopyalarını azaltmaktır. Workload identity, mTLS, federation ve broker modelleri bu yaklaşıma geçişte önemli araçlardır.

Secret Saklamak Yerine Identity Kullanmak Ne Zaman Daha Doğrudur?

Hedef servis workload identity veya federation destekliyorsa önce bu seçenek değerlendirilmelidir. AWS workload'un AWS API'sine erişmesi için static access key saklamak yerine IAM Role kullanmak bunun açık örneğidir. Kubernetes application Vault'a Service Account identity ile bağlanabilir ve ayrı login password kullanmayabilir. Harici servis yalnızca API key destekliyorsa secret manager hâlâ gereklidir. Basit kural, identity üzerinden kısa ömürlü erişim üretilebiliyorsa yeni bir kalıcı secret yaratmamaktır.

HashiCorp Vault Nedir?

HashiCorp Vault merkezi secret management, identity tabanlı access control, dynamic credential, PKI ve encryption hizmetleri sunan bir platformdur. Vault'u yalnızca key value biçiminde parola saklayan bir kasa olarak görmek ürünün en güçlü kullanım alanlarının büyük bölümünü kaçırmak anlamına gelir. Multi-cloud veya on-premise yapılarda farklı workload'ların ortak authentication ve policy modeli altında yönetilmesi için güçlü bir control plane sağlayabilir. Bunun karşılığında self-hosted kullanımda cluster, storage, backup, upgrade, monitoring, seal ve disaster recovery gibi ek operasyon sorumlulukları oluşur. Bu nedenle Vault seçimini yalnızca özellik sayısına bakarak değil, kurumun gerçekten ihtiyaç duyduğu yetenekler ve platform ekibinin işletme kapasitesi üzerinden yapmak gerekir.

Vault'ın Temel Mimarisi

Vault mimarisinde client önce desteklenen authentication method üzerinden kimliğini doğrular. Başarılı authentication sonucunda policy'lerle ilişkili token veya identity context elde eder. Yapılan request belirli path üzerinde tanımlanan capability kurallarına göre authorize edilir ve ilgili Secrets Engine tarafından işlenir. Veriler storage backend üzerinde Vault'un security barrier modeli içinde korunur. Audit devices yapılan işlemlerin kayıtlarını farklı hedeflere aktararak güvenlik ekibinin hangi identity'nin hangi secret'a ne zaman eriştiğini izlemesini sağlar.

Vault Server

Vault Server client API request'lerini kabul eden ana bileşendir. Authentication, authorization, Secrets Engine yönlendirmesi ve storage erişimi bu katmanda kontrol edilir. Client doğrudan storage backend ile konuşmaz ve bütün hassas operasyon Vault Server üzerinden geçer. Production ortamında server endpoint TLS ile korunmalı, network erişimi mümkün olduğunca dar tutulmalı ve health monitoring aktif olmalıdır. HA yapısında birden fazla node kullanılması hem maintenance hem de node failure senaryolarında servis sürekliliğini destekler.

Storage Backend

Storage backend Vault'un kalıcı verilerini tuttuğu katmandır. Integrated Storage yani Raft güncel self-hosted kurulumlarda yaygın seçeneklerden biridir. Vault storage içindeki veriyi kendi encryption barrier modeliyle korur, ancak storage erişiminin yine de güçlü biçimde sınırlandırılması gerekir. Snapshot ve backup dosyaları da hassas veri taşıdığı için aynı güvenlik seviyesinde ele alınmalıdır. HA, disaster recovery ve restore tasarımının başarısı storage modelinin doğru anlaşılmasına doğrudan bağlıdır.

Authentication Methods

Authentication Methods kullanıcı veya workload'un kimliğini Vault'a kanıtlayan mekanizmalardır. Token, AppRole, Kubernetes, AWS, LDAP, OIDC ve JWT gibi farklı yöntemler farklı çalışma ortamlarına uyum sağlar. İnsan kullanıcılarla machine workload'ların aynı authentication yöntemini kullanması gerekmez. İnsan tarafında SSO ve OIDC uygunken Kubernetes workload'u için Kubernetes Auth daha doğal olabilir. Doğru yöntem secret zero problemini azaltmalı, mevcut enterprise identity sistemine bağlanmalı ve static credential üretme ihtiyacını minimuma indirmelidir.

Policies

Policies Vault içindeki path'lere hangi identity'nin hangi işlemleri yapabileceğini belirler. Bir application yalnızca kendi secret veya dynamic credential path'ine erişebilmelidir. Runtime workload'a secret delete veya policy update yetkisi vermek çoğu durumda gereksizdir. Application, team ve environment sınırları policy yapısında açık biçimde gösterilmelidir. Çok geniş wildcard kullanımı başlangıçta kolaylık sağlasa da zamanla least privilege yaklaşımını bozduğu için düzenli access review uygulanmalıdır.

Secrets Engines

Secrets Engines Vault'un static secret saklayan, dynamic credential üreten veya kriptografik işlem yapan modüler bileşenleridir. KV Engine static değerleri saklarken Database Engine kısa ömürlü database credential üretebilir. PKI Engine certificate issuance yapabilir ve Transit Engine application key'i görmeden encryption hizmeti sağlayabilir. Her engine belirli path altında etkinleştirilebilir ve kendi access policy'sine sahip olabilir. Bu yapı Vault'un klasik password vault yaklaşımından daha kapsamlı bir security platformu olmasını sağlar.

Audit Devices

Audit Devices Vault request ve response metadata'sını belirlenen hedeflere kaydeder. File, syslog ve socket gibi seçenekler farklı logging mimarilerine uyum sağlar. Hassas alanlar loglarda doğrudan görünmeyecek biçimde koruyucu işlemlerden geçirilir. Buna rağmen audit loglarının kendisi yüksek değerli güvenlik verisi olduğu için erişimi sınırlanmalıdır. Kritik ortamlarda birden fazla audit hedefi kullanmak tek log destination arızasında görünürlük kaybı yaşama riskini azaltabilir.

Vault Community ve Enterprise Yaklaşımı

Vault farklı dağıtım ve lisans modelleriyle kullanılabilir ve her kurumun ihtiyaç duyduğu özellik seti aynı değildir. Community düzeyindeki yetenekler birçok secret management senaryosu için yeterli olabilir. Daha büyük organizasyonlarda namespace, gelişmiş governance veya kurumsal operasyon gereksinimleri farklı ürün seçeneklerini gündeme getirebilir. Lisans maliyeti yalnızca satın alma konusu değil uzun vadeli mimari bağımlılık konusu olarak da değerlendirilmelidir. Seçim yapılırken bugün gereken özelliklerle üç yıl sonra beklenen scale ve governance ihtiyacı birlikte ele alınmalıdır.

Self-Hosted Vault

Self-hosted Vault network, infrastructure ve data control üzerinde yüksek esneklik sağlar. On-premise veya özel network gereksinimi bulunan kuruluşlar cluster'ı kendi ortamlarında işletebilir. Bunun karşılığında node lifecycle, storage, HA, snapshot, certificate, monitoring ve upgrade işlemleri kurumun sorumluluğuna geçer. Küçük ekiplerin yalnızca birkaç AWS secret'ı yönetmek için bu operasyon yükünü üstlenmesi çoğu zaman gerekli değildir. Self-hosted model daha fazla kontrol isteyen ve bunu sürdürebilecek platform ekibine sahip kuruluşlarda anlamlı hale gelir.

HCP Vault

HCP Vault Vault yeteneklerini yönetilen hizmet yaklaşımıyla kullanmak isteyen ekipler için bir seçenektir. Managed model altyapı operasyonunun bir bölümünü azaltabilir ve ekiplerin application authentication, policy ve secret lifecycle konularına daha fazla odaklanmasını sağlayabilir. Buna rağmen yanlış policy, gereksiz static credential veya zayıf application handling gibi problemler managed hizmet kullanınca kendiliğinden çözülmez. Network, identity ve data governance tasarımı hâlâ kurumun sorumluluğundadır. Self-hosted ile managed model arasında seçim yaparken operasyon kapasitesi, veri konumu, maliyet ve entegrasyon gereksinimleri birlikte değerlendirilmelidir.

HashiCorp Vault Hangi Problemleri Çözer?

Vault static secret storage, dynamic credential, certificate lifecycle, centralized policy, encryption service ve audit gibi farklı ihtiyaçları aynı platformda birleştirebilir. Özellikle on-premise, Kubernetes ve birden fazla cloud provider kullanan kuruluşlarda ortak control plane sağlaması önemli avantajdır. Dynamic Database Secrets ile shared password kullanımını azaltabilir, PKI ile kısa ömürlü certificate üretebilir ve Transit Engine ile application'a key vermeden encryption işlemi yaptırabilir. Bununla birlikte Vault her sistem için zorunlu değildir. Platformun getirdiği işletim maliyeti gerçek güvenlik ve standardizasyon ihtiyacıyla karşılanıyorsa tercih edilmelidir.

HashiCorp Vault Secrets Engines

Vault Secrets Engines seçimi sistemin yalnızca secret saklayan bir yapı mı yoksa gerçekten credential lifecycle yöneten bir platform mu olacağını belirler. Her şeyi KV Engine içine koymak kolaydır, ancak database password gibi değerlerde dynamic credential fırsatını kaçırabilir. Benzer biçimde application encryption key'ini doğrudan dağıtmak yerine Transit Engine kullanmak bazı projelerde daha güvenli olur. Hangi engine'in kullanılacağı hedef sistemin özellikleri ve security model'e göre belirlenmelidir. Amaç sadece mevcut secret'ı başka bir kasaya taşımak değil, mümkünse erişim modelinin kendisini iyileştirmektir.

KV Secrets Engine

KV Secrets Engine key value biçimindeki static secret'ları saklamak için kullanılır. Harici API key, desteklenmeyen servis credential'ı veya sabit configuration secret'ı burada tutulabilir. Erişim path ve policy kuralları üzerinden sınırlandırılır. KV v2 versioning gibi ek özelliklerle geçmiş sürümler kontrollü biçimde yönetilebilir. Bununla birlikte KV'ye taşınan database password hâlâ static password'dur ve dynamic secret avantajlarından yararlanmak için ilgili engine'e geçmek gerekir.

KV v1

KV v1 daha basit bir key value storage modelidir. Secret güncellendiğinde önceki sürümlere yönelik yerleşik versioning davranışı bulunmaz. Küçük ve basit kullanım senaryolarında yeterli olabilir. Production sistemlerinde yanlış update durumunda geri dönüş ihtiyacı varsa bu özellik eksikliği dikkate alınmalıdır. Yeni proje tasarlanırken gerçekten version history gerekip gerekmediğine bakılarak KV v1 ve KV v2 arasında seçim yapılmalıdır.

KV v2

KV v2 secret versioning ve metadata özellikleri sunar. Aynı secret path'in farklı sürümleri tutulabilir ve kontrollü delete davranışları uygulanabilir. Hatalı update sonrasında önceki version'a dönmek operasyonel avantaj sağlayabilir. Ancak eski version'ın var olması hedef sistemde credential'ın hâlâ geçerli olduğu anlamına gelmemeli ve revocation ayrıca yönetilmelidir. Version retention politikası hassas değerlerin gereksiz süre saklanmasını önleyecek biçimde belirlenmelidir.

Secret Versioning

Secret Versioning aynı logical secret'ın zaman içindeki farklı değerlerini takip etmeyi sağlar. Deployment sırasında yanlış değer yazıldığında önceki sürüm operasyonel kurtarma sağlayabilir. Versioning ile rotation birbirine karıştırılmamalıdır çünkü version oluşturmak hedef API veya database password'unu otomatik olarak geçersiz kılmaz. Eski credential hedef sistemde aktifse security risk devam eder. Bu nedenle version history, revocation, rotation ve retention policy birlikte tasarlanmalıdır.

Database Secrets Engine

Database Secrets Engine Vault'un en güçlü dynamic secret özelliklerinden biridir. Vault hedef database'e kontrollü yönetim bağlantısı kurar ve önceden tanımlanmış role göre application için kısa ömürlü kullanıcı oluşturabilir. Her workload ayrı credential aldığı için shared production password ihtiyacı önemli ölçüde azalır. Lease sona erdiğinde kullanıcı kaldırılabilir veya yetkisi revoke edilebilir. Bu model audit kalitesini artırırken application'ın connection pool, renewal ve credential refresh davranışının doğru tasarlanmasını da zorunlu hale getirir.

PostgreSQL

PostgreSQL entegrasyonunda Vault role tanımına göre kullanıcı oluşturma ve kaldırma işlemleri çalıştırabilir. Application kendi identity'siyle Vault'a bağlanıp yalnızca belirlenen database role için credential talep eder. Oluşturulan kullanıcı sınırlı yetkiye ve belirli TTL değerine sahip olabilir. Connection pool uzun süre açık kalıyorsa credential expiration sonrasında yeni bağlantıların nasıl kurulacağı test edilmelidir. Dynamic user modeli ortak production hesabına göre hem audit hem de revocation açısından daha güçlü bir yapı sunar.

MySQL

MySQL ortamında da application bazlı kısa ömürlü kullanıcı üretimi uygulanabilir. Vault role gerekli CREATE USER ve privilege işlemlerini kontrollü biçimde tanımlar. Workload yalnızca ihtiyacı olan database ve table yetkilerine sahip olmalıdır. Lease bittiğinde kullanıcının hedef sistemde gerçekten kaldırıldığı monitoring ile doğrulanabilir. Uzun yaşayan application instance'larında renewal ve reconnect davranışı production öncesinde yük testiyle incelenmelidir.

SQL Server

SQL Server entegrasyonu paylaşılan servis hesaplarını azaltmak isteyen kurumlarda değer sağlayabilir. Application bazlı credential oluşturulduğunda audit kayıtları gerçek workload'a daha kolay bağlanır. Role tanımı yalnızca gerekli database işlemlerine izin vermelidir. Connection pooling ve transaction davranışı credential rotation sırasında kesinti yaşanmaması için test edilmelidir. Mevcut enterprise identity platformu password yerine daha güçlü federated authentication sağlıyorsa dynamic password modeliyle birlikte bu seçenek de değerlendirilmelidir.

MongoDB

MongoDB için dynamic credential kullanımı application başına ayrı ve kısa ömürlü erişim sağlayabilir. Shared admin user kullanmak yerine workload'un ihtiyacı olan collection veya database kapsamı tanımlanabilir. TTL sona erdiğinde ilgili kullanıcının kaldırılması stale credential riskini azaltır. Cluster topolojisi ve replication davranışı kullanıcı yönetimi sırasında test edilmelidir. Audit verileri Vault identity ile MongoDB erişim kayıtları arasında ilişkilendirildiğinde incident investigation daha hızlı yürütülebilir.

AWS Secrets Engine

Vault AWS Secrets Engine AWS erişimleri için geçici credential üretiminde kullanılabilir. Multi-cloud bir platformda merkezi Vault policy'si üzerinden AWS erişimi sağlamak governance açısından avantaj sunabilir. Bununla birlikte AWS workload doğrudan IAM Role kullanabiliyorsa araya ekstra credential broker eklemenin gerçekten gerekli olup olmadığı sorgulanmalıdır. Native workload identity çoğu AWS içi senaryoda daha sade ve düşük operasyonlu çözüm sağlar. Vault AWS Secrets Engine özellikle farklı platformlardan gelen workload'ların ortak merkezi policy üzerinden AWS erişimi alması gereken yapılarda anlamlıdır.

Azure Secrets Engine

Azure Secrets Engine Vault üzerinden Azure ortamına yönelik geçici credential senaryoları oluşturmak için kullanılabilir. Multi-cloud kuruluşlarda farklı provider kimliklerini tek security control plane altında yönetme isteği bu yaklaşımı değerli hale getirebilir. Buna rağmen Azure tarafındaki native workload identity özellikleri önce değerlendirilmelidir. Gereksiz static credential üretmek Vault kullanılsa bile iyi güvenlik modeli değildir. Merkezi governance gerçek ihtiyaçsa Vault devreye alınmalı, yalnızca araç standardizasyonu için ek bağımlılık oluşturulmamalıdır.

GCP Secrets Engine

GCP Secrets Engine Google Cloud kaynakları için credential lifecycle yönetiminde kullanılabilir. Birden fazla cloud provider kullanan platform ekipleri ortak policy, authentication ve audit modeli elde edebilir. Ancak Google Cloud workload identity seçenekleri destekleniyorsa long lived service account key üretmek yerine bunları kullanmak çoğu durumda daha iyi olur. Vault merkezi kontrol katmanı sağlarken native identity kabiliyetlerini tamamen devre dışı bırakmak zorunda değildir. En iyi mimari credential üretme zorunluluğunu azaltan ve ek operational hop'ları gerekçelendiren modeldir.

PKI Secrets Engine

PKI Secrets Engine X.509 certificate üretimi, imzalama ve yaşam döngüsünü otomatikleştirmek için kullanılır. Manuel certificate request ve yıllarca yaşayan private key yerine workload kimliğini doğrulayıp kısa ömürlü certificate üretmek mümkündür. Service to service TLS veya internal API kimlik doğrulamasında güçlü bir temel sağlayabilir. Root CA ve intermediate CA key'lerinin korunması ayrı ve yüksek öncelikli güvenlik konusudur. Certificate TTL, renewal, revocation ve CA hierarchy production tasarımının başlangıcında belirlenmelidir.

SSH Secrets Engine

SSH Secrets Engine kalıcı ortak private key dağıtımı yerine kontrollü ve süreli SSH erişimi kurmaya yardımcı olur. Certificate tabanlı modelde kullanıcı veya automation identity belirli sunucu grubu için kısa ömürlü SSH certificate alabilir. Böylece çalışan ayrıldığında onlarca sunucudaki authorized_keys dosyasını manuel güncelleme ihtiyacı azalır. Yetki süresi ve target scope role üzerinden kontrol edilebilir. Audit kayıtları hangi identity'nin hangi erişimi talep ettiğini görünür hale getirerek shared key kullanımına göre daha iyi izlenebilirlik sağlar.

Transit Secrets Engine

Transit Secrets Engine application'ın encryption key materyalini doğrudan görmeden encrypt ve decrypt işlemleri yapmasını sağlar. Application plaintext veriyi Vault'a gönderir ve ciphertext alır, ancak kriptografik key merkezi platform sınırları içinde kalır. Key version ve rotation işlemleri application kodunu değiştirmeden yönetilebilir. Transit Engine veri deposu değildir ve business data'nın kalıcı storage sorumluluğu başka sistemdedir. Özellikle farklı uygulamaların ortak key governance modeline ihtiyacı olduğu durumlarda encryption as a service yaklaşımı değerli olabilir.

Vault Dynamic Secrets Nasıl Çalışır?

Vault Dynamic Secrets modelinde application önceden paylaşılmış production password'u okumak yerine ihtiyaç anında yeni credential ister. Vault önce workload identity'sini doğrular, ardından policy üzerinden hangi role erişebildiğini kontrol eder. Secrets Engine hedef sistemde benzersiz credential üretir ve belirli TTL veya lease ile application'a verir. Süre tamamlandığında credential revoke edilebilir veya izin verilen durumda renewal yapılabilir. Bu model credential sharing, stale account ve uzun süreli yetki risklerini azaltırken application'ın kısa ömürlü credential kullanımına hazır olmasını gerektirir.

Role Tanımlama

Role dynamic credential'ın hangi yetkilerle ve hangi yaşam süresiyle üretileceğini tanımlar. Database Engine örneğinde role oluşturulacak kullanıcının SQL yetkilerini, default TTL değerini ve maksimum yaşam süresini belirleyebilir. Her uygulamaya tek genel role vermek yerine işlev ve environment bazlı farklı role'lar tanımlamak daha güvenlidir. Role isimleri application, team ve environment bilgisini açıkça ifade etmelidir. Bu standardizasyon policy yönetimi, audit analizi ve incident response sürecini önemli ölçüde kolaylaştırır.

On-Demand Credential Generation

On-demand generation credential'ın gerçekten ihtiyaç oluştuğunda üretilmesini sağlar. Aylar öncesinden oluşturulmuş ve hiç kullanılmayan hesapların ortamda beklemesi engellenebilir. Application başladığında veya yeni bağlantı gerektiğinde kendi identity'si üzerinden credential talep eder. Kullanılmayan workload için secret oluşmadığı için orphan credential riski de azalır. Merkezi platformun availability'si bu modelde daha önemli hale geldiği için cache, retry ve HA stratejileri application architecture ile birlikte tasarlanmalıdır.

Unique Credential

Unique credential her workload veya kullanım dönemi için farklı erişim bilgisi üretilmesini ifade eder. Ortak database user yerine application instance'a özel kullanıcı verilmesi audit kayıtlarını çok daha anlamlı hale getirir. Bir credential compromise olduğunda yalnızca ilgili identity'nin erişimi revoke edilebilir. Diğer application'ların aynı anda password değiştirmesi gerekmez. Blast radius'un daralması dynamic secret kullanımının static shared credential modeline göre en önemli güvenlik avantajlarından biridir.

TTL ve Lease

Dynamic secret üretildiğinde credential belirli TTL ve çoğu zaman lease bilgisiyle ilişkilendirilir. TTL credential'ın maksimum geçerlilik süresini ifade eder. Lease ise Vault'un bu credential'ın yaşam döngüsünü takip etmesini sağlar. Workload gerekli izinlere sahipse renewal talep edebilir veya olay halinde lease erken revoke edilebilir. Bu yapı yıllarca değişmeden kalan static password modeline göre çok daha kontrollü ve otomasyona uygun bir yaşam döngüsü oluşturur.

Credential Renewal

Credential Renewal uzun süren workload'ların erişimi güvenli biçimde devam ettirmesini sağlar. Application expiration yaklaşmadan önce mevcut lease'i yenileyebilir. Maksimum TTL sınırı renewal'ın sonsuza kadar devam etmesini engeller. Renewal başarısız olduğunda uygulama yeni credential talep etmeyi veya bağlantıyı yeniden kurmayı bilmelidir. Bu fallback davranışı doğru tasarlanmazsa güvenliği artırmak için kısaltılan TTL production availability problemlerine dönüşebilir.

Automatic Revocation

Automatic Revocation lease süresi dolduğunda credential'ın hedef sistemde geçersiz hale getirilmesini amaçlar. Bu davranış unutulan database kullanıcılarının yıllarca açık kalmasını önlemeye yardımcı olur. Target servis temporary olarak ulaşılamazsa revoke işleminin nasıl retry edildiği ve cleanup'ın gerçekten tamamlanıp tamamlanmadığı izlenmelidir. Security dashboard yalnızca credential creation değil failed revocation event'lerini de göstermelidir. Otomasyonun güvenilirliği production öncesi kontrollü failure testleriyle doğrulanmalıdır.

Kullanıcı Bazlı Audit

Dynamic credential belirli workload identity ile ilişkilendirildiğinde audit kayıtları shared kullanıcı modeline göre çok daha faydalı olur. Database tarafında farklı username görülebilir ve bu değer Vault lease bilgisiyle gerçek application'a bağlanabilir. Bir olay yaşandığında “payment service hangi credential'ı aldı?” sorusunun cevabı merkezi loglardan bulunabilir. Vault audit logları ile database audit kayıtlarının zaman senkronizasyonu bu ilişkilendirmeyi kolaylaştırır. SIEM tarafında iki veri kaynağının birlikte analiz edilmesi credential abuse tespitini güçlendirir.

Database Dynamic Secret Örneği

Örneğin Kubernetes üzerinde çalışan payment API, Vault'a kendi Service Account identity'siyle authenticate olabilir. Vault policy bu workload'un yalnızca payment production database role'una erişmesine izin verir. Database Secrets Engine PostgreSQL üzerinde sınırlı yetkili, benzersiz ve bir saat geçerli kullanıcı oluşturur. Application TTL yaklaşınca yeni credential alır veya lease renewal yapar ve eski kullanıcı süresi sonunda revoke edilir. Böylece source code, CI pipeline veya static configuration içinde ortak production database password bulundurmaya gerek kalmaz.

Vault Authentication Methods

Vault Authentication Methods secret zero probleminin nasıl çözüleceğini belirleyen en önemli tasarım alanlarından biridir. İnsan kullanıcı, Kubernetes workload, cloud VM ve CI pipeline aynı authentication yöntemini kullanmak zorunda değildir. Doğal identity ne kadar iyi kullanılırsa static bootstrap credential ihtiyacı o kadar azalır. Kubernetes için Kubernetes Auth, AWS workload için AWS Auth, kullanıcılar için OIDC ve belirli CI senaryoları için JWT güçlü seçeneklerdir. Bir authentication yöntemi yalnızca login kolaylığına göre değil, credential dağıtımı, revocation, audit ve operasyon modeli açısından değerlendirilmelidir.

Token Authentication

Vault token client'ın sonraki Vault API request'lerinde identity ve authorization bilgisini temsil eder. Token doğrudan oluşturulabilir veya başka authentication method sonucunda verilebilir. TTL ve policy kapsamı minimum ihtiyaçla sınırlandırılmalıdır. Root token günlük application veya yönetim işlemleri için kullanılmamalıdır. Application mümkün olduğunca kısa ömürlü token kullanmalı ve token renewal veya expiration davranışını güvenli biçimde yönetmelidir.

AppRole

AppRole doğrudan Kubernetes veya cloud identity kullanamayan machine workload'lar için yararlı authentication yöntemidir. RoleID ile SecretID bileşenleri uygulamanın Vault token almasını sağlar. SecretID dağıtımı güvenli tasarlanmazsa başka bir static secret problemi oluşur. Uzun ömürlü ortak SecretID kullanımından kaçınılmalıdır. Native workload identity bulunan ortamlarda AppRole yerine ilgili platform authentication yöntemi tercih edildiğinde secret zero riski daha düşük olur.

Kubernetes Auth

Kubernetes Auth pod'un Service Account identity'si üzerinden Vault'a authentication yapmasını sağlar. Vault role belirli namespace ve Service Account değerlerini policy ile eşleştirir. Böylece pod içine Vault login password veya uzun ömürlü token eklenmez. Audience, namespace ve role binding tanımları dar tutulmalıdır. Bu yaklaşım Kubernetes ve CI/CD pipeline içinde Vault secret yönetimi nasıl yapılır sorusunun Kubernetes tarafındaki en güçlü başlangıç modellerinden biridir.

AWS Auth

AWS Auth AWS identity bilgisini kullanarak Vault authentication yapılmasına olanak verir. EC2 veya IAM tabanlı workload'lar mevcut cloud identity'sini kullanabilir ve ayrı Vault password taşımak zorunda kalmaz. Vault role hangi AWS account veya IAM identity'nin hangi policy setini alacağını belirler. Geniş role matching kuralları yanlış workload'ların erişim kazanmasına neden olabilir. Account, role ve diğer doğrulanabilir identity özellikleriyle authorization mümkün olduğunca dar kapsamlı tanımlanmalıdır.

LDAP

LDAP kurumsal dizin sistemindeki kullanıcıların Vault'a merkezi identity ile giriş yapmasını sağlayabilir. Ayrı Vault kullanıcı parolası oluşturmak yerine mevcut enterprise account kullanılır. LDAP group bilgileri Vault policy'leriyle eşleştirilebilir. Modern MFA ve SSO gereksinimlerinde OIDC tabanlı identity provider daha uygun olabilir. Hangi yöntem seçilirse seçilsin çalışan ayrıldığında Vault erişiminin merkezi identity lifecycle üzerinden hızlı biçimde kapanması hedeflenmelidir.

OIDC

OIDC Vault'u enterprise identity provider ile federated login modeline bağlayabilir. Kullanıcılar mevcut SSO hesabıyla giriş yapar ve group veya claim bilgileri üzerinden uygun policy'leri alır. Redirect URI, issuer, audience ve claim mapping doğru yapılandırılmalıdır. Merkezi identity provider MFA uyguluyorsa Vault insan erişimi de aynı güvenlik seviyesinden faydalanabilir. Bu yaklaşım ayrı local kullanıcı hesaplarını ve uzun ömürlü Vault password yönetimini azaltır.

JWT

JWT Auth doğrulanabilir token claim'lerine göre Vault erişimi vermek için kullanılabilir. CI/CD platformları bunun yaygın kullanım alanlarından biridir. Pipeline kısa ömürlü JWT ile Vault'a authenticate olur ve yalnızca ilgili repository veya environment secret'ına erişebilir. Subject, audience, branch ve project bilgisi gibi claim'ler policy binding için kullanılabilir. Claim kontrolü yapılmadan verilen geniş erişim, passwordless model kullanılmasına rağmen ciddi authorization riski oluşturabilir.

Authentication Method Nasıl Seçilir?

En iyi authentication method workload'un zaten sahip olduğu güvenilir identity'yi kullanan yöntemdir. Kubernetes pod için Kubernetes Auth, AWS instance için AWS tabanlı model ve insan kullanıcı için OIDC çoğu durumda doğal seçimdir. Native identity bulunmayan legacy sistemlerde AppRole değerlendirilebilir. Static Vault token'ı configuration file içine yazmak hızlı görünse de uzun vadede rotation ve secret zero problemi yaratır. Authentication seçimi yapılırken identity'nin nasıl oluşturulduğu, kim tarafından revoke edildiği ve audit logunda nasıl göründüğü açık biçimde belgelenmelidir.

HashiCorp Vault Policy Tasarımı

Vault Policy Tasarımı hangi identity'nin hangi path üzerinde hangi işlemleri yapabileceğini belirlediği için güvenli Vault kullanımının temelidir. Veriyi şifreli saklamak tek başına yeterli değildir çünkü over permissioned workload merkezi kasadaki başka uygulamaların secret'larına da erişebilir. Application, environment ve görev bazlı sınırlar policy modelinde açık biçimde gösterilmelidir. Runtime workload çoğu zaman yalnızca belirli read veya dynamic credential generation yetkisine ihtiyaç duyar. Policy değişikliklerini code review ve otomatik test sürecine taşımak zaman içinde oluşabilecek geniş yetkileri azaltır.

Path-Based Access Control

Vault kaynakları path mantığıyla organize edilir ve policy bu path'lere göre yetki tanımlar. Payment application yalnızca kendi production path'ini okuyabilirken başka takımın secret alanına erişmemelidir. İsimlendirme standardı doğru kurulursa authorization yönetimi büyük ölçüde kolaylaşır. Team, application ve environment bilgisi path hiyerarşisinde anlamlı biçimde kullanılabilir. Geniş wildcard yerine mümkün olduğunca dar prefix veya exact path izinleri tercih edilmelidir.

Capability'ler

Capability'ler belirli Vault path üzerinde hangi API işlemlerinin yapılabileceğini tanımlar. Create, read, update, delete ve list gibi yetkiler birbirinden ayrılabilir. Runtime application çoğu zaman secret değerini okumakla yetinmeli ve yönetim işlemleri ayrı identity tarafından yapılmalıdır. Böylece application compromise olduğunda saldırgan secret tree içinde değişiklik yapamaz veya yeni kaynak oluşturamaz. Capability seçimi least privilege prensibinin uygulanabilir hale gelmesini sağlayan temel policy aracıdır.

Create

Create capability belirli path üzerinde yeni resource oluşturma yetkisi verir. Runtime application'ın bu yetkiye çoğu durumda ihtiyacı yoktur. Secret provisioning ve platform management işlemleri ayrı automation identity üzerinden çalıştırılabilir. Böylece application ele geçirildiğinde saldırgan kendi secret veya configuration nesnelerini üretme imkânına sahip olmaz. Create yetkisinin verildiği servis hesapları audit ve access review açısından daha yüksek riskli kabul edilmelidir.

Read

Read capability belirli path'teki veriyi okumaya izin verir. Application workload'larında en sık gereken yetkilerden biridir. Bütün secret tree için read vermek yerine yalnızca application'ın kullandığı path açıkça belirtilmelidir. Development workload production secret'ını okuyamamalıdır. Read olayları audit loglarında identity ve target path bilgisiyle izlenerek beklenmeyen erişim pattern'leri tespit edilebilir.

Update

Update capability mevcut resource üzerinde değişiklik yapılmasına izin verir. Secret rotation automation veya platform yönetim aracı bu yetkiye ihtiyaç duyabilir. Normal runtime application'ın kendi production secret'ını değiştirmesi çoğu sistemde gerekli değildir. Read ve update yetkilerinin farklı identity'lere verilmesi separation of duties açısından faydalıdır. Update işlemleri yüksek değerli audit event olarak SIEM'e aktarılabilir.

Delete

Delete capability secret veya resource silme yetkisi sağlar. Yanlış kullanım production kesintisine veya kalıcı veri kaybına yol açabileceği için çok dar kapsamlı verilmelidir. Application runtime role çoğu zaman delete yetkisine ihtiyaç duymaz. Silme işlemleri kontrollü management automation veya privileged platform role üzerinden yürütülmelidir. Kritik path'lerde change review ve break glass süreçleri ek koruma sağlayabilir.

List

List capability path altındaki resource isimlerini görmeye izin verir. Secret değerleri doğrudan gösterilmese bile naming convention hassas application veya environment bilgisini açığa çıkarabilir. Application exact path biliyorsa list yetkisine çoğu zaman ihtiyaç yoktur. Yönetim ve inventory araçlarında ise kontrollü biçimde kullanılabilir. List permission da diğer capability'ler gibi least privilege kapsamında düzenli olarak gözden geçirilmelidir.

Least Privilege

Least Privilege her identity'ye yalnızca görevi için gereken minimum yetkinin verilmesini hedefler. Application sadece kendi database credential'ını okuyorsa PKI veya başka takımın KV path'ine erişmemelidir. Management ve runtime yetkilerinin ayrılması blast radius alanını küçültür. Policy'ler application işlevi değiştiğinde yeniden değerlendirilmelidir. Kullanılmayan izinlerin zamanla birikmesini engellemek için düzenli access review süreci kurulmalıdır.

Policy Sprawl Nasıl Önlenir?

Her application için rastgele isimlendirilmiş onlarca farklı policy oluşturmak büyüyen kurumlarda yönetimi zorlaştırır. Tekrarlanabilir application, team ve environment şablonları oluşturmak policy sayısını kontrol altında tutar. Policy as code yaklaşımı değişiklikleri version control ve review sürecine taşır. Otomatik testler wildcard veya riskli capability kullanımını deployment öncesinde tespit edebilir. Kullanılmayan policy ve role'ların düzenli temizliği de uzun vadede governance kalitesini korur.

Team ve Application Bazlı Policy

Team ve application bazlı policy sorumluluk sınırlarını açık hale getirir. Bir takım kendi servislerinin secret'larına erişirken başka takımın alanına erişmemelidir. Ortak servisler için ayrı shared path tanımlanabilir ve daha sıkı review uygulanabilir. Platform management yetkileri application runtime erişiminden ayrı tutulmalıdır. Bu model organizasyon büyüdükçe kimlik ve secret ownership ilişkisinin anlaşılır kalmasını sağlar.

Environment Isolation

Development, staging ve production secret'larının aynı policy kapsamına alınması gereksiz risk oluşturur. Developer development secret okuyabiliyor diye production credential görmemelidir. Environment isolation path, namespace, account veya ayrı cluster yaklaşımıyla risk seviyesine göre uygulanabilir. Production erişimi daha güçlü authentication ve daha kapsamlı audit şartlarına bağlanabilir. Aynı credential'ın farklı environment'larda tekrar kullanılmaması isolation modelinin önemli tamamlayıcısıdır.

Vault Seal ve Unseal Nedir?

Vault storage içindeki hassas verileri encryption barrier modeliyle korur ve sealed durumda normal secret işlemleri yapılamaz. Vault restart sonrasında gerekli key material aktif hale gelmeden storage verisini kullanamaz. Unseal işlemi sistemi hizmet verebilir duruma getirir. Production yapılarda manuel unseal yerine cloud KMS veya HSM tabanlı auto unseal modeli operasyon yükünü azaltabilir. Seal tasarımı aynı zamanda recovery, startup bağımlılığı ve break glass prosedürleriyle birlikte düşünülmelidir.

Vault Neden Sealed Başlar?

Vault restart olduğunda encryption barrier için gerekli key material'i otomatik olarak kullanıma açmaması ek güvenlik katmanı sağlar. Storage erişimi ele geçirilse bile Vault gerekli unseal süreci tamamlanmadan normal secret işlemlerini gerçekleştiremez. Bu davranış özellikle self-hosted ortamda root of trust tasarımının parçasıdır. Manual veya auto unseal yöntemi production availability beklentisine göre belirlenir. Restart ve disaster recovery testlerinde sealed durumun application'lara etkisi önceden ölçülmelidir.

Unseal Süreci

Unseal süreci Vault'un encryption barrier için gereken anahtar erişimini elde ederek storage verisini kullanabilir hale gelmesini sağlar. Manuel modelde birden fazla yetkili kişinin sahip olduğu key shard'ları belirli threshold değerine ulaşacak biçimde kullanılabilir. Böylece tek kişinin bütün kontrolü elinde tutması önlenebilir. Ancak node restart sayısı arttıkça manuel süreç ciddi operasyon yükü oluşturur. Production sistemlerinde auto unseal bu nedenle sık tercih edilen bir yaklaşımdır.

Auto-Unseal

Auto unseal Vault'un gerekli key işlemini güvenilir harici KMS veya HSM üzerinden otomatik gerçekleştirmesini sağlar. Node restart sonrasında insan müdahalesi gerekmediği için availability açısından önemli avantaj sunar. Bununla birlikte harici key service yeni kritik bağımlılık haline gelir. KMS erişimi kesildiğinde startup ve recovery davranışının nasıl etkileneceği test edilmelidir. IAM, key policy ve deletion protection gibi kontroller auto unseal mimarisinde yüksek öncelik taşımalıdır.

AWS KMS ile Auto-Unseal

AWS KMS self-hosted Vault için auto unseal sağlayabilecek seçeneklerden biridir. Vault node yalnızca gerekli KMS key üzerinde minimum operasyon yetkisine sahip olmalıdır. KMS key policy çok geniş tutulmamalı ve key deletion koruması uygulanmalıdır. Region failure veya account erişim problemi Vault startup davranışını etkileyebileceği için disaster recovery planına dahil edilmelidir. KMS CloudTrail logları da Vault unseal operasyonunun güvenlik görünürlüğünü artırabilir.

Root Token Yönetimi

Root token Vault üzerinde son derece geniş yetkiye sahiptir ve günlük operasyon için kullanılmamalıdır. Initial setup sonrasında erişimi güvenli biçimde sonlandırmak veya çok sınırlı break glass prosedürüne almak gerekir. Normal yönetim işleri gerekli capability'lere sahip ayrı privileged identity üzerinden yapılmalıdır. Root token üretimi veya kullanımı yüksek öncelikli audit event olarak değerlendirilmelidir. Erişim prosedürü tek kişiye bağlı olmamalı ve kontrollü recovery senaryosuyla belgelenmelidir.

Recovery ve Break-Glass Senaryoları

Break glass normal authentication veya yönetim yolları çalışmadığında kritik erişim sağlamak için kullanılan acil prosedürdür. Kimlerin bu süreci başlatabileceği, kaç kişinin onay vereceği ve hangi koşulların acil durum kabul edildiği önceden belirlenmelidir. Recovery key gibi hassas materyal günlük operasyon ortamında tutulmamalıdır. Prosedür düzenli masa başı ve teknik tatbikatlarla test edilmelidir. Gerçek olay anında ilk kez denenmeye çalışılan recovery süreci hata ve kesinti riskini önemli ölçüde artırır.

AWS Secrets Manager Nedir?

AWS Secrets Manager AWS üzerinde API key, database credential ve diğer hassas değerleri saklamak, erişimlerini kontrol etmek, versioning uygulamak ve belirli senaryolarda rotation yapmak için kullanılan yönetilen servistir. AWS workload'larının IAM Role üzerinden doğrudan erişebilmesi secret zero problemini önemli ölçüde azaltır. KMS encryption, IAM authorization ve CloudTrail audit aynı AWS güvenlik modeli içinde birleşir. Gizli Veri (Secret) Yönetimi: HashiCorp Vault ve AWS Secrets karşılaştırmasında Secrets Manager'ın en büyük avantajlarından biri ayrı cluster, storage veya upgrade operasyonu gerektirmemesidir. Özellikle AWS ağırlıklı uygulamalarda düşük platform işletim yükü ve native entegrasyon ekiplerin hızlı ve güvenli standart oluşturmasını kolaylaştırır.

AWS Secrets Manager'ın Temel Bileşenleri

AWS Secrets Manager secret value, metadata, version stage, encryption key ilişkisi, tag ve access policy gibi bileşenleri birlikte yönetir. Uygulama IAM identity üzerinden servise erişir. Secret value KMS tabanlı encryption ile at rest durumda korunur. CloudTrail API erişimlerini audit etmek için kullanılabilir. Rotation desteklenen sistemlerde yeni credential oluşturma ve aktif version'a geçiş sürecini otomatik hale getirebilir.

Secret Oluşturma

Secret oluştururken naming standard, owner ve environment bilgisi baştan belirlenmelidir. Secret içine yalnızca gerçekten hassas değerler koymak configuration yönetimini sade tutar. Application runtime role secret oluşturma veya silme yetkisine sahip olmamalıdır. Tag bilgileri team, application, environment ve data classification için kullanılabilir. Creation aşamasında rotation gereksinimi ve KMS key seçimi de gelecekte yeniden tasarım gerektirmeyecek biçimde planlanmalıdır.

Secret Versioning

Secrets Manager secret'ın farklı version değerlerini ve staging label ilişkilerini yönetir. Rotation sırasında yeni credential oluşturulurken mevcut active value korunabilir ve geçiş kontrollü yapılabilir. Application çoğunlukla AWSCURRENT olarak işaretlenen version'ı okur. Önceki değer AWSPREVIOUS etiketiyle takip edilebilir. Versioning rollback ve rotation operasyonunu kolaylaştırsa da eski credential'ın hedef sistemde revoke edilmesi ayrıca yönetilmelidir.

AWSCURRENT

AWSCURRENT aktif olarak kullanılacak secret version'ını gösteren staging label'dır. Application retrieval request'leri çoğunlukla bu version'a yönelir. Rotation başarılı olduğunda label yeni doğrulanmış credential'a taşınır. Application cache süresi AWSCURRENT değişiminin ne kadar hızlı görüleceğini etkiler. Bu nedenle rotation schedule ile cache TTL aynı mimari kararın parçaları olarak değerlendirilmelidir.

AWSPREVIOUS

AWSPREVIOUS önceki secret version'ını takip etmek için kullanılan staging label'dır. Sorun giderme veya kontrollü rollback sırasında operasyonel fayda sağlayabilir. Ancak eski credential target system üzerinde hâlâ aktifse security risk devam eder. Version label ile credential validity kavramlarını birbirinden ayırmak gerekir. Retention ve rotation policy eski version'ların ne kadar süre tutulacağını açık biçimde belirlemelidir.

KMS ile Encryption

Secrets Manager secret değerlerini KMS ile at rest durumda korur. AWS managed key veya ihtiyaca göre customer managed KMS key kullanılabilir. Customer managed key daha ayrıntılı key policy, cross account ve governance kontrolü sağlayabilir. Bunun karşılığında ek key lifecycle ve maliyet sorumluluğu oluşur. Secrets Manager erişimi ile KMS key erişimi birlikte incelenmelidir çünkü yanlış key policy application'ın secret'a ulaşamamasına veya gereksiz yetki oluşmasına neden olabilir.

IAM ile Access Control

IAM hangi principal'ın hangi Secrets Manager operasyonlarını yapabileceğini belirler. Runtime application çoğu durumda yalnızca belirli secret için GetSecretValue yetkisine ihtiyaç duyar. CreateSecret, PutSecretValue veya DeleteSecret gibi yönetim izinleri ayrı role verilmelidir. Wildcard resource kullanımı mümkün olduğunca azaltılmalıdır. IAM Role temporary credential kullanımı application içine static access key yerleştirme ihtiyacını ortadan kaldırdığı için AWS native workload'larda güçlü bir temel oluşturur.

Resource-Based Policies

Resource based policy doğrudan secret kaynağı üzerinde hangi principal'ların erişebileceğini tanımlayabilir. Özellikle cross account kullanım senaryolarında önemli rol oynar. Identity policy ve resource policy birlikte değerlendirildiği için access model'in açık biçimde belgelenmesi gerekir. Geniş principal veya account izinleri yanlışlıkla secret'ın erişim alanını büyütebilir. Kritik secret'larda policy değişiklikleri security review ve otomatik validation sürecinden geçirilmelidir.

Tag-Based Authorization

Tag based authorization secret erişimini application, environment veya team gibi attribute bilgilerine göre kontrol etmeye yardımcı olur. Büyük secret sayılarında tek tek ARN policy yazmak yerine ABAC modeli operasyonu sadeleştirebilir. Örneğin workload yalnızca kendi application tag değerine sahip secret'ları okuyabilir. Tag değiştirme yetkisi access sonucunu etkilediği için yüksek riskli kabul edilmelidir. Standart tag şeması, ownership ve policy governance olmadan ABAC kullanmak beklenmeyen erişimlere yol açabilir.

CloudTrail Audit

CloudTrail Secrets Manager API çağrılarını identity, zaman ve kaynak bilgisiyle kaydeder. GetSecretValue, PutSecretValue ve policy değişiklikleri security monitoring için önemli event'lerdir. Loglar merkezi security account veya SIEM sistemine aktarılabilir. Normal workload erişimleriyle insan kullanıcı erişimleri farklı risk seviyesinde değerlendirilmelidir. CloudTrail retention ve log integrity ayarları incident investigation süresini destekleyecek biçimde yapılandırılmalıdır.

AWS Secrets Manager Rotation Nasıl Çalışır?

AWS Secrets Manager Rotation secret değerinin belirlenen schedule doğrultusunda yenilenmesini ve application'ın yeni credential'a geçmesini sağlayan süreçtir. Rotation yalnızca secret store içinde yeni value üretmek değildir çünkü target database veya service tarafında da credential değişikliği yapılmalıdır. Application cache, connection pool ve retry mekanizması yeni değeri kesintisiz kullanabilecek biçimde tasarlanmalıdır. Kurumsal sistemlerde API key parola sertifika ve secret rotation nasıl otomatikleştirilir sorusunun en önemli cevabı, automation kadar tüketici application davranışının da rotation aware olmasıdır. Rotation success yalnızca platform status üzerinden değil gerçek application connection testiyle doğrulanmalıdır.

Managed Rotation

Managed Rotation desteklenen AWS servislerinde rotation işleminin hizmet tarafından yönetilmesini sağlar. Böylece özel Lambda function geliştirme ve bakım ihtiyacı bazı kullanım alanlarında azalabilir. Hangi servis ve credential türünün managed rotation desteklediği proje zamanında güncel AWS özelliklerine göre kontrol edilmelidir. Managed model kullanılsa bile IAM, schedule ve application refresh davranışı kurumun sorumluluğundadır. Rotation failure event'lerinin monitoring sistemine bağlanması ve belirli sürede çözülmemesi halinde alert üretmesi gerekir.

Lambda-Based Rotation

Lambda based rotation özel credential veya belirli target sistemler için esnek rotation workflow'u sağlar. Function yeni secret oluşturma, target sistemde credential güncelleme, değeri test etme ve active version'a geçme adımlarını uygulayabilir. Function IAM role yalnızca ihtiyaç duyduğu Secrets Manager ve target resource izinlerine sahip olmalıdır. Loglarda secret value görünmemelidir. Retry, timeout ve rollback davranışı production öncesinde failure senaryolarıyla test edilmelidir.

Managed External Secrets Rotation

External secret rotation AWS dışındaki veya farklı lifecycle modeline sahip credential'ların yenilenmesi gerektiğinde gündeme gelebilir. Buradaki en önemli karar hangi platformun authoritative source ve rotation owner olduğudur. Aynı secret'ı hem Secrets Manager hem başka platform bağımsız olarak değiştirmeye çalışırsa dual write problemi oluşabilir. Rotation transaction'ı target system, secret store ve application arasında tutarlı biçimde tamamlanmalıdır. Failure halinde rollback veya retry davranışının hangi system tarafından yönetileceği baştan belirlenmelidir.

Rotation Schedule

Rotation Schedule credential'ın hangi sıklık ve zaman penceresinde yenileneceğini belirler. Çok uzun interval ele geçirilen secret'ın risk süresini büyütür. Çok kısa interval application cache ve connection pool davranışı hazır değilse gereksiz outage riski yaratabilir. Schedule risk sınıfı, target system kabiliyeti ve application dayanıklılığına göre seçilmelidir. Emergency rotation normal schedule'dan bağımsız olarak anında çalıştırılabilecek ayrı prosedür olarak tasarlanmalıdır.

Rate Expressions

Rate expression belirli aralıklarla rotation çalıştırmak için kullanılan schedule yöntemidir. Belirli sayıda gün veya saat gibi periyot tanımlanabilir. Business workload'un maintenance window ihtiyacı varsa sadece sıklık tanımlamak yeterli olmayabilir. Rotation target service üzerinde kısa süreli ek yük veya reconnect oluşturabileceği için uygun zamanlama seçilmelidir. Schedule değişiklikleri de security policy değişikliği olarak audit ve review kapsamına alınmalıdır.

Cron Expressions

Cron expression rotation'ı belirli gün ve saat pencerelerine yerleştirmeyi sağlar. Trafiğin daha düşük olduğu zamanlarda çalıştırmak bazı application'larda operasyon riskini azaltabilir. Global sistemlerde timezone hesapları doğru yapılmalıdır. Rotation yalnızca gece yapılıyor diye application'ın kesintiye dayanıklı olduğu varsayılmamalıdır. Schedule configuration staging ortamında gerçek rotation testiyle doğrulanmalıdır.

Single-User Rotation

Single User Rotation aynı database kullanıcısının credential değerini değiştirir. Model basittir ancak eski ve yeni credential arasındaki geçiş application connection pool üzerinde dikkatle yönetilmelidir. Existing connection'lar açık kalırken new connection eski password nedeniyle fail edebilir. Application authentication error aldığında güncel secret'ı yeniden okuyabilmelidir. Zero downtime hedefleniyorsa cache refresh ve retry davranışı rotation testinin temel parçası olmalıdır.

Alternating-Users Rotation

Alternating Users Rotation iki farklı database kullanıcısı arasında kontrollü geçiş yapmayı hedefler. Aktif kullanıcı çalışırken diğer kullanıcının credential'ı yenilenip test edilebilir. Test başarılı olduğunda active role yeni kullanıcıya geçirilir. Önceki user belirlenen grace period sonrasında rotate veya disable edilebilir. Bu model connection pool kullanılan sistemlerde daha kontrollü zero downtime geçişi sağlayabilir ancak database permission eşitliğinin iki kullanıcı için doğru yönetilmesi gerekir.

Zero-Downtime Rotation

Zero Downtime Rotation application'ın credential değişimi sırasında kullanıcıya hata yansıtmadan çalışmaya devam etmesini hedefler. Yeni credential aktif edilmeden önce target system üzerinde test edilmelidir. Application cache süresi, connection pool refresh ve retry mekanizması birlikte doğrulanmalıdır. Eski credential'ın ne kadar süre geçerli kalacağı açık grace period kuralına bağlanmalıdır. Başarılı rotation testi yalnızca platformun success durumuna değil application'ın gerçek yeni bağlantı kurabilmesine göre değerlendirilmelidir.

Manuel Acil Rotation

Manuel acil rotation credential sızıntısı veya compromise şüphesinde normal schedule beklenmeden uygulanır. İlk hedef eski credential'ın kullanımını mümkün olduğunca hızlı durdurmaktır. Yeni credential güvenli biçimde üretilmeli ve application'lar güncel değere geçirilmelidir. Audit ve monitoring üzerinden hangi workload'ların eski değeri kullanmaya çalıştığı izlenebilir. Olay sonrasında root cause belirlenmeli ve aynı secret'ın başka kopyalarının bulunup bulunmadığı inventory ve scanning ile kontrol edilmelidir.

AWS Secrets Manager ile IAM Arasındaki İlişki

Secrets Manager hassas değeri saklar, IAM ise kimin hangi API operasyonunu yapabileceğini belirler. Bu iki sistemi birbirinden bağımsız değerlendirmek yaygın tasarım hatasıdır. Secret güçlü encryption ile korunuyor olsa bile çok geniş IAM policy onlarca workload'un değeri okuyabilmesine neden olabilir. Runtime role yalnızca gerekli secret ve action için izin almalıdır. Management, rotation ve delete işlemleri ayrı identity'lere verilerek least privilege ve separation of duties uygulanmalıdır.

IAM User

IAM User uzun ömürlü access key kullanımına yol açabildiği için application workload authentication için varsayılan yöntem olmamalıdır. İnsan kullanıcı tarafında da federated SSO mümkünse daha iyi lifecycle yönetimi sağlar. Application'ın Secrets Manager'a erişmesi için IAM User access key üretmek yerine IAM Role tercih edilmelidir. Static access key sızdığında manuel rotation ve revocation gerekir. Temporary role credential kullanımı bu yönetim yükünü ve risk penceresini önemli ölçüde azaltır.

IAM Role

IAM Role AWS workload'larının temporary credential kullanmasına imkân verir. Lambda, ECS, EC2 ve EKS application'ları Secrets Manager'a role üzerinden erişebilir. Policy yalnızca gereken secret resource'larını kapsamalıdır. Application içinde AccessKeyId ve SecretAccessKey saklanmasına gerek kalmaz. Bu yaklaşım AWS native sistemlerde secret zero problemini çözmenin en güçlü ve en düşük operasyonlu yöntemlerinden biridir.

Resource Policy

Resource Policy belirli secret'a hangi principal veya account'ların erişebileceğini doğrudan tanımlar. Cross account mimarilerinde sık kullanılır. Identity based policy ile resource policy birlikte çalıştığı için access model açıkça belgelenmelidir. Geniş principal izinleri beklenmeyen account veya role erişimine yol açabilir. Kritik secret policy değişiklikleri otomatik security validation ve code review sürecine dahil edilmelidir.

Cross-Account Access

Cross Account Access merkezi shared services veya security account modellerinde gerekli olabilir. Secret Resource Policy target account içindeki belirli IAM Role'a erişim verebilir. Customer Managed KMS Key kullanılıyorsa KMS Key Policy tarafında da gerekli cross account izinleri bulunmalıdır. Network ve VPC endpoint yaklaşımı erişim modeline ek güvenlik katmanı sağlayabilir. Account sayısı büyüdükçe ownership, audit ve organization boundary kontrolleri daha önemli hale gelir.

Least Privilege

Least Privilege runtime application'a yalnızca gereken GetSecretValue gibi minimum operasyon izinlerini vermeyi hedefler. DeleteSecret veya PutSecretValue gibi management izinleri application rolüne eklenmemelidir. Resource ARN mümkün olduğunca exact veya dar pattern ile sınırlandırılmalıdır. Production ve development account ayrımı erişim riskini daha da azaltabilir. Access review kullanılmayan role ve policy izinlerini zaman içinde kaldırmalıdır.

ABAC ve Secret Tags

ABAC secret ve principal tag bilgilerini authorization kararında kullanabilir. Büyük application sayılarında her secret için ayrı IAM statement üretmek yerine scalable policy modeli sağlar. Örneğin workload ve secret aynı application tag değerine sahipse erişim verilebilir. Bununla birlikte tag değiştirme yetkisi doğrudan authorization sonucunu etkilediği için sıkı biçimde kontrol edilmelidir. Governance olmadan kullanılan ABAC yanlış etiket nedeniyle beklenmeyen production secret erişimine yol açabilir.

AWS Credential Neden Secrets Manager'da Saklanmamalı?

AWS workload'un AWS servislerine erişmesi gerekiyorsa static access key'i Secrets Manager içine koymak çoğu durumda gereksizdir. IAM Role zaten temporary credential üretir ve AWS tarafından lifecycle yönetimi sağlanır. Secrets Manager'a konan static key encryption altında olsa bile key'in uzun ömürlü olma problemi devam eder. Rotation ve secret zero yükü gereksiz biçimde application ekibine geçer. Harici sistem gerçekten static AWS credential gerektiriyorsa scope daraltılmalı, kullanım izlenmeli ve rotation süresi kısa tutulmalıdır.

AWS KMS ile AWS Secrets Manager Arasındaki Fark

AWS KMS cryptographic key ve encryption operasyonlarını yönetirken AWS Secrets Manager application secret değerlerinin saklanması ve yaşam döngüsüne odaklanır. İki servis birbirinin alternatifi değildir ve çoğu mimaride birlikte çalışır. Secrets Manager içindeki secret değerleri KMS key ile at rest durumda korunabilir. Database password'u doğrudan KMS içine normal secret gibi koymak doğru service abstraction değildir. Servis seçimi yapılırken verinin credential mı yoksa cryptographic key mi olduğu açık biçimde belirlenmelidir.

Secrets Manager Ne Saklar?

Secrets Manager API key, password, database credential, token ve benzeri application secret değerlerini saklar. Metadata, version, tag ve rotation configuration aynı resource çevresinde yönetilebilir. IAM üzerinden erişim kontrolü uygulanır. Application runtime sırasında GetSecretValue çağrısıyla gerekli değeri alabilir. Secret'ın at rest encryption'ı KMS ile sağlanarak storage security ile application lifecycle ayrı katmanlar halinde yönetilir.

KMS Ne Yönetir?

KMS encryption key ve cryptographic operation yönetimine odaklanır. Application Encrypt, Decrypt veya desteklenen signing operasyonlarını KMS üzerinden çalıştırabilir. Key Policy hangi identity'nin cryptographic key'i kullanabileceğini belirler. Key rotation ile database password rotation birbirinden farklı süreçlerdir. KMS application secret store olarak değil güvenli key management ve cryptographic service olarak değerlendirilmelidir.

Envelope Encryption

Envelope Encryption verinin data key ile, data key'in ise daha yüksek seviye key ile korunmasına dayanan yaygın encryption modelidir. Büyük veriyi doğrudan merkezi KMS üzerinde işlemeye çalışmak yerine daha verimli cryptographic workflow sağlar. Managed AWS servisleri bu yaklaşımı arka planda kullanabilir. Application kendi encryption sistemini tasarlıyorsa data key lifecycle ve master key access kurallarını doğru yönetmelidir. KMS ile Secrets Manager arasındaki ilişkiyi anlamak bu katmanların neden birbirinin yerine kullanılmadığını açık hale getirir.

AWS-Managed Key

AWS Managed Key ilgili AWS servisi tarafından yönetilen KMS key seçeneğidir. Basit kullanımda ek key lifecycle operasyonunu azaltabilir. Özel Key Policy veya belirli cross account gereksinimlerinde yeterli esnekliği sağlamayabilir. Compliance veya internal governance ihtiyacı customer managed key gerektirebilir. Her application'da otomatik olarak özel key kullanmak ise gereksiz policy ve maliyet yükü oluşturabileceği için ihtiyaca göre karar verilmelidir.

Customer-Managed KMS Key

Customer Managed KMS Key kurumun Key Policy, lifecycle ve kullanım kontrolü üzerinde daha fazla yetki sahibi olmasını sağlar. Cross account access ve ayrıntılı governance senaryolarında faydalıdır. Bunun karşılığında yanlış policy değişikliği Secrets Manager secret'larının application tarafından okunamamasına yol açabilir. Key deletion ciddi production outage oluşturabileceği için güçlü deletion protection süreci gerekir. Maliyet, compliance ve yönetim sorumluluğu birlikte değerlendirilmelidir.

Hangi Problem İçin Hangi Servis Kullanılmalı?

Application'ın database password, API key veya OAuth credential saklaması gerekiyorsa Secrets Manager doğru başlangıç noktasıdır. Application verisini cryptographic key ile encrypt etmek veya signing yapmak istiyorsanız KMS kullanılır. Secret'ın storage encryption'ı için iki servis zaten birlikte çalışabilir. Internal key governance ihtiyacı farklıysa ayrıca HSM ve KMS mimarisi değerlendirilir. Doğru seçim verinin sınıflandırılması ve yaşam döngüsünün anlaşılmasıyla yapılır.

AWS Secrets Manager ve SSM Parameter Store Arasındaki Fark

AWS Secrets Manager ile SSM Parameter Store bazı ortak kullanım alanlarına sahip olsa da odak noktaları farklıdır. Parameter Store configuration ve parameter yönetiminde güçlüdür, Secrets Manager ise secret lifecycle ve rotation yeteneklerini öne çıkarır. Basit encrypted configuration değeri için Parameter Store yeterli olabilir. Database credential rotation veya secret version workflow gereken durumda Secrets Manager daha doğal seçim olabilir. Servis seçimi yapılırken yalnızca encryption özelliğine değil rotation, API usage, integration ve maliyet gereksinimlerine birlikte bakılmalıdır.

Secret Storage

Her iki servis hassas değer saklamak için kullanılabilir. Secrets Manager secret odaklı metadata, versioning ve rotation özellikleri sağlar. Parameter Store SecureString belirli configuration değerlerini KMS ile koruyabilir. Basit kullanımda iki servis de teknik olarak ihtiyacı karşılayabilir. Fark lifecycle, integration ve operasyon beklentisi arttıkça daha net hale gelir.

Configuration Management

Parameter Store normal application configuration değerlerini merkezi biçimde yönetmek için uygundur. Port, endpoint, feature configuration ve bazı hassas parametreler hiyerarşik path altında tutulabilir. Secrets Manager esas olarak secret değerlerine odaklandığı için normal configuration verisinin tamamını buraya taşımak gerekli değildir. Secret ile configuration ayrımı access policy'leri sadeleştirir. Aynı zamanda gereksiz Secrets Manager resource ve API maliyetini azaltabilir.

Rotation

Secrets Manager credential rotation senaryolarını destekleyen yerleşik özellikler sunar. Parameter Store içinde değer automation ile değiştirilebilir, ancak target system credential update ve validation workflow'unu ayrıca tasarlamak gerekir. Database password gibi düzenli rotation gereken değerlerde Secrets Manager daha uygun olabilir. Basit application configuration'da rotation ihtiyacı bulunmayabilir. Bu nedenle servis seçimi sadece “ikisi de encrypted value saklıyor” yaklaşımına indirgenmemelidir.

Encryption

Parameter Store SecureString KMS ile encryption sağlayabilir. Secrets Manager da KMS tabanlı at rest encryption kullanır. Bu nedenle iki servis arasındaki temel fark encryption yapıp yapmaması değildir. Rotation, metadata, versioning, integration ve pricing asıl karşılaştırma alanlarıdır. Customer Managed KMS Key gereksinimi her iki serviste de ayrıca governance ve maliyet kararı oluşturabilir.

Maliyet

Maliyet secret veya parameter sayısı, API request hacmi ve KMS kullanımına göre değerlendirilmelidir. Parameter Store bazı basit kullanım modellerinde daha ekonomik olabilir. Secrets Manager'ın rotation ve secret lifecycle özellikleri farklı fiyatlandırma modeliyle gelir. Yüksek request hacminde client side caching API maliyetini düşürür. Güncel fiyatlandırma region ve servis özelliklerine göre değişebileceği için proje planlama aşamasında doğrudan AWS fiyat bilgileri üzerinden yeniden hesaplanmalıdır.

Hangi Senaryoda Parameter Store Yeterlidir?

Application'ın merkezi configuration değerlerini yönetmesi gerekiyorsa Parameter Store çoğu durumda yeterlidir. SecureString üzerinden az sayıda hassas configuration değeri de tutulabilir. Otomatik credential rotation veya gelişmiş secret version lifecycle ihtiyacı yoksa daha sade çözüm sağlar. Küçük projelerde operasyon ve maliyet avantajı olabilir. Buna rağmen IAM, KMS, audit ve environment isolation gereksinimleri hassas değer kullanıldığında ihmal edilmemelidir.

Hangi Senaryoda Secrets Manager Kullanılmalıdır?

Database credential, API key veya düzenli rotation gereken secret değerlerinde Secrets Manager güçlü seçimdir. RDS, Lambda, ECS ve EKS gibi AWS servisleriyle yakın entegrasyon application development sürecini kolaylaştırır. Secret version lifecycle ve automatic rotation gerekiyorsa Parameter Store'a göre daha uygun özellik seti sağlar. AWS native workload IAM Role ile doğrudan erişebilir. Multi cloud merkezi secret platformu gerekiyorsa Vault ile ayrı bir mimari karşılaştırma yapılmalıdır.

HashiCorp Vault vs AWS Secrets Manager

HashiCorp Vault mı AWS Secrets Manager mı kullanılmalı sorusunun tek bir genel cevabı yoktur. Vault multi cloud, on premise, dynamic secrets, PKI ve encryption service gibi daha geniş platform kabiliyetleri sunarken Secrets Manager AWS native düşük operasyon yaklaşımıyla öne çıkar. Vault self hosted olduğunda HA, backup, storage, upgrade ve monitoring sorumluluğu kurumun üzerindedir. Secrets Manager bu altyapı operasyonunu AWS tarafından yönetilen hizmet olarak sağlar. Doğru karar ekip büyüklüğü, workload dağılımı, dynamic credential ihtiyacı, vendor bağımlılığı ve total cost of ownership birlikte değerlendirilerek verilmelidir.

Deployment Modeli

Vault self hosted veya managed hizmet modeliyle kullanılabilir ve farklı cloud veya on premise ortamlarına yerleştirilebilir. AWS Secrets Manager ise doğrudan AWS tarafından yönetilen regional service olarak sunulur. Vault daha fazla infrastructure control sağlarken aynı ölçüde operasyon sorumluluğu da getirir. Secrets Manager node, storage veya upgrade yönetimini application ekibinden uzaklaştırır. Deployment tercihi data residency, network, platform yetkinliği ve availability gereksinimine göre yapılmalıdır.

Static Secret Management

Her iki platform da static secret saklayabilir. Vault KV Engine path ve policy tabanlı model sunar. Secrets Manager IAM, KMS ve versioning ile AWS native yapı sağlar. Yalnızca birkaç API key veya password saklanacaksa iki çözüm de teknik olarak ihtiyacı karşılayabilir. Kararı belirleyen asıl unsur environment kapsamı ve platform operasyon modelidir.

Dynamic Secrets

Vault Dynamic Secrets özellikle database ve bazı infrastructure credential'larında güçlüdür. Credential request anında üretilebilir ve lease ile kısa süreli yönetilebilir. Secrets Manager'ın temel modeli çoğunlukla saklanan secret'ın version ve rotation sürecine dayanır. AWS cloud access için ise IAM Role zaten temporary credential üretir. Bu nedenle iki platformun dynamic credential yaklaşımını birebir aynı özellik gibi değerlendirmek doğru değildir.

Secret Rotation

Secrets Manager AWS servisleriyle rotation entegrasyonunda avantajlıdır. Vault static secret rotation yanında dynamic credential üretimiyle uzun ömürlü secret ihtiyacını tamamen azaltabilir. Target system hangi modeli destekliyorsa en güçlü sonuç oradan gelir. Application rotation aware değilse iki platformda da outage yaşanabilir. Rotation başarısı application connection ve gerçek workload davranışı üzerinden doğrulanmalıdır.

Authentication

Vault Kubernetes, AWS, OIDC, JWT, AppRole ve LDAP gibi farklı authentication method seçenekleri sunar. Secrets Manager erişimi AWS IAM identity modeline dayanır. AWS workload için IAM Role son derece doğal ve düşük operasyonlu çözüm sağlar. Multi cloud veya on premise workload'larda Vault'un auth çeşitliliği daha fazla esneklik sunabilir. Her iki durumda da long lived login credential yerine workload identity tercih edilmelidir.

Authorization

Vault path ve capability tabanlı policy modeli kullanır. Secrets Manager authorization AWS IAM identity policy, resource policy ve tag condition yapıları üzerinden çalışır. Kurumun güvenlik sistemi zaten IAM merkezliyse Secrets Manager yeni bir policy platformu getirmez. Çoklu ortamda Vault ortak authorization katmanı sağlayabilir. Least privilege ve düzenli access review her iki modelde de temel gereksinimdir.

Encryption

Vault stored secret encryption yanında Transit Engine ile application'a encryption as a service sağlayabilir. Secrets Manager secret değerini KMS ile at rest durumda korur. Genel application encryption ihtiyacı için Secrets Manager kullanılmaz. AWS tarafında bu amaç KMS gibi cryptographic service'lerle çözülür. Karşılaştırmada storage encryption ile application cryptography kavramları birbirinden ayrılmalıdır.

PKI

Vault PKI Secrets Engine internal certificate authority ve short lived certificate üretiminde güçlüdür. Secrets Manager genel amaçlı PKI platformu değildir. AWS ortamında certificate lifecycle için farklı AWS servisleri kullanılabilir. Kurum internal PKI ve secret platformunu tek policy modeli altında yönetmek istiyorsa Vault avantaj sağlayabilir. Root CA security ve certificate revocation süreçleri platform seçiminden bağımsız olarak dikkatle tasarlanmalıdır.

Audit Logging

Vault audit devices üzerinden kendi request kayıtlarını üretir. Secrets Manager erişimleri CloudTrail aracılığıyla izlenebilir. Her iki sistemin logları merkezi SIEM'e gönderilebilir. Audit loglarının kendisi de access controlled ve integrity protected biçimde tutulmalıdır. Application, identity ve secret access loglarını birlikte analiz etmek incident investigation süresini azaltır.

High Availability

Self hosted Vault HA tasarımı kurumun sorumluluğundadır. Node dağılımı, storage quorum, load balancer ve failure domain planlanmalıdır. Secrets Manager managed service availability modelini kullanır. Buna rağmen application API timeout, cache ve region failure davranışını kendisi yönetmelidir. HA yalnızca secret platformunun ayakta olması değil application'ın credential erişimi bozulduğunda nasıl davrandığıyla da ilgilidir.

Disaster Recovery

Vault backup, snapshot, restore ve gerekirse secondary site tasarımı kurum tarafından yapılır. Secrets Manager cross region replication gibi mekanizmalarla disaster recovery senaryolarını destekleyebilir. Application failover sırasında hangi region secret'ını kullanacağını bilmelidir. KMS ve IAM dependency'leri target region için hazır olmalıdır. RTO ve RPO secret platformuyla application disaster recovery planında birlikte değerlendirilmelidir.

Kubernetes Integration

Vault Kubernetes Auth, Agent Injector, CSI Provider ve Secrets Operator gibi farklı integration modelleri sunar. AWS Secrets Manager EKS üzerinde Secrets Store CSI Driver ve AWS Secrets and Configuration Provider ile kullanılabilir. EKS workload identity IRSA veya EKS Pod Identity ile sağlanabilir. Her iki platform da secret'ı file veya runtime retrieval modeliyle application'a ulaştırabilir. Karar cluster'ların yalnızca AWS içinde mi yoksa multi cloud ortamda mı olduğuna göre değişebilir.

Multi-Cloud

Vault multi cloud ve on premise altyapılarda ortak secret control plane oluşturma konusunda güçlüdür. AWS Secrets Manager doğal olarak AWS ekosistemine odaklanır. Farklı cloud provider'larda ayrı secret servisleri kullanmak istemeyen platform ekipleri Vault ile standardizasyon sağlayabilir. Bunun karşılığında merkezi platform network ve HA bağımlılığı daha kritik hale gelir. Multi cloud esnekliğinin operasyon maliyetini karşılayıp karşılamadığı gerçek workload ihtiyacına göre değerlendirilmelidir.

Operational Complexity

Self hosted Vault node, storage, TLS, seal, snapshot, monitoring ve upgrade işlemleri gerektirir. Secrets Manager bu platform altyapısının büyük bölümünü managed service olarak sunar. Küçük ekiplere en büyük farkı çoğu zaman özellik değil operasyon yükü yaratır. Büyük platform ekipleri Vault'un gelişmiş kabiliyetlerini sürdürebilecek kaynak ve on call organizasyonuna sahip olabilir. Operational complexity mutlaka architecture decision record içinde açık maliyet kalemi olarak yer almalıdır.

Vendor Lock-In

Secrets Manager IAM ve diğer AWS servisleriyle yakın entegre olduğu için AWS dependency'sini artırabilir. Vault farklı provider'larda ortak API ve policy modeli sunarak cloud bağımlılığını azaltabilir. Ancak Vault da kendi API, policy, operational tooling ve lisans modeline bağımlılık oluşturur. Soyutlama katmanı geliştirmek lock in riskini azaltabilir, fakat kendi bakım maliyetini getirir. Vendor dependency tamamen yok edilecek bir durumdan çok bilinçli biçimde yönetilecek architecture trade off olarak ele alınmalıdır.

Maliyet

Secrets Manager maliyeti secret sayısı, API request, KMS ve rotation bileşenleri üzerinden hesaplanabilir. Vault self hosted modelde compute, storage, load balancer, backup, monitoring ve insan operasyonu maliyeti taşır. Enterprise özellik gerekiyorsa lisans da TCO hesabına eklenir. Yalnızca aylık service invoice karşılaştırması çoğu zaman yanıltıcıdır. Bir veya üç yıllık total cost of ownership hesabı gerçek ekip zamanı ve on call sorumluluğunu da kapsamalıdır.

HashiCorp Vault Ne Zaman Tercih Edilmeli?

HashiCorp Vault özellikle secret management ihtiyacı tek cloud provider sınırlarını aştığında daha güçlü hale gelir. Multi cloud, hybrid cloud, on premise, dynamic database credential, internal PKI ve encryption as a service gereksinimleri tek control plane altında birleştirilebilir. Farklı workload identity kaynakları ortak policy modeline bağlanabilir. Bununla birlikte platform ekibinin Vault'u yüksek erişilebilir ve güvenli biçimde işletme kapasitesi bulunmalıdır. Sadece birkaç static API key saklamak için Vault kurmak güçlü özelliklerin büyük bölümünü kullanmadan önemli operasyon sorumluluğu almak anlamına gelebilir.

Multi-Cloud Ortamlar

Multi cloud ortamda her provider'ın farklı secret manager servisini kullanmak governance ve developer deneyimini parçalayabilir. Vault ortak API, authentication ve policy modeli sağlayarak platform ekiplerine standardizasyon sunar. Application farklı cloud ortamlarında benzer secret consumption pattern kullanabilir. Merkezi platform network latency ve availability açısından dikkatli tasarlanmalıdır. Bir Vault outage birden fazla cloud workload'unu etkileyebileceği için HA ve disaster recovery gereksinimi ciddi biçimde artar.

Hybrid Cloud

Hybrid cloud on premise sistemlerle public cloud workload'larının birlikte çalıştığı yapılardır. Vault iki taraf için ortak secret ve credential hizmeti sağlayabilir. Legacy database ile modern Kubernetes application aynı governance altında yönetilebilir. Her environment kendi native identity yöntemiyle Vault'a authenticate olabilir. Private network connectivity, certificate trust ve disaster recovery tasarımı merkezi platformun güvenli çalışması için başlangıçtan planlanmalıdır.

On-Premise Sistemler

On premise ortamda cloud native secret service kullanımı network, identity veya data governance nedeniyle uygun olmayabilir. Vault kurumun kendi veri merkezinde çalıştırılabilir. Bu model storage, network ve key management üzerinde yüksek kontrol sağlar. Bunun karşılığında bütün infrastructure lifecycle ve security operation kuruma geçer. HSM veya özel KMS entegrasyonu gerekiyorsa mimari gereksinimler ayrıca ayrıntılı biçimde test edilmelidir.

Dynamic Database Credentials

Dynamic Database Credentials Vault tercihinin en güçlü gerekçelerinden biridir. Application'lar shared production password yerine kendi short lived user bilgisini alabilir. Lease expiration ve revocation credential yaşam döngüsünü otomatikleştirir. Audit unique identity ve username üzerinden daha anlamlı hale gelir. Mikroservis sayısı arttıkça bu model manuel static password rotation'a göre çok daha sürdürülebilir olabilir.

Short-Lived Cloud Credentials

Vault birden fazla cloud provider için short lived credential üretimini ortak control plane'e bağlayabilir. CI/CD veya central automation farklı cloud ortamlarına deployment yapıyorsa bu standardizasyon faydalıdır. Bununla birlikte target cloud native federation destekliyorsa doğrudan workload identity kullanmak daha sade olabilir. Vault araya ek network ve availability dependency koyar. Merkezi governance ihtiyacı bu ek maliyeti gerçekten karşılıyorsa tercih edilmelidir.

Internal PKI

Internal PKI çok sayıda service certificate'ın otomatik üretilmesini ve yenilenmesini gerektirir. Vault PKI Secrets Engine kısa ömürlü X.509 certificate üretimini merkezi hale getirebilir. Manuel CSR ve yıllarca yaşayan private key kullanımını azaltır. Kubernetes veya service mesh ortamlarında automated issuance ile güçlü integration kurulabilir. Root CA protection, intermediate CA design ve certificate revocation stratejisi ayrıca güvenli biçimde planlanmalıdır.

Encryption-as-a-Service

Transit Engine application'ın cryptographic key materyalini görmeden encryption ve decryption işlemi yapmasına imkân verir. Birden fazla application ortak key governance modeline ihtiyaç duyuyorsa bu yaklaşım güçlüdür. Key rotation merkezi platformda yürütülebilir. Application yalnızca gerekli encrypt veya decrypt capability'sine sahip olabilir. Bu model geliştiricilerin key dosyalarını configuration içine koymasını engelleyerek operational security seviyesini yükseltir.

Karmaşık Enterprise Policy Gereksinimleri

Büyük organizasyonlarda team, application, environment ve farklı infrastructure türleri için ayrıntılı access kuralları gerekir. Vault path ve identity tabanlı policy sistemi bu yapıyı merkezi hale getirebilir. Gelişmiş enterprise yetenekleri belirli organizasyonel ayrım ihtiyaçlarında ek fayda sağlayabilir. Policy değişiklikleri code review ve automated validation sürecine alınmalıdır. Aksi halde merkezi Vault zamanla çok geniş permission'ların toplandığı riskli bir control plane'e dönüşebilir.

AWS Secrets Manager Ne Zaman Tercih Edilmeli?

AWS Secrets Manager workload'ların büyük bölümü AWS üzerinde çalışıyorsa oldukça güçlü ve sade bir seçimdir. IAM, KMS, CloudTrail, Lambda, ECS, EKS ve RDS ile native integration yeni bir secret platformu işletme ihtiyacını azaltır. Küçük ve orta ölçekli ekiplerde bu operasyon avantajı çoğu zaman belirleyicidir. AWS native application yalnızca secret saklama ve rotation ihtiyacı taşıyorsa Vault cluster kurmak gereksiz ek responsibility yaratabilir. En iyi seçim daha fazla özelliği olan ürün değil, gerçek security ihtiyacını en sürdürülebilir biçimde çözen platformdur.

AWS-Native Uygulamalar

AWS native application IAM Role ile Secrets Manager'a doğrudan erişebilir. Ayrı secret manager login password veya static AWS key taşımaz. CloudTrail audit ve KMS encryption mevcut AWS security modeline entegre olur. Private network gereksiniminde VPC endpoint gibi seçenekler değerlendirilebilir. Bu bütünlük hem developer experience hem de security governance açısından daha sade architecture oluşturabilir.

Küçük ve Orta Ölçekli Ekipler

Küçük ekiplerin özel Vault platformunu sürekli işletmek için ayrı mühendislik kapasitesi bulunmayabilir. Secrets Manager managed service olduğu için node, storage, backup ve upgrade sorumluluğunu azaltır. Ekip IAM policy ve application integration üzerine yoğunlaşabilir. Basit database credential rotation AWS native workflow ile çözülebilir. Multi cloud veya gelişmiş dynamic secret gereksinimi ortaya çıkana kadar bu sadelik çoğu proje için önemli avantajdır.

Operasyon Yükünü Azaltmak İsteyen Ekipler

Vault kurmak kadar onu yıllarca güvenli işletmek de sürekli iş gerektirir. Upgrade, monitoring, snapshot, capacity ve incident süreçleri platform ekibinin sorumluluğundadır. Secrets Manager bu infrastructure katmanını AWS tarafından yönetilen hizmete dönüştürür. IAM ve application side güvenlik sorumluluğu yine kurumda kalır. Managed service yanlış access policy problemini çözmez, ancak cluster management ve on call yükünü önemli ölçüde azaltır.

RDS / Aurora Credential Yönetimi

RDS ve Aurora Secrets Manager'ın güçlü kullanım alanlarından biridir. Database credential merkezi saklanabilir ve uygun rotation modeliyle otomatik yenilenebilir. Application IAM Role üzerinden güncel secret value'ya erişebilir. Connection pool'un yeni credential'a geçiş davranışı mutlaka test edilmelidir. Database service identity tabanlı authentication destekliyorsa static password'u tamamen azaltma fırsatı da ayrıca değerlendirilmelidir.

Lambda ve Serverless Uygulamalar

Lambda execution role ile Secrets Manager'a temporary credential üzerinden erişebilir. Application içine static AWS key eklemeye gerek kalmaz. Client side cache veya local provider modelinin kullanılması remote API call ve latency değerlerini azaltabilir. Secret environment variable içinde deployment paketine sabitlenmek yerine runtime sırasında alınabilir. Rotation sonrası cache refresh davranışı özellikle uzun yaşayan execution environment'larda test edilmelidir.

ECS ve EKS Workload'ları

ECS task role ve EKS pod identity mekanizmaları Secrets Manager erişimini workload identity ile ilişkilendirebilir. Static AWS access key dağıtımı ortadan kalkar. EKS tarafında CSI Driver ve AWS Secrets and Configuration Provider file mount modeli sunabilir. Application isterse AWS SDK üzerinden runtime retrieval yapabilir. Hangi consumption yönteminin seçileceği rotation, latency, code change ve Kubernetes Secret kullanım ihtiyacına göre belirlenmelidir.

AWS IAM'ın Merkezi Yetkilendirme Sistemi Olduğu Ortamlar

Kurumun authorization sistemi zaten AWS IAM üzerine kurulmuşsa Secrets Manager yeni policy platformu getirmez. Security ekipleri mevcut role, tag, account ve organization governance yöntemlerini kullanabilir. CloudTrail erişim event'leri merkezi security monitoring'e bağlanır. Vault eklenmesi ikinci authentication ve policy control plane yaratabilir. Gerçek multi cloud, dynamic secret veya PKI ihtiyacı bulunmuyorsa IAM merkezli Secrets Manager modeli daha sade ve sürdürülebilir kalabilir.

Vault ve AWS Secrets Manager Birlikte Kullanılabilir mi?

Vault ve AWS Secrets Manager aynı kurumda birlikte kullanılabilir, ancak hangi platformun hangi secret sınıfından sorumlu olduğu açık biçimde tanımlanmalıdır. Merkezi multi cloud control plane Vault olabilirken bazı AWS native database credential'ları Secrets Manager üzerinde yönetilebilir. Aynı secret iki platformda bağımsız olarak rotate edilirse source of truth problemi ve production outage riski oluşur. Hibrit model tek başına güvenlik artışı sağlamaz ve aksine inventory, audit ve rotation operasyonunu zorlaştırabilir. İki platformun birlikte kullanımı gerçek organizasyonel veya teknik gerekçeye dayanmalı ve ownership kesin biçimde belgelenmelidir.

Merkezi Vault + AWS-Native Secrets Manager

Bu modelde Vault kurum genelinde merkezi platform olurken AWS'ye özel belirli secret lifecycle işlemleri Secrets Manager'da tutulabilir. Örneğin on premise database credential Vault'ta, RDS credential ise Secrets Manager'da yönetilebilir. Her secret sınıfının authoritative source'u baştan belirlenmelidir. Application hangi sistemden değer okuyacağını açık biçimde bilmelidir. İki platform arasında kopyalama gerekiyorsa mümkün olduğunca tek yönlü ve kontrollü synchronization kullanılmalıdır.

Multi-Cloud Control Plane

Vault multi cloud control plane olarak farklı provider workload'ları için ortak authentication ve policy sunabilir. AWS native application'lar bazı secret türlerinde Secrets Manager kullanmaya devam edebilir. Bu yapı merkezi governance ile local cloud integration arasında denge kurabilir. Bunun karşılığında iki farklı audit ve rotation sistemi security ekibinin izleme yükünü artırır. Merkezi secret inventory her iki platformdaki kaynakları tek görünümde gösterecek biçimde tasarlanmalıdır.

AWS Workload'larına Secret Dağıtımı

AWS workload secret kullanırken gereksiz kopya oluşturulmaması önemlidir. Secret Vault'ta ise application doğrudan Vault'a authenticate olabilir veya belirli entegrasyon modeliyle değeri alabilir. Secret zaten Secrets Manager'da tutuluyorsa aynı değeri tekrar Vault'a kopyalamak çoğu durumda fayda sağlamaz. Her yeni kopya ayrı access policy ve rotation synchronization ihtiyacı yaratır. Runtime retrieval mümkünse workload authoritative source'tan doğrudan okuma yapmalıdır.

Source of Truth Problemi

Aynı secret Vault ve Secrets Manager içinde bulunduğunda hangisinin güncel ve doğru değer olduğu kesin olarak bilinmelidir. Bir platform rotation yaparken diğeri eski değeri tutarsa application farklı source'lardan farklı credential alabilir. Bu durum aralıklı authentication error ve outage oluşturur. Her secret sınıfı için tek authoritative system belirlemek en güvenli çözümdür. Replica veya synchronized copy gerekiyorsa update yönü ve failure davranışı açıkça tanımlanmalıdır.

Dual-Write Riski

Dual Write aynı secret'ın iki ayrı sistem tarafından değiştirilebilmesi anlamına gelir. Vault rotate ettikten sonra Secrets Manager eski değeri target system'e yeniden yazabilir veya tam tersi gerçekleşebilir. Bu race condition özellikle otomatik scheduler'larda zor teşhis edilen kesintilere neden olur. Tek platform mutation owner olmalıdır. Diğer sistem gerekiyorsa read only consumer veya controlled replica rolünde tutulmalıdır.

Conflict Resolution

Conflict oluştuğunda hangi version'ın authoritative kabul edileceği önceden belirlenmiş olmalıdır. Yalnızca timestamp karşılaştırmak her zaman güvenli değildir. Rotation transaction ID, version metadata veya explicit source flag kullanılabilir. Application yanlış credential gördüğünde rollback veya retry davranışının ne olacağı belgelenmelidir. Conflict event'leri security ve platform monitoring sisteminde görünür hale getirilmelidir.

Rotation Ownership

Rotation Ownership bir secret'ı hangi platformun ve hangi ekibin değiştirebileceğini tanımlar. Aynı credential için iki bağımsız scheduler çalıştırılmamalıdır. Owner bilgisi inventory ve metadata içinde bulunmalıdır. Normal rotation ile emergency rotation yetkileri ayrı role'lara verilebilir. Hibrit architecture'da ownership belirsizliği en sık görülen production sorunlarından biri olduğu için başlangıçta çözülmelidir.

Hibrit Mimari Ne Zaman Mantıklıdır?

Hibrit model farklı environment ve workload'ların gerçekten farklı secret platform kabiliyetlerine ihtiyacı olduğunda mantıklıdır. Örneğin multi cloud ve on premise credential Vault'ta, AWS managed database rotation Secrets Manager'da yönetilebilir. Aynı secret'ı iki platformda aynı işlevle tutmak ise çoğu zaman gereksizdir. Operasyon ekibi iki sistemin audit, incident ve lifecycle süreçlerini birlikte yönetebilecek kapasitede olmalıdır. Hibrit yaklaşım araç çeşitliliği hedefi değil net architecture ihtiyacının sonucu olmalıdır.

Kubernetes'te Secret Management

Kubernetes kendi Secret resource'unu sunsa da production secret management yalnızca bu objeyi oluşturmakla tamamlanmaz. Secret'ın cluster'a nasıl girdiği, etcd üzerinde nasıl korunduğu, pod'a hangi yöntemle verildiği ve rotation sonrası nasıl güncellendiği düşünülmelidir. External secret manager kullanmak workload identity ile merkezi lifecycle arasında daha güçlü bağlantı kurabilir. Environment variable, file mount ve runtime retrieval farklı risk ve operasyon modellerine sahiptir. Kubernetes ortamında Service Account identity'yi kullanmak secret zero problemini azaltan en önemli tasarım yaklaşımlarından biridir.

Kubernetes Secret Nedir?

Kubernetes Secret hassas configuration veya credential bilgisini workload'lara sağlamak için kullanılan API resource'udur. Değer pod'a environment variable veya volume olarak verilebilir. Base64 encoding encryption anlamına gelmediği için etcd encryption at rest ayrıca yapılandırılmalıdır. RBAC yalnızca gerekli Service Account'ların Secret resource'una erişmesine izin vermelidir. External secret platformundan değer senkronize edilse bile Kubernetes Secret oluşturuluyorsa cluster içindeki yeni kopyanın güvenliği kurumun sorumluluğundadır.

Kubernetes Secret Tek Başına Yeterince Güvenli mi?

Kubernetes Secret tek başına tam lifecycle secret management platformu değildir. External credential generation, advanced rotation ve merkezi audit için ek bileşenlere ihtiyaç duyulabilir. RBAC yanlış yapılandırıldığında başka namespace veya workload'lar secret değerini okuyabilir. Etcd backup'larının güvenliği de production threat model'in parçasıdır. Kubernetes Secret güçlü cluster hardening ile kullanılabilir, ancak Vault veya Secrets Manager gibi harici platformların sağladığı lifecycle özelliklerini otomatik olarak sunmaz.

Secret'ı Environment Variable Olarak Vermek

Environment Variable application entegrasyonunu kolaylaştırır ve birçok framework tarafından doğal biçimde desteklenir. Ancak değer process startup sırasında yüklenir ve rotation sonrasında running container'a otomatik olarak yansımayabilir. Debug veya process inspection hassas değeri açığa çıkarabilir. Pod restart gereksinimi rotation operasyonunu etkiler. Sık rotate edilen credential'larda file mount veya runtime retrieval daha uygun olabilir.

Secret'ı File Olarak Mount Etmek

File Mount secret değerini container filesystem üzerinde belirli path'e sunar. CSI tabanlı çözümler external secret manager'dan alınan değeri memory backed volume üzerinde gösterebilir. Rotation mekanizması dosyayı güncelleyebilir, ancak application'ın değişikliği algılaması gerekir. File permission yalnızca gerekli process veya container'a erişim verecek biçimde tanımlanmalıdır. Shared volume gereksiz container'lara secret erişimi sağlamamalıdır.

Runtime Retrieval

Runtime Retrieval application'ın ihtiyaç anında doğrudan secret manager API'sinden değer almasını sağlar. Kubernetes Secret resource oluşturmak zorunlu değildir. Workload identity Service Account veya cloud pod identity üzerinden sağlanabilir. API latency ve temporary outage için client side cache gerekir. Bu model application kodunda SDK entegrasyonu gerektirse de rotation ve refresh davranışı üzerinde daha fazla kontrol sunar.

Kubernetes ile HashiCorp Vault Entegrasyonu

Kubernetes ile HashiCorp Vault entegrasyonunda authentication ve secret delivery ayrı kararlar olarak ele alınmalıdır. Kubernetes Auth workload identity'yi doğrularken Agent Injector, CSI Provider, Secrets Operator veya direct API yöntemi secret'ın application'a nasıl ulaşacağını belirler. Application kodunu değiştirmek istemeyen ekip file based modelleri tercih edebilir. Dynamic secret kullanan uzun ömürlü pod'larda renewal ve refresh davranışı kritik hale gelir. Kubernetes ve CI/CD pipeline içinde Vault secret yönetimi nasıl yapılır sorusunun doğru cevabı tek tool değil, workload identity ile güvenli consumption pattern'in birlikte tasarlanmasıdır.

Kubernetes Auth Method

Kubernetes Auth Method pod'un Service Account token bilgisini Vault üzerinde doğrular. Vault role belirli namespace ve Service Account'ları uygun policy ile eşleştirir. Pod içine static Vault password veya token eklenmez. Audience ve role binding tanımları mümkün olduğunca dar tutulmalıdır. Birden fazla cluster aynı Vault'a bağlanıyorsa cluster identity ve Service Account isim çakışmaları authorization tasarımında dikkate alınmalıdır.

Vault Agent Injector

Vault Agent Injector pod'a ek container ve volume bileşenleri enjekte ederek secret retrieval sürecini application kodundan ayırabilir. Application Vault SDK kullanmadan file üzerinden secret okuyabilir. Agent authentication, token lifecycle, rendering ve bazı renewal işlemlerini yönetebilir. Legacy application'ları Vault'a taşımak için uygun bir geçiş modeli olabilir. Sidecar sayısının arttığı büyük cluster'larda resource kullanımı ve operational monitoring ayrıca değerlendirilmelidir.

Init Container

Init Container application başlamadan önce gerekli secret'ın hazır olmasını sağlayabilir. Secret file oluşturulduktan sonra ana application container başlatılır. Startup sırasında gereken ve sık değişmeyen credential'lar için basit pattern sunar. Uzun yaşayan pod içinde rotation gerekiyorsa yalnızca init container yeterli olmaz. Sidecar veya farklı refresh mekanizmasıyla application'ın yeni değeri alması sağlanmalıdır.

Sidecar

Sidecar Vault Agent application ile birlikte çalışmaya devam eder. Token renewal, dynamic secret refresh veya template update gibi işlemleri sürekli yönetebilir. File içeriği rotation sonrasında güncellenebilir. Application'ın dosya değişikliğini otomatik algılayıp yeni credential'a geçmesi gerekir. Resource request, security context ve health monitoring sidecar deployment standardının parçası olmalıdır.

Shared Memory Volume

Shared Memory Volume secret file'ını kalıcı disk yerine memory backed storage üzerinde tutmaya yardımcı olabilir. Vault Agent ve application aynı volume üzerinden değeri paylaşabilir. File permission yalnızca gerekli container'ların erişebileceği biçimde ayarlanmalıdır. Pod sona erdiğinde content'in kalıcı olarak saklanmaması güvenlik açısından avantaj sağlar. Buna rağmen application'ın secret'ı log veya crash dump içine yazmaması için code level güvenlik kuralları devam eder.

Vault CSI Provider

Vault CSI Provider secret değerini pod filesystem'ine volume olarak mount etmeyi sağlar. Application doğrudan Vault API entegrasyonu yapmadan file okuyabilir. Kubernetes Secret resource oluşturmadan external secret kullanmak mümkün olabilir. Rotation davranışı driver ve configuration özelliklerine göre test edilmelidir. Pod startup sırasında Vault erişilemezse application availability'nin nasıl etkileneceği deployment ve retry tasarımında dikkate alınmalıdır.

Vault Secrets Operator

Vault Secrets Operator Vault içindeki değerleri Kubernetes resource modeline senkronize etmek için kullanılabilir. Kubernetes native application'larda migration kolaylığı sağlayabilir. Secret Kubernetes Secret objesine yazılıyorsa etcd ve RBAC riskleri devam eder. Refresh interval rotation beklentisine uygun seçilmelidir. Operator identity yalnızca senkronize etmesi gereken Vault path ve namespace kaynaklarına erişebilmelidir.

Hangi Entegrasyon Modeli Seçilmeli?

Application kodunu değiştirmek istemiyorsanız Agent Injector veya CSI file mount uygun olabilir. Application secret lifecycle üzerinde doğrudan kontrol istiyorsa runtime API retrieval değerlendirilebilir. Kubernetes Secret bekleyen legacy workload için operator tabanlı sync daha kolay migration sağlayabilir. Dynamic secret ve sık rotation kullanılıyorsa refresh mekanizması seçimde temel kriter olmalıdır. Bütün organization için tek yöntem zorlamak yerine birkaç güvenli ve desteklenen standard pattern belirlemek daha iyi developer experience sağlar.

Amazon EKS ile AWS Secrets Manager Entegrasyonu

Amazon EKS üzerinde Secrets Manager secret'larını pod'lara ulaştırmak için AWS native identity ve Kubernetes storage entegrasyonları birlikte kullanılabilir. Secrets Store CSI Driver ve AWS Secrets and Configuration Provider secret'ı file olarak workload'a sunabilir. IRSA veya EKS Pod Identity static AWS access key ihtiyacını ortadan kaldırır. Rotation sonrasında dosya güncellense bile application'ın yeni değeri gerçekten kullanıp kullanmadığı test edilmelidir. Kubernetes Secret resource oluşturmadan external value tüketmek bazı threat model'lerde daha güvenli ve sade olabilir.

Secrets Store CSI Driver

Secrets Store CSI Driver external secret source'larından alınan değeri pod volume olarak mount eder. Kubernetes API içine plaintext secret kopyası oluşturmak zorunda kalmadan file based consumption sağlar. Provider bileşeni hangi external secret service ile konuşulacağını belirler. Rotation reconciler uygun configuration ile güncel version'ın mount edilmesine yardımcı olabilir. Application dosya değişikliğini yalnızca startup'ta değil runtime sırasında da algılayabilmelidir.

AWS Secrets and Configuration Provider

AWS Secrets and Configuration Provider EKS workload'larının Secrets Manager ve Parameter Store değerlerini CSI Driver üzerinden kullanmasını sağlar. Pod identity IAM policy ile yalnızca gerekli resource'lara sınırlandırılabilir. Secret file olarak container içine mount edilir. Application AWS SDK entegrasyonu yapmak zorunda kalmayabilir. Driver ve provider health pod startup için dependency olduğundan monitoring ve failure handling production architecture içinde ele alınmalıdır.

IRSA

IAM Roles for Service Accounts EKS Service Account'ını IAM Role ile ilişkilendirir. Pod static AWS access key taşımadan temporary credential alabilir. Role policy yalnızca gereken Secrets Manager resource'larına erişmelidir. Namespace ve Service Account kapsamları yanlış eşleştirilmemelidir. EKS Pod Identity ile birlikte mevcut architecture, operational model ve account structure değerlendirilerek en uygun yöntem seçilebilir.

EKS Pod Identity

EKS Pod Identity Kubernetes workload'larına AWS IAM yetkisi vermek için kullanılan pod odaklı identity modelidir. Static access key dağıtımı ihtiyacını ortadan kaldırır. Secrets Manager erişimi IAM Role policy üzerinden kontrol edilir. IRSA kullanan mevcut sistemlerle migration veya coexistence planı ihtiyaca göre yapılabilir. Temel hedef hangi yöntem seçilirse seçilsin application içine long lived AWS credential yerleştirmemektir.

Secret Rotation'ın Pod'lara Yansıtılması

Secrets Manager secret rotate olduğunda pod'un yeni değeri kullanması ayrıca doğrulanmalıdır. CSI rotation mekanizması mounted file içeriğini güncelleyebilir. Application dosyayı yalnızca startup sırasında okuyorsa yeni value aktif hale gelmeyebilir. Reload, reconnect veya controlled restart gerekebilir. Rotation testinde yalnızca AWS tarafındaki success status değil pod'un yeni credential ile gerçek target service bağlantısı da kontrol edilmelidir.

Kubernetes Secret Oluşturmadan Secret Kullanmak

CSI file mount external secret değerini Kubernetes Secret resource oluşturmadan application'a verebilir. Böylece etcd üzerinde ek secret kopyası oluşmaz. Access control workload IAM identity ve filesystem permission üzerinden şekillenir. Pod içindeki process yine file value'yu okuyabildiği için container security ve namespace isolation önemini korur. Threat model'e göre bu model Kubernetes Secret synchronization yaklaşımından daha uygun olabilir.

AWS Workload Credentials Provider Nedir?

AWS Workload Credentials Provider benzeri local secret provider modeli application'ın remote secret service'e her defasında doğrudan API çağrısı yapmak yerine local endpoint üzerinden credential veya secret tüketmesine yardımcı olabilir. Workload'un AWS identity'si arka planda kullanılarak ilgili secret alınır ve memory cache ile tekrar eden çağrılar azaltılabilir. Lambda, ECS, EKS ve EC2 gibi farklı execution modellerinde application integration pattern'ini sadeleştirebilir. Local retrieval latency avantajı sağlarken cache TTL ve rotation davranışı doğru tasarlanmalıdır. Böyle bir model IAM least privilege ve workload isolation ihtiyacını ortadan kaldırmaz, yalnızca secret consumption yolunu değiştirir.

Local Secret Provider Modeli

Local provider application ile remote secret service arasında yerel bir erişim katmanı oluşturur. Application localhost endpoint üzerinden secret ister ve provider arka planda AWS identity kullanarak remote retrieval yapar. Cache sayesinde her application call için dış API request oluşturmak gerekmez. Secret value'nun persistent disk üzerinde tutulmaması tercih edilir. Local endpoint yalnızca ilgili workload tarafından erişilebilir olacak biçimde process ve network isolation ile korunmalıdır.

Lambda Desteği

Lambda workload'larında local provider veya extension modeli tekrar eden Secrets Manager call sayısını azaltabilir. Execution Role yine gerekli GetSecretValue yetkisine sahip olmalıdır. In memory cache execution environment yaşadığı sürece kullanılabilir. Rotation sonrası cache TTL eski credential'ın ne kadar süre tutulacağını belirler. Hassas application'larda uzun cache süresi yerine kısa ve kontrollü refresh tercih edilmelidir.

ECS Desteği

ECS Task Role workload identity için doğal mekanizmadır. Local secret provider bu temporary identity üzerinden Secrets Manager'a erişebilir. Application içine static access key veya ayrı AWS credential koymaya gerek kalmaz. Provider lifecycle task ile uyumlu biçimde yönetilmelidir. Container network ve localhost endpoint erişimi aynı task içindeki gereksiz process'lere açık olmamalıdır.

EKS Desteği

EKS workload local provider modelini Pod Identity veya IRSA ile birleştirebilir. Application localhost üzerinden secret retrieval yaparken provider AWS IAM Role ile remote service'e erişir. File mount yerine request based consumption kullanılabilir. Cache ve rotation davranışı application'ın credential refresh ihtiyacına göre ayarlanmalıdır. CSI veya direct SDK modeline göre hangi yaklaşımın daha iyi olduğu code change ve latency gereksinimine bağlıdır.

EC2 Desteği

EC2 Instance Role temporary AWS credential sağlar. Local provider bu identity ile gerekli Secrets Manager secret'larını çekebilir. Application configuration içine AccessKeyId yazılmaz. Aynı instance üzerinde birden fazla application çalışıyorsa local provider endpoint erişiminin process bazında nasıl sınırlandırıldığı önemlidir. Instance Role yalnızca gerçekten ihtiyaç duyulan secret resource'larına izin vermelidir.

In-Memory Cache

In Memory Cache remote API call sayısını ve retrieval latency'yi azaltır. Secret process memory içinde belirli TTL boyunca tutulur. Process restart olduğunda value kalıcı olarak saklanmıyorsa disk leakage riski azalır. Çok uzun cache TTL rotation etkisini geciktirebilir. Security ile performance arasındaki denge secret risk sınıfı ve application request pattern üzerinden belirlenmelidir.

Secret Retrieval Latency

Remote secret retrieval network, authentication ve KMS işlemleri nedeniyle application latency'sine ek süre getirebilir. Her business request içinde secret manager çağrısı yapmak çoğu workload için gerekli değildir. Local cache P95 ve P99 response süresini azaltabilir. Secret startup, connection establishment veya belirli refresh interval'ında alınabilir. Latency metriği cache hit rate ve error rate ile birlikte izlenmelidir.

SSRF Koruması

Local credential endpoint'leri SSRF riskine karşı korunmalıdır. Application dışarıdan gelen URL veya request parametresini kontrolsüz biçimde localhost provider'a yönlendirmemelidir. Network namespace ve process isolation ek güvenlik sağlar. Provider endpoint'in authentication veya request validation özellikleri varsa production configuration'da etkinleştirilmelidir. SSRF testleri web application security testing sürecine dahil edilmelidir.

SDK ile Doğrudan Erişimden Farkı

SDK modelinde application kodu doğrudan Secrets Manager API ile konuşur. Local provider modelinde retrieval ve cache sorumluluğunun bir bölümü ayrı component'e taşınır. SDK daha fazla application kontrolü sunarken local provider farklı programlama dillerinde ortak consumption standardı sağlayabilir. Her iki modelde IAM Role ve least privilege aynı ölçüde önemlidir. Karar team standardı, latency, code ownership ve rotation gereksinimine göre verilmelidir.

CI/CD Pipeline'larında Secret Management

CI/CD Pipeline secret yönetiminde temel hedef deployment için gerekli erişimi long lived credential saklamadan sağlamaktır. OIDC federation GitHub Actions, GitLab ve benzeri sistemlerin AWS veya Vault'a kısa ömürlü identity ile bağlanmasına imkân verir. Pipeline logları hassas değeri göstermemeli ve debug ayarları production workflow'larında kontrollü kullanılmalıdır. Build time secret ile runtime secret birbirinden ayrılmalıdır. Production database password'un pipeline'a hiç verilmemesi mümkünse en güvenli çözüm application'ın deployment sonrasında kendi workload identity'siyle secret almasıdır.

GitHub Actions

GitHub Actions OIDC token kullanarak AWS IAM Role veya Vault JWT authentication üzerinden short lived access alabilir. Repository secret içinde long lived cloud access key tutmak zorunda kalmaz. Trust policy repository, branch, environment ve workflow claim'leriyle sınırlandırılmalıdır. Pull request kaynaklarının production role'a erişmesi engellenmelidir. Workflow command ve log output içinde secret value'nun yazılmaması için reusable güvenli pipeline template'leri oluşturulabilir.

GitLab CI/CD

GitLab CI/CD federated identity veya platformun protected variable özelliklerini kullanabilir. Tercih edilen model static credential yerine job süresince geçerli identity token kullanmaktır. Vault JWT authentication project ve branch claim'lerine göre policy eşleştirebilir. Protected branch ve environment kuralları production erişimini sınırlar. Runner security de secret management zincirinin parçasıdır çünkü compromise olmuş runner job sırasında erişilen credential'ları dışarı çıkarabilir.

Jenkins

Jenkins uzun süredir kullanılan enterprise ortamlarda çok sayıda static credential'ın merkezi store içinde birikmesine neden olabilir. Vault integration veya cloud workload identity kullanımı bu değerlerin sayısını azaltabilir. Shared agent workspace ve environment cleanup özellikle önemlidir. Pipeline step secret'ı command line veya console log içine yazmamalıdır. Controller ve plugin security düzenli olarak yönetilmelidir çünkü Jenkins compromise olduğunda geniş credential erişimi ele geçirilebilir.

AWS CodePipeline

AWS CodePipeline ve ilişkili build servisleri IAM Role ile AWS kaynaklarına erişebilir. Static AWS access key pipeline secret olarak saklanmamalıdır. Build sırasında gerçekten harici API key gerekiyorsa Secrets Manager veya Parameter Store üzerinden minimum yetkiyle alınabilir. Runtime application secret'ı artifact veya Docker image içine eklenmemelidir. Deployment tamamlandıktan sonra workload kendi identity'siyle production secret'ını almalıdır.

Pipeline'ın Vault'a Kimlik Doğrulaması

CI pipeline Vault'a long lived token ile değil mümkünse OIDC veya JWT ile authenticate olmalıdır. Vault role yalnızca ilgili repository ve environment için gereken policy'yi verir. Feature branch ile production deployment branch aynı secret erişimine sahip olmamalıdır. Token TTL tipik job süresine yakın tutulmalıdır. Pipeline tamamlandığında credential natural expiration ile kullanılmaz hale gelmelidir.

OIDC ile Passwordless CI/CD

OIDC federation CI platformunun oluşturduğu signed identity token'ını target platformun doğrulamasına dayanır. Static password veya cloud key repository içinde tutulmaz. Trust policy issuer, audience, project ve branch bilgisine göre daraltılabilir. Credential otomatik kısa ömürlü olduğu için manual rotation ihtiyacı azalır. Passwordless model yanlış authorization policy sorununu çözmediği için federation claim'leri mutlaka sıkı biçimde kontrol edilmelidir.

Build-Time Secret vs Runtime Secret

Build Time Secret dependency indirme veya private package repository erişimi gibi build sırasında gereken değerdir. Runtime Secret application çalışırken database veya API erişimi için kullanılır. Production runtime secret'ın build system'e verilmesi çoğu zaman gereksiz risk oluşturur. Artifact içine gömülen credential image registry veya cache üzerinden sızabilir. Application production ortamında kendi workload identity'siyle runtime secret almalıdır.

Secret'ların Log'lara Yazılmasının Önlenmesi

CI/CD logları geniş kullanıcı grubuna açık olabildiği için secret exposure açısından önemli risk noktasıdır. Shell trace, verbose HTTP client ve debug logging hassas değeri gösterebilir. Masking özelliği faydalı olsa da her encoding veya transformation durumunu yakalamayabilir. Script'ler secret value'yu hiçbir zaman bilerek console'a yazmamalıdır. Log access ve retention policy de secret security modelinin bir parçası olarak değerlendirilmelidir.

Short-Lived CI Credentials

Short Lived CI Credential pipeline başlangıcında üretilir ve job tamamlandıktan kısa süre sonra geçersiz hale gelir. Static deploy key veya cloud access key kullanımına göre çok daha küçük risk penceresi sağlar. Credential yalnızca gereken target environment ve resource scope'una sahip olmalıdır. TTL tipik pipeline süresinden gereksiz ölçüde uzun tutulmamalıdır. Job logunda token sızsa bile kısa süre sonra expire olması saldırganın kullanım fırsatını sınırlar.

GitOps ve Secret Management

GitOps repository'yi desired state kaynağı olarak kullanır, ancak bu production secret'ın plaintext olarak Git içine yazılması gerektiği anlamına gelmez. External secret manager veya encrypted manifest yöntemleri secret value'yu Git history'den uzak tutabilir. External Secrets Operator, SOPS ve Sealed Secrets farklı security ve operational modeller sunar. Vault ve AWS Secrets Manager GitOps deployment'ın external source of truth'u olarak kullanılabilir. Temel prensip production credential'ın hiçbir zaman plaintext commit olarak history'ye girmemesidir.

Git Repository İçinde Plaintext Secret Kullanılmaması

Git repository içindeki plaintext secret kopyalanır, fork edilir ve geçmiş commit'lerde uzun süre yaşamaya devam eder. Değer bir sonraki commit'te silinse bile history içinde bulunabilir. Bir sızıntı tespit edildiğinde credential hemen rotate edilmelidir. History cleanup ek temizlik sağlar, ancak security response'un ilk adımı değildir. Pre commit ve CI secret scanning gelecekte aynı hatanın tekrar edilmesini azaltır.

External Secrets Operator

External Secrets Operator Vault veya AWS Secrets Manager gibi harici source'lardan Kubernetes Secret üretmek için kullanılabilir. Operator workload identity üzerinden source store'a erişebilir. Refresh interval external secret rotation sıklığına göre ayarlanmalıdır. Değer Kubernetes Secret olarak sync ediliyorsa etcd ve RBAC riskleri devam eder. Operator policy yalnızca senkronize etmesi gereken path veya resource'larla sınırlandırılmalıdır.

SOPS

SOPS configuration dosyalarının belirli alanlarını encrypt ederek encrypted manifest'in Git içinde tutulmasını sağlar. Decryption key repository'den ayrı yönetilmelidir. KMS veya diğer supported key provider'lar ile merkezi key governance kurulabilir. Pull request içinde ciphertext görülür, plaintext secret görünmez. Key erişimi çok geniş verilirse encryption'ın sağladığı koruma azaldığı için decryption permission dikkatle yönetilmelidir.

Sealed Secrets

Sealed Secrets cluster tarafındaki controller'ın private key'iyle çözülebilecek encrypted manifest modeli sağlar. Developer public key kullanarak secret'ı seal eder ve encrypted resource Git'e eklenebilir. Private key cluster içinde korunur. Disaster recovery sırasında controller key backup stratejisi önemlidir. Multi cluster kullanımında hangi key'in hangi cluster'a ait olduğu ve migration süreci açık biçimde tasarlanmalıdır.

Vault Entegrasyonu

GitOps controller veya Kubernetes workload Vault'tan secret çekebilir. Repository yalnızca path referansı veya desired configuration tutar. Authentication workload identity üzerinden yapıldığında static Vault token Git içine girmez. Dynamic secret kullanıldığında credential value hiçbir zaman repository'de oluşmaz. Bu model Git desired state ile credential lifecycle sorumluluğunu güvenli biçimde birbirinden ayırır.

AWS Secrets Manager Entegrasyonu

AWS Secrets Manager EKS ve GitOps ortamlarında external secret source olarak kullanılabilir. Repository secret value yerine logical name veya ARN referansı tutabilir. Workload IAM Role üzerinden Secrets Manager'a erişir. Rotation sonrasında operator veya application yeni version'ı alır. Git history production credential'ın kendisini içermediği için incident response ve rotation süreçleri daha yönetilebilir hale gelir.

Pull-Based ve Push-Based Secret Distribution

Pull Based model workload veya controller'ın secret manager'dan değeri almasına dayanır. Push Based model merkezi system'in credential'ı target environment'a yazmasıdır. Pull model workload identity ve least privilege ile daha doğal biçimde çalışabilir. Push model merkezi automation'a çok sayıda target'a write yetkisi verdiği için blast radius'u büyütebilir. Hangi model seçilirse seçilsin failure, rotation ve audit davranışı önceden belirlenmelidir.

Infrastructure as Code ile Secret Yönetimi

Infrastructure as Code secret metadata, access policy, KMS key ve integration resource'larını tekrar edilebilir biçimde yönetmek için çok değerlidir. Bununla birlikte gerçek secret value'yu Terraform veya CloudFormation template içine yazmak güvenli değildir. Değer state, deployment history veya pipeline loglarında kalabilir. En iyi yaklaşım secret container ve policy'yi IaC ile oluşturup secret value lifecycle'ını ayrı güvenli kanalda yönetmektir. Policy as Code access değişikliklerini review ve automated validation sürecine taşıyarak security governance seviyesini artırır.

Terraform

Terraform Vault, AWS ve Kubernetes secret infrastructure kaynaklarını yönetebilir. Secret value bir resource argument olarak kullanılırsa state dosyasına yazılabilir. Sensitive flag terminal output'u maskeleyebilir, ancak state security problemini tamamen çözmez. IaC ile metadata, access policy ve rotation configuration yönetmek daha güvenlidir. Remote state backend encryption ve minimum IAM permission production standardının temel parçasıdır.

CloudFormation

CloudFormation Secrets Manager resource, IAM Role ve rotation configuration gibi AWS kaynaklarını kod olarak tanımlayabilir. Template içine plaintext credential eklenmemelidir. Dynamic reference veya runtime retrieval pattern kullanılarak secret value deployment history'den uzak tutulabilir. Stack role yalnızca gereken infrastructure permission'lara sahip olmalıdır. Change Set production öncesinde access policy ve secret lifecycle değişikliklerini incelemek için kullanılabilir.

Secret Değeri ile Secret Metadata'sını Ayırmak

Secret Metadata isim, owner, tag, environment, rotation schedule ve access policy gibi bilgileri içerir. Bu verilerin IaC içinde version control altında tutulması operasyonel şeffaflık sağlar. Gerçek secret value ise farklı güvenlik yaşam döngüsüne sahiptir. Böylece code review sırasında credential görünmez. Metadata ve value ayrımı governance ile confidentiality arasında daha temiz boundary oluşturur.

Terraform State Riski

Terraform State infrastructure resource değerlerini içerdiği için bazı hassas bilgiler burada plaintext biçimde bulunabilir. State file yüksek hassasiyetli asset olarak korunmalıdır. Remote backend encryption, restricted IAM access ve audit logging kullanılmalıdır. Developer bilgisayarlarına gereksiz state download yapılmamalıdır. Secret value kullanımını IaC'den uzaklaştırmak state exposure riskini önemli ölçüde azaltır.

Secret Value'yu IaC Koduna Yazmamak

IaC repository içine hard coded password veya API key yazılmamalıdır. Variable file kullanmak dosya Git'e giriyorsa problemi çözmez. CI variable üzerinden Terraform'a verilen secret'ın state'e yazılma ihtimali de ayrıca kontrol edilmelidir. En güvenli model secret resource oluşturulduktan sonra application'ın runtime'da değeri secret manager'dan almasıdır. Bootstrap credential zorunluysa tek kullanımlık veya kısa ömürlü provisioning workflow tasarlanmalıdır.

Policy-as-Code

Policy as Code IAM ve Vault authorization kurallarını version control ve code review sürecine taşır. Her access değişikliği pull request üzerinden incelenebilir. Automated test geniş wildcard veya riskli capability kullanımını engelleyebilir. Production deployment öncesinde policy lint ve security validation uygulanabilir. Bu yaklaşım manual console değişikliklerinden kaynaklanan configuration drift sorununu azaltır.

Secret Caching Nasıl Tasarlanmalıdır?

Secret caching performans, availability ve API maliyeti açısından faydalıdır, ancak rotation etkisini doğrudan değiştirdiği için dikkatle tasarlanmalıdır. Her business request'te remote secret manager çağrısı yapmak çoğu system için gereksizdir. Buna karşılık secret'ı process ömrü boyunca süresiz cache'lemek yeni credential'ın application'a ulaşmasını geciktirir. Cache TTL secret risk seviyesi ve rotation interval ile uyumlu olmalıdır. Authentication failure alındığında application TTL'nin bitmesini beklemek yerine cache invalidate edip güncel credential'ı tekrar istemelidir.

Her İstekte Secret Manager Çağrısı Yapmak

Her application request için remote secret manager call yapmak network latency ve API request sayısını artırır. Secret platform geçici olarak yavaşladığında business application da doğrudan etkilenir. Credential çoğu kullanımda her request başına değişmez. Bu nedenle controlled local cache daha verimli olabilir. Kritik erişimlerde bile retrieval frequency gerçek threat model ve rotation ihtiyacına göre belirlenmelidir.

Client-Side Caching

Client Side Caching secret value'nun application process içinde belirli süre tutulmasını sağlar. Remote API çağrıları azalır ve latency düşer. Value mümkünse yalnızca memory içinde kalmalıdır. TTL sona erdiğinde yeni secret alınır. Rotation event'i application tarafından biliniyorsa süreyi beklemeden cache invalidation yapılması daha hızlı geçiş sağlar.

In-Memory Cache

In Memory Cache secret'ı process memory içinde geçici olarak saklar. Process restart olduğunda cache natural olarak temizlenir. Memory dump ve debug tool'ların hassas veriyi gösterebileceği unutulmamalıdır. Secret'ın gereksiz kopyaları farklı object ve log yapılarına yayılmamalıdır. Multi tenant host veya container environment'ında process isolation cache güvenliğinin önemli parçasıdır.

Cache TTL

Cache TTL secret'ın remote source'tan tekrar alınmadan önce ne kadar süre tutulacağını belirler. TTL rotation interval'dan uzun olursa application eski credential'ı kullanmaya devam edebilir. Çok kısa TTL ise API request ve latency maliyetini artırır. Authentication error durumunda emergency refresh yapılması iyi practice'tir. Risk sınıfı farklı secret'lar için farklı TTL uygulanabilir.

Rotation ve Cache Invalidation

Rotation tamamlandığında application'ın eski value'yu cache'ten ne zaman kaldıracağı belirlenmelidir. Event based invalidation mümkünse hızlı geçiş sağlar. Alternatif olarak kısa TTL ve authentication failure retry modeli kullanılabilir. Database connection pool memory cache dışında eski credential ile kurulmuş active connection'ları da barındırabilir. Bu nedenle rotation sonrası invalidation sadece secret object değil connection lifecycle açısından da test edilmelidir.

Security vs Latency Dengesi

Sık remote retrieval credential'ın güncel kalmasını sağlar, ancak application latency'sini artırabilir. Uzun cache süresi performansı iyileştirirken revocation etkisini geciktirir. Database admin credential ile düşük yetkili third party API key aynı policy'ye sahip olmak zorunda değildir. P95 ve P99 retrieval latency ölçümleri caching kararını gerçek data ile destekler. Security hedefi ile application SLO birlikte değerlendirilmelidir.

Security vs API Cost Dengesi

Managed secret service API request'leri toplam maliyeti etkileyebilir. Yüksek trafik alan service her user request'inde secret retrieval yaparsa gereksiz call hacmi oluşur. Client side cache bu maliyeti ciddi biçimde azaltır. Yalnızca tasarruf için çok uzun TTL seçmek rotation ve incident response hızını düşürür. Cache hit rate, secret age ve Mean Time to Revoke birlikte izlendiğinde daha sağlıklı denge kurulabilir.

Secret Rotation Uygulamaları Nasıl Etkiler?

Secret Rotation platform tarafında başarılı görünse bile application eski credential'ı memory, environment veya connection pool içinde kullanmaya devam edebilir. Bu durum aralıklı authentication error ve zor teşhis edilen production problemine dönüşür. Sağlıklı rotation yeni credential oluşturma, doğrulama, dağıtma, application'ın geçişini sağlama ve eski credential'ı revoke etme sırasını açık biçimde tanımlar. Retry ve grace period application behavior'ın önemli parçalarıdır. Rotation testine security ekibinin yanında application developer ve database ekiplerinin de katılması gerekir.

Connection Pool Problemi

Database Connection Pool uzun yaşayan bağlantıları yeniden kullanır. Password rotate edildiğinde existing connection çalışmaya devam ederken new connection eski credential ile fail olabilir. Bu durum application'ın yalnızca bazı request'lerinde hata oluşmasına neden olabilir. Pool'un credential refresh ve reconnect davranışı açıkça anlaşılmalıdır. Rotation testi sırasında hem existing hem de new connection senaryosu ayrı ayrı doğrulanmalıdır.

Eski Credential ile Açık Bağlantılar

Bazı database sistemleri password değiştiğinde mevcut session'ları hemen kapatmaz. Bu özellik normal rotation sırasında zero downtime geçişi kolaylaştırabilir. Ancak credential compromise olmuşsa attacker'ın açtığı session'ın da devam edebileceği unutulmamalıdır. Emergency incident durumunda active session revocation ayrıca gerekebilir. Normal scheduled rotation ile security incident rotation bu nedenle farklı runbook'lara sahip olabilir.

Yeni Credential'ın Dağıtılması

Yeni credential target system üzerinde aktif hale geldiğinde bütün consumer application'ların değeri alması gerekir. File mount, cache refresh veya runtime API retrieval modeline göre dağıtım yöntemi değişir. Push model kullanılıyorsa bütün target'ların başarıyla update edildiği doğrulanmalıdır. Pull modelde application refresh interval izlenmelidir. Dağıtım tamamlanmadan eski credential'ın kapatılması outage oluşturabilir.

Retry Stratejisi

Authentication failure oluştuğunda application sonsuz biçimde aynı eski credential ile retry yapmamalıdır. İlk veya belirli sayıda failure sonrasında cache invalidate edilip güncel secret alınabilir. Exponential backoff target service üzerinde ek yük oluşmasını engeller. Maksimum retry sayısı ve fallback behavior açıkça tanımlanmalıdır. Rotation kaynaklı beklenen failure ile gerçek security problem monitoring açısından birbirinden ayrılmalıdır.

Grace Period

Grace Period eski ve yeni credential'ın kısa süre birlikte geçerli olduğu transition window'dur. Dağıtık system'lerde bütün instance'ların aynı saniyede refresh yapamaması problemini azaltır. Çok uzun grace period eski credential'ın security riskini uzatır. Çok kısa pencere yavaş refresh yapan workload'larda outage oluşturur. Gerçek application deployment ve cache süreleri ölçülerek uygun değer belirlenmelidir.

Alternating User Pattern

Alternating User Pattern iki database kullanıcısını dönüşümlü kullanarak controlled rotation sağlar. Pasif user credential'ı değiştirilip test edilir. Başarılı test sonrasında application yeni user'a geçirilir. Önceki kullanıcı grace period sonrası disable veya rotate edilir. Bu yöntem özellikle connection pool ve zero downtime gereksinimi bulunan application'larda güçlü olabilir.

Zero-Downtime Rotation Testi

Zero Downtime Rotation Test production'a benzer concurrent traffic altında yapılmalıdır. Rotation çalışırken existing ve new connection davranışı izlenmelidir. Authentication error rate, latency ve connection pool metric'leri takip edilmelidir. Eski credential ile yeni session açılamadığı ayrıca doğrulanmalıdır. Başarılı test yalnızca rotation service'in success sonucu değil application SLO'nun bozulmadan kalmasıdır.

Secret Management ve Zero Trust

Zero Trust hiçbir network konumunu veya workload'u varsayılan olarak güvenilir kabul etmeme yaklaşımıdır. Secret management bu modelde identity based access, least privilege ve short lived credential ile önemli rol oynar. Application private subnet içinde çalışıyor diye bütün production secret'larına erişmemelidir. Her workload kendi identity'siyle authenticate olmalı ve yalnızca ihtiyacı kadar authorization almalıdır. Dynamic credential ve just in time access blast radius alanını daraltarak network perimeter'a tek başına güvenme ihtiyacını azaltır.

Identity-Based Access

Identity Based Access secret erişimini IP adresi veya subnet yerine doğrulanmış user veya workload identity'ye bağlar. IAM Role, Kubernetes Service Account ve OIDC token bu modele örnektir. Identity metadata authorization kararında kullanılabilir. Aynı network içindeki iki application farklı secret yetkilerine sahip olabilir. Workload lifecycle bittiğinde identity ve access'in de kapanması stale credential riskini azaltır.

Least Privilege

Least Privilege Zero Trust modelinin temel prensiplerinden biridir. Her workload yalnızca kendi görevini yapmak için gereken secret'a erişir. Runtime role management permission taşımaz. Unused read, list veya write izinleri kaldırılır. Policy review ve automated validation bu prensibin zaman içinde bozulmasını önler.

Short-Lived Credentials

Short Lived Credentials kalıcı güven varsayımını azaltır. Workload belirli süre için access alır ve süre sonunda yeniden authenticate olur. Credential ele geçirilirse saldırganın kullanım süresi sınırlı kalır. Dynamic secrets ve cloud temporary token bu modele uygundur. Scope ve TTL birlikte dar tutulduğunda security etkisi daha güçlü olur.

Just-in-Time Access

Just in Time Access yetkinin yalnızca gerçek ihtiyaç oluştuğunda verilmesini hedefler. İnsan admin erişiminde approval workflow kullanılabilir. Machine workload'larda dynamic secret veya temporary role credential benzer yaklaşım sağlar. Süresiz standing privilege azalır. Audit record access'in kim tarafından, ne zaman ve hangi amaçla alındığını göstermelidir.

Continuous Authentication

Continuous Authentication tek login sonrasında sonsuz güvenmek yerine identity ve session'ın belirli aralıklarla yeniden değerlendirilmesini hedefler. Short lived token ve renewal bu modelin uygulama araçlarıdır. Workload identity değişirse eski access devam etmemelidir. Risk signal oluştuğunda token revoke edilebilir. Böylece security yalnızca başlangıç authentication event'ine bağlı kalmaz.

Blast Radius'ın Azaltılması

Blast Radius bir credential compromise olduğunda saldırganın erişebileceği toplam alanı ifade eder. Tek shared admin password yüzlerce application için kullanılıyorsa etki alanı çok büyüktür. Her workload'a ayrı ve dar yetkili credential vermek riski küçültür. Short TTL saldırganın kullanım süresini de sınırlar. Incident response sırasında hangi credential'ın hangi downstream resource'lara erişebildiğinin hızla görülebilmesi bu nedenle çok önemlidir.

Secret Management Güvenlik Tehditleri

Secret manager kullanmak credential risklerini otomatik olarak ortadan kaldırmaz. Yanlış IAM policy, compromised workload, stale secret, log leakage ve supply chain saldırıları yine hassas değerlere erişim sağlayabilir. Merkezi secret platformu yüksek değerli hedef olduğu için authentication, authorization ve audit kontrolleri daha güçlü olmalıdır. Secret value kadar secret'a erişen application ve pipeline da korunmalıdır. Güvenlik değerlendirmesi platform, identity, network, application code ve insan operasyonlarını tek threat model içinde ele almalıdır.

Credential Theft

Credential Theft password, token veya key'in yetkisiz kişi tarafından ele geçirilmesidir. Repository, log, developer laptop, memory dump veya compromised CI runner yaygın kaynaklardır. Short TTL ve narrow scope hırsızlığın etkisini azaltabilir. Secret scanning erken detection sağlar. Ele geçirilen credential'ın hızlı revoke edilmesi olay yönetiminin en önemli performans göstergelerinden biridir.

Secret Exfiltration

Secret Exfiltration yetkili access yolunun kötüye kullanılarak hassas değerin güvenli boundary dışına çıkarılmasıdır. Compromised application kendi policy'siyle okuyabildiği secret'ları dışarı gönderebilir. Secret manager bu durumda teknik olarak normal authorized request görebilir. Minimum permission ve egress control ek savunma sağlar. Runtime behavior monitoring olağandışı retrieval veya data transfer pattern'lerini tespit etmeye yardımcı olabilir.

Privilege Escalation

Privilege Escalation saldırganın mevcut düşük yetkiden daha yüksek permission seviyesine geçmesini ifade eder. Vault policy management veya IAM privilege değişikliği bu açıdan kritik alandır. Runtime application policy create veya permission grant yetkisine sahip olmamalıdır. Privileged management identity MFA ve güçlü approval kurallarıyla korunmalıdır. Authorization değişiklikleri SIEM üzerinde high severity event olarak izlenmelidir.

Over-Permissioned Application

Over Permissioned Application ihtiyacından fazla secret veya resource okuyabilen workload'dur. Application compromise olduğunda attacker aynı geniş yetkiyi kullanabilir. Wildcard policy blast radius'u ciddi biçimde büyütür. Secret inventory hangi workload'un hangi credential'a gerçekten ihtiyaç duyduğunu göstermelidir. Kullanılmayan permission'lar düzenli access review ile kaldırılmalıdır.

Stale Secret

Stale Secret uzun süredir rotate edilmemiş veya artık aktif kullanımı bilinmeyen credential'dır. Target system üzerinde hâlâ geçerli olabilir. Last accessed ve last rotated metadata risk önceliklendirmesine yardımcı olur. Kullanılmayan credential owner onayıyla revoke edilmelidir. Stale secret sayısı kurumsal secret hygiene KPI'ı olarak düzenli takip edilebilir.

Orphan Secret

Orphan Secret aktif owner veya consumer'ı olmayan credential'dır. Proje kapatıldıktan sonra secret manager kaydı ve target account açık kalmış olabilir. Ownership metadata bu tür değerleri daha erken tespit etmeye yardımcı olur. Last accessed bilgisi uzun süredir kullanılmayan secret'ları bulmak için kullanılabilir. Deletion süreci hem secret store kaydını hem downstream credential'ı kapatmalıdır.

Secret Sprawl

Secret Sprawl aynı credential'ın CI variable, Kubernetes Secret, config file ve local developer environment gibi birçok yerde kopyalanmasıdır. Rotation sırasında bütün kopyaları güncellemek zorlaşır. Bir kopya unutulduğunda application outage veya security exposure oluşabilir. Merkezi source of truth ve runtime retrieval kopya sayısını azaltır. Inventory yalnızca secret manager içindeki resource'ları değil dağıtım noktalarını da mümkün olduğunca göstermelidir.

Insider Threat

Insider Threat yetkili kullanıcının erişimini kötüye kullanması riskidir. Privileged operation shared account yerine kişisel enterprise identity ile yapılmalıdır. MFA ve approval workflow yüksek riskli access'i kontrol eder. Audit logları identity bazlı olmalıdır. Separation of Duties tek kişinin policy değiştirme, secret okuma ve audit loglarını yönetme yetkisini aynı anda taşımasını engelleyebilir.

Supply-Chain Attack

Supply Chain Attack build tool, dependency, package veya CI plugin üzerinden credential sızdırabilir. Build ortamına yalnızca gerçekten gereken short lived secret verilmelidir. Runtime production secret'ların CI pipeline'a hiç girmemesi güçlü korumadır. Third party action ve plugin version'ları kontrollü ve mümkünse pin edilmiş biçimde kullanılmalıdır. Software supply chain security secret management politikasının ayrı değil tamamlayıcı parçasıdır.

Secret Sızıntısı Olursa Ne Yapılmalı?

Secret sızıntısı tespit edildiğinde ilk hedef credential'ın kötüye kullanılabileceği süreyi mümkün olduğunca hızlı kapatmaktır. Önce revoke veya disable işlemi yapılmalı ve ardından yeni credential üretilmelidir. Repository'den değeri silmek tek başına güvenlik önlemi değildir. Audit logları, application access ve downstream authorization incelenerek blast radius belirlenmelidir. Olay sonrasında root cause analizi yapılıp aynı sızıntı kanalının başka secret'larda bulunup bulunmadığı kurum genelinde kontrol edilmelidir.

Secret'ı Derhal Revoke Etmek

Sızmış credential artık güvenilir kabul edilmemelidir. Kullanıldığı production workload bulunsa bile revocation gereksiz yere geciktirilmemelidir. Zero downtime emergency transition planı bu durumda devreye girmelidir. Dynamic secret lease üzerinden hızlı revoke edilebilir. Static credential için target system üzerinde password veya key hemen değiştirilmeli ve eski değerin gerçekten geçersiz olduğu doğrulanmalıdır.

Yeni Credential Üretmek

Eski credential kapatıldıktan sonra yeni value güvenilir source tarafından üretilmelidir. Önceki secret ile tahmin edilebilir ilişki taşımamalıdır. Application refresh veya deployment mekanizması yeni credential'ı almalıdır. Yeni değerin ticket, chat veya log içine kopyalanmaması gerekir. Olay sonrasında automated rotation süreci yoksa uzun vadeli improvement olarak planlanmalıdır.

İlgili Access Token'ları İptal Etmek

Sızan password veya key başka access token üretmek için kullanıldıysa yalnızca ana credential'ı değiştirmek yeterli olmayabilir. Aktif session, OAuth token veya cloud session ayrıca revoke edilmelidir. Audit logları hangi token'ların üretildiğini göstermeye yardımcı olabilir. Downstream credential dependency önceden inventory içinde tutulursa response süresi kısalır. Incident checklist bu ikinci seviye revocation adımını açık biçimde içermelidir.

Audit Log Analizi

Audit Log Analizi secret'ın hangi identity tarafından, ne zaman ve hangi source'tan kullanıldığını belirlemeye yardımcı olur. Vault Audit, CloudTrail, database audit ve application logları birlikte incelenebilir. Sistemlerin zaman senkronizasyonu olay timeline'ının doğru çıkarılmasını sağlar. Beklenen workload access ile bilinmeyen source request'leri ayrıştırılmalıdır. Log retention geç tespit edilen incident'ları inceleyebilecek kadar uzun tutulmalıdır.

Blast Radius Analizi

Blast Radius Analizi ele geçirilen credential'ın hangi resource ve operation'lara erişebildiğini belirler. IAM veya Vault policy bu analizin başlangıç noktasıdır. Credential başka secret üretme veya permission değiştirme yetkisine sahipse etki alanı genişler. Network access ve target system privilege birlikte değerlendirilmelidir. Sonuç hangi downstream credential'ların rotate edilmesi gerektiğini ve incident severity seviyesini belirler.

Git History Temizliği

Secret Git repository'ye girdiyse credential rotate edildikten sonra history temizliği yapılabilir. Amaç artık geçersiz olan değerin gereksiz kopyalarını azaltmaktır. Rewrite işlemi developer laptop'larındaki mevcut clone'ları otomatik olarak temizlemez. Bu nedenle security açısından ilk adım her zaman revocation'dır. Pre commit ve CI scanning aynı problemin gelecekte tekrar oluşmasını engellemeye yardımcı olur.

Downstream Credential Rotation

Sızan secret başka credential veya system access'i elde etmek için kullanıldıysa downstream değerler de risk altında olabilir. Örneğin CI token Vault'tan database credential okuyabiliyorsa database secret da rotate edilmelidir. Dependency graph incident response hızını artırır. Rotation sırası application availability dikkate alınarak planlanmalıdır. Bütün affected identity ve token'ların kapatıldığı audit üzerinden doğrulanmalıdır.

Root-Cause Analysis

Root Cause Analysis yalnızca secret'ı yanlış commit eden kişiyi bulmak değildir. Neden scanner bulunmadığı, production credential'ın developer ortamına neden ulaştığı ve hızlı revoke mekanizmasının neden olmadığı da incelenmelidir. Process ve architecture seviyesinde kalıcı iyileştirme yapılmalıdır. Aynı kontrol eksikliği başka repository veya application'larda da aranmalıdır. Başarılı analiz gelecekte benzer incident'ın oluşma ihtimalini kurum genelinde azaltır.

Incident Postmortem

Incident Postmortem olay timeline'ını, etkiyi, response adımlarını ve kalıcı aksiyonları belgeler. Amaç kişi suçlamak değil sistem ve süreç eksikliklerini görünür hale getirmektir. Mean Time to Detect ve Mean Time to Revoke gibi metric'ler ölçülebilir. Her improvement action için owner belirlenmelidir. Benzer secret sınıflarında proactive scanning ve rotation yapılarak olaydan elde edilen öğrenim daha geniş alana uygulanmalıdır.

Secret Scanning ile Secret Management Arasındaki Fark

Secret Scanning repository, file veya CI output içinde yanlışlıkla bulunan credential'ları tespit etmeye odaklanır. Secret Management ise credential'ın creation, storage, distribution, access, rotation ve revocation yaşam döngüsünü yönetir. Bu iki kontrol birbirinin yerine geçmez. Scanner sızıntıyı bulabilir, ancak target system üzerinde credential'ı otomatik kapatmak ayrı workflow gerektirir. En güçlü model detection sonucunu revoke ve rotate automation ile birleştirerek insan müdahalesine bağımlı süreyi azaltmaktır.

Secret Scanning Nedir?

Secret Scanning code ve repository içindeki API key, token veya password pattern'lerini tespit eden güvenlik kontrolüdür. Known provider credential formatları yüksek doğrulukla bulunabilir. Generic password pattern'lerinde false positive oranı daha yüksek olabilir. Scanner current code yanında Git history üzerinde de çalışabilir. Aktif credential bulunduğunda değer compromise olmuş kabul edilip revoke ve rotate işlemi başlatılmalıdır.

Pre-Commit Scanning

Pre Commit Scanning secret repository'ye ulaşmadan developer workstation üzerinde kontrol sağlar. Hızlı feedback geliştiricinin hatayı commit anında düzeltmesine yardımcı olur. Local hook kullanıcı tarafından devre dışı bırakılabileceği için tek güvenlik katmanı olarak görülmemelidir. Server side CI scanning ile desteklenmelidir. Rule set düzenli güncellenerek yeni provider credential pattern'leri yakalanmalıdır.

Repository Scanning

Repository Scanning mevcut branch ve history içinde secret pattern arar. Legacy project'lerde yıllardır unutulmuş credential'lar bulunabilir. Her finding'in halen aktif olup olmadığı güvenli biçimde doğrulanmalıdır. Validation sırasında secret'ın yeni log veya ticket kopyaları oluşturulmamalıdır. Aktif değerler risk seviyesine göre hızlı rotation sürecine alınmalıdır.

CI Pipeline Scanning

CI Pipeline Scanning her pull request veya merge sırasında merkezi secret kontrolü sağlar. Local pre commit kontrolü atlanmış olsa bile organization policy uygulanabilir. High confidence credential finding build'i durdurabilir. Scanner output secret'ın tamamını console'a yazmamalıdır. False positive allowlist süreli ve review edilmiş biçimde yönetilmelidir.

Detection Secret Management'ın Yerini Alır mı?

Detection yalnızca secret'ın yanlış yerde bulunduğunu gösterebilir. Credential'ı güvenli üretmek, saklamak, application'a ulaştırmak ve rotate etmek için secret management gerekir. Scanner kullanıp bütün production password'ları config file içinde tutmak güvenli architecture değildir. Aynı şekilde secret manager kullanıp repository scanning yapmamak developer hatalarını görünmez bırakır. İki kontrol birlikte kullanıldığında prevention ve response kapsamı güçlenir.

Detect + Revoke + Rotate Workflow

Detect Revoke Rotate Workflow secret scanning bulgusunu automated incident response ile birleştirir. Scanner geçerli credential tespit ettiğinde güvenlik sistemi ilgili provider veya secret owner'a event gönderir. Eski credential revoke edilir, yenisi üretilir ve application güncel value'ya geçirilir. Repository history temizliği sonrasında yapılabilir. Bu automation Mean Time to Revoke değerini ciddi biçimde azaltarak saldırganın erişim penceresini küçültür.

Audit ve Observability

Secret platformunun güvenli olduğunu söylemek için sadece access policy tanımlamak yeterli değildir. Kim, hangi secret'a, ne zaman ve hangi workload üzerinden erişti soruları cevaplanabilmelidir. Rotation failure, expiration, policy denial ve failed authentication event'leri merkezi monitoring altında tutulmalıdır. Audit logları SIEM'e aktarılırken secret value'nun kendisi gönderilmemelidir. Observability security metric'lerinin yanında latency, availability ve error rate gibi platform sağlığı göstergelerini de kapsamalıdır.

Kim Hangi Secret'a Erişti?

Audit record erişim yapan user veya workload identity'yi açık biçimde göstermelidir. Shared account kullanımı bu görünürlüğü ciddi biçimde azaltır. Her application kendi machine identity'sine sahip olmalıdır. Target secret path veya ARN loglarda görülebilir. Secret value ise audit sistemine plaintext olarak yazılmamalıdır.

Ne Zaman Erişti?

Timestamp incident timeline oluşturmak için kritik veridir. Bütün system ve log collector güvenilir time synchronization kullanmalıdır. Rotation öncesi ve sonrası access event'leri karşılaştırılabilir. Mesai dışındaki high privilege human access ayrı alarm oluşturabilir. Retention süresi compliance ve threat detection ihtiyaçlarına göre belirlenmelidir.

Hangi Workload Erişti?

Modern environment'larda machine identity sayısı insan kullanıcı sayısından çok daha fazladır. Pod, Lambda function, ECS task veya VM identity'sinin audit içinde görünmesi gerekir. Aynı application'ın farklı instance'ları gerektiğinde ayırt edilebilir. Dynamic credential bu ilişkiyi daha güçlü hale getirebilir. SIEM workload metadata ile access event'lerini enrich ederek daha iyi anomaly detection yapabilir.

Başarısız Access Denemeleri

Failed access attempt yanlış policy, application bug veya malicious behavior işareti olabilir. Tek bir denial normal deployment hatası olabilirken kısa sürede yüzlerce farklı secret'a erişim denemesi security alarmı gerektirebilir. Source identity ve target resource birlikte analiz edilmelidir. Deployment sırasında beklenen error pattern baseline olarak tanımlanabilir. Threshold ve anomaly based detection birlikte kullanıldığında daha güvenilir monitoring elde edilir.

Rotation Failure

Rotation Failure credential'ın beklenenden daha uzun süre aktif kalmasına neden olabilir. Hata sadece log içine yazılmamalı ve alert üretmelidir. Target database connectivity, Lambda permission veya validation error farklı kategori olarak izlenebilir. Otomatik retry sınırlı ve kontrollü olmalıdır. Belirli süre çözülmeyen failure on call veya secret owner ekibine escalation oluşturmalıdır.

Secret Expiration

Expiration yaklaşan certificate, token veya credential önceden görünür olmalıdır. Expired certificate veya service account key production outage'ın yaygın nedenlerinden biridir. Monitoring belirli gün veya saat kala uyarı üretebilir. Dynamic secret normal expiration öncesinde renewal veya reissue yapabilir. Manual credential için owner metadata alert'in doğru ekibe gitmesini sağlar.

Policy Denial

Policy Denial workload'un izin verilmeyen resource'a erişmeye çalıştığını gösterir. Yeni deployment sırasında yanlış path configuration nedeniyle oluşabilir. Aynı identity farklı sensitive secret'ları sürekli deniyorsa malicious behavior ihtimali değerlendirilmelidir. Denial logları merkezi security analysis için saklanmalıdır. Alarm gürültüsünü azaltmak için bilinen configuration problemleri hızlı biçimde düzeltilmelidir.

SIEM Entegrasyonu

SIEM Vault Audit, CloudTrail, application ve database loglarını tek timeline üzerinde ilişkilendirebilir. Secret access ile identity login ve network event'leri birlikte analiz edilebilir. High value secret access daha yüksek risk score alabilir. Detection rule yalnızca text pattern yerine identity, time ve environment context kullanmalıdır. Log pipeline hassas secret value taşımadığından emin olacak biçimde test edilmelidir.

HashiCorp Vault Audit Logging

HashiCorp Vault Audit Logging production secret platformunda temel güvenlik kontrolüdür. En az bir audit device etkin olmalı ve kritik yapılarda birden fazla bağımsız hedef değerlendirilmelidir. Audit kaydı request identity, path ve operation bilgisi sağlayarak incident investigation'ı destekler. Hassas alanlar koruyucu biçimde loglanır, ancak audit destination yine yüksek güvenlikli sistem olarak korunmalıdır. Audit pipeline failure normal log sorunu değil security ve availability problemi olarak ele alınmalıdır.

Audit Device Nedir?

Audit Device Vault event'lerinin gönderildiği logging hedefidir. File, syslog veya socket gibi farklı modeller kullanılabilir. Birden fazla device aynı anda etkinleştirilebilir. Hedef seçimi organization'ın log collection ve SIEM architecture'ına göre yapılmalıdır. Audit destination erişimi yalnızca gerekli security ve logging identity'leriyle sınırlandırılmalıdır.

File Audit Device

File Audit Device event'leri belirlenen local file içine yazar. Log agent bu file'ı okuyarak merkezi platforma gönderebilir. Disk dolması veya file permission problemi monitoring altında tutulmalıdır. Log rotation audit kaybına neden olmayacak biçimde planlanmalıdır. File content sensitive metadata barındırabileceği için OS level access restriction uygulanmalıdır.

Syslog

Syslog mevcut enterprise logging altyapısıyla kolay integration sağlayabilir. Vault event'leri merkezi collector'a iletilebilir. Network failure veya collector outage sırasında davranış test edilmelidir. Mümkünse encrypted transport kullanılmalıdır. Central syslog compromise olduğunda audit integrity'nin nasıl korunacağı ayrıca security architecture içinde değerlendirilmelidir.

Socket

Socket Audit Device event'leri socket üzerinden başka process veya collector'a iletebilir. Custom log processor veya security integration için kullanılabilir. Consumer process'in yavaşlaması backpressure oluşturabileceği için performance monitoring gerekir. Socket permission yalnızca ilgili collector tarafından erişilebilir olmalıdır. Failure testleri production öncesinde kontrollü biçimde gerçekleştirilmelidir.

Hassas Değerlerin Hash'lenmesi

Vault audit system hassas alanları doğrudan plaintext kaydetmek yerine koruyucu transformation uygulayabilir. Bu yaklaşım log sisteminin ikinci secret store'a dönüşmesini önler. Aynı değer belirli durumlarda correlation amacıyla güvenli biçimde izlenebilir. Audit reader yine privileged role kabul edilmelidir. Application kendi loglarında secret value'yu ayrıca yazarsa Vault audit protection bu exposure'ı engelleyemez.

Birden Fazla Audit Device Kullanımı

Birden fazla Audit Device tek logging target arızasında visibility kaybı yaşama riskini azaltabilir. Örneğin local file ve merkezi syslog birlikte kullanılabilir. Her destination health ve storage capacity açısından ayrı izlenmelidir. Duplicate log storage retention ve access control maliyetini artırabilir. Dayanıklılık ile operasyon yükü arasında risk seviyesine uygun denge kurulmalıdır.

Audit Sistemi Kullanılamadığında Vault Davranışı

Vault audit subsystem security model'in kritik parçasıdır. Audit target failure normal application log hatası gibi değerlendirilmemelidir. Bütün audit destination'ların kullanılamaz olması Vault operation davranışını etkileyebileceği için yüksek availability sağlanmalıdır. Disk capacity ve network connectivity için erken alert kurulmalıdır. Controlled failure testleri ekibin gerçek incident sırasında sistem davranışını önceden bilmesini sağlar.

AWS Secrets Manager Monitoring

AWS Secrets Manager Monitoring CloudTrail, CloudWatch ve diğer AWS security servisleriyle oluşturulabilir. Secret access event, rotation failure, IAM policy change ve cross account access birlikte izlenmelidir. Yalnızca Secrets Manager resource metric'lerine bakmak yeterli değildir çünkü IAM değişikliği secret security'sini doğrudan etkiler. High value secret için human access veya beklenmeyen account kullanımı özel alarm oluşturabilir. Monitoring strategy operational error ile malicious behavior arasındaki farkı context bilgisi üzerinden anlamaya çalışmalıdır.

AWS CloudTrail

AWS CloudTrail Secrets Manager API request'lerini identity ve zaman bilgisiyle kaydeder. GetSecretValue, PutSecretValue ve resource policy değişiklikleri security açısından önemli event'lerdir. Loglar merkezi security account'a taşınabilir. Organization seviyesinde bütün account'ları kapsayan logging visibility sağlar. Retention ve log integrity ayarları incident investigation gereksinimine uygun biçimde yapılandırılmalıdır.

CloudWatch

CloudWatch rotation function logları, operational metric ve alarm için kullanılabilir. Lambda based rotation function error ve duration değerleri izlenebilir. Application authentication failure custom metric olarak eklenebilir. Böylece rotation service success görünürken application'ın yeni credential ile bağlanamadığı durum tespit edilir. Dashboard secret platform metric'leri ile application health verilerini aynı görünümde sunabilir.

Secret Access Event'leri

Secret Access Event hangi principal'ın hangi secret'a eriştiğini gösterir. Runtime workload için düzenli erişim normal olabilir. Human user'ın production database secret'ını okuması daha yüksek risk taşıyabilir. Baseline davranıştan sapmalar anomaly detection için kullanılabilir. Secret value audit event içinde bulunmamalı ve yalnızca metadata izlenmelidir.

Rotation Monitoring

Rotation Monitoring planlanan job'un zamanında çalışıp çalışmadığını ve başarıyla tamamlanıp tamamlanmadığını izler. Failed rotation belirli süre içinde çözülmezse alert oluşturulmalıdır. Target service connectivity ve permission hataları ayrı kategoride tutulabilir. Last successful rotation zamanı KPI olarak raporlanabilir. Application connection testinin de success criteria içine alınması daha gerçekçi monitoring sağlar.

Compliance Monitoring

Compliance Monitoring secret'ların organization rotation, ownership ve access policy kurallarına uyup uymadığını kontrol eder. Last rotated tarihi belirlenen threshold'u aşan secret finding oluşturabilir. Owner veya environment tag eksikliği governance problemi olarak raporlanabilir. Cross account sharing ve wildcard permission otomatik rule ile denetlenebilir. Düzenli compliance report audit hazırlığını ciddi biçimde kolaylaştırır.

Cross-Account Access Monitoring

Cross Account Access özellikle merkezi shared secret modelinde yakından izlenmelidir. Hangi account ve IAM Role'un hangi secret'a eriştiği CloudTrail üzerinden görülebilir. Organization dışı principal yüksek riskli alarm oluşturabilir. Resource Policy change event'leri de aynı monitoring kapsamına alınmalıdır. KMS Key Policy cross account permission'larıyla Secrets Manager Resource Policy birlikte değerlendirilmelidir.

High Availability ve Disaster Recovery

Secret platformu erişilemez olduğunda application yeni credential alamayabilir ve mevcut cache süresi sona erdikten sonra outage yaşayabilir. Bu nedenle High Availability ve Disaster Recovery security kadar önemli architecture alanıdır. Vault cluster quorum, storage, backup ve recovery süreci kurum tarafından yönetilir. AWS Secrets Manager managed availability sunsa da region failure için application ve secret replication planı gerekir. RTO ve RPO genel business continuity hedefleriyle uyumlu biçimde tanımlanmalıdır.

Vault HA

Vault HA birden fazla node kullanarak service availability'yi artırmayı amaçlar. Active node request'leri işlerken standby node failure durumunda leadership devralabilir. Storage ve leader election cluster behavior'ın temelidir. Load Balancer health check Vault node durumunu doğru anlamalıdır. Node'ların farklı failure domain'lere dağıtılması tek altyapı arızasının bütün secret platformunu etkilemesini önlemeye yardımcı olur.

Integrated Storage / Raft

Integrated Storage Raft tabanlı Vault storage modelidir. Veriler cluster node'ları arasında replication ile tutulur. Quorum kaybı cluster operation'larını etkileyebilir. Node placement farklı availability zone veya failure domain planına göre yapılmalıdır. Raft replication backup yerine geçmediği için düzenli snapshot alınmaya devam edilmelidir.

Active ve Standby Nodes

Active node Vault client request'lerini işler. Standby node active failure durumunda leadership devralmaya hazırdır. Failover süresi application retry ve timeout ayarlarıyla birlikte test edilmelidir. Load Balancer yanlış endpoint health logic kullanırsa traffic uygun olmayan node'a gidebilir. Maintenance işlemleri quorum kaybı yaratmayacak kontrollü sıra ile uygulanmalıdır.

Vault Backup

Vault Backup operator hatası, cluster kaybı veya yanlış configuration durumunda recovery sağlar. Raft snapshot otomatik schedule ile alınabilir. Backup file yüksek hassasiyetli secret data içerdiği için güçlü encryption ve access control gerektirir. Restore testi yapılmayan backup gerçek recovery garantisi vermez. Snapshot retention ve offsite storage organization RPO hedeflerine göre planlanmalıdır.

Vault Disaster Recovery

Vault Disaster Recovery yalnızca backup file bulundurmak değildir. Alternate site, network, DNS, TLS, authentication ve unseal dependency'lerinin birlikte çalışması gerekir. RTO hedefine göre standby cluster veya farklı replication yaklaşımı değerlendirilebilir. Failover procedure düzenli tatbikatla doğrulanmalıdır. İki cluster'ın aynı anda authoritative write alması gibi conflict senaryoları önceden engellenmelidir.

AWS Secrets Manager Managed Availability

AWS Secrets Manager infrastructure availability AWS tarafından yönetilir. Kullanıcı node, storage veya database cluster işletmez. Buna rağmen application'ın API timeout ve retry behavior'ını doğru tasarlaması gerekir. Client cache kısa süreli service disruption durumunda dayanıklılık sağlayabilir. Çok region'lı kritik application'larda regional dependency ayrıca address edilmelidir.

Cross-Region Secret Replication

Cross Region Secret Replication secret'ın başka AWS region'ında replica olarak bulunmasını sağlar. Disaster recovery application'ı failover region'ında uygun secret'a erişebilir. IAM ve KMS configuration target region için hazır olmalıdır. Rotation ownership primary ve replica ilişkisine göre net tanımlanmalıdır. Application failover sırasında doğru regional endpoint ve resource identifier kullanmalıdır.

Region Failure Senaryosu

Region Failure testinde yalnızca compute failover değil secret retrieval de kontrol edilmelidir. Application yeni region'a geçtiğinde replica secret, KMS key, IAM Role ve target database hazır olmalıdır. Cache içindeki eski credential target region'da geçersiz olabilir. DNS ve configuration switch automation ile uyumlu olmalıdır. Game day testleri gizli dependency'leri production outage öncesinde ortaya çıkarır.

RTO ve RPO

RTO service'in ne kadar sürede geri dönmesi gerektiğini ifade eder. RPO kabul edilebilir data loss veya state gap miktarını tanımlar. Secret platformu için RPO özellikle yeni oluşturulan veya rotate edilen credential'ın secondary environment'a ne kadar hızlı ulaştığıyla ilgilidir. Çok düşük RTO ve RPO daha yüksek infrastructure ve operasyon maliyeti getirir. Business impact gerçekçi biçimde değerlendirilerek target belirlenmelidir.

Secret Management Performansı Nasıl Ölçülür?

Secret Management Performansı yalnızca average response time ile değerlendirilmemelidir. P50, P95, P99 retrieval latency, request throughput, cache hit rate, authentication latency ve error rate birlikte izlenmelidir. Rotation veya massive deployment sırasında oluşan burst traffic ayrı test edilmelidir. Availability end to end application deneyimi üzerinden ölçülmelidir. Performance metric'leri security decision'larını desteklemeli, ancak daha hızlı retrieval için gereksiz uzun cache veya geniş access gibi güvenlik tavizlerine dönüşmemelidir.

Secret Retrieval Latency

Secret Retrieval Latency application'ın credential alması için geçen süredir. Startup sırasında yüksek latency deployment time'ı artırabilir. Business request path içinde retrieval yapılıyorsa end user response süresi etkilenebilir. Client side cache veya local provider bu süreyi azaltabilir. Ölçüm application tarafından yapılırsa network, authentication ve service processing dahil gerçek deneyim görülebilir.

P50

P50 median latency değeridir. Request'lerin yarısının bu değerin altında tamamlandığını gösterir. Günlük normal performans hakkında iyi fikir verir. Tail latency problemlerini tek başına göstermez. P50 iyi görünürken P99 kötü olabilir ve production timeout'ları yine yaşanabilir.

P95

P95 request'lerin yüzde 95'inin tamamlandığı latency seviyesidir. Production service deneyimini median'a göre daha gerçekçi gösterir. Network veya throttling problemi P95 üzerinde belirginleşebilir. Cache change öncesi ve sonrası karşılaştırma için kullanılabilir. Alarm threshold application SLO ve expected traffic pattern'e göre belirlenmelidir.

P99

P99 tail latency'nin önemli göstergesidir. Az sayıdaki çok yavaş request dağıtık application'da timeout oluşturabilir. Vault failover, network fluctuation veya KMS delay P99 üzerinde görünür olabilir. Caching tail latency'yi azaltabilir. Performance test normal load yanında rotation ve failure dönemlerini de kapsamalıdır.

Requests per Second

Requests per Second secret platformunun bir saniyede işlediği request sayısını gösterir. Her application request'inde secret retrieval yapılması gereksiz RPS oluşturabilir. Deployment sırasında binlerce pod aynı anda authentication yaparsa burst traffic oluşur. Capacity Planning bu startup storm davranışını hesaba katmalıdır. Cache, jitter ve controlled rollout merkezi platform üzerindeki ani yükü azaltabilir.

Cache Hit Rate

Cache Hit Rate secret retrieval işlemlerinin ne kadarının remote service'e gitmeden local cache'ten karşılandığını gösterir. Yüksek hit rate latency ve API maliyetini azaltır. Çok uzun TTL ile elde edilen yüksek oran rotation riskini artırabilir. Cache hit rate secret age ve rotation lag ile birlikte izlenmelidir. İdeal oran workload behavior ve security requirement'e göre değişir.

Rotation Success Rate

Rotation Success Rate planlanan credential rotation işlemlerinin ne kadarının başarıyla tamamlandığını gösterir. Yüzde yüz platform success application'ın yeni credential ile bağlanabildiğini tek başına kanıtlamaz. End to end connection validation metriğe dahil edilmelidir. Retry sonrası düzelmiş operation ayrı kategoride izlenebilir. Sürekli failure yaşayan secret'lar owner ve risk seviyesine göre önceliklendirilmelidir.

Authentication Latency

Authentication Latency workload'un secret platformuna identity doğrulaması yapması için geçen süredir. Kubernetes Auth, OIDC veya cloud identity additional network call oluşturabilir. Token cache bu maliyeti azaltabilir. Çok uzun token TTL policy change ve revocation etkisini geciktirebilir. Authentication ve secret retrieval latency ayrı metric olarak izlenmelidir.

Secret Availability

Secret Availability authorized application'ın ihtiyaç duyduğu anda doğru credential'ı alabilme oranıdır. Secret platform uptime tek başına yeterli gösterge değildir. IAM policy veya KMS key problemi application açısından secret'ı unavailable hale getirir. Network failure da aynı sonucu doğurabilir. Synthetic end to end check gerçek application path'ini test ederek daha doğru availability ölçümü sağlar.

Error Rate

Error Rate başarısız authentication, retrieval ve rotation işlemlerinin toplam request'e oranıdır. Authorization denial ile service 5xx error ayrı sınıfta tutulmalıdır. Rotation sonrası authentication error artışı cache veya application refresh problemi gösterebilir. Error budget secret platform SLO'su için kullanılabilir. Kısa transient spike ile uzun süreli incident farklı alert threshold'larıyla yönetilmelidir.

Secret Management KPI'ları

Secret Management KPI'ları teknik platform metric'lerinin yanında organization'ın credential hygiene seviyesini de ölçmelidir. Toplam secret sayısı, static ve dynamic oranı, rotation coverage, average age ve orphan secret sayısı önemli göstergelerdir. Hard coded secret finding developer process'in sağlık seviyesini gösterir. Mean Time to Revoke incident response hızını ölçer. KPI'lar yalnızca dashboard göstergesi olarak değil risk azaltma programının hedeflerini takip etmek için kullanılmalıdır.

Toplam Secret Sayısı

Toplam Secret Sayısı organization'ın machine credential inventory büyüklüğünü gösterir. Sayının artması tek başına kötü değildir çünkü application sayısı da artıyor olabilir. Önemli olan her secret'ın owner ve kullanım amacının bilinmesidir. Duplicate credential oranı ayrıca takip edilebilir. Ani secret artışı yeni platform veya application pattern'inde gereksiz static credential üretildiğini gösterebilir.

Static Secret Oranı

Static Secret Oranı toplam credential içinde long lived değerlerin payını gösterir. Oranın yüksek olması rotation ve leakage riskini artırabilir. Her static secret dynamic modele dönüştürülemez çünkü bazı third party servisler yalnızca API key sunar. Workload identity desteklenen alanlarda static oranı azaltmak gerçekçi hedeftir. Risk bazlı migration en yüksek privilege taşıyan static credential'lardan başlamalıdır.

Dynamic Secret Oranı

Dynamic Secret Oranı on demand veya short lived credential kullanım seviyesini gösterir. Yüksek oran tek başına otomatik security garantisi değildir. TTL, policy ve revocation yanlışsa risk devam eder. Database ve cloud access alanlarında bu KPI özellikle anlamlıdır. Organization'ın long lived shared credential'dan uzaklaşma hızını ölçmek için kullanılabilir.

Rotation Coverage

Rotation Coverage rotate edilmesi gereken secret'ların ne kadarında çalışan rotation mekanizması bulunduğunu gösterir. Sadece schedule configured olması success kabul edilmemelidir. Last successful rotation ve application validation bilgisi birlikte değerlendirilmelidir. Exemption verilen secret'ların gerekçesi ve expiration tarihi bulunmalıdır. Risk seviyesi yüksek credential'larda daha yüksek coverage target belirlenebilir.

Ortalama Secret Yaşı

Ortalama Secret Yaşı credential'ların ne kadar süredir aynı value ile yaşadığını gösterir. Average tek başına outlier'ları saklayabilir. En eski secret listesi veya P95 age daha faydalı ek metric olabilir. Yıllardır rotate edilmeyen admin credential yüksek riskli kabul edilmelidir. Dynamic secret kullanımında bu değer doğal olarak oldukça düşük olur.

Orphan Secret Sayısı

Orphan Secret Sayısı owner veya aktif consumer'ı bulunmayan credential miktarını gösterir. Bu KPI project closure ve asset lifecycle süreçlerinin kalitesini yansıtır. Owner tag boş olan secret otomatik review listesine alınabilir. Uzun süredir access edilmeyen resource'lar da orphan candidate olarak değerlendirilebilir. Deletion öncesinde downstream dependency kontrolü yapılmalıdır.

Hard-Coded Secret Sayısı

Hard Coded Secret Sayısı repository scanning sonucunda bulunan credential miktarını gösterir. Trend zaman içinde azalmalıdır. Aynı team veya repository'de tekrar eden finding education veya tooling eksikliğine işaret edebilir. Gerçek aktif credential finding daha yüksek severity almalıdır. Finding kapatılırken revoke ve rotation işleminin tamamlandığı doğrulanmalıdır.

Mean Time to Revoke

Mean Time to Revoke secret exposure tespiti ile credential'ın gerçekten geçersiz hale gelmesi arasındaki ortalama süredir. Bu süre ne kadar kısa olursa attacker'ın kullanım penceresi o kadar küçülür. Automated revoke workflow büyük iyileştirme sağlayabilir. Static credential'ın target system üzerinde manual değiştirilmesi süreyi uzatabilir. Düzenli incident drill ile bu KPI gerçek koşullarda test edilmelidir.

Policy Violation Sayısı

Policy Violation Sayısı wildcard access, eksik owner, fazla secret age veya yanlış environment sharing gibi governance problemlerini gösterir. Finding severity ve team bazında ayrıştırılmalıdır. Yeni automated policy rule devreye alındığında ilk dönemde sayının artması normal olabilir. Amaç zaman içinde açık ihlalleri azaltmaktır. Tekrarlanan violation pattern platform standardının veya developer documentation'ın iyileştirilmesi gerektiğini gösterebilir.

HashiCorp Vault ve AWS Secrets Manager Maliyet Karşılaştırması

HashiCorp Vault ve AWS Secrets Manager maliyet karşılaştırması yalnızca aylık service invoice üzerinden yapılmamalıdır. Secrets Manager secret sayısı ve API request gibi doğrudan kullanım maliyetleri üretirken self hosted Vault compute, storage, load balancer, backup, monitoring ve insan operasyonu maliyeti taşır. Vault Enterprise özellikleri gerekiyorsa lisans da eklenir. Secrets Manager tarafında KMS ve Lambda based rotation gibi ek bileşenler maliyet oluşturabilir. En doğru karşılaştırma gerçek workload sayısı, request hacmi, engineer zamanı ve on call sorumluluğunu içeren Total Cost of Ownership hesabıdır.

Secret Başına Maliyet

Secrets Manager pricing secret sayısını doğrudan maliyet kalemi haline getirebilir. Çok sayıda küçük secret büyük organization'da toplam faturayı artırır. Maliyeti düşürmek için farklı application'ların credential'ını tek secret içinde birleştirmek security açısından yanlış sonuç verebilir. Vault'ta birebir secret başına cloud service fiyatı olmayabilir, ancak scale infrastructure kaynaklarını etkiler. Güncel fiyat bilgisi deployment region ve service modeline göre proje zamanında doğrulanmalıdır.

API Request Maliyeti

Secrets Manager API Request sayısı managed service maliyetini etkileyebilir. Her business transaction sırasında GetSecretValue çağrısı yapmak gereksiz request hacmi üretir. Client side cache hem latency hem maliyet açısından faydalıdır. Vault self hosted modelde request başına doğrudan managed API faturası olmayabilir. Buna rağmen yüksek RPS daha büyük cluster capacity ve compute ihtiyacına dönüşür.

KMS Maliyeti

Customer Managed KMS Key kullanıldığında key ve cryptographic operation maliyetleri oluşabilir. Secret sayısı ve access volume toplam KMS kullanımını etkileyebilir. AWS Managed Key bazı basit senaryolarda ek operasyonu azaltır. Compliance özel key gerektiriyorsa maliyet planına dahil edilmelidir. Vault auto unseal AWS KMS kullanıyorsa KMS dependency'si Vault TCO hesabında da dikkate alınmalıdır.

Lambda Rotation Maliyeti

Lambda based rotation invocation ve execution süresi maliyet oluşturabilir. Tek secret için küçük görünen değer binlerce credential bulunan ortamda toplamda anlamlı hale gelebilir. VPC networking ve logging de ek maliyet yaratabilir. Rotation failure retry sayısı invocation volume'u artırır. Managed rotation desteklenen senaryolarda custom function bakım ve işletim maliyeti ayrıca karşılaştırılmalıdır.

Vault Compute Maliyeti

Self Hosted Vault node'ları sürekli compute kaynağı tüketir. HA için birden fazla node gerektiğinden minimum production cluster maliyeti tek VM yaklaşımından daha yüksektir. Disaster recovery cluster veya ikinci region ek compute gerektirir. Transit Engine yoğun kullanımında CPU ihtiyacı artabilir. Capacity Planning normal average yerine deployment burst ve authentication peak değerlerine göre yapılmalıdır.

Storage Maliyeti

Vault storage data volume secret value'lar küçük olsa bile audit log ve backup retention nedeniyle büyüyebilir. Raft snapshot'lar farklı location'da saklanmalıdır. Merkezi log sistemi uzun retention süresinde önemli storage maliyeti yaratabilir. Secrets Manager managed infrastructure storage'ı service modeline dahil eder. TCO hesabında observability ve backup storage kalemleri unutulmamalıdır.

HA Maliyeti

Vault HA birden fazla node, load balancer ve failure domain dağılımı gerektirir. DR environment varsa maliyet daha da yükselir. Secrets Manager managed service olduğu için kullanıcı HA node'ları provision etmez. Cross region replication ve multi region application architecture yine ek AWS maliyeti oluşturabilir. Availability target yükseldikçe iki modelde de farklı kalemlerden toplam maliyet artar.

Operasyon ve On-Call Maliyeti

Self Hosted Vault için en az görünür maliyet deneyimli platform engineer zamanıdır. Upgrade, snapshot, capacity, alert ve incident işleri sürekli devam eder. Gece oluşan cluster problemi on call yükü yaratır. Secrets Manager infrastructure katmanının büyük bölümünü managed service haline getirir. IAM ve application integration problemleri için security ve development operasyonu yine kurum sorumluluğunda kalır.

Enterprise Lisans Maliyeti

Vault Enterprise özelliği gerekiyorsa lisans maliyeti TCO hesabına eklenmelidir. Hangi enterprise capability'nin gerçek requirement olduğu açık biçimde belirlenmelidir. Gelecekte belki gerekir yaklaşımıyla gereksiz yüksek maliyetli architecture seçilmemelidir. Lisans koşulları procurement ve hukuk ekipleriyle değerlendirilmelidir. Uzun vadeli product strategy ve exit plan da finansal risk değerlendirmesinin parçası olmalıdır.

Total Cost of Ownership

Total Cost of Ownership service invoice, engineer zamanı, lisans, infrastructure, training ve outage riskini birlikte değerlendirir. AWS only küçük ekipte Secrets Manager çoğu zaman daha düşük TCO sağlar. Büyük multi cloud organization'da Vault merkezi governance ile dağınık tool maliyetlerini azaltabilir. Hesabın bir veya üç yıllık dönem üzerinden yapılması daha gerçekçi sonuç verir. Security ve compliance gereksinimleri maliyetten bağımsız değil birlikte değerlendirilmelidir.

Self-Hosted Vault'ın Gizli Operasyon Maliyetleri

Self hosted Vault ücretsiz indirilebilen veya belirli lisans modeliyle kullanılan yazılım olsa bile production işletimi ciddi operasyon maliyeti taşır. Upgrade, backup, HA, seal, capacity, monitoring ve incident response sürekli platform sorumluluğudur. Bu işler doğrudan cloud invoice üzerinde “Vault” adıyla görünmeyebilir, ancak mühendislik zamanı ve on call maliyeti üretir. Tek uzmana bağımlı Vault platformu sürdürülebilir değildir. Kurulum kararı verilmeden önce hangi ekibin 7/24 ownership alacağı ve disaster recovery'yi gerçekten test edeceği açık biçimde belirlenmelidir.

Upgrade

Vault Upgrade security patch ve yeni feature için düzenli yapılmalıdır. Node'lar uygun sıra ile güncellenmeli ve version compatibility kontrol edilmelidir. Upgrade öncesi backup veya snapshot alınması rollback güvenliği sağlar. Plugin ve integration compatibility staging ortamında test edilmelidir. Yıllarca upgrade edilmeyen Vault deployment security ve technical debt riskini büyütür.

Backup

Backup otomatik schedule ile alınmalı ve farklı failure domain'de tutulmalıdır. Snapshot hassas secret verisi taşıdığı için güçlü encryption ve access control gerektirir. Restore procedure belirli aralıklarla test edilmelidir. Retention compliance ve RPO hedeflerine göre planlanmalıdır. Backup var fakat restore doğrulanmamışsa disaster recovery güvenilir kabul edilmemelidir.

HA

HA cluster node placement, load balancer ve quorum yönetimi gerektirir. Node failure sırasında leader failover ölçülmelidir. Network partition behavior test edilmelidir. Maintenance operation quorum kaybı yaratmayacak biçimde yürütülmelidir. HA bir defalık setup değil sürekli operational responsibility'dir.

Seal / Unseal

Seal ve Unseal node restart ve recovery süreçlerini doğrudan etkiler. Manual unseal human coordination gerektirir. Auto unseal KMS veya HSM dependency'si getirir. Recovery key'lerin güvenli saklanması ayrı operasyon gerektirir. Bu süreçlerin documentation ve drill maliyeti Vault platform işletiminin parçasıdır.

Capacity Planning

Vault authentication, dynamic credential ve Transit request'leri farklı resource consumption pattern'leri oluşturur. Deployment sırasında binlerce pod aynı anda login yapabilir. Transit Engine yoğun cryptographic workload CPU ihtiyacını artırabilir. P95 ve P99 latency capacity signal olarak izlenmelidir. Cluster sizing yalnızca günlük average request sayısına göre yapılmamalıdır.

Monitoring

Vault node health, Raft status, request latency, audit device ve error rate izlenmelidir. Alert threshold gerçek SLO hedeflerine göre tanımlanmalıdır. Çok fazla gereksiz alarm on call yorgunluğu yaratır. Authentication failure ve policy denial security metric olarak ayrıca takip edilebilir. Monitoring stack'in kendisi de yüksek availability ve uygun retention sağlamalıdır.

Incident Response

Vault incident aynı anda birçok application'ın secret access'ini etkileyebilir. On call ekibinin leader failover, storage problem ve KMS access issue gibi senaryoları tanıması gerekir. Runbook önceden hazırlanmalıdır. Game Day exercise gerçek incident öncesinde ekip refleksini geliştirir. Central security platform olduğu için Vault outage severity seviyesi birçok normal application servisinden daha yüksek olabilir.

7/24 Platform Sorumluluğu

Production Vault mesai saati dışında da erişilebilir olmalıdır. Gece oluşan cluster problem credential renewal veya yeni application deployment'ını etkileyebilir. Gerçek 7/24 ownership modeli belirlenmelidir. Tek engineer'a bağlı knowledge risk oluşturur. Runbook, training ve rotation'lı on call organizasyonu toplam işletim maliyetinin doğrudan parçasıdır.

Secret Management ve Compliance

Secret Management erişim kontrolü, audit trail, rotation ve separation of duties gibi birçok compliance hedefini destekler. Ancak Vault veya Secrets Manager kullanmak tek başına KVKK, GDPR, ISO 27001, SOC 2 veya PCI DSS uyumluluğu sağlamaz. Organization policy, process ve teknik kontroller birlikte çalışmalıdır. Kimlerin hangi secret'a eriştiği ve bu erişimin ne kadar süre tutulduğu kanıtlanabilmelidir. Compliance requirement architecture kararlarını yönlendirmeli, ancak tool deployment tek başına sertifikasyon veya yasal uyumluluk garantisi olarak sunulmamalıdır.

KVKK

KVKK kişisel verilerin korunmasına yönelik hukuki yükümlülükler içerir. Secret Management kişisel veriye erişen application ve database credential'larının korunmasına katkı sağlayabilir. Least privilege ve audit unauthorized data access riskini azaltır. Kişisel verinin kendisi ile credential aynı data classification değildir. Hukuki gereksinimler security ve hukuk ekipleri tarafından birlikte değerlendirilmelidir.

GDPR

GDPR kişisel veri güvenliği için uygun teknik ve organizasyonel önlemler bekler. Secret management access credential'larının korunması açısından bu kontrollere katkı sağlar. Rotation, audit ve minimum permission unauthorized access riskini azaltabilir. Data retention ve data subject process'leri secret manager'ın görev alanından ayrıdır. Compliance architecture bütün veri lifecycle'ını kapsayan daha geniş governance sistemi içinde ele alınmalıdır.

ISO 27001

ISO 27001 bilgi güvenliği yönetim sistemi yaklaşımında access control ve credential yönetimi önemli alanlardır. Merkezi secret inventory kontrol evidence üretmeyi kolaylaştırır. Rotation policy, access review ve incident procedure belgelenebilir. Audit logları control'ün gerçekten çalıştığını gösterebilir. Technology seçimi kurumun risk assessment sonucu ve Information Security Management System hedefleriyle uyumlu olmalıdır.

SOC 2

SOC 2 çalışmalarında logical access, change management ve monitoring kontrolleri öne çıkabilir. Secret access audit kayıtları authorization kullanımına dair kanıt sağlar. IAM veya Vault Policy değişikliklerinin review sürecinden geçmesi change control açısından değerlidir. Production secret'a human direct access minimum tutulmalıdır. Automated report ve centralized logging auditor evidence toplama sürecini kolaylaştırabilir.

PCI DSS

PCI DSS payment card data environment için güçlü access ve authentication kontrolleri gerektirir. Database ve application credential'larının merkezi yönetimi ilgili güvenlik hedeflerini destekleyebilir. Unique identity ve rotation shared password kullanımını azaltır. Payment environment secret'ları development ortamından kesin biçimde ayrılmalıdır. Geçerli PCI DSS version ve spesifik requirement'lar proje sırasında ilgili uzmanlar tarafından ayrıca doğrulanmalıdır.

Audit Trail

Audit Trail access geçmişini kanıtlamak için kullanılır. Identity, resource, operation ve timestamp bilgisi birlikte bulunmalıdır. Secret value'nun log içine yazılması gerekli değildir. Audit record değiştirilme ve yetkisiz silinmeye karşı korunmalıdır. Retention organization policy ve regulatory requirement'lara göre belirlenmelidir.

Separation of Duties

Separation of Duties tek kişinin bütün secret lifecycle üzerinde sınırsız kontrol sahibi olmasını engellemeyi amaçlar. Policy administrator ile audit log administrator farklı role olabilir. Runtime application rotation veya management permission taşımamalıdır. Break glass access çoklu approval gerektirebilir. Bu ayrım insider threat ve accidental high impact change riskini azaltır.

Key Rotation Policy

Key Rotation Policy hangi credential veya cryptographic key'in hangi sıklıkla yenileneceğini tanımlar. Her secret için aynı schedule doğru değildir. Risk classification, target system capability ve business impact birlikte değerlendirilir. Automatic rotation mümkünse tercih edilmelidir. Exception verilen secret'ın owner, gerekçe ve expiration bilgisi bulunmalıdır.

Access Review

Access Review mevcut IAM ve Vault permission'larının hâlâ gerekli olup olmadığını düzenli kontrol eder. Employee veya application role değiştiğinde eski permission kalmamalıdır. High value secret access daha sık gözden geçirilebilir. Kullanılmayan role ve policy'ler kaldırılmalıdır. Review sonucu compliance evidence olarak saklanabilir.

HashiCorp Vault'tan AWS Secrets Manager'a Migration

Vault'tan AWS Secrets Manager'a Migration yalnızca secret value kopyalamak değildir. Authentication, authorization, rotation, naming, ownership ve application consumption modelleri yeniden değerlendirilmelidir. Vault Dynamic Secrets kullanan workload'u doğrudan static Secrets Manager password modeline geçirmek security açısından geri adım olabilir. AWS IAM Role veya native database authentication ile long lived credential ihtiyacı yeniden sorgulanmalıdır. Parallel run, cutover ve final credential rotation migration riskini azaltan temel aşamalardır.

Secret Inventory

İlk aşamada bütün Vault path ve Secrets Engine kullanımının inventory'si çıkarılmalıdır. Her resource static, dynamic, PKI veya encryption use case olarak sınıflandırılır. Last access ve consumer application bilgisi kaydedilir. Kullanılmayan secret yeni platforma taşınmamalıdır. Inventory migration scope ve risk önceliğini belirlemek için temel veri setidir.

Secret Ownership

Her secret için application veya team owner belirlenmelidir. Owner migration sırasında değerin hâlâ gerekli olduğunu doğrular. Sahibi bulunamayan secret orphan candidate olarak değerlendirilir. Production cutover sonrasında rotation failure kime gidecek sorusu önceden cevaplanmalıdır. Ownership tag veya metadata yeni platformda da korunmalıdır.

Naming Standardization

Vault path yapısı ile Secrets Manager naming convention birebir aynı olmak zorunda değildir. Account, environment ve application bilgisini anlaşılır biçimde gösteren standart seçilmelidir. IAM resource pattern'leri naming modeline göre planlanabilir. Name change application configuration update gerektirebilir. İyi naming standard gelecekte access policy ve inventory yönetimini kolaylaştırır.

Policy Mapping

Vault path ve capability modeli IAM permission yapısına dönüştürülmelidir. Read access yalnızca gerekli Secrets Manager action ve resource ARN ile eşleştirilmelidir. Vault'taki geniş wildcard permission aynı genişlikte IAM'e taşınmamalıdır. Workload Role tasarımı least privilege yaklaşımıyla yeniden kontrol edilmelidir. Cross account access gerekiyorsa Resource Policy ve KMS Key Policy birlikte planlanmalıdır.

Rotation Mapping

Her Vault secret için mevcut rotation veya dynamic credential davranışı incelenmelidir. RDS credential Secrets Manager rotation modeline taşınabilir. Vault Dynamic Database Secret birebir aynı yapı sunulmuyorsa IAM database authentication gibi alternative değerlendirilebilir. Security posture migration nedeniyle zayıflatılmamalıdır. Application rotation aware behavior target AWS modeline göre yeniden test edilmelidir.

Parallel Run

Parallel Run Vault ve Secrets Manager'ın kısa süre birlikte çalışmasını sağlar. Aynı secret'ın iki platform tarafından rotate edilmesi engellenmelidir. Authoritative source net biçimde belirlenir. Application belirli cohort'larla yeni source'a geçirilebilir. Error, latency ve audit metric'leri migration sırasında karşılaştırılır.

Application Cutover

Application Cutover secret retrieval ve authentication modelinin yeni platforma geçirildiği aşamadır. AWS workload mümkünse IAM Role kullanmalıdır. Cache ve retry behavior Secrets Manager'a göre test edilmelidir. Canary deployment outage riskini azaltabilir. Eski Vault access cutover doğrulandıktan sonra kaldırılmalıdır.

Credential Rotation

Migration sonunda aynı secret value'yu iki platformda bırakmak riskli olabilir. Application yeni source üzerinden çalıştığı doğrulandıktan sonra credential tekrar rotate edilmelidir. Eski Vault copy artık target system üzerinde geçerli olmamalıdır. New value yalnızca authoritative platform üzerinden dağıtılmalıdır. Böylece migration sırasında oluşan geçici kopyalar fiilen etkisiz hale getirilir.

Eski Vault Verilerinin Kapatılması

Bütün workload migration tamamladıktan sonra eski Vault path veya engine access'i disable edilebilir. Audit last access bilgisini doğrulamak için kullanılmalıdır. Backup retention compliance gereksinimine göre yönetilir. Target credential rotate edildiği için eski secret value geçersiz hale gelmelidir. Vault cluster tamamen kapatılacaksa snapshot, recovery key ve infrastructure resource'ları kontrollü decommission sürecinden geçmelidir.

AWS Secrets Manager'dan Vault'a Migration

AWS Secrets Manager'dan Vault'a Migration multi cloud, on premise veya dynamic secret ihtiyacından kaynaklanabilir. IAM Role ve policy modeli Vault authentication ve path policy sistemine yeniden eşlenmelidir. Bütün static secret'ları olduğu gibi KV Engine'e taşımak Vault'un dynamic credential avantajını kaçırabilir. Database password gibi uygun değerler migration sırasında dynamic model için değerlendirilebilir. Parallel run ve rollback planı production riskini kontrol altında tutar.

Secret Inventory

Secrets Manager resource'ları account ve region bazında listelenmelidir. Owner, tag, rotation status ve last accessed bilgisi çıkarılmalıdır. Kullanılmayan resource migration scope'undan temizlenebilir. Cross account secret'lar ayrı risk kategorisi olarak incelenmelidir. Inventory Vault path ve Secrets Engine tasarımının temel girdisini oluşturur.

IAM Policy'den Vault Policy'ye Geçiş

IAM Resource ARN permission'ları Vault path based policy modeline çevrilmelidir. Her workload'un gerçek ihtiyaçları yeniden kontrol edilmelidir. IAM wildcard permission'ları aynı genişlikte Vault'a taşınmamalıdır. Read, List ve Update capability'leri ayrı değerlendirilmelidir. Policy as Code migration boyunca standardizasyon ve review sağlar.

Authentication Mapping

AWS workload IAM Role ile Secrets Manager'a erişiyorsa Vault tarafında AWS Auth veya uygun federated model kullanılabilir. EKS workload'ları Kubernetes Auth kullanabilir. CI pipeline OIDC veya JWT ile bağlanabilir. Static Vault token dağıtmak migration'ı kısa vadede kolaylaştırsa da secret zero problemi oluşturur. Her environment için native identity öncelikli seçim olmalıdır.

Static Secret'ları Dynamic Secret'a Dönüştürmek

Migration Vault'un Dynamic Secrets özelliğini kullanmak için iyi fırsattır. Static database password KV'ye kopyalanmadan önce Database Secrets Engine desteği incelenmelidir. Application connection pool ve renewal behavior bu modele hazırlanmalıdır. TTL gerçek workload kullanımına göre belirlenir. Dönüşüm riskini azaltmak için önce pilot application üzerinde test yapılmalıdır.

Application Migration

Application Vault endpoint ve authentication yöntemine entegre edilir. Agent, CSI veya direct API consumption modelinden uygun olanı seçilebilir. Cache ve retry behavior yeni platforma göre test edilmelidir. Secret path environment bazında açık biçimde ayrılmalıdır. Log ve error handling secret value'yu göstermeyecek biçimde doğrulanmalıdır.

Parallel Run

Parallel Run iki platformun kısa süre birlikte kullanılmasını sağlar. Read traffic kontrollü biçimde Vault'a yönlendirilebilir. Rotation yalnızca authoritative source tarafından yapılmalıdır. Error ve latency metric'leri karşılaştırılır. Parallel dönem gereksiz uzatılmamalıdır çünkü dual operation maliyeti ve conflict riski artar.

Cutover

Cutover sonrasında application yalnızca Vault üzerinden credential alır. Secrets Manager access policy kaldırılabilir. Target credential rotate edilerek eski value geçersiz hale getirilebilir. Monitoring cutover penceresinde sıklaştırılmalıdır. Rollback trigger kriterleri önceden tanımlanmalıdır.

Rollback Planı

Rollback Plan application'ın Vault access'inde kritik problem yaşaması halinde güvenli dönüş sağlar. Eski Secrets Manager secret geçerli tutulacaksa geçiş süresince rotation ownership belirlenmelidir. Credential tamamen rotate edildiyse rollback için controlled synchronization gerekebilir. Plan staging ortamında test edilmelidir. Rollback süresinin application RTO hedefini karşılayıp karşılamadığı ölçülmelidir.

HashiCorp Vault Lisans Modeli ve OpenBao

HashiCorp Vault değerlendirmesinde teknik feature'ların yanında lisans ve uzun vadeli product governance konusu da dikkate alınmalıdır. Kullanılan edition ve sürümün güncel lisans şartları procurement ve hukuk ekipleri tarafından incelenmelidir. OpenBao açık kaynak secret management ekosisteminde Vault kökenli projelerden biri olarak değerlendirilebilir. API ve operational compatibility her feature için birebir varsayılmamalıdır. Enterprise architecture yalnızca bugünkü teknik uygunluk değil support, upgrade, migration ve vendor dependency risklerini de içermelidir.

BSL Nedir?

Business Source License source code'un görüntülenebildiği, ancak kullanım ve redistribution koşullarının geleneksel open source lisanslardan farklı olabildiği modeldir. Bazı commercial use case'ler özel restriction içerebilir. Organization kendi kullanım modelini güncel license text üzerinden değerlendirmelidir. Managed service veya product embedding gibi durumlar farklı legal sonuçlar oluşturabilir. Teknik ekip gerekirse hukuk ve procurement ekiplerinden lisans yorumu için destek almalıdır.

Source-Available ile Open Source Arasındaki Fark

Source Available yazılımın kaynak kodunun görülebilmesi anlamına gelir, ancak kullanım özgürlüğü her zaman open source definition ile aynı değildir. Open Source lisanslar redistribution ve modification haklarını belirli standartlara göre tanımlar. Bir repository'nin public olması tek başına yazılımın open source olduğu anlamına gelmez. Enterprise kullanımda lisans metni ve governance modeli birlikte incelenmelidir. Uzun vadeli architecture dependency buna göre değerlendirilmelidir.

OpenBao Nedir?

OpenBao secret management alanında açık kaynak bir proje olarak geliştirilir ve Vault kökenli çalışma modeline yakın yaklaşım sunar. Benzer API ve architecture kavramları migration veya skill reuse açısından avantaj sağlayabilir. Ancak feature parity her release için otomatik kabul edilmemelidir. Authentication method, plugin, HA ve enterprise ihtiyacı proof of concept ortamında test edilmelidir. Community governance, security response ve release sıklığı production seçiminde önemli göstergelerdir.

Vault-Compatible Alternatiflerin Avantajları

Vault compatible alternatifler mevcut application integration'larını tamamen yeniden yazmadan platform değişikliği yapma imkânı sağlayabilir. Benzer API ve policy modeli migration maliyetini azaltabilir. Buna rağmen operational behavior ve feature support arasında fark bulunabilir. Production workload mutlaka gerçek authentication, rotation ve HA testleriyle doğrulanmalıdır. Compatibility yalnızca KV read ve write operasyonuyla ölçülmemelidir.

Enterprise Projelerde Lisans Riskinin Değerlendirilmesi

Enterprise proje lisans riskini uzun product lifetime üzerinden değerlendirmelidir. Bugün internal kullanılan system gelecekte managed service veya customer facing product içine dönüşebilir. Bu değişiklik license etkisini değiştirebilir. Procurement agreement ve support condition architecture kadar önemlidir. Exit plan, data portability ve migration cost karar belgesine eklenmelidir.

Vendor Lock-In

Vendor Lock In yalnızca cloud provider bağımlılığı değildir. Proprietary API, policy language veya enterprise feature de migration maliyeti yaratabilir. Common interface ve automation lock in riskini azaltabilir. Bununla birlikte kendi abstraction layer'ınızı geliştirmek de maintenance cost oluşturur. Dependency tamamen ortadan kaldırılmaya çalışılmak yerine iş değeri karşılığında bilinçli biçimde yönetilmelidir.

Secret Management İçin Hangi Programlama Dili Kullanılır?

Secret Management için tek bir en iyi programlama dili yoktur. Python, Java, Go, JavaScript, TypeScript ve C# gibi yaygın diller AWS SDK veya Vault API ile entegre olabilir. Asıl önemli konu application'ın secret'ı nasıl aldığı, ne kadar süre cache ettiği ve rotation sırasında nasıl davrandığıdır. Workload identity programlama dilinden daha temel security kararıdır. Platform ekibi ortak library veya sidecar standardı sağlayarak her development team'in secret handling code'unu sıfırdan yazma ihtiyacını azaltabilir.

Python

Python backend, automation ve DevOps workflow'larında yaygın kullanılır. AWS Secrets Manager için boto3 kullanılabilir. Vault HTTP API veya uygun client library ile entegre olunabilir. Secret value debug loguna yazdırılmamalıdır. Long running service'lerde cache refresh ve rotation behavior açık biçimde tasarlanmalıdır.

boto3

boto3 Python application'larının AWS servisleriyle konuşmasını sağlar. Secrets Manager client GetSecretValue çağrısı yapabilir. Application içinde static access key yerine default credential chain ve IAM Role kullanılmalıdır. High request volume'da cache eklenebilir. Error handling authorization, missing secret ve service failure durumlarını ayrı ele almalıdır.

Vault API Client'ları

Python application Vault HTTP API veya maintained client library kullanabilir. Authentication token lifecycle doğru yönetilmelidir. Kubernetes veya cloud auth kullanıldığında static Vault token configuration içine yazılmamalıdır. Dynamic secret alındığında lease ve TTL bilgisi takip edilebilir. Library security update ve Vault API compatibility production öncesinde kontrol edilmelidir.

Java

Java enterprise backend ve büyük application platformlarında yaygın kullanılır. AWS SDK Secrets Manager integration sağlar. Vault için API client ve framework integration seçenekleri bulunabilir. JVM process içinde secret'ın gereksiz süre global static memory'de tutulmaması gerekir. Database connection pool rotation behavior Java application'larda özellikle önemli test alanıdır.

AWS SDK

AWS SDK Java application'ın IAM Role üzerinden Secrets Manager'a erişmesini sağlar. Retry ve timeout değerleri production latency hedeflerine göre ayarlanmalıdır. Static AWS key application property içine yazılmamalıdır. Client caching API request sayısını azaltabilir. SDK debug logging hassas request içeriğini göstermeyecek biçimde yapılandırılmalıdır.

Spring Entegrasyonları

Spring application configuration lifecycle secret retrieval davranışını etkileyebilir. Startup sırasında alınan value rotation sonrasında otomatik refresh edilmeyebilir. Dynamic configuration veya custom refresh mechanism gerekebilir. Datasource connection pool yeni credential ile yeniden bağlantı kurabilmelidir. Framework kolaylığı security lifecycle testinin yerine geçmemelidir.

Go

Go cloud native platform tool ve backend service'lerde sık kullanılır. AWS SDK ve Vault client entegrasyonları mevcuttur. Background goroutine cache refresh için kullanılabilir. Secret structured log veya error output içine düşmemelidir. Sidecar, operator veya credential broker gibi infrastructure component geliştirirken Go doğal seçenek olabilir.

Cloud-Native ve Platform Engineering

Go Kubernetes operator ve controller ecosystem'inde yaygın kullanılır. Secret management controller geliştiren ekipler Kubernetes API ve Go library'lerinden faydalanabilir. Controller'ın cluster genelinde geniş secret permission taşıması ciddi blast radius oluşturabilir. Reconciliation loop içinde secret value loglanmamalıdır. Leader election ve retry behavior platform reliability açısından test edilmelidir.

JavaScript / TypeScript

JavaScript ve TypeScript Node.js backend ve serverless application'larda yaygındır. AWS SDK üzerinden Secrets Manager'a erişilebilir. Async retrieval application startup veya connection lifecycle içinde yönetilebilir. Her request'te remote secret call yapılmamalıdır. Cache ve rotation refresh Lambda ve container workload'larına göre ayrı planlanmalıdır.

Node.js Uygulamaları

Node.js process secret value'yu memory cache içinde tutabilir. Cluster veya worker modeli kullanılıyorsa her process ayrı cache'e sahip olabilir. Rotation sonrası bütün worker'ların güncel value'ya geçmesi gerekir. Environment variable kolay entegrasyon sağlasa da runtime update yapmaz. SDK veya local provider daha esnek secret refresh modeli sunabilir.

C#

C# ve .NET application'ları AWS veya Vault secret service'leriyle rahat biçimde entegre olabilir. Dependency Injection üzerinden secret client ortak service olarak tanımlanabilir. Cache thread safe biçimde tasarlanmalıdır. Configuration provider startup only çalışıyorsa rotation refresh desteği kontrol edilmelidir. Database pool yeni credential ile connection açabilecek biçimde test edilmelidir.

AWS SDK for .NET

AWS SDK for .NET Secrets Manager client sağlar. EC2, ECS ve Lambda workload role üzerinden temporary credential kullanabilir. Hard coded access key appsettings içine eklenmemelidir. Retry ve timeout production requirement'e göre ayarlanabilir. Client caching yüksek call volume'da latency ve API cost avantajı sağlar.

En İyi Programlama Dili Yerine Doğru Secret Consumption Modeli Nasıl Seçilir?

Secret security'sini programlama dilinden çok consumption modeli belirler. Application static credential'ı config file'dan mı okuyor, workload identity ile runtime retrieval mı yapıyor sorusu daha önemlidir. Rotation aware cache ve least privilege bütün dillerde uygulanabilir. Platform team birkaç standard pattern sunarsa developer her project için security architecture yeniden tasarlamak zorunda kalmaz. Dil seçimi team skill ve performance ihtiyacına göre, secret modeli ise security ve operational requirement'e göre verilmelidir.

Open Source ve İşbirliğinin Secret Management Ekosistemindeki Yeri

Secret management ecosystem yalnızca commercial platformlardan oluşmaz. OpenBao, External Secrets Operator, Secrets Store CSI Driver, SOPS ve secret scanning projeleri farklı problemler için açık kaynak çözümler sunar. Community review ve contribution yeni integration'ların daha hızlı gelişmesine yardımcı olur. Bununla birlikte open source kullanmak security patch ve maintenance sorumluluğunu ortadan kaldırmaz. Production kullanılan project'lerin release, maintainer activity, vulnerability response ve upgrade compatibility durumu düzenli olarak takip edilmelidir.

OpenBao

OpenBao secret management alanında open source seçeneklerden biridir. Vault kökenli usage pattern'lerine yakın olması mevcut knowledge ve bazı integration yaklaşımlarının yeniden kullanılmasını kolaylaştırabilir. Production geçişte authentication, storage, policy ve API compatibility test edilmelidir. Community governance ve security response uzun vadeli support açısından önemlidir. Tool seçimi yalnızca bugün sunulan feature listesine göre yapılmamalıdır.

External Secrets Operator

External Secrets Operator Kubernetes ile external secret provider arasında ortak integration layer sağlar. AWS Secrets Manager ve Vault gibi farklı backend'lerle çalışabilir. Operator permission minimum tutulmalıdır. Kubernetes Secret sync edildiğinde cluster içindeki secret copy'nin güvenliği devam eden sorumluluktur. Release ve CRD change'leri upgrade planında test edilmelidir.

Secrets Store CSI Driver

Secrets Store CSI Driver external secret'ı pod volume olarak sunar. Provider model farklı backend'lerle integration sağlar. Kubernetes Secret resource oluşturmadan file mount kullanılabilir. Node level plugin security context dikkatle yönetilmelidir. Upgrade sırasında mount ve rotation behavior staging cluster'da test edilmelidir.

SOPS

SOPS encrypted configuration file'larını Git içinde yönetmek için kullanılır. Decryption key repository'den ayrı tutulmalıdır. KMS integration centralized key governance sağlar. Encrypted manifest pull request içinde paylaşılabilir. Decrypt permission geniş verilirse encrypted storage'ın security avantajı azalır.

GitLeaks ve Secret Scanning Araçları

GitLeaks ve benzeri scanner'lar repository ve commit history içinde credential pattern arar. Pre commit ve CI control olarak kullanılabilir. Finding automated revoke workflow'a bağlanırsa response süresi azalır. False positive yönetimi kontrollü yapılmalıdır. Allowlist entries düzenli review edilerek permanent bypass oluşması önlenmelidir.

Topluluk Tabanlı Plugin Geliştirme

Community plugin özel backend veya authentication integration ihtiyaçlarını çözebilir. Plugin trusted security boundary içinde çalışıyorsa code quality daha da önemlidir. Maintainer activity ve security response geçmişi incelenmelidir. Uzun süredir güncellenmeyen plugin production riskidir. Kurum kendi plugin'ini geliştiriyorsa test, review ve release process açık biçimde kurulmalıdır.

GitHub Üzerinden Güvenlik Katkıları

Open source security project'lerine documentation, test, bug fix veya code contribution yapılabilir. Security vulnerability public issue olarak paylaşılmadan responsible disclosure procedure izlenmelidir. Documentation contribution bile yanlış secret usage pattern'lerini azaltabilir. Yeni developer'lar test ve example deployment ile başlayabilir. Düzenli contribution gerçek production problem'lerini anlamayı ve secure code review becerisini geliştirir.

Üniversite–Sektör İşbirliği

Üniversite ve sektör ortak çalışma programları secret management gibi pratik güvenlik alanlarını gerçek kullanım senaryolarıyla öğretmek için değerlidir. Öğrenciler yalnızca Vault install etmeyi değil threat modeling ve incident response'u da öğrenebilir. Sektör ekipleri anonimleştirilmiş case study paylaşabilir. Open source contribution kalıcı öğrenme çıktısı oluşturur. Yerel software community'leri bu işbirliğini workshop ve mentorship programlarıyla güçlendirebilir.

Yazılım Topluluklarının Secret Management Eğitimindeki Rolü

Secret management yalnızca documentation okuyarak öğrenilmesi zor bir alandır çünkü gerçek problemler farklı system'lerin birlikte çalıştığı anlarda ortaya çıkar. Workshop, lab ve CTF senaryoları developer'ın credential leakage etkisini güvenli ortamda görmesini sağlar. Kubernetes, IAM, Vault ve CI/CD tek çalışma içinde birleştirilebilir. Diyarbakır Yazılım Topluluğu'nun farklı teknik proje alanlarını görmek isteyenler https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilir. Eğitim programlarının yalnızca komut ezberletmek yerine secret lifecycle, identity ve incident response düşünme biçimini öğretmesi uzun vadede daha fazla fayda sağlar.

DevSecOps Workshop'ları

DevSecOps Workshop insecure repository örneğiyle başlayıp secret scanning ve secure runtime retrieval modeline geçebilir. Katılımcılar yanlış configuration'ın gerçek riskini doğrudan görür. CI pipeline OIDC authentication static credential farkını somut biçimde gösterir. Workshop sonunda emergency rotation exercise yapılabilir. Böylece eğitim tool installation seviyesinde kalmadan bütün secret lifecycle'ı kapsar.

Vault Uygulama Laboratuvarları

Vault lab başlangıçta KV Engine ile temel secret storage gösterebilir. Daha sonra Kubernetes Auth ve Database Dynamic Secrets senaryosuna geçilebilir. Katılımcılar shared database password yerine unique short lived credential almayı deneyebilir. Lease revoke ve renewal application behavior ile birlikte test edilir. Son aşamada audit log analizi yapılarak authentication'dan incident response'a kadar bütün akış tamamlanır.

AWS Secrets Manager Workshop'ları

AWS Secrets Manager Workshop IAM Role ile runtime secret retrieval modelini gösterebilir. Lambda veya EKS workload static AWS key olmadan secret okuyabilir. RDS rotation application connection pool ile birlikte test edilebilir. CloudTrail access event'leri incelenebilir. Cache, latency ve API cost ölçülerek security ile operational design arasındaki ilişki pratik biçimde öğrenilebilir.

CTF ve Secret Leakage Senaryoları

CTF ortamında bilinçli bırakılmış API key veya Git history secret eğitim amacıyla kullanılabilir. Katılımcı yalnızca credential'ı bulmakla yetinmemeli, defensive aşamayı da tamamlamalıdır. Secret revoke edilir, repository temizlenir ve scanner eklenir. Böylece offensive finding ile defensive response aynı senaryoda öğrenilir. Gerçek production credential hiçbir eğitim lab ortamında kullanılmamalıdır.

Açık Kaynak Güvenlik Projeleri

Community member secret scanner rule, Kubernetes policy veya Vault integration example geliştirebilir. Küçük documentation veya test contribution yeni katılımcılar için iyi başlangıçtır. Open source project üzerinde gerçek code review secure coding alışkanlığı kazandırır. Vulnerability disclosure süreçleri öğrenilebilir. Ortak proje çıktısı yalnızca eğitime katılan kişiler için değil daha geniş developer community için de kalıcı kaynak oluşturur.

Diyarbakır Yazılım Topluluğu İçin Uygulama Fikirleri

Diyarbakır Yazılım Topluluğu için uygulamalı bir laboratuvar Git repository'ye yanlışlıkla bırakılan secret'ın scanner ile bulunmasıyla başlayabilir. İkinci aşamada aynı application Vault Dynamic Database Credential veya AWS Secrets Manager rotation modeline taşınabilir. Üçüncü aşamada Kubernetes workload identity ve CI OIDC integration eklenebilir. Database automation konularıyla bağlantı kurmak isteyenler https://www.diyarbakiryazilim.com.tr/posts/veritabani-yedekleme-ve-restorasyon-otomasyonlari adresindeki çalışma yaklaşımını inceleyebilir. Bu tür uçtan uca uygulamalar secret management'ı tek tool yerine gerçek DevSecOps workflow'u içinde öğretir.

Yazılımcılar Secret Management Alanında Nasıl Uzmanlaşabilir?

Secret management uzmanlığı tek bir Vault veya AWS eğitimiyle oluşmaz. Linux, networking, IAM, cryptography, cloud, Kubernetes, Terraform ve CI/CD bilgisinin birlikte gelişmesi gerekir. Secret değerleri bu system'ler arasında hareket ettiği için yalnızca bir katmanı bilmek production problem'lerini çözmeye yetmez. Uygulamalı lab ve open source contribution öğrenmeyi hızlandırır. En iyi eğitim senaryolarından biri insecure application'ı adım adım workload identity, dynamic credential, automated rotation ve centralized audit modeline taşımaktır.

Linux

Linux process, filesystem permission ve environment variable behavior secret security için temel bilgidir. Secret file'ının kim tarafından okunabileceğini OS permission belirler. Process inspection ve debug tool yanlış kullanımda hassas değeri gösterebilir. Container runtime da Linux isolation mekanizmalarına dayanır. Bu nedenle operating system temelini anlamadan production secret handling konusunu eksiksiz yönetmek zordur.

Networking

Secret manager access DNS, TLS, routing ve firewall üzerinden gerçekleşir. Private endpoint ve network segmentation exposure alanını azaltabilir. Yanlış timeout application'ın secret retrieval sırasında uzun süre beklemesine neden olabilir. Mutual TLS ve certificate trust chain PKI senaryolarında kritik hale gelir. Network control authorization'ın yerine geçmez, ancak güçlü defense in depth sağlar.

IAM

IAM secret management'ın en kritik öğrenme alanlarından biridir. Authentication kim olduğunuzu, authorization ne yapabileceğinizi belirler. AWS IAM Role, Vault Policy ve Kubernetes RBAC aynı architecture içinde birlikte bulunabilir. Wildcard permission'ın blast radius etkisi anlaşılmalıdır. Least privilege gerçek policy örnekleri üzerinde çalışılarak öğrenilir.

Cryptography Temelleri

Encryption, hashing, signing, certificate ve key kavramlarının birbirinden farkı bilinmelidir. Application password ile encryption key aynı lifecycle'a sahip değildir. TLS private key ile public certificate arasındaki ayrım önemlidir. Key rotation ve credential rotation farklı süreçlerdir. Derin matematik bilgisi her engineer için zorunlu olmasa da yanlış security assumption yapmayacak temel kavrayış gereklidir.

AWS

AWS üzerinde IAM, KMS, Secrets Manager, CloudTrail, EKS, ECS ve Lambda birlikte öğrenilmelidir. Service Role temporary credential modelinin nasıl çalıştığı anlaşılmalıdır. Rotation ve cross account policy lab ortamında test edilmelidir. KMS Key Policy değişikliğinin secret access'e etkisi görülmelidir. Cost ve monitoring de security training'in parçası olmalıdır.

Kubernetes

Kubernetes Service Account, RBAC, Secret, CSI ve admission mekanizmaları secret integration'ın temelidir. Pod Identity cloud provider modeliyle birlikte öğrenilmelidir. Environment variable ve file mount farkı pratik olarak test edilmelidir. Vault Agent veya External Secrets Operator gerçek cluster üzerinde uygulanabilir. Etcd encryption ve backup security Kubernetes Secret modelinin önemli parçalarıdır.

Terraform

Terraform secret infrastructure'ını code olarak yönetmeyi öğretir. State içine secret value girme riski uygulamalı görülmelidir. Vault policy ve AWS IAM resource reusable module olarak tasarlanabilir. Policy as Code testleri CI pipeline'a eklenebilir. Sensitive output'un state security problemini tamamen çözmediği özellikle anlaşılmalıdır.

CI/CD

CI/CD secret management alanında OIDC federation temel modern beceridir. Pipeline static AWS key yerine short lived Role credential alabilir. Vault JWT Auth ile benzer identity model kurulabilir. Log masking ve runner security test edilmelidir. Build time ile runtime secret ayrımı deployment architecture üzerinde açık biçimde gösterilmelidir.

DevSecOps

DevSecOps secret scanning, policy as code ve automated security control'leri development lifecycle içine taşır. Pre commit scanner developer'a hızlı feedback verir. CI scanning merkezi enforcement sağlar. Detection revoke ve rotate workflow'a bağlanabilir. Platform team secure default sunarak developer'ın her project'te güvenliği manuel yeniden oluşturmasını önlemelidir.

HashiCorp Vault

Vault öğrenirken KV Engine ile başlanabilir, ancak eğitim orada bitmemelidir. Authentication, policy, dynamic database credential, PKI, Transit, audit ve HA birlikte çalışılmalıdır. Backup restore ve seal recovery lab ortamında denenmelidir. Kubernetes ve CI integration gerçek workload ile test edilmelidir. Böylece Vault basit password storage değil identity aware security platformu olarak anlaşılır.

Açık Kaynak Projelere Katkı

Open source contribution gerçek code base üzerinde security ve review kültürünü öğrenmeyi sağlar. Documentation veya test case ile başlanabilir. Secret scanning rule veya Kubernetes integration example geliştirilebilir. Responsible disclosure process öğrenilmelidir. Düzenli katkı teknik bilgi kadar team collaboration ve secure software development becerisini de geliştirir.

AI ve GenAI Projelerinde Secret Management

AI ve GenAI application'ları model provider, vector database, RAG data source ve external tool'lara bağlandığı için secret sayısını hızla artırabilir. LLM API key ve agent tool credential aynı application içinde yüksek privilege taşıyabilir. En büyük risklerden biri modelin raw secret value'yu prompt veya tool response içinde görmesidir. Mümkünse agent'a credential vermek yerine broker service gerekli işlemi onun adına gerçekleştirmelidir. Short lived ve action scoped credential prompt injection kaynaklı credential abuse riskini azaltmaya yardımcı olur.

LLM API Keys

LLM API Key source code, notebook veya shared script içine yazılmamalıdır. Notebook paylaşımı secret exposure için ciddi risk oluşturabilir. Runtime secret manager retrieval kullanılmalıdır. Provider usage limit ve scope özellikleri destekleniyorsa etkinleştirilmelidir. Usage anomaly ve rotation monitoring key compromise durumunu daha erken fark etmeye yardımcı olabilir.

Model Provider Credentials

Model Provider Credential environment ve application bazında ayrılmalıdır. Development workload production budget veya high privilege model endpoint'ine erişmemelidir. Tek shared key bütün engineering team tarafından kullanılmamalıdır. Usage audit application identity ile ilişkilendirilebilmelidir. Provider workload identity veya federation destekliyorsa static key yerine bu model değerlendirilmelidir.

Vector Database Credentials

Vector Database hassas embedding veya document chunk içerebilir. Credential yalnızca gerekli index veya collection access'ine sahip olmalıdır. AI application compromise olduğunda admin permission ele geçirilmemelidir. Rotation connection pool behavior ile test edilmelidir. Dynamic veya application specific credential destekleniyorsa shared account yerine tercih edilmelidir.

RAG Data Source Credentials

RAG system file storage, database ve internal API gibi birçok data source'a erişebilir. Credential scope gereksiz geniş tutulursa prompt üzerinden farklı veri alanlarına erişim riski oluşur. User authorization bilgisi retrieval layer'a yansıtılmalıdır. Secret manager yalnızca credential'ı korur ve data level permission sorununu çözmez. Her connector minimum permission ve ayrı audit ile tasarlanmalıdır.

AI Agent Tool Credentials

AI Agent Tool Credential payment, email veya cloud API gibi yüksek etkili operation yetkisi taşıyabilir. Agent'a permanent admin token vermek ciddi risk yaratır. Broker service action request'i policy kontrolünden geçirip credential'ı kendi boundary'si içinde kullanabilir. Tool access short lived ve action scoped tutulmalıdır. Prompt injection ve unauthorized tool usage security testlerine dahil edilmelidir.

MCP Server Secrets

MCP Server external tool veya data source'a bağlanırken secret kullanabilir. Credential server side tutulmalı ve model context içine doğrudan verilmemelidir. Tool response secret value döndürmemelidir. Workload identity destekleniyorsa static credential azaltılabilir. Audit her tool invocation'ı identity ve authorization kararıyla ilişkilendirmelidir.

Agent'ın Secret Değerini Görmemesi

En güçlü model agent'ın raw secret value'yu hiçbir aşamada almamasıdır. Agent yalnızca işlem isteğini broker service'e gönderir. Broker gerekli credential'ı kendi güvenlik boundary'si içinde kullanarak sonucu döndürür. Böylece model prompt veya output üzerinden secret'ı dışarı çıkaramaz. Özellikle payment, cloud management ve enterprise data tool'larında bu pattern güçlü güvenlik sınırı sağlar.

Short-Lived Agent Credentials

Agent için permanent access token yerine görev süresince geçerli short lived credential üretilebilir. Her job ayrı token kullanabilir. Task tamamlandığında token expire veya revoke edilir. Scope yalnızca gerekli tool ve resource'a izin verir. Audit token issuance ile agent job ID arasında bağlantı kurarak investigation sürecini kolaylaştırabilir.

AI Coding Agent'larda Secret Güvenliği

AI Coding Agent repository ve shell access'e sahipse local environment secret'larını yanlışlıkla okuyabilir. Agent production credential bulunan developer shell'iyle çalıştırılmamalıdır. Sandbox ve minimum filesystem permission kullanılmalıdır. Generated code veya commit secret scanning'den geçirilmelidir. CI OIDC credential kullanımı agent'ın static deploy key görme ihtiyacını azaltır.

Örnek Bir Kurumsal Secret Management Projesi Nasıl Yapılır?

Kurumsal secret management projesi doğrudan tool install ederek başlamamalıdır. Önce inventory, ownership, classification ve workload identity fırsatları çıkarılmalıdır. Daha sonra static secret azaltma hedefi belirlenir ve Vault ile AWS Secrets Manager kararı gerçek gereksinimlere göre verilir. Pilot application authentication, rotation, Kubernetes, CI/CD, audit ve emergency response akışlarını uçtan uca test eder. Başarılı pilot sonrasında production rollout standard pattern ve sürekli secret hygiene programıyla genişletilir.

Adım 1: Secret Inventory Çıkarma

Repository, CI variable, Kubernetes, cloud secret store ve configuration file gibi bütün kaynaklar taranmalıdır. Aynı credential'ın kaç farklı yerde kopyalandığı belirlenmelidir. Type, environment ve last accessed bilgisi kaydedilmelidir. Hard coded secret scanner ek data source olarak kullanılabilir. Inventory olmadan migration scope ve risk önceliği doğru biçimde belirlenemez.

Adım 2: Secret Owner Belirleme

Her secret için sorumlu application veya team belirlenmelidir. Owner credential'ın hâlâ gerekli olduğunu doğrular. Sahibi bulunamayan değer orphan review listesine alınır. Rotation failure alert'i doğrudan doğru ekibe yönlendirilmelidir. Ownership metadata secret manager içinde tag veya path convention ile saklanabilir.

Adım 3: Secret Classification

Secret'lar risk ve kullanım türüne göre sınıflandırılmalıdır. Database admin password ile düşük privilege API key aynı risk seviyesinde değildir. Machine credential, human credential ve cryptographic key ayrımı yapılmalıdır. Her class için TTL, rotation ve audit requirement belirlenebilir. Classification güvenlik kontrolünün gerçek business impact ile uyumlu olmasını sağlar.

Adım 4: Workload Identity Kullanılabilecek Alanları Belirleme

Static AWS access key kullanan workload'lar ilk iyileştirme adaylarından biridir. IAM Role, EKS Pod Identity veya OIDC federation ile bu secret tamamen kaldırılabilir. Kubernetes workload Vault'a Service Account identity ile bağlanabilir. CI pipeline static cloud credential yerine OIDC kullanabilir. Ortadan kaldırılan secret en düşük operasyon yüküne sahip secret'tır.

Adım 5: Static Secret'ları Azaltma

Static database password uygun ortamda dynamic credential'a dönüştürülebilir. Cloud access key workload identity ile ortadan kaldırılabilir. Third party API key gibi zorunlu static değerler merkezi store'a taşınır. Her static secret için rotation policy oluşturulur. Hedef bütün secret'ları yok etmek değil gereksiz long lived credential kullanımını azaltmaktır.

Adım 6: Vault vs AWS Secrets Manager Kararı

AWS only küçük ekipte Secrets Manager güçlü adaydır. Multi cloud, on premise, dynamic database credential veya internal PKI ihtiyacında Vault avantajlıdır. Hibrit model yalnızca source of truth net ise kullanılmalıdır. Total Cost of Ownership engineer zamanı ve on call maliyetini kapsamalıdır. Architecture Decision Record neden diğer seçeneğin elendiğini de açıklamalıdır.

Adım 7: Authentication Modeli Tasarlama

Her workload type için native identity seçilmelidir. EKS pod IAM veya Kubernetes Service Account kullanabilir. CI OIDC token ile authenticate olabilir. Human user merkezi SSO kullanmalıdır. Static Vault token veya AWS key yalnızca zorunlu legacy scenario için sınırlı geçiş çözümü olmalıdır.

Adım 8: Policy Modeli Tasarlama

Policy application ve environment bazında least privilege olarak tasarlanmalıdır. Runtime role yalnızca gerekli read veya retrieval action'a sahip olmalıdır. Management permission ayrı identity'ye verilmelidir. Wildcard rule automated test ile engellenebilir. Policy as Code bütün authorization change'lerini review sürecine taşır.

Adım 9: Rotation Politikası

Her secret class için rotation interval belirlenmelidir. Application'ın yeni credential'a geçiş behavior'ı test edilmelidir. Emergency rotation normal schedule'dan bağımsız çalışabilmelidir. Failed rotation alert üretmelidir. Success kriteri application'ın new credential ile gerçekten target system'e bağlanabilmesidir.

Adım 10: Kubernetes / CI/CD Entegrasyonu

Kubernetes için CSI, Agent, Operator veya direct API pattern seçilir. CI için OIDC veya JWT authentication kullanılır. Runtime production secret build pipeline'a taşınmamalıdır. Environment isolation policy ile uygulanmalıdır. Reusable manifest ve pipeline template developer experience'i güçlendirir.

Adım 11: Audit ve Monitoring

Vault Audit veya CloudTrail logları merkezi SIEM'e gönderilmelidir. Rotation failure, policy denial ve high value access için alarm kurulmalıdır. Dashboard performance ve security KPI'larını birlikte göstermelidir. Logların secret value içermediği doğrulanmalıdır. Retention compliance ve incident investigation ihtiyacına göre belirlenmelidir.

Adım 12: Pilot

Pilot düşük riskli fakat gerçek production pattern'ini temsil eden workload ile yapılmalıdır. Authentication, retrieval, cache, rotation ve incident senaryosu test edilir. Developer experience ölçülür. Platform team runbook'ları gerçek flow üzerinde doğrular. Pilot sonucu enterprise standard güncellenir.

Adım 13: Production Deployment

Production rollout bütün application'ları tek seferde taşımak yerine kontrollü dalgalar halinde yapılmalıdır. Team veya application bazlı migration risk azaltır. Monitoring geçiş sırasında sıklaştırılır. Eski credential kopyaları cutover doğrulandıktan sonra revoke edilir. Rollback criteria production deployment öncesinde hazır olmalıdır.

Adım 14: Emergency Rotation Testi

Controlled exercise ile production credential exposure senaryosu simüle edilmelidir. Secret revoke edilir, yenisi üretilir ve application güncellenir. Mean Time to Revoke ölçülür. Audit log üzerinden blast radius çıkarılır. Tatbikat sonrasında runbook ve automation eksikleri düzeltilir.

Adım 15: Sürekli Secret Hygiene

Secret management deployment tamamlandığında biten proje değildir. Orphan secret, age review ve policy review düzenli çalışmalıdır. CI scanning sürekli aktif olmalıdır. Yeni workload identity özellikleri çıktıkça static credential kullanım alanları yeniden değerlendirilmelidir. KPI trend'i security ve platform ekiplerine düzenli olarak raporlanmalıdır.

Secret Management'ta Yapılan Yaygın Hatalar

Secret management alanında en yaygın hata merkezi platform kurmanın tek başına güvenlik sağladığını düşünmektir. Hard coded credential bırakmak, geniş policy kullanmak veya application'ı rotation aware tasarlamamak platformun faydasını ciddi biçimde azaltır. Bir diğer hata basit AWS projesinde gereksiz Vault operasyonu oluşturmak veya tam tersine multi cloud dynamic credential ihtiyacını yalnızca static cloud store ile çözmeye çalışmaktır. Araç seçimi gerçek threat model ve team capability üzerinden yapılmalıdır. Güvenlik standardı secret lifecycle'ın tamamını kapsamalıdır.

Secret Manager Kullanıp Hard-Coded Credential Bırakmak

Yeni secret manager kurulurken eski repository ve config credential'ları unutulabilir. Application'ın gerçekten yeni source'tan okuduğu doğrulanmadan migration tamamlanmış sayılmamalıdır. Scanner legacy value'ları tespit edebilir. Cutover sonrasında eski credential target system üzerinde revoke edilmelidir. Aksi halde attacker secret manager'ı bypass ederek eski kopyayı kullanabilir.

AWS Access Key'i Secret Olarak Saklamak

AWS workload için static Access Key'i Secrets Manager içine koymak çoğu zaman yanlış modeldir. IAM Role temporary credential sağlar. Static key rotation ve secret zero problemi yaratır. EC2, Lambda, ECS ve EKS native role kullanabilir. Harici system zorunlu static key kullanıyorsa permission ve rotation daha sıkı yönetilmelidir.

Tüm Uygulamaların Aynı Database Credential'ını Kullanması

Shared database credential audit ve revocation açısından ciddi sorun oluşturur. Bir application compromise olduğunda aynı account'u kullanan bütün workload'ların yetkisi risk altına girer. Application specific static credential ilk iyileştirme olabilir. Dynamic database credential daha ileri seviyede unique short lived access sağlar. Database Role minimum data access'e göre tanımlanmalıdır.

Rotation Yapıp Uygulamayı Rotation-Aware Tasarlamamak

Secret manager credential'ı değiştirebilir, ancak application cache eski değeri kullanabilir. New database connection authentication error üretir. Refresh ve retry behavior yoksa rotation outage'a dönüşür. Staging ortamında gerçek rotation test edilmelidir. Application team secret lifecycle design'ın aktif parçası olmalıdır.

Secret'ları Süresiz Cache'lemek

Infinite cache API cost'u azaltır, ancak revocation ve rotation etkisini geciktirir. Application restart edilene kadar eski credential kullanılabilir. TTL ve authentication failure refresh kullanılmalıdır. High risk secret daha kısa cache süresine sahip olabilir. Cache policy ortak application standard olarak tanımlanabilir.

Çok Geniş IAM/Vault Policy Kullanmak

Wildcard permission başlangıçta hızlı çözüm gibi görünür. Application compromise olduğunda bütün secret store erişilebilir hale gelebilir. Team ve application bazlı resource scope kullanılmalıdır. Runtime role management permission taşımamalıdır. Policy scanning geniş access'i CI aşamasında tespit edebilir.

Dev ve Production Secret'larını Karıştırmak

Development workload production secret okuyabiliyorsa environment isolation başarısızdır. Ayrı account, namespace veya path kullanılabilir. Developer direct production runtime credential access'ine sahip olmamalıdır. Aynı secret iki environment'ta tekrar kullanılmamalıdır. Test endpoint ve data da production'dan ayrılmalıdır.

Audit Logging'i Etkinleştirmemek

Audit olmadan incident sonrasında hangi identity'nin secret okuduğunu anlamak zorlaşır. Vault Audit Device production standardı olmalıdır. AWS ortamında CloudTrail merkezi olarak korunmalıdır. Retention incident investigation ihtiyacına uygun tutulmalıdır. Audit pipeline failure yüksek priority alert oluşturmalıdır.

Secret Owner Tanımlamamak

Owner bulunmayan secret rotation failure durumunda kimin müdahale edeceğini belirsiz bırakır. Yıllar sonra değer kullanılmaya devam ediyor mu sorusunun cevabı bulunamaz. Owner tag veya metadata zorunlu hale getirilebilir. Organization değişikliklerinde ownership güncellenmelidir. Orphan owner tespiti düzenli governance control olarak çalıştırılmalıdır.

Kullanılmayan Secret'ları Silmemek

Kullanılmayan credential hâlâ target system üzerinde aktif olabilir. Last accessed bilgisi ve application inventory kullanılmalıdır. Önce revoke veya disable edilip kısa observation period uygulanabilir. Daha sonra secret ve downstream account kalıcı olarak kaldırılır. Deletion audit record olarak saklanmalıdır.

Secret Zero Problemini Görmezden Gelmek

Secret manager'a giriş için application içine master password koymak problemi çözmez. O password da başka yerde korunmak zorundadır. Workload identity, IAM Role, OIDC veya Kubernetes Auth kullanılmalıdır. Legacy environment AppRole kullanıyorsa SecretID distribution ayrıca güvenli tasarlanmalıdır. Authentication modeli secret storage kadar önemlidir.

Vault'ı Basit Bir Key-Value Store Olarak Kullanmak

Vault kurulup bütün database password'lar KV içine taşındığında yalnızca storage location değişmiş olur. Dynamic Database Credential fırsatı değerlendirilmelidir. PKI ve Transit gibi capability'ler gerçek requirement varsa kullanılabilir. Bütün feature'ları kullanmak zorunlu değildir. Ancak platform operasyon maliyeti üstleniliyorsa Vault'un anlamlı güvenlik avantajlarından yararlanmak gerekir.

Basit AWS Projesinde Gereksiz Vault Operasyon Yükü Oluşturmak

Bir Lambda ve RDS application yalnızca birkaç secret yönetiyorsa Secrets Manager çoğu zaman yeterlidir. Böyle bir sistem için multi node Vault cluster, backup ve on call süreci gereksiz olabilir. IAM Role secret zero problemini doğal biçimde çözer. RDS credential rotation managed modelle karşılanabilir. Vault gerçek multi cloud, dynamic secret veya PKI ihtiyacı ortaya çıktığında değerlendirilmelidir.

HashiCorp Vault mu AWS Secrets Manager mı? Karar Matrisi

Karar Matrisi hangi ürünün daha fazla feature'a sahip olduğundan çok hangi problem için hangi modelin daha uygun olduğunu gösterir. AWS only application düşük operasyon hedefliyorsa Secrets Manager güçlü seçimdir. Multi cloud, on premise ve dynamic database credential ihtiyacında Vault öne çıkar. Internal PKI veya merkezi encryption service gereksinimi Vault lehine olabilir. Hibrit model yalnızca source of truth, rotation ownership ve audit süreçleri açık biçimde tanımlandığında kullanılmalıdır.

AWS-Only + Küçük Ekip

AWS only küçük team yeni secret platform cluster'ı işletmek istemeyebilir. IAM Role workload identity için hazırdır. CloudTrail ve KMS mevcut AWS security modeline oturur. Vault eklemek ikinci policy ve operations katmanı oluşturur. Bu senaryoda managed AWS service daha doğal başlangıç noktasıdır.

AWS Secrets Manager

AWS Secrets Manager AWS only küçük ekip için güçlü default seçimdir. RDS, Lambda, ECS ve EKS integration'ları hazırdır. IAM Role static access key ihtiyacını azaltır. Managed rotation belirli credential lifecycle'larını sadeleştirebilir. Multi cloud requirement oluştuğunda architecture yeniden değerlendirilebilir.

Multi-Cloud + Dynamic Secrets

Birden fazla cloud provider ve on demand credential ihtiyacı merkezi control plane değerini artırır. Ayrı provider secret service'leri governance fragmentation oluşturabilir. Vault ortak authentication ve policy modeli sağlar. Dynamic engine short lived credential üretebilir. Platform team gerekli HA ve on call kapasitesine sahip olmalıdır.

HashiCorp Vault

HashiCorp Vault multi cloud dynamic secret senaryosunda güçlü seçimdir. Database, cloud ve PKI access'leri ortak governance altında yönetilebilir. Workload farklı authentication method'larla aynı control plane'e bağlanabilir. HA ve disaster recovery kurum tarafından yönetiliyorsa ciddi platform ownership gerekir. TCO hesabı bu insan operasyonunu içermelidir.

On-Prem + Cloud

On premise ve cloud system'leri tek secret lifecycle altında yönetmek merkezi platform ihtiyacı oluşturabilir. Native cloud secret service on premise workload için ek network ve identity tasarımı gerektirir. Vault her iki environment'a ortak API sağlayabilir. Legacy database ile Kubernetes workload aynı policy governance altında çalışabilir. Availability architecture merkezi dependency'yi güvenli hale getirmelidir.

HashiCorp Vault

HashiCorp Vault hybrid infrastructure için güçlü central secret platform olabilir. Self hosted deployment on premise control requirement'ını karşılar. Cloud workload uygun Auth Method ile aynı platforma erişebilir. Dynamic secrets ve PKI ek değer sağlayabilir. Platform team'in işletim kapasitesi seçimden önce doğrulanmalıdır.

AWS Serverless

AWS Lambda ve serverless workload IAM Role üzerinden identity alır. Application ayrı Vault credential taşımak zorunda değildir. Secrets Manager SDK veya local cache modeliyle kullanılabilir. Managed service serverless operational yaklaşımıyla uyumludur. Ek network dependency minimumda tutulabilir.

AWS Secrets Manager

AWS Secrets Manager serverless application için doğal seçimdir. Lambda Execution Role yalnızca gerekli secret'a erişir. Cache invocation cost ve latency'yi azaltabilir. Rotation RDS gibi target system'lerle entegre edilebilir. Vault daha geniş organization requirement varsa ayrıca değerlendirilmelidir.

Internal PKI

Internal PKI çok sayıda service için short lived certificate issuance gerektirir. Secret storage'dan daha geniş certificate lifecycle platformuna ihtiyaç vardır. Vault PKI Secrets Engine bu ihtiyaca odaklanabilir. Identity ve certificate issuance aynı policy modeline bağlanır. CA Key protection ve recovery ayrı security control gerektirir.

HashiCorp Vault

HashiCorp Vault Internal PKI için güçlü araçlardan biridir. Automated certificate issuance mümkündür. Short TTL long lived private key riskini azaltır. Kubernetes ve internal service integration kurulabilir. CA hierarchy ve disaster recovery production architecture içinde baştan planlanmalıdır.

Minimum Operasyon Yükü

Secret platform node, backup ve upgrade yönetmek istemeyen AWS team managed service tercih edebilir. IAM ve CloudTrail zaten organization içinde kullanılmaktadır. Secrets Manager additional cluster operation oluşturmaz. Application integration ve policy security yine kurum sorumluluğundadır. Infrastructure on call yükü önemli ölçüde azalır.

AWS Secrets Manager

AWS Secrets Manager minimum platform operations hedefleyen ekipler için güçlü seçimdir. Node, Raft veya seal management gerekmez. IAM authorization ve CloudTrail audit hazır AWS ecosystem içinde çalışır. Managed availability infrastructure bakım yükünü azaltır. Service cost ile engineer operation tasarrufu birlikte değerlendirilmelidir.

Merkezi Enterprise Secrets Platform

Büyük organization çoklu cloud, on premise ve Kubernetes cluster yönetiyorsa merkezi control plane faydalı olabilir. Vault ortak policy ve dynamic credential sunar. AWS native team'ler bazı local secret'larda Secrets Manager kullanmaya devam edebilir. Hibrit model central inventory gerektirir. Governance hangi platformun hangi secret class'ından sorumlu olduğunu açık biçimde belirlemelidir.

Vault veya Hibrit Model

Vault merkezi control plane olarak kullanılabilir veya AWS native alanlarla kontrollü hibrit model kurulabilir. Aynı secret iki platform tarafından aktif biçimde yönetilmemelidir. Application ownership ve environment boundary açık olmalıdır. SIEM iki platformun audit loglarını birleştirmelidir. Hibrit architecture yalnızca gerçek iş gerekçesi varsa tercih edilmelidir.

Dynamic Database Credentials

Application başına short lived database credential üretmek isteniyorsa Dynamic Secrets güçlü avantaj sağlar. Shared static password ortadan kaldırılır. Lease expiration ve revocation automated lifecycle sunar. Audit unique database user üzerinden daha anlamlı olur. Application connection pool bu modele hazırlanmalıdır.

HashiCorp Vault

HashiCorp Vault Database Secrets Engine dynamic database credential için güçlü çözümdür. PostgreSQL, MySQL ve desteklenen diğer target'larda role tabanlı user creation uygulanabilir. TTL kısa tutularak exposure window azaltılır. Application renewal veya reissue behavior yönetmelidir. Bu özellik Vault'un basit KV store yaklaşımının ötesinde sağladığı en net güvenlik faydalarından biridir.

Secret Management'ın Geleceği

Secret management alanındaki güçlü yön long lived static credential'dan workload identity ve short lived access modeline geçiştir. OIDC federation, machine identity, just in time credential ve automated rotation bu dönüşümün temel araçlarıdır. Amaç yalnızca secret'ı daha iyi saklamak değil, mümkün olan credential'ı tamamen ortadan kaldırmaktır. AI agent gibi yeni machine workload türleri credential brokering ihtiyacını daha da artıracaktır. Geleceğin platformları raw secret value dağıtmaktan çok doğrulanmış identity adına kontrollü ve süreli access üretmeye yönelecektir.

Long-Lived Secret'lardan Short-Lived Credentials'a Geçiş

Aylarca yaşayan API key ve password compromise durumunda uzun risk window oluşturur. Short lived credential bu pencereyi dakika veya saat seviyesine indirebilir. Dynamic database user ve cloud temporary token bunun örnekleridir. Application renewal ve refresh mekanizması gerektirir. Platform team bunu common library veya sidecar ile developer'dan büyük ölçüde soyutlayabilir.

Secret-Based Authentication'dan Workload Identity'ye Geçiş

Workload Identity application'ın static password olmadan kendisini doğrulamasını sağlar. Kubernetes Service Account ve cloud role model'leri giderek yaygınlaşmaktadır. Secret manager'a login için ayrı credential ihtiyacı azalır. Identity lifecycle workload lifecycle ile hizalanır. Bu dönüşüm secret inventory ve rotation yükünü ciddi biçimde azaltabilir.

OIDC Federation

OIDC farklı platformlar arasında short lived identity federation için ortak mekanizma sağlar. CI/CD system cloud'a static key olmadan erişebilir. SaaS ve internal platform integration'larında kullanım alanı büyümektedir. Trust policy claim ve audience ile daraltılmalıdır. Federation credential rotation yükünü azaltırken yanlış trust configuration'ın etkisini artırabileceği için governance önemlidir.

SPIFFE / SPIRE

SPIFFE workload identity için standard kimlik biçimi tanımlar. SPIRE bu identity'lerin issuance ve attestation süreçlerini uygulayabilir. Multi cluster ve multi cloud workload'larda common machine identity modeli sağlayabilir. Static secret dağıtımı yerine mTLS ve identity based access kullanımını destekler. Operational cost ve integration requirement gerçek ihtiyaca göre değerlendirilmelidir.

Just-in-Time Credentials

Just in Time Credential yalnızca ihtiyaç anında oluşturulur. Standing privilege azalır. Human admin access approval workflow ile, machine access dynamic secret ile sağlanabilir. TTL iş süresine göre kısa tutulur. Operation tamamlandığında credential revoke veya expire olur.

Automated Rotation

Manual rotation human calendar'a bağlı olduğu için zamanla aksayabilir. Automated Rotation lifecycle'ı sürekli hale getirir. Rotation aware application daha kısa interval kullanabilir. Failure monitoring ve rollback mekanizması şarttır. Automation security'yi artırırken yanlış tasarlanırsa geniş outage oluşturabileceği için production öncesi test gerektirir.

Machine Identity Security

Machine Identity sayısı mikroservis ve AI workload'larıyla hızla artmaktadır. Her service instance'ın doğrulanabilir identity'si olması shared credential ihtiyacını azaltır. Identity issuance, attestation ve revocation yeni platform security alanıdır. Shared service account kullanımından kaçınılmalıdır. Audit machine identity'yi gerçek workload metadata'sıyla ilişkilendirmelidir.

Agentic AI için Credential Brokering

AI agent'a raw API key vermek yerine broker service kontrollü operation'ı onun adına gerçekleştirebilir. Broker policy engine hangi tool ve action'ın izinli olduğunu doğrular. Credential agent prompt context'e girmez. Her operation audit edilebilir. Short lived delegated access prompt injection kaynaklı credential exfiltration riskini azaltır.

Secretless Infrastructure

Secretless Infrastructure hiçbir cryptographic secret'ın bulunmadığı system anlamına gelmez. Amaç application katmanındaki long lived shared credential'ı mümkün olduğunca azaltmaktır. Workload identity, mTLS ve federation bu hedefe yardımcı olur. Cryptographic key'ler güvenilir platformlarda yaşamaya devam eder. Başarı metriği kaç secret saklandığından çok kaç static credential'ın ortadan kaldırıldığı olabilir.

Sıkça Sorulan Sorular

Secret management konusunda en sık sorulan sorular genellikle hangi tool'un seçileceğinden çok doğru identity ve lifecycle modelinin nasıl kurulacağıyla ilgilidir. Vault ile AWS Secrets Manager arasındaki karar cloud kapsamı, dynamic credential ihtiyacı, platform team büyüklüğü ve operasyon kapasitesine göre değişir. AWS native workload ile multi cloud platform aynı çözümü kullanmak zorunda değildir. Kubernetes, CI/CD ve database rotation senaryoları gerçek application behavior ile test edilmelidir. Gizli Veri (Secret) Yönetimi: HashiCorp Vault ve AWS Secrets değerlendirmesinde en iyi sonuç, seçilen aracın least privilege, workload identity, short lived access ve güçlü audit ile birlikte uygulanmasıyla elde edilir.

Secret management nedir?

Secret management API key, password, token, private key ve benzeri hassas credential'ların güvenli yaşam döngüsünü yönetir. Storage bunun yalnızca bir bölümüdür. Access control, distribution, rotation, revocation ve audit aynı sürecin parçalarıdır. Modern yaklaşım mümkünse static secret yerine workload identity ve short lived credential kullanır. Merkezi platform secret sprawl ve ownership problemlerini azaltmaya yardımcı olur.

HashiCorp Vault nedir?

HashiCorp Vault identity aware secret ve encryption management platformudur. KV storage yanında dynamic database credential, PKI ve Transit Engine gibi yetenekler sunar. Farklı authentication method'larla cloud, Kubernetes ve human identity'leri destekleyebilir. Self hosted modelde HA, backup ve upgrade kurumun sorumluluğundadır. Multi cloud ve on premise enterprise architecture'da merkezi control plane olarak kullanılabilir.

AWS Secrets Manager nedir?

AWS Secrets Manager AWS üzerinde managed secret storage ve rotation service'idir. IAM access control, KMS encryption ve CloudTrail audit ile native integration sağlar. RDS, Lambda, ECS ve EKS gibi AWS workload'larıyla kolay çalışır. Ayrı secret cluster işletme ihtiyacını azaltır. Application cache ve rotation behavior yine doğru biçimde tasarlanmalıdır.

HashiCorp Vault ile AWS Secrets Manager arasındaki fark nedir?

Vault multi cloud, dynamic secrets, PKI ve encryption service gibi daha geniş platform kabiliyetleri sunar. Secrets Manager AWS native managed secret lifecycle service'idir. Vault self hosted kullanıldığında daha fazla infrastructure control ve daha fazla operation responsibility getirir. Secrets Manager IAM ile doğal biçimde bütünleşir. Seçim workload dağılımı ve team capability'ye göre yapılmalıdır.

Vault mı AWS Secrets Manager mı daha güvenlidir?

Security yalnızca product'a değil configuration ve operating model'e bağlıdır. Yanlış policy verilen iki platform da riskli olabilir. AWS only workload IAM Role kullanıyorsa Secrets Manager güçlü ve sade güvenlik modeli sunar. Multi cloud dynamic credential ihtiyacında Vault daha fazla control sağlayabilir. En güvenli platform sürdürülebilir least privilege, short lived credential ve audit modelinin doğru uygulandığı platformdur.

Vault dynamic secrets nedir?

Vault Dynamic Secrets request anında üretilen short lived credential'lardır. Database user yaygın örnektir. Her workload unique value alabilir. TTL ve Lease ile yaşam süresi yönetilir. Süre sonunda credential revoke edilerek shared permanent password ihtiyacı azaltılır.

Secret rotation nedir?

Secret Rotation mevcut credential'ın yeni value ile değiştirilmesidir. Amaç long lived credential riskini azaltmaktır. Target system ve application aynı değişime uyum sağlamalıdır. Cache ve connection pool behavior test edilmelidir. Automated rotation manual takip ihtiyacını azaltır.

Dynamic secret ile rotation arasındaki fark nedir?

Rotation static credential'ı belirli aralıklarla değiştirir. Dynamic secret request anında yeni ve çoğunlukla unique credential üretir. Haftalık rotate edilen shared password ile bir saatlik application specific database user aynı model değildir. Dynamic credential blast radius'u daha fazla sınırlar. Target system dynamic model desteklemiyorsa rotation hâlâ önemli security control'dür.

AWS Secrets Manager otomatik rotation yapabilir mi?

Evet, desteklenen use case'lerde automatic rotation yapılandırılabilir. Managed veya Lambda based model target service'e göre kullanılabilir. Rotation Schedule tanımlanabilir. Application yeni credential'a geçebilecek biçimde tasarlanmalıdır. Failed rotation monitoring ve alert sistemine bağlanmalıdır.

AWS Secrets Manager için Lambda şart mı?

Her rotation senaryosunda Lambda zorunlu değildir. Bazı supported integration'larda managed rotation seçenekleri bulunabilir. Custom rotation logic gereken durumda Lambda yaygın yöntemdir. Target service'in güncel support durumu proje sırasında doğrulanmalıdır. Application rotation modelinden bağımsız olarak new credential refresh davranışına sahip olmalıdır.

Vault Kubernetes ile nasıl kullanılır?

Vault Kubernetes Auth ile Service Account identity'yi doğrulayabilir. Secret delivery Agent Injector, CSI Provider, Secrets Operator veya direct API üzerinden yapılabilir. Static Vault token pod configuration içine yazılmamalıdır. Dynamic secret kullanılıyorsa Lease renewal ve rotation behavior test edilmelidir. Integration seçimi application'ın file veya runtime retrieval beklentisine göre yapılmalıdır.

AWS Secrets Manager EKS ile nasıl kullanılır?

EKS workload IAM based Pod Identity ile Secrets Manager'a erişebilir. Secrets Store CSI Driver ve AWS Secrets and Configuration Provider file mount sağlayabilir. Application AWS SDK ile runtime retrieval da yapabilir. Kubernetes Secret resource oluşturmadan kullanım mümkündür. Rotation sonrasında application'ın yeni value'yu gerçekten kullandığı doğrulanmalıdır.

Environment variable içinde secret saklamak güvenli midir?

Environment Variable tek başına mutlak güvensiz değildir, ancak önemli riskleri bulunur. Process inspection, debug ve accidental logging exposure yaratabilir. Running process rotation sonrası value'yu otomatik değiştirmeyebilir. File mount veya runtime retrieval bazı workload'larda daha uygun olabilir. Seçim application threat model ve lifecycle ihtiyacına göre yapılmalıdır.

Kubernetes Secret güvenli midir?

Kubernetes Secret doğru RBAC ve encryption at rest ile güvenli architecture'ın parçası olabilir. Base64 encoding encryption değildir. Etcd ve backup security ayrıca önemlidir. External credential lifecycle için ek secret manager gerekebilir. Kubernetes Secret tek başına bütün secret management gereksinimlerini çözmez.

AWS Secrets Manager mı Parameter Store mu?

Basit configuration ve SecureString ihtiyacında Parameter Store yeterli olabilir. Automatic credential rotation ve secret lifecycle gerektiğinde Secrets Manager daha güçlüdür. IAM ve KMS her iki modelde de önemlidir. Cost secret ve request sayısına göre değerlendirilmelidir. Normal configuration'ın tamamını Secrets Manager içinde tutmak gerekli değildir.

AWS KMS ile Secrets Manager arasındaki fark nedir?

KMS cryptographic key ve encryption operations yönetir. Secrets Manager application credential saklar ve rotate edebilir. Secrets Manager secret'ları KMS ile korunabilir. İki servis birbirinin alternatifi değildir. Password için Secrets Manager, cryptographic key lifecycle için KMS düşünülmelidir.

Vault Transit Engine ne işe yarar?

Vault Transit Engine encryption as a service sağlar. Application key materyalini doğrudan görmeden encrypt veya decrypt operation yapabilir. Key rotation merkezi olarak yönetilebilir. Transit business data storage sistemi değildir. Encrypted output farklı database veya storage üzerinde tutulur.

Vault'ta secret rotation nasıl yapılır?

Vault rotation secret type'a göre farklı modelle yapılabilir. Dynamic database credential short TTL ve Lease üzerinden natural rotation sağlar. Static secret target system ve Vault value birlikte güncellenerek rotate edilir. Application cache ve connection pool new value'ya geçmelidir. Automation failure monitoring ile desteklenmelidir.

Secret zero nedir?

Secret Zero application'ın secret manager'a ilk authentication için ne kullanacağı problemidir. Başka static password saklamak problemi yalnızca taşır. Workload Identity, IAM Role, OIDC ve Kubernetes Service Account güçlü çözümlerdir. Legacy system AppRole kullanabilir. Amaç ilk trust relationship'i static secret olmadan kurmaktır.

Workload identity secret manager'ın yerini alabilir mi?

Bazı credential ihtiyaçlarında evet. AWS workload IAM Role ile AWS API'ye erişiyorsa static Access Key gerekmez. Third party API yalnızca API key destekliyorsa secret manager yine gerekir. Workload Identity secret manager'a authentication için de kullanılabilir. En iyi yaklaşım identity ile çözülebilen static secret'ları tamamen kaldırmaktır.

CI/CD pipeline'da secret nasıl saklanmalıdır?

Pipeline static cloud credential yerine OIDC ile short lived access almalıdır. Harici secret gerekiyorsa job süresince merkezi store'dan okunmalıdır. Secret loglara yazılmamalıdır. Runtime production credential build artifact içine eklenmemelidir. Branch ve environment claim'leri production access'i sınırlandırmalıdır.

HashiCorp Vault açık kaynak mı?

Vault'un lisans modeli kullanılan sürüm ve edition'a göre değerlendirilmelidir. Source available yaklaşım klasik open source lisansla aynı değildir. Community ve commercial özellikler farklı olabilir. Enterprise kullanımda güncel lisans şartları hukuk ve procurement ekipleriyle incelenmelidir. OpenBao gibi open source seçenekler de teknik gereksinime göre değerlendirilebilir.

OpenBao nedir?

OpenBao Vault kökenli open source secret management project'lerinden biridir. Benzer API ve usage model bazı migration senaryolarında avantaj sağlayabilir. Feature parity otomatik varsayılmamalıdır. Authentication, plugin ve HA requirement test edilmelidir. Community governance ve support model seçim kriteri olmalıdır.

Secret management için hangi programlama dili kullanılmalıdır?

Tek bir doğru programlama dili bulunmaz. Python, Java, Go, JavaScript, TypeScript ve C# secret manager API'leriyle çalışabilir. Asıl kritik konu Workload Identity, caching, rotation ve logging design'dır. Language team skill ve application requirement'e göre seçilir. Secret consumption model organization security standardına göre belirlenmelidir.

Küçük bir proje için Vault kullanmak gerekli midir?

Çoğu küçük AWS native project için Vault zorunlu değildir. Secrets Manager veya uygun durumda Parameter Store daha düşük operational cost ile ihtiyacı karşılayabilir. Vault cluster HA, backup ve monitoring sorumluluğu getirir. Dynamic secret veya multi cloud requirement yoksa bu yük gereksiz olabilir. Project büyüdüğünde architecture yeniden değerlendirilebilir.

Vault ve AWS Secrets Manager birlikte kullanılabilir mi?

Evet, ancak authoritative source ve rotation ownership net olmalıdır. Vault merkezi multi cloud platform olurken bazı AWS native secret'lar Secrets Manager'da tutulabilir. Aynı secret'ın iki system tarafından bağımsız rotate edilmesi engellenmelidir. Central inventory ve audit her iki platformu kapsamalıdır. Hibrit model yalnızca gerçek use case ayrımı bulunduğunda anlamlıdır.

Sonuç

Gizli Veri (Secret) Yönetimi: HashiCorp Vault ve AWS Secrets değerlendirmesinde doğru karar yalnızca feature listesine bakılarak verilmemelidir. AWS ağırlıklı, küçük veya orta ölçekli ekiplerde AWS Secrets Manager IAM entegrasyonu ve düşük operasyon yüküyle çoğu zaman güçlü başlangıç noktası olur; multi cloud, on premise, dynamic database credential, internal PKI veya merkezi enterprise control plane ihtiyacında HashiCorp Vault daha fazla esneklik sağlayabilir. Hangi platform seçilirse seçilsin asıl güvenlik kazanımı long lived credential'ları azaltmak, workload identity kullanmak, least privilege uygulamak, rotation'ı otomatikleştirmek ve audit verisini sürekli izlemekten gelir. HashiCorp Vault ve AWS Secrets Manager kurulum entegrasyon hizmeti veya secret management ve DevSecOps danışmanlığı yakınımda gibi bir ihtiyacınız varsa Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir ve teknik proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz. Başlangıç için en verimli adım mevcut secret inventory'nizi çıkarmak, hangi static credential'ların workload identity ile tamamen kaldırılabileceğini belirlemek ve kalan secret'lar için owner, rotation, audit ve emergency revocation modelini oluşturmaktır.

Ek Sıkça Sorulan Sorular

Aşağıdaki sorular özellikle ürün seçimi, Kubernetes ve CI/CD entegrasyonu, automatic rotation ve danışmanlık arayan ekiplerin karşılaştığı pratik konuları özetler. Tek bir ürün bütün workload tipleri için otomatik olarak en doğru çözüm değildir. AWS native application, on premise database ve Kubernetes platform farklı identity ve secret consumption model'lerine ihtiyaç duyabilir. Bu nedenle production architecture proof of concept ve emergency rotation exercise ile doğrulanmalıdır. Doğru secret management yaklaşımı tool seçiminden önce credential lifecycle ve machine identity tasarımını netleştirir.

Gizli veri (Secret) yönetimi nedir ve HashiCorp Vault ile AWS Secrets Manager nasıl kullanılır?

Gizli veri yönetimi API key, parola, token, TLS private key ve database credential gibi hassas değerlerin creation, storage, access, rotation ve revocation süreçlerini yönetir. HashiCorp Vault KV Engine üzerinden static secret saklayabilir, Dynamic Secrets üretebilir, PKI ve Transit özellikleri sağlayabilir. AWS Secrets Manager IAM, KMS, CloudTrail ve rotation özellikleriyle AWS native managed secret hizmeti sunar. Her iki platformda da application'ın static login credential taşımaması ve workload identity kullanması tercih edilmelidir. Ürün seçimi cloud kapsamı, dynamic secret ihtiyacı, team capability ve total operational cost üzerinden yapılmalıdır.

HashiCorp Vault ile AWS Secrets Manager arasındaki farklar nelerdir ve hangi senaryoda hangisi tercih edilmelidir?

HashiCorp Vault multi cloud, on premise, dynamic secrets, PKI ve encryption service alanlarında daha geniş bir platform yaklaşımı sunar. AWS Secrets Manager AWS application'ları için düşük operasyonlu managed secret storage ve rotation sağlar. AWS only küçük veya orta ekiplerde Secrets Manager çoğu zaman daha sade seçimdir. Multi cloud, internal PKI ve dynamic database credential ihtiyacında Vault daha güçlü hale gelir. Hibrit kullanım mümkündür, ancak source of truth ve rotation ownership kesin biçimde tanımlanmalıdır.

API anahtarları parolalar ve erişim bilgileri HashiCorp Vault veya AWS Secrets Manager ile nasıl güvenli şekilde saklanır ve döndürülür?

İlk adım secret değerlerini source code, image ve plaintext configuration file'dan ayırmaktır. Vault'ta KV veya uygun Dynamic Secrets Engine, AWS tarafında Secrets Manager kullanılabilir. Access Policy yalnızca ilgili workload'a gerekli read veya retrieval yetkisini vermelidir. Rotation Schedule application'ın cache ve connection pool behavior'ıyla birlikte test edilmelidir. Sızıntı halinde eski credential hemen revoke edilmeli, yeni value üretilmeli ve application kontrollü biçimde güncel credential'a geçirilmelidir.

CI/CD ve Kubernetes ortamlarında secret yönetimi erişim yetkilendirmesi ve otomatik rotasyon nasıl yapılandırılmalıdır?

CI pipeline static key yerine OIDC veya JWT üzerinden short lived identity almalıdır. Kubernetes workload Vault için Service Account ve Kubernetes Auth, AWS için IRSA veya EKS Pod Identity kullanabilir. Secret Agent, CSI, Operator veya runtime SDK üzerinden application'a verilebilir. Production runtime secret build artifact içine konulmamalıdır. Rotation sonrasında file refresh, cache invalidation veya reconnect behavior ile application'ın yeni credential'ı gerçekten kullandığı end to end test edilmelidir.

HashiCorp Vault ve AWS Secrets Manager kurulumu ve secret yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Secret management eğitimi yalnızca product kurulumu değil authentication, least privilege, rotation, Kubernetes, CI/CD ve incident response başlıklarını birlikte ele almalıdır. Uygulamalı lab gerçek production behavior'ını anlamak için güçlü yöntemdir. Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi edinebilirsiniz. Teknik proje örnekleri ve çalışma alanları için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz. Eğitim veya danışmanlık öncesinde mevcut cloud yapınızı, Kubernetes kullanımınızı, CI/CD platformunuzu ve secret inventory'nizi çıkarmak doğru architecture önerisinin daha hızlı oluşturulmasını sağlar.