Checklist de Segurança do OpenClaw Gateway: Evidência Antes da Exposição

Checklist de Segurança do OpenClaw Gateway: Evidência Antes da Exposição

Um OpenClaw Gateway não deve receber usuários remotos até o operador provar quem consegue alcançá-lo, como a identidade é verificada, quais agentes e ferramentas ficam acessíveis, quais credenciais eles possuem e como o acesso será revogado. Uma instalação funcionando não basta. A decisão de exposição precisa de evidência para cada controle e de um caminho de rollback testado.

Este checklist serve para a revisão imediatamente anterior à saída do uso local. Ele complementa o guia amplo de implementação do OpenClaw para empresas, que cobre desenho do fluxo, responsabilidade e operação em produção.

A decisão de exposição em uma tabela

A evidência não certifica a implantação. Ela torna a decisão revisável e revela controles ausentes antes que um canal ao vivo os descubra.

1. Registre o limite de confiança

Comece com um inventário curto:

• host do Gateway, usuário do sistema operacional e diretório de estado;
• bind, porta e todos os saltos de rede até o cliente;
• modo de autenticação e responsável pelo segredo ou fonte de identidade;
• canais habilitados, DMs, grupos e webhooks;
• agentes acessíveis por remetentes não locais;
• perfil de ferramentas, modo de sandbox, política de execução e acesso elevado de cada agente;
• credenciais externas disponíveis para esses agentes;
• local do backup e pessoa autorizada a restaurá-lo.

O runbook de exposição do OpenClaw diz que várias pessoas falando com o mesmo bot devem ser tratadas como autoridade delegada e compartilhada sobre ferramentas, não como isolamento de host por usuário. Se empresas, clientes ou grupos adversariais não podem compartilhar autoridade, pare e separe Gateway, credenciais, usuário do sistema operacional ou host.

Evidência: inventário datado com um operador responsável e um limite explícito.

Impedir exposição: ninguém consegue explicar quais identidades compartilham a mesma autoridade no host.

2. Escolha o padrão mais estreito de exposição

Prefira acesso local. Amplie apenas quando o fluxo exigir.

Redirecionamento público direto da porta é condição de parada. Quando acesso público for inevitável, o proxy deve ser a única rota de rede até o Gateway.

Evidência: padrão escolhido, motivo, valor de bind e probe pelo caminho esperado do cliente.

Impedir exposição: a porta do Gateway pode ser acessada diretamente pela internet pública.

3. Rode o baseline e guarde os findings

Execute as verificações nativas antes de mudar a exposição:

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

A auditoria devolve findings estruturados com checkId. A versão profunda adiciona probes do Gateway ao vivo e varredura de código em plugins e skills. Guarde versão do comando, horário, findings e decisão. Resolva findings críticos. Se um warning for aceito, registre por que ele é intencional, quem o aceitou e quando será revisto.

Para uma URL remota, passe a credencial explicitamente no probe. Não presuma que a credencial da configuração local vale para aquela URL.

Evidência: saída da auditoria e tratamento de todo finding crítico ou warning.

Impedir exposição: existe finding crítico aberto, o probe profundo não autentica ou um warning não tem responsável.

4. Prove identidade e negação nos canais

Autenticação só é útil quando o caminho indesejado falha. Teste os dois lados:

1. Uma identidade autorizada consegue conectar.
2. Um remetente ou navegador não autorizado é negado.
3. Cada DM ou grupo alcança apenas o agente pretendido.
4. Conversas compartilhadas não misturam contexto privado.

Nos canais de mensagem, prefira pareamento ou uma lista allowFrom estrita em vez de DMs abertas. Use IDs estáveis, exija menções em grupos quando a sala não for rigidamente controlada e use sessões de DM separadas por peer quando várias pessoas puderem falar com o bot.

Não combine wildcard de remetentes com ferramentas amplas. Parear alguém significa permitir que essa pessoa acione o bot. Isso não cria um limite de segurança separado no host.

Evidência: resultados dos testes permitido e negado, política do canal e escopo efetivo da sessão.

Impedir exposição: o time testou apenas o caminho feliz.

5. Inspecione a autoridade efetiva do agente

Sandbox, política de ferramentas e execução elevada são controles diferentes:

• o sandbox decide onde as ferramentas rodam;
• a política decide quais ferramentas existem;
• a execução elevada permite que exec saia do sandbox quando habilitada.

Use o inspetor nativo para a sessão ou agente real:

openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work

Depois revise a política efetiva de execução:

openclaw approvals get
openclaw exec-policy show

O OpenClaw documenta tools.exec.mode como a superfície preferida para política de execução no host. Comece com deny quando o fluxo não precisa de comandos no host. Se precisar, use a menor allowlist ou caminho de aprovação compatível com o trabalho. A política efetiva é o resultado mais restritivo entre configuração e arquivo de aprovações no host de execução.

Para ações de negócio além da execução no host, defina o mesmo limite por uma política de aprovação para agentes de IA que vincule cada decisão a um efeito, revisor, expiração e registro de evidência exatos.

Negar ferramentas de arquivo não torna um shell permitido somente leitura. O shell ainda pode mudar arquivos dentro das permissões do host ou sandbox. Bind mounts também atravessam o sistema de arquivos do sandbox, e o socket do Docker concede controle efetivo do host.

Evidência: explicação do sandbox, lista efetiva de ferramentas, política de execução e allowlist de acesso elevado.

Impedir exposição: um canal aberto alcança execução no host, acesso elevado, ferramentas do plano de controle, credenciais pessoais ou mounts amplos com escrita sem necessidade documentada.

6. Proteja segredos, estado e transcrições

A auditoria de segurança verifica permissões inseguras em estado, configuração, credenciais, perfis de autenticação, sessões e logs. Revise principalmente:

• estado ou configuração alterável por outros usuários;
• configuração, credenciais ou perfis legíveis por outros usuários;
• estado armazenado em pasta pessoal sincronizada;
• mesmo token reutilizado no Gateway e na entrada de hooks;
• logs com redação de valores sensíveis desabilitada;
• backups sem criptografia, responsável ou teste de restauração.

Separe credenciais do negócio de contas pessoais. Todo segredo precisa de responsável e caminho de revogação. Um backup que o operador não consegue restaurar não é evidência de recuperação.

Evidência: auditoria de permissões, inventário de segredos, local do backup e procedimento de rotação.

Impedir exposição: credenciais ou transcrições alcançam identidades além do usuário de sistema pretendido.

7. Verifique runtime e recuperação de falhas

O processo online não prova que o Gateway atende o fluxo. Verifique plano de controle, RPC e canais:

openclaw gateway status
openclaw status
openclaw gateway status --require-rpc
openclaw channels status --probe

Revise logs durante inicialização, pedido autorizado, pedido negado e uma falha esperada. Reinicie o processo gerenciado e prove que serviço, conexão do canal e agente pretendido se recuperam.

Também teste dependência indisponível, credencial expirada, aprovação negada e pedido duplicado. O responsável pelo fluxo deve saber o que para, o que tenta novamente e o que passa para uma pessoa.

Evidência: saída de saúde, teste de reinício, probe dos canais e um exercício documentado de falha.

Impedir exposição: a recuperação depende de a pessoa que construiu lembrar uma sequência não documentada.

8. Teste o rollback antes de ampliar acesso

Um rollback útil devolve o Gateway a um estado estreito:

1. remova redirecionamento público, rotas do proxy e exposição remota;
2. limite o Gateway ao loopback;
3. desabilite DMs e grupos expostos;
4. negue execução no host e desabilite acesso elevado;
5. rotacione credenciais do Gateway e integrações afetadas;
6. revise auditorias, execuções, chamadas de ferramentas e mudanças recentes;
7. rode novamente a auditoria profunda;
8. restaure apenas o menor padrão de acesso necessário ao fluxo.

Execute a sequência uma vez antes do lançamento. Registre responsável, tempo esperado, dependências e evidência de que o acesso foi realmente negado depois do rollback.

Evidência: registro do rollback testado e responsáveis pela rotação.

Impedir exposição: a única resposta para exposição excessiva é improvisar.

Registro copiável da revisão

Use este registro na decisão:

Gateway:
Responsável:
Data da revisão:
Versão do OpenClaw:
Fluxo:
Limite de confiança:
Padrão de exposição:
Identidades permitidas:
Agentes acessíveis:
Ferramentas acessíveis:
Credenciais externas:
Findings da auditoria:
Warnings aceitos e responsável:
Teste de conexão autorizada:
Teste de negação não autorizada:
Teste de roteamento dos canais:
Teste de reinício e recuperação:
Teste de rollback:
Decisão: segurar / exposição condicional / expor
Data da próxima revisão:

A decisão deve continuar como segurar enquanto houver condição de parada aberta. Exposição condicional significa piloto estreito com responsável, validade e limites explícitos, não uma exceção permanente.

Perguntas frequentes

Passar no openclaw security audit --deep é suficiente?

Não. A auditoria é um controle importante, mas a revisão também precisa de testes de identidade, roteamento dos canais, autoridade de ferramentas, credenciais, recuperação e rollback específicos ao fluxo.

O sandbox torna um OpenClaw Gateway seguro?

O sandbox limita onde certas ferramentas rodam. Ele não decide quem alcança o agente, quais ferramentas existem, quais credenciais ficam disponíveis ou se execução elevada pode sair do sandbox. Esses controles precisam ser revisados em conjunto.

Aprovações de execução são um sistema de permissão por usuário?

Não. O OpenClaw afirma que aprovações reduzem risco de execução acidental, mas não são um limite de autorização por usuário nem uma política de sistema de arquivos somente leitura. Limites de confiança diferentes ainda exigem isolamento arquitetural.

Um OpenClaw Gateway pode ficar público?

O runbook oficial trata exposição na internet pública como rara e de alto risco. Ele recomenda proxy com identidade, TLS, rate limit, allowlists estritas e sessões não principais em sandbox, sem rota pública direta até o Gateway.

Quando repetir o checklist?

Repita depois de mudar exposição, proxy, canais, agentes acessíveis, política de ferramentas, credenciais, plugins, skills ou limites de host. Defina também uma revisão recorrente compatível com o impacto do fluxo.

Referências oficiais

• Runbook de exposição do OpenClaw Gateway
• Catálogo de checks da auditoria de segurança
• Runbook do OpenClaw Gateway
• Sandbox, política de ferramentas e acesso elevado
• Aprovações de execução do OpenClaw

---

Se a revisão revelar limites misturados, credenciais amplas ou recuperação não testada, redesenhe antes da exposição. Mapeie uma implementação gerenciada de OpenClaw para a empresa ao redor do menor fluxo capaz de produzir evidência sem receber autoridade desnecessária.