Integrar API OTC envolve mover dinheiro real entre sistemas — qualquer falha de segurança pode custar dezenas a milhões de reais. Em 2026, padrões de segurança para APIs financeiras (cripto inclusive) são bem definidos. Este guia é o checklist de segurança que toda empresa integrando API OTC deve seguir.
Solicitar credenciais API OTC seguras →
Camada 1 — Autenticação HMAC-SHA256
HMAC-SHA256 é o padrão da indústria para autenticar requisições de API financeira. Como funciona:
- Mesa emite API key + secret
- Sua aplicação calcula
hmac_sha256(secret, timestamp + method + path + body) - Envia a assinatura no header da requisição
- Servidor valida usando o mesmo cálculo
Vantagens vs autenticação simples (Bearer token):
- Cada requisição é assinada individualmente
- Replay attacks são bloqueados (timestamp + tolerância)
- Body integrity é validada (não dá para mexer no payload em trânsito)
Erros comuns que comprometem a segurança:
- Logar o secret em arquivos ou monitoramento
- Hardcoded em código-fonte (use variáveis de ambiente ou secrets manager)
- Compartilhar secret entre dev/prod
Camada 2 — IP Whitelist
Toda mesa profissional permite restringir o uso da API key a IPs específicos. Boas práticas:
- Liste apenas IPs estáticos das suas máquinas de produção
- Use NAT Gateway para garantir IP fixo de saída
- NUNCA permita 0.0.0.0/0 (qualquer IP) — anula todo o resto
- Tenha API keys separadas para cada ambiente (dev/staging/prod) com whitelists diferentes
Sem IP whitelist, um secret vazado pode ser usado de qualquer lugar do mundo. Com whitelist, o atacante ainda precisa estar na rede correta.
| Camada de segurança | O que faz | Erro comum |
|---|---|---|
| HMAC-SHA256 | Autentica e valida integridade | Logar secret |
| IP whitelist | Restringe origem | Permitir 0.0.0.0/0 |
| Mínimo privilégio | Limita escopo | Habilitar withdrawal sem precisar |
| Rotação | Reduz janela de exposição | Não rotacionar nunca |
| Webhooks assinados | Bloqueia injeção | Não validar assinatura |
| Idempotency-Key | Evita duplicação | Não usar em retries |
Camada 3 — Princípio do mínimo privilégio
API keys devem ter exatamente as permissões necessárias — e nem uma a mais. Permissões típicas:
- read-only: ver saldos, histórico
- trading: solicitar cotação, executar operação
- withdrawal: sacar fundos para endereços externos
Boas práticas:
- API key de read-only para dashboards e monitoramento
- API key separada com permissão de trading para o sistema operacional
- NUNCA habilite withdrawal a menos que absolutamente necessário
- Se withdrawal for necessário, use whitelist de endereços de destino
Camada 4 — Rotação periódica e revogação
- Rotacione API secrets a cada 90 dias
- Revogue API keys imediatamente em caso de:
- Saída de funcionário com acesso
- Suspeita de comprometimento
- Mudança de ambiente
- Use “key versioning” — gere nova key, transicione em rolling deploy, depois revogue a antiga
- Mantenha audit log de criação/revogação de keys
Acessar a mesa OTC BitcoinP2P →
Práticas adicionais
Validação de webhooks
Webhooks recebidos da mesa também devem ser assinados com HMAC. Sua aplicação valida a assinatura ANTES de processar — caso contrário, atacantes podem injetar webhooks falsos.
Idempotência
Toda requisição que cria operação deve incluir Idempotency-Key único. Se a mesma chave for vista duas vezes, a mesa retorna o resultado da primeira — evita executar a mesma operação duas vezes em retries.
Rate limiting
APIs OTC têm rate limits (típico: 100-1000 RPM). Implemente backoff exponencial em sua aplicação. Não martele a API.
Logs estruturados
Log toda chamada com: timestamp, endpoint, status code, duration, correlation ID. Crucial para debug e auditoria. NUNCA logar secrets, payloads completos com PII, ou tokens.
Monitoramento
- Alertas de erro 5xx
- Alertas de taxa anormal de operações
- Alertas de operações fora do horário esperado
- Alertas de uso de API key de fora do whitelist (se vazar)
Segurança API OTC — 2026
HMAC
Padrão da indústria
90 dias
Rotação típica de secrets
4 camadas
Mínimo a implementar
Plano de resposta a incidentes
Tenha runbook para os cenários:
- Suspeita de vazamento de secret → revogar imediatamente
- Operação não autorizada detectada → pausar API key + investigar
- Reconciliação contábil falha → comparar logs internos com extrato da mesa
- Indisponibilidade da mesa → fallback para canal humano (chat OTC)
“Em API financeira, segurança não é feature — é pré-requisito. Toda integração que vimos comprometida tinha pelo menos uma das 4 camadas faltando. Geralmente IP whitelist.”
— Engenheiro de segurança
Auditoria periódica
- Trimestralmente: revisar permissões de cada API key
- Trimestralmente: revisar IPs no whitelist
- Anualmente: pen test do fluxo de integração
- Mensalmente: revisar logs de uso de API
Perguntas Frequentes
Quais são as 4 camadas de segurança em API OTC?
1) Autenticação HMAC-SHA256, 2) IP whitelist, 3) Princípio do mínimo privilégio nas permissões, 4) Rotação periódica de credenciais. Toda integração séria deve implementar as 4.
É seguro guardar API secret em código-fonte?
Não. Use variáveis de ambiente, secrets manager (AWS Secrets Manager, Vault) ou KMS. Nunca commit em repositórios.
O que é IP whitelist e por que importa?
É restringir o uso de uma API key a IPs específicos. Sem whitelist, um secret vazado pode ser usado de qualquer lugar do mundo. Com whitelist, o atacante precisa estar na rede correta.
Devo habilitar permissão de withdrawal na minha API key?
Apenas se absolutamente necessário. Se sim, use whitelist de endereços de destino. Para a maioria dos casos de uso (RFQ + settlement), withdrawal não é necessário.
Como reagir se eu suspeitar de vazamento de secret?
Revogue a API key imediatamente no painel da mesa. Audite logs de uso recente. Investigue o vetor de vazamento. Gere nova key com novo secret e volte ao operacional. Nunca tente “esperar para ver” — sempre revogue na suspeita.
Leia também: Como integrar API OTC para empresas e fundos