Olá a todos, sou Pat Reeves, ao vivo do bunker de botsec.net. A data de hoje é 31 de março de 2026, e nos últimos dias tenho pensado muito sobre como gerenciamos as identidades dos nossos bots. Não de uma maneira filosófica do tipo “quem sou eu?”, mas de uma forma muito prática: “quem é este bot e por que ele está autorizado a fazer isso?”.
Em particular, quero falar sobre autenticação bot-to-bot e as evidentes falhas que estou observando no mundo real. Temos avançado muito desde que inseríamos as chaves de API de forma hardcoded em cada script, graças aos céus. Mas mesmo com as práticas modernas, existe um persistente e insidioso padrão do “bom o suficiente” que nos está preparando para sérias dores de cabeça no futuro.
A Armadilha do “Bom o Suficiente”: Por Que Sua Autenticação Bot-to-Bot Provavelmente é Mais Fraca do Que Você Pensa
Na semana passada, estive em uma chamada com uma startup que estava empolgada com a arquitetura de microserviços deles. Eles tinham dezenas de bots, todos se comunicando, fazendo seu trabalho. E quando perguntei sobre a estratégia deles de autenticação bot-to-bot, o desenvolvedor principal declarou orgulhosamente: “Oh, estamos usando JWTs e contas de serviço!”.
Parece ótimo no papel, certo? Os JSON Web Tokens são um padrão da indústria, as contas de serviço são um passo à frente em relação ao acesso root. Mas quando fomos mais a fundo, ficou claro que a implementação deles era… digamos, mais porosa do que uma peneira.
Esse é o ponto: muitas equipes tratam a autenticação bot-to-bot como um item de uma lista de verificação. “Estamos usando tokens? Marcado. Estamos usando contas de serviço? Marcado.” Eles não pensam realmente nos vetores de ataque que um ator malicioso usaria para se passar por ou comprometer um de seus bots.
E é aqui que a armadilha do “bom o suficiente” o atinge. É a diferença entre ter uma fechadura na porta e ter uma fechadura que pode ser aberta com um clipe de papel.
A Conta de Serviço Muito Permissiva: Um Erro Clássico
Essa é provavelmente a vulnerabilidade mais comum que encontro. Você cria uma conta de serviço para o Bot A, que precisa ler dados do Bot B. Então, quais permissões você concede à conta de serviço do Bot A? Frequentemente é algo como `read:*` ou até mesmo `admin:*` dentro do escopo do Bot B.
Por quê? Porque é mais fácil. Evita problemas de permissões detalhadas e “simplesmente funciona”. Mas pense nas implicações. Se um atacante comprometer o Bot A (digamos, através de uma dependência vulnerável ou uma variável de ambiente mal configurada), agora ele herda todas as permissões do Bot A. Se o Bot A tem acesso `admin:*` ao Bot B, então o atacante também controla o Bot B. É um sonho de movimentação lateral para um adversário.
Vi isso acontecer com um cliente no ano passado. O bot de “ingestão de dados” deles tinha acesso de leitura/gravação a praticamente todo o seu banco de dados interno porque, “às vezes ele precisa atualizar os flags.” Quando esse bot foi comprometido através de um endpoint interno exposto, os atacantes tiveram um campo livre, não apenas exfiltrando dados, mas também injetando registros maliciosos que causaram falhas nos sistemas a jusante por dias.
Tokens de Longa Duração, Emitidos Estaticamente: Uma Bomba Relógio
Outro padrão comum: gerar um JWT ou uma chave de API para um bot, e depois inseri-lo diretamente na sua configuração ou nas variáveis de ambiente. E esses tokens? Frequentemente têm datas de expiração medidas em meses ou, às vezes, nenhuma expiração.
Isso equivale a dar ao seu bot uma chave física e permanente para um cofre. Se essa chave for exposta – por meio de um arquivo de configuração vazado, um pipeline CI/CD comprometido, ou até mesmo um distraído `echo $TOKEN` durante o debug – está acabado até que você troque manualmente. E com que frequência você realmente troca esses tokens estáticos de longa duração?
Uma empresa com que trabalhei tinha toda a comunicação interna entre microserviços protegida por uma única chave de API nunca expirada para cada serviço. Essas chaves eram armazenadas em texto simples no repositório Git deles (um privado, por sorte, mas ainda assim). Quando um novo desenvolvedor se juntava, ele clonava o repositório e tinha imediatamente acesso a cada serviço interno. “É só para desenvolvimento interno,” afirmavam eles. Até que um dia, um ex-funcionário descontente decidiu explorar o acesso que ainda tinha.
Além do “Bom o Suficiente”: Passos Práticos para uma Autenticação Bot-to-Bot Segura
Então, como podemos superar essas armadilhas comuns? Não é ciência de foguetes, mas requer uma mudança de mentalidade de “marcar a caixa” para “minimizar ativamente o risco.”
1. Implemente o Princípio do Mínimo Privilégio, Sempre
Este não é um conselho novo, mas é de vital importância para a comunicação bot-a-bot. Cada conta de serviço ou identidade de um bot deve ter o mínimo absoluto de permissões necessárias para realizar sua função específica, e nada mais.
Em vez de `read:*`, especifique `read:users`, `read:orders`, e apenas se absolutamente necessário, `write:order_status` para um campo específico. Isso torna o trabalho do atacante muito mais difícil. Mesmo que comprometam o Bot A, seu alcance é consideravelmente reduzido porque o Bot A tem acesso apenas a um conjunto muito restrito de recursos.
Aqui está um exemplo simplificado de como você poderia definir uma política IAM detalhada para um bot que deve apenas ler os dados dos clientes:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::my-customer-data-bucket/customers/*"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:Query"
],
"Resource": "arn:aws:dynamodb:REGION:ACCOUNT_ID:table/customer_profiles"
}
]
}
Note quão específicas são as ações e os recursos. Isso não é um blanket `s3:*` ou `dynamodb:*`. É um conjunto de permissões direcionadas.
2. Abrace Credenciais de Curto Prazo, Emitidas Dinamicamente
Esta é provavelmente a mudança única mais impactante que você pode fazer. Em vez de codificar tokens de longa duração, faça com que seus bots solicitem credenciais de curto prazo de um provedor de identidade centralizado (IdP) justo antes de precisarem executar uma ação.
Pense nos papéis IAM na nuvem (como os papéis IAM da AWS para instâncias EC2 ou as contas de serviço Kubernetes com IRSA). Seu bot (executando em uma instância EC2 ou em um pod K8s) assume um papel e o provedor de nuvem emite dinamicamente credenciais temporárias que são válidas por um breve período (ex. 15 minutos a uma hora). Essas credenciais são automaticamente atualizadas, então o bot sempre tem acesso válido sem que você precise tocar em um token estático.
Se um atacante comprometer o bot, ele tem acesso apenas por um tempo muito limitado. Uma vez que as credenciais temporárias expirarem, seu acesso é revogado, a menos que consiga re-autenticar-se. Isso restringe consideravelmente a janela de oportunidade para um atacante.
Para sistemas internos que não rodam diretamente em infraestrutura de nuvem, você pode implementar esquemas semelhantes usando ferramentas como HashiCorp Vault ou até mesmo um serviço de identidade personalizado que emite JWT ou chaves de API temporárias que são assinadas e validadas.
Aqui está um fluxo conceitual para credenciais emitidas dinamicamente:
- O Bot A inicia, autentica-se em um IdP usando um mecanismo seguro específico para a plataforma (ex. metadados da instância, token da conta de serviço Kubernetes).
- O IdP verifica a identidade do Bot A e emite um token de acesso de curto prazo para um escopo específico (ex. 15 minutos, permissão para chamar o endpoint `/read-metrics` do Bot B).
- O Bot A usa esse token para chamar o Bot B.
- Antes que o token expire, o Bot A solicita um novo token ao IdP.
- Se o Bot A for comprometido, o atacante tem acesso apenas pelo tempo restante de validade do token.
3. Segurança do Seu Provedor de Identidade
Isso pode parecer óbvio, mas vale a pena dizer: seu IdP é a joia da coroa. Se um atacante comprometer seu IdP, ele pode se passar por qualquer bot e emitir credenciais à vontade. Certifique-se de que seu IdP esteja reforçado, monitorado e siga as melhores práticas de segurança (MFA para acesso humano, isolamento rigoroso da rede, auditorias regulares, etc.).
4. Implemente TLS Mutual (mTLS) para Comunicações Sensíveis
Para comunicações críticas bot-a-bot, especialmente em redes que você não controla totalmente, considere usar mTLS. Com mTLS, tanto o bot cliente quanto o bot servidor apresentam certificados um ao outro e verificam suas identidades antes de estabelecer uma conexão.
Isso fornece uma autenticação bidirecional: não apenas o servidor sabe quem é o cliente, mas o cliente também sabe que está falando com o servidor legítimo, prevenindo ataques man-in-the-middle e impersonificação.
Ferramentas como Istio, Linkerd, ou até mesmo Nginx com autenticação via certificados de cliente podem te ajudar a implementar mTLS sem precisar reescrever todo o seu código de aplicativo. Por exemplo, se você está executando serviços no Kubernetes com Istio, pode ativar o mTLS com algumas linhas de YAML:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: my-bot-services
spec:
mtls:
mode: STRICT
Isso força todos os serviços no namespace `my-bot-services` a se comunicarem utilizando mTLS, presumindo que sua service mesh esteja configurada corretamente.
Ações Práticas para a Sua Auditoria de Segurança dos Bots
Ok, vamos concluir com algumas ações concretas que você pode tomar a partir de hoje para fortalecer sua autenticação bot-to-bot:
- Faça um Inventário dos Seus Bots e Seus Permissões: Você sabe quais bots possui e exatamente quais recursos podem acessar? Crie uma planilha, use uma ferramenta de gerenciamento de configuração, qualquer coisa que funcione. Obtenha uma visão clara.
- Revise as Políticas das Contas de Serviços: Para cada bot, avalie criticamente suas permissões. Você pode reduzi-las? Você pode torná-las mais detalhadas? Aplique rigorosamente o princípio do menor privilégio.
- Identifique os Tokens de Longa Duração: Escaneie seu código-fonte e as configurações em busca de chaves API estáticas e de longa duração ou JWT. Dê prioridade a substituí-los por credenciais de curta duração emitidas dinamicamente.
- Explore os Papéis IAM na Nuvem / Provedor de Identidade: Se você está em uma plataforma de nuvem, certifique-se de usar totalmente seus papéis IAM nativos para emissão dinâmica de credenciais. Se não estiver, pesquise soluções como HashiCorp Vault.
- Considere mTLS para Caminhos Críticos: Identifique suas comunicações bot-to-bot mais sensíveis e explore a implementação de TLS mútuo para melhor autenticação e criptografia.
- Planeje a Rotação das Credenciais: Mesmo com credenciais dinâmicas, você tem um plano para como girar as chaves raiz para o seu IdP ou os certificados para mTLS.
Não caia na armadilha do “bom o suficiente”. Seus bots são frequentemente a força de trabalho invisível da sua infraestrutura e sua segurança é fundamental. Seguindo esses passos, você não está apenas marcando uma caixa; está construindo um verdadeiro ecossistema de bots robusto e seguro. Fique seguro por aí e mantenha esses bots sob controle!
🕒 Published: