Fabian Wolter
92 lines
2.0 KiB
Markdown
92 lines
2.0 KiB
Markdown
# 020 - Bootstrap-Seed-Script und Admin-Passwort
|
|
|
|
## Ziel
|
|
|
|
Die Bootstrap-Daten wurden reproduzierbar gemacht. Dafür wurde ein versioniertes Seed-Script im tactical-deploy Repository angelegt.
|
|
|
|
Zusätzlich wird für den Admin-Datensatz jetzt lokal ein Passwort abgefragt und als PBKDF2-SHA256-Hash in PostgreSQL gespeichert.
|
|
|
|
## Script
|
|
|
|
Pfad:
|
|
|
|
/opt/ruvnox/tactical/deploy-repo/scripts/seed-bootstrap-data.sh
|
|
|
|
## Verhalten
|
|
|
|
Das Script:
|
|
|
|
1. lädt /opt/ruvnox/tactical/config/server.env
|
|
2. fragt lokal ein Bootstrap-Admin-Passwort ab
|
|
3. verlangt mindestens 12 Zeichen
|
|
4. bestätigt das Passwort durch zweite Eingabe
|
|
5. erzeugt einen PBKDF2-SHA256-Hash
|
|
6. setzt app_users.password_hash für username admin
|
|
7. stellt den HQ-Einsatzraum sicher
|
|
8. stellt die lead-Mitgliedschaft des Admins in HQ sicher
|
|
9. stellt ein Bootstrap-Audit-Event sicher
|
|
|
|
## Wichtig
|
|
|
|
Das Passwort wird nicht im Chat eingegeben.
|
|
|
|
Das Passwort wird nicht im Git gespeichert.
|
|
|
|
In der Datenbank liegt nur ein Hash im Feld password_hash.
|
|
|
|
## Hash-Format
|
|
|
|
Format:
|
|
|
|
pbkdf2_sha256$iterations$salt_base64$hash_base64
|
|
|
|
Aktuelle Iterationen:
|
|
|
|
310000
|
|
|
|
## Betroffene Tabellen
|
|
|
|
- app_users
|
|
- operation_rooms
|
|
- operation_room_members
|
|
- audit_events
|
|
|
|
## Verifikation
|
|
|
|
Admin-Passwort-Hash gesetzt:
|
|
|
|
select username, password_hash is not null as has_password_hash from app_users where username = 'admin';
|
|
|
|
Erwartung:
|
|
|
|
has_password_hash = true
|
|
|
|
## API-Verifikation
|
|
|
|
curl -fsS https://tactical.ruvnox.de/api/v1/system/overview
|
|
|
|
Erwartete Werte:
|
|
|
|
- users.total = 1
|
|
- users.active = 1
|
|
- operationRooms.total = 1
|
|
- operationRooms.active = 1
|
|
- auditEvents >= 1
|
|
|
|
## Sicherheitshinweis
|
|
|
|
Der Admin hat jetzt einen Passwort-Hash in der Datenbank.
|
|
|
|
Ein echter Login ist damit aber noch nicht aktiv, weil Login-Endpunkt, Passwortprüfung, Token-Erzeugung und Session-Verwaltung noch nicht implementiert sind.
|
|
|
|
## Nächster Abschnitt
|
|
|
|
Als nächstes folgt die Auth-Grundlage:
|
|
|
|
- Passwort-Hash-Verifikation im Server
|
|
- Login-DTOs
|
|
- Login-Route
|
|
- Session-/Token-Erzeugung
|
|
- auth_sessions nutzen
|
|
- System-Endpunkte schützen
|