Entwurf – juristische Prüfung ausstehend (A15)

Technische und organisatorische Maßnahmen (TOM)

Anbieter: Jasmann Werk 52, Inhaber Muhammad Saeed, Elberfelder Str. 72, 42553 Velbert (Einzelunternehmen).

1. Vertraulichkeit

1.1 Zutrittskontrolle

Die Server stehen in einem Rechenzentrum der Hetzner Online GmbH in Deutschland. Zutritt, Überwachung und Stromversorgung regelt Hetzner; Nachweise dazu stellt Hetzner auf Anfrage bereit.
Der Anbieter betreibt keine eigenen Server in Büroräumen. Der Arbeitsrechner, auf dem verschlüsselte Sicherungen liegen, steht in den Räumen des Anbieters (Velbert).

1.2 Zugangskontrolle (Systeme)

Server: Anmeldung nur per SSH mit kryptografischem Schlüssel, Kennwortanmeldung abgeschaltet. Nach außen offen sind nur die Ports 22, 80 und 443.
Anwendung: Kennwörter werden nur als scrypt-Prüfwert gespeichert. Ein zweiter Faktor (TOTP) ist Pflicht für jede Rolle, die Berichte erzeugt, freigibt, versendet, abrechnet oder Zugänge verwaltet (Administrator, Qualität); für Werkstattrollen, die nur Messwerte erfassen oder lesen (Werker, Leser), ist er freiwillig. Der Kunde kann ihn in den Einstellungen für alle Rollen verlangen (»Zweiten Faktor für alle verlangen«, nur Administration, protokolliert). Wer ihn eingerichtet hat, braucht ihn bei jeder Anmeldung. Wird ein Zugang während einer Sitzung pflichtig (Rollenwechsel, Schalter), führt seine nächste Anfrage in die Einrichtung. Nach fünf Fehlversuchen (Kennwort oder zweiter Faktor) wird der Zugang zunehmend gesperrt, höchstens eine Stunde; zusätzlich bremst eine Anfragegrenze je IP-Adresse.
Sitzungen: Das Sitzungscookie trägt 32 zufällige Byte; in der Datenbank steht nur deren SHA-256. Das Cookie ist HttpOnly, Secure, SameSite=Lax und als __Host--Cookie an die eigene Adresse gebunden. Jeder schreibende Aufruf braucht zusätzlich ein CSRF-Merkmal. Eine Sitzung endet nach 4 Stunden ohne Aufruf, spätestens nach 12 Stunden; nach der Anmeldung entsteht ein neues Cookie.

1.3 Zugriffskontrolle (Daten)

Rollen je Nutzer: Administrator, Qualität, Werker, Leser. Die Schnittstelle prüft die Rolle bei jedem Aufruf.
Row Level Security: Jede Tabelle mit Geschäftsdaten trägt die Kennung des Betriebs; die Datenbank liefert nur Zeilen des Betriebs, der für die Anfrage gesetzt ist. Ohne gesetzten Betrieb liefert keine Abfrage eine Zeile. Die Datenbankrolle der Anwendung ist weder Eigentümer der Tabellen noch Superuser und hat kein Recht, die Regeln zu umgehen; die Anwendung verweigert den Start, wenn das anders ist. Automatische Prüfungen weisen mit zwei Betrieben nach, dass kein Betrieb die Daten des anderen lesen kann.
Betreiberzugriff: Eine eigene Rolle für Verwaltungsaufgaben arbeitet über die Grenzen der Betriebe hinweg. Sie läuft nur auf ausdrücklichen Aufruf auf dem Server; Änderungen, die sie vornimmt, stehen im Änderungsprotokoll des betroffenen Betriebs.

1.4 Trennungskontrolle

Trennung der Betriebe in der Datenbank (1.3) und in der Dateiablage: je Betrieb ein eigenes Verzeichnis und ein eigener Datenschlüssel.
Getrennte Umgebungen: Entwicklung und Prüfung arbeiten nur mit erzeugten Beispielzeichnungen; Zeichnungen von Kunden kommen nie in das Quellcode-Archiv.
Auf dem geteilten Server hat irot Erstmuster eigene Container, eine eigene Datenbank und feste Ressourcengrenzen.

1.5 Verschlüsselung und Pseudonymisierung

Dateien: AES-256-GCM mit dem Datenschlüssel des Betriebs. Die Datenschlüssel sind mit einem Hauptschlüssel verpackt, der nicht in der Datenbank steht. Jeder Geheimtext ist an Betrieb und Datei gebunden: eine in ein fremdes Verzeichnis kopierte Datei lässt sich nicht entschlüsseln. Beim Lesen wird die Prüfsumme nachgerechnet; eine veränderte Datei wird nicht ausgeliefert.
Zweiter Faktor: Die TOTP-Geheimnisse sind ebenfalls mit dem Schlüssel des Betriebs verschlüsselt.
Übertragung: nur verschlüsselt (TLS). HSTS ist für cnc-x.de und app.cnc-x.de eingeschaltet (ein Jahr, mit Subdomains).
Sicherungen: mit age verschlüsselt; der private Schlüssel liegt nicht auf dem Server.
Schwärzen: Auf Wunsch erzeugt die Anwendung eine Kopie einer Zeichnung ohne Schriftfeld, Firmen- und Personenangaben; die Kopie wird neu aufgebaut, sodass unter den Schwärzungen nichts erhalten bleibt.

1.6 Löschung

Einzelheiten im Löschkonzept.

Aufbewahrungsfrist für Zeichnungen und daraus abgeleitete Dateien: 30, 90 oder 365 Tage oder unbegrenzt, eingestellt vom Kunden in der Anwendung – je Betrieb und für einzelne seiner Kunden kürzer. Die Frist gilt ab dem Hochladen für alle Dateien; ein stündlicher Löschlauf entfernt fällige Dateien vom Datenträger.
Null-Retention: Auf Wunsch des Kunden (je Betrieb oder je Kunde) werden Zeichnung, Seitenbilder und Ausschnitte gelöscht, sobald die Merkmale geprüft sind und der Bericht vollständig ausgegeben ist. Die Kopie der gestempelten Zeichnung in den erzeugten Berichten (PDF und ZIP) folgt 7 Tage nach der Ausgabe oder 10 Minuten nach dem Versand; es bleiben der Bericht ohne Zeichnung und das Excel.
Vorrang von Aufbewahrungspflichten: Dateien von Teilen, die der Kunde als sicherheitsrelevant (D/TLD) markiert, und Rechnungen löscht kein Automatismus.
Nachweis: Jede Löschung steht mit Grund und Dateiklasse, ohne Inhalt, im Änderungsprotokoll des Betriebs; die Zeile der Datei bleibt ohne Inhalt stehen.
Vertragsende: Ein Befehl der Betreiberkonsole löscht alle Daten und Dateien eines Betriebs nach einem Trockenlauf und einer ausdrücklichen Bestätigung und ersetzt seinen Datenschlüssel (Krypto-Löschung). Rechnungen bleiben nach den gesetzlichen Fristen; ein Löschnachweis bleibt im Protokoll und geht in Textform an den Kunden. Sicherungen von vor dem Löschtag enthalten die Daten, bis sie planmäßig ablaufen.

2. Integrität

2.1 Weitergabekontrolle

Die Oberfläche lädt nichts von fremden Servern; eine strenge Content-Security-Policy erlaubt nur eigene Quellen. Keine Analyse-, Werbe- oder Fehlerverfolgungsdienste.
Die Zeichnung wird auf dem eigenen Server gelesen. An einen Dienst außerhalb gehen Daten nur nach der Liste der Unterauftragnehmer; an generative KI-Dienste nie eine Zeichnung.
Hochgeladene Dateien werden geprüft (Art, Größe, Seitenzahl); Excel-Vorlagen von Kunden werden gegen Makros, Archivbomben und externe Verweise geprüft.

2.2 Eingabekontrolle

Änderungsprotokoll: Alles, was in einem unterschriebenen Bericht steht – Bestätigung von Merkmalen, Änderung einer Toleranz, Freigabe des Prüfplans, Ausgaben, Entscheidungen zu n.i.O. –, hinterlässt einen Eintrag: wer, wann, was, vorher, nachher. Zeitpunkt und Prüfsummenkette setzt die Datenbank selbst; ein Auslöser weist jedes Ändern und Löschen von Einträgen zurück. Die Kette lässt sich jederzeit nachrechnen.
Unveränderliche Stände: Ein freigegebener Prüfplan ist unveränderlich; eine Änderung erzeugt eine neue Version.
Berechnete Urteile: i.O./n.i.O. wird aus Messwert und Grenzmaß berechnet, nie eingetippt.

3. Verfügbarkeit und Belastbarkeit

Tägliche, verschlüsselte Sicherung von Datenbank und Dateien; 14 Tage auf dem Server, Kopien beim Anbieter ebenfalls höchstens 14 Tage; danach überschrieben. Zugriff nur für den Inhaber.
Möglicher Datenverlust im Ernstfall: höchstens seit der letzten Nacht (RPO 24 Stunden). Wiederanlauf (RTO): etwa 15 Minuten auf dem vorhandenen Server, 1–2 Stunden auf einem neuen (Wiederherstellungsproben September 2026, Prüfkette und alle Dateien nach der Rückspielung geprüft).
Die Dienste starten nach einem Absturz selbst neu; eine Gesundheitsprüfung läuft alle 30 Sekunden.
Feste Grenzen für Speicher und Rechenzeit verhindern, dass ein Dienst andere verdrängt.
Fehler in Hintergrundaufträgen und gehäufte Serverfehler meldet die Anwendung per E-Mail an den Anbieter.

4. Wiederherstellbarkeit

Wiederherstellung aus einer Sicherung in eine getrennte Umgebung, mit Nachrechnen des Änderungsprotokolls je Betrieb und Prüfung jeder Datei; die laufende Produktion bleibt dabei unberührt.
Probe vierteljährlich; die erste Probe ist vor dem ersten zahlenden Kunden vorgesehen (Stand: ausstehend).

5. Verfahren zur regelmäßigen Überprüfung

Automatische Prüfungen bei jeder Änderung des Programms, darunter die Trennung der Betriebe, die Unveränderlichkeit des Protokolls und die Ver- und Entschlüsselung. Ein Stand mit fehlgeschlagener Prüfung wird nicht ausgeliefert.
Sicherheitsupdates des Betriebssystems täglich automatisch.
Sicherheitsprüfung des Codes (September 2026, 18 Befunde, alle behoben und mit Regressionstests abgesichert), Prüfung der Abhängigkeiten (pip-audit, npm audit ohne Befund) und Anfragegrenzen an allen öffentlichen Endpunkten und Anfragegrößen. Wiederholung vor jeder größeren Änderung der Zugangs- oder Dateiwege.
Überprüfung dieser TOM mindestens jährlich und bei jeder wesentlichen Änderung.

6. Auftragskontrolle

Unterauftragnehmer nur mit Vertrag nach Art. 28 Abs. 4 DSGVO; Liste und Stand im Dokument Unterauftragnehmer.
Weisungen des Kunden werden über die Einstellungen der Anwendung (Aufbewahrung je Betrieb und je Kunde, Null-Retention, Training, KI-Textfunktionen) und in Textform erteilt. Die Einstellungen zu Aufbewahrung und Null-Retention ändert nur die Administration des Betriebs; jede Änderung steht im Änderungsprotokoll.

7. Organisatorische Maßnahmen

Personen mit Zugriff auf Server oder Sicherungen: der Inhaber allein; weitere Personen erhalten Zugriff erst nach schriftlicher Verpflichtung zur Vertraulichkeit.
Geheimnisse (Schlüssel, Kennwörter) nie im Quellcode-Archiv und nie in Nachrichten; der Hauptschlüssel liegt zusätzlich im Passwortmanager des Anbieters.
Datensparsamkeit: Der Webserver schreibt kein Zugriffsprotokoll; die Anwendung protokolliert Zugriffe auf Zeichnungen mit Betrieb, aber ohne Inhalt.