⚙️
Artigo para equipas técnicas

Este artigo assume familiaridade com o Microsoft Entra ID, Azure Portal e conceitos de RBAC. Pressupõe que a decisão de implementar o PIM já foi tomada pela liderança. Se procura a justificativa de negócio ou a explicação do que é o PIM, consulte os Artigos 1 e 2 da série.

Antes de começar: o que você precisa ter

A implementação do PIM é um projeto de mudança, não apenas uma configuração técnica. Para ter sucesso, alguns pré-requisitos precisam estar em ordem antes de qualquer configuração no portal.

Pré-requisitos técnicos: Licenças Microsoft Entra ID P2 ou equivalente para todos os usuários que serão gerenciados; acesso como Administrador Global ou Administrador de Função Privilegiada no tenant; inventário atualizado das funções privilegiadas existentes no Entra ID e no Azure.

Pré-requisitos organizacionais: Apoio e suporte da liderança (CIO, CISO ou equivalente); definição dos aprovadores para funções críticas; comunicação planejada para os administradores impactados; processo de suporte definido para dúvidas durante a transição.

Stakeholders essenciais do projeto

Sponsor
CIO / CISO
Aprova o projeto, remove impedimentos organizacionais, comunica a prioridade para as equipes
Gestor Técnico
Líder de Identidade / Sysadmin Sr.
Conduz a implementação técnica, configura as funções e políticas no PIM
Aprovadores
Administradores Globais atuais
Aprovam ativações de funções críticas; 2 aprovadores por função de alto risco é o recomendado
Conformidade
Auditor Interno / GRC
Define requisitos de rastreabilidade e valida o atendimento a normas como ISO 27001, SOC 2, LGPD

Visão geral: as 4 fases

A implementação do PIM é estruturada em quatro fases progressivas. Cada fase tem um escopo claro, entregáveis definidos e um critério de saída antes de avançar para a próxima.

Fase 1
Diagnóstico e Preparação
⏱ Semanas 1–3

A fase de diagnóstico é a mais crítica e frequentemente subestimada. O objetivo é ter um inventário completo e preciso de tudo que será gerenciado pelo PIM antes de qualquer configuração.

☐
Inventário de funções privilegiadas: Exportar todas as atribuições de funções do Entra ID e do Azure. Identificar usuários com múltiplas funções de alto risco. Listar funções permanentes que deveriam ser elegíveis.
☐
Classificação de risco por função: Criar uma matriz de risco para cada função (alto, médio, baixo) baseada no escopo de impacto de um eventual comprometimento. Administrador Global e Proprietário de Assinatura são sempre Alto Risco.
☐
Definição das políticas por função: Para cada função de alto risco, definir: duração máxima de ativação, se requer aprovação, quem são os aprovadores, se requer MFA, se requer justificativa e ticket de incidente.
💡 Observação: Calibre os tempos para a realidade da sua organização

Não existe uma duração de ativação universalmente correta. Os valores recomendados neste guia (1h para Admin Global, 2h para Exchange/SharePoint, 4h para Helpdesk) são pontos de partida baseados em boas práticas, mas cada organização tem rotinas próprias que precisam ser consideradas. Uma equipa de infraestrutura que executa manutenções noturnas longas tem necessidades diferentes de uma equipa de suporte de primeiro nível. Um ambiente de operação contínua 24/7 exige aprovadores disponíveis em todos os turnos, o que impacta diretamente o fluxo de aprovação viável.

O objetivo é encontrar o equilíbrio entre segurança e produtividade: tempos muito curtos geram atrito excessivo e levam os utilizadores a contornar o processo; tempos muito longos reduzem a efetividade do controlo JIT. Use a fase piloto (Fase 2) para observar o comportamento real das equipas e ajuste as políticas antes do rollout completo. Documente o raciocínio por trás de cada decisão, incluindo as exceções, para facilitar revisões futuras.

☐
Identificação de contas de acesso de emergência: Garantir que existam exatamente 2 contas "break-glass" com acesso ativo permanente ao Administrador Global, fora do escopo do PIM para ativação (mas monitoradas).
☐
Verificação de licenciamento: Confirmar que todos os usuários elegíveis, aprovadores e revisores têm licença Entra ID P2. Planejar aquisição de licenças adicionais se necessário.
☐
Comunicação inicial: Informar os administradores sobre o projeto, o cronograma e o que mudará no dia a dia. Criar canal de suporte dedicado para dúvidas durante a transição.
Critério de Saída da Fase 1
✅ Inventário completo de todas as funções privilegiadas documentado
✅ Matriz de risco criada e aprovada pelo gestor responsável
✅ Políticas de configuração definidas para cada função
✅ Contas de emergência identificadas e documentadas
✅ Licenças confirmadas para todos os usuários no escopo
Fase 2
Piloto Controlado
⏱ Semanas 4–7

O piloto é executado com um grupo limitado de usuários e funções de menor risco. O objetivo é validar as configurações, identificar problemas operacionais e ajustar antes da implantação ampla.

☐
Seleção do grupo piloto: Escolher 5 a 10 administradores colaborativos e com perfil técnico. Priorizar usuários que já têm familiaridade com MFA e o portal Entra. Incluir pelo menos um aprovador no grupo.
☐
Configurar funções de baixo/médio risco no PIM: Começar com funções como Administrador do Helpdesk, Administrador de Usuários ou Administrador do Teams. Configurar as políticas definidas na Fase 1 para essas funções.
☐
Converter atribuições permanentes para elegíveis: Para os usuários do piloto, converter as atribuições ativas para elegíveis nas funções selecionadas. Manter a atribuição ativa temporariamente em paralelo por 1 semana como garantia.
☐
Executar cenários de teste: Seguir o plano de teste definido: ativação com MFA, ativação com aprovação, solicitação negada, expiração automática, renovação de elegibilidade, verificação do histórico de auditoria.
☐
Coletar feedback do grupo piloto: Realizar reuniões semanais com os participantes. Documentar pontos de atrito, dúvidas recorrentes e sugestões de ajuste nas políticas.
☐
Ajustar configurações baseado no piloto: Revisar durações de ativação, fluxos de aprovação e requisitos de justificativa conforme feedback coletado. Atualizar a documentação de políticas.
Critério de Saída da Fase 2
✅ Todos os cenários de teste executados com resultado esperado
✅ Feedback do piloto documentado e endereçado
✅ Políticas ajustadas e documentação atualizada
✅ Aprovação formal da liderança para avançar ao rollout
Fase 3
Rollout para Funções Críticas
⏱ Semanas 8–14

Com o piloto validado, é hora de expandir para as funções de maior impacto. Esta fase requer atenção máxima, já que qualquer problema na conversão do Administrador Global pode afetar o acesso administrativo de toda a organização.

☐
Pré-requisito crítico, Break-glass: Antes de qualquer modificação nas funções de Administrador Global, confirmar que as contas de acesso de emergência estão funcionando corretamente e que as credenciais estão acessíveis. Testar o acesso com essas contas.
☐
Configurar funções de Administrador Global no PIM: Configurar a função com aprovação obrigatória, MFA, duração máxima de 1 hora, e dois aprovadores. Converter os admins atuais (exceto break-glass) para elegíveis.
☐
Expansão gradual por onda: Onda 1 (Semana 8-9): Administrador Global, Administrador de Segurança. Onda 2 (Semana 10-11): Proprietário de Assinatura Azure, Administrador de Acesso. Onda 3 (Semana 12-14): Demais funções de médio risco.
☐
Configurar alertas de segurança do PIM: Ativar todos os alertas disponíveis no PIM para monitorar padrões suspeitos: muitos admins globais, funções sem MFA, ativações fora do horário, etc.
☐
OpcionalRecomendadoIntegrar logs com SIEM: Configurar exportação de logs do PIM para o Microsoft Sentinel ou outra ferramenta de monitoramento. Criar alertas para ativações de funções críticas fora do horário comercial. (Requer ferramenta SIEM já implantada, como Microsoft Sentinel, e custos adicionais de ingestão. Recomendado para organizações com requisitos de monitoramento contínuo ou sujeitas a auditorias frequentes.)
☐
Monitoramento intensivo pós-conversão: Durante as primeiras 2 semanas após converter cada onda, monitorar o histórico de ativações diariamente. Ter um processo rápido de reversão caso alguma função crítica apresente problemas operacionais.
Critério de Saída da Fase 3
✅ 100% das funções de Administrador Global convertidas para elegíveis (exceto break-glass)
✅ Todas as funções críticas do Azure sob gestão do PIM
✅ Alertas de segurança configurados e monitorados
✅ Integração com SIEM validada com logs recebendo dados
Fase 4
Governança e Maturidade Contínua
⏱ A partir da Semana 15 (contínuo)

A Fase 4 não tem fim. É a operação continuada do PIM como parte da rotina de segurança da organização. O objetivo é automatizar revisões, responder a alertas e melhorar continuamente as políticas.

☐
Configurar Revisões de Acesso automáticas (Microsoft Entra Access Reviews): Esta etapa não é feita dentro do PIM diretamente. É necessário criar uma Access Review em Entra ID > Identity Governance > Access reviews > New access review. Na configuração, define-se: escopo (função PIM específica ou grupo), frequência (trimestral, para funções críticas), revisores (gestor direto do usuário ou revisores designados) e ação ao término (remoção automática da elegibilidade se não houver resposta, ou manutenção com alerta). O gestor recebe notificação por e-mail e acessa o portal de revisão para confirmar ou revogar cada elegibilidade. Requer licença Microsoft Entra ID P2 ou Microsoft Entra ID Governance.
☐
Processo de onboarding e offboarding integrado via Entitlement Management: O Microsoft Entra Entitlement Management (Entra ID > Identity Governance > Entitlement management) permite criar Access Packages (pacotes de acesso) que agrupam elegibilidades PIM, grupos, aplicações e sites do SharePoint em um único objeto gerenciável.
  • Onboarding: O gestor ou o próprio colaborador solicita o Access Package correspondente ao seu perfil (ex.: "Administrador de Exchange", "Engenheiro Cloud"). O sistema atribui automaticamente todas as elegibilidades PIM definidas no pacote, sem necessidade de configurar cada função individualmente no PIM.
  • Offboarding: Quando o colaborador é desligado ou muda de função, a remoção do Access Package revoga automaticamente todas as elegibilidades PIM vinculadas, além dos demais acessos do pacote. Isso elimina o risco de elegibilidades órfãs que persistem após a desabilitação da conta no Entra ID.
  • Ciclo de vida automatizado: Os pacotes suportam data de expiração e políticas de renovação, garantindo que acessos temporários (contratos, projetos) sejam encerrados sem intervenção manual.
Requer licença Microsoft Entra ID Governance. Configuração: Entra ID > Identity Governance > Entitlement management > Access packages > New access package.
☐
Revisão periódica do histórico de auditoria: Um administrador designado revisa periodicamente o histórico de ativações, identificando padrões anômalos, funções nunca utilizadas, e elegibilidades que podem ser removidas.
☐
Expansão para PIM for Groups: Identificar grupos de segurança que controlam acesso a aplicações críticas e configurar PIM for Groups para eles, ampliando o controle JIT além das funções do Entra e Azure.
☐
Relatórios para conformidade: O PIM armazena 30 dias de histórico de auditoria no portal (Entra ID > PIM > Audit history), exportável manualmente em CSV. Relatórios mensais automáticos exigem configuração adicional fora do PIM. As opções são:
  • Diagnostic Settings + Log Analytics (recomendado): Em Entra ID > Diagnostic settings, enviar os logs de auditoria para um Log Analytics Workspace. A partir daí, criar alertas agendados no Azure Monitor que disparam a query mensalmente e enviam o resultado por e-mail via Action Group. Requer assinatura Azure com Log Analytics.
  • PowerShell + Azure Automation: Script que chama a Microsoft Graph API para extrair o histórico de ativações do PIM e envia um relatório formatado por e-mail. Opção de menor custo, sem dependência de Log Analytics.
  • Microsoft Sentinel: Se já implantado, possui workbooks nativos para Entra ID e PIM com agendamento de relatórios integrado. Mais completo, mas adiciona custo de ingestão.
  • Exportação manual periódica: Para organizações com menor volume, a exportação manual mensal do CSV do portal pode ser suficiente para atender auditorias ISO 27001 e SOC 2.

Riscos e mitigações

Todo projeto de mudança em infraestrutura crítica de identidade carrega riscos. Mapeá-los com antecedência é parte essencial do planejamento.

Risco Probabilidade Impacto Mitigação
Administrador bloqueado sem acesso ao portal de ativação Médio Alto Garantir 2 contas break-glass ativas. Documentar processo de uso emergencial. Testar antes da conversão.
Aprovador indisponível quando ativação urgente é necessária Médio Médio Configurar sempre 2 aprovadores por função crítica. Definir substitutos para períodos de ausência.
Resistência cultural dos administradores ao novo processo Alto Médio Comunicação antecipada, treinamento, e garantia de que a ativação é rápida (menos de 2 minutos).
Falta de licenças para todos os usuários elegíveis Baixo Alto Auditar licenças na Fase 1. Reservar orçamento para licenças adicionais antes do início do piloto.
Configuração incorreta de uma função crítica (ex.: Global Admin) Baixo Alto Executar sempre em ambiente de teste antes de produção. Ter rollback documentado. Manter conta break-glass ativa durante toda a Fase 3.
Perda de logs por falta de retenção configurada Médio Médio Configurar Diagnostic Settings com Log Analytics Workspace na Fase 1, antes de qualquer ativação em produção.

Critérios de conclusão do projeto

O projeto de implementação do PIM está concluído quando todos os critérios abaixo forem atendidos e documentados: