Identidades não-humanas: o ponto cego do CI/CD e das máquinas

Peça para qualquer time de segurança listar quantos usuários humanos existem no ambiente corporativo e, em minutos, alguém traz um número razoavelmente preciso. Peça o mesmo sobre chaves de API, service accounts, tokens de integração e credenciais de automação, e a resposta costuma ser silêncio — ou um número que todo mundo sabe estar errado.

Identidades não-humanas já são maioria em ambientes modernos: cada serviço, pipeline, integração e agente automatizado carrega uma credencial própria. E, ao contrário de um usuário humano, elas raramente passam por MFA, revisão periódica de acesso ou desligamento quando deixam de ser necessárias.

Por que esse ponto cego existe

Programas de identidade corporativa foram construídos, historicamente, em torno de pessoas: contratação, mudança de cargo, desligamento. Máquinas não seguem esse ciclo — uma chave de API criada para um projeto pontual pode continuar ativa anos depois, com o mesmo nível de privilégio, sem ninguém revisando se ainda é necessária.

Some a isso o fato de que identidades de máquina normalmente vivem fora da governança de identidade humana — em cofres de segredos diferentes, em pipelines de CI/CD, em variáveis de ambiente — e o resultado é um universo de credenciais de alto privilégio sem dono claro nem ciclo de vida definido.

O risco concreto de deixar isso sem controle

Uma credencial de máquina comprometida costuma ter privilégio mais amplo e vida mais longa do que uma senha humana comprometida — exatamente o perfil que um atacante procura para se mover lateralmente sem ser detectado. E como poucas dessas credenciais têm MFA ou monitoramento comportamental, o abuso pode passar despercebido por muito tempo.

Casos de vazamento de segredos em repositórios de código público, pipelines expostos e integrações mal configuradas seguem entre as causas mais recorrentes de incidentes reportados pelo setor — muitas vezes a mesma porta de entrada explorada em ataques de supply chain de software — não por sofisticação do ataque, mas por ausência de controle básico sobre esse tipo de identidade.

O que uma governança madura de identidade não-humana exige

O ponto de partida é o mesmo de qualquer programa de identidade: inventário. Sem saber quantas credenciais de máquina existem, onde vivem e o que podem acessar, não há priorização possível. A partir daí, três práticas concentram a maior parte do valor: rotação automática de segredos, escopo de privilégio mínimo por credencial, e monitoramento de uso anômalo — um token que sempre acessou o mesmo recurso, no mesmo horário, e de repente muda de padrão, é sinal de alerta.

CIEM (cloud infrastructure entitlement management) e plataformas de gestão de segredos cobrem boa parte dessa camada, mas exigem integração real com os pipelines onde essas identidades nascem — não adianta um cofre de segredos que ninguém no time de engenharia efetivamente usa. Essa é a mesma lógica de identidade como novo perímetro aplicada a máquinas em vez de pessoas.

Um exercício simples que revela o tamanho do problema

Um jeito rápido de dimensionar a exposição real é perguntar: quantas credenciais de máquina, hoje, têm acesso irrestrito a dados de produção, e há quanto tempo cada uma foi criada sem revisão desde então? Na maioria das empresas que fazem esse exercício pela primeira vez, o número surpreende — e normalmente aponta para credenciais criadas por projetos que já terminaram, mas cujo acesso nunca foi revogado.

Esse é o tipo de achado que justifica tratar identidade de máquina com a mesma prioridade orçamentária e de atenção executiva que já se dá à identidade humana — não como um item técnico secundário dentro do time de plataforma.

Extensão da mesma arquitetura

A UNIQ trata identidade não-humana como extensão natural da arquitetura de Identity & Access — não como projeto separado — e ajuda a priorizar onde a exposição de credenciais de máquina representa o maior risco real no ambiente do cliente.