Princípio do Menor Privilégio

O princípio do menor privilégio determina que cada identidade, humana ou de serviço, receba apenas as permissões estritamente necessárias para executar sua função atual, pelo tempo necessário e sobre os recursos necessários. Em produção, ele é o controle que limita o blast radius de qualquer comprometimento: uma credencial roubada vale exatamente o que a política dela vale, e nada mais. O princípio é antigo na segurança de sistemas, mas ganhou execução prática em nuvem, onde ferramentas como o IAM Access Analyzer revelam, a partir do log real, quais permissões nunca foram usadas. A dificuldade nunca foi conceitual, e sim organizacional: apertar permissões encontra atrito com prazos e com o medo de quebrar produção. Este arquivo trata de como aplicar o princípio sem transformá-lo em burocracia que o time contorna.

Conceito e fundamento

Menor privilégio é a negação por padrão organizada: nada é permitido sem justificativa, e cada concessão carrega escopo, prazo e dono. O princípio opera em três dimensões que precisam ser declaradas juntas. A dimensão de ação define quais operações são possíveis; a de recurso define sobre o que; a de condição define quando e de onde. Um acesso que cuida só da primeira dimensão, como conceder s3:* a um usuário, falha nas outras duas e produz privilégio muito maior que o necessário.

A medida de sucesso não é que nada quebre, e sim que o dano potencial de cada credencial seja computável. Quando alguém pergunta qual o pior caso de uma chave vazada, a resposta precisa ser uma lista finita de ações sobre um conjunto finito de recursos. Se a resposta é acesso total à conta, o princípio não está aplicado, independentemente de o incidente ter acontecido.

O problema que resolve

O problema central é a amplificação de incidentes por permissão excessiva. Credenciais estáticas vazadas em repositórios públicos são descobertas por bots em minutos, e o que acontece em seguida depende inteiramente da política anexada. Com permissão ampla, o atacante monta instâncias para minerar criptomoeda, apaga snapshots de backup ou exfiltra buckets inteiros; com permissão mínima, o mesmo vazamento se reduz a uma leitura de prefixo específico, detectável e reversível.

• Blast radius reduzido: cada comprometimento fica confinado ao escopo da identidade comprometida, e o plano de resposta trabalha um perímetro conhecido.
• Auditoria viável: políticas pequenas e nomeadas por função tornam a revisão humana possível, enquanto políticas gigantes escondem excessos em volume ilegível.
• Conformidade demonstrável: LGPD, PCI DSS e ISO 27001 exigem controle de acesso por mínimo necessário, e a política em código é a evidência direta.
• Menos erro humano: um time com permissão de deletar produção por acidente criará esse acidente; permissão mínima também protege o time contra si mesmo.

Como aplicar: concessão mínima estruturada

A concessão mínima começa com uma pergunta de desenho: qual tarefa essa identidade executa, sobre quais recursos, em que condições? A resposta vira a política, e não o caminho inverso, que é copiar uma policy ampla e confiar. Aplicar o princípio é um processo cíclico de quatro movimentos que se repete a cada mudança de escopo:

1. Declarar a tarefa: nomear a função de trabalho e o resultado esperado, como "a API lê objetos do prefixo consolidado do bucket de faturamento".
2. Conceder o mínimo visível: mapear a tarefa para ações, recursos e condições concretas, sem wildcards de ação e com recurso nomeado.
3. Medir o uso real: executar em produção com CloudTrail e Access Analyzer registrando o que de fato foi chamado.
4. Apertar com evidência: remover ações e recursos sem uso, estreitar condições e repetir o ciclo na próxima mudança de escopo.

O erro comum é começar pelo passo 3 sem ter passado pelo 2: medir o uso de uma política aberta revela o que foi usado, mas não o que foi tentado e bloqueado, e a tentativa frustrada também é dado para o desenho.

Começar amplo e apertar com dados de uso

Na prática, equipes novas em um domínio não sabem de antemão todas as permissões de que precisam, e tentar adivinhar o mínimo no primeiro dia gera bloqueio e revolta. A estratégia funcional é começar com um escopo delimitado, mas mais largo que o provável, e apertar com dados de uso em uma janela curta e declarada. O IAM Access Analyzer gera políticas a partir da atividade registrada no CloudTrail: você aponta uma role e um período, e a ferramenta propõe uma política com as ações efetivamente chamadas, agrupadas por serviço.

O mesmo vale para credenciais humanas: o campo de último uso de cada Access Key e o relatório de credenciais da conta mostram chaves que nunca foram usadas, que são remoção imediata. Revisões de acesso periódicas usam esse dado para fazer a pergunta correta, que não é "esse acesso parece razoável", e sim "esse acesso foi usado nos últimos noventa dias". Permissão sem uso por dois ciclos seguidos sai sem discussão, porque a evidência é objetiva.

Políticas por função de trabalho

Políticas eficazes são escritas por função de trabalho e não por pessoa. A função descreve uma responsabilidade estável, como operador de pipeline, aplicação de faturamento ou auditor de compliance, e a política herda o nome da função. Esse desenho tem três efeitos práticos: onboarding acelera porque atribuir acesso é anexar uma função existente; revisão escala porque o número de funções é pequeno e fechado; e auditoria responde à pergunta regulatória correta, que é quem com qual responsabilidade pode fazer o quê.

• Função por responsabilidade: o nome da política descreve a tarefa de trabalho, e não o time ou a pessoa, para sobreviver a reorganizações.
• Camadas somáveis: funções base compartilhadas mais escopos específicos por projeto, evitando cada função como variante única de todas as outras.
• Separação de deveres: funções que criam e aprovam mudanças ficam separadas de funções que aprovam e auditam, impedindo que o mesmo principal escreva e valide.
• Escopo por ambiente: as funções de desenvolvimento não alcançam produção como padrão; o acesso cruzado é uma função própria, justificada e monitorada.

Exemplo: política aberta versus apertada

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AntipadraoAcessoAberto",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

A política acima concede controle total sobre todos os buckets de todas as regiões, incluindo gerenciamento de políticas, versões e replicação. É o ponto de partida típico de um deploy que precisa resolver um erro de permissão, e o ponto de permanência típico de quem não revisa.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeituraDoPrefixoConsolidado",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::dados-faturamento",
        "arn:aws:s3:::dados-faturamento/consolidado/*"
      ],
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "sa-east-1" }
      }
    },
    {
      "Sid": "EscritaSomenteEmStaging",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::dados-faturamento/staging/*"
    }
  ]
}

A versão apertada expressa a mesma tarefa com ação nomeada, recurso delimitado e condição de região. O esforço de escrevê-la é de minutos quando a função já foi declarada, e o Access Analyzer pode gerar o rascunho inicial a partir do uso real.

Revisão periódica e ciclo de vida

Privilégio mínimo não é estado alcançado uma vez, e sim propriedade mantida por cadência. Sem revisão, qualquer sistema de acesso tende ao monopólio por acúmulo: pessoas trocam de função e mantêm o acesso antigo, serviços são aposentados e as roles continuam ativas, e concessões de emergência viram permanentes. O ciclo de vida formal precisa amarrar quatro eventos a quatro ações:

• Entrada de pessoa ou serviço: acesso pela função de trabalho declarada, nunca por cópia do colega, com data de primeira revisão agendada.
• Mudança de função: permissões do papel anterior são revogadas no mesmo dia em que as novas são concedidas, e não quando sobrar tempo.
• Saída ou desativação: revogação automática integrada ao RH e ao inventário de serviços, com verificação de chaves e sessões ativas.
• Revisão periódica: varredura trimestral por dados de uso, com remoção por padrão de tudo que não foi usado na janela de observação.

O dado que sustenta essa cadência é objetivo: relatório de credenciais com último uso de cada chave, CloudTrail com ações chamadas por principal e Access Analyzer com recursos expostos. Revisões conduzidas por evidência terminam com permissões removidas; revisões conduzidas por opinião terminam com ata assinado e nada alterado.

Equilíbrio com a velocidade do time

Menor privilégio falha quando é implementado como fila de tickets: cada concessão depende de um time de plataforma reagir em dias, e o produto atrasa. O equilíbrio funcional passa por três alavancas. A primeira é self-service com guarda-corpo: o time pede e recebe acesso comum automaticamente, e a boundary técnica impede qualquer pedido fora do teto da aplicação. A segunda é tempo de concessão: acesso de emergência é imediato, temporário e auditado, em vez de permanente e demorado. A terceira é aperto automatizado: revisões por dados de uso, e não por reunião de opinião.

O sinal de que o equilíbrio funciona é a ausência de política-gaveta: não existem permissões genéricas mantidas "para não precisar pedir depois". Se o time precisa de velocidade, o caminho é melhorar o processo de concessão, nunca conceder tudo de uma vez.

Erros comuns

• Concessão ampla por conveniência em emergência, sem prazo de expiração; toda concessão de incidente precisa de TTL e de revisão no post-mortem.
• Aperto quebrando produção sem plano: retirar permissão de uma vez em vez de usar CloudTrail para validar que a ação não ocorre há meses.
• Revisão de acesso sem remoção: a reunião acontece, o relatório é assinado, nenhuma permissão é retirada; revisão sem consequência é teatro.
• Permissão herdada invisível: políticas anexadas a grupos aninhados e roles cross-account que ninguém inventariou; sem inventário, o mínimo não é mensurável.
• Wildcards em Resource por falta de padronização de nomes: quando buckets e filas não seguem convenção, apertar recursos se torna caro e a conta inteira fica como escopo.
• Princípio aplicado só a humanos: as roles de serviço costumam ser as mais amplas, e são justamente as expostas em runtime.

Boas práticas em produção

Declare funções de trabalho em código, versionadas no mesmo repositório da aplicação, com testes de política que falham quando um wildcard aparece onde ação nomeada era possível. Use Access Analyzer na rotina, tanto para gerar rascunhos de política quanto para alertar sobre recursos compartilhados com entidades externas sem intenção.

Estabeleça cadência dupla: revisão trimestral com remoção por padrão de permissões sem uso, e revisão por evento a cada mudança de escopo de serviço. Para produção, exija justificativa de negócio em qualquer política com Resource "*" e trate exceções como dívida com prazo. O princípio do menor privilégio não é um estado final alcançado, e sim um ciclo contínuo de concessão mínima, medição de uso e aperto com evidência, executado com a mesma disciplina de qualquer outro trabalho de engenharia.