Identidades dos agentes: análise aprofundada do design

Nota do editor: Bem-vindo ao Capítulo 4 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.

No capítulo anterior deste guia abrangente sobre a prevenção de ataques à identidade do agente Entra ID, definimos os objetos principais que compõem o modelo do Agent ID. Tendo esse modelo global em mente — e, esperamos, após um breve desvio para praticar a criação do Agent ID com o MS Graph —, estamos prontos para aprofundar a nossa compreensão sobre a forma como as identidades na plataforma Agent ID estão estruturadas.

Vamos voltar ao assunto.

Explorar o modelo de dados do Microsoft Graph

Para compreender como os quatro elementos fundamentais da identidade estão representados na hierarquia de dados subjacente do Microsoft Graph, podemos analisar o ponto final de metadados do Graph.

O Microsoft Graph disponibiliza o seu modelo de dados através do ponto final de metadados OData em https://graph.microsoft.com/beta/$metadata. Ao aceder a este ponto final, obtém-se um documento XML que define os tipos de entidade, tipos complexos, enumerações e relações suportadas pela API. Em termos mais simples, trata-se do mapa estrutural do Microsoft Graph. Não nos revela tudo o que a plataforma permitirá em tempo de execução, mas mostra-nos como a Microsoft optou por modelar os objetos.

A Microsoft explica que estes metadados ajudam os programadores a compreender o modelo de dados e as relações entre as entidades. Para os investigadores de segurança, este ponto de acesso é extremamente valioso, pois revela a hierarquia de herança e as definições de propriedades que determinam o comportamento dos objetos do Entra ID, incluindo os novos tipos de Agent ID.

Dito isto, o Agent ID continua a ser uma área em evolução, e alguns detalhes do esquema poderão sofrer alterações à medida que a plataforma for amadurecendo.

Antes de nos debruçarmos sobre os próprios objetos, vamos esclarecer que existem dois conceitos de metadados que vale a pena distinguir: EntityType e ComplexType.

• Um EntityType representa normalmente um objeto que pode ser consultado diretamente através do seu próprio ponto de extremidade, possui propriedades de navegação (relações com outras entidades) e pode ser armazenado, recuperado e atualizado de forma independente. Exemplos desses tipos de entidades são user, application, servicePrincipale group.
• A ComplexType é um tipo de valor estruturado que agrupa várias propriedades. Não possui identidade própria, existindo incorporado numa entidade (ou mesmo dentro de outra ComplexType) e não podem ser consultados diretamente como um objeto independente. Exemplos desses tipos são apiApplication, appRole, federatedIdentityCredentiale keyCredential.

Pensa nisto desta forma: um EntityType é como uma linha de uma tabela de uma base de dados, e um ComplexType é um objeto JSON aninhado nessa linha.

Na resposta de metadados XML, podemos ver o tipo de entidade base abstrato do qual quase todos os tipos de entidade do Graph herdam (e é por isso que quase todos os recursos do Microsoft Graph acabam por ter uma cadeia de caracteres de identificação):

A próxima peça é a directoryObject entidade, que herda da entidade.

A partir daí, podemos analisar servicePrincipal tipo e a sua estrutura.

Uma interface de utilizador baseada em texto não é, para dizer o mínimo, o formato mais legível para navegar num documento de metadados de 428 KB; por isso, criámos rapidamente uma aplicação web local para tornar a exploração destas relações entre entidades um pouco mais fácil de gerir.

Agora, em vez de tentarmos compreender o tipo de entidade «agentIdentity» analisando os seus metadados em bruto:

… podemos explorar visualmente a hierarquia de objetos e interagir com as relações em torno de cada tipo de uma forma mais orientada para a investigação:

Os metadados indicam-nos que agentIdentity herda de servicePrincipal (com OpenType="true", o que significa que também podem existir propriedades dinâmicas ou não documentadas) e acrescenta o seguinte pequeno conjunto de elementos específicos do agente ao nível do subtipo:

• Duas propriedades:
  • agentIdentityBlueprintId (uma cadeia de caracteres obrigatória que associa a identidade do agente ao seu modelo pai)
  • createdDateTime
• Três propriedades de navegação:
  • patrocinadores (um conjunto de directoryObject)
  • inheritedAppRoleAssignments (uma coleção de appRoleAssignment)
  • inheritedOauth2PermissionGrants (uma coleção de oAuth2PermissionGrant)

As duas últimas são adições recentes ao esquema beta e são especialmente importantes porque representam o mecanismo de herança de permissões do principal «Agent Identity Blueprint» pai para a identidade do agente. A Microsoft documenta estas atribuições de funções de aplicação herdadas e estas concessões delegadas como permissões efetivas aplicadas no momento da emissão do token.

É também aqui que a diferença entre os «agentes clássicos» e os «agentes modernos» na Entra ID começa a tornar-se mais clara.

• Os agentes clássicos, como os criados pelo Copilot Studio e pelo Azure AI Foundry antes da introdução do novo modelo de ID de agente, são representados nos bastidores através de objetos de entidade de serviço normais.
• Agentes modernos, por outro lado, são representados através do novo agentIdentity subtipo.

Sabendo isso, é fácil compreender por que razão filtrar pela coluna «Agent Blueprint ID» no portal Agent ID (versão preliminar) pode ajudar a separar estes dois mundos. Os objetos com um agentIdentityBlueprintId pertencem ao novo modelo de ID de agente, ao passo que os agentes mais antigos, baseados em entidades de serviço, não pertencem.

Vale a pena referir que os metadados da v1.0 apresentam, neste momento, uma definição mais sucinta do esquema, sem os dois inherited* propriedades de navegação ativadas agentIdentity. Este tipo de discrepância entre a versão beta e a v1.0 é comum nas funcionalidades em pré-visualização, mas tem um impacto real na segurança para os responsáveis pela segurança que pretendam avaliar agentes Entra já integrados na sua organização. Qualquer ferramenta de auditoria, produto CSPM ou script de enumeração de permissões que não tenha em conta estas relações de permissões herdadas poderá não captar parte do panorama das permissões efetivas dos objetos de ID do Agente.

E se configurarmos permissões hereditárias num blueprint, concedermos consentimento de administrador ao principal do blueprint e consultarmos um agente associado a ele através de diferentes versões da API, essa lacuna torna-se visível.

Tudo o resto — todas as mais de 40 propriedades e mais de 20 propriedades de navegação do servicePrincipal objeto — é herdado estruturalmente. Isto inclui propriedades como keyCredentials, passwordCredentials, owners, federatedIdentityCredentialse memberOf.

No entanto, é precisamente aqui que o esquema nos pode induzir em erro.

A herança OData descreve a estrutura do modelo de objeto. Não garante que todas as capacidades herdadas estejam funcionalmente disponíveis em tempo de execução. A documentação da Microsoft refere explicitamente esse padrão para os recursos relacionados com o ID do agente:

…embora este recurso herde de `servicePrincipal`, algumas propriedades não são aplicáveis.

As propriedades das credenciais são o exemplo mais claro disso, uma vez que as identidades dos agentes não possuem credenciais próprias: nem palavras-passe, nem certificados, nem segredos de cliente. Dependem do blueprint pai para obter tokens em seu nome; as tentativas de adicionar credenciais diretamente a um objeto de identidade de agente são rejeitadas pela API.

Assim, embora keyCredentials e passwordCredentials aparecem no esquema herdado, são nulos ou vazios no que diz respeito às identidades dos agentes e, na prática, indisponíveis. Essa imposição não provém do próprio ficheiro de metadados. Provém de percursos de código da lógica de tempo de execução na camada da API, que têm de reconhecer o subtipo e rejeitar operações que não se devem aplicar.

O mesmo se aplica ao agentIdentityBlueprintPrincipal objeto, que também herda de servicePrincipal e acrescenta apenas a relação de proprietário na definição do seu subtipo. Tal como a identidade do agente, herda o conjunto completo de credenciais de servicePrincipal em teoria, mas, na prática, as suas credenciais são geridas através do objeto de aplicação «blueprint», e as operações realizadas nesse objeto estão associadas a medidas de proteção específicas por ponto de extremidade, verificações dinâmicas em tempo de execução, etc.

Esta é uma das lições mais importantes em matéria de segurança no modelo Agent ID: o esquema indica-nos o que o objeto herda, mas a plataforma tem, ainda assim, de garantir que o objeto cumpra as restrições que lhe são impostas.

A parte do problema que depende do utilizador

O agentUser A entidade segue o mesmo padrão de herança que temos vindo a analisar, mas, desta vez, situa-se acima da user objeto em vez de servicePrincipal.

E se sobrepor subtipos de agentes à superfície do principal de serviço é uma questão delicada, sobrepor-lhes à superfície do utilizador é, sem dúvida, ainda mais delicado. O objeto utilizador está relacionado com políticas de autenticação, licenciamento, funcionalidades de colaboração, pertença a grupos, estrutura organizacional e fluxos de atribuição administrativa que foram originalmente concebidos em torno de identidades humanas.

Analisando os metadados, agentUser herda de graph.user e não adiciona nenhuma nova propriedade nem nenhuma nova propriedade de navegação ao nível do subtipo. Por outras palavras, todas as propriedades e todos os documentado A relação que um utilizador agente mantém decorre do tipo de base de utilizadores.

Mas «zero novos atributos» não significa que não exista nenhum sinal distintivo.

O identityParentId A propriedade, que associa o utilizador agente à identidade do agente pai, é definida no próprio tipo base do utilizador. Para os humano Para os utilizadores, esta propriedade é sempre nula, mas, no caso dos utilizadores agentes, contém o ID do objeto da identidade do agente associado e é obrigatória no momento da criação. A documentação da Microsoft refere ainda que esta relação é imutável, uma vez estabelecida, e não pode ser eliminada nem alterada.

Ao contrário do que acontece no agentIdentity e agentIdentityBlueprintPrincipal objetos, a Microsoft optou, neste caso, por transferir a propriedade distintiva para o tipo pai, em vez de a definir no subtipo, o que significa que os metadados OData, por si só, não nos dirão que agentUser seja outra coisa que não um utilizador e o único sinal ao nível do esquema seja o @odata.type discriminador no próprio objeto.

Esta distinção é importante devido à finalidade para a qual os utilizadores-agente foram concebidos. Ao contrário das identidades de agente, que são objetos derivados de entidades de serviço e se autenticam através de fluxos de tokens exclusivos da aplicação, os utilizadores-agente existem especificamente para contextos em que é necessária uma identidade com características de utilizador.

Em termos de tokens, recebem tokens com o idtyp=user autorização, o que significa que podem aceder a APIs e serviços que verificam especificamente um token de utilizador em vez de um token de aplicação (Outlook, Teams, SharePoint e qualquer outro serviço que dependa do tipo de identidade), para que possam ter caixas de correio, aderir a canais do Teams e aparecer em organogramas. Uma visão de um assistente pessoal com IA em todo o seu esplendor.

A Microsoft documentou várias restrições de segurança relativas às identidades dos utilizadores dos agentes:

• Não podem ter palavras-passe nem chaves de acesso.
• Não lhes podem ser atribuídas funções de administrador com privilégios.
• As atribuições de funções personalizadas e os grupos aos quais se podem atribuir funções não estão disponíveis para eles.
• O seu modelo de permissões predefinido é semelhante ao dos utilizadores convidados, com capacidades ligeiramente mais amplas para enumerar utilizadores e grupos.

Estas são medidas de proteção importantes. No entanto, cada uma delas tem de ser aplicada na camada da API e das políticas, individualmente, para cada caminho de código que envolva um user objeto.

Essa é a parte incómoda. Se um terminal tratar agentUser como mais um user e se esquecer de aplicar as restrições específicas do subtipo, o resultado não é apenas um erro. Pode tornar-se um problema relacionado com os limites de privilégios.

Por exemplo, apesar do restrições oficiais de segurança no que diz respeito à atribuição de funções privilegiadas, durante os testes conseguimos atribuir utilizadores de agente 3 em 32 funções assinaladas com isPrivileged=true:

• Global Reader: Acesso de leitura total a todo o diretório e aos dados do Microsoft 365
• Security Reader: Acesso de leitura em ferramentas de segurança, no Microsoft Defender e na Proteção de Identidade
• Administrador de IA: Controlo administrativo sobre a IA e as funcionalidades relacionadas com os agentes

Também conseguimos atribuir muitas funções que não estão marcadas como privilegiadas (ou que são tratadas como standardAssigned) mas que, na prática, correspondem efetivamente ao Nível 0, tais como o Administrador de Faturação, o Administrador do Exchange, o Administrador do SharePoint e as Contas de Sincronização de Diretórios.

Este padrão não é novo, nem é exclusivo das identidades dos agentes.

A concessão excessiva de permissões à função de Administrador de IA e^{a descoberta da Silverfort¹} que discutimos no capítulo anterior são os exemplos mais recentes, mas inscrevem-se numa linha bem documentada de «lacunas de âmbito» do Entra ID. Nestes casos, uma permissão ou função que parece operar sobre uma classe mais restrita de objetos acaba por abranger o tipo base mais amplo ou uma superfície de controlo mais sensível do que o esperado. Os percursos clássicos de escalonamento de privilégios do «Administrador de Aplicações» e do «Administrador de Aplicações na Nuvem» são exemplos paradigmáticos disso.

Amplamente documentado por Dirk-jan Mollema²e a SpecterOps,³ estas vias de escalonamento tiram partido do facto de as funções poderem adicionar credenciais a qualquer entidade de serviço no inquilino. Se uma entidade de serviço tiver permissões de aplicações de elevado impacto, tais como RoleManagement.ReadWrite.Directory ou AppRoleAssignment.ReadWrite.All—ou a quem tenham sido atribuídas funções privilegiadas de diretório—a adição de credenciais a esse serviço pode permitir que o atacante se autentique como essa entidade de serviço e herde os seus privilégios efetivos.

A questão do âmbito aqui é subtil; a função é descrita, com toda a sinceridade, como a gestão de aplicações. O pressuposto perigoso é que «gerir aplicações» não deva significar também «ser capaz de assumir o controlo de entidades de serviço arbitrárias com privilégios elevados». A Microsoft introduziu posteriormente controlos de bloqueio das propriedades das instâncias de aplicações para reduzir parte deste risco, mas a natureza subjacente do problema continua a ser importante: o controlo sobre um objeto pode transformar-se em controlo sobre as permissões já associadas a esse objeto.

Estudo da Semperis de 2024 sobre UnOAuthorized demonstrou outra versão deste padrão. Várias entidades de serviço próprias da Microsoft (lembra-se deste tipo da taxonomia?) podiam ser utilizadas por administradores de aplicações e administradores de aplicações na nuvem para adicionar e remover utilizadores de funções privilegiadas. A questão não se resumia simplesmente a «permissões excessivas» num plano abstrato. Tratava-se de uma incompatibilidade entre os limites pretendidos para as funções e a forma como os âmbitos do OAuth 2.0 e as entidades de serviço próprias eram avaliados na prática.

Da mesma forma, o Datadog I SPy⁴A divulgação de 2025 revelou mais uma variação. Em determinados cenários, os entidades de serviço com as funções de Administrador de Aplicações na Nuvem, Administrador de Aplicações ou Application.ReadWrite.All poderia sequestrar a entidade de serviço do Exchange Online do Office 365, adicionando-lhe credenciais. Em ambientes híbridos, isto poderia ser encadeado, através de uma relação de confiança de domínios federados, até ao acesso de Administrador Global. Superfície diferente, lição igual: as permissões limitadas a «aplicações» podem tornar-se muito mais perigosas quando a aplicação visada é, ela própria, uma primitiva de confiança privilegiada.

E a vulnerabilidade «Actor Token» de Dirk-jan Mollema,^⁵ CVE-2025-55241, embora estruturalmente diferente, enquadra-se na mesma família geral. Nesse caso, tokens internos não documentados de suplantação de identidade entre serviços, combinados com uma lacuna na validação de inquilinos na API legada do Azure AD Graph, permitiram a suplantação de identidade entre inquilinos de qualquer utilizador, incluindo Administradores Globais, sem registos e sem aplicação do Acesso Condicional. A lacuna de âmbito, neste caso, situava-se no limite do inquilino e não no limite do subtipo de objeto, mas a lição fundamental é a mesma: quando uma primitiva privilegiada é introduzida sem validação rigorosa em todas as superfícies de consumo, eventualmente uma dessas superfícies torna-se um caminho de acesso.

Então, o que é que tudo isto significa?

Bem, em primeiro lugar, esse Agent ID não é um novo tipo de objeto isolado. Trata-se de um novo modelo de identidade que se sobrepõe a elementos básicos que o Entra ID já conhece muito bem: aplicações, entidades de serviço, utilizadores, autorizações OAuth, atribuições de funções a aplicações, credenciais e funções de diretório.

E, em segundo lugar, esse design é prático, mas também significa que o modelo de segurança depende de algo mais delicado. A hierarquia do esquema de metadados pode indicar-nos o que um objeto herda, mas apenas o comportamento em tempo de execução nos revela quais as capacidades herdadas que estão efetivamente acessíveis.

Esta é a principal contradição do Agent ID: a Microsoft está a atribuir aos agentes de IA um tratamento de primeira classe no Entra ID, mas fá-lo através da extensão de tipos de objetos que já carregam anos de significado em termos de segurança. Cada propriedade herdada, cada ação de função, cada fluxo de tokens e cada ponto de extremidade passa agora a fazer parte da questão.

Por isso, antes de falarmos sobre como abusar, defender ou monitorizar as Identidades de Agente, temos primeiro de compreender a natureza do próprio conceito.

E agora, espero que essa imagem esteja um pouco mais clara.

Muito bem, vamos falar de permissões

A plataforma Agent ID introduz novos tipos de identidade capazes de realizar ações autónomas, agir em nome dos utilizadores e deter permissões persistentes. Compreender o seu modelo de permissões é essencial para prevenir a escalada de privilégios e evitar percursos de acesso indesejados e de grande impacto. Este modelo introduz também um novo conceito de permissão hereditária, que precisamos de compreender.

Permissões exclusivas da aplicação e delegadas

Tal como acontece com as aplicações normais e os princípios de serviço, aos modelos de identidade de agente e às identidades de agente podem ser atribuídas permissões exclusivas da aplicação ou permissões delegadas.

Como vimos anteriormente, o modelo de identidade do agente inclui sempre uma permissão exclusiva da aplicação — AgentIdentity.CreateAsManager—por predefinição, o que lhe permite criar e gerir identidades de agentes.

No que diz respeito às identidades dos agentes, as permissões exclusivas da aplicação devem ser utilizadas quando o agente opera de forma totalmente autónoma. As permissões delegadas aplicam-se quando um utilizador está envolvido no fluxo de trabalho e o agente precisa de agir em nome desse utilizador.

Permissões herdáveis

As permissões hereditárias são uma configuração de herança de permissões definida ao nível do modelo de identidade do agente. Permitem que as identidades de agente criadas a partir do modelo herdem automaticamente as permissões aprovadas do modelo, em vez de ser necessário conceder o mesmo consentimento separadamente para cada identidade de agente.

Inicialmente, isto manifestava-se principalmente no contexto das permissões delegadas, mas a documentação atual da Microsoft descreve agora as permissões herdáveis como sendo compatíveis tanto com âmbitos delegados como com funções de aplicação. Os âmbitos delegados aparecem no token de acesso delegado da identidade do agente no scp reivindicação, enquanto as funções da aplicação aparecem no token de acesso exclusivo da aplicação no roles alegação.

Para que as permissões hereditárias entrem em vigor, não basta, por si só, configurar o modelo. É necessário que se verifiquem duas condições:

• A aplicação de recursos relevante deve ser configurada no blueprint’s inheritablePermissions.
• A autorização também deve ser concedida ao titular do blueprint.

A Microsoft descreve isto como a diferença entre declaração, concessão e herança: inheritablePermissions é uma configuração, enquanto o consentimento relativo ao entidade principal do plano é o que concede a autorização.

Isto significa que o allAllowed Esta configuração não deve ser interpretada como «o agente obtém automaticamente todas as permissões expostas pela aplicação do recurso». Significa que todas as permissões elegíveis desse tipo, para essa aplicação do recurso, que sejam concedidas ao principal do modelo podem ser transmitidas às identidades do agente. O token efetivo é, então, o resultado da fusão entre as permissões herdadas e quaisquer permissões concedidas diretamente à identidade específica do agente.

A configuração é efetuada através da aplicação de recursos, sendo que os âmbitos delegados e as funções de aplicação podem ser configurados de forma independente para o mesmo recurso. Por exemplo, um modelo pode herdar âmbitos delegados, mas não funções de aplicação; pode herdar funções de aplicação, mas não âmbitos delegados. Os exemplos da Microsoft ilustram isto utilizando inheritableScopes e inheritableRoles separadamente.

Para que as permissões delegadas e hereditárias entrem em vigor, a entidade de serviço do blueprint deve já possuir as OAuth2PermissionGrants registos para esses âmbitos, na sequência de um consentimento a nível do plano.

No que diz respeito às permissões delegadas, os padrões de herança de âmbito documentados são:

• allAllowed: Estes padrões herdam todos os âmbitos delegados disponíveis para o recurso que concederam.
• noScopes: Estes padrões não herdam quaisquer âmbitos delegados para essa aplicação de recursos.
• enumerated: Apresentados apenas na documentação da API beta, estes padrões incluem apenas os âmbitos especificados na lista. Ao utilizar o padrão enumerado, é possível incluir até 40 âmbitos por aplicação de recurso.

No que diz respeito às permissões das aplicações, os padrões de herança exclusivos da aplicação atualmente documentados são:

• allAllowed: Estes padrões herdam todos os âmbitos de aplicação disponíveis para a aplicação de recursos a que concederam acesso.
• noRoles: Estes modelos não herdam quaisquer funções de aplicação para essa aplicação de recursos.

Ora, a documentação oficial não inclui nenhuma opção enumerada para a herança exclusiva da aplicação. No entanto, após alguns testes, descobrimos que esta opção pode ser incluída no fluxo de herança exclusiva da aplicação.

O esquema seguinte ilustra o conceito subjacente às permissões enumeradas, delegadas e herdáveis. Um esquema semelhante seria aplicável às permissões exclusivas da aplicação, que funcionam de forma muito semelhante. (As diferenças serão apresentadas no Ponto de Verificação Prático 2.)

Um modelo pode definir permissões hereditárias para, no máximo, 60 aplicações de recursos. Este limite não se aplica exclusivamente aos modelos.

É igualmente importante referir que algumas permissões de alto risco do Microsoft Graph estão bloqueadas para identidades de agente. A Microsoft indica que os âmbitos de permissão delegados ou funções de aplicação bloqueados não podem ser concedidos a identidades de agente, e a inclusão de um âmbito delegado ou função de aplicação bloqueado faz com que o pedido seja rejeitado.

As permissões herdáveis são opcionais. Mesmo sem as utilizar, as permissões podem continuar a ser concedidas diretamente a cada identidade de agente, individualmente. A diferença reside no facto de as concessões diretas se aplicarem apenas a essa identidade de agente específica, enquanto as permissões herdáveis permitem que um administrador aprove as permissões uma única vez ao nível do modelo e que as permissões elegíveis sejam transferidas para as identidades de agente atuais e futuras criadas a partir desse modelo.

Pertença a um grupo (apenas para utilizadores agentes)

A adesão a grupos está limitada aos utilizadores com o papel de agente. Os utilizadores com o papel de agente podem ser adicionados a grupos de segurança, mas não a grupos aos quais se podem atribuir papéis. Herdam as permissões das suas adesões a grupos da mesma forma que os utilizadores normais.

Funções do Microsoft Entra

É possível atribuir funções do diretório do Microsoft Entra às identidades de agente, à semelhança dos entidades de serviço, mas com limitações importantes. Funções com privilégios elevados, tais como Administrador Global, Administrador de Funções Privilegiadas e Administrador de Utilizadores, não podem ser atribuídas a identidades de agente. Apenas é suportado um subconjunto definido de funções do Microsoft Entra, e algumas dessas funções continuam a ser de natureza administrativa, pelo que devem ser atribuídas com cuidado, com base na finalidade pretendida do agente e nos requisitos de privilégios mínimos.

A lista completa das funções suportadas está disponível aqui.

Pacote de acesso

Para além de atribuírem acesso diretamente a uma identidade de agente, as organizações podem utilizar pacotes de acesso. Um pacote de acesso permite que o agente ou um conjunto de agentes com as mesmas necessidades acedam aos recursos. Os pacotes de acesso podem incluir funções do Entra, pertenças a grupos de segurança, permissões delegadas OAuth2 e permissões de aplicações — todas elas já descritas anteriormente.

Os pacotes de acesso são configurados por um administrador, que define:

• Que recursos estão incluídos
• Quem pode solicitar acesso
• Quem deve aprovar o acesso
• Quanto tempo dura o acesso
• E outras definições de política

A identidade de um agente pode solicitar um pacote de acesso por conta própria, ou um patrocinador ou gestor pode solicitá-lo em nome do agente. Também pode ser atribuído diretamente pelo administrador. Uma vez aprovado, o agente recebe acesso por um período limitado aos recursos incluídos, e um patrocinador pode solicitar uma prorrogação, se necessário.

Analisar a questão das permissões

Para resumir o modelo de permissões, cada componente da plataforma Agent ID pode possuir as suas próprias permissões. As identidades de agente podem ter permissões exclusivas da aplicação ou permissões delegadas; os utilizadores de agente podem ser membros de grupos; e os modelos de identidade de agente podem definir permissões hereditárias que se aplicam a todas as identidades de agente criadas a partir deles. Dependendo do fluxo de autenticação, os elementos relevantes combinam-se durante a execução.

No caso de um fluxo «Em nome de», combinado com as novas permissões hereditárias, as permissões finais do agente ficarão assim:

Espera-se um fluxo semelhante também quando se utilizam as permissões exclusivas da aplicação com permissões herdáveis. Basta substituir todos os termos delegados por termos exclusivos da aplicação.

A seguir: Exercício sobre a definição de permissões de identidade de agentes

Agora, faça uma visita ao nosso segundo Ponto de Verificação Prático e siga os passos para atribuir permissões à identidade do agente que configurou no primeiro exercício.

Pratique a definição de permissões de identidade dos agentes.

Explore o guia

• Introdução: Compreender e prevenir ataques à identidade do agente Entra ID: Um guia completo
• Capítulo 1: Conheça as identidades dos agentes da Entra ID (a propósito, não são pessoas)
• Capítulo 2: A taxonomia das identidades de carga de trabalho no Entra ID: aplicações empresariais, entidades de serviço e outras formas de confusão organizada
• Capítulo 3: Compreender o Microsoft Agent ID e a Plataforma de Identidade do Agente
• Ponto de verificação 1: Criação de um ID de agente com o MS Graph
• Ponto de verificação 2: Definição das permissões de identidade do agente

Notas finais

1. https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
2. Escalação de privilégios no Azure AD – Assumir as permissões predefinidas da aplicação como Administrador da Aplicação – dirkjanm.io
3. Escalação de privilégios no Azure através do abuso de entidades de serviço – SpecterOps
4. I SPy: Acesso ao administrador global da Entra ID através de uma aplicação própria | Datadog Security Labs
5. Vulnerabilidade do Token do Actor