1. Secrets Management Nedir?
Secrets management; şifreler, API key’ler, token’lar, sertifikalar, SSH key’ler gibi hassas bilgileri güvenli saklama, güvenli paylaşma ve yaşam döngüsünü yönetme disiplinidir. “Güvenli saklamak” tek başına yetmez; kim erişebilir, ne kadar süre erişebilir, sızarsa nasıl iptal edilir ve erişimler nasıl kayıt altına alınır soruları birlikte yönetilmelidir.
Secrets management nedir, neden önemlidir?
Secrets management; hassas anahtar/parolaları merkezi bir sistemde saklayıp rol bazlı erişimle dağıtmak, düzenli rotation ve gerektiğinde revocation yapmak ve erişimleri audit log ile izlemektir. Önemlidir çünkü kod depo sızıntıları, yanlış paylaşım ve eski çalışan erişimleri en yaygın sızma yollarıdır; iyi bir secret modeli bu riskleri ciddi biçimde azaltır.
En yaygın anti-pattern’ler
- •.env dosyasının sunucular arasında kopyalanması
- •Secret’ların git’e yanlışlıkla commit edilmesi
- •“Ortak bir admin hesabı” veya ortak SSH key
- •Slack/WhatsApp/not defteri ile paylaşım
- •Loglarda token/parola görünmesi
☑ Mini Check: Secret hijyeni hızlı kontrol
- •Repo’da (.env, config, README) secret var mı?
- •Secret paylaşımı “kişiye özel” ve geri alınabilir mi?
- •Token/parola loglarda maskeleniyor mu?
- •Rotation periyodu var mı?
- •“Kim hangi secret’a erişti?” audit ile görülebiliyor mu?
Ne yapmalıyım?
- • Secret’ların envanterini çıkar (API key, token, sertifika, SSH key).
- • Git/.env/not defteri kullanımını hedef olarak bitir.
- • Vault/KMS’te merkezi sakla; RBAC ile dağıt.
- • Rotation+revocation ve audit log’u standartlaştır.
2. Parola, API Key ve Token’ları Koddan Uzak Tutmak
Bu bölümün kuralı nettir: Secret, kod değildir. Kod deposunda durmamalı, build artifact’ına gömülmemeli, image içine yazılmamalı. Secret’lar çalışma zamanında (runtime) güvenli kanal üzerinden verilmelidir.
Parola ve API key’leri kod deposunda tutmak neden risklidir?
Çünkü repo; ekip içinde geniş erişime açılır, fork/backup’lanır, CI loglarına sızabilir ve yanlışlıkla public olabilir. Secret bir kez sızdığında saldırganlar onu otomatik kullanabilir; özellikle PMS/ödeme/CRM anahtarlarında etki alanı çok büyür. Bu yüzden secret’ları repo dışına taşımak temel güvenlik kuralıdır.
“Runtime injection” yaklaşımı (prensip)
- •Uygulama çalışırken secret’ı alır (pull) veya secret güvenli şekilde push edilir
- •Secret yalnız gereken servis/ortama verilir
- •Secret’ın yaşam döngüsü ve erişimi merkezi yönetilir
Loglarda ve hata çıktılarında secret sızıntısını engellemek
Secret’lar sadece depoda değil, loglarda da sızar. Bu yüzden:
- •Token/parola maskelenir
- •Hata mesajları sanitize edilir
- •Debug log’ları prod’da kısıtlanır
☑ Mini Check: Koddan uzak tutma
- •Repo’da secret zero-tolerance (scan) var mı?
- •CI/CD loglarında secret mask’leniyor mu?
- •Docker image içinde secret yok mu?
- •Runtime’da secret injection var mı?
- •Prod debug log’ları kontrol altında mı?
Ne yapmalıyım?
- • Repo secret scan’i CI gate yap.
- • .env yerine vault/KMS + runtime injection uygula.
- • Log masking’i zorunlu kıl.
- • Prod debug seviyesini sınırlandır ve audit et.
3. Vault Çözümleri (HashiCorp Vault, KMS vb.)
Vault/KMS; secret saklamanın “güvenli kasası”dır. Pratikte iki hedefi aynı anda sağlar: (1) merkezi saklama ve erişim kontrolü, (2) audit izleri. Çözüm seçimi sağlayıcıya göre değişir; prensipler aynı kalır.
Vault/KMS çözümleriyle secrets nasıl yönetilir?
Secret’lar vault/KMS’e kaydedilir, erişim politikaları (RBAC) ile hangi rolün hangi secret’ı okuyabileceği tanımlanır. Uygulamalar runtime’da token/kimlik ile doğrulanıp sadece gerekli secret’ları çeker. Erişimler audit log’a yazılır; rotation zamanı geldiğinde secret yenilenir, gerekirse eski secret revoke edilir ve uygulamalar yeni secret’a geçirilir.
RBAC — “kim hangi secreti görebilir?”
İdeal yaklaşım:
- •İnsan kullanıcılar minimum erişime sahip
- •Uygulama servis hesapları sadece kendi secret’ını görür
- •Prod ve staging secret’ları ayrıdır
- •Ajans/partner erişimi süreli ve logludur
Rotation ve revocation (iptal) süreçleri
- •Rotation: belirli periyotta secret değiştir
- •Revocation: sızıntı şüphesinde anında iptal et
Bu ikisi “kâğıt üstünde” değil, operasyonel prosedür olmalıdır.
☑ Mini Check: Vault/KMS olgunluğu
- •RBAC politikaları rol bazlı mı?
- •Prod/stage secret ayrımı var mı?
- •Rotation takvimi ve sorumlusu var mı?
- •Revocation prosedürü (incident) hazır mı?
- •Audit log’lar erişilebilir ve korunuyor mu?
Ne yapmalıyım?
- • Rol bazlı policy çıkar: insan ≠ servis hesabı.
- • Prod secret’ları için daha sıkı erişim uygula.
- • Rotation’ı takvime bağla ve otomasyonla destekle.
- • Revocation’ı tatbik et (tabletop + teknik test).
4. Sertifika ve SSH Key Yönetimi
Secret sadece API key değildir; sertifikalar ve SSH key’ler de kritik kimlik materyalidir. Sertifika süreleri bittiğinde kesinti olur; SSH key’ler paylaşıldığında iz kaybolur. Bu yüzden yaşam döngüsü yönetimi şarttır.
Sertifika yaşam döngüsü
- •Envanter: hangi domain/subdomain, nerede kullanılıyor?
- •Yenileme: otomasyon ve uyarı
- •Dağıtım: doğru ortama doğru sertifika
- •İptal: sızıntıda revocation
SSH key yaşam döngüsü
- •Kişi bazlı key, paylaşım yok
- •Süreli erişim ve offboarding
- •Oturum kayıtları (bastion/SSM gibi) ile audit
Sertifika/SSH key ile KVKK ve erişim izleri
Kişisel veri erişimi olan sistemlerde “kim erişti?” sorusunu yanıtlamak önemlidir. Bu nedenle key/sertifika kullanım izleri ve erişim logları KVKK teknik tedbirleriyle uyumlu şekilde saklanmalıdır (Internal link: /tr/raporlama/kvkk-veri-guvenligi, /tr/yazilim/kvkk-uyum-hizmeti).
☑ Mini Check: Sertifika + SSH key
- •Sertifika envanteri ve yenileme alarmı var mı?
- •SSH key’ler kişi bazlı mı?
- •Offboarding’de key iptali otomatik mi?
- •Oturumlar kayıt altına alınıyor mu?
- •Audit log’lar KVKK uyumlu saklanıyor mu?
Ne yapmalıyım?
- • Sertifika ve SSH key envanteri çıkar.
- • Yenileme/rotasyon otomasyonu + alarm kur.
- • Paylaşılan key kullanımını bitir; kişi bazlı model.
- • Erişim loglarını audit için merkezi topla ve koru.
5. Otel ve B2B İçin Secrets Politika Örnekleri
Bu bölüm, politika dilini “iş bağlamı”na bağlar: PMS/OTA, CRM, ödeme anahtarları en kritik secret’lardır. Ayrıca ajans/partner erişimi olan projelerde paylaşım kültürü risk yaratır; policy bunu standardize eder.
Otel örneği — PMS/OTA API key’leri
- •Her entegrasyon için ayrı key
- •Scope/izin minimal
- •Vault/KMS’ten runtime çekme
- •Rotation periyodu + sızıntı prosedürü
- •Kim erişti: audit log
B2B örneği — CRM ve payments API key’leri
- •Prod ve staging ayrımı
- •Token’lar kısa ömürlü (mümkünse)
- •Export/rapor gibi işlerde secret’lar log’a düşmez
- •Revocation hızlı (incident runbook)
Otel ve B2B entegrasyonları için secrets politikası nasıl olmalı?
Politika; secret’ların repo/.env’de tutulmasını yasaklamalı, vault/KMS kullanımını zorunlu kılmalı, erişimi rol bazlı sınırlandırmalı, rotation periyodu ve revocation prosedürü tanımlamalı ve tüm erişimleri audit log’la kayıt altına almalıdır. Prod secret’ları için daha sıkı yetki ve daha güçlü izleme uygulanmalıdır.
Fark yaratan mini bölüm (Competitor Gap): “Eski çalışan erişimi” ve paylaşılmış secret riski
Birçok sızıntı “kötü niyetli dış saldırgan” kadar, eski çalışan/ajans erişiminin açık kalmasından doğar. Bu yüzden offboarding; secret revocation ve rol iptaliyle otomatikleşmelidir. Sheet’teki sektörel notla uyumlu şekilde, vault/KMS’e geçen ekiplerde repo sızıntısı kaynaklı ifşa vakalarının azaldığı sık raporlanır.
☑ Mini Check: Politika uygulanabilir mi?
- •Repo/.env yasağı net mi ve CI ile denetleniyor mu?
- •RBAC rolleri tanımlı mı?
- •Rotation periyotları yazılı mı?
- •Revocation runbook’u var mı?
- •Audit log ile “kim erişti” cevabı var mı?
Ne yapmalıyım?
- • Secrets policy yaz: saklama, paylaşma, rotation, revocation.
- • Denetimi otomatikleştir: repo secret scan + pipeline gate.
- • Prod secret’ları için ayrı sıkı policy uygula.
- • KVKK uyum hizmetiyle erişim izlerini teknik tedbire bağla (Internal link: /tr/yazilim/kvkk-uyum-hizmeti).
6. İçerik İçi Tablo: Secret Türleri ve Rotation Periyotları
| Secret türü | Örnek | Rotation periyodu (çerçeve) | Not |
|---|---|---|---|
| API key | PMS/OTA, CRM | Aylar (ör. 90–180 gün) | Sızıntıda anında revoke |
| Access token | OAuth token | Kısa (dakika–saat) | Mümkünse kısa ömürlü |
| Parola | DB/app admin | Aylar | MFA + erişim log’u |
| Sertifika | HTTPS sertifikası | Süre bitimine göre | Auto-renew + alarm |
| SSH key | Admin erişimi | Periyodik gözden geçirme | Kişi bazlı, paylaşım yok |
Varsayım: Periyotlar altyapı kritiklik ve sağlayıcı kısıtlarına göre değişir; tablo “prensip” çerçevesidir.
7. Parola & API Key Yönetimi için Vault/KMS Planlama Şablonunu İndir
Parola & API Key Yönetimi için Vault/KMS Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon; secret’ları repo/.env’den çıkarıp vault/KMS’e taşıma, rol bazlı erişim politikası kurma ve rotation/revocation süreçlerini standartlaştırma için hazırlanmıştır. PMS/OTA, CRM ve ödeme entegrasyonlarında “kritik key” riskini azaltır. Audit log’larla erişimleri izleyip KVKK teknik tedbirlerini destekler.
Kim Kullanır?
DevOps/Backend, güvenlik/ops, otel IT ve B2B entegrasyon ekipleri.
Nasıl Kullanılır?
- Secret envanterini çıkar ve risk sınıfını işaretle.
- RBAC politikası ve erişim akışını yaz; runtime injection planını ekle.
- Rotation periyotları, revocation runbook’u ve audit log kurallarını tanımla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Secret’lar repo/.env’de değil
- ▢ ✅ Prod/stage ayrımı var
- ▢ ✅ RBAC rol matrisi hazır
- ▢ ✅ Rotation takvimi var
- ▢ ✅ Revocation runbook test edildi
- ▢ ✅ Audit log ile erişim izleniyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
6) Kontrol listesi
- •Secret’lar repo/.env’de değil
- •Prod/stage ayrımı var
- •RBAC rol matrisi hazır
- •Rotation takvimi var
- •Revocation runbook test edildi
- •Audit log ile erişim izleniyor
Deliverables
- •Secret envanteri ve risk sınıflandırması
- •Vault/KMS saklama ve runtime dağıtım planı
- •RBAC rol matrisi
- •Rotation takvimi
- •Revocation incident runbook’u
- •Audit logging ve KVKK erişim politikası
Bir Sonraki Adım
PMS/CRM/ödeme entegrasyonlarında secret sızıntısı riskini azaltıp, RBAC+rotation ile denetlenebilir secret yönetimi kurmak isteyen otel ve B2B ekipleri için.