Güvenlik Duvarı Kural Analizi Neden Gerekir?

Kısa cevap

Güvenlik duvarı kural seti, kurulduğu gün doğru olsa bile zamanla bozulur: geçici kurallar kalıcılaşır, kullanılmayan kurallar birikir, geniş "her şeye izin" satırları alta değil üste kayar, kimin neden eklediği unutulur.
Kural analizi, kural setini üç eksende gözden geçirmektir: hijyen (gereksiz, yinelenen, gölgelenmiş kurallar), uyumluluk (kurum politikası ve mevzuat/standart gerekleri) ve risk (internete açık tehlikeli servisler, aşırı geniş erişimler).
Kılavuzlar ve standartlar da bunu açıkça ister: ABD standart kurumu NIST'in güvenlik duvarı kılavuzu (SP 800-41 Rev. 1) kural setlerinin olabildiğince özgül olmasını, varsayılan reddet yaklaşımını, periyodik gözden geçirmeyi ve resmî değişiklik yönetimini önerir; PCI DSS v4.0.1 ise ağ güvenlik kontrolü yapılandırmalarının en az altı ayda bir gözden geçirilmesini şart koşar (gereklilik 1.2.7).
Pratik yöntem: kural setini dışa aktarıp yedekle, kullanım (hit) verisiyle eşleştir, kuralları sınıflandır, riskli olanları puanla, değişiklikleri kayıt altında uygula, altı ayda bir tekrarla.

Kural seti neden bozulur?

Bir güvenlik duvarı, yıllar içinde yüzlerce kurala ulaşabilir; sayı ne olursa olsun bozulmanın tipik biçimleri aynıdır:

Geçici kural kalıcılaşır. "Bugünlük aç, yarın kapatırız" denilen erişim yıllarca kalır.
Kullanılmayan kurallar birikir. Sunucu emekliye ayrılır, kural kalır; sıfır hit almasına rağmen silinmez.
Gölgelenmiş (shadowed) kurallar. Yukarıdan aşağı ilk eşleşmeyle çalışan güvenlik duvarlarında üstteki geniş bir kural, alttaki özgül kuralın hiç çalışmamasına yol açar; yönetici alttakine bakıp "kısıtlı" sanır.
Yinelenen ve çakışan kurallar. Aynı erişim iki farklı nesne grubuyla iki kez tanımlanır; biri güncellenir, diğeri kalır.
"Any" şişmesi. Kaynak, hedef ya da servis alanında any kullanımı, sorun giderme kolaylığı için başlar, kalıcı olur.
Belgesiz değişiklik. Kuralın kim tarafından, hangi talep için, ne zaman eklendiği bilinmez; silmeye kimse cesaret edemez.
Nesne karmaşası. Aynı sunucu için üç farklı adres nesnesi; adı "test", "yeni", "eski2" olan gruplar.

Sonuç: kural seti hem daha geniş (gereksiz erişimler açık) hem daha az anlaşılır (kimse tamamını okuyamaz) hale gelir. Güvenlik duvarının kendisi sağlıklıdır; politikası çürümüştür.

Standartlar ne diyor?

NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy (Eylül 2009). Kılavuz şunları söyler: (1) Kural setleri "kontrol ettikleri ağ trafiği bakımından olabildiğince özgül" olmalıdır. (2) Açıkça izin verilmemiş gelen ve giden trafik için varsayılan reddet (deny by default) yaklaşımı, "açıkça yasaklanmayan her şeye izin vermekten daha güvenli"dir. Kılavuz, uygulamada giden trafik için daha gevşek politikaların yaygın olduğunu da not eder. (3) Politika kuralları yeni tehditler ve gereksinim değişiklikleriyle güncellenmeli, güvenlik politikasına uyumun sürmesi için periyodik olarak gözden geçirilmelidir. (4) Kural setleri ve politikalar resmî bir değişiklik yönetimi süreciyle yönetilmeli; periyodik kural seti gözden geçirmeleri ya da testleri yapılmalıdır. (5) Log ve alarmlar sürekli izlenmelidir.

PCI DSS v4.0.1 (ödeme kartı verisi işleyenler için). Gereklilik 1.2.7: ağ güvenlik kontrollerinin (NSC) yapılandırmaları, ilgili ve etkili olduklarını doğrulamak için en az altı ayda bir gözden geçirilir. Kart verisi işlemeyen kurumlar için bağlayıcı değildir; bu yazıda referans periyot olarak PCI DSS'nin altı ayı esas alınmıştır (NIST süre vermez, "periyodik" der).

KVKK açısından. Kişisel Veri Güvenliği Rehberi, internetten gelen izinsiz erişime karşı öncelikli tedbir olarak güvenlik duvarı ve ağ geçidini sayar ve "iyi yapılandırılmış" bir güvenlik duvarının ihlalleri ağa nüfuz etmeden durdurabileceğini belirtir — yani Rehber cihazı tedbir olarak sayar, ama tedbirin etkisini yapılandırmasının kalitesine bağlar.

Kural analizinin üç ekseni

1. Hijyen

Kullanılmayan kurallar (belirli süredir sıfır eşleşme).
Gölgelenmiş kurallar (üstteki kural tarafından hiç erişilemeyen).
Yinelenen/çakışan kurallar ve nesneler.
Açıklama alanı boş, sahibi ve talep numarası olmayan kurallar.
Süresi dolmuş geçici kurallar (bitiş tarihi geçmiş ya da hiç konmamış).

2. Uyumluluk

Açıkça izin verilmemiş trafik için varsayılan reddet var mı; son kural açık bir "her şeyi reddet" mi ve reddedilen trafik, hacmin izin verdiği ölçüde loglanıyor mu (iyi uygulama; standartların açık şartı değil)?
Yönetim arayüzüne (SSH/HTTPS) erişim yalnızca yönetim ağından mı?
İnternete çıkış kurallarında oturum logu açık mı (5651 erişim kaydı ve merkezi log toplama için şart)?
Segmentasyon politikasına uyum: misafir ağı, sunucu ağı, OT/kamera ağı birbirinden ayrı mı; ayrılık kurallara yansımış mı?
Kart verisi gibi özel kapsamlar için standardın istediği kısıtlar (PCI DSS) sağlanıyor mu?

3. Risk

İnternete açık uzak masaüstü (RDP), SMB, veritabanı ve yönetim portları.
Kaynak any ile gelen (inbound) kurallar.
Servis alanı any ya da geniş port aralıkları içeren kurallar.
VPN kullanıcılarına iç ağın tamamına erişim veren kurallar.
Test/geçici amaçlı açılıp kapatılmamış geçitler.
Uzun süredir değişmemiş ama yüksek hacimli trafik geçiren, kimsenin gerekçesini bilmediği kurallar.

Adım adım kural analizi

Dışa aktar ve yedekle. Kural setini ve nesne tanımlarını dışa aktarın; analiz öncesi yapılandırma yedeğini alın (değişiklik takibi için sürümleyin).
Kullanım verisiyle eşleştirin. Kural başına eşleşme sayacı (hit count) ve varsa son eşleşme zamanını alın; sayaçların ne zamandan beri biriktiğini not edin (yeniden başlatma veya politika yükleme sıfırlayabilir) ve gözlem penceresini logla doğrulayın. Sıfır hit alan kuralları "aday" olarak işaretleyin, hemen silmeyin.
Nesneleri çözümleyin. Grupları üyelerine açın; aynı adresi temsil eden çoklu nesneleri birleştirin.
Sınıflandırın. Her kuralı hijyen/uyumluluk/risk etiketleriyle işaretleyin; gölgelenme analizini cihazın kural işleme mantığına (çoğu üründe kural sırası) göre yapın.
Puanlayın ve önceliklendirin. İnternete açık tehlikeli servisler ve any kaynaklı gelen kurallar en üste; kullanılmayan kurallar temizlik listesine.
Değişiklik yönetimiyle uygulayın. Her silme/daraltma bir talep, bir onay, bir uygulama penceresi ve bir geri alma planıyla yapılır; kaldırılan kurallar önce devre dışı bırakılıp bir süre izlenir.
Doğrulayın. Değişiklik sonrası iş uygulamalarının çalıştığını ve logda beklenmedik reddin oluşmadığını kontrol edin.
Periyodu yazın. En az altı ayda bir tam analiz; büyük değişikliklerden sonra hedefli analiz.

Sık yapılan hatalar

Analizi yalnızca cihaz arayüzünden, kural sırasını dikkate almadan yapmak (gölgelenme kaçar).
Kullanılmayan kuralları hit sayacına bakmadan silmek — bazı kurallar yılda bir çalışır (yıl sonu kapanışı, felaket kurtarma testi).
Yedek almadan temizlik yapmak.
Analizi tek seferlik proje sanmak; kural seti zamanla yine bozulur, periyodik gözden geçirme bu yüzden gerekir.
Log kapalı kurallar: 5651 ve SIEM için gereken oturum kaydı üretilmez, sorun ancak yasal talepte anlaşılır.

voosec'te nasıl yapıyoruz?

PolicyLens güvenlik duvarı kural setini hijyen, uyumluluk ve risk açısından değerlendirir ve raporlar; kural setini de içeren cihaz yapılandırmasının değişiklik izini ConfigVault tutar (düzenli yedekleme, sürümleme ve diff takibi). İkisi de giriş paketi Görünürlük'ten itibaren tüm paketlerde yer alır.
Aynı güvenlik duvarının oturum logları SIEM korelasyonuna ve LogVault eklentisi (paketten ayrı seçilir, kapsam cihaz başına) seçildiyse imzalı 5651 arşivine gider; böylece "kural analizi", "log toplama" ve "izleme" aynı panelde birbirini destekler.
Kural değişikliği kararı ve uygulaması sizde ya da yetkilendirdiğiniz kişide kalır; PolicyLens kural setini değerlendirir, bulguları ve riskleri raporlar.

Sık sorulanlar

Kural analizini ne sıklıkla yapmalıyız?

En az altı ayda bir tam analiz (PCI DSS'nin de istediği periyot) ve önemli değişikliklerden — yeni sunucu, yeni şube, VPN yapılandırması — sonra hedefli bir gözden geçirme.

Kural sayısını azaltmak performansı artırır mı?

Kural sayısı ve sırası bazı platformlarda performansı etkileyebilir; NIST SP 800-41 de sık eşleşen kuralların üste alınmasını önerir. Ancak analizin asıl kazancı performans değil, kural setinin okunabilir ve savunulabilir hale gelmesidir; gereksiz ve aşırı geniş kurallardan arındırılmış bir set daha kolay denetlenir.

Değişiklikleri kim yapmalı?

Analiz raporu bulguları ve riskleri ortaya koyar; kuralı silme veya daraltma kararı, iş etkisini bilen kurum yöneticisinin onayıyla, değişiklik yönetimi kaydı altında uygulanmalıdır.

Kaynaklar

Bu yazı genel bilgilendirme amaçlıdır; hukuki görüş niteliği taşımaz.