diff --git a/MULTITOOL_AUSBAU_PLAN.md b/MULTITOOL_AUSBAU_PLAN.md deleted file mode 100644 index 3a5518e..0000000 --- a/MULTITOOL_AUSBAU_PLAN.md +++ /dev/null @@ -1,222 +0,0 @@ -# MULTITOOL-AUSBAU — Orchestrierungs-KI, Sicherheit & feinkörnige Nutzerprofile - -> Planungsdokument. Erstellt 2026-06-26. Umsetzung geplant ab nächster Woche -> (neues Wochen-Kontingent). Selbst-enthaltend, damit eine frische Session den -> Kontext ohne Vorwissen versteht. -> -> Status: **PLAN — noch nichts implementiert.** Branch: `jamulix-optimized`. - ---- - -## 0. Ausgangsfrage (wörtlich sinngemäß vom Nutzer) - -> „Könnte unser System auch so umgebaut werden, dass es ein Orchestrierungs-KI-Tool -> als zentrales KI-Modell benutzt, das seinerseits wieder OpenRouter-KI-Modelle -> aufruft, um bestimmte Dienste (z. B. Recherche im Internet) zu leisten?" - -Zusatzwunsch des Nutzers: feinkörniges **Management der Nutzerprofile** — festlegen, -**wer was darf**, um Gefahren auszuschließen und Risiken klein zu halten. Begründung: -Senioren sind unterschiedlich kompetent; ab einem gewissen Stadium ist schon der -Umgang mit dem Mobilgerät eine Überforderung. - ---- - -## 1. Architektur-Befund: das System ist dafür gebaut - -Die LLM-Achse ist eine **austauschbare Achse hinter einem winzigen Interface** -(`app/providers/llm/base.py`): - -```python -async def complete(text, history, session_id, language) -> str -async def stream(...) -> AsyncIterator[str] # Default: complete() als ein Chunk -``` - -Ein „Orchestrierungs-Tool" ist aus Kern-Sicht **nur ein weiterer LLM-Provider**, der -intern beliebig viel tun darf (Tool-Calls, mehrere Modelle, Websuche) und am Ende -Text liefert/streamt. **Kein Kern-Code muss geändert werden** — ein Registry-Eintrag -(`LLM_REGISTRY` in `app/dependencies.py`) genügt. Der **gerade gebaute Modell-Dropdown** -(Admin › System › Status, `config/models.yaml`, `app/model_presets.py`) ist der -natürliche Umschalter; Auswahl/Umstellung läuft über die Laufzeit-Overrides -(`RUNTIME_SETTABLE`, wirkt ohne Neustart). - -### Drei Andock-Formen (alle ohne Architektur-Bruch) -1. **OpenRouter-nativ (am leichtesten).** Der OpenRouter-Provider baut nur ein simples - `{model, messages, stream}`-JSON (`app/providers/llm/openrouter.py`). Erweiterbar um - OpenRouters **Websuche** (Web-Plugin bzw. `modell:online`) und/oder den **Auto-Router** - `openrouter/auto`. → „Recherche" + „Modell-Orchestrierung light" praktisch ohne Agent-Code, - nur ein neues Preset im Dropdown. -2. **Eigener Orchestrator-Provider.** `app/providers/llm/orchestrator.py` implementiert das - ABC und fährt intern eine **begrenzte Tool-Schleife** (OpenRouter-Tool-Calling) mit Werkzeugen - wie `web_search`, `call_model(model, prompt)`, `datum/zeit`. Plug-in als - `default_llm_provider="orchestrator"` (ein Registry-Eintrag, ein Preset). **= genau das vom - Nutzer gewünschte Bild.** -3. **Externer Orchestrierungs-Dienst.** Agent-Framework (LangGraph/Flowise/n8n/eigener - MCP-Host) mit **OpenAI-kompatibler `/chat/completions`**-Fassade; der vorhandene - `local_openai_compatible`-Provider zeigt per `base_url` darauf → **null neuer Provider-Code**. - -**Verifizieren (gegen aktuelle OpenRouter-Doku, Wissensstand kann hinterherhinken):** -Web-Plugin / `:online`-Suffix, Perplexity-„sonar"-Modelle (native Online-Suche), -`openrouter/auto`-Router, Tool-/Function-Calling-Passthrough, Kosten der Websuche. - ---- - -## 2. Diskussion & Entscheidungen - -### 2.1 Latenz — gelöst über Füllsprache (Nutzer-Idee, bestätigt) -Voice braucht „erster Ton in ~1–2 s"; eine Agenten-Schleife + Web-Fetch dauern 5–20 s mit -Totstille. Lösung (Nutzer): Frage **zusammenfassen + vorlesen**, dann in **30–50 Varianten** -sinngemäß „Ich kümmere mich darum, eine gute Antwort zu finden. Lass mich kurz lesen und -nachdenken." → zwischendurch „Habe noch ein bisschen Geduld, ich bin gleich soweit." → dann -die Antwort. - -**Ergänzungen/Verbesserungen:** -- Das **Vorlesen der zusammengefassten Frage = Verständnis-Rückversicherung** (gegen STT-/ - Missverständnis-Fehler) — doppelter Nutzen. -- Varianten **an verstrichene/erwartete Restzeit koppeln** (nicht „gleich soweit" beim Start). -- Füllsätze müssen **barge-in-fähig** sein (Nutzer korrigiert → sofort abbrechen + neu zuhören). - Nutzt die bereits gebaute **entkoppelte, satzweise TTS + Barge-in**: Füllsatz wird sofort - gesprochen, während die Recherche läuft; danach streamt die echte Antwort in dieselbe - geordnete TTS-Queue. -- **Graceful give-up**, falls Zeitbudget reißt („ich konnte es nicht sicher herausfinden"). -- Optional multimodale Beruhigung (Bubble „🔎 liest…"). -- Varianten + Sicherheits-Antworten **pro Sprache** pflegen. - -### 2.2 Selektives Routing — Muss (Nutzer bestätigt) -- **Intent-Gate** (billig/schnell, Regeln oder kleines Modell): „einfacher Plausch/Frage" vs. - „braucht Recherche/Tools". Die meisten Senioren-Turns dürfen NICHT die Agenten-Steuer zahlen. -- Entscheidung berücksichtigt **auch Nutzerprofil/Berechtigungen** (§ 2.6), nicht nur das Intent. -- Im Zweifel **rückfragen** statt selbstsicher veraltet antworten. Entscheidung **protokollieren**. -- Muster existiert schon: der nicht-blockierende Notruf-LLM-Klassifikator (`app/safety/`). - -### 2.3 Kosten — Deckel + Logging (Nutzer bestätigt) -- Budget **pro Turn _und_ pro Nutzer/Tag _und_ global**; **inkl. Websuche-Kosten** (extra zu Tokens). -- **Circuit-Breaker** bei Kostenausreißern; Kosten als **Admin-Metrik** sichtbar - (`app/metrics.py`, vorhandenes Tageskontingent `app/quota.py` zählt heute nur Turns → um - Token-/Kosten-Konten erweitern). - -### 2.4 Sicherheit — der EIGENTLICHE Kern (Nutzer-Schwerpunkt: Medizin/gefährliche Ratschläge) -Prompt-Injection ist beherrschbar; **falsche/gefährliche, v. a. medizinische Ratschläge** sind -das große Risiko (Senioren reden gern über Krankheiten). **Eigener Arbeitsstrang.** -- **Unterscheiden:** *über Krankheit reden* (Empathie, zuhören, KEINE Ratschläge) vs. - *um medizinischen Rat fragen* (immer an Arzt/Apotheke/Betreuer verweisen). Themen-Detektor - (analog Notruf-Klassifikator) → **sicherer Antwortmodus**. -- **Harte Tabus:** keine Dosierungen, keine Diagnosen, kein „Medikament absetzen/ändern". - Nachgelagerter Output-Check (billiger Klassifikator), der unsicheren medizinischen Inhalt - blockt/umschreibt. -- **Web bei Gesundheit:** ganz aus ODER nur **kuratierte, seriöse Quellen**. -- **Datenschutz:** Gesundheitsdaten = DSGVO-**besondere Kategorie**. Sensible medizinische Frage - evtl. **lokal (Ollama, keine Cloud, kein Web)** beantworten → verbindet Routing + Sicherheit + - Datenschutz. -- **Betreuer-Schleife:** riskante Themen → Kontakt informieren (nutzt Notruf-Benachrichtigungs- - Infrastruktur `app/safety/emergency.py`). -- **Scam-/Betrugsschutz:** „soll ich Geld an … überweisen?" → Warn-Layer (Senioren sind Ziel). - -### 2.5 Notruf-Invariante bleibt schnell & getrennt (Klarstellung zu meinem Punkt 5) -Heute läuft die **Notruf-Stichwort-Erkennung VOR dem LLM**, unabhängig von jedem Modell -(`app/safety/emergency.py`, Hot-Path). Wenn das „zentrale Modell" ein **langsamer Orchestrator** -(5–20 s) wird, darf die Notruf-Erkennung **nicht** durch ihn laufen — sonst verzögert eine -Recherche einen echten Notruf. **Der schnelle Sicherheits-Pfad bleibt getrennt und schnell.** - -### 2.6 Feinkörnige Nutzerprofile = Policy-Schicht des Systems (Nutzer-Grundsatzpunkt) -Kein Nebenpunkt, sondern **die zentrale Policy-Schicht**, die Router/Orchestrator/Sicherheit -konsultieren. Passt auf die vorhandenen **Pro-Nutzer-Prefs** (`user.prefs`, gerade um -per-User-Notrufpause erweitert). -- **Kompetenz-Stufen als Vorlagen** (z. B. *Selbstständig · Begleitet · Stark eingeschränkt*) - mit Defaults + **Pro-Nutzer-Feinjustierung** (nicht 20 Schalter pro Person). -- Jede Stufe legt fest: **Web-Recherche an/aus, Medizin-Modus, Modell-Stufe (schnell vs. - Orchestrator), Antwort-Komplexität/-Länge, Freitext vs. „einfacher Modus", Auslöser für - Betreuer-Benachrichtigung.** -- **„Einfacher Modus"-UI** für Überforderte (großer Sprechknopf + SOS, keine Menüs/Tabs) — - eigener kleiner Strang (UX). -- **Vom Betreuer/Admin konfiguriert** (Admin › Nutzer › Notfall-/Profil-Bereich), der Senior - kann Sicherheitseinstellungen **nicht selbst aufweichen**. - -### 2.7 Verlässlichkeit (Nutzer bestätigt) -Agenten sind weniger deterministisch. Orchestrierung **opt-in/selektiv**, nicht Default — -der normale, schnelle Assistenzbetrieb darf nicht leiden. - ---- - -## 3. Querschnitts-Anforderungen (gelten für alle Phasen) -- **Hartes Wall-Clock-Budget** je Turn (z. B. ≤ 6–8 s) + max. 1–2 Tool-Schritte + Timeouts. -- **Füllsprache** (barge-in-fähig, zeit-gekoppelt, mehrsprachig, graceful give-up). -- **Routing-Policy** konsultiert Intent **und** Nutzerprofil/Berechtigungen. -- **Kostenkonto** (Turn/Nutzer/global) inkl. Websuche; Circuit-Breaker; Admin-Sichtbarkeit. -- **Sicherheits-Guardrails** (Medizin/gefährlich/Scam) mit sicherem Antwortmodus + Output-Check. -- **Notruf-Hot-Path bleibt getrennt & schnell.** -- **Graceful Degradation** (Web/Modell/Budget aus → sichere gesprochene Notlösung; Fallback-Ketten - `app/providers/fallback.py` nutzen). -- **DSGVO/Consent** für Sprach- & Gesundheitsdaten; sensible Themen ggf. lokal (Ollama). -- **Auditierbarkeit** (Routing, Tool-Use, Kosten, Sicherheits-Trigger) für Betreuer/Admin - (`app/audit.py`, Admin-Log). -- **Eval-/Guardrail-Testset** (Medizin-Verweigerung, Injection, Latenz, Routing-Korrektheit). -- Hinweis: Profil nimmt **ein Nutzer pro Gerät/Login** an (Besuch/zweite Person nicht modelliert). - ---- - -## 4. Phasenplan - -### Phase 0 — Realitätstest „Recherche" (fast gratis) -Ziel: **Ist die Latenz für Senioren überhaupt erträglich?** — vor jedem Agenten-Bau. -- OpenRouter-Websuche (Web-Plugin / `:online`) an EINEM Modell aktivieren; als Dropdown-Preset - „… (Recherche)" in `config/models.yaml` (Provider-Payload in `openrouter.py` um Plugin/Suffix - erweitern). -- Erste, einfache **Füllsprache** (1–2 Varianten) im Streaming-Pfad testen. -- Messen: End-to-End-Latenz, „Time-to-first-Füllsatz", Antwortqualität, Kosten/Turn. -- **Akzeptanzkriterium** (mit Nutzer festzulegen): z. B. „bis ~5 s, mit gesprochenem ‚ich schaue nach'". - -### Phase 1 — Eigener Orchestrator-Provider (falls Phase 0 trägt) -- `app/providers/llm/orchestrator.py` (ABC): **Intent-Gate → begrenzte Tool-Schleife - (web_search, call_model) → Füllsatz-Streaming → hartes Zeitbudget**. Registry-Eintrag + Preset. -- **Routing** mit Profil-Berücksichtigung (§ 2.6) verdrahten. -- **Kostenkonto** + Circuit-Breaker (`app/quota.py`/`metrics.py` erweitern). -- **Füllsprache** voll ausbauen (30–50 Varianten, zeit-gekoppelt, mehrsprachig, barge-in). - -### Phase 2 — Medizin-/Sicherheits-Guardrails (parallel ab Phase 1, hohe Priorität) -- Themen-Detektor (Medizin/gefährlich/Scam) → **sicherer Antwortmodus** (Empathie + Verweis, - harte Tabus, Output-Check). -- Sensible Themen → **lokales Modell (Ollama), kein Web**; optional Betreuer-Benachrichtigung. -- Eval-/Guardrail-Testset. - -### Phase 3 — Nutzerprofil-/Berechtigungs-Management -- **Kompetenz-Stufen (Vorlagen) + Pro-Nutzer-Overrides** in `user.prefs` - (Schema `AdminUserPrefsUpdate`, Admin-UI im Notfall-/Profil-Bereich erweitern). -- Policy-Schicht, die Router/Orchestrator/Guardrails konsultieren. -- **„Einfacher Modus"-UI** (großer Sprechknopf + SOS, keine Menüs) als gegateter Strang. - -### Phase 4 (optional, falls es wächst) — Externer Agenten-Dienst -- Orchestrator in separaten Dienst auslagern (OpenAI-kompatible Fassade → `local_openai_compatible` - per `base_url`); Gateway bleibt schlank; Tools via MCP. - ---- - -## 5. Risiken & offene Fragen (für nächste Woche) -- **Latenz-Akzeptanz** der Senioren — durch Phase 0 empirisch klären. -- **Medizin-Sicherheit**: genaue Linie „zuhören vs. verweisen", kuratierte Quellenliste, Output-Check-Modell. -- **Kostenmodell**: konkrete Deckel pro Turn/Nutzer/Tag; Websuche-Preis. -- **Profil-Stufen**: welche Stufen genau, welche Schalter pro Stufe (Default-Matrix entwerfen). -- **DSGVO**: Consent-Fluss, Speicherung von Gesundheitsthemen (auch im Auto-Memory-Extractor). -- **Wer testet die Guardrails** (Red-Team-Promptset) und wie oft (CI?). -- **OpenRouter-Features** gegen aktuelle Doku verifizieren (Namen/Preise/Verfügbarkeit). - -## 6. Konkrete erste Schritte (Start nächste Woche) -1. OpenRouter-Doku prüfen: Websuche/`:online`, `openrouter/auto`, sonar, Tool-Calling, Preise. -2. Phase 0: Recherche-Preset + minimale Füllsprache, Latenz/Kosten messen, Akzeptanzkriterium mit - Nutzer fixieren. -3. Default-Matrix der Kompetenz-Stufen entwerfen (Tabelle Stufe × Schalter). -4. Medizin-Safety-Linie skizzieren (was sagt das System bei Krankheitsthemen — Beispiele sammeln). - ---- - -## 7. Bezug zum bestehenden Code (Andockpunkte) -- LLM-Provider/Interface: `app/providers/llm/{base,openrouter,local_openai_compatible}.py` -- Registry/Routing: `app/dependencies.py` (`LLM_REGISTRY`, `resolve_route`) -- Laufzeit-Umschaltung: `app/runtime_config.py` (`RUNTIME_SETTABLE`) + Admin-Config-Endpunkte -- Modell-Dropdown (Umschalter): `config/models.yaml`, `app/model_presets.py`, Admin › System › Status -- Pro-Nutzer-Policy: `user.prefs`, `app/schemas.py` (`AdminUserPrefsUpdate`), Admin › Nutzer -- Sicherheit/Notruf (Muster + Invariante): `app/safety/` (`emergency.py`, `llm_classifier.py`) -- Kosten/Quota/Metriken: `app/quota.py`, `app/metrics.py` -- Resilienz/Fallback: `app/providers/fallback.py` -- Audit: `app/audit.py` -- Streaming/TTS-Entkopplung + Barge-in (Basis für Füllsprache): `app/core/orchestrator.py`, - `app/pipeline/sentence_chunker.py`, `app/api/ws.py` diff --git a/VERSCHLUESSELUNGS_ANALYSE.md b/VERSCHLUESSELUNGS_ANALYSE.md deleted file mode 100644 index 6e934e3..0000000 --- a/VERSCHLUESSELUNGS_ANALYSE.md +++ /dev/null @@ -1,162 +0,0 @@ -# Verschlüsselungs-Analyse — Datenbank & Backups - -> Stand: Entwurf / Diskussionsgrundlage. Betrifft die SQLite-DB mit Userdaten, -> Gesprächsverläufen, Erinnerungen und Notfall-Profilen (Name, Adresse, -> Geburtsdatum, **medizinische Notizen**, Telefon). Ziel: Schutz der Daten **at -> rest** gegen Diebstahl von DB-Datei, Backups oder Datenträger. -> -> Leitsatz: **Der Cipher ist der einfache Teil — entscheidend ist das -> Schlüsselmanagement und das Bedrohungsmodell.** - -## 1. Bedrohungsmodell — wogegen schützt at-rest-Verschlüsselung überhaupt? - -| Szenario | Hilft Verschlüsselung? | -|---|---| -| **Gestohlenes Backup** (kopiert, geleakt, alter USB/Cloud-Ordner) | **Ja** — wahrscheinlichster & am leichtesten zu schließender Fall | -| **Gestohlene/ausgemusterte Platte** (Box aus, Disk-Image) | **Ja — nur wenn der Schlüssel NICHT auf derselben Platte liegt** | -| **Live-Kompromittierung** (root/App-Zugriff auf dem laufenden Server) | **Nein** — die App muss entschlüsseln können → Schlüssel im RAM | -| **Hypervisor / Rechenzentrum** (RAM- & Disk-Snapshot durch Betreiber) | **Kaum** — RAM-Snapshot greift den Schlüssel ab | - -**Kernfalle:** Liegt der Schlüssel als Datei/`.env` auf **derselben** Platte wie -die DB, bekommt ein Disk-/Backup-Dieb beides → die Verschlüsselung ist wertlos. - -## 2. Ganze DB einmal verschlüsseln vs. jeden User einzeln? - -**Empfehlung: ganze DB (eine Verschlüsselung), NICHT pro User.** - -- Pro-User-Verschlüsselung bringt nur dann Mehrwert, wenn die User-Schlüssel - **nicht** serverseitig verfügbar sind (aus User-Geheimnis abgeleitet, nur bei - aktiver Sitzung). -- Der Assistent ist aber ein **autonomer, immer-laufender Server**: er verarbeitet - Userdaten **ohne** anwesenden Nutzer (Auto-Erinnerungs-Extraktion, LLM-Kontext, - Safety, Admin). Er muss also jederzeit entschlüsseln können → hält/leitet alle - Schlüssel ab → ein Dieb des Schlüsselmaterials bekommt **trotzdem alles**. -- Authelia/SSO liefert **keinen** stabilen pro-User-Krypto-Schlüssel. Echte - Client-seitige Verschlüsselung würde den LLM-Assistenten unmöglich machen. -- Pro-Feld-Verschlüsselung zerstört zudem Indizes/Suche/SQL, leakt Metadaten - (wer/wann/wie viel) und lässt WAL-/Temp-Dateien im Klartext. - -→ Pro-User = **sehr hoher Aufwand, kaum Sicherheitsgewinn** in dieser Architektur -(Security-Theater). Whole-DB ist richtig und ausreichend. - -## 3. Methoden für Whole-DB - -- **(a) SQLCipher** (verschlüsseltes SQLite): App öffnet die DB mit `PRAGMA key`, - verschlüsselt DB + WAL transparent. Aufwand: Dependency (`pysqlcipher3`) + - `store._connect` + Einmal-Migration. App-contained. -- **(b) Verschlüsseltes Volume** (LUKS-Loopback, **gocryptfs** userspace, fscrypt) - fürs `data/`: **app-transparent** (kein Code), deckt DB + WAL + Temp + dort - liegende Backups ab. Aufwand: OS-Setup + **Entsperren beim Boot**. -- **(c) LUKS Full-Disk-Encryption** (ganze Platte): deckt zusätzlich **Logs, - Swap, OS** ab; ideal gegen physischen Diebstahl (s. Heim-Szenario). - -**Der eigentliche Hebel — Schlüssel-Ort:** nicht auf der Datenplatte. Optionen: -Passphrase **beim Service-Start** injizieren (`systemd-ask-password`), Schlüssel -beim Start **extern** holen (nur im RAM halten), oder **TPM** (s. u.). Trade-off: -bricht den **unbeaufsichtigten Auto-Neustart** — bei einem Always-On-Care-System -ein echter Betriebsnachteil. - -## 4. Aufwand vs. Sicherheit - -| Maßnahme | Aufwand | Sicherheitsgewinn | -|---|---|---| -| Backups off-host/-site + `age`/GPG | **niedrig** | **hoch** (häufigstes Leck) | -| Whole-DB, Schlüssel auf gleicher Platte | mittel | **niedrig** (nur „nackte .db-Kopie") | -| Whole-DB, Schlüssel off-disk / Start-Injektion | mittel–hoch (Ops) | mittel–hoch (echter Disk-Diebstahl) | -| LUKS-FDE + TPM2 (Heim-PC) | mittel | **hoch** (deckt alles, löst Key-Problem) | -| Pro-User-Feldverschlüsselung | **sehr hoch** | marginal hier, bricht Features | - -## 5. Empfohlenes Vorgehen (vHost), nach ROI sortiert - -1. **Backups verschlüsselt & off-host — sofort, größter Nutzen, kleinster Aufwand.** - Jedes Backup mit `age`/GPG (Public-Key); privater Schlüssel **nur offline/Heim-Host**. - Backups **weg vom Server**. -2. **Live-DB verschlüsseln** (SQLCipher oder gocryptfs/LUKS). -3. **Schlüssel vom Datenträger trennen** (Start-Injektion) — macht Stufe 2 erst wirksam. -4. **Datensparsamkeit/Retention**: alte Verläufe automatisch löschen (Tools vorhanden) — - weniger Daten = weniger Schaden. - -## 6. Was leicht vergessen wird - -- **Backups liegen aktuell NEBEN der DB** auf demselben Datenträger (inkl. der - `…bak-*`-Dateien) → ein Disk-Dieb bekommt DB **und** Backups. Größte aktuelle - Schwachstelle → auslagern. -- **WAL/-shm/-journal & SQLite-Temp** enthalten Klartext-Fragmente → spricht für - Whole-DB/Volume statt Feld-Ebene. -- **Logs / journald**: Gesprächsinhalte können in App-Logs landen → Log-Level prüfen. -- **Swap**: Schlüssel & Klartext können in den Swap geraten → **verschlüsselter Swap**. -- **Schlüsselverlust = Datenverlust**: Für ein Care-System ist **Verfügbarkeit** - teils kritischer als Vertraulichkeit → **Key-Escrow/sicheres Backup des Schlüssels**. -- **Sensibelste Daten = Notfall-Profil** (DSGVO-Gesundheitsdaten) — Hauptziel; - evtl. zusätzliche Feldverschlüsselung als Defense-in-Depth (nur Stufe 2). -- **Realismus vHost**: Gegen bösartigen RZ-Betreiber (RAM-Snapshot) schützt - at-rest mit auto-verfügbarem Schlüssel **nicht** — ehrlich kommunizieren. - ---- - -## 7. Wenn der Server LOKAL (zuhause) läuft — wie ändert sich das Bild? - -Der Standortwechsel verschiebt das Bedrohungsmodell **überwiegend zugunsten der -Sicherheit**: - -### 7.1 Der schwierigste Gegner verschwindet -Kein Rechenzentrums-Betreiber/Hypervisor mehr, der RAM **und** Disk snapshotten -kann. Du kontrollierst die physische Hardware → **at-rest-Verschlüsselung liefert -nahezu ihren vollen Wert.** Wichtigste Änderung. - -### 7.2 Neuer Hauptgegner: physischer Diebstahl / Einbruch -Vorher abstrakt, jetzt konkret: Einbruch, Mitnahme von Rechner/Platten, Reparatur-/ -Besuchszugriff, Platten-Entsorgung. **LUKS-Full-Disk-Encryption** ist dagegen das -natürliche, starke Mittel: gestohlener Heim-PC mit LUKS = Briefbeschwerer. - -### 7.3 Schlüsselmanagement wird einfacher UND besser: TPM -Ein echter Heim-PC hat meist ein **TPM 2.0** (der vHost nicht). LUKS an das TPM -binden → -- entsperrt **automatisch, nur auf genau dieser Maschine** (kein Key auf Platte, - keine manuelle Eingabe) → **unbeaufsichtigter Neustart** funktioniert wieder; -- **Platte ausbauen & woanders auslesen** scheitert; -- **Trade-off:** ganze Maschine gestohlen **und eingeschaltet** → TPM entsperrt. - Wer das abdecken will: **TPM + PIN** (wieder Eingabe nötig — Verfügbarkeit vs. - Diebstahlschutz). - -→ Zuhause empfohlene Primärmaßnahme: **LUKS-FDE mit TPM2-Auto-Unlock (optional +PIN)** -— deckt **alles** ab (DB, WAL, Logs, Swap, Temp), OS-nativ, löst zugleich das -Schlüssel-/Neustart-Problem. - -### 7.4 Backups: aus „off-host" wird „off-SITE" -Zweites Laufwerk im selben Raum nützt wenig — Einbruch/Brand nimmt alles mit. -→ **verschlüsselte Off-Site-Backups** (`age`/GPG, Schlüssel getrennt) an einen -zweiten Ort. Deckt Vertraulichkeit **und** Disaster-Recovery (Totalverlust) ab. - -### 7.5 Was zuhause schwieriger wird / auf dich übergeht -- **Physische Sicherheit**: abschließbarer Raum, gesperrter Bildschirm, - Haushalts-/Gästevertrauen. -- **Verfügbarkeit**: kein redundanter Strom/Kühlung/Remote-Hands → **USV** (auch - gegen DB-Korruption bei Stromausfall). -- **Netzwerk-/Live-Kompromittierung kann GRÖSSER werden**: Heim-LAN heterogen - (IoT, schwache Segmentierung). Ist der Server **internet-exponiert**, kann ein - gekapertes Gerät seitlich angreifen. **Verschlüsselung hilft hier nicht** → - Netz-Härtung: möglichst **nur per VPN/Tunnel**, Reverse-Proxy, fail2ban, - minimale Ports, SSO behalten, **eigenes VLAN** weg von IoT. -- **Platten-Entsorgung** wird durch FDE unkritisch. - -### 7.6 Unverändert -- **Whole-DB schlägt weiter Pro-User.** -- **Live-Kompromittierung** bleibt der Fall, den Verschlüsselung **nicht** abdeckt — - durch mögliche Heim-Internet-Exposition evtl. das **dominante** Restrisiko → - Netz-Härtung mindestens so ernst nehmen wie Verschlüsselung. - -## 8. Fazit - -- **Whole-DB-Verschlüsselung reicht**; pro User lohnt sich nicht. -- **vHost:** Fokus auf (1) verschlüsselte Off-Host-Backups, (2) Live-DB - (SQLCipher/Volume), (3) Schlüssel vom Datenträger trennen. -- **Heim-Server (besser & einfacher):** **LUKS-FDE + TPM2 (optional +PIN)** + - **verschlüsselte Off-Site-Backups** + **Netz-Härtung gegen Live-Angriffe** + - **physische Sicherheit & USV**. Der TPM löst zugleich Verschlüsselung und das - Schlüssel-/Neustart-Dilemma. - -### Offene Entscheidung -Soll der Heim-Server **internet-exponiert** oder **nur per VPN/Tunnel** erreichbar -sein? Davon hängt das Gewicht des Live-Kompromittierungs-Risikos ab — der einzige -große Punkt, den Verschlüsselung nicht abdeckt.