Security - Neotask by Neotask Documentation | Neotask

Seguranca

Visao Geral

Open Claw e projetado com uma arquitetura que prioriza seguranca. O Gateway se vincula ao localhost por padrao, todos os dados sensiveis sao criptografados em repouso e a execucao de agentes pode ser isolada em containers sandbox.

Seguranca de Rede

Loopback por Padrao

O Gateway escuta apenas em 127.0.0.1 (localhost) a menos que voce altere explicitamente o modo de vinculacao. Nenhuma exposicao de rede externa por padrao.

Autenticacao

Todas as conexoes WebSocket requerem autenticacao:

  • Token auth -- Bearer token (UUID ou string personalizada)
  • Password auth -- Senha com hash bcrypt
  • Proxy confiavel -- Headers pre-autenticados de proxies reversos
  • Confianca local -- Conexoes loopback sao implicitamente confiaveis

    • Seguranca de Acesso Remoto

    Para acesso remoto, a abordagem recomendada e VPN Tailscale ou tunelamento SSH -- nunca exponha o Gateway diretamente a internet.

    Pareamento de Dispositivos

    Como o Pareamento Funciona

    Todo cliente que se conecta ao Gateway deve ser pareado:

  • Dispositivo apresenta sua identidade (fingerprint + chave publica)
  • Gateway emite um desafio de pareamento (nonce)
  • Dispositivo assina o nonce com sua chave privada
  • Voce aprova o dispositivo pela UI
  • Gateway emite um token de dispositivo para conexoes futuras

    • Modelo de Confianca

  • Dispositivos locais (loopback) sao auto-aprovados por conveniencia
  • Dispositivos nao-locais requerem aprovacao explicita
  • Tokens de dispositivo sao armazenados localmente e reutilizados na reconexao
  • Dispositivos podem ser revogados a qualquer momento

    • Criptografia

    Dados em Repouso

  • AES-256-GCM -- Todos os tokens, segredos e API keys sao criptografados em repouso
  • Chaves derivadas da maquina -- Chaves de criptografia derivadas via scrypt da identidade do dispositivo
  • Sem armazenamento em texto puro -- Tokens nunca sao armazenados em texto puro

    • Dados em Transito

  • TLS -- HTTPS para comunicacao API
  • WSS -- WebSocket Secure para conexoes do Gateway (ao usar Tailscale Serve ou proxy reverso)
  • Assinatura HMAC -- Integridade de requisicao com nonce e timestamp

    • Sandboxing

    Isolamento Baseado em Docker

    A execucao de comandos de agentes pode ser isolada em containers Docker:

  • Perfis por agente -- Cada agente pode ter sua propria configuracao de sandbox
  • Limites de recursos -- Limites configuraveis de CPU, memoria e timeout
  • Isolamento de rede -- Containers podem ser isolados da rede
  • Confinamento de sistema de arquivos -- Agentes acessam apenas seu workspace
  • Imagens personalizadas -- Use imagens pre-construidas com ferramentas especificas instaladas

    • Escopos de Sandbox

    | Escopo | Descricao | |--------|-----------| | Por sessao | Container novo para cada sessao | | Por agente | Container persistente por agente | | Compartilhado | Container compartilhado entre agentes |

    Acesso ao Workspace

    Agentes em sandbox podem acessar seu diretorio de workspace (montado no container) mas nao podem acessar o sistema de arquivos do host fora do seu workspace.

    Aprovacoes de Exec

    Controle quais comandos agentes podem executar em nodes e no host do Gateway:

    Modos

    | Modo | Descricao | |------|-----------| | Lista de permissao | Apenas comandos pre-aprovados executam | | Perguntar | Comandos desconhecidos solicitam aprovacao do usuario | | Completo | Sem restricoes (use com cautela) |

    Configuracao por Node

    Cada node (macOS, host headless) tem sua propria configuracao de aprovacao de exec, armazenada localmente. Voce pode permitir binarios especificos (ex.: /usr/bin/docker, /usr/local/bin/terraform) enquanto bloqueia todo o resto.

    Modo Elevado

    Algumas operacoes requerem execucao diretamente no host do Gateway (nao em sandbox). O modo elevado e:

  • Controlado por permissao explicita na configuracao do agente
  • Disponivel apenas no host do Gateway
  • Desabilitado por padrao
  • Auditavel atraves de logging

    • Auditoria de Seguranca

    A auditoria de seguranca integrada verifica:

  • Permissoes de arquivo de configuracao (devem ser 600)
  • Permissoes de arquivo de sessao
  • Versao do Node.js (patches de seguranca)
  • Deteccao de segredos em texto puro
  • Validacao de lista de permissao de plugins
  • Auditoria de interfaces de rede abertas
  • Completude da configuracao de autenticacao

    • A auditoria pode corrigir automaticamente muitos problemas quando dada permissao.

    Melhores Praticas

  • Mantenha o Gateway em loopback -- Use Tailscale ou SSH para acesso remoto
  • Habilite sandboxing -- Execute comandos de agentes em containers Docker
  • Use listas de permissao de exec -- Restrinja quais comandos agentes podem executar em nodes
  • Defina tokens de auth -- Sempre configure token auth, mesmo para loopback
  • Revise permissoes de agentes -- Use perfis de ferramentas minimos quando possivel
  • Mantenha o Open Claw atualizado -- Atualizacoes incluem patches de seguranca
  • Audite regularmente -- Execute auditorias de seguranca para detectar configuracoes incorretas
  • Restrinja carregamento de plugins -- Instale apenas plugins confiaveis

    • View full documentation