GitHub

A maioria das pessoas confunde autenticação com autorização, e essa confusão custa caro. Autenticar é provar quem você é, login, senha, token, biometria. Autorizar é decidir o que você, já identificado, tem o direito de fazer. São problemas distintos, e o segundo é onde mora a maior parte dos vazamentos e fraudes internas.

É comum ver sistemas com login impecável e autorização frouxa. A porta da frente tem fechadura biométrica, mas, uma vez dentro, qualquer pessoa abre qualquer gaveta. O atacante não precisa quebrar sua autenticação se, depois de entrar com uma conta comum, consegue acessar dados que não deveria.

Este texto reúne os passos essenciais e as melhores práticas de autorização. O objetivo é prático: garantir que cada usuário, sistema ou serviço acesse exatamente o que precisa, nem mais, nem menos.

O princípio que sustenta tudo: menor privilégio

Se você só levar uma ideia deste texto, leve esta: dê a cada usuário o mínimo de acesso necessário para fazer o trabalho dele, e nada além disso. É o princípio do menor privilégio, e ele resolve, na prática, a maioria dos problemas de autorização.

A tentação contrária é forte. É mais fácil dar acesso amplo "para não travar ninguém" e lidar com as consequências depois. Só que cada permissão a mais é uma porta a mais. Quando uma conta é comprometida, o estrago é proporcional ao que aquela conta podia fazer. Contas com poder demais transformam um incidente pequeno em catástrofe.

Menor privilégio não é desconfiança das pessoas. É reconhecer que contas são comprometidas, erros acontecem e o dano deve ser contido por desenho.

Passo 1: modele papéis antes de distribuir permissões

Distribuir permissão usuário por usuário não escala e vira bagunça em pouco tempo. A prática madura é organizar acesso por papéis, o modelo conhecido como RBAC (controle de acesso baseado em papéis).

Em vez de dizer "o João pode ver relatórios financeiros", você define o papel "analista financeiro" com um conjunto de permissões, e atribui esse papel ao João. Quando o João sai e a Maria entra, você só troca quem ocupa o papel. As permissões ficam descritas em um lugar, auditáveis e consistentes.

Para cenários mais complexos, existe o controle baseado em atributos (ABAC), onde a decisão considera contexto, horário, localização, sensibilidade do dado. Mas comece simples. RBAC bem-feito resolve a esmagadora maioria dos casos, e complexidade prematura aqui só gera erro.

Passo 2: centralize a decisão de autorização

Um erro arquitetural comum é espalhar regras de permissão por todo o código, um "if" aqui, uma checagem ali. Com o tempo, ninguém sabe ao certo quem pode o quê, e as regras divergem entre partes do sistema.

A boa prática é tratar autorização como uma responsabilidade central, com um ponto claro onde as decisões são tomadas. Não importa se é uma biblioteca, um serviço ou um módulo, o importante é que a pergunta "esse usuário pode fazer isso?" seja respondida de forma consistente, em um lugar que dá para auditar e mudar.

Isso também facilita a vida na hora de provar conformidade. Quando um auditor, ou a própria LGPD, no caso de dados pessoais, pergunta quem tem acesso a quê, você consegue responder olhando um lugar, não vasculhando o código inteiro.

Passo 3: nunca confie só no que o cliente diz

Aqui está uma das falhas mais perigosas e mais comuns. O frontend esconde um botão que o usuário não deveria ver, e o time considera o problema resolvido. Não está. Esconder o botão é experiência, não segurança.

A autorização precisa ser verificada no backend, em toda requisição, sempre. Um atacante não usa a sua interface, ele chama a API diretamente. Se a única barreira é visual, não há barreira. A regra é simples e inegociável: o cliente pode sugerir, o servidor decide.

O mesmo vale para identificadores. Se o sistema deixa o usuário acessar um recurso só trocando o número na URL, sem verificar se aquele recurso é dele, você tem uma das vulnerabilidades mais exploradas que existem, o acesso indevido a objeto por referência direta, catalogado há anos pelo OWASP. Verifique posse, não apenas existência.

Passo 4: torne o acesso revogável e auditável

Acesso concedido precisa poder ser tirado, e rápido. Quando alguém sai da organização, muda de função ou tem a conta comprometida, você precisa cortar o acesso na hora, não na próxima sprint.

Isso pressupõe duas coisas. Primeiro, saber quem tem acesso a quê, o que volta ao ponto de centralizar e modelar por papéis. Segundo, registrar quem acessou o quê e quando. O log de acesso não impede o problema, mas é o que permite investigar, responder e aprender depois de um incidente. Sistema sem trilha de auditoria é sistema que não sabe o que aconteceu com ele.

Reflexão crítica: o acúmulo silencioso de privilégios

Há um problema que cresce sem ninguém perceber: o acúmulo de permissões ao longo do tempo. A pessoa muda de área, ganha acessos novos e mantém os antigos. Anos depois, ela acumula permissões de três funções que já teve. Ninguém revisou, porque revisar dá trabalho e não dá troféu.

Esse acúmulo é uma bomba-relógio. Quando uma dessas contas é comprometida, o acesso é desproporcional. A defesa é desconfortável mas necessária: revisão periódica de acessos. Olhar de tempos em tempos e perguntar "essa pessoa ainda precisa disso?". Quase sempre a resposta, para uma parte das permissões, é não.

O outro desafio é cultural. Autorização restritiva gera atrito, e atrito gera reclamação. O usuário quer acesso amplo, o gestor quer agilidade, e a segurança vira a vilã que trava todo mundo. Sustentar o menor privilégio exige convicção de liderança, e a clareza de que o atrito de hoje é mais barato que o vazamento de amanhã.

O que fica

Autorização bem-feita é invisível quando funciona e devastadora quando falha. Ela não aparece em demonstração de produto, não impressiona em reunião, e mesmo assim é uma das decisões mais consequentes de qualquer sistema que lida com dado sensível.

Os passos são claros: menor privilégio como princípio, papéis em vez de permissões soltas, decisão centralizada, verificação no servidor e acesso revogável e auditável. Nenhum deles é sofisticado. Todos são frequentemente ignorados.

Se a sua organização lida com dados sensíveis e você não tem certeza de quem pode acessar o quê, esse é um bom momento para revisar. No blog há outros textos sobre segurança, controle de acesso e conformidade que aprofundam o tema.

Autorização e permissões: as melhores práticas que evitam o acesso indevido