Kansho/docs/architecture/technical/security.md

---
title: "Kanshō – Security"
version: "0.1"
status: "Arbeitsstand"
date: "2026-08-19"
product_family: "Jinkendo"
document_role: "Technical Chapter / Security"
parent_document: "technische_zielarchitektur.md"
---
# Kanshō – Security

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`).

**Additiv 2026-10-12.** Reset- und Bestätigungstoken werden nur als SHA-256-Hash gespeichert. SMTP ist Betriebsmail und Fail Closed: ohne Konfiguration kein stiller Versand. In `development` erscheint der Link nur im Server-Log, nie in der API-Antwort. Details: `auth_identity_and_roles.md` §2.1.

## 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 |
| Verschlüsselung at rest (DB, Backups, Gerät) | – | offen |
| Client-Token in localStorage | XSS-Risiko bekannt | bevorzugte Richtung, später bewerten |
| Vollständiges Löschen / selektives Vergessen | Journal-Entry: Soft Delete + explizites Purge; Account/DSFA offen | Slice teilweise, H1 offen |
| Export/Portabilität | fachlich gewünscht (menschenlesbar) | offen in Technik |

## 4. Dependency- und Deploy-Hygiene

- Keine Provider-Keys in Compose-Dateien im Repo.
- Fail Closed bei fehlender Privacy-Policy des Endpoints, nicht Fail Open wegen Verfügbarkeit.
- Healthchecks ohne Leak von Nutzerdaten.

## 5. Safety vs. Security

Krisengrenzen und medizinische Hochrisikothemen sind **nicht** dieses Kapitel (`ai_architecture.md`, fachlich H3). Hier: Zugriff, Secrets, Isolation, Logging.

## 6. Entscheidungsstand

| Thema | Stand | Status |
|---|---|---|
| Guardrails / Privacy-Invariante | bindend, unabhängig von H1-Ausprägung | entschieden |
| IDOR-Profilheader | verworfen | entschieden |
| Encryption at rest, Delete, Cookie-Sessions | – | offen |
| Shared-Postgres mit anderen Apps | Default nein | bevorzugte Richtung |

## 7. Offene Fragen

1. Getrennte Datenbank pro App vs. gemeinsamer Server mit getrennten Schemas?
2. Backup-Verschlüsselung und Schlüsselhaltung.
3. DSFA und Retention, sobald Mehrbenutzer über den privaten Betrieb hinausgeht.

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.

## 8. Querverweise

- `auth_identity_and_roles.md`, `privacy_gateway.md`, `runtime_and_deploy.md`
- Fachlich: `../functional/guardrails.md` §18–19