2.9 KiB
2.9 KiB
| title | version | status | date | product_family | document_role | parent_document |
|---|---|---|---|---|---|---|
| Kanshō – Security | 0.1 | Arbeitsstand | 2026-08-19 | Jinkendo | Technical Chapter / Security | 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_idin 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
- Getrennte Datenbank pro App vs. gemeinsamer Server mit getrennten Schemas?
- Backup-Verschlüsselung und Schlüsselhaltung.
- 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