Seguridad
Descripcion General
Neotask 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 Neotask 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