Autorização e Permissões em Aplicativos: Controle de Acesso Seguro

Autorização define o que um usuário autenticado pode fazer. Enquanto autenticação confirma identidade, autorização controla acesso a recursos e ações. Este guia apresenta modelos, implementações e boas práticas para construir sistemas de permissões robustos.

Autenticação vs Autorização

Autenticação

Responde: "Quem é você?". Verifica identidade através de credenciais.

Autorização

Responde: "O que você pode fazer?". Determina permissões após identidade confirmada.

Exemplo Prático

Usuário faz login (autenticação). Sistema verifica se pode acessar painel admin (autorização).

Por Que Autorização Importa

Sem controle de acesso adequado, qualquer usuário autenticado acessa qualquer recurso. Dados sensíveis ficam expostos, ações destrutivas ficam disponíveis. Autorização protege dados e operações críticas.

Modelos de Controle de Acesso

ACL (Access Control List)

Lista que define quem pode acessar cada recurso. Simples, mas não escala bem para sistemas complexos.

RBAC (Role-Based Access Control)

Permissões atribuídas a roles, roles atribuídas a usuários. Estrutura hierárquica. Modelo mais comum.

ABAC (Attribute-Based Access Control)

Decisões baseadas em atributos: do usuário, do recurso, do ambiente. Flexível, mas complexo.

ReBAC (Relationship-Based Access Control)

Baseado em relacionamentos entre entidades. "Pode editar se for dono". Usado por Zanzibar (Google).

RBAC em Detalhes

Componentes

• Usuários: Pessoas ou sistemas que acessam.
• Roles: Conjuntos de permissões (Admin, Editor, Viewer).
• Permissões: Ações permitidas (create, read, update, delete).
• Recursos: Objetos protegidos (posts, usuários, configurações).

Hierarquia de Roles

Roles podem herdar de outras. Admin herda de Editor, que herda de Viewer. Reduz duplicação.

Exemplo de Estrutura

Admin: [create, read, update, delete] em [todos recursos]
Editor: [create, read, update] em [conteúdo]
Viewer: [read] em [conteúdo público]

Implementação de RBAC

Banco de Dados

Tabelas para users, roles, permissions e relacionamentos (user_roles, role_permissions).

Middleware de Verificação

Antes de ação, middleware verifica se usuário tem permissão necessária.

Decorators/Guards

Em frameworks modernos, annotations que protegem rotas ou métodos.

Caching de Permissões

Evite consultar banco a cada requisição. Cache permissões do usuário em token ou Redis.

ABAC: Flexibilidade Avançada

Quando Usar

Quando RBAC não é expressivo o suficiente. Regras dependem de contexto dinâmico.

Exemplos de Políticas

• Pode editar se for autor do documento.
• Pode acessar se estiver no mesmo departamento.
• Pode aprovar se valor for menor que seu limite.

XACML

Padrão para expressar políticas ABAC. XML-based, usado em ambientes enterprise.

Permissões em Nível de Recurso

Row-Level Security

Controle por registro. Usuário só vê seus próprios dados. PostgreSQL tem suporte nativo.

Column-Level Security

Controle por campo. Certos campos só visíveis para certos roles.

Multi-Tenancy

Isolamento entre tenants. Cada organização só acessa seus dados.

Permissões do Sistema Operacional

iOS

Acesso a câmera, localização, fotos exige permissão explícita do usuário. Info.plist define descrições.

Android

Permissões declaradas no Manifest. Dangerous permissions exigem consentimento runtime.

Boas Práticas

• Peça no momento de uso, não upfront.
• Explique por que precisa.
• Funcione graciosamente se negada.

Tokens e Claims

JWT Claims

Token pode conter claims de permissão. Servidor valida sem consultar banco.

Scopes em OAuth

Definem que recursos o token pode acessar. read:users, write:posts.

Cuidados

Tokens grandes impactam performance. Balance claims inline vs consulta.

Autorização em APIs

Verificação por Endpoint

Cada endpoint verifica permissão específica antes de executar.

Resource Servers

Servidor de API valida tokens e autoriza com base em scopes e claims.

Policy Decision Point (PDP)

Serviço centralizado que decide autorizações. Open Policy Agent (OPA) é exemplo.

Padrões de Implementação

Deny by Default

Negue acesso a menos que explicitamente permitido. Falha segura.

Least Privilege

Conceda mínimo necessário. Usuário só pode o que precisa.

Separation of Duties

Tarefas críticas exigem múltiplas pessoas. Ninguém faz tudo sozinho.

Auditoria e Logging

Registre Decisões

Log de quem tentou acessar o quê e se foi permitido ou negado.

Detecção de Anomalias

Padrões suspeitos: muitas negações, acessos fora do horário, escalação de privilégio.

Compliance

Regulações exigem trilha de auditoria. GDPR, SOX, HIPAA.

Erros Comuns

Verificação Apenas no Frontend

Backend deve sempre verificar. Frontend é manipulável.

Roles Hardcoded

Dificulta evolução. Use configuração flexível.

Permissões Excessivas

Por conveniência, dar mais acesso que necessário. Princípio do menor privilégio.

Falta de Teste

Permissões mal testadas criam brechas. Teste cenários de acesso.

Ferramentas e Bibliotecas

Casbin

Biblioteca de autorização com suporte a múltiplos modelos (RBAC, ABAC, ACL).

Open Policy Agent (OPA)

Motor de políticas. Decisões de autorização como código.

Auth0 FGA

Fine-Grained Authorization. Modelo similar ao Zanzibar do Google.

Ory Keto

Implementação open source inspirada em Zanzibar.

Multi-Tenancy e Autorização

Isolamento

Tenants não acessam dados uns dos outros. Verificação em todas as queries.

Roles por Tenant

Usuário pode ter roles diferentes em organizações diferentes.

Super Admin

Acesso cross-tenant para operações de plataforma. Use com extremo cuidado.

Conclusão

Autorização bem implementada protege dados e garante que usuários façam apenas o que devem. Escolha modelo adequado (RBAC para maioria), implemente com deny by default, teste exaustivamente e audite acesso. Segurança é processo contínuo, não configuração única.

FAQs

1) RBAC é suficiente para a maioria dos casos? Sim. RBAC atende bem a maioria dos aplicativos. ABAC é para cenários mais complexos.

2) Onde armazenar permissões? Banco de dados para fonte da verdade. Cache (JWT claims, Redis) para performance.

3) Como lidar com permissão negada? Retorne 403 Forbidden com mensagem genérica. Não revele detalhes da política.

4) Preciso de serviço de autorização separado? Para sistemas grandes, pode valer. Para apps menores, biblioteca integrada basta.

5) Como testar autorização? Testes automatizados que verificam acesso permitido e negado por role/permissão.