Permissões que Não Mentem: RBAC e Trilho de Auditoria Imutável num ERP Industrial | Blog

# Permissões que Não Mentem: RBAC e Trilho de Auditoria Imutável num ERP Industrial

TL;DR: Num ERP industrial, o controlo de acessos RBAC só protege enquanto as concessões de excepção forem revistas com a mesma disciplina com que são criadas — e a base de dados, não a aplicação, deve ser a última linha de defesa que impede alguém de reescrever o histórico.

Quem constrói sistemas para operações upstream, EPC ou serviços petrolíferos em Angola já ouviu a frase "só precisamos disto por uma semana, até fechar o inventário". É exactamente aí que o controlo de acessos RBAC começa a falhar — não no desenho, mas na manutenção. A Wise Hustlers constrói e opera o seu próprio ERP para o sector energético. Este artigo descreve, a partir dessa experiência da Wise Hustlers a construir e operar um ERP energético completo (upstream, poços, produção, contratos, procurement, MRO, frota, HSE, finanças), como estruturar papéis, permissões e concessões de forma que aguentem anos de excepções pontuais sem se tornarem um queijo suíço — e como desenhar uma tabela de auditoria que a própria base de dados se recusa a alterar.

Papéis, permissões e concessões: três coisas que se confundem facilmente

O standard de referência para RBAC — o INCITS 359, formalizado a partir do trabalho original de David Ferraiolo e Rick Kuhn no NIST em 1992 — define um papel (role) como "uma função dentro da organização, com semântica associada sobre a autoridade e responsabilidade conferidas ao utilizador atribuído a esse papel" (ANSI Blog). Na prática de um ERP industrial, vale a pena manter três camadas separadas e nunca as fundir:

Permissão — a unidade atómica: pode aprovar requisição de compra até 50.000 USD, pode fechar período contabilístico, pode editar dados-mestre de poço. Uma permissão não sabe quem a tem; só descreve uma acção sobre um recurso.
Papel — um conjunto nomeado de permissões que corresponde a uma função real na organização: Engenheiro de Produção, Controller Financeiro, Coordenador HSE de Campo. O papel é a unidade que se atribui a pessoas, não a permissão individual — isto é o que torna o RBAC gerível: alterar o que um Controller Financeiro pode fazer altera-o para todos os que têm esse papel, sem tocar em cada conta.
Concessão (grant) — a ligação concreta entre um utilizador (ou grupo) e um papel, normalmente com um âmbito: esta unidade de negócio, este projecto, este período. É aqui que entra a dimensão temporal — e é aqui que a maior parte dos sistemas falha, porque tratam a concessão como permanente por omissão.

A confusão mais comum que vemos em sistemas legados é permissões atribuídas directamente a utilizadores individuais, sem papel intermédio. Funciona nos primeiros seis meses. Ao fim de dois anos, ninguém sabe porque é que o utilizador jsilva tem acesso de escrita ao módulo de tesouraria, porque essa concessão nunca passou por uma revisão de papel — foi um pedido pontual que ficou.

O modo de falha central: a excepção que ninguém revoga

Isto é o ponto mais importante deste artigo, e é sistematicamente subestimado: o RBAC não falha por ausência de regras — falha porque uma regra deixa de reflectir a realidade e ninguém repara.

O padrão é sempre o mesmo. Alguém precisa de um acesso alargado por uma razão legítima e temporária: cobrir uma ausência, resolver um incidente, fechar um período fiscal atrasado. Cria-se uma concessão de excepção — um utilizador com um papel mais amplo do que o normal, ou uma regra que ignora uma validação habitual ("saltar aprovação de gestor para requisições abaixo de X, só esta campanha"). A excepção resolve o problema imediato. E depois fica.

Ninguém a revoga porque revogar exige que alguém se lembre — e o sistema, tal como está desenhado, não obriga ninguém a lembrar-se. A excepção não aparece como um alarme activo; aparece como uma linha silenciosa numa tabela de permissões que ninguém volta a abrir. Passados dois anos, um auditor (interno, da ANPG, de um parceiro internacional numa operação conjunta) pergunta porque é que uma conta de serviço tem acesso de aprovação financeira sem limite de valor. A resposta, invariavelmente, é "isso foi criado para um projecto que já terminou".

O ponto central é este: uma lista de excepções desactualizada não é neutra — é uma vulnerabilidade activa que se parece com controlo. O guarda continua ali, mas deixou de olhar. A concessão continua na tabela, o relatório de acessos continua a "passar", a caixa de verificação de compliance continua marcada — e, no entanto, a protecção real já não existe, porque a excepção desarmou-a silenciosamente. Isto é consistente com o que a OWASP documenta como a categoria mais prevalente de falha de segurança em aplicações: o Broken Access Control (A01:2021) foi encontrado em 94% das aplicações testadas, com mais ocorrências reportadas do que qualquer outra categoria do Top 10 (OWASP) — não porque falte controlo de acessos nos sistemas, mas porque o controlo que existe se degrada sem ninguém notar.

A mitigação prática que aplicamos num ERP industrial tem três componentes, nenhum opcional:

1. Toda a concessão de excepção tem data de expiração obrigatória no esquema da base de dados — não é um campo opcional que alguém preenche se se lembrar; é uma coluna NOT NULL com um valor por omissão curto (7 a 30 dias, consoante o tipo de excepção).

2. Expiração é automática, não pedida. Um trabalho agendado revoga a concessão à meia-noite da data de expiração, sem intervenção humana. Se ainda for necessária, alguém tem de a renovar activamente — o ónus está em manter o acesso, não em o remover.

3. Toda a concessão activa há mais de 90 dias aparece num relatório de revisão periódica, visível ao responsável do papel e à equipa de segurança — não escondida numa tabela que só é aberta durante uma auditoria externa.

Isto é, no fundo, controlo de acessos aplicado com a mesma disciplina de gestão de identidade e vulnerabilidades que descrevemos com mais detalhe na página de cibersegurança da Wise Hustlers — o RBAC bem desenhado é uma componente de segurança do sistema, não um formulário de administração.

Trilho de auditoria imutável: quando a aplicação não é suficiente

Um sistema RBAC bem desenhado responde à pergunta "quem pode fazer isto". Um trilho de auditoria responde à pergunta, muito mais incómoda, "quem fez isto, quando, e o que era antes". Nos módulos onde isto mais pesa — aprovação de despesas de capital, alocação de produção, ordens de trabalho de manutenção — a auditoria não é um requisito de conformidade acessório; é o único mecanismo que permite reconstruir uma decisão financeira ou operacional meses depois.

O erro mais comum é confiar apenas na camada de aplicação para garantir que os registos de auditoria não são alterados: um serviço que escreve para uma tabela audit_log e assume que, como só esse serviço escreve lá, os registos estão protegidos. Isto falha sempre que alguém com acesso directo à base de dados — um administrador, uma migração mal escrita, um script de correcção de dados executado às pressas — corrige "só este registo" directamente em produção. A partir desse momento, o trilho de auditoria já não é uma prova; é uma opinião.

A alternativa correcta é fazer a própria base de dados recusar a alteração, independentemente de quem a pede:

-- Revoga UPDATE e DELETE do papel aplicacional na tabela de auditoria
REVOKE UPDATE, DELETE ON audit_log FROM app_role;
GRANT INSERT, SELECT ON audit_log TO app_role;

-- Reforça com um gatilho, para cobrir contas com privilégios mais amplos
CREATE OR REPLACE FUNCTION audit_log_no_mutation()
RETURNS TRIGGER AS $$
BEGIN
  RAISE EXCEPTION 'audit_log é append-only: UPDATE/DELETE não permitido';
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_log_block_update
  BEFORE UPDATE OR DELETE ON audit_log
  FOR EACH ROW EXECUTE FUNCTION audit_log_no_mutation();

Este padrão — privilégios ao nível da base de dados combinados com um gatilho que rejeita explicitamente UPDATE/DELETE — é a prática estabelecida para tabelas de auditoria em PostgreSQL: "a regra mais simples é: nunca actualizar nem apagar linhas de auditoria, só inserir" (wiki PostgreSQL, Audit trigger). É importante ser honesto sobre o que isto garante e o que não garante: bloquear edições por privilégio não é o mesmo que tornar as edições detectáveis de forma criptográfica — qualquer conta com privilégios de superutilizador, ou acesso directo ao disco, ainda pode alterar histórico (AppMaster). Por isso, em contextos que exigem prova reforçada (litígio, arbitragem entre parceiros de um bloco, inspecção da ANPG a um processo de conteúdo local), o passo seguinte é encadeamento de hash — cada registo inclui o hash do registo anterior, tornando qualquer alteração posterior matematicamente detectável, mesmo por quem tem acesso de superutilizador.

Para operadores angolanos, este desenho tem uma segunda função: o quadro legal de protecção de dados pessoais (Lei n.º 22/11, sob supervisão da Agência de Protecção de Dados) exige práticas de segurança e responsabilização sobre o tratamento de dados pessoais, e um trilho de auditoria que a própria base de dados protege é a forma mais directa de conseguir demonstrar, e não apenas alegar, que os acessos e as alterações a dados sensíveis foram registados com integridade.

Uma checklist prática

Elemento	Pergunta que deve responder	Onde falha normalmente
Papel	Que conjunto de permissões corresponde a esta função?	Papéis genéricos demais ("Admin") que acumulam tudo
Permissão	Que acção concreta sobre que recurso?	Permissões vagas que cobrem módulos inteiros
Concessão	Quem tem este papel, com que âmbito e até quando?	Sem data de expiração; nunca revista
Excepção	Esta concessão alargada ainda é necessária?	Criada para um incidente, nunca revogada
Auditoria	Quem alterou isto, e o registo pode ser alterado?	Confiar só na aplicação; sem `REVOKE` ao nível da base de dados

Perguntas frequentes

RBAC é suficiente, ou preciso de ABAC (controlo baseado em atributos)?

Para a maior parte dos módulos de um ERP industrial, RBAC com âmbito (por unidade de negócio, projecto ou centro de custo) resolve bem. ABAC — decisões baseadas em atributos dinâmicos como localização, hora ou classificação do activo — vale a pena quando as regras de negócio dependem de contexto que muda com frequência, por exemplo em HSE de campo. Muitos sistemas maduros combinam os dois: papéis para a estrutura, atributos para excepções contextuais.

Uma tabela de auditoria append-only não faz a base de dados crescer indefinidamente?

Sim, e é intencional — não se deve apagar histórico de auditoria por espaço em disco. A resposta correcta é particionamento por data e arquivo frio (para armazenamento mais barato) das partições antigas, nunca eliminação de registos activos.

Quem deve poder criar uma concessão de excepção?

O mesmo papel que a pode revogar, nunca um papel diferente — caso contrário cria-se uma assimetria onde é fácil conceder e difícil revogar, que é exactamente o padrão que gera excepções esquecidas.

Isto aplica-se a sistemas mais pequenos, ou só a ERPs de grande escala?

O princípio aplica-se a qualquer sistema com dados financeiros ou operacionais sensíveis. A escala muda a complexidade dos papéis, não a necessidade de expiração automática de excepções nem de auditoria protegida ao nível da base de dados.