Bezpieczna komunikacja MQTT w systemie SCADA ICONICS

93

Z tego wpisu dowiesz się, w jaki sposób przebiega bezpieczna komunikacja pomiędzy systemem SCADA od ICONICS a brokerem MQTT. Spis treści [Ukryj]

Krótko o protokole MQTT

Protokół MQTT opiera się o architekturę publikacja-subskrypcja. Co to oznacza w praktyce? Urządzenia komunikujące się za jego pośrednictwem nie łączą się bezpośrednio ze sobą podczas komunikacji. W protokole MQTT występuje natomiast narzędzie pośredniczące w komunikacji – Broker. Jest to oprogramowanie, które pełni rolę serwera wiadomości. Urządzenia klienckie (zarówno wysyłające, jak i odbierające dane) łączą się własnie z Brokerem. Te, które wysyłają dane, publikują je na Brokerze (serwerze wiadomości) pod określonym „tematem” (ang. Topic). Klienci, którzy chcą pobrać informacje, łączą się natomiast z brokerem i podają temat, z którego docelowo nastąpi odczyt danych. Na tym właśnie polega wzorzec publikowania/subskrybowania wiadomości.

Widać więc tutaj, że urządzenie publikujące informacje nie może „wiedzieć”, kto będzie ich odbiorcą, ani nawet ilu odbiorców istnieje. Tak samo subskrybent nie posiada informacji zarówno na temat fizycznej lokalizacji urządzenia wysyłającego wiadomości, jak i jego adresu IP.

Komunikacja z wykorzystaniem MQTT nie jest jednak niebezpieczna, mimo pewnej anonimowości klientów. Bezpieczeństwo zapewnia tu oprogramowanie pełniące rolę Brokera. Może ono być skonfigurowane tak, aby przy każdym połączeniu, klient musiał podać swój unikatowy login i hasło. Ponadto, do każdego konta użytkownika przypisać można pewne dozwolone akcje, jak na przykład możliwość publikacji danych tylko pod konkretnymi tematami (Topic).

Oprócz uwierzytelniania użytkowników przy logowaniu, całą komunikację z brokerem można opcjonalnie zabezpieczyć z wykorzystaniem protokołu TLS – przy użyciu Certyfikatów X.509. Bezpieczna komunikacja oparta na certyfikatach oferuje zarówno uwierzytelnianie serwera, jak i klientów.

Ze względu na prostotę nawiązywania komunikacji pomiędzy dużą liczbą urządzeń jednocześnie oraz łatwą implementację, protokół MQTT wykorzystuje się szeroko w rozwiązaniach z zakresu Internet of Things, czy połączeniach maszyna-maszyna. Protokół ten jest wolniejszy od swoich tradycyjnych odpowiedników, lecz dzięki wbudowanym mechanizmom kontroli przepływu danych oferuje większą niezawodność.

MQTT i system SCADA od ICONICS

Przedstawione niżej działania przeprowadzono w systemie SCADA GENESIS64 w wersji 10.95 z zainstalowanym Update 5.

Komunikacja z MQTT jest realizowana zarówno za pomocą pełnej wersji systemu SCADA, jak i oprogramowania dla bram IoT od ICONICS – IoTWorX. Jako, że projekty dla bram IoT tworzy się i tak za pomocą GENESIS64, działania przedstawione dalej odnoszą się również do oprogramowania IoTWorX.

Możliwości oferowane przez GENESIS64 w zakresie komunikacji MQTT

Oprogramowanie GENESIS64 oferuje możliwość nawiązania połączenia z:

  • usługą Azure IoT Hub (natywny broker platformy Azure),
  • usługą Azure Event Hub (broker zdarzeń od Azure),
  • usługami Platform Services na innych serwerach oprogramowania od ICONICS (natywne połączenia z innymi modułami ICONICS),
  • dowolną aplikacją wykorzystującą architekturę REST,
  • brokerami MQTT od dostawców trzecich.

Jeśli chodzi o ostatnie z powyższych (połączenia z brokerami MQTT), możliwe jest skonfigurowanie połączenia z wykorzystaniem protokołów:

  • MQTT – standardowy protokół dla tego typu połączeń, działający domyślnie na porcie 1883;
  • MQTTs – szyfrowana (bezpieczna) wersja powyższego protokołu wykorzystująca domyślnie port 8883;
  • Web Sockets – technologia dwukierunkowej komunikacji w aplikacjach klient-serwer wykorzystująca jedno gniazdo TCP, domyślny port to 80;
  • Secure Web Socket – technologia jak powyżej, z dodaną szyfrowaną transmisją (domyślny port: 443).

W celu określenia sposobu szyfrowania komunikacji dla bezpiecznych wersji powyższych protokołów, użytkownik może wybrać wersje 1.0, 1.1 oraz 1.2 protokołu TLS. Rekomendowana jest jednak tylko ta ostatnia, jako najbardziej bezpieczna.

Użytkownik może szyfrować komunikację z wykorzystaniem certyfikatów X.509. Oprogramowanie ICONICS umożliwia używanie certyfikatów w celu uwierzytelniania zarówno brokera, jak i klientów łączących się przez MQTT. Tak więc operator ma możliwość kontroli tożsamości brokera MQTT, z którym się łączy oraz aplikacji klienckich, które próbują się do tego brokera zalogować.

Ustawienia protokołu oraz szyfrowania dokonywane są jedynie w przypadku połączeń z brokerami MQTT od dostawców trzecich. W przypadku rozwiązań np. od platformy Azure, połączenie następuje z wykorzystaniem tzw. „Connection Strings” pozyskiwanych bezpośrednio od administratorów danego konta na platformie.

Dalsza część wpisu będzie dotyczyć połączenia GENESIS64 z dowolnym brokerem MQTT. Zakończy się ona krótkim filmem instruktażowym. Więcej informacji o integracji produktów od ICONICS z chmurą Azure można natomiast znaleźć w innym artykule na naszym blogu.

W jaki sposób dane wysyłane są do brokerów?

Pierwszą rzeczą, którą wykonuje użytkownik jest określenie listy danych do publikacji (Publish List). Wprowadza się tam szereg parametrów, jak na przykład częstość próbkowania i wysyłania danych, w celu dostosowania transmisji do indywidualnych wymagań. Następie operator określa, które zmienne system wyśle do brokera. Co więcej, dane można publikować okresowo, jak i po aktywacji określonego „triggera”.

Ostatni krok to zdefiniowanie kompletnego połączenia (Publisher Connection), gdzie użytkownik podaje m.in. typ połączenia (MQTT, Azure, Platform Services), jego parametry, używany broker oraz temat, pod którym udostępnia się dane.

Jeśli wymiana danych zachodzi pomiędzy aplikacjami ICONICS, istnieje możliwość zaznaczenia opcji kompatybilności z tego rodzaju klientami. Wtedy system SCADA udostępni do wyboru 4 domyślne enkodery danych (binarne lub JSON). W przypadku publikacji/odbioru danych od zewnętrznych systemów, możliwe jest zbudowanie własnego enkodera JSON w osobnej zakładce w Workbench.

Przy publikacji danych do brokerów MQTT lub usług Azure IoT Hub, wysyłane informacje są czasu rzeczywistego. Przy wykorzystaniu połączenia typu Platform Services (np. z modułem Hyper Historian) procującym na osobnym serwerze, możliwe jest również utworzenie list publikacji z danymi historycznymi lub pochodzącymi z narzędzi analitycznych od ICONICS.

Odbiór danych z brokera MQTT

Odczyt danych z brokera MQTT następuje na podobnych zasadach, co ich publikowanie. To, co użytkownik musi wykonać, to dodanie odpowiedniej subskrypcji (Subscriber Connection). Opcje dotyczące kompatybilności z klientami ICONICS, czy nazwy brokera są analogiczne jak wcześniej. Z oczywistych przyczyn użytkownik nie wybiera tu np. listy publikacji.

Odpowiednie konfiguracje przedstawia krótki film pokazowy zamieszczony na końcu tego wpisu.

Przykład projektu transmisji po MQTT

Założenia projektu

Na potrzeby zaprezentowania możliwości oprogramowania GENESIS64 przygotowano krótki projekt pokazowy.

W jego ramach, oprogramowanie SCADA od ICONICS będzie łączyć się z popularnym brokerem MQTT – Mosquitto. Działa on na osobnej maszynie pod systemem z rodziny Linux/Ubuntu.

Pierwsza część projektu dotyczy nawiązania połączenia z brokerem jako Publisher – klient publikujący dane. W celu najszerszej prezentacji możliwości połączenia utworzono dwie listy publikacji – jedną okresową, a drugą wysyłającą dane po aktywacji określonego trigger’a.

Druga część projektu to prezentacja konfiguracji odczytu danych z brokera.

Obydwa połączenia (publikacji i subskrypcji) realizuje jedna aplikacja SCADA. Co więcej, połączenia nawiązywane są z wykorzystaniem:

  • uwierzytelniania użytkownika za pomocą loginu i hasła,
  • uwierzytelniania serwera i szyfrowania transmisji przy użyciu certyfikatów X.509.

W celu zwiększenia przejrzystości prezentacji pominięto aspekt uwierzytelniania klienta z wykorzystaniem certyfikatów, lecz taka możliwość również istnieje w systemie GENESIS64.

Konfiguracja łączności broker MQTT – system SCADA

Pierwszym krokiem jest oczywiście instalacja i odpowiednia konfiguracja brokera MQTT Mosquitto na zdalnej maszynie. Nie jest to jednak działanie charakterystyczne dla systemu ICONICS, więc nie zostanie tutaj opisane. Wiele instrukcji na ten temat można znaleźć natomiast w internecie. Przykład poniżej.

Do tworzenia własnych certyfikatów w projekcie użyto środowiska openssl. Certyfikaty wykorzystane podczas tego projektu podpisano przez własny lokalny Urząd Certyfikacji, tak więc rozwiązanie to nadaje się do lokalnych systemów komunikacji, np. dla aplikacji działających w ramach firmy. O tym, jak wdrożyć wykorzystanie certyfikatów do serwera Mosquitto można również przeczytać w artykułach zamieszczonych w internecie.

Jak działa uwierzytelnianie serwera w tym przypadku? Wykorzystując certyfikaty oraz dane logowania klientów do brokera, proces ustanawiania połączenia jest dwustopniowy. Najpierw, oprogramowanie GENESIS64 prosi broker o wysłanie jego certyfikatu. Po jego otrzymaniu, sprawdza go poprzez weryfikację prawdziwości podpisu Urzędu Certyfikacji widniejącego na tym certyfikacie. Do tego procesu potrzebna oczywiście jest wcześniejsza instalacja samego certyfikatu Urzędu Certyfikacji, w katalogu zaufanych urzędów w konsoli MMC Windows. Jeśli oprogramowanie GENESIS64 potwierdzi prawdziwość certyfikatu, wyśle do serwera swoje dane logowania – login i hasło. Jeśli dane te będą poprawne, serwer zezwoli aplikacji SCADA na publikację danych pod określonym tematem.

Nawiązywanie połączenia w celu subskrypcji informacji z brokera przebiega w analogiczny sposób.

Oczywiście, jeśli któryś z etapów uwierzytelniania zakończy się niepowodzeniem, połączenie nie zostanie nawiązane.

Działania mające na celu nawiązanie bezpiecznej komunikacji, publikację oraz odczyt danych przedstawia poniższy film.

Bezpieczny MQTT w systemie SCADA – konfiguracja

Elmark Automatyka udostępnia wersję demo oprogramowania GENESIS64, w celu osobistego przetestowania funkcjonalności pakietu. Skontaktuj się z nami na ICONICS@elmark.com.pl w celu otrzymania wersji testowej lub oferty handlowej.

Źródło: Elmark