Bild 1. Industrielle IoT-Anwendungen verteilen sich in der Regel über vier Schichten. Um eine durchgängige Datenintegration softwaretechnisch zu bewerkstelligen, sind Docker-basierte Konzepte eine gute Wahl. Docker-Container lassen sich im Verbund einsetzen und können untereinander über anwendungsbezogene APIs (Application Programming Interfaces) kommunizieren.

© Quelle: SSV

Anwendungen, die auf einer Edge-Datenintegration basieren, erfordern in der Regel keine Spezialhardware. Vielfach reicht eine Linux- oder Windows-basierte Laufzeitumgebung mit jeweils einer USB- und Ethernet-LAN-Schnittstelle aus. Ältere, aber nach wie vor sehr weit verbreitete OT-Schnittstellen wie RS232, RS485 oder CAN werden bei Bedarf USB-basiert integriert. Ähnlich sieht es mit besonderen Funkschnittstellen aus.

Auf Grund dieser Minimalanforderungen eignen sich theoretisch unzählige IT-Systeme für den Einsatz als Edge-Gateway in der Automatisierung. Besondere Umweltbedingungen am Installationsort – Vibrationen, hohe Temperaturen, Staub, Spannungsschwankungen und weitere Störgrößen – schränken die Hardwareauswahl allerdings etwas ein.

Plattformunabhängig durch Virtualisierung

Beispiel: BLE-to-MQTT Docker

Bild 3. Mit Hilfe eines Edge-Gateway-Dockers und einer relativ kostengünstigen Bluetooth Low Energy (BLE) IoT-Sensorik lassen sich Datenintegrationsanwendungen realisieren, um ein hochwertiges Datenbild der jeweiligen Automatisierungslandschaft für übergeordnete IT-Anwendungen zu erzeugen. Da ein solcher Docker in verschiedene Netzwerke eingebunden ist, sind die jeweiligen Cybersecurity-Aspekte zu beachten.

© Quelle: SSV

Funktional verbindet ein Edge-Gateway-Docker beispielsweise ein OT- mit einem IT-Netzwerk. Beide Netzwerke sind in der Regel IP-basiert und lassen sich per Ethernet mit der Docker-Host-Hardware koppeln. Aus Sicherheitsaspekten sollte der Docker-Host hierfür allerdings zwei voneinander unabhängige LAN-Schnittstellen besitzen, denen jeweils eine eigene MAC-Adresse zugeordnet ist. Dadurch lässt sich eine klare physikalische Trennung der Vertrauensgrenzen schaffen (siehe Beispiel in der Bild 3), sowie ein wirkungsvolles Rechtemanagement und die erforderlichen Schutzmaßnahmen realisieren. In der Abbildung ist die Edge-Gateway-Beispielanwendung über das OT-Netzwerk darüber hinaus mit unterschiedlichen BLE-Funktionseinheiten verbunden. Sie erfüllen die folgenden Funktionen:

Beacon Device: BLE-basierter Sensor zur Messdatenerfassung an Maschinen- und Anlagenkomponenten. Ein solcher Sensor bildet einen Datenendpunkt mit einer 2,4-GHz-Bluetooth-Funkschnittstelle. Im einfachsten Fall werden von einer solchen Funktionseinheit lediglich Sensordaten per Broadcast verschickt; also an alle, die sich in Funkreichweite befinden und zuhören. In dieser GAP-basierten Betriebsart (GAP = Generic Access Profile, ein spezieller BLE-Dienst gemäß Bluetooth-Standard) führt ein Beacon Device periodisch Messungen mit der jeweils zur Verfügung stehenden Sensorik durch und verschickt die Messdaten als BLE-Advertising-Datenpakete. Neben GAP ist ein Beacon Device optional auch für GATT-Funktionen nutzbar (GATT = Generic Attribute Profile, ein weiterer standardkonformer BLE-Dienst). Dabei entsteht eine Client-Server-Verbindung für den bidirektionalen Datenaustausch zwischen dem Device als Peripheral und einem sogenannten Central Device, um etwa Updates an ein Device zu übermitteln.

Bild 4. Bei der Entwicklung eines Edge-Gateway-Dockers liefert der Teil 4-1 der DIN EN IEC 62433 die Orientierungshilfen, um etwa ein LAN-Schnittstellen-Bedrohungsmodell zu entwerfen, mittels CVSS (Common Vulnerability Scoring System) die erkannten Gefahren zu gewichten und im Rahmen des Entwicklungsprozesses geeignete Gegenmaßnahmen vorzusehen, umzusetzen und umfassend zu testen.

© Quelle: SSV

Beacon Agent: Einfacher Schnittstellen- und Datenwandler. Auf der einen Seite besitzt ein Agent eine 2,4-GHz-BLE-Funkschnittstelle für die Verbindung zu den Beacon Devices in Funkreichweite. Die gegenüberliegende Seite bildet ein Ethernet-LAN-Interface zum OT-Netzwerk. Sie dient als MQTT-Client-Verbindung zum Edge-Docker. Datentechnisch wandelt der Beacon Agent die empfangenen BLE Advertising Broadcasts mit den Messwerten der Devices in JSON-Objekte um und überträgt diese per MQTT an den Edge-Gateway-Docker. Funktional dient der Beacon Agent allerdings auch zur Vergrößerung der BLE-Funkreichweite. Durch eine integrierte Multicast-DNS-Funktion findet eine Edge-Docker-Anwendung automatisch alle Beacon Agenten in einem OT-Netzwerk.

Der Edge-Gateway-Docker muss alle von den Beacon Agenten erhaltenen Device-Messdaten zunächst einmal vorverarbeiten, um Mehrfachübertragungen auszufiltern und die einzelnen Datenquellen zu authentifizieren. Anschließend werden die relevanten Sensordaten zu einem werthaltigen Datensatz mit entsprechendem Zeitkontext zusammengefügt und über das IT-Netzwerk an den dafür zuständigen digitalen Zwilling übermittelt.

Standardkonforme Sicherheitsüberlegungen

Da die gesamte Docker-Technologie inzwischen einen De-facto-Standard bildet, der in der Informationstechnologie seit Jahren millionenfach zur Auslieferung, Pflege und Weiterentwicklung von Anwendungssoftware genutzt wird, schaffen Docker-basierte Edge-Gateway-Applikationen auch ein interessantes neues Betätigungsfeld für IT-Softwareentwickler. Eine Smart-Factory-Anwendung, die direkt in der OT-Ebene zum Einsatz kommen soll und per Ethernet-LAN mit der IT-Umgebung oder sogar einer Cloud kommuniziert, lässt sich per Docker-Container vollständig hardwareunabhängig entwickeln und auf den Geräten verschiedener Hersteller mit entsprechender Container-Engine einsetzen. Die Docker-Technologie könnte daher in der Automatisierungstechnik zu einem Paradigmenwechsel führen, da hier das Potenzial für ein neues Software-Marktsegment beachtlicher Größe schlummert, in das schon jetzt immer mehr branchenfremde Anbieter einsteigen. Dadurch ergeben sich allerdings auch weitere Sicherheitsprobleme.

Der Autor: Klaus-Dieter Walter ist CEO bei SSV Software Systems.

© SSV Software Systems

Docker-Technologie wurde definitiv nicht unter Cybersecurity-Aspekten entwickelt. Vielmehr wurde stattdessen offensichtlich das Ziel verfolgt, eine komponentenbasierte – also hochgradig modulare – Lösung für besonders wartungsfreundliche Informationstechnik-Anwendungen zu schaffen, die sich über eine externe Registry bei Bedarf einfach austauschen lassen. Da IT-Softwareentwickler die Verantwortung hinsichtlich der Security in der Regel bei einem Admin sehen, ist zu beachten, dass vernetzte Automatisierungsapplikationen durch den Einsatz von Docker-Containern nicht noch unsicherer werden, als sie es ohnehin schon sind.

Ein möglicher Lösungsansatz für dieses Problem ist die Anwendung einer Norm, wie die DIN EN IEC 62443 zur IT-Sicherheit für industrielle Automatisierungssysteme. Da ein Edge-Docker eine kommunikationsfähige Automatisierungskomponente bildet, eignet sich besonders der Teil IEC 62443-4-1 (Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung). Er spezifiziert die Anforderungen an den „gesicherten Entwicklungsprozess“ für industrielle Systeme, die im OT-Umfeld zum Einsatz kommen. Dabei wird der gesamte Lebenszyklus betrachtet, also die IT-Sicherheitsanforderungen vom Entwurf, über die sichere Implementierung, Verifikation, Validierung sowie dem zwingend erforderlichen Patch-Management bis zur Außerbetriebnahme und fachgerechten Entsorgung.