Perfis de acesso e trilha de auditoria bem feitos

O sistema nasceu com três perfis: administrador, gerente e operador. Dois anos depois, a empresa abriu filiais, criou uma área de compras, terceirizou parte do financeiro e passou a atender clientes que acessam um portal. Os três perfis continuam lá, e metade da empresa virou administrador, porque era o único jeito de conseguir fazer o trabalho.

Permissão mal modelada não aparece no dia do lançamento. Aparece quando a empresa cresce, quando alguém pergunta quem aprovou aquele pagamento ou quando um auditor pede a lista de quem tinha acesso ao cadastro de fornecedores no semestre passado. Este texto mostra como projetar controle de acesso que acompanha a estrutura da empresa e uma trilha de auditoria que responde perguntas de verdade.

O perfil administrador que todo mundo acaba tendo

O modelo de perfis fixos funciona enquanto a empresa é pequena e todo mundo faz um pouco de tudo. Ele quebra por um motivo previsível: cada perfil mistura duas perguntas diferentes. Uma é "o que essa pessoa pode fazer?" (aprovar pedido, editar cadastro, ver custo). A outra é "sobre quais dados?" (a filial dela, a carteira dela, os clientes da região dela).

Quando o sistema só responde a primeira, cada exceção vira um perfil novo: "gerente da filial Sul que também aprova compras", "operador que vê custo, mas só do centro de distribuição". Em pouco tempo existem dezenas de perfis com nomes que ninguém entende, ou, o caminho mais comum, a exceção é resolvida dando acesso de administrador.

Os sintomas de que o modelo chegou ao limite:

• Muitos usuários com perfil administrador ou equivalente.
• Pedidos de acesso resolvidos por "copia o perfil do fulano".
• Ninguém sabe dizer o que um perfil permite sem abrir o código.
• Pessoas que mudaram de área mantêm os acessos antigos.
• Relatórios filtrados por unidade na tela, mas com exportação que traz a empresa inteira.

Papéis, permissões e escopo por unidade ou cliente

O modelo que resolve a maior parte dos casos separa três conceitos:

Permissão é uma ação atômica sobre um tipo de recurso: pedido.aprovar, fornecedor.editar, produto.ver_custo. É definida pelo sistema e muda pouco.

Papel é um conjunto de permissões com nome de negócio: comprador, aprovador financeiro, analista de estoque. É configurado pela empresa, não pelo desenvolvedor.

Escopo é o recorte de dados sobre o qual o papel vale: uma filial, um conjunto de centros de custo, uma carteira de clientes, uma empresa do grupo.

A atribuição fica: Maria é compradora na filial Sul e aprovadora financeira no centro de custo Obras. Um usuário pode ter vários papéis em escopos diferentes, e o sistema combina tudo a cada requisição.

Os cuidados de implementação que fazem diferença:

• Negar por padrão. Sem permissão explícita, a resposta é não. Tela nova sem regra configurada não fica aberta para todos.
• Verificar no servidor, sempre. Esconder o botão é conveniência; a barreira está na API. Esse é o erro mais comum em produção, detalhado em segurança de APIs.
• Escopo aplicado na consulta, não depois. O filtro de filial entra na consulta ao banco, inclusive em relatórios, exportações e buscas. Se o escopo é aplicado só na tela, a exportação vaza.
• Uma política central, consultada por todas as rotas, em vez de if espalhados pelo código.
• Hierarquia de escopos. Quem tem acesso à regional enxerga as filiais abaixo dela, sem precisar receber cada uma.

Quando o sistema atende clientes externos, como num portal B2B, o escopo principal é o cliente: cada empresa enxerga só os próprios dados, e dentro dela pode haver papéis próprios (quem compra, quem só consulta boletos).

Quando o modelo por atributos faz sentido

Papéis com escopo resolvem a maioria dos sistemas. Algumas regras, porém, não cabem neles porque dependem de características do próprio dado ou do contexto:

• O analista pode editar o pedido enquanto ele estiver em rascunho.
• O aprovador pode aprovar compras até o limite da alçada dele.
• Prontuários marcados como confidenciais só são vistos pelo profissional responsável pelo atendimento.
• O acesso ao módulo financeiro é permitido apenas a partir da rede da empresa ou com segundo fator.

Esse é o controle de acesso baseado em atributos: a decisão considera atributos do usuário, do recurso, da ação e do contexto. É poderoso, mas tem custo de compreensão: fica mais difícil responder "o que essa pessoa pode fazer?" só olhando a configuração.

O caminho equilibrado é papéis e escopos como base, com regras por atributo onde o negócio exige, escritas numa camada de política única e testadas. Alçadas de aprovação são o exemplo clássico: em vez de criar um papel para cada faixa de limite, o limite é um atributo da atribuição do usuário, e a regra compara com o valor do documento.

Segregação de funções em processos financeiros

Segregação de funções é o princípio de que uma mesma pessoa não deve controlar todas as etapas de uma operação sensível. É controle interno básico, cobrado por auditorias e por clientes corporativos, e o sistema é o lugar certo para garantir.

Exemplos típicos em processos de compra e pagamento:

• Quem cadastra ou altera os dados bancários de um fornecedor não aprova pagamentos para ele.
• Quem cria a requisição de compra não aprova a própria requisição.
• Quem registra o recebimento da mercadoria não é quem lança a nota para pagamento.
• Quem concede acesso a outros usuários não usa esses acessos para operar.

Há duas formas de implementar, e as boas soluções usam as duas:

Prevenção. O sistema impede a combinação: o botão de aprovar não funciona para o autor do documento, e a atribuição de papéis conflitantes à mesma pessoa gera bloqueio ou exige justificativa.

Detecção. Em empresas pequenas, a segregação total pode ser inviável. Nesses casos, o sistema permite com registro e gera relatório periódico das exceções para revisão por outra pessoa.

A alteração de dados bancários de fornecedor merece destaque: é um dos pontos mais explorados em fraudes de pagamento. Exija aprovação de uma segunda pessoa, registre o antes e o depois e alerte quando houver pagamento logo após uma alteração. O fluxo completo de requisição, cotação e aprovação por alçada está em sistema de cotação e compras.

Trilha de auditoria: o que registrar e como proteger

Trilha de auditoria feita só para cumprir tabela costuma ser uma tabela de log com a mensagem "registro alterado". Ela não responde nenhuma pergunta útil. Uma trilha que serve para investigação registra, para cada evento relevante:

• Quem: o usuário, e também quem ele estava representando quando houver delegação ou acesso de suporte.
• O quê: a ação e o recurso, com o identificador do registro.
• Antes e depois: os valores alterados, campo a campo.
• Quando: data e hora do servidor, com fuso horário.
• De onde: endereço de origem, aplicativo ou integração, e o identificador da requisição para cruzar com os logs técnicos.
• Por quê: justificativa, quando a ação exige uma (ajuste de estoque, estorno, liberação de bloqueio).

Os eventos que não podem faltar: login, falhas de login e troca de senha; concessão e remoção de acessos; aprovações e reprovações; alterações em dados cadastrais sensíveis; exportações em massa; e, para dados pessoais sensíveis, também as leituras. Saber quem consultou um prontuário ou a folha de pagamento é tão importante quanto saber quem alterou. É um dos pontos em que controle de acesso e LGPD no desenvolvimento de sistemas se encontram.

Protegendo a trilha

Uma trilha que o administrador do sistema pode apagar não serve como evidência. Cuidados:

• Somente inclusão. A aplicação grava, mas não tem permissão para alterar ou excluir registros de auditoria.
• Armazenamento separado, com acesso restrito e diferente do acesso ao banco principal.
• Encadeamento ou verificação de integridade, para que a remoção de um registro no meio da sequência seja detectável.
• Retenção definida com o jurídico, coerente com obrigações legais e com a política de privacidade, já que a própria trilha contém dados pessoais.
• Consulta útil: uma tela em que o gestor filtra por usuário, registro ou período, sem precisar pedir para a equipe técnica.

Revisão periódica de acessos e desligamentos

A maior parte dos acessos indevidos não vem de invasão, vem de acesso que deveria ter sido removido. A pessoa mudou de área, o estagiário terminou o contrato, o fornecedor encerrou o projeto, e as contas continuam ativas.

O sistema pode tornar isso gerenciável:

• Desligamento integrado ao RH. Quando o colaborador é desligado no sistema de pessoal, os acessos são revogados e as sessões derrubadas automaticamente. Se a empresa tem um portal interno, ele é o ponto natural dessa integração, como descrito em portal do colaborador e intranet.
• Acessos com validade. Terceiros, temporários e acessos concedidos por exceção nascem com data de expiração.
• Revisão periódica pelo gestor. O sistema gera, em ciclos definidos pela empresa, a lista de pessoas e papéis de cada área, e o gestor confirma ou remove. A revisão fica registrada.
• Alerta de contas inativas sem login há muito tempo, para bloqueio.
• Contas nominais. Usuário genérico compartilhado ("financeiro", "caixa01") torna a trilha de auditoria inútil.

Login único e autenticação em dois fatores

Quanto mais senhas a pessoa precisa lembrar, mais elas se repetem e mais ficam anotadas. Se a empresa já usa um provedor de identidade corporativo, como Microsoft Entra ID ou Google Workspace, o sistema deve autenticar por ele via login único, usando padrões como OpenID Connect ou SAML. Ganhos diretos: uma senha só, política de senha centralizada e, principalmente, desligamento em um lugar só.

O segundo fator de autenticação deve ser obrigatório pelo menos para administradores, aprovadores financeiros e quem acessa dados sensíveis. Aplicativos autenticadores e chaves de segurança são preferíveis a códigos por SMS.

Uma divisão de responsabilidade saudável: o provedor de identidade diz quem a pessoa é; o sistema decide o que ela pode fazer. Grupos do diretório podem alimentar papéis, mas escopos e regras de negócio ficam no sistema, onde fazem sentido.

Riscos e erros comuns

• Permissão verificada só na tela, deixando a API aberta.
• Escopo esquecido em relatórios e exportações.
• Papéis criados por pessoa, e não por função, recriando a explosão de perfis.
• Acesso de suporte sem registro, em que a equipe técnica entra como o usuário e a trilha atribui a ele as ações.
• Trilha de auditoria editável ou misturada com logs técnicos que são apagados por rotação.

Como medir se o modelo funciona

• Quantidade de usuários com privilégio administrativo, que deve ser pequena e justificada.
• Tempo entre o desligamento no RH e a revogação efetiva dos acessos.
• Proporção de revisões periódicas concluídas no ciclo.
• Tempo para responder a uma pergunta de auditoria do tipo "quem alterou este registro e o que mudou".
• Exceções de segregação de funções registradas e revisadas.

Permissões desenhadas para a sua estrutura

Na Pervian Tech, controle de acesso e trilha de auditoria são tratados como parte do modelo de negócio, não como tela de configuração no fim do projeto. É assim que trabalhamos em desenvolvimento web: papéis e escopos que acompanham filiais, carteiras e clientes, segregação de funções nos processos financeiros e trilha que resiste a auditoria.

Cada estrutura de empresa é diferente, então o sistema é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se metade da sua empresa já virou administrador, conte como funciona a sua operação.