Azure Firewall Kurulum ve Yapılandırma Rehberi

Bulut altyapısı yönetiyorsanız, güvenlik duvarı yapılandırması her şeyin temelini oluşturur. Azure Firewall, Microsoft’un yönetilen, bulut tabanlı ağ güvenlik hizmeti olarak özellikle kurumsal ortamlarda ciddi bir yer edinmiş durumda. Geleneksel on-premises çözümlerden farklı olarak patch yönetimi, yüksek erişilebilirlik ve ölçeklenebilirlik konularında ekstra efor gerektirmiyor. Bu yazıda sıfırdan bir Azure Firewall kurulumu yapacak, temel yapılandırmaları geçeceğiz ve gerçek dünya senaryolarıyla konuyu pekiştireceğiz.

Azure Firewall Nedir ve Ne Zaman Kullanmalısınız?

Azure Firewall, Azure Virtual Network kaynaklarınızı korumak için kullanılan durum bilgisi olan (stateful) bir güvenlik duvarı hizmetidir. Network Security Group (NSG) ile karıştırılmamalı; NSG subnet veya NIC seviyesinde basit bir paket filtresi iken Azure Firewall çok daha gelişmiş özellikler sunar.

Azure Firewall’un öne çıkan özellikleri şunlardır:

• FQDN filtreleme: Alan adı bazlı trafik kontrolü
• Tehdit istihbaratı tabanlı filtreleme: Bilinen kötü amaçlı IP ve domain’leri otomatik engelleme
• TLS inspection: Şifreli trafiği denetleme (Premium SKU)
• IDPS (Intrusion Detection and Prevention System): Premium SKU ile gelir
• Merkezi log yönetimi: Azure Monitor ve Log Analytics entegrasyonu
• Yüksek erişilebilirlik: Yerleşik olarak gelir, ekstra konfig gerekmez

Şirketinizde birden fazla VNet varsa, hub-spoke mimarisinde merkezi güvenlik katmanı oluşturmak için Azure Firewall ideal bir tercih. NSG’ler her subnet’te ayrı ayrı yönetilmek zorundayken, Azure Firewall merkezi bir noktadan tüm trafiği kontrol etmenizi sağlar.

Ön Hazırlık: Gereksinimler ve Planlama

Kuruluma geçmeden önce birkaç şeyi netleştirmeliyiz. Azure Firewall için ayrı bir subnet oluşturmanız zorunlu ve bu subnet’in adı kesinlikle AzureFirewallSubnet olmalı, farklı bir isim kullanırsanız deployment başarısız olur. Ayrıca bu subnet en az /26 CIDR bloğuna sahip olmalı.

Önce Azure CLI kurulu ve login olmuş olduğunuzu varsayıyorum. Değilse şu şekilde başlayın:

# Azure CLI ile login
az login

# Hangi subscription üzerinde çalışacağımızı belirleyelim
az account list --output table

# Doğru subscription'ı seçelim
az account set --subscription "your-subscription-id"

# Çalışacağımız subscription'ı doğrulayalım
az account show --output table

Ortamımızı düzenli tutmak için değişkenler tanımlayalım. Bu alışkanlık özellikle uzun scriptlerde hayat kurtarır:

# Temel değişkenlerimizi tanımlayalım
RESOURCE_GROUP="rg-network-security"
LOCATION="westeurope"
VNET_NAME="vnet-hub"
FIREWALL_NAME="fw-hub-prod"
FIREWALL_POLICY_NAME="fwpolicy-hub-prod"
PUBLIC_IP_NAME="pip-fw-hub-prod"
FIREWALL_SUBNET="AzureFirewallSubnet"
MANAGEMENT_SUBNET="AzureFirewallManagementSubnet"
SPOKE_VNET="vnet-spoke-workloads"

echo "Degiskenler tanimlandi, kuruluma hazir."

Resource Group ve Network Altyapısını Oluşturma

Hub-spoke mimarisini simüle eden bir senaryo kuracağız. Hub VNet’te Azure Firewall olacak, spoke VNet’teki iş yükleri tüm trafiği firewall üzerinden geçirecek.

# Resource group oluştur
az group create 
  --name $RESOURCE_GROUP 
  --location $LOCATION 
  --tags Environment=Production Owner=NetworkTeam

# Hub VNet oluştur - yeterli adres alanı bırakın
az network vnet create 
  --resource-group $RESOURCE_GROUP 
  --name $VNET_NAME 
  --location $LOCATION 
  --address-prefix 10.0.0.0/16

# Azure Firewall için zorunlu subnet - isim kritik!
az network vnet subnet create 
  --resource-group $RESOURCE_GROUP 
  --vnet-name $VNET_NAME 
  --name $FIREWALL_SUBNET 
  --address-prefix 10.0.1.0/26

# Spoke VNet - iş yüklerimiz burada olacak
az network vnet create 
  --resource-group $RESOURCE_GROUP 
  --name $SPOKE_VNET 
  --location $LOCATION 
  --address-prefix 10.1.0.0/16

# Spoke'taki workload subnet'i
az network vnet subnet create 
  --resource-group $RESOURCE_GROUP 
  --vnet-name $SPOKE_VNET 
  --name "snet-workloads" 
  --address-prefix 10.1.1.0/24

# VNet peering - hub'dan spoke'a
az network vnet peering create 
  --resource-group $RESOURCE_GROUP 
  --name "hub-to-spoke" 
  --vnet-name $VNET_NAME 
  --remote-vnet $SPOKE_VNET 
  --allow-vnet-access true 
  --allow-forwarded-traffic true

# Spoke'tan hub'a peering
az network vnet peering create 
  --resource-group $RESOURCE_GROUP 
  --name "spoke-to-hub" 
  --vnet-name $SPOKE_VNET 
  --remote-vnet $VNET_NAME 
  --allow-vnet-access true 
  --allow-forwarded-traffic true 
  --use-remote-gateways false

Azure Firewall Deployment

Artık asıl kurulum kısmına geldik. Önce Public IP ve Firewall Policy oluşturacağız, ardından firewall’un kendisini deploy edeceğiz. Bu işlem genellikle 10-15 dakika sürüyor, sabırlı olun:

# Firewall için statik Public IP oluştur
az network public-ip create 
  --resource-group $RESOURCE_GROUP 
  --name $PUBLIC_IP_NAME 
  --location $LOCATION 
  --allocation-method Static 
  --sku Standard 
  --tier Regional

# Firewall Policy oluştur - kurallarımız buraya gidecek
az network firewall policy create 
  --resource-group $RESOURCE_GROUP 
  --name $FIREWALL_POLICY_NAME 
  --location $LOCATION 
  --sku Standard 
  --threat-intel-mode Alert

# Azure Firewall'u oluştur - bu adım zaman alır
az network firewall create 
  --resource-group $RESOURCE_GROUP 
  --name $FIREWALL_NAME 
  --location $LOCATION 
  --sku AZFW_VNet 
  --tier Standard 
  --firewall-policy $FIREWALL_POLICY_NAME 
  --vnet-name $VNET_NAME 
  --public-ip $PUBLIC_IP_NAME

# Firewall'un private IP adresini alalım - route table için lazım olacak
FW_PRIVATE_IP=$(az network firewall show 
  --resource-group $RESOURCE_GROUP 
  --name $FIREWALL_NAME 
  --query "ipConfigurations[0].privateIPAddress" 
  --output tsv)

echo "Firewall Private IP: $FW_PRIVATE_IP"

Firewall private IP adresini bir yere not edin. Route table konfigürasyonunda bu adrese ihtiyacınız olacak.

Route Table ile Trafiği Firewall’dan Geçirme

Azure Firewall var olması trafik otomatik olarak oradan geçmez. Spoke subnet’teki trafiği firewall’a yönlendirmek için User Defined Route (UDR) oluşturmanız gerekiyor. Bu adımı atlayan sysadminlerin “firewall çalışmıyor” diye saat kaybettiğine çok şahit oldum:

# Route Table oluştur
az network route-table create 
  --resource-group $RESOURCE_GROUP 
  --name "rt-spoke-to-hub-fw" 
  --location $LOCATION 
  --disable-bgp-route-propagation true

# Tüm internet trafiğini firewall'a yönlendir
az network route-table route create 
  --resource-group $RESOURCE_GROUP 
  --route-table-name "rt-spoke-to-hub-fw" 
  --name "route-to-internet-via-fw" 
  --address-prefix 0.0.0.0/0 
  --next-hop-type VirtualAppliance 
  --next-hop-ip-address $FW_PRIVATE_IP

# RFC 1918 aralıklarını da firewall'dan geçir (isteğe bağlı ama önerilir)
az network route-table route create 
  --resource-group $RESOURCE_GROUP 
  --route-table-name "rt-spoke-to-hub-fw" 
  --name "route-to-rfc1918-10" 
  --address-prefix 10.0.0.0/8 
  --next-hop-type VirtualAppliance 
  --next-hop-ip-address $FW_PRIVATE_IP

# Route table'ı spoke subnet'e bağla
az network vnet subnet update 
  --resource-group $RESOURCE_GROUP 
  --vnet-name $SPOKE_VNET 
  --name "snet-workloads" 
  --route-table "rt-spoke-to-hub-fw"

echo "Route table konfigurasyonu tamamlandi."

Firewall Kurallarını Yapılandırma

Azure Firewall’da üç tip kural koleksiyonu bulunur:

• Network Rules: IP ve port bazlı L3/L4 kuralları
• Application Rules: FQDN bazlı HTTP/HTTPS filtreleme
• NAT Rules: Inbound trafiği iç kaynaklara yönlendirme (DNAT)

Gerçek dünya senaryosu olarak şunu düşünelim: Development ortamındaki VM’lerinizin Windows Update’e ve belirli paket depolarına erişmesi gerekiyor, ama genel internet erişimi kısıtlı olacak. Ayrıca bir web sunucunuza dışarıdan port 443 üzerinden erişim sağlanacak.

# Önce rule collection group oluşturalım
az network firewall policy rule-collection-group create 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --name "rcg-production-rules" 
  --priority 200

# Windows Update için Application Rule Collection
az network firewall policy rule-collection-group collection add-filter-collection 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --rule-collection-group-name "rcg-production-rules" 
  --name "arc-windows-update" 
  --collection-priority 300 
  --action Allow 
  --rule-name "allow-windows-update" 
  --rule-type ApplicationRule 
  --source-addresses "10.1.1.0/24" 
  --protocols Http=80 Https=443 
  --fqdn-tags WindowsUpdate

# Linux paket yöneticileri için Application Rule
az network firewall policy rule-collection-group collection add-filter-collection 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --rule-collection-group-name "rcg-production-rules" 
  --name "arc-linux-repos" 
  --collection-priority 310 
  --action Allow 
  --rule-name "allow-ubuntu-repos" 
  --rule-type ApplicationRule 
  --source-addresses "10.1.1.0/24" 
  --protocols Http=80 Https=443 
  --target-fqdns "*.ubuntu.com" "security.ubuntu.com" "archive.ubuntu.com" 
    "*.debian.org" "deb.debian.org" "*.centos.org"

# DNS trafiği için Network Rule
az network firewall policy rule-collection-group collection add-filter-collection 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --rule-collection-group-name "rcg-production-rules" 
  --name "nrc-dns-allow" 
  --collection-priority 200 
  --action Allow 
  --rule-name "allow-dns-outbound" 
  --rule-type NetworkRule 
  --source-addresses "10.1.1.0/24" 
  --destination-addresses "8.8.8.8" "8.8.4.4" "168.63.129.16" 
  --destination-ports 53 
  --ip-protocols UDP TCP

# DNAT kuralı: Dışarıdan web sunucuya erişim
WEBSERVER_PRIVATE_IP="10.1.1.10"
FW_PUBLIC_IP=$(az network public-ip show 
  --resource-group $RESOURCE_GROUP 
  --name $PUBLIC_IP_NAME 
  --query ipAddress 
  --output tsv)

az network firewall policy rule-collection-group collection add-nat-collection 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --rule-collection-group-name "rcg-production-rules" 
  --name "narc-inbound-web" 
  --collection-priority 100 
  --action DNAT 
  --rule-name "dnat-https-to-webserver" 
  --rule-type NatRule 
  --source-addresses "*" 
  --destination-addresses $FW_PUBLIC_IP 
  --destination-ports 443 
  --translated-address $WEBSERVER_PRIVATE_IP 
  --translated-port 443 
  --ip-protocols TCP

echo "Firewall kurallari basariyla olusturuldu."

Loglama ve Monitoring Yapılandırması

Azure Firewall’u deploy etmek yetmez, ne yaptığını da görmek lazım. Log Analytics workspace’e bağlamak hem troubleshooting hem de güvenlik analizi için kritik.

# Log Analytics Workspace oluştur
LOG_WORKSPACE_NAME="law-network-security"

az monitor log-analytics workspace create 
  --resource-group $RESOURCE_GROUP 
  --workspace-name $LOG_WORKSPACE_NAME 
  --location $LOCATION 
  --sku PerGB2018 
  --retention-time 90

# Workspace ID'sini alalım
WORKSPACE_ID=$(az monitor log-analytics workspace show 
  --resource-group $RESOURCE_GROUP 
  --workspace-name $LOG_WORKSPACE_NAME 
  --query id 
  --output tsv)

# Firewall resource ID'sini alalım
FW_RESOURCE_ID=$(az network firewall show 
  --resource-group $RESOURCE_GROUP 
  --name $FIREWALL_NAME 
  --query id 
  --output tsv)

# Diagnostic settings'i etkinleştir
az monitor diagnostic-settings create 
  --resource $FW_RESOURCE_ID 
  --name "fw-diagnostics-to-law" 
  --workspace $WORKSPACE_ID 
  --logs '[
    {"category": "AzureFirewallApplicationRule", "enabled": true},
    {"category": "AzureFirewallNetworkRule", "enabled": true},
    {"category": "AzureFirewallDnsProxy", "enabled": true},
    {"category": "AzureFirewallThreatIntel", "enabled": true}
  ]' 
  --metrics '[
    {"category": "AllMetrics", "enabled": true}
  ]'

echo "Diagnostic logging aktif edildi."

Loglar aktive olduktan sonra Log Analytics’te şu KQL sorgularını kullanabilirsiniz. Engellenen trafiği bulmak için:

# Bu KQL sorgusunu Azure Portal'daki Log Analytics ekranında çalıştırın
# AzureDiagnostics tablosunda firewall logları tutulur

# Engellenen application rule trafiğini görmek için:
# AzureDiagnostics
# | where Category == "AzureFirewallApplicationRule"
# | where msg_s contains "Deny"
# | project TimeGenerated, msg_s, SourceIP = sourceIp_s
# | order by TimeGenerated desc
# | take 100

# Engellenen network trafiği için:
# AzureDiagnostics
# | where Category == "AzureFirewallNetworkRule"
# | where msg_s contains "Deny"
# | summarize Count = count() by DestinationIP = destinationIp_s, DestPort = destinationPort_s
# | order by Count desc

echo "KQL sorgu ornekleri yukarida yorum satirlarinda mevcut."
echo "Azure Portal > Log Analytics Workspace > Logs ekranindan calistirin."

Gerçek Dünya Senaryosu: Çok Katmanlı Uygulama Güvenliği

Bir e-ticaret şirketinde karşılaşacağınız tipik bir senaryo düşünelim. Frontend katmanı, backend API katmanı ve veritabanı katmanı ayrı subnet’lerde. Güvenlik duvarı kuralları şu mantıkta kurulacak:

• Internet sadece frontend’e 80/443 üzerinden ulaşabilecek
• Frontend, backend’e sadece 8080 üzerinden konuşabilecek
• Backend, database’e sadece 5432 (PostgreSQL) üzerinden erişecek
• Tüm katmanlar Windows Update ve yum/apt repolarına erişebilecek
• Hiçbir katmandan rastgele internet çıkışına izin verilmeyecek

Bu senaryoda önce network segmentasyonunu kurun, ardından en az ayrıcalık prensibiyle kurallarınızı ekleyin. Özellikle “deny all” kuralını en sona koyun ve her onaylı trafiği ayrı bir kuralla açın. Bu yaklaşım audit sırasında da çok işinize yarar.

Peki ya troubleshooting? Firewall bir şeyi engelliyor ama hangi kural bunu yapıyor bilmiyorsunuz. Diagnostic loglardan sonra şu yaklaşımı izleyin:

# Firewall policy'deki tüm kuralları listele
az network firewall policy rule-collection-group list 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --output table

# Belirli bir rule collection group'un detaylarını gör
az network firewall policy rule-collection-group show 
  --resource-group $RESOURCE_GROUP 
  --policy-name $FIREWALL_POLICY_NAME 
  --name "rcg-production-rules" 
  --output json | python3 -m json.tool

# Firewall'ın mevcut durumunu kontrol et
az network firewall show 
  --resource-group $RESOURCE_GROUP 
  --name $FIREWALL_NAME 
  --query "{Name:name, State:provisioningState, ThreatIntel:threatIntelMode}" 
  --output table

# Public IP adresini teyit et
az network public-ip show 
  --resource-group $RESOURCE_GROUP 
  --name $PUBLIC_IP_NAME 
  --query "{Name:name, IP:ipAddress, AllocationMethod:publicIPAllocationMethod}" 
  --output table

Maliyet Optimizasyonu ve Önemli Notlar

Azure Firewall masraflı bir hizmet. Standard SKU yaklaşık saatte 1.25 USD plus işlenen veri başına ücret alıyor. Bunu optimize etmek için birkaç pratik öneri:

• Dev/test ortamlarında: Geceleri ve hafta sonları firewall’u durdurun. az network firewall update --vnet-name null gibi bir yaklaşımla allocation’ı kaldırabilirsiniz ama bu production’da yapılmaz
• Firewall Policy kullanın: Classic kurallar yerine Firewall Policy kullanmak hem merkezi yönetim hem de maliyet açısından avantajlı
• Log retention: 90 gün Log Analytics maliyeti artırır, gereksinim yoksa 30 güne indirin
• Availability Zones: Premium SKU ile zone redundancy aktif etmek güvenilirliği artırır ama maliyeti de

Güvenlik açısından mutlaka yapmanız gereken birkaç şey var:

• Threat Intelligence modunu Alert değil Deny yapın; başlangıçta Alert’te bırakıp logları izlemek, ardından Deny’a geçmek iyi bir pratik
• Firewall’a giden management trafiği için ayrı bir yönetim subnet’i oluşturun
• Public IP’yi sadece DNAT için kullandığınız kurallarla sınırlandırın
• Tüm değişiklikleri IaC (Terraform veya Bicep) ile yapın, elle portal değişikliklerini minimize edin

Sonuç

Azure Firewall, doğru yapılandırıldığında kurumsal ağ güvenliğinin sağlam bir parçası haline geliyor. Bugün yaptıklarımızı özetleyelim: Hub-spoke mimarisi üzerine kurulu bir VNet topolojisi oluşturduk, Azure Firewall’u deploy ettik ve Firewall Policy üzerinden application, network ve NAT kurallarını tanımladık. Route table ile spoke trafiğini merkezi firewall’dan geçirecek şekilde yönlendirdik ve Log Analytics entegrasyonuyla görünürlüğü sağladık.

En çok dikkat etmeniz gereken nokta kural öncelikleri. Azure Firewall kuralları öncelik sırasına göre işler ve ilk eşleşen kural uygulanır. Deny kurallarınızı doğru önceliğe koymazsanız beklenmedik sürprizlerle karşılaşırsınız. Her environment için ayrı rule collection group kullanmak ve bunları öncelik numaralarıyla mantıklı bir şekilde düzenlemek uzun vadede yönetimi kolaylaştırır.

Bir sonraki adım olarak Azure Firewall Premium’un IDPS ve TLS inspection özelliklerini incelemenizi, ayrıca Azure Firewall Manager ile merkezi politika yönetimini araştırmanızı tavsiye ederim. Birden fazla firewall instance’ınız varsa Manager olmadan yönetmek gerçekten zorlaşıyor.