Como Implementar Acesso Just in Time: Guia Prático 2026

Resumo

• Uma implementação de acesso Just in Time precisa definir previamente quem é elegível, quais privilégios podem ser ativados, quem aprova, por quanto tempo o acesso permanece ativo, como ele é revogado e quais evidências são registradas.
• A arquitetura normalmente segue um fluxo composto pelas etapas de elegibilidade, solicitação, validação e aprovação, ativação temporária, expiração ou revogação, e registro para auditoria. Microsoft, AWS, Google Cloud e SailPoint utilizam variações desse modelo em suas soluções de acesso temporário.
• IAM, IGA e PAM podem desempenhar papéis diferentes na arquitetura JIT: autenticação e identidade, governança das decisões de acesso e controle de privilégios elevados, respectivamente.
• A migração não deve necessariamente eliminar todos os privilégios permanentes de uma só vez. Em sua implementação interna, a Tenable manteve temporariamente JIT e acessos estáticos em paralelo até validar o novo fluxo e testar o processo de emergência.
• Acesso temporário só funciona de fato quando a revogação chega ao sistema de destino. Além da expiração automática, a implementação deve registrar solicitação, aprovação, ativação e encerramento do acesso para fins de governança e auditoria.

Implementar o acesso Just in Time não significa apenas configurar permissões para expirarem depois de algumas horas. A mudança exige revisar quem pode receber privilégios, quais sistemas entram no modelo, como a solicitação será aprovada, quanto tempo o acesso deve permanecer ativo, como ele será efetivamente removido do sistema de destino e quais evidências precisam ser mantidas.

Se sua empresa ainda está avaliando o que é o acesso Just in Time, como ele funciona e por que substituir privilégios permanentes, veja nosso conteúdo introdutório sobre o tema: Acesso Just in Time: entenda o fim dos privilégios permanentes.

Neste guia, partimos do próximo estágio: como estruturar uma implementação de JIT.

Antes de implementar JIT, defina o escopo

Um dos primeiros erros em um projeto de Just in Time é começar pela ferramenta. Antes de configurar workflows ou comprar uma solução, é preciso saber qual problema de acesso permanente será resolvido primeiro.

Não existe obrigação de migrar todos os acessos da organização simultaneamente. Uma estratégia mais controlada é começar pelos privilégios de maior risco ou por um conjunto limitado de sistemas, testar o processo e expandir gradualmente.

A experiência publicada pela Tenable segue essa lógica: a empresa recomenda implantações incrementais por time, sistema ou até entitlement, reduzindo o impacto operacional caso surjam problemas durante a transição.

Antes do primeiro rollout, responda a seis perguntas:

1. Quem pode solicitar acesso?
2. Quais funções, grupos ou permissões podem ser ativados temporariamente?
3. Quem pode aprovar cada tipo de solicitação?
4. Quanto tempo cada acesso pode durar?
5. O que provoca sua expiração ou revogação?
6. Quais informações precisam ficar registradas?

Esse conjunto de decisões forma a política básica do JIT.

Também é importante mapear:

• Acessos administrativos existentes.
• Contas com privilégios permanentes.
• Usuários internos e terceiros.
• Sistemas críticos.
• Workloads em cloud.
• Aplicações SaaS.
• Donos dos sistemas e dos acessos.
• Dependências técnicas.
• Cenários de emergência.

A partir daí, a empresa consegue diferenciar o que realmente pode migrar para JIT e o que exige outra estratégia de controle.

Como funciona a arquitetura de acesso Just in Time

Embora a implementação varie conforme a tecnologia, uma arquitetura JIT normalmente pode ser representada da seguinte forma:

Identidade elegível → Solicitação ou ativação → Validação de políticas, contexto e autenticação → Aprovação → Concessão temporária → Uso do recurso → Expiração ou revogação → Registro para governança e auditoria

Essa estrutura aparece em diferentes plataformas.

No Microsoft Entra Privileged Identity Management, por exemplo, uma pessoa pode ser definida como elegível para uma função sem permanecer continuamente ativa. Para utilizá-la, pode ser necessário cumprir condições como MFA, justificativa ou aprovação, e a ativação permanece válida apenas pelo período configurado.

A AWS define acesso privilegiado temporário como um processo para solicitar, aprovar e acompanhar o uso de uma permissão para determinada tarefa e durante um período definido.

No Google Cloud Privileged Access Manager, um usuário solicita uma concessão baseada em uma permissão, recebe os papéis temporariamente e esses papéis são removidos ao final da concessão.

Portanto, JIT não é apenas “dar acesso por duas horas”. É um ciclo completo de decisão e execução de acesso.

1. Comece pelos pré-requisitos

Antes de criar o primeiro workflow JIT, alguns elementos precisam estar minimamente organizados.

Inventário dos privilégios existentes

É difícil eliminar privilégios permanentes sem saber quais existem.

• Administradores.
• Cargos elevados.
• Grupos.
• Privilégios.
• Contas de serviço, quando aplicável.
• Acessos temporários que acabaram se tornando permanentes.
• Permissões herdadas após mudanças de função.

Priorize permissões de maior impacto para a primeira etapa de implantação.

Identidades confiáveis

A concessão temporária deve estar associada a uma identidade individual e verificável.

Contas administrativas compartilhadas dificultam a responsabilização, evidências e governança. Recomenda-se utilizar acessos administrativos nomeados sempre que possível, além de fluxos de aprovação para solicitações envolvendo privilégios elevados.

Autenticação reforçada

A ativação de um privilégio pode exigir autenticação adicional. O Microsoft Entra PIM, por exemplo, permite exigir MFA para ativação de determinadas funções.

Ownership

Cada recurso e privilégio precisa ter um responsável claro. Sem isso, fica difícil saber quem tem autoridade para decidir se um usuário realmente precisa daquele acesso.

Logs e integrações

Também é necessário verificar se o sistema de destino permite conceder acesso dinamicamente, remover esse acesso, registrar eventos e integrar com a camada de identidade ou governança utilizada no JIT.

Sem isso, o workflow pode funcionar perfeitamente na ferramenta central e falhar na última etapa: o sistema efetivamente acessado.

2. Transforme acesso permanente em elegibilidade

Uma diferença essencial em uma arquitetura JIT está entre ter um privilégio e estar elegível para ativá-lo. Em vez de manter uma função administrativa permanentemente associada à identidade, o usuário permanece apenas elegível para ativá-la quando necessário. 

A SailPoint, por exemplo, descreve seu modelo de Privilege on Demand dessa forma: o acesso pode ser autorizado previamente, mas só é provisionado quando o usuário o ativa. Ao final da duração, por desativação do próprio usuário ou por revogação, o acesso é removido.

Ao definir elegibilidade, avalie:

• Quais funções realmente podem solicitar o acesso.
• Quais sistemas cada função pode acessar.
• Qual nível de permissão pode ser solicitado.
• Se a elegibilidade também possui prazo.
• O que ocorre quando o usuário muda de cargo.
• Quando essa elegibilidade deve ser revisada.

Esse último ponto conecta JIT à governança contínua. Remover acessos permanentes não resolve o problema se centenas de pessoas continuarem indefinidamente elegíveis para ativar privilégios de que não precisam mais.

3. Desenhe o fluxo de solicitação e aprovação

Nem todo acesso JIT precisa passar por vários gestores e uma solicitação formal. O nível de exigência deve ser proporcional ao risco: acessos de baixo impacto podem ser ativados automaticamente, se o usuário cumprir certas condições. Já privilégios críticos em produção podem exigir:

• Justificativa.
• MFA.
• Aprovação do gestor.
• Aprovação do owner do sistema.
• Solicitação vinculada.
• Janela de manutenção.
• Validação de contexto.

A Tenable recomenda definir nas políticas de JIT temas como responsabilidade dos aprovadores, duração máxima, situações em que a aprovação é necessária e critérios para casos em que o JIT não pode ser utilizado. A empresa também recomenda redundância entre aprovadores para evitar que todo o processo dependa de uma única pessoa disponível.

A pergunta não é apenas “Quem aprova?”, mas também “O aprovador recebe contexto suficiente para tomar uma decisão?”. Uma aprovação sem informação tende a virar apenas mais um clique operacional.

4. Defina duração, expiração e revogação

Não existe uma duração universal adequada para todo acesso JIT. Um privilégio necessário por 30 minutos não deveria permanecer ativo por oito horas apenas porque esse é o valor padrão da ferramenta.

A duração pode variar conforme:

• Criticidade do sistema.
• Tipo de tarefa.
• Privilégio solicitado.
• Identidade.
• Ambiente.
• Risco.
• Requisitos internos.

O importante é estabelecer limites.

Também é preciso distinguir três eventos:

Expiração: o tempo autorizado termina.

Revogação: o acesso é encerrado antes do prazo.

Desativação: o próprio usuário encerra o privilégio quando termina a tarefa.

Plataformas como a SailPoint permitem remover automaticamente o privilégio quando a ativação expira, quando o usuário o desativa ou quando ocorre revogação.

O Google Cloud PAM também remove os papéis ao término da concessão, embora a própria documentação ressalte que alterações de acesso podem levar algum tempo para se propagar pelo sistema.

JIT não é realmente temporário se a revogação registrada na plataforma não chegar ao recurso de destino.

Por isso, o teste de implementação deve validar o fluxo completo.

5. Qual o papel de IAM, IGA e PAM no JIT?

JIT pode envolver diferentes camadas de segurança de identidades. Elas não são necessariamente substitutas.

A arquitetura necessária depende do caso de uso. Um acesso temporário a um SaaS pode exigir uma arquitetura diferente de uma sessão administrativa em um servidor de produção.

Recomenda-se integrar IGA e PAM para que as decisões e políticas de governança não fiquem isoladas da camada de acesso privilegiado. Isso inclui usar JIT para tarefas administrativas, adotar fluxos de aprovação e manter uma camada de política compartilhada entre IGA e PAM.

Isso significa que, antes de implementar o JIT, é preciso saber qual componente é responsável por cada decisão e cada ação do fluxo.

6. Estruture logs e evidências desde o início

A trilha de auditoria não deveria ser uma etapa adicionada depois do rollout. Ela faz parte da arquitetura. Para cada ativação, deve ser possível responder:

• Quem solicitou.
• Qual privilégio foi solicitado.
• Para qual sistema.
• Qual justificativa foi fornecida.
• Quem aprovou.
• Quando o acesso começou.
• Por quanto tempo permaneceu ativo.
• Quando terminou.
• Se houve revogação antecipada.
• Quais exceções ocorreram.

A AWS descreve o acesso temporário elevado como uma forma de solicitar, aprovar e acompanhar permissões temporárias de maneira estruturada.

O Microsoft Entra PIM também disponibiliza histórico de auditoria sobre funções privilegiadas e documenta como eventos de solicitação, aprovação e ativação podem ser correlacionados.

Para empresas sujeitas a auditorias, essas informações também ajudam a demonstrar que o controle não existe apenas como política escrita. A empresa consegue reconstruir quem recebeu determinado privilégio, por quê, sob qual autorização e por quanto tempo.

7. Migre acessos permanentes para JIT gradualmente

Substituir acessos permanentes é uma mudança operacional. Se feita de maneira abrupta, pode criar indisponibilidade, resistência dos usuários e atalhos informais.

Na implementação interna publicada pela Tenable, a empresa manteve o JIT e o modelo tradicional em paralelo durante um período de transição. Uma data concreta era definida para desligar o acesso estático somente depois que o novo fluxo tivesse sido utilizado e validado pelo time.

Uma estratégia possível é:

• Mapear privilégios permanentes.
• Escolher um sistema, time ou privilégio piloto.
• Definir quem será elegível.
• Configurar solicitação, aprovação e expiração.
• Testar concessão e revogação.
• Acompanhar problemas durante o período de transição.
• Testar o acesso de emergência.
• Remover o privilégio permanente.
• Revisar resultados.
• Expandir para o próximo grupo.

Essa abordagem também facilita descobrir exceções antes de escalar o modelo.

8. Não remova acessos permanentes antes de testar o break-glass

Quanto mais a empresa reduz privilégios permanentes, mais importante se torna pensar em situações de emergência. O que acontece se:

• O IdP ficar indisponível?
• O fluxo de aprovação parar?
• A ferramenta JIT não responder?
• O provisionamento falhar?
• Ninguém autorizado estiver disponível para aprovar?
• O time precisar recuperar um ambiente crítico?

A AWS recomenda estabelecer um processo específico de acessos emergenciais e manter uma alternativa controlada para cenários em que o provedor de identidade principal não está disponível. Esse caminho deve ser monitorado e restrito à finalidade de recuperação.

Na implementação da Tenable, a recomendação foi testar o caminho de break-glass ponta a ponta antes de remover o entitlement estático.

Um processo de emergência não deve se transformar em uma conta administrativa compartilhada que todos conhecem. Ele deve ser:

• Restrito
• Documentado.
• Monitorado.
• Protegido.
• Testado periodicamente.

9. Principais erros na implementação de acesso Just in Time

Migrar tudo de uma vez

JIT afeta a forma como as pessoas trabalham. Começar com um piloto reduz o impacto de erros e ajuda a ajustar workflows.

Criar durações longas por conveniência

Se o usuário precisa de 40 minutos e recebe acesso por um dia inteiro, parte do benefício de reduzir acessos permanentes é perdida.

Criar aprovações excessivamente burocráticas

Um workflow lento demais incentiva usuários a procurar atalhos ou pressionar pela manutenção de privilégios permanentes.

Não validar a revogação no destino

Não basta o dashboard mostrar que o acesso expirou. É preciso verificar se o privilégio realmente deixou de existir na aplicação, cloud ou sistema correspondente.

Esquecer a elegibilidade

O acesso ativo pode ser temporário, mas a lista de pessoas elegíveis também precisa ser governada e revisada.

Manter contas administrativas compartilhadas

Isso prejudica a rastreabilidade e a responsabilização. A preferência deve ser por identidades individuais sempre que possível.

Não preparar acesso de emergência

Uma arquitetura sem plano de contingência pode transformar uma falha de identidade em uma indisponibilidade operacional.

Ignorar logs e evidências

Se solicitação, aprovação, ativação e revogação não ficarem correlacionadas, o time de compliance continuará reconstruindo o histórico manualmente.

Como escolher ferramentas para implementar acesso Just in Time

Depois de definir a arquitetura, é possível avaliar a tecnologia.

Não comece simplesmente perguntando se a ferramenta possui JIT. Pergunte o que esse JIT realmente consegue fazer.

Cobertura

• Quais aplicações, clouds e sistemas podem ser governados?
• É possível trabalhar com SaaS?
• Há suporte para sistemas on-premises ou legados?
• Quais tipos de privilégios podem ser ativados?

Workflow

• Há solicitação self-service?
• É possível exigir justificativa?
• Há múltiplos níveis de aprovação?
• É possível aplicar políticas de risco?
• Há integração com MFA?

Tempo e revogação

• Existem limites diferentes por tipo de privilégio?
• A revogação é automática?
• Ela chega diretamente ao sistema alvo?
• O usuário pode encerrar o acesso antes do prazo?

Governança

• Quem define elegibilidade?
• É possível revisar quem continua elegível?
• Existem owners?
• O ciclo de vida do usuário altera automaticamente a elegibilidade?

Auditoria

• O sistema registra solicitação, aprovação e ativação?
• O histórico pode ser exportado?
• Há integração com SIEM?
• É possível reconstruir o ciclo completo de uma concessão?

Operação e contingência

• Como funciona break-glass?
• O que acontece se uma integração falhar?
• Quanto da implementação depende de customização?
• Como novas aplicações entram no modelo?

Uma ferramenta pode oferecer uma interface de acesso temporário e ainda deixar grande parte do processo dependendo de tickets, scripts ou controles manuais.

Por isso, o critério não deveria ser apenas se há JIT, mas até onde o JIT funciona de ponta a ponta?

JIT em cloud, SaaS e acesso privilegiado: a arquitetura é a mesma?

O princípio é semelhante, mas a implementação muda.

Cloud

Em ambientes como Azure, AWS e Google Cloud, o foco costuma estar na ativação temporária de funções ou permissões sobre recursos. AWS e Google Cloud possuem documentação específica para acesso temporário elevado, enquanto o Microsoft Entra PIM permite acesso baseado em elegibilidade, aprovação e tempo para recursos do ecossistema Microsoft.

Aplicações SaaS

Em SaaS, a implementação depende de como a aplicação expõe contas, grupos, roles, entitlements, APIs e mecanismos de provisionamento e revogação. Aqui, integração e governança cross-application tornam-se especialmente importantes.

Acesso privilegiado

Para servidores, bancos de dados, infraestrutura crítica ou contas administrativas, PAM pode assumir papel maior na arquitetura, inclusive com controles de sessão e credenciais.

A decisão deve partir do tipo de recurso e privilégio que precisam ser temporários, e não da ideia de que existe uma única implementação JIT válida para toda a organização.

Checklist para implementação de acesso JIT

☐ Os privilégios permanentes foram mapeados.

☐ Os primeiros sistemas ou entitlements do rollout foram priorizados.

☐ Os responsáveis estão definidos.

☐ As pessoas elegíveis estão identificadas.

☐ O fluxo de solicitação está configurado.

☐ Os aprovadores e backups estão definidos.

☐ MFA e demais condições de ativação estão configurados quando necessário.

☐ A duração máxima de cada tipo de acesso foi definida.

☐ A revogação foi testada no sistema de destino.

☐ Solicitações, aprovações e encerramentos ficam registrados.

☐ O processo de break-glass foi documentado e testado.

☐ A elegibilidade será revisada periodicamente.

☐ Existe um plano para remover o standing access após a validação do JIT.

Como a governança de identidades ajuda na implementação de JIT

Acesso temporário resolve apenas parte do problema se a organização não consegue responder quem deveria ser elegível para solicitar aquele privilégio.

É aí que JIT se conecta à governança de identidades.

Uma camada de IGA pode apoiar processos como:

• Definição de elegibilidade.
• Ciclo de vida.
• Solicitação de acesso.
• Ownership.
• Aprovações.
• Revisões.
• Revogações.
• Registros para auditoria.

Já a execução técnica do acesso privilegiado pode depender de IAM, PAM, cloud IAM ou da própria aplicação, de acordo com a arquitetura adotada.

A Niuco posiciona sua solução de governança de identidade em processos como provisionamento, aprovações, revogação e trilhas de auditoria, conectando a gestão de acessos ao ciclo de vida dos usuários.

O ponto principal é que JIT não deve ser um workflow isolado. Quanto mais ele estiver conectado ao estado real da identidade, entrada, mudança de função, saída, revisão e necessidade de acesso, menor a chance de transformar privilégios temporários em mais um processo difícil de governar.

FAQ: implementação de acesso Just in Time

Como implementar acesso Just in Time?

Comece mapeando privilégios permanentes, definindo elegibilidade e escolhendo um escopo piloto. Depois, configure solicitação, aprovação, duração, revogação, logging e acesso de emergência antes de remover os privilégios estáticos.

JIT precisa de PAM?

Não necessariamente. PAM é especialmente relevante para privilégios administrativos e sessões sensíveis, mas JIT também pode ser implementado por IAM, IGA, ferramentas cloud ou mecanismos nativos de aplicações, dependendo do recurso que precisa ser governado.

Qual é o papel do IGA no acesso Just in Time?

IGA pode governar quem é elegível para determinado acesso, quem aprova, como o ciclo de vida e a revisões de acesso afetam essa elegibilidade e quais evidências ficam registradas. A execução do privilégio pode ocorrer em outra camada da arquitetura.

Quanto tempo deve durar um acesso JIT?

Não existe uma duração universal. O período deve ser o menor necessário para executar a tarefa e pode variar conforme privilégio, sistema, contexto e risco.

O acesso deve ser revogado automaticamente?

Sempre que a tecnologia permitir, sim. A expiração automática reduz a dependência de alguém lembrar de remover o acesso posteriormente. Também é importante testar se a revogação é efetivamente propagada ao sistema de destino.

Como auditar acessos Just in Time?

A trilha deve permitir reconstruir quem solicitou o acesso, qual privilégio foi pedido, justificativa, aprovador, horário de ativação, duração e encerramento ou revogação. Dependendo do caso, também podem ser necessários logs das ações realizadas durante a sessão.