Azure Local ortamlarında ağ güvenliğini sağlamak ve trafiği kontrol altına almak için kullanılan en temel yapılardan biri Network Security Group (NSG)’lerdir. NSG’ler, hem sanal makineler (VM) hem de mantıksal ağlar (logical networks) arasında gerçekleşen veri akışını merkezi ve kurallı bir şekilde yönetmenizi sağlar.

Azure Local’da NSG Nedir?

Network Security Group, Azure Local üzerindeki ağ trafiğini denetlemek için kullanılan bir güvenlik katmanıdır. Temel işlevi, belirlenen kurallar doğrultusunda gelen (inbound) ve giden (outbound) trafiğe izin vermek veya bu trafiği engellemektir. Bu sayede hem güvenlik artırılır hem de ağ segmentasyonu sağlanır.

Trafik Kontrolü Nasıl Çalışır?

NSG’ler, ağ trafiğini belirli kriterlere göre değerlendirir. Bu kriterler şunlardır:

  • Kaynak ve hedef IP adresleri: Trafiğin nereden geldiği ve nereye gittiği
  • Port numaraları: Hangi uygulama veya servis üzerinden iletişim kurulduğu
  • Protokoller: TCP veya UDP gibi iletişim türleri
  • Yön: Trafiğin içeri mi (inbound) yoksa dışarı mı (outbound) olduğu

Bu parametreler üzerinden oluşturulan kurallar sayesinde oldukça granular (ince detaylı) bir kontrol mekanizması elde edilir.

NSG’lerin Konumlandırılması

Azure Local mimarisinde NSG’ler iki ana noktaya bağlanabilir:

  • Mantıksal ağlar (Logical Networks): Ağ seviyesinde genel kurallar uygulanır
  • VM ağ arayüzleri (NIC): Belirli bir sanal makineye özel güvenlik politikaları tanımlanır

Bu yapı, hem geniş kapsamlı hem de mikro seviyede güvenlik senaryolarını aynı anda uygulamaya imkan tanır.

Azure Local gibi dağıtık ve hibrit ortamlarda, farklı lokasyonlar ve iş yükleri arasında güvenli iletişim kritik öneme sahiptir. NSG kullanımı sayesinde, Yetkisiz erişimlerin önüne geçilir, ağ trafiği segmentlere ayrılarak izole edilir, uygulama bazlı güvenlik politikaları uygulanabilir, merkezi yönetim ile operasyonel kontrol sağlanır. Aslında Azure NSG bilen birisi için fark olmadığını görebilirsiniz. Bu da aslında çok kıymetli bir durum, neden derseniz tek bir plarformu öğrenip onprem sistemlerde dahi aslında aynı teknolojileri kullanabiliyorsunuz. Azure Local’ in en büyük olayı da bu zaten :)

Görsel olarak konuyu ele almak gerekir ise durum aşağıdaki gibidir;

Azure Local ortamında Network Security Group (NSG) kullanımını somut bir senaryo üzerinden ele aldığımızda, iki ayrı mantıksal ağ (logical network) arasında güvenli ve kontrollü iletişim sağlandığını görüyoruz.

Senaryo Mimarisi

Bu örnekte iki farklı ağ segmenti bulunuyor:

Logical Network A (Uygulama Katmanı)

  • Subnet: 192.168.1.0/24
  • VLAN: 206
  • VM: Web sunucusu (192.168.1.3)
  • NSG Kuralı: İnternete outbound erişime izin veriliyor

Bu yapı sayesinde Web sunucusu hem dış dünyaya erişebiliyor hem de uygulama katmanı olarak kullanıcı isteklerini karşılayabiliyor.

Logical Network B (Veri Katmanı)

  • Subnet: 192.168.2.0/24
  • VLAN: 310
  • VM: SQL sunucusu (192.168.2.3)
  • NSG Kuralı: İnternete outbound erişim engellenmiş

SQL sunucusu yalnızca lokal ortamda çalışıyor ve dış dünyaya tamamen kapalı. Bu, veri güvenliği açısından kritik bir izolasyon sağlıyor.

Trafik Akışı ve Güvenlik Kontrolü

Bu mimaride NSG’ler iki temel kontrolü gerçekleştiriyor:

  1. Ağlar arası trafik kontrolü (East-West Traffic):
    Logical Network A ile B arasındaki iletişim sınırlandırılıyor. Örneğin yalnızca belirli portlara izin veriliyor.
  2. Dış dünya erişimi (North-South Traffic):
    • Web sunucusu internete çıkabiliyor
    • SQL sunucusu internete kapalı

Örnek Güvenlik Kuralı

En kritik senaryolardan biri, uygulama katmanının veri tabanına erişimi:

  • Logical Network B üzerinde bir NSG kuralı tanımlanır
  • Sadece Logical Network A’dan gelen trafik kabul edilir
  • Sadece TCP 1433 (SQL portu) açık bırakılır

Bu sayede:

  • Web sunucusu → SQL sunucusuna erişebilir
  • Başka hiçbir kaynak → SQL sunucusuna erişemez
  • SQL sunucusu → internete çıkamaz

NSG’nin Konumlandırılması

Bu senaryoda NSG iki farklı seviyede uygulanabilir:

  • Logical Network seviyesinde: Tüm subnet için genel politika
  • VM NIC seviyesinde: Daha granular, VM bazlı kontrol

Bu yapı klasik 3-tier mimarinin (web + database) Azure Local üzerindeki modern karşılığıdır. NSG kullanımı sayesinde:

  • Katmanlar arası izolasyon sağlanır
  • Minimum yetki prensibi uygulanır
  • Saldırı yüzeyi ciddi şekilde azaltılır

Azure Local’da NSG’ler, yalnızca trafiği açıp kapatan basit kurallar değil; aynı zamanda mimari güvenliğin temel yapı taşlarından biridir. Doğru kurgulandığında, hem uygulama sürekliliğini korur hem de veri katmanını dış tehditlere karşı güçlü bir şekilde izole eder.

Peki uygulama tarafına geçelim, Azure Local üzerinde NSG için minimum sistem gereksinimleri ve yetkileri aşağıdaki gibidir;

Eğer Azure CLI ile NSG uygulaması yapacaksanız;

1. Platform ve Sürüm Gereksinimi

Azure Local instance’ının belirli bir minimum versiyonda çalışması zorunludur:

  • Azure Local versiyonu: 2506 veya üzeri
  • İşletim sistemi versiyonu: 26100.xxxx veya üzeri

Bu sürümler, NSG ve SDN gibi gelişmiş ağ özelliklerinin desteklenmesi için gereklidir.

2. Custom Location Tanımı

Azure Local instance’ının bir custom location ile ilişkilendirilmiş olması gerekir.

Custom location, Azure kaynakları ile on-prem ortam arasındaki ilişkiyi kurar ve kaynakların Azure üzerinden yönetilmesini mümkün kılar.

3. Yetkilendirme (RBAC)

NSG yönetimi için uygun rol ataması yapılmalıdır:

  • Azure Stack HCI Administrator RBAC rolü gereklidir
  • Bu rol, Azure Local instance ve ilgili tüm kaynaklar üzerinde tam yetki sağlar

Bu sayede NSG oluşturma, düzenleme ve uygulama işlemleri yapılabilir.

4. SDN (Software Defined Networking) Aktif Olmalı

NSG’ler, Azure Local’daki yazılım tanımlı ağ mimarisinin bir parçasıdır:

  • SDN özelliği aktif olmalıdır
  • SDN olmadan NSG gibi merkezi ağ politikaları uygulanamaz

Bu katman, ağ izolasyonu ve trafik kontrolünün temelini oluşturur.

5. Ağ Kaynaklarının Hazır Olması

NSG’lerin uygulanabilmesi için temel ağ bileşenlerinin önceden oluşturulmuş olması gerekir:

  • En az bir adet statik logical network
  • En az bir adet statik network interface (NIC)

Bu kaynaklar, NSG kurallarının bağlanacağı hedeflerdir.

6. Yönetim Araçları (Client Gereksinimleri)

Azure Local ortamını dışarıdan yönetmek için kullanılan istemci tarafında da bazı gereksinimler vardır:

  • Güncel Azure CLI kurulumu
  • az-stack-hci-vm extension yüklü olmalı

Bu araçlar sayesinde NSG ve VM ağ yapılandırmaları komut satırı üzerinden yönetilebilir.

Eğer Azure CLI yerine Azure Portal üzerinden NSG uygulamasını yapacaksanız gereksinimler ise aşağıdaki gibidir;

1. Platform ve Sürüm Uyumluluğu

Azure Local instance’ının güncel ve desteklenen bir sürümde çalışması kritik bir ön koşuldur:

  • Azure Local versiyonu: 2506 veya üzeri
  • İşletim sistemi: 26100.xxxx veya üzeri

Bu sürümler, NSG ve SDN gibi modern ağ özelliklerinin sorunsuz çalışabilmesi için gereklidir.

2. Custom Location Tanımı

Azure Local ortamının Azure ile entegre çalışabilmesi için:

  • Instance’ın bir custom location ile ilişkilendirilmiş olması gerekir

Custom location, Azure kaynakları ile on-prem altyapı arasında bir köprü görevi görerek merkezi yönetimi mümkün kılar.

3. Yetkilendirme (RBAC)

Ağ güvenliği ve NSG yönetimi için doğru rol atanmalıdır:

  • Azure Stack HCI Administrator rolü gereklidir
  • Bu rol, Azure Local instance ve bağlı tüm kaynaklar üzerinde tam yetki sağlar

Bu sayede kullanıcı, NSG oluşturma, düzenleme ve uygulama işlemlerini gerçekleştirebilir.

4. Software Defined Networking (SDN)

NSG’ler, Azure Local’daki yazılım tanımlı ağ mimarisinin bir parçasıdır:

  • SDN özelliği aktif olmalıdır

SDN olmadan merkezi ağ politikaları, segmentasyon ve trafik kontrolü mümkün değildir.

Gelelim uygulama aşamasına. Öncelikle Azure Local kaynak sayfasından kaynaklar ve NSG’ye ilerliyoruz;

Ardından sağ bölümde “Create network security group” linkine tıklıyoruz

Daha sonra temel bilgileri giriyoruz

Subscription (Abonelik)

NSG’nin hangi Azure aboneliği altında oluşturulacağını belirlediğiniz alandır.

  • Azure Local instance’ınızın bağlı olduğu subscription seçilmelidir
  • Yanlış subscription seçimi, kaynakların görünmemesine veya yönetilememesine neden olabilir

Resource Group

NSG’nin yer alacağı kaynak grubunu belirler:

  • Yeni bir resource group oluşturabilir veya mevcut bir grubu seçebilirsiniz
  • Genellikle Azure Local VM ve ağ kaynakları ile aynı resource group kullanılır

Bu yaklaşım, operasyonel yönetimi ve lifecycle takibini kolaylaştırır.

Instance Name (NSG İsmi)

Oluşturulacak NSG için benzersiz ve anlamlı bir isim girilmelidir:

  • Örnek: nsg-web-tier, nsg-sql-isolation
  • İsimlendirme, mimariyi ve amacını yansıtacak şekilde yapılmalıdır

Region (Bölge)

NSG’nin oluşturulacağı Azure bölgesi seçilir:

  • Mutlaka Azure Local instance ile aynı region olmalıdır
  • Farklı region seçimi, kaynak eşleşme ve deployment hatalarına yol açar

Custom Location

Azure Local instance ile ilişkilendirilmiş custom location seçilir:

  • Bu seçim, NSG’nin doğrudan ilgili Azure Local ortamına bağlanmasını sağlar
  • Azure Arc entegrasyonunun bir parçasıdır

Review + Create

Tüm parametreler girildikten sonra:

  • Konfigürasyon gözden geçirilir
  • Herhangi bir hata yoksa NSG oluşturma işlemi başlatılır

Son olarak Create düğmesine basıyoruz ve işin bitmesini bekliyoruz.

Ardından kaynaklar bölümünde yeni NSG görünür

Şimdi sıra Security Rule oluşturmaya geldi.

Azure Local resource page > Resources > Network security groups.

Bu yolu izliyoruz

Ardından sağ bölümdeki ilgili NSG’lerden birini seçiyoruz

Daha sonra sol menüden settings, inbound security rules veya outbound security rules kısmına geliyoruz. Daha sonra sağ menüden create linkine tıklıyoruz.

Ardından aşağıdaki bölümleri dolduruyoruz

NSG Kural Parametreleri

Source (Kaynak)

Trafiğin nereden geldiğini tanımlarsınız:

  • IP address: Belirli bir IP veya subnet
  • Any: Tüm kaynaklardan gelen trafik

Bu alan, inbound trafiğin başlangıç noktasını belirler.

Source IP Address / CIDR Ranges

Kaynağı daha spesifik tanımlamak için kullanılır:

  • Tek IP: 192.168.1.10
  • Subnet (CIDR): 192.168.1.0/24

CIDR kullanımı, geniş ağ segmentlerini tek kural ile yönetmeyi sağlar.

Source Port Ranges

Kaynak portlarını belirtir:

  • Tek port: 443
  • Port aralığı: 1000-2000
  • Tüm portlar: *

Genellikle client tarafı dinamik port kullandığı için çoğu senaryoda * tercih edilir.

Destination (Hedef)

Trafiğin nereye gittiğini tanımlar:

  • IP address: Belirli bir hedef
  • Any: Tüm hedefler

Outbound trafiğin hedefini kontrol etmek için kullanılır.

Destination IP Address / CIDR Ranges

Hedef IP veya subnet tanımı:

  • Örnek: 192.168.2.0/24 (SQL ağı)

Bu alan, özellikle ağ segmentasyonu senaryolarında kritik rol oynar.

Destination Port Ranges

Hedef servis/uygulama portunu belirler:

  • Örnekler:
    • 80 (HTTP)
    • 443 (HTTPS)
    • 1433 (SQL Server)
  • Tüm portlar için: *

Protocol (Protokol)

Trafiğin türünü belirler:

  • TCP: Web, SQL gibi stateful uygulamalar
  • UDP: DNS, streaming gibi connectionless trafik
  • ICMP: Ping ve network testleri
  • Any: Tüm protokoller

Action (Aksiyon)

Kuralın sonucu:

  • Allow: Trafiğe izin ver
  • Deny: Trafiği engelle

NSG mantığında explicit deny/allow kuralları güvenliğin temelini oluşturur.

Priority (Öncelik)

Kuralların işlenme sırasını belirler:

  • Değer aralığı: 100 – 4096
  • Düşük sayı = yüksek öncelik

İlk eşleşen kural uygulanır, bu yüzden kritik kurallar daha düşük priority ile tanımlanmalıdır.

Name (İsim)

Kural için benzersiz bir isim:

  • Örnek: allow-web-to-sql-1433
  • NSG içinde unique olmalıdır

Description (Açıklama)

Opsiyonel ama kritik bir alan:

  • Kuralın amacını açıklar
  • Operasyonel sürdürülebilirlik için önerilir

Örnek Senaryo

Önceki mimariyi düşünürsek:

  • Web (192.168.1.0/24) → SQL (192.168.2.0/24) erişimi

Bir NSG kuralı şu şekilde olur:

  • Source: 192.168.1.0/24
  • Destination: 192.168.2.0/24
  • Destination Port: 1433
  • Protocol: TCP
  • Action: Allow
  • Priority: 200

Bunun altına:

  • Tüm diğer trafiği engelleyen bir Deny kuralı eklenir

Son olarak “Add” dediğimiz zaman aşağıdaki gibi kuralı panelde görebiliriz;

Süreci tamamlamış olduk.

Gelelim bir başka önemli konuya; Default Network Access Policy

Azure Local ortamında default network access policy oluşturmak, güvenliği “default deny” yaklaşımıyla kurgulamanın en doğru yoludur. Bu modelde temel prensip:

  • Inbound trafik: Varsayılan olarak engellenir
  • Outbound trafik: Varsayılan olarak serbest bırakılır

Böylece sadece açıkça izin verilen erişimler mümkün olur ve özellikle lateral movement (yatay saldırı yayılımı) ciddi şekilde sınırlandırılır.

Default Network Access Policy Nedir?

Bu politika, Azure Local VM’ler için başlangıç seviyesinde bir güvenlik baseline’ı oluşturur. Amaç:

  • Gereksiz tüm inbound erişimleri kapatmak
  • Sadece gerekli yönetim ve uygulama portlarını açmak
  • VM’lerin dış kaynaklara erişimini kontrollü ama esnek bırakmak

Politika Tasarımı (Best Practice)

1. Inbound Trafik: “Deny by Default”

Tüm inbound trafiği engelleyen bir kural tanımlanır:

  • Source: Any
  • Destination: VM subnet veya NIC
  • Port: *
  • Protocol: Any
  • Action: Deny
  • Priority: Örn. 300

Ancak bunun öncesinde yönetim erişimleri için allow kuralları tanımlanmalıdır.

2. Yönetim Portları için Allow Kuralları

İhtiyaca göre sadece belirli portlar açılır:

Örnekler:

  • RDP (3389) → Windows VM yönetimi
  • SSH (22) → Linux VM yönetimi
  • WinRM / PowerShell Remoting

Bu kurallar:

  • Daha düşük priority ile (örn. 100–200 arası) yazılmalıdır
  • Mümkünse IP bazlı kısıtlanmalıdır (örneğin sadece bastion veya admin subnet)

3. Outbound Trafik: “Allow by Default”

Outbound trafik genellikle serbest bırakılır:

  • Destination: Any
  • Port: *
  • Protocol: Any
  • Action: Allow

Bu sayede:

  • VM’ler update alabilir
  • dış servislerle iletişim kurabilir

İleri seviye güvenlik için outbound da kısıtlanabilir (örn. sadece belirli FQDN/IP’ler).

NSG Politikasının Uygulanma Yöntemleri

Azure Local’da bu default policy iki farklı aşamada uygulanabilir:

1. VM Oluşturulurken (Recommended)

  • VM, bir logical network’e bağlanır
  • NSG bu aşamada iliştirilir

Avantaj:

  • VM daha baştan güvenli şekilde ayağa kalkar
  • “Security by design” yaklaşımı uygulanır

2. VM Oluşturulduktan Sonra

  • Mevcut VM’in NIC’ine veya bağlı olduğu logical network’e NSG atanır

Avantaj:

  • Mevcut sistemlerde retrofit uygulanabilir

Risk:

  • NSG uygulanana kadar VM açık olabilir

Güvenlik Perspektifi

Bu model özellikle şu riskleri minimize eder:

  • Aynı ağ içindeki VM’ler arası kontrolsüz erişim
  • Zararlı yazılımların network içinde yayılması
  • Gereksiz açık portlardan exploitation

Bu nedenle enterprise ortamlarda bu yaklaşım Zero Trust mimarisinin temel adımlarından biri olarak kabul edilir ki benimde önerdiğim bir mimaridir.

Umarım faydalı bir yazı olmuştur, bir sonraki yazımda görüşmek üzere.

Published On: 25 Mart 2026 / Categories: Microsoft Azure / 12,9 min read /

Bilgiyi Paylaşın!