IIoT-Gateway sicher betreiben: Zertifikate, VPN und Benutzerrechte in OT-Netzen richtig umsetzen

→ Produktkategorie: IIoT Lösungen

 

Ein neues IIoT-Gateway wird im Schaltschrank installiert.

Die Verbindung zum MQTT-Broker funktioniert, Messwerte erscheinen im Dashboard und der Servicetechniker kann bei Bedarf aus der Ferne auf das System zugreifen.

Technisch scheint damit alles erledigt.

Doch auf dem Gateway ist noch das Standardpasswort aktiv, das Webinterface ist aus mehreren Netzen erreichbar und das TLS-Zertifikat läuft in wenigen Wochen ab.

Aus einer funktionierenden IIoT-Anbindung wird damit schnell ein unnötiges Sicherheitsrisiko.

Das zentrale Problem:

Ein IIoT-Gateway verbindet häufig zwei Bereiche mit sehr unterschiedlichen Sicherheitsanforderungen: die operative Feldebene beziehungsweise OT und übergeordnete IT-, Cloud- oder Fernwartungsnetze.

Die Sicherheitsbetrachtung darf sich deshalb nicht auf den Sensor beschränken.

Entscheidend ist die gesamte Kommunikationskette:

Sensor / Feldgerät → Feldbus → Edge-Gateway → OT-Firewall / DMZ → MQTT / HTTPS → Broker / Server / Cloud

Zusätzlich kommen häufig administrative Zugänge hinzu:

Service-PC → VPN / Remote Access → freigegebener Administrationszugang → Gateway

Für einen sicheren Betrieb müssen deshalb mehrere Schutzebenen zusammenspielen:

• Netzsegmentierung,
• Firewall-Regeln,
• verschlüsselte Kommunikation,
• Zertifikate,
• eindeutige Benutzerkonten,
• Rollen und Rechte,
• kontrollierter Fernzugriff,
• Firmware- und Patchmanagement,
• Logging,
• Zeitsynchronisation,
• Backup und Wiederherstellung,
• klare Verantwortlichkeiten.

Besonders wichtig ist die Unterscheidung:

TLS ≠ VPN ≠ Benutzerberechtigung

Diese Mechanismen lösen unterschiedliche Aufgaben.

TLS schützt eine einzelne Kommunikationsverbindung, ein VPN schafft einen geschützten Netzwerktunnel und Benutzerrechte entscheiden, was eine authentifizierte Person oder ein Dienst tatsächlich tun darf.

Ein sicher betriebenes IIoT-Gateway benötigt deshalb nicht „eine Sicherheitsfunktion“, sondern ein abgestimmtes Sicherheitskonzept über den gesamten Lebenszyklus.

IIoT-Lösungen für die Verbindung von Sensorik, Feldgeräten, Edge-Systemen und übergeordneten IT-/OT-Systemen finden Sie bei ICS Schneider unter IIoT Lösungen. Weitere industrielle Feldgeräte und Integrationsmöglichkeiten finden Sie unter Siemens Prozessinstrumentierung.

Warum das IIoT-Gateway ein besonders kritischer Netzpunkt ist

Ein Sensor besitzt häufig nur eine begrenzte Kommunikationsfunktion.

Ein IIoT-Gateway kann dagegen mehrere Aufgaben gleichzeitig übernehmen:

• Feldgeräte abfragen,
• Messwerte verarbeiten,
• Messwerte skalieren,
• Zeitstempel erzeugen,
• lokale Alarme auswerten,
• Daten puffern,
• MQTT- oder HTTPS-Verbindungen aufbauen,
• Konfiguration über Webinterface oder andere Administrationsdienste ermöglichen,
• Fernwartungsverbindungen unterstützen.

Damit besitzt das Gateway häufig Kommunikationsbeziehungen sowohl in Richtung:

Maschine / Prozess

als auch in Richtung:

IT / Rechenzentrum / Cloud

Das Gateway wird zur Vertrauensgrenze

Ein kompromittiertes Gateway kann theoretisch nicht nur falsche Messdaten übertragen.

Abhängig von seiner Konfiguration könnte es auch als Ausgangspunkt für weitere Zugriffe auf angeschlossene Netze dienen.

Deshalb sollte ein Gateway grundsätzlich nach dem Prinzip betrachtet werden:

Nur die Kommunikationsbeziehungen zulassen, die für seine konkrete Aufgabe tatsächlich benötigt werden.

IT, OT und Cloud logisch trennen

Eine typische IIoT-Architektur sollte nicht aus einem einzigen großen Ethernet-Netz bestehen.

Sinnvoll ist eine Trennung verschiedener Sicherheitszonen.

Vereinfacht:

Feldgeräte → Maschinen-/OT-Netz → Edge-Zone → industrielle DMZ → IT / Cloud

Warum diese Trennung wichtig ist

Ein kompromittierter Büro-PC sollte nicht automatisch Netzwerkzugriff auf:

• SPS-Systeme,
• Messumformer,
• Antriebe,
• IIoT-Gateways

besitzen.

Umgekehrt sollte ein Feldgerät nicht beliebige Verbindungen in das Unternehmensnetz aufbauen können.

Zonen und Kommunikationswege definieren

Für jede Verbindung sollte dokumentiert werden:

Quelle	Ziel	Protokoll	Richtung	Zweck
Feldgerät	Gateway	Feldprotokoll	lokal	Messwerte erfassen
Gateway	MQTT-Broker	MQTT über TLS	ausgehend	Messdaten übertragen
Gateway	Zeitserver	NTP	ausgehend	Zeitsynchronisation
Service-Netz	Gateway	HTTPS / administrativer Dienst	kontrolliert	Administration

Damit wird sichtbar, welche Verbindungen wirklich benötigt werden.

Netzsegmentierung statt flachem Netzwerk

Netzsegmentierung bedeutet, dass Systeme mit unterschiedlichen Aufgaben oder Schutzbedarfen in getrennten Netzwerkbereichen betrieben werden.

Die Kommunikation zwischen diesen Bereichen wird kontrolliert.

Beispiel

Ungünstig:

Büronetz + SPS + Messgeräte + Gateway + Fernwartungs-PC = ein gemeinsames Subnetz

Besser:

IT-Netz ↔ Firewall / DMZ ↔ OT-Netz ↔ Maschinenzelle

Vorteil bei einem Sicherheitsvorfall

Segmentierung kann verhindern, dass sich ein Problem ungehindert von einem Bereich auf den nächsten ausbreitet.

Sie reduziert damit die erreichbare Angriffsfläche.

Segmentierung darf nicht nur auf dem Papier existieren

Getrennte IP-Adressbereiche allein sind noch keine wirksame Sicherheitsgrenze.

Entscheidend ist, dass der Datenverkehr zwischen den Zonen tatsächlich kontrolliert wird.

Firewall nach dem Allowlist-Prinzip konfigurieren

Eine häufig sinnvolle Grundidee lautet:

Standardmäßig sperren → nur benötigte Verbindungen gezielt freigeben

Nicht „alle Ports zwischen Gateway und Server freigeben“

Stattdessen sollte eine Regel möglichst konkret definieren:

• Quell-IP beziehungsweise Quellnetz,
• Ziel-IP beziehungsweise Zielnetz,
• Protokoll,
• Zielport,
• Kommunikationsrichtung.

Beispiel

Das Gateway soll Messwerte ausschließlich an einen internen MQTT-Broker senden.

Dann benötigt es nicht automatisch Zugriff auf:

• beliebige Internetserver,
• Dateifreigaben,
• Drucker,
• Domänencontroller,
• andere Maschinenzellen.

Die erlaubte Kommunikation sollte möglichst genau dem tatsächlichen Datenfluss entsprechen.

Ausgehende Verbindungen bevorzugen

Viele IIoT-Anwendungen können so aufgebaut werden, dass das Gateway die Verbindung selbst nach außen initiiert.

Beispiel:

Gateway → MQTT-Broker

statt:

externes Netz → direkte eingehende Verbindung zum Gateway

Warum das vorteilhaft ist

Eine ausgehende Verbindung lässt sich häufig wesentlich kontrollierter über Firewall-Regeln abbilden.

Das Gateway muss dafür nicht allgemein aus externen Netzen erreichbar sein.

Administration getrennt behandeln

Die Datenübertragung und der administrative Fernzugriff sollten als zwei getrennte Kommunikationsbeziehungen betrachtet werden.

Nur weil ein Gateway Daten an einen Broker übertragen darf, müssen seine administrativen Dienste nicht aus demselben Netz erreichbar sein.

Was TLS tatsächlich schützt

TLS schützt Daten während der Übertragung zwischen zwei Kommunikationspartnern.

Typische Anwendungen sind:

• HTTPS,
• MQTT über TLS,
• verschlüsselte API-Verbindungen.

TLS bietet insbesondere

• Verschlüsselung der übertragenen Daten,
• Schutz gegen unbemerkte Manipulation während der Übertragung,
• Authentifizierung mindestens einer Kommunikationsseite über Zertifikate.

TLS schützt nicht automatisch das gesamte Gateway

Eine verschlüsselte MQTT-Verbindung verhindert beispielsweise nicht:

• ein schwaches Administratorpasswort,
• einen unnötig erreichbaren Administrationsdienst,
• veraltete Firmware,
• zu weitreichende Benutzerrechte.

Deshalb gilt:

Verschlüsselung ist ein wichtiger Baustein, aber kein Ersatz für Systemhärtung und Zugriffskontrolle.

TLS-Zertifikate richtig verwalten

Ein Zertifikat verbindet eine digitale Identität mit einem kryptografischen Schlüssel.

Bei einer TLS-Verbindung wird damit beispielsweise geprüft:

Kommuniziere ich tatsächlich mit dem vorgesehenen Server?

Typische Bestandteile eines Zertifikatsmanagements

Für jedes produktive Gateway sollten mindestens dokumentiert werden:

• Geräte-ID,
• Hostname,
• verwendetes Zertifikat,
• ausstellende CA,
• Gültigkeitsbeginn,
• Ablaufdatum,
• Verwendungszweck,
• Verantwortlicher für die Erneuerung.

Ablaufdatum ist ein Betriebsrisiko

Ein technisch einwandfreies Gateway kann plötzlich keine Daten mehr übertragen, wenn sein Zertifikat nicht mehr gültig ist.

Deshalb sollte gelten:

Zertifikatsablauf überwachen → rechtzeitig erneuern → Verbindung anschließend testen

Keine Zertifikatswarnungen dauerhaft ignorieren

Problematisch sind Einstellungen wie:

„Zertifikatsprüfung deaktivieren“

nur damit eine Verbindung schneller funktioniert.

Damit wird ein wesentlicher Teil der Serveridentitätsprüfung ausgehebelt.

Client-Zertifikate und mTLS einsetzen

Bei normalem TLS weist sich typischerweise der Server gegenüber dem Client aus.

Bei gegenseitiger Authentifizierung – häufig als:

mTLS = mutual TLS

bezeichnet – besitzt auch das Gateway ein eigenes Client-Zertifikat.

Prinzip

Der Broker prüft:

Ist dieses Gateway ein zugelassener Client?

und das Gateway prüft:

Ist dies der vorgesehene Broker?

Vorteil gegenüber einem gemeinsamen Passwort

Bei individuellen Zertifikaten kann jedes Gateway eine eigene Identität erhalten.

Wird ein einzelnes Gerät außer Betrieb genommen oder kompromittiert, kann dessen Berechtigung gezielt entzogen werden, ohne alle anderen Gateways gleichzeitig umzustellen.

Private Schlüssel schützen

Das Client-Zertifikat selbst ist nicht das eigentliche Geheimnis.

Kritisch ist der zugehörige private Schlüssel.

Dieser sollte:

• nicht unverschlüsselt auf Service-Laptops verteilt,
• nicht per E-Mail verschickt,
• nicht gemeinsam für viele Gateways verwendet

werden.

MQTT sicher betreiben

MQTT ist für IIoT-Anwendungen gut geeignet, weil Daten effizient zwischen Publishern und Subscribern ausgetauscht werden können.

Security muss jedoch separat konfiguriert werden.

Typische Sicherheitsbausteine

• TLS-Verschlüsselung,
• Serverzertifikat prüfen,
• Gateway authentifizieren,
• individuelle Benutzer oder Zertifikate verwenden,
• Topic-Berechtigungen einschränken,
• nicht benötigte anonyme Zugänge deaktivieren.

Topic-Berechtigungen sind besonders wichtig

Ein Gateway, das ausschließlich Messdaten einer Maschine veröffentlicht, benötigt beispielsweise nicht automatisch Zugriff auf alle MQTT-Topics des Unternehmens.

Statt:

Gateway darf publish/subscribe auf #

besser beispielsweise:

publish: plant/werk1/linie2/maschine4/measurement/#

und nur diejenigen Subscribe-Rechte, die für die Anwendung tatsächlich benötigt werden.

Publish und Subscribe getrennt betrachten

Ein reiner Messdatenlogger muss möglicherweise:

publish

dürfen, aber überhaupt keine Befehle:

subscribe

müssen.

Damit kann die Berechtigung erheblich eingeschränkt werden.

Benutzerrollen und Least Privilege umsetzen

Nicht jeder Benutzer benötigt Administratorrechte.

Ein sinnvolles Rollenmodell könnte beispielsweise unterscheiden zwischen:

Rolle	Typische Berechtigung
Viewer	Status und Messwerte ansehen
Operator	Betriebsparameter innerhalb freigegebener Grenzen ändern
Service	Diagnose, Backup und definierte Wartungsfunktionen
Administrator	Netzwerk, Benutzer, Zertifikate und Security-Einstellungen ändern

Prinzip der geringsten notwendigen Rechte

Ein Benutzer sollte nur die Rechte besitzen, die für seine Aufgabe tatsächlich erforderlich sind.

Dieses Prinzip wird häufig bezeichnet als:

Least Privilege

Warum das praktisch wichtig ist

Ein Servicetechniker, der lediglich:

• Diagnosedaten lesen,
• Messkanäle prüfen,
• ein Backup erstellen

muss, benötigt nicht zwangsläufig die Berechtigung:

• Benutzer zu löschen,
• Firewall-Regeln zu ändern,
• Zertifikate auszutauschen.

Standardpasswörter und gemeinsame Konten vermeiden

Ein Gateway sollte nicht mit werkseitigen Standardzugangsdaten in den produktiven Betrieb übernommen werden.

Problem gemeinsamer Konten

Wenn zehn Mitarbeiter dasselbe Konto:

admin

verwenden, ist später kaum nachvollziehbar:

Wer hat die Einstellung geändert?

Besser

• individuelle Benutzerkonten,
• eindeutige Rollen,
• zentrale Passwortverwaltung beziehungsweise Passwort-Tresor,
• gesicherter Prozess für Notfallzugänge,
• Konten ausgeschiedener Mitarbeiter zeitnah deaktivieren.

Servicekonten dokumentieren

Auch technische Konten für:

• MQTT,
• API-Zugriff,
• Backup,
• Fernwartung

sollten eindeutig einem Verwendungszweck zugeordnet sein.

Fernwartung über VPN oder kontrollierten Remote Access

Direkter Zugriff aus dem Internet auf ein IIoT-Gateway sollte vermieden werden.

Ein typisches Fernwartungskonzept nutzt stattdessen einen kontrollierten Zugangsweg.

Beispiel:

Servicetechniker → authentifizierter Remote Access / VPN → definierte OT-Zone → bestimmtes Gateway

Keine pauschale Netzwerkfreigabe

Ein VPN-Benutzer sollte nicht allein aufgrund einer erfolgreichen Anmeldung Zugriff auf das gesamte Produktionsnetz erhalten.

Zusätzlich sollten Regeln festlegen:

• welcher Benutzer,
• auf welche Anlage,
• mit welchem Protokoll,
• zu welchem Zeitpunkt

zugreifen darf.

Fernzugriff nur bei Bedarf

Je nach Anlagenkonzept kann es sinnvoll sein, externe Wartungszugänge nur:

• für ein definiertes Zeitfenster,
• nach Freigabe durch den Betreiber,
• für eine konkrete Maschine

zu aktivieren.

Mehrfaktor-Authentifizierung

Wenn die verwendete Remote-Access-Lösung dies unterstützt, kann eine zusätzliche Authentifizierungsebene für externe Zugänge sinnvoll sein.

Dabei wird nicht nur ein Passwort verlangt, sondern ein weiterer Authentifizierungsfaktor.

Warum VPN allein nicht genügt

Ein VPN verschlüsselt und authentifiziert einen Netzwerktunnel.

Es beantwortet jedoch nicht automatisch die Frage:

Was darf der Benutzer nach Aufbau des Tunnels tun?

Beispiel

Ungünstig:

VPN verbunden → komplettes OT-Netz erreichbar

Besser:

VPN verbunden → Firewall-Regel → nur freigegebenes Gateway über den benötigten Administrationsdienst erreichbar

TLS innerhalb eines VPN bleibt sinnvoll

Ein VPN ist kein zwingender Grund, die Anwendungskommunikation unverschlüsselt zu betreiben.

Wo technisch sinnvoll, kann beispielsweise:

MQTT über TLS innerhalb der abgesicherten Netzwerkarchitektur

verwendet werden.

Damit bleiben die Schutzmechanismen auf mehreren Ebenen erhalten.

Ports und Dienste auf das Notwendige reduzieren

Jeder aktive Netzwerkdienst erweitert grundsätzlich die erreichbare Funktionsfläche des Systems.

Deshalb sollte geprüft werden:

• wird ein administrativer Shell-Zugang benötigt?
• wird ein Webinterface benötigt?
• wird ein Dateitransferdienst benötigt?
• wird ein lokaler MQTT-Broker benötigt?
• wird eine serielle Netzwerkbrücke benötigt?

Nicht benötigte Dienste deaktivieren

Wenn eine Funktion nicht eingesetzt wird, sollte geprüft werden, ob sie abgeschaltet werden kann.

Besonders kritisch

Historisch gewachsene Systeme enthalten teilweise Dienste, die nur für:

• Inbetriebnahme,
• Testbetrieb,
• temporäre Fehlersuche

aktiviert wurden.

Nach Projektabschluss bleiben sie jedoch dauerhaft eingeschaltet.

Security-Abnahme vor Übergabe

Vor der Übergabe an den Betrieb sollte deshalb eine Liste erstellt werden:

Dienst → Port → Zweck → benötigter Kommunikationspartner → dauerhaft erforderlich?

Secure Boot und signierte Firmware unterscheiden

Die Begriffe:

Secure Boot

und:

signiertes Firmware-Update

sind nicht identisch.

Secure Boot

Secure Boot bezeichnet grundsätzlich einen Mechanismus, bei dem beim Start geprüft wird, ob die auszuführenden Softwarebestandteile aus einer vertrauenswürdigen beziehungsweise autorisierten Quelle stammen.

Signierte Firmware

Bei einem signierten Update kann das Gerät vor der Installation prüfen, ob:

• das Firmwarepaket authentisch ist,
• das Paket nicht unbemerkt verändert wurde.

Gerätespezifisch prüfen

Nicht jedes Gateway unterstützt beide Funktionen.

Deshalb sollte in der konkreten Geräte- und Firmwaredokumentation geprüft werden:

• welche Boot-Sicherheitsfunktionen vorhanden sind,
• wie Updates validiert werden,
• welche Einstellungen dafür erforderlich sind.

Firmware- und Patchmanagement organisieren

Ein Gateway bleibt häufig viele Jahre in einer Maschine oder Anlage installiert.

Die Softwareumgebung verändert sich jedoch weiter.

Deshalb muss geklärt sein

• wer Security-Hinweise des Herstellers beobachtet,
• wer neue Firmware bewertet,
• wie Updates getestet werden,
• wann sie in die Produktionsanlage eingespielt werden,
• wie bei Problemen zurückgerollt wird.

Nicht jedes Update sofort ungeprüft installieren

OT-Systeme besitzen besondere Anforderungen an:

• Verfügbarkeit,
• Protokollkompatibilität,
• Treiber,
• Anwendungssoftware.

Ein Security-Update sollte deshalb nicht ignoriert, aber auch nicht ohne Bewertung direkt in eine laufende Produktionsanlage eingespielt werden.

Typischer Prozess

Hinweis erhalten → Relevanz prüfen → Risiko bewerten → Backup → Test → Wartungsfenster → Update → Funktionstest → dokumentieren

Security-Logging und Audit-Trail einrichten

Bei einer Störung oder einem Sicherheitsvorfall ist entscheidend, nachvollziehen zu können, was zuvor passiert ist.

Sinnvolle Log-Ereignisse

• erfolgreiche Anmeldung,
• fehlgeschlagene Anmeldung,
• Benutzeränderung,
• Rollenänderung,
• Konfigurationsänderung,
• Firmware-Update,
• Zertifikatswechsel,
• Verbindungsabbruch zum Broker,
• Neustart des Gateways,
• VPN- beziehungsweise Fernwartungsverbindung.

Lokale Logs allein können unzureichend sein

Wenn das Gateway nur einen kleinen internen Ringspeicher besitzt, können ältere Ereignisse schnell überschrieben werden.

Wo verfügbar und sinnvoll, können Logs deshalb zusätzlich an ein zentrales System übertragen werden.

Logging benötigt korrekte Zeit

Ein Ereignisprotokoll:

Login fehlgeschlagen – 01.01.1970 00:02

ist für eine spätere Analyse kaum hilfreich.

Damit wird die Zeitsynchronisation selbst zu einem wichtigen Bestandteil des Security-Konzepts.

Zeitserver und Zertifikatsprüfung berücksichtigen

Eine korrekte Systemzeit wird bei IIoT-Gateways aus mehreren Gründen benötigt.

Unter anderem für:

• Zeitstempel der Messdaten,
• Audit-Logs,
• Alarmhistorie,
• Zertifikatsgültigkeit.

Falsche Zeit kann TLS-Verbindungen verhindern

Ein Zertifikat besitzt einen definierten Gültigkeitszeitraum.

Ist die Uhrzeit des Gateways falsch, kann ein eigentlich gültiges Zertifikat beispielsweise als:

noch nicht gültig

oder:

bereits abgelaufen

interpretiert werden.

Definierte Zeitquelle verwenden

Statt jedes Gateway beliebige Internet-Zeitserver verwenden zu lassen, sollte in industriellen Netzen eine definierte Zeitarchitektur geplant werden.

Beispiel:

interner Zeitserver → OT-Zeitserver → Gateways

Konfigurationen und Schlüsselmaterial sichern

Ein Gateway kann nach einem Hardwaredefekt gegebenenfalls vergleichsweise schnell ersetzt werden.

Die größere Herausforderung ist häufig:

Wie wird die ursprüngliche Konfiguration zuverlässig wiederhergestellt?

Ein Backup sollte je nach System enthalten

• Netzwerkkonfiguration,
• Feldgerätezuordnung,
• Datenmodell,
• MQTT-Topics,
• Alarmgrenzen,
• Benutzer- und Rollenkonfiguration,
• Zertifikatsinformationen,
• Firmwareversion.

Geheimnisse nicht ungeschützt sichern

Ein vollständiges Konfigurationsbackup kann auch:

• Passwörter,
• API-Keys,
• private Schlüssel

enthalten.

Solche Backups müssen entsprechend geschützt gespeichert werden.

Restore testen

Ein Backup ist erst dann wirklich wertvoll, wenn bekannt ist, wie es wieder eingespielt wird.

Deshalb sollte zumindest für kritische Gateways ein dokumentierter Wiederherstellungsprozess existieren.

Passwörter, API-Keys und private Schlüssel schützen

Neben Benutzerpasswörtern existieren in IIoT-Systemen häufig weitere Zugangsdaten.

Beispiele:

• MQTT-Passwort,
• API-Key,
• Cloud-Token,
• VPN-Schlüssel,
• privater TLS-Schlüssel.

Diese Daten gehören nicht

• in frei zugängliche Tabellen,
• in unverschlüsselte Projektordner,
• in öffentlich zugängliche Quellcode-Repositories,
• auf Etiketten am Schaltschrank.

Individuelle Credentials verwenden

Ein einziges Kennwort für:

alle Gateways aller Werke

vergrößert die Auswirkungen eines einzelnen kompromittierten Zugangs erheblich.

Wo möglich, sollten Identitäten und Geheimnisse daher individuell vergeben werden.

Cybersecurity und Anlagenverfügbarkeit gemeinsam betrachten

OT-Sicherheit besitzt eine Besonderheit:

Eine Sicherheitsmaßnahme darf nicht unkontrolliert die Anlagenverfügbarkeit gefährden.

Beispiel Zertifikatserneuerung

Ein neues Zertifikat wird installiert.

Der Broker vertraut der neuen CA jedoch noch nicht.

Ergebnis:

Security formal geändert → Telemetrie vollständig ausgefallen

Beispiel Firewall

Eine Regel wird verschärft und blockiert versehentlich:

NTP

Nach einem Neustart besitzt das Gateway eine falsche Uhrzeit.

Dadurch scheitert anschließend die TLS-Verbindung.

Änderungen deshalb kontrolliert durchführen

Für Security-relevante Änderungen sollten vorhanden sein:

• Änderungsantrag beziehungsweise Dokumentation,
• vorheriges Backup,
• definiertes Wartungsfenster,
• Funktionstest,
• Rollback-Möglichkeit.

Verantwortlichkeiten zwischen IT, OT und Service festlegen

Viele IIoT-Probleme entstehen nicht durch fehlende Technik, sondern durch unklare Zuständigkeiten.

Typische Fragen

• Wer erneuert das Gateway-Zertifikat?
• Wer verwaltet die Firewall-Regeln?
• Wer vergibt Servicekonten?
• Wer prüft Firmwareupdates?
• Wer überwacht fehlgeschlagene Anmeldungen?
• Wer sperrt externe Zugänge nach Projektende?
• Wer besitzt das Konfigurationsbackup?

Beispiel für eine Verantwortungsmatrix

Aufgabe	Typische Verantwortung
OT-Netzarchitektur	OT / Automatisierung mit IT-Security
Firewall-Regeln	Netzwerk-/Security-Verantwortliche
Gateway-Konfiguration	Automatisierung / Systemintegrator
Zertifikatsmanagement	klar definierter IT-/OT-Verantwortlicher
Firmwarebewertung	Betreiber zusammen mit Hersteller / Integrator
Fernwartungsfreigabe	Anlagenbetreiber
Servicezugang	personengebunden und dokumentiert

Die konkrete Zuordnung hängt von der Organisation ab.

Entscheidend ist, dass jede Aufgabe eindeutig vergeben ist.

Typische Sicherheits- und Konfigurationsfehler

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
Gateway ist direkt aus dem Internet erreichbar	Portweiterleitung statt kontrolliertem Fernzugriff	Netzarchitektur und Firewall-Regeln prüfen
Alle Servicetechniker verwenden dieselben Administrator-Zugangsdaten	Standard- oder gemeinsames Konto nicht ersetzt	Individuelle Konten und Rollen einrichten
MQTT-Verbindung funktioniert nur ohne Zertifikatsprüfung	CA, Hostname oder Zertifikat falsch konfiguriert	Zertifikatskette und Serveridentität prüfen
Datenübertragung stoppt plötzlich zu einem festen Datum	Zertifikat abgelaufen	Gültigkeitsdatum und Zertifikatsmonitoring prüfen
Neues Gateway meldet „certificate not yet valid“	Systemzeit falsch	NTP und Zeitzone prüfen
VPN-Benutzer kann sämtliche OT-Systeme erreichen	Fernzugriff zu weit freigegeben	Firewall und Zugriffsrollen begrenzen
Gateway kann beliebige Internetadressen erreichen	Keine Egress-Filterung	Ausgehende Kommunikationsziele einschränken
Nicht nachvollziehbar, wer Konfiguration geändert hat	Gemeinsames Benutzerkonto	Personengebundene Konten und Audit-Logs verwenden
Nach Firmwareupdate keine Messdaten mehr	Kompatibilitätsproblem oder geänderte Konfiguration	Backup, Release Notes und Funktionstest prüfen
Gateway besitzt mehrere unbekannte offene Ports	Werkseitige oder temporäre Dienste aktiv	Diensteliste erstellen und unnötige Funktionen deaktivieren
Zertifikat wurde erneuert, Verbindung bleibt unterbrochen	Neue CA oder Zertifikatskette wird nicht vertraut	Trust Store auf beiden Seiten prüfen
Logs zeigen falsche Reihenfolge der Ereignisse	Uhren nicht synchronisiert	NTP-Konzept kontrollieren
Ersatzgateway kann nicht schnell in Betrieb genommen werden	Kein aktuelles Backup vorhanden	Backup- und Restore-Prozess einführen
Externer Servicezugang bleibt dauerhaft aktiv	Keine zeitliche Freigabe beziehungsweise kein Offboarding	Remote-Access-Prozess prüfen

Systematische Security-Inbetriebnahme eines IIoT-Gateways

Für die Inbetriebnahme empfiehlt sich ein strukturierter Ablauf.

1. Gateway eindeutig inventarisieren: Gerät, Seriennummer, Standort, IP-Adresse und Verantwortlichen dokumentieren.
2. Netzwerkzonen festlegen: Feld-, OT-, DMZ-, IT- und Cloud-Verbindungen unterscheiden.
3. Datenfluss dokumentieren: Quelle, Ziel, Protokoll und Kommunikationsrichtung festlegen.
4. Standardzugangsdaten ändern: Werkseitige Kennwörter vor Produktivbetrieb ersetzen.
5. Benutzerrollen einrichten: Anzeige-, Bedien-, Service- und Administratorrechte nach Bedarf trennen.
6. Nicht benötigte Konten deaktivieren: Test- und Installationskonten entfernen oder sperren.
7. Nicht benötigte Dienste deaktivieren: Offene Ports und Netzwerkdienste prüfen.
8. Firewall-Regeln definieren: Nur erforderliche Kommunikationsbeziehungen freigeben.
9. Direkte Interneterreichbarkeit vermeiden: Keine unnötigen Portweiterleitungen auf das Gateway.
10. TLS konfigurieren: MQTT, HTTPS und weitere geeignete Verbindungen verschlüsseln.
11. Zertifikatsprüfung aktivieren: Vertrauenswürdige CA und korrekte Serveridentität verwenden.
12. Gateway-Identität festlegen: Wenn vorgesehen, individuelles Client-Zertifikat beziehungsweise mTLS konfigurieren.
13. MQTT-Rechte begrenzen: Nur notwendige Publish-/Subscribe-Topics zulassen.
14. Fernzugriff einrichten: VPN oder definierte Remote-Access-Lösung statt direkter Internetzugriffe verwenden.
15. Fernzugriffsrechte beschränken: Benutzer, Zielsystem und Protokoll einschränken.
16. Zeitsynchronisation prüfen: Definierten NTP- beziehungsweise Zeitserver verwenden.
17. Logging aktivieren: Anmeldungen, Änderungen, Fehler und Verbindungsereignisse protokollieren.
18. Firmwarestand dokumentieren: Aktuelle und freigegebene Version festhalten.
19. Updateverfahren definieren: Verantwortlichen und Wartungsprozess festlegen.
20. Backup erstellen: Nach erfolgreicher Inbetriebnahme einen definierten Ausgangszustand sichern.
21. Restore-Verfahren dokumentieren: Vorgehen für Ersatzgerät oder Hardwaredefekt festlegen.
22. Zertifikatsablauf dokumentieren: Erinnerung beziehungsweise Monitoring vor Ablauf einrichten.
23. Funktionstest durchführen: Messdaten, Alarme, Broker-Verbindung und lokale Funktionen prüfen.
24. Security-Test durchführen: Nicht freigegebene Zugriffe und Benutzerrechte praktisch überprüfen.
25. Abnahme dokumentieren: Netzwerkplan, Benutzer, Zertifikate, Ports, Firmware und Backupstand festhalten.

Praxisbeispiel: MQTT-Verbindung fällt nach Zertifikatsablauf aus

Ein IIoT-Gateway erfasst Messdaten einer Produktionsanlage.

Die Messwerte werden über MQTT an einen zentralen Broker übertragen.

Ausgangssituation

Das System funktioniert seit fast zwei Jahren störungsfrei.

Am Montagmorgen fehlen plötzlich sämtliche Messwerte im Dashboard.

Die angeschlossene Sensorik selbst arbeitet korrekt.

Schritt 1: Feldkommunikation prüfen

Das Gateway liest die angeschlossenen Messgeräte weiterhin korrekt aus.

Damit ist die Verbindung:

Sensor → Gateway

funktionsfähig.

Schritt 2: Netzwerk prüfen

Das Gateway erreicht den vorgesehenen Broker über das Netzwerk.

Die Firewall blockiert die Verbindung nicht.

Schritt 3: Gateway-Log prüfen

Im Ereignisprotokoll erscheint eine TLS-Fehlermeldung.

Die Verbindung wird während des Zertifikatsaufbaus beendet.

Schritt 4: Zertifikat kontrollieren

Das Client-Zertifikat des Gateways ist am Wochenende abgelaufen.

Es existierte:

• keine automatische Verlängerung,
• keine Erinnerung,
• kein zentral geführtes Zertifikatsinventar.

Schritt 5: Zertifikat erneuern

Ein neues gültiges Zertifikat wird entsprechend des vorgesehenen PKI-Prozesses ausgestellt und auf dem Gateway installiert.

Schritt 6: Broker-Berechtigung prüfen

Der Broker akzeptiert die neue Gateway-Identität und die vorgesehenen Topic-Berechtigungen werden kontrolliert.

Schritt 7: Verbindung wiederherstellen

Die MQTT-Verbindung wird erneut aufgebaut und die Messwerte werden wieder übertragen.

Die eigentliche Ursache

Das technische Problem war:

abgelaufenes Zertifikat

Die organisatorische Ursache war jedoch:

kein Zertifikats-Lifecycle-Management

Verbesserte Lösung

Für alle Gateways werden anschließend dokumentiert:

• Geräte-ID,
• Zertifikats-ID,
• Ablaufdatum,
• zuständige Person,
• Erneuerungsprozess.

Zusätzlich wird mehrere Wochen vor Ablauf eine Warnung erzeugt.

Weiterer Security-Check

Während der Analyse wird festgestellt, dass das Gateway zusätzlich noch ein gemeinsames Administratorpasswort verwendet.

Dieses wird durch:

• individuelle Benutzerkonten,
• rollenbasierte Rechte,
• einen dokumentierten Notfallzugang

ersetzt.

Ergebnis

Das Beispiel zeigt:

IIoT-Cybersecurity ist keine einmalige Einstellung bei der Inbetriebnahme. Zertifikate, Benutzer, Firmware und Fernzugänge müssen über den gesamten Lebenszyklus des Gateways verwaltet werden.

Passende ICS-Produkte für IIoT-Anwendungen

Siemens SITRANS MS200 – IIoT Vibrations- und Temperatursensor

Ein konkretes IIoT-Produkt aus dem aktuellen ICS-Portfolio ist der Siemens SITRANS MS200 mit der Artikelnummer:

7MP2210-2AB21-2AB1

Der SITRANS MS200 ist ein drahtloser IIoT-Sensor zur Erfassung von:

• Vibration,
• Temperatur.

Er ist insbesondere für Anwendungen im Condition Monitoring beziehungsweise zur Zustandsüberwachung von Maschinen vorgesehen.

Auf der ICS-Produktseite wird der SITRANS MS200 ausdrücklich für die Nutzung in Kombination mit dem:

SITRANS CC220 Gateway

beschrieben.

Damit ergibt sich eine typische IIoT-Struktur:

SITRANS MS200 → SITRANS CC220 → übergeordnetes Monitoring-System

Warum diese Architektur für Cybersecurity relevant ist

Bei einer solchen Anwendung sollten mehrere Kommunikationsbereiche getrennt betrachtet werden.

Dazu gehören:

• die lokale Kommunikation zwischen Sensor und Gateway,
• die Kommunikation des Gateways mit übergeordneten Systemen,
• administrative Zugänge zum Gateway,
• Benutzer- und Servicezugänge.

Die Absicherung sollte deshalb nicht allein am Sensor erfolgen.

Entscheidend ist die komplette Kommunikationskette vom Feldgerät bis zum übergeordneten System.

Weitere Informationen finden Sie unter Siemens SITRANS MS200 bei ICS Schneider.

Siemens IIoT-Wägeelektronik für SIMATIC IOT2050

Ein weiteres direkt bei ICS gelistetes IIoT-Produkt ist die Siemens:

IIoT-Wägeelektronik 7MH4647-0KK00-0AA2

für den Einsatz mit dem SIMATIC IOT2050 Gateway.

Die Wägeelektronik besitzt einen Kanal zum Anschluss einer:

Wägezelle / DMS-Vollbrücke mit 1 … 4 mV/V

und dient zur Umwandlung des analogen Wägesignals in eine digitale Verarbeitung innerhalb einer IIoT-Architektur.

Typische IIoT-Struktur

Eine solche Anwendung kann vereinfacht aufgebaut sein als:

Wägezelle → IIoT-Wägeelektronik → SIMATIC IOT2050 → übergeordnetes System

Auch hier entsteht durch die Verbindung von lokaler Messwerterfassung und übergeordneter Datenverarbeitung eine Schnittstelle zwischen unterschiedlichen Ebenen der Automatisierungsarchitektur.

Security nicht auf die Messfunktion beschränken

Für die Cybersecurity sind deshalb zusätzlich zur eigentlichen Wägemessung beispielsweise relevant:

• Netzwerksegmentierung,
• erlaubte Kommunikationsverbindungen,
• Benutzerzugriffe,
• administrative Dienste,
• Firmware- und Softwarestände,
• Backup der Konfiguration.

Weitere Informationen finden Sie unter Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 bei ICS Schneider.

Welche ICS-Produkte passen zum Thema?

Anwendung	Passendes ICS-Produkt
Drahtlose Vibrations- und Temperaturüberwachung	Siemens SITRANS MS200 – 7MP2210-2AB21-2AB1
IIoT-Anbindung einer Wägezelle / DMS-Vollbrücke	Siemens IIoT-Wägeelektronik – 7MH4647-0KK00-0AA2
Condition-Monitoring-Anwendung mit drahtlosem Sensor	SITRANS MS200 in der auf der ICS-Seite beschriebenen Kombination mit SITRANS CC220
Digitalisierung einer Wägemessung	7MH4647-0KK00-0AA2 für SIMATIC IOT2050

Security-Funktionen immer anhand des konkreten Systems prüfen

Welche Cybersecurity-Funktionen tatsächlich verfügbar sind, hängt von:

• Gateway,
• Hardwareversion,
• Firmware beziehungsweise Betriebssystem,
• installierter Software,
• Netzwerkarchitektur

ab.

Funktionen wie:

• Secure Boot,
• mTLS,
• VPN,
• rollenbasierte Benutzerverwaltung,
• signierte Firmwareupdates,
• zentrales Security-Logging

sollten deshalb nicht pauschal einem Gerät zugeschrieben werden, nur weil es als IIoT- oder Gateway-Komponente eingesetzt wird.

Für die konkrete Planung müssen die tatsächlich unterstützten Security-Funktionen anhand der jeweiligen Geräte-, Firmware- und Softwaredokumentation geprüft werden.

IIoT-Lösungen bei ICS Schneider

Weitere Produkte und Lösungen für IIoT-Anwendungen finden Sie unter IIoT Lösungen bei ICS Schneider.

Weitere Siemens-Produkte für die industrielle Prozessinstrumentierung finden Sie unter Siemens Prozessinstrumentierung bei ICS Schneider.

Fazit

Ein IIoT-Gateway ist weit mehr als ein Protokollumsetzer.

Es verbindet häufig:

Feldtechnik ↔ OT ↔ IT ↔ Cloud

und wird dadurch zu einem besonders wichtigen Punkt innerhalb der Sicherheitsarchitektur.

Ein wirksames Schutzkonzept beginnt mit der Netzstruktur.

Statt eines flachen Netzes sollten:

• Feldgeräte,
• Maschinenzellen,
• Gateways,
• IT-Systeme,
• externe Zugänge

logisch getrennt und über definierte Kommunikationswege verbunden werden.

Firewalls sollten nur diejenigen Verbindungen erlauben, die tatsächlich benötigt werden.

Besonders vorteilhaft sind häufig Architekturen, bei denen das Gateway selbst eine definierte ausgehende Verbindung zum Broker oder Server herstellt und nicht allgemein aus externen Netzen erreichbar ist.

Für MQTT- und HTTPS-Verbindungen ist TLS ein zentraler Baustein.

Die Verschlüsselung allein reicht jedoch nicht.

Zertifikate müssen:

• korrekt geprüft,
• eindeutig zugeordnet,
• vor Ablauf erneuert

werden.

Mit individuellen Client-Zertifikaten beziehungsweise mTLS kann zusätzlich jedes Gateway eine eigene kryptografische Identität erhalten.

Auch innerhalb des MQTT-Brokers sollten Rechte begrenzt werden.

Ein Gateway benötigt nicht automatisch Zugriff auf alle Topics.

Dasselbe Prinzip gilt für Benutzer:

so viele Rechte wie nötig – so wenige wie möglich

Gemeinsame Administratorzugänge und unveränderte Standardpasswörter erschweren sowohl die Sicherheit als auch die Rückverfolgbarkeit.

Fernwartung sollte über einen kontrollierten Zugangsweg wie VPN beziehungsweise eine geeignete Remote-Access-Lösung erfolgen.

Ein erfolgreicher VPN-Aufbau darf jedoch nicht automatisch bedeuten, dass der Benutzer das gesamte OT-Netz erreicht.

Zusätzlich müssen über den Lebenszyklus berücksichtigt werden:

• Firmwareupdates,
• Security-Hinweise,
• Zertifikatslaufzeiten,
• Benutzerwechsel,
• Audit-Logs,
• Zeitsynchronisation,
• Backups,
• Wiederherstellung.

Für die Praxis gilt:

Gateway inventarisieren → IT-/OT-Zonen definieren → Kommunikationswege dokumentieren → Netz segmentieren → Firewall nach Allowlist-Prinzip konfigurieren → Standardkonten absichern → individuelle Rollen vergeben → TLS aktivieren → Zertifikate und Ablaufdaten verwalten → MQTT-Rechte begrenzen → Fernzugriff kontrollieren → unnötige Dienste deaktivieren → Firmwarestand verwalten → Logging und Zeitserver einrichten → Backup und Restore vorbereiten → Verantwortlichkeiten festlegen → Security regelmäßig erneut prüfen.

FAQ: IIoT-Gateway, TLS, VPN und OT-Cybersecurity

Warum ist ein IIoT-Gateway sicherheitskritisch?

Weil es häufig Kommunikationsbeziehungen zwischen Feldtechnik beziehungsweise OT und übergeordneten IT- oder Cloud-Systemen besitzt. Dadurch verbindet es Bereiche mit unterschiedlichen Schutzanforderungen.

Was ist Netzsegmentierung?

Netzsegmentierung bedeutet, dass Systeme in getrennte Netzwerkzonen aufgeteilt werden und die Kommunikation zwischen diesen Zonen kontrolliert wird.

Warum sollte ein IIoT-Gateway nicht direkt im Büronetz betrieben werden?

Eine direkte gemeinsame Netzwerkzone kann dazu führen, dass Büro- und Produktionssysteme gegenseitig unnötig erreichbar sind. Eine segmentierte Architektur reduziert diese Angriffsfläche.

Was bedeutet Defense in Depth?

Defense in Depth bezeichnet ein mehrschichtiges Sicherheitskonzept, bei dem nicht nur eine einzelne Maßnahme eingesetzt wird, sondern unter anderem Netzwerksegmentierung, Firewall, Zugriffskontrolle, Systemhärtung und Überwachung zusammenwirken.

Was ist eine industrielle DMZ?

Eine industrielle DMZ ist eine getrennte Netzwerkzone zwischen OT und anderen Netzen, über die definierte Dienste und Daten kontrolliert ausgetauscht werden können.

Was bedeutet Allowlisting bei einer Firewall?

Dabei wird grundsätzlich nur die Kommunikation zugelassen, die ausdrücklich für einen bekannten Zweck freigegeben wurde.

Sollte ein IIoT-Gateway direkt aus dem Internet erreichbar sein?

Direkte Interneterreichbarkeit sollte möglichst vermieden werden. Für Fernwartung sind kontrollierte und authentifizierte Remote-Access-Verfahren vorzuziehen.

Warum sind ausgehende Verbindungen häufig günstiger?

Wenn das Gateway die Verbindung selbst zu einem definierten Broker oder Server aufbaut, muss kein allgemein erreichbarer eingehender Dienst für die reine Telemetrie bereitgestellt werden.

Was ist TLS?

TLS ist ein kryptografisches Protokoll zur Absicherung von Netzwerkkommunikation. Es ermöglicht Verschlüsselung, Integritätsschutz und die Authentifizierung von Kommunikationspartnern über Zertifikate.

Was bedeutet MQTTS?

Damit wird üblicherweise MQTT-Kommunikation bezeichnet, die über TLS abgesichert ist.

Ist MQTT automatisch verschlüsselt?

Nein. Die Verschlüsselung muss innerhalb der jeweiligen Architektur entsprechend konfiguriert werden.

Was ist ein TLS-Zertifikat?

Ein Zertifikat verbindet eine digitale Identität mit einem kryptografischen Schlüssel und ermöglicht unter anderem die Prüfung, ob ein Kommunikationspartner vertrauenswürdig ist.

Was ist eine CA?

CA steht für Certificate Authority beziehungsweise Zertifizierungsstelle. Sie stellt Zertifikate aus beziehungsweise bildet einen Vertrauensanker innerhalb einer PKI.

Was passiert, wenn ein Gateway-Zertifikat abläuft?

Abhängig von der Konfiguration kann die authentifizierte beziehungsweise verschlüsselte Verbindung anschließend nicht mehr aufgebaut werden.

Warum muss der Ablauf von Zertifikaten überwacht werden?

Damit Zertifikate rechtzeitig erneuert werden können und kein ungeplanter Kommunikationsausfall entsteht.

Was ist mTLS?

mTLS steht für Mutual TLS. Dabei authentifizieren sich beide Kommunikationspartner gegenseitig über Zertifikate.

Warum sollte jedes Gateway ein eigenes Zertifikat erhalten?

Damit Geräte eindeutig identifiziert und Berechtigungen bei Bedarf für ein einzelnes Gateway geändert oder entzogen werden können.

Ist ein Client-Zertifikat geheim?

Das Zertifikat selbst muss nicht zwingend geheim sein. Besonders geschützt werden muss jedoch der zugehörige private Schlüssel.

Was sind MQTT-Topic-Rechte?

Damit wird festgelegt, auf welche Topics ein Client Daten veröffentlichen oder welche Topics er abonnieren darf.

Sollte ein Gateway Zugriff auf alle MQTT-Topics besitzen?

Normalerweise nur dann, wenn dies für seine Aufgabe tatsächlich erforderlich ist. Rechte sollten möglichst auf die benötigten Topic-Bereiche begrenzt werden.

Was bedeutet Least Privilege?

Ein Benutzer, Dienst oder Gerät erhält nur diejenigen Berechtigungen, die für seine konkrete Aufgabe erforderlich sind.

Welche Benutzerrollen sind bei einem Gateway sinnvoll?

Je nach Gerät können beispielsweise Anzeige-, Bedien-, Service- und Administratorrollen sinnvoll sein.

Warum sind gemeinsame Administratoraccounts problematisch?

Weil Änderungen später nicht eindeutig einer Person zugeordnet werden können und ein kompromittiertes gemeinsames Passwort mehrere Benutzer beziehungsweise Systeme betrifft.

Sollte das Standardpasswort bei der Inbetriebnahme geändert werden?

Ja. Werkseitige Standardzugangsdaten sollten nicht für den produktiven Betrieb beibehalten werden.

Was ist ein VPN?

Ein VPN stellt einen authentifizierten und verschlüsselten Tunnel zwischen Kommunikationspartnern beziehungsweise Netzwerken bereit.

Reicht ein VPN für sicheren Fernzugriff aus?

Nicht allein. Zusätzlich müssen unter anderem Benutzerrechte, erreichbare Zielsysteme, Firewall-Regeln und die Sicherheit des verwendeten Endgerätes berücksichtigt werden.

Warum sollte ein VPN-Benutzer nicht das gesamte OT-Netz erreichen?

Weil ein Fernwartungszugang normalerweise nur für bestimmte Systeme und Aufgaben benötigt wird. Eine Begrenzung reduziert die Auswirkungen kompromittierter Zugangsdaten oder Servicegeräte.

Ist TLS innerhalb eines VPN noch sinnvoll?

Ja. Beide Verfahren schützen unterschiedliche Ebenen und können innerhalb eines mehrschichtigen Sicherheitskonzeptes kombiniert werden.

Was ist Zero Trust?

Zero Trust ist ein Sicherheitsprinzip, bei dem Zugriff nicht allein aufgrund der Netzwerkposition vertraut wird. Identität, Berechtigung und Kommunikationsbeziehung werden gezielt geprüft.

Welche Ports sollte ein IIoT-Gateway geöffnet haben?

Nur diejenigen Dienste und Ports, die für die konkrete Anwendung benötigt werden. Die genaue Auswahl hängt vom Gateway, den Protokollen und der Netzwerkarchitektur ab.

Sollte ein administrativer Netzwerkdienst dauerhaft aktiviert bleiben?

Nur wenn der Dienst tatsächlich benötigt wird und entsprechend abgesichert ist. Nicht benötigte administrative Dienste sollten deaktiviert werden.

Was ist Secure Boot?

Secure Boot bezeichnet einen Mechanismus, bei dem beim Start die Vertrauenswürdigkeit beziehungsweise Authentizität auszuführender Softwarebestandteile überprüft wird.

Was bedeutet signierte Firmware?

Ein Gerät kann anhand einer digitalen Signatur prüfen, ob ein Firmwarepaket aus einer autorisierten Quelle stammt und unverändert ist.

Hat jedes IIoT-Gateway Secure Boot?

Nein. Ob diese Funktion vorhanden ist, muss für das konkrete Gateway und dessen Hardware- beziehungsweise Firmwareversion geprüft werden.

Warum müssen IIoT-Gateways aktualisiert werden?

Firmwareupdates können Fehler beheben, Funktionen verbessern und bekannte Sicherheitsprobleme adressieren. Updates sollten im OT-Umfeld kontrolliert bewertet, getestet und dokumentiert werden.

Sollte jedes Firmwareupdate sofort installiert werden?

Die Dringlichkeit hängt von Sicherheitsrisiko, Anwendung und Herstellerhinweisen ab. In Produktionsanlagen sollten Kompatibilität, Backup, Wartungsfenster und Rollback berücksichtigt werden.

Welche Ereignisse sollte ein Gateway protokollieren?

Besonders nützlich sind Anmeldungen, fehlgeschlagene Zugriffe, Konfigurationsänderungen, Benutzeränderungen, Zertifikatswechsel, Updates und Kommunikationsfehler.

Warum ist ein Audit-Log wichtig?

Damit nach einer Störung oder Sicherheitsauffälligkeit nachvollzogen werden kann, welche Ereignisse und Änderungen zuvor stattgefunden haben.

Warum benötigt ein IIoT-Gateway einen Zeitserver?

Eine korrekte Systemzeit wird für Messwertzeitstempel, Logs, Alarmhistorien und die Prüfung der Zertifikatsgültigkeit benötigt.

Kann eine falsche Uhrzeit TLS stören?

Ja. Ein gültiges Zertifikat kann bei falscher Gerätezeit fälschlicherweise als noch nicht gültig oder bereits abgelaufen bewertet werden.

Was sollte von einem Gateway gesichert werden?

Je nach Gerät insbesondere Netzwerk-, Kommunikations-, Messstellen-, Benutzer- und Zertifikatskonfiguration sowie die verwendete Firmwareversion.

Sollten private Schlüssel im normalen Backup enthalten sein?

Wenn Schlüsselmaterial gesichert werden muss, muss dies mit geeigneten Schutzmaßnahmen erfolgen. Private Schlüssel dürfen nicht ungeschützt abgelegt oder verteilt werden.

Was ist ein API-Key?

Ein API-Key ist ein Zugangsschlüssel, mit dem sich eine Anwendung gegenüber einem Dienst identifizieren beziehungsweise authentifizieren kann.

Sollten alle Gateways denselben API-Key verwenden?

Wenn die Architektur individuelle Identitäten unterstützt, sind getrennte Schlüssel beziehungsweise Credentials meist besser zu verwalten und gezielter sperrbar.

Was ist die wichtigste Security-Maßnahme für ein IIoT-Gateway?

Es gibt keine einzelne Maßnahme, die alle Risiken abdeckt. Entscheidend ist die Kombination aus Segmentierung, kontrollierter Kommunikation, sicheren Identitäten, Rechteverwaltung, Updates und Überwachung.

Welche Rolle spielt IEC 62443?

Die Normenreihe IEC 62443 dient als wichtiger Rahmen für Cybersecurity in industriellen Automatisierungs- und Steuerungssystemen und behandelt unter anderem Security-Prozesse, Systemarchitekturen, Zonen und technische Anforderungen.

Ist ein Gateway mit TLS automatisch IEC-62443-konform?

Nein. Eine einzelne technische Funktion wie TLS reicht nicht aus, um die Cybersecurity eines kompletten Systems beziehungsweise die Erfüllung eines umfassenden Normenrahmens nachzuweisen.

Was ist der Siemens SITRANS MS200?

Der SITRANS MS200 mit der Artikelnummer 7MP2210-2AB21-2AB1 ist ein bei ICS gelisteter IIoT-Sensor zur Vibrations- und Temperaturüberwachung. Auf der ICS-Produktseite wird seine Verwendung in Kombination mit dem SITRANS CC220 Gateway beschrieben.

Wofür wird das SITRANS CC220 im Zusammenhang mit dem SITRANS MS200 genannt?

Auf der ICS-Produktseite des SITRANS MS200 wird das SITRANS CC220 als zugehöriges Gateway für die IIoT-Anwendung genannt. Damit können die Sensordaten in eine übergeordnete Condition-Monitoring- beziehungsweise IIoT-Architektur eingebunden werden.

Was ist die Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2?

Die bei ICS gelistete IIoT-Wägeelektronik dient zum Anschluss einer Wägezelle beziehungsweise DMS-Vollbrücke mit 1 … 4 mV/V und wandelt deren analoges Signal für die digitale Verarbeitung um. Auf der ICS-Produktseite ist sie für das SIMATIC IOT2050 Gateway vorgesehen.

Wie wird das SIMATIC IOT2050 auf der ICS-Seite verwendet?

Auf der ICS-Produktseite der IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 wird das SIMATIC IOT2050 als zugehörige Gateway-Plattform für diese Anwendung genannt.

Muss ich Security-Funktionen beim konkreten Gateway prüfen?

Ja. Funktionen wie Secure Boot, mTLS, Benutzerrollen, VPN oder signierte Updates hängen von Hardware, Firmware, Betriebssystem und eingesetzter Software ab und dürfen nicht pauschal vorausgesetzt werden.

Wo finde ich den Siemens SITRANS MS200 bei ICS Schneider?

Weitere Informationen finden Sie unter Siemens SITRANS MS200 bei ICS Schneider.

Wo finde ich die Siemens IIoT-Wägeelektronik für SIMATIC IOT2050 bei ICS Schneider?

Weitere Informationen finden Sie unter Siemens IIoT-Wägeelektronik 7MH4647-0KK00-0AA2 bei ICS Schneider.

Wo finde ich IIoT-Lösungen bei ICS Schneider?

Eine Übersicht finden Sie unter IIoT Lösungen bei ICS Schneider.

Wo finde ich Siemens Prozessinstrumentierung bei ICS Schneider?

Weitere Siemens-Feldgeräte und Prozessinstrumentierung finden Sie unter Siemens Prozessinstrumentierung bei ICS Schneider.