OT için Ayrı Active Directory: Ayrı Orman mı, IT Domain’i mi?

SCADA sunucuları, historian, mühendislik istasyonları ve operatör panelleri bir noktada merkezi kimlik doğrulama ister. Bu ihtiyaç çoğu tesiste en kısa yoldan çözülür: makineler kurumsal Active Directory domain’ine katılır. İş görür, ta ki IT’de bir domain yöneticisi hesabı ele geçirilene kadar. Aşağıda OT için üç kimlik seçeneğini (IT domain’ine katılım, ayrı OT ormanı, yerel hesaplar) karşılaştırıyor; ayrı orman tasarımında etki alanı denetleyicisi yerleşimini, DNS’i, zamanı, GPO kapsamını ve trust kararını anlatıyoruz. Kurumsal AD’nin sertleştirilmesi ayrı bir konu.

OT’de kimlik altyapısı seçenekleri

Üç temel model var. Tesislerin çoğu bunlardan birine, genellikle bilinçli bir karar vermeden, yerleşmiş durumda:

• IT domain’ine katılım: OT sistemleri kurumsal domain üyesidir; kullanıcılar kurumsal hesaplarıyla oturum açar, GPO’lar kurumsal yapıdan gelir.
• Ayrı OT ormanı: OT tarafında, Seviye 3’te kendi etki alanı denetleyicileri olan bağımsız bir Active Directory ormanı kurulur. IT ile ya hiç trust yoktur ya da sınırlı bir trust vardır.
• Yerel hesaplar (workgroup): Her sistem kendi yerel hesaplarıyla çalışır. Küçük kurulumlarda ve tek amaçlı panellerde yaygındır.

Doğru seçim; OT altyapısındaki Windows sistemi sayısına, SCADA üreticisinin desteklediği yapıya, OT ekibinin AD işletme yetkinliğine ve IT ile OT arasında DMZ olup olmadığına bağlıdır. Purdue seviyeleri ve IT/OT ayrımının genel mantığı için Purdue modeli ile IT/OT ağ ayrımı yazısına bakabilirsiniz.

IT domain’ine katılımın riskleri ve kolaylıkları

IT domain’ine katılım cazip görünür: tek hesap, tek parola, hazır yama ve antivirüs altyapısı, merkezi denetim. Bedeli şu: OT’nin güvenlik sınırı fiilen kurumsal domain’in sınırına kadar genişler.

Somut riskler:

• Kimlik ihlalinin taşınması: IT’de ele geçirilen bir domain yöneticisi hesabı OT sistemlerinde de yöneticidir. Fidye yazılımı operatörlerinin domain yöneticisi yetkisini aldıktan sonra GPO veya uzaktan yönetim araçlarıyla tüm domain üyelerine yayılması bilinen bir saldırı tekniğidir. Domain sınır tanımaz.
• Firewall’da geniş açıklık: OT’deki üye sunucuların IT’deki etki alanı denetleyicilerine ulaşması için Kerberos, LDAP, SMB ve RPC dinamik port aralığı dahil çok sayıda portun IT ile OT arasında açılması gerekir. Bu, DMZ’deki “doğrudan oturum yok” ilkesini bozar. Sahada IT–OT kural tabanında en sık gördüğümüz geniş izinler de bu ihtiyaçtan doğar.
• GPO etkisi: Kurumsal ekran kilidi, otomatik yeniden başlatma, yazılım dağıtımı veya güvenlik ajanı politikaları operatör panellerinde beklenmedik sonuçlar doğurur. Gece yarısı yeniden başlayan bir HMI, kimsenin planlamadığı bir duruştur.
• Bağımlılık: IT ağında veya WAN’da yaşanan bir kesinti, OT’de oturum açmayı ve bazı uygulamaların lisans/servis doğrulamasını etkileyebilir.

Kolaylıklar gerçek, ama ayrı bir ormanla da büyük ölçüde sağlanabilir. Mevcut bir domain katılımını sürdürmek ancak bilinçli bir risk kabulüyle ve sıkı telafi edici önlemlerle savunulabilir: ayrı OT yönetici hesapları, IT yöneticilerinin OT sistemlerinde oturum açmasının reddedilmesi, OT için ayrı OU ve GPO zinciri.

Ayrı OT ormanı tasarımı

Ayrı ormanın temel tasarım kararları:

• Orman ve domain adı: IT ormanıyla çakışmayan, kuruma ait tescilli bir alan adı altında bir ad seçin. IT domain’inin alt alanı gibi görünen bir ad (IT domain’i corp.ornek.com.tr iken ot.corp.ornek.com.tr) DNS’te karışıklığa ve yanlış yönlendirmeye yol açabilir; ayrı bir ad daha temizdir.
• Etki alanı denetleyicileri: En az iki DC, Seviye 3’te, farklı fiziksel sunucularda veya farklı sanallaştırma hostlarında. Aynı host üzerindeki iki DC, tek arıza noktasıdır. DC’ler DMZ’de durmaz. Büyük tesislerde her üretim alanına bir DC düşünülebilir; ama her DC ek bakım yükü demektir.
• Tek domain: OT ormanında birden fazla domain’e çoğu zaman ihtiyaç yoktur. Ayrım OU yapısı ve yetki devriyle yapılır.
• Yönetici modeli: OT ormanının yöneticileri ayrı hesaplar kullanır; bu hesaplar IT ormanında yoktur. Yönetim yalnız OT’deki yönetim istasyonlarından yapılır.
• Yedekleme: System State yedeği OT içindeki yedek altyapısına alınır. Yedeği IT domain’ine bağlı bir yedekleme sunucusunda tutmak ayrımı boşa çıkarır.

Yeni ormanın ilk DC’si PowerShell ile şöyle kurulabilir (ad ve NetBIOS adı örnektir):

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "otnet.ornek.com.tr" -DomainNetbiosName "OTNET" `
  -InstallDns -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM parolasi")

Orman ve domain işlev düzeyini seçmeden önce SCADA, historian ve mühendislik yazılımı üreticilerinin desteklediği işletim sistemi ve AD yapısını kontrol edin. Bazı üreticiler belirli bir kurulum sırası (önce DC, sonra uygulama sunucusu) veya özel servis hesabı yapısı ister. Bunu kurulumdan sonra öğrenmek, kurulumu iki kez yapmak demektir.

Trust kurmak ya da kurmamak

Ayrı orman kurulur kurulmaz ilk talep gelir: “IT kullanıcıları OT raporlarına kendi hesaplarıyla erişsin.” Trust kurmadan önce şu soruyu sorun: Bu erişim neden OT’ye uzanmak zorunda? Raporlama ihtiyacı çoğu zaman DMZ’deki historian replikası veya raporlama sunucusu üzerinden karşılanır ve o sunucu IT tarafından kendi kimlik altyapısıyla yönetilebilir. Bu yerleşimin ayrıntıları OT DMZ tasarımı yazısında.

Trust kaçınılmazsa şu sınırlar uygulanır:

• Yön: Trust yönü, hangi tarafın hesaplarının diğer taraftaki kaynaklara erişeceğini belirler. OT ormanı IT’ye güvenirse IT hesapları OT kaynaklarına erişebilir; tersi OT hesaplarına IT kaynaklarını açar. Gerçekten gereken yönü netleştirin ve yalnız o yönde tek yönlü trust kurun.
• Selective authentication: Trust, kaynak taraftaki her sunucuya otomatik erişim vermemeli; yalnız “Allowed to Authenticate” izni verilen sunuculara erişim mümkün olmalıdır.
• SID filtering: Orman trust’larında varsayılan olarak etkindir. Kapatılmaz.
• Ağ açıklığı: Trust için gereken portlar yalnız iki ormanın DC’leri arasında açılır; genel bir IT–OT izni olarak açılmaz.

Trust durumunu düzenli gözden geçirmek için Get-ADTrust -Filter * çıktısında yön (Direction), selective authentication ve SID filtering alanları kontrol edilir. Kurulduğu gün doğru olan trust, iki yıl sonra kimsenin hatırlamadığı bir istisnaya dönüşebilir.

DNS, zaman senkronizasyonu ve GPO kapsamı

DNS: OT ormanının DNS bölgeleri OT DC’lerinde, AD ile bütünleşik olarak tutulur. OT istemcileri yalnız OT DNS sunucularını kullanır. Çoğu OT sisteminin internet adı çözmesine gerek yoktur; gerekiyorsa DMZ’deki bir çözümleyiciye koşullu yönlendirme yapılır. IT adları gerekiyorsa yalnız ilgili bölge için koşullu yönlendirici tanımlanır. Sahada sık rastlanan hata: OT istemcilerinde ikincil DNS olarak IT’deki bir sunucunun bırakılması. Birincil yanıt vermediği anda istemci IT’ye gider.

Zaman: Kerberos, istemci ile DC arasındaki saat farkına duyarlıdır; varsayılan tolerans 5 dakikadır. Ayrıca alarm ve olay kayıtlarının sıralanabilmesi için tüm OT’nin tutarlı bir zaman kaynağına ihtiyacı vardır. Ormanın kök domain’indeki PDC emulator rolüne sahip DC, DMZ’deki NTP sunucusundan veya OT içindeki GPS tabanlı bir kaynaktan zaman alacak şekilde yapılandırılır:

w32tm /config /manualpeerlist:"10.20.0.5,0x8 10.20.0.6,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /query /status

Diğer DC’ler ve üye sunucular varsayılan domain hiyerarşisinden zaman alır. PLC’ler ve endüstriyel switch’ler gibi Windows dışı cihazlar da aynı OT NTP kaynağına yönlendirilir. Saatler kayarsa önce oturumlar düşer, sonra loglar anlamsızlaşır.

GPO kapsamı: Kurumsal güvenlik tabanını olduğu gibi kopyalamak yerine sistem rollerine göre ayrı OU’lar oluşturun: sunucular, mühendislik istasyonları, operatör panelleri, servis hesapları. Operatör panellerinde ekran kilidi ve otomatik yeniden başlatma proses ihtiyacına göre ayarlanır; Windows Update otomatik kurulum yerine OT’deki WSUS’a ve değişiklik penceresine bağlanır. Uygulama izin listeleme (AppLocker veya Windows Defender Application Control) OT’de IT’ye kıyasla daha uygulanabilirdir, çünkü yazılım envanteri durağandır.

Seçeneklerin karşılaştırma tablosu

Ölçüt	IT domain’i	Ayrı OT ormanı	Yerel hesaplar
IT ihlalinin OT’ye etkisi	Doğrudan	Sınırlı (trust yoksa yok)	Sınırlı
IT–OT firewall açıklığı	Geniş (AD portları)	Yok veya yalnız DC’ler arası	Yok
Merkezi yönetim	Var	Var	Yok
İşletme yükü	Düşük	Orta (DC bakımı, yedek)	Sistem sayısıyla artar
Uygun ölçek	Önerilmez	Orta ve büyük OT	Az sayıda sistem

OT ormanı kendi içinde kaldığı sürece AD portları için gereken firewall kuralları IT–OT sınırında değil, OT içindeki zonlar arasında yazılır: Kerberos (88), Kerberos parola değişimi (464), LDAP (389), LDAPS (636), Global Catalog (3268/3269), DNS (53), SMB (445), RPC endpoint mapper (135) ve RPC dinamik aralığı (Windows Server’da varsayılan 49152–65535). Ayrıntılı liste için Microsoft’un Active Directory Domain Services dokümantasyonu esas alınır. RPC dinamik aralığı geniştir; zonlar arası kuralda kaynak ve hedefi DC’lerle sınırlamak bu yüzden şarttır.

Geçiş adımları

IT domain’ine üye OT sistemlerini ayrı ormana taşımak, her sistemde domain değişikliği ve dolayısıyla yeniden başlatma demektir. Geçiş bu yüzden değişiklik penceresi disipliniyle planlanır (OT’de değişiklik penceresi mühendisliği).

1. Envanter: IT domain’ine üye tüm OT sistemlerini, kullandıkları servis hesaplarını ve bu hesapların hangi uygulamada tanımlı olduğunu çıkarın. Unutulan servis hesabı, taşımadan sonra duran servis olarak geri döner.
2. Üretici kontrolü: SCADA ve historian üreticilerinin domain değişikliği prosedürünü edinin; bazı uygulamalar servis hesabı veya sertifika değiştiğinde yeniden yapılandırma ister.
3. OT ormanını kurun: İki DC, DNS, zaman, OU ve GPO yapısı, yedekleme.
4. Servis hesaplarını yeniden oluşturun: Mümkünse gMSA (group Managed Service Account) kullanın; uygulama desteklemiyorsa güçlü parolalı ve yalnız gerekli haklara sahip hesaplar açın.
5. Pilot: Bir mühendislik istasyonu veya üretime etkisi düşük bir sunucuyla başlayın.
6. Hat hat taşıma: Her taşıma bir değişiklik penceresinde; uygulama işlevleri ve oturum açma testleri geçtikten sonra sıradaki sisteme geçin.
7. Kapatma: Tüm sistemler taşındıktan sonra IT–OT arasındaki AD portlarını kapatın, IT domain’inde kalan OT bilgisayar hesaplarını devre dışı bırakıp temizleyin. Portlar açık kalırsa geçiş yarım kalmış demektir.

Kurumsal tarafta yönetici hesaplarının katmanlandırılması OT ayrımını tamamlar; konu Active Directory tier modeli rehberinde işleniyor. OT kimlik mimarisini segmentasyonla birlikte planlamak için OT siber güvenlik ve segmentasyon ile IT/OT entegrasyon danışmanlığı sayfalarına bakabilirsiniz.

Sık sorulan sorular

Küçük bir tesiste ayrı OT ormanı aşırı bir yatırım mı?

Domain’e bağlı OT sistemi az ve kullanıcı sayısı birkaç kişiyle sınırlıysa, merkezi yönetilen yerel hesaplar ve sıkı parola yönetimi geçici olarak yeterli olabilir. SCADA istemcileri, historian ve mühendislik istasyonları çoğaldıkça yerel hesapların yönetimi zorlaşır; bu noktada iki etki alanı denetleyicili küçük bir OT ormanı genellikle daha yönetilebilir ve daha güvenlidir.

OT ormanı ile IT ormanı arasında trust kurmak tamamen yanlış mı?

Yanlış değil ama ayrımın getirdiği korumanın bir kısmını geri verir. Trust zorunluysa OT ormanının IT’ye güvendiği tek yönlü bir yapı kurulur, selective authentication ile yalnız seçili kaynaklara sınırlanır ve portlar yalnız ilgili etki alanı denetleyicileri arasında açılır. Çoğu senaryoda trust yerine DMZ’deki aracı sistemler ve ayrı OT hesapları daha temiz bir çözümdür.

OT etki alanı denetleyicisi DMZ’de durabilir mi?

Durmamalı. OT ormanının etki alanı denetleyicileri OT tarafında, Seviye 3’te bulunur. DMZ’deki sunucular OT ormanına üye yapılırsa DMZ’den OT etki alanı denetleyicilerine kimlik doğrulama trafiği açmak gerekir; bu da DMZ’nin amacını zayıflatır. DMZ için yerel hesaplar ya da ayrı ve küçük bir DMZ kimlik yapısı tercih edilir.

OT kullanıcıları IT’deki parolalarını OT’de de kullanabilir mi?

Parola senkronizasyon araçlarıyla teknik olarak mümkündür, önerilmez. Aynı parola iki ortamda geçerliyse IT’de çalınan kimlik bilgisi OT’de de çalışır. OT hesapları ayrı olmalı; çok faktörlü doğrulama en azından OT’ye giriş noktasında, yani DMZ’deki uzak erişim aracısında uygulanmalıdır.