Diagrama do PIM for Groups concedendo acesso Just-in-Time a funções do Entra ID e do Azure RBAC

Fala pessoal, tudo certo?

Em praticamente todo assessment de identidade que eu conduzo, aparece o mesmo cenário: administradores com Global Administrator, Owner na assinatura e mais meia dúzia de funções atribuídas de forma permanente. Funciona no dia a dia, mas é exatamente o tipo de privilégio permanente (standing access) que um atacante adora encontrar depois de comprometer uma conta.

O Privileged Identity Management (PIM) resolve parte disso há anos com atribuições elegíveis. Só que, quando o time cresce e cada analista precisa de três ou quatro funções do Entra ID e mais algumas funções no Azure, gerenciar tudo usuário por usuário vira um pesadelo. É aí que entra o PIM for Groups: em vez de tornar o usuário elegível a cada função, você torna o usuário elegível a ser membro de um grupo — e o grupo carrega as permissões.

Neste artigo vou mostrar, passo a passo, como montar esse modelo para funções do Microsoft Entra ID e funções do Azure RBAC, com aprovação, MFA, justificativa e validação via logs. O roteiro é inspirado no guia Step-by-Step Guide to Azure AD PIM for Groups da Microsoft Tech Community, atualizado para o portal atual do Entra e complementado com o que eu aplico em produção.

Por que PIM for Groups?

O PIM tem três “frentes”: Microsoft Entra roles, Azure resources e Groups. As duas primeiras trabalham diretamente sobre a atribuição de função. Já o PIM for Groups controla o vínculo do usuário com um grupo de segurança (como Member ou Owner) de forma Just-in-Time.

Na prática, isso abre três vantagens importantes:

• Pacote de permissões em uma ativação: o grupo pode ter várias funções do Entra ID e várias funções do Azure RBAC em escopos diferentes. O usuário ativa uma vez e recebe tudo.
• Governança centralizada: as regras de ativação (duração, MFA, aprovação, justificativa) ficam no grupo, e não espalhadas por dezenas de funções.
• Alcance além do Entra e do Azure: qualquer serviço que autorize por grupo (Intune, Key Vault via RBAC, Defender, aplicações corporativas) passa a herdar o acesso Just-in-Time.

💡 NOTA: “Role-assignable group” e “PIM for Groups” são recursos diferentes. Um grupo role-assignable é aquele criado com a opção Microsoft Entra roles can be assigned to the group = Yes e é obrigatório quando o grupo vai receber funções do Entra ID. Para funções do Azure RBAC, qualquer grupo de segurança atende — mas usar role-assignable também nesse caso traz proteções extras, que explico mais abaixo.

Comparativo de abordagens

Existem basicamente três formas de entregar acesso privilegiado a um time. Veja como elas se comparam:

E para configurar o PIM for Groups, você pode escolher entre portal, Graph ou PowerShell:

Cenário do laboratório

Vamos montar um pacote chamado PIM-SecOps-Admins para o time de operações de segurança, contendo:

• Security Administrator (Entra ID)
• Conditional Access Administrator (Entra ID)
• Contributor em um Resource Group de segurança (Azure RBAC)

Os analistas serão elegíveis ao grupo por 6 meses e, quando ativarem, receberão as três permissões por no máximo 4 horas, com MFA, justificativa e aprovação.

Pré-requisitos

Implementação passo a passo

Passo 1 — Criar o grupo role-assignable

No Microsoft Entra admin center, navegue até Entra ID > Groups > All groups > New group e preencha:

• Group type: Security
• Group name: PIM-SecOps-Admins
• Microsoft Entra roles can be assigned to the group: Yes
• Membership type: Assigned
• Owners / Members: deixe vazio — quem entra no grupo será controlado pelo PIM

Tela New group no Entra admin center com a opção Microsoft Entra roles can be assigned to the group marcada como Yes

⚠️ ATENÇÃO: a opção role-assignable só pode ser definida na criação do grupo. Não é possível converter um grupo existente. Além disso, o limite é de 500 grupos role-assignable por tenant — planeje a nomenclatura e evite criar um grupo por usuário.

Alternativa via PowerShell:

Connect-MgGraph -Scopes "Group.ReadWrite.All","RoleManagement.ReadWrite.Directory"
$grupo = New-MgGroup -DisplayName "PIM-SecOps-Admins" `
    -Description "Pacote JIT - Security Admin + CA Admin + Contributor RG-Security" `
    -MailEnabled:$false `
    -MailNickname "pim-secops-admins" `
    -SecurityEnabled `
    -IsAssignableToRole
$grupo.Id

Passo 2 — Atribuir as funções do Entra ID ao grupo

Acesse Entra ID > Roles & admins > Roles & admins, procure por Security Administrator e clique em Add assignments. Selecione o grupo PIM-SecOps-Admins.

Como o tenant tem P2, o assistente vai perguntar o tipo de atribuição. Aqui está o pulo do gato: como quem controla o “Just-in-Time” é o grupo, a função deve ser atribuída ao grupo como Active e Permanently assigned.

Repita o processo para Administrador de Usuário. Via PowerShell:

$funcoes = "Security Administrator","Conditional Access Administrator"
foreach ($nome in $funcoes) {
    $role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq '$nome'"
    New-MgRoleManagementDirectoryRoleAssignment `
        -PrincipalId $grupo.Id `
        -RoleDefinitionId $role.Id `
        -DirectoryScopeId "/"
}

💡 NOTA: se o objetivo fosse uma ativação por função (abordagem “grupo elegível à função”), aqui você escolheria Eligible em vez de Active e pularia os passos 4 a 6. Não misture as duas abordagens no mesmo grupo — isso gera ativação dupla e confunde o usuário.

Passo 3 — Atribuir a função do Azure RBAC ao grupo

No portal do Azure, abra o Resource Group de destino (no exemplo, rg-security) e vá em Access control (IAM) > Add > Add role assignment. Escolha Contributor, selecione User, group, or service principal e adicione o grupo PIM-SecOps-Admins.

Se a assinatura também estiver integrada ao PIM for Azure resources, na aba Assignment type escolha Active e Permanent, pela mesma lógica do passo anterior.

Connect-AzAccount
Set-AzContext -Subscription "<ID-DA-ASSINATURA>"
New-AzRoleAssignment -ObjectId $grupo.Id `
    -RoleDefinitionName "Contributor" `
    -ResourceGroupName "rg-security"

💡 Alternativa via Azure CLI:
az role assignment create --assignee-object-id <OBJECT-ID-DO-GRUPO> --assignee-principal-type Group --role Contributor --resource-group rg-security

Passo 4 — Colocar o grupo sob gerenciamento do PIM

Agora vamos “ligar” o PIM no grupo. Acesse ID Governance > Privileged Identity Management > Groups e clique em Discover groups. Localize o PIM-SecOps-Admins, selecione-o e clique em Manage groups.

⚠️ ATENÇÃO: não é recomendado aninhar grupos dentro de um grupo gerenciado pelo PIM — e grupos role-assignable nem permitem aninhamento. As elegibilidades devem ser sempre de usuários diretamente no grupo.

Passo 5 — Configurar as regras de ativação (Settings)

Dentro do grupo no PIM, vá em Settings e selecione a função Member. Clique em Edit. Cada grupo tem suas próprias configurações, independentes dos demais. A configuração que eu recomendo para um pacote privilegiado como este:

💡 NOTA: se você usar authentication context, crie antes uma política de Conditional Access direcionada a esse contexto (por exemplo, exigindo Phishing-resistant MFA). Se nenhuma política estiver mirando o contexto configurado, o PIM aplica o MFA padrão como mecanismo de proteção.

Lembre-se também de revisar as configurações da função Owner. Um owner pode alterar a associação do grupo — trate essa função com o mesmo rigor (ou maior) que a de Member.

Passo 6 — Adicionar as atribuições elegíveis

Ainda no grupo, vá em Assignments > Add assignments:

• Select role: Member
• Select member(s): os analistas do time de SecOps
• Assignment type: Eligible
• Duração: 6 meses (respeitando o limite configurado no passo anterior)

Via PowerShell (Graph SDK):

Connect-MgGraph -Scopes "PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup"
$usuario = Get-MgUser -UserId "analista01@contoso.com"
$params = @{
    accessId      = "member"
    principalId   = $usuario.Id
    groupId       = $grupo.Id
    action        = "adminAssign"
    justification = "Elegibilidade semestral - time SecOps"
    scheduleInfo  = @{
        startDateTime = (Get-Date).ToUniversalTime().ToString("o")
        expiration    = @{
            type     = "afterDuration"
            duration = "P180D"
        }
    }
}
New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Passo 7 — Ativação pelo usuário

Com o pacote montado, o analista acessa My Roles (pelo portal do Entra em ID Governance > Privileged Identity Management > My roles > Groups ou diretamente em https://aka.ms/myroles), localiza o grupo PIM-SecOps-Admins na aba Eligible assignments e clica em Activate.

Ele informa a duração (até 4 horas), a justificativa e o número do chamado, e conclui o MFA exigido.

O aprovador recebe a notificação e aprova em Privileged Identity Management > Approve requests > Groups.

A ativação também pode ser feita por PowerShell, útil para quem trabalha muito no terminal:

Connect-MgGraph -Scopes "PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup"
$eu = Get-MgUser -UserId (Get-MgContext).Account
$params = @{
    accessId      = "member"
    principalId   = $eu.Id
    groupId       = "<OBJECT-ID-DO-GRUPO>"
    action        = "selfActivate"
    justification = "CHG0012345 - Ajuste de política de CA"
    scheduleInfo  = @{
        startDateTime = (Get-Date).ToUniversalTime().ToString("o")
        expiration    = @{
            type     = "afterDuration"
            duration = "PT4H"
        }
    }
}
New-MgIdentityGovernancePrivilegedAccessGroupAssignmentScheduleRequest -BodyParameter $params

⚠️ ATENÇÃO: depois da ativação, o token atual do usuário ainda não contém o novo grupo. Oriente o time a sair e entrar novamente no portal (ou abrir uma janela anônima) para que as permissões do Entra ID e do Azure sejam refletidas. Alguns serviços do Microsoft 365 podem levar mais alguns minutos para reconhecer a nova associação.

Passo 8 — Validar o acesso e auditar

Com a ativação aprovada, valide três coisas:

No Azure

Para auditoria, use o Resource audit do próprio grupo no PIM ou, se os logs do Entra estão enviados para um workspace do Log Analytics, a consulta abaixo:

Notificações recebidas PIM

AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService == "PIM"
| where Category == "GroupManagement"
| extend Solicitante = tostring(InitiatedBy.user.userPrincipalName)
| extend Grupo = tostring(TargetResources[0].displayName)
| project TimeGenerated, ActivityDisplayName, Result, Solicitante, Grupo, ResultReason
| order by TimeGenerated desc

Entendendo os blocos técnicos

Troubleshooting

Boas práticas para produção

Desenhe pacotes por função de trabalho, não por pessoa. Grupos como PIM-SecOps-Admins, PIM-Identity-Operators e PIM-Azure-Platform-Contributors são fáceis de revisar. Um grupo “PIM-Fulano” é só uma atribuição direta com mais passos.

Mantenha o Global Administrator fora dos pacotes. Para funções de nível 0, prefira elegibilidade direta por usuário com aprovação, para que cada ativação seja explícita e rastreável isoladamente.

Proteja a função Owner do grupo. Quem é owner de um grupo gerenciado pelo PIM consegue alterar a associação. Deixe o grupo sem owners permanentes ou também controle o Owner pelo PIM.

Use authentication context com MFA resistente a phishing. Uma política de Conditional Access exclusiva para a ativação do PIM eleva muito a barreira contra roubo de sessão e ataques de MFA fatigue.

Combine com Access Reviews. Configure revisões trimestrais das atribuições elegíveis do grupo. Elegibilidade esquecida é o novo “admin permanente”.

Monitore atribuições fora do PIM. Ative os alertas do PIM e acompanhe no Log Analytics qualquer atribuição direta de função que contorne o modelo.

Teste com usuários piloto. Antes de migrar o time inteiro, valide o fluxo completo (ativação, aprovação, expiração) com contas de teste — e só então remova as atribuições permanentes antigas.

Break-glass sempre fora. As contas de emergência devem permanecer com acesso permanente, excluídas das políticas de CA que poderiam bloqueá-las e monitoradas com alerta a cada login.

Contribua com a comunidade

Se este guia te ajudou, compartilhe com o seu time e confira os outros projetos e scripts que publico no meu GitHub: github.com/ErickMedeiros. Deixa aquela ⭐ nos repositórios e, se tiver sugestões ou cenários diferentes de PIM for Groups no seu ambiente, comenta aqui — sempre aprendo muito com as trocas.

Referências:

• Step-by-Step Guide to Azure AD PIM for Groups — Microsoft Tech Community
• Privileged Identity Management (PIM) for Groups — Microsoft Learn
• Configure PIM for Groups settings — Microsoft Learn
• Use Microsoft Entra groups to manage role assignments — Microsoft Learn

Forte abraço pessoal 👊