Security - Neotask by Neotask Documentation | Neotask

Sicherheit

Ueberblick

Open Claw ist mit einer Security-First-Architektur konzipiert. Das Gateway bindet standardmaessig an localhost, alle sensiblen Daten werden im Ruhezustand verschluesselt, und die Agenten-Ausfuehrung kann in isolierten Containern sandboxed werden.

Netzwerksicherheit

Loopback als Standard

Das Gateway hoert nur auf 127.0.0.1 (localhost), es sei denn, Sie aendern den Bindungsmodus explizit. Keine externe Netzwerkexposition standardmaessig.

Authentifizierung

Alle WebSocket-Verbindungen erfordern Authentifizierung:

  • Token-Auth -- Bearer-Token (UUID oder benutzerdefinierte Zeichenkette)
  • Passwort-Auth -- Bcrypt-gehashtes Passwort
  • Trusted Proxy -- Vorab authentifizierte Header von Reverse-Proxys
  • Local Trust -- Loopback-Verbindungen werden implizit vertraut

    • Remote-Zugriffssicherheit

    Fuer Remote-Zugriff ist der empfohlene Ansatz Tailscale VPN oder SSH-Tunneling -- setzen Sie das Gateway nie direkt dem Internet aus.

    Geraetekopplung

    Wie Kopplung funktioniert

    Jeder Client, der sich mit dem Gateway verbindet, muss gekoppelt werden:

  • Geraet praesentiert seine Identitaet (Fingerprint + oeffentlicher Schluessel)
  • Gateway sendet eine Kopplungs-Challenge (Nonce)
  • Geraet signiert die Nonce mit seinem privaten Schluessel
  • Sie genehmigen das Geraet ueber die Benutzeroberflaeche
  • Gateway stellt ein Geraete-Token fuer zukuenftige Verbindungen aus

    • Vertrauensmodell

  • Lokale Geraete (Loopback) werden der Bequemlichkeit halber automatisch genehmigt
  • Nicht-lokale Geraete erfordern explizite Genehmigung
  • Geraete-Tokens werden lokal gespeichert und bei Wiederverbindung wiederverwendet
  • Geraete koennen jederzeit widerrufen werden

    • Verschluesselung

    Daten im Ruhezustand

  • AES-256-GCM -- Alle Tokens, Secrets und API-Schluessel werden im Ruhezustand verschluesselt
  • Maschinenabgeleitete Schluessel -- Verschluesselungsschluessel ueber scrypt von der Geraeteidentitaet abgeleitet
  • Keine Klartextspeicherung -- Tokens werden nie im Klartext gespeichert

    • Daten waehrend der Uebertragung

  • TLS -- HTTPS fuer API-Kommunikation
  • WSS -- WebSocket Secure fuer Gateway-Verbindungen (bei Verwendung von Tailscale Serve oder Reverse Proxy)
  • HMAC-Signierung -- Anfrage-Integritaet mit Nonce und Zeitstempel

    • Sandboxing

    Docker-basierte Isolation

    Agenten-Befehlsausfuehrung kann in Docker-Containern sandboxed werden:

  • Pro-Agent-Profile -- Jeder Agent kann seine eigene Sandbox-Konfiguration haben
  • Ressourcenlimits -- Konfigurierbare CPU-, Speicher- und Timeout-Limits
  • Netzwerkisolation -- Container koennen netzwerkisoliert werden
  • Dateisystembeschraenkung -- Agenten greifen nur auf ihren Workspace zu
  • Benutzerdefinierte Images -- Vorgefertigte Images mit bestimmten installierten Tools verwenden

    • Sandbox-Scopes

    | Scope | Beschreibung | |-------|-------------| | Per-Session | Frischer Container fuer jede Session | | Per-Agent | Persistenter Container pro Agent | | Shared | Geteilter Container ueber Agenten hinweg |

    Workspace-Zugriff

    Sandboxed Agenten koennen auf ihr Workspace-Verzeichnis zugreifen (in den Container eingehaengt), aber nicht auf das Host-Dateisystem ausserhalb ihres Workspaces.

    Exec-Genehmigungen

    Steuern Sie, welche Befehle Agenten auf Nodes und dem Gateway-Host ausfuehren koennen:

    Modi

    | Modus | Beschreibung | |------|-------------| | Allowlist | Nur vorab genehmigte Befehle werden ausgefuehrt | | Ask | Unbekannte Befehle erfordern Benutzergenehmigung | | Full | Keine Einschraenkungen (mit Vorsicht verwenden) |

    Pro-Node-Konfiguration

    Jeder Node (macOS, Headless-Host) hat seine eigene Exec-Genehmigungskonfiguration, lokal gespeichert. Sie koennen bestimmte Binaerdateien erlauben (z.B. /usr/bin/docker, /usr/local/bin/terraform) und alles andere blockieren.

    Elevated Mode

    Einige Operationen erfordern die Ausfuehrung direkt auf dem Gateway-Host (nicht in einer Sandbox). Der Elevated Mode ist:

  • Durch explizite Berechtigung in der Agent-Konfiguration eingeschraenkt
  • Nur auf dem Gateway-Host verfuegbar
  • Standardmaessig deaktiviert
  • Durch Protokollierung ueberpruefbar

    • Sicherheits-Audit

    Die integrierte Sicherheitspruefung untersucht:

  • Konfigurationsdatei-Berechtigungen (sollten 600 sein)
  • Session-Datei-Berechtigungen
  • Node.js-Version (Sicherheitspatches)
  • Klartext-Secret-Erkennung
  • Plugin-Allowlist-Validierung
  • Offene Netzwerk-Interface-Pruefung
  • Auth-Konfiguration-Vollstaendigkeit

    • Die Pruefung kann viele Probleme automatisch beheben, wenn die Berechtigung erteilt wird.

    Best Practices

  • Gateway auf Loopback belassen -- Tailscale oder SSH fuer Remote-Zugriff verwenden
  • Sandboxing aktivieren -- Agentenbefehle in Docker-Containern ausfuehren
  • Exec-Allowlists verwenden -- Einschraenken, welche Befehle Agenten auf Nodes ausfuehren koennen
  • Auth-Tokens setzen -- Immer Token-Auth konfigurieren, auch fuer Loopback
  • Agent-Berechtigungen ueberpruefen -- Wo moeglich minimale Tool-Profile verwenden
  • Open Claw aktuell halten -- Updates enthalten Sicherheitspatches
  • Regelmaessig pruefen -- Sicherheits-Audits durchfuehren, um Fehlkonfigurationen zu erkennen
  • Plugin-Laden einschraenken -- Nur vertrauenswuerdige Plugins installieren

    • View full documentation