Identidades Não Humanas Se Tornaram a Maior Superfície de Ataque Não Gerenciada na Segurança em Nuvem

Em um ambiente corporativo típico de nuvem hoje, identidades de máquina — contas de serviço, API keys, OAuth tokens, credenciais de CI/CD e workload identities — superam contas de usuário humano em proporções comumente citadas entre 45:1 e 90:1. Times de segurança passaram duas décadas construindo identity and access management em torno de pessoas: onboarding, offboarding, autenticação multifator, revisão periódica de acesso. Quase nada dessa infraestrutura foi feita para máquinas, e isso fica evidente. As non-human identities (NHIs) silenciosamente se tornaram a maior superfície de ataque não gerenciada na segurança em nuvem, e a maioria das organizações não consegue responder uma pergunta básica: quantas credenciais de máquina existem no ambiente, quem ou o que é dono de cada uma, e quando foi usado pela última vez.

Por Que o IAM Tradicional Não Cobre Máquinas

A governança de identidade humana depende de premissas que não se aplicam a máquinas. Uma pessoa tem um gestor que pode atestar a necessidade contínua de acesso. Uma pessoa passa por entrevista de saída e checklist de offboarding quando sai. A solicitação de acesso de uma pessoa passa por um ciclo de revisão. Contas de serviço, por outro lado, são frequentemente criadas ad hoc por um desenvolvedor provisionando um novo microserviço, recebem permissões amplas para evitar erros de permissão na depuração, e nunca mais são revisitadas. A credencial sobrevive ao projeto, ao desenvolvedor que a criou e, muitas vezes, ao motivo pelo qual existia em primeiro lugar. Multiplique esse padrão por cada pipeline de CI/CD, cada integração SaaS de terceiros, cada serviço interno chamando outro serviço interno, e o problema de inventário se torna enorme.

Como Credenciais de Máquina São Realmente Comprometidas

Os padrões de breach são surpreendentemente consistentes nos relatórios de incidentes. API keys de longa duração são commitadas em repositórios públicos do GitHub por desenvolvedores que esquecem de adicioná-las a um arquivo .gitignore — scanners automatizados encontram e exploram essas chaves em minutos após a exposição. Contas de serviço com privilégios excessivos, que receberam acesso de admin porque era mais rápido do que escopar permissões corretamente, transformam uma única credencial comprometida em acesso total ao ambiente. OAuth tokens obsoletos de uma integração SaaS desativada há dezoito meses continuam válidos porque ninguém os revogou. E em ambientes cloud-native, workload identities que deveriam ser de curta duração e escopadas a um único pod ou função acabam embutidas em container images como secrets estáticos e de longa duração.

Nenhuma dessas é uma técnica de ataque exótica. São falhas básicas de higiene em escala, e os atacantes sabem disso. Ataques baseados em credenciais contra identidades de máquina se tornaram um dos vetores de acesso inicial mais confiáveis justamente porque as ferramentas defensivas que pegariam um login humano suspeito — geografia anômala, horário de acesso incomum, device fingerprinting — muitas vezes não se aplicam de forma limpa a um script chamando uma API de um data center às 3 da manhã, o que é comportamento completamente normal de máquina.

O Que Está Realmente Mudando

Uma nova categoria de ferramentas de segurança surgiu especificamente para resolver essa lacuna, com vendors como Astrix Security, Entro, Oasis Security e Token Security construindo produtos que descobrem, inventariam e monitoram NHIs em ambientes de nuvem e SaaS de formas que as ferramentas de IAM de propósito geral nunca foram projetadas para fazer. Essas plataformas normalmente começam construindo um inventário abrangente — algo que a maioria das organizações nunca teve — depois adicionam camadas de risk scoring baseado em nível de privilégio, idade da credencial e padrões de uso, e por fim automatizam a remediação, como rotação de credenciais ou escopo de acesso.

Os cloud providers também avançaram nisso. AWS, Google Cloud e Azure agora oferecem workload identity federation, que permite que um serviço autentique usando tokens de curta duração, rotacionados automaticamente e vinculados à identidade real do runtime, em vez de uma chave estática de longa duração. Isso elimina uma categoria inteira de risco — a credencial estática vazada — por design, mas a adoção exige re-arquitetar integrações existentes, e é por isso que a migração tem sido lenta apesar das ferramentas estarem disponíveis há vários anos.

O Que os Times de Segurança Devem Fazer de Verdade

Comece pela descoberta, não pela remediação. Você não pode proteger o que não consegue ver, e a maioria das organizações subestima sua contagem de NHIs por uma ordem de magnitude até rodar um scan adequado em contas de nuvem, consoles de admin de SaaS, sistemas de CI/CD e repositórios de código-fonte. Depois que você tiver um inventário, priorize pelo blast radius: uma credencial com acesso de admin à nuvem importa mais do que uma API key somente leitura para uma ferramenta interna de baixa sensibilidade, independentemente de qual é mais antiga ou mais visível.

Migre para credenciais de curta duração onde a plataforma suportar — workload identity federation para autenticação cloud-to-cloud, OIDC tokens para pipelines de CI/CD em vez de secrets estáticos armazenados na configuração do pipeline. Para credenciais que precisam permanecer de longa duração, imponha rotação em um cronograma fixo em vez de depender de alguém lembrar de fazer manualmente, e defina datas de expiração como padrão, não como exceção. Por fim, atribua ownership. Toda credencial de máquina deve mapear para um humano ou time responsável por ela, da mesma forma que toda conta humana mapeia para um funcionário. Uma credencial sem dono é uma credencial que ninguém vai notar ficando obsoleta, que ninguém vai sinalizar por uso suspeito, e que ninguém vai pensar em revogar quando o sistema que ela atende for desativado — que é exatamente a lacuna que os atacantes estão explorando em escala agora.