Tipik Başlangıç Durumu
Üretim ağı, ofis kullanıcıları, IP kameralar, misafir ağı ve uzaktan erişim aynı güvenlik alanında büyümüş olabilir. Bu yapı hem görünürlüğü azaltabilir hem de bir güvenlik olayında etki alanını genişletebilir.
Teknik Çözüm Yaklaşımı
Mevcut topoloji, kritik üretim cihazları, internet hatları, VPN bağlantıları ve erişim gereksinimleri analiz edilir. Yeni firewall kapasitesi belirlenir; VLAN ve güvenlik bölgeleri oluşturulur; NAT/VPN politikaları kontrollü biçimde taşınır ve gerekli güvenlik servisleri etkinleştirilir.
Proje Kapsamındaki Teknik Bileşenler
- Üretim / ofis / misafir / IP kamera VLAN ayrımı
- NGFW üzerinde bölge bazlı firewall politikaları
- Site-to-site ve remote-access VPN
- MFA ve kontrollü yönetim erişimi
- EDR/XDR ile uç nokta güvenliği
- Değişiklik öncesi ve sonrası yapılandırma dokümantasyonu
Bu Mimari Ne Sağlamayı Amaçlar?
Amaç; ağ görünürlüğünü artırmak, gereksiz erişimleri azaltmak, uzaktan erişimi kontrollü hale getirmek ve olay anında etki alanını sınırlandırabilecek daha katmanlı bir yapı oluşturmaktır.
İlgili Hizmet ve Çözümler
Mimari ve çalışma modeli
Üretim segmentasyonu için firewall kuralı, gözlenen ve doğrulanan iletişim matrisinin uygulamasıdır. Kaynak/hedef adresi yanında başlatan taraf, protokol, port, oturum davranışı ve üretim gerekçesi kaydedilir. Dinamik adres, multicast veya üreticiye özel protokol varsa basit statik port listesinin yeterli olup olmadığı sınanır. Gözlemde görünmeyen vardiya, bakım ve ürün geçişi akışları unutulmamalıdır.
Politika önce küçük bir hücrede kontrollü uygulanır. Varsayılan kapalı yaklaşım için zorunlu trafik ve geri dönüş yöntemi hazır olmalıdır. Stateful oturum kontrolü ve bazı protokol incelemeleri cihaz davranışını etkileyebilir; gecikme, paket kaybı ve üretici desteği test edilir. Güvenlik fonksiyonunu açmak, fiziksel prosesin doğru çalıştığına dair kanıt değildir.
Kuralların açıklaması, sahibi ve gözden geçirme tarihi tutulur. Yönetim servisleri ve tedarikçi bakımı üretim veri akışından ayrı kapsamlanır. Geniş geçici istisna teslimden sonra kalıcılaşmamalıdır; değişiklik kayıtlarıyla kapatılmalıdır.
- 1Gerçek iletişim matrisi
- 2Pilot hücre politikası
- 3Üretim ve engelleme testi
- 4Sahipli kural yaşam döngüsü
Tasarım parametreleri
- Kuralın üretim gerekçesi
- Her kuralın sahibi, başlatan yönü, normal/bakım kapsamı ve gözden geçirme tarihini kaydedin.
- Pilot ve rollback
- Küçük hücrede izin/engel ve gecikmeyi test edin; rollback adımını üretim penceresinde hazırlayın.
- Üretim bağımlılığı
- PLC, SCADA, HMI, MES, ERP, kimlik ve zaman ilişkilerini kaydedin. Teknik olarak açılan sistem, üretimin güvenle başlayabildiğini kanıtlamaz.
- Bölge ve iletişim
- Gerekli kaynak/hedef, protokol ve yönü gerçek üretim akışından çıkarın. Yönetim, kullanıcı ve kontrol trafiğini ayırın.
- Bakım ve emniyet
- Tarama, güncelleme ve arıza testini üretim sahibiyle koordine edin. Cihaz desteği ve emniyet koşulları geçiş sırasını etkiler.
- Kurtarma erişimi
- Program, reçete, yapılandırma, lisans ve donanım bağımlılıklarını ayrı yedekleyin. Teknik ve operasyonel kabul sahiplerini belirleyin.
Hesap ve uygulama örneği
Bir MES sunucusu iki hücredeki veri toplama servislerine erişsin. Önce hangi tarafın bağlantı başlattığını doğrulayın; gerekçesiz iki yönlü tüm-port izin yazmayın. Pilot hücrede üretim kaydı, reçete geçişi ve bakım oturumunu test edin. Aynı anda ofis VLAN’ından kontrol ağına izinsiz erişim denemesinin reddedildiğini kayda alın. Sonra ikinci hücreye aynı kuralı körlemesine kopyalamadan farkları kontrol edin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Politika normal çalışıyor, ürün geçişi duruyor | Yalnız değişimde kullanılan akış gözlemde kaçmış olabilir. | Vardiya, ürün değişimi ve bakım akışını ayrı senaryolarla doğrulayın. |
| BT sistemleri açıldı ama üretim başlamıyor | Reçete, kontrol programı, zaman veya saha bağlantısı eksik olabilir. | Üretim bağımlılık listesini gerçek hat başlangıç adımlarıyla karşılaştırın. |
| Yeni politika üretim iletişimini kesiyor | Protokol, yön veya cihaz davranışı yanlış modellenmiş olabilir. | Onaylı gözlem verisiyle akışı doğrulayın; üretim sahibinin kabulüyle kontrollü geri dönün. |
| Yedek mevcut ama saha sistemi açılamıyor | Donanım, sürüm, lisans veya program yükleme aracı bağımlılığı olabilir. | Temsilî yedek cihazda program ve reçete geri yükleme testini yapın. |
Kabul ve doğrulama kontrolleri
- İzinli üretim akışının sürmesi ve izinsiz erişimin reddi aynı kabul testinde kanıtlanmalıdır.
- Geçiş planını üretim ve emniyet sorumlularıyla onaylı testte uygulayın.
- Zorunlu üretim akışlarının sürdüğünü uygulama ve saha üzerinden doğrulayın.
- Yetkisiz IT’den OT’ye erişimi kontrollü testle engelleyin.
- Üretimi geri açma sırasını sahip ve süre bilgisiyle kaydedin.
- Yedek, program, reçete ve lisans erişimini ana sistem olmadan sınayın.
İlgili kavramlar
IT/OT güvenlik bölgeleri
Bölge, benzer güvenlik ve işletim gereksinimlerini paylaşan varlık grubudur; bölgeler arasındaki iletişim kontrollü geçitlerden geçmelidir. OT cihazının erişilebilir olması, tarama veya güncelleme için güvenli olduğunu göstermez. Kontrol gecikmesi, emniyet, üretici desteği ve bakım penceresi kararları değiştirir. PLC ve SCADA iletişimini mevcut üretim akışından gözlemleyin; IT tarafındaki politikayı olduğu gibi aktarmayın. Uzaktan destek erişimine kimlik, süre, onay ve kayıt koşulları tanımlayın. Aktif test ve geçişleri üretim sorumlusuyla koordine edin.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Bu Senaryo Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
Bu örnek teknik senaryo, Doz Teknoloji'nin kurumsal IT ve altyapı projelerinde kullandığı değerlendirme başlıkları temel alınarak hazırlanmıştır.
Doz Teknoloji hakkındaTeknik Kriterler + Birincil Kaynaklar
Senaryo; OT/IT ayrımı, güvenlik bölgeleri, DMZ ve kontrollü iletişim ilkeleri açısından NIST ICS güvenlik rehberi ve CISA segmentasyon önerileriyle karşılaştırıldı.
Karar Kalitesini Artırmak
Gerçek müşteri vakası iddiası oluşturmadan, üretim ağında segmentasyon kararlarının nasıl düşünülmesi gerektiğini göstermek.
İçerik ve birincil kaynaklar yeniden kontrol edildi.
İlgili Sonraki Adımlar
Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Benzer Bir Altyapıyı Değerlendirmek İster misiniz?
Mevcut altyapınızı, kritik sistemlerinizi ve proje hedeflerinizi paylaşın; ihtiyaç analizi sonrasında uygun teknik kapsamı birlikte oluşturalım.