TL;DR

• Stadtwerke fallen haeufig unter die KRITIS-Verordnung -- je nach Schwellenwert bei Strom, Gas, Wasser oder Fernwaerme gelten verschaerfte BSI-Anforderungen
• OT/IT-Trennung ist Pflicht: Network Policies und dedizierte Namespaces isolieren Leittechnik-Anbindungen von klassischen IT-Workloads
• Systeme zur Angriffserkennung (SzA) nach IT-SiG 2.0 lassen sich mit Falco und Audit-Logging in Kubernetes umsetzen
• 24/7-Monitoring ist fuer KRITIS-Betreiber keine Option, sondern gesetzliche Pflicht -- ein kleines Team allein kann das nicht leisten
• Managed Kubernetes mit C5-Testat reduziert den Dokumentationsaufwand fuer BSI-Pruefungen erheblich

Kubernetes fuer Stadtwerke: KRITIS-konforme Container-Infrastruktur

Stadtwerke stehen vor einer doppelten Herausforderung: Auf der einen Seite muessen veraltete IT-Systeme modernisiert werden, um Smart Metering, digitale Kundenschnittstellen und neue Energiedienstleistungen zu ermoeglichen. Auf der anderen Seite verschaerfen IT-SiG 2.0 und die NIS2-Richtlinie die Sicherheitsanforderungen fuer Betreiber Kritischer Infrastrukturen.

Kubernetes kann hier das technische Fundament liefern. Aber nur, wenn die regulatorischen Anforderungen von Anfang an in der Architektur beruecksichtigt werden.

Wann fallen Stadtwerke unter KRITIS?

Nicht jedes Stadtwerk ist automatisch KRITIS-Betreiber. Die BSI-KritisV definiert Schwellenwerte je nach Versorgungsbereich. In der Praxis ueberschreiten viele mittlere und grosse Stadtwerke mindestens einen dieser Werte.

Selbst wenn ein Stadtwerk unter den Schwellenwerten liegt: Mit NIS2 erweitert sich der Kreis der betroffenen Unternehmen. Wer jetzt eine neue Plattform baut, sollte KRITIS-Anforderungen von Beginn an einplanen.

OT/IT-Trennung: Die wichtigste Architekturentscheidung

Die saubere Trennung von Operational Technology (Leitsysteme, SCADA, Smart-Meter-Gateways) und klassischer IT (ERP, Kundenportal, Abrechnungssysteme) ist die zentrale Sicherheitsanforderung. In Kubernetes laesst sich das ueber Namespaces und Network Policies abbilden.

Namespace-Struktur fuer Stadtwerke

# Namespace fuer OT-nahe Workloads (Smart Meter Gateway Administration)
apiVersion: v1
kind: Namespace
metadata:
  name: ot-smartmeter
  labels:
    zone: ot-dmz
    compliance: kritis
    data-classification: critical-infrastructure
---
# Namespace fuer klassische IT-Workloads (Kundenportal)
apiVersion: v1
kind: Namespace
metadata:
  name: it-kundenportal
  labels:
    zone: it
    compliance: standard
    data-classification: internal
---
# Default-Deny NetworkPolicy fuer den OT-Bereich
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: ot-smartmeter
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Explizite Freigabe: Nur der Datenkollektor darf Smart-Meter-Daten empfangen
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-meter-data-ingress
  namespace: ot-smartmeter
spec:
  podSelector:
    matchLabels:
      app: meter-data-collector
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              zone: ot-dmz
      ports:
        - protocol: TCP
          port: 8443

Wichtig: Die Default-Deny-Policy ist nicht optional. Ohne sie kann jeder Pod im Cluster mit den OT-Workloads kommunizieren. Das ist ein Audit-Finding, das sofort auffaellt.

Vergleich: Netzwerkarchitektur-Ansaetze

Fuer die meisten Stadtwerke ist die Kombination aus dedizierten Node-Pools fuer OT-nahe Workloads und Network Policies fuer die IT-Seite ein guter Kompromiss zwischen Sicherheit und Betriebsaufwand.

Angriffserkennung nach IT-SiG 2.0

Seit Mai 2023 muessen KRITIS-Betreiber Systeme zur Angriffserkennung (SzA) betreiben und dem BSI nachweisen. In Kubernetes-Umgebungen bedeutet das: Runtime Security auf Container-Ebene und lueckenlose Audit-Logs.

Falco als SzA-Komponente

# Falco-Regel: Erkennung verdaechtiger Aktivitaeten in KRITIS-Namespaces
apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-kritis-rules
  namespace: security
data:
  kritis-rules.yaml: |
    - rule: Shell in OT-Container
      desc: Erkennt Shell-Zugriff auf Container im OT-Namespace
      condition: >
        spawned_process and container and
        proc.name in (bash, sh, zsh) and
        k8s.ns.name = "ot-smartmeter"
      output: >
        KRITIS-ALARM: Shell in OT-Container geoeffnet
        (user=%user.name pod=%k8s.pod.name namespace=%k8s.ns.name
        command=%proc.cmdline image=%container.image.repository)
      priority: CRITICAL
      tags: [kritis, ot-security, bsi-sza]

    - rule: Unerwarteter Netzwerkzugriff OT-Zone
      desc: Erkennt Verbindungsversuche aus IT-Zone in OT-Zone
      condition: >
        outbound and container and
        fd.snet != "0.0.0.0/0" and
        k8s.ns.name = "it-kundenportal" and
        fd.sport in (502, 102, 20000)
      output: >
        KRITIS-ALARM: IT-Zone versucht OT-Protokoll-Zugriff
        (pod=%k8s.pod.name namespace=%k8s.ns.name
        connection=%fd.name port=%fd.sport)
      priority: CRITICAL
      tags: [kritis, ot-security, network-anomaly]

Die Falco-Regeln allein reichen nicht. Die Alerts muessen an ein SIEM-System (z.B. Splunk, Elastic SIEM) weitergeleitet werden, das die BSI-konforme Aufbewahrung und Auswertung sicherstellt. Die Aufbewahrungsfrist fuer Audit-Logs betraegt mindestens zwei Jahre, fuer KRITIS-Betreiber empfiehlt das BSI sieben Jahre.

24/7-Monitoring: Gesetzliche Pflicht, nicht Kuer

KRITIS-Betreiber muessen Stoerungen und Sicherheitsvorfaelle dem BSI melden -- und zwar unverzueglich. Das setzt voraus, dass jemand rund um die Uhr die Systeme ueberwacht und auf Alerts reagiert.

Ein Team von ein bis zwei Admins kann echtes 24/7-Monitoring nicht leisten. Die Mathematik ist eindeutig: Fuer eine lueckenlose Abdeckung brauchen Sie mindestens vier bis fuenf Personen in Rotation. Fuer die meisten Stadtwerke ist ein Managed-Service-Modell mit professioneller On-Call-Rotation die wirtschaftlich sinnvollere Loesung.

Cloud-Anbieter-Wahl: C5-Testat als Pflichtkriterium

Fuer KRITIS-Betreiber ist das C5-Testat (Cloud Computing Compliance Criteria Catalogue) des BSI ein zentrales Auswahlkriterium fuer Cloud-Anbieter. Ohne C5-Testat muessen Sie die gesamte Sicherheitsdokumentation selbst erstellen und pflegen.

Praxis-Checkliste: Kubernetes-Einfuehrung bei Stadtwerken

Phase 1: Vorbereitung (Monat 1-2)

• KRITIS-Betroffenheit pruefen und Schwellenwerte dokumentieren
• Bestandsaufnahme: Welche Systeme sollen migriert werden?
• Cloud-Anbieter mit C5-Testat evaluieren
• OT/IT-Zonenkonzept erstellen und mit dem CISO abstimmen
• BSI IT-Grundschutz Anforderungen fuer Container-Umgebungen pruefen

Phase 2: Aufbau (Monat 3-5)

• Cluster-Architektur mit dedizierten Node-Pools fuer OT und IT
• Network Policies implementieren (Default-Deny als Basis)
• Monitoring-Stack aufsetzen: Prometheus, Grafana, Alertmanager
• Falco fuer Runtime Security und Angriffserkennung installieren
• RBAC-Konzept umsetzen und dokumentieren

Phase 3: Migration und Compliance (Monat 6-9)

• Erste IT-Workloads migrieren (Kundenportal, Abrechnungssysteme)
• OT-nahe Workloads schrittweise anbinden (Smart-Meter-Datenkollektor)
• BSI-Pruefung vorbereiten: Sicherheitskonzept, RBAC-Doku, Notfallplan
• KRITIS-spezifische Compliance-Checks automatisieren
• Penetrationstest durch externen Dienstleister

Phase 4: Betrieb und Optimierung (laufend)

• 24/7-Betriebsmodell etablieren oder Managed Service beauftragen
• Kosten-Monitoring einrichten (Kubecost/OpenCost)
• Regelmaessige Compliance-Audits alle zwei Jahre
• Schulungen fuer Betriebsteam und Notfalluebungen

Typische Fehler bei Stadtwerk-Projekten

1. OT-Systeme ohne Netzwerk-Isolation

Das groesste Risiko: Leittechnik-Anbindungen im gleichen Netzwerksegment wie das Kundenportal. Ein kompromittierter Webserver kann dann auf SCADA-Systeme zugreifen. Default-Deny Network Policies sind die erste Verteidigungslinie.

2. Monitoring nur waehrend der Buerozeiten

KRITIS-Betreiber muessen Stoerungen unverzueglich melden. "Wir haben es am Montagmorgen bemerkt" ist bei einem Vorfall am Freitagabend keine akzeptable Antwort. Automatisierte Alerting-Ketten mit Eskalation sind Pflicht.

3. Fehlende Audit-Log-Retention

Kubernetes-API-Server-Logs werden standardmaessig nicht langfristig aufbewahrt. Fuer BSI-Pruefungen brauchen Sie nachweisbare Aufbewahrung ueber Jahre. Eine dedizierte Log-Aggregation mit definierten Retention-Policies muss von Anfang an eingeplant werden.

4. Kein getesteter Notfallplan

Ein Notfallplan, der in der Schublade liegt, hilft nicht. Das BSI erwartet regelmaessige Tests -- mindestens jaehrlich. Dazu gehoeren Failover-Tests, Recovery-Uebungen und dokumentierte Lessons Learned.

Wirtschaftlichkeit: Kosten und Nutzen

Die Einfuehrung von Kubernetes bei Stadtwerken ist kein Selbstzweck. Sie muss sich rechnen.

Die groessten Einsparungen kommen nicht durch niedrigere Infrastrukturkosten, sondern durch reduzierten Compliance-Aufwand und vermiedene Ausfallkosten. Managed Kubernetes mit C5-Testat reduziert den Dokumentationsaufwand fuer BSI-Pruefungen typischerweise um 40-60%.

Fazit

Kubernetes ist fuer Stadtwerke kein Technologie-Trend, sondern eine strategische Entscheidung. Die Container-Plattform liefert die Bausteine fuer eine KRITIS-konforme Infrastruktur: Netzwerkisolation, Audit-Logging, automatisierte Angriffserkennung und Self-Healing. Aber diese Bausteine muessen korrekt konfiguriert und betrieben werden.

Die drei wichtigsten Punkte:

1. OT/IT-Trennung von Anfang an in der Architektur verankern -- nachtraegliches Einziehen von Network Policies ist aufwendig und fehleranfaellig.
2. BSI-Anforderungen frueh einplanen, nicht als nachtraegliches Compliance-Projekt. Die Architekturentscheidungen in Phase 1 bestimmen, wie aufwendig die BSI-Pruefung wird.
3. 24/7-Betrieb realistisch planen. Ein einzelner Admin mit Rufbereitschaft erfuellt nicht die Anforderungen an KRITIS-Betreiber.

Wenn Sie vor der Entscheidung stehen, ob Kubernetes fuer Ihr Stadtwerk die richtige Wahl ist, lohnt sich ein Blick auf unseren Leitfaden fuer KRITIS-Betreiber und die DSGVO-Compliance-Checkliste.