Tehdit Modelleme Atölyesi

Bu eğitimdeki bütün güvenlik laboratuvarları bir şeyi buldu: statik analiz kodda bir desen buldu, tarayıcı bir CVE buldu, DAST eksik bir başlık buldu. Hepsi var olan bir şeye bakıyordu.

Tehdit modelleme bunların hiçbirine benzemiyor, çünkü henüz var olmayan bir şeye bakıyor. Araç yok, tarama yok, çıktı yok. Bir tahta, sistemin şeması ve birkaç kişi var. Çıktısı bir rapor değil, kararlar.

Neden değsin? Çünkü bulduğunuz her zafiyetin bir maliyeti var ve o maliyet zamanla katlanıyor:

• tasarımda fark edilirse → bir cümlelik karar
• kodda fark edilirse → bir commit
• testte fark edilirse → bir sürüm gecikmesi
• üretimde fark edilirse → bir gece, bir bildirim, belki bir ceza

Tehdit modelleme bu merdivenin en üst basamağı. Ve bu eğitimdeki tek etkinlik ki çalıştırılacak bir kodu bile gerektirmiyor.

Bu bir atölye, komut satırı labı değil. Çalıştıracak bir şey yok; okuyacak, tartışacak ve yazacaksınız. Grup hâlinde yapılıyorsa en verimli hâli budur.

Başlamadan önce

Süre: yaklaşık 60 dakika.

Bütün komutları deponun kök dizininden çalıştırın; bu labdaki yollar ona göre yazıldı.

Bu lab ne işe yarıyor

Bu eğitimdeki diğer güvenlik etkinliklerinin hepsi var olan bir şeyi inceliyor. Bu, henüz inşa edilmemiş olanı inceliyor — bir kusurun bir sürüme değil bir cümleye mal olduğu tek nokta. Ayrıca eğitimin baştan beri ürettiği soruyu yanıtlıyor: container'a geçmek hangi tehditleri kaldırıyor, hangilerini taşıyor, hangilerini yaratıyor.

Bu labdan sonra şunları yapabileceksiniz:

• bir sistemi çizip güvenin gerçekte nerede el değiştirdiğini işaretlemek
• tehditleri hayal gücünden değil kontrol listesinden üretmek
• her tehdit için karar vermek: azalt, kaldır, devret veya kabul et — yazılı
• container'ın hangi tehdidi kaldırdığını, hangisini taşıdığını söylemek

Bu lab nasıl işliyor

Bunu bir kez okuyun - bu eğitimdeki her lab aynı kurallarla yazıldı.

Komutları nereye yazacaksınız. Bir terminal açın ve bu depoyu kopyaladığınız klasöre gidin. Windows'ta PowerShell kullanın (Başlat menüsünde aratın), macOS veya Linux'ta Terminal. Labdaki bütün yollar depo kökünden yazıldı, yani bir adım aksini söylemedikçe orada kalın.

> ile başlayan satırlar açıklamadır, komut değildir. Onları yapıştırmayın. Yalnızca gri kod kutularının içindeki metin yazılır.

📋 işareti "sıra sizde" demektir. Onu gördüğünüzde adımı önce kendiniz deneyin. Hemen altında cevabı saklayan kapalı bir "Nasıl yapılır?" oku var; onu denedikten sonra açın, önce değil. Lablar bilerek böyle yazıldı: kendi çözdüğünüz şeyi hatırlarsınız, yapıştırdığınızı değil.

Bir komut hata verirse bu normal olabilir. Bazı adımlar hatanın nasıl göründüğünü göstermek için bilerek başarısız olur. Bir şeyin bozuk olduğuna karar vermeden önce komutun üstündeki cümleyi okuyun.

Takılırsanız şu sırayla:

1. Komutun üstündeki paragrafı tekrar okuyun - cevap genelde oradadır.
2. "Nasıl yapılır?" okunu açın.
3. hints.md dosyasını açın, küçük bir yönlendirme verir.
4. solution.md dosyasını açın, tam cevap orada. Kullanmak serbest; okumadan kopyalamak değil.

Bitirdiğinizde en alttaki Temizlik bölümünü çalıştırın. Lablar aynı portları ve container adlarını paylaşıyor; birinden kalan artık diğerini bozar.

Kaynaklar

• OWASP Threat Modeling Cheat Sheet

• Microsoft — STRIDE ile tehdit modelleme

• NIST SSDF (SP 800-218) PW.1 — tasarımda güvenlik gereksinimleri

• OWASP ASVS — V1 Architecture, Design and Threat Modeling

Dört soru

Tehdit modelleme karmaşık görünüyor ama özü dört sorudan ibaret:

1. Ne inşa ediyoruz? — sistemin şeması, parçaları, aralarındaki akış
2. Ne ters gidebilir? — tehditler
3. Ne yapacağız? — her tehdit için bir karar
4. İyi iş çıkardık mı? — modelin kendisini gözden geçirmek

Çoğu ekip ikinciyi yapmaya çalışıp birinciyi atlıyor ve dağılıyor. Sırayı bozmayın.

1. Ne inşa ediyoruz

Modelleyeceğimiz sistem şu: eğitimdeki laboratuvarlarda gördüğünüz sipariş servisinin kurumsal hâli. Önce bugünkü kurulumuyla çalışacağız — httpd, uygulama sunucusu, SQL sunucusu.

  Internet
     │
     │  443/tcp
     ▼
┌─────────────────┐
│  web-01 (VM)    │   httpd 2.4, ters vekil
│  DMZ ag         │   TLS burada sonlaniyor
└────────┬────────┘
         │  8080/tcp
         ▼
┌─────────────────┐
│  app-01 (VM)    │   uygulama sunucusu
│  ic ag          │   siparis is mantigi
└────────┬────────┘
         │  1433/tcp
         ▼
┌─────────────────┐
│  sql-01 (VM)    │   veritabani
│  veri agi       │   siparis + musteri verisi
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  SAN depolama   │   LUN, gece yedegi
└─────────────────┘

Bilmeniz gereken ayrıntılar:

• web-01 üzerindeki httpd root olarak başlıyor, sonra apache kullanıcısına düşüyor
• app-01 veritabanına siparis_app hesabıyla bağlanıyor; parola uygulamanın config.properties dosyasında düz metin
• sql-01 yalnızca iç ağdan erişilebilir, ama bütün iç ağdan
• Yedekler gece SAN üzerinde LUN kopyası olarak alınıyor, şifreli değil
• Üç VM'e de yöneticiler RDP/SSH ile doğrudan bağlanıyor
• Yama işlemi aylık bakım penceresinde elle yapılıyor
• Günlükler her sunucunun kendi diskinde, 30 gün

Aynı sistemin container'a taşınmış hâli bu labın dördüncü bölümünde; oraya geldiğimizde ikisini karşılaştıracağız.

Şemada eksik olan tek şey güven sınırları (trust boundary): verinin bir güven seviyesinden diğerine geçtiği yerler. Tehditler neredeyse her zaman o çizgilerin üzerinde oturuyor.

📋 Bu sistemde kaç tane güven sınırı var? Nerede?

2. Ne ters gidebilir: STRIDE

Tehdit üretmek için hayal gücüne güvenmek işe yaramıyor — herkes kendi bildiği saldırıyı söylüyor ve liste oradan ileri gitmiyor. STRIDE bunun yerine kontrol listesi veriyor. Her bileşen için altı soruyu sırayla soruyorsunuz:

Birlikte yapalım: web-01

Bu altı satır on dakikada çıktı ve hiçbirini bulmak için araç gerekmedi.

📋 Şimdi siz sql-01 için aynı tabloyu doldurun. Sistem tanımındaki ayrıntılara dikkat edin — özellikle parolanın nerede durduğuna.

3. Ne yapacağız

Her tehdit için dört seçenek var. "Düzelt" bunlardan yalnızca biri:

• Azalt (mitigate) — kontrolü ekle. Parolayı kasaya taşı, hesabı kısıtla, yedekleri şifrele.
• Ortadan kaldır (eliminate) — özelliği veya yolu sil. Veritabanına iç ağın tamamından erişimi kapat, yalnızca app-01'e izin ver.
• Devret (transfer) — riski başkasına geçir. Ödeme verisini hiç tutma, sağlayıcıya bırak.
• Kabul et (accept) — bilinçli olarak yaşa. Yazılı, sahibi ve tarihi belli.

Son seçenek DAST ve IaC laboratuvarlarındaki istisna satırlarının ta kendisi. Orada bir dosyaya yazdığınız şeyin kararı burada veriliyor.

Her satır için şu biçimi kullanın:

Tehdit     : app-01 uzerindeki duz metin parola ile veritabanina baglanilmasi
Harf       : S (kimlik taklidi)
Etki       : Musteri verisinin tamami okunabilir
Karar      : Azalt
Nasil      : Parola sir kasasina tasinacak, uygulama calisma aninda cekecek
Sahibi     : Uygulama ekibi
Son tarih  : 2027-01-31

4. Aynı sistem container'da

Şimdi işin ilginç yerine geliyoruz. Aynı sistemi bu eğitimde kurduğunuz yapıya taşıdınız:

  Internet
     │
     ▼
┌──────────────────────────────────────┐
│  Kubernetes kumesi                   │
│                                      │
│  ┌────────┐   ┌────────┐   ┌──────┐  │
│  │ ingress│──▶│  app   │──▶│ sql  │  │
│  │        │   │ (3 kop)│   │(stf) │  │
│  └────────┘   └────────┘   └──────┘  │
│       ▲            ▲                 │
│       │            │                 │
│   TLS burada   imaj: registry        │
└──────────────────────────────────────┘
         ▲
         │  dagitim
┌────────┴────────┐
│  CI/CD hatti    │  Jenkins, imaj derleme, tarama
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  imaj registry  │
└─────────────────┘

• İmajlar CI hattında derleniyor, registry'ye gönderiliyor
• Kümeye dağıtım GitOps ile; dağıtım bildirimi git deposunda
• Veritabanı parolası Kubernetes Secret nesnesinde
• Kümeye erişim kubectl ile, kimlik doğrulama kurumsal dizinden
• Günlükler merkezî bir toplayıcıya akıyor
• Yama = imajın yeniden derlenmesi ve dağıtılması

Tehditler ne oldu?

📋 Üç gruba ayırın: hangi tehditler kayboldu, hangileri yer değiştirdi, hangileri yeni?

Buradan çıkan sonuç

Container'a geçmek güvenliği otomatik olarak artırmıyor. Bazı tehdit sınıflarını gerçekten yok ediyor — bunlar çoğunlukla makine bakımıyla ilgili olanlar. Karşılığında yeni ve tanıdık olmayan bir yüzey açıyor: imajın nereden geldiği, hattın kime ait olduğu, kümenin kime ne yetki verdiği.

Bu eğitimdeki modüllerin neden o sırayla dizildiğini de açıklıyor: imaj derleme, registry, tarama, altın imaj, GitOps, politika zorlama — hepsi yukarıdaki "yeniler" listesine verilmiş cevaplar.

Lab

Modeli tamamlayın.

Birinci bölüm — mevcut sistem. app-01 için STRIDE tablosunu doldurun. Yukarıdaki web-01 ve sql-01 tablolarını örnek alın. En az altı tehdit yazın; her harf için en az bir satır zorlamayın, bazı harfler o bileşen için boş kalabilir — ama boş bıraktığınızı bilerek bırakın.

İkinci bölüm — kararlar. Çıkardığınız tehditlerden üç tanesini seçip karar biçimini doldurun: etki, karar, nasıl, sahibi, son tarih. Üçünden en az biri "Kabul et" olsun — gerekçesini yazmak zorunda kalın.

Üçüncü bölüm — yeni mimari. Container'lı kurulumda CI/CD hattını modelleyin. Hat bir bileşen; STRIDE'ı ona uygulayın. İpucu: hattın üretime yazma yetkisi var ve kodu bir git deposundan alıyor.

Sonucu sınıfla paylaşın. Bu atölyenin asıl çıktısı tablo değil, tartışma — aynı sisteme bakan iki kişi farklı tehditler görüyor ve asıl değer orada.

Takıldınız mı? İpuçlarına bakın veya çözümü inceleyin.

Temizlik

Bu atölyede çalıştırılan bir şey olmadı; temizlenecek bir şey de yok.

Çıkardığınız modeli saklayın. Tehdit modeli bir kerelik belge değil: mimari değiştiğinde tekrar açılıyor ve "bu değişiklik hangi tehditi etkiliyor" sorusu soruluyor.