A senha nunca foi o único problema: PAM legado vs. PAM moderno

Parte 1 de 3 da nossa série Rethinking Privileged Access.

A conversa sobre gerenciamento de acesso privilegiado (PAM) originalmente girava em torno de uma pergunta: como protegemos a senha? Guardá-la em um cofre. Rotacioná-la. Injetá-la nas sessões para que ninguém a veja. Protegê-la com aprovações e MFA para que apenas a pessoa certa possa obtê-la. O PAM legado é uma das respostas mais maduras e amplamente implantadas para essa pergunta.

Resolver o problema da senha é algo importante, mas está longe de ser o único. Zero trust, privilégio permanente zero e acesso just-in-time amadureceram desde que o PAM legado foi projetado, mas ele não acompanhou.

Esse é o ponto de bifurcação entre o PAM legado e o PAM moderno com Netwrix Privilege Secure (NPS). O PAM legado foi excelente naquilo para o qual foi criado, mas deter ataques modernos exige uma ferramenta criada para outra coisa.

PAM legado: proteger a senha

O PAM legado parte de uma premissa: contas privilegiadas existem permanentemente, e seu trabalho é protegê-las da melhor forma possível. Se uma conta é membro de Domain Admins hoje, continuará sendo amanhã, na semana que vem e no ano que vem, quer alguém esteja usando esse privilégio ou não. O PAM legado atua como um guardião disciplinado diante desse privilégio permanente.

Na prática, esse controle se parece com isto:

• Um usuário precisa de acesso a uma conta privilegiada. Primeiro, ele precisa das permissões corretas dentro da própria ferramenta PAM, por meio de atribuições de função ou acesso ao segredo no nível da pasta.
• Dependendo da política, ele pode precisar atender ao MFA antes de seguir adiante.
• Ele solicita acesso ao segredo (um check-out), o que pode exigir a aprovação de um ou mais aprovadores designados.
• Depois de aprovado, o usuário normalmente nunca vê a senha. A ferramenta inicia uma sessão RDP ou SSH e injeta a credencial diretamente nela.
• O check-out tem um limite de tempo. Quando o usuário termina ou o tempo se esgota, a ferramenta faz o check-in do segredo novamente.
• Após o check-in, a ferramenta rotaciona a senha, então mesmo uma credencial exposta durante o uso deixa de ser válida.

Esse modelo elimina a exposição de credenciais, cria uma trilha de auditoria limpa e impõe controles de aprovação antes que alguém toque em uma conta sensível. Mas, por mais rigoroso que seja o fluxo, a conta subjacente continua sendo Domain Admin (ou administrador local, ou sudoer) entre as sessões. O privilégio é permanente. Apenas o acesso à senha é temporário. Um administrador também pode pegar uma senha para um trabalho “rápido” fora da ferramenta, contornando todos esses controles.

O PAM legado também tem um limite rígido no Active Directory. Ele lê a associação a grupos para decidir quem acessa os segredos, mas não cria, exclui nem modifica grupos do AD. A associação a grupos, e o privilégio permanente que ela traz, fica totalmente fora do seu controle.

A parte 2 desta série aborda os ataques que contornam o acesso à senha ou que nem precisam dele, e por que o just-in-time e o privilégio permanente zero são tão poderosos.

Quando fornecedores de PAM legado dizem “just-in-time” ou “privilégio permanente zero”, eles se referem ao acesso à senha, não ao privilégio na conta. Também vão dizer que um just-in-time real exige um produto separado de gerenciamento de privilégios em endpoints. Esse produto controla os direitos de administrador local em computadores de funcionários. É uma forma de just-in-time, mas não cobre as contas que sustentam sua infraestrutura crítica, que é o trabalho do PAM. A Netwrix também oferece um produto nessa categoria: Netwrix PolicyPak.

PAM moderno: o Netwrix Privilege Secure elimina o privilégio permanente

O Netwrix Privilege Secure parte de uma premissa diferente. Em vez de perguntar “como protegemos uma conta poderosa?”, pergunta “por que uma conta poderosa precisa ser poderosa o tempo todo?”

O NPS se concentra na sessão e nas Activities, que são executadas antes, durante e depois dessa sessão para conceder o privilégio exatamente quando ele é necessário e removê-lo no momento em que deixa de ser. O NPS oferece suporte a três abordagens de conta, e cada uma lida com esse ciclo de vida de forma diferente.

1. Contas do solicitante

Esta é a conta que o usuário já usa para fazer login no computador e no e-mail, sem nenhuma conta privilegiada separada envolvida. Quando uma sessão começa, uma Activity concede o privilégio na hora, por exemplo adicionando o usuário ao Domain Admins ou a outro grupo privilegiado do AD. Como é a conta própria do usuário, a senha não fica guardada em um cofre, e o usuário a digita durante a sessão. Quando a sessão termina, o NPS remove automaticamente o privilégio que concedeu no início.

Muitas vezes é a mais conveniente das três abordagens, mas oferece a menor proteção de credenciais, já que a senha não é rotacionada nem injetada. Ainda assim, elimina o privilégio permanente, porque a conta só tem direitos elevados pela duração da sessão.

2. Contas gerenciadas

Esta é a abordagem mais próxima de como o PAM legado funciona. Quando uma sessão começa, o NPS rotaciona a senha da conta e a habilita. As Activities concedem o privilégio para essa sessão, por exemplo adicionando a conta ao Domain Admins, aos Administradores locais ou a um grupo sudo. A senha é injetada na sessão, então o usuário nunca a vê.

A diferença aparece no final: o NPS rotaciona a senha novamente e a guarda no cofre, reverte o privilégio concedido e desabilita a conta. A conta continua existindo, mas entre as sessões não tem privilégios e não consegue se autenticar, o que torna uma senha roubada inútil para um atacante.

3. Contas efêmeras

Este modelo vai além, criando uma conta totalmente nova no início de cada sessão. Durante a sessão, ele se comporta como uma conta gerenciada: o privilégio é concedido e a senha é injetada. Quando a sessão termina, o NPS exclui a conta por completo, sem deixar nada para ser atacado.

Além do privilégio: o que mais as Activities podem fazer

Conceder e revogar a associação a grupos é o recurso principal, mas as Activities também fecham caminhos de ataque que modelos de acesso permanente costumam deixar abertos:

• Limpeza de tickets Kerberos. Quando uma sessão RDP termina, o NPS pode limpar os tickets Kerberos do recurso, cortando um caminho de movimento lateral que não exige a senha de uma conta.
• Ativar/desativar RDP. A maioria dos servidores Windows deixa o RDP ativo por padrão. O NPS pode ativá-lo apenas no início de uma sessão e desativá-lo logo em seguida, removendo uma superfície de ataque grande e constantemente disponível.
• Modo de proteção. O NPS pode verificar recursos Windows ou Linux em busca de contas locais não aprovadas. Um insider mal-intencionado que use sua ferramenta PAM corretamente poderia criar discretamente administradores locais para um uso não autorizado no futuro.
• Sincronização de replicação de DC. Uma mudança de privilégio em um controlador de domínio nem sempre se propaga imediatamente para o DC que trata a autenticação da sessão. O NPS pode forçar uma sincronização direcionada para que o privilégio concedido fique disponível de imediato, em vez de aguardar o tempo normal de replicação do AD.

Comparativo

O PAM legado reduziu o risco das credenciais. O PAM moderno elimina o alvo.

O modelo de check-out/check-in do PAM legado é uma forma madura e bem testada de reduzir a exposição de credenciais e adicionar responsabilização ao acesso privilegiado. Para muitas organizações, foi um grande avanço em relação às senhas compartilhadas e não gerenciadas.

O Netwrix Privilege Secure foi criado para os ataques de hoje. Ele trata o próprio privilégio permanente, junto com a senha que o protege, como a superfície de ataque a ser eliminada. Seja a conta própria de um usuário elevada apenas pela duração de uma sessão, uma conta gerenciada que não serve para nada entre um uso e outro ou uma conta efêmera que deixa de existir quando o trabalho termina, a lógica é a mesma: se não há privilégio esperando para ser usado, não há nada para um atacante roubar.

Próximos capítulos desta série

Eliminar o privilégio permanente interrompe muito mais do que o fluxo de check-out/check-in que o PAM legado foi criado para proteger. Parte 2, Além do cofre: como o NPS neutraliza mais do que ataques a senhas, percorre a superfície de ataque mais ampla de credenciais no Windows e no Active Directory (hashes NTLM, tickets Kerberos, Kerberoasting, credenciais de domínio em cache e outros) e mostra quais desses ataques o modelo de sessão do NPS fecha e quais não fecha.

Depois, Parte 3 mostra como o Bring Your Own Vault permite obter essas proteções em nível de sessão sobre o cofre que você já usa, sem uma migração do tipo rip-and-replace.