Incident Sırasında Delil Toplama Kiti ve Roller

Incident anında iki uç vardır: ya hiç veri yoktur ya da “her şeyi topla” diye sistemi log/pcap’a boğarsın. İkisinin de ortak sonucu aynıdır: postmortem’de “tam olarak ne oldu?” sorusuna kanıt yerine yorumla cevap verilir.

Benim sahada en çok işe yarayan yaklaşım: Delil Toplama Kiti (evidence kit) + rol dağılımı. Bu ikisi, incident’ı sadece söndürmek değil, aynı zamanda bir sonraki incident’ı ucuzlatmak için çalışır.

Neyi hedefliyoruz?

• Olayı çözerken kanıtı öldürmemek
• Olaydan sonra “şansa bağlı” değil, kanıta dayalı iyileştirme yapmak
• Güvenlik (forensics) ihtiyacı doğarsa, başlangıç verisini hazır tutmak

Rol dağılımı: üç kişi, üç sorumluluk

Küçük ekiplerde bile bu ayrım işe yarar:

1. Incident Commander (IC): karar alır, öncelik belirler, iletişimi yönetir
2. Scribe: zaman çizelgesi tutar, alınan aksiyonları ve sonuçlarını yazar
3. Evidence Owner: kanıt checklist’ini yürütür (log/snapshot/konfig)

Bu üç rol tek kişide toplanırsa, genelde kanıt kısmı kaybolur.

Delil Toplama Kiti: “minimal ama geri üretilebilir”

Ben kit’i 6 parçaya ayırıyorum. Her parça için “neden var?” sorusunun cevabı nettir.

1) Zaman standardı

• Tüm sistemlerde NTP/Chrony sağlık kontrolü
• Incident’ta tüm kayıtların UTC veya tek bir saat standardıyla toplanması

Pratik kontrol:

timedatectl status
chronyc tracking 2>/dev/null || true

2) Değişiklik izi (change evidence)

Olayın en sık kök nedeni: “az önce bir şey değişti.”

Topla:

• Deploy/CI/CD logu (commit SHA, pipeline id)
• Config management değişiklikleri
• Firewall/LB/policy değişiklikleri

3) Erişim izi (access evidence)

Topla:

• Bastion/SSO audit
• Privileged komut kayıtları (auditd, shell history değil; audit)
• Break-glass kullanımı (kim, ne zaman, neden)

4) Servis sinyali (service evidence)

Topla:

• Hata oranı, latency, saturation (SLO/SLI)
• En kritik dashboard ekran görüntüsü veya export
• Alarm fırtınası varsa “hangileri semptom, hangileri neden” notu

5) Sistem sinyali (host evidence)

Topla:

• CPU/memory/disk/net temel metrikleri
• Son 30–60 dk kernel logları
• OOM, conntrack table full, filesystem error gibi “tek satırlık” kritik sinyaller

Pratik:

uptime
free -m
df -h
dmesg -T | tail -n 200
journalctl --since "-60m" --no-pager | tail -n 200

6) Konfig snapshot (config evidence)

Amaç: “şu anki hâli” dondurmak.

• Edge: routing table / policy snapshot
• Uygulama: feature flag durumu, env/secret versiyonu (değer değil, sürüm)
• Infra: LB pool üyeleri, weight’ler, health-check state

Incident akışına nasıl bağlanır?

En pratik model:

• IC ilk 5 dakikada containment kararını verir
• Scribe, her aksiyonu “timestamp + komut + sonuç” olarak yazar
• Evidence Owner, containment sonrası ilk sakinleşme anında kit’i tamamlar

Bu sayede “yangın söndürme” ile “kanıt üretme” aynı anda yürür.

Sonuç

Delil toplama kiti, incident’ı yavaşlatmaz; doğru kurulduğunda incident’ı hızlandırır. Çünkü ekip, panik anında “ne toplayalım?” diye düşünmez; standart çalışır. Operasyonel liderlik burada başlar: sadece sistemi değil, olayı yönetme sistemini de tasarlamak.