Security - Neotask by Neotask Documentation | Neotask

Seguridad

Descripcion General

Open Claw esta disenado con una arquitectura de seguridad primero. El Gateway se vincula a localhost por defecto, todos los datos sensibles se encriptan en reposo y la ejecucion de agentes puede aislarse en contenedores sandbox.

Seguridad de Red

Loopback por Defecto

El Gateway solo escucha en 127.0.0.1 (localhost) a menos que cambie explicitamente el modo de vinculacion. Sin exposicion de red externa por defecto.

Autenticacion

Todas las conexiones WebSocket requieren autenticacion:

  • Autenticacion por token -- Token bearer (UUID o cadena personalizada)
  • Autenticacion por contrasena -- Contrasena con hash bcrypt
  • Proxy de confianza -- Headers pre-autenticados de proxies inversos
  • Confianza local -- Las conexiones loopback se confian implicitamente

    • Seguridad de Acceso Remoto

    Para acceso remoto, el enfoque recomendado es VPN Tailscale o tunel SSH -- nunca exponga el Gateway directamente a internet.

    Emparejamiento de Dispositivos

    Como Funciona el Emparejamiento

    Todo cliente que se conecta al Gateway debe ser emparejado:

  • El dispositivo presenta su identidad (huella digital + clave publica)
  • El Gateway emite un desafio de emparejamiento (nonce)
  • El dispositivo firma el nonce con su clave privada
  • Usted aprueba el dispositivo a traves de la interfaz
  • El Gateway emite un token de dispositivo para futuras conexiones

    • Modelo de Confianza

  • Dispositivos locales (loopback) se aprueban automaticamente por conveniencia
  • Dispositivos no locales requieren aprobacion explicita
  • Los tokens de dispositivo se almacenan localmente y se reutilizan al reconectar
  • Los dispositivos pueden revocarse en cualquier momento

    • Encriptacion

    Datos en Reposo

  • AES-256-GCM -- Todos los tokens, secretos y claves API se encriptan en reposo
  • Claves derivadas de la maquina -- Claves de encriptacion derivadas via scrypt de la identidad del dispositivo
  • Sin almacenamiento en texto plano -- Los tokens nunca se almacenan en texto plano

    • Datos en Transito

  • TLS -- HTTPS para comunicacion API
  • WSS -- WebSocket Secure para conexiones al Gateway (cuando se usa Tailscale Serve o proxy inverso)
  • Firma HMAC -- Integridad de solicitud con nonce y marca de tiempo

    • Sandboxing

    Aislamiento Basado en Docker

    La ejecucion de comandos de agentes puede aislarse en contenedores Docker:

  • Perfiles por agente -- Cada agente puede tener su propia configuracion de sandbox
  • Limites de recursos -- Limites configurables de CPU, memoria y tiempo de espera
  • Aislamiento de red -- Los contenedores pueden aislarse de la red
  • Confinamiento del sistema de archivos -- Los agentes solo acceden a su espacio de trabajo
  • Imagenes personalizadas -- Use imagenes pre-construidas con herramientas especificas instaladas

    • Alcances de Sandbox

    | Alcance | Descripcion | |-------|-------------| | Por sesion | Contenedor nuevo para cada sesion | | Por agente | Contenedor persistente por agente | | Compartido | Contenedor compartido entre agentes |

    Acceso al Espacio de Trabajo

    Los agentes en sandbox pueden acceder a su directorio de espacio de trabajo (montado en el contenedor) pero no pueden acceder al sistema de archivos del host fuera de su espacio de trabajo.

    Aprobaciones de Ejecucion

    Controle que comandos pueden ejecutar los agentes en nodos y en el host del Gateway:

    Modos

    | Modo | Descripcion | |------|-------------| | Allowlist | Solo se ejecutan comandos pre-aprobados | | Ask | Los comandos desconocidos solicitan aprobacion del usuario | | Full | Sin restricciones (usar con precaucion) |

    Configuracion por Nodo

    Cada nodo (macOS, host headless) tiene su propia configuracion de aprobacion de ejecucion, almacenada localmente. Puede permitir binarios especificos (por ejemplo, /usr/bin/docker, /usr/local/bin/terraform) mientras bloquea todo lo demas.

    Modo Elevado

    Algunas operaciones requieren ejecutarse directamente en el host del Gateway (no en un sandbox). El modo elevado esta:

  • Controlado por permiso explicito en la configuracion del agente
  • Solo disponible en el host del Gateway
  • Deshabilitado por defecto
  • Auditable a traves de logging

    • Auditoria de Seguridad

    La auditoria de seguridad integrada verifica:

  • Permisos de archivos de configuracion (deben ser 600)
  • Permisos de archivos de sesion
  • Version de Node.js (parches de seguridad)
  • Deteccion de secretos en texto plano
  • Validacion de lista de permitidos de plugins
  • Auditoria de interfaces de red abiertas
  • Completitud de la configuracion de autenticacion

    • La auditoria puede corregir automaticamente muchos problemas cuando se le da permiso.

    Mejores Practicas

  • Mantenga el Gateway en loopback -- Use Tailscale o SSH para acceso remoto
  • Habilite sandboxing -- Ejecute comandos de agentes en contenedores Docker
  • Use listas de permitidos de ejecucion -- Restrinja que comandos pueden ejecutar los agentes en nodos
  • Establezca tokens de autenticacion -- Siempre configure autenticacion por token, incluso para loopback
  • Revise permisos de agentes -- Use perfiles de herramientas minimos donde sea posible
  • Mantenga Open Claw actualizado -- Las actualizaciones incluyen parches de seguridad
  • Audite regularmente -- Ejecute auditorias de seguridad para detectar configuraciones incorrectas
  • Restrinja la carga de plugins -- Solo instale plugins de confianza

    • View full documentation