SQL Risk Skorlama: Ortalama Almak Neden Yanlış?

Bir SQL script'ine risk puanı vermek kulağa nesnel gelir. Kurallar tanımlanır, her kurala bir ağırlık verilir, tetiklenen kuralların puanları toplanır ve ortaya bir sayı çıkar. Bu sayı raporlarda güzel durur. Sorun şu ki, karar verirken çoğu zaman yanıltır.

Toplama Modelinin Sorunu

İki script düşünün. Birincisi altı küçük adlandırma kuralını ihlal ediyor ama yaptığı iş zararsız. İkincisi tek bir kuralı ihlal ediyor: WHERE koşulu olmadan bir DELETE içeriyor. Toplama modeli birinciye daha yüksek risk puanı verebilir. Oysa birincisi en fazla kod okunabilirliğini bozar, ikincisi tabloyu boşaltır.

Daha kötüsü, ortalama alan modellerde küçük bulgular kritik bulguyu seyreltir. Bir kritik ve dokuz bilgi seviyesi bulgu, ortalamada "orta risk" görünebilir. Bu, güvenlik açısından kabul edilemez bir davranıştır: risk seyreltilemez.

Bant Yaklaşımı

Bant yaklaşımında her kural bir seviye taşır: bilgi, düşük, orta, yüksek, kritik. Bir script çalıştırıldığında tetiklenen kuralların en yükseği bandı belirler. Toplama yoktur, ortalama yoktur, çarpan yoktur. En kötü durum kararı verir.

Bu yaklaşımın üç pratik faydası vardır. Birincisi, karar tahmin edilebilir olur: aynı kural aynı sonucu verir. İkincisi, açıklanabilir olur: "kararı hangi kural verdi" sorusunun tek bir cevabı vardır. Üçüncüsü, tartışma kuralın seviyesine taşınır. "Bu kural gerçekten kritik mi" sorusu sağlıklı bir tartışmadır; "62 puan yüksek mi" sorusu değildir.

Sayısal skor tamamen atılmak zorunda değildir. Bandın okunur bir yansıması olarak kullanılabilir: yönetim raporlarında eğilim göstermek için kullanışlıdır. Kritik olan, kapı kararının bu sayıya değil banda bağlı olmasıdır.

Atlanamaz Kural Kavramı

Her onay sürecinde bir hızlandırma yolu vardır: acil durumlarda adım atlama, tek onayla ilerleme, otomatik çalıştırma. Bu yollar gereklidir ama sınırsız olmamalıdır. Bazı kurallar tetiklendiğinde hiçbir hızlandırma geçerli olmamalıdır.

Atlanamaz işaretlenen bir kural tetiklendiğinde onay adımları atlanamaz. Bu, hız ile güvenlik arasındaki dengeyi kural düzeyinde kurmanın yoludur: sıradan değişiklikler hızlı ilerlerken, tanımlı bir eşiği aşan değişiklikler tam süreçten geçer. Liste kısa tutulmalıdır; her kuralı atlanamaz yapan bir sistem, acil durumda tamamen devre dışı bırakılır.

Açıklanabilir Karar

Bir risk modeli, kararını üç kitleye açıklayabilmelidir: script'i yazan geliştiriciye, onaylayan yöneticiye ve altı ay sonra bakan denetçiye. Bu üç kitle farklı şeyler sorar ama hepsi aynı bilgiyi ister: neden bu sonuç?

İyi bir açıklama şunları içerir: tetiklenen tüm kuralların listesi, her birinin seviyesi, kararı belirleyen kuralın hangisi olduğu ve diğer bulguların karara etkisinin olmadığı bilgisi. Son madde önemlidir; aksi halde geliştirici küçük bulguları düzelterek bandı düşürmeye çalışır ve zaman kaybeder.

Aynı açıklamanın denetim kaydına ve kanıt paketine de yazılması gerekir. Denetçi ekranda gördüğünüz gerekçenin aynısını okuduğunda tartışma biter.

Kendi Modelinizi Kurarken

Sık Sorulan Sorular

Risk puanlarını toplamak neden yanlış?

Çünkü toplama, çok sayıda küçük bulgunun tek bir kritik bulguyu geçmesine izin verir. Yedi biçimsel uyarı toplandığında kritik bir DROP ifadesiyle aynı puana ulaşabilir, oysa ikisi aynı şey değildir. Bandı en yüksek bulgunun belirlemesi, kararın anlamını korur.

Atlanamaz kural ile yüksek riskli kural arasındaki fark ne?

Yüksek riskli kural bandı yükseltir ve daha fazla onay gerektirir; süreç yine de akar. Atlanamaz kural ise politika ne derse desin ilgili onay adımının atlanmasını engeller. Biri riskin ölçüsüdür, diğeri kontrolün alt sınırıdır.

Skorun açıklanabilir olması neden bu kadar önemli?

Çünkü açıklanamayan bir skor tartışılamaz. Onaylayan kişi neden yüksek riskli olduğunu göremezse ya körü körüne onaylar ya da sistemi dikkate almaz. Denetçi de aynı soruyu sorar: bu karar neye dayanıyor. Hangi kuralın bandı belirlediği görünür olduğunda skor bir gerekçeye dönüşür.