# 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