Erro de Ativação do Entra PIM: Aprovação, MFA e Justificativa Ausentes

Erro de Ativação do Entra PIM: Aprovação, MFA e Justificativa Ausentes Explicado

Ativar o Microsoft Entra Privileged Identity Management (PIM) é a parte fácil. O erro de configuração de ativação do Entra PIM em aprovação, MFA e justificativa é o que acontece depois: o PIM está implantado, as funções são elegíveis em vez de permanentes, mas a própria etapa de ativação fica totalmente aberta — sem aprovação exigida, sem MFA na ativação, sem justificativa registrada, e uma janela de ativação de 8 horas ou mais. O resultado parece acesso just-in-time em um painel, mas na prática se comporta como acesso administrativo permanente: qualquer pessoa elegível para uma função a obtém no momento em que clica em "Ativar", sem segundo fator, sem trilha de responsabilização, e com uma janela longa o suficiente para superar a maioria dos ciclos de detecção.

Este é um modo de falha distinto de "o PIM não está habilitado". Um tenant pode passar nessa primeira verificação e ainda assim estar exposto, porque o valor de segurança do PIM vem quase inteiramente de como a ativação é configurada, não do fato de existirem atribuições elegíveis. Cada um dos quatro controles de ativação — aprovação, MFA, justificativa e duração — é opcional por função no Microsoft Entra, e nenhum deles é exigido por padrão.

Como Funcionam os Controles de Ativação do PIM

O Microsoft Entra expõe as configurações de função do PIM — internamente chamadas de policies — pelo Microsoft Entra admin center (ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles > [função] > Role settings) ou pelo recurso unifiedRoleManagementPolicy do Microsoft Graph. Cada policy é composta por regras independentes, e quatro delas definem o que acontece no momento da ativação (Configure Microsoft Entra role settings in PIM, Update rules in PIM by using Microsoft Graph):

Os quatro são configurados por função, e nenhum é mutuamente exclusivo — uma função bem protegida tipicamente tem aprovação e MFA e justificativa e uma duração curta, não apenas um desses itens.

Por Que "PIM Habilitado" Não É o Mesmo Que "Ativação Protegida"

Uma verificação relacionada, mais básica, é se o PIM está configurado para funções privilegiadas em primeiro lugar — essa é uma lacuna separada e mais grave, que abordamos em Azure Privileged Access: Muitos Global Admins. Este artigo assume que essa verificação já passa: o PIM está ativo, as funções são elegíveis, e o tenant parece conforme em uma primeira análise. A lacuna aqui está um nível mais profundo — é o que acontece dentro do PIM quando alguém ativa uma função.

Os quatro padrões importam porque nenhum deles é seguro por padrão:

• A aprovação vem desativada por padrão. Qualquer usuário elegível pode se autoativar imediatamente, sem envolvimento de uma segunda pessoa.
• O MFA na ativação tem um ponto cego documentado. A própria orientação da Microsoft observa que "os usuários podem não ser solicitados a fazer autenticação multifator se tiverem se autenticado com credenciais fortes ou fornecido autenticação multifator anteriormente na sessão" — ou seja, uma sessão que já satisfez o MFA no login pode ativar uma função privilegiada sem nenhum desafio adicional. Essa é a mesma lacuna de reautenticação abordada em Azure Identity Security: Por Que o MFA Sozinho Não Basta.
• A justificativa vem desativada por padrão, de modo que as ativações não carregam nenhum motivo de negócio registrado — o que enfraquece tanto a revisão em tempo real quanto a auditoria posterior.
• A duração máxima de ativação é de 8 horas por padrão e pode ser configurada para até 24 horas — tempo suficiente para que uma sessão ou token sequestrado seja útil por um dia inteiro de trabalho.

🚨 Perigo: Como a configuração de MFA na ativação não força a reautenticação quando o MFA já foi satisfeito na sessão, um atacante que roubou um token de sessão válido pode ativar uma função privilegiada sem nunca precisar de um segundo fator. A mitigação documentada pela Microsoft para essa lacuna específica é o contexto de autenticação do Conditional Access combinado com a frequência de login definida como "Sempre" — não a simples caixa de seleção de MFA na ativação.

Detecção

O que verificar por função

Obtenha a política de ativação atual de cada função de diretório do Microsoft Entra e compare-a com os quatro controles acima. Manualmente, isso significa abrir Role settings para cada função no admin center. Em escala, consulte via Graph:

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

Ou com Microsoft Graph PowerShell:

# Requires RoleManagement.Read.Directory or RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

Sinalize uma função se: isApprovalRequired for false, enabledRules da regra de enablement não incluir MultiFactorAuthentication, enabledRules não incluir Justification, ou maximumDuration da regra de expiration exceder o limite definido pela sua política (geralmente 1–4 horas para funções Tier 0). Priorize Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator e qualquer função personalizada com permissões de escrita em todo o diretório — essas são as funções em que a lacuna tem o maior raio de impacto.

O que observar no log de auditoria

O Microsoft Entra mantém o histórico de políticas e ativações do PIM no blade Resource audit (ID Governance > Privileged Identity Management > Microsoft Entra roles > Resource audit), retido por 30 dias por padrão (View audit log report for Microsoft Entra roles in PIM) — se essa janela padrão for um problema para o seu prazo de investigação, veja Entra ID Logs: Retenção, Configurações de Diagnóstico e Lacunas de Exportação para SIEM para saber como encaminhá-la a um armazenamento de longo prazo. Dois tipos de atividade importam mais:

Correção

1. Levante a política atual de cada função usando a consulta Graph ou o PowerShell acima, para ter uma baseline de antes/depois, não apenas uma estimativa por função.
2. Exija aprovação para ativar funções Tier 0, com pelo menos dois aprovadores nomeados configurados explicitamente. Não deixe a lista de aprovadores vazia: a própria orientação da Microsoft alerta que um tenant pode ficar bloqueado se todo Privileged Role Administrator/Global Administrator tiver apenas atribuições elegíveis (não ativas), a aprovação for exigida e nenhum aprovador estiver configurado — configure contas de acesso de emergência devidamente monitoradas como atribuições ativas e permanentes antes de ativar isso.
3. Exija MFA na ativação, e, onde a função justificar, adicione o contexto de autenticação do Conditional Access com a frequência de login definida como "Sempre" — essa é a configuração que realmente força a reautenticação na ativação, em vez de aceitar silenciosamente uma comprovação de MFA de mais cedo na sessão.
4. Exija justificativa na ativação (e considere exigir também informações de ticket) para que cada ativação carregue um motivo de negócio registrado e revisável.
5. Reduza a duração máxima de ativação. Tanto o padrão de 8 horas quanto o teto de 24 horas existem por conveniência, não por segurança — a maioria das tarefas operacionais cabe em 1–4 horas. Configure-a pelo maximumDuration da regra de expiration em formato ISO 8601 (PT2H para duas horas, PT4H para quatro).
6. Aplique a mesma política a cada função equivalente, não apenas à que você testou. As configurações de função são independentes, então um script que corrige apenas o Global Administrator deixa o Privileged Role Administrator, o Security Administrator e as funções de diretório personalizadas inalterados.
7. Execute novamente a consulta de enumeração do Graph após a mudança e confirme que isApprovalRequired: true, que enabledRules inclui MultiFactorAuthentication e Justification, e que maximumDuration reflete seu novo teto — depois repita essa verificação periodicamente, já que um evento Update role setting in PIM posterior pode reverter tudo isso silenciosamente.

Como a EtcSec Detecta Isso

A auditoria Azure da EtcSec verifica a política de ativação do PIM em cada varredura, independentemente de o PIM em si estar habilitado.

PA_PIM_NO_APPROVAL_REQUIRED sinaliza atribuições de função elegíveis em que a ativação não exige aprovação.

PA_PIM_NO_MFA_ON_ACTIVATION sinaliza funções cuja política de ativação não exige autenticação multifator.

PA_PIM_NO_JUSTIFICATION sinaliza funções cuja ativação não exige uma justificativa de negócio.

PA_PIM_LONG_ACTIVATION sinaliza funções configuradas com uma duração máxima de ativação longa o suficiente para estender materialmente a exposição após uma ativação comprometida.

Controles Relacionados

O hardening da ativação do PIM é uma camada do controle de acesso privilegiado. Revise-o junto com Azure Privileged Access: Muitos Global Admins para saber se o PIM está implantado e se a quantidade de admins permanentes está sob controle, Contas de Acesso de Emergência Break Glass do Entra ID antes de exigir aprovação em funções Tier 0, Azure Identity Security: Por Que o MFA Sozinho Não Basta para a lacuna de reautenticação que o MFA na ativação sozinho não fecha, e Como Auditar a Segurança do Microsoft Entra ID para a checklist completa de revisão de identidade em que isso se encaixa.

Referências Primárias

• Configure Microsoft Entra role settings in PIM — Microsoft Learn
• Approve or deny requests for Microsoft Entra roles in PIM — Microsoft Learn
• Update rules in PIM by using Microsoft Graph — Microsoft Learn
• View audit log report for Microsoft Entra roles in PIM — Microsoft Learn
• Manage emergency access accounts in Microsoft Entra ID — Microsoft Learn