Purdue modeli ile ISA-95 arasındaki fark, endüstriyel mimarideki en yaygın karışıklık noktalarından biridir; çünkü ikisi de 0'dan 4'e numaralandırılmış seviyeler kullanır ve ikisi de üst üste dizilmiş katmanlar olarak çizilir. Bu karşılaştırmada her modelin ne için tasarlandığını, seviyelerinin nasıl eşleştiğini, gerçekte nerelerde ayrıştıklarını ve MQTT ile unified namespace'in, Purdue tarzı ağların sağladığı güvenlik bölgelendirmesinden vazgeçmeden verinin seviyeler arasında hareket etme biçimini nasıl değiştirdiğini öğreneceksiniz.
Her Model Nereden Geliyor?
Purdue Kurumsal Referans Mimarisi (Purdue Enterprise Reference Architecture), 1990'ların başında Purdue Üniversitesi'nde bilgisayarla bütünleşik üretim için genel bir model olarak geliştirildi. Endüstriyel güvenlik dünyasında katmanlı bir ağ mimarisinin kısa adı haline geldi: en altta fiziksel proses, en üstte kurumsal BT ve aralarında kontrollü sınırlar. OT güvenlik programlarında referans olarak yaygın biçimde kullanılır ve ISA/IEC 62443'ün bölge ve kanal (zone and conduit) yaklaşımını etkilemiştir.
IEC 62264 olarak da yayımlanan ISA-95 bir entegrasyon standardıdır. Amacı, ERP gibi iş sistemlerinin ve MES gibi üretim operasyon sistemlerinin bilgi alışverişini nasıl yapacağını tanımlamaktır: üretim planları, malzeme tüketimi, ekipman kabiliyeti, kalite sonuçları. Nesne modelleri, faaliyet modelleri ve bir fonksiyonel hiyerarşi sunar; ayrıca kuruluş, saha, alan, iş merkezi ve iş biriminden oluşan rol tabanlı ekipman hiyerarşisini de tanımlar.
Kısacası: Purdue çoğunlukla "ağlar nasıl bölümlenmeli?" sorusunu yanıtlamak için kullanılırken ISA-95 "her seviyede hangi işlevler var ve iş tarafı ile operasyonlar arasında hangi bilgiler akıyor?" sorusunu yanıtlar.
Seviyeler Nasıl Eşleşiyor?
Seviye numaraları işe yarayacak kadar yakın, tartışmaya yol açacak kadar da gevşek biçimde eşleşir.
| Seviye | Purdue modeli (ağ görünümü) | ISA-95 fonksiyonel hiyerarşisi | Tipik sistemler |
|---|---|---|---|
| 5 | Kurumsal ağ | Ayrıca tanımlanmamış | Kurumsal BT, internete açık hizmetler |
| 4 | İş lojistiği | İş planlama ve lojistik | ERP, planlama, e-posta |
| 3.5 | Endüstriyel DMZ | Tanımlanmamış | Jump host'lar, yama sunucuları, veri broker'ları |
| 3 | Saha operasyonları | Üretim operasyonları yönetimi | MES, historian, saha SCADA sunucuları |
| 2 | Alan denetim kontrolü | İzleme ve denetim kontrolü | HMI, SCADA istemcileri, mühendislik istasyonları |
| 1 | Temel kontrol | Algılama ve müdahale | PLC'ler, DCS kontrolörleri, RTU'lar |
| 0 | Fiziksel proses | Fiziksel proses | Sensörler, aktüatörler, sürücüler |
Üç fark öne çıkar:
- Seviye 3.5 bir Purdue kavramıdır. ISA-95 ağları modellemediği için bir DMZ'ye sahip değildir. Güvenlik uzmanları, BT ile OT arasındaki doğrudan trafiği önlemek için saha operasyonları ile kurumsal ağlar arasına endüstriyel DMZ'yi eklemiştir.
- Seviye 5 pek çok Purdue diyagramında ayrı bir kurumsal veya internet katmanı olarak görünür. ISA-95 ise Seviye 4'te durur.
- ISA-95'in asıl katkısı Seviye 3 ile Seviye 4 arasındaki arayüzdür; Purdue diyagramları bunu tek bir güvenlik duvarı sınırı olarak ele alır.
Purdue Modeli ve ISA-95: Temel Farklar
| Özellik | Purdue modeli | ISA-95 |
|---|---|---|
| Tür | Referans mimari | Uluslararası standart (IEC 62264) |
| Bugünkü ana odak | Ağ bölümleme ve güvenlik | Sistem entegrasyonu ve bilgi modelleri |
| Veri modelleri tanımlar mı | Hayır | Evet; üretim, kalite, bakım, envanter için |
| Ekipman hiyerarşisi tanımlar mı | Hayır | Evet; kuruluştan iş birimine |
| DMZ tanımlar mı | Evet; genellikle Seviye 3.5 olarak | Hayır |
| Tipik hedef kitle | OT güvenliği, ağ mühendisleri | MES mimarları, entegratörler, operasyon |
| MQTT topic tasarımıyla ilgisi | Dolaylı; broker'ların konumu üzerinden | Doğrudan; ekipman hiyerarşisi üzerinden |
Pratik sonuç şudur: MQTT topic'lerini tasarlarken ISA-95 ekipman hiyerarşisi rehberimizde açıklanan ISA-95 ekipman hiyerarşisini kullanın. Broker'ın nerede çalışacağına ve güvenlik duvarlarının hangi bağlantılara izin vereceğine karar verirken ise Purdue bölgeleriyle düşünün.
MQTT Seviyeler Arası İletişimi Nasıl Düzleştirir?
Klasik Purdue tarzı bir tesiste veri seviyeleri birer adımla tırmanır. PLC, Seviye 2'deki SCADA tarafından sorgulanır; SCADA, Seviye 3'teki historian'ı besler; historian DMZ üzerinden çoğaltılır ve ERP sonunda bir özet görür. Her adım, kendi protokolü, eşlemesi ve arıza biçimleri olan noktadan noktaya bir entegrasyondur.
Yayınla-abone ol mimarisi veri akışını değiştirir. Unified namespace olarak bir MQTT broker kullanıldığında, yetkili her üretici bir kez yayın yapar ve yetkili her tüketici doğrudan abone olur. MES, historian, bir pano ve bir bulut analitik işi, aynı dolum makinesi telemetrisini aynı topic'ten okur. İnsanların MQTT'nin "piramidi düzleştirdiğini" söylerken kastettiği budur.
Neyin düzleştiği konusunda kesin olmak önemlidir. Bilgi mimarisi düzleşir: bir kopyalar zinciri yerine tek bir namespace vardır. Ağ mimarisinin ise düzleşmesi gerekmez: bölgeler, güvenlik duvarları ve DMZ varlığını sürdürür. MQTT burada yardımcı olur, çünkü istemciler broker'a her zaman giden (outbound) bağlantı açar. Seviye 2'deki bir gateway, kontrol ağına gelen (inbound) hiçbir port açılmadan DMZ'deki veya buluttaki bir broker'a yayın yapabilir.
Broker Nereye Yerleştirilmeli?
| Yerleşim | Nasıl çalışır | Dikkat edilecekler |
|---|---|---|
| Seviye 3 saha broker'ı | Gateway'ler saha içinde yayın yapar; bir köprü veya tüketici veriyi yukarı iletir | Veri yerelde kalır; sunucuyu siz işletirsiniz |
| Seviye 3.5 DMZ broker'ı | OT istemcileri DMZ'ye giden bağlantı kurar; BT istemcileri yukarıdan bağlanır | Net sınır; hiçbir taraf diğerinin bölgesine bağlanmaz |
| Bulut broker'ı | Saha gateway'leri barındırılan bir broker'a TLS üzerinden giden bağlantı kurar | Çalıştırılacak sunucu yok; kontrollü bir bölgeden giden internet erişimi gerekir |
| Hibrit | Yerel tüketiciler için saha broker'ı, kurumsal ve sahalar arası erişim için bulut broker'ı | Daha fazla bileşen; en iyi dayanıklılık ve erişim |
DMZ'de MQTT yazımız, güvenlik duvarı kuralları dahil DMZ tasarımını derinlemesine ele alıyor. Bir bulut MQTT broker seçerseniz ConnectMQ gibi yönetilen bir hizmet sunucu tarafını üstlenir; güvenlik duvarınızın yalnızca gateway'in bulunduğu bölgeden giden TLS trafiğine izin vermesi yeterlidir.
Bir OT Bölgesinden Giden Yolu Test Etmek
Bir yerleşime karar vermeden önce, hedeflenen bölgedeki bir gateway'in broker'a doğru port üzerinden ulaşabildiğini ve TLS doğrulamasının başarılı olduğunu kontrol edin. Bu komutlar bir Linux gateway'inden veya jump host'tan güvenle çalıştırılabilir; herkese açık test broker'ını kullandıkları için hassas hiçbir şey yayınlamayın:
# 1. 8883 üzerinden giden TLS'e izin veriliyor mu ve sertifika doğrulanıyor mu?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. TLS üzerinden tek bir retained test mesajı yayınla
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Başka bir bölgeden geri oku
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
Verify return code: 0 (ok) satırı, sertifika zincirinin güvenilir olduğunu doğrular. 1. adım askıda kalırsa bir güvenlik duvarı 8883'ü engelliyordur; tek seçenek WebSocket ise /mqtt yoluyla 8084 portu bir alternatiftir. Ücretsiz herkese açık MQTT broker bu bağlantı kontrolü için uygundur; üretim trafiği kimlik bilgileri olan özel bir broker'a aittir.
Güvenlik Hâlâ Önemli
Düz bir namespace veriye erişimi kolaylaştırır; bu yüzden kimlik doğrulama ve en az ayrıcalık ilkesi daha az değil, daha çok önem kazanır:
- Yalnızca giden bağlantı. Gateway'ler broker'a dışarı doğru bağlanır; Seviye 0 ile 2 arasına asla gelen port açmayın.
- Her yerde TLS. TLS üzerinden MQTT için 8883 portu, güvenli WebSocket için 8084.
- İstemci başına bir kimlik. Her birinin erişimi bağımsız olarak iptal edilebilsin diye kimlik bilgilerini gateway ve uygulama başına verin. ConnectMQ'da client ID'ler verilen kimlik bilgilerine bağlıdır.
- Kontrol için ayrı okuma ve yazma yolları. Komut topic'lerini yüksek riskli kabul edin ve kapalı döngü kontrolü yerel kontrol ağında tutun.
- Bağlantıları izleyin. Beklenmeyen istemcileri ve başarısız girişleri takip edin. ConnectMQ, tekrarlanan başarısız girişlerden sonra IP'leri engeller ve tenant başına flood koruması uygular.
İki model arasındaki ilişki daha geniş BT/OT yakınsaması tartışmasının bir parçasıdır; endüstriyel IoT MQTT rehberimiz de bu parçaların eksiksiz bir tesis mimarisine nasıl oturduğunu gösteriyor.
Seviyelerinizi ConnectMQ ile Köprüleyin
Veri akışını düzleştirirken Purdue tarzı bölgeleri korumak, her bölgenin giden TLS üzerinden ulaşabileceği bir broker gerektirir. ConnectMQ; 8883'te TLS, 8084'te güvenli WebSocket, istemci başına kimlik bilgileri ve ISA-95 cihazlar görünümü sunan, paylaşımlı, Dedicated veya BYOC kurulumlarla kullanılabilen bir yönetilen MQTT broker hizmetidir. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz Serverless planla başlayın.
Sık Sorulan Sorular
Purdue modeli artık geçerliliğini yitirdi mi?
Katı, adım adım ilerleyen veri akışının yerini yayınla-abone ol mimarileri alıyor; ancak ağları kontrollü sınırlara sahip bölgelere ayırma şeklindeki temel fikri OT güvenliğinin merkezinde kalmaya devam ediyor.
ISA-95 ağ güvenliğini tanımlar mı?
Hayır. ISA-95 işlevleri, bilgi modellerini ve ekipman hiyerarşisini tanımlar. Endüstriyel otomasyon için ağ ve sistem güvenliği ISA/IEC 62443 serisinde ele alınır.
MQTT topic tasarımı için hangi modeli kullanmalıyım?
Topic'ler için ISA-95 ekipman hiyerarşisini kullanın; broker'ın nerede çalışacağına ve hangi giden bağlantılara izin verileceğine karar vermek için ise Purdue tarzı bölgeleri kullanın.
Unified namespace Purdue modelini bozar mı?
Veri akışını değiştirir, ağ bölümlemesini ise zorunlu olarak değiştirmez. Yalnızca giden MQTT bağlantıları ve DMZ'de ya da bulutta bir broker ile bölgeler ve güvenlik duvarları yerinde kalır.
