Firewall Kural Temizliği: Kullanılmayan Politikaları Bulma ve Denetleme

Firewall politika denetimi, güvenlik duvarındaki her kuralın hâlâ bir iş gerekçesi taşıdığını, gerçekten trafik gördüğünü ve başka bir kuralın gölgesinde kalmadığını kanıtlarla doğrulama sürecidir. Kural temizliği bu denetimin çıktısıdır: kullanılmayan, mükerrer ve aşırı geniş politikalar kontrollü biçimde daraltılır veya kaldırılır. Sonuç daha küçük bir saldırı yüzeyi, okunabilir bir kural seti ve denetçiye sunulabilir bir kanıt dosyasıdır.

Firewall Kural Temizliği Nedir, Neden Zamanla Kaçınılmaz Olur?

Firewall kural temizliği, güvenlik duvarı politikalarının envanterini çıkarıp trafik görmeyen, başka bir kuralın kapsamında kalan veya gerekçesi ortadan kalkan politikaları tespit ederek kaldırma ya da daraltma işidir. Kural seti canlı bir belgedir; kimse silmeye cesaret edemediği için yalnızca büyür ve büyüdükçe hem risk hem işletme maliyeti artar.

Kural seti işin doğasından büyür. Yeni uygulama devreye alınır, tedarikçiye iki haftalık erişim açılır, sorun giderirken "geçici" bir izin yazılır. Proje biter, tedarikçi ayrılır; kural kalır. Birkaç yıl sonra yüzlerce satırlık listede "bu kuralı silersem ne bozulur" sorusunun yanıtı yoktur.

Bu birikimin üç maliyeti vardır. Güvenlik: aşırı geniş ve unutulmuş izin kuralları, ağa sızan saldırgan için yanal hareket yollarıdır. Operasyon: her değişiklikte yüzlerce kural okunur ve sorun giderme uzar. Uyum: denetçi "bu kural neden var?" sorusuna yanıt alamazsa, cihaz ne kadar güncel olursa olsun bulgu yazar.

Bu yazı politika yönetiminin temellerini tekrar etmez; kural yazımı, nesne yönetimi ve güvenlik profilleri için FortiGate firewall politikaları ve policy yönetimi rehberimize bakabilirsiniz. Burada odak, var olan kural setini denetleyip güvenle küçültmektir. En verimli an cihaz değişimidir: eski firewall'dan FortiGate'e geçiş planında anlattığımız gibi, kuralları denetimden geçirip taşımak yeni cihazı temiz başlatır.

Denetime Nereden Başlanır? Kural Envanteri ve İş Gerekçesi

Firewall denetimi tam bir kural envanteriyle başlar: her cihaz ve sanal alan (VDOM) için politikalar dışa aktarılır, her kurala bir sahip, bir amaç ve bir değişiklik kaydı eşlenir. Gerekçesi bulunamayan kural teknik olarak çalışsa bile şüpheli olarak işaretlenir ve yeniden onay sürecine girer.

Envanter, tarihli bir yapılandırma yedeğiyle başlar; bu yedek hem geri dönüş noktası hem kanıt dosyasının ilk belgesidir. Ardından politika listesi bir tabloya aktarılır: politika kimliği, arayüzler, adres ve servis nesneleri, aksiyon, zamanlama, NAT, güvenlik profilleri, loglama, yorum, hit count ve son kullanım zamanı. Bulgular ve kararlar aynı tabloya işlenir.

Teknik alanlardan daha zor olanı iş bağlamıdır. Her kurala üç soru sorulur: Bu kuralı kim istedi? Hangi iş süreci için gerekli? Ne zaman gereksiz hale gelecek? Yanıtlar yorum alanında ve bilet sisteminde aranır. Denetim sonrasında politika adı ve yorum alanında bilet numarası ile sahip birimi zorunlu kılan bir adlandırma standardı kabul edilmelidir. NIST'in SP 800-41 Rev. 1 Firewall ve Firewall Politikası Rehberi, varsayılan olarak reddetme ilkesine dayanan, her kuralı olabildiğince dar yazılmış ve belgelenmiş bir kural seti önerir; envanter tablosu bu belgenin kurum içindeki karşılığıdır.

Sahibi bilinen kurallar için yeniden onay (recertification) turu açılır: iş birimine kural listesi gönderilir, "hâlâ gerekli" ya da "kaldırılabilir" yanıtı istenir; yanıt gelmeyen kurallar devre dışı bırakma adayı olur. Böylece silme kararı teknik ekipten iş sahibine geçer. Saha deneyimimizde ilk denetimin en uzun adımı budur.

Kullanılmayan Politikalar Nasıl Bulunur? Hit Count ve Son Kullanım Verisi

Kullanılmayan firewall politikası, tanımlı gözlem penceresi boyunca hiç eşleşme almamış kuraldır. FortiGate'te politika tablosundaki hit count ve son kullanım sütunları, CLI'da ise diagnose firewall iprope show 100004 <politika-id> çıktısı ilk ve son eşleşme zamanını verir; FortiAnalyzer logları bu veriyi zaman ekseninde doğrular.

Hit count denetimin en güçlü aracıdır, ancak yanlış yorumlanmaya açıktır. Sayaçlar yeniden başlatma, kural düzenleme veya elle sıfırlama (diagnose firewall iprope clear 100004) sonrasında baştan başlayabilir; FortiOS 7.2 belgelerinde anlatılan yedi günlük kayan sayaç da ekrandaki değerin kapsadığı dönemi değiştirir. "Sıfır" tek başına "hiç kullanılmadı" demek değildir. Sayaçların ne zamandan beri saydığını not edin ve sürümünüzün sayaç davranışını Fortinet belgelerinden doğrulayın. Gözlem penceresi işin ritmine göre belirlenir: rutin trafik için doksan gün makul bir asgaridir; yıl sonu kapanışı veya felaket kurtarma tatbikatı gibi seyrek süreçlerin kuralları altı ile on iki ay ister.

İkinci kanıt kaynağı loglardır. FortiAnalyzer üzerinde trafik logları politika kimliğine göre gruplanarak politika kullanım raporu üretilebilir; bu rapor cihaz sayaçlarından bağımsızdır ve sayaç sıfırlansa bile geçmişi gösterir. Kurulum ve rapor tasarımı için FortiGate loglama ve FortiAnalyzer entegrasyonu yazımıza bakın.

Kullanılmayan kural bulunduğunda yol dört adımdır. Sınıflandırma: hit almayan açık bir deny kuralı çoğu zaman bilinçli bir politikadır ve korunabilir. Devre dışı bırakma: kural silinmez, kapatılır, yoruma tarih ve denetim referansı yazılır. Karantina: örneğin otuz gün kesinti bildirilmezse kural silinebilir. Kayıt: silinen kuralın tam tanımı kanıt dosyasına eklenir. Bu süreçte örtük reddetme (implicit deny) politikasında ihlal trafiği loglamasının açık olması, kaldırılan bir kuralın engellediği gerçek trafiği hemen görünür kılar ve geri alma kararını kolaylaştırır.

Gölge, Yedek ve Çakışan Kurallar Nasıl Tespit Edilir?

Gölgelenmiş kural, üstünde yer alan daha geniş bir kuralın tüm trafiğini yakalaması nedeniyle hiç çalışmayan kuraldır; yedek kural aynı trafiğe aynı aksiyonu tekrarlar; çakışan kural ise kısmen örtüşen trafiğe farklı aksiyon uygular. Üçü de hit count'ta sıfır ya da düşük görünür, fakat kökü sıralama hatasıdır ve çözümü silmek değil yeniden düzenlemektir.

Güvenlik duvarı politikaları yukarıdan aşağıya değerlendirilir ve ilk eşleşen kural kazanır. Bu basit kural, uzun listelerde sürprizler üretir. Örnek: on ikinci sıradaki kural yerel ağdan DMZ'deki uygulama sunucusuna tüm servislere izin veriyorsa, yirmi beşinci sıradaki "yalnızca HTTPS" kuralı hiçbir zaman çalışmaz; yönetici dar bir politika yazdığını düşünür, cihaz geniş olanı uygular. Daha tehlikelisi, misafir ağını sunucudan ayıran bir reddetme kuralının üstteki geniş izin nedeniyle hiç devreye girmemesidir; belgedeki önlem fiilen yoktur.

Tespit için üç yol vardır. FortiManager'ın politika tutarlılık kontrolü (Policy Consistency Check), politika paketindeki mükerrer, gölgelenmiş, örtüşen ve kullanılmayan (orphan) nesneleri raporlar. Bağımsız kural analizi platformları birden çok üreticinin cihazını tek ekranda inceler. Küçük kural setlerinde ise envanter tablosunu adres örtüşmesine göre sıralamak yeterlidir. Aşağıdaki tablo anomali türlerini ve doğru aksiyonu özetler.

Gölge kural bulunduğunda ilk soru "sileyim mi?" değil "hangisi doğru?" olmalıdır. Çoğu zaman gölgede kalan dar kural, gerçek niyeti ifade eder; kaldırılması gereken üstteki geniş kuraldır. Bu nedenle gölge kural analizi, bir sonraki bölümdeki any-any daraltma çalışmasıyla birlikte yürütülür.

Any-Any ve Aşırı Geniş Kurallar: En Riskli Politikaları Daraltma

Any-any kuralı, kaynak, hedef veya servis alanlarından en az ikisinde "all" kullanan politikadır ve ağ segmentasyonunu fiilen iptal eder. Güvenli kaldırma yolu doğrudan silmek değil; önce loglamayı açıp gerçek trafiği ölçmek, bu trafiği karşılayan dar kuralları üstüne yazmak ve geniş kuralı aşamalı olarak devre dışı bırakmaktır.

Any-any kuralları genellikle ilk kurulumda "önce çalışsın" diye açılan izinlerden, sorun giderirken yazılıp unutulan kurallardan ve eski cihazdan taşınan politikalardan gelir. Hit count'ları yüksektir, bu yüzden kullanılmayan kural analizine takılmazlar; yüksek sayaç kuralın gerekli olduğunu değil, çok trafiğin oradan geçtiğini gösterir.

Daraltma altı adımda yürütülür. Birincisi, geniş kuralda tüm oturumların loglanmasını açıp gözlem penceresi boyunca veri biriktirmek. İkincisi, loglardan gerçekten kullanılan kaynak, hedef ve servis üçlülerini çıkarmak. Üçüncüsü, bu akışları dar kurallar olarak geniş kuralın üstüne yazmak. Dördüncüsü, internete çıkan kurallara IPS, antivirüs ve web filtresi profillerini atamak. Beşincisi, geniş kuralın hit count'unun sıfıra düşmesini izlemek; düşmüyorsa kaçırılan bir akış vardır. Altıncısı, sayaç sıfırlandığında geniş kuralı devre dışı bırakmak, karantinayı bekleyip silmek.

Aynı yaklaşım yönetim erişimine de uygulanır: WAN'dan yönetim kapatılır, yönetim yalnızca güvenilir kaynak adreslerinden yapılır. FortiGate ailesinin tüm modellerinde aynı politika mantığı bulunduğundan şube cihazında kurulan disiplin merkez cihaza olduğu gibi taşınır.

Değişiklik Yönetimi ve Denetim Kanıtı: Temizlik Kalıcı Nasıl Olur?

Temizliğin kalıcı olması, her yeni kuralın onaylı bir talep, sahip, amaç ve son kullanma tarihiyle açılmasına bağlıdır. Değişiklik yönetimi öncesi ve sonrası yapılandırma yedeği, onay kaydı ve geri alma planı ister; denetim kanıtı ise tarihli envanter, hit count raporu, kaldırılan kural listesi ve yeniden onay yazışmalarından oluşur.

Temizlenen kural seti, değişiklik süreci yoksa kısa sürede eski haline döner. Asgari süreç: talep iş gerekçesiyle bilete girer; teknik ekip yeni kuralın gölge veya mükerrer olmadığını kontrol eder; onay alınır; değişiklik bakım penceresinde uygulanır; öncesi ve sonrası yedek saklanır. Geçici erişimlerde bitiş tarihli FortiGate zamanlama nesnesi kullanılır; kural süresi dolunca kendiliğinden etkisizleşir. FortiManager'ın revizyon geçmişi ise değişikliği kimin ne zaman yaptığını gösterir.

Denetim kanıtı dosyası, "kural setinizi gözden geçiriyor musunuz?" sorusuna belgeyle yanıt verir: tarihli yedekler, kural envanteri, hit count ve politika kullanım raporu, anomali listesi ve kararlar, kaldırılan kuralların tam tanımı, yeniden onay yanıtları ve değişiklik biletleri. Bu dosya bir sonraki denetimin de başlangıç noktasıdır.

Uyum çerçeveleri bu döngüyü zorunlu kılar. PCI DSS v4.0'ın 1.2.7 gereksinimi ağ güvenlik kontrolü yapılandırmalarının en az altı ayda bir gözden geçirilmesini ister. Kişisel Verileri Koruma Kurumu'nun Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler) güvenlik duvarı ve erişim yetkilerinin yönetimini teknik tedbirler arasında sayar; bu tedbirlerin firewall tarafındaki karşılığını KVKK teknik tedbirler kontrol listemizde ayrıntılı ele aldık. Trafik ve olay loglarının saklama yükümlülükleri için 5651 sayılı Kanun ve merkezi log yönetimi yazımıza bakın; her iki konuda da güncel mevzuatı ve resmî rehberi doğrulamanızı öneririz. İç ekibin bu döngüye zaman ayıramadığı kurumlarda periyodik politika denetimi, yönetilen firewall hizmetinin standart kapsamında yer alır.

Firewall Politika Denetimi Kontrol Listesi

Firewall politika denetimi kontrol listesi, bir denetimi baştan sona yürütmek ve sonucunu kanıtla belgelemek için kullanılır. Her satır tek bir soruya evet ya da hayır yanıtı verir ve hangi kanıtın dosyaya konacağını belirtir; liste en az altı ayda bir, yüksek değişimli ortamlarda üç ayda bir tekrarlanır.

Her "hayır" yanıtını bir aksiyon maddesine çevirin. İlk denetimde çok sayıda "hayır" çıkması normaldir; amaç sonraki döngülerde denetimin rutin bakıma dönüşmesidir. Projelerimizde en hızlı kazanım yorum alanı standardı ve bitiş tarihli zamanlamadan gelir.

Sık Sorulan Sorular

Firewall kural temizliği ne sıklıkla yapılmalı?

PCI DSS v4.0'ın 1.2.7 gereksinimi ağ güvenlik kontrolü yapılandırmalarının en az altı ayda bir gözden geçirilmesini ister. Sık değişen ortamlarda üç aylık döngü daha sağlıklıdır; büyük bir migrasyon veya yeniden yapılanma sonrasında ise plan dışı bir denetim yapılmalıdır.

Hit count sıfır olan bir kuralı hemen silmek güvenli mi?

Hayır. Sayaç yeniden başlatma veya kural düzenlemesiyle sıfırlanmış olabilir, yıllık süreçler gözlem penceresine girmemiş olabilir. Önce sayaçların ne zamandan beri saydığını doğrulayın, kuralı devre dışı bırakıp karantina süresi bekleyin, ardından silin ve kaydını tutun.

Gölgelenmiş kural ile yedek (mükerrer) kural arasındaki fark nedir?

Gölgelenmiş kural, üstündeki daha geniş bir kuralın trafiğini tamamen yakalaması nedeniyle hiç çalışmaz ve niyet edilen politikanın uygulanmaması riskini taşır. Yedek kural aynı trafiğe aynı aksiyonu tekrarlar; işlevsel zararı yoktur ama kural setini şişirir ve bakımı zorlaştırır.

FortiGate'te kullanılmayan politikaları nasıl görürüm?

Politika tablosundaki hit count ve son kullanım sütunlarını görünür yapın ve sıfır ya da eski tarihli satırları filtreleyin. CLI'da diagnose firewall iprope show 100004 komutu politika başına ilk ve son eşleşme zamanını verir; FortiAnalyzer politika kullanım raporu bu bulguyu log tarafından doğrular.

Any-any kuralını kaldırırsak iş uygulamaları durur mu?

Doğru sırayla yapılırsa durmaz. Önce geniş kuralda tüm oturum loglamasını açıp gözlem penceresi boyunca gerçek trafiği ölçün, bu trafiği karşılayan dar kuralları üstüne yazın ve geniş kuralın hit count'unun sıfıra düşmesini bekleyin. Ancak o zaman devre dışı bırakın.

Firewall politika denetimi KVKK ve PCI DSS için kanıt sayılır mı?

Kanıt, denetimin kendisi değil çıktılarıdır: tarihli kural envanteri, hit count raporu, kaldırılan ve daraltılan kural listesi, sahiplerin yeniden onay yazışmaları ve değişiklik kayıtları. Bu dosya, KVKK teknik tedbirlerinin ve PCI DSS düzenli gözden geçirme gereksiniminin uygulandığını gösterir.

Kural temizliğini dışarıdan bir ekibe yaptırmak mantıklı mı?

İç ekip günlük operasyonla dolu ise mantıklıdır; periyodik politika denetimi çoğu yönetilen firewall hizmetinin kapsamında yer alır. Kritik nokta, kural silme kararının iş sahipleriyle birlikte verilmesi ve her adımın kayıt altına alınmasıdır; dış ekip analiz ve uygulamayı, kurum ise onayı üstlenir.

Sonuç

Firewall kural temizliği, cihazın gücünü artırmaz; cihazın gerçekten sizin yazdığınız politikayı uygulamasını sağlar. Envanterle başlayan, kullanılmayan kuralları ayıklayan, gölge ve any-any kuralları düzenleyen ve her adımı belgeleyen bir denetim döngüsü saldırı yüzeyini küçültür, uyum için savunulabilir bir dosya üretir. Kalıcılığın sırrı teknik değil süreçseldir: onaylı talep, sahip, amaç ve bitiş tarihi olmayan kural açılmaz.

Kural setinizin ilk denetimini planlamak, mevcut FortiGate yapılandırmanızı gözden geçirmek ya da periyodik denetimi yönetilen hizmet kapsamına almak için Sora Yazılım ile ücretsiz bir keşif görüşmesi planlayabilirsiniz; ihtiyacınıza uygun kapsamı birlikte belirleyip teklif hazırlarız.