70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
# Sicherheitsmodell
|
|
|
|
## Netzgrenze
|
|
|
|
- KI-Ports binden ausschließlich an die WireGuard-IP.
|
|
- Docker-Netze `172.30.0.0/16` verwenden eine eigene Routingtabelle.
|
|
- Heimnetz- und optionaler Internetverkehr laufen über WireGuard.
|
|
- Eine Blackhole-Default-Route verhindert Fail-open bei Tunnelverlust.
|
|
- `DOCKER-USER` erlaubt nur etablierte Verbindungen, KI→WireGuard und
|
|
WireGuard→Open-WebUI/Router.
|
|
- Der Host ist kein Router zwischen Universitäts- und Heimnetz.
|
|
|
|
Docker-publizierte Ports können gewöhnliche Host-Firewallregeln umgehen.
|
|
Darum setzt der Installer seine Regeln ausdrücklich in `DOCKER-USER` und
|
|
verlässt sich nicht allein auf UFW.
|
|
|
|
## Containergrenzen
|
|
|
|
- llama.cpp: read-only, keine Capabilities, Modelle read-only, keine Ports.
|
|
- Router: unprivilegierter Benutzer, kein Docker-Socket, feste API-Oberfläche.
|
|
- Profile Controller: einzige Socket-Ausnahme; feste Profile und nur
|
|
List/Start/Stop, keine frei wählbaren Images, Befehle oder Mounts.
|
|
- Open WebUI: einziges persistentes Chat-Volume.
|
|
- MCP-Fachcontainer: intern, getrennte Secrets und keine Host-Ports.
|
|
- TinySearch/SearXNG: intern, Suchanfragen ohne Chatverlauf.
|
|
|
|
llama.cpp bekommt weder MCP-Konfiguration noch HA-, ARR- oder Unraid-Secrets.
|
|
Open WebUI kennt nur interne MCP-URLs; Authentisierung zu den Zielsystemen
|
|
findet im jeweiligen Fachcontainer statt. Externe MCP-Clients werden erst über
|
|
einen authentifizierten WireGuard-Gateway zugelassen.
|
|
|
|
Ein Docker-Socket bleibt grundsätzlich privilegiert. Der Controller reduziert
|
|
die erreichbare Funktion stark, ersetzt aber keine zusätzliche Socket-Proxy-
|
|
Sandbox. Er ist klein, testbar und nicht von Clients direkt erreichbar.
|
|
|
|
## Secrets und private Daten
|
|
|
|
- Keine Secrets in Git, Prompts, MCP-Schemas, Logs oder Screenshots.
|
|
- Installer-Konfiguration und `/etc/mike-ai/*` haben restriktive Rechte.
|
|
- Router-, Controller- und WebUI-Schlüssel sind getrennt und zufällig.
|
|
- Das Modell bekommt keine Schlüsselwerte zurück; spätere Integrationen nutzen
|
|
lokale Broker/Environment-Dateien.
|
|
- Open-WebUI-Volume kann Chats enthalten und wird nur verschlüsselt gesichert.
|
|
|
|
## Werkzeugprofile
|
|
|
|
| Modus | Erlaubte Werkzeuge |
|
|
|---|---|
|
|
| Standard | lokale Websuche, harmlose Hilfsfunktionen |
|
|
| Home Assistant | eigener begrenzter HA-MCP |
|
|
| ARR | Sonarr/Radarr, zuerst read-only |
|
|
| Unraid Diagnose | Status und eng begrenzte Logs |
|
|
| Administration | Vorschau, Approval-Ticket, Verifikation |
|
|
|
|
Allgemeine Shell, beliebiges SSH/SCP, freies `curl`, Docker-Administration und
|
|
Dateisystemsuche gehören nicht ins Standardprofil.
|
|
|
|
## Schreibaktionen
|
|
|
|
Persistente oder destruktive Änderungen folgen immer: Bestandsaufnahme,
|
|
exakte Vorschau, an die Vorschau gebundene Freigabe, unveränderte Ausführung,
|
|
anschließende Verifikation.
|
|
|
|
## Vor jedem Push
|
|
|
|
- Private-Key-, Token-, Passwort- und API-Key-Muster suchen.
|
|
- Keine `.env`, Zertifikate, Logs, Bilder, Audio oder Modelle einchecken.
|
|
- Beispiele enthalten nur Platzhalter; interne Hostnamen nur wenn bewusst.
|
|
- Änderungen am Controller und Netzwerkguard mit Tests und Review versehen.
|