Bulut Altyapısında Sanal Ağ Segmentasyonu Nasıl Kurulur

Bulut ortamlarına taşınan sistemlerin sayısı arttıkça, tek bir düz ağ yapısı içinde tüm sunucuları, veritabanlarını ve uygulamaları çalıştırmak ciddi güvenlik riskleri doğurur. Bir bileşende oluşan güvenlik açığı, segmentasyon olmadığı durumda tüm ortama yayılabilir. Bu makalede bulut altyapısında sanal ağ segmentasyonunun nasıl kurulacağını, hangi bileşenlerin devreye girdiğini ve platformlar arasındaki farkları ele alıyoruz.

Bulut Ağ Segmentasyonunun Temelleri

Sanal ağ segmentasyonu, bulut ortamındaki kaynakları mantıksal gruplara ayırarak her grup arasındaki trafiği kontrol etme pratiğidir. Amaç, bir sunucu veya uygulama ele geçirildiğinde saldırganın ağın diğer bölümlerine serbestçe geçiş yapmasını önlemektir.

Ağ izolasyonu, güvenlik seviyesini artırmanın en temel yollarından biridir. Web sunucularını, uygulama katmanını ve veritabanı sunucularını ayrı alt ağlara (subnet) yerleştirip aralarındaki trafiği yalnızca gerekli portlarla sınırlamak, saldırı yüzeyini önemli ölçüde azaltır. Bu yaklaşım aynı zamanda "yanal hareket" (lateral movement) riskini düşürür; yani bir sistemde ele geçirilen erişim, otomatik olarak diğer sistemlere sıçramaz.

Segmentasyonun performans ve maliyet üzerinde de etkileri vardır. Trafiği mantıksal olarak ayırmak, gereksiz veri akışını azaltır ve ağ kaynaklarının daha verimli kullanılmasını sağlar. Ayrıca yanlış yapılandırılmış, aşırı geniş kapsamlı kurallar yerine ihtiyaca özel kurallar tanımlamak, hem güvenliği hem de izlenebilirliği kolaylaştırır.

Düzenleyici gereklilikler açısından da segmentasyon kritik bir rol oynar. HIPAA ve PCI-DSS gibi standartlar, hassas verilerin (sağlık kayıtları, kart bilgileri) diğer sistemlerden izole edilmesini şart koşar. Bu nedenle denetimlerde segmentasyon mimarisinin dokümante edilmiş ve test edilmiş olması beklenir. Bu standartların tam gerekliliklerini uygularken ilgili resmi kılavuzlara başvurmak önemlidir.

Temel Bileşenler: Subnets, Security Groups ve Network ACL'ler

Segmentasyonu kurmadan önce üç temel bileşeni anlamak gerekir.

Subnets (alt ağlar): Bir sanal ağın (VPC/VNet) IP adres aralığının daha küçük parçalara bölünmesidir. Her subnet, belirli bir kaynak grubuna (örneğin web sunucuları veya veritabanları) ayrılabilir ve genellikle belirli bir erişilebilirlik bölgesine (availability zone) bağlanır. Subnet'ler, ağın fiziksel/mantıksal sınırlarını oluşturan ilk katmandır.

Security Groups: Sanal makine veya kaynak seviyesinde çalışan, stateful (durum bilgili) bir filtreleme mekanizmasıdır. Bir bağlantıya izin verildiğinde, o bağlantının yanıt trafiği otomatik olarak kabul edilir; ayrıca bir kural tanımlamaya gerek yoktur. Bu, günlük kullanımda daha basit ve yönetilebilir kurallar yazmayı sağlar.

Network ACL'ler (NACL): Subnet seviyesinde çalışan, stateless (durumsuz) bir filtreleme katmanıdır. Giden ve gelen trafik için ayrı ayrı kural tanımlanması gerekir; bir isteğe verilen yanıtın da açıkça izin verilmesi şarttır. NACL'ler genellikle subnet düzeyinde geniş kapsamlı, kaba taneli kurallar için kullanılırken, Security Group'lar kaynak düzeyinde daha ince taneli kontrol sağlar.

Pratikte ikisi birlikte kullanılır: NACL'ler subnet'e giren/çıkan trafiğin genel sınırlarını çizer, Security Group'lar ise her bir kaynağın hangi port ve protokollerle erişilebilir olacağını belirler. Çok katmanlı bir savunma (defense in depth) stratejisi için bu ikilinin birlikte kullanılması önerilir.

Sanal Ağ Segmentasyonu Adım Adım Kurulum

Segmentasyon kurulumu genel olarak şu aşamalardan oluşur:

1. Planlama ve tasarım: Önce hangi kaynakların hangi gruplara ayrılacağı belirlenir. Tipik bir üç katmanlı mimari; web, uygulama ve veri tabanı katmanlarını ayrı subnet'lere yerleştirir. Bu aşamada IP adresleme planı (CIDR blokları) da hazırlanmalıdır — ileride büyüme ihtimaline karşı yeterli adres alanı bırakmak önemlidir.

2. Sanal ağın (VPC/VNet) oluşturulması: Genel IP aralığı (örneğin 10.0.0.0/16) tanımlanarak sanal ağ oluşturulur. Bu, tüm alt ağların içinde yer alacağı üst kapsayıcıdır.

3. Alt ağların (subnets) oluşturulması: Üst CIDR bloğu, her katman için ayrı aralıklara bölünür (örneğin web katmanı için 10.0.1.0/24, uygulama katmanı için 10.0.2.0/24, veri tabanı için 10.0.3.0/24). Veri tabanı gibi dışa açılmaması gereken kaynaklar genellikle "private subnet" olarak, doğrudan internete açık olması gereken kaynaklar ise "public subnet" olarak tasarlanır.

4. Internet Gateway, NAT Gateway ve Route Table yapılandırması: Public subnet'lerin internete çıkışı için bir Internet Gateway tanımlanır. Private subnet'lerdeki kaynakların güncelleme gibi işlemler için çıkış trafiğine ihtiyacı varsa, bir NAT Gateway üzerinden yönlendirme yapılır. Route Table'lar, hangi trafiğin hangi gateway üzerinden geçeceğini belirler; her subnet uygun route table ile ilişkilendirilmelidir.

5. Güvenlik kurallarının tanımlanması: Security Group ve NACL kuralları, sadece gerekli port ve protokollere izin verecek şekilde dar kapsamlı tanımlanır. Örneğin veri tabanı subnet'i, yalnızca uygulama katmanından gelen belirli bir port üzerinden (örneğin 3306 veya 5432) erişime açılmalı, dışarıdan doğrudan erişime kapatılmalıdır.

Trafik Kontrulü ve Mikro-Segmentasyon Stratejileri

Temel subnet tabanlı segmentasyonun ötesinde, daha granüler kontrol isteyen ortamlar için mikro-segmentasyon uygulanabilir.

Katman bazlı segmentasyon: Web, uygulama ve veri tabanı katmanları arasındaki trafik sıkı şekilde sınırlanır. Web katmanı sadece uygulama katmanına belirli portlardan erişebilir; uygulama katmanı sadece veri tabanına gerekli porttan bağlanabilir. Veri tabanı katmanının dışarıya giden trafiği de mümkün olduğunca kısıtlanmalıdır.

İç ağ trafiğinin kontrolü: Aynı subnet içindeki kaynaklar arasında da (East-West trafik) kontrol uygulanabilir. Bulut sağlayıcılarının sunduğu Security Group'lar, kaynak bazlı (instance-level) kurallarla aynı subnet içindeki makineler arasında da izolasyon sağlayabilir.

Zero-trust modeli: Geleneksel "ağ içindekine güven" yaklaşımının tersine, zero-trust modeli her bağlantının kimlik doğrulaması ve yetkilendirmeden geçmesini zorunlu kılar. Buluta özgü uygulamalarda bu, her isteğin hem ağ seviyesinde hem kimlik/erişim yönetimi (IAM) seviyesinde doğrulanması anlamına gelir. Mikro-segmentasyon, zero-trust'ın ağ katmanındaki en pratik uygulama şekillerinden biridir.

Uygulama seviyesinde kurallar: Ağ seviyesindeki segmentasyona ek olarak, uygulama güvenlik duvarları (WAF) ve servis mesh çözümleri, HTTP istek düzeyinde ek filtreleme sağlayarak segmentasyonu tamamlayabilir.

AWS, Azure ve Google Cloud'da Segmentasyon Farklılıkları

Üç büyük bulut sağlayıcısı da benzer kavramları farklı isimlerle ve bazı teknik farklarla sunar.

AWS: Temel yapı VPC (Virtual Private Cloud) üzerine kuruludur. Subnet'ler availability zone'lara bağlıdır. Security Group'lar stateful ve sadece "allow" kuralları içerir ("deny" kuralı tanımlanamaz); Network ACL'ler ise stateless olup hem allow hem deny kuralları destekler. AWS'de ayrıca VPC Peering ve Transit Gateway gibi mekanizmalarla farklı VPC'ler arasında kontrollü bağlantı kurulabilir.

Azure: Yapı Virtual Network (VNet) üzerine kuruludur. Network Security Group'lar (NSG) hem subnet hem network interface seviyesinde uygulanabilir, bu da AWS'ye kıyasla biraz daha esnek bir model sunar. Azure'da ayrıca Application Security Groups ile kaynaklar mantıksal etiketlerle gruplanabilir, kurallar IP yerine bu gruplara göre tanımlanabilir.

Google Cloud: VPC yapısı global bir kaynak olarak tasarlanmıştır; subnet'ler bölgesel (regional) olup birden fazla zone'u kapsayabilir. Firewall Rules, AWS'nin Security Group'larına benzer şekilde çalışır ancak VPC seviyesinde tanımlanır ve etiketler (tags) veya hizmet hesapları (service accounts) üzerinden hedeflenebilir. Google Cloud'da ayrıca varsayılan olarak bazı firewall kuralları önceden tanımlıdır; bunların gözden geçirilip ihtiyaca göre sıkılaştırılması gerekir.

Her üç platformda da ortak prensip aynıdır: mümkün olan en dar kapsamlı kural setini tanımlamak ve varsayılan "hepsine izin ver" kurallarından kaçınmak. Platforma özgü detaylar için ilgili sağlayıcının resmi dokümantasyonuna başvurulması önerilir.

Yaygın Yapılandırma Hataları ve Sorun Giderme

Segmentasyon kurulumunda sıkça rastlanan hatalar şunlardır:

Yanlış veya çakışan Security Group/NACL kuralları: Bir kaynağa erişim sağlanamadığında, genellikle sorun hem Security Group hem NACL seviyesinde ayrı ayrı kontrol edilmelidir. NACL stateless olduğu için dönüş trafiğine izin verilmemesi, bağlantının "yarı açık" kalmasına ve zaman aşımına yol açabilir.

Aşırı permissif kurallar: "0.0.0.0/0" gibi tüm kaynaklara açık kurallar, hızlı test amacıyla eklenip sonradan kaldırılmayı unutulduğunda ciddi güvenlik açıkları oluşturur. Özellikle veri tabanı ve yönetim portlarının (SSH, RDP) genel internete açık bırakılması yaygın ve riskli bir hatadır.

Routing problemleri: Subnet'in doğru route table ile ilişkilendirilmemesi, private subnet'teki bir kaynağın internete çıkamamasına veya public subnet'in beklenmedik şekilde izole kalmasına neden olabilir. Route table'ların her subnet için doğru gateway'e işaret ettiği düzenli olarak kontrol edilmelidir.

Tanılama araçları: Bağlantı sorunlarında ping, traceroute (veya tracert) ve telnet/nc gibi araçlar, trafiğin hangi noktada kesildiğini belirlemede yardımcı olur. Bulut sağlayıcılarının sunduğu "flow log" ve ağ analiz araçları da (örneğin AWS VPC Flow Logs) hangi paketlerin reddedildiğini görmek için faydalıdır.

Segmentasyon Konfigürasyonunun Test Edilmesi ve Doğrulanması

Kurulum tamamlandıktan sonra doğrulama adımı atlanmamalıdır.

Bağlantı testleri: Her katman arasında beklenen trafiğin geçtiği, beklenmeyen trafiğin ise reddedildiği doğrulanmalıdır. Örneğin web katmanından veri tabanına doğrudan erişim denenip reddedildiğinden emin olunmalı, sadece uygulama katmanından izin verilen port üzerinden bağlantı kurulabildiği kontrol edilmelidir.

Kural denetimi: Security Group ve NACL kuralları periyodik olarak gözden geçirilmeli, kullanılmayan veya artık gereksiz olan kurallar temizlenmelidir. Kural listesinin düzenli tutulması, hem güvenlik hem de yönetilebilirlik açısından önemlidir.

Penetration testing: Erişim kontrollerinin gerçekten etkili olup olmadığını anlamak için düzenli sızma testleri yapılmalıdır. Bu testler, yapılandırma dokümanlarında görünmeyen ama pratikte var olan açıkları ortaya çıkarabilir.

Monitoring ve logging: Flow log'lar, güvenlik duvarı reddetme kayıtları ve merkezi log yönetimi araçları ile sürekli izleme yapılmalıdır. Anormal trafik desenleri (örneğin beklenmedik portlara yapılan denemeler) erken uyarı sinyali olarak değerlendirilmelidir.

Güvenlik İçin En İyi Uygulamalar

Segmentasyon mimarisinin uzun vadede etkili kalması için bazı temel prensiplere uyulmalıdır.

Least privilege (en az yetki) prensibi: Her kaynak, görevini yerine getirmek için gereken minimum erişime sahip olmalıdır. Kurallar yazılırken "gerekirse açarız" yaklaşımı yerine "varsayılan olarak kapalı, sadece gerekeni aç" yaklaşımı benimsenmelidir.

Dokümantasyon: Hangi subnet'in hangi amaçla kullanıldığı, hangi kuralın neden tanımlandığı belgelenmelidir. Bu, hem denetimlerde hem de ekip değişikliklerinde sürekliliği sağlar.

Düzenli denetim ve güncelleme: İş gereksinimleri değiştikçe segmentasyon kuralları da güncellenmelidir. Kullanılmayan kurallar birikmeye bırakılmamalı, periyodik gözden geçirme takvimi oluşturulmalıdır.

Felaket kurtarma planlaması: Segmentasyon mimarisi, yedekleme ve felaket kurtarma stratejisiyle uyumlu olmalıdır. Örneğin farklı bölgelerde (region) çalışan yedek ortamların da aynı segmentasyon prensiplerine göre yapılandırılmış olması, kurtarma sürecinde güvenlik açığı oluşmasını önler.

Sonuç olarak, bulut ortamında sanal ağ segmentasyonu tek seferlik bir kurulum değil, sürekli gözden geçirilmesi gereken yaşayan bir güvenlik pratiğidir. Doğru planlama, dar kapsamlı kurallar ve düzenli test/denetim döngüsüyle hem güvenlik hem performans açısından sağlam bir bulut altyapısı kurulabilir.