1. Ağ Segmentasyonu Nedir?
Ağ segmentasyonu; altyapıyı “mantıksal bölgelere” ayırıp her bölge arasında kontrollü ve minimum erişim kurmaktır. Bu sayede bir servis ele geçirilse bile saldırganın diğer servislere geçmesi zorlaşır. Segmentasyon, hem on-prem VLAN’larla hem bulutta security group/network ACL gibi kontrollerle uygulanabilir; mantık aynıdır: default deny, ihtiyaç kadar izin.
Ağ segmentasyonu ve DMZ nedir, neden önemlidir?
Ağ segmentasyonu, sistemleri web/app/DB gibi katmanlara ayırıp aralarındaki erişimi sınırlandırmaktır. DMZ ise internete açık web katmanının “tampon bölge” olarak konumlandırıldığı, iç ağdan ayrılmış segmenttir. Önemlidir çünkü düz ağda bir noktadan sızan saldırgan tüm altyapıya yayılabilir; segmentasyon bu yayılımı zorlaştırır ve etki alanını küçültür.
“Düz ağ”ın gerçek maliyeti
- •Tek hata noktası: bir servis düştü mü tüm ağ etkilenir
- •Kontrolsüz port açma alışkanlığı kalıcılaşır
- •Audit ve KVKK teknik tedbirlerinde “kim neye erişti?” kanıtı zayıflar
- •Olay sonrası kök neden analizi zorlaşır
☑ Mini Check: Düz ağ sinyalleri
- •Web sunucusu DB’ye doğrudan erişiyor mu?
- •Yönetim erişimi (SSH/RDP) her segmentte açık mı?
- •Monitoring/yedekleme trafiği prod ile aynı ağda mı?
- •“Geçici” açılan kurallar kapanmıyor mu?
- •Segmentler arası izin listesi kimse tarafından sahiplenilmiyor mu?
Ne yapmalıyım?
- • Önce katmanları tanımla: DMZ(web) → app → DB → yönetim → yedek/monitor.
- • Default deny ile başla; sadece gerekli portları aç.
- • “Geçici kural” için kapanış tarihi zorunlu kıl.
- • Log/izleme trafiğini ayrı segmentte tasarla (Internal link: /tr/veri-analiz-ve-raporlama).
2. DMZ Katmanı ile Web Sunucularını İzole Etmek
DMZ, internete açık web katmanını iç ağdan ayıran tampon bölgedir. Amaç; web katmanı ele geçirilse bile iç ağın (app/DB/PMS) doğrudan erişilebilir olmamasıdır. DMZ tasarımının en kritik kuralı: DMZ’den iç ağa erişim minimum ve açıkça gerekçeli olmalıdır.
DMZ’de tipik bileşenler
- •Reverse proxy / load balancer
- •Web sunucuları (statik içerik, edge cache)
- •WAF/CDN terminasyonu (mimariden bağımsız)
DMZ’de DB veya PMS gibi kritik sistemler tutulmaz.
Yönetim erişimi DMZ üzerinden değil “yönetim segmentinden” olmalı
DMZ’deki sunucuya yönetim erişimi; mümkünse bastion/SSM gibi tek noktadan ve kayıtlı olmalıdır (bu konu IAM yazınızla uyumludur). Bu, SSH/RDP yüzeyini küçültür.
☑ Mini Check: DMZ doğrulama
- •DMZ ile iç ağ ayrımı net mi?
- •DMZ’den DB’ye doğrudan erişim kapalı mı?
- •Yönetim erişimi DMZ üzerinden değil yönetim segmentinden mi?
- •WAF/CDN politikaları DMZ tasarımıyla uyumlu mu?
- •DMZ’de “minimum servis” yaklaşımı var mı?
Ne yapmalıyım?
- • Web katmanını DMZ’ye al; app ve DB’yi iç segmente taşı.
- • DMZ→iç ağ kurallarını “sadece app portları” ile sınırla.
- • Yönetim erişimini ayrı segmente al ve oturumları logla.
- • DMZ’de gereksiz servisleri kapat (attack surface küçült).
3. Web–App–DB Katmanlı Mimari
Segmentasyonun pratik hali, tier’lı mimaridir: web yalnız web işi yapar, app iş mantığını taşır, DB en içte kalır. Böylece web ele geçirilse bile DB’ye “tek atım” yoktur.
Web, uygulama ve veritabanı katmanlarını nasıl ayırmalıyım?
Web katmanı DMZ’de internete açık olur; yalnız uygulama katmanına gerekli portlardan konuşur. Uygulama katmanı iç segmentte, DB’ye sadece gerekli DB portlarından erişir. DB katmanı en iç segmentte kalır; web’den doğrudan erişim kapalıdır. Yönetim, yedekleme ve monitoring erişimleri ayrıca ayrılmış ağlardan yapılır.
“Web sunucularını doğrudan DB’ye değil app katmanına konuşturmak”
Bu, lateral movement’i azaltan temel kuraldır. App katmanı; auth, rate limit, input doğrulama ve audit gibi kontrollerin merkezi olabilir. DB’ye giden trafik; daha az noktadan geçer ve daha iyi izlenir.
Otel özel notu — PMS/rezervasyon sistemi nerede durmalı?
PMS/rezervasyon çekirdeği, DMZ dışında güvenli iç segmentte olmalıdır. Web DMZ, app katmanı üzerinden PMS ile konuşur; doğrudan erişim kapatılır. Bu hem erişim yüzeyini hem de KVKK riskini azaltır.
☑ Mini Check: Tier’lı mimari
- •Web→DB doğrudan kapalı
- •Web→App erişimi sınırlı portlarla
- •App→DB erişimi tek yön ve minimal
- •DB dış dünyaya kapalı
- •PMS/rezervasyon iç segmentte
Ne yapmalıyım?
- • Önce akışları çiz: web→app→DB ve web/app→PMS.
- • DB’yi en iç segmente al; inbound’u minimuma indir.
- • Uygulama katmanını “kontrol noktası” yap (auth, rate limit).
- • Segmentler arası kuralları dokümante et ve sahip ata.
4. Güvenlik Grupları ve VLAN’lar
Segmentasyonun “mekaniği” SG/VLAN gibi kontrollerdir. Burada hedef; kuralları basit, denetlenebilir ve zaman içinde “delik deşik” olmayacak şekilde tasarlamaktır.
SG/VLAN kural tasarımında 4 prensip
- Default deny
- Least privilege (sadece gerekli port + sadece gerekli kaynak)
- Kural sahipliği (owner) ve gerekçe
- “Geçici kural” için kapanış tarihi
Yönetim, yedekleme ve monitoring ağlarını ayırmak
Sadece web/app/DB değil; yönetim (admin), yedekleme (backup) ve monitoring (observability) ağları da ayrılmalıdır. Böylece gereksiz cross-segment erişimler azalır. Sheet’teki teknik notla uyumlu olarak; izleme ve loglama trafiği /tr/veri-analiz-ve-raporlama ve /tr/raporlama/kvkk-veri-guvenligi ile uyumlu kurgulanmalı; log erişimleri ve saklama politikaları net olmalıdır.
☑ Mini Check: Kural hijyeni
- •Kurallarda owner ve gerekçe var
- •Geçici kurallarda kapanış tarihi var
- •Yönetim ağı ayrı ve kayıtlı erişim var
- •Backup/monitoring ağları ayrı
- •Segmentler arası izinler periyodik gözden geçiriliyor
Ne yapmalıyım?
- • SG/VLAN kurallarını “akış diyagramı”na göre üret.
- • Yönetim ağını ayır ve oturumları logla.
- • Backup/monitoring trafiğini prod’dan izole et.
- • 6–12 ayda bir “kural temizlik” çalışması yap.
5. Otel ve B2B İçin Örnek Segmentasyon Diyagramları
Bu bölüm, örnek topolojiyle “nasıl görünür?” sorusunu kapatır. Amaç; otel PMS/rezervasyon ve B2B portal/API/DB bileşenlerini doğru katmanda konumlandırmaktır.
Otel örneği (DMZ + PMS güvenli katman)
- •DMZ: web + reverse proxy/WAF terminasyonu
- •App segment: rezervasyon mantığı, entegrasyon servisleri
- •DB segment: uygulama DB
- •PMS segment (iç): PMS/rezervasyon çekirdeği (DMZ dışı)
- •Mgmt/Monitoring/Backup: ayrı ağlar
B2B örneği (portal–API–DB segmentasyonu)
- •DMZ: portal UI, edge katmanı
- •App/API segment: API gateway + servisler
- •DB segment: ana veritabanları
- •Mgmt/Monitoring/Backup segmentleri: ayrı
Otel PMS ve rezervasyon sistemi hangi segmentte olmalı?
PMS ve rezervasyon çekirdeği DMZ’de olmamalı; iç segmentte, yalnız uygulama katmanından kontrollü erişimle çalışmalıdır. Web katmanı sadece app katmanına konuşmalı, PMS/DB’ye doğrudan erişmemelidir. Bu model, ihlal anında yayılımı ve KVKK riskini azaltır.
Fark yaratan mini bölüm (Competitor Gap): “Geçici portlar kalıcılaşmasın”
Segmentasyon zamanla bozulur; yeni servis ve entegrasyonlarda “geçici” port açılır ve unutulur. Bu yüzden kural yönetimi; kapanış tarihi, owner ve periyodik gözden geçirme ile işletilmelidir. (Notes alanıyla uyumlu)
☑ Mini Check: Segmentasyon sürdürülebilirliği
- •Segment diyagramı güncel
- •Yeni servis eklenince kural review yapılıyor
- •Geçici portlar kapanıyor
- •Log/izleme trafiği segmentlere göre kontrol ediliyor
- •KVKK uyum: erişim logları saklama/erişim politikası net
Ne yapmalıyım?
- • “Altın topoloji” diyagramı çıkar ve değişiklikte güncelle.
- • Kural değişikliklerini PR/review benzeri süreçle yönet (IaC uyumlu).
- • Geçici kuralları otomatik takip et ve kapat.
- • KVKK uyum hizmetiyle erişim loglarını teknik tedbir olarak konumlandır (Internal link: /tr/yazilim/kvkk-uyum-hizmeti).
6. İçerik İçi Tablo: Örnek Güvenlik Grubu Kuralları
| Kaynak segment | Hedef segment | Port/Protokol | Amaç | Not |
|---|---|---|---|---|
| Internet | DMZ (Web) | 80/443 | Kullanıcı trafiği | WAF/CDN terminasyonu olabilir |
| DMZ (Web) | App | Uygulama portu (örn. 443/8443) | İş mantığı | Sadece gerekli |
| App | DB | DB portu (örn. 5432/3306) | Veri erişimi | DB inbound minimal |
| Mgmt | DMZ/App/DB | Yönetim portları (kontrollü) | Admin erişim | Bastion/SSM önerilir |
| Monitoring | Tüm segmentler | Agent/metric portları | İzleme | Gereksiz çapraz erişim yok |
| Backup | DB/App | Backup portları/işlemleri | Yedekleme | Ayrı ağ ve yetki |
Varsayım: Portlar kullanılan teknolojiye göre değişir; tablo “akış mantığı”nı örnekler.
7. Web/App/DB Katmanlı Ağ Segmentasyonu Planlama Şablonunu İndir
Web/App/DB Katmanlı Ağ Segmentasyonu Planlama Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu şablon; DMZ, web/app/DB ve yönetim-yedekleme-izleme ağlarını segmentlere ayırıp SG/VLAN kurallarını sürdürülebilir şekilde tasarlamak için hazırlanmıştır. “Geçici portların kalıcılaşması” riskini owner + kapanış tarihi kuralıyla azaltır. KVKK teknik tedbirleri açısından erişim loglarının doğru saklanmasını da kapsar.
Kim Kullanır?
Ağ yöneticisi, sistem yöneticisi, DevOps/BT lideri (otel/B2B).
Nasıl Kullanılır?
- Segmentleri ve varlık envanterini doldur.
- Segmentler arası izin matrisi çıkar ve default-deny ile başla.
- Kural sahipliği + kapanış tarihi + periyodik gözden geçirme takvimini ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Web DMZ’de, DB iç segmentte
- ▢ ✅ Web→DB direkt kapalı
- ▢ ✅ Mgmt/backup/monitoring ayrı ağ
- ▢ ✅ Kurallarda owner + gerekçe + kapanış tarihi
- ▢ ✅ Periyodik kural temizlik planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5) Kontrol listesi
- •Web DMZ’de, DB iç segmentte
- •Web→DB direkt kapalı
- •Mgmt/backup/monitoring ayrı ağ
- •Kurallarda owner + gerekçe + kapanış tarihi
- •Periyodik kural temizlik planı var
Bir Sonraki Adım
Düz ağdan DMZ ve web–app–DB katmanlı mimariye geçip saldırının yayılmasını zorlaştırmak isteyen otel ve B2B altyapı ekipleri için.
Sık Sorulan Sorular
Ağ segmentasyonu ve DMZ nedir, neden önemlidir?▾
Web, uygulama ve veritabanı katmanlarını nasıl ayırmalıyım?▾
Otel PMS ve rezervasyon sistemi hangi segmentte olmalı?▾
B2B portaller için örnek ağ segmentasyonu nasıl görünür?▾
Segmentler arası kurallar neden zamanla bozulur?▾
İlgili İçerikler