Güvenli yazılım geliştirme: SDLC, tasarım ilkeleri ve tehdit modelleme

Güvenlik açıklarının çoğu “kötü kodlanmış satır” değil, kötü verilmiş kararlardır: kimse yetkiyi düşünmemiştir, hata durumunda ne olacağı tanımlanmamıştır, admin paneli internete açık bırakılmıştır. Bu hafta güvenliği yazılım yaşam döngüsünün (SDLC) içine nasıl yerleştireceğini öğreniyorsun. Sınavda tipik soru şöyle: kısa bir senaryo verilir, “which principle is violated?” ya da “which STRIDE category?” diye sorulur. Bir de DREAD veya risk hesabı gelebilir.

Altın kurallar:

1. Güvenlik bir aşama değil, her aşamadır. Gereksinimde başlar, bakımda bitmez.
2. Varsayılan cevap “hayır”. Emin değilsen erişimi reddet.
3. Her erişimi denetle. Bir kez kontrol edip unutmak yetmez.
4. Tehditleri sistematik bul. STRIDE harf harf sorgulatır, akla gelmeyeni yakalar.
5. Riski sayıyla sırala. Her şeyi aynı anda düzeltemezsin.

Güvenli SDLC (secure software development life cycle)

Klasik SDLC aşamalarına her birinde yapılacak güvenlik işini ekleyince güvenli SDLC elde edilir. Microsoft SDL, OWASP SAMM, BSIMM bu fikrin farklı çerçeveleridir.

Neden en başta? Bir tasarım hatasını tasarım aşamasında düzeltmek bir diyagram değişikliğidir. Aynı hata canlı sistemde bulunursa kod, veri göçü, müşteri bildirimi ve itibar kaybı gelir. Literatürdeki “geç bulunan hatanın maliyeti katlanır” eğrisi güvenlik için daha da diktir.

TUZAK · “Sonunda pentest yaparız” yaklaşımı. Penetrasyon testi bulduğu açığı gösterir ama tasarım hatasını sonradan düzeltmek pahalıdır. Pentest güvenli SDLC’nin yerine geçmez, son kontrolüdür.

Güvenli tasarım ilkeleri (Saltzer & Schroeder)

1975’te Saltzer ve Schroeder’in yazdığı sekiz ilke bugün hâlâ sınavların gözdesi. Yanına sık eklenen derinlemesine savunmayı da koyuyoruz.

Fail-safe defaults: kodda nasıl görünür

// KÖTÜ: servis çökünce herkese izin
boolean canRead(User u, File f) {
    try { return acl.allows(u, f, READ); }
    catch (Exception e) { return true; }
}

// İYİ: belirsizlikte reddet, olayı kaydet
boolean canRead(User u, File f) {
    try { return acl.allows(u, f, READ); }
    catch (Exception e) {
        log.warn("ACL check failed, denying", e);
        return false;
    }
}

Aynı fikir firewall kurallarında da geçerli: en sonda “deny all” kuralı olur, izin verilenler tek tek yazılır (allowlist).

Derinlemesine savunma ve olasılık

Bağımsız katmanlarda saldırganın her birini aşma olasılığı çarpılır. Örnek: WAF’ı geçme olasılığı 0.3, uygulama içi doğrulamayı geçme 0.2, veritabanı yetki kısıtını geçme 0.1 ise hepsini geçme olasılığı:

$0.3 \times 0.2 \times 0.1 = 0.006$

Tek tek zayıf görünen katmanlar birlikte güçlüdür. Ama dikkat: katmanlar aynı zayıflığı paylaşıyorsa (aynı parola, aynı kütüphane) bağımsız değildir ve çarpım geçersiz olur.

İPUCU · İlkeyi bulma yöntemi. Senaryoda “fazla yetki” varsa least privilege, “hata olunca izin” varsa fail-safe, “bir kez kontrol” varsa complete mediation, “gizli algoritma” varsa open design, “tek kişi yeterli” varsa separation of privilege.

Tehdit modelleme (threat modeling)

Tehdit modelleme dört soruya cevap arar: Ne inşa ediyoruz? Ne ters gidebilir? Buna karşı ne yapacağız? İyi bir iş çıkardık mı?

Adım 1: veri akış diyagramı (DFD)

Sistemi dört öğeyle çizersin:

Bunların üstüne güven sınırı (trust boundary) çizgileri çizilir: internet ile sunucu arası, uygulama ile veritabanı arası. Tehditlerin çoğu bu sınırları geçen akışlarda ortaya çıkar, çünkü bir taraf diğerinin verisine güvenmemelidir.

Adım 2: STRIDE

Her DFD öğesini altı tehdit kategorisiyle sorgularsın:

Örnek: “Kullanıcı → Login API” akışı için S: başkasının parolasıyla giriş; T: istek yolda değiştirilir; R: kullanıcı girişi inkâr eder; I: hata mesajı “bu e-posta kayıtlı değil” diyerek kullanıcı varlığını sızdırır; D: saniyede binlerce login denemesi; E: istekteki role=admin alanına güvenilmesi.

Adım 3: riskleri sırala

İki yaygın yöntem var.

Risk = olasılık × etki. Olasılık 0-1, etki 1-10:

Sıra: T2 > T3 > T1. Etkisi en büyük olan T1 en sonda, çünkü olasılığı düşük.

DREAD. Beş kategori 0-10 puanlanır, ortalaması alınır: Damage, Reproducibility, Exploitability, Affected users, Discoverability.

DREAD öznel olduğu için Microsoft içeride bırakmıştır, ama ders kitaplarında ve sınavlarda hâlâ çıkar. CVSS daha standart bir alternatiftir.

Adım 4: önlem ve doğrulama

Her tehdit için dört seçenek var: azalt (mitigate), ortadan kaldır (özelliği kaldır), devret (sigorta, üçüncü taraf), kabul et (belgelenmiş karar). Sonra önlemin gerçekten çalıştığı testle doğrulanır.

Güvenlik gereksinimleri ve misuse case

Fonksiyonel gereksinim “sistem ne yapmalı” der. Güvenlik gereksinimi “sistem neye izin vermemeli ve nasıl korunmalı” der. İyi bir güvenlik gereksinimi ölçülebilir ve test edilebilir olur.

Bu gereksinimleri bulmanın yolu misuse case yazmaktır. Normal use case’te aktör “Müşteri”, senaryo “Hesabına giriş yapar”. Misuse case’te aktör “Saldırgan” (misactor), senaryo “Parola listesini otomatik dener”. Misuse case, use case’i “tehdit eder” (threatens); karşı önlem misuse case’i “azaltır” (mitigates). Her misuse case bir güvenlik gereksinimi doğurur.

TUZAK · Güvenlik gereksinimini fonksiyonel gibi yazmamak. “Admin kullanıcıları silebilir” fonksiyoneldir. Güvenlik tarafı: “Sadece admin rolü silebilir, her silme işlemi kimin yaptığıyla loglanır.” İkinci cümle test edilebilir ve E ile R tehditlerini kapatır.

Sık yapılan hatalar

boolean canDelete(User u, Doc d) {
    try {
        return acl.check(u, d, "DELETE");
    } catch (Exception e) {
        return true;   // ACL service down, let it through
    }
}