IEC 62443 ve MQTT: Bölgeler ve Kanallarla Endüstriyel Mesajlaşmayı Güvence Altına Almak

IEC 62443 MQTT tasarımı, bir MQTT veri akışını endüstriyel güvenlik ekiplerinin zaten kullandığı bölge ve kanal (zone and conduit) modelinin içine yerleştirmekle ilgilidir. Bu rehber, temel IEC 62443 kavramlarını PLC'ler, edge gateway'ler ve bir bulut broker'dan oluşan tipik bir mimariye eşler; böylece tasarımınızı OT güvenlik denetçilerinizin beklediği dille anlatabilirsiniz. Bu bir mühendislik rehberidir, hukuki ya da sertifikasyon tavsiyesi değildir: uyumluluk tek bir ürün tarafından verilmez, sisteminiz ve kuruluşunuz için değerlendirilir.

IEC 62443'e Kısa Bir Giriş

IEC 62443, endüstriyel otomasyon ve kontrol sistemlerinin (IACS) güvenliğine yönelik bir standartlar serisidir. Birkaç farklı hedef kitle için yazılmıştır: tesisleri işleten varlık sahipleri, çözümleri kuran sistem entegratörleri ve bileşenleri üreten ürün tedarikçileri. Mesajlaşma tasarımı açısından en önemli kavramlar şunlardır:

• Bölgeler (zones): Ortak güvenlik gereksinimlerine sahip varlık grupları; örneğin bir PLC hücresi veya kurumsal BT ağı.
• Kanallar (conduits): Bölgeler arasındaki, kendine ait güvenlik gereksinimleri olan iletişim yolları.
• Temel gereksinimler (FR): Teknik gereksinimleri yapılandıran yedi kategori: tanımlama ve kimlik doğrulama kontrolü, kullanım kontrolü, sistem bütünlüğü, veri gizliliği, kısıtlı veri akışı, olaylara zamanında yanıt ve kaynak kullanılabilirliği.
• Güvenlik seviyeleri (SL): Bölgenin veya kanalın ne kadar yetenekli bir saldırgana dayanması gerektiğini tanımlayan, SL 1'den SL 4'e kadar hedefler; sıradan kötüye kullanımdan gelişmiş ve kaynakları bol saldırılara kadar.
• Risk değerlendirmesi: Bölgeleri, kanalları ve hedef güvenlik seviyelerini belirleyen süreç (3-2. bölümde açıklanır).

MQTT projeleri için birkaç bölüm önemlidir. 3-3. bölüm sistem güvenlik gereksinimlerini listeler, 4-2. bölüm bileşen gereksinimlerini kapsar, 2-1. bölüm ise varlık sahibinin güvenlik programını ele alır.

MQTT Neden Bölge ve Kanal Modeline Uyar?

MQTT'nin güvenlik mimarlarının sevdiği bir özelliği vardır: istemciler broker'a her zaman dışarıya doğru bağlanır. Bir PLC gateway'i broker'a publish eder; tesise içeriden gelen hiçbir bağlantı gerekmez. Bu da iletişim yolunu, yönü, protokolü ve portu tanımlı tek bir kanal olarak tarif etmeyi kolaylaştırır.

Bunu, merkezi bir sistemin değerleri okumak için tesis ağına uzandığı yoklama (polling) protokolleriyle karşılaştırın. Her yoklama, güvenlik duvarlarından geçmesine izin verilmesi gereken içe dönük bir akıştır. MQTT'de bağlantıyı tesis başlatır ve güvenlik duvarı içe doğru kapalı kalabilir.

Bir MQTT Mimarisini Bölgelere ve Kanallara Eşlemek

Tipik bir endüstriyel MQTT mimarisinde dört bölge bulunur:

Ve üç kanal:

1. Kontrolden edge'e kanal: Gateway'den PLC'lere salt okunur endüstriyel protokol erişimi.
2. Edge'den broker'a kanal: Gateway'den veya DMZ'den broker'a, 8883 portunda TLS üzerinden MQTT; yalnızca dışa doğru.
3. Broker'dan tüketiciye kanal: Analitik uygulamalarından ve dashboard'lardan broker'a TLS üzerinden MQTT.

Tablodaki hedef güvenlik seviyeleri bilinçli olarak sabitlenmemiştir. Bunlar risk değerlendirmenizden gelir; aynı mimari bir tesiste SL 2, bir başkasında SL 3 olabilir.

Her Kanalı Belgeleyin

Her kanal için şunları yazın: uç noktalar, bağlantının hangi yönde kurulduğu, protokol ve port, kimlik doğrulama yöntemi, şifreleme, izin verilen topic'ler veya veriler ve kanal arızalandığında ne olacağı. Denetçiler tam olarak bu ayrıntıları soracaktır.

Temel Gereksinimleri MQTT'ye Uygulamak

Komutlar Ayrı Bir Analizi Hak Eder

Tesisten dışarıya telemetri göndermek bir risk seviyesidir. Tesise komut göndermek ise başka bir seviyedir. Pek çok kuruluş bulut kanalını kesinlikle salt okunur tutar ve yazma işlemlerini yerelde yönetir. Uzaktan set değeri göndermeniz gerekiyorsa bunları ayırın: farklı topic'ler, farklı kimlik bilgileri, gateway üzerinde doğrulama ve gateway'in PLC'ye ileteceği değerlere sınırlar. Kontrol bölgesi, bir broker'dan gelen ham payload'ları asla doğrudan çalıştırmamalıdır.

Yönetilen Bir Broker Nereye Oturur?

Bu modelde bulut broker bir bölge, edge'den broker'a bağlantı ise bir kanaldır. Yönetilen bir broker sisteminizi IEC 62443 uyumlu hale getirmez ve bunu ima eden her tedarikçiye karşı temkinli olmalısınız. Yapabileceği şey, kendi değerlendirmenizde referans verebileceğiniz kontroller sağlamaktır.

ConnectMQ, böyle bir değerlendirmeyi destekleyebilecek şu kontrolleri sunar:

• Let's Encrypt sertifikasıyla 8883 portunda TLS ve 8084 portunda güvenli WebSocket (FR3, FR4).
• Oluşturulan kimlik bilgileriyle kimlik doğrulama; client ID'ler bu kimlik bilgilerine bağlıdır (FR1).
• Çok kiracılı (multi-tenant) izolasyon, Dedicated planlarda izole bir küme veya BYOC ile kendi bulut hesabınıza dağıtım (FR5).
• MQTT 5 reason code 0x97 ile plan bazlı kotalar, flood koruması ve tekrarlanan başarısız oturum açma denemelerinden sonra IP engelleme (FR6, FR7).
• $SYS/broker/connection/{clientId}/state üzerinden bağlantı durumu görünürlüğü, ayrıca portal dashboard'ları ve eşik tabanlı uyarı kuralları (FR6).

ConnectMQ topic bazlı ACL sunmaz; bu nedenle topic düzeyinde ayrım gereken yerlerde her güven bölgesi için ayrı broker'lar veya kimlik bilgileri kullanın ve komut filtrelemeyi edge gateway'inizde uygulayın. Bu sorumlulukları paylaşılan sorumluluk matrisinize kaydedin. Bulut MQTT broker rehberi, bölge tasarımında sıklıkla önem taşıyan paylaşımlı, dedicated ve BYOC modellerini karşılaştırır.

Örnek: Broker Bölgesine Publish Eden Edge Gateway

Güvenlik çalışmasının büyük kısmı gateway'de yaşar. Değerleri yerelde okuyup TLS üzerinden publish eden minimal bir Python gateway'i şöyle görünebilir:

import json
import time
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"  # ConnectMQ portalından
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"

def read_plc_values():
    # Kendi OPC UA veya Modbus okumanızla değiştirin; gateway yalnızca okur.
    return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()  # broker sertifikasını sistem CA'larına karşı doğrula
client.reconnect_delay_set(min_delay=2, max_delay=300)

client.connect(BROKER, 8883, keepalive=60)
client.loop_start()

while True:
    payload = read_plc_values()
    payload["ts"] = int(time.time())
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(10)

Olmayan şeylere dikkat edin: gateway'de içe açık port yok, komut topic'lerine subscription yok, diğer gateway'lerle paylaşılan kimlik bilgisi yok. Topic, ISA-95 tarzı bir hiyerarşi izler; bu da bölge sınırlarınızı veri modelinde görünür kılar. MQTT ile endüstriyel IoT rehberi bu yapıyı daha ayrıntılı açıklar.

IEC 62443 MQTT Tasarımı İçin İnceleme Kontrol Listesi

1. Bir risk değerlendirmesi, MQTT akışları için bölgeleri, kanalları ve hedef güvenlik seviyelerini tanımlar.
2. Bölge sınırını geçen her MQTT bağlantısı TLS kullanır ve sunucu sertifikasını doğrular.
3. Tüm bağlantılar tesis tarafından dışarıya doğru başlatılır; kontrol bölgesine içe açık port yoktur.
4. Her gateway ve uygulamanın benzersiz, iptal edilebilir kimlik bilgileri vardır.
5. Komut yolları telemetriden ayrılmıştır ve gateway üzerinde doğrulanır.
6. Gateway'ler kanal kapalıyken veriyi tamponlar ve sistemi boğmadan toparlanır.
7. Bağlantı durumu, başarısız oturum açma denemeleri ve anormal hızlar tanımlı bir yanıt süreciyle izlenir.
8. Broker sağlayıcısıyla paylaşılan sorumluluklar belgelenmiştir.

Bu kontrol listesinin ağ tarafı için OT ağlarında MQTT güvenliği yazısını, kimlik tarafı için ise IoT mesajlaşmasında sıfır güven makalesini okuyun.

Endüstriyel Veri Kanalınızı ConnectMQ Üzerinde Kurun

Edge'den broker'a kanalın prototipini bugün oluşturabilirsiniz. app.connectmq.com adresinde ücretsiz Serverless planla özel bir broker oluşturun (kredi kartı gerekmez), bir gateway'i TLS üzerinden bağlayın ve ISA-95 topic'lerinin portalın cihazlar görünümünde belirdiğini izleyin. Tasarım izolasyon gerektirdiğinde, Dedicated veya BYOC dağıtımındaki tam yönetilen MQTT hizmeti aynı istemci yapılandırmasını korur. Daha kapsamlı MQTT güvenliği en iyi uygulamaları her aşamada geçerlidir.

Sık Sorulan Sorular

IEC 62443 kapsamında MQTT kullanımına izin veriliyor mu?

IEC 62443 belirli protokolleri yasaklamaz veya şart koşmaz. Bölgeler arası iletişimin kendi kanalına ait güvenlik gereksinimlerini karşılamasını ister; güçlü kimlik doğrulamayla TLS üzerinden MQTT bunu destekleyebilir.

Bir bulut MQTT broker, tesisim için IEC 62443 sertifikalı olabilir mi?

Sertifikasyon, standardın belirli bölümlerine göre belirli ürünlere, süreçlere veya sistemlere uygulanır. Genel sisteminizin uygunluğu tesisiniz için değerlendirilir; bir broker sağlayıcısı yalnızca bu değerlendirmede referans verdiğiniz kontrolleri sağlayabilir.

Komutlar buluttan tesise akmalı mı?

Yalnızca risk değerlendirmesi buna izin veriyorsa. Pek çok saha bulut kanalını salt okunur tutar; komutlara izin verenler ise bunları ayırır, gateway üzerinde doğrular ve neyin değiştirilebileceğini sınırlar.

DMZ'de yerel bir broker'a ihtiyacım var mı?

Her zaman değil. DMZ broker'ı tamponlama ve bir denetim noktası ekler; gateway'in TLS üzerinden doğrudan bulut broker'a publish etmesi ise daha basittir. Kararı risk değerlendirmesi ve hedef güvenlik seviyesi verir.