Identidades não humanas (NHIs) explicadas e como protegê-las

A maioria das organizações não consegue produzir um inventário completo das identidades não humanas (NHIs) que estão em execução em seu ambiente. Contas de serviço, chaves de API e credenciais de aplicativo se acumulam no Active Directory (AD) e nas plataformas em nuvem, muitas vezes sem propriedade clara, propósito documentado ou um ciclo de revisão definido.

Essa lacuna traz um risco real. De acordo com o Relatório de Tendências em Cibersegurança da Netwrix 2025, 46% das organizações sofreram compromissos de conta no ano passado, em comparação com apenas 16% em 2020. Identidades máquina a máquina, como contas de serviço e tokens, são um fator crescente nessa tendência, e a maioria das equipes de TI de médio porte não tem a visibilidade para gerenciá-las de forma eficaz.

O que são identidades não humanas em cibersegurança e por que são importantes?

Identidades não humanas (NHIs) são credenciais digitais que permitem que máquinas, aplicativos e processos automatizados se autentiquem e acessem recursos sem intervenção humana. Contas de serviço, chaves de API, identidades gerenciadas, tokens OAuth e agentes de IA estão todos sob o guarda-chuva NHI.

Os números deles estão crescendo rapidamente. Cada recurso em nuvem, pipeline de CI/CD, fluxo de trabalho de automação e integração de IA cria novas NHIs que precisam de credenciais e permissões. Na maioria das organizações, as identidades de máquina superam o número de usuários humanos por um fator de 10:1 ou mais.

Quando seu software de backup se conecta a um banco de dados às 2 da manhã, ele não digita uma senha. Ele se autentica usando uma conta de serviço com credenciais armazenadas. Isso é um NHI. O mesmo se aplica à chave API que seu sistema de tickets usa para puxar dados do CRM, ou ao token OAuth que sincroniza os registros de funcionários com Entra ID.

Como observou Jeff Warren, Chief Product Officer da Netwrix, no Relatório de Tendências em Cibersegurança de 2025, os ataques impulsionados por identidade provavelmente dominarão ainda mais, com "o abuso de identidades máquina-a-máquina, como contas de serviço e tokens" entre os vetores emergentes.

Identidades humanas vs. identidades não humanas

Identidades humanas e não humanas diferem em como são possuídas, autenticadas, geridas e monitoradas:

• Propriedade: As identidades humanas têm proprietários claros. As NHIs muitas vezes têm propriedade compartilhada ou pouco clara, dificultando a aplicação da responsabilidade.
• Autenticação: Os humanos usam senhas combinadas com MFA. Os NHIs usam chaves, tokens e certificados, e MFA não se aplica.
• Ciclo de vida: As identidades humanas seguem processos impulsionados por recursos humanos (integração, mudanças de função, desligamento). As NHIs são criadas ad hoc por desenvolvedores e administradores, sem uma gestão equivalente do ciclo de vida.
• Comportamento: O acesso humano é interativo e variável. O acesso NHI é programático e repetitivo, tornando a detecção de anomalias mais fácil de estabelecer como base e mais difícil de revisar em grande escala.

As políticas de senha, MFA, SSO e as revisões de acesso não se traduzem bem para NHIs. É por isso que as identidades de máquina exigem sua própria abordagem de governança.

O termo relacionado “identidade da máquina” refere-se especificamente a identidades em nível de infraestrutura, como servidores, VMs e certificados. NHI é mais amplo, cobrindo esses mais credenciais em nível de aplicação, como chaves de API, tokens e bots.

Métodos de autenticação de identidade não humana

Os NHIs se autenticam programaticamente em vez de por meio de login interativo, usando quatro métodos principais:

• Baseado em token: chaves de API, tokens portadores e tokens JWT
• Baseado em chave: chaves SSH e chaves de conta de serviço
• Baseado em certificados: Certificados X.509 e TLS mútuo (mTLS)
• Federação de identidade de carga de trabalho: Mecanismos nativos da nuvem, como funções do AWS IAM, identidades gerenciadas do Azure e contas de serviço do GCP

O risco crítico em todos os quatro é que MFA e SSO não se aplicam. Quando uma credencial é comprometida, não há um segundo fator para evitar a exploração, e o atacante herda qualquer acesso que essa identidade tenha.

Tipos comuns de identidades não humanas

Entender os diferentes tipos de NHIs em seu ambiente é o primeiro passo para gerenciá-los de forma eficaz. As seguintes categorias representam as identidades não humanas mais comuns que você encontrará em ambientes locais e na nuvem.

1. Contas de serviço e identidades de aplicativo

Contas de serviço são contas especializadas que permitem que aplicativos realizem tarefas sem credenciais humanas. Seu software de backup usa uma para acessar bancos de dados do SQL Server, e suas ferramentas de monitoramento as usam para coletar dados de desempenho. Em ambientes AD, essas são identificadas pelo atributo ServicePrincipalName (SPN).

O principal desafio de segurança é que as senhas raramente mudam. A melhor prática moderna é migrar para Contas de Serviço Gerenciadas por Grupo (gMSAs), que fornecem gerenciamento automático de senhas através do Active Directory e eliminam a intervenção manual do administrador.

As identidades de aplicativos estendem esse conceito para ambientes nativos da nuvem, onde as plataformas de nuvem atribuem identidades dedicadas aos aplicativos para acessar APIs, bancos de dados e outros recursos em nuvem.

2. Chaves de API e segredos

As chaves API e os segredos desempenham a mesma função básica: permitem que um sistema se autentique em outro sem a intervenção humana. Elas estão incorporadas em ferramentas internas, integrações de SaaS e conexões de serviços de terceiros para conceder acesso programático sem exigir que alguém faça login.

That third-party category is broader than most teams realize. When a printer communicates with its manufacturer for supply monitoring, or when manufacturing equipment sends telemetry to an OEM for remote maintenance, those connections rely on API keys or embedded credentials that authenticate across organizational boundaries. These vendor-managed NHIs often fall outside standard identity governance because they're provisioned by the vendor, not by your IT team.

O desafio em tudo isso é a sua natureza estática. Ao contrário das senhas ligadas a contas de usuário, as chaves de API não expiram por padrão na maioria dos sistemas e tendem a acabar em arquivos de configuração, repositórios de código, variáveis de ambiente e até mesmo em registros de chat.

O mesmo se aplica a segredos armazenados em cofres ou arquivos de configuração, incluindo senhas, strings de conexão e chaves de criptografia. Essas credenciais apresentam o mesmo risco de acesso que qualquer chave de API, mas muitas vezes recebem menos atenção.

Uma vez vazadas, qualquer uma dessas credenciais é imediatamente explorável, e as organizações muitas vezes não sabem que uma foi exposta até que já tenha sido usada. Quando a credencial comprometida pertence a uma integração de terceiros, o raio de explosão se estende além do seu ambiente para relacionamentos com fornecedores regidos por estruturas como NIS2 e DORA, ambas as quais exigem controles de risco da cadeia de suprimentos para dependências de serviços digitais.

3. Identidades gerenciadas

Identidades gerenciadas representam a abordagem moderna da Microsoft para autenticação NHI no Azure. Identidades gerenciadas atribuídas pelo sistema estão diretamente ligadas a recursos específicos do Azure e eliminam a necessidade de armazenar credenciais completamente. Identidades gerenciadas atribuídas ao usuário podem ser compartilhadas entre vários recursos.

No entanto, as identidades gerenciadas resolvem o problema apenas dentro do ecossistema Azure. As organizações que executam ambientes híbridos ainda precisam de visibilidade sobre contas de serviço locais e credenciais multiplataforma que as identidades gerenciadas não cobrem.

4. Tokens OAuth

Tokens OAuth permitem acesso delegado entre aplicativos. Quando sua plataforma de RH sincroniza os dados dos funcionários com seu provedor de identidade, ou sua ferramenta de relatórios extrai registros de um CRM SaaS, essas conexões dependem de tokens de atualização OAuth para manter o acesso persistente.

Esses tokens geralmente têm uma vida útil mais longa do que o pretendido e se acumulam em suas integrações SaaS à medida que as equipes conectam mais ferramentas.

5. Identidades de carga de trabalho e contêineres na nuvem

As identidades de carga de trabalho abrangem as credenciais atribuídas a aplicativos em contêiner, funções sem servidor e cargas de trabalho em nuvem. Suas implantações do Kubernetes, Azure Container Instances e funções AWS Lambda exigem credenciais para acessar outros serviços.

As plataformas em nuvem atribuem identidades a essas cargas de trabalho, incluindo VMs, contêineres, funções sem servidor e pods do Kubernetes, para acessar recursos em nuvem, armazenamento e APIs. Essas identidades de carga de trabalho são criadas e destruídas rapidamente, muitas vezes superando a capacidade das equipes de segurança de rastreá-las.

6. Identidades de máquinas e dispositivos

Máquinas físicas e virtuais, dispositivos IoT e componentes de infraestrutura possuem suas próprias identidades. Certificados frequentemente autenticam essas identidades de máquina, criando uma camada de governança NHI que se sobrepõe, mas se estende além das credenciais em nível de aplicativo. À medida que a adoção de IoT cresce, essa população de identidades também cresce.

7. Bots e agentes de IA

Bots e agentes de IA representam a categoria mais nova e de mais rápido crescimento de identidades não humanas. Por exemplo:

• O Microsoft Copilot precisa de acesso aos seus arquivos e e-mails para ser útil
• Os bots de automação de processos robóticos (RPA) precisam de credenciais para interagir com aplicativos empresariais
• Bots de CI/CD precisam de acesso para implantar código
• Ferramentas de orquestração e agentes de IA operam como identidades não humanas, muitas vezes com amplo acesso para habilitar fluxos de trabalho de automação

Cada um deles cria relacionamentos de identidade que requerem a mesma governança que qualquer outro NHI, mas muitas vezes são provisionados rapidamente por equipes de negócios sem revisão de segurança.

O risco adicional é que as ferramentas de IA interagem com repositórios de código e ambientes de desenvolvimento. Isso pode expor inadvertidamente credenciais em prompts, saídas e logs, criando vetores de vazamento que a varredura tradicional de segredos nem sempre captura.

Cada um desses tipos de identidade requer abordagens de gerenciamento diferentes, mas todos compartilham desafios comuns de governança: rastreamento de propriedade, rotação de credenciais e desativação quando não forem mais necessárias.

Como descobrir identidades não humanas em seu ambiente

Antes de poder governar os NHI, você precisa encontrá-los. Um processo de descoberta estruturado ajuda você a entender o escopo do problema, mas a maioria das organizações percebe rapidamente que abordagens manuais apenas arranham a superfície.

Comece com seu provedor de identidade

Consulta o Active Directory para contas com Nomes de Principais de Serviço, contas de serviço geridas de forma independente e contas de serviço geridas por grupos.

Para ambientes de nuvem, extraia um inventário de principais serviços, registros de aplicativos e identidades gerenciadas do console de administração do seu provedor de identidade. Concentre-se em quatro atributos para cada identidade: qual aplicativo a utiliza, quais credenciais ela possui, quais recursos ela pode acessar e quem a possui.

Expanda para sua camada de código e automação

Trabalhe com sua equipe de DevOps para identificar credenciais armazenadas nas configurações de pipeline CI/CD, modelos de infraestrutura como código e variáveis de ambiente. Ferramentas de varredura de repositórios podem sinalizar credenciais codificadas e chaves de API comprometidas no controle de versão. Este é frequentemente onde vivem os NHIs mais não rastreados.

Audite suas integrações SaaS

Revise as concessões de OAuth e as conexões de API em suas aplicações SaaS. Muitas organizações descobrem dezenas de tokens OAuth ativos de integrações que foram configuradas há meses ou anos por pessoas que desde então deixaram a equipe ou a empresa.

Documente o que você encontrar

Para cada NHI que você descobrir, registre o proprietário (uma pessoa, não uma equipe), a justificativa comercial, o tipo de credencial e o status de rotação, e a última vez que alguém validou que ainda é necessário. Este inventário se torna a base para tudo o que vem a seguir.

Uma advertência importante: a descoberta manual oferece uma visão instantânea, não um inventário vivo. Os ambientes mudam diariamente e uma exportação trimestral não capturará a conta de serviço que alguém criou na última terça-feira.

A descoberta contínua e automatizada é o que separa as organizações que conhecem sua população NHI daquelas que apenas acham que a conhecem.

Como proteger e governar identidades não humanas

A gestão de identidades não humanas (NHIM) é a prática de descobrir, governar e proteger identidades de máquinas que o gerenciamento tradicional de identidades (IAM) e o Privileged Access Management (PAM) não foram projetados para lidar.

Isso significa governar o acesso sem um ator humano, gerenciar credenciais que não podem usar MFA e rastrear a propriedade de identidades criadas por desenvolvedores e automação em vez de processos de RH.

Uma vez que você tenha identificado o que existe em seu ambiente, a governança garante que permaneça sob controle. A segurança NHI eficaz trata as identidades das máquinas como cidadãos de primeira classe em seu programa de segurança de identidade, com políticas definidas para cada etapa de seu ciclo de vida.

Aqui está como isso se parece na prática:

• Atribua um proprietário a cada NHI na criação: Nenhuma identidade deve existir sem um indivíduo nomeado (não uma lista de distribuição, não um alias de equipe) responsável pelo seu acesso e ciclo de vida. Faça da propriedade um campo obrigatório em seu processo de provisionamento.
• Imponha o menor privilégio desde o primeiro dia: Conceda apenas as permissões específicas que cada NHI precisa para sua função, limitadas ao nível de recurso mais restrito possível. Evite permissões em toda a assinatura ou domínio para contas de serviço que precisam apenas de acesso a um único aplicativo.
• Automatize a rotação de credenciais sempre que possível: gMSAs lidam com isso automaticamente para cargas de trabalho AD locais. Para principais de serviços em nuvem e chaves de API, integre a rotação em seus pipelines de implantação ou use uma solução de gerenciamento de segredos.

A cadência correta depende do tipo de credencial e do risco de exposição, já que estruturas importantes como NIST, CIS, e PCI DSS não exigem um período de rotação universal para contas privilegiadas.

• Monitore anomalias comportamentais: Uma conta de serviço que de repente acessa recursos fora de seu padrão normal, ou uma chave de API que se autentica de um local desconhecido, deve acionar um alerta. Concentre o monitoramento na desvio das linhas de base estabelecidas, em vez de tentar revisar cada evento.
• Descomissionar agressivamente: NHIs obsoletos são uma das fraquezas mais exploráveis em qualquer ambiente. Incorpore gatilhos de descomissionamento em seu processo: se uma identidade não se autenticou em 90 dias, sinalize-a para revisão. Se o proprietário não puder justificá-la, desative-a. Se ninguém notar por mais 30 dias, remova-a.
• Certificar o acesso em um cronograma recorrente: Exigir que os proprietários de NHI revalidem que cada identidade ainda precisa de suas permissões atuais. Revisões anuais são um ponto de partida, mas trimestrais são melhores para identidades privilegiadas.

Esses controles mapeiam diretamente os requisitos já incorporados em principais estruturas de conformidade:

• O Nível 2 do CMMC requer controle de acesso e gerenciamento de contas para todas as identidades, incluindo as não humanas
• Os critérios de serviço de confiança SOC 2 exigem controles de acesso que se estendam a identidades não humanas
• A HIPAA exige trilhas de auditoria para todos os acessos a Informações de Saúde Protegidas, incluindo acessos por processos automatizados e contas de serviço
• A NIS2 (UE) exige que as organizações gerenciem os riscos da cadeia de suprimentos de TIC, incluindo credenciais de serviços de terceiros e identidades gerenciadas por fornecedores que acessam seu ambiente
• DORA (setor financeiro da UE) exige a gestão de riscos de terceiros em TIC com requisitos específicos para monitorar e governar as dependências de serviços digitais, incluindo as identidades de máquina que esses serviços utilizam

Se você está construindo a governança NHI, está simultaneamente construindo evidências de conformidade.

Como a Netwrix apoia a segurança de identidades não humanas

Cada prática de governança acima depende de uma coisa: saber quais identidades não humanas existem em seu ambiente e o que estão fazendo. Essa é a lacuna que a maioria das organizações tem dificuldade em fechar sozinhas, e é onde a Netwrix se encaixa.

A plataforma Netwrix 1Secure fornece visibilidade contínua sobre a postura de identidade em Active Directory e ambientes de nuvem. Para identidades não humanas especificamente, ela destaca contas inativas, contas obsoletas e configurações de acesso excessivamente permissivas que violam a política organizacional, oferecendo às equipes de segurança uma imagem do estado atual em vez de uma instantânea trimestral.

Onde consultas manuais lhe dão uma exportação em um ponto no tempo, o 1Secure mantém uma visão contínua à medida que novas identidades são criadas e as existentes mudam.

Para Active Directory especificamente, Netwrix Auditor rastreia alterações em contas de serviço, monitora eventos de autenticação e audita modificações de Política de Grupo, preenchendo as lacunas de visibilidade que as ferramentas nativas deixam abertas.

Quando alguém cria uma nova conta de serviço, altera sua associação a grupos ou tenta um login interativo, Auditor sinaliza isso. As equipes podem começar a responder perguntas de auditoria sobre a atividade de NHI com relatórios legíveis por humanos que se mapeiam diretamente para estruturas de conformidade como HIPAA, SOC 2 e CMMC.

Para identidades não humanas privilegiadas que requerem acesso elevado, Netwrix Privilege Secure elimina privilégios permanentes através de provisionamento just-in-time com gravação completa de sessões para trilhas de auditoria. Em vez de contas de serviço que mantêm acesso administrativo persistente 24 horas por dia, o Privilege Secure concede permissões elevadas apenas quando necessário e as revoga automaticamente quando a tarefa é concluída.

Pronto para fechar a lacuna de visibilidade em identidades não humanas?Agende uma demonstração para ver como a Netwrix funciona em seu ambiente.