Kanonisches Home für Zugriffssicherheit des Mitai-Rahmens (Auth, TLS, Secrets, IDOR). Der Schutz personenbezogener Daten beim AI-Egress liegt in `privacy_gateway.md`. Encryption at rest, selektives Vergessen und DSFA: Interview H1, Ausprägung **offen**.
## 1. Rahmen, übernommen aus Mitai
- bcrypt für Passwort-Hashes, keine Klartext-PINs.
- Rate Limiting an Login/Register (Mitai: Login 5/min, Register restriktiver) – konkrete Zahlen für Kanshō **bevorzugte Richtung**, bei Bedarf anpassen.
- CORS explizit, nicht `*` in Prod.
- HTTPS vor der App (Synology/Reverse Proxy der Familie).
- Secrets nur Server-`.env` (SMTP, Provider-Keys, DB). Nie im Frontend, nie ins Git.
- Session-Invalidierung beim Logout.
- Kein IDOR über Client-gewähltes Profil (`auth_identity_and_roles.md`).
## 2. Kanshō-spezifisch
- Provider-Keys für LLM nur hinter dem Gateway, mit Policy-Check vor Verwendung.
- Audit-Logs ohne Prompt-Volltext.
- Admin-API nicht über Security-by-Obscurity; immer `require_admin`.
- Fremde `profile_id` in Pfaden/Bodies ignorieren oder 403.
## 3. Transport und Ruhe
| Thema | Stand | Status |
|---|---|---|
| TLS nach außen | ja, Betriebsstandard der Familie | entschieden als Anforderung |
Der implementierte Privacy-Pfad ist durchgängig, aber nicht der vollständige Security Layer. Offene Implementierungspunkte (Minimierung, Detection-Qualität, Antwortprüfung, Audit, Mapping-Härtung, Detect-Klartext in der Testphase) stehen in `privacy_gateway.md` §9.2.
