Security - Neotask by Neotask Documentation | Neotask

Sicurezza

Panoramica

Open Claw è progettato con un'architettura security-first. Il Gateway si lega a localhost per default, tutti i dati sensibili sono crittografati a riposo e l'esecuzione degli agenti può essere sandboxed in container isolati.

Sicurezza di Rete

Loopback per Default

Il Gateway ascolta solo su 127.0.0.1 (localhost) a meno che tu non cambi esplicitamente la modalità di binding. Nessuna esposizione alla rete esterna per default.

Autenticazione

Tutte le connessioni WebSocket richiedono autenticazione:

  • Token auth — Bearer token (UUID o stringa personalizzata)
  • Password auth — Password con hash bcrypt
  • Trusted proxy — Header pre-autenticati da proxy inversi
  • Local trust — Le connessioni loopback sono implicitamente affidabili

    • Sicurezza dell'Accesso Remoto

    Per l'accesso remoto, l'approccio consigliato è Tailscale VPN o SSH tunneling — non esporre mai il Gateway direttamente a Internet.

    Pairing dei Dispositivi

    Come Funziona il Pairing

    Ogni client che si connette al Gateway deve essere associato:

  • Il dispositivo presenta la propria identità (impronta digitale + chiave pubblica)
  • Il Gateway emette una sfida di pairing (nonce)
  • Il dispositivo firma il nonce con la propria chiave privata
  • Tu approvi il dispositivo tramite l'interfaccia utente
  • Il Gateway emette un token del dispositivo per le connessioni future

    • Modello di Fiducia

  • I dispositivi locali (loopback) vengono approvati automaticamente per comodità
  • I dispositivi non locali richiedono l'approvazione esplicita
  • I token del dispositivo vengono archiviati localmente e riutilizzati alla riconnessione
  • I dispositivi possono essere revocati in qualsiasi momento

    • Crittografia

    Dati a Riposo

  • AES-256-GCM — Tutti i token, segreti e chiavi API sono crittografati a riposo
  • Chiavi derivate dalla macchina — Chiavi di crittografia derivate tramite scrypt dall'identità del dispositivo
  • Nessun archiviazione in chiaro — I token non vengono mai archiviati in testo normale

    • Dati in Transito

  • TLS — HTTPS per la comunicazione API
  • WSS — WebSocket Secure per le connessioni al Gateway (quando si usa Tailscale Serve o proxy inverso)
  • Firma HMAC — Integrità delle richieste con nonce e timestamp

    • Sandboxing

    Isolamento Basato su Docker

    L'esecuzione dei comandi degli agenti può essere sandboxed in container Docker:

  • Profili per agente — Ogni agente può avere la propria configurazione sandbox
  • Limiti di risorse — Limiti CPU, memoria e timeout configurabili
  • Isolamento di rete — I container possono essere isolati dalla rete
  • Confinamento del filesystem — Gli agenti accedono solo al proprio workspace
  • Immagini personalizzate — Usa immagini pre-built con strumenti specifici installati

    • Scope del Sandbox

    | Scope | Descrizione | |-------|-------------| | Per sessione | Container nuovo per ogni sessione | | Per agente | Container persistente per agente | | Condiviso | Container condiviso tra gli agenti |

    Accesso al Workspace

    Gli agenti sandboxed possono accedere alla propria directory workspace (montata nel container) ma non possono accedere al filesystem dell'host fuori dal loro workspace.

    Approvazioni di Esecuzione

    Controlla quali comandi possono eseguire gli agenti sui nodi e sull'host del Gateway:

    Modalità

    | Modalità | Descrizione | |------|-------------| | Allowlist | Solo i comandi pre-approvati vengono eseguiti | | Ask | I comandi sconosciuti richiedono l'approvazione dell'utente | | Full | Nessuna restrizione (usa con cautela) |

    Configurazione per Nodo

    Ogni nodo (macOS, host headless) ha la propria configurazione delle approvazioni di esecuzione, archiviata localmente. Puoi consentire binari specifici (es. /usr/bin/docker, /usr/local/bin/terraform) bloccando tutto il resto.

    Modalità Elevata

    Alcune operazioni richiedono l'esecuzione direttamente sull'host del Gateway (non in un sandbox). La modalità elevata è:

  • Controllata da permessi espliciti nella configurazione dell'agente
  • Disponibile solo sull'host del Gateway
  • Disabilitata per default
  • Verificabile tramite logging

    • Audit di Sicurezza

    L'audit di sicurezza integrato controlla:

  • Permessi dei file di configurazione (dovrebbero essere 600)
  • Permessi dei file di sessione
  • Versione Node.js (patch di sicurezza)
  • Rilevamento di segreti in chiaro
  • Validazione della allowlist dei plugin
  • Audit delle interfacce di rete aperte
  • Completezza della configurazione dell'autenticazione

    • L'audit può correggere automaticamente molti problemi quando glielo viene permesso.

    Best Practice

  • Mantieni il Gateway su loopback — Usa Tailscale o SSH per l'accesso remoto
  • Abilita il sandboxing — Esegui i comandi degli agenti in container Docker
  • Usa le allowlist di esecuzione — Limita quali comandi possono eseguire gli agenti sui nodi
  • Imposta i token di autenticazione — Configura sempre l'autenticazione tramite token, anche per loopback
  • Rivedi i permessi degli agenti — Usa profili di strumenti minimali dove possibile
  • Mantieni Open Claw aggiornato — Gli aggiornamenti includono patch di sicurezza
  • Esegui audit regolarmente — Esegui audit di sicurezza per individuare configurazioni errate
  • Limita il caricamento dei plugin — Installa solo plugin affidabili

    • View full documentation