Entra ID: Grupos Privilegiados Aninhados, Atribuíveis a Funções e Convidados em Grupos de Segurança

O Que São Grupos Atribuíveis a Funções e Grupos Privilegiados Aninhados no Entra ID

"Entra id grupos privilegiados aninhados atribuíveis a funções": essa combinação de busca cobre um dos cantos menos auditados do controle de acesso do Microsoft Entra ID — privilégio aninhado por meio de grupos atribuíveis a funções, e um convidado entrando em um grupo de segurança pela associação em vez de convite, formando juntos um caminho silencioso rumo ao Global Administrator que a maioria dos tenants nunca mapeou.

Um grupo atribuível a funções (role-assignable group) é um grupo de segurança com a propriedade isAssignableToRole definida como true (ou "Funções do Microsoft Entra podem ser atribuídas a este grupo" definido como Sim no portal). Atribuir uma função do Microsoft Entra a um grupo, em vez de a usuários individuais, permite que uma organização gerencie a associação à função por meio de alterações na associação ao grupo, em vez de chamadas repetidas à API de atribuição de função. Segundo a documentação da Microsoft, criar grupos atribuíveis a funções exige Microsoft Entra ID P1 ou P2, a propriedade isAssignableToRole é imutável após a criação do grupo, um grupo atribuível a funções não pode usar associação dinâmica, e um tenant pode ter no máximo 500 grupos atribuíveis a funções. A Microsoft também "protege" especificamente os proprietários de grupos atribuíveis a funções para reduzir o risco de elevação de privilégio no próprio objeto de grupo.

Grupos privilegiados aninhados descreve um grupo que é membro de outro grupo com funções privilegiadas do Entra ou acesso a recursos — a mesma lógica do "caminho para o Domain Admin" existente no Active Directory local (veja aninhamento perigoso de grupos no Active Directory), aplicada ao diretório em nuvem. A Microsoft bloqueia explicitamente a versão mais óbvia disso: um grupo não pode ser membro ativo de um grupo atribuível a funções. O que a Microsoft permite — e o que a maioria dos tenants não considerou — é que um grupo seja membro elegível de um grupo atribuível a funções por meio do Privileged Identity Management (PIM) for Groups.

Por fim, convidados em grupos de segurança é um problema distinto da governança de convites de convidados. Este artigo não trata de quem pode convidar um convidado (veja Contas de Convidado no Azure: A Superfície de Ataque Esquecida sobre esse ângulo) — trata de uma conta de convidado acabar como membro de um grupo de segurança que carrega acesso ou elegibilidade de função, por meio de aninhamento ou de uma regra de associação dinâmica, sem que ninguém tenha decidido explicitamente conceder algo a esse convidado.

Entra ID Grupos Privilegiados Aninhados Atribuíveis a Funções: A Cadeia de Escalonamento

Passo 1 — Um grupo não privilegiado é aninhado como membro elegível

O PIM for Groups permite que um administrador configure atribuições elegíveis em duas direções: ou usuários são adicionados ativamente a um grupo e o próprio grupo se torna elegível para uma função, ou uma função é atribuída ativamente a um grupo e usuários se tornam elegíveis para associação a esse grupo — e, segundo a própria documentação da Microsoft sobre PIM for Groups, um grupo em si também pode ser configurado como membro elegível de outro grupo, incluindo um atribuível a funções. Como a restrição de associação ativa em grupos atribuíveis a funções bloqueia apenas a associação direta e permanente, um grupo de privilégio inferior pode ser configurado como membro elegível de um grupo atribuível a funções sem violar essa restrição.

Passo 2 — Nenhum fluxo de aprovação é imposto na ativação

O PIM for Groups suporta os mesmos controles de política que o PIM para funções do Entra: exigir aprovação, impor MFA na ativação, exigir justificativa de negócio e limitar a duração máxima de ativação. Quando esses controles não estão configurados — a postura padrão em muitos tenants que adotaram o PIM for Groups sem endurecê-lo —, qualquer membro do grupo de nível inferior pode ativar por conta própria sua associação elegível no grupo privilegiado e herdar a função que esse grupo carrega (Global Administrator, Privileged Role Administrator, Application Administrator e assim por diante — veja Acesso Privilegiado no Azure: Administradores Globais Demais sobre por que o acesso permanente e facilmente alcançável a Global Administrator já é um achado comum).

Passo 3 — Um convidado entra junto pelo mesmo grupo

O grupo aninhado do Passo 1 raramente nasceu como um grupo "privilegiado" — costuma ser uma equipe de projeto, um grupo de acesso a aplicativo, ou um grupo com uma regra de associação dinâmica ampla. Se uma conta de convidado foi adicionada a esse grupo (diretamente, ou porque a regra dinâmica do grupo foi escrita de forma mais ampla do que o pretendido — por exemplo, correspondendo a atributos que não excluem de forma confiável userType eq Guest; veja a aposentadoria do operador memberOf em regras de grupo dinâmico sobre como essas regras já estão mudando), o convidado herda o mesmo caminho elegível para o grupo atribuível a funções que qualquer usuário membro. Ninguém revisou explicitamente "esse convidado deveria ser elegível para Global Administrator" — o aninhamento de grupos tomou essa decisão implicitamente.

Conta de convidado
  -> membro do grupo de segurança "Project-Falcon" (associação dinâmica ou manual)
      -> "Project-Falcon" é membro elegível de "Tier0-Admins" (grupo atribuível a funções)
          -> "Tier0-Admins" tem atribuição ativa da função Global Administrator
              -> convidado ativa por conta própria a associação elegível (sem aprovação necessária)
                  -> convidado passa a ter Global Administrator durante a janela de ativação

A ferramenta de avaliação EntraFalcon da Compass Security documenta a mesma fragilidade subjacente sob uma ótica ofensiva: ela sinaliza qualquer grupo que não seja atribuível a funções, sincronizado de um ambiente local, nem colocado em uma Unidade Administrativa de Gerenciamento Restrito como um grupo privilegiado "desprotegido" (ID de achado GRP-005 em seus relatórios), pois nenhuma dessas três propriedades é garantida para um grupo que só se torna privilegiado transitivamente por aninhamento.

Detecção

Aqui, detecção significa encontrar grupos atribuíveis a funções, descobrir o que está aninhado como elegível dentro deles e encontrar convidados na árvore de grupos que alimenta esses grupos — nada disso aparece como um único alerta por padrão.

# Microsoft Graph — enumerar grupos atribuíveis a funções
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — convidados transitivamente dentro de um grupo específico
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — alterações de associação de grupo em uma watch-list de IDs de grupos privilegiados
AuditLogs
| where OperationName in ("Add member to group", "Add owner to group")
| where TargetResources[0].id in (privilegedGroupIds)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)

Correção

1. Inventarie todo grupo atribuível a funções com a consulta Graph isAssignableToRole eq true acima — não confie na memória do tenant sobre "os grupos que criamos para isso". Atribua um proprietário a cada um e remova proprietários que não precisam mais do acesso, já que a própria orientação da Microsoft aponta a propriedade não governada como o principal risco de elevação nesses objetos.
2. Exija aprovação e MFA na ativação para toda atribuição elegível de PIM for Groups que termine em um grupo atribuível a funções, e defina uma duração máxima de ativação limitada, em vez de deixá-la em aberto.
3. Proíba o aninhamento de grupos em grupos atribuíveis a funções onde isso não for operacionalmente necessário. A própria orientação da Microsoft recomenda limitar ou evitar grupos aninhados em caminhos de elevação de função, pois cada nível de aninhamento adiciona proprietários de grupo que podem gerenciar indiretamente quem alcança a função, mesmo sem essa intenção.
4. Audite regras de associação dinâmica que alimentam qualquer grupo em uma cadeia privilegiada, tornando a exclusão de convidados explícita (userType -ne "Guest") em vez de presumida — um grupo atribuível a funções em si não pode usar associação dinâmica, mas os grupos aninhados sob ele podem, e é exatamente aí que uma regra ampla causa o dano.
5. Execute revisões de acesso na associação de grupos atribuíveis a funções e nas cadeias de associação elegível, não apenas nas atribuições de função diretamente — uma revisão trimestral limitada a "quem tem Global Administrator" não vai capturar um convidado dois níveis de aninhamento abaixo dela.
6. Remova convidados de grupos de segurança aos quais nunca deveriam ter se juntado. Se a presença de um convidado em um grupo só puder ser explicada por "a regra dinâmica o capturou" ou "alguém o adicionou ao grupo errado", trate isso como um incidente a ser fechado, não como um detalhe de configuração a anotar para depois.

Essas verificações se somam a uma revisão mais ampla — veja como auditar a segurança do Microsoft Entra ID sobre onde a higiene de grupos e PIM se encaixa em relação a Conditional Access, MFA e permissões de aplicativos.

Como a EtcSec Detecta Isso

A auditoria de Azure/Entra ID da EtcSec verifica exatamente essa cadeia: Grupos Aninhados com Acesso Privilegiado (AZ_GROUP_NESTED_PRIVILEGED) sinaliza grupos que alcançam um grupo atribuível a funções por aninhamento elegível ou transitivo, Grupos Atribuíveis a Funções (AZ_GROUP_ROLE_ASSIGNABLE) inventaria todo grupo isAssignableToRole e sua postura de propriedade/aprovação, e Usuários Convidados em Grupos de Segurança (AZ_GROUP_GUEST_IN_SECURITY) revela contas de convidado dentro de grupos de segurança, independentemente de terem sido convidadas diretamente ou de terem obtido associação por aninhamento ou por uma regra dinâmica. Verificações relacionadas — Função de Admin Atribuída a Grupo (PA_GROUP_ASSIGNED_ADMIN) e Grupos Privilegiados Sem Monitoramento de Alterações (AZ_GROUP_PRIVILEGED_CHANGES) — estendem a mesma auditoria a atribuições de função para grupos e a se as alterações de associação nesses grupos estão de fato sendo registradas e revisadas.