1. Security Chaos Engineering Nedir?
Security chaos engineering; güvenlik kontrolleri, izleme sistemleri ve incident süreçlerini “gerçek hayata yakın” ama kontrollü koşullarda test eden deney disiplinidir. Klasik yaklaşım “kontrolü kurduk” diye biter; chaos yaklaşımı “kontrol gerçekten çalışıyor mu?” diye sorar. Burada amaç, sistemi kırmak değil; kontrollü kırılma ile öğrenmek ve dayanıklılığı artırmaktır.
Security chaos engineering nedir, klasik penetrasyon testinden farkı nedir?
Pentest daha çok açık bulmaya (finding) odaklanır; security chaos ise kontrol ve süreçlerin “dayanıklılığını” ölçer. Pentest bir fotoğraf karesi gibiyken, chaos; kontrollü inject’lerle alarm, triage, müdahale ve geri dönüş kabiliyetini test eder. İkisi rakip değil tamamlayıcıdır: pentest açıkları bulur, chaos “olay anında gerçekten hazır mıyız?” sorusunu cevaplar.
“Resilience over assumptions” yaklaşımı
Assumption: “WAF bizi korur.” Resilience: “WAF kuralı yanlışlıkla kapanırsa 15 dakikada yakalayıp geri açabiliyor muyuz?” Chaos, işte bu ikinci soruyu sistematikleştirir.
☑ Mini Check : Chaos’a hazır mıyız?
- •Üretim-benzeri bir test ortamı var mı?
- •Kritik akışlar (rezervasyon/portal) tanımlı mı?
- •Alarm→triage→resolve akışı yazılı mı?
- •Deney sırasında “dur” butonu ve rollback var mı?
- •KVKK ve uptime risk sınırları net mi?
Ne yapmalıyım? (SXO aksiyon listesi)
- • “Üretim-benzeri ama kontrollü” ortamı tanımla.
- • Deneylerin kapsamını küçük tut ve ölçülebilir hedef koy.
- • Dur/rollback mekanizmasını zorunlu yap.
- • Deneyleri bakım-destek ve KVKK süreçleriyle koordine et.
2. Klasik PenTest’ten Farkı
Pentest, uygulama ve altyapının zayıflıklarını “bulmak” için yapılır. Chaos, bulduğunuz zayıflıkları ve kurduğunuz kontrolleri “işletmek” için yapılır. Çoğu kurumun aksadığı yer de burasıdır: kontrol var, ama olay anında çalışmıyor veya ekip o sinyali okuyamıyor.
Pentest vs Chaos (kısa pratik ayrım)
- •Pentest: “hangi açık var?”
- •Chaos: “kontrol devre dışı kalırsa nasıl anlarız ve nasıl toparlarız?”
- •Pentest: rapor + remediation
- •Chaos: deney + ölçüm + süreç iyileştirme
Chaos’un en büyük kazanımı: koordinasyon kası
Sheet’teki veri noktasını yumuşak şekilde içerik içine gömelim: Chaos deneyleri yapan ekiplerde, gerçek olaylarda tepki süresi ve koordinasyonun “gözle görülür” şekilde iyileştiği sık raporlanır; çünkü refleksler pratikle gelişir.
☑ Mini Check : Hangi boşluğu dolduruyor?
- •Alarm geliyor ama kimse bakmıyor mu?
- •Triage uzuyor mu?
- •Runbook güncel değil mi?
- •Rol/eskalasyon belirsiz mi?
- •Restore/rollback pratikte çalışmıyor mu?
Ne yapmalıyım? (SXO aksiyon listesi)
- • Chaos’u “kontrol testleri” olarak konumlandır.
- • Alarm ve runbook kalitesini deneyle ölç.
- • Ekip rol/eskalasyonunu tatbikatla netleştir.
- • Öğrenimleri backlog’a bağla.
3. Kontrollü Saldırı ve Hata Senaryoları
Chaos deneyleri küçük ve kontrollü olmalı. “Büyük felaket senaryosu” ile başlamak çoğu ekibi yorar. En iyi yaklaşım; düşük riskli inject’lerle başlayıp olgunlaştıkça kapsamı artırmaktır.
Deney tasarım prensipleri
- •Küçük adım: tek değişken, tek hipotez
- •Ölçüm: MTTD/MTTR, alarm kalitesi, false-positive
- •Güvenlik sınırı: üretime etki etmeyecek şekilde; gerekiyorsa prod-benzeri lab
- •Geri dönüş: rollback/dur butonu
- •Dokümantasyon: plan, sonuç, öğrenim
Hangi güvenlik bileşenlerinde chaos deneyleri yapabilirim?
DNS, WAF kuralları, IAM yetkileri, secrets yönetimi, rate limit, SIEM/monitoring alarmları, yedek/restore süreçleri ve segmentasyon kuralları; en verimli chaos alanlarıdır. Amaç “hack simülasyonu” değil; bu kontrollerin bozulduğunda hızlı yakalanıp yakalanmadığını test etmektir.
Çok kritik not: Ransomware simülasyonu
Row’da belirtildiği gibi: yalnızca lab/üretim-benzeri ama kontrollü ortamda. Üretimde ransomware simülasyonu yapılmaz; KVKK ve uptime riski kabul edilemez olabilir.
☑ Mini Check : Deney güvenliği
- •Deney scope’u küçük mü?
- •Etki alanı (blast radius) sınırlandı mı?
- •Rollback adımı yazılı mı?
- •KVKK/veri riskleri değerlendirilip maskeleme var mı?
- •Deney sonrası log/kanıtlar saklanıyor mu?
Ne yapmalıyım? (SXO aksiyon listesi)
- • İlk deneyleri “konfig bozulması” gibi düşük riskli seç.
- • Blast radius’u sınırla (tek servis/tek ortam).
- • Rollback’i otomatikleştir ve tatbik et.
- • Deney raporunu süreçlere geri besle.
4. Otel ve B2B İçin Örnek Chaos Deneyleri
Bu bölüm, “ne deneyeyim?” sorusuna hızlı bir set sunar. Otel ve B2B’de ortak payda: çok paydaşlı erişim, entegrasyonlar ve sezonsal/yoğun trafik dalgalanması.
Otel senaryoları (sezon öncesi tehdit simülasyonu)
- •WAF kuralı kapalı kaldı: alarm ne kadar sürede çalıyor? kim müdahale ediyor?
- •DNS yanlış kayıt: kullanıcı etkisi olmadan staging’de “resolve bozulursa” ne oluyor?
- •Rezervasyon entegrasyonunda yetki daraltma: IAM policy fazla geniş mi?
- •Backup/restore tatbikatı: immutable/offline yedekten geri dönüş süresi (RTO) ölçümü
B2B senaryoları (üretim-benzeri ortamda)
- •API rate limit yanlış ayar: overload protection ve müşteri etkisi nasıl?
- •Secrets rotation testi: token rotate olunca servisler ayakta kalıyor mu?
- •NetworkPolicy “default-deny” regressions: hangi servisler kırılıyor, gözlem/geri dönüş nasıl?
- •SIEM/monitoring kuralı yanlış eşik: gürültü mü üretiyor, kritik sinyal kaçıyor mu?
“Küçükten büyüğe” deney matrisi
Başlangıç: DNS/WAF/alert eşiği gibi küçük inject Orta: IAM daraltma + secrets rotation İleri: segmentasyon/policy regressions + restore tatbikatları (Üretim değil, prod-benzeri kontrollü ortam)
☑ Mini Check : Deney seçimi
- •Kritik akışlara dokunmadan test edilebiliyor mu?
- •Ölçüm KPI’ı net mi (MTTD/MTTR)?
- •Owner ve eskalasyon net mi?
- •Öğrenim backlog’a girecek mi?
- •Deney seti 180 günde bir güncellenecek mi?
Ne yapmalıyım? (SXO aksiyon listesi)
- • Otel: sezon öncesi 3–5 küçük deney seti planla.
- • B2B: prod-benzeri ortamda rate limit + secrets rotation deneyleri yap.
- • Her deneyin çıktısını runbook ve policy’ye geri yaz.
- • Deneyleri bakım-destek takvimiyle koordine et (Internal link: /tr/yazilim/bakim-ve-destek).
5. Sonuçları Süreç ve Araçlara Geri Beslemek
Chaos’un değeri “deney yaptık” demek değil; öğrenimi kalıcılaştırmaktır. Her deney, bir süreç/araç iyileştirmesine bağlanmalı: policy güncelleme, alarm eşiği kalibrasyonu, runbook iyileştirme, eğitim.
Chaos deneylerinden çıkan sonuçları nasıl süreçlere geri beslerim?
Her deney için hipotez, sonuç, ölçüm ve aksiyon maddesi çıkarın. Aksiyonları sprint backlog’una girin; policy/runbook güncellemesini versiyonlayın ve bir sonraki deneyde doğrulayın (learn→re-test). Böylece deneyler “tek seferlik tatbikat” olmaktan çıkar, güvenlik programının motoru olur.
Geri besleme checklist’i
- •Alarm eşikleri: gürültü azaltma
- •Runbook: adım adım netleştirme
- •Policy: IAM/network/WAF kuralları
- •Eğitim: ekip refleksleri
- •Raporlama: KVKK/teknik tedbir kanıtları (audit)
KVKK ve uptime koordinasyonu (teknik not)
Chaos deneyleri mutlaka üretim-benzeri ama kontrollü ortamlarda yapılmalı; KVKK ve uptime riskleri göz önünde bulundurularak /tr/raporlama/kvkk-veri-guvenligi ve /tr/yazilim/bakim-ve-destek süreçleriyle koordine edilmelidir.
☑ Mini Check : Öğrenim kapanışı
- •Deney raporu var (plan/sonuç/öğrenim)
- •Aksiyonlar backlog’a girdi
- •Policy/runbook güncellendi
- •Re-test ile doğrulandı
- •180 gün sonra deney seti revize edilecek
Ne yapmalıyım? (SXO aksiyon listesi)
- • Deney raporunu standart şablona bağla.
- • Aksiyonları sprint’e sok; “not” olarak bırakma.
- • Runbook/policy’yi versiyonla ve re-test et.
- • KVKK/audit kanıtlarını düzenli sakla.
6. İçerik içi tablo (Örnek chaos deney senaryoları)
| Deney | Inject | Gözlem | Beklenen öğrenim |
|---|---|---|---|
| DNS bozulması | Yanlış kayıt (staging) | Uptime/DNS alarmı | MTTD + runbook netliği |
| WAF kuralı kapalı | Kural devre dışı | Trafik anomali/WAF log | Alarm eşikleri + eskalasyon |
| IAM aşırı yetki | Policy daralt/boz | Yetki hatası/403 trendi | Least-privilege doğrulama |
| Backup restore | Immutable yedekten restore | RTO ölçümü | DR readiness |
| Secrets rotation | Token rotate | Hata oranı/yeniden deneme | Rotation güvenliği |
7. Security Chaos Deneyleri & Senaryo Tasarımı Planlama Şablonunu İndir
Security Chaos Deneyleri & Senaryo Tasarımı Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon; güvenlik kontrollerini ve incident süreçlerini küçük, kontrollü chaos deneyleriyle test etmek için hazırlanmıştır. Deneylerin blast radius’unu sınırlamayı, ölçümleri (MTTD/MTTR) netleştirmeyi ve öğrenimleri backlog/policy/runbook güncellemelerine dönüştürmeyi hedefler. KVKK ve uptime riskleri için “kontrollü ortam” kuralını zorunlu kılar.
Kim Kullanır?
Güvenlik lideri, DevOps/SRE, platform ekibi, otel/B2B operasyon lideri.
Nasıl Kullanılır?
- Deney senaryosunu seç, hipotez ve başarı ölçütünü yaz.
- Inject planını (kapsam, süre, rollback) ve gözlem metriklerini belirle.
- Learn çıktısını backlog’a ekle ve re-test ile doğrula.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Blast radius sınırlı
- ▢ ✅ Rollback adımı yazılı
- ▢ ✅ KPI ölçümü net
- ▢ ✅ Aksiyonlar backlog’a girdi
- ▢ ✅ Re-test planlandı
- ▢ ✅ KVKK ve bakım-destek koordinasyonu yapıldı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
6) Kontrol listesi
- •Blast radius sınırlı
- •Rollback adımı yazılı
- •KPI ölçümü net
- •Aksiyonlar backlog’a girdi
- •Re-test planlandı
- •KVKK ve bakım-destek koordinasyonu yapıldı
Bir Sonraki Adım
Güvenlik kontrollerini ve incident süreçlerini kontrollü deneylerle test edip zayıf halkaları pratikte görmek isteyen otel ve B2B ekipleri için.
Sık Sorulan Sorular
Security chaos engineering nedir, klasik penetrasyon testinden farkı nedir?▾
Hangi güvenlik bileşenlerinde chaos deneyleri yapabilirim?▾
Otel ve B2B için örnek security chaos senaryoları neler?▾
Chaos deneylerinden çıkan sonuçları nasıl süreçlere geri beslerim?▾
Ransomware simülasyonu chaos kapsamında yapılır mı?▾
İlgili İçerikler