Conceder permissões de acesso pelo princípio do menor privilégio

O que é

O princípio do menor privilégio (least privilege) exige que uma conta ou um processo tenha exatamente os direitos que a sua tarefa requer – não os que seriam cômodos. O Linux oferece para isso ferramentas mais finas do que «root ou não root»: as capabilities dividem os direitos do superusuário em capacidades individuais; CAP_NET_BIND_SERVICE, por exemplo, permite apenas associar-se (bind) a portas abaixo de 1024, sem mais nada. No PostgreSQL, GRANT atribui direitos a roles por objeto e por ação (por exemplo SELECT, INSERT, UPDATE, DELETE), e as roles podem ser membros de outras roles, de modo que os direitos são agrupados em vez de distribuídos um a um.

Por que importa

O dano causado por um erro ou uma invasão fica limitado pelos direitos da identidade afetada. Um serviço web com uma role que só pode ler e escrever em duas tabelas não consegue apagar o schema em caso de SQL injection. Um script executado como usuário comum não consegue esvaziar o diretório raiz por causa de um erro de digitação. Para agentes automatizados isso vale em dobro: eles executam instruções cuja origem nem sempre conseguem avaliar, e os seus direitos são o limite máximo do dano possível.

Como aplicar

• Uma identidade própria por serviço e por ambiente: role de banco de dados própria, chave de API própria, usuário de sistema próprio; nunca uma conta «app» compartilhada para tudo.
• Derivar os direitos da tarefa e documentá-los: quais tabelas, quais ações, quais diretórios, quais destinos de rede? Tudo o que não estiver na lista não é concedido. As migrações rodam com uma role separada, em uma etapa separada.
• Iniciar processos sem root; onde um direito de root for necessário, conceder apenas a capability específica e descartar as demais.
• Para pessoas: conta padrão sem privilégios especiais, elevação apenas por tempo limitado e com registro em log, contas de administração separadas da conta do dia a dia.
• Negação como padrão: novos recursos ficam inacessíveis para todos até que alguém registre um direito – e não o contrário.
• Fazer limpeza regular: retirar direitos que não são usados há muito tempo; remover no mesmo dia as pessoas que saíram e os serviços desativados.

Armadilhas

Os direitos só crescem: cada correção de falha acrescenta um e ninguém o retira depois. Roles coletivas como «developer» com acesso à produção. O serviço tem poucos direitos, mas o seu token de deployment é administrador. O acesso de leitura é considerado inofensivo, embora exponha dados pessoais e segredos. O princípio do menor privilégio limita o abuso de direitos alheios, não o abuso dos próprios direitos legítimos; para isso são necessários registro em log e o princípio dos quatro olhos.