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
|