Przemysł 4.0 to nie tylko innowacje, usprawnienia oraz automatyzacja tych obszarów przemysłu, które dotąd nie były zautomatyzowane. Wraz z rozwojem koncepcji Przemysłu 4.0 pojawia się również coraz więcej potencjalnych zagrożeń – dotychczas marginalizowanych lub pomijanych w analizach dotyczących automatyzacji kolejnych stanowisk pracy. Współczesne fabryki coraz częściej podążają za trendem integracji praktycznie każdego urządzenia ze sterownikiem PLC, wykorzystując do tego otwarty protokół komunikacyjny TCP/IP. Zaletą tego rozwiązania jest jego elastyczność – za pomocą kilku wcześniej zdefiniowanych wiadomości wymienianych pomiędzy sterownikiem PLC a urządzeniem zewnętrznym, możliwa jest efektywna wymiana danych dotyczących stanu urządzenia, nawet jeśli pochodzi ono od innego producenta. Dodatkowo, system umożliwia rozpoznawanie błędów oraz ich przetwarzanie bezpośrednio w sterowniku PLC, tak aby operatorzy mogli szybko reagować na nie poprzez wizualizację systemu SCADA.
Warto również wspomnieć, że wiele rozwiązań SCADA umożliwia bezpośrednią komunikację ze sterownikami PLC właśnie za pomocą protokołu TCP/IP, co jeszcze bardziej ułatwia integrację systemów automatyki.
Rozwiązanie to wydaje się na pierwszy rzut oka idealne do prostego i elastycznego komunikowania się z urządzeniami zewnętrznymi. Istnieje jednak jedno poważne zagrożenie, które bardzo często jest pomijane w dyskusjach na temat tej komunikacji. Mowa o braku szyfrowania przesyłanych wiadomości przy wymianie danych pomiędzy klientami w podstawowej wersji protokołu TCP/IP, a taka konfiguracja jest najczęściej stosowana w przemyśle. Jest to bardzo poważne zagrożenie w dobie rozpędu zagrożeń cybernetycznych, ponieważ dane przesyłane za pomocą niezabezpieczonego protokołu komunikacyjnego mogą w łatwy sposób zostać przechwycony. Problem ten potęguje też fakt, że jednym z terenów przemysłu 4.0 jest rozszerzanie zdalnego dostępu do fabryki w celu pomocy utrzymania ruchu, optymalizacji procesu czy ściągania danych.
Powyższy rysunek ilustruje sposób przesyłania niezabezpieczonego ruchu TCP/IP. Za pomocą aplikacji WireShark uruchomiono nasłuchiwanie na porcie, przez który transmitowane są wiadomości. Wyniki pokazują, że osoba trzecia, posiadająca dostęp do takiej sieci, może w prosty sposób rozpocząć przechwytywanie komunikacji i odczytywać przesyłane dane. W rzeczywistych warunkach ruch sieciowy zazwyczaj jest kierowany przez przełącznik (switch), co oznacza, że ramki trafiają wyłącznie na porty, do których podłączony jest docelowy klient. Taka architektura zwiększa bezpieczeństwo, ponieważ uniemożliwia łatwe podsłuchiwanie komunikacji przez osoby postronne. Jednak dla doświadczonych atakujących nie stanowi to większego problemu – mogą oni zastosować techniki takie jak np. MAC flooding. Polega ona na przepełnieniu tablicy MAC przełącznika dużą liczbą fałszywych adresów MAC, co w efekcie prowadzi do tzw. „fail-open”. W takim przypadku przełącznik zaczyna przesyłać ruch na wszystkie porty, umożliwiając podsłuchiwanie ruchu przez dowolnego użytkownika w sieci.
Protokół MQTT (Message Queuing Telemetry Transport) to wydajny, lekki protokół komunikacyjny, który został zaprojektowany z myślą o urządzeniach o ograniczonych zasobach – jest więc szczególnie popularny w środowisku Internetu Rzeczy (IoT). Dzięki niskim wymaganiom sprzętowym umożliwia niezawodną wymianę informacji nawet przy słabym łączu sieciowym.
Aby ułatwić wdrożenie komunikacji opartej na protokole MQTT, powszechnie korzysta się z gotowych rozwiązań oferowanych przez różnych producentów. Wybór odpowiedniego brokera zależy od specyfiki projektu, skali wdrożenia oraz wymagań dotyczących kosztów i dostępnych funkcji.
Pod względem kosztów integratorzy mogą wybierać spośród brokerów dostępnych zarówno w wersjach darmowych do zastosowań komercyjnych, jak i w modelu płatnej subskrypcji. Rozwiązania komercyjne zwykle oferują bardziej zaawansowane możliwości konfiguracji, lepsze zabezpieczenia oraz wsparcie techniczne.
Wybór odpowiedniego brokera powinien być podyktowany zarówno wymaganiami technicznymi, jak i planowanym kosztem wdrożenia i utrzymania systemu.
Protokół MQTT polega na uruchomieniu tzw. brokera na urządzeniu, które pełni funkcję „serwera” pośredniczącego w całej komunikacji pomiędzy wszystkimi urządzeniami (klientami) w sieci. W praktyce wymiana informacji odbywa się poprzez precyzyjnie zdefiniowane tematy (topics) – klienci publikują wiadomości w wybranych tematach, a ci, którzy subskrybują dany temat, automatycznie otrzymują każdą nową wiadomość pojawiającą się w tym kanale. Jest to model typu „publish-subscribe”, pozwalający na łatwe skalowanie systemu i elastyczne dodawanie nowych urządzeń bez konieczności budowania dodatkowych, dedykowanych połączeń pomiędzy nimi. Dodanie kolejnego urządzenia wymaga jedynie nawiązania połączenia z brokerem i ewentualnie konfiguracji certyfikatów bezpieczeństwa, a także ustalenia, które tematy ma ono subskrybować lub na których publikować dane.
MQTT oferuje mechanizm QoS (Quality of Service), który pozwala określić niezawodność dostarczania wiadomości między urządzeniami.
Poziom QoS ustala nadawca wiadomości i obowiązuje wszystkich subskrybujących dany temat. Wybór właściwego poziomu zależy od potrzeb aplikacji – wymaganej niezawodności, szybkości działania oraz dostępności zasobów.
W ramach testów komunikacji MQTT w środowisku przemysłowym przeprowadziliśmy próbę nawiązania połączenia między komputerem PC a sterownikiem PLC. Do realizacji zadania wykorzystano język programowania Python, który pełnił rolę klienta nr 1, oraz sterownik PLC z rodziny S7-1500, działający jako klient nr 2. Brokerem obsługującym komunikację był Mosquitto, uruchomiony w kontenerze Docker.
W celu utworzenia kontenera w środowisku Docker należy przygotować plik konfiguracyjny w formacie YAML, na podstawie którego tworzony jest kontener. W przeprowadzonych przez nas testach skupiliśmy się na sprawdzeniu aplikacji pod kątem podstawowej konfiguracji, dodatkowo zabezpieczonej za pomocą certyfikatu SSL.
W celu prostej weryfikacji czy środowisko, docker zostało poprawnie skonfigurowane użyto aplikacji MQTTX, które oferuje przejrzyste GUI do łączenia się ze brokerami MQTT. W tym celu wygenerowane zostały odpowiednie certyfikaty, które należy zaaplikować po stronie klienta.
Po uruchomieniu brokera w środowisku Docker i połączeniu klienta możliwe było wymienianie informacji i publikowanie wiadomości do tematów.
W celu przeprowadzenia rzetelnych testów uruchomiono dodatkowo dwóch klientów. Jeden z nich został zaimplementowany w języku Python, wykorzystując bibliotekę Paho. Python cechuje się wyjątkowo łatwym prototypowaniem aplikacji, dlatego został wybrany do tego zadania.
Prosta aplikacja działa na zasadzie utworzenia klienta MQTT, który komunikuje się z brokerem za pomocą portu 8883 — port zarezerwowany domyślnie dla komunikacji zabezpieczonej protokołem SSL/TLS.
Po uruchomieniu klient subskrybuje temat „Test1”, a następnie uruchamia dodatkowy wątek, umożliwiający wysyłanie wiadomości z poziomu środowiska IDE, w którym stworzono aplikację.
Trzeci klient został uruchomiony na sterowniku PLC. W celach testowych wykorzystano sterownik zasymulowany za pomocą oprogramowania S7-PLCSIM Advanced V6.0 Upd1. Do zaprogramowania sterownika wykorzystano środowisko TIA Portal w wersji 19.
Do połączenia z brokerem MQTT zastosowano funkcję LMQTT_Client, przygotowaną przez firmę Siemens i udostępnioną za pośrednictwem biblioteki Libraries_Comm_Controller. Funkcja ta umożliwia implementację klienta MQTT bezpośrednio na sterowniku PLC, co pozwala na integrację przemysłowych systemów automatyki z protokołem MQTT.
Aby nawiązać komunikację MQTT poprzez port 8883, konieczne było dodanie certyfikatów do projektu w środowisku TIA Portal. Cały proces odbywa się z poziomu zakładki Security settings.
Pierwszym krokiem jest zabezpieczenie projektu — należy ustawić wymóg logowania do projektu przy użyciu nazwy użytkownika oraz hasła spełniającego standardy bezpieczeństwa określone przez firmę Siemens. Dopiero po aktywowaniu tych zabezpieczeń możliwe jest przejście do zakładki Certificate Manager, gdzie dodaje się odpowiednie certyfikaty.
Następnie należy przejść do zakładki Trusted certificates and root certification authorities, gdzie można zaimportować certyfikaty oraz klucze niezbędne do nawiązania połączenia z brokerem. Import odpowiednich certyfikatów umożliwia weryfikację tożsamości brokera oraz zapewnia bezpieczną wymianę danych w ramach komunikacji MQTT przy użyciu SSL/TLS.
Następnie, w ustawieniach sterownika PLC, należy wskazać, z którego certyfikatu ma korzystać urządzenie. W tym celu w odpowiedniej sekcji konfiguracji wybiera się wcześniej zaimportowany certyfikat, który będzie wykorzystywany do uwierzytelniania i zapewnienia bezpiecznej komunikacji z brokerem MQTT. Wskazanie właściwego certyfikatu jest kluczowe dla prawidłowego ustanowienia połączenia szyfrowanego oraz spełnienia wymagań polityki bezpieczeństwa projektu.
Na koniec należy poprawnie skonfigurować ustawienia połączenia w odpowiednim bloku sterownika. Po tej konfiguracji komunikacja z brokerem MQTT może zostać zainicjowana.
Po poprawnym skonfigutrowaniu połączenia i wpisaniu odpowiedniego użytkwnika i hasła komunikacja z system zostanie nawiązania i wiadomości zostaną przetwarzane.
Jak można zauważyć, wiadomości przesyłane za pomocą komunikacji szyfrowanej nie mogą zostać odczytane bez zastosowania odpowiednich certyfikatów uwierzytelniających.
MQTT wyróżnia się na tle tradycyjnej komunikacji TCP/IP przede wszystkim prostotą implementacji oraz elastycznością w kwestii bezpieczeństwa. Standardowe połączenia TCP/IP domyślnie nie oferują szyfrowania, przez co przesyłane dane mogą być podatne na podsłuch i ingerencję osób niepowołanych. W praktyce oznacza to, że wdrożenie dodatkowych zabezpieczeń w tradycyjnych rozwiązaniach sieciowych bywa skomplikowane i czasochłonne.
W przypadku MQTT sytuacja wygląda zupełnie inaczej – protokół ten został zaprojektowany tak, aby maksymalnie uprościć zarówno konfigurację, jak i rozbudowę systemu komunikacji. Dzięki natywnemu wsparciu dla szyfrowania (np. poprzez TLS), bardzo łatwo można podnieść poziom bezpieczeństwa transmisji, bez potrzeby przeprowadzania złożonych modyfikacji architektury. Dodanie szyfrowania w MQTT ogranicza się najczęściej do kilku prostych ustawień po stronie brokera i klienta.
To właśnie ta łatwość wdrożenia, elastyczność oraz dostępność mechanizmów bezpieczeństwa sprawiają, że MQTT jest idealnym wyborem dla projektów wymagających szybkiego uruchomienia, a jednocześnie gotowych do łatwej adaptacji w miarę wzrostu wymagań dotyczących ochrony danych.
