Sobre privilégio mínimo, JIT e autorização forte

Trabalho como profissional de segurança há mais de 20 anos. Não consigo contar quantas vezes pronunciei as palavras “privilégio mínimo”. É como um pequeno mantra, sentado no mesmo banco que “defesa em profundidade” e “ameaça interna”.

Mas dizer a alguém para aplicar o privilégio mínimo e sair da sala equivale ao médico dizer-lhe para “comer de forma mais saudável” enquanto o reprova no exame médico do seguro e sai da sala antes de lhe cobrar em excesso.

O privilégio mínimo é real. É importante. Ao contrário de mudar as palavras-passe a cada 90 dias, pode ter um impacto material na melhoria da sua segurança.

O privilégio mínimo também é muito difícil. Sobretudo em escala. E não funciona para os seus utilizadores mais importantes.

Porquê? Porque o privilégio mínimo não são os privilégios mínimos de que precisa naquele momento, são os privilégios mínimos de que poderá vir a precisar para fazer o seu trabalho… alguma vez. E quando alguém precisa de fazer algo fora do âmbito definido quando esses privilégios foram mapeados pela primeira vez, inicia-se um processo de alteração lento que tem de atravessar diferentes equipas e gestores.

Ou, por vezes, basta convencer o Bob a dar-lhe acesso. E o Bob é uma espécie de chato defensivo, já que não confia em ninguém e não quer ser culpado quando você fizer asneira.

Mesmo com privilégio mínimo, se um atacante obtiver essas credenciais (a principal origem das violações nativas da cloud), é provável que ainda consiga fazer estragos. Porque, embora o privilégio mínimo nem sempre seja demasiado terrível de implementar para o utilizador ou colaborador médio, é muito difícil de aplicar a programadores e administradores que, por definição, precisam de mais privilégios.

Tal como temos MFA para autenticação forte, precisamos de algo para autorização forte.

É aqui que entra o Just in Time (JIT). Em vez de tentar determinar antecipadamente todos os privilégios de que alguém necessita, essa pessoa pode solicitar permissões com limite de tempo em qualquer momento. Acredito agora que o JIT deve ser o padrão para acessos administrativos e sensíveis.

Recomendo o privilégio mínimo como um excelente conceito para o acesso geral dos utilizadores, mas o JIT é melhor para qualquer nível de acesso de administração/desenvolvimento/sensível na cloud.

Just in Time

O JIT é uma variante de PIM/PAM. O Privileged Access Management e o Privileged Identity Management são sistemas concebidos para elevar os privilégios de um utilizador. Funcionam com um nível mais baixo até ser necessário elevar, e estes sistemas usam múltiplas técnicas para conceder acesso alargado, normalmente numa sessão com limite de tempo. Hoje não é o dia para entrar nas nuances, mas a vantagem é que permitem flexibilidade mantendo a segurança. Alguém tem de solicitar privilégios adicionais quando deles necessita, pelo que, mesmo que as suas credenciais sejam comprometidas, o atacante continua limitado.

“JIT” (Just in Time) é uma técnica para PAM/PIM (ou, na verdade, para qualquer acesso). Um utilizador tem credenciais base que podem não ter acesso a absolutamente nada e, depois, os seus privilégios são elevados mediante pedido. Nós próprios usamos JIT (e está disponível no Cloud Defense), e a Netflix lançou uma ferramenta open source chamada ConsoleMe baseada na sua ferramenta interna. O Azure tem um serviço integrado (mas com custo adicional) chamado Entra ID Privileged Identity Management. (Entra ID é o que costumávamos chamar Azure AD, antes de alguém ter decidido que era boa ideia confundir milhões de clientes por motivos de marca.) Existem mais opções; estes são apenas exemplos.

Para reforçar a segurança, o JIT tem de usar um fluxo de aprovação fora de banda e conceder acesso com limite de tempo. Estes são os princípios básicos. O pedido e a aprovação devem seguir um caminho diferente do da autenticação normal, como uma forma de MFA. A diferença é que a MFA é um fator fora de banda para a autenticação (provar que é quem diz ser) e o JIT é uma forma de autorização (solicita e recebe permissão para fazer algo).

Gerir a fricção

Tanto o privilégio mínimo como o JIT introduzem fricção. Quer dizer, tudo o que fazemos em segurança introduz algum tipo de fricção, sobretudo o Bob. Com o privilégio mínimo, a principal fricção é o esforço de definir e implementar privilégios, e o que deixa de funcionar quando alguém não tem os privilégios de que precisa. Com o JIT, a fricção é o processo de submeter e receber uma aprovação.

Tendo usado e estudado tanto o privilégio mínimo como o JIT durante muito tempo, aprendi técnicas para reduzir a fricção. Em alguns casos, acaba por obter processos mais rápidos e melhores do que a forma como historicamente fizemos as coisas

• O fluxo de pedido e aprovação tem de ser em tempo real. Isto significa aprovações via ChatOps, mensagens de texto ou o chip 5G implantado com a sua vacina contra a COVID.
• Para acessos com menos privilégios, como o acesso de leitura a alguns registos, pode e deve suportar uma autoaprovação. Como é que isto ajuda? Porque continua a usar o processo fora de banda e reduz a capacidade de um atacante tirar partido de credenciais perdidas/roubadas/expostas.
• Também pode suportar aprovações automáticas, em que nem sequer precisa de clicar para se autoaprovar. Como é que isto ajuda? Pode aprovar automaticamente, mas usar também o seu canal fora de banda para notificar que os privilégios foram elevados. Provavelmente já viu isto se alguma vez adicionou um dispositivo Netflix ou Hulu à sua conta. Só a consciencialização pode ser incrivelmente eficaz.
• Se isto for para programadores, tem de suportar a linha de comandos e as outras ferramentas que eles usam. Vá ter com eles. Torne o uso extremamente fácil. Se os obrigar a iniciar sessão numa ferramenta de segurança, o projeto vai falhar.
• Se os aprovadores não responderem, e de forma instantânea, vai falhar. Não faça do Bob o único aprovador.

Leve esta capacidade aos seus programadores/administradores nas ferramentas que já utilizam. Torne-a rápida e sem fricção. Idealmente, torne-a mais fácil e rápida do que abrir um gestor de palavras-passe ou navegar por um portal de SSO repleto de 374 contas cloud para escolher. Compre umas bolachas ao Bob. De pepitas de chocolate. (Ah, espere, esse sou eu.)

Também pode recorrer à automação para reduzir a fricção no acesso com privilégio mínimo. O Duckbill Group implementou a sua própria versão de privilégio mínimo automatizado com tecnologia diferente, com a ajuda de Chris Farris. Ferramentas como o AWS Access Advisor existem para o ajudar a monitorizar as permissões utilizadas e a reduzi-las. A automação existe para o ajudar a implementar o privilégio mínimo em escala e pode também ser um complemento ao JIT.

Quando usar cada um

O privilégio mínimo não é, de modo algum, um conceito morto. Continua a ser o padrão de excelência para utilizadores/colaboradores do dia a dia que precisam de um nível de acesso bastante consistente. O JIT é melhor para acessos mais privilegiados, sobretudo a ambientes de produção, e especialmente na cloud, onde as exposições de credenciais são A maior origem de violações. Eis onde nós próprios o usamos:

• Acesso de leitura de programadores à produção.
• Acesso de alteração de programadores à produção (fora do CI/CD). Muito mais restrito, exigindo mais aprovadores.
• Acesso de administração a contas de produção.
• Acesso para resposta a incidentes.
• Acesso a algumas contas de desenvolvimento, uma vez que pode ser mais rápido do que voltar ao portal de SSO, sobretudo quando se trabalha na linha de comandos.

Já não considero que o privilégio mínimo, por si só, seja um conceito válido para qualquer nível significativo de acesso privilegiado na cloud (IaaS/PaaS), mesmo quando usamos MFA forte. É demasiado difícil definir corretamente o âmbito das permissões em escala, ao longo do tempo. O JIT é uma opção muito melhor nestes casos de uso. O privilégio mínimo continua a ser bastante viável quando são necessárias permissões consistentes ao longo do tempo, sobretudo combinado com bons registos de acesso e MFA. O JIT é o companheiro da MFA. É a autorização forte a combinar com a sua autenticação forte. À medida que continuamos a mover operações mais críticas para planos de gestão expostos à Internet, o JIT é o caminho.