Privilégios permanentes são o problema de identidade mais fácil de explorar e o mais lento de remover depois que o atacante já entrou. Este guia é para equipes que administram contas privilegiadas em Microsoft Entra ID ou AWS: a ação prioritária é converter atribuições permanentes em elegibilidade com ativação just-in-time e prazo curto, substituindo credenciais de longa duração por credenciais temporárias. A referência conceitual é o NIST SP 800-207, que define confiança zerada como acesso concedido por sessão e com o mínimo necessário de privilégio.
O princípio: perde a validade sozinho
O NIST SP 800-207 recomenda que o acesso a recursos corporativos seja concedido por sessão, expirando quando ela termina, e aplicado com o mínimo privilégio necessário para a tarefa em curso. Em vez de o usuário carregar o privilégio para sempre, ele pede, comprova quem é e recebe a permissão apenas pelo período da operação. É o mesmo raciocínio do zero trust que já abordamos ao falar de redução de acessos de cargas de trabalho na nuvem: a identidade recebe o menor escopo possível e por tempo definido.
Na prática, a decisão operacional de fundo é uma só: preferir credenciais que expiram sozinhas a segredos que alguém precisa revogar. O modelo just-in-time da Microsoft chama isso de permissão elegível: você só recebe o papel depois de ativar, com autenticação multifator e justificativa.
Como implementar PIM no Entra ID
O Privileged Identity Management (PIM) do Microsoft Entra ID fornece ativação de papéis baseada em tempo e em aprovação para reduzir o risco de permissões excessivas ou mal utilizadas. A documentação da Microsoft orienta configurar a atribuição como elegível em vez de ativa: o usuário só ganha o privilégio quando executa uma ativação, que pode exigir verificação multifator, justificativa e aprovação de um aprovador designado.
Um roteiro prático em quatro passos:
- P1 — inventariar e rebaixar: liste quem tem atribuições ativas de administrador global e de outros papéis sensíveis; converta para elegível quem não precisa do privilégio permanente.
- P1 — forçar condições de ativação: exija autenticação multifator e justificativa em toda ativação; para os papéis mais críticos, exija também aprovação.
- P2 — definir prazo máximo: limite a duração máxima de cada ativação para o tempo real da tarefa, com renovação aprovada quando necessário.
- P2 — rever periodicamente: use as revisões de acesso e o histórico de auditoria para retirar elegibilidade de quem não usou o papel no período.
Guarde uma exceção documentada: a conta de emergência (break-glass) costuma permanecer ativa permanente, mas precisa ser monitorada com alertas de uso — um tema detalhado no nosso guia sobre acesso de emergência testável.
AWS STS: credenciais temporárias por padrão
Ao rebaixar privilégios de administradores, o segundo eixo é eliminar chaves de acesso de longa duração. O AWS Security Token Service (AWS STS) emite credenciais temporárias que funcionam como chaves normais, mas expiram após minutos ou horas e, depois disso, a AWS simplesmente não reconhece mais chamadas feitas com elas. A documentação da AWS recomenda esse modelo porque as credenciais não são armazenadas com o usuário: são geradas dinamicamente na hora do pedido, inclusive para federação de identidade, acesso entre contas e papéis de serviço em instâncias EC2.
Checklist de migração:
- P1 — federação no lugar de usuário IAM: autentique pessoas pelo provedor de identidade corporativo (SAML 2.0 ou OIDC) e entregue acesso por papel, sem criar usuários IAM com senha ou chave.
- P1 — papéis para cargas de trabalho: instâncias EC2, funções Lambda e serviços da AWS devem assumir papéis de serviço, sem credenciais gravadas em configuração.
- P2 — prazo menor que o padrão: reduza a duração da sessão dos papéis sensíveis ao mínimo viável para a operação.
- P2 — auditoria contínua: acompanhe com o IAM Access Analyzer quem, fora da sua zona de confiança, poderia assumir seus papéis.
O sinal mais importante para acompanhar é o tempo médio de vida de uma credencial privilegiada na sua organização: se a resposta for semanas, o just-in-time ainda não existe de fato; o alvo é que cada ativação expire no mesmo dia em que começou.
Sinais para medir o programa
| Indicador | Meta | Como medir |
|---|---|---|
| Administração permanente em Entra ID | Zero, exceto contas de emergência | Relatório de atribuições ativas no PIM |
| Chaves de acesso de longa duração na AWS | Zero para humanos | IAM Access Analyzer e relatório de credenciais |
| Duração máxima de ativação | Menor ou igual ao prazo da tarefa | Configuração de papéis no PIM |
| Ativações sem justificativa | Zero | Histórico de auditoria do PIM |
Dois erros comuns travam o programa. O primeiro é transformar todo mundo em elegível sem aprovação: a elegibilidade sem fricção vira privilégio permanente disfarçado. O segundo é migrar para STS mantendo políticas de permissão largas: credencial curta com escopo largo continua sendo um risco alto.