Zum Inhalt

Sicherheit

Stand: 2026-05-30

Die Security-/Trust-Boundary-Sicht der AI Suite ist als Mermaid-Diagramm in der Diagrammübersicht dokumentiert. Für produktive Änderungen gelten zusätzlich die Environment Policies.

Grundregeln

  • Keine Secrets in Git speichern.
  • Keine privaten SSH Keys kopieren oder exportieren.
  • Passwörter nicht in Dokumentation schreiben.
  • Vor Datei- und Konfigurationsänderungen Backups erstellen.
  • Keine bestehenden VMs/LXCs löschen oder unkontrolliert verändern.
  • Reverse Proxy nur gezielt erweitern.

OpenCode Self-Service Token-Regeln

Der OpenCode Self-Service erzeugt neue Benutzerzugaenge ueber https://ai.lanstyle.de/opencode-access. Tokenwerte duerfen nicht in OpenWebUI-Chatverlaeufen, Tool-Traces, Browser-History-URLs, Logs, Markdown, Tickets oder Screenshots landen.

Hermes Voice / Jarvis

Hermes Voice ist als backend-only Pilot aktiv. Mikrofon, Lautsprecher, Wakeword, Browser Web Speech API und Screen Capture gehoeren auf ein Client-Geraet oder in einen Browser, nicht in den Hermes-LXC.

Der eigentliche Agent-Core ist Nous Hermes Agent. Er laeuft nur intern hinter dem Lanstyle AI Gateway. Der Core darf Memory, Sessions und Skills nutzen, aber keine Infrastrukturaktionen direkt ausfuehren.

Sicherheitsregeln:

  • Keine direkten Anthropic- oder ElevenLabs-Secrets im Code
  • Keine Secretwerte in Chat, Tooltrace, Browser-History oder Audit
  • Kein Screen Capture auf Hermes
  • Keine freie Browser-Automation mit sichtbarem Chromium auf Hermes
  • Alle Infrastrukturaktionen ausschliesslich ueber MCP/Controlled Execution
  • Nous Core API nicht public exposen
  • Gateway muss Auth, RBAC, Audit und Governance-Grenzen erzwingen
  • Core-Toolsets fuer API-Server ohne Terminal-/File-Write-Zugriff betreiben
  • Device-/User-Kontext muss auditiert werden

Pflichtregeln:

  • Status-Endpunkte zeigen nur Fingerprints und Metadaten.
  • One-time Downloads werden nach erfolgreichem Abruf entfernt.
  • One-time Downloads werden nicht als OpenAPI-/LLM-Tool veroeffentlicht.
  • One-time Downloads sind POST-only und verwenden keine Secret- oder Delivery-ID-Query-Parameter.
  • Browser-POSTs muessen CSRF-/Origin-Pruefung bestehen.
  • Self-Service-Antworten setzen Cache-Control: no-store, Pragma: no-cache und Referrer-Policy: no-referrer.
  • Die Benutzeridentitaet wird aus einer serverseitig validierten OpenWebUI-Session abgeleitet, nicht aus frei gesetzten Formularfeldern.
  • Der sichtbare OpenWebUI-Einstieg ist ein Banner-Link ohne Secretwerte und ohne Download-ID.
  • LiteLLM Virtual Key lanstyle-openwebui ist auf lanstyle/ai beschraenkt. User sehen nur "Lanstyle AI".
  • MCP Tokens fuer normale Operatoren erlauben nur read-only, plan-only und approval-preview.
  • Experimentelle Modelle sind nicht ueber Open WebUI erreichbar.
  • Die Lanstyle Tools API erzwingt Bearer-Auth fuer geschuetzte Endpunkte; der OpenWebUI Legacy-Token ist auf die Rolle operator begrenzt.
  • Revocation deaktiviert den MCP Token und entfernt die serverseitige Secret-Kopie.
  • Vaultwarden bleibt Source of Truth fuer dokumentierte Secret-Ownership und Rotation.

Multi-Tenant Datentrennung

  • Obsidian/Qdrant-Fakten sind per owner_id getrennt.
  • Automatisches Owner-Tagging aus Auth-Token ist aktiv.
  • shared_with und visibility steuern Freigaben.
  • Hermes Nous Core lernt global (Skills, Patterns) -- persoenliche Fakten bleiben per-User isoliert.

Open WebUI

  • Nicht direkt offen ins Internet stellen.
  • Zugriff ueber NPM und TLS.
  • Registrierung deaktiviert.
  • Neue Benutzer auf Rolle pending.
  • Admin-Account mit starkem Passwort und MFA/SSO pruefen, falls verfuegbar.
  • Code Execution und Code Interpreter deaktiviert lassen.
  • Web Search ist aktiviert, aber begrenzt und ohne externen API-Key.
  • Gitea ist als OpenAPI-Toolserver ohne globalen API-Token hinterlegt.
  • Direct User Connections sind deaktiviert.
  • Open Terminal ist nur intern ueber Open WebUI angebunden, nicht per NPM veroeffentlicht.
  • Open Terminal laeuft in eigenem unprivilegiertem LXC mit Docker ohne Host-Mounts und ohne Host-Docker-Socket.
  • Jeder bekannte Open-WebUI-User hat einen eigenen Open-Terminal-Container mit eigenem Volume und eigenem Token.
  • Open Terminal API-Keys nicht in Git, Wiki oder Chatverlaeufen speichern.
  • Terminal-Nutzung regelmaessig pruefen; neue User nur mit eigener Container-/Volume-/Token-Zuordnung aufnehmen.

Open Terminal Token-Rotation

  • Bei Rotation muss Open WebUI terminal_server.connections mit aktualisiert werden, sonst schlagen die Tool-Verbindungen fehl.
  • Aktive Token-Dateien liegen unter /root/open-terminal/**/api_key mit Rechten 0400 1000:1000.
  • Alte Backup-Kopien unter /root/open-terminal-backups und /root/backups sind auf 0600 root:root gesetzt.

Ollama

  • Nicht oeffentlich exponieren.
  • Intern ueber 10.222.70.11:11434 (VLAN70) beziehungsweise https://ollama.lanstyle.de nutzen.
  • Externer Zugriff nur ueber NPM mit Access List und TLS.
  • Modell-Downloads und Updates bewusst pruefen.

Gitea

  • Registrierung nach erstem Admin deaktivieren.
  • SSH/HTTP Zugriff ueber NPM und interne Netze absichern.
  • Repos mit .gitignore und Secret-Scanning betreiben.
  • Backups fuer Gitea-Datenbank und Repositories einrichten.

MkDocs Wiki

  • MkDocs selbst hat keine Benutzerverwaltung.
  • Zugriffsschutz ueber Nginx Proxy Manager Access List setzen.
  • Fuer wiki.lanstyle.de ist die NPM Access List Max aktiv.
  • Basic Auth plus optional IP-Allowlist in der Access List Max pflegen.
  • Pro Benutzer eigene Zugangsdaten anlegen.
  • Keine Wiki-Passwoerter in Markdown, Git oder Skripten speichern.
  • Vor Aenderungen an NPM immer /data/database.sqlite sichern.

OpenCode

  • Secrets liegen lokal in ~/.config/opencode/secrets.env mit Rechten 600.
  • API-Keys werden ueber Umgebungsvariablen referenziert.
  • Memory-Dateien duerfen keine Passwoerter, Tokens oder private Keys enthalten.
  • OpenCode spricht Lanstyle-Tools ueber https://mcphub.lanstyle.de/lanstyle-mcp mit LANSTYLE_MCPHUB_TOKEN.
  • Remote-MCP-Tokens werden pro Benutzer/Client vergeben und serverseitig einzeln aktivierbar, deaktivierbar und rotierbar gehalten.
  • Vaultwarden ist Source of Truth fuer aktive OpenCode-/MCP-Tokens; lokale secrets.env-Dateien sind nur Client-Kopien.
  • Der Bootstrap-/Legacy-Token ist deaktiviert; ungueltige oder deaktivierte Tokens muessen 401 liefern.
  • Remote-MCP-Logs duerfen nur Tokennamen und Hashpraefixe enthalten, niemals Tokenwerte.
  • Read-only- und Plan-only-Grenzen bleiben aktiv; Live-Writes benoetigen weiterhin einen separaten Approval-Flow.

Benutzer-Onboarding und Client-Haertung:

Controlled Execution

  • Echte Infrastruktur-Writes duerfen nur ueber den Controlled Execution Layer erfolgen.
  • Keine freie Shell, keine freien Root-/SSH-Writes und keine generischen PowerShell-/Bash-Execute-Tools.
  • Jede Write-Action braucht eine gueltige, nicht abgelaufene, serverseitig gepruefte approval_id.
  • Jede erfolgreiche Aktion braucht Backup-/Export-Referenz, Audit-Event, Verification-Ergebnis und Rollback-Referenz.
  • Approval-IDs sind Single-Use und werden nach erfolgreicher Ausfuehrung nicht erneut akzeptiert.
  • Forbidden Actions bleiben blockiert: VM/LXC delete/destroy, Firewall Default Policy, mass AD/Exchange, Intune wipe/delete, Secret Export, NPM Lockout, destruktive VLAN-/Routing-Aenderungen, Proxmox Storage Deletion.
  • Aktuell freigegeben sind nur Mock, Export-only Aktionen und eng gescopte Low-Risk-Testwrites.
  • Failure-Audits muessen vorhandene Backup-/Export-Referenzen enthalten, auch wenn der anschliessende Write oder die Verification fehlschlaegt.

Vaultwarden

  • Vaultwarden ist die zentrale Ablage fuer Passwoerter, API-Keys und Service-Credentials.
  • Externer Zugriff erfolgt ueber https://vault.lanstyle.de mit TLS und NPM.
  • Admin-Token nicht in Git, Wiki, Shell-Historie oder Chatverlaeufen speichern.
  • Automatisierung bevorzugt ueber Bitwarden CLI bw mit aktiver BW_SESSION.
  • API-Keys, die in Chats oder Logs sichtbar wurden, rotieren und danach im Vault neu hinterlegen.
  • Projektdateien enthalten nur Secret-Namen oder Beispiele, keine echten Werte.
  • OpenCode-MCP-Tokens werden als Vaultwarden-Eintraege nach Schema Lanstyle / OpenCode MCP Token / <vorname-nachname-client> abgelegt.
  • NetBox-Test-Write-Tokens werden als Vaultwarden-Eintrag Lanstyle / NetBox API Token Agent Test Write abgelegt.

Secret Lifecycle Governance

Alle produktiven Secrets brauchen einen Lifecycle-Datensatz nach agent-runtime/configs/secret-lifecycle.schema.json.

Betroffene Klassen: MCP Tokens, NetBox Tokens, LiteLLM Keys, OpenCode User Tokens, NPM API, Proxmox API, SMTP/API Keys.

Pflichtfelder: Owner, Scope, Ablauf, Erstellzeit, Rotation Policy, Rotation History, Source of Truth, erlaubte Systeme, Emergency-Revoke-Weg.

Bootstrap- und Legacy-Tokens muessen als solche markiert, zeitlich begrenzt und nach erfolgreicher Migration deaktiviert werden.

Backup-Empfehlung

Regelmaessig sichern:

  • Open WebUI Datenverzeichnis
  • Ollama Modelle und Konfiguration
  • Open Terminal LXC-Konfiguration und Docker Volume open-terminal-data
  • Gitea Repositories und Datenbank
  • Vaultwarden Datenverzeichnis, Env-Datei und Admin-Token
  • NPM Datenbank

Backup-Metadaten

runtime_backup_validation_v1 darf Backup-Readiness nur anhand von Metadaten bewerten (Pfad, Existenz, Zeitstempel, Alter, Groesse, Rechte, Owner, Restore-Runbook-Referenz).

Nicht erlaubt: Backup-Inhalte lesen, Datenbank-Dumps oeffnen, Secret-Dateien ausgeben, Tokenwerte in Reports schreiben, Backups loeschen oder ueberschreiben.

Metadaten-Snapshots externer Systeme liegen unter /var/lib/lanstyle-agent/controlled-execution/backup-metadata/ und muessen privat gehalten werden.