O pedido veio do domínio certo. Não veio da autoridade.

Existe uma categoria de incidente que não aparece em painel de segurança porque nada nela quebrou. Este é o exemplo do ano.

Não houve exploração de vulnerabilidade. Não houve credencial roubada, sessão sequestrada, malware, movimentação lateral ou exfiltração. O dado saiu pela porta que a instituição mantém aberta de propósito, operada por pessoas que fizeram exatamente o que o procedimento manda fazer. O controle não falhou. O controle não existia.

O canal que roda na confiança

Toda instituição financeira, toda operadora de telecomunicações e toda plataforma de tecnologia mantém um canal para atender requisição de autoridade. Delegacia, Ministério Público, juízo, autoridade fiscal, autoridade administrativa. Na maior parte dos casos, esse pedido vem acompanhado de ordem judicial e o fluxo é lento por desenho: o jurídico analisa, questiona escopo, responde por ofício.

Existe, porém, uma via rápida. Em situação de perigo iminente à vida, a autoridade pode pedir dado sem esperar a ordem judicial, e a instituição pode entregar. Em inglês o mecanismo se chama emergency data request, e a crítica a ele não é nova: a via foi criada justamente para dispensar a verificação que tomaria tempo. É essa dispensa que o atacante compra.

O precedente mais conhecido é de 2022, quando contas de e-mail policiais comprometidas foram usadas para enviar pedidos falsos a Meta, Apple, Discord e Snap. As empresas entregaram dado de usuário acreditando responder a uma autoridade real. Quatro anos depois, o mesmo método funciona contra um banco digital com dezenas de milhões de clientes.

Por que a verificação técnica não ajuda

Vale desmontar a defesa que vem primeiro à cabeça, porque ela não resolve o problema.

A resposta intuitiva é autenticação de e-mail. SPF, DKIM e DMARC existem para provar que a mensagem saiu do domínio que ela diz ter saído. Nesse caso, provaram. O domínio era de fato de uma agência de governo. O que a autenticação de e-mail não faz, e nunca se propôs a fazer, é responder a outra pergunta: a pessoa que controla essa caixa tem competência legal para pedir isso?

São duas verificações distintas, e a segunda é de processo, não de tecnologia. Ela depende de três coisas que nenhum gateway entrega:

• Retorno por canal independente. Ligar para o número institucional publicado pelo órgão, nunca para o telefone que consta na assinatura do e-mail, e confirmar a existência do procedimento com o setor responsável.
• Conferência de competência. Verificar se aquele órgão, naquela matéria e naquela jurisdição, pode requisitar aquele tipo de dado sem ordem judicial. Nem toda autoridade pode pedir tudo.
• Proporcionalidade do escopo. Uma investigação criminal específica quase nunca justifica passaporte, selfie de verificação e histórico completo de transações de um cliente. Pedido amplo demais é sinal, e sinal que se repete por meses deveria ter escalado.

Esse último ponto é o mais desconfortável do caso. A relação durou meses. Não foi um e-mail isolado em uma sexta-feira à noite, que é o cenário em que o erro humano se explica sozinho. Houve tempo, volume e repetição — três coisas que, em um processo bem desenhado, disparam revisão.

O que a LGPD faz com um caso assim

Aqui a leitura brasileira diverge do noticiário internacional, e vale explicitar por quê.

A LGPD trata a hipótese de cumprimento de obrigação legal ou regulatória e a de atendimento a requisição de autoridade competente como bases que autorizam o tratamento. A palavra que carrega o peso é competente. Se a requisição não partiu de autoridade com competência para fazê-la, não há base legal, e o compartilhamento passa a ser tratamento irregular de dado pessoal — inclusive de dado que, no caso, alimenta fraude de identidade por anos.

A boa-fé do controlador não desfaz o fato. Ela entra na dosimetria da sanção, não na caracterização da irregularidade. O artigo 48 impõe a comunicação à autoridade nacional e aos titulares quando o incidente puder acarretar risco ou dano relevante, e um conjunto que reúne documento de identidade, selfie de verificação e histórico financeiro de clientes de alto patrimônio dificilmente escapa desse critério.

Há ainda o agravante da sensibilidade prática. Documento e selfie são exatamente o par que serve para abrir conta em outra instituição por verificação remota. O dado vazado aqui é insumo direto de fraude de abertura de conta em terceiros que não têm relação nenhuma com o incidente.

Leitura LATAMSEC

Quatro perguntas para levar à próxima reunião de comitê. Nenhuma delas é sobre a Revolut.

Quem, na sua organização, pode atender uma requisição de autoridade sem segunda assinatura? Se a resposta for um time de atendimento, um analista de compliance ou uma caixa compartilhada, o risco está aberto hoje.

Existe procedimento escrito de retorno por canal independente? Escrito, com a lista de telefones institucionais dos órgãos que mais requisitam, e treinado. Procedimento que mora na cabeça de quem faz há dez anos não sobrevive à primeira férias.

O que é registrado quando um pedido é atendido? Precisa haver trilha com data, órgão, fundamento invocado, escopo entregue, quem autorizou e como a autenticidade foi confirmada. Sem essa trilha, a organização não consegue nem dizer quantos clientes foram afetados quando descobrir a fraude.

Há limite de escopo automático? Entregar documento de identidade, biometria facial e histórico financeiro completo deveria exigir aprovação de nível diferente da entrega de um cadastro básico. Se o mesmo botão libera as duas coisas, a decisão está no lugar errado da hierarquia.

O incidente da Revolut é caro porque expõe uma assimetria que vale para quase toda empresa regulada da região: investe-se muito em impedir que o dado saia por onde o atacante força, e quase nada em verificar quem pede o dado pela porta que a própria empresa mantém aberta.