Segurança
Como controlar quem acessa qual dado, na prática
A regra que a IA escreve por padrão é: quem está logado vê tudo. Transformar isso em controle de verdade leva uma tarde e evita o vazamento mais comum que existe.
Existe uma pergunta que separa sistema com controle de acesso de sistema que só tem login:
O usuário A consegue ver o dado do usuário B?
Em muito sistema feito rápido, a resposta é sim. E ninguém sabe, porque pela interface isso nunca acontece.
Autenticar não é autorizar
São duas perguntas diferentes e muita gente trata como uma.
Autenticação: quem é você? Resolvida pelo login.
Autorização: o que você pode ver? É outra coisa, e é onde o problema mora.
Quando você pede um sistema com login pra IA, ela entrega autenticação. Autorização ela entrega no nível mais básico: está logado, pode acessar.
Não é erro dela. Você pediu login; ela fez login. Quem precisa dizer que cada um só vê o que é seu é você. É a mesma lógica de não delegar arquitetura: a decisão de consequência é de quem constrói.
Camada 1: define os papéis antes do código
Antes de escrever qualquer coisa, uma lista curta.
Quem são os perfis e o que cada um enxerga. Aluno vê as próprias notas. Professor vê a turma dele. Admin vê tudo.
Três linhas. Parece burocracia e é o que evita a reescrita mais cara que existe, porque mudar quem vê o quê depois encosta em todas as telas.
Camada 2: o servidor confere de quem é o dado
Esta é a camada que protege de verdade.
Em toda rota que devolve ou altera dado de alguém, a pergunta tem que ser feita no servidor: esse registro pertence a quem está pedindo?
Não é checar se está logado. É checar propriedade.
A versão errada, e comum, é confiar no que o navegador manda. Se o cliente envia qual usuário ele é, qualquer um pode enviar outro. O identificador de quem pede vem da sessão no servidor, nunca do pedido.
E vale o alerta: esconder o botão na tela não é controle. A tela é conveniência pro usuário honesto. Quem não usa a tela pega o dado direto, e é isso que está entre os três lugares por onde dado sensível vaza.
Camada 3: o banco nega por padrão
A última linha, pra quando as outras falharem.
Nas regras do banco, o padrão é negar tudo. Depois você abre exceções específicas, sempre amarradas ao usuário dono do dado.
Começar liberando e tentar restringir depois é a receita do banco aberto, porque sempre sobra uma coleção que ninguém lembrou de fechar.
Essa camada é o que protege quando alguém esquece a verificação numa rota nova. E alguém vai esquecer.
O teste de um minuto
Depois de implementar, confere assim:
Entra com uma conta. Abre uma tela que mostra algo seu, do tipo barra pedido barra 1024. Troca pra 1025.
Três resultados:
Erro de permissão: está correto. Aparece dado de outro: o controle está só na interface. Erro feio de sistema: bloqueou por acidente, não por regra. Vale consertar, porque acidente não é garantia.
Repete pra cada tipo de dado sensível. Leva minutos e é a verificação de maior retorno que existe.
O caso que quase todo mundo esquece
Relatório e exportação.
A tela do cliente está protegida, mas a rota que gera o relatório em planilha devolve tudo, porque foi escrita pensando no admin.
Vale revisar separadamente: exportação, relatório, endereço de busca e qualquer coisa que devolva lista. São as rotas que mais entregam dado de uma vez e as que menos recebem atenção.
Login diz quem entrou. Autorização diz o que cada um leva.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Autenticação não é suficiente?
Não. Autenticação responde quem é a pessoa; autorização responde o que ela pode ver. Sistema que só autentica deixa qualquer usuário logado alcançar o dado de qualquer outro.
+Onde a verificação precisa ficar?
No servidor, em toda rota que devolve ou altera dado de alguém. Verificação na tela apenas esconde botões e não impede o acesso direto.
+Como testar se o controle funciona?
Entrando com uma conta, abrindo um registro seu e trocando o identificador na URL por outro. Se aparecer dado alheio, o controle está só na interface.
+Qual o padrão correto nas regras do banco?
Negar tudo por padrão e abrir exceções específicas, sempre amarradas ao usuário dono do dado, em vez de liberar e tentar restringir depois.
Continue lendo
Como apagar o dado de um cliente que pediu (LGPD na prática)
Parece um comando de apagar. Não é. O dado está em mais lugares do que você imagina, parte dele você é obrigado a manter, e o backup é a pegadinha que quase todo mundo esquece.
SegurançaBackup que você nunca restaurou não é backup
É uma crença. Existe uma diferença enorme entre ter arquivos sendo copiados e conseguir voltar a operar, e a maioria só descobre qual tem no pior dia possível.
SegurançaQuem tem acesso ao seu banco hoje? Quase ninguém sabe responder
Faz a pergunta na sua empresa e observa a pausa. Acesso é concedido o tempo todo, por motivo legítimo, e praticamente nunca é retirado.