Rejeitando imediatamente chaves de API habilitadas para saque: o mergulho técnico

A maioria das plataformas de trading aceita chaves de API com permissão de saque habilitada. Elas mostram um banner amarelo de aviso, pedem que você digite 'Eu entendo' e armazenam a chave assim mesmo. Nós não fazemos isso. Se sua chave tiver permissão de saque, rejeitamos no onboarding e nunca a armazenamos. Este post explica por que, como e o que a alternativa realmente custa.

O modelo de ameaça em um parágrafo

Qualquer sistema que mantém uma chave de API habilitada para saque está a um vazamento de credenciais de distância de esvaziar contas de usuários. O vazamento não precisa ser uma violação de banco de dados — pode ser um laptop de funcionário comprometido, um backup mal configurado, um canal lateral em uma dependência de terceiros ou um dump de memória de processo em um log não criptografado. Cada um desses já aconteceu com empresas maiores que nós. A única defesa durável é: não ter as chaves dos fundos de ninguém em primeiro lugar.

Como a detecção funciona

Na primeira chamada autenticada após o usuário colar uma chave, fazemos uma chamada de introspecção de permissão específica da exchange. A maioria das principais venues expõe:

• Um endpoint dedicado de 'consulta de informações de chave de API' que retorna o conjunto de permissões como um campo estruturado, ou
• Um endpoint de informações de conta onde o escopo de permissão da chave está incluído como parte do payload de resposta.

Procuramos qualquer flag que conceda saque, transferência interna, transferência de sub-conta para fora ou transferência universal para fora — as venues usam nomes diferentes para a mesma ideia. Se algum desses estiver presente, descartamos o segredo da memória imediatamente, retornamos um erro estruturado para a interface e nunca gravamos a chave em nosso banco de dados.

Por que rejeitar imediatamente em vez de avisar

Avisos são clicados sem leitura. Observamos os dados sobre isso por anos em vários produtos. A taxa base de usuários digitando 'Eu entendo' sem ler uma única palavra acima disso está acima de 80%. Um aviso que 80% dos usuários ignoram não é um controle de segurança; é um escudo de responsabilidade.

A rejeição imediata é o oposto. Coloca o atrito no lugar certo: o usuário volta para a exchange, cria uma nova chave apenas com permissão de trade, volta e cola essa. O ciclo inteiro custa ao usuário talvez dois minutos. Custa ao atacante — no pior cenário de vazamento de credenciais — a conta inteira.

O que o caminho de avisar-em-vez-de-rejeitar realmente custa

O padrão de avisar-e-armazenar parece amigável ao usuário até você perguntar: como seria o pior caso? Você tem um funcionário hostil, um comprometimento na cadeia de suprimentos, um canal lateral em uma dependência transitiva, um log com escopo errado, e a resposta é que chaves habilitadas para saque são exatamente tão boas quanto a pessoa mais fraca e o código mais fraco que já as tocou.

A rejeição imediata inverte esse cálculo. Mesmo em um comprometimento total do banco de dados no pior caso, o atacante sai com chaves de leitura e trade. Chaves somente de trade podem causar danos — podem encerrar posições, gerar taxas, lançar posições abertas em pares ilíquidos — mas não podem sacar. Os fundos permanecem na exchange. Isso não é risco zero, mas é o risco que você aceitou ao conectar um agente de trading automatizado.

O que ainda não conseguimos defender

Não estamos fingindo que a rejeição imediata é uma postura de segurança completa. É um controle. O conjunto completo está documentado em nossa página de segurança: criptografia de envelope KMS com chaves de dados por usuário, segredos descriptografados que vivem apenas na memória do processo e apenas pela duração de uma chamada de API, log de auditoria append-only com hash encadeado, isolamento entre usuários testado por CI e um programa de divulgação de vulnerabilidades. Rejeitar a permissão de saque é apenas a parte mais visível dessa pilha — e a mais fácil de verificar você mesmo, porque você pode nos ver rejeitando uma chave habilitada para saque em tempo real durante o onboarding.