Em artigos anteriores, falamos o que são as Identidades Não Humanas, por que a autenticação baseada em credenciais estáticas falha estruturalmente e como o HORACIUS IAM viabiliza a gestão unificada de humanos e robôs em um único ecossistema de governança. O que ficou em aberto é a camada mais operacional dessa discussão.
Saber que NHIs precisam de governança não resolve o problema do dia a dia da equipe de segurança: qual acesso um agente de IA realmente precisa, como definir o escopo mínimo de uma máquina em produção, quando revisar as permissões de um robô de automação que ninguém mais lembra quem configurou.
Este artigo trata exatamente disso. O princípio do menor privilégio já é conhecido, mas a questão é como aplicá-lo para identidades que não têm gestor, não passam por revisão periódica e não foram desenhadas com restrição de escopo em mente.
Por que o menor privilégio é mais difícil para NHIs do que para humanos
Para um colaborador humano, o ciclo de vida de acesso tem pontos de verificação naturais: o onboarding define o perfil inicial, mudanças de cargo disparam revisões, o desligamento aciona a revogação. O processo é imperfeito, mas existe uma estrutura que o suporta.
NHIs não têm equivalente. Uma service account criada para integrar dois sistemas em um projeto de migração não tem data de validade, não tem avaliação de desempenho e não tem gestor que a revise trimestralmente. Ela simplesmente existe, com os acessos que foram concedidos na criação, que costumam ser amplos por precaução operacional.
O resultado é previsível: identidades com acesso de administrador para sistemas que exigiriam apenas leitura, API keys com escopo global para funções que consomem um único endpoint, scripts com permissões de escrita em bases de dados que só precisariam consultar. O excesso de privilégio, portanto, não é exceção: é o padrão de origem.
Além disso, há uma segunda dificuldade: ao contrário de humanos, NHIs não relatam o que fazem. Um colaborador que acessa um sistema fora do seu escopo pode ser notado. Um agente de IA com permissões excessivas age dentro do esperado, até que não age mais.
Menor privilégio por tipo de NHI
Cada categoria de identidade não humana tem características distintas que determinam como o menor privilégio deve ser definido e mantido.
Service accounts
São identidades usadas por sistemas para se autenticar em outros sistemas. O critério central é funcional: o acesso deve cobrir exatamente o que o sistema precisa executar, sem margem para expansão. Uma service account que integra o ERP com o sistema de folha de pagamento não precisa de permissão de leitura em outras bases, mesmo que tecnicamente o ambiente permita.
Service accounts tendem a acumular permissões ao longo do tempo, à medida que novos requisitos surgem e os antigos não são removidos. A equipe de segurança precisa, portanto, manter o menor privilégio ativamente, não apenas configurá-lo na criação.
API keys
A definição de escopo mínimo para API keys é mais objetiva: cada chave deve ser válida apenas para os endpoints que a integração efetivamente consome. Uma API key com acesso de leitura e escrita para uma integração que só lê dados é um risco desnecessário.
Além do escopo, há duas dimensões adicionais: validade e contexto. API keys sem data de expiração geram credenciais estáticas com vida útil indefinida, exatamente o modelo que os artigos anteriores desta série descreveram como estruturalmente inseguro.
Da mesma forma, uma chave válida globalmente para um uso restrito a um ambiente de produção é excesso de exposição evitável.
Scripts e automações
Scripts criados para resolver problemas pontuais costumam ser os mais difíceis de governar: nascem sem processo formal, geralmente com credenciais embutidas e permissões amplas, e sobrevivem muito além do problema que resolviam.
O princípio do menor privilégio aplicado a scripts exige, em primeiro lugar, que eles sejam inventariados. Scripts que ninguém identifica como ativos ainda em uso são, por definição, contas órfãs com acesso ativo. Após o inventário, o critério é o mesmo: leitura onde apenas leitura é necessária, escopo restrito ao sistema específico, sem acesso a ambientes que a automação não deveria alcançar.
Agentes de IA
São o tipo de NHI mais recente e, por isso, o menos coberto pelos modelos de governança existentes. Agentes autônomos operam com credenciais concedidas na configuração e tomam decisões em velocidade de máquina, o que significa que o escopo definido na criação determina o raio de ação de cada decisão futura.
O menor privilégio para agentes de IA exige uma camada adicional de especificidade: quais sistemas o agente pode acessar e quais ações pode executar dentro de cada um.
Um agente com permissão de leitura e escrita em um sistema de relacionamento com clientes pode, dentro do escopo técnico concedido, tomar ações que nenhum humano teria autorizado individualmente. Portanto, o controle granular de ação, e não só de acesso, é o critério relevante aqui.
O escopo mínimo, sozinho, não cobre tudo: ele delimita o que o agente alcança, porém não impede que uma única identidade concentre funções que, em um fluxo humano, estariam separadas.
As quatro perguntas para cada NHI
Independentemente do tipo, quatro perguntas definem se uma NHI está operando dentro do princípio do menor privilégio:
Para que serve? A função da identidade deve ser documentada e específica. “Integração entre sistemas A e B para sincronização de dados cadastrais” é um propósito válido. “Acesso geral para automações” não é.
Quem é o sponsor? Toda NHI precisa de um responsável humano que assuma formalmente a existência e o escopo daquela identidade. Sem sponsor definido, a identidade é uma conta órfã independente de quantos sistemas ela acessa.
Quando expira? Credenciais sem data de validade são o modelo que criou o problema que estamos tentando resolver. A validade deve ser proporcional ao uso: integrações permanentes exigem renovação periódica, não validade indefinida.
Qual é o escopo mínimo necessário? A pergunta não é “o que essa identidade pode precisar acessar”, mas “o que ela precisa acessar para executar sua função hoje”. A diferença entre as duas define a superfície de ataque.
Ciclo de revisão: quando disparar
Diferente de humanos, NHIs não têm eventos de vida que disparam revisões naturalmente. Por isso, a equipe de segurança precisa definir o ciclo por outros gatilhos.
O primeiro é temporal: toda NHI deve passar por revisão de escopo em intervalos definidos, independente de mudanças no ambiente. O intervalo adequado varia conforme a criticidade do sistema acessado; identidades com acesso a sistemas financeiros ou de dados pessoais exigem ciclos mais curtos.
O segundo gatilho é o offboarding do sponsor. Quando o responsável por uma NHI deixa a organização ou muda de área, a equipe de segurança precisa revisar imediatamente a identidade não humana vinculada a ele.
Sem esse processo, o desligamento do sponsor cria exatamente o tipo de conta órfã que o primeiro artigo desta série descreveu como risco estrutural.
O terceiro é a mudança no sistema acessado. Migrações, atualizações de arquitetura e mudanças de fornecedor são momentos em que escopos concedidos anteriormente podem ter se tornado mais amplos do que o necessário. Contudo, sem um processo que vincule essas mudanças à revisão de NHIs, o excesso de acesso simplesmente persiste.
Checklist de revisão de menor privilégio para NHIs
- A NHI tem propósito documentado e específico?
- Existe um Sponsor humano formalmente designado?
- A credencial tem data de expiração definida?
- O escopo de acesso foi revisado dentro do ciclo definido para a criticidade do sistema (90 dias, por exemplo, para sistemas de menor risco)?
- Há permissões concedidas que não aparecem nos logs de uso dentro da janela esperada para essa identidade (30 dias, por exemplo, para automações de execução frequente)?
- O acesso cobre apenas os sistemas necessários para a função declarada?
- Para agentes de IA: as ações permitidas dentro de cada sistema estão definidas além do acesso ao sistema em si?
- O offboarding do sponsor está mapeado para disparar revisão automática desta NHI?
Cada item sem resposta confirmada é um ponto de exposição ativo.
Como o HORACIUS IAM suporta esse processo
O modelo de governança (sponsor, ciclo de revisão, SoD e rastreabilidade) está estruturado nativamente no HORACIUS IAM. O IGA atua como núcleo de governança de NHIs com o mesmo rigor aplicado a identidades humanas: provisionamento controlado, detecção contínua de contas órfãs e visão consolidada de quem autorizou cada acesso e quando.
No próximo artigo desta série, avançamos para o modelo de maturidade: como avaliar em qual estágio de governança de NHIs a sua organização está hoje e o que é necessário para evoluir.
Fale com um especialista da E-TRUST e veja o HORACIUS IAM em ação.
