#003 Datenmodell und Migrationen #3

New Issue

2026-10-12T15:12:33Z

florian.wilde commented

2026-10-12 15:12:33 +00:00

Ziel

Prisma-Schema für alle Phasen (Hosts, Gruppen, Personen, Schlüssel, Verwendungen, Host-Keys, Vorgänge, Protokoll), erste Migration, Seed.

Aufgaben

Schema mit deutschen Bezeichnern (siehe CLAUDE.md)
Datenbankregeln (CHECK, Trigger) für das, was auch an der Service-Schicht vorbei gelten muss
Seed: Notfall-Admin, eingebaute Vorlagen (Demo-Daten folgen mit #008)
Test-Datenbank-Setup für Vitest

Akzeptanzkriterien

Migration läuft auf leerer Datenbank
Tests für die Datenbankregeln

Abhängigkeiten

#001

Notizen / Entscheidungen

Protokoll-Hash in der Datenbank berechnet (Trigger), nicht in der Anwendung: so kann niemand eine Zeile ohne Verkettung einfügen. Die ID wird erst unter einer Advisory-Sperre vergeben, sonst bricht die Kette bei gleichzeitigem Schreiben (Test mit 20 parallelen Einträgen).
TRUNCATE des Protokolls nur mit SET LOCAL sshkv.test_modus = 'ja' – ausschließlich für die Testhilfe. Ein Datenbank-Superuser kann Trigger immer abschalten; dagegen hilft die Hash-Kette (Prüfung findet die manipulierte Zeile) und später der Syslog-Export (#027).
Zielbenutzer, Adresse und Private-Key-Pfad per CHECK eingeschränkt: Diese Werte landen in Shell-Skripten auf den Hosts. Quotierung bleibt Pflicht, aber was gar nicht erst in die Datenbank kommt, kann nichts anrichten.
TOTP-Geheimnis mit SSHKV_APP_SECRET verschlüsselt, nicht mit dem Master-Key: geprüft wird es im Webprozess, und der Master-Key bleibt im Worker.
Ein Host-Key-Wechsel ist eine neue Zeile AUSSTEHEND neben der vertrauten; je Host und Algorithmus höchstens ein vertrauter Key (partieller Index).

Quelle: docs/issues/003-datenmodell.md – dort wird dieses Issue gepflegt.

## Ziel Prisma-Schema für alle Phasen (Hosts, Gruppen, Personen, Schlüssel, Verwendungen, Host-Keys, Vorgänge, Protokoll), erste Migration, Seed. ## Aufgaben - [x] Schema mit deutschen Bezeichnern (siehe `CLAUDE.md`) - [x] Datenbankregeln (CHECK, Trigger) für das, was auch an der Service-Schicht vorbei gelten muss - [x] Seed: Notfall-Admin, eingebaute Vorlagen (Demo-Daten folgen mit #008) - [x] Test-Datenbank-Setup für Vitest ## Akzeptanzkriterien - [x] Migration läuft auf leerer Datenbank - [x] Tests für die Datenbankregeln ## Abhängigkeiten #001 ## Notizen / Entscheidungen - **Protokoll-Hash in der Datenbank berechnet** (Trigger), nicht in der Anwendung: so kann niemand eine Zeile ohne Verkettung einfügen. Die ID wird erst unter einer Advisory-Sperre vergeben, sonst bricht die Kette bei gleichzeitigem Schreiben (Test mit 20 parallelen Einträgen). - **TRUNCATE des Protokolls** nur mit `SET LOCAL sshkv.test_modus = 'ja'` – ausschließlich für die Testhilfe. Ein Datenbank-Superuser kann Trigger immer abschalten; dagegen hilft die Hash-Kette (Prüfung findet die manipulierte Zeile) und später der Syslog-Export (#027). - **Zielbenutzer, Adresse und Private-Key-Pfad per CHECK eingeschränkt:** Diese Werte landen in Shell-Skripten auf den Hosts. Quotierung bleibt Pflicht, aber was gar nicht erst in die Datenbank kommt, kann nichts anrichten. - **TOTP-Geheimnis mit `SSHKV_APP_SECRET` verschlüsselt,** nicht mit dem Master-Key: geprüft wird es im Webprozess, und der Master-Key bleibt im Worker. - Ein Host-Key-Wechsel ist eine neue Zeile `AUSSTEHEND` neben der vertrauten; je Host und Algorithmus höchstens ein vertrauter Key (partieller Index). --- Quelle: `docs/issues/003-datenmodell.md` – dort wird dieses Issue gepflegt.

florian.wilde added this to the v0.1.0 milestone 2026-10-12 15:12:33 +00:00

florian.wilde added the datenbank label 2026-10-12 15:12:33 +00:00

florian.wilde closed this issue

2026-10-12 15:12:33 +00:00

florian.wilde referenced this issue

2026-10-12 15:12:34 +00:00

#004 Anmeldung, Rollen und erneute Bestätigung #4

florian.wilde referenced this issue

2026-10-12 15:12:34 +00:00

#005 Revisionssicheres Protokoll #5

florian.wilde referenced this issue

2026-10-12 15:12:35 +00:00