Semion Vasilevitzky e Jonathan Elkabas

É aqui que o nosso guia passa a abordar temas mais técnicos, por isso vamos analisá-lo com cuidado.

Começemos pelo princípio: em termos simples, o termo «identidade de carga de trabalho» é um conceito abrangente que a Microsoft utiliza para descrever vários tipos de identidades não humanas que operam no âmbito do Entra ID. Estas identidades permitem que aplicações, serviços, recursos na nuvem, cargas de trabalho de automatização — e agora também agentes —se autentiquem e interajam com outros sistemas com pouca ou nenhuma intervenção humana.

Eis o ponto importante: todas as identidades de carga de trabalho, incluindo os tipos de identidade de agente recentemente introduzidos, acabam por corresponder a um único tipo de objeto subjacente: o «Service Principal».

E, sinceramente, isso faz sentido.


Como encarar os Service Principals

O servicePrincipal A entidade é provavelmente o objeto de identidade mais versátil do Entra ID. Se analisarmos o seu esquema através do ponto de extremidade $metadata do Microsoft Graph OData, o número de propriedades, propriedades de navegação e ações associadas expostas por este objeto já nos diz muito sobre o seu papel na plataforma.

Figura 1. Os «Service Principals» desempenham inúmeras funções no Entra ID.

Essa base do principal de serviço está a realizar um trabalho discreto, mas importante, neste contexto. Estabelece ligação com muitas das interfaces e subsistemas que o Entra ID opera para suportar funcionalidades como a gestão de credenciais, a concessão de autorizações OAuth, a atribuição de funções às aplicações, a adesão a grupos, a propriedade, a avaliação do Acesso Condicional, os mecanismos RBAC, a auditoria e o registo de inícios de sessão.

Assim, quando a Microsoft desenvolveu as identidades de agente, não optou por criar uma primitiva de identidade totalmente nova a partir do zero, mas sim por alargar uma já existente.

Tal como indicado na documentação, ambos agentIdentity1 e agentIdentityBlueprintPrincipal2 os objetos (que iremos abordar mais detalhadamente num capítulo posterior) são tipos especializados de entidades de serviço que representam instâncias de identidade de agentes no ecossistema do Microsoft Entra ID. Na prática, isto significa que herdam a arquitetura existente das entidades de serviço, incluindo as vantagens, a compatibilidade com as APIs existentes e, naturalmente, parte da complexidade.


É aqui que a arquitetura se torna relevante em termos de segurança.

Um bom exemplo é adescoberta³ divulgada pela equipa da Silverfort há pouco tempo.

Quando a Microsoft introduziu a função de Administrador de ID de Agente para gerir o novo plano de controlo de identidades de agente, foi documentado que o seu âmbito se limitava estritamente a objetos relacionados com agentes. Na prática, esse limite não se manteve. As identidades às quais era atribuída apenas esta função podiam assumir o controlo de entidades de serviço arbitrárias, incluindo aquelas que nada tinham a ver com identidades de agente, adicionando-se a si próprias como proprietárias, adicionando credenciais à entidade de serviço e, em seguida, autenticando-se como essa entidade.

Trata-se de uma aquisição total da empresa principal.

A causa provável está diretamente relacionada com o modelo descrito acima.

Se agentIdentity e agentIdentityBlueprintPrincipal os objetos são implementados com base no servicePrincipal base, então a camada de autorização deve distinguir de forma fiável entre entidades de serviço suportadas por agentes e entidades de serviço «normais». Essa distinção tem de ser aplicada de forma explícita.

Esta é uma das razões pelas quais a Microsoft introduziu novas funções de diretório (Administrador de ID de Agente, Desenvolvedor de ID de Agente e Administrador de Registo de Agentes) e funções de gestão específicas para objetos (proprietário, patrocinador e gestor), a par do novo modelo de identidade de agente.

Conceitualmente, estas funções devem gerir a nova superfície específica do agente:

  • Identidades dos agentes
  • Princípios do modelo de identidade do agente
  • Modelos de identidade de agentes
  • Utilizadores do agente

A sua autoridade deve ser limitada ao modelo de agente, e não a todos os entidades de serviço do inquilino.

Como nota à parte interessante e não propriamente curta , o modelo RBAC visível nem sempre mostra claramente toda a superfície do agente. Atualmente, a documentação da Microsoft relativa ao Agent ID Administrator refere-se às «Ações» mais amplas relacionadas com o agente, que são entradas de permissão que definem quais as operações que uma função de diretório está autorizada a realizar em relação a tipos específicos de recursos.

Seguindo a documentação oficial, a Silverfort especulou (com toda a razão!) que ações como microsoft.directory/agentIdentities/owners/update e microsoft.directory/agentIdentityBlueprintPrincipals/owners/update vazou da função integrada para o plano de controlo do entidade de serviço geral.

No entanto, ao consultar a definição da função ativa através do Microsoft Graph, o visível allowedResourceActions parecem centrar-se apenas em agentUsers/*.

Figura 2. Consulta que identifica as ações permitidas aos utilizadores do agente.

E enumerando as variáveis declaradas microsoft.directory As ações relacionadas com recursos revelam a mesma discrepância: 18 registos relacionados com agentes, todos sob agentUsers/*. Nenhum para os subtipos da camada de entidade de serviço (agentIdentities/*, agentIdentityBlueprintPrincipals/*e agentIdentityBlueprints/*). O que, basicamente, significa que nenhuma função as inclui.

Figura 3. Não se verifica qualquer papel para os subtipos da camada de entidade de serviço.

Uma observação um pouco semelhante aplica-se à função de Administrador de IA.

Ao contrário do Administrador de ID de Agente, que parece ser uma função altamente específica para a gestão do plano de controlo da ID de Agente, é muito mais provável que a função de Administrador de IA seja delegada de forma mais abrangente. As suas responsabilidades documentadas centram-se no Microsoft 365 Copilot, nos serviços de IA, nos agentes Copilot, nas análises de utilização, no estado dos serviços e nas operações de suporte.

Por outras palavras, parece tratar-se de uma função relacionada com as operações de IA, e não de um controlo total sobre o plano de identidade subjacente do Agent ID.

Mas, na prática, a função parece ter capacidades quase idênticas ao nível do plano de controlo do Agent ID, tal como o Administrador do Agent ID. 17 das 17 operações que testámos produziram resultados idênticos para ambas as funções. Isto significa que qualquer pessoa com a função de Administrador do Agent ID pode assumir a propriedade de qualquer identidade de agente no inquilino, atribuir credenciais a qualquer modelo e herdar quaisquer permissões de aplicação que os administradores tenham concedido a esses modelos.

Figura 4: Comparação entre as funções de «Administrador de IA» e «Administrador de ID de Agente»

Apesar de as duas funções indicarem valores ligeiramente diferentes allowedResourceActions, e apesar de ambas herdarem da base «Directory Readers», da qual quase todas as funções privilegiadas herdam (o que contribui com 55 ações apenas de leitura), a diferença efetiva limita-se às seguintes ações:

Figura 5: Diferenças específicas entre as funções de Administrador de IA e de Administrador de ID de Agente

Esses detalhes não constam na própria conclusão da Silverfort, mas são úteis no contexto. Mostram que parte do plano de controlo da identidade do agente não está representada como um vocabulário RBAC claro e totalmente visível. Parte da autoridade sobre os objetos relacionados com os agentes parece ser aplicada a um nível mais profundo da camada da API (por exemplo, proteções de reforço de segurança por ponto de extremidade, substituições vinculadas a IDs de modelo, verificações dinâmicas em tempo de execução). Isto também explica por que razão os objetos da aplicação não foram afetados, uma vez que a falha não se situava na gestão da propriedade.


E isso leva-nos de volta à questão da segurança.

A herança confere aos sistemas de identidade a sua flexibilidade, consistência e reutilização. No entanto, sem limites de âmbito bem definidos, pode também alargar a superfície de ataque a todos os objetos envolvidos.
Contudo, a hierarquia de herança é apenas uma das variações do modelo de entidade de serviço. Para além de partilharem a mesma arquitetura de objetos subjacente, as entidades de serviço são também categorizadas logicamente em diferentes tipos de identidade.


Tipos de entidades de serviço lógicas — e onde falham

Ao longo do último ano, tive a oportunidade de viajar e apresentar o EntraGoat, um laboratório de código aberto e deliberadamente vulnerável que criámos na Semperis para partilhar e simular cenários reais de ataques à identidade no Microsoft Entra ID.

O feedback foi excelente, mas o que mais me marcou foram as conversas que se seguiram. Um tema surgiu repetidamente: as aplicações e os princípios de serviço são muito mais complexos do que parecem à primeira vista.

Assim, esperamos aqui desvendar essa complexidade e lançar alguma luz sobre os ataques a que estas identidades estão sujeitas.

O tipo de um entidade de serviço pode ser identificado através do servicePrincipalType propriedade enum, que a Entra ID atribuiu internamente para indicar a categoria lógica da identidade.

De acordo com a Microsoft, documentação relativa ao servicePrincipal tipo de recurso, este campo pode conter cinco valores principais:

  • Aplicação
  • Identidade Gerida
  • Legado
  • SocialIdp
  • Identidade do Serviço

Na minha experiência, estas identidades estão entre os objetos mais poderosos do Entra ID, situando-se frequentemente no centro de percursos de acesso críticos.

Compreender como estes tipos de entidades de serviço se comportam, de onde provêm, como se autenticam e o que os distingue uns dos outros é essencial para compreender como o Entra ID funciona, na realidade, nos bastidores.


Compreender os 5 principais valores dos «service principal» no Entra ID

Vamos começar a mapear os tipos de entidades de serviço lógicas no panorama de identidades da carga de trabalho.

Figura 6. A taxonomia das identidades de cargas de trabalho no Entra ID

Um grande agradecimento a Eric Woodruff, Arquiteto-Chefe de Identidade da Semperis, por ter sido o primeiro a dar a conhecer esta taxonomia e por ma ter mostrado.


Aplicações

Conforme detalhado no diagrama de identidades de carga de trabalho acima, o primeiro grupo que inicia entidades de serviço num inquilino do Entra ID provém das aplicações que todos utilizamos e reconhecemos, tais como o Microsoft Teams, o Salesforce ou sistemas desenvolvidos internamente, como um portal de RH.

Um objeto Application representa a definição global de uma aplicação. É criado no inquilino onde a aplicação foi originalmente criada (pode ser visualizado na interface de utilizador de registos de aplicações ) e serve como modelo ou esboço que define a configuração de identidade da aplicação, incluindo URIs de redirecionamento, permissões de API necessárias, credenciais e outras definições. Isso significa que o objeto descreve como o IdP pode emitir tokens que permitem aos clientes aceder à aplicação, os recursos aos quais a aplicação poderá precisar de aceder e as ações ou permissões que a aplicação pode executar dentro de um inquilino.

Para permitir e integrar tudo isso, e como se pode ver no ponto de extremidade da API $metadata, o objeto «application» é também um objeto complexo (e muito relevante para as identidades dos agentes!) com muitas propriedades e métodos diferentes.

Figura 7. O objeto «Application service principal», de elevada complexidade

A Objeto «Service Principal» com servicePrincipalType : application representa a instância dessa aplicação num inquilino específico e pode ser visualizada no Aplicações empresariais UI. Trata-se do princípio de segurança que o Entra ID utiliza efetivamente durante os fluxos de autenticação e autorização.

A entidade de serviço permite que a aplicação inicie sessão ou aceda a recursos dentro desse diretório e armazena dados específicos do inquilino, tais como permissões concedidas, consentimento administrativo e atribuições de funções à aplicação. Ou seja, a entidade de serviço é o objeto que obtém tokens, possui permissões, aparece nos registos de início de sessão —e é alvo de ataques.


Qual é a diferença entre aplicações e entidades de serviço?

Pela nossa experiência, a distinção entre objetos de aplicação e objetos de entidade de serviço é um dos conceitos mais frequentemente mal compreendidos no Entra ID.

Para tentar esclarecer a diferença, listámos os exemplos seguintes, que mostram como se relacionam, mantendo-se, no entanto, muito distintos. Se já estiver familiarizado com o tema, sinta-se à vontade para dar uma vista de olhos aos pontos.

  • Um objeto de aplicação existe apenas no seu inquilino de origem.
  • Uma aplicação de inquilino único tem exatamente um entidade de serviço, que existe apenas no mesmo inquilino (de origem).
  • Quando uma aplicação multilocatária é autorizada num locatário externo, apenas é criada aí uma entidade de serviço, não sendo criado qualquer objeto de aplicação.
  • O appId A propriedade (ID da aplicação / ID do cliente) identifica a definição do objeto de aplicação e é único a nível global entre todos os inquilinos da Entra ID. É atribuído no momento da criação e nunca se altera.
  • O appId A propriedade de um entidade de serviço corresponde sempre à appId do respetivo objeto de aplicação. É por isso que a mesma aplicação própria (como o Microsoft Graph) partilha o mesmo appId em todos os inquilinos a nível mundial.
  • Cada entidade de serviço tem a sua própria id (ID do objeto) que é único no âmbito do inquilino em que se encontra.
  • As atribuições de funções da aplicação e as concessões de permissões OAuth2 são atribuídas à entidade de serviço, e não ao objeto da aplicação; por isso, dois inquilinos podem dar o seu consentimento à mesma aplicação com âmbitos de permissão completamente diferentes.
  • As credenciais adicionadas diretamente a uma entidade de serviço têm o seu âmbito limitado apenas a esse inquilino específico e não podem ser utilizadas fora dele.
  • As credenciais adicionadas ao objeto da aplicação são herdadas por todas as entidades de serviço em todos os inquilinos onde a aplicação foi autorizada, o que permite um vetor de ataque entre inquilinos.
  • A eliminação de um objeto de entidade de serviço num inquilino não afeta o objeto de aplicação (nem as entidades de serviço noutros inquilinos), uma vez que o ciclo de vida de cada entidade de serviço é independente.
  • A eliminação do objeto de aplicação no inquilino principal remove automaticamente a entidade de serviço do inquilino principal, mas não remove as entidades de serviço noutros inquilinos (estas permanecem até serem explicitamente removidas).
  • Até 1 de abril de 2026, e em alguns cenários específicos, era possível utilizar uma aplicação sem criar uma entidade de serviço; no entanto, esta «autenticação sem entidade de serviço» já não deverá ser suportada.

Tipos de objetos de aplicação

Todos os entidades de serviço associadas a aplicações provêm, em geral, de uma das três categorias lógicas de aplicações.

Figura 8: Três categorias de entidades de serviço associadas a aplicações

Identificação dos tipos de aplicações

As aplicações próprias da Microsoft são aplicações detidas e geridas pela Microsoft que fornecem serviços do Azure e do M365, tais como o Exchange Online, o SharePoint, o Microsoft Graph e centenas de outros. Estas aparecem no seu inquilino quando um utilizador dá o seu consentimento, quando um administrador lhes concede acesso ou quando a Microsoft as provisiona automaticamente ao ativar um serviço ou uma licença (como o E5, o Defender ou o Intune).

Para identificar esses tipos de identidades de carga de trabalho, basta verificar o appOwnerOrganizationId Propriedade GUID num objeto de entidade de serviço. Nas aplicações próprias da Microsoft, esta propriedade está normalmente definida com o ID do inquilino da Microsoft (f8cdef31-a31e-4b4a-93e4-5f571e91255a), embora alguns utilizem outros IDs de inquilino pertencentes à Microsoft.

Figura 9. As aplicações próprias da Microsoft têm normalmente a propriedade GUID «appOwnerOrganizationId» definida com o ID do inquilino da Microsoft.

É importante compreender que, embora possam aparecer nos registos de início de sessão, a maioria dos entidades de serviço próprias está oculta, por predefinição, no painel «Aplicações Empresariais» da interface do utilizador do Portal do Azure, mas continua a poder ser consultada através da API do Graph.

Isto deve-se ao facto de a guia da interface do utilizador filtrar com base no WindowsAzureActiveDirectoryIntegratedApp etiqueta, que normalmente identifica as aplicações integradas com o Entra ID; no entanto, os próprios entidades de serviço da Microsoft (deliberadamente) não a possuem.

Além disso, as aplicações próprias da Microsoft funcionam com mecanismos de autorização internos que vão além dos âmbitos padrão do OAuth, o que significa que as suas permissões efetivas podem exceder o que é visível através das concessões de permissão e não podem ser totalmente auditadas por meio de consultas padrão à API Graph.

Figura 10. As permissões das aplicações próprias da Microsoft podem não estar visíveis através de consultas padrão à API Graph.

O próximo tipo lógico de objetos de aplicação são as suas próprias aplicações, também conhecidas como aplicações de registo.

Trata-se de aplicações registadas diretamente por administradores ou programadores através da funcionalidade «Registos de Aplicações ». Neste caso, a organização é proprietária do objeto da aplicação e pode controlar totalmente a sua configuração, credenciais e permissões. É criada automaticamente uma entidade de serviço correspondente no locatário principal durante o registo.

Para identificar as entidades de serviço criadas a partir de aplicações registadas pela nossa organização, à semelhança do que fazemos ao filtrar as aplicações próprias da Microsoft, podemos enumerar todas as entidades de serviço cujo appOwnerOrganizationId está definido com o nosso ID de inquilino.

Figura 11. Visualização de uma entidade de serviço configurada com o nosso próprio ID de locatário

O último tipo de aplicação suportada é o das aplicações de terceiros/da galeria.

Trata-se de aplicações SaaS integradas através da Microsoft Entra App Gallery, tais como o Salesforce, o ServiceNow ou o Zoom. Tal como referido anteriormente neste capítulo, quando é concedido consentimento para uma destas aplicações num inquilino, é criada localmente uma entidade de serviço (que remete para o objeto de aplicação multilocatária do fornecedor).

Para identificar os principais de serviço criados por aplicações de terceiros — ou seja, aplicações que não foram registadas no nosso inquilino e que não são propriedade da Microsoft —, basta excluir tanto o ID do nosso inquilino como o ID do inquilino da Microsoft do conjunto completo de principais de serviço no lado do cliente (uma vez que o Microsoft Graph não suporta ne filtros ativados appOwnerOrganizationId).

Figura 12. Visualização de uma entidade de serviço criada por uma aplicação de terceiros

Vulnerabilidade de exploração na aplicação

Como já dissemos (provavelmente demasiadas vezes até agora), cada um desses três tipos de aplicação instancia um objeto de entidade de serviço local no seu tenant. A entidade de serviço é a identidade em tempo de execução: contém as concessões de permissão, a configuração de SSO e as definições específicas do protocolo que o Entra ID aplica no momento da autenticação.

Ao analisar o preferredSingleSignOnMode Com base na propriedade do objeto principal do serviço, o Entra ID determina qual o protocolo SSO utilizado pela aplicação. Os valores possíveis são:

  • saml: A aplicação utiliza o SAML 2.0, sendo que o Entra ID atua como fornecedor de identidade e emite asserções SAML assinadas.
  • oidc: A aplicação utiliza o OpenID Connect / OAuth 2.0, o protocolo moderno baseado em tokens.
  • palavra-passe: SSO baseado em palavra-passe, em que o Entra ID introduz as credenciais no formulário de início de sessão da aplicação em nome do utilizador.
  • notSupported: Não está configurado qualquer SSO através do Entra ID.
  • null: Indica aplicações SAML mais antigas ou aplicações OIDC em que o valor não foi definido automaticamente; também é utilizado para outros tipos lógicos de entidades de serviço (como veremos em breve).

Do ponto de vista da segurança, o modo SSO tem implicações diretas. As aplicações SAML dependem de um certificado de assinatura de tokens configurado na própria entidade de serviço. Se um atacante obtiver acesso à chave privada deste certificado, poderá falsificar asserções SAML e autenticar-se como qualquer utilizador em quem a aplicação confie.

Os investigadores da Semperis demonstraram exatamente este cenário no blogue de investigação «Meet Silver SAML: Golden SAML in the Cloud», mostrando que a importação de um certificado de assinatura gerado externamente para uma entidade de serviço (em vez de utilizar o certificado autoassinado integrado do Entra ID) cria um vetor de ataque explorável que não requer qualquer interação com o Entra ID.


Experimenta tu mesmo no EntraGoat

Uma vez que nada ilustra melhor a forma como os «service principals» moldam o panorama atual das ameaças à identidade do que observar o fenómeno a ocorrer num laboratório, várias das vias de escalada de privilégios mais impactantes no EntraGoat — o laboratório Entra ID deliberadamente vulnerável que criámos aqui na Semperis — foram concebidas inteiramente em torno deles.

Os cenários variam quanto ao ponto de partida e ao método, mas o padrão é intencionalmente consistente: basta encontrar um caminho para uma entidade de serviço baseada numa aplicação e o caminho para o comprometimento de todo o inquilino tende a ser mais curto do que qualquer um imagina.

Se quiseres ver como é todo o processo, do início ao fim, o EntraGoat é um bom ponto de partida. Lê mais e segue os tutoriais na nossa série de artigos do blogue.

Figura 13. Exemplo de percurso de ataque do Cenário 6 do EntraGoat

Identidades geridas

As identidades geridas são, de certa forma, a tentativa da Microsoft de resolver um problema que nós próprios criámos: a gestão de credenciais.

Cada identidade, e em particular as identidades não humanas, que se autenticam através de segredos do cliente (palavras-passe, chaves de acesso ou certificados) apresenta um desafio relacionado com o ciclo de vida desse segredo (rotação, armazenamento, expiração e fuga de informação). A implementação das identidades geridas procurou eliminar este fardo, transferindo a gestão de credenciais inteiramente para o plano de controlo do Azure. A identidade existe; autentica-se, mas nenhum ser humano toca (ou utiliza indevidamente) uma credencial associada à mesma.


Tipos de identidades geridas

Qualquer recurso que suporte a autenticação Entra ID (como uma máquina virtual, um App Service, um Logic App, um cluster do Kubernetes e muitos outros serviços e tipos de recursos do Azure) pode utilizar identidades geridas para obter tokens e aceder a outros recursos.

Existem dois tipos:

  • As identidades geridas atribuídas pelo sistema são criadas como parte integrante e no contexto do próprio recurso do Azure. A relação é estritamente 1:1. Um recurso, uma identidade, um ciclo de vida. A identidade não pode existir de forma independente, não pode ser partilhada e é automaticamente eliminada quando o recurso é eliminado. Este forte acoplamento constitui também a sua principal vantagem em termos de segurança.
  • Por outro lado, as identidades geridas atribuídas pelo utilizador são recursos autónomos do Azure. Podem ser associadas a um ou mais recursos, e o seu ciclo de vida é independente dos recursos que as utilizam. Esta natureza de desacoplamento da identidade gerida atribuída pelo utilizador constitui uma vantagem operacional e, naturalmente, um compromisso em termos de segurança.
Figura 14. Tipos de identidade gerida

Identificação de identidades geridas

Identificar os principais de serviço que representam identidades geridas no Entra ID é bastante simples. Basta consultar o diretório para obter os servicePrincipalType propriedade definida como ManagedIdentity.

Figura 15. Identificação de identidades geridas no Entra ID

Na verdade, ambos os tipos de identidade são autenticados através de pontos de extremidade controlados pelo Azure — tais como o Serviço de Metadados de Instâncias (IMDS) em 169.254.169.254—ou através de pontos de extremidade de identidade disponibilizados por serviços como o App Service e o Functions. O fluxo de aquisição do token decorre inteiramente no Azure e nenhum segredo é transmitido pela rede, nem são armazenadas credenciais no Key Vault (ou, pior ainda, em appsettings.json), ou mesmo disponibilizados aos programadores.

Ao contrário das entidades de serviço associadas a aplicações, as identidades geridas não estão associadas a um objeto de aplicação no diretório, pelo que não há registo de aplicação, nem manifesto, nem URIs de redirecionamento. Além disso, não são visíveis para o utilizador e não participam em quaisquer protocolos de SSO.

Lembra-te do preferredSingleSignOnMode propriedade de que falámos anteriormente? Esperamos que agora compreenda por que razão essa e outras propriedades específicas da autenticação são normalmente nulas para identidades geridas. Estas não se autenticam através de fluxos SAML, OIDC ou baseados em palavra-passe. Em vez disso, o Azure emite e gere certificados com um período de validade de 90 dias, renovando-os a cada 45 dias, para cada identidade gerida.

Estes certificados são emitidos por Microsoft.ManagedIdentity e incluir o ID do objeto do principal do serviço de identidade gerida no assunto do certificado. O Azure utiliza-os para realizar a autenticação baseada em certificados e emitir tokens diretamente através do seu plano de controlo, sem expor as credenciais ao inquilino (ou aos seus administradores).

Parte deste mecanismo pode ser observada através do keyCredentials propriedade no objeto de entidade de serviço da identidade gerida.

Figura 16. O keyCredential propriedade de uma identidade gerida

Ao contrário das entidades de serviço associadas a aplicações, nas quais keyCredentials Normalmente, contém certificados carregados por um administrador ou programador; no caso das identidades geridas, as credenciais das chaves são preenchidas e renovadas inteiramente pelo Azure.

E, ao consultar a propriedade, vemos de facto um AsymmetricX509Cert entrada com a opção «Utilização» definida como «Verificar», tendo o ID do objeto principal do serviço como assunto do certificado.

Figura 17. Uma consulta rápida revela que a utilização das credenciais está definida para Verify nesta identidade gerida.

Este projeto é elegante, até o observarmos da perspetiva de um atacante.


Explorações de identidades geridas

Existem dois padrões distintos de abuso que vale a pena compreender e que mostram como o modelo começa a adaptar-se quando a teoria se depara com as necessidades da realidade.

A primeira é o roubo de tokens através do recurso em anexo.

Uma vez que as identidades geridas se autenticam através de pontos finais locais (IMDS ou o ponto final de identidade da plataforma), qualquer entidade com acesso (ou seja, que possa executar código no recurso subjacente) pode solicitar um token em nome da identidade gerida.

Este é o vetor de ataque clássico e bem documentado:

  1. Comprometer um utilizador com acesso a uma VM / Registo de contentores / Arc / AKS / Contas de automatização / Serviços de aplicações / Logic Apps / Scripts de implementação / Data Factory
  2. Consultar o ponto final do token de alguma forma (Invoke-WebRequest 169.254.169.254/metadata/identity/oauth2/token)

Se isto devolver algum resultado, significa que já dispõe de um token OAuth válido, com o âmbito das permissões que essa identidade tem para utilizar nas APIs do Azure.

Embora esta técnica se aplique tanto às identidades geridas atribuídas pelo sistema como às atribuídas pelo utilizador, a superfície de ataque varia diretamente em função do contexto da identidade.

No caso de identidades geridas atribuídas pelo utilizador e partilhadas entre vários recursos, uma única identidade comprometida pode ser utilizada para solicitar tokens para todos os recursos sobre os quais tenha permissões. Um caso clássico de movimento lateral.

Ou, tal como é explicado resumidamente no Microsoft Learn:

O limite de segurança das identidades geridas para recursos do Azure é o próprio recurso onde a identidade é utilizada. Todo o código ou scripts em execução numa máquina virtual podem solicitar e recuperar tokens para quaisquer identidades geridas disponíveis nessa máquina.

O segundo padrão de abuso é o abuso de credenciais federadas, que compromete o modelo de confiança subjacente às identidades geridas.

Como vimos há pouco, as identidades geridas atribuídas pelo utilizador não suportam a configuração de credenciais tradicionais; é explicitamente proibido modificar estas propriedades na entidade de serviço que representa a identidade gerida no Entra ID. No entanto, suportam credenciais de identidade federada. Estas permitem que fornecedores de identidade externos (como o GitHub Actions ou qualquer emissor compatível com OIDC, incluindo um auto-hospedado) se autentiquem como a identidade gerida sem qualquer troca de segredos.

Não vamos aprofundar muito os detalhes de implementação aqui, uma vez que este capítulo já se desviou bastante do tema, mas, a um nível geral, isto pode ser feito criando um federatedIdentityCredential objeto na entidade de serviço da identidade gerida através da API ARM, especificando um URL do emissor OIDC e um identificador de sujeito.

Posteriormente, no momento da autenticação, o Entra ID valida o token externo em relação ao emissor configurado e verifica a correspondência com a reivindicação do sujeito. No entanto, não valida a relação de propriedade entre o emissor e o inquilino ou recurso da identidade gerida.

Isto significa que qualquer diretor com o Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write A ação na permissão RBAC do Azure (que inclui várias funções integradas, como Colaborador, Proprietário e Colaborador de Identidade Gerida) permite adicionar uma nova credencial federada que aponte para um repositório externo ou ambiente sob o seu controlo.

Assim que essa credencial estiver configurada, o atacante autentica-se a partir do seu próprio fluxo de trabalho do GitHub (ou de qualquer ambiente compatível com OIDC), recebe um token válido para a identidade gerida e opera com o seu conjunto completo de permissões (inteiramente a partir do exterior dos limites do recurso do Azure).

Figura 18. Obtenção de credenciais para uma identidade gerida

Em ambos os casos, a questão central é a mesma: as identidades geridas foram concebidas para eliminar o risco associado às credenciais dentro dos limites de um recurso, mas o próprio modelo de permissões do Azure permite que esses limites sejam alargados (ou totalmente contornados) por qualquer pessoa com acesso RBAC suficiente.

A identidade destina-se a existir num contexto de execução específico, mas o acesso à mesma nem sempre se mantém dentro desse contexto. No primeiro caso, pode ser assumida ao obter-se a execução de código num recurso ao qual a identidade gerida está associada. No segundo caso, pode ser assumida através de uma relação de confiança federada que não requer, de todo, qualquer ligação real ao recurso original do Azure.


Identidades «Legacy» e «SocialIdp»

Os dois tipos de identidades de entidade de serviço seguintes são «Legacy » e «SocialIdP». Ambos são menos relevantes para o objetivo principal deste guia, pelo que iremos abordá-los apenas brevemente.

O tipo «Legacy» representa aplicações mais antigas, criadas antes do modelo moderno de registo de aplicações ou através de experiências legadas. O appId Existe uma propriedade nessa entidade, mas não aponta para um registo de aplicação. Uma entidade de serviço legada pode ainda ter credenciais e URLs de resposta que os administradores podem gerir diretamente, e só pode ser utilizada no inquilino onde foi criada.

O tipo SocialIdp é documentado pela Microsoft como «para uso interno», pelo que há menos informações públicas disponíveis. Com base no seu nome e no contexto de utilização, é provável que represente fornecedores de identidade social (como o Google ou o Facebook) configurados para fluxos de utilizadores B2C. Na prática, este tipo permite que o B2C se federar com fornecedores sociais externos, mas normalmente não irá interagir diretamente com ele, a menos que esteja a trabalhar com políticas personalizadas do B2C.


ServiceIdentity: O tipo de entidade de serviço para os agentes

Isto leva-nos à mais recente categoria deste ecossistema: o ServiceIdentity, o modelo de identidade introduzido para apoiar as operações digitais baseadas em agentes.

As identidades dos agentes assentam em dois conceitos fundamentais do Entra ID: o objeto «Application» e o objeto «Service Principal». É por isso que, para compreender como funcionam as identidades dos agentes e qual é o seu «potencial», tivemos primeiro de compreender os diferentes modelos dos quais estas herdam.

Figura 19. As identidades dos agentes baseiam-se em objetos de entidade de serviço e de aplicação.

Em termos gerais, o agentIdentityBlueprint, que é um subtipo de aplicação, define o modelo do agente e armazena as credenciais. O agentIdentity, um subtipo de servicePrincipal com propriedadeservicePrincipalType definido como ServiceIdentity, é o objeto de tempo de execução por agente que obtém permissões e interage com os recursos.

Esta distinção é importante porque as identidades dos agentes não possuem credenciais próprias.

Em vez disso, recorrem ao blueprint para adquirir tokens em seu nome através de um modelo de suplantação de identidade. O blueprint autentica-se utilizando as suas próprias credenciais e efetua uma troca de tokens, em que o token resultante identifica o agente como sendo o cliente, apesar de ter sido o blueprint a realizar a autenticação propriamente dita.

Como se pode ver no diagrama, há também um terceiro objeto (Atenção, spoiler: há também um quarto) no modelo: o agentIdentityBlueprintPrincipal, que herda de servicePrincipal e funciona como a representação do blueprint no ambiente de execução local do inquilino. É criado quando um blueprint é instanciado num inquilino e é o que permite que o blueprint obtenha tokens exclusivos da aplicação para criar e gerir identidades de agentes.

Outra distinção arquitetónica importante é o modelo de relação. As aplicações tradicionais seguem normalmente uma relação de um para um entre o objeto da aplicação e a entidade de serviço no inquilino de origem, enquanto as aplicações multilocatárias criam uma entidade de serviço por cada inquilino onde a aplicação é utilizada. O modelo de agente acrescenta mais uma camada: um único modelo pode gerar várias entidades de serviço de identidade de agente, tanto dentro de um mesmo inquilino como entre inquilinos.

Compreender esta separação é fundamental para compreender tanto a arquitetura como a superfície de ataque, uma vez que as identidades dos agentes não são apenas «mais um tipo de entidade de serviço».

Num capítulo posterior, vamos aprofundar um pouco mais esta arquitetura, analisar o que o ponto final de metadados OData do Microsoft Graph revela sobre estas relações entre objetos, quais as camadas de autorização que provavelmente estão implementadas e fazer algumas suposições fundamentadas sobre onde poderão surgir futuras vulnerabilidades.

Mas, antes de mais, vamos analisar a estrutura que a Microsoft criou para autenticar, autorizar, gerir e proteger estas identidades não humanas.

Fique atento ao próximo capítulo: Compreender o Microsoft Agent ID e a Plataforma de Identidade do Agente.


Explore o guia

Passa para o próximo capítulo publicado da série — ou escolhe a tua própria aventura.


Notas finais