Appearance
Incident Response Runbook
- Sahip: Simetri (birincil), tüm ekip (destek)
- Son Güncelleme: 2026-04-16
- Durum: MVP iskeleti. İlk prod incident sonrası "lessons learned" bölümü genişler.
- Tetikleyici (dosya güncellemesi): Yeni incident tipi, yeni bileşen, yeni uyum yükümlülüğü.
0. Bu Runbook Kimler İçin?
İlk prod deployment'tan itibaren herkes için. Pre-development aşamasında bile "nasıl haberdar oluruz" altyapısı kurulurken referans alınır.
1. Incident Sınıfları ve İlk Aksiyon
| Sınıf | Ne demek | İlk aksiyon (P0) | SLA yanıt |
|---|---|---|---|
| S1 — Veri İhlali / PII Sızıntısı | T3 veriye yetkisiz erişim veya sızıntı | Sistemi oku-only'e al, erişim loglarını dondur | 15 dk |
| S2 — RLS Bypass | Context Room izolasyonu bozulmuş | Şüpheli endpoint'i kapat, etkilenen kullanıcıları tespit | 15 dk |
| S3 — LLM Jailbreak / Prompt Injection | Ajan guardrail'i aşmış, PII sızdırmış | Etkilenen session'ları snapshot al, prompt'u hotfix'le | 30 dk |
| S4 — Secret Exposure | API key / token public repo'ya düşmüş | Hemen rotate, eski key iptal | 15 dk |
| S5 — Availability | Sistem/servis erişilemiyor | Status page, müşteri iletişimi | 30 dk |
| S6 — Model Behavior Regression | Eval metriği düşmüş, ama erişim var | Önceki prompt versiyonuna rollback | 2 saat |
| S7 — Compliance / Regulator Sorusu | DPO/yetkili yazılı soru | Hukuka bildir, yanıt taslağı hazırla | Yazılı SLA |
S1, S2, S4 → aynı zamanda GDPR Art. 33 (72 saat içinde bildirim) kapsamında olabilir. S1 → EU AI Act Art. 62 (ciddi incident) kapsamında olabilir.
2. Yaşam Döngüsü (6 Adım)
Detect → Triage → Contain → Eradicate → Recover → Postmortem2.1. Detect (Tespit)
Kaynaklar:
audit-trail.mdalarm kuralları (yetkisiz admin T3 erişimi, audit tablosu UPDATE denemesi)- Observability altyapısı (
architecture/observability.md): Grafana Cloud alerting — hata oranı, latency, model davranış drift, RLS ihlal denemeleri, audit write failure. §6'daki alert rule tablosu incident sınıflarına (§1) eşlenir. - Kullanıcı raporu (
security@humindx.com) - Bug bounty / responsible disclosure
- Otomatik secret scanning (GitHub, pre-commit hook)
2.2. Triage (Sınıflandırma ve Önceliklendirme)
On-call kişi:
- Sınıfı belirle (§1 tablosundan).
- Kapsamı çıkar: kaç kullanıcı, hangi tenant, hangi T tier?
- Linear'da
[INCIDENT]prefix'li issue aç, label:incident, severity label'ı. - Slack
#humindx-incidentkanalına çağrı (aktif incident komutanı belirle).
2.3. Contain (Sınırla)
"Daha fazla zarar yayılmasın" — bazı tipik aksiyonlar:
- Endpoint'i feature flag ile kapat
- Şüpheli API key'i revoke et
- Tenant'a geçici read-only mod
- Ajan prompt'unu safe-mode'a düşür (boş yanıt)
- Audit trail snapshot al (immutable), log dondur
2.4. Eradicate (Kökeni Kaldır)
- Kodsal fix veya prompt patch
- Şüpheli erişim token'larını iptal
- Etkilenen embedding'leri forget (RAG'dan çıkar)
- Migration gerekiyorsa hazırla (düzeltilmiş RLS, yeni index)
2.5. Recover (Normale Dön)
- Fix deploy + smoke test
- Rate-limit'i normale al
- Etkilenen kullanıcılara bildirim (GDPR Art. 34 eşiği aşıldıysa zorunlu)
- Status page güncelle
2.6. Postmortem (Ders Çıkar)
Her S1–S5 incident'ı için blameless postmortem — 1 hafta içinde:
- Ne oldu (timeline)
- Neden oldu (kök neden — 5 whys)
- Ne işe yaradı, ne yaramadı
- Önleme aksiyonları → Linear issue olarak açılır, tracker edilir
- Gerekirse
threat-model.md§5 matrisi güncellenir
3. İletişim Matrisi
| Durum | İç (Slack) | Dış (müşteri/regülatör) |
|---|---|---|
| Incident açıldı | #humindx-incident + komutan | Müşteri etkilenmediyse: yok |
| Müşteri etkisi var | CEO + Simetri'ye bildirim | Etkilenen müşteri(ler) — 4 saat içinde |
| PII sızıntısı | Legal + DPO | DPO → 72 saat içinde yetkili (GDPR Art. 33) |
| Ciddi AI incident | DPO + Legal | EU AI Act Art. 62 bildirimi |
| Kapalı | Postmortem özeti #humindx-dev | Sonuç raporu (müşteri talep ederse) |
4. Veriler ve Delil Zinciri
- Audit trail değiştirilmez (
audit-trail.mdimmutability kuralı). - Incident sırasında alınan her snapshot
_incident-<id>klasörüne, kriptografik hash'i ile birlikte arşivlenir. - Hukuki işlem ihtimali varsa delil zinciri (chain of custody) notu tut: kim aldı, ne zaman, neden.
5. Simülasyon ve Hazırlık
MVP sonrası, en az çeyrekte bir tabletop exercise:
- Senaryo oku, ekip rolleri canlandır (komutan, iletişim, teknik).
- Runbook'un gerçek incident'ta nerede takılacağını bul.
- Sonuç: bu dosyada §1 veya §2 güncellemesi.
6. Dış Referanslar
- GDPR Art. 33 (bildirim), Art. 34 (veri öznesine bildirim), Art. 35 (DPIA)
- EU AI Act Art. 62 (ciddi incident bildirimi, yüksek riskli sistemler)
- NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide
docs/security/threat-model.md— tehditlere karşılık gelen senaryolar
7. İlk Incident Sonrası Genişleme
Bu doküman MVP iskeletidir. İlk gerçek incident'tan sonra şunlar eklenecek:
- Ekip rol tanımları (komutan, iletişim sorumlusu, teknik lead)
- Dış iletişim şablonları (müşteri bildirimi, status page)
- Regulator bildirim şablonu
- Tenant-bazlı etki değerlendirme checklist'i