Princípio do Menor Privilégio, Explicado

O princípio do menor privilégio parece óbvio quando você o enuncia: conceda a uma conta, processo ou usuário apenas o acesso necessário para fazer seu trabalho, nada mais. O abismo entre dizer isso e realmente operar seus sistemas dessa forma é onde a maioria das violações sai de um incidente menor para um compromisso total do domínio.

O que realmente significa

O princípio do menor privilégio (PoLP) diz que todo assunto em um sistema — um usuário, uma conta de serviço, uma aplicação, um container — deve operar com o conjunto mínimo de permissões necessárias para completar sua função. Não as permissões que são convenientes. Não as permissões que alguém concedeu três anos atrás e esqueceu de revogar. O mínimo.

Isso se aplica em todas as camadas: permissões do sistema de arquivos, funções de banco de dados, escopos de API, políticas IAM na nuvem, regras de firewall, acesso a sudo. Um processo de servidor web lendo arquivos estáticos não precisa de acesso de escrita para /etc. Um script de relatórios que apenas executa queries SELECT não precisa de uma função de banco de dados com direitos de DROP TABLE. Um estagiário de marketing não precisa ser admin de domínio porque era mais fácil do que descobrir o grupo correto.

Por que importa mais do que parece

Quando um atacante compromete uma conta ou um processo, ele herda tudo o que essa conta pode fazer. Se o laptop de um funcionário phishing tem acesso apenas aos compartilhamentos de arquivos relevantes para seu time, o raio de ação do phishing fica contido. Se essa mesma conta tem direitos de admin de domínio porque a TI configurou assim uma vez para troubleshooting e nunca reverteu, o atacante agora controla a rede.

Esta é a lógica por trás da maioria dos relatórios de análise forense pós-violação: o acesso inicial tinha baixo valor, mas o movimento lateral através de contas com permissões excessivas o transformou em ransomware em todo o ambiente. Privilégio em excesso não causa o compromisso inicial, mas é quase sempre o que torna o compromisso custoso.

Onde aparece na prática

IAM na nuvem. AWS, Azure e GCP usam comportamento permissivo por padrão se você não tomar cuidado — uma política IAM com "Action": "*" e "Resource": "*" passa na validação e funciona perfeitamente, até o momento em que uma chave de acesso vazada entrega ao atacante o controle total da conta. Restrinja as políticas a ações específicas e ARNs de recurso em vez de usar wildcards.

Contas de serviço. Estas são frequentemente as piores infratoras porque ninguém as revisa do jeito que revisa contas humanas. Um pipeline de CI/CD que implanta em um bucket S3 não deveria ter credenciais que podem ler todos os buckets da conta.

Funções de banco de dados. Separe funções de relatórios somente leitura de funções de aplicação que precisam de INSERT/UPDATE, e separe essas da função DBA que pode alterar schema. PostgreSQL e MySQL suportam declarações GRANT granulares — use-as em vez de dar a cada conexão de app o equivalente a root.

Sudo e admin local. Elevação just-in-time (solicite acesso, receba por uma janela limitada, perca automaticamente) vence direitos de admin permanentes sempre. Ferramentas como sudo com regras com limite de tempo, ou soluções PAM em ambientes empresariais, existem especificamente para isso.

A tensão com