Laborbuch — Technische und organisatorische Maßnahmen (TOM)
TOM gem. Art. 32 DSGVO für den Self-Hosted-Betrieb von Laborbuch.
Produkt: Laborbuch — elektronische FuE-Stundenaufzeichnung mit Beweissicherung (FZulG/BSFZ) Anbieter: Advena Partners, inh.Adam Koch, Weißensteinstr. 44, 58093 Hagen Betriebsmodell: Self-Hosted (Betrieb ausschließlich auf Infrastruktur des Kunden) Dokument: TOM gem. Art. 32 DSGVO · Version 1.0 · Stand: 17.07.2026
1. Architekturprinzip: Self-Hosting und geteilte Verantwortung
Laborbuch wird als Docker-Image ausgeliefert und ausschließlich auf der Infrastruktur des Kunden betrieben. Der Anbieter hat im Regelbetrieb keinen Zugriff auf die Instanz, die Datenbank oder die verarbeiteten personenbezogenen Daten. Es existiert kein zentraler SaaS-Dienst; pro Kunde läuft eine dedizierte Instanz mit dedizierter Datenbank (Ein-Mandanten-Architektur — eine Instanz = ein Labor).
Daraus ergibt sich eine geteilte Verantwortung:
| Ebene | Verantwortlich |
|---|---|
| Maßnahmen im Produkt (Softwarefunktionen, Abschnitte 4–7) | Anbieter (Implementierung), Kunde (Konfiguration) |
| Maßnahmen der Betriebsumgebung (Host, Netzwerk, Backups, physische Sicherheit) | Kunde als Betreiber (Abschnitt 8) |
| Support-Zugriffe (nur auf ausdrückliche Anforderung des Kunden) | gesonderter AVV, siehe Abschnitt 9 |
2. Verarbeitete Datenkategorien
| Kategorie | Inhalt | Anmerkung |
|---|---|---|
| Benutzerkonten | Login, Name, E-Mail-Adresse, Rollen | angelegt durch Kunden-Admin |
| Zeiteinträge | Datum, Stunden, Tätigkeits-/Ergebnisbeschreibung, Projekt/Vorhaben, Erfassungsregime, FuE/Routine-Kennzeichnung | Beschäftigtendaten i. S. v. § 26 BDSG |
| Commit-Metadaten | SHA, Zeitstempel, Autor, Commit-Nachricht | optional (Git-Integration abschaltbar) |
| Beweisdateien | Scans, Messdaten, Fotos oder nur deren SHA-256 | je nach Modus, siehe 4.3/4.5 |
| Lesezugriffs-Protokoll | wer wann welchen Bericht/welche Datei abgerufen hat | append-only, siehe 5.3 |
3. Externe Datenflüsse (produktseitig)
Alle externen Datenflüsse sind konfigurierbar bzw. abschaltbar und in der Standardkonfiguration auf das Minimum reduziert:
| Dienst | Zweck | Übermittelte Daten | Steuerung |
|---|---|---|---|
| BeatTime (Zeitstempeldienst des Anbieters) | Proof-of-Existence der Wochenabschlüsse | ausschließlich SHA-256-Hash — niemals Inhalte | Ed25519-signierte Antwort, Merkle-Kette |
| OpenTimestamps-Kalenderserver | Verankerung des Wochen-Hashes in der Bitcoin-Blockchain | ausschließlich Hash | abschaltbar (OTS_ENABLED) |
| GitHub API | Import von Commit-Metadaten (eingehend) | ausgehend nur Lese-Token des Kunden | optional (enable_git) |
| Anthropic Claude API | optionale Übersetzung der Einträge PL→DE für Berichte | Inhalt der übersetzten Einträge | nur bei aktiver Nutzung der Funktion; ohne API-Schlüssel inaktiv |
| SMTP-Server des Kunden | Versand von E-Mail-Einmalcodes (2FA) | E-Mail-Adresse, Einmalcode | Konto und Server wählt der Betreiber |
| S3-Objektspeicher des Betreibers | Ablage von Beweisdateien | Dateien (bei aktiviertem Schlüssel verschlüsselt, siehe 4.3) | optional; ohne S3 lokale Ablage |
| Öffentliche Website der Instanz | Außendarstellung | keine Cookies, keine Analytik, keine Drittanfragen | — |
4. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
4.1 Zugangskontrolle (Systemzugang)
- Passwortrichtlinien (Mindestlänge, Ähnlichkeits-, Trivialpasswort- und Zahlenprüfung).
- Zwei-Faktor-Authentisierung pro Benutzer, Methode wird durch den Admin je Konto festgelegt: TOTP-App (z. B. Google Authenticator), Hardware-TOTP-Token/Karte (Seed-Eingabe durch Admin, Toleranz für Uhren-Drift) oder E-Mail-Einmalcode.
- Der Admin-Bereich ist an denselben 2FA-Login gebunden (keine Umgehung über ein separates Admin-Login).
- Brute-Force-Schutz: Sperrung nach 5 Fehlversuchen für 15 Minuten je Kombination (Benutzername, IP-Adresse); erfolgreiche Anmeldung setzt den Zähler zurück.
- Transportverschlüsselung erzwungen: TLS-Redirect, HSTS (12 Monate, inkl. Subdomains), Secure-Cookies. Optional zusätzlicher Zugang als Tor Onion Service (v3).
4.2 Zugriffskontrolle (Datenzugriff)
- Rollenmodell: Forscher/in, FuE-Leitung, CMS-Redaktion.
- Zweistufige Projektsichtbarkeit: Mitglieder (dürfen Einträge anlegen) vs. Beobachter (reine Einsicht). Durchsetzung serverseitig in der Datenbankabfrage, nicht nur in der Oberfläche.
- Stundenmaskierung: Beobachter sehen Tätigkeiten der Kolleginnen und Kollegen, jedoch nicht deren Stundenwerte — auch in allen Exporten (PDF/CSV).
- Beweisdateien werden nur nach serverseitiger Berechtigungsprüfung ausgeliefert (kurzlebige signierte URLs, 300 s, bzw. applikationsseitiges Streaming).
4.3 Verschlüsselung
- At-rest (Beweisdateien): AES-256-GCM. Der SHA-256-Hash wird vor der Verschlüsselung über die Klartextdatei gebildet (der Hash geht in den gestempelten Wochenabschluss ein); im Speicher liegt ausschließlich das Chiffrat. Der Schlüssel (32 Byte) verbleibt beim Betreiber (Umgebungsvariable) und verlässt die Instanz nicht.
- In transit: TLS (siehe 4.1); Tor-Zugriff Ende-zu-Ende innerhalb des Tor-Netzes.
- Datenbank- und Volume-Verschlüsselung auf Hostebene: betreiberseitig (Abschnitt 8).
4.4 Trennungskontrolle
- Dedizierte Instanz und dedizierte Datenbank pro Kunde; eine Vermischung von Mandanten ist architektonisch ausgeschlossen.
4.5 Datenminimierung / Pseudonymisierung
- Hash-only-Modus (instanzweit wählbar): Beweisdateien werden nicht hochgeladen; der Browser berechnet lokal den SHA-256, gespeichert werden nur Hash, Dateiname, Größe und Änderungsdatum. Die Instanz besitzt die Inhalte zu keinem Zeitpunkt — der Nachweis erfolgt durch Vorlage des Originals und Hash-Vergleich.
- Zeitstempeldienste erhalten ausschließlich Hashes (Zero-Knowledge-Stempelung).
- Öffentliche Website ohne Cookies, ohne Tracking, ohne Einbindung Dritter.
5. Integrität (Art. 32 Abs. 1 lit. b DSGVO)
5.1 Eingabekontrolle
- Append-only-Journal: Nach dem Wochenabschluss sind Einträge unveränderlich und unlöschbar (auf Modellebene erzwungen); Korrekturen ausschließlich als neue Storno-Einträge mit Verweis auf den korrigierten Eintrag.
- Autorenzuordnung je Eintrag; getrennte Erfassungsregime (zeitnahe Erfassung vs. gekennzeichnete nachträgliche Rekonstruktion).
- Harte Plausibilitätsregeln: max. 40 FuE-Stunden/Woche pro Person (§ 3 FZulG), max. 20 Stunden/Tag gesamt, keine Null-Einträge, negative Stunden nur als Storno.
- Explizite Abgrenzung FuE vs. Routine: Nicht-FuE-Arbeit wird dokumentiert und gekennzeichnet, zählt aber nicht in FuE-Summen und Berichte ein.
5.2 Manipulationserkennung (Beweissicherung)
- Wochenabschluss: kanonisches JSON aller Einträge inkl. Anker → SHA-256 → doppelte Zeitstempelung: BeatTime (Hash-Kette, Merkle-Baum, Ed25519-Signatur) und OpenTimestamps (Verankerung in der Bitcoin-Blockchain).
- Beweisdateien und Commits sind über SHA-256 bzw. Commit-SHA Bestandteil des gestempelten JSON — nachträgliche Änderungen sind erkennbar.
5.3 Protokollierung von Lesezugriffen
- Append-only-Protokoll: Abruf von Berichten (Stundenaufzeichnung, BSFZ-Basis, inkl. Exportformat) und Download von Beweisdateien mit Benutzer und Zeitpunkt. Änderung/Löschung der Protokolleinträge ist auf Modellebene blockiert.
6. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b–c DSGVO)
Produktseitig:
- Containerisierter Betrieb (Docker), automatische Migrationen beim Start,
Health-Endpunkt (/healthz), Neustart-Policy.
- Exportfunktionen (PDF, CSV) für sämtliche Berichtsdaten.
- Zeitstempelnachweise sind unabhängig von der Instanz verifizierbar
(BeatTime-Belege, OTS-Dateien, Bitcoin-Blockchain) — der Beweiswert übersteht
auch einen Totalverlust der Instanz.
- Nach Lizenzablauf: Read-only-Betrieb mit vollem Export (geplant) —
Nachweisdaten werden niemals eingeschlossen.
Betreiberseitig (Empfehlungen, Abschnitt 8): Datenbank-Backups, Versionierung des Objektspeichers, redundante Ablage der Schlüssel, Host-Härtung.
7. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)
- Abhängigkeiten versionsfixiert; Updates werden als neue Container-Images geliefert.
- Signierte Container-Images (cosign) und SBOM: geplant.
- OTS-Nachweise werden nach Bitcoin-Bestätigung aktualisiert (upgradebar).
- Der Kunde kann die Integrität der Aufzeichnung jederzeit selbst prüfen (Hash-Nachrechnung des kanonischen JSON gegen die gestempelten Belege).
8. Pflichten des Betreibers (Kunde)
Die folgenden Maßnahmen liegen beim self-hosted Betrieb in der Verantwortung des Kunden; der Anbieter stellt Konfigurationshinweise bereit:
- TLS-Terminierung/Reverse-Proxy und Firewall der Umgebung.
- Physische Sicherheit und Festplattenverschlüsselung des Hosts.
- Regelmäßige, verschlüsselte Backups der Datenbank und des Objektspeichers; Wiederherstellungstests.
- Sichere Verwahrung der Schlüssel (
SECRET_KEY, Dateiverschlüsselungs-Schlüssel, S3-Zugangsdaten, SMTP-Zugangsdaten) sowie deren Rotation. - Benutzer-Lebenszyklus: zeitnahe Deaktivierung ausgeschiedener Beschäftigter, Zuweisung der 2FA-Methode je Benutzer.
- Aktualisierung der Container-Images bei neuen Releases.
- Aufbewahrungsfristen: steuerlich relevante Aufzeichnungen unterliegen GoBD/AO-Fristen (i. d. R. 10 Jahre) — Löschkonzepte sind darauf abzustimmen.
9. Auftragsverarbeitung
Im Regelbetrieb findet keine Auftragsverarbeitung durch den Anbieter statt
(kein Zugriff auf personenbezogene Daten). Für Support-Einsätze mit Datenzugriff
auf ausdrückliche Anforderung des Kunden wird ein gesonderter
Auftragsverarbeitungsvertrag (AVV) geschlossen — Muster: AVV-Muster.de.md
(im selben Verzeichnis). Zur Aufbewahrung nach GoBD/AO siehe
GoBD-Aufbewahrung.de.md.
Der Zeitstempeldienst BeatTime verarbeitet ausschließlich SHA-256-Hashes ohne Personenbezug; eine Auftragsverarbeitung im Sinne von Art. 28 DSGVO liegt insoweit nicht vor. Die optionale Übersetzungsfunktion (Anthropic Claude API) übermittelt Eintragsinhalte an Anthropic; ihre Aktivierung liegt in der Entscheidung und Verantwortung des Kunden (eigener API-Schlüssel, abschaltbar).
10. Maßnahmenstatus (Übersicht)
| Maßnahme | Status |
|---|---|
| 2FA pro Benutzer (App / Hardware-Token / E-Mail) | implementiert |
| Brute-Force-Sperre | implementiert |
| TLS/HSTS/Secure-Cookies | implementiert |
| Rollen, Projektsichtbarkeit, Stundenmaskierung | implementiert |
| AES-256-GCM at-rest (Beweisdateien) | implementiert (Aktivierung durch Betreiber-Schlüssel) |
| Hash-only-Modus (Datenminimierung) | implementiert |
| Append-only-Journal + Storno | implementiert |
| Doppelte Zeitstempelung (BeatTime + OTS) | implementiert |
| Lesezugriffs-Protokoll (append-only) | implementiert |
| Tor Onion Service | implementiert (optional) |
| Read-only-Betrieb mit Export nach Lizenzablauf | geplant |
| Signierte Images (cosign), SBOM | geplant |
| Host-/Backup-/Netzwerksicherheit | betreiberseitig |
Änderungshistorie: v1.0 (17.07.2026) — Erstfassung.