Nota do editor: Bem-vindo ao segundo «Ponto de Verificação Prática» do guia «Compreender e Prevenir Ataques à Identidade do Agente Entra ID: Um Guia Abrangente». Ao longo da série, utilize estes pequenos tutoriais práticos para explorar os objetos e comportamentos que abordámos. Para rever os capítulos anteriores e praticar as lições, comece aqui.
No nosso primeiro «Practice Checkpoint», aprendeu a definir o ID do agente e a criar o seu primeiro utilizador de agente.
Agora que os objetos principais já existem, vamos configurar o modelo de permissões da mesma forma que aparece em implementações reais: permissões diretas na identidade do agente e permissões herdadas concedidas ao nível do blueprint.
Este ponto de verificação define os dados de entrada exatos que iremos validar posteriormente nos tokens ao longo dos fluxos de autenticação.
Atribuir permissão à identidade do agente
Para demonstrar as permissões «diretas» exclusivas da aplicação ao nível da identidade do agente, atribua uma função de aplicação a <agent-identity-id> utilizando o mesmo appRoleAssignments padrão como anteriormente.
Nesta demonstração, o appRoleId representa User.Read.All. Vamos utilizá-la mais tarde para nos autenticarmos com a identidade do agente e para listar os utilizadores.
Configurar permissões herdáveis
Configure as permissões hereditárias para que o agente possa herdar os âmbitos delegados nos fluxos delegados.
Passo 1: Conceder a autorização delegada
Criar um oauth2PermissionGrants registo que concede Group.Read.All para o modelo de identidade do agente (fluxo padrão de consentimento delegado).
Passo 2: Marcar como hereditário
Ligue para o /applications/microsoft.graph.agentIdentityBlueprint/<blueprint-id>/inheritablePermissions ponto final e inclua o ID da aplicação do recurso do Graph. Utilize um âmbito enumerado para que a identidade do agente herde apenas o Group.Read.All permissões.
Num cenário de autenticação delegada, iremos ver e utilizar essas permissões para listar os grupos de inquilinos. Se pretender que todas as permissões sejam herdadas, basta definir tipo para allAllowed em vez de enumerated e remova a propriedade «scopes».
Embora não esteja documentado, é possível herdar permissões enumeradas exclusivas da aplicação. Em vez de âmbitos, iremos utilizar appRoleIds, que exigem o GUID da função da aplicação. Assim, o pedido terá o seguinte aspeto:
Também pode definir ambas ao mesmo tempo. Para atualizar as permissões herdáveis existentes, envie um pedido «Patch» para o recurso relevante que pretende atualizar.
PATCH /applications/microsoft.graph.agentIdentityBlueprint/<blueprint-id>/inheritablePermissions/<resource-app-id>
A seguir: Vamos descobrir como a identidade do seu agente se autentica e funciona no Entra ID.
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
- Capítulo 4: Identidades dos agentes: análise aprofundada do design
- Capítulo 5: O Registo de Agentes e o Funcionamento das Identidades dos Agentes no Entra ID
- Ponto de verificação 3: Registo de um agente — com e sem ID de agente
- Ponto de verificação 4: Verificação de tokens e reivindicações em três fluxos de autenticação do Entra ID
- Capítulo 6: Onde as coisas podem correr mal com as identidades dos agentes no Entra ID — e como evitar o desastre
