NIS2 fuer Zulieferer: Wenn der OEM-Kunde Compliance verlangt

TL;DR

• NIS2 verpflichtet regulierte Unternehmen, ihre gesamte Lieferkette auf Cybersicherheit zu pruefen. Als Zulieferer werden Sie diese Anforderungen erfuellen muessen -- oder den Kunden verlieren.
• OEM-Kunden verlangen zunehmend Nachweise fuer Netzwerksegmentierung, Zugriffskontrollen, Schwachstellenmanagement und Incident-Response-Faehigkeiten in der IT-Infrastruktur ihrer Lieferanten.
• Kubernetes bietet mit RBAC, Network Policies und Policy-as-Code die technischen Mittel, diese Anforderungen nachweisbar und auditierbar umzusetzen.
• Starten Sie mit einer Gap-Analyse gegen die typischen OEM-Frageboegen, nicht mit der NIS2-Richtlinie selbst. Die Kundenanforderungen sind konkreter und oft strenger.
• Die Investition zahlt sich doppelt aus: Sie erfuellen nicht nur die Anforderungen eines Kunden, sondern aller Kunden -- und schuetzen Ihr eigenes Unternehmen.

Warum NIS2 ploetzlich Ihr Problem ist

Sie betreiben ein mittelstaendisches Unternehmen mit 400 Mitarbeitern, liefern Komponenten an einen Automobilhersteller und haben bisher mit NIS2 nichts zu tun gehabt. Ihr Unternehmen faellt nicht direkt unter die Regulierung -- Sie sind weder kritische Infrastruktur noch gross genug fuer die NIS2-Schwellenwerte.

Dann kommt die E-Mail vom Einkauf Ihres groessten Kunden: Ab dem naechsten Vertragsupdate muessen Sie einen Cybersicherheits-Fragebogen ausfuellen. 87 Fragen zu Netzwerksicherheit, Zugriffsmanagement, Schwachstellenmanagement, Incident Response und Business Continuity. Bei Nichterfuellung droht Auslistung.

Was ist passiert? Artikel 21 Absatz 2 Buchstabe d der NIS2-Richtlinie verpflichtet regulierte Unternehmen zur "Sicherheit der Lieferkette einschliesslich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern." Ihr OEM-Kunde muss seine Lieferkette absichern -- und reicht die Anforderungen an Sie weiter.

Was OEM-Kunden typischerweise verlangen

Die Anforderungen variieren je nach Branche und Kunde, aber bestimmte Themen tauchen in fast jedem Zulieferer-Assessment auf. Hier eine Zusammenfassung der gaengigsten Forderungen, uebersetzt auf Kubernetes-Infrastruktur:

Die vollstaendige Aufstellung der DSGVO- und BSI-Anforderungen fuer Kubernetes finden Sie in unserem Compliance-Leitfaden.

Die typischen OEM-Frageboegen verstehen

OEM-Kunden nutzen haeufig standardisierte Frageboegen, die auf internationalen Frameworks basieren. Als Zulieferer muessen Sie wissen, welches Framework hinter den Fragen steckt, um effizient antworten zu koennen:

Unabhaengig vom Fragebogen: Die Fragen lassen sich fast immer auf dieselben technischen Kontrollen zurueckfuehren. Wer seine Kubernetes-Infrastruktur einmal sauber absichert, kann die meisten Frageboegen aus einer gemeinsamen Datenbasis beantworten.

Netzwerksegmentierung: Die erste Forderung jedes OEM

"Beschreiben Sie, wie Ihre Produktionsnetzwerke von anderen Netzwerken getrennt sind." Diese Frage kommt in jedem Assessment vor. In Kubernetes bedeutet Netzwerksegmentierung: Namespaces plus Network Policies.

# network-policies-zulieferer.yaml
# Netzwerksegmentierung fuer OEM-Compliance
# Trennung von Kundenprojekten und internen Systemen

# Policy 1: Kundenprojekt-Namespace komplett isolieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-oem-projekt-alpha
  namespace: oem-projekt-alpha
  labels:
    compliance: nis2-supply-chain
    oem-kunde: automotive-ag
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Nur Traffic vom Ingress Controller erlauben
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-system
      ports:
        - protocol: TCP
          port: 8080
  egress:
    # Nur DNS und eigene Datenbank erlauben
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: oem-projekt-alpha
      ports:
        - protocol: TCP
          port: 5432

---
# Policy 2: Default-Deny fuer alle Produktions-Namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: produktion
  labels:
    compliance: nis2-supply-chain
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Das Prinzip: Jeder Kunden-Namespace ist per Default vollstaendig isoliert. Nur explizit freigegebene Kommunikationswege sind offen. Dieses Modell laesst sich direkt im OEM-Assessment als Nachweis vorlegen -- inklusive der YAML-Dateien und der Dokumentation, welche Kommunikationswege warum erlaubt sind.

Zugriffskontrollen: Wer darf was auf Ihrem Cluster?

"Beschreiben Sie Ihr Berechtigungskonzept und wie Sie das Least-Privilege-Prinzip umsetzen." Die zweithaeufigste Frage in OEM-Assessments. Kubernetes RBAC liefert die technische Antwort:

# rbac-zulieferer-compliance.yaml
# Rollenbasierte Zugriffskontrolle fuer OEM-Compliance
# Umsetzung des Least-Privilege-Prinzips

# Rolle: Entwickler im OEM-Projekt (eingeschraenkt)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oem-projekt-developer
  namespace: oem-projekt-alpha
  labels:
    compliance: nis2-supply-chain
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  # Kein create, update, delete -- nur ueber CI/CD-Pipeline

---
# Rolle: CI/CD-Pipeline (eingeschraenkt auf Deployments)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oem-projekt-cicd
  namespace: oem-projekt-alpha
  labels:
    compliance: nis2-supply-chain
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "create", "update"]

---
# RoleBinding: Entwickler an Rolle binden
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: oem-developer-binding
  namespace: oem-projekt-alpha
subjects:
  - kind: Group
    name: "oem-alpha-developers"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: oem-projekt-developer
  apiGroup: rbac.authorization.k8s.io

Entscheidend fuer das Assessment: Dokumentieren Sie nicht nur die technische Konfiguration, sondern auch den Prozess. Wer beantragt Zugriffsrechte? Wer genehmigt sie? Wie oft werden sie ueberprueft? OEM-Assessments fragen immer nach dem Prozess hinter der Technik.

Eine ausfuehrliche Anleitung zu Enterprise-RBAC finden Sie in unserem RBAC-Leitfaden.

Schwachstellenmanagement: Nachweisbar und kontinuierlich

"Wie stellen Sie sicher, dass bekannte Schwachstellen zeitnah gepatcht werden?" OEM-Kunden erwarten keine perfekte Infrastruktur, aber sie erwarten einen nachvollziehbaren Prozess. Fuer Kubernetes bedeutet das: automatisiertes Image Scanning mit definierten SLAs.

Diese SLAs muessen Sie nicht nur definieren, sondern auch nachweisen. Integrieren Sie Trivy oder Grype in Ihre CI/CD-Pipeline und exportieren Sie die Scan-Ergebnisse in ein Reporting-System. Im Assessment koennen Sie dann zeigen: "In den letzten 6 Monaten hatten wir 12 CRITICAL CVEs, alle innerhalb von 48 Stunden gepatcht. Hier sind die Tickets."

Der Auditierbare Cluster: Was der OEM-Pruefer sehen will

Wenn ein OEM-Kunde (oder sein beauftragter Auditor) Ihre Infrastruktur prueft, reichen muendliche Aussagen nicht. Sie brauchen technische Nachweise. Folgende Artefakte sollten Sie vorhalten:

Automatisch generiert:

• CIS Benchmark Reports (kube-bench), monatlich
• Image-Scan-Reports (Trivy), bei jedem Deployment und taeglich fuer laufende Images
• RBAC-Konfiguration als Code (Git-versioniert)
• Network Policy Dokumentation als Code (Git-versioniert)
• Audit-Log-Retention-Nachweis (mindestens 12 Monate)

Manuell gepflegt:

• Sicherheitskonzept mit Kubernetes-spezifischem Kapitel
• Berechtigungskonzept mit Rollen und Verantwortlichkeiten
• Incident-Response-Plan mit NIS2-spezifischen Meldeprozessen
• Ergebnisse der letzten Penetration Tests
• Schulungsnachweise fuer das Operations-Team

Wie Sie Compliance-Nachweise ohne dediziertes Security-Team erstellen, beschreibt unser Artikel Kubernetes Compliance ohne Security-Team.

Supply-Chain-Security fuer Ihre eigene Lieferkette

NIS2 wirkt in beide Richtungen: Ihr OEM-Kunde prueft Sie, aber Sie muessen auch Ihre eigenen Lieferanten pruefen. Auf Kubernetes bedeutet das vor allem: Container-Image-Supply-Chain-Security.

Jedes Container-Image, das Sie in Ihrem Cluster einsetzen, ist ein Glied in der Software-Lieferkette. Wenn ein Base-Image kompromittiert ist, hilft die beste Netzwerksegmentierung nichts.

Massnahmen fuer die Image-Supply-Chain:

• Nur signierte Images zulassen. Nutzen Sie Cosign/Sigstore, um Images zu signieren, und Kyverno, um nur signierte Images im Cluster zuzulassen.
• Private Registry verwenden. Ziehen Sie Images nicht direkt von Docker Hub in Produktion. Spiegeln Sie sie in eine private Registry und scannen Sie dort.
• SBOM (Software Bill of Materials) generieren. Fuer jedes Image, das Sie deployen, sollten Sie eine SBOM vorhalten koennen. Tools wie Syft generieren SBOMs automatisch.
• Base-Image-Updates automatisieren. Nutzen Sie Renovate oder Dependabot, um ueber neue Versionen Ihrer Base-Images informiert zu werden.

Kosten und Aufwand realistisch einschaetzen

Die Frage, die jeder Geschaeftsfuehrer stellt: Was kostet das? Hier eine realistische Einschaetzung fuer ein Mittelstandsunternehmen mit bestehender Kubernetes-Infrastruktur:

Gesamt: 15-26 Personentage einmalig, danach 2-3 Personentage pro Monat laufend. Verglichen mit dem Risiko, einen Grosskunden zu verlieren, ist das eine ueberschaubare Investition.

Einen detaillierten Kostenvergleich zwischen internem und externem Kubernetes-Betrieb finden Sie in unserem Kostenvergleich.

Zeitplan: In 90 Tagen OEM-auditierbar

Dieser Zeitplan ist ambitioniert, aber realistisch, wenn ein erfahrener DevOps-Engineer 50% seiner Zeit dafuer einsetzen kann. Wenn das intern nicht moeglich ist, kann ein externer Dienstleister die technische Umsetzung beschleunigen.

Fazit: NIS2 Supply Chain als Chance begreifen

Die NIS2-Lieferkettenanforderungen fuehlen sich zunaechst wie eine Last an. Noch ein Fragebogen, noch ein Audit, noch mehr Dokumentation. Aber betrachten Sie es aus einer anderen Perspektive:

• Wettbewerbsvorteil: Zulieferer, die NIS2-Compliance nachweisen koennen, stehen bei der Lieferantenauswahl besser da als solche, die es nicht koennen.
• Kundenbindung: Ein OEM, der weiss, dass seine Lieferkette sicher ist, wechselt weniger leicht den Zulieferer.
• Eigener Schutz: Die Massnahmen, die Sie fuer den OEM implementieren, schuetzen auch Ihr eigenes Unternehmen vor Cyberangriffen.
• Skalierbarkeit: Was Sie einmal fuer einen OEM aufgebaut haben, gilt fuer alle Kunden. Der zweite Fragebogen ist halb so viel Arbeit.

Die technische Basis auf Kubernetes ist vorhanden. RBAC, Network Policies, Audit Logs und Image Scanning sind keine Zusatzprodukte -- sie sind Teil der Plattform. Sie muessen sie nur aktivieren, konfigurieren und dokumentieren.

Weitergehende Themen

• KRITIS und IT-SiG 2.0 auf Kubernetes -- Fuer Zulieferer in regulierten Branchen
• Security Hardening fuer Kubernetes -- Technische Baseline absichern
• Kubernetes Monitoring und Observability -- Nachweisbares Monitoring aufbauen

Sie muessen Ihre Kubernetes-Infrastruktur fuer ein OEM-Assessment vorbereiten und brauchen Unterstuetzung bei der technischen Umsetzung oder Dokumentation? Schreiben Sie uns unter /kontakt.