Guia Cibersegurança Gestão de TI

Identidades de máquinas: a superfície de ataque que sua equipe de segurança não está gerenciando

Chaves de API, contas de serviço, certificados TLS e tokens OAuth superam contas humanas em 45 para 1 nos ambientes corporativos. A maioria das organizações não tem um inventário completo deles. Os atacantes varrem esses ativos continuamente.

25 de junho de 2026
9 min de leitura
Principais pontos
  • Identidades de máquinas superam identidades humanas em 45 para 1 nos ambientes corporativos, mas a maioria das equipes de segurança inventariou apenas uma fração delas
  • Contas de serviço, chaves de API, certificados TLS e tokens OAuth são cada um um ponto de entrada potencial se não gerenciados
  • Certificados expirados causam interrupções; chaves de API expostas causam vazamentos; contas de serviço abandonadas permitem movimentação lateral
  • Ferramentas de gerenciamento de secrets resolvem o problema de armazenamento, mas o inventário deve vir antes da rotação
  • A arquitetura Zero Trust só funciona se a confiança máquina a máquina for tão rigorosamente governada quanto o acesso de usuários

O que conta como identidade de máquina

Identidades de máquinas são credenciais que sistemas usam para se autenticar entre si. Um usuário faz login com nome de usuário e senha. Uma máquina usa algo diferente: um certificado TLS, uma chave de API, uma chave SSH, um token OAuth, uma conta de serviço ou um token de conta de serviço do Kubernetes.

Infraestrutura em nuvem, microsserviços, contêineres, pipelines de CI/CD e integrações com APIs de terceiros multiplicaram as conexões máquina a máquina na maioria das organizações em uma ordem de magnitude na última década. Cada conexão precisa de autenticação. As organizações têm processos formais para contas de usuários. Quase nenhuma tem processos equivalentes para máquinas.

45:1
proporção de identidades de máquinas para humanas nos ambientes corporativos
68%
dos vazamentos envolvem credenciais comprometidas (Verizon DBIR)
250k+
identidades de máquinas em uma grande empresa típica

Por que os números saíram do controle

Tudo se acumula em pequenas etapas sem alardes. Uma equipe de DevOps cria uma conta de serviço para executar um pipeline de implantação. Um engenheiro cria uma chave de API para conectar duas ferramentas SaaS. Um desenvolvedor adiciona credenciais a um arquivo de configuração de ambiente de teste. Uma imagem de contêiner carrega um secret codificado do computador de um desenvolvedor para a produção.

Nada disso parece um evento de segurança no momento. Quando sua equipe de segurança faz o primeiro inventário, as credenciais de máquinas já superam o total de funcionários por uma margem que surpreende a maioria das equipes.

Contas de usuários têm um gatilho natural de desprovisionamento: a pessoa sai. Credenciais de máquinas não têm equivalente. Contas de serviço se acumulam. Chaves de API são compartilhadas entre equipes e nunca rotacionadas. Certificados TLS expiram no dia em que um engenheiro está de férias. Tokens do Kubernetes de uma implantação dois anos atrás continuam válidos e ninguém sabe para quê serviam.

Como os atacantes exploram isso

O Verizon DBIR encontra credenciais comprometidas na maioria dos vazamentos. Credenciais de máquinas representam uma parcela grande e pouco defendida dessa exposição.

Um atacante que encontra uma chave de API em um repositório público do GitHub tem acesso imediato a tudo que essa chave autoriza. Um pipeline de CI/CD comprometido permite que o atacante injete credenciais em artefatos de build. Uma conta de serviço com permissões excessivas dá ao atacante um veículo de movimentação lateral assim que ele a obtém.

Ferramentas de detecção baseadas em padrões de comportamento humano não sinalizariam uma conta de serviço fazendo o que contas de serviço normalmente fazem. Por isso, credenciais de máquinas comprometidas frequentemente ficam sem detecção por meses.

Sessões de usuários expiram. Credenciais de máquinas, a menos que alguém as rotacione ou revogue explicitamente, tendem a permanecer válidas indefinidamente. Uma chave de API de um serviço que já não existe pode ainda funcionar. Uma conta de serviço de um projeto concluído dois anos atrás pode ainda ter direitos de administrador de domínio.

Quatro controles que importam

1
Inventariar primeiro
Você não pode gerenciar o que não pode ver. Um inventário de identidades de máquinas abrange contas de serviço no Active Directory e Azure AD, chaves de API em provedores de nuvem e ferramentas SaaS, certificados TLS, chaves SSH, tokens OAuth e tokens de conta de serviço do Kubernetes. A fase inicial de descoberta é a que a maioria das organizações subestima.
2
Centralizar o gerenciamento de secrets
Secrets codificados em código, arquivos de configuração e variáveis de ambiente são a fonte mais comum de exposição de credenciais. Gerenciadores de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) fornecem um repositório centralizado com controles de acesso, logs de auditoria e rotação automatizada.
3
Aplicar o princípio do menor privilégio
Uma conta de serviço que precisa ler de um bucket S3 não deve ter acesso de escrita a outros cinco. Identidades de máquinas acumulam permissões porque é mais fácil conceder acesso amplo do que definir os requisitos exatos. Uma revisão de privilégios revela mais do que a maioria das equipes espera.
4
Automatizar o gerenciamento de certificados
A expiração de certificados TLS é um problema resolvido. A automação baseada em ACME (Let's Encrypt, AWS Certificate Manager, HashiCorp Vault PKI) renova certificados automaticamente antes da expiração. Interrupções por certificados expirados resultam de processos manuais em ambientes onde a automação estava disponível e não foi utilizada.
Antes de rotacionar

Rotacionar secrets em massa antes de ter um inventário completo cria novos problemas. Serviços que dependem de credenciais que você não conhecia vão falhar. Inventarie primeiro, rotacione depois, com rollback automatizado para qualquer serviço que não captar a nova credencial.

Por onde começar

Comece com as contas de serviço no Active Directory e Azure AD. A auditoria não custa nada e traz à tona os itens de maior risco imediatamente: contas privilegiadas sem proprietário claro e sem uso recente. Quando você sabe quais sistemas estão no escopo, a descoberta de chaves de API e certificados segue naturalmente.

Obtenha o inventário de credenciais dos seus provedores de nuvem logo no início. Os IAM Credential Reports da AWS, as Azure AD App Registrations e as listas de contas de serviço do GCP não capturam secrets em repositórios ou ferramentas SaaS de terceiros, mas fornecem uma base de referência mensurável.

A LGPD, a ISO 27001 e a maioria dos frameworks de auditoria interna marcam o gerenciamento de credenciais e acessos como uma área de controle essencial. Se identidades de máquinas aparecem nos seus achados de auditoria, uma avaliação estruturada é o caminho mais rápido para fechar essa lacuna.

Como a Cyvra ajuda

A Cyvra conduz avaliações de identidades de máquinas, estabelece capacidades de gerenciamento de secrets e integra a automação do ciclo de vida de certificados em ambientes de nuvem e CI/CD existentes. Se sua última auditoria sinalizou o gerenciamento de credenciais como uma lacuna, é por aí que começamos.

Perguntas frequentes

O que é uma identidade de máquina?

Uma identidade de máquina é qualquer credencial que um sistema usa para se autenticar com outro sistema: um certificado TLS, uma chave de API, uma chave SSH, uma conta de serviço, um token OAuth ou um token de conta de serviço do Kubernetes. As equipes que constroem e operam os sistemas gerenciam essas credenciais, não os usuários individualmente. Elas superam as identidades de usuários na maioria das organizações, e a governança sobre elas é muito mais fraca.

Como os atacantes encontram credenciais de máquinas expostas?

Os atacantes as encontram com mais frequência em repositórios de código públicos onde desenvolvedores commitam credenciais acidentalmente (GitHub, GitLab, Bitbucket), em armazenamento em nuvem mal configurado e dumps de variáveis de ambiente, em estações de trabalho comprometidas de desenvolvedores e em artefatos de pipeline CI/CD. Ferramentas automatizadas varrem repositórios públicos e endpoints de metadados de nuvem ininterruptamente, e os atacantes as executam em escala.

O que é gerenciamento de secrets e quais ferramentas cuidam disso?

Gerenciamento de secrets é a prática de armazenar, controlar o acesso, rotacionar e auditar as credenciais de máquinas que uma aplicação precisa para funcionar. As principais plataformas são HashiCorp Vault (open source e enterprise), AWS Secrets Manager, Azure Key Vault e GCP Secret Manager. Cada uma se integra com infraestrutura em nuvem e pode automatizar a rotação. A escolha depende principalmente do seu ambiente de nuvem.

Como o gerenciamento de identidades de máquinas se relaciona com Zero Trust?

Zero Trust exige que cada solicitação seja autenticada e autorizada independentemente da origem. Para máquinas, isso significa que cada chamada serviço a serviço carrega uma credencial válida e atual, tem apenas as permissões necessárias e produz uma trilha de auditoria. Sem isso, o Zero Trust vale para os usuários, mas não para a infraestrutura da qual eles dependem.

Fale com a Cyvra

Pronto para ter visibilidade sobre suas identidades de máquinas?

Ajudamos organizações a encontrar, governar e automatizar as credenciais que a maioria das ferramentas de segurança ignora.

Aviso legal: Este artigo tem finalidade exclusivamente informativa e não constitui aconselhamento jurídico, regulatório ou profissional. A Cyvra não garante a exatidão ou completude deste conteúdo. Os leitores devem buscar orientação independente adequada às suas circunstâncias específicas. A Cyvra não aceita responsabilidade por perdas decorrentes da confiança neste conteúdo.