Boas Práticas de Segurança

Checklist e recomendações para manter seu OpenClaw seguro.

Introdução

A segurança do OpenClaw depende mais da configuração correta do que da sorte. Diferente de softwares simples que funcionam de forma razoavelmente segura com as configurações padrão, um agente de IA com capacidade de execução requer atenção ativa à configuração de permissões, gerenciamento de credenciais e monitoramento de atividades.

Este guia compila as boas práticas essenciais em formato de checklist, organizado por área e nível de risco. Você não precisa implementar tudo de uma vez — comece pelas práticas de alto impacto e evolua progressivamente. Para o contexto completo de segurança, consulte também os riscos conhecidos e o guia de LGPD.

A segurança eficaz é sempre em camadas: nenhuma medida isolada é suficiente, mas a combinação de várias proteções cria um ambiente robusto.

Por Que É Importante

O OpenClaw executa comandos reais no seu sistema, acessa integrações com dados sensíveis e processa informações que podem incluir credenciais, dados de clientes e propriedade intelectual. Uma configuração inadequada pode resultar em:

• Acesso não autorizado a arquivos e sistemas
• Exposição de credenciais de API
• Execução acidental de comandos destrutivos
• Processamento inadequado de dados pessoais (risco LGPD)
• Vulnerabilidade a ataques de prompt injection

Como Funciona o Modelo de Permissões

O OpenClaw usa um modelo de permissões em camadas que você controla completamente. O princípio fundamental é o mínimo privilégio necessário: o assistente só deve ter acesso ao que realmente precisa para as tarefas configuradas. Permissões extras não são “mais seguras por terem opções” — são superfícies de ataque desnecessárias.

Implementação Passo a Passo

Fase 1: Credenciais (Faça Primeiro)

Credenciais expostas são o risco mais crítico. Configure corretamente antes de qualquer outra coisa:

# Configuração protegida
chmod 600 ~/.openclaw/config.yaml

# Workspace do usuário
chmod 700 ~/clawd

# Logs com acesso restrito
chmod 600 ~/clawd/memory/*.md

Nunca armazene API keys diretamente no config.yaml. Use sempre variáveis de ambiente:

# config.yaml - CORRETO
anthropic:
  api_key: ${ANTHROPIC_API_KEY}

# config.yaml - ERRADO
anthropic:
  api_key: "sk-ant-xxxxxxxxx"  # Nunca faça isso

Fase 2: Execução de Comandos

Configure a allowlist de comandos — o que o assistente pode executar. Prefira allowlist (lista de permitidos) em vez de denylist (lista de bloqueados), pois é mais seguro:

# config.yaml
exec:
  security: allowlist
  allowlist:
    - ls
    - cat
    - grep
    - git status
    - git log
    - npm
  denylist:
    - rm -rf
    - sudo
    - dd
    - mkfs
    - curl  # Se não precisar

Fase 3: Controle de Acesso

Restrinja quem pode interagir com o assistente:

# config.yaml - Exemplo seguro completo

# Keys via variáveis de ambiente
anthropic:
  api_key: ${ANTHROPIC_API_KEY}

# Comandos restritos
exec:
  security: allowlist
  allowlist:
    - ls
    - cat
    - grep
    - git
    - npm
  denylist:
    - rm -rf
    - sudo
    - dd

# Auditoria habilitada
audit:
  enabled: true
  log_commands: true

# Canais restritos
channels:
  whatsapp:
    allowlist:
      - "+5511999999999"  # Só seu número

Fase 4: Auditoria

Habilite logs antes de usar em produção:

# config.yaml
audit:
  enabled: true
  path: ~/clawd/audit.log
  log_commands: true
  log_files: true
  retention_days: 30

Checklist de Segurança

API Keys e Credenciais

• API keys em variáveis de ambiente (não hardcoded)
• Arquivo config.yaml com permissão 600
• Keys diferentes para desenvolvimento e produção
• Rotação de keys a cada 6 meses
• Revogação imediata de keys comprometidas

Permissões de Arquivo

• chmod 600 no config.yaml
• chmod 700 no diretório clawd
• Logs com acesso restrito
• Backups criptografados

Execução de Comandos

• Allowlist de comandos configurada
• Comandos destrutivos bloqueados (rm -rf, etc.)
• sudo desabilitado ou restrito
• Sandbox quando possível
• Confirmação para ações destrutivas habilitada

Rede e Acesso

• Gateway não exposto à internet pública (se uso local)
• HTTPS para webhooks externos
• Firewall configurado
• VPN para acesso remoto se necessário

Dados Sensíveis

• Senhas nunca no chat ou na memória
• Dados de cartão nunca armazenados
• PII minimizado na memória
• Backups criptografados
• Retenção de logs configurada

Por Nível de Risco

Alto Risco — Nunca Faça

• Armazenar senhas na memória do assistente
• Rodar como usuário root
• Expor o gateway sem autenticação na internet
• Desabilitar a allowlist de comandos completamente
• Escrever API keys diretamente no arquivo de configuração

Médio Risco — Evite

• API keys hardcoded em qualquer arquivo versionado
• Permissões muito abertas em diretórios do assistente
• Logs com dados pessoais identificáveis
• Webhooks sem validação de assinatura
• Skills de comunidade sem revisão do código

Baixo Risco — Recomendado

• Auditoria de comandos habilitada
• Backup regular dos arquivos de configuração
• Atualizações automáticas do OpenClaw
• Revisão periódica das permissões configuradas
• Monitoramento de uso anormal de API

Revisando Logs de Auditoria

Revise periodicamente o que o assistente está fazendo:

# Comandos executados
grep "exec:" ~/clawd/audit.log

# Arquivos acessados
grep "file:" ~/clawd/audit.log

# Ações suspeitas
grep -E "(rm|sudo|password)" ~/clawd/audit.log

Procure padrões incomuns: comandos fora do horário de trabalho, acesso a arquivos que não deveriam ser acessados, tentativas de execução de comandos não permitidos.

Boas Práticas Avançadas

Isolamento por ambiente: Use instâncias separadas do OpenClaw para diferentes ambientes (desenvolvimento, produção, dados sensíveis). Cada instância tem permissões específicas para o seu contexto.

Revisão de skills: Antes de instalar qualquer skill da comunidade, leia o código. Use o Cisco Skill Scanner para análise automática de segurança.

Rotação de sessões: Configure expiração de sessões e não acumule histórico indefinidamente. Contexto desnecessariamente longo aumenta a superfície de ataque para prompt injection.

Resposta a Incidentes

Se Suspeitar de Comprometimento

1. Pare o gateway: openclaw gateway stop
2. Revogue keys: Nos dashboards de Anthropic/OpenAI/Google
3. Verifique logs: Procure ações suspeitas no audit.log
4. Mude senhas: Se alguma foi exposta ou está nos logs
5. Reporte: Se encontrar vulnerabilidade, escreva para security@clawd.bot

Contato de Segurança

Email: security@clawd.bot

Não abra issues públicas para relatar vulnerabilidades — use o canal privado para dar tempo de correção antes da divulgação pública.

Atualizações de Segurança

Mantenha o OpenClaw atualizado para receber correções de segurança:

# Verificar atualizações disponíveis
npm outdated -g openclaw

# Atualizar para versão mais recente
npm update -g openclaw

Configure notificações do repositório para receber alertas sobre novas versões de segurança.

Checklist de Segurança

FAQ

Q: Preciso configurar tudo isso antes de começar a usar? As práticas de alta prioridade (keys em variáveis de ambiente, allowlist de comandos, permissões de arquivo) devem ser configuradas desde o início. As demais podem ser implementadas progressivamente.

Q: Como saber se a configuração está segura? Execute openclaw security-check para uma análise automática das configurações mais críticas. Consulte também a lista de riscos conhecidos.

Q: É necessário usar usuario dedicado para o OpenClaw? Para uso pessoal, não é obrigatório, mas é altamente recomendado em ambientes de produção ou com dados sensíveis. Um usuário dedicado com permissões mínimas limita o impacto de qualquer comprometimento.

Q: Com que frequência devo revisar os logs de auditoria? Para uso pessoal, semanal é suficiente. Para ambientes corporativos, configure alertas automáticos para padrões suspeitos e revisão diária dos logs críticos.

Próximos Passos

• Guia de Segurança completo
• Proteção contra Prompt Injection
• Auditoria e Logs
• LGPD e conformidade