☁️ Cloud’a firewall koymak, tek başına Cloud Security değildir.

İlgili yazılar

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

18 saat önce

FortiGate Troubleshooting: Trafik Gerçekten Nerede Kesiliyor?

1 hafta önce

FortiGate NAT Troubleshooting: Policy Doğru Ama Trafik Neden Çıkmıyor?

2 hafta önce

AWS veya Azure ortamına FortiGate-VM deploy etmek işin kolay kısmıdır.

Asıl mesele:

🧭 Routing
🧱 Segmentation
🔐 Least Privilege
🔥 High Availability
📊 Visibility
🤖 Automation

başlıklarını tek bir mimari içerisinde doğru çalıştırabilmektir.

Çünkü cloud ortamında firewall’ın var olması:

Traffic is inspected

anlamına gelmez.

Trafiğin gerçekten firewall üzerinden geçmesini sağlayacak traffic steering tasarımına da ihtiyacınız vardır.

---

🧭 1️⃣ Routing her şeyin başlangıcı

FortiGate-VM stateful bir firewall’dır.

Yani bir session için:

Forward Path
↓
FortiGate
↓
Destination

ve

Return Path
↓
Aynı stateful inspection yolu
↓
Source

mantığının korunması kritik olabilir.

Yanlış route table, UDR veya NAT tasarımı şu sorunları oluşturabilir:

⚠️ Asymmetric routing
⚠️ Session mismatch
⚠️ Session drop
⚠️ Intermittent bağlantı problemi
⚠️ TCP retransmission
⚠️ “Bir yönde çalışıyor, diğer yönde çalışmıyor” vakaları

Bu yüzden:

Route exists
≠
Traffic path is correct

---

☁️ AWS tarafında örnek mimari

AWS üzerinde merkezi inspection tasarımında sık görülen yapılardan biri:

Spoke VPC A
      │
      ▼
Transit Gateway
      │
      ▼
Security / Inspection VPC
      │
      ▼
Gateway Load Balancer
      │
      ▼
FortiGate-VM
      │
      ▼
Transit Gateway
      │
      ▼
Spoke VPC B

Bu yapı ile:

🧱 VPC-to-VPC East-West trafik
🌐 Internet North-South trafik
🏢 On-Prem ↔ AWS trafik

inspection’a yönlendirilebilir.

Ancak önemli nokta:

VPC’ler arası trafik sırf FortiGate deploy edildi diye otomatik olarak FortiGate’ten geçmez.

Route table ve TGW politikalarının inspection mimarisine göre tasarlanması gerekir.

---

⚠️ AWS’de Appliance Mode neden önemli?

Stateful firewall kullanıyorsanız request ve response trafiğinin farklı Availability Zone veya farklı firewall instance üzerinden dönmesi problem yaratabilir.

Örnek:

Request
→ FortiGate-A
→ Server

Response
→ FortiGate-B
→ Client

FortiGate-B üzerinde ilgili session state yoksa:

Session not found
→ DROP

riski ortaya çıkar.

AWS Transit Gateway kullanan centralized inspection tasarımlarında Appliance Mode, bidirectional flow’un aynı inspection path/AZ üzerinden kalmasını sağlamak açısından kritik bir tasarım bileşenidir.

---

🔷 Azure tarafında temel mantık

Azure’da FortiGate-VM çoğunlukla Network Virtual Appliance — NVA mantığında konumlandırılır.

Protected subnet’lerin route table’larında örneğin:

0.0.0.0/0
↓
Next Hop: Virtual Appliance
↓
FortiGate Internal IP

şeklinde UDR — User Defined Route kullanılabilir.

Basitleştirilmiş:

Workload Subnet
      │
      ▼
Azure UDR
      │
      ▼
FortiGate-VM
      │
      ▼
Internet / Other VNet / On-Prem

Burada da yanlış UDR tasarımı:

Traffic bypass
Asymmetric routing
Unexpected next-hop
Black-hole

oluşturabilir.

---

🧱 2️⃣ East-West segmentasyon

Cloud güvenliğinde sadece:

Internet → Application

trafiğini korumak yeterli değildir.

Bir workload compromise olduğunda saldırganın sonraki hedefi çoğunlukla başka bir workload’dur.

Yani:

App → DB
Web → Application
VPC → VPC
VNet → VNet
Dev → Prod
Workload → Shared Services

trafiği de önemlidir.

FortiGate-VM doğru routing tasarımıyla East-West inspection için kullanılabilir.

Örneğin:

APP-ZONE
→ HTTPS
→ API-ZONE

ALLOW

ancak:

APP-ZONE
→ ANY
→ DB-ZONE

DENY

Temel prensip değişmez:

Doğru kaynak → doğru hedef → sadece gerekli servis.

---

🔐 3️⃣ Least Privilege

Cloud olması firewall policy mantığını değiştirmez.

Policy şu kadar geniş olmamalı:

Source: ANY
Destination: ANY
Service: ANY
Action: ACCEPT

Mümkün olduğunca:

Source
+
Destination
+
Application
+
Service
+
Environment
+
Business Requirement

bazlı erişim uygulanmalıdır.

Örnek:

DEV
→ PROD DB
→ DENY

PROD APP
→ PROD DB
→ TCP/5432
→ ALLOW

---

🔥 4️⃣ High Availability yalnız iki firewall deploy etmek değildir

Cloud HA tasarımında şu sorular da cevaplanmalıdır:

Node fail olursa trafik nereye gider?
Route nasıl değişir?
Public IP nasıl taşınır?
Load balancer health probe neyi kontrol eder?
Session'lara ne olur?
AZ failure senaryosu test edildi mi?

AWS tarafında FortiGate-VM için Active-Passive unicast HA ve AWS SDN entegrasyonlu modeller bulunur.

Azure tarafında ise:

Active / Passive

ve mimariye bağlı olarak:

Active / Active
+
Azure Load Balancer

yaklaşımları kullanılabilir.

Ama:

2 firewall deployed
≠
HA validated

Failover mutlaka test edilmelidir.

---

📊 5️⃣ Visibility olmadan security eksik kalır

Firewall trafiği kontrol ediyor olabilir.

Ama şu soruların cevabı yoksa operasyon eksiktir:

Kim nereye bağlanıyor?
Hangi policy hit alıyor?
Hangi trafik deny oluyor?
IPS ne tespit etti?
Hangi application görülüyor?
Hangi threat signature tetiklendi?
Hangi NAT kullanıldı?
Session hangi path üzerinden geçti?

Bu nedenle:

📊 Traffic Logs
🚨 Threat Logs
🛡️ IPS / Application Control
🌐 Cloud flow logs
📈 FortiAnalyzer / merkezi log yönetimi
🔍 SIEM entegrasyonu

birlikte değerlendirilmelidir.

---

🤖 6️⃣ Automation artık opsiyon değil

Cloud ortamının önemli avantajlarından biri altyapının kod ile yönetilebilmesidir.

Örneğin:

Terraform
Cloud templates
SDN Connectors
API
CI/CD

kullanılarak deployment ve policy süreçleri daha kontrollü hale getirilebilir.

Özellikle dynamic cloud ortamlarında sadece statik IP object kullanmak operasyonel yük yaratabilir.

FortiGate’in AWS/Azure SDN connector özellikleriyle cloud kaynaklarının dinamik olarak security policy’lere dahil edilmesi de değerlendirilebilir.

---

🧩 7️⃣ Cloud-native güvenlik kontrollerini kaldırmayın

FortiGate kullanıyorum diye:

AWS Security Groups
Azure NSG
Cloud IAM
Native logging
Cloud security controls

devre dışı bırakılmamalıdır.

Daha doğru yaklaşım:

Cloud Native Controls
+
FortiGate NGFW
+
Identity
+
Segmentation
+
Logging
+
Automation

şeklinde defense-in-depth modelidir.

FortiGate cloud-native güvenliği yok etmez.

Tamamlar.

---

🔄 Hybrid Cloud senaryosu

FortiGate-VM özellikle hybrid yapılarda önemli bir kontrol noktası haline gelebilir.

Örneğin:

On-Prem
   │
IPsec / Direct Connect / ExpressRoute
   │
   ▼
Cloud Transit
   │
   ▼
FortiGate-VM
   │
 ┌─┴────────────┐
 ▼              ▼
APP            DB

Burada FortiGate:

🔐 On-Prem ↔ Cloud inspection
🧱 East-West segmentation
🌐 Internet ingress/egress kontrolü
🚨 IPS / Application Control
📊 Logging

için kullanılabilir.

Ancak yine kritik nokta:

Trafiğin hangi path’i izleyeceğini firewall değil, mimari belirler.

---

🎯 Cloud Network Security’de kontrol listem

1. CIDR / IP Plan
↓
2. Routing
↓
3. Traffic Steering
↓
4. Symmetric Path
↓
5. Segmentation
↓
6. Firewall Policy
↓
7. NAT
↓
8. HA
↓
9. Logging
↓
10. Automation
↓
11. Failover Test

Özellikle şu dört soruya cevap veremiyorsam tasarımı tamamlanmış kabul etmem:

Traffic nereden geliyor?

Hangi FortiGate üzerinden geçiyor?

Return traffic hangi path'i kullanıyor?

Firewall fail olursa trafik ne olacak?

🔥 Kritik mesaj:

FortiGate deployed
≠
Cloud secured

Daha doğru denklem:

Routing
+
Segmentation
+
Least Privilege
+
HA
+
Visibility
+
Automation
+
Cloud-Native Controls
=
Daha sağlam Cloud Network Security

Cloud tarafında da network security’nin temel prensibi değişmiyor:

Doğru trafik, doğru kaynaktan, doğru hedefe ve yalnızca gerekli servis üzerinden erişebilmeli. 🔐

💬 Sizce Cloud Network Security tarafında en kritik konu hangisi?

🧭 Routing
🧱 Segmentation
🔥 HA
📊 Visibility