OT DMZ Nasıl Tasarlanır? Hangi Sunucu Nereye Yerleştirilir?

ERP raporu historian’dan veri çekemediği için birisi IT’den OT’ye “geçici” bir kural açar; aylar sonra o kural hâlâ oradadır. OT DMZ, kurumsal ağ (Seviye 4–5) ile üretim ağı (Seviye 0–3) arasındaki, Purdue modelinde Seviye 3.5 diye anılan ara katmandır ve tam olarak bu tür kısa yolları kapatmak için vardır. İşi iki ağı birbirine bağlamak değil, aralarındaki her veri alışverişini bir aracı sunucuda sonlandırmaktır. Aşağıda hangi sunucunun DMZ’ye gireceğini, akışı hangi tarafın başlatacağını ve kural tabanının nasıl yazılıp denetleneceğini, sıfırdan DMZ kuran ya da mevcut DMZ’yi elden geçiren IT/OT ekipleri için sahadaki sırasıyla anlatıyoruz.

OT DMZ’nin amacı ve doğrudan oturum yasağı

Kural tek cümledir: IT ağındaki bir sistem ile OT ağındaki bir sistem arasında doğrudan TCP/UDP oturumu kurulmaz. Her akış DMZ’deki bir sunucuda biter; karşı taraf veriyi o sunucudan ayrı bir oturumla alır. ERP üretim verisi istiyorsa OT historian’ına değil, DMZ’deki historian replikasına bağlanır. Mühendis evden PLC projesine erişecekse önce DMZ’deki jump host’a, oradan ayrı bir oturumla OT’deki mühendislik istasyonuna geçer. İstisnası yok.

Pratikte bunun anlamı şu: firewall kural tabanında “kaynak IT, hedef OT” biçiminde tek bir izin satırı bile bulunmaz. Mevcut bir DMZ’yi denetlerken ilk baktığımız yer burasıdır; sahada en sık gördüğümüz bulgu da devreye alma sırasında açılıp unutulmuş bu tür bir satırdır. Purdue seviyelerinin genel çerçevesi için Purdue modeli ile IT/OT ağ ayrımı yazısına bakabilirsiniz; burada yalnız 3.5 katmanının iç tasarımı var.

İkinci kural akış yönüdür. OT içinden DMZ’ye doğru başlatılan (push) akışlar, DMZ’den OT’ye doğru başlatılanlara (pull) tercih edilir. Böylece OT tarafındaki firewall’da gelen bağlantı kuralı sayısı en aza iner ve DMZ’deki bir sunucu ele geçirilse bile OT’ye yeni oturum açma yetkisi dar kalır. Gelen kural az olsun.

Tek firewall ve çift firewall modelleri

DMZ iki topolojiyle kurulur. Tek firewall modelinde üç bacaklı bir cihazın bir arayüzü IT’ye, biri DMZ’ye, biri OT’ye bakar. Çift firewall modelinde IT–DMZ ve DMZ–OT sınırlarında ayrı cihazlar durur ve çoğu zaman farklı ekipler yönetir.

Ölçüt	Tek firewall (üç bacak)	Çift firewall
Maliyet ve işletme	Düşük, tek kural tabanı	Daha yüksek, iki kural tabanı
Tek hata noktası	Bir yapılandırma hatası iki sınırı birden açabilir	Bir cihazdaki hata tek sınırı etkiler
Yönetim ayrımı	IT ve OT aynı cihazı yönetir	IT dış, OT iç firewall’u yönetebilir
Uygun olduğu yer	Küçük–orta tesis, sınırlı akış sayısı	Kritik süreç, çok sayıda akış, ayrı OT ekibi

Tek firewall modelinde riskin büyük kısmı kural yazımındadır. IT ve OT arayüzleri arasında “any” içeren tek bir satır DMZ’yi işlevsiz bırakır. Bu modeli seçtiyseniz IT→OT ve OT→IT arayüz çiftleri için açık bir “deny all” kuralını en üste koyun ve loglayın; sonradan eklenen bir kural yanlışlıkla üste yazılırsa log bunu hemen gösterir. Çift firewall modelinde bazı kurumlar iki cihazı farklı üreticilerden seçer. Aynı zafiyetin iki sınırı birden etkilemesi zorlaşır, ama iki ayrı arayüzde uzmanlık gerekir. Seçimi cihaz markası değil, beklenen kural sayısı ve değişiklik sıklığı belirler.

DMZ’de yer alacak sunucular ve rolleri

DMZ’ye yalnız aracılık yapan sunucular girer. Kontrol işlevi olan hiçbir sistem (SCADA sunucusu, mühendislik istasyonu, OT domain controller) DMZ’de durmaz. Tipik bileşenler:

• Historian replikası: OT historian’ındaki verinin salt okunur kopyası. Raporlama, MES/ERP ve analitik kullanıcıları buna bağlanır, asla OT’dekine.
• Yama dağıtım sunucusu: Microsoft ortamlarında IT’deki WSUS’tan senkronize olan bir WSUS replikası; OT’deki alt WSUS güncellemeyi bu sunucudan çeker. Onay yetkisi OT ekibinde kalır.
• Antivirüs/EDR imza aracısı: İmza ve politika güncellemelerini IT konsolundan alıp OT ajanlarına aktaran relay sunucusu.
• Uzak erişim aracısı (jump host / RD Gateway): Tüm etkileşimli erişimin geçtiği tek nokta. MFA zorunlu, oturum kaydı açık.
• Dosya aktarım sunucusu: PLC projeleri, reçeteler ve kurulum dosyaları için SFTP tabanlı ara depo; dosya OT’ye geçmeden önce zararlı yazılım taramasından geçer.
• Zaman kaynağı aracısı: OT kurumsal NTP’ye doğrudan bağlanmasın diye DMZ’de bir NTP sunucusu ya da GPS tabanlı yerel kaynak.

DMZ sunucusu tek ağ kartıyla, yalnız DMZ segmentinde durur. İki kartla hem DMZ’ye hem OT’ye bağlanan (dual-homed) bir sunucu firewall’u tamamen atlar; envanter taramasında ilk aradığımız şeylerden biri budur, çünkü “hızlı çözüm” diye ikinci kart takılmış sunucu sahada hiç az değildir. DMZ’yi tek düz VLAN yerine role göre alt segmentlere bölmek de değerlidir: veri sunucuları, uzak erişim ve dosya aktarımı ayrı segmentte olursa, ele geçirilen jump host historian replikasına doğrudan yol bulamaz.

Historian replikasyonu ve veri akış yönü

Historian, DMZ’de en çok trafik üreten bileşendir ve akış yönü burada belirleyicidir. Doğru yapı, OT’deki historian’ın veriyi DMZ’deki replikaya göndermesidir; replika OT’ye bağlantı başlatmaz. Pek çok ticari historian bu iş için sunucudan sunucuya replikasyon arayüzü sunar. Port ve yönü tahmin etmeyin, üreticinin dokümanından doğrulayın. Historian seçimi ve zaman serisi veritabanları için üretim historian’ı seçimi yazısı ayrıca yol gösterir.

Replikasyonda kontrol edilecekler:

• Replika salt okunur olmalı; IT kullanıcılarının yazdığı etiket veya not OT historian’ına geri dönmemeli.
• Bağlantı koptuğunda OT tarafında tamponlama (store-and-forward) olmalı. Yoksa DMZ’deki her bakım, historian’da delik bırakır.
• Replikaya aktarılacak etiketler tek tek seçilmeli; reçete, güvenlik sistemi ve proses alarm verisinin IT’de görünmesi her zaman gerekmez.

Tek yönlü akışın donanımla zorlanması gereken kritik süreçlerde firewall yerine veri diyotu değerlendirilebilir; karşılaştırma veri diyotu ve unidirectional gateway yazısında.

Örnek akış ve kural tablosu

Aşağıdaki tablo tipik bir DMZ için başlangıç kural kümesidir. Portlar örnektir; kendi ürününüzün varsayılanını ve yapılandırmasını esas alın. Her satırda akışı başlatan taraf “kaynak” sütunundadır.

Kaynak	Hedef	Hizmet	Amaç
OT historian	DMZ historian replikası	Üreticiye özgü TCP	Veri replikasyonu (push)
IT raporlama, MES	DMZ historian replikası	Üreticiye özgü TCP veya HTTPS	Okuma
DMZ WSUS	IT WSUS	TCP 8530/8531	Upstream senkronizasyon
OT WSUS (alt sunucu)	DMZ WSUS	TCP 8530/8531	Onaylı güncellemeleri çekme
IT kullanıcıları (VPN, MFA)	DMZ RD Gateway	TCP 443	Uzak erişim girişi
DMZ RD Gateway	OT mühendislik istasyonu	TCP 3389	Yetkili hedefe oturum
OT dosya istemcisi	DMZ SFTP	TCP 22	Taranmış dosyayı çekme
OT sunucuları	DMZ NTP	UDP 123	Zaman senkronizasyonu
IT ↔ OT	—	Tümü	Açık “deny” ve log

Tablodaki tek DMZ→OT satırı, RD Gateway’den mühendislik istasyonlarına giden RDP’dir. Bu kuralı hedef bazında daraltın: tüm OT alt ağı değil, belirli istasyonlar. RD Gateway’de kaynak kullanıcı–hedef eşlemesi (ör. RD Gateway kaynak yetkilendirme politikası) tanımlayın ve oturumları kayda alın. WSUS 8530/8531, Windows Server 2012 ve sonrasında varsayılan HTTP/HTTPS portlarıdır; farklı port yapılandırdıysanız kuralı ona göre yazın. Kural açıldıktan sonra mutlaka DMZ dışından deneyip reddedildiğini logda görün.

DMZ’de sık yapılan tasarım hataları

• “Geçici” geçiş kuralları: Devreye alma sırasında açılan IT→OT kuralı kapanmaz. Her kurala bir sahip ve bitiş tarihi yazın, süresi dolanları periyodik olarak temizleyin.
• Protokolün DMZ’den “geçirilmesi”: OPC Classic (DCOM) ya da veritabanı bağlantısını DMZ’deki bir port yönlendirmesiyle OT’ye taşımak, sonlandırma kuralını deler. Aracı uygulama veriyi alıp yeniden sunmalıdır.
• Ortak yönetim ağı: DMZ sunucuları ve OT cihazları IT’deki aynı yönetim VLAN’ından erişilebiliyorsa firewall yan yoldan aşılmıştır. Kural tabanı temiz görünür, ağ değildir.
• DMZ’den internete serbest çıkış: DMZ sunucularının internet erişimi yalnız gerekli güncelleme kaynaklarıyla sınırlanmalı, tercihen IT’deki proxy üzerinden gitmelidir.
• Loglanmayan sınır: DMZ firewall logları merkezi izlemeye gitmiyorsa, “deny” kuralına takılan denemeleri kimse görmez.
• Yedeklerin OT’de tutulması: DMZ sunucularının yedeği OT ağına alınırsa DMZ ile OT arasında gereksiz geniş bir kanal açılır. Yedek akışını ayrıca tasarlayın.

Tasarım kontrol listesi

• Kural tabanında IT ile OT arasında doğrudan izin satırı yok; açık “deny” kuralı loglanıyor.
• Her akış için kaynak, hedef, port, başlatan taraf, sahip ve gerekçe belgelenmiş.
• DMZ sunucuları tek ağ kartlı; IT domain’ine üye değil.
• DMZ, role göre alt segmentlere ayrılmış (veri, uzak erişim, dosya aktarımı).
• Historian replikası salt okunur; OT tarafında tamponlama var.
• Uzak erişim MFA ile korunuyor, oturumlar kaydediliyor, hedefler kullanıcı bazında kısıtlı.
• Dosya aktarımı tarama adımı olmadan OT’ye ulaşamıyor.
• Yama ve imza güncellemeleri DMZ aracısı üzerinden, OT ekibinin onayıyla dağıtılıyor.
• Firewall ve sunucu logları merkezi izlemeye gidiyor; yönetim erişimi ayrı bir ağdan yapılıyor.
• Geçici kurallar için bitiş tarihi ve periyodik gözden geçirme takvimi var.

DMZ, IT/OT segmentasyonunun yalnız bir parçasıdır; kurumsal tarafta ayrımın nasıl kurgulandığı üretim tesislerinde IT/OT segmentasyonu rehberinde. Mimari çerçeve için NIST’in SP 800-82 Rev. 3 OT güvenliği kılavuzu birincil kaynaktır. Mevcut akışların envanterini çıkarıp DMZ’ye taşıma planı yapacaksanız OT siber güvenlik ve segmentasyon ile IT/OT entegrasyon danışmanlığı sayfalarımızda bu işi nasıl yürüttüğümüzü görebilirsiniz.

Sık sorulan sorular

OT DMZ için ayrı bir firewall almak zorunlu mu?

Zorunlu değil. Üç bacaklı tek bir firewall ile de DMZ kurulur. Ama bu modelde tek bir hatalı kural iki sınırı birden açar; bu yüzden IT ile OT arayüzleri arasında açık ve loglanan bir deny kuralı ve düzenli kural denetimi şarttır. Kritik süreçlerde ve ayrı OT ekibi olan tesislerde çift firewall, yönetim ayrımını daha temiz sağlar.

MES sunucusu DMZ’de mi durmalı, OT’de mi?

MES’in proses ekipmanıyla doğrudan konuşan ve üretimin sürmesi için gereken bileşenleri Seviye 3’te, yani OT tarafında kalır. ERP ve kurumsal kullanıcılarla etkileşen raporlama veya entegrasyon katmanı ise veriyi DMZ’deki aracı sunucular üzerinden alıp verir. Ölçüt basit: bağlantı kesildiğinde üretim duruyorsa bileşen OT’dedir.

DMZ’deki jump host’tan PLC’ye doğrudan bağlanmak doğru mu?

Doğru değil. Jump host, OT’deki yetkili bir mühendislik istasyonuna oturum açmak için kullanılır; PLC’ye erişim o istasyondaki mühendislik yazılımıyla yapılır. Böylece PLC protokolleri DMZ’ye taşınmaz ve mühendislik araçları tek, kontrollü bir noktada kalır.

Bulut tabanlı bir izleme servisi OT verisine nasıl erişmeli?

Bulut servisi OT’ye bağlanmaz. Veri OT’den DMZ’deki bir aracıya gönderilir; bulut yalnız bu aracıdan ya da aracının dışarıya doğru başlattığı bağlantıdan veri alır. Böylece internetten OT yönüne tek bir giriş kuralı gerekmez.