70 lines
2.9 KiB
Markdown
70 lines
2.9 KiB
Markdown
---
|
||
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`).
|
||
|
||
## 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 | fachlich offen | 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.
|
||
|
||
## 8. Querverweise
|
||
|
||
- `auth_identity_and_roles.md`, `privacy_gateway.md`, `runtime_and_deploy.md`
|
||
- Fachlich: `../functional/guardrails.md` §18–19
|