FortiGate Security Profiles Tasarımı: Departman Bazlı Web Filter, IPS, Application Control ve SSL Inspection Rehberi

01 / AMAÇ

Amaç

FortiGate üzerinde Security Profile tasarlarken hedef yalnızca mümkün olan en fazla kategoriyi Block etmek değildir. İyi bir tasarım; güvenlik seviyesini yükseltirken iş süreçlerini bozmaz, hangi profile neden ihtiyaç duyulduğunu açıkça gösterir ve aylar sonra yapılacak troubleshooting sırasında anlaşılabilir kalır.

Bu rehberde aşağıdaki bileşenler tek bir mimari altında ele alınır:

Kullanıcı / Rol
      |
      v
Firewall Policy
      |
      v
Security Profile Group
      |
      +-- Antivirus
      +-- Web Filter
      +-- Application Control
      +-- IPS
      +-- SSL Inspection
      +-- File Filter
      +-- DNS Filter

Örnek tasarım Proxy-Based Inspection mantığı üzerinden hazırlanmıştır. FortiOS sürümüne ve kullanılan lisanslara göre menü, kategori ve bazı CLI seçenekleri değişebilir; üretim uygulaması öncesinde ilgili sürümün davranışı doğrulanmalıdır.

02 / 1. İLK KARAR: HER KULLANICIYA AYNI PROFIL MI?

1. İlk Karar: Her Kullanıcıya Aynı Profil mi?

Tek bir Security Profile setini tüm kullanıcılara uygulamak yönetimi kolaylaştırabilir, ancak iş ihtiyacı farklı olan gruplarda gereksiz engellemelere veya gereğinden fazla erişime neden olabilir.

Örneğin:

• standart ofis kullanıcısının executable indirme ihtiyacı sınırlı olabilir,
• teknik ekiplerin üretici aracı veya installer indirmesi gerekebilir,
• IT ekibinin remote access araçlarına ihtiyacı olabilir,
• uzak erişim/VPN trafiğinde SSL inspection modeli farklı tasarlanabilir.

Bu nedenle karar modeli şu şekilde kurulabilir:

Risk
  +
İş ihtiyacı
  +
Kullanıcı rolü
  +
Trafik tipi
  +
Gözlemlenebilirlik
  =
Security Profile kararı

Buradaki kritik nokta şudur: farklı profil oluşturmak için gerçek bir davranış farkı olmalıdır. Aynı güvenlik baseline'ının kopyalarını üretmek yerine ortak kontroller korunmalı, yalnızca iş ihtiyacının değiştiği alanlar ayrıştırılmalıdır.

03 / 2. ÖRNEK ROL SINIFLARI

2. Örnek Rol Sınıfları

Gerçek departman isimleri yerine aşağıdaki nötr roller kullanılabilir:

Bu sınıflandırma firewall policy isimlerine birebir yansımak zorunda değildir. Ama profil tasarımını kimin hangi kontrole gerçekten ihtiyaç duyduğunu düşünmeye zorlar.

04 / 3. İSIMLENDIRME STANDARDI

3. İsimlendirme Standardı

Profil isimlerinin yalnızca teknik olarak benzersiz olması yeterli değildir; ilk bakışta hangi role ve hangi profile ait olduğu anlaşılmalıdır.

Örnek:

FW-<ROLE>-AV
FW-<ROLE>-WEB
FW-<ROLE>-APP
FW-<ROLE>-IPS
FW-<ROLE>-SSL
FW-<ROLE>-FILE
FW-<ROLE>-DNS
FW-<ROLE>-GROUP

Örneğin:

FW-STANDARD-WEB
FW-TECHNICAL-FILE
FW-IT-APP

Bu yapı policy üzerinde görülen profile bakıldığında rolü ve fonksiyonu hızlıca ayırt etmeyi sağlar.

05 / 4. ANTIVIRUS: ORTAK BASELINE ILE BAŞLAMAK

4. Antivirus: Ortak Baseline ile Başlamak

Antivirus tarafında her departman için tamamen farklı davranış oluşturmak çoğu zaman gerekli değildir. Önce ortak bir malware protection baseline'ı tanımlanabilir.

Örnek tasarımda temel protokoller için malware tespit edildiğinde Block yaklaşımı kullanıldı:

HTTP   -> Block
FTP    -> Block
SMTP   -> Block
POP3   -> Block
IMAP   -> Block

Ayrıca:

• Machine Learning tabanlı tespit açık tutuldu.
• Grayware tespiti açık tutuldu.
• E-posta üzerinden taşınan executable dosyaların riskli içerik olarak değerlendirilmesi hedeflendi.
• Profil Proxy-Based çalışma modeline göre ele alındı.

06 / 5. WEB FILTER: BLOCK LISTESI DEĞIL, İŞ POLITIKASI

5. Web Filter: Block Listesi Değil, İş Politikası

Web Filter tasarımında iki katman kullanmak faydalıdır:

1. 01

   Tüm kullanıcılar için ortak yüksek risk kategorileri

2. 02

   İş ihtiyacına göre değişen kullanım kategorileri

5.1. Ortak Block kategorileri

Örnek tasarımda aşağıdaki kategoriler tüm kullanıcı gruplarında kısıtlandı:

Games             -> Block
Peer-to-Peer      -> Block
Domain Parking    -> Block
Cryptocurrency    -> Block

Ayrıca malicious, phishing ve benzeri açıkça riskli kategoriler doğal olarak güvenlik baseline'ının parçası olarak engellenir.

5.2. Rol bazlı değişen kategoriler

Aşağıdaki kategorilerde tek bir global karar yerine rol bazlı politika uygulandı:

• Remote Access
• AI servisleri
• Streaming
• Social Media
• Shopping
• Travel
• Job Search
• File Sharing
• Software Download
• Online Meeting

Önemli örneklerden biri Remote Access kategorisidir:

IT Administrator  -> Monitor
Diğer roller      -> Block

IT ekibinin uzaktan yönetim araçlarına meşru ihtiyacı olabilir. Aynı kategoriyi standart kullanıcılar için açmak ise gereksiz bir risk yüzeyi yaratabilir.

İzin verilen kategorilerin doğrudan Allow yerine mümkün olan yerlerde Monitor + Log yaklaşımıyla çalıştırılması, kullanım görünürlüğünü korur.

07 / 6. APPLICATION CONTROL: ERIŞIMDEN ÇOK GÖRÜNÜRLÜK

6. Application Control: Erişimden Çok Görünürlük

Application Control yalnızca uygulama engellemek için kullanılmamalıdır. Özellikle başlangıç aşamasında hangi uygulamaların gerçekten kullanıldığını görmek için güçlü bir gözlem katmanıdır.

Örnek tasarımın ortak yaklaşımı:

P2P                 -> Block
Proxy / Anonymizer  -> Block
Games               -> Block

Rol bazlı farklılaştırılan örnekler:

Remote Access
  IT Administrator  -> Monitor
  Diğer roller      -> Block

Social Media
  Seçilmiş iş rolleri -> Monitor
  Diğer roller        -> ihtiyaca göre daha kısıtlı

Video / Audio
  İhtiyaç olan roller -> Monitor
  Diğer roller        -> ihtiyaca göre kısıtlı

Burada Monitor kullanımı özellikle değerlidir: trafik çalışmaya devam ederken loglarda gerçek kullanım görülebilir. Sonraki aşamada hangi uygulamanın gerçekten gerekli olduğu daha sağlıklı belirlenir.

08 / 7. IPS: DEPARTMANA GÖRE DEĞIL, TEHDIDE GÖRE BASELINE

7. IPS: Departmana Göre Değil, Tehdide Göre Baseline

IPS tarafında departmanlar arasında çok farklı sensörler oluşturmak yerine ortak güçlü bir baseline kullanıldı.

Örnek aksiyon modeli:

Buna ek olarak:

Malicious URL  -> Block
Botnet C&C     -> Block

Packet logging sürekli açık tutulmadı; gerektiğinde troubleshooting için kontrollü olarak etkinleştirilmesi tercih edildi.

09 / 8. SSL INSPECTION: DIĞER PROFILLERIN GÖRÜŞ ALANI

8. SSL Inspection: Diğer Profillerin Görüş Alanı

Modern kullanıcı trafiğinin büyük kısmı TLS ile şifreli olduğu için Web Filter, Antivirus ve File Filter tasarımının etkinliği SSL inspection yaklaşımından bağımsız düşünülemez.

Basitleştirilmiş akış:

Client
   |
   | TLS
   v
FortiGate
   |
   | Inspection
   v
Internet Service

Örnek tasarımda kullanıcı gruplarının çoğunda Full Deep Inspection, uzak erişim/VPN gibi farklı güven ilişkisine sahip trafikte ise daha sınırlı Certificate Inspection yaklaşımı kullanıldı.

Deep Inspection tarafında değerlendirilen başlıklar:

• endpoint'lerde güvenilir inspection CA dağıtımı,
• TLS 1.2 ve üzeri protokol beklentisi,
• invalid / expired / revoked / untrusted certificate davranışı,
• SNI uyumluluğu,
• QUIC / HTTP3 trafiğinin inspection stratejisi,
• gerektiğinde kontrollü exemption kategorileri.

Örnek exemption başlıkları:

Finance / Banking
Health and Wellness
Personal Privacy

Bu istisnalar her kurum için aynı olmak zorunda değildir. Teknik gereksinim, gizlilik politikası, mevzuat ve uygulama uyumluluğu birlikte değerlendirilmelidir.

QUIC neden ayrıca düşünülmeli?

HTTP/3 trafiği QUIC üzerinden ve tipik olarak UDP/443 kullanarak çalışabilir:

Browser
   |
   v
HTTP/3 / QUIC
   |
   v
UDP/443

SSL inspection tasarlanırken yalnız klasik TCP/443 akışına bakmak yeterli değildir. QUIC'in mevcut FortiOS sürümünde nasıl inspect edildiği veya policy tarafından nasıl ele alındığı doğrulanmalıdır.

10 / 9. FILE FILTER: DOSYA UZANTISINDAN FAZLASI

9. File Filter: Dosya Uzantısından Fazlası

File Filter tasarımında en önemli nokta bütün dosya türlerini körü körüne engellememektir. Dosyanın riski kadar kullanıcının iş ihtiyacı da değerlendirilmelidir.

Örnek sınıflandırma:

9.1. Executable ve installer türleri

exe
msi
dll
.net

9.2. Script ve yardım dosyaları

bat
hta
chm

9.3. Arşivler

zip
rar
7z

9.4. Dokümanlar

pdf
doc / docx
xls / xlsx
ppt / pptx

Örnek rol bazlı politika:

Bu çalışmada teknik ekiplerden bazıları için installer dosyaları Monitor, ancak script temelli daha yüksek riskli türler Block olarak bırakıldı. IT grubunda executable ve installer trafiği daha geniş şekilde Monitor edildi.

Office ve PDF gibi iş dosyaları topluca engellenmedi; bunların analizi Antivirus ve SSL Deep Inspection katmanlarıyla birlikte değerlendirildi. Bu yaklaşım bu dosyaların risksiz olduğu anlamına gelmez; yalnızca iş ihtiyacı nedeniyle blanket block uygulanmadığı anlamına gelir.

Şifreli arşivler

Password-protected arşivler içerik analizi açısından özel bir durumdur. Örnek tasarımda:

Standard User     -> Block
Technical User    -> Monitor
IT Administrator -> Monitor

kullanıldı.

Ayrıca archive içeriğinin taranabilmesi için archive scanning açık tutuldu ve password-protected archive kuralı genel archive Monitor kuralından önce değerlendirilecek şekilde tasarlandı.

Mantık:

Password-protected archive?
        |
     Yes|------------------> özel aksiyon
        |
      No
        |
        v
General archive rule
        |
        v
Monitor / Log

11 / 10. DNS FILTER: DNS AKIŞINI GÖRMEDEN PROFIL TASARLAMAYIN

10. DNS Filter: DNS Akışını Görmeden Profil Tasarlamayın

DNS Filter tasarımında yalnız kategori listesini hazırlamak yeterli değildir. Önce istemcinin DNS sorgusunun gerçekten hangi cihazdan geçtiği anlaşılmalıdır.

Örneğin kurumsal istemciler doğrudan public DNS'e değil internal DNS resolver'a gidiyorsa akış şu şekilde olabilir:

Client
   |
   v
Internal DNS Resolver
   |
   v
FortiGate
   |
   v
Upstream DNS

Bu durumda DNS Filter'ın kullanıcı policy'sine eklenmiş olması tek başına beklenen görünürlüğü sağlamayabilir. Policy konumu ve DNS sorgusunun gerçek trafik yolu doğrulanmalıdır.

Örnek ortak risk kategorileri:

Malicious / Phishing
Botnet
P2P
Proxy Avoidance
Cryptocurrency
Potentially Unwanted Programs

İş kullanım kategorileri ise role göre farklılaştırılabilir.

12 / 11. SECURITY PROFILE GROUP: POLICY'YI OKUNABILIR TUTMAK

11. Security Profile Group: Policy'yi Okunabilir Tutmak

Tek tek profile isimlerini firewall policy üzerinde yönetmek yerine, aynı role ait kontrolleri bir Profile Group altında toplamak yapılandırmayı sadeleştirir.

FW-STANDARD-GROUP
      |
      +-- FW-STANDARD-AV
      +-- FW-STANDARD-WEB
      +-- FW-STANDARD-APP
      +-- FW-STANDARD-IPS
      +-- FW-STANDARD-SSL
      +-- FW-STANDARD-FILE

Avantajları:

• policy standardizasyonu,
• eksik profil bağlama riskinin azalması,
• daha kolay audit,
• daha hızlı troubleshooting,
• değişikliklerin rol bazında takip edilebilmesi.

File Filter gibi bazı profil tiplerinin Profile Group içinde kullanılabilirliği FortiOS sürümüne göre doğrulanmalıdır.

13 / 12. COMMENTS STANDARDI: PROFILIN NEDEN VAR OLDUĞUNU YAZIN

12. Comments Standardı: Profilin Neden Var Olduğunu Yazın

Bir profile yalnız ismine bakarak ne yaptığını anlamak her zaman mümkün değildir. Bu nedenle comments alanını gerçek bir operasyon standardı haline getirmek faydalıdır.

İyi bir comment üç soruya cevap vermelidir:

AMAÇ   -> Bu profil neden var?
KAPSAM -> Hangi kullanıcı/trafik için?
AKSİYON -> Temel olarak neyi block/monitor ediyor?

Örnek Türkçe comment'ler:

Antivirus

Kurumsal internet ve e-posta trafiğinde zararlı içerik ile bilinen malware örneklerini tespit ederek engellemek amacıyla kullanılan Antivirus profilidir.

Web Filter

Kullanıcı grubunun internet erişiminde zararlı ve kurum politikası dışındaki web kategorilerini engeller; izin verilen kategorileri görünürlük amacıyla loglar.

Application Control

Riskli veya kurum politikası dışında kalan uygulamaları engeller; izin verilen uygulamaları kullanım görünürlüğü için izler ve loglar.

IPS

Bilinen exploit ve ağ tabanlı saldırı girişimlerini tespit ederek Medium, High ve Critical seviyelerde engellemek amacıyla kullanılan IPS profilidir.

SSL Inspection

HTTPS trafiğinde güvenlik profillerinin içerik analizi yapabilmesi için TLS trafiğini kurum politikasına uygun olarak inspect eden SSL profilidir.

File Filter

Yüksek riskli executable, script ve şifreli arşiv dosyalarını kullanıcı rolüne göre engellemek veya loglamak amacıyla kullanılan File Filter profilidir.

Bu açıklamalar mümkün olduğunca kısa tutulmalı ancak profilin amacını bir sonraki mühendise anlatacak kadar anlamlı olmalıdır.

14 / 13. DEVREYE ALMA: MONITOR -> VALIDATE -> BLOCK

13. Devreye Alma: Monitor -> Validate -> Block

Yeni bir profile setini doğrudan üretimde en sert aksiyonlarla devreye almak yerine kontrollü bir geçiş daha güvenlidir.

Monitor
   |
   v
Logları incele
   |
   v
Gerçek iş kullanımını doğrula
   |
   v
False Positive kontrol et
   |
   v
Gerekli exception'ları belirle
   |
   v
Block

Bu yaklaşım özellikle:

• Application Control,
• Web Filter'ın iş kategorileri,
• File Filter,
• IPS signature setleri

için değerlidir.

15 / 14. TROUBLESHOOTING SIRASI

14. Troubleshooting Sırası

Security Profile uygulanmış olmasına rağmen beklenen sonuç alınmıyorsa yalnız profile bakmak yeterli değildir.

Önerilen kontrol sırası:

Doğru firewall policy eşleşiyor mu?
        |
        v
Policy Proxy-Based mı?
        |
        v
Beklenen Security Profile / Group bağlı mı?
        |
        v
SSL Inspection gerçekten trafiği görebiliyor mu?
        |
        v
Exemption var mı?
        |
        v
Web / App / AV / IPS / File logları ne gösteriyor?
        |
        v
FortiGuard kategori veya signature sonucu nedir?
        |
        v
Client davranışı ile firewall logu aynı şeyi mi söylüyor?

Özellikle Proxy-Based Web Filter davranışında sorun varsa, yalnız kategori politikasını değiştirmeden önce WAD ve regex/URL filter katmanı ayrıca kontrol edilmelidir. Bu konunun detaylı bir örneği için [FortiGate Proxy-Based Web Filter: Belirli Domainler Neden Bloklanmıyor?](../troubleshooting/fortigate-proxy-web-filter-domain-match.html) troubleshooting notuna bakılabilir.

16 / 15. YAYIN ÖNCESI / DEĞIŞIKLIK ÖNCESI KONTROL LISTESI

15. Yayın Öncesi / Değişiklik Öncesi Kontrol Listesi

[ ] Kullanıcı ve rol grupları gerçek iş ihtiyacına göre sınıflandırıldı
[ ] Firewall policy'lerin Proxy-Based olduğu doğrulandı
[ ] Antivirus ortak baseline oluşturuldu
[ ] Web Filter ortak Block kategorileri tanımlandı
[ ] İş kategorileri rol bazında Monitor / Block olarak ayrıştırıldı
[ ] Application Control üzerinde P2P / Anonymizer / Games politikası doğrulandı
[ ] Remote Access yalnız ihtiyaç olan rollere açıldı
[ ] IPS Critical / High / Medium davranışı test edildi
[ ] Deep Inspection kullanılan endpoint'lerde CA güveni doğrulandı
[ ] Certificate / Deep Inspection ayrımı kontrol edildi
[ ] QUIC / HTTP3 davranışı test edildi
[ ] File Filter executable ve script politikası doğrulandı
[ ] Password-protected archive kural sırası kontrol edildi
[ ] DNS sorgularının gerçek trafik yolu doğrulandı
[ ] Profile Group eşleşmeleri kontrol edildi
[ ] Her profile anlamlı comments eklendi
[ ] Monitor aşamasındaki loglar incelendi
[ ] False Positive ve iş kritik exception'lar doğrulandı
[ ] Değişiklik rollback planı hazırlandı

17 / 16. TASARIMIN TEMEL İLKELERI

16. Tasarımın Temel İlkeleri

Bu çalışmadan çıkan en önemli ilkeler şunlardır:

1. 01

   Her departmana farklı profil yazmak amaç değildir. Farklılık gerçek iş ihtiyacından gelmelidir.

2. 02

   Ortak baseline güçlü tutulmalıdır. Antivirus ve IPS gibi kontrollerde gereksiz varyasyon yönetimi zorlaştırır.

3. 03

   Monitor bir zayıflık değildir. Doğru kullanıldığında görünürlük ve güvenli geçiş sağlar.

4. 04

   Deep Inspection bağımsız bir ayar değildir. Web, AV ve File Filter görünürlüğünü doğrudan etkiler.

5. 05

   File Filter yalnız uzantı listesi değildir. Kullanıcı rolü ve iş akışıyla birlikte tasarlanmalıdır.

6. 06

   Comments operasyonel dokümantasyonun parçasıdır. Profile neden ihtiyaç duyulduğunu cihazın üzerinde bırakır.

7. 07

   Policy ve profile birlikte troubleshoot edilmelidir. Doğru profil yanlış policy üzerinde hiçbir değer üretmez.

18 / SONUÇ

Sonuç

FortiGate Security Profile mimarisinde iyi tasarım, mümkün olan her şeyi engellemekten çok doğru kullanıcıya doğru kontrolü, ölçülebilir ve yönetilebilir biçimde uygulamak anlamına gelir.

En sürdürülebilir yaklaşım:

Common Security Baseline
          |
          v
Role-Based Differences
          |
          v
Monitor & Log
          |
          v
Validate
          |
          v
Controlled Block
          |
          v
Periodic Review

Bu yapı yalnız güvenliği artırmaz; policy review, audit, troubleshooting ve sonraki değişikliklerin daha anlaşılır yapılmasını da sağlar.

FortiGate üzerinde büyük bir profil değişikliği yapılmadan önce kullanılan FortiOS sürümünün davranışı ve bilinen sorunları ayrıca kontrol edilmelidir. Sürüm yükseltme kararının nasıl ele alınabileceği için [FortiGate Firmware Upgrade Kararı: Yeni Sürüm Çıktı Diye Upgrade Yapılır mı?](../articles/yeni-firmware-cikti-diye-upgrade-yapilir-mi.html) yazısına bakılabilir.

---

How-To ID: HT-004 Platform: FortiGate / FortiOS Durum: Security Profile tasarım ve uygulama rehberi