Add AI workspace reviews
This commit is contained in:
@@ -0,0 +1,99 @@
|
||||
# ADR 0010 — Secrets-Management
|
||||
|
||||
## Status
|
||||
Accepted
|
||||
|
||||
## Kurz erklärt
|
||||
Secrets sind geheime technische Zugangsdaten, z. B.:
|
||||
|
||||
- API-Keys
|
||||
- Registrar-Zugänge
|
||||
- Tokens
|
||||
- Passwörter
|
||||
- Webhook-Secrets
|
||||
|
||||
Secrets dürfen nicht wie normale Stammdaten gespeichert werden.
|
||||
|
||||
## Kontext
|
||||
Hosting-Backoffice wird später Zugangsdaten zu externen Systemen verwalten:
|
||||
|
||||
- KeyHelp
|
||||
- 1blu
|
||||
- Lexware
|
||||
- Invoice Ninja
|
||||
- SMTP
|
||||
- Zahlungsanbieter
|
||||
|
||||
Das Architekturreview hat fehlendes Secrets-Management als kritisches Risiko bewertet.
|
||||
|
||||
## Entscheidung
|
||||
Das Datenmodell speichert keine Secrets direkt in fachlichen Tabellen.
|
||||
|
||||
Fachliche Tabellen speichern nur Referenzen auf Secrets.
|
||||
|
||||
## V1-Strategie
|
||||
Für V1 wird mindestens verwendet:
|
||||
|
||||
- verschlüsselte Speicherung mit Laravel Encryption
|
||||
- getrennte Secret-Tabelle
|
||||
- Zugriff nur über Secret-Service
|
||||
- keine Ausgabe von Secrets im UI
|
||||
- Audit-Log bei Secret-Erstellung/Änderung
|
||||
- Rotation vorbereiten
|
||||
|
||||
## Spätere Strategie
|
||||
Für SaaS- oder größere Multi-Tenant-Nutzung wird ein externer Vault vorbereitet, z. B.:
|
||||
|
||||
- HashiCorp Vault
|
||||
- Bitwarden Secrets Manager
|
||||
- Cloud KMS / Secrets Manager
|
||||
|
||||
## Beispiel
|
||||
|
||||
Nicht erlaubt:
|
||||
|
||||
```text
|
||||
registrar_accounts.api_password
|
||||
```
|
||||
|
||||
Erlaubt:
|
||||
|
||||
```text
|
||||
registrar_accounts.secret_reference_id
|
||||
```
|
||||
|
||||
## Begründung
|
||||
Bei einem Einbruch darf nicht sofort der direkte Zugriff auf alle externen Systeme möglich sein.
|
||||
|
||||
Secrets brauchen:
|
||||
|
||||
- Verschlüsselung
|
||||
- Zugriffskontrolle
|
||||
- Rotation
|
||||
- Auditierung
|
||||
- Mandantenisolation
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
### Positiv
|
||||
- höheres Sicherheitsniveau
|
||||
- bessere Mandantenisolation
|
||||
- spätere Vault-Anbindung möglich
|
||||
|
||||
### Negativ
|
||||
- mehr technische Komplexität
|
||||
- Secret-Service muss früh gebaut werden
|
||||
- Backups müssen besonders betrachtet werden
|
||||
|
||||
## Mindestregeln
|
||||
|
||||
- Secrets nie im Klartext loggen
|
||||
- Secrets nie im UI vollständig anzeigen
|
||||
- Secrets nie in normalen Exporten ausgeben
|
||||
- Secret-Zugriff auditieren
|
||||
- API-Keys rotierbar halten
|
||||
|
||||
## Verwandte ADRs
|
||||
- ADR 0004 — Tenancy-Modell
|
||||
- ADR 0006 — Auth-Strategie
|
||||
- ADR 0017 — Adapter-Fehlerresilienz
|
||||
Reference in New Issue
Block a user