MQTT OT Güvenliği: Buluta Veri Gönderirken Endüstriyel Tesisleri Korumak

MQTT OT güvenliği, endüstriyel bir tesisten veri çıkarırken tesise yeni bir giriş yolu açmama pratiğidir. Bu rehber; yalnızca dışa dönük bağlantılar, DMZ gateway'leri ve segmentasyon gibi işe yarayan ağ desenlerini, ayrıca bulut broker'a gönderilen tesis verisi için kimlik bilgisi hijyenini ve izlemeyi ele alır. Sonunda hem OT hem de BT ekiplerinizle tartışabileceğiniz bir referans tasarıma ve kontrol listesine sahip olacaksınız.

OT Ağları Neden Farklı Bir Yaklaşım Gerektirir?

Operasyonel teknoloji (OT) ağları; hareket ettiren, ısıtan, karıştıran ve kesen ekipmanları çalıştırır. Ofis BT'sinden, her güvenlik kararını şekillendiren yönlerden ayrılırlar:

• Önce kullanılabilirlik gelir. Üretimi durduran bir güvenlik kontrolü, çoğu zaman karşıladığı tehditten daha büyük bir risk olarak görülür.
• Uzun yaşam döngüleri. PLC'ler ve HMI'lar yıllarca hizmette kalır ve sıklıkla hızla yamalanamayan firmware çalıştırır.
• Eski protokoller. Modbus, eski Profinet ve pek çok seri protokolde hiçbir kimlik doğrulama yoktur.
• Fiziksel sonuçlar. Sahte bir komut yalnızca veri sızdırmakla kalmaz; ekipmana zarar verebilir veya insanları yaralayabilir.

MQTT bu ortama çok uygundur, çünkü trafiğin olağan yönünü tersine çevirir. Bir bulut uygulamasının makineleri yoklamak için tesise uzanması yerine, tesis içindeki bir gateway veriyi dışarı iter. Doğru yapıldığında bu, OT ağına doğru hiçbir içe dönük güvenlik duvarı kuralı gerekmemesi anlamına gelir.

Temel İlke: Yalnızca Dışa Dönük Bağlantılar

Her MQTT istemcisi broker'a bir TCP bağlantısı açar; asla tersi olmaz. Bu nedenle bulut broker'a publish eden bir tesis gateway'i tam olarak tek bir güvenlik duvarı kuralına ihtiyaç duyar: broker hostname'ine 8883 portundan dışa dönük TCP.

Yalnızca dışa dönük olmak risksiz olmak demek değildir. Gateway'in dış dünyayla hâlâ bir TCP oturumu vardır ve komut topic'lerine subscribe oluyorsa veri içeri geri akabilir. Tasarım sorusu şuna dönüşür: gateway neyi kabul ediyor ve bunu nasıl doğruluyor?

Referans Mimari

Purdue modeli seviyelerini gevşek biçimde izleyen ve çoğu tesise uyan katmanlı bir tasarım:

1. Seviye 0–1: Saha cihazları ve PLC'ler. İnternet rotası yok. Yalnızca endüstriyel protokoller konuşulur.
2. Seviye 2: Denetim ağı. HMI'lar ve SCADA. Hâlâ internet rotası yok.
3. Seviye 3/3.5: Endüstriyel DMZ. Edge gateway burada bulunur. Seviye 2'den (örneğin OPC UA veya Modbus TCP ile) yalnızca bu belirli akışlara izin veren bir güvenlik duvarı üzerinden okur.
4. Seviye 4–5: Kurumsal ve bulut. Gateway, TLS üzerinden bulut MQTT broker'a publish eder. Dashboard'lar, analitik ve historian'lar buradan subscribe olur.

Tek Gateway mi, DMZ Broker mı?

İyi çalışan iki yaygın varyant vardır:

• Gateway doğrudan bulut broker'a publish eder. En basit seçenek: tek bir dışa dönük bağlantı, kesintiler için gateway üzerinde store-and-forward.
• Yerel DMZ broker'ı buluta köprü kurar. Makineler veya gateway'ler DMZ'deki bir broker'a publish eder ve tek bir bridge veya relay istemcisi seçilen topic'leri dışarı iletir. Bu, yamalanacak ve izlenecek bir sistem daha pahasına yerel bir tampon ve trafiği denetleyip filtrelemek için tek bir nokta ekler.

Her iki durumda da üretim sahası hiçbir zaman doğrudan internetle konuşmaz. Bir broker'ın veriyi nasıl yönlendirdiğine dair arka plan için bir MQTT broker'ın ne yaptığı yazısına bakın.

Önemli Segmentasyon Kuralları

Güvenlik duvarı kurallarını, her birinin açıklayabileceğiniz bir gerekçesi olacak şekilde yazın:

# OT firewall (between Level 2 and DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (OPC UA read)
ALLOW  gateway-01  -> plc-line2:502/tcp    (Modbus TCP read)
DENY   any         -> any                   (default)

# Perimeter firewall (DMZ to internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT over TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (time sync for TLS)
DENY   any         -> any                          (default)
DENY   internet    -> DMZ                          (no inbound)

Şu noktaları aklınızda tutun:

• Broker IP adresleri değişebiliyorsa, bir proxy veya yeni nesil güvenlik duvarında egress filtrelemeyle hostname kullanmayı tercih edin.
• Yalnızca 8883 portuna izin verin. 1883 üzerindeki şifresiz MQTT asla tesisten çıkmamalıdır.
• Doğru saat önemlidir: saati yanlış olan gateway'lerde TLS sertifika doğrulaması başarısız olur.
• OT tarafından reddedilen bağlantıları loglayın; beklenmeyen dışa dönük denemeler erken bir uyarı işaretidir.

Gateway'ler İçin Kimlik Bilgisi Hijyeni

Tesis gateway'leri çoğu zaman yıllarca gözetimsiz çalışır; bu yüzden kimlik bilgileri ilk günden itibaren özenle yönetilmelidir.

1. Her gateway için bir kimlik. Bir gateway ele geçirilirse diğerlerine dokunmadan onu iptal edin.
2. Farklı roller için farklı kimlikler. Bir telemetri publisher'ı ile bir komut alıcısı kimlik bilgilerini paylaşmamalıdır.
3. Gizli bilgileri kaynak kodun dışında saklayın; korumalı bir yapılandırma dosyasında veya işletim sisteminin secret store'unda, yalnızca gateway servis hesabının okuyabileceği şekilde.
4. Düzenli aralıklarla ve olay bazlı rotasyon yapın; örneğin personel değişikliklerinde veya şüpheli bir ihlalde. MQTT kimlik bilgilerini döndürme rehberi, kesinti süresini en aza indiren bir yaklaşım gösterir.
5. Tesis kimlik bilgilerini asla test broker'larında yeniden kullanmayın. Herkese açık MQTT test broker'ını yalnızca tek kullanımlık client ID'ler ve sahte verilerle kullanın.

ConnectMQ üzerinde her broker oluşturulmuş kimlik bilgileri alır ve client ID'ler bu kimlik bilgilerine bağlıdır; dolayısıyla sızdırılmış bir client ID tek başına bağlanmak için kullanılamaz. Tekrarlanan başarısız oturum açma denemeleri IP engellemeye yol açar ve bu da gateway hesaplarınıza yönelik parola tahminini sınırlar.

Komutları Güvenle Yönetmek

İş gereksinimi uzaktan set değerleri veya reçete değişiklikleri gerektiriyorsa, komut yolunu ayrı ve daha yüksek riskli bir kanal olarak ele alın:

• Özel komut topic'leri ve ayrı bir subscriber kimliği kullanın.
• Her komutu gateway üzerinde bir izin listesine göre doğrulayın: hangi tag, hangi aralık, hangi birimler.
• Operatörlerin gerçekte ne olduğunu görebilmesi için bir yanıt veya onay topic'i zorunlu tutun. MQTT 5 response topic'leri burada yardımcı olur.
• Yerel bir geçersiz kılma (override) imkânı bırakın ve broker'a ulaşılamadığında ekipmanın güvenli duruma geçtiğinden emin olun.
• Ham payload'ları asla bir PLC'ye iletmeyin.

Pek çok tesis, bulut yolunun salt okunur kalmasına ve yazma işlemlerinin yalnızca yerel HMI'lar üzerinden yapılmasına karar verir. Bu meşru ve yaygın bir tercihtir.

İzleme ve Kullanılabilirlik

OT'de güvenlik, kullanılabilirliği de kapsar. Şu durumlar için plan yapın:

• Broker veya internet kesintisi: Gateway veriyi yerelde tamponlar ve bağlantı geri geldiğinde backoff ile yeniden gönderir. Message expiry, eskimiş verilerin saatler sonra yeniden oynatılmasını engeller.
• Gateway arızası: ConnectMQ üzerinde $SYS/broker/connection/{clientId}/state topic'ine subscribe olun veya bir last will mesajı kullanın; böylece dashboard'lar gateway'i çevrimdışı gösterir.
• Olağandışı trafik: Birdenbire normal hızının on katında publish eden veya yeni bir IP adresinden bağlanan bir gateway incelenmeyi hak eder.
• Kota sınırları: MQTT 5 reason code 0x97, bir plan kotasının aşıldığını bildirir; böylece bunu ağ sorunlarından ayırt edebilirsiniz.

ConnectMQ portalının dashboard'u, ISA-95 seviyesine göre cihazlar görünümü ve eşik tabanlı uyarı kuralları, operasyon ekiplerinin özel araçlar geliştirmeden bunları görmesine yardımcı olur.

MQTT İçin OT Güvenliği Kontrol Listesi

1. MQTT için OT ağına içe dönük güvenlik duvarı kuralı yok.
2. Gateway bir DMZ'de bulunur ve PLC'lerden dar kapsamlı kurallarla okur.
3. Sahadan yalnızca 8883 portunda TLS çıkar; sunucu sertifikası doğrulanır ve saat doğrudur.
4. Her gateway ve her rol için benzersiz, iptal edilebilir bir kimlik.
5. Komut yolları ayrıdır, doğrulanır ve güvenli duruma geçer; ya da hiç yoktur.
6. Gateway'ler kesintilerde veriyi tamponlar ve backoff ile yeniden bağlanır.
7. Gateway bağlantı durumu ve mesaj hızları izlenir.
8. Tesis, BT ve broker sağlayıcısı arasındaki sorumluluklar belgelenmiştir.

Aynı konunun standartlar tarafı için IEC 62443 ve MQTT yazısını okuyun. MQTT ile endüstriyel IoT rehberi veri modellemeyi, MQTT güvenliği en iyi uygulamaları ise genel istemci sıkılaştırmasını ele alır.

Tesisinizi ConnectMQ'ya Güvenle Bağlayın

Bu tasarımı tek bir gateway üzerinde bir öğleden sonrada test edebilirsiniz. app.connectmq.com adresinde ücretsiz Serverless planla özel bir broker oluşturun (kredi kartı gerekmez), 8883 portu için tek bir dışa dönük kural açın ve ilk ISA-95 topic'inizi TLS üzerinden publish edin. Üretim için izolasyona ihtiyaç duyduğunuzda, Dedicated veya BYOC dağıtımındaki yönetilen MQTT broker aynı istemci yapılandırmasını korur.

Sık Sorulan Sorular

MQTT, tesise içe dönük port açmayı gerektirir mi?

Hayır. MQTT istemcileri broker'a dışarıya doğru bağlanır; bu nedenle bir tesis gateway'i yalnızca 8883 portuna dışa dönük bir kurala ihtiyaç duyar. Varsa komutlar da aynı bağlantı üzerinden geri gelir.

PLC'ler doğrudan bir bulut broker'a bağlanmalı mı?

Genellikle hayır. PLC'leri izole bir ağda tutmak ve bir DMZ'ye edge gateway yerleştirmek maruziyeti sınırlar ve tesisten tam olarak neyin çıktığını kontrol etmenizi sağlar.

Tesisten buluta MQTT için VPN gerekir mi?

Genellikle hayır. Sunucu sertifikası doğrulaması ve güçlü istemci kimlik bilgileriyle TLS üzerinden MQTT, VPN olmadan şifreli ve kimliği doğrulanmış bir kanal sağlar.

İnternet bağlantısı koptuğunda verilere ne olur?

İyi tasarlanmış bir gateway veriyi yerelde tamponlar ve yeniden bağlandıktan sonra backoff ile tekrar gönderir. Message expiry, artık işe yaramayan değerleri atabilir.