🧩 Kural Tablonuz Neden Şişiyor? FortiGate için 7 Basit Kural

İlgili yazılar

FortiGate DNS Troubleshooting: IP Çalışıyor Ama Domain Çalışmıyor

1 gün önce

FortiGate Session Table: Policy Değişti Ama Trafik Neden Eski Davranıyor?

1 hafta önce

FortiGate Troubleshooting: Trafik Gerçekten Nerede Kesiliyor?

2 hafta önce

FortiGate policy tablosu zaman içinde kolayca şişer: dağınık objeler, ANY/ALL servisler, kopyala-yapıştır istisnalar, gölgelenen kurallar, sahibi belli olmayan geçici izinler…

Sonuç nettir:

• Değişiklik yönetimi yavaşlar.
• Denetimlerde açıklama yapmak zorlaşır.
• Yanlış pozitif ve alarm kalabalığı artar.
• Kural sırası karmaşıklaştıkça troubleshooting süresi uzar.
• Gereksiz geniş izinler saldırı yüzeyini büyütür.

FortiGate policy tablosunu temiz, anlaşılır ve denetlenebilir tutmanın yolu; isimlendirme, sahiplik, kullanım takibi, NAT disiplini ve otomasyonun birlikte yönetilmesidir.

---

Neden şimdi?

🚦 Kural kalabalığını azalt → troubleshooting ve değişiklik süresi düşsün
🧾 Denetime hazır yapı kur → kim, neden, ne zamana kadar izin aldı net olsun
🔒 Saldırı yüzeyini küçült → ANY/ALL ve sahipsiz izinleri temizle
📊 Hit-count ile karar ver → gerçekten kullanılan ve kullanılmayan kuralları ayır
🤖 Otomasyonla sürdürülebilir yap → unutulan istisnaları otomatik gündeme getir

---

✅ FortiGate Policy Tablosu için 7 Basit Kural

1️⃣ 🏷️ İsimlendirme Standardı Oluştur

İsimlendirme standardı yoksa birkaç ay sonra obje ve policy tablosu okunamaz hale gelir.

Policy adı formatı

[SRC-ZONE]-[DST-ZONE]-[APP]-[ENV]-[FUNC]

Örnek:

LAN-DMZ-WEB-PROD-APP
BRANCH-DC-PAYMENT-PROD-API
VPN-LAN-ADMIN-PROD-MGMT

Obje önekleri

SRV_  → Sunucu objeleri
GRP_  → Address group objeleri
SVC_  → Servis objeleri
VIP_  → DNAT/VIP objeleri
NET_  → Network/subnet objeleri

Örnek:

SRV_PAYMENT_API_10.10.10.20
GRP_BRANCH_USERS
SVC_HTTPS_443
VIP_PAYMENT_PUBLIC_185.x.x.x

Comment standardı

Her policy açıklamasında minimum şu alanlar olmalı:

[OWN=AppTeam][REQ=CHG-123][EXP=2026-12-31][WHY=Payment API Access]

Bu standart sayesinde denetimde “bu kural neden var?” sorusuna hızlı cevap verilir.

---

2️⃣ 🗂️ Bölümlendirme ve Sıralama Yap

FortiGate policy tablosunda kurallar yukarıdan aşağıya çalışır. Bu yüzden sıralama sadece görsel değil, doğrudan güvenlik davranışını etkiler.

Önerilen bölüm yapısı

01-CRITICAL-BUSINESS
02-DMZ-INBOUND
03-BRANCH-TO-DC
04-VPN-USERS
05-INTERNET-OUTBOUND
06-TEMPORARY-EXCEPTIONS
99-CLEANUP-DENY

Sıralama prensibi

• Kritik ve dar kapsamlı izinler üstte
• Genel kullanıcı internet çıkışı daha altta
• Geçici istisnalar ayrı section altında
• Cleanup deny en altta
• Geniş kurallar spesifik kuralların üstüne konulmamalı

---

3️⃣ 🎯 ANY / ALL Kullanımını Azalt

src:any, dst:any, service:ALL gibi kurallar hızlı çözüm gibi görünür ama uzun vadede en büyük güvenlik borcudur.

Kötü örnek

src:any dst:any svc:ALL action:ACCEPT log:off

İyi örnek

src:GRP_BRANCH_USERS
dst:SRV_PAYMENT_API
svc:SVC_HTTPS
action:ACCEPT
profile:UTM-PROD_APP_INSPECT
log:all
comment:[OWN=AppTeam][REQ=CHG-123][EXP=2026-12-31]

Pratik yaklaşım

• Servisleri netleştirin: SVC-HTTPS, SVC-DNS, SVC-NTP
• Gerektiğinde service-group kullanın
• Uygulama bazlı kontrol gerekiyorsa App Control profili bağlayın
• Geçici ANY izinlere mutlaka EXP tarihi koyun

---

4️⃣ 🕶️ Shadow ve Duplicate Kuralları Avlayın

Üstteki geniş bir kural, alttaki daha dar kuralı tamamen gölgeleyebilir. Bu durumda alttaki kural tabloda görünür ama pratikte hiç çalışmaz.

Kontrol edilecek başlıklar

• Aynı source/destination/service ile tekrar eden kurallar
• Üstteki geniş kuralın alttaki spesifik kuralı gölgelemesi
• Aynı VIP’e farklı açıklamalarla açılmış tekrar kurallar
• Eski migration’dan kalan kullanılmayan objeler
• Hit-count değeri sıfır olan policy’ler

FortiManager ile yapılacaklar

• Policy Package Diff
• Object Usage
• Policy Check
• Find Unused Policies
• Hit-count kontrolü

Kural: 90 gün ve üzeri hit almayan policy doğrudan silinmez; önce sahibiyle doğrulanır, sonra disable edilir, izlenir ve kaldırılır.

---

5️⃣ 👤 Sahiplik ve Yaşam Döngüsü Tanımlayın

Her kuralın bir sahibi olmalı. Sahibi olmayan kural, güvenlik borcudur.

Her policy’de zorunlu alanlar

OWN  → Kural sahibi ekip
REQ  → Change / Jira / talep numarası
EXP  → Bitiş tarihi
WHY  → İş gerekçesi
ENV  → PROD / TEST / UAT

Örnek:

[OWN=Network][REQ=CHG-456][EXP=N/A][WHY=Branch to DC DNS][ENV=PROD]

Yaşam döngüsü modeli

1. Talep açılır.
2. Risk ve kapsam kontrol edilir.
3. Policy oluşturulur.
4. Hit-count ve log izlenir.
5. Süresi dolan veya hitsiz kurallar review edilir.
6. Gerekirse disable edilir.
7. Doğrulama sonrası silinir.

---

6️⃣ 🔁 Tutarlı NAT Stratejisi Kullanın

NAT karmaşası policy tablosunu en hızlı şişiren alanlardan biridir. VIP, DNAT, SNAT ve Central SNAT tutarlı yönetilmezse troubleshooting zorlaşır.

Önerilen yaklaşım

• Central SNAT kullanılıyorsa tüm çıkış NAT’ları aynı mantıkta yönetilsin.
• VIP objelerinde public IP, private IP ve servis net yazılsın.
• “1 public IP → 1 VIP mantığı” mümkün olduğunca korunmalı.
• VIP açıklamalarında owner, servis ve talep numarası bulunmalı.
• NAT policy ile firewall policy açıklamaları tutarlı olmalı.

VIP isim örneği

VIP_PAYMENT_API_185.x.x.x_TO_10.10.10.20_HTTPS

SNAT açıklama örneği

[OWN=Network][REQ=CHG-789][WHY=Branch Internet NAT][POOL=ISP1_GENERAL]

---

7️⃣ 📊🤖 Görünürlük ve Otomasyon ile Sürdürülebilir Hale Getirin

Policy temizliği tek seferlik iş değildir. Her ay düzenli çalıştırılmalı ve otomasyonla desteklenmelidir.

FortiAnalyzer / FortiManager metrikleri

• Top rules by hits
• Zero-hit rules
• Last used
• Top sources
• Top destinations
• Top services
• Deny log trendleri
• UTM event yoğunluğu

Otomasyon fikirleri

• 60 gün hitsiz policy → sahibine otomatik uyarı
• 90 gün hitsiz policy → review ticket
• EXP tarihi yaklaşan kural → owner’a bildirim
• Geçici istisna süresi doldu → disable önerisi
• High-risk policy değişikliği → ikinci onay

Automation Stitch örneği

Trigger: Policy/UTM event veya scheduled kontrol
Action: Email / Webhook / Ticket / Notification
Amaç: Sahipsiz veya süresi dolmuş kuralları gündeme getirmek

---

⚠️ Kötü → ✅ İyi Örnek

Kötü

src:any
dst:any
svc:ALL
action:ACCEPT
log:off
comment:boş

İyi

src:BRANCH_*
dst:SRV_PAYMENT_API
svc:SVC_HTTPS
action:ACCEPT
profile:UTM-PROD_APP_INSPECT
log:all
comment:[OWN=AppTeam][REQ=CHG-123][EXP=2026-12-31][WHY=Payment API Access]

---

⚡ 48s Mini-PoC Planı

1. FortiManager veya FortiGate üzerinde policy hit-count görünümünü açın.
2. Son 60–90 günde hit almayan kuralları listeleyin.
3. ANY/ALL içeren kuralları ayrı raporlayın.
4. En riskli 10 policy için owner ve change ID kontrolü yapın.
5. 3 kuralı disable-candidate olarak işaretleyin.
6. Geçici istisnalar için EXP tarihi ekleyin.
7. Aylık “Policy Hygiene Review” rutini oluşturun.

---

Sonuç

FortiGate policy tablosunu temiz tutmak sadece estetik bir konu değildir. Bu doğrudan güvenlik, performans, denetim ve operasyonel hız meselesidir.

En iyi firewall kural seti, en çok kural içeren değil; en az gereksiz izinle, en net iş ihtiyacını karşılayan ve denetlenebilir olan kural setidir.

---