Veri akış şeması ve güven sınırı

Bir önceki derste tehdit modellemenin ilk sorusunu, ne üzerinde çalışıyoruz sorusunu sonraya bırakmıştın. Bu dersin konusu tam olarak o soru. Cevabı bir veri akış şemasıdır (data flow diagram, DFD). Şema verinin sisteme nereden girdiğini, hangi süreçlerden geçtiğini, nerede saklandığını ve nerede el değiştirdiğini gösterir.

Kod bilmeyen ürün sahibi de, altyapıyı bilmeyen geliştirici de aynı resme bakar. STRIDE incelemesi bu resmin üstünde yapılır. Şemada olmayan bir akış incelemeye de girmez; eksik bir şema, eksik bir tehdit listesi demektir. Bu derste AltayKargo iade servisinin şemasını adım adım kuracak, güven sınırlarını işaretleyecek ve aynı modeli kod olarak yazacaksın.

Veri akış şeması az sayıda sembolle kurulur. Dış varlık (external entity), uygulamanın dışında kalan ve sisteme bir giriş noktasından dokunan taraftır; iade servisinde müşteri ve ödeme sağlayıcısı dış varlıktır. Süreç (process), veriyi işleyen ya da ona göre bir eylem yapan kod parçasıdır. İade formunu karşılayan uygulama bir süreçtir.

Çoklu süreç (multiple process), alt süreçlere bölünebilen bir süreç topluluğudur ve başka bir şemada ayrıntılandırılır. Veri deposu (data store), verinin durduğu yerdir: veritabanı, dosya sistemi, önbellek. Depo veriyi değiştirmez, yalnız saklar. Veri akışı (data flow), iki öğe arasındaki oktur ve verinin yönünü gösterir.

Son sembol güven sınırıdır (trust boundary). Kesikli çizgiyle çizilir ve güven düzeyinin değiştiği yeri gösterir. OWASP bu çizgiye ayrıcalık sınırı da der.

Şemayı çizmek kolaydır, asıl iş güven sınırını doğru yere koymaktır. Sınırı geçen her veri, karşı tarafta yeniden sorgulanmayı hak eder. Sınırın öbür yanındaki taraf, bu yanın kurallarına uymak zorunda değildir. Tarayıcıdaki doğrulama kodunu saldırgan kapatabilir, isteği elle yazabilir, alanları istediği gibi doldurabilir.

İnternetten gelen kullanıcı isteği ile şirket içi bir servisin isteği bu yüzden aynı güven düzeyinde değildir. Bunu somutlaştırmak için basit bir istek yolunu ele al. Aşağıdaki şema, iade servisine giden bir isteğin geçtiği durakları sırayla gösterir.

Tarayıcı ile web sunucu arasındaki ilk sınır en kalabalık sınırdır, çünkü buradan geçen veri hiç denetlenmemiş olabilir. Yoldaki DNS ve güvenlik duvarı durakları da şemaya girer, ama verinin anlamına dokunmaz. DNS yalnız adı adrese çevirir. Güvenlik duvarı adrese ve porta bakar, formdaki alanları okumaz.

İkinci sınır web sunucu ile veritabanı arasındadır: uygulama kendi kimlik bilgisiyle veritabanına bağlanır, kullanıcı oraya doğrudan erişemez. Kullanıcıya en yakın sınır en çok saldırı denemesini görür, çünkü saldırgan oraya hiçbir engel olmadan ulaşır.

Her okun güven sınırı taşıdığını düşünmek yanlış olur. DNS sorgusu da ağın dışına çıkar, ama iade verisini taşımaz ve kimsenin yetkisini değiştirmez. Sınır, veri akışının yetki ya da güven düzeyini değiştirdiği yerde durur, uzaklıkta değil. Aynı makinede bile sınır olabilir.

Web uygulaması sınırlı bir kullanıcıyla, yedekleme betiği kök kullanıcıyla çalışıyorsa ikisinin arasında bir ayrıcalık sınırı vardır. Tersine, iki ayrı veri merkezindeki iki kopya aynı kimlik ve aynı yetkiyle çalışıyorsa aralarında yeni bir güven düzeyi oluşmaz.

Sık karşılaşacağın dört sınır türü vardır. Ağ sınırı, internet ile iç ağ arasındaki klasik çizgidir. Ayrıcalık sınırı, aynı makinede farklı kullanıcı ya da farklı yetkiyle çalışan süreçleri ayırır. Kiracı sınırı, çok kiracılı (multi-tenant) bir sistemde bir müşteri şirketin verisini ötekinden ayırır.

AltayKargo iade servisini başka kargo firmalarına da satarsa bu sınır doğar. Servis sınırı ise iki servisin birbirini çağırdığı yerdir. Mikro servis mimarisinde her servisin kendi kimliği olur ve çağrıyı yapan servis doğrulanır. Karşılıklı TLS (mutual TLS) bunun yaygın yoludur: iki taraf da sertifika gösterir.

Büyük bir sistemi tek şemaya sığdırmaya çalışma. Önce bağlam şeması (context diagram) çizilir; buna seviye 0 da denir. Seviye 0'da iade servisi tek bir çoklu süreç olarak durur.

Çevresinde yalnız dış varlıklar ve onlarla arasındaki akışlar vardır: müşteri, destek temsilcisi, ödeme sağlayıcısı ve SMS sağlayıcısı. Seviye 1'de bu kutu alt süreçlere açılır: iade formu, fotoğraf yükleme, durum sorgulama ve yönetici onayı. Veri depoları da bu seviyede kendi kutusunu alır, çünkü hangi kimlik bilgisiyle erişildikleri ayrı bir sorudur.

Alt seviyeye inmenin kuralı basittir. Bir kutunun içinde farklı güven düzeyleri ya da farklı veri türleri varsa onu açarsın. İçi tek düze olan kutuyu açmak şemayı yalnız kalabalıklaştırır.

Şemanın yanında kısa bir envanter tutulur. OWASP'ın tehdit modelleme süreci dört liste önerir: giriş noktaları, çıkış noktaları, varlıklar ve güven düzeyleri. Giriş noktası, saldırganın veri sokabildiği her yerdir.

Varlık, korunmaya değer her şeydir. Güven düzeyi ise sisteme kimin hangi haklarla dokunduğunu tanımlar. OWASP'ın saldırı yüzeyi analizi rehberi de giriş noktalarını sayar ve her değişiklikte bu sayının nasıl değiştiğine bakar.

Aşağıdaki envanter iade servisi için doldurulmuştur. Her giriş noktası, hangi güven düzeylerinin ona ulaşabildiğini de söyler.

GÜVEN DÜZEYLERİ
  G1  Anonim ziyaretçi
  G2  Oturum açmış müşteri
  G3  Destek temsilcisi
  G4  İade yöneticisi

GİRİŞ NOKTALARI
  E1  POST /iadeler              iade formu               G2
  E2  POST /iadeler/{id}/foto    fotoğraf yükleme         G2
  E3  GET  /iadeler/{id}         durum sorgusu            G2, G3, G4
  E4  POST /iadeler/{id}/onay    yönetici onayı           G4
  E5  POST /webhook/odeme        ödeme geri çağrısı       dış servis, imzalı

VARLIKLAR
  V1  Müşteri adı, adresi, telefonu (kişisel veri)
  V2  Hasar fotoğrafları
  V3  İade tutarı ve onay durumu
  V4  Oturum çerezleri

Envantere giriş noktalarından bak. E1 ile E2 yalnız oturum açmış müşteriye açıktır; G1'in bu noktalara ulaşması bir kimlik denetimi hatasıdır. E3'e üç güven düzeyi ulaşır. Bu yüzden nesne düzeyinde sahiplik denetimi gerekir: müşteri yalnız kendi iadesini görür.

E4 en değerli giriş noktasıdır, çünkü V3'ü doğrudan değiştirir. E5 sık unutulur. Bu uç noktayı insan değil, ödeme sağlayıcısı çağırır ve güven imza doğrulamasından gelir.

İmza denetlenmezse herkes ödeme tamamlandı mesajı gönderebilir. Yeni bir webhook eklemek saldırı yüzeyine yeni bir giriş noktası eklemektir. Şema ve envanter o gün güncellenir.

Şema ve sınır birlikte çalışır. Şema nereye baktığını gösterir, sınır ise nerede durup sorgulaman gerektiğini söyler. İkisini karıştırmak incelemeyi ya çok geniş ya da çok dar tutar.

Sınırsız bir şemada her oka aynı özeni gösterirsin ve asıl riskli akış kalabalıkta kaybolur. Sınırı çizip şemayı eksik bırakırsan da çizgiyi geçen bir akışı hiç görmezsin. Bu ayrımın merkezindeki terimi şimdi kendin yaz.

Her öğeye altı kategorinin hepsini sormak zaman kaybıdır. Microsoft'un STRIDE-öğe başına (STRIDE-per-element) yaklaşımı, hangi öğe türünün hangi tehditlere açık olduğunu önceden eşler. Dış varlık kimlik sahteciliğine ve inkâra açıktır. Süreç altı kategorinin hepsine açıktır, çünkü kod hem veri alır hem karar verir.

Veri deposu değiştirme, bilgi ifşası ve hizmet reddine açıktır. Depo bir günlük deposuysa inkâr da eklenir, çünkü günlüğü değiştiren kişi izini siler. Veri akışı da değiştirme, bilgi ifşası ve hizmet reddine açıktır. Saldırgan diske ya da veritabanına doğrudan erişirse, deponun bütünlüğü ve gizliliği aynı anda kırılır.

Öğe türü      S  T  R  I  D  E   İade servisinden örnek soru
------------  -----------------   ----------------------------------------------
Dış varlık    x     x             Webhook'u gerçekten ödeme sağlayıcısı mı çağırıyor?
Süreç         x  x  x  x  x  x    Onay süreci çağıranın rolünü denetliyor mu?
Veri deposu      x  *  x  x       Fotoğraf klasörüne web uygulaması dışında kim yazar?
Veri akışı       x     x  x       Form verisi yolda okunabilir ya da değişebilir mi?

* Depo günlük tutuyorsa R de sorulur.

Sınırın üstünde hep aynı altı denetimi ararsın ve OWASP ASVS 5.0 her birini bir bölüme bağlar. Kimlik doğrulama V6'dır: sınırı geçen kim, bunu nasıl kanıtlıyor? Yetkilendirme V8'dir: bu kimlik bu nesneye bu işlemi yapabilir mi?

Girdi doğrulama V2'dir: gelen veri beklenen yapıya ve iş kuralına uyuyor mu? Aynı bölüm otomasyona karşı önlemi, yani hız sınırını da kapsar.

Şifreli taşıma V12'dir: veri yolda korunuyor mu, iç servisler de TLS kullanıyor mu? Güvenlik günlüğü V16'dır: sınırdaki başarısız denemeler kayda geçiyor mu? Bir sınırda bu altıdan biri eksikse, eksik denetim tehdit kaydına bir satır olarak girer.

Aynı sözlük her sistemde çalışır. Akıllı ev santrali, mobil bankacılık ya da bir fabrika hattı fark etmez: dış varlık, süreç, depo, akış ve sınır. Mobil bankacılıkta telefon, fabrikada saha cihazı dış varlığın ya da uzak sürecin yerini alır.

Sınır sahiplikten değil, güven düzeyinden doğar. Aynı üreticinin iki parçası farklı ağlarda duruyorsa aralarındaki akış bir sınırı geçer. Bir parça genel internete açıksa, öteki yalnız yerel ağdan ulaşılabiliyorsa, veri bu çizgiyi aştığı anda yeniden doğrulanır.

Çizim araçları kolaydır ama çizim, kodla birlikte yaşlanmaz. OWASP pytm modeli bir Python dosyası olarak yazdırır. Dosya depoda kodun yanında durur, kod incelemesinden geçer ve değişiklik geçmişi tutulur. Araç aynı dosyadan veri akış şemasını, sıralama şemasını ve bir tehdit raporunu üretir.

Aşağıdaki model, iade servisinin seviye 1 şemasından iki sınırı, üç öğeyi ve iki akışı tanımlar. Örnek pytm 1.4 ile çalışır. pytm Python 3.11 ya da üstünü ister, şemayı resme çevirmek için de Graphviz gerekir.

#!/usr/bin/env python3
from pytm import TM, Actor, Server, Datastore, Dataflow, Boundary

tm = TM("AltayKargo iade servisi")
tm.description = "Hasar bildirimi, fotoğraf yükleme ve iade durumu"

internet = Boundary("İnternet")
ic_ag = Boundary("İç ağ")

musteri = Actor("Müşteri")
musteri.inBoundary = internet

web = Server("İade web uygulaması")
web.inBoundary = ic_ag

db = Datastore("İade veritabanı")
db.inBoundary = ic_ag

form = Dataflow(musteri, web, "İade formu ve fotoğraf")
form.protocol = "HTTPS"
form.dstPort = 443

sorgu = Dataflow(web, db, "İade kaydı yazma")
sorgu.protocol = "PostgreSQL"
sorgu.dstPort = 5432

tm.process()

Kodu satır satır oku. TM nesnesi modelin kendisidir. Boundary iki güven sınırını tanımlar: İnternet ve İç ağ. Actor bir dış varlıktır, Server bir süreçtir, Datastore bir veri deposudur.

Her öğenin inBoundary alanı onu bir sınırın içine koyar. Dataflow iki öğeyi bir okla bağlar; protocol ve dstPort akışın niteliklerini yazar. Müşteri İnternet sınırında, web uygulaması İç ağ sınırında durur ve form akışı bu yüzden bir sınırı geçer. Şemada sınırlar kesikli kırmızı çerçeve olarak çizilir.

En sondaki tm.process() çağrısı komut satırı bayraklarını okur ve istenen çıktıyı üretir. --dfd şemayı, --report tehdit raporunu verir. --list ise kural kütüphanesindeki bütün tehditleri kimlik ve adıyla yazar.

$ cat bulgular.md
{findings:repeat:{{item.threat_id}} | {{item.target}} | {{item.description}} | {{item.severity}}
}

$ ./tm.py --dfd | dot -Tpng -o iade-dfd.png

$ ./tm.py --report bulgular.md | head -4
INP03 | İade web uygulaması | Server Side Include (SSI) Injection | High
INP05 | İade web uygulaması | Command Line Execution through SQL Injection | Very High
AA01 | İade web uygulaması | Authentication Abuse/ByPass | Medium
DS01 | İade web uygulaması | Excavation | Medium

$ ./tm.py --report bulgular.md | grep -c "|"
58

İlk komut Graphviz biçimli şemayı dot aracına verir ve bir PNG dosyası üretir. İkinci komut bulgular.md şablonunu doldurur: her satır kural kimliğini, hedef öğeyi, tehdit adını ve önemi yazar. Toplam 58 bulgu çıkar ve 44'ü web uygulamasına düşer. Bu şaşırtıcı değildir: STRIDE-öğe başına tablosunda da en çok soruyu süreç alır.

Burada bir tuzak var. pytm bulguyu, öğeye tanımladığın denetim alanlarına bakarak üretir.

Web sunucusuna controls.validatesInput ve controls.sanitizesInput alanlarını True yazınca bulgu sayısı 49'a iner. Araç girdinin gerçekten doğrulanıp doğrulanmadığını bilmez, yalnız senin beyanına bakar. Beyan ettiğin her denetim kod incelemesinde ya da testte kanıtlanır.