Na madrugada de 17 de setembro, 520 transferências Pix saíram de depósitos judiciais vinculados ao Tribunal de Justiça da Bahia. Entre 6h10 e 10h10, R$ 53,1 milhões mudaram de lugar.

O ataque não aconteceu no tribunal. Aconteceu na plataforma BRBJUS, do Banco de Brasília. O TJ-BA informou que o incidente ocorreu integralmente em ambiente tecnológico externo ao tribunal, sob administração exclusiva do banco, e que as credenciais envolvidas eram geridas pelo BRB.

A principal hipótese do banco é que o ataque envolveu o uso indevido de um certificado digital somado à exploração de uma interface do sistema. Ou seja: não foi uma porta arrombada. Foi uma chave legítima usada por quem não deveria.

Tudo isso é verdade. E não mudou nada para quem dependia daquele dinheiro.

É aí que o caso deixa de ser notícia sobre banco e vira pergunta sobre a sua operação.

Quantos fornecedores têm acesso à sua rede agora?

A resposta honesta da maioria dos gestores de TI é: não sei exatamente.

Não é desleixo. É acúmulo. Cada projeto de implantação, cada migração, cada contrato de suporte deixou um acesso para trás. O integrador que configurou o ERP há cinco anos precisou de uma VPN. A consultoria que fez a migração para a nuvem criou um usuário administrativo. O fornecedor do CRM pediu uma conta de serviço para a integração funcionar.

Cada um desses acessos foi criado por um motivo legítimo, aprovado por alguém, e nunca mais revisado.

O que encontramos quando assumimos um ambiente

Todo contrato novo da Strati começa com um assessment de segurança. Antes de operar, mapeamos o que existe.

Em 9 de cada 10 ambientes avaliados, encontramos pelo menos um acesso de terceiro ativo que o cliente não sabia que existia.

Não é um acesso irregular, criado por invasor. É um acesso legítimo, criado por alguém da própria empresa, que continuou funcionando depois que o projeto acabou, o contrato venceu ou a pessoa responsável saiu.

Nove em cada dez. A pergunta não é se existe um na sua rede. É quantos.

Dados levantados por William Lima, CISO da Strati, a partir dos assessments de onboarding conduzidos pela equipe de segurança.

Onde esses acessos se escondem

Nos ambientes que avaliamos, o acesso de terceiro aparece em sete lugares. Raramente em um só.

VPN. O caminho clássico. Criada para o integrador trabalhar durante a implantação e mantida depois, porque desligar dava trabalho e alguém podia precisar. Costuma ser o acesso mais amplo de todos — entra na rede inteira, não num sistema específico.

ERP. Usuário de suporte do fornecedor, com permissão alta porque suporte precisa enxergar tudo. Em muitos casos é uma conta compartilhada entre vários técnicos do fornecedor, o que elimina qualquer rastreabilidade de quem fez o quê.

CRM. Mesma lógica do ERP, com o agravante de que ali estão os dados comerciais e a base de clientes — material de valor direto para quem quiser revender.

Bancos de dados. Acesso concedido para uma migração, uma integração ou um relatório específico. Permanece ativo porque ninguém lembra que foi criado, e porque bancos de dados raramente entram na revisão de acessos.

Usuários do Active Directory. Contas de serviço e usuários nominais de prestadores que continuam habilitados. O AD é o centro da identidade corporativa: um usuário esquecido ali é chave de entrada para tudo que confia nele.

Microsoft 365. Licenças de prestadores que continuam ativas, acesso a SharePoint e OneDrive, e aplicativos de terceiros com consentimento concedido por algum administrador que já não está na empresa.

Nuvem pública. Chaves de API, usuários de console e papéis de acesso criados durante projetos de infraestrutura. É o caso mais perigoso dos sete, porque ali o acesso frequentemente permite criar, destruir e expor recursos inteiros.

O padrão por trás da lista

Repare que esses sete pontos não têm nada de exótico. São exatamente os sistemas mais importantes de qualquer operação de médio porte.

Isso não é coincidência. O acesso de terceiro existe justamente onde o fornecedor precisava trabalhar — e fornecedor é contratado para mexer no que é crítico. O risco se concentra, por construção, no pior lugar possível.

E há uma assimetria incômoda: a sua empresa aplica política de senha, MFA e revisão periódica aos próprios funcionários. Ao acesso do fornecedor, aplica um contrato.

Quatro horas e 520 transferências

Volte ao caso. O que mais chama atenção não é o valor, é o relógio.

As transferências começaram às 6h10 e foram contidas às 10h10. Quatro horas. Nesse intervalo, 520 operações saíram em sequência.

Quinhentas e vinte operações consecutivas, de madrugada, fora do padrão de qualquer dia normal. Não é um evento sutil escondido no meio do ruído. É uma anomalia gritante que permaneceu quatro horas sem ser interrompida.

Regra estática não pega isso

A maioria dos controles de segurança funciona por regra: se acontecer X, bloqueie. Valor acima de determinado limite, destino em lista restrita, horário proibido.

Regra é útil e necessária. Mas tem uma limitação estrutural: ela só enxerga o que alguém imaginou antes. Transferências dentro do limite permitido, para destinos não listados, por um usuário autorizado, não acionam nada — individualmente.

O que denuncia o ataque não é nenhuma transferência isolada. É o padrão: o volume, a sequência, o horário, a repetição.

Detecção por desvio de comportamento parte de outra pergunta. Em vez de “isso é proibido?”, ela pergunta “isso é normal para este usuário, neste sistema, neste horário?”. Quinhentas e vinte operações em quatro horas de madrugada responde não na quinquagésima, não na quingentésima.

A pergunta que vale fazer internamente

Pegue o sistema mais crítico da sua operação. Se um usuário legítimo começasse a fazer, hoje de madrugada, dez vezes mais operações do que faz num dia normal — alguém seria avisado?

Se a resposta for “depende de alguém olhar o relatório amanhã”, você tem detecção por regra, não por comportamento.

E repare: essa pergunta não é sobre o fornecedor. É sobre o que você consegue enxergar dentro de casa quando um acesso legítimo passa a se comportar de forma ilegítima. É exatamente o cenário de um acesso de terceiro comprometido.

O que fazer, na ordem

Nada aqui exige projeto ou orçamento novo. Exige decidir que alguém é dono do assunto.

1. Levante o inventário. Liste todo acesso de terceiro ativo nos sete pontos: VPN, ERP, CRM, bancos de dados, Active Directory, Microsoft 365 e nuvem pública. Para cada um, registre quem é o fornecedor, quem aprovou, quando foi criado e por quê.

Esse primeiro passo costuma ser o mais desconfortável — e o mais revelador. Em nove de cada dez vezes, aparece algo que ninguém sabia.

2. Elimine o que não tem dono. Acesso sem responsável identificável e sem justificativa atual deve ser desativado, não documentado. Se alguém reclamar, você descobriu o dono. Se ninguém reclamar em trinta dias, remova em definitivo.

3. Reduza o que sobrou. Todo acesso que permanecer precisa de três coisas: permissão mínima para a função, usuário nominal em vez de conta compartilhada, e prazo de validade. Acesso de fornecedor deveria expirar por padrão e ser renovado por decisão, não o contrário.

4. Exija MFA, inclusive do fornecedor. É a medida de maior efeito pelo menor esforço. Credencial de terceiro vazada é um dos caminhos mais comuns de entrada, e o segundo fator interrompe quase todos eles.

5. Monitore comportamento, não só regra. Para os sistemas críticos, estabeleça o que é normal e configure alerta para o desvio. Volume fora do padrão, horário atípico, acesso a dados que aquele usuário nunca acessou.

6. Coloque na agenda. Revisão trimestral de acessos de terceiro, com responsável nomeado. Sem recorrência, o inventário volta a envelhecer no dia seguinte.

Contrato não é controle

Vale separar duas coisas que costumam ser confundidas.

Cláusula contratual define quem responde pelo prejuízo. É necessária e o jurídico deve cuidar dela.

Controle técnico define se o prejuízo acontece. É outra conversa, e é a sua.

No caso do TJ-BA, a delimitação de responsabilidade estava clara: ambiente do banco, credenciais do banco. Isso não devolveu o dinheiro nem evitou o desgaste público. Responsabilidade atribuída não é risco mitigado.

Terceirizar a operação é legítimo. Terceirizar a responsabilidade, não.

Nenhuma empresa de médio porte opera sozinha. Depender de fornecedor para ERP, folha, nuvem e suporte é decisão de negócio correta — concentra a equipe interna no que é estratégico.

O erro não está em terceirizar a operação. Está em achar que, junto com ela, foi terceirizado o risco.

O acesso continua apontando para dentro da sua rede. O dado continua sendo seu. E quando algo dá errado, quem explica para a diretoria é você.

É por isso que, na Strati, todo contrato começa por um assessment. Não para apontar o que está errado e devolver a lista — para saber o que existe antes de assumir a responsabilidade de proteger.

Quer saber quantos acessos de terceiro existem hoje no seu ambiente? É a primeira coisa que mapeamos. Fale com a Strati e comece pelo assessment.