PAM na prática: do cofre de senhas ao acesso just-in-time

Muita empresa diz que tem PAM porque comprou um cofre de senhas. Quase sempre o cofre guarda as senhas de alguns servidores Windows, os administradores continuam entrando por fora dele quando estão com pressa, e ninguém sabe dizer quantas contas privilegiadas existem de fato.

As contas privilegiadas são o alvo mais valioso de qualquer invasor, porque abrem caminho para todo o resto. O MITRE ATT&CK cataloga o uso de contas válidas (técnica T1078) como meio de acesso inicial, persistência, escalada de privilégio e evasão de defesas. Proteger essas contas é o papel do PAM (Privileged Access Management). Mas o PAM não é um produto único: é uma sequência de degraus de maturidade, e o cofre é só o segundo deles.

No texto anterior, vimos que agentes de IA precisam de identidade própria e de tokens de curta duração. O mesmo raciocínio vale para as contas humanas e técnicas com mais poder na empresa: o melhor privilégio é o que existe só pelo tempo da tarefa.

Quando o cofre vira o alvo

Imagine uma empresa que instala um cofre de senhas e, para automatizar uma rotina, grava num script a credencial de administrador do próprio cofre. O script fica numa pasta de rede que dezenas de pessoas acessam. Quem encontra o arquivo não precisa quebrar nada: abre o cofre com a chave que estava ao lado dele e herda os segredos de tudo o que ele guarda.

A lição não é que o PAM falha. É que um PAM que não protege a si mesmo, e que convive com segredos escritos em scripts, vira o alvo único.

Contas privilegiadas que ninguém inventariou

Antes de configurar qualquer ferramenta, é preciso saber o que proteger. A lista costuma ser maior e mais variada do que se imagina:

•     Administradores de domínio e de diretório, inclusive contas antigas de quem já saiu.

•     root e administradores locais de servidores Linux e Windows, muitas vezes com a mesma senha em vários equipamentos.

•     Contas de banco de dados com acesso amplo, como as de DBA e as de aplicação com privilégio de escrita.

•     Contas de serviço e chaves de API com privilégios elevados. São identidades não humanas, tema do nosso texto sobre NHI.

•     Administradores de nuvem e de aplicações SaaS, que não aparecem no diretório local.

•     Contas compartilhadas e de emergência (break-glass), usadas por mais de uma pessoa ou anotadas em planilhas.

A descoberta automática ajuda, mas o inventário só fica de pé quando cada conta tem dono e justificativa. Conta sem dono não entra no cofre: entra na fila de desligamento.

Os degraus de maturidade do PAM

Cada degrau reduz um risco diferente, e nenhum deles substitui o anterior:

Degrau	O que entrega	Pergunta que responde	O que ainda fica exposto
1. Descoberta	Inventário das contas privilegiadas, cada uma com dono.	Quais contas existem e quem responde por elas?	Nada está protegido ainda, apenas conhecido.
2. Cofre e rotação	Credenciais guardadas, entregues sob solicitação e trocadas após o uso.	Quem pegou a credencial, e ela continua válida?	O privilégio ainda é permanente, e quem pega a senha pode abusar dela durante o uso.
3. Sessão	Acesso intermediado, com gravação e monitoramento dos comandos.	O que foi feito com o privilégio?	A gravação mostra o que aconteceu, mas não impede o ato. O privilégio continua permanente.
4. Acesso efêmero	Privilégio concedido sob demanda, por tempo limitado.	O privilégio existe quando ninguém precisa dele?	Resta o risco do período de concessão e dos caminhos de emergência.

Pular direto para o cofre, sem o inventário, deixa contas de fora. Parar no cofre mantém o privilégio aberto o tempo todo.

Cofre e rotação de credenciais

O cofre guarda a credencial, a entrega a quem foi autorizado e a troca depois do uso. O ganho real vem da rotação: uma senha válida só durante a sessão perde a utilidade se vazar depois. Três cuidados:

•     Mapeie as dependências antes de rotacionar contas de serviço. Trocar a senha de uma conta usada por aplicações, tarefas agendadas ou integrações, sem avisar ninguém, derruba o serviço. Comece pelas contas interativas e avance para as técnicas com testes.

•     Proteja o cofre como o sistema mais crítico da empresa. Ele concentra os segredos de muitos outros. Exija MFA resistente a phishing de quem o administra, separe esse acesso do uso diário e mantenha uma conta de emergência fora do próprio cofre, guardada e testada.

•     Tire os segredos de scripts e arquivos de configuração. Se uma automação precisa de credencial, ela deve buscá-la no cofre em tempo de execução. Melhor ainda: usar federação e tokens de curta duração, sem segredo guardado.

Gravação e monitoramento de sessão

Quando o acesso passa por um intermediário, a sessão pode ser gravada, os comandos registrados e as ações de risco bloqueadas ou sinalizadas. O NIST SP 800-53 trata esse recurso no controle de auditoria de sessão (AU-14). Dois pontos merecem atenção:

•     Gravar não é revisar. Sem uma rotina de revisão por amostragem e alertas para ações críticas, a gravação só serve depois do incidente.

•     A gravação também contém dados. Uma sessão pode expor dados pessoais e segredos digitados. Defina quem acessa as gravações, por quanto tempo elas ficam guardadas e como entram na política da LGPD.

Acesso just-in-time e zero standing privileges

O último degrau muda a pergunta. Em vez de proteger privilégios permanentes, a empresa deixa de tê-los. No acesso just-in-time (JIT), a pessoa pede o privilégio para uma tarefa, recebe-o por tempo limitado, e ele some sozinho. O objetivo de longo prazo é o zero standing privileges (ZSP): nenhuma conta com privilégio permanente, além do mínimo de emergência.

Há três formas comuns de implementar:

•     Elevação temporária de papel. A conta existe sem poder, e o papel administrativo é ativado por uma janela, com justificativa e, quando necessário, aprovação.

•     Contas efêmeras. A conta privilegiada é criada para a tarefa e removida ao final.

•     Credenciais de curta duração. Tokens ou certificados que expiram em minutos, o mesmo princípio que vimos para agentes de IA e cargas de trabalho.

Esse é o mesmo princípio dos acessos efêmeros, tema de um texto anterior do nosso blog: permissões temporárias, revogadas quando a tarefa termina. O JIT reduz a janela de ataque e simplifica a revisão, porque o privilégio que não existe não precisa ser revisado. Também enfraquece o roubo de credenciais: uma credencial capturada hoje deixa de servir amanhã.

Na prática, o ZSP é uma direção, não um interruptor. Contas de emergência continuam existindo, e algumas plataformas legadas não aceitam elevação temporária. Comece pelas funções de maior risco: administração de domínio, nuvem e banco de dados.

Erros de implantação

•     Comprar o cofre antes de fazer o inventário. O PAM nasce cobrindo só o que já era conhecido.

•     Cobrir apenas Windows. Servidores Linux, bancos de dados, equipamentos de rede e consoles de nuvem ficam de fora e viram o caminho alternativo.

•     Manter o acesso direto aberto. Se o administrador pode entrar sem passar pelo PAM, o PAM só protege quem tem paciência.

•     Rotacionar contas de serviço sem mapear dependências. O primeiro serviço que cair faz o projeto perder apoio.

•     Conta sem dono. Quando ninguém responde pela conta, ninguém a revisa nem a desliga.

•     Exceção temporária que vira permanente. Acessos "só por esta semana" precisam de data de fim imposta pelo sistema.

•     Gravar sem revisar. A trilha existe, mas ninguém olha.

•     Esquecer de proteger o próprio PAM. MFA fraco, credenciais em scripts e administradores compartilhados reproduzem o problema que o projeto queria resolver.

Quando o PAM não resolve

O PAM controla como o privilégio é usado. Ele não decide quem deveria tê-lo, e alguns problemas ficam fora do seu alcance:

•     Quem deve ter o papel privilegiado é uma decisão de governança de identidades (IGA), com revisão periódica e segregação de funções (SoD).

•     Privilégio excessivo em nuvem pede gestão de direitos de acesso à infraestrutura em nuvem (CIEM), porque os papéis nascem e crescem fora do ciclo do PAM tradicional.

•     Segredos de aplicações e de pipelines pertencem à gestão de segredos e à identidade de workload, e não ao cofre de senhas para pessoas.

•     Usuários comuns com acesso demais continuam sendo um problema de menor privilégio.

Um programa maduro combina PAM com IGA, gestão de segredos e monitoramento de identidade.

Checklist rápido para o seu próximo projeto

1.    Faça o inventário das contas privilegiadas e atribua um dono a cada uma.

2.    Defina o escopo pelo risco: domínio, nuvem, bancos de dados e Linux antes do resto.

3.    Feche o acesso direto: o administrador entra pelo PAM ou não entra.

4.    Rotacione primeiro as contas interativas e mapeie as dependências antes das contas de serviço.

5.    Tire os segredos de scripts e arquivos de configuração.

6.    Proteja o PAM com MFA resistente a phishing, administradores dedicados e uma conta de emergência testada.

7.    Grave as sessões críticas e defina quem revisa, com que frequência e quando alertar.

8.    Escolha duas funções de alto risco para o primeiro piloto de acesso just-in-time e meça o tempo de concessão.

Conclusão

O PAM não é um cofre: é uma escada. Primeiro descobrir, depois guardar e trocar, depois observar e, por fim, deixar de ter privilégio permanente. Quem para no cofre protege a senha, mas mantém o privilégio aberto o tempo todo.

No próximo texto, falamos de auditoria de IAM: o que SOX, ISO 27001 e a regulação bancária pedem.

Referências

•     MITRE ATT&CK, T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/

•     NIST, SP 800-53 Rev. 5, Security and Privacy Controls (controle AU-14, Session Audit): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final