Semion Vasilevitzky e Jonathan Elkabas

Nota do editor: Bem-vindo ao Capítulo 6 de «Compreender e Prevenir Ataques à Identidade do Agente do Entra ID: Um Guia Abrangente». Este guia técnico em várias partes ajuda-o a compreender a abordagem da Microsoft em relação às identidades dos agentes e como pode protegê-las contra agentes maliciosos. Para rever os capítulos anteriores e as lições práticas, comece aqui.

A plataforma Agent ID introduz novos tipos de identidade e padrões operacionais e, uma vez que esta funcionalidade está apenas a começar a evoluir, as suas falhas de configuração e vias de ataque no mundo real só agora começam a surgir. Nesta secção, não pretendemos abordar todos os riscos ou vulnerabilidades possíveis. Em vez disso, iremos destacar um pequeno conjunto de falhas de configuração simples, mas importantes, que provavelmente se tornarão comuns à medida que as organizações começarem a adotar a Agent ID em grande escala.


Quem é o proprietário deste agente? IDs de agentes sem proprietário nem patrocinador

As identidades de agentes não geridas (aquelas sem proprietário nem patrocinador) criam uma lacuna na governação de identidades. Quando não há uma pessoa ou equipa responsável designada, é mais provável que estas identidades de cargas de trabalho sejam ignoradas durante as auditorias e não sejam detetadas durante a resposta a incidentes.

Na página de visão geral do Entra Agent ID, podemos ver o número de identidades de agentes não geridas.

Figura 1. Visualização das identidades dos agentes não geridos na visão geral do Microsoft Agent ID

Embora seja necessário indicar pelo menos um patrocinador ao criar uma identidade de agente, é possível que, com o tempo, essas identidades fiquem sem gestão. Por exemplo, esta situação pode ocorrer se um utilizador que atuava como patrocinador for eliminado, nomeadamente após deixar a organização.

Outra situação semelhante, mas que não aparece na página de resumo, ocorre quando a conta do patrocinador ou do proprietário é desativada. Nestes casos, a identidade do agente parece ter um proprietário ou patrocinador atribuído, mas a conta atribuída já não está ativa na organização. Isto deixa a identidade efetivamente órfã e fácil de passar despercebida pelos administradores.

Idealmente, as identidades dos agentes devem ter sempre uma pessoa responsável por elas, que esteja ciente do seu objetivo. Garantir a responsabilização contínua é uma parte essencial da governação de identidades.

Em Semperis Lightning Intelligence e Directory Services Protector DSP)— duas soluções que fazem parte da Identity Resilience Platform— já identificamos essas duas situações. Num painel de controlo claro, é possível ver não só o número de identidades de agentes não geridas, mas também a lista exata.

Figura 2. Visualização das identidades dos agentes não geridos na plataforma Semperis

Também é possível ver as identidades de agentes órfãos em questão e quais são, exatamente, os patrocinadores ou proprietários desativados que, na prática, tornam essas identidades de agentes órfãos.

Figura 3. Revelação da identidade dos patrocinadores e proprietários de agentes desativados

Quem Conhece o Meu Segredo? Planos que Utilizam Segredos do Cliente

Tal como descrevemos anteriormente no Ponto de Verificação Prático 1 deste guia, um segredo de cliente é um dos tipos de credenciais que podem ser atribuídos a um modelo de identidade de agente. Este tipo de credencial é considerado fraco porque é frequentemente armazenado em ficheiros de configuração, scripts, pipelines de CI/CD ou repositórios de código-fonte, onde pode ser divulgado involuntariamente. Se um atacante obtiver um segredo de cliente, poderá autenticar-se como esse modelo de identidade de agente ou como as identidades de agente a ele associadas, sem necessidade de início de sessão interativo ou autenticação multifator (MFA).

A Microsoft adverte explicitamente que:

Os segredos do cliente não devem ser utilizados como credenciais do cliente em ambientes de produção para modelos de identidade de agentes, devido aos riscos de segurança.

Em vez disso, a Microsoft recomenda a utilização de credenciais de identidade federada (FIC) com identidades geridas ou certificados para a autenticação.

Os indicadores do Semperis permitem-lhe acompanhar todos os modelos de identidade de agentes com dados confidenciais num único local centralizado e identificar as credenciais mal configuradas de cada modelo.

Figura 4. Visibilidade das credenciais do modelo de identidade do agente mal configuradas

Demasiado poder: identidades de agentes altamente privilegiados

Até agora, falámos sobre como os agentes obtêm permissões exclusivas da aplicação ou delegadas e como funciona a atribuição de funções neste modelo. Embora a Microsoft limite as permissões e as funções que podem ser atribuídas às identidades dos agentes, a aplicação do princípio do privilégio mínimo continua a ser fundamental.

As permissões com privilégios elevados numa identidade de agente aumentam o risco, mesmo quando não há nenhum atacante presente. As identidades de agente podem ser executadas automaticamente e realizar ações em grande escala. Se um agente estiver mal configurado, se comportar de forma inesperada ou for integrado incorretamente num fluxo de trabalho, os privilégios elevados podem transformar um simples erro num incidente que afete todo o inquilino. Do ponto de vista da segurança, as identidades de agente com privilégios excessivos aumentam a superfície de ataque e constituem um alvo para os atacantes.

Os administradores da organização devem rever regularmente as permissões atribuídas às identidades dos agentes e reduzi-las ao mínimo necessário para o funcionamento do agente.

Os indicadores da Semperis mostram-lhe, num único local, as identidades dos agentes com privilégios elevados e as suas funções exatas com privilégios excessivos.

Figura 5. Identificação de funções com privilégios excessivos

Conclusões

As identidades dos agentes não são apenas mais uma caixa de seleção no Centro de Administração do Microsoft Entra. São a tentativa da Microsoft de atribuir aos agentes de IA uma identidade formal no diretório. Não se trata de um objeto de automação vago. Nem apenas de uma entidade de serviço com uma nova função. Trata-se de um novo modelo de identidade que procura representar os agentes como algo que a plataforma possa reconhecer, gerir, autorizar e auditar.

E isso é importante porque, no momento em que um agente precisa de ultrapassar um limite do sistema, chamar uma API, ler dados organizacionais, atualizar o estado, enviar uma mensagem, aceder a uma caixa de correio ou agir em nome de algo maior do que ele próprio, deixa de ser apenas «lógica de IA». Torna-se um participante no sistema de identidade. Precisa de um principal. Precisa de permissões. Precisa de um token. Precisa de um lugar no diretório.

O Agent ID é a resposta da Microsoft a essa necessidade.

No centro deste modelo encontra-se o «Agent Identity Blueprint», o modelo a partir do qual as identidades dos agentes são criadas e através do qual as permissões herdadas podem ser transmitidas. Em torno deste, a Microsoft introduziu vários objetos relacionados: identidades de agente, utilizadores de agente, entidades do modelo e agentes legados apoiados por entidades de serviço. Em conjunto, formam uma nova camada operacional para os agentes de IA no Entra ID.

Mas, como vimos ao longo deste guia, o Agent ID não surge do nada. Assenta nas primitivas existentes do Entra ID, e essas primitivas já vêm associadas a uma estrutura, permissões, pressupostos e um historial.

As identidades dos agentes herdam das entidades de serviço. Os utilizadores dos agentes herdam dos utilizadores. Os modelos herdam das aplicações. As permissões são geridas através dos mecanismos habituais de OAuth e de atribuição de funções às aplicações. A aplicação das funções continua a depender de ações RBAC, verificações de API e comportamento em tempo de execução. Os nomes são novos, mas o plano de controlo subjacente é-nos muito familiar.

E, para ser sincero, isso constitui simultaneamente o ponto forte (operacional) e o risco (de segurança) do modelo.

Isso significa que o Agent ID pode integrar-se naturalmente no Entra ID, no Microsoft Graph, nos registos de auditoria, nas permissões das aplicações e nos fluxos de administração existentes. Mas significa também que cada capacidade herdada, cada pressuposto oculto e cada antigo problema de delimitação de âmbito volta a tornar-se relevante num novo contexto.

As identidades de agente introduzem uma nova superfície de ataque, e devemos esperar que surjam novas vias de ataque à medida que as organizações começam a adotá-las. Algumas provavelmente resultarão de modelos com permissões excessivas. Outras, de limites de funções pouco claros. Outras, de permissões herdadas que os defensores ainda não identificaram corretamente. Outras, de utilizadores de agentes que interagem com superfícies originalmente concebidas para utilizadores humanos. Outras, do Acesso Condicional e do comportamento dos tokens, que ainda necessitam de testes práticos mais aprofundados. E outras, como sempre, de locais enfadonhos que ninguém analisou porque o portal e a documentação os faziam parecer inofensivos.

O importante é não tratar os agentes como algo mágico ou distinto do que já conhecemos, porque são identidades.

E as identidades autenticam-se, obtêm autorização, realizam ações e deixam rasto. O mesmo velho ciclo AAA está agora a usar uma máscara com a forma da IA.

Portanto, se há uma lição prática a reter desta análise, é esta.

Não te limites à etiqueta do portal ou à tabela da documentação. Segue o modelo de objetos. Segue a herança. Segue o token. Segue as permissões. Segue as ações da função. Segue os registos de auditoria e de início de sessão. O comportamento real da plataforma revela-se, normalmente, algures entre o que o esquema descreve, o que a documentação promete e o que o tempo de execução permite efetivamente.

À medida que o Agent ID continua a evoluir, as questões mais complexas não serão apenas de natureza técnica. Serão questões de confiança: até que ponto estamos dispostos a conceder acesso a estas identidades, com que clareza conseguimos perceber o que estão a fazer e até que ponto a plataforma consegue impor limites em torno delas, assim que começarem a operar em grande escala.

Porque os agentes não são apenas código a funcionar silenciosamente em segundo plano. São código com autonomia, dotado de identidade, com permissões, que toma decisões e ultrapassa limites em nome de alguém ou de algo.

E quando o código passa a ter autonomia, identidade e confiança, torna-se mais do que «automatização».

Torna-se uma vontade delegada no seio do sistema, transportando as nossas autorizações, os nossos pressupostos e, por fim, as nossas consequências.


Não adivinhe — analise. Como é que a Semperis pode ajudar?

As ferramentas da Semperis já permitem identificar lacunas de governação, destacar potenciais pontos de exposição e ajudar a revelar esse tipo de configurações incorretas e riscos. Esta área continua a evoluir e, aqui na Semperis, já estamos a trabalhar em indicadores adicionais de exposição e em capacidades de deteção mais aprofundadas, que serão introduzidas ao longo do tempo.

À medida que for alargando a adoção de identidades de agente nos seus sistemas de identidade, irá certamente deparar-se com novas questões a cada passo. Contacte-nos a qualquer momento; estamos aqui para o ajudar.


Ler mais


Explore o guia