IT- und OT-Netze unterscheiden sich

In einer Fabrik oder einem Bergwerk transportiert das Netz weit mehr als E-Mail und Webverkehr. Steuerungen, Bedienpanels, Kameras, Sensoren und sicherheitsrelevante Systeme hängen davon ab. Netzwerkautomatisierung muss diese Unterschiede ernst nehmen, statt Verfahren aus der Büro-IT unverändert zu übernehmen.

AspektIT-NetzOT-Netz
Oberste PrioritätVertraulichkeit und DatenintegritätVerfügbarkeit und Prozesssicherheit
Lebensdauer der GeräteEinige JahreOft deutlich länger
ÄnderungsfensterRelativ flexibelAn geplante Stillstände gebunden
DatenverkehrVielfältig und stoßweiseVorhersehbar, teils latenzkritisch
UmgebungServerraumStaub, Vibration, Temperatur, Feuchte

Die praktische Folge: Im OT-Umfeld muss jede automatisierte Änderung vorhersehbar, umkehrbar und mit dem Betrieb abgestimmt sein. Automatisierung dient der Einheitlichkeit, nicht dazu, häufiger zu ändern.

Industrienetze haben zudem eigene Protokolle und Topologien. Echtzeit-Ethernet-Protokolle wie PROFINET, EtherNet/IP oder Modbus TCP können empfindlich auf Latenz, Multicast-Stürme oder einen Switch-Neustart zur falschen Zeit reagieren. Ringtopologien mit Redundanzprotokollen sind an Fertigungslinien und im Bergbau verbreitet, und eine unbedachte Änderung an Spanning-Tree- oder Ringeinstellungen kann ein ganzes Segment unterbrechen. Vor jeder Automatisierung sollte klar sein, welche Geräte prozesskritisch sind, wer dafür verantwortlich ist und welche Herstellervorgaben gelten, etwa vom Maschinenlieferanten freigegebene Firmwarestände.

Segmentierung: Zonen und Conduits

Die Normenreihe IEC 62443 beschreibt das Konzept von Zonen und Conduits. Eine Zone fasst Anlagenteile mit ähnlichem Schutzbedarf zusammen, etwa eine Fertigungslinie oder eine Pumpstation. Ein Conduit ist der kontrollierte Kommunikationsweg zwischen Zonen, über den nur der tatsächlich benötigte Verkehr läuft.

  • Trennung von Büronetz und Steuerungsnetz mit einer Zwischenschicht (industrielle DMZ) für Datenserver und Fernzugriff.
  • VLANs und Firewallregeln zur Begrenzung der Kommunikation zwischen Zonen.
  • Dokumentation, welches System mit welchem System über welches Protokoll kommuniziert.

Hier bringt Automatisierung echten Nutzen: Firewallregeln und VLAN-Definitionen lassen sich aus einer strukturierten Quelle erzeugen. So bleibt die Segmentierung an allen Standorten einheitlich, statt durch manuelle Eingriffe schleichend auseinanderzulaufen.

Konfigurationsmanagement, Sicherung und Vorlagen

Der erste und risikoärmste Automatisierungsschritt ist die regelmäßige Sicherung der Konfiguration aller Geräte. Ein zeitgesteuerter Job verbindet sich mit jedem Gerät, liest die Konfiguration aus und legt sie in einem versionierten Repository wie Git ab. Jede Änderung wird so sichtbar und vergleichbar, was bei der Fehlersuche nach einer Störung sehr hilft.

Single Source of Truth

Der nächste Schritt ist eine maßgebliche Datenquelle: ein strukturiertes Inventar aus Geräten, Adressen, VLANs und Standortrollen. Konfigurationen werden aus diesen Daten mit Vorlagen erzeugt, statt auf jedem Gerät von Hand bearbeitet zu werden. Das Inventar beantwortet zudem schnell Grundfragen, etwa welche Firmware wo läuft.

Vorlagen

Mit einer Template-Engine wie Jinja2 lässt sich eine Vorlage für einen „Access-Switch Fertigungslinie“ schreiben, bei der nur die standortspezifischen Variablen variieren. Werkzeuge wie Ansible, Netmiko oder NAPALM übertragen diese Konfigurationen auf die Geräte oder vergleichen sie mit dem laufenden Zustand, um Abweichungen zu erkennen.

Abweichungserkennung

In der Praxis ist die Erkennung von Konfigurationsabweichungen oft der erste greifbare Nutzen. Ein nächtlicher Vergleich zwischen Soll-Konfiguration und tatsächlichem Zustand deckt undokumentierte Änderungen, vergessene Testeinstellungen oder ein Gerät auf, das mit Werkseinstellungen getauscht wurde. Solche Befunde werden zunächst gemeldet und später in einem geplanten Fenster korrigiert; das hält den Ablauf für das Betriebspersonal nachvollziehbar.

Skripting auf MikroTik RouterOS und Cisco IOS

MikroTik RouterOS

RouterOS bietet eine eigene Skriptsprache, einen Scheduler und in neueren Versionen eine REST-API. Ein Textexport entsteht etwa mit /export file=site-a-config, eine binäre Sicherung mit /system backup save name=site-a. Der Textexport eignet sich besser für Vergleiche und Versionsverwaltung, die binäre Sicherung für die Wiederherstellung desselben Geräts.

Cisco IOS

Unter Cisco IOS liest ein Automatisierungswerkzeug typischerweise show running-config und show version per SSH aus. Die Funktion archive kann Konfigurationsstände auf dem Gerät vorhalten, und in vielen Versionen ermöglicht configure replace die Rückkehr zu einer bekannten, funktionierenden Konfiguration.

Auf beiden Plattformen gilt dasselbe Prinzip: zuerst den aktuellen Zustand lesen, die Differenz anzeigen, dann ändern und das Ergebnis prüfen. Skripte sollten bei Unerwartetem sicher abbrechen.

Überwachung und Anbindung entfernter Standorte

  • SNMP: Schnittstellenstatus, CPU-Last, Temperatur und Datenverkehr; vorzugsweise SNMPv3 mit Authentifizierung und Verschlüsselung.
  • Syslog: zentrale Erfassung von Ereignissen wie Linkausfällen, Anmeldungen und Konfigurationsänderungen.
  • NetFlow/IPFIX: Einblick, wer mit wem in welchem Umfang kommuniziert; hilfreich, um unerwarteten Verkehr zwischen Zonen zu erkennen.

Netzwerkdaten lassen sich neben Prozessdaten darstellen, zum Beispiel in einem ThingsBoard Dashboard, sodass Netzwerkprobleme und Anlagenstillstände gemeinsam betrachtet werden können.

Gute Alarmierung ist wichtiger als die Menge gesammelter Daten. Schwellwerte sollten das normale Verhalten jedes Segments abbilden, Alarme bei den Personen ankommen, die handeln können, und wiederkehrende Fehlalarme behoben statt ignoriert werden. Eine im Normalbetrieb aufgezeichnete Referenz erleichtert es erheblich, spätere Veränderungen zu erkennen.

Entfernte Standorte wie Bergwerke, Pumpstationen oder Umspannwerke werden häufig über VPN-Tunnel mit IPsec oder WireGuard angebunden. Tunnelkonfiguration, Schlüsselwechsel und Zustandsprüfungen lassen sich gut automatisieren und erleichtern einheitliche Einstellungen an allen Standorten erheblich.

Änderungsmanagement, Risiken und Einführung

Automatisierung erhöht das Tempo, auch das Tempo von Fehlern. Eine fehlerhafte Vorlage kann mehrere Standorte gleichzeitig vom Netz trennen. Diese Maßnahmen verringern das Risiko:

  • Vier-Augen-Prüfung jeder Änderung vor der Ausführung.
  • Testläufe (Dry Run), die die genauen Unterschiede zeigen.
  • Stufenweise Anwendung: ein Gerät, dann ein Standort, dann der Rest.
  • Abstimmung mit dem Betrieb und Ausführung in vereinbarten Wartungsfenstern.
  • Rückfallplan und separater Out-of-Band-Managementzugang für kritische Geräte.
  • Schutz der Zugangsdaten und Berechtigungen des Automatisierungssystems selbst, das ein sensibles Gut ist.

Ein sinnvoller Einführungspfad:

  1. Geräteinventar und Zonenplan.
  2. Automatische, versionierte Konfigurationssicherung.
  3. Zentrale Überwachung mit SNMP und Syslog.
  4. Konformitätsprüfungen gegen Vorlagen, ohne Änderungen auszurollen.
  5. Automatisierung wiederkehrender, risikoarmer Änderungen.
  6. Schrittweise Erweiterung auf komplexere Änderungen.

Fazit

Netzwerkautomatisierung im Industrieumfeld gelingt, wenn sie die Prioritäten der OT respektiert: zuerst Transparenz und Sicherungen, dann Konformität und erst danach kontrollierte automatisierte Änderungen. Weitere Informationen finden Sie auf den Seiten Netzwerkautomatisierung und Industrielles Monitoring. Für die Besprechung eines konkreten Standortnetzes nutzen Sie bitte die Kontaktseite.

Häufige Fragen

Ist Netzwerkautomatisierung im OT-Umfeld riskant?

Unkontrollierte Automatisierung kann einen einzelnen Fehler gleichzeitig auf viele Geräte übertragen. Deshalb beginnt man mit rein lesenden Aufgaben wie Sicherungen und Konformitätsprüfungen und führt Änderungen schrittweise, mit Prüfung und Rückfallweg, ein.

Womit sollte man bei der Netzwerkautomatisierung beginnen?

In der Regel mit einem genauen Geräteinventar und automatischen, versionierten Konfigurationssicherungen. Beides ist risikoarm und bildet die Grundlage für alle weiteren Schritte.

Braucht man für die Automatisierung neue Netzwerkhardware?

Meist nicht. Plattformen wie MikroTik RouterOS und Cisco IOS lassen sich per SSH und in vielen Versionen auch über eine API automatisiert verwalten.

Ali Porkareh

IT- und Netzwerkspezialist mit Schwerpunkt Industrial IoT, Smart Mining und intelligente Lösungen.