Secrets Management (Sır Yönetimi)

1. Giriş

Bu kitap boyunca defalarca "bu anahtar/sır bir sır yöneticisinde saklanmalı" dedik — parola hash pepper'ı (Bölüm 13), JWT imzalama sırrı (Bölüm 23), OAuth client_secret'ı (Bölüm 24), veritabanı bağlantı bilgisi, üçüncü taraf API anahtarları. Bu bölüm o vaadi yerine getirir ve sır yönetimini bir disiplin olarak ele alır.

Sır yönetiminin merkezî gerilimi şudur: sırlar, uygulamaya çalışma zamanında erişilebilir olmalı ama saldırgana ifşa olmamalı. Bu ikisi çelişir gibi görünür ve çözülme biçimi — sırların nerede ve nasıl saklandığı — güvenliğin belirleyici bir parçasıdır. Yanlış çözüm (sırrı koda gömmek), tarihin en büyük ihlallerinden bazılarına yol açmıştır.

Bunun ders kitabı örneği Uber'in 2016 ihlalidir (Bölüm 11): bir mühendisin özel GitHub deposundaki koda gömülü AWS kimlik bilgileri, saldırganların bir S3 kovasına erişip 57 milyon kullanıcının verisini indirmesine yol açtı. Dahası, o anahtar 2013'te oluşturulmuş ve rotasyonu gecikmişti; ve Uber olayı bir yıl boyunca gizledi — güvenlik sorumlusu (CSO) sonradan bu gizleme nedeniyle mahkûm edildi. Bu tek vaka, sır yönetiminin üç temel dersini — koda gömme, rotasyon yap, en az yetki — ve bir bonus dersi (gizleme her şeyi kötüleştirir, Bölüm 32) barındırır.

---

2. Temel Teori

Sır nedir? Uygulamanın işlevi için gerekli, ifşa olursa güvenliği çökerten her gizli değer:

Sır türü	Örnek
Kimlik bilgileri	DB parolası, bulut (AWS/GCP) anahtarları, SSH/servis hesapları
API anahtarları	Ödeme (Stripe), e-posta, üçüncü taraf servisler
İmzalama anahtarları	JWT HMAC sırrı / özel anahtar (Bölüm 23), OAuth client_secret (Bölüm 24)
Şifreleme anahtarları	AES/libsodium anahtarları (Bölüm 13), pepper
TLS özel anahtarları	Sunucu sertifikası özel anahtarı
Token'lar	Kalıcı erişim token'ları, webhook sırları

Temel gerilim. Sır çalışma zamanında gereklidir (uygulama DB'ye bağlanmalı, API çağırmalı) ama saldırgana açık olmamalıdır. Çözüm, sırrı nerede sakladığınıza bağlıdır — ve yaygın "kolay" çözümlerin çoğu yanlıştır.

Sırların bulunmaması gereken yerler (anti-desenler):

Anti-desen	Neden felaket
Koda gömülü	Version control'e girer → sızar (Uber). "Özel repo" bile sızar
Version control'de (.env commit'li)	Git geçmişi sonsuza dek tutar; silmek yetmez
İstemci kodunda (JS/mobil)	Tamamen ifşa; frontend'deki sır sır değildir
Loglarda / hata mesajlarında / URL'de	Sızıntı kanalları
Container imajında (baked-in)	İmaja erişen sırra erişir
Gevşek izinli düz-metin config'de	Sunucuya erişen okur

.env — bir adım, ama son değil. Yaygın kalıp: sırları bir .env dosyasına koyup ortam değişkeni (environment variable) olarak yüklemek ve .env'i asla commit etmemek (.gitignore). Bu, koda gömmekten iyidir ama yeterli değildir: ortam değişkenleri de sızabilir — süreç listeleme, /proc/<pid>/environ, hata dökümleri, alt süreçlere miras, ve SSRF ile bulut metadata'sının (Bölüm 21) ortamı ifşa etmesi. .env bir başlangıçtır; olgun çözüm sır yöneticisidir.

Sır yöneticileri (doğru çözüm). HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault gibi araçlar: - Merkezî, şifreli saklama (encryption at rest). - Erişim kontrolü (IAM — her uygulama/servis yalnızca gerekli sırlara erişir; en az yetki). - Denetim logu (kim, hangi sırra, ne zaman erişti). - Dinamik sırlar (kısa ömürlü, talep üzerine üretilen — statik sır sızıntısını azaltır). - Otomatik rotasyon.

Uygulama, sırları çalışma zamanında kimlik doğrulamalı bir API ile çeker; sır kodda/git'te kalıcı olarak durmaz.

Dört temel pratik: 1. Asla gömme/commit etme. .gitignore + pre-commit sır tarama (gitleaks, trufflehog). 2. Sır yöneticisi kullan. 3. Rotasyon. Düzenli ve şüpheli sızıntıda hemen. (Uber'in anahtarı rotasyonu gecikmişti.) 4. En az yetki. Her sır minimal kapsamlı (Bölüm 1, 21). Tek bir "tam admin" anahtarı (Uber 2014) felakettir.

---

3. Mimarisel Bakış

 GÜVENSİZ (koda gömülü — Uber kalıbı):
   Kaynak kod: $awsKey = "AKIA..."; $secret = "..."
        ↓  git commit → version control (özel repo bile)
   Saldırgan → repo erişimi (çalınan GitHub kimliği) → anahtarı okur
        ↓
   Bulut (S3) erişimi → veri sızdırma (57M kayıt)
        ✗ üstelik anahtar rotasyonu gecikmiş + tam-admin yetkili

 GÜVENLİ (sır yöneticisi):
   Kod: $secret = SecretsManager::get('db/password')   ← çalışma zamanında çekilir
        ↓  kimlik doğrulamalı (IAM), denetim loglu, en az yetkili
   Sır yöneticisi (şifreli saklama) → sırrı döndürür
        ↓  sır kodda/git'te YOK; kısa ömürlü/rotasyonlu
   → sızıntı yüzeyi minimal

 SIZINTI TESPİTİ:
   git commit → pre-commit hook (gitleaks) → sır tespit edilirse ENGELLE
   repo → sürekli sır tarama (GitHub secret scanning) → alarm + otomatik rotasyon

Kritik gözlem: sır kaynak kodda/git'te hiç bulunmamalı; çalışma zamanında güvenli bir kaynaktan çekilmeli. Ve sızıntı kaçınılmaz varsayılıp rotasyon + en az yetki ile hasar sınırlanmalı (derinlemesine savunma, Bölüm 1).

---

4. Güvensiz Kod

Gerçekçi bir yapılandırma ve bağlantı katmanı:

<?php
// ⚠️ GÜVENSİZ — koda gömülü sırlar
declare(strict_types=1);

// 1) Koda gömülü kimlik bilgileri (Uber hatası)
$db = new PDO('mysql:host=db;dbname=app', 'root', 'P@ssw0rd123');  // repo'ya girer
$stripeKey = 'sk_live_51H...';                    // ödeme anahtarı kodda!
$jwtSecret = 'my-super-secret-key';               // JWT sırrı kodda (Böl. 23)

// 2) config.php commit edilmiş (git geçmişinde sonsuza dek)
require 'config.php';                              // içinde düz-metin sırlar, git'te

// 3) Sırrı loglama / hata mesajı
error_log("DB bağlantısı: root:P@ssw0rd123@db");  // loglara sızar

// 4) İstemciye sır gönderme
echo "<script>const API_KEY = '$stripeKey';</script>";  // frontend'de = ifşa

// 5) Tek, tam-yetkili bulut anahtarı (Uber 2014 kalıbı)
// tüm servisler aynı "full admin" AWS anahtarını kullanıyor (en az yetki yok)

---

5. Açığın Analizi

Koda gömülü kimlik bilgileri — Uber ihlalinin ta kendisi. $db parolası, $stripeKey, $jwtSecret kodda yazılı. Kod version control'e girdiğinde bu sırlar da girer; repo'ya erişen (çalınan GitHub kimliğiyle, iç tehditle, yanlış-public repo ile) hepsini okur. GitHub'ı tarayan botlar, commit edilen bir AWS/Stripe anahtarını saniyeler içinde bulur.

config.php commit edilmiş — Sır bir config dosyasında olsa da, dosya git'e girdiyse git geçmişi onu sonsuza dek tutar. Sonradan silmek yetmez; geçmişte kalır ve git log/git show ile geri getirilir. Bu yüzden bir sır bir kez commit edildiyse, sızmış sayılmalı ve rotasyona sokulmalıdır — sadece silmek değil.

Sırrı loglama — error_log'a parola yazmak, sırrı log dosyalarına (ve merkezî log/SIEM'e) sızdırır. Sırlar asla loglanmaz.

İstemciye sır gönderme — Frontend'e (JS) bir API anahtarı koymak, onu tümüyle ifşa eder; herkes "görüntüle kaynak" ile okur. Frontend'deki bir sır, sır değildir. İstemcinin sırra ihtiyacı varsa, mimari yanlıştır (istek arka uçtan proxy'lenmeli).

Tek, tam-yetkili anahtar — Uber 2014 kalıbı: tüm servisler tek bir "full admin" AWS anahtarını paylaşıyor. Bu anahtar sızarsa her şey açılır. En az yetki (Bölüm 1, 21) ve anahtar ayrımı yok.

Kök sorun: sırlar kodda/git'te/loglarda/istemcide — yani sızıntıya açık her yerde — ve tek/aşırı yetkili/rotasyonsuz. Çözüm: sırları çalışma zamanında güvenli bir kaynaktan çekmek, rotasyon ve en az yetki.

---

6. Hacker Bakış Açısı

Saldırgan sırları nasıl arar?

Version control'ü tarar. İlk ve en verimli hedef: kaynak kod depoları. Public repo'lar botlarla otomatik taranır (AWS/Stripe/Google anahtar desenleri saniyeler içinde bulunur). Özel repo'lara erişildiğinde (çalınan geliştirici kimliği, sızmış CI token'ı, iç tehdit) aynı tarama yapılır. Git geçmişi özellikle değerlidir: silinmiş ama commit'lenmiş sırlar orada durur.

Yan kanalları toplar. Ortam değişkenleri (/proc/<pid>/environ, hata dökümleri, phpinfo()), loglar, yedek dosyalar (.env.bak, config.php~), açıkta kalan .git/ dizini (web'den .git/config/geçmiş indirme), frontend JS, container imaj katmanları.

SSRF ile metadata çeker. Bir SSRF (Bölüm 21) ile bulut metadata'sından geçici kimlik bilgilerini (ve bazen ortam değişkenlerini) alır — Capital One kalıbı.

Sızmış sırrı sömürür. Bir bulut anahtarı bulduğunda, yetkisini keşfeder ve en yüksek etkiye ulaşır: veri deposuna erişim (S3), yeni kaynak oluşturma (cryptominer), yanal hareket. Anahtar aşırı yetkiliyse (Uber 2014) tek anahtar tüm hesabı açar.

Rotasyonsuzluğu sever. Uzun ömürlü, hiç döndürülmemiş statik anahtarlar en değerli hedeftir; bir kez çalındığında süresiz kullanılır (Uber'in 2013 anahtarı).

Savunmacı dersi: Saldırgan için sırlar "kaynak koddan bulut hesabına giden en kısa yoldur". Savunma, sırrı sızabileceği her yerden (kod, git, log, istemci, imaj) uzak tutmalı ve sızıntı kaçınılmaz varsayılıp rotasyon + en az yetkiyle hasarı sınırlamalıdır.

---

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. Sır sızıntısının neden bu kadar yıkıcı olduğu kavramsaldır:

• Doğrudan ve kademesiz erişim. Bir sır (özellikle bulut/DB kimliği), saldırgana meşru bir kullanıcı/servis yetkisiyle doğrudan erişim verir. Ara açık aramaya gerek kalmaz; anahtar kapıyı açar. Uber'de sızmış AWS anahtarı doğrudan 57M kayda erişim demekti.
• Kalıcılık ve iz bırakmama. Çalınan bir kimlikle yapılan erişim, meşru erişimden ayırt edilemez; klasik alarmları tetiklemez. Rotasyon yoksa süresiz sürer.
• Git geçmişinin kalıcılığı. Bir sır bir kez commit'lendiğinde, silinse bile geçmişte kalır; "sildim" güvenlik sağlamaz. Bu yüzden tek doğru yanıt rotasyondur.
• En az yetki etkiyi belirler (Bölüm 1, 21). Sızan anahtarın yetkisi ne kadar genişse etki o kadar büyüktür. Tek "full admin" anahtar (Uber 2014) = tek nokta felaketi.
• Zincir başlangıcı. Sır sızıntısı sıklıkla daha büyük ihlallerin ilk halkasıdır (SSRF→metadata→kimlik→veri; Capital One).

Araştırmacının çerçevesi: (a) sırlar kodda/git'te/logda/istemcide mi, (b) rotasyon var mı, (c) sızan sırrın yetkisi ne kadar geniş. Savunma sırrı sızıntı yüzeyinden çeker, rotasyonla ömrünü sınırlar, en az yetkiyle etkisini daraltır.

---

8. Güvenli Kod

Sırları çalışma zamanında güvenli kaynaktan çeken sürüm:

<?php
// ✅ GÜVENLİ — sırlar koddan/git'ten ayrı
declare(strict_types=1);

// 1) Geliştirme: .env (ASLA commit edilmez — .gitignore) → ortam değişkeni
//    Üretim: sırlar ortama sır yöneticisinden enjekte edilir
$dbPass    = getenv('DB_PASSWORD') ?: throw new RuntimeException('DB_PASSWORD yok');
$jwtSecret = getenv('JWT_SECRET')  ?: throw new RuntimeException('JWT_SECRET yok');

// 2) Daha olgun: sır yöneticisinden çalışma zamanında çekme (kavramsal)
//    AWS Secrets Manager / Vault SDK ile:
$stripeKey = SecretsManager::get('payments/stripe/live');   // IAM'li, denetim loglu
//    → sır kodda/env'de kalıcı durmaz; kısa ömürlü/dinamik olabilir

$db = new PDO('mysql:host=db;dbname=app', 'app_user', $dbPass);   // app_user: en az yetki

// 3) Sırları ASLA loglama / istemciye gönderme
// error_log("...$dbPass...");   ← YAPMA
// echo "const KEY='$stripeKey'"; ← YAPMA (frontend'de sır olmaz; arka uçtan proxy'le)

// 4) Sır tespit edilirse fail-fast (eksik sır sessizce boş kalmasın)

Depo ve süreç hijyeni (kod dışı ama kritik):

# .gitignore — sırları içeren dosyalar ASLA commit edilmez
.env
.env.*
!.env.example        # yalnızca ANAHTAR ADLARI (değerler YOK) örneği commit edilir
config/secrets.php
*.pem
*.key

# pre-commit / CI — sır tarama (gitleaks / trufflehog)
- repo: gitleaks
  hooks: [gitleaks]    # commit'te sır varsa ENGELLE

Öne çıkan modern pratikler: - Sırları koddan ayır: Ortam değişkeni (.env, gitignore'lu) asgari; olgun çözüm sır yöneticisi (Vault/AWS Secrets Manager). - .env asla commit edilmez: .gitignore + yalnızca .env.example (değersiz anahtar adları). - Sır yöneticisi: Merkezî, şifreli, IAM'li, denetim loglu, rotasyonlu, dinamik sırlar. - Rotasyon: Düzenli + şüpheli sızıntıda hemen. Kısa ömürlü/dinamik sırlar tercih. - En az yetki (Bölüm 1, 21): Her sır/kimlik minimal kapsamlı; tek "full admin" anahtar yok; ayrı servis kimlikleri. - Sır tarama: Pre-commit hook (gitleaks/trufflehog) + sürekli repo tarama (GitHub secret scanning). Botlar zaten tarıyor; siz de tarayın. - Loglama/istemci yasağı: Sırlar loglanmaz, hata mesajlarında görünmez, istemciye gönderilmez (.git/ dizini web'de açık olmaz). - Fail-fast: Eksik sır sessizce boş kalmasın; uygulama başlamasın. - Sızmış sır = rotasyon: Git'ten silmek yetmez; sırrı döndür (aşağıda).

---

9. Patch Analizi

Neden işe yarar? Sırları koddan/git'ten ayırmak, en büyük sızıntı yüzeyini (version control) kapatır. Sır yöneticisi, şifreli saklama + IAM erişim kontrolü + denetim logu + rotasyon ile sırrı hem korur hem izler. Rotasyon, sızsa bile sırrın ömrünü sınırlar. En az yetki (Bölüm 1, 21), sızan sırrın etkisini daraltır. Bunlar birlikte "sızıntı kaçınılmaz" gerçeğini kabul edip derinlemesine savunma (Bölüm 1) uygular: sızıntı yüzeyini küçült, ömrü sınırla, etkiyi daralt.

Çözümlerin olgunluk basamağı:

Yaklaşım	Olgunluk	Not
Koda gömülü	✗ Felaket	Uber; git'e girer, kalıcı
Commit'li config/.env	✗	Git geçmişi tutar
.env (gitignore'lu) + env var	~ Asgari	Env sızıntısına açık ama koddan iyi
Sır yöneticisi (statik)	✓ İyi	Merkezî, şifreli, IAM, denetim
Sır yöneticisi (dinamik/kısa ömürlü)	✓✓ En iyi	Rotasyon otomatik, sızıntı penceresi minimal

Sızmış sır — neden rotasyon şart: Git geçmişi bir sırrı sonsuza dek tutar; commit'i silmek/geçmişi yeniden yazmak bile "sır zaten görülmüş olabilir" gerçeğini değiştirmez. Bu yüzden bir sır bir kez ifşa olduysa derhal döndürülmeli (eski değer geçersiz kılınmalı). Uber'in anahtarı rotasyonu gecikmiş uzun-ömürlü bir statik anahtardı; dinamik/kısa-ömürlü olsaydı sızıntı penceresi çok daralırdı.

Performans: Sır yöneticisinden çekme, başlangıçta küçük bir gecikme ekler (önbelleklenebilir); çalışma-zamanı etkisi ihmal edilebilir. Güvenlik kazancı çok büyüktür.

---

10. Gerçek Hayat Senaryosu

Kurgu — hızlı büyüyen bir startup. Ekip, hıza öncelik verip DB parolasını, Stripe canlı anahtarını ve JWT sırrını doğrudan config.php'ye yazıp repo'ya commit ediyor. Repo "özel" olduğundan güvenli sanılıyor. Aylar sonra, bir geliştiricinin kişisel cihazı ele geçiriliyor ve GitHub kimliği çalınıyor; saldırgan özel repo'ya erişip tüm sırları — ve git log ile geçmişte silinmiş eski sırları da — topluyor. Stripe anahtarıyla sahte iadeler, JWT sırrıyla token forge (Bölüm 23), DB kimliğiyle veri sızdırma yapıyor. Dersler: (1) "özel repo" bir güven sınırı değildir; sırlar koda/git'e hiç girmemeli; (2) git geçmişi sonsuz hafızadır — sızmış sır rotasyona sokulmalı; (3) sır yöneticisi + en az yetki + rotasyon, tek bir çalınan kimliğin etkisini sınırlardı.

---

11. Gerçek Vaka Analizi — Uber İhlali (2016, 57 milyon kayıt)

ABD Adalet Bakanlığı, Bloomberg, FTC ve TechTarget/CyberScoop ile doğrulanmıştır. Koda gömülü sırların ders kitabı vakasıdır.

Özet. Ekim 2016'da iki saldırgan (Brandon Glover, Vasile Mereacre), Uber'in özel GitHub deposuna çalınan kimlik bilgileriyle erişti; depodaki koda gömülü AWS kimlik bilgilerini bulup bir S3 kovasına ulaştı ve 57 milyon kullanıcının (ad, e-posta, telefon) ve 600.000 ABD sürücüsünün ehliyet numarası verisini indirdi. Uber, saldırganlara HackerOne üzerinden 100.000 dolar "ödül" (hush money) ödeyip bir NDA imzalatarak olayı bir yıl gizledi. 2017'de yeni yönetim olayı açıkladı; CSO Joe Sullivan ve bir avukat kovuldu. Sullivan 2022'de gizleme nedeniyle mahkûm edildi; Uber çok-eyaletli ~148 milyon dolarlık uzlaşma imzaladı.

Teknik neden — üç sır-yönetimi hatası (+ bir bonus). 1. Koda gömülü, version control'de sırlar. AWS kimlik bilgileri bir mühendisin özel GitHub deposunda yazılıydı. "Özel repo" güvence sağlamadı: saldırganlar çalınan GitHub kimlikleriyle erişti. (Uber'in 2014'teki benzer ihlali public bir repo'daydı — aynı hata, iki kez.) 2. Rotasyon eksikliği. İhlalde kullanılan AWS erişim anahtarı 2013'te oluşturulmuş ve rotasyonu planlanmış ama yapılmamıştı. Uzun-ömürlü statik anahtar, çalındığında hâlâ geçerliydi. Kısa-ömürlü/rotasyonlu bir sır sızıntı penceresini daraltırdı. 3. En az yetki ihlali. (Özellikle 2014 vakasında belgelenen desen:) Uber, uzun süre tüm program ve mühendislerin tek bir tam-yönetici AWS anahtarını kullanmasına izin vermişti. Tek anahtar tüm veri deposunu açıyordu — Capital One'daki (Bölüm 21) aşırı-yetki dersinin ikizi. 4. Bonus: gizleme (Bölüm 32). Sırrın sızması kötüydü; ama asıl skandal, olayın bir yıl gizlenmesi ve saldırganlara "ödül" kılıfında para ödenmesiydi. CSO'nun mahkûmiyeti, açıklama etiğinin (Bölüm 32) hukuki bir zorunluluk olduğunu gösterdi.

Ek bir ayrıntı öğreticidir: Uber yedeklerinin çoğu istemci-taraflı şifreliydi, ama saldırganlar elle oluşturulmuş, şifresiz (ya da anahtarın çözebildiği) tek bir yedek buldu — "bir istisna tüm korumayı çökertir" (Bölüm 13, Adobe dersiyle aynı).

Etki. 57 milyon kayıt + 600.000 ehliyet; ~148 milyon dolar uzlaşma; CSO mahkûmiyeti; kalıcı itibar kaybı. Bloomberg'in aktardığı uzman yorumu net: "GitHub üzerinden geliştiriciler sürekli, çoğu zaman farkında olmadan kimlik bilgisi paylaşıyor."

Çıkarılacak dersler: 1. Sırları asla koda gömme/commit etme. "Özel repo" bir güven sınırı değildir; git geçmişi kalıcıdır. 2. Rotasyon yap. Uzun-ömürlü statik anahtarlar birer zaman bombasıdır; kısa-ömürlü/dinamik sırlar ve düzenli rotasyon şarttır. 3. En az yetki (Bölüm 1, 21). Tek tam-yetkili anahtar felakettir; sırlar minimal kapsamlı ve ayrık olmalı. 4. Sır yöneticisi kullan. Vault/AWS Secrets Manager, bu üç dersi yapısal olarak uygular. 5. Doğru açıkla (Bölüm 32). Gizleme her şeyi kötüleştirir — hukuki ve etik olarak.

---

12. Detection

Kod/repo incelemede: Gömülü sırları ve commit'li sır dosyalarını arayın:

# Yaygın sır desenleri (basit tarama; olgun araç için gitleaks/trufflehog)
grep -rnE "(AKIA[0-9A-Z]{16}|sk_live_|-----BEGIN.*PRIVATE KEY)" .
grep -rnE "(password|secret|api[_-]?key|token)\s*=\s*['\"]" src/ config/
git log -p | grep -iE 'password|secret|AKIA|sk_live'   # GEÇMİŞTEKİ sırlar
find . -name '.env' -not -path './.git/*'              # commit'lenmiş .env?
git ls-files | grep -E '\.env$|\.pem$|\.key$'          # git'te sır dosyası var mı?

Kontroller: sır kodda/git'te var mı? .env gitignore'da mı? Git geçmişinde sır var mı? Sır yöneticisi kullanılıyor mu?

SAST/sır tarama: gitleaks, trufflehog, GitHub secret scanning — commit ve geçmişteki sırları (yüksek doğrulukla, desen + entropi) yakalar. Pre-commit hook ile engelleme en etkilisidir.

SCA/CI: CI loglarında/artefaktlarında sır sızıntısı; container imaj katmanlarında gömülü sır taraması.

Loglar/SIEM: Sızmış kimlik kötüye kullanımı — Uber'de olduğu gibi bilinen altyapı dışından gelen bulut erişimi; olağandışı bölge/saat/hacimde API çağrıları; sır yöneticisi denetim loglarında anormal erişim. Bulut denetim logları (CloudTrail) + anomali, sır kötüye kullanımını yakalar.

---

13. Prevention

• Asla gömme/commit etme: .gitignore + .env.example (değersiz); pre-commit sır tarama (gitleaks).
• Sır yöneticisi kullan: Vault/AWS Secrets Manager — merkezî, şifreli, IAM, denetim, rotasyon, dinamik sırlar.
• Rotasyon: Düzenli + şüpheli sızıntıda derhal; kısa-ömürlü/dinamik sırları tercih et.
• En az yetki (Bölüm 1, 21): Minimal kapsam; ayrı servis kimlikleri; tek tam-admin anahtar yok.
• Sır tarama: Repo + CI + container sürekli taranır (botlar zaten tarıyor).
• Loglama/istemci yasağı: Sır loglanmaz, hata mesajında/istemcide görünmez; .git/ web'de kapalı.
• Fail-fast: Eksik sır sessiz boş kalmaz; uygulama başlamaz.
• Doğru açıklama (Bölüm 32): Sızıntıyı gizleme; şeffaf ve zamanında bildir.

---

14. Mitigation

• Acil (sır sızdıysa): Sırrı derhal döndür (eski değeri geçersiz kıl) — git'ten silmek yetmez, sızmış say. Etkilenen servisleri yeni sırla güncelle.
• Geçici: Bulut denetim loglarından (CloudTrail) sızmış sırrın kötüye kullanım kapsamını belirle; oluşturulan kaynakları/erişimleri incele ve geri al; aşırı-yetkili kimlikleri daralt.
• Kalıcı: Sırları sır yöneticisine taşı; rotasyon + en az yetki + dinamik sırlar; pre-commit + sürekli sır tarama; git geçmişini temizle (yine de rotasyon şart); açıklama sürecini (Bölüm 32) hazır tut.

---

15. Checklist

• [ ] Hiçbir sır kaynak kodda gömülü değil mi?
• [ ] .env (ve .pem/.key) .gitignore'da ve git'e hiç girmemiş mi?
• [ ] Git geçmişi sır içermiyor mu (tarandı mı)?
• [ ] Sırlar bir sır yöneticisinde mi (şifreli, IAM, denetim, rotasyon)?
• [ ] Rotasyon uygulanıyor mu (düzenli + sızıntıda derhal); kısa-ömürlü/dinamik sır mümkün mü?
• [ ] Her sır/kimlik en az yetkili mi (tek tam-admin anahtar yok — Bölüm 1, 21)?
• [ ] Pre-commit + sürekli sır tarama (gitleaks/GitHub secret scanning) var mı?
• [ ] Sırlar loglanmıyor, hata mesajında/istemcide görünmüyor mu? .git/ web'de kapalı mı?
• [ ] Sızmış bir sır için "derhal rotasyon" prosedürü hazır mı?

---

16. Laboratuvar

Lab 25.1 — Git geçmişi sızıntısı. İzole bir repo'ya bir "sır" commit et, sonra sil ve yeni bir commit yap. git log -p/git show ile sırrın geçmişte hâlâ durduğunu göster. "Silmek yetmez, rotasyon şart" dersini yaz.

Lab 25.2 — Sır tarama. gitleaks/trufflehog'u bir repo üzerinde çalıştır; gömülü sırları yakala. Pre-commit hook kurup sır içeren bir commit'in engellendiğini gözlemle.

Lab 25.3 — .env ve gitignore. Sırları .env'e taşı, .gitignore'a ekle, yalnızca .env.example (değersiz) commit et. Uygulamanın getenv ile sırrı okuduğunu ve .env'in izlenmediğini doğrula.

Lab 25.4 — En az yetki (kavramsal). Tek "full admin" bir kimlik vs iki ayrı, minimal-kapsamlı kimlik senaryosunu karşılaştır; sızıntıda etkinin nasıl daraldığını (Bölüm 21'e atıfla) yaz.

---

17. Quiz

1. Sır nedir? En az beş sır türü sayın.
2. Sır yönetiminin "merkezî gerilimi" nedir?
3. Sırların bulunmaması gereken beş yeri sayın ve her birinin neden tehlikeli olduğunu açıklayın.
4. .env neden "bir adım ama son değil"dir? Ortam değişkenleri nasıl sızabilir?
5. Bir sır git'e bir kez commit edildiyse neden silmek yetmez? Doğru yanıt nedir?
6. Sır yöneticisi (Vault/Secrets Manager) hangi beş şeyi sağlar?
7. "Frontend'deki bir sır, sır değildir" ne demektir? İstemcinin sırra ihtiyacı varsa doğru mimari nedir?
8. Rotasyon neden kritiktir? Uber'in anahtarında hangi rotasyon hatası vardı?
9. En az yetki (Bölüm 1, 21) sır sızıntısının etkisini nasıl sınırlar? Uber 2014'teki ihlal neydi?
10. Uber ihlalindeki üç sır-yönetimi hatası nelerdi?
11. Uber vakasının "gizleme" boyutu neden önemlidir (Bölüm 32'ye atıfla)?
12. Pre-commit sır taraması (gitleaks) neden sürekli taramadan daha etkili olabilir?

---

18. Kaynakça

• OWASP, Secrets Management Cheat Sheet; Secrets Management (DevSecOps).
• MITRE, CWE-798: Use of Hard-coded Credentials; CWE-312: Cleartext Storage of Sensitive Information; CWE-522: Insufficiently Protected Credentials.
• ABD Adalet Bakanlığı, United States v. Sullivan (Uber gizleme); Bloomberg, Uber Concealed Cyberattack (2017); FTC uzlaşma belgeleri.
• TechTarget/CyberScoop/Huntress, Uber 2014 & 2016 ihlal analizleri; breaches.cloud, Uber olay kaydı.
• HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager dokümantasyonu; gitleaks / trufflehog projeleri.
• PHP Manual, getenv, $_ENV; vlucas/phpdotenv dokümantasyonu.