Menor privilégio na prática: papéis por tarefa, não admin para todo mundo

A loja tem 14 contas no painel. Doze são administradoras, porque "era mais rápido do que configurar". Uma delas é da Bruna, que fazia os textos das páginas e saiu há cinco meses. A senha dela vazou num site de terceiros, alguém entrou no painel, exportou a base de clientes e estornou três pedidos. A Bruna nunca precisou exportar cliente nem estornar pedido. A conta dela podia.

A resposta curta: cada pessoa recebe o menor papel que cobre o trabalho dela. Papéis são desenhados por tipo de tarefa (conteúdo, atendimento, financeiro), a permissão é conferida no servidor em cada ação, a lista de administradores é revisada todo mês e a conta é desligada no dia em que a pessoa sai. Login compartilhado "da equipe" não existe.

Por que admin para todos parece barato e sai caro

Dar acesso total elimina pedidos de permissão, telas de configuração e a reclamação de "não consigo fazer tal coisa". O custo aparece depois, e de uma vez. Toda conta passa a ter o poder máximo, então qualquer senha fraca, qualquer sessão esquecida aberta num computador compartilhado e qualquer clique errado têm o maior estrago possível.

O menor privilégio não impede o incidente. Ele limita o tamanho dele. Se a conta da Bruna tivesse só o papel de conteúdo, o invasor poderia, no máximo, mexer em textos de páginas. Ruim, mas restaurável em minutos, e sem dado pessoal de cliente exposto, o que pesa também para a adequação à LGPD.

Como desenhar os papéis, passo a passo

1. Liste as ações do sistema como verbos sobre recursos: ver pedido, estornar pedido, editar página, exportar clientes, gerenciar usuários.
2. Liste os tipos de trabalho reais da equipe: quem escreve conteúdo, quem atende, quem cuida do financeiro, quem administra o sistema.
3. Cruze os dois. Cada papel recebe só as ações que aquele trabalho usa toda semana. O que é raro vira pedido pontual.
4. Separe as ações destrutivas. Apagar, estornar, exportar em massa e mexer em permissões ficam em papéis específicos, nunca no papel de quem só escreve ou só lê.
5. Confira no servidor. Esconder o botão na tela é conforto; a regra vale na rota da API.
6. Defina a revisão. Troca de função revisa o papel; saída desliga a conta no mesmo dia; uma vez por mês, alguém olha a lista de administradores.

Os papéis da loja do exemplo

• conteudo: ver e editar páginas e banners.
• atendimento: ver pedidos e clientes, comentar em pedidos.
• financeiro: ver pedidos, estornar, ver relatórios financeiros.
• admin: tudo, inclusive gerenciar usuários. Duas pessoas.

Das 14 contas, a revisão chegou a: 2 admin, 2 financeiro, 4 atendimento, 3 conteúdo, e 3 desligadas (pessoas que já tinham saído). Ninguém perdeu acesso a algo que usava.

Conferindo a permissão no servidor

Um mapa de papéis para permissões e um middleware resolvem a maioria dos sistemas pequenos. Exemplo com Express:

const PERMISSOES = {
  conteudo: ['pagina:ver', 'pagina:editar'],
  atendimento: ['pedido:ver', 'pedido:comentar', 'cliente:ver'],
  financeiro: ['pedido:ver', 'pedido:estornar', 'relatorio:financeiro'],
  admin: ['*'],
};

function pode(usuario, permissao) {
  const lista = PERMISSOES[usuario.papel] || [];
  return lista.includes('*') || lista.includes(permissao);
}

function exigir(permissao) {
  return (req, res, next) => {
    if (!req.usuario) return res.status(401).json({ erro: 'não autenticado' });
    if (!pode(req.usuario, permissao)) return res.status(403).json({ erro: 'sem permissão' });
    next();
  };
}

app.post('/pedidos/:id/estorno', exigir('pedido:estornar'), async (req, res, next) => {
  try {
    const pedido = await pedidos.buscar(req.params.id, req.usuario.lojaId);
    if (!pedido) return res.status(404).json({ erro: 'pedido não encontrado' });
    await pagamentos.estornar(pedido, { autorId: req.usuario.id });
    res.status(204).end();
  } catch (err) {
    next(err);
  }
});

Três detalhes. Um papel desconhecido cai numa lista vazia, ou seja, nega por padrão. O papel permite estornar, mas a busca ainda filtra pela loja do usuário: permissão por tipo de ação não substitui a conferência de que aquele registro pertence a quem pede. E o estorno registra quem fez, porque permissão sem trilha de auditoria não responde à pergunta "quem estornou isso?". Responder 401 para quem não está logado e 403 para quem não tem permissão segue a semântica explicada em códigos de status HTTP.

Um tema de painel administrativo bonito não traz nada disso pronto; a regra de quem pode o quê é sua, como discute template de admin não é o produto.

A revisão que mantém o mínimo mínimo

Papéis bem desenhados apodrecem sem revisão. Pessoas mudam de função e acumulam o papel antigo com o novo; alguém recebe admin "só por hoje" e fica com ele por um ano. Uma consulta simples, rodada todo mês, mostra o que mudou:

SELECT u.email, m.papel, u.ultimo_login_em
FROM membros m
JOIN usuarios u ON u.id = m.usuario_id
WHERE m.papel IN ('admin', 'financeiro')
ORDER BY u.ultimo_login_em;

Quem aparece no topo, com último login muito antigo, provavelmente não precisa mais do papel. Pergunte à pessoa e ao gestor. Se ninguém defender o acesso em uma semana, rebaixe. Anote a revisão com data: na próxima auditoria ou incidente, você mostra que o controle existe.

Para a saída de alguém, crie um roteiro curto e siga-o no mesmo dia: desativar a conta no sistema, encerrar as sessões abertas, revogar tokens de API pessoais e trocar qualquer segredo compartilhado a que a pessoa tinha acesso. Se o acesso ao banco passa por uma ferramenta exposta na internet, o problema é maior, como mostra phpMyAdmin aberto é o banco aberto.

Erros comuns

• Login compartilhado da equipe. Ninguém sabe quem fez cada ação, e a senha não pode ser trocada sem parar todo mundo.
• Só esconder o botão. Quem chama a API direto, com a própria sessão, executa a ação que a tela escondia.
• Papel novo somando ao antigo. Quem passou por três áreas acumula três conjuntos de permissões e vira admin informal.
• Conta ativa depois da saída. Uma senha reaproveitada e vazada abre o painel meses depois, com todas as permissões de antes.
• Negar por exceção em vez de permitir por regra. Uma rota nova esquecida fica aberta para todos os papéis.
• Admin "temporário" sem data. O temporário vira permanente, e a lista de administradores só cresce.

Checklist

• Cada papel corresponde a um tipo de trabalho real da equipe.
• Ações destrutivas e exportação em massa ficam fora dos papéis de leitura e conteúdo.
• Toda rota sensível confere a permissão no servidor e nega por padrão.
• Ações sensíveis registram quem fez e quando.
• Não existe login compartilhado.
• A lista de administradores é revisada todo mês, com data anotada.
• A saída de alguém desliga conta, sessões e tokens no mesmo dia.

Conte agora quantas contas de administrador existem no seu sistema: quantas delas foram usadas para algo que só um administrador pode fazer nos últimos 30 dias?