NIS2 fuer produzierende Unternehmen: OT/IT-Security auf Kubernetes ohne Spezialistenteam

TL;DR

• NIS2 erweitert den Geltungsbereich auf produzierende Unternehmen ab 50 Mitarbeitern oder 10 Mio. EUR Umsatz in bestimmten Sektoren. Viele Mittelstaendler sind betroffen, ohne es zu wissen.
• Die groesste Herausforderung ist die OT/IT-Konvergenz: Produktionsnetze (SCADA, MES, SPS) wachsen mit der IT-Infrastruktur zusammen, aber Security-Konzepte hinken hinterher.
• Kubernetes kann als Vermittlungsschicht zwischen OT und IT dienen: Container isolieren Datenintegrationspunkte, Network Policies segmentieren den Traffic, und Monitoring erfasst beide Welten.
• Sie brauchen kein OT-Security-Spezialistenteam. Starten Sie mit Netzwerksegmentierung und Monitoring -- die zwei Massnahmen mit dem hoechsten Schutzeffekt bei geringstem Aufwand.
• Die Purdue-Modell-Architektur laesst sich auf Kubernetes-Namespaces abbilden und liefert eine auditierfaehige Struktur fuer NIS2-Pruefungen.

Warum NIS2 jetzt produzierende Unternehmen trifft

Die NIS2-Richtlinie (EU 2022/2555) hat den Kreis der regulierten Unternehmen massiv erweitert. Erstmals fallen auch produzierende Unternehmen unter die Cybersicherheitsanforderungen, sofern sie bestimmte Kriterien erfuellen:

Der Sektor "Fertigung" umfasst unter anderem: Maschinenbau, Fahrzeugbau, elektrische Ausruestung, Medizinprodukte und Datenverarbeitungsgeraete. Ein Maschinenbauer mit 200 Mitarbeitern und 30 Millionen Euro Umsatz ist damit eine "wichtige Einrichtung" im Sinne der NIS2.

Die Details zur Meldepflicht und wie Sie die 24-Stunden-Frist einhalten, beschreibt unser Artikel zur NIS2-Meldepflicht.

Das Problem: Zwei Welten, die nie fuereinander gedacht waren

In produzierenden Unternehmen existieren zwei grundlegend verschiedene Infrastrukturwelten:

IT (Information Technology): Server, Kubernetes-Cluster, Datenbanken, ERP-Systeme. Regelmaessige Updates, kurze Lebenszyklen, standardisierte Sicherheitstools. Lebenserwartung einer Komponente: 3-5 Jahre.

OT (Operational Technology): SCADA-Systeme, MES (Manufacturing Execution Systems), SPS/PLC (Speicherprogrammierbare Steuerungen), Sensoren, Aktoren. Seltene Updates, Lebenszyklen von 15-25 Jahren, proprietaere Protokolle. Die SPS, die Ihre Fertigungslinie steuert, laeuft moeglicherweise noch mit Software von 2008.

Das Problem entsteht an den Beruehrungspunkten. Moderne Industrie-4.0-Initiativen verlangen, dass Produktionsdaten in die IT-Welt fliessen: MES-Daten ins ERP, Sensordaten in Dashboards, Qualitaetsdaten in Cloud-Analytics. Jeder dieser Datenfluesse ist ein potenzielles Einfallstor.

Das Purdue-Modell auf Kubernetes abbilden

Das Purdue-Modell (auch ISA-95 / IEC 62443) ist der Standard fuer die Segmentierung von OT/IT-Netzwerken. Es definiert Schichten (Levels) von der physischen Produktion bis zur Unternehmens-IT. Kubernetes eignet sich hervorragend, um die oberen Schichten dieses Modells abzubilden und die Uebergaenge zwischen OT und IT zu sichern.

Die Levels 0-2 bleiben ausserhalb von Kubernetes. Diese Systeme sind zu spezialisiert, zu empfindlich und zu alt fuer Containerisierung. Kubernetes uebernimmt die Levels 3-5 und insbesondere die kritische DMZ zwischen OT und IT (Level 3.5).

Netzwerksegmentierung: Die wichtigste einzelne Massnahme

Wenn Sie nur eine Sache tun koennten, waere es Netzwerksegmentierung. Die meisten OT-Sicherheitsvorfaelle entstehen, weil IT-Netze und OT-Netze nicht sauber getrennt sind. Ein Ransomware-Angriff, der im Buero-Netzwerk beginnt, erreicht ueber ungesicherte Bruecken die Produktionssteuerung.

Die folgende Konfiguration implementiert die Purdue-Level-Segmentierung in Kubernetes:

# purdue-segmentierung.yaml
# Netzwerksegmentierung nach Purdue-Modell fuer NIS2-Compliance

# Level 3.5 DMZ: Nur definierte Datenfluesse zwischen OT und IT
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ot-it-dmz-policy
  namespace: ot-it-dmz
  labels:
    purdue-level: "3.5"
    compliance: nis2-manufacturing
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Eingehend: Nur vom OPC-UA Gateway (Level 3)
    - from:
        - namespaceSelector:
            matchLabels:
              purdue-level: "3"
      ports:
        - protocol: TCP
          port: 4840  # OPC-UA
    # Eingehend: Nur vom Enterprise-Level fuer Abfragen
    - from:
        - namespaceSelector:
            matchLabels:
              purdue-level: "5"
      ports:
        - protocol: TCP
          port: 8443  # REST API (read-only)
  egress:
    # DNS erlauben
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    # Ausgehend: Nur zum Historian (Level 3)
    - to:
        - namespaceSelector:
            matchLabels:
              purdue-level: "3"
      ports:
        - protocol: TCP
          port: 5432  # PostgreSQL Historian

---
# Level 5 Enterprise: Kein direkter Zugriff auf OT
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: enterprise-policy
  namespace: enterprise
  labels:
    purdue-level: "5"
    compliance: nis2-manufacturing
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    # Enterprise darf nur die DMZ ansprechen, nie direkt OT
    - to:
        - namespaceSelector:
            matchLabels:
              purdue-level: "3.5"
      ports:
        - protocol: TCP
          port: 8443
    # Ausgehend ins Internet (ERP-Cloud, Updates)
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
      ports:
        - protocol: TCP
          port: 443

Das zentrale Prinzip: Die Enterprise-IT (Level 5) darf nie direkt mit den OT-Systemen (Level 3 und darunter) kommunizieren. Alle Datenfluesse muessen durch die DMZ (Level 3.5), wo sie gefiltert, protokolliert und ueberwacht werden. Diese Trennung ist die Kernforderung von IEC 62443 und wird von NIS2-Pruefern als Erstes abgefragt.

Weitere Details zur Netzwerksicherheit finden Sie in unserem Security-Hardening-Leitfaden.

OPC-UA Gateway: Der sichere Datenaustausch zwischen OT und IT

OPC-UA (Open Platform Communications Unified Architecture) ist der Industriestandard fuer die Kommunikation zwischen Maschinen und IT-Systemen. Ein OPC-UA Gateway auf Kubernetes fungiert als kontrollierter Uebergabepunkt zwischen den Welten.

# opcua-gateway-deployment.yaml
# OPC-UA Gateway in der DMZ (Purdue Level 3.5)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-gateway
  namespace: ot-it-dmz
  labels:
    app: opcua-gateway
    purdue-level: "3.5"
    compliance: nis2-manufacturing
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opcua-gateway
  template:
    metadata:
      labels:
        app: opcua-gateway
        purdue-level: "3.5"
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
      containers:
        - name: opcua-gateway
          image: registry.internal/opcua-gateway:2.4.1
          ports:
            - containerPort: 4840
              name: opcua
              protocol: TCP
            - containerPort: 8443
              name: rest-api
              protocol: TCP
          env:
            - name: OT_ENDPOINT
              value: "opc.tcp://historian.site-operations:4840"
            - name: READ_ONLY
              value: "true"
            - name: TLS_ENABLED
              value: "true"
            - name: AUDIT_LOG_ENABLED
              value: "true"
          resources:
            limits:
              cpu: "500m"
              memory: "512Mi"
            requests:
              cpu: "200m"
              memory: "256Mi"
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          volumeMounts:
            - name: tls-certs
              mountPath: /etc/opcua/certs
              readOnly: true
      volumes:
        - name: tls-certs
          secret:
            secretName: opcua-gateway-tls

Kritische Punkte bei der Gateway-Konfiguration:

• READ_ONLY: true -- Das Gateway liest nur Daten aus der OT-Welt. Kein Schreibzugriff von der IT auf die Produktion. Diese Einbahnstrasse ist die wichtigste Sicherheitsmassnahme.
• TLS fuer OPC-UA -- OPC-UA unterstuetzt Transport-Verschluesselung. Aktivieren Sie sie immer, auch im internen Netzwerk.
• Audit-Logging -- Jeder Datenzugriff wird protokolliert. Fuer NIS2-Pruefungen muessen Sie nachweisen koennen, wer wann welche Produktionsdaten abgerufen hat.
• Read-Only Filesystem und keine Privilege Escalation -- Selbst wenn der Gateway-Container kompromittiert wird, kann der Angreifer keine Dateien schreiben oder Root-Rechte erlangen.

Monitoring: OT und IT in einer einzigen Ansicht

NIS2 verlangt "geeignete Massnahmen zur Erkennung von Sicherheitsvorfaellen". Fuer produzierende Unternehmen bedeutet das: Monitoring muss beide Welten abdecken -- IT und OT. Kubernetes mit Prometheus und Grafana kann als zentrale Monitoring-Plattform dienen.

#!/bin/bash
# ot-it-monitoring-setup.sh
# Prometheus und Grafana fuer kombiniertes OT/IT-Monitoring einrichten

# Namespace fuer Monitoring erstellen
kubectl create namespace monitoring
kubectl label namespace monitoring purdue-level=5

# Prometheus mit OT-spezifischen Scrape-Targets installieren
helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  --set prometheus.prometheusSpec.additionalScrapeConfigs[0].job_name=opcua-gateway \
  --set prometheus.prometheusSpec.additionalScrapeConfigs[0].static_configs[0].targets[0]=opcua-gateway.ot-it-dmz:9090 \
  --set prometheus.prometheusSpec.additionalScrapeConfigs[0].metrics_path=/metrics \
  --set prometheus.prometheusSpec.retention=90d \
  --set grafana.adminPassword="$(kubectl get secret grafana-admin -o jsonpath='{.data.password}' | base64 -d)" \
  --set alertmanager.config.global.resolve_timeout=5m

# Alerting-Regeln fuer OT-spezifische Anomalien
kubectl apply -f - <<EOF
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ot-anomaly-rules
  namespace: monitoring
  labels:
    release: prometheus
spec:
  groups:
    - name: ot-security
      rules:
        - alert: OT_UnexpectedDataFlow
          expr: |
            rate(opcua_gateway_requests_total{direction="write"}[5m]) > 0
          for: 0m
          labels:
            severity: nis2-critical
            purdue_level: "3.5"
          annotations:
            summary: "KRITISCH: Schreibzugriff auf OT-System erkannt"
            description: "Das OPC-UA Gateway hat einen Schreibzugriff registriert. Das Gateway ist als Read-Only konfiguriert. Moegliche Kompromittierung."

        - alert: OT_GatewayLatencyHigh
          expr: |
            histogram_quantile(0.99, rate(opcua_gateway_request_duration_seconds_bucket[5m])) > 2
          for: 5m
          labels:
            severity: warning
            purdue_level: "3.5"
          annotations:
            summary: "OPC-UA Gateway Latenz erhoeht"
            description: "Die Antwortzeit des OPC-UA Gateways liegt ueber 2 Sekunden. Moeglicherweise versucht jemand, grosse Datenmengen abzuziehen."
EOF

Zwei Alerts sind besonders wichtig fuer NIS2-Compliance in der Produktion:

1. Schreibzugriffe auf OT-Systeme erkennen: Wenn Ihr Gateway als Read-Only konfiguriert ist und trotzdem Schreibzugriffe registriert, ist etwas grundlegend falsch. Dieser Alert hat hoechste Prioritaet.
2. Ungewoehnliche Datenmengen erkennen: Erhoehte Latenz am Gateway kann auf Datenexfiltration hindeuten. Jemand versucht, Produktionsdaten (Rezepturen, Prozessparameter, Qualitaetsdaten) abzuziehen.

Einen umfassenden Ueberblick ueber Kubernetes Monitoring finden Sie in unserem Monitoring-Leitfaden.

Was gehoert auf Kubernetes -- und was nicht?

Die Faustregel: Alles, was Daten verarbeitet und darstellt (MES-Frontend, Historian, Dashboards, OPC-UA Gateway, Edge-Analytics), kann auf Kubernetes. Alles, was Maschinen direkt steuert (SPS/PLC, SCADA mit Maschinenanbindung, SIL-zertifizierte Safety-Systeme), bleibt auf dedizierter Hardware. Echtzeit-Anforderungen und proprietaere Protokolle sind mit Containern nicht vereinbar.

NIS2-Massnahmen priorisieren: Die 80/20-Regel

Produzierende Unternehmen mit begrenztem Security-Budget muessen priorisieren. Diese Reihenfolge liefert den groessten Schutzeffekt pro investiertem Euro:

Beginnen Sie mit Prioritaet 1 und 2. Wenn Sie Netzwerksegmentierung und Monitoring implementiert haben, ist Ihr Unternehmen bereits signifikant besser geschuetzt als die meisten Mittelstaendler -- und Sie koennen dem NIS2-Pruefer eine nachvollziehbare Struktur praesentieren.

Praxisnahe Architektur fuer den Mittelstand

Fuer ein produzierendes Unternehmen mit 200-500 Mitarbeitern empfehlen wir folgende Aufteilung:

Kubernetes-Cluster (3-5 Nodes): Namespaces enterprise (Level 5: ERP-Integration, Dashboards), ot-it-dmz (Level 3.5: OPC-UA Gateway, API-Proxy), site-operations (Level 3: Historian, MES-Frontend), monitoring (Prometheus, Grafana) und security (Falco, Audit-Log-Collector).

Physisch getrennt: SCADA-Server und SPS/PLC bleiben im OT-Netzwerk, abgetrennt durch eine physische Firewall. Die Firewall erlaubt nur OPC-UA (Port 4840) vom OT-Netzwerk zum DMZ-Namespace. Es gibt keinen Rueckkanal vom Kubernetes-Cluster ins OT-Netzwerk.

Diese Architektur erfuellt die Segmentierungsanforderungen nach IEC 62443 und NIS2, ist mit einem kleinen DevOps-Team betreibbar und laesst sich schrittweise aufbauen. Wie Sie Kubernetes-Cluster fuer Produktionsumgebungen absichern, beschreibt unser Compliance-Leitfaden.

Haeufige Fehler bei der OT/IT-Integration

Fazit: NIS2 in der Produktion ist beherrschbar

NIS2-Compliance fuer produzierende Unternehmen erfordert kein OT-Security-Spezialistenteam. Es erfordert klare Segmentierung zwischen OT und IT, Monitoring an den Uebergangspunkten, Dokumentation der Sicherheitsmassnahmen und einen Incident-Response-Plan, der die Meldefristen beruecksichtigt.

Ein erfahrener DevOps-Engineer kann diese Massnahmen in 2-3 Monaten umsetzen. Die Technik ist vorhanden, die Regulierung ist klar. Was fehlt, ist oft nur der erste Schritt.

Weitergehende Themen

• NIS2 Meldepflicht: 24-Stunden-Frist einhalten -- Incident Response und Meldeprozesse
• KRITIS und IT-SiG 2.0 auf Kubernetes -- Fuer Unternehmen mit KRITIS-Einstufung
• Kubernetes Compliance ohne Security-Team -- DSGVO und BSI mit Open-Source-Tools
• Kubernetes Security Hardening -- Technische Baseline absichern
• Kubernetes Notfallplan fuer Produktionsausfaelle -- Business Continuity

Sie betreiben eine Produktionsumgebung mit Kubernetes und muessen NIS2-Anforderungen umsetzen? Wir unterstuetzen Sie bei der OT/IT-Segmentierung, dem Monitoring-Aufbau und der Audit-Vorbereitung. Schreiben Sie uns unter /kontakt.