MQTT - protokół IoT i bezpieczeństwo komunikacji publish/subscribe

MQTT (Message Queuing Telemetry Transport) to lekki protokół komunikacyjny oparty na modelu publish/subscribe, zaprojektowany w 1999 roku przez Andy’ego Stanford-Clarka (IBM) i Arlena Nippera (Cirrus Link) do transmisji telemetrii z rurociągów naftowych przez łącza satelitarne o ograniczonej przepustowości. Dziś MQTT jest dominującym protokołem w ekosystemie IoT i IIoT - od czujników środowiskowych i inteligentnych liczników, przez systemy monitoringu SCADA, po platformy chmurowe AWS IoT Core, Azure IoT Hub i Google Cloud IoT.

Standard MQTT jest utrzymywany przez OASIS i aktualnie obowiązuje wersja 5.0 (2019), choć wersja 3.1.1 (2014) pozostaje najszerzej stosowana w urządzeniach embedded.

Architektura publish/subscribe

W przeciwieństwie do protokołów request/response (HTTP, Modbus TCP), MQTT opiera się na pośredniku - brokerze - który zarządza dystrybucją wiadomości między nadawcami (publishers) i odbiorcami (subscribers). Klienci nie komunikują się bezpośrednio - publikują wiadomości w tematach (topics), a broker doręcza je wszystkim subskrybentom danego tematu.

Parametr	MQTT (nieszyfrowany)	MQTT over TLS
Transport	TCP	TCP + TLS 1.2/1.3
Port	1883	8883
Uwierzytelnianie	Opcjonalne (username/password)	Certyfikaty X.509 + username/password
Szyfrowanie	Brak	AES-256-GCM (TLS)
QoS	0 (at most once), 1 (at least once), 2 (exactly once)	Jak obok
Overhead nagłówka	2 bajty minimum	+ narzut TLS

Model publish/subscribe ma istotne konsekwencje dla bezpieczeństwa. Broker jest centralnym punktem - kto kontroluje brokera, kontroluje całą komunikację. Subskrypcja na temat wildcard (#) pozwala nasłuchiwać wszystkich wiadomości przechodzących przez brokera.

Zastosowania w OT i IoT

MQTT znalazł szerokie zastosowanie w:

• IIoT i telemetria - przesyłanie danych z czujników do platform SCADA i historyków (np. Sparkplug B - specyfikacja MQTT dla przemysłu)
• Inteligentne budynki - integracja urządzeń IoT z systemami BMS
• Energetyka - komunikacja z inteligentnymi licznikami (AMI) i falownikami PV
• Edge computing - agregacja danych na bramkach IoT przed przesłaniem do chmury

W kontekście przemysłowym szczególne znaczenie ma Sparkplug B - specyfikacja definiująca strukturę tematów i payloadów MQTT dla systemów SCADA/IIoT, z obsługą birth/death certificates (informowanie o dostępności urządzeń) i typami danych kompatybilnymi z systemami automatyki.

Ocena bezpieczeństwa

MQTT sam w sobie jest protokołem transportowym - nie narzuca polityk bezpieczeństwa, a jedynie udostępnia mechanizmy, które trzeba świadomie włączyć i skonfigurować.

Typowe podatności instalacji MQTT:

• Broker bez uwierzytelniania - domyślna konfiguracja wielu brokerów (np. Mosquitto) nie wymaga loginu. Skanery Shodan identyfikują tysiące otwartych brokerów MQTT w internecie
• Brak autoryzacji na poziomie tematów - nawet z uwierzytelnianiem, klient po zalogowaniu często może subskrybować dowolny temat (w tym #), uzyskując dostęp do całej telemetrii
• Komunikacja jawna na porcie 1883 - hasła przesyłane w plaintext, dane telemetryczne (wartości pomiarowe, stany urządzeń) widoczne dla każdego w segmencie sieciowym
• Retained messages i Last Will - wiadomości retained pozostają na brokerze i są dostarczane nowym subskrybentom, co może ujawnić stan systemu atakującemu
• Brak walidacji payloadu - broker nie weryfikuje zawartości wiadomości, co umożliwia wstrzykiwanie fałszywych danych telemetrycznych

MQTT v5.0 wprowadza mechanizm Enhanced Authentication (rozszerzalne uwierzytelnianie, np. SCRAM), ale jego adopcja w urządzeniach embedded jest wciąż ograniczona.

Segmentacja i ochrona

Bezpieczeństwo instalacji MQTT wymaga działań na trzech poziomach: konfiguracja brokera, segmentacja sieciowa i monitoring.

Konfiguracja brokera:

1. Wymuś TLS 1.2+ na wszystkich listenerach - wyłącz listener na porcie 1883
2. Wdróż mTLS - wzajemne uwierzytelnianie certyfikatami X.509 dla urządzeń IoT
3. ACL na poziomie tematów - każde urządzenie powinno mieć dostęp wyłącznie do swoich tematów (np. site/floor1/sensor42/+)
4. Ogranicz wildcard subscriptions - zablokuj subskrypcje # i + dla klientów IoT

Segmentacja sieciowa:

1. Broker w dedykowanej strefie DMZ - oddzielony firewallem zarówno od sieci IoT/OT, jak i od sieci IT/chmury
2. Osobne brokery dla różnych poziomów krytyczności - broker dla telemetrii środowiskowej nie powinien obsługiwać komunikacji ze sterownikami PLC
3. Mostkowanie (bridging) zamiast jednego globalnego brokera - brokery lokalne na edge, z kontrolowanym forwardingiem do brokera centralnego

Szczegółowe podejście do projektowania stref i korytarzy w sieciach OT i IoT opisujemy w artykule o segmentacji sieci OT.

Narzędzia open source

Narzędzie	Język	Opis	Link
mosquitto	C	Broker MQTT + narzędzia CLI do publikowania i subskrypcji (mosquitto_pub, mosquitto_sub)	GitHub
MQTT Explorer	Desktop GUI	Graficzny klient do przeglądania tematów, podglądu wiadomości i struktury brokera	GitHub
paho-mqtt	Python	Biblioteka kliencka MQTT - publikowanie, subskrypcja, obsługa QoS i TLS	GitHub

Źródła

• OASIS MQTT Version 5.0 - oficjalna specyfikacja protokołu
• Eclipse Sparkplug B Specification - MQTT dla aplikacji przemysłowych SCADA/IIoT
• NIST SP 800-183 - Networks of Things - wytyczne bezpieczeństwa IoT
• ENISA Good Practices for Security of IoT - europejskie wytyczne bezpieczeństwa IoT
• Eclipse Mosquitto Security - dokumentacja bezpieczeństwa najpopularniejszego brokera open-source