Identidades não humanas (NHI): o risco que o seu IAM não enxerga
Quando uma pessoa sai da empresa, o processo é conhecido: o RH registra o desligamento, o IAM desativa a conta e o acesso desaparece. Agora faça outra pergunta: quando foi a última vez que alguém desativou a conta de serviço que essa mesma pessoa criou?
Para a maioria das organizações, a resposta é “nunca” ou “não sei”. E é nesse espaço que moram as identidades não humanas.
O que são identidades não humanas
Uma identidade não humana (NHI, do inglês non-human identity) é qualquer identidade que não representa uma pessoa e que se autentica para acessar algo. Em ambientes de nuvem, desenvolvimento e integração, é comum haver mais identidades desse tipo do que de pessoas.
Tipo | O que é | Exemplo | Credencial típica |
Conta de serviço | Conta usada por um sistema, não por uma pessoa | Conta de banco usada pela aplicação de relatórios | Senha ou chave |
Chave de API e token | Credencial que autoriza uma aplicação a chamar outra | Integração entre CRM e plataforma de e-mail | Texto fixo, muitas vezes sem validade |
Aplicação registrada (service principal) | Identidade de uma aplicação no provedor de identidade ou na nuvem | App registrada no Entra ID ou service account no GCP | Segredo de cliente ou certificado |
Chave de acesso de nuvem | Par de chaves para usar a API da nuvem | Access key de um usuário técnico na AWS | Chave de longa duração |
Identidade de workload | Identidade atribuída a um serviço em execução | Role de função serverless, managed identity | Token de curta duração emitido pela plataforma |
Pipeline e bot | Automação que faz deploy ou integra sistemas | Pipeline de CI/CD, bot de chat | Segredo guardado no pipeline |
Agente de IA | Software autônomo que age com credenciais | Assistente com acesso a e-mail e documentos | Token delegado ou credencial própria |
Por que o IAM tradicional não as enxerga
IAM nasceu para governar pessoas, e quase tudo nele parte do RH. As NHIs quebram essa lógica de seis maneiras:
Não nascem no RH. Não existe admissão, movimentação ou desligamento que dispare o ciclo de vida de uma chave de API.
São criadas por quem precisa, não por quem governa. Quem cria costuma ser a pessoa de desenvolvimento, infraestrutura ou o fornecedor do SaaS, no meio de uma entrega.
Ficam sem dono. A pessoa mudou de time ou saiu, o projeto terminou, e a credencial continua válida.
Não fazem MFA. Quem possui o segredo é a identidade. Se o segredo vaza, não existe segundo fator para barrar.
Ficam fora das campanhas de revisão de acessos. A certificação costuma cobrir pessoas e papéis, não contas de serviço.
Os segredos vivem em lugares errados. Repositórios de código, wikis, tickets, variáveis de ambiente e planilhas.
Um caso público: a credencial que ninguém lembrou de trocar
Em novembro de 2023, a Cloudflare publicou o relato de um incidente em que um invasor acessou seus sistemas Atlassian (Jira, Confluence e Bitbucket). O acesso se deu com um token e três credenciais de contas de serviço que tinham vazado em um incidente anterior na Okta, em outubro de 2023, e que a empresa não chegou a trocar, entre milhares que foram renovadas. cloudflare
O detalhe mais instrutivo é o motivo: as credenciais não foram trocadas porque se acreditou, por engano, que não estavam em uso. Entre elas havia um token de serviço de uma integração de terceiro que dava acesso remoto ao Atlassian, uma conta de serviço de um SaaS com acesso administrativo ao Jira e uma conta de serviço do Bitbucket. Depois do incidente, a empresa precisou trocar mais de 5.000 credenciais de produção.
Não houve falha de MFA nem de senha de pessoa. Houve identidades não humanas esquecidas, ligadas a integrações de terceiros e com privilégio alto. É o retrato de como esse risco aparece na prática.
Os riscos mais comuns segundo o OWASP
Em 2025, o OWASP publicou seu primeiro Top 10 dedicado a esse tema. A lista começa por desligamento inadequado e vazamento de segredos, e inclui NHIs de terceiros vulneráveis, autenticação insegura, privilégio excessivo, configurações inseguras de nuvem, segredos de longa duração, falta de isolamento entre ambientes, reuso de NHI e uso humano de NHI. Cinco deles aparecem em quase toda auditoria: owasp
Desligamento inadequado: a conta ou a chave sobrevive ao projeto, ao fornecedor ou à pessoa que a criou.
Vazamento de segredos: chaves que aparecem em repositórios, tickets e conversas.
Privilégio excessivo: permissões amplas “só para funcionar”, que nunca são reduzidas.
Segredos de longa duração: chaves que não expiram e nunca são trocadas.
Reuso: a mesma credencial em vários serviços e ambientes, de modo que um vazamento atinge todos.
O último item da lista, o uso humano de NHI, merece atenção própria. Quando alguém entra com uma conta de serviço para fazer uma consulta “rápida”, a rastreabilidade acaba: o log mostra o sistema, não a pessoa.
O ciclo de vida de uma NHI
A resposta é tratar cada NHI com o mesmo rigor de uma pessoa, adaptado à realidade delas:
Descobrir. Montar um inventário a partir da nuvem, do provedor de identidade, dos repositórios, dos SaaS e dos pipelines.
Atribuir dono. Todo item tem um responsável nomeado, um time e um sistema associado. Sem dono, a credencial não é renovada.
Justificar e limitar. Registrar a finalidade, reduzir ao privilégio mínimo e restringir a origem (rede, ambiente, serviço).
Substituir segredo fixo por credencial temporária, sempre que a plataforma permitir.
Rotacionar e expirar. Definir um prazo máximo de vida e automatizar a troca.
Monitorar e revisar. Acompanhar o uso, alertar sobre acessos fora do padrão e pedir ao dono, periodicamente, que confirme a necessidade.
Desligar. Quando o projeto ou o contrato acaba, desativar, observar por uma janela curta e só então remover.
O caso da Cloudflare mostra o cuidado necessário no passo 7: nunca presuma que uma credencial está sem uso. Verifique nos logs e, se houver dúvida e a credencial já tiver circulado, troque.
Do segredo estático à identidade de workload
A melhor credencial é a que não existe. Em vez de guardar uma chave dentro de um pipeline ou de uma aplicação, o workload prova quem é por meio de um documento de identidade assinado, emitido pela plataforma onde ele roda, e recebe uma credencial temporária. Não há chave para vazar nem rotação manual, e o log aponta qual workload agiu.
Isso pode ser feito de três formas, conforme o ambiente:
Federação OIDC com a nuvem: o pipeline obtém um token assinado e o troca por uma credencial temporária na AWS, no Azure ou no Google Cloud. É o caminho mais simples para pipelines de CI/CD.
Identidades gerenciadas da plataforma: managed identities no Azure, roles no IAM da AWS e workload identity no Google Cloud e no Kubernetes. Servem para serviços que já rodam dentro de uma nuvem.
SPIFFE e SPIRE: o SPIFFE (Secure Production Identity Framework for Everyone) é um padrão aberto que atribui a cada serviço um identificador e um documento assinado de curta duração, emitido depois que o ambiente verifica que o workload é legítimo. O SPIRE é a implementação mais usada. É a opção quando há vários ambientes (várias nuvens, Kubernetes, datacenter) e se quer o mesmo modelo de identidade em todos, inclusive para autenticação entre serviços.
Uma ordem de prioridade que funciona:
Eliminar o segredo: adotar uma das três formas acima. Comece pela mais simples para o seu ambiente: federação OIDC para pipelines, identidade gerenciada para serviços dentro da nuvem e SPIFFE quando houver vários ambientes para padronizar.
Se não for possível, guardar em cofre com rotação automática.
Em último caso, manter o segredo fixo, mas com dono, escopo mínimo e prazo de validade registrado.
Sistemas legados nem sempre aceitam a primeira opção, e tudo bem. O importante é saber quais são eles e decidir de forma consciente.
Checklist dos primeiros 30 dias
Semana 1: enxergar
Listar contas de serviço, aplicações registradas e chaves de nuvem.
Procurar segredos expostos nos repositórios de código.
Semana 2: responsabilizar
Atribuir um dono a cada item e marcar quais têm privilégio administrativo.
Identificar as credenciais sem uso recente, olhando os logs em vez de confiar na memória do time.
Semana 3: reduzir risco
Desativar o que está claramente sem uso, com janela de observação antes de remover.
Reduzir o escopo das mais privilegiadas e restringir a origem de uso.
Semana 4: criar processo
Definir uma política mínima: dono obrigatório, prazo de vida e rotação.
Incluir as NHIs no checklist de desligamento de pessoas e de encerramento de projetos.
Escolher um pipeline e migrá-lo para federação de workload, para servir de modelo.
Cinco erros comuns
Tratar NHI como assunto só do cofre de senhas. O cofre ajuda, mas não resolve dono, privilégio nem desligamento.
Fazer o inventário uma vez e arquivar. Novas NHIs surgem toda semana.
Rotacionar sem inventário. A troca derruba uma integração que ninguém sabia que existia.
Exigir MFA de todos e esquecer dos tokens. O controle fica forte onde o atacante não precisa passar.
Deixar pessoas usarem contas de serviço. Isso apaga a trilha de auditoria.
Conclusão
A gestão de IAM de pessoas está maduro: existe processo, ferramenta e auditoria. IAM de identidades não humanas ainda não está na maioria das empresas, e é por onde os incidentes mais discretos acontecem. Comece pelo que é possível em 30 dias: inventário, dono e redução de privilégio.
Para receber os próximos conteúdos, assine a newsletter e consulte o Glossário IAM. No próximo texto, falamos de OAuth, OIDC, SAML e SCIM, a base para entender como essas identidades se autenticam.
Referências
OWASP, Non-Human Identities Top 10 (2025): https://owasp.org/www-project-non-human-identities-top-10/
Cloudflare, Thanksgiving 2023 security incident: https://blog.cloudflare.com/thanksgiving-2023-security-incident
BleepingComputer, Cloudflare hacked using auth tokens stolen in Okta attack: https://www.bleepingcomputer.com/news/security/cloudflare-hacked-using-auth-tokens-stolen-in-okta-attack/
Comentários