Secret management; API anahtarı, veritabanı parolası, erişim token'ı, özel anahtar, webhook imzalama sırrı ve benzeri hassas kimlik bilgilerinin oluşturulmasından iptal edilmesine kadar geçen yaşam döngüsünü yönetme disiplinidir. Amaç yalnızca bu değerleri şifreli bir kasaya koymak değildir. Hangi uygulamanın hangi secret'a, hangi ortamda, ne kadar süreyle ve hangi işlem için erişebileceği de denetlenmelidir.
Kod içine gömülen bir API anahtarı kaynak kod deposuna, CI loguna, container imajına, istemci bundle'ına veya geliştirici cihazındaki yedeklere yayılabilir. Daha sonra satır silinse bile anahtar Git geçmişinde ve daha önce üretilmiş artefaktlarda kalabilir. Bu nedenle secret yönetimi, “gizli değeri nereye yazalım?” sorusundan daha geniştir; envanter, erişim, dağıtım, rotasyon, kullanım kaydı ve sızıntı müdahalesi birlikte planlanmalıdır.
Secret olarak kabul edilmesi gereken bilgiler nelerdir?
Bir değerin secret olup olmadığını belirlemek için dosya adına değil, ele geçirilmesi halinde ne yapılabileceğine bakılmalıdır. Bir saldırgan değerle sisteme giriş yapabiliyor, işlem imzalayabiliyor, veri çözebiliyor veya güvenilen servis gibi davranabiliyorsa bu bilgi secret olarak yönetilmelidir.
| Secret türü | Ne için kullanılır? | Sızıntı halinde temel risk |
|---|---|---|
| API anahtarı | Bir servise uygulama veya proje adına erişim sağlar. | Yetkisiz API çağrısı, maliyet, veri erişimi veya kota tüketimi |
| Veritabanı kimlik bilgisi | Uygulamanın veri tabanına bağlanmasını sağlar. | Veri okuma, değiştirme veya silme |
| OAuth client secret veya access token | Üçüncü taraf servislerde yetkili işlem yürütür. | Kullanıcı ya da uygulama adına işlem yapılması |
| Özel anahtar | İmza, kimlik doğrulama veya şifre çözme amacı taşır. | Sahte imza, sunucu taklidi veya korunan verinin açılması |
| Webhook signing secret | Gelen webhook'un beklenen sağlayıcıdan geldiğini doğrular. | Sahte event gönderme ve iş akışını tetikleme |
| CI/CD ve deployment token'ı | Build, package publish veya production dağıtımı yapar. | Zararlı artefakt üretme veya üretime erişim |
| Şifreleme anahtarı | Uygulama verisini şifreler ya da çözer. | Veri gizliliğinin ve bütünlüğünün kaybı |
Kullanıcıların giriş parolalarıyla uygulama secret'ları aynı şekilde saklanmamalıdır. Kullanıcı parolaları geri okunabilir biçimde tutulmak yerine uygun parola hash algoritmasıyla işlenmelidir. Uygulamanın başka sisteme bağlanmak için ihtiyaç duyduğu veritabanı parolası veya API anahtarı ise çalışma anında geri alınması gerektiğinden secret store içinde saklanabilir. OWASP parola saklama rehberi, parolaların şifrelenmek yerine güçlü ve yavaş hash algoritmalarıyla korunmasını önerir OWASP Password Storage Cheat Sheet.
Secret'ları kod içine yazmak neden tehlikelidir?
Hardcoded secret, hassas değerin kaynak kodda, yapılandırma dosyasında, test scriptinde veya uygulama içine derlenen sabit bir metinde bulunmasıdır. Private repository kullanmak bu yöntemi güvenli hale getirmez. Repository'ye geliştirici, otomasyon, yedekleme, fork, entegrasyon ve üçüncü taraf uygulamalar erişebilir. Kod daha sonra public hale getirilebilir veya bir çalışan cihazından sızabilir.
- Secret Git geçmişinden yalnız son satır silinerek çıkarılamaz.
- Eski commit, tag, release paketi ve fork'larda kopya kalabilir.
- CI sistemi secret'ı komut satırı, hata mesajı veya debug loguna yazabilir.
- Container imajının eski katmanında silinmiş dosya bulunabilir.
- Frontend JavaScript veya mobil uygulama içine gömülen değer kullanıcı cihazına teslim edilir.
- Aynı anahtar geliştirme, test ve production ortamlarında tekrar kullanılmış olabilir.
- Secret'ın kim tarafından ve ne zaman okunduğu izlenemez.
Bir secret istemciye gönderilen kodun içinde bulunuyorsa artık secret değildir. Tarayıcı ve mobil uygulama kullanıcı tarafından incelenebildiği için sunucuya ait gizli anahtarlar bu paketlere gömülmemelidir.
GitHub push protection, desteklenen secret türlerini repository'ye ulaşmadan önce tespit ederek push işlemini engellemeyi amaçlar. Bu kontrol sızıntıyı önlemeye yardımcı olur; ancak bütün özel formatları tanıyamaz ve mevcut geçmişteki secret'ları otomatik olarak güvenli hale getirmez GitHub Push Protection.
Environment variable kullanmak yeterli midir?
Environment variable, secret'ı kaynak koddan ayırmak için yararlı bir taşıma yöntemidir; fakat tek başına secret management sistemi değildir. Değer hâlâ deployment panelinde, CI ayarında, process environment'ında veya sunucu yapılandırmasında korunmalıdır. Yetkisiz kullanıcı process bilgilerini, crash dump'ı veya yanlış loglanan ortam değişkenlerini görebiliyorsa secret sızabilir.
| Yöntem | Avantaj | Sınır veya risk | Uygun kullanım |
|---|---|---|---|
| Kod içi sabit değer | Uygulaması kolay görünür. | Repository, geçmiş ve artefaktlara yayılır. | Kullanılmamalıdır. |
| .env dosyası | Yerel geliştirmede kod ile yapılandırmayı ayırır. | Yanlışlıkla commit, yedek veya dosya izni sızıntısı olabilir. | Gerçek değer içermeyen .env.example ile birlikte kontrollü yerel geliştirme |
| Environment variable | Uygulama koduna secret yazılmasını önler. | Değerin kaynağı, rotasyonu ve erişim kaydı ayrıca yönetilmelidir. | Secret store'dan çalışma anında iş yüküne aktarım |
| CI secret alanı | Pipeline için merkezi ve maskelenmiş değer sunar. | Yetkili workflow veya üçüncü taraf action değeri okuyabilir. | Job bazlı minimum yetki ve korunan ortamlarla birlikte |
| Merkezi secret manager | Erişim politikası, audit, sürümleme ve rotasyon sağlayabilir. | Entegrasyon, erişilebilirlik ve ilk kimlik problemi doğru çözülmelidir. | Production ve birden fazla uygulama/ortam bulunan sistemler |
| Kısa ömürlü dinamik credential | Sızıntının geçerlilik penceresini azaltır. | Hedef sistemin ve uygulamanın dinamik kimliği desteklemesi gerekir. | Cloud, veritabanı ve CI/CD iş yükleri |
Merkezi secret manager nasıl çalışır?
Merkezi secret manager; secret değerlerini şifreli saklayan, uygulama ve kullanıcı erişimini politika ile denetleyen, audit kaydı tutan ve sürüm ya da rotasyon özellikleri sunan hizmettir. Uygulama kodunda gerçek secret bulunmaz. Çalışan iş yükü önce kendi kimliğiyle secret manager'a doğrulanır, yetkili olduğu değeri alır ve mümkün olduğunca bellekte kısa süre kullanır.
OWASP Secrets Management Cheat Sheet; secret oluşturma, rotasyon, iptal, süre sonu ve audit gibi yaşam döngüsü ihtiyaçlarının kuruluş çapında politika ile yönetilmesini önerir OWASP Secrets Management Cheat Sheet.
- Secret oluşturulur. Yeterli rastgelelik ve hedef sistemin gerektirdiği format kullanılır.
- Güvenli kasaya kaydedilir. Değer uygulama repository'sine veya image içine konmaz.
- Erişim politikası tanımlanır. Uygulama yalnız ihtiyaç duyduğu secret ve işlem için yetkilendirilir.
- İş yükü kimliğini kanıtlar. Cloud role, workload identity, Kubernetes service account veya benzeri yöntem kullanılır.
- Secret çalışma anında teslim edilir. SDK, sidecar, volume, agent veya environment variable üzerinden aktarılabilir.
- Kullanım kaydedilir. Hangi kimliğin hangi secret sürümünü ne zaman aldığı izlenir.
- Secret döndürülür veya iptal edilir. Uygulama yeni sürüme kesintisiz geçecek şekilde tasarlanır.
Merkezi sistemin önemli sorusu “secret manager'a giriş için gereken ilk secret nerede?” sorusudur. Uzun ömürlü bir master token'ı yine environment variable içine koymak problemi başka yere taşır. Mümkün olduğunda platformun iş yükü kimliği kullanılmalıdır. CI job'ı OIDC ile kısa süreli cloud rolü alabilir; sunucu kendi instance kimliğiyle; Kubernetes pod'u ise service account tabanlı workload identity ile doğrulanabilir.
Secret, encryption key ve configuration arasındaki fark nedir?
Her yapılandırma secret değildir ve her kriptografik anahtar aynı sistemde tutulmamalıdır. Uygulama davranışını belirleyen herkese açık endpoint veya feature flag normal configuration olabilir. API anahtarı geri alınabilir secret'tır. Yüksek değerli şifreleme anahtarları ise donanım güvenlik modülü veya key management service içinde dışarı çıkarılmadan işlem yapacak biçimde yönetilebilir.
| Bilgi türü | Örnek | Temel yönetim yaklaşımı |
|---|---|---|
| Normal configuration | Uygulama dili, herkese açık servis URL'si | Version control veya configuration yönetimi |
| Secret | API anahtarı, DB parolası, webhook signing secret | Secret manager, minimum erişim ve rotasyon |
| Kriptografik anahtar | Veri şifreleme veya imzalama anahtarı | KMS/HSM, key usage policy ve anahtar yaşam döngüsü |
| Kullanıcı parolası | Son kullanıcı login parolası | Salt içeren güçlü parola hash'i; geri okunabilir saklama değil |
| Public key veya sertifika | İmza doğrulama açık anahtarı | Bütünlük ve doğru sahiplik gerekir; gizlilik her zaman gerekmez |
En az yetki secret erişiminde nasıl uygulanır?
Tek bir production secret setini bütün geliştiricilere, uygulamalara ve CI job'larına vermek kolay yönetim gibi görünür; fakat sızıntının etkisini büyütür. Erişim uygulama, ortam, tenant ve görev bazında bölünmelidir.
- Geliştirme, test ve production için farklı secret kullanın.
- Her servis için ayrı veritabanı kullanıcısı ve API kimliği oluşturun.
- Uygulamaya yalnız ihtiyaç duyduğu secret path'lerini okuma izni verin.
- Secret oluşturma, okuma, döndürme ve silme yetkilerini ayırın.
- İnsan erişimini varsayılan olarak kapatın; gerektiğinde süreli ve onaylı erişim verin.
- CI build job'ına production deploy secret'ı vermeyin.
- Okuma yetkisini listeleme ve bütün secret'ları keşfetme yetkisinden ayırın.
- Ortak admin veya root credential yerine uygulamaya özgü minimum yetkili hesap kullanın.
Bir uygulama üçüncü taraf servislerle çalışıyorsa API entegrasyonunda her sağlayıcının anahtarı ayrı secret olarak saklanmalı ve yalnız ilgili servis erişebilmelidir. Aynı anahtarı farklı müşteri, proje veya ortamlar arasında paylaşmak iptal ve etki analizini zorlaştırır.
Secret rotasyonu nasıl planlanmalıdır?
Rotasyon, eski secret'ın yenisiyle değiştirilmesidir. Düzenli rotasyon sızmış bir değerin geçerli kalma süresini azaltabilir; ancak yanlış uygulandığında servis kesintisi oluşturur. Uygulama yalnız tek aktif parola kabul ediyorsa secret store'daki değeri değiştirmek yeterli değildir; hedef veritabanı veya API tarafındaki kimlik bilgisi de aynı süreçte güncellenmelidir.
AWS Secrets Manager, otomatik rotasyon için tek kullanıcı ve dönüşümlü kullanıcı gibi stratejiler sunar ve uygulamaların minimum yetkili veritabanı kullanıcıları kullanmasını önerir AWS Secrets Manager Best Practices.
| Rotasyon yaklaşımı | Nasıl çalışır? | Temel risk |
|---|---|---|
| Tek kullanıcı parolasını değiştirme | Aynı hesap için yeni secret hedef sistemde ve kasada güncellenir. | Eski ve yeni değer arasında eşzamanlama hatası kesinti yaratabilir. |
| Dönüşümlü iki kullanıcı | Bir kullanıcı aktifken diğerinin credential'ı yenilenir ve roller değişir. | Yetki eşitliği ve iki hesabın yaşam döngüsü doğru yönetilmelidir. |
| Kısa ömürlü dinamik credential | Her iş yükü veya oturum için süreli kimlik oluşturulur. | Hedef sistem ve uygulama yenilemeyi desteklemelidir. |
| Anahtar çifti geçişi | Yeni public key önceden yayımlanır, iki anahtar kısa süre birlikte doğrulanır. | Eski anahtarın kaldırılma zamanı ve cache'ler yönetilmelidir. |
| Olay bazlı acil rotasyon | Sızıntı şüphesinde secret hemen iptal edilip yenilenir. | Bağımlı bütün sistemler bilinmiyorsa kesinti veya eksik iptal olabilir. |
Her secret için sahip, bağlı sistem, geçerlilik süresi, rotasyon yöntemi ve rollback planı kaydedilmelidir. “Her 30 günde değiştir” gibi tek politika bütün secret türlerine uygun olmayabilir. Kısa ömürlü credential zaten otomatik yenilenirken bazı imzalama anahtarları kontrollü geçiş ve daha uzun doğrulama dönemi gerektirebilir.
CI/CD içinde secret'lar nasıl korunmalıdır?
Pipeline; kaynak kodu, paket registry'sini ve production altyapısını birleştirdiği için secret erişimi açısından kritik noktadır. Secret yalnız gerçekten ihtiyaç duyan job'a, korunan branch veya environment koşuluyla verilmelidir.
- Secret'ı workflow dosyasında veya komut satırı argümanında açık yazmayın.
- Third-party action'ların hangi secret ve token'lara erişebildiğini inceleyin.
- Fork ve güvenilmeyen pull request iş akışlarına production secret vermeyin.
- Build, publish ve deploy job'larını farklı yetkilerle ayırın.
- Uzun ömürlü cloud anahtarı yerine OIDC ile kısa süreli rol kullanın.
- Log masking'e güvenmeyin; uygulama ve script secret'ı hiçbir zaman yazdırmamalıdır.
- Secret okuma işlemini audit log ile repository, workflow ve run kimliğine bağlayın.
- Push protection ve secret scanning ile repository sızıntısını erken tespit edin.
Kubernetes Secret kullanmak tek başına yeterli midir?
Kubernetes Secret nesnesi hassas yapılandırmayı Pod tanımından ayırır; ancak varsayılan base64 gösterimi şifreleme değildir. Cluster yöneticisi etcd için encryption at rest, RBAC, namespace sınırları ve audit politikası uygulamalıdır. Kubernetes resmî rehberi; secret erişimini minimuma indirmeyi, encryption at rest kullanmayı ve gerekirse harici secret store çözümlerini değerlendirmeyi önerir Kubernetes Secrets Good Practices.
- Secret'ları Git içinde düz Kubernetes YAML olarak tutmayın.
- etcd encryption at rest yapılandırmasını doğrulayın.
- list ve watch yetkilerinin secret içeriklerine erişim sağlayabildiğini hesaba katın.
- Pod ve service account'lara yalnız ihtiyaç duyduğu secret'ı verin.
- Secret'ı environment variable yerine volume veya harici store entegrasyonuyla vermenin risklerini karşılaştırın.
- Node, kubelet, exec ve debug erişimlerini secret riski açısından sınırlandırın.
- Harici secret store kullanılıyorsa senkronizasyon ve iptal davranışını test edin.
Secret sızdığında ne yapılmalıdır?
Repository'de anahtar görülür görülmez yalnız dosyadan silmek veya commit'i değiştirmek yeterli değildir. Secret'ın kopyalanmış olabileceği varsayılmalı ve önce geçerliliği sonlandırılmalıdır.
- Secret'ı iptal edin veya döndürün. Mümkünse eski değer anında geçersiz hale getirilmelidir.
- Etkilenen sistemi belirleyin. Secret'ın hangi servis, ortam, müşteri ve yetkilere sahip olduğu çıkarılmalıdır.
- Kullanım loglarını inceleyin. Oluşturulma tarihinden itibaren beklenmeyen IP, işlem ve erişimler araştırılmalıdır.
- Kopyaları bulun. Git geçmişi, fork, CI logu, artefakt, container katmanı, ticket ve mesajlaşma kanalları taranmalıdır.
- Yeni secret'ı güvenli kanaldan dağıtın. Kod içine yeniden yazılmamalı; secret manager ve kontrollü workload identity kullanılmalıdır.
- Repository geçmişini temizleyin. Bu işlem sızıntıyı geri almaz; ancak gelecekteki kopyalamayı azaltır.
- Kök nedeni düzeltin. Push protection, pre-commit tarama, erişim politikası ve geliştirici süreci güncellenmelidir.
- Olayı kaydedin. Etki, yapılan rotasyon, log incelemesi ve takip aksiyonları dokümante edilmelidir.
Secret sızıntısında ilk hedef geçmişi estetik olarak temizlemek değil, değerin artık çalışmadığından emin olmaktır.
Secret management uygulama kontrol listesi
- Kurumdaki API anahtarı, parola, token ve özel anahtarlar envanterli mi?
- Her secret'ın sahibi, amacı, bağlı sistemi ve ortamı belli mi?
- Kaynak kod, image, frontend bundle ve mobil uygulamada hardcoded secret taranıyor mu?
- Gerçek değer içeren .env dosyaları repository dışında mı?
- Production secret'ları merkezi secret manager veya uygun key management sistemi içinde mi?
- İş yükleri uzun ömürlü master token yerine platform kimliğiyle doğrulanıyor mu?
- Geliştirme, test ve production secret'ları birbirinden ayrı mı?
- Her servis yalnız ihtiyaç duyduğu secret'a erişebiliyor mu?
- İnsan erişimleri süreli, onaylı ve audit kayıtlı mı?
- Rotasyon yöntemi uygulama kesintisi olmadan test edildi mi?
- CI/CD job'ları minimum secret ve token yetkisiyle çalışıyor mu?
- Secret değerleri log, hata mesajı ve telemetry içine yazılmıyor mu?
- Git secret scanning ve push protection kontrolleri etkin mi?
- Sızıntıda iptal, rotasyon ve etki analizi prosedürü hazır mı?
- Secret politikaları düzenli yazılım geliştirme ve bakım süreçlerinde denetleniyor mu?
Sonuç: Secret saklamak değil yaşam döngüsünü yönetmek gerekir
Secret management; hassas değeri koddan çıkarmakla başlar, fakat orada bitmez. Güvenli sistem; secret'ın kim tarafından üretildiğini, nerede saklandığını, hangi uygulamaya hangi yetkiyle verildiğini, ne zaman kullanıldığını ve nasıl döndürüleceğini bilir. Environment variable ve .env dosyası taşıma kolaylığı sağlar; merkezi erişim, audit ve rotasyon ihtiyacını tek başına karşılamaz.
En güçlü yaklaşım; merkezi secret store, workload identity, kısa ömürlü credential, minimum yetki, otomatik rotasyon, secret scanning ve hazır olay müdahalesini birlikte kullanır. Kimlik bilgilerinin güvenliği, özel yazılım mimarisinin ve CI/CD tasarımının başlangıç gereksinimi olmalıdır.
Sıkça Sorulan Sorular
API anahtarını .env dosyasında tutmak güvenli midir?
.env dosyası secret'ı kaynak koddan ayırabilir, ancak kendi başına güvenli kasa değildir. Dosya yanlışlıkla Git'e eklenebilir, yedeğe alınabilir veya sunucuda geniş dosya izinleriyle okunabilir. Yerel geliştirmede gerçek .env dosyası repository dışında tutulmalı; repository'ye yalnız değişken adlarını gösteren .env.example eklenmelidir. Production ortamında değerler merkezi secret manager'dan veya platformun korumalı secret mekanizmasından, minimum erişimle sağlanmalıdır.
Environment variable secret management için yeterli midir?
Environment variable bir teslim yöntemidir, secret management sistemi değildir. Değerin nerede saklandığı, hangi kimliğin okuyabildiği, ne zaman döndürüldüğü ve erişimin nasıl kaydedildiği ayrıca çözülmelidir. Process bilgisi, debug çıktısı, crash dump veya yanlış loglama environment variable içeriğini açığa çıkarabilir. Güvenli modelde uygulama workload identity ile secret manager'a erişir ve ihtiyaç duyduğu değeri çalışma anında alır.
Git'e yanlışlıkla eklenen secret dosyadan silinince güvende olur mu?
Hayır. Secret eski commit, branch, tag, fork, CI logu veya daha önce indirilmiş kopyalarda kalabilir. İlk işlem secret'ı sağlayıcı tarafında iptal etmek veya döndürmektir. Ardından kullanım logları incelenmeli, bağlı sistemler belirlenmeli ve yeni secret güvenli kanaldan dağıtılmalıdır. Git geçmişini temizlemek gelecekteki kopyalamayı azaltabilir; ancak daha önce görülen değeri tekrar gizli hale getirmez.
Secret'lar ne sıklıkla döndürülmelidir?
Tek bir süre bütün secret türleri için doğru değildir. Süre; secret'ın yetkisi, kullanım alanı, otomatik rotasyon desteği, sızıntı ihtimali ve kesinti riskiyle belirlenmelidir. Kısa ömürlü dinamik credential'lar dakika veya saat ölçeğinde yenilenebilir. Veritabanı parolaları kontrollü takvimle, imzalama anahtarları ise iki anahtarın birlikte doğrulandığı geçiş planıyla döndürülebilir. Sızıntı şüphesinde takvim beklenmeden acil rotasyon yapılmalıdır.
Kubernetes Secret içindeki veriler şifreli midir?
Kubernetes Secret manifestinde görülen base64 gösterimi şifreleme değildir. Cluster güvenliği için etcd üzerinde encryption at rest, sıkı RBAC, namespace ve service account sınırları, audit kayıtları ve node erişim kontrolleri gerekir. Secret verileri yalnız ihtiyaç duyan Pod'lara verilmelidir. Daha güçlü merkezi yönetim veya rotasyon gerektiğinde harici secret store ve workload identity entegrasyonu değerlendirilebilir.
Secret manager ele geçirilirse bütün secret'lar risk altında mı kalır?
Merkezi secret manager yüksek değerli bir sistemdir; bu nedenle erişim en az yetki, güçlü kimlik doğrulama, network sınırı, audit, yedekleme ve acil durum prosedürleriyle korunmalıdır. Her uygulamanın bütün secret'ları okuyabildiği tek master token kullanılmamalıdır. Uygulama bazlı policy ve kısa ömürlü workload identity, tek bir iş yükünün ele geçirilmesinde erişilebilecek secret sayısını sınırlar. Kritik anahtarlar gerekirse ayrı key management veya HSM katmanında tutulabilir.
