NIS2 und Kubernetes in der Abfallwirtschaft: Compliance ohne Overhead

TL;DR

• Die NIS2-Richtlinie betrifft seit Oktober 2024 auch Unternehmen der Abfallwirtschaft als "wichtige Einrichtungen" -- bei Verstoessen drohen Bussgelder bis 7 Mio. EUR
• Kubernetes deckt mit Network Policies, RBAC, Audit Logging und Pod Security Standards einen Grossteil der technischen NIS2-Anforderungen ab
• Die groesste Luecke ist meist nicht die Technik, sondern fehlende Incident-Response-Prozesse und lueckenhaftes Logging
• Ein schrittweiser Ansatz -- erst Audit Logging, dann Netzwerksegmentierung, dann Hardening -- minimiert Betriebsrisiken
• Die Entsorgungsbranche profitiert besonders, weil IoT-Daten (Fuellstaende, GPS-Tracking) ueber Kubernetes zentral und sicher verarbeitet werden koennen

Warum NIS2 die Entsorgungsbranche betrifft

Die NIS2-Richtlinie (EU 2022/2555) weitet den Kreis der regulierten Unternehmen erheblich aus. Abfallwirtschaft und Entsorgung fallen unter die Kategorie "wichtige Einrichtungen" (Anhang II). Das betrifft nicht nur die grossen Entsorger, sondern auch mittelstaendische Unternehmen ab 50 Mitarbeitern oder 10 Mio. EUR Jahresumsatz.

Die zentralen Anforderungen aus Artikel 21 der Richtlinie lassen sich in technische Massnahmen uebersetzen, die Kubernetes nativ oder ueber sein Oekosystem abdeckt:

Die Richtlinie verlangt keine bestimmte Technologie. Sie verlangt angemessene Massnahmen. Kubernetes bietet die Bausteine -- ihr muesst sie konfigurieren und dokumentieren.

Architektur: Entsorgungslogistik auf Kubernetes

Ein typisches Setup in der Abfallwirtschaft verarbeitet Daten aus mehreren Quellen: GPS-Tracker in Fahrzeugen, Fuellstandsensoren an Containern, Wiegedaten an Anlagen und Auftragsdaten aus dem ERP-System. Diese Daten muessen zuverlaessig erfasst, verarbeitet und fuer Compliance-Berichte vorgehalten werden.

Die Architektur sieht im Kern so aus:

Edge-Schicht: Telematik-Boxen und IoT-Sensoren senden Daten per MQTT oder HTTPS an einen zentralen Endpunkt.

Ingestion: Ein Message Broker (z.B. Kafka oder NATS) nimmt die Daten entgegen und puffert sie. Das entkoppelt die Datenproduktion von der Verarbeitung.

Verarbeitung: Microservices konsumieren die Events und kuemmern sich um Routenoptimierung, Fuellstandsanalyse, Compliance-Pruefungen und Reporting.

Persistenz: PostgreSQL fuer Stammdaten und Auftraege, TimescaleDB fuer Zeitreihendaten (Sensorwerte, GPS-Tracks), Object Storage fuer Langzeitarchivierung.

Monitoring: Prometheus und Grafana fuer Metriken, Loki fuer Logs, Alertmanager fuer Incident-Benachrichtigungen.

Jede dieser Schichten laeuft in einem eigenen Kubernetes Namespace. Das ist nicht nur gute Praxis, sondern die Basis fuer die NIS2-geforderte Netzwerksegmentierung.

Network Policies: Netzwerksegmentierung umsetzen

NIS2 verlangt die Segmentierung von Netzwerken, um die Ausbreitung von Angriffen einzudaemmen. In Kubernetes sind Network Policies das Werkzeug dafuer.

Ausgangspunkt ist eine Default-Deny-Policy pro Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: logistics
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Dann werden gezielt die erlaubten Verbindungen freigeschaltet. Beispiel: Der Tracking-Service darf nur von der Kafka-Ingestion Daten empfangen und nur auf die Datenbank zugreifen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tracking-service-policy
  namespace: logistics
spec:
  podSelector:
    matchLabels:
      app: tracking-service
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingestion
          podSelector:
            matchLabels:
              app: kafka-consumer
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: timescaledb
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Das Prinzip: Jeder Service bekommt nur die Verbindungen, die er tatsaechlich braucht. Wenn ein Angreifer den Tracking-Service kompromittiert, kann er weder andere Services erreichen noch ins Internet kommunizieren.

Audit Logging: Nachweispflicht erfuellen

NIS2 verlangt lueckenloses Logging und die Faehigkeit, Sicherheitsvorfaelle nachzuvollziehen. Kubernetes liefert dafuer Audit Logs auf API-Server-Ebene.

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets und ConfigMaps: Aenderungen vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
    verbs: ["create", "update", "patch", "delete"]

  # Deployments, StatefulSets, DaemonSets: Aenderungen loggen
  - level: RequestResponse
    resources:
      - group: "apps"
        resources: ["deployments", "statefulsets", "daemonsets"]
    verbs: ["create", "update", "patch", "delete"]

  # RBAC-Aenderungen: Immer vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # Read-Only Operationen: Nur Metadaten
  - level: Metadata
    verbs: ["get", "list", "watch"]

  # Alles andere: Request-Body loggen
  - level: Request

Die Audit-Policy wird beim Start des API-Servers angegeben:

# In der API-Server-Konfiguration (z.B. /etc/kubernetes/manifests/kube-apiserver.yaml)
# folgende Flags hinzufuegen:
#   --audit-policy-file=/etc/kubernetes/audit-policy.yaml
#   --audit-log-path=/var/log/kubernetes/audit.log
#   --audit-log-maxage=90
#   --audit-log-maxbackup=10
#   --audit-log-maxsize=100

# Alternativ: Audit Logs direkt an ein Webhook-Backend senden
#   --audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml

Fuer NIS2 ist besonders wichtig, dass ihr nachweisen koennt: Wer hat wann welche Aenderung an der Infrastruktur vorgenommen? Die Audit Logs muessen mindestens 90 Tage vorgehalten werden (Empfehlung des BSI).

Incident Response: Die groesste Luecke schliessen

Die Technik ist bei den meisten Teams nicht das Problem. Die groesste NIS2-Luecke ist der fehlende Incident-Response-Prozess. NIS2 verlangt, dass erhebliche Sicherheitsvorfaelle innerhalb von 24 Stunden gemeldet werden.

Was ihr braucht:

Alerting-Regeln fuer sicherheitsrelevante Events. Mindestens diese Alerts sollten konfiguriert sein:

• Fehlgeschlagene Authentifizierungsversuche am API-Server
• Aenderungen an RBAC-Rollen und -Bindings
• Pods mit privilegierten Containern oder Host-Netzwerk
• Unbekannte Images (nicht aus der erlaubten Registry)
• Network Policy Violations (bei Cilium ueber Hubble)

Runbooks fuer jeden Alert-Typ. Ein Runbook beschreibt: Was ist passiert? Wer muss informiert werden? Welche Sofortmassnahmen sind zu ergreifen? Wie wird dokumentiert?

Regelmaessige Tests. Fuehrt mindestens quartalsweise einen simulierten Sicherheitsvorfall durch. Prueft, ob die Meldekette funktioniert und die Dokumentation vollstaendig ist.

Pod Security Standards: Haertung der Workloads

Kubernetes Pod Security Standards (PSS) definieren drei Stufen: Privileged, Baseline und Restricted. Fuer NIS2-relevante Workloads sollte mindestens Baseline gelten, besser Restricted.

# Namespace mit Restricted PSS konfigurieren
apiVersion: v1
kind: Namespace
metadata:
  name: logistics
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Im restricted-Modus koennen Pods nicht mehr als Root laufen, keine Host-Namespaces verwenden und muessen ein Read-Only Root Filesystem haben. Das verhindert eine ganze Klasse von Angriffen.

Wenn bestehende Workloads noch nicht mit Restricted kompatibel sind, startet mit audit statt enforce. So seht ihr in den Logs, welche Pods angepasst werden muessen, ohne den Betrieb zu stoeren.

Secrets Management: Verschluesselung als Pflicht

NIS2 fordert den Einsatz von Kryptographie. Kubernetes Secrets sind standardmaessig nur Base64-codiert, nicht verschluesselt. Das muss geaendert werden.

Zwei praktische Optionen:

Encryption at Rest konfigurieren: Der API-Server verschluesselt Secrets automatisch, bevor sie in etcd geschrieben werden.

External Secrets Operator mit Vault: Secrets werden in HashiCorp Vault gespeichert und ueber den External Secrets Operator in Kubernetes synchronisiert. Das ist der sicherere Ansatz, weil die Secrets nie im Klartext in etcd liegen.

# ExternalSecret: Datenbank-Credentials aus Vault laden
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: tracking-db-credentials
  namespace: logistics
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: tracking-db-secrets
  data:
    - secretKey: db_host
      remoteRef:
        key: secret/data/logistics/tracking-db
        property: host
    - secretKey: db_password
      remoteRef:
        key: secret/data/logistics/tracking-db
        property: password

Backup und Business Continuity

NIS2 verlangt Massnahmen zur Aufrechterhaltung des Betriebs. In Kubernetes heisst das:

• PodDisruptionBudgets (PDBs): Stellen sicher, dass waehrend Rolling Updates oder Node-Wartung immer genug Replikas laufen
• Multi-AZ Deployments: Pods ueber mehrere Verfuegbarkeitszonen verteilen
• Velero Backups: Regelmaessige Backups der Cluster-Konfiguration und Persistent Volumes
• Disaster Recovery Plan: Dokumentierter Prozess fuer die Wiederherstellung des Clusters

Der DR-Plan muss getestet werden. Ein Backup, das nie restauriert wurde, ist kein Backup.

Schrittweiser Rollout

Monat 1: Sichtbarkeit schaffen. Audit Logging aktivieren. Prometheus und Grafana installieren. Baseline-Metriken erheben. Bestandsaufnahme der aktuellen Sicherheitslage.

Monat 2: Segmentierung und Haertung. Network Policies pro Namespace einfuehren (erst Audit-Modus, dann Enforcement). Pod Security Standards aktivieren. Secrets Management umstellen.

Monat 3: Prozesse etablieren. Incident-Response-Runbooks schreiben. Alerting-Regeln konfigurieren. Ersten simulierten Sicherheitsvorfall durchfuehren. NIS2-Compliance-Dokumentation erstellen.

Weitergehende Themen

• Audit Logging im Detail -- Policy-Konfiguration und SIEM-Anbindung
• Network Policies Advanced -- Komplexe Segmentierungsszenarien
• Compliance-Automation -- Policy-as-Code mit OPA und Kyverno
• Security Scanning -- Image- und Konfigurationspruefung
• Storage-Loesungen -- Persistente Daten DSGVO-konform speichern

Fazit

NIS2 klingt zunaechst nach viel Buerokratie, aber die technischen Anforderungen sind mit Kubernetes gut umsetzbar. Network Policies, RBAC, Audit Logging und Pod Security Standards decken den Grossteil ab. Die eigentliche Arbeit liegt in den Prozessen: Incident Response, Dokumentation und regelmaessiges Testen.

Fuer die Abfallwirtschaft bietet die Umstellung einen doppelten Nutzen: Neben der NIS2-Compliance bekommt ihr eine moderne Plattform, auf der IoT-Daten aus Fahrzeugen und Sensoren zuverlaessig verarbeitet werden koennen. Das ist die Grundlage fuer Routenoptimierung, vorausschauende Wartung und besseres Reporting.

Wenn ihr Unterstuetzung bei der NIS2-Umsetzung oder der Architektur eurer Entsorgungslogistik auf Kubernetes braucht, sprecht uns an unter /kontakt.