Azure Firewall makale serimin bu bölümünde, önceki yazıda Azure Portal üzerinden kurduğum ortamı PowerShell komutlarıyla hazırlamıştım. 2020 yılında gerçekleştirdiğim laboratuvar çalışmasının ekran görüntülerini ve adımlarını bu makalede koruyorum. Aradan geçen sürede hem Azure PowerShell modülleri hem de Azure Firewall yönetim yaklaşımı değişti. Bu nedenle eski örnekleri tarihsel laboratuvar olarak okuyup, güncel ortamlarda nelere dikkat etmemiz gerektiğini de paylaşacağım.
Ekim 2026 güncellemesi: Azure Firewall için yeni dağıtımlarda Firewall Policy ile merkezi kural yönetimini tercih etmek daha doğru. Bu yazının eski bölümünde kullandığım New-AzFirewallApplicationRuleCollection ve New-AzFirewallNetworkRuleCollection komutları klasik kural modelini gösteriyor. Hâlâ bazı mevcut ortamlarda karşılaşılabilir; ancak yeni mimarinin varsayılan tercihi olarak düşünülmemeli. Aşağıdaki komutlar hazır bir üretim scripti değildir; abonelik, SKU, bölge, sanal ağ, erişim ve güvenlik gereksinimlerine göre ayrıca doğrulanmalıdır.
Azure Firewall laboratuvarının mimarisi
Senaryomuzda Test-FW-VN isimli bir sanal ağ ve üç subnet bulunuyor. AzureFirewallSubnet firewall servisine, Workload-SN internet trafiğini denetlemek istediğimiz sunucuya, Jump-SN ise o dönem yönetim için oluşturduğumuz atlama sunucusuna ayrılmıştı. Srv-Work sunucusunun doğrudan public IP adresi bulunmuyor; dışarıya çıkan trafiği Azure Firewall üzerinden yönlendireceğiz.
Buradaki topoloji bir eğitim laboratuvarıdır. Güncel üretim kurulumlarında Azure Firewall için ayrı bir hub VNet ve uygulamalar için spoke VNet yapısı tercih edilebilir. Ayrıca doğrudan internete açık RDP portu yerine Azure Bastion, VPN veya yönetim ağı kullanılması gerekir. 2020 ekran görüntülerindeki public IP üzerinden RDP yöntemi yeni kuruluma tavsiye olarak alınmamalıdır.
Azure PowerShell ortamının hazırlanması
İlk kontrolümüz PowerShell sürümüdür. Eski makalede Windows PowerShell 5.1, .NET gereksinimleri ve AzureRM modülüne odaklanmıştım. Artık AzureRM eski bir modül ailesidir; güncel kurulumlarda Az modülünü kullanıyoruz. Güncel ve desteklenen bir PowerShell ortamında modül durumunu kontrol ederek başlamalıyız.
$PSVersionTable.PSVersion
Get-Module -ListAvailable Az | Select-Object Name, Version
AzureRM ile Az modüllerini aynı Windows PowerShell oturumunda birlikte kullanmaya çalışmak sürüm ve komut çakışmalarına neden olabilir. Bu nedenle eski AzureRM betiklerini taşıma planıyla ele almak gerekir; 2020 yılındaki modül yükleme ekranının yeni sürümlerde bire bir aynı olması beklenmemelidir.
# Kullanıcı profiline Az modülünü kurmak için
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery
# Abonelik ve hesap oturumunu aç
Connect-AzAccount
Get-AzContext
Get-AzSubscription | Select-Object Name, Id
Birden fazla abonelik kullananların yanlış kaynak grubunda işlem yapmaması için Set-AzContext -SubscriptionId <subscription-id> ile hedef aboneliği açıkça seçmesini öneriyorum. Komutları çalıştıran hesabın ilgili kaynak gruplarında gerekli Azure RBAC yetkilerine sahip olması gerekir.
Kaynak grubu, sanal ağ ve subnetler
Önce kaynak grubumuzu oluşturuyoruz. Test ortamında kaynak isimleri ve IP aralıklarını aynen koruyorum. Bölge olarak örnekteki East US kullanılıyor; ancak kaynakların kullanılabilirliği, veri yerleşimi ve fiyatlandırma nedeniyle kendi bölgenizi seçebilirsiniz.
$rg = 'Test-FW-RG'
$location = 'eastus'
New-AzResourceGroup -Name $rg -Location $location
Firewall subneti için özel AzureFirewallSubnet adının kullanılması gerekir. Bu subnetin en az /26 olması şarttır. Adresler uygulama subnetleri ile çakışmamalıdır.
$fwSub = New-AzVirtualNetworkSubnetConfig -Name 'AzureFirewallSubnet' -AddressPrefix '10.0.1.0/26'
$workSub = New-AzVirtualNetworkSubnetConfig -Name 'Workload-SN' -AddressPrefix '10.0.2.0/24'
$jumpSub = New-AzVirtualNetworkSubnetConfig -Name 'Jump-SN' -AddressPrefix '10.0.3.0/24'
$vnet = New-AzVirtualNetwork -Name 'Test-FW-VN' -ResourceGroupName $rg `
-Location $location -AddressPrefix '10.0.0.0/16' `
-Subnet $fwSub,$workSub,$jumpSub
Sanal makinelerin hazırlanması ve erişim güvenliği
İlk laboratuvarda Srv-Jump internete açık RDP ile kullanılıyor, Srv-Work ise public IP olmadan Workload-SN üzerinde bulunuyordu. Bu düzeni tarihsel senaryo olarak saklıyorum. Bugün aynı testi kuracak olsam iki VM için de doğrudan public yönetim portu açmaz; Azure Bastion veya şirketin özel ağ bağlantısını tercih ederdim.
VM oluştururken kullanılan Standard_DS2 boyutunu ve Windows Server 2016 imajını güncel öneri olarak almamak gerekiyor. Seçilecek bölge, mevcut VM SKU, desteklenen işletim sistemi imajı, kimlik doğrulama yöntemi ve maliyet mutlaka kontrol edilmeli. Örnek aşağıda yalnızca sanal NIC mantığını gösteriyor:
# Public IP olmadan Workload-SN içinde ağ kartı oluşturma örneği
$workloadSubnet = $vnet.Subnets | Where-Object Name -eq 'Workload-SN'
$nic = New-AzNetworkInterface -Name 'Srv-Work-NIC' -ResourceGroupName $rg `
-Location $location -SubnetId $workloadSubnet.Id
# VM boyutu, işletim sistemi imajı ve yönetici kimlik bilgileri
# bölgeye ve kurum politikasına göre ayrıca seçilmelidir.
Azure Firewall dağıtımı ve Firewall Policy
Şimdi güvenlik duvarına geçebiliriz. Standart genel IP adresi ve Azure Firewall altyapısı için 2020 laboratuvarındaki dağıtım adımları kavramsal olarak hâlâ açıklayıcı. Ancak güncel yeni kurulumda Firewall Policy oluşturup kural koleksiyonlarını bu ilkeye bağlamak daha sürdürülebilir bir yöntemdir. Basic, Standard ve Premium SKU seçenekleri arasında özellik farkları bulunur; örneğin TLS inspection ve IDPS gereksinimlerinde Premium değerlendirilmelidir.
# Firewall için Standard SKU statik Public IP
$fwPip = New-AzPublicIpAddress -Name 'fw-pip' -ResourceGroupName $rg `
-Location $location -AllocationMethod Static -Sku Standard
# Firewall Policy kaynağı (kural koleksiyonları ayrıca tanımlanır)
$policy = New-AzFirewallPolicy -Name 'Test-FW-Policy' `
-ResourceGroupName $rg -Location $location
# Klasik 2020 komutunun örneği (policy bağlantısını içermez):
# $azfw = New-AzFirewall -Name 'Test-FW01' -ResourceGroupName $rg `
# -Location $location -VirtualNetworkName 'Test-FW-VN' -PublicIpName 'fw-pip'Burada özellikle altını çiziyorum: Yukarıdaki iki oluşturma komutu firewall dağıtımını tamamlamaz. Firewall Policy nesnesinin firewall ile ilişkilendirilmesi, rule collection group tanımı ve SKU seçimi kendi dağıtımına göre ayrıca yapılmalıdır. Tam dağıtımın doğrulamasını yapmadan trafiğin filtrelendiğini kabul etmeyin.
Varsayılan rotanın Azure Firewall üzerine alınması
Workload sunucusunun internet trafiğinin firewall üzerinden geçmesi için subnet üzerinde user-defined route (UDR) tanımlıyoruz. Buradaki 0.0.0.0/0 rotası next hop olarak firewall private IP adresini kullanır. Bu rota Workload-SN üzerinde uygulanır; AzureFirewallSubnet için aynı yaklaşımı körlemesine uygulamak doğru değildir.
# Firewall kurulduktan sonra private IP'yi mevcut kaynaktan okuyun
$azfw = Get-AzFirewall -Name 'Test-FW01' -ResourceGroupName $rg
$fwPrivateIp = $azfw.IpConfigurations[0].PrivateIPAddress
$routeTable = New-AzRouteTable -Name 'Firewall-rt-table' `
-ResourceGroupName $rg -Location $location
$routeTable = Add-AzRouteConfig -Name 'DG-Route' -AddressPrefix '0.0.0.0/0' `
-NextHopType VirtualAppliance -NextHopIpAddress $fwPrivateIp -RouteTable $routeTable
$routeTable | Set-AzRouteTable
$vnet = Get-AzVirtualNetwork -Name 'Test-FW-VN' -ResourceGroupName $rg
Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name 'Workload-SN' `
-AddressPrefix '10.0.2.0/24' -RouteTable $routeTable | Set-AzVirtualNetworkRoute tamamlandıktan sonra yalnızca konfigürasyona bakmak yeterli değil. Workload VM ağ kartının Effective routes görünümünde varsayılan rotanın doğru next hop üzerinden geçtiğini kontrol edin.
Uygulama kuralı: ÇözümPark erişimine izin verilmesi
Orijinal laboratuvarda amaç www.cozumpark.com erişimine izin vermek ve örneğin Google erişimini kural olmadığı için engellemekti. Bu, Azure Firewall application rule mantığını göstermek için kullanışlı bir testtir. Güncel Firewall Policy modelinde application rule ve network rule koleksiyonlarını bir rule collection group içinde tanımlarız.
# Firewall Policy için application rule örneği
$appRule = New-AzFirewallPolicyApplicationRule -Name 'Allow-CozumPark' `
-SourceAddress '10.0.2.0/24' -Protocol 'http:80','https:443' `
-TargetFqdn 'www.cozumpark.com'
$appCollection = New-AzFirewallPolicyFilterRuleCollection -Name 'App-Coll01' `
-Priority 200 -ActionType Allow -Rule $appRule
# $appCollection ilgili Firewall Policy Rule Collection Group içine eklenmelidir.Kuralın etkili olması için Firewall Policy ilişkisinin, collection priority değerlerinin ve diğer izin/engelleme kurallarının birlikte incelenmesi gerekir. Ayrıca sadece FQDN izin vermek, uygulamanın çağırdığı başka uç noktaların otomatik açılacağı anlamına gelmez.
Network rule ve DNS davranışı
2020 laboratuvarında 209.244.0.3 ve 209.244.0.4 adreslerine UDP 53 izni vererek DNS çözümlemesi sağlamıştık. Bu IP adresleri eski senaryonun parçasıdır; şirket ortamında bilinçsizce dış DNS sunucularına yönlendirme yapılmamalı. AD ortamında kurumsal DNS, Azure DNS Private Resolver ve güvenlik mimarisi ayrıca değerlendirilmelidir.
# Eğitim ortamında network rule örneği (gerçek DNS hedeflerini doğrulayın)
$dnsRule = New-AzFirewallPolicyNetworkRule -Name 'Allow-DNS' `
-Protocol UDP,TCP -SourceAddress '10.0.2.0/24' `
-DestinationAddress '<KURUMSAL-DNS-IP>' -DestinationPort 53
# Rule collection ve policy ile ilişkilendirilmeden aktif değildir.Güncel tasarımda Azure Firewall DNS Proxy de değerlendirilmelidir. Özellikle network rule üzerinde FQDN kullanıldığında istemci ile firewall arasında farklı DNS sonuçları oluşmaması için DNS Proxy yapılandırması önemlidir. DNS Proxy varsayılan olarak açık değildir; ihtiyaca göre policy içinde etkinleştirilir.
Test: izin verilen ve verilmeyen erişim
Tüm ağ, yönlendirme, DNS ve kural ayarları tamamlandığında bağlantı testine geçebiliriz. Eski senaryoda önce Jump sunucusuna bağlanıp oradan Workload sunucusuna RDP yapmış, ardından iki farklı web sitesini açarak sonucu kontrol etmiştim. Günümüzde aynı testi private yönetim kanalıyla yapmayı tercih ederim.
2020 örneğinde ÇözümPark açılırken izin vermediğim başka bir site açılmıyordu. Ancak tarayıcı testi tek başına yeterli bir üretim kabul testi değildir. Firewall Policy hit logları, DNS çözümleme sonuçları, effective routes, NSG akışı ve Azure Monitor kayıtları birlikte incelenmelidir. Hatalı bir UDR veya DNS ayarı firewall kuralı doğru olsa bile erişim sorununa neden olabilir.
2026 için dikkat ettiğim noktalar
Yeni bir müşteri ortamında Azure Firewall kurarken önce topolojiyi, internet çıkış ihtiyacını, DNS çözümlemesini ve yönetim erişimini tasarlıyorum. Basic/Standard/Premium seçiminde maliyet kadar ihtiyaç duyulan yetenekler de önemli. Firewall Policy, uygulama ve ağ kurallarının merkezi yönetimini kolaylaştırıyor; Hub-Spoke modeli ise aynı firewall hizmetini birden fazla workload için kullanmamıza olanak tanıyor.
Kurulumdan önce egress gereksinimlerini, zorunlu Microsoft servis etiketlerini, özel bağlantı senaryolarını ve kurumsal erişim yollarını netleştirmek gerekir. Kurulumdan sonra ise Azure Monitor günlükleri ve alarm kurallarıyla yalnızca erişimin değil, kural eşleşmelerinin de takip edilmesi önemlidir. Özellikle üretim ortamlarında public RDP açılmasını, laboratuvarda gördüğümüz örneğin doğrudan tekrarını ve tanımları gözden geçirilmemiş geniş Allow kurallarını önermiyorum.
Bu yazıdaki 19 ekran görüntüsü 2020 yılında kurduğum laboratuvarın gerçek adımlarını gösteriyor. Komutların ve ekranların aynı şekilde çalışacağını varsaymak yerine, güncel Az modülü ve Firewall Policy yapısıyla uyumluluğu kendi aboneliğinizde doğrulayarak ilerlemek gerekiyor.
Önceki bölümde anlattığım portal tabanlı kurguyu görmek isteyenler için Azure Portal üzerinden Azure Firewall yapılandırılması makalem de tamamlayıcı bir kaynak olabilir.
