NIS2 und die KI-Transformation der Fertigungsindustrie: Wie OpenKBS die Einhaltung des NIS2UmsuCG gewährleistet

Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) ist am 6. Dezember 2025 in Kraft getreten und setzt die Richtlinie (EU) 2022/2555 in deutsches Recht um. Das Gesetz erfasst rund 29.500 Unternehmen in Deutschland — ohne Übergangsfrist. Die Registrierungspflicht beim BSI (Bundesamt für Sicherheit in der Informationstechnik) besteht seit dem 6. März 2026.

Mittlere und große Fertigungsunternehmen fallen als „wichtige Einrichtungen" in den Anwendungsbereich des Gesetzes (Unternehmen ab 50 Beschäftigten und 10 Mio. EUR Jahresumsatz in den Sektoren nach Anhang II der Richtlinie). Für diese Organisationen stellt NIS2 eine konkrete Herausforderung dar: Wie lassen sich KI-Lösungen in Fertigungsprozesse integrieren, ohne das regulatorische und cybersicherheitsbezogene Risiko zu erhöhen? Diese Veröffentlichung beschreibt, wie die Plattform OpenKBS die Anforderungen des NIS2UmsuCG für ihre Enterprise-Kunden adressiert.

Infrastruktursicherheit durch AWS

OpenKBS betreibt die Infrastruktur seiner Kunden vollständig auf Amazon Web Services (AWS). Damit wird ein umfangreicher Katalog unabhängig geprüfter Zertifizierungen und Attestierungen übernommen, darunter:

ISO/IEC 27001 — Informationssicherheits-Managementsystem;
ISO/IEC 22301 — Business Continuity Management;
ISO/IEC 27017 — Sicherheitskontrollen für Cloud-Dienste;
SOC 2 Type II — Kontrollen für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz;
C5 — Cloud Computing Compliance Criteria Catalogue, entwickelt vom BSI — der maßgebliche deutsche Standard für Cloud-Sicherheit.

AWS verfügt über mehr als 150 unabhängig geprüfte Sicherheitszertifizierungen weltweit. Im Kontext des NIS2UmsuCG ist dies wesentlich, da Art. 21 Abs. 1 der Richtlinie (EU) 2022/2555 verlangt, dass Risikomanagementmaßnahmen dem „Stand der Technik" entsprechen. Die Nutzung zertifizierter Infrastruktur belegt die Einhaltung dieses Grundsatzes.

In Deutschland ist AWS bereits Teil der nationalen Kritischen Infrastruktur (KRITIS). Amazon EC2 und Amazon CloudFront fallen in den KRITIS-Regulierungsbereich, und AWS ist Mitglied der Initiative UP KRITIS — einer gemeinsamen Anstrengung von Industrie und Bundesregierung zur Festlegung von Branchenstandards für Cybersicherheit. Der C5-Katalog des BSI gilt als Referenzstandard für Cloud-Dienste, die in der deutschen Verwaltung und von regulierten Unternehmen eingesetzt werden.

Modell der geteilten Verantwortung

AWS wendet das Modell der geteilten Verantwortung (Shared Responsibility Model) an:

AWS verantwortet die Sicherheit der Cloud-Infrastruktur — physische Rechenzentren, Netzwerk, Hypervisor, verwaltete Dienste;
Der Kunde verantwortet die Sicherheit dessen, was in der Cloud aufgebaut wird — Anwendungscode, Konfigurationen, Zugriffssteuerung.

Für Enterprise-Kunden durchläuft jede Lösung vor der Inbetriebnahme einen strukturierten Audit- und Sicherheitsüberprüfungsprozess.

Dedizierter AWS-Account für jeden Enterprise-Kunden

Zu den zentralen Anforderungen des NIS2UmsuCG gehört die Gewährleistung der Betriebskontinuität und des Krisenmanagements (Art. 21 Abs. 2 lit. c) der Richtlinie (EU) 2022/2555). Die Richtlinie betont zudem die Sicherheit der Lieferkette (Art. 21 Abs. 2 lit. d)), einschließlich des Managements von Risiken aus Abhängigkeiten gegenüber Technologieanbietern.

OpenKBS adressiert diese Anforderungen durch ein Modell dedizierter AWS-Accounts.

Funktionsweise

Jeder Enterprise-Kunde erhält einen eigenen AWS-Account, in dem sämtliche Ressourcen bereitgestellt werden:

Ressource	Beschreibung
Lambda-Funktionen	Serverless-Berechnungen für Geschäftslogik (bis zu 20 pro Projekt)
S3-Speicher	Objektspeicher für Dateien und Daten
Aurora PostgreSQL	Verwaltete relationale Datenbank mit automatischen Backups und Point-in-Time-Wiederherstellung
CloudFront CDN	Content Distribution mit TLS-Verschlüsselung
EventBridge	Geplante Aufgaben und Automatisierungen

Die Ressourcen eines Kunden sind physisch von den Ressourcen jedes anderen Kunden auf AWS-Account-Ebene isoliert. Dies ist keine logische Trennung (Namespace, Tag oder virtuelles Netzwerk), sondern eine harte Grenze auf Account-Ebene, durchgesetzt durch AWS Identity and Access Management (IAM).

Übertragung der Infrastruktur bei Vertragsende

Bei Vertragsende oder bei Bedarf kann der dedizierte AWS-Account vollständig an den Kunden übertragen werden. Der Prozess umfasst:

Änderung des Root-Benutzers des Accounts auf eine kundeneigene E-Mail-Adresse;
Bestätigung durch den Kunden und Festlegung eines neuen Passworts;
Entfernung des Accounts aus der AWS Organization von OpenKBS;
Der Kunde fügt eine Zahlungsmethode hinzu und übernimmt die volle Kontrolle;
Der Kunde entfernt den Zugriff von OpenKBS durch Löschen der Cross-Account-IAM-Rolle.

Es wird nichts migriert. Lambda-Funktionen laufen weiter, Daten in S3 und Aurora bleiben an Ort und Stelle, CloudFront-Distributionen bedienen den Datenverkehr ohne Unterbrechung. Der Kunde erhält die volle Kontrolle über seine Infrastruktur ohne Datenverlust und ohne Ausfallzeit.

Alle Ressourcen sind Standard-AWS-Primitive — keine proprietären Formate, kein Vendor Lock-in. Der Kunde kann die Infrastruktur eigenständig oder mit einem anderen Anbieter weiterbetreiben.

AWS Organizations ermöglicht die Erstellung von bis zu 50.000 Accounts innerhalb einer Organisation, ohne zusätzliche Gebühren für den Account selbst. Abgerechnet wird ausschließlich der Ressourcenverbrauch innerhalb des Accounts.

Bedeutung für die NIS2-Compliance

Art. 21 Abs. 2 lit. c) (Betriebskontinuität): Die Infrastruktur ist unabhängig vom operativen Status von OpenKBS. Bei Einstellung der Tätigkeit des Anbieters kann der Kunde den Betrieb fortsetzen.
Art. 21 Abs. 2 lit. d) (Sicherheit der Lieferkette): Das Risiko einer Abhängigkeit von einem einzelnen Anbieter wird durch die garantierte vollständige Übertragungsmöglichkeit minimiert.
Klausel 5 der NIS2-Vertragsanforderungen (Unterstützung bei Beendigung und Datensicherheit): Konstruktionsbedingt abgedeckt — die Daten befinden sich bereits in einem Account, den der Kunde vollständig übernehmen kann.

Datenstandort und Serverless-Architektur

Hosting in der Europäischen Union

Alle Ressourcen der Enterprise-Kunden werden standardmäßig in der AWS-Region eu-central-1 (Frankfurt, Deutschland) bereitgestellt. Die zentrale Plattformdatenbank (AWS Aurora DSQL) arbeitet ausschließlich in eu-central-1.

Die Daten verlassen das Gebiet der EU nicht. Jedes Kundenprojekt erhält:

S3-Speicher in eu-central-1;
Aurora PostgreSQL-Instanz in eu-central-1;
Lambda-Funktionen, die in eu-central-1 ausgeführt werden;
CloudFront-Distribution mit Edge-Standorten in der EU.

Der Datenstandort ist ein Schlüsselfaktor bei der Risikobewertung gemäß NIS2. Die Bereitstellung der Infrastruktur in der EU vereinfacht die Einhaltung der Datenschutzanforderungen und erleichtert die Interaktion mit den nationalen Regulierungsbehörden.

Serverless-Architektur und reduzierte Angriffsfläche

OpenKBS verwendet eine vollständig serverlose Architektur für Kundenressourcen. Das bedeutet:

Keine Server zu warten — kein Betriebssystem zum Aktualisieren, kein SSH-Zugang, keine offenen Ports;
AWS verwaltet die Laufzeitumgebung — Node.js 24.x auf Lambda, mit automatischen Sicherheitsupdates;
Isolation auf Ausführungsebene — jede Lambda-Funktion wird in einer separaten microVM-Umgebung ausgeführt;
TLS 1.2+ für alle Kommunikationen — über CloudFront, ohne Ausnahmen.

Aus Sicht von Art. 21 Abs. 2 lit. e) der Richtlinie (EU) 2022/2555 (Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen) eliminiert die Serverless-Architektur eine ganze Klasse von Schwachstellen — ungepatchte Betriebssysteme, fehlkonfigurierte Server, unautorisierter Netzwerkzugriff.

Sicherheit von KI-generiertem Code

Die Realität der modernen Softwareentwicklung

Ein erheblicher und wachsender Anteil des Programmcodes in der Industrie wird mithilfe von KI-Modellen generiert. Diese Entwicklung ist unumkehrbar. Die Frage ist nicht, ob KI den Code generieren wird, sondern welche Prozesse die Qualität und Sicherheit dieses Codes gewährleisten.

KI-generierter Code ist nicht per se unsicher. Moderne Sprachmodelle (wie Claude von Anthropic) erkennen Schwachstellen im Code effizienter als die meisten manuellen Überprüfungen — einschließlich SQL-Injections, XSS-Angriffe, unautorisierter Zugriff, fehlerhafte Sitzungsverwaltung und Dutzende weiterer Kategorien aus den OWASP Top 10 und CWE-Klassifikationen.

Die Risiken von KI-generiertem Code resultieren nicht aus dem Modell selbst, sondern aus dem Fehlen von Audit- und Validierungsprozessen. Ein System, in dem generierter Code ohne Überprüfung direkt eingesetzt wird, ist riskant — unabhängig davon, ob der Code von einem Menschen oder einer KI geschrieben wurde.

Der OpenKBS-Prozess für Enterprise-Kunden

OpenKBS wendet bei jeder neuen Version der Kundenlösung einen strukturierten Sicherheitsüberprüfungsprozess an:

Automatisierter Sicherheitsaudit bei jeder Version:

Statische Codeanalyse auf Schwachstellen aus den OWASP Top 10;
Prüfung auf SQL-Injections, XSS, CSRF, SSRF, Command Injection;
Abhängigkeitsanalyse (Dependency Audit) auf bekannte Schwachstellen (CVE);
Prüfung auf Offenlegung sensibler Daten (hartcodierte Anmeldedaten, API-Schlüssel, Connection Strings);
Validierung der Eingabedaten und Zugriffskontrolle;
Prüfung auf unautorisierte Informationsweitergabe in HTTP-Antworten und Fehlerbehandlung.

Infrastrukturüberprüfung:

Überprüfung der IAM-Richtlinien und des Prinzips der geringsten Privilegien (Least Privilege);
Validierung der Verschlüsselung bei Übertragung (TLS) und im Ruhezustand (AES-256);
Prüfung auf öffentlich zugängliche Ressourcen (S3 Buckets, Lambda-Endpunkte);
Audit der Netzwerkkonfiguration und Firewall-Regeln.

Dokumentierter Bericht:

Jeder Audit erzeugt einen dokumentierten Bericht mit Feststellungen und Empfehlungen;
Kritische Schwachstellen werden vor der Inbetriebnahme in der Produktivumgebung behoben;
Die Berichte stehen dem Kunden zur Verfügung und können bei Audits den Regulierungsbehörden vorgelegt werden.

Dieser Prozess adressiert die Anforderungen von Art. 21 Abs. 2 lit. e) (Sicherheit bei Entwicklung und Wartung) und Art. 21 Abs. 2 lit. f) (Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen).

Konsolidierung der KI-Lieferkette

Eine Organisation, die KI-Modelle mehrerer Anbieter (OpenAI, Anthropic, Google) nutzen möchte, muss separate Verträge abschließen, separate Risikobewertungen durchführen und die NIS2-Compliance für jeden einzelnen sicherstellen.

OpenKBS konsolidiert den Zugang zu mehreren KI-Modellen über einen einheitlichen Proxy, der in der EU-Infrastruktur der Plattform betrieben wird. Der Kunde interagiert mit einem Anbieter (OpenKBS), der die Verantwortung für die Integration mit den KI-Anbietern übernimmt.

Dies reduziert:

die Anzahl der Anbieter, die gemäß Art. 21 Abs. 2 lit. d) des NIS2UmsuCG zu bewerten sind;
die Anzahl der Verträge, die die fünf obligatorischen Klauseln zur Lieferkettensicherheit enthalten müssen;
den Verwaltungsaufwand bei der regelmäßigen Überprüfung der Anbieter.

Weitere Compliance-Maßnahmen

Verschlüsselung

Gemäß Art. 21 Abs. 2 lit. h) der Richtlinie (EU) 2022/2555 (Konzepte für den Einsatz von Kryptografie):

Bei Übertragung: TLS 1.2+ für alle Kommunikationen, ohne Ausnahmen;
Im Ruhezustand: AES-256 für sensible Daten (Connection Strings, API-Schlüssel), AWS-verwaltete Verschlüsselung für S3 und Aurora;
Zugriffstoken: Werden als SHA-256-Hash gespeichert, der Originaltext wird nicht aufbewahrt;
MQTT-Kommunikation: SigV4-signierte WebSocket-Verbindungen mit temporären STS-Sitzungstoken (15 Minuten Gültigkeit).

Zugriffskontrolle

Gemäß Art. 21 Abs. 2 lit. i) (Sicherheit des Personals, Zugriffskontrolle):

JWT-basierte Authentifizierung (RS256) mit begrenzter Gültigkeitsdauer;
Per-Project-API-Schlüssel mit explizit definierten Berechtigungen;
Automatische Schlüsselrotation bei jedem Deployment;
STS Session Credentials mit 15-minütiger Gültigkeit für Cross-Account-Zugriff.

Audit-Protokoll

Gemäß Art. 21 Abs. 2 lit. f) (Bewertung der Wirksamkeit der Maßnahmen):

Administratives Audit-Protokoll: Aktionstyp, betroffene Ressource, Details, IP-Adresse;
Nachverfolgung des Ressourcenverbrauchs nach Projekt und Zeitraum;
CloudWatch-Metriken für jede Funktion (Aufrufe, Dauer, Fehler).

Backups, Wiederherstellung und Notfallplan

Gemäß Art. 21 Abs. 2 lit. c) (Betriebskontinuität, Backup-Management, Disaster Recovery und Krisenmanagement):

Datenbank (Aurora PostgreSQL Serverless v2):

Automatische kontinuierliche Backups, verwaltet von AWS;
Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Restore) mit sekundengenauer Präzision, für einen konfigurierbaren Zeitraum von bis zu 35 Tagen;
Daten werden in sechs Kopien über drei Availability Zones innerhalb der Region eu-central-1 gespeichert;
Bei Ausfall der primären Instanz schaltet Aurora automatisch auf eine Standby-Replik um.

Objektspeicher (S3):

Objektversionierung — jede Änderung oder Löschung bewahrt die vorherige Version;
AWS S3 bietet 99,999999999 % (11 Neunen) Datenhaltbarkeit;
Daten werden in mehreren Availability Zones innerhalb der Region gespeichert.

Allgemeine Grundsätze:

Weiches Löschen (Soft Delete) aller Ressourcen — kein unwiderrufliches Löschen;
Die Serverless-Architektur eliminiert die Notwendigkeit der Server-Wiederherstellung — bei Ausfall einer Lambda-Instanz startet AWS automatisch eine neue;
CloudFront CDN gewährleistet die Bereitstellung des Datenverkehrs auch bei teilweiser Nichterreichbarkeit des Origin-Servers.

Zusammenfassung: Abdeckung der Mindestmaßnahmen nach Art. 21 NIS2

Maßnahme nach Art. 21 Abs. 2	Wie OpenKBS diese adressiert
a) Risikoanalyse und Sicherheitskonzepte	Strukturierter Auditprozess bei jeder Version; dokumentierte Berichte
b) Bewältigung von Sicherheitsvorfällen	Incident-Response-Verfahren; 24-Stunden-Frühwarnung an den Kunden
c) Betriebskontinuität	Dedizierter AWS-Account; Aurora PITR bis 35 Tage; S3-Versionierung; 6 Kopien in 3 AZ
d) Sicherheit der Lieferkette	Konsolidierter KI-Proxy; einheitlicher Vertrag; übertragbarer Account
e) Sicherheit bei Entwicklung und Wartung	Sicherheitsaudit bei jeder Version; Serverless-Architektur
f) Bewertung der Wirksamkeit der Maßnahmen	Audit-Protokoll; Ressourcenüberwachung; CloudWatch-Metriken
g) Cybersicherheitsschulungen	Beratung und Dokumentation für Kundenteams
h) Kryptografie und Verschlüsselung	TLS 1.2+; AES-256; SHA-256 für Token; SigV4 für MQTT
i) Zugriffskontrolle	JWT-Authentifizierung; Per-Project-Schlüssel; automatische Rotation
j) MFA und verschlüsselte Kommunikation	Verschlüsselte WebSocket-Verbindungen; STS Session Credentials

Nächster Schritt

OpenKBS arbeitet mit Fertigungsunternehmen in Deutschland und Europa zusammen, die KI-Lösungen unter Einhaltung der Anforderungen des NIS2UmsuCG implementieren.

Wenn Ihre Organisation in den Anwendungsbereich des NIS2UmsuCG fällt und eine KI-Transformation plant, kontaktieren Sie uns für eine Beratung zu:

Bewertung Ihrer aktuellen Infrastruktur anhand der Anforderungen des NIS2UmsuCG;
Konzeption einer KI-Lösung in einem dedizierten AWS-Account mit EU Data Residency;
Prozesse für Sicherheitsaudits bei KI-generiertem Code;
Plan für Betriebskontinuität und Krisenmanagement.

Die beschriebenen Leistungen — Sicherheitsaudit, dedizierter AWS-Account und Überprüfung von KI-generiertem Code — sind Teil des Enterprise-Plans von OpenKBS.

Diese Veröffentlichung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Bei konkreten Fragen zur Anwendung des NIS2UmsuCG wenden Sie sich an einen qualifizierten Rechtsberater.

Book a Strategy Call

NIS2NIS2UmsuCGBSICybersicherheitFertigungProduktionAWSKISupply ChainEnterprise