Ein Managed-Ethernet-Switch in einem SCADA- oder DCS-Netzwerk ist mehr als ein Portvervielfacher. Er steuert Datenverkehrspfade, stellt Diagnoseinformationen bereit und kann die Auswirkungen eines Konfigurationsfehlers entweder begrenzen oder verstärken.

Das technische Ziel ist nicht die maximale Nutzung von Funktionen. Es sind vorhersehbare Kommunikationsabläufe, ein eingeschränkter Managementzugriff und genügend Informationen, um Fehler zu diagnostizieren, ohne den Prozess zu beeinträchtigen.

Ein mehrschichtiges Design trennt Feldsteuerung, Leitsysteme, Standortbetrieb und den Datenaustausch mit der Unternehmens-IT.

Mit Datenverkehr und Auswirkungen beginnen

Dokumentieren Sie jeden Controller, jedes HMI, jeden Historian, jeden Engineering-Arbeitsplatz, jedes Gateway und jeden Fernzugriffspfad, bevor Sie Switch-Einstellungen ändern. Erfassen Sie erforderliche Protokolle, Kommunikationspartner, Aktualisierungsraten, Multicast-Verhalten und Erwartungen an die Wiederherstellung.

Dieses Inventar macht Segmentierung zu einer technischen Entscheidung. Ein VLAN allein ist keine Sicherheitsgrenze, sofern Routing- und Firewall-Regeln die vorgesehenen Kommunikationspfade nicht durchsetzen.

NIST SP 800-82 Rev. 3 beschreibt die OT-Sicherheit im Kontext von Leistung, Zuverlässigkeit und Sicherheit. Auch die CISA-Leitlinien betonen die Segmentierung und den kontrollierten Datenaustausch zwischen kritischen Systemen und Unternehmensdiensten.

Management- und Prozessdatenverkehr trennen

Platzieren Sie die Managementschnittstellen der Switches in einem dedizierten Managementnetzwerk. Erlauben Sie den Zugriff nur von autorisierten Administrationshosts über definierte Firewalls oder Zugriffskontrolllisten.

Deaktivieren Sie nicht verwendete Managementdienste. Bevorzugen Sie SSH und HTTPS, sofern der Switch diese unterstützt. Vermeiden Sie Telnet und unverschlüsseltes HTTP, da Anmeldedaten und Sitzungen offengelegt werden können.

Ändern Sie Standardzugangsdaten, verwenden Sie benannte Konten und vergeben Sie rollenbasierte Berechtigungen. Eine zentrale Authentifizierung kann die Nachvollziehbarkeit verbessern, doch der Betrieb benötigt auch eine dokumentierte Wiederherstellungsmethode für den Fall, dass der Authentifizierungsdienst nicht verfügbar ist.

Lokalen Zugriff schützen

Der Konsolenzugriff bleibt bei der Inbetriebnahme und bei Netzwerkausfällen wertvoll. Der physische Zugriff sollte daher kontrolliert werden, und lokale Zugangsdaten sollten nicht unbedacht weitergegeben werden.

Eine gespeicherte Konfiguration darf keine Demonstrationspasswörter oder Hersteller-Standardzugangsdaten enthalten. Bewahren Sie Wiederherstellungszugangsdaten gemäß dem genehmigten Zugriffsprozess des Standorts auf.

Eine an den Betrieb angepasste Segmentierung verwenden

Gruppieren Sie Geräte nach Funktion, Auswirkungen und Kommunikationsbedarf. Beispiele sind Controller-Zellen, Schutzsysteme, Leitsystemserver, sicherheitsbezogene Geräte und Wartungszugänge.

Erstellen Sie kein flaches Anlagen-VLAN, nur weil alle Geräte Industrial Ethernet verwenden. Ein kompromittierter Arbeitsplatz oder ein Broadcast-Sturm kann dann Geräte erreichen, die niemals eine direkte Kommunikation benötigt hätten.

Ein Management-VLAN sollte nur über genehmigte Administrationspfade erreichbar sein.

Wenn Multicast-Protokolle verwendet werden, überprüfen Sie IGMP-Snooping, die Platzierung des Querier und das Redundanzverhalten. Ein fehlerhaftes Multicast-Design kann Ports überlasten oder die I/O-Kommunikation unterbrechen, selbst wenn gewöhnliche Unicast-Tests erfolgreich sind.

Geeignete Schnittstellen- und Gateway-Hardware finden Sie in der Kollektion Kommunikation & Netzwerktechnik. Controller-Plattformen sind unter SPS- & PAC-Systeme zusammengefasst.

Redundanz als System planen

Redundante Verbindungen erfordern ein dokumentiertes Protokoll und eine getestete Konvergenzzeit. Das Hinzufügen paralleler Kabel ohne Schleifenschutz kann statt Ausfallsicherheit einen Broadcast-Sturm verursachen.

Prüfen Sie, ob das Netzwerk Rapid Spanning Tree, ein herstellerspezifisches Ringprotokoll, das Media Redundancy Protocol oder eine andere Methode verwendet. Bestätigen Sie die Kompatibilität aller beteiligten Switches.

Testen Sie Kabelausfall, Stromausfall eines Switches, die Wiederherstellung blockierter Ports und die Rückkehr zum Normalbetrieb. Erfassen Sie Paketverluste und das Verhalten der Controller, nicht nur die vom Switch gemeldete Konvergenzzeit.

Protokollierung und Zeitsynchronisierung unterstützen die Diagnose

Senden Sie Switch-Ereignisse nach Möglichkeit an ein geschütztes Protokollierungssystem. Nützliche Ereignisse sind Verbindungsänderungen, fehlgeschlagene Authentifizierungen, Konfigurationsänderungen, Topologieübergänge und Stromversorgungsalarme.

Eine einheitliche Zeit ist unverzichtbar. Ohne synchronisierte Uhren kann ein Bediener einen Switch-Übergang nicht zuverlässig mit SPS-Fehlern, HMI-Alarmen oder Firewall-Ereignissen in Beziehung setzen.

SNMP sollte bewusst konfiguriert werden. Beschränken Sie die Managementstationen und verwenden Sie, sofern unterstützt, authentifizierte und verschlüsselte Versionen. Vermeiden Sie weitreichenden Schreibzugriff.

Änderungen durchführen, ohne versteckte Risiken zu schaffen

Sichern Sie die laufende Konfiguration vor Beginn der Arbeiten. Dokumentieren Sie Switch-Modell, Firmware, aktive Konfiguration, angeschlossene Ports und die Rollback-Methode.

Nehmen Sie Änderungen während eines genehmigten Wartungsfensters vor. Validieren Sie nach jedem größeren Schritt die Prozesskommunikation, Alarmübermittlung, Historian-Aktualisierungen, Redundanz, den Fernzugriff und die Zeitsynchronisierung.

Firmware-Updates erfordern dieselbe Sorgfalt wie Änderungen an Controllern. Prüfen Sie Herstellerhinweise, testen Sie die Zielversion im Labor und stellen Sie sicher, dass ein Wiederherstellungs-Image verfügbar ist.

Meinung des Autors: Managed-Switches schaffen dann einen Mehrwert, wenn ihre Konfiguration verständlich und wiederherstellbar ist. Ein kompliziertes Design ohne klare Zuständigkeiten, Backups und getestetes Ausfallverhalten ist schwieriger zu betreiben als ein einfacheres, dokumentiertes Netzwerk.