Identidade de máquina: contas de serviço, tokens e chaves

O funcionário pediu demissão numa sexta. Na segunda, o time de TI desativou a conta dele em três minutos: e-mail bloqueado, sessões revogadas, crachá recolhido, checklist assinado.

O token que ele gerou dois anos antes, para uma integração entre o sistema de pedidos e a planilha do financeiro, continua válido. Ninguém sabe que ele existe. Ele não está no checklist porque não é dele — é de uma máquina.

Essa é a assimetria que define o problema da identidade de máquina: toda empresa tem um processo razoável para admitir e desligar pessoas, e quase nenhuma tem processo para o que essas pessoas criam.

A tese em uma frase: identidade de máquina não é um problema técnico novo, é um problema de ciclo de vida — ela nasce sem dono, não expira, não aparece no desligamento e supera as humanas em ordem de grandeza, o que significa que o seu programa de identidade cobre hoje a menor parte da superfície.

O tamanho do problema de identidade de máquina

O levantamento da CyberArk sobre identidades de máquina (2025) mediu uma proporção de mais de 80 identidades de máquina para cada identidade humana. Em ambientes nativos de nuvem, passa de 140 para 1. A população cresceu 44% em um ano, e quase metade dessas identidades tem acesso sensível ou privilegiado.

A ressalva honesta, do mesmo tipo que faço com qualquer número de fornecedor: quem publicou vende proteção de identidade de máquina. O incentivo existe. Mas a ordem de grandeza bate com o que aparece ao inventariar qualquer ambiente com nuvem, integração e automação — e a diferença entre 80 e 40 para 1 não muda nenhuma decisão.

O que muda a decisão é outra conta. Se o seu programa de identidade cobre MFA, senha forte e desligamento — tudo voltado a pessoas —, ele está cuidando de pouco mais de 1% das credenciais que existem na empresa.

Por que elas escapam do controle

Quatro razões, e nenhuma é preguiça do time.

Nascem no meio de outra tarefa. Ninguém acorda decidindo criar uma conta de serviço. Alguém precisa entregar uma integração até sexta, gera uma chave, cola no script e segue. A credencial é meio, não fim — e meios não entram em checklist.

Não têm dono registrado. Identidade humana tem nome, gestor e centro de custo. A chave api-integracao-financeiro tem, no máximo, um comentário no código.

Não expiram. Senha de pessoa vence, exige troca, dispara lembrete. Token costuma nascer sem validade, porque validade quebra automação — e quebrar automação é problema imediato, enquanto credencial eterna é problema futuro.

Não saem quando a pessoa sai. O desligamento olha para o que a pessoa acessava, nunca para o que ela criou. E o que ela criou continua autenticando normalmente, com permissões que ninguém revisou.

Os cinco lugares onde a identidade de máquina mora

Este é o inventário mínimo. Se você olhar só esses cinco, já encontra a maioria.

A quarta linha merece atenção especial. Integração de SaaS autorizada com a conta pessoal de alguém é frágil nos dois sentidos: se a conta é desativada, a integração quebra; se não é, o acesso continua. As duas situações são ruins, e as duas são comuns — o DBIR 2026 da Verizon registrou terceiros envolvidos em 48% das violações, com integrações autorizadas entre os caminhos explorados.

O elo que quebra: rotação

Das quatro etapas do ciclo, a terceira é a que quase nunca acontece — e é fácil entender por quê.

Rotacionar uma chave significa trocá-la em todos os lugares onde ela é usada. Se ninguém sabe onde ela é usada, rotacionar é sortear qual sistema vai parar. Então adia-se. E, como adiar não dói hoje, adia-se de novo.

A saída não é começar pela rotação. É inverter a ordem: primeiro descobrir onde cada credencial é usada e quem responde por ela; depois estabelecer validade. Uma credencial com dono e mapa de uso pode ser rotacionada num horário combinado. Uma credencial órfã só é rotacionada por acidente, normalmente durante um incidente.

Vale notar que o roubo de credencial já é um mercado maduro, com malware dedicado a coletar o que está salvo na máquina — assunto de infostealer. Chave em texto puro dentro de um script é exatamente o tipo de item que esse malware leva.

O que dá para fazer nesta semana

Nada aqui exige compra, e é por isso que cabe cedo na fila do orçamento de segurança.

1. Liste as identidades privilegiadas no diretório e na nuvem. Só as privilegiadas. A lista costuma ser menor do que o medo e maior do que a expectativa.
2. Rode uma varredura de segredo no repositório, incluindo o histórico. Chave removida num commit continua acessível no anterior.
3. Atribua dono a cada item encontrado. Pessoa, não time — time não recebe alerta.
4. Adicione uma linha ao desligamento: o que esta pessoa criou, e o que fazemos com cada item.
5. Defina validade para credenciais novas. Não vale para as antigas ainda; vale para tudo que nascer a partir de agora.

O quinto item é o que interrompe o crescimento do problema. Os quatro primeiros lidam com o passivo.

O acelerador novo: agentes e integrações

Vale registrar para onde isso está indo, porque a curva ficou mais íngreme.

Cada agente de IA que age em sistemas precisa de credencial própria. Cada servidor MCP conectado a uma ferramenta interna também. E essas credenciais nascem, quase sempre, com permissão ampla — porque restringir dá trabalho, e no piloto ninguém quer descobrir qual permissão faltou.

O resultado é uma população nova de identidades de máquina privilegiadas, criada por equipes que não são de segurança, em velocidade maior do que qualquer inventário manual acompanha. É o risco de sempre, com prazo menor. E é mais um motivo para o princípio de menor privilégio deixar de ser slide e virar configuração, como já discuti em Zero Trust.

O ponto que fica

Identidade humana é um problema resolvido o suficiente: MFA barato, gerenciador de senha acessível, desligamento com checklist. É a parte fácil, e é onde quase todo o esforço está concentrado.

A identidade de máquina é a maioria silenciosa da superfície de ataque: sem dono, sem prazo, sem checklist e com permissão herdada de uma urgência antiga. Ela não vai aparecer em painel nenhum até o dia em que aparecer no relatório de um incidente.

A pergunta de verificação, e ela é desconfortável de propósito: qual foi a última credencial de sistema que a sua empresa revogou — e ela foi revogada por decisão ou porque alguém foi embora?