NIS2-Richtlinie: Kubernetes-Compliance praktisch umsetzen

TL;DR

Die NIS2-Richtlinie verpflichtet viele Unternehmen zu konkreten Cybersicherheitsmassnahmen -- auch fuer Container-Infrastrukturen. Kubernetes-Betreiber muessen Incident-Detection und -Reporting einrichten, Supply-Chain-Sicherheit durch SBOMs nachweisen und Risikomanagement dokumentieren. Dieser Artikel zeigt die technische Umsetzung mit Falco, Syft und Alertmanager.

Was NIS2 fuer Kubernetes-Betreiber bedeutet

Die NIS2-Richtlinie (EU 2022/2555) ist seit Oktober 2024 in nationales Recht umzusetzen. Sie betrifft deutlich mehr Unternehmen als die urspruengliche NIS-Richtlinie: Neben kritischer Infrastruktur fallen jetzt auch Unternehmen aus den Bereichen digitale Dienste, Fertigung, Lebensmittel und Forschung unter die Regelung.

Wenn Ihre Organisation Container-Workloads betreibt, ist die Kubernetes-Infrastruktur Teil Ihrer IT-Systeme und damit im Scope von NIS2. Drei Bereiche sind besonders relevant:

• Artikel 21: Risikomanagement-Massnahmen fuer die Cybersicherheit
• Artikel 23: Meldepflichten bei Sicherheitsvorfaellen (24 Stunden Fruehwarnung, 72 Stunden Bericht)
• Artikel 21 Abs. 2d: Sicherheit der Lieferkette

NIS2-Anforderungen auf Kubernetes abbilden

Incident Detection mit Falco und Alertmanager

NIS2 verlangt, dass Sicherheitsvorfaelle erkannt und innerhalb von 24 Stunden an die zustaendige Behoerde gemeldet werden. Dafuer brauchen Sie automatisierte Detection.

Falco ueberwacht Syscalls in Containern und erkennt verdaechtiges Verhalten. Installieren Sie Falco und konfigurieren Sie Alertmanager als Ausgabekanal:

# falco-values.yaml fuer Helm-Installation
falco:
  rules_file:
    - /etc/falco/falco_rules.yaml
    - /etc/falco/k8s_audit_rules.yaml
    - /etc/falco/rules.d
  json_output: true
  http_output:
    enabled: true
    url: "http://falcosidekick.security:2801"

falcosidekick:
  enabled: true
  config:
    alertmanager:
      hostport: "http://alertmanager.monitoring:9093"
      minimumpriority: "warning"
    webhook:
      address: "https://incident-api.intern/nis2/fruehwarnung"
      minimumpriority: "critical"

Der Webhook an incident-api.intern triggert bei kritischen Events Ihren NIS2-Meldeprozess. Das muss kein vollautomatisches Meldesystem sein -- ein Ticket im Incident-Management-System mit Eskalation genuegt als erster Schritt.

Definieren Sie NIS2-spezifische Falco-Regeln fuer meldepflichtige Vorfaelle:

# nis2-detection-rules.yaml
- rule: NIS2 - Unauthorized Data Access
  desc: Zugriff auf sensitive Daten ausserhalb normaler Muster
  condition: >
    spawned_process and container and
    (proc.name in (curl, wget) and
     fd.sip_name != "localhost") and
    k8s.ns.name in (production, pii-data)
  output: >
    NIS2-MELDEPFLICHTIG: Unautorisierter Datenzugriff
    (user=%user.name pod=%k8s.pod.name ns=%k8s.ns.name
     command=%proc.cmdline image=%container.image.repository)
  priority: CRITICAL
  tags: [nis2, meldepflicht, data-breach]

- rule: NIS2 - Container Escape Attempt
  desc: Versuch eines Container-Ausbruchs erkannt
  condition: >
    spawned_process and container and
    proc.name in (nsenter, unshare) and
    not proc.pname in (runc, containerd-shim)
  output: >
    NIS2-MELDEPFLICHTIG: Container-Escape-Versuch
    (pod=%k8s.pod.name ns=%k8s.ns.name command=%proc.cmdline)
  priority: CRITICAL
  tags: [nis2, meldepflicht, container-escape]

Meldeprozess technisch abbilden

NIS2 definiert klare Fristen: 24 Stunden fuer die Fruehwarnung, 72 Stunden fuer den vollstaendigen Bericht. Bilden Sie das in Ihrem Alerting ab:

# alertmanager-nis2-config.yaml
route:
  group_by: ['alertname', 'namespace']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default'
  routes:
    # NIS2-meldepflichtige Vorfaelle: Sofortige Eskalation
    - match:
        nis2_meldepflicht: "true"
      receiver: 'nis2-incident'
      group_wait: 0s
      repeat_interval: 15m

receivers:
  - name: 'nis2-incident'
    pagerduty_configs:
      - service_key: '<pagerduty-key>'
        severity: 'critical'
        description: 'NIS2-MELDEPFLICHT: {{ .CommonAnnotations.summary }}'
    email_configs:
      - to: 'ciso@unternehmen.de,it-sicherheit@unternehmen.de'
        send_resolved: true
        headers:
          Subject: '[NIS2-MELDEPFLICHT] {{ .CommonAnnotations.summary }}'
    webhook_configs:
      - url: 'https://ticketsystem.intern/api/nis2-incident'
        send_resolved: true

Der entscheidende Punkt: Die group_wait: 0s fuer NIS2-Alerts stellt sicher, dass keine Verzoegerung durch Alert-Gruppierung entsteht. Bei meldepflichtigen Vorfaellen zaehlt jede Minute.

Supply-Chain-Sicherheit mit SBOMs

Artikel 21 Abs. 2d fordert Sicherheit der Lieferkette. Fuer Container bedeutet das: Sie muessen wissen, welche Software in Ihren Images steckt. Software Bill of Materials (SBOM) machen das nachvollziehbar.

Integrieren Sie SBOM-Generierung in Ihre CI/CD-Pipeline mit Syft:

#!/bin/bash
# sbom-pipeline.sh - SBOM-Generierung und -Speicherung

IMAGE="registry.intern/app:${CI_COMMIT_SHA}"

# 1. SBOM im SPDX-Format generieren
syft "${IMAGE}" -o spdx-json > sbom-spdx.json

# 2. SBOM im CycloneDX-Format (alternative Darstellung)
syft "${IMAGE}" -o cyclonedx-json > sbom-cdx.json

# 3. Bekannte Schwachstellen gegen SBOM pruefen
grype sbom:sbom-spdx.json --fail-on critical -o json > vuln-report.json

# 4. SBOM an zentrales Repository senden
cosign attach sbom --sbom sbom-spdx.json "${IMAGE}"

# 5. Image signieren fuer Herkunftsnachweis
cosign sign --key cosign.key "${IMAGE}"

echo "SBOM generiert: $(jq '.packages | length' sbom-spdx.json) Pakete erfasst"
echo "Kritische Schwachstellen: $(jq '.matches | map(select(.vulnerability.severity == "Critical")) | length' vuln-report.json)"

Speichern Sie SBOMs fuer jedes produktive Image. Bei einem Supply-Chain-Vorfall (z.B. eine neu entdeckte Schwachstelle in einer Bibliothek) koennen Sie sofort pruefen, welche Deployments betroffen sind.

Risikomanagement dokumentieren

NIS2 verlangt systematisches Risikomanagement. Fuer Kubernetes bedeutet das: Dokumentieren Sie die Risiken Ihrer Container-Infrastruktur und die Massnahmen dagegen.

Ein praxistauglicher Ansatz:

Risiko 1: Kompromittierter Container

• Eintrittswahrscheinlichkeit: Mittel
• Auswirkung: Hoch (Datenzugriff, Lateral Movement)
• Massnahmen: Network Policies, Pod Security Standards, Falco-Monitoring
• Restrisiko: Niedrig nach Umsetzung

Risiko 2: Supply-Chain-Angriff ueber Container-Images

• Eintrittswahrscheinlichkeit: Mittel
• Auswirkung: Hoch (Code-Ausfuehrung in Produktion)
• Massnahmen: Image Signing, SBOM, Vulnerability Scanning, Private Registry
• Restrisiko: Niedrig nach Umsetzung

Risiko 3: Datenverlust durch fehlendes Backup

• Eintrittswahrscheinlichkeit: Niedrig
• Auswirkung: Kritisch (Business Continuity)
• Massnahmen: Velero-Backups, etcd-Snapshots, Multi-Cluster-Setup
• Restrisiko: Niedrig nach Umsetzung

Aktualisieren Sie die Risikobewertung mindestens jaehrlich oder nach signifikanten Aenderungen an der Infrastruktur. Der NIS2-Auditor wird nach dem Datum der letzten Aktualisierung fragen.

Verschluesselung und Netzwerksicherheit

Artikel 21 Abs. 2e fordert den Einsatz von Kryptographie. In Kubernetes decken Sie das ueber drei Ebenen ab:

1. Encryption at Rest: Secrets im etcd verschluesseln (EncryptionConfiguration)
2. Encryption in Transit: mTLS zwischen Services (Service Mesh oder Cilium)
3. Network Policies: Netzwerksegmentierung zwischen Namespaces

Network Policies sind fuer NIS2 besonders relevant, weil sie Lateral Movement einschraenken -- ein Kernziel der Richtlinie:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nis2-default-deny
  namespace: production
  labels:
    nis2.compliance: "art-21-2e"
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  # Default Deny: Kein Traffic erlaubt, ausser explizit freigegeben
  ingress: []
  egress:
    # Nur DNS erlauben
    - to: []
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Beginnen Sie mit Default-Deny in Produktions-Namespaces und geben Sie Traffic gezielt frei. Das entspricht dem Least-Privilege-Prinzip, das NIS2 fordert.

Haeufig gestellte Fragen

Faellt mein Unternehmen ueberhaupt unter NIS2?

NIS2 betrifft Unternehmen mit mindestens 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in bestimmten Sektoren (Energie, Transport, Gesundheit, digitale Infrastruktur, Fertigung und weitere). Pruefen Sie Anhang I und II der Richtlinie fuer die vollstaendige Liste.

Reicht es, nur den Kubernetes-Cluster abzusichern?

Nein. NIS2 betrifft die gesamte IT-Infrastruktur. Kubernetes ist ein Teil davon. Sie brauchen ein uebergreifendes Cybersicherheitskonzept, in das Ihre Container-Plattform eingebettet ist.

Was passiert, wenn ich die 24-Stunden-Meldefrist verpasse?

NIS2 sieht Bussgelder von bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes vor. Die Meldefrist beginnt ab Kenntnis des Vorfalls. Automatisierte Detection reduziert die Zeit zwischen Vorfall und Kenntnis.

Muessen SBOMs fuer alle Container-Images vorliegen?

Die Richtlinie fordert Supply-Chain-Sicherheit, schreibt aber kein spezifisches Format vor. SBOMs sind der de-facto-Standard und die beste Methode, um Transparenz ueber verwendete Softwarekomponenten herzustellen. Beginnen Sie mit produktiven Workloads.

Kann ich NIS2-Compliance mit Open-Source-Tools erreichen?

Ja. Falco, Syft, Grype, Cosign und Alertmanager sind alle Open Source. Entscheidend ist nicht die Lizenz der Tools, sondern dass die Prozesse dokumentiert und nachweisbar sind.