Document authenticated deployment

docs/deployment.md

@@ -16,10 +16,10 @@ und macOS keine inotify-Events durchreichen; das kostet dauerhaft CPU, auch
 ohne Benutzeraktivität. Dieser Stack gehört deshalb nur auf einen
 Entwicklungsrechner.
 
-Beide Stacks enthalten weder TLS, Authentifizierung, einen vorgeschalteten
-Reverse Proxy noch ein zentral betriebenes Datenbanksystem. Die oben genannten
-Container-Schutzmaßnahmen ersetzen diese Funktionen nicht. Der Stack darf
-deshalb nicht öffentlich erreichbar gemacht werden.
+Beide Stacks enthalten Anmeldung mit festen Rollen, aber weder TLS, einen
+vorgeschalteten Reverse Proxy noch ein zentral betriebenes Datenbanksystem.
+Passwörter und Session-Cookies werden bei reinem HTTP unverschlüsselt
+übertragen. Der Stack darf deshalb nicht öffentlich erreichbar gemacht werden.
 
 ## Topologie
 
@@ -29,9 +29,10 @@ deshalb nicht öffentlich erreichbar gemacht werden.
 | Express API | 3000 | nicht veröffentlicht (Server) / `127.0.0.1:3000` (Dev) | `GET /health` | `./data:/app/data` |
 | SQLite | Datei | – | Integritäts-/FK-Prüfung via Backup und Skript | `data/leistungsbilanz.db` |
 
-Die Express-API wird im Server-Stack nicht mehr auf dem Host veröffentlicht
-(`expose` statt `ports`). Sie hat keine Authentifizierung; jeder, der sie
-erreicht, kann jedes Projekt lesen und ändern. Erreichbar ist sie nur aus dem
+Die Express-API wird im Server-Stack nicht auf dem Host veröffentlicht
+(`expose` statt `ports`). Alle fachlichen API-Routen verlangen eine aktive
+Session; Schreibzugriffe zusätzlich den Anwendungsheader
+`X-Leistungsbilanz-Request: 1`. Erreichbar ist die API nur aus dem
 Compose-Netz, praktisch also über den Next.js-Rewrite. Im Entwicklungs-Stack
 hängen beide Ports am Loopback und sind nicht aus dem LAN erreichbar.
 
@@ -72,6 +73,26 @@ Verwendete Umgebungsvariablen:
   JSON-Loggers (`error`, `warn`, `info`, `verbose`, `debug`), Standard `info`.
   Setzbar über eine `.env`-Datei neben `compose.yaml` oder
   `LOG_LEVEL=verbose docker compose up`.
+- `AUTH_BOOTSTRAP_USERNAME` und `AUTH_BOOTSTRAP_PASSWORT` – erzeugen nur bei
+  leerer Benutzertabelle den ersten Administrator; das Startpasswort hat
+  mindestens 12 Zeichen.
+- `AUTH_SESSION_HOURS` – Inaktivitätsgrenze einer Session, Standard 12 Stunden.
+- `AUTH_SESSION_MAX_DAYS` – absolute Session-Laufzeit, Standard 7 Tage.
+- `COOKIE_SECURE` – hinter HTTPS `true`; beim direkten HTTP-Zugriff im LAN
+  `false`, da Browser das Cookie sonst nicht speichern.
+
+Vor dem ersten Start müssen mindestens die Bootstrap-Werte in einer lokalen,
+nicht versionierten `.env` neben `compose.yaml` gesetzt werden:
+
+```dotenv
+AUTH_BOOTSTRAP_USERNAME=admin
+AUTH_BOOTSTRAP_PASSWORT=<eigenes Startpasswort mit mindestens 12 Zeichen>
+```
+
+Nach dem ersten erfolgreichen Start werden diese Werte ignoriert, solange
+mindestens ein Benutzer existiert. Weitere Zugänge legt ein Administrator in
+**Config → Benutzer** an. Details stehen in
+[Anmeldung und Benutzerverwaltung](authentication.md).
 
 Beim API-Start laufen zuerst die Migrationen und die Schemaprüfung
 (`scripts/run-migrations.js` und `scripts/db-verify-circuit-schema.js`, im
@@ -137,7 +158,8 @@ bleibt `sh` der Vordergrundprozess, und `SIGTERM` erreicht Node nie.
 Vor einer produktiven Installation werden mindestens benötigt:
 
 - TLS-Termination und Reverse Proxy
-- Authentifizierung, Autorisierung und Benutzer-/Rollenmodell
+- zentraler Identitätsanbieter oder eine feinere Rechte-Matrix, falls die zwei
+  festen Rollen später nicht ausreichen
 - definierte Secrets- und Konfigurationsverwaltung
 - persistenter, gesicherter Datenbankbetrieb
 - kontrollierter einmaliger Migrationsschritt vor dem API-Rollout