Files
AI-Profile-Router/docs/SECURITY.md
T

80 lines
3.8 KiB
Markdown

# Sicherheitsmodell
## Netzgrenze
- Open WebUI und Router veröffentlichen keinerlei Host-Ports.
- Ein dedizierter WireGuard-Container stellt OpenWebUI, Router und die
Werkzeugdienste direkt auf seiner VPN-Adresse bereit. Die verbindliche
Portmatrix steht in [VPN_SERVICE_PORTS.md](VPN_SERVICE_PORTS.md).
- Die egressfähigen Docker-Netze verwenden eigene Routingtabellen.
- Heimnetz- und optionaler Internetverkehr laufen über WireGuard.
- Die Tabellen zeigen ausschließlich zum Gateway-Container und besitzen keine
Route über das Standortgateway. Das ist der Fail-Closed-Mechanismus.
- Der Host ist kein Router zwischen Universitäts- und Heimnetz.
Da keine KI-Ports publiziert werden, kann Docker die Host-Firewall an dieser
Stelle nicht umgehen. SSH bleibt davon getrennt und schlüsselbasiert auf der
physischen Schnittstelle erreichbar.
## 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 verbunden und über feste WireGuard-Ports direkt
für OpenWebUI, Pi, Hermes und andere Heim-VPN-Clients erreichbar.
- TinySearch/SearXNG: intern, Suchanfragen ohne Chatverlauf.
llama.cpp bekommt weder MCP-Konfiguration noch HA-, ARR- oder Unraid-Secrets.
Open WebUI kann weiterhin die internen MCP-Namen verwenden. Andere Clients
nutzen ohne zusätzliches Gateway die festen MCP-Ports der WireGuard-Adresse.
Authentisierung zu den Zielsystemen findet im jeweiligen Fachcontainer statt.
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
freie Dateisystemsuche gehören nicht ins Standardprofil. Für die Athena-
Plattform existiert genau ein Operator-MCP. Seine unprivilegierte Fassade sieht
nur einen lokalen Unix-Socket; ein rootseitiger Executor besitzt die für
Repository, Docker, Modelle, Git und Recovery notwendigen Rechte. Er bietet
keinen beliebigen Befehl an, sondern strukturierte Operationen mit Vorschau,
Inhaltsbindung, Ablaufzeit und späterer exakter Freigabe. SSH-, Netzwerk-,
WireGuard-, Firewall-, Boot-, Kernel-, Treiber-, Partitions-, Reboot- und
Shutdown-Änderungen liegen außerhalb seiner API.
## 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.