LGPD, segurança e auditoria hash-chain no SST

Classificação de dados: público, pessoal e sensível

A base de toda a proteção é a classificação do dado. O dicionário de dados define três categorias alinhadas à LGPD (Lei nº 13.709/2018), e cada documento ou evidência no módulo de Documentos e Evidências (M11) carrega o campo classificacao_dado, que determina quais regras se aplicam a cada registro.

• PÚBLICO: sem identificação de pessoa.
• PESSOAL: identifica o colaborador.
• SENSÍVEL: saúde ocupacional, dados psicossociais, denúncias e acidentes com detalhes.

Para o dado sensível a regra é explícita: exige RBAC estrito, trilha auditável reforçada e minimização de propagação. Sempre que possível, o sistema trabalha com sinais agregados em vez de expor a identidade do titular, reduzindo a superfície de exposição de dados sensíveis de SST ao mínimo necessário.

Criptografia AES-256-GCM em campos sensíveis

Os requisitos não funcionais exigem criptografia em trânsito (TLS) e em repouso. Em repouso, a plataforma cifra evidências e anexos com AES-256-GCM e IV (vetor de inicialização) aleatório por operação. A chave é carregada de um arquivo protegido no servidor — nunca embutida no código — e o material de chave jamais é gravado em log.

Campos sensíveis de subsistemas também ficam cifrados coluna a coluna, no padrão *_encrypted mais *_iv: instruções de modelo e telemetria do motor de IA (M25), além do texto bruto de OCR e das notas de revisão humana. Assim, o payload sensível não permanece em claro dentro do banco, mesmo para quem tenha acesso direto às tabelas.

ACL por grupo e tags (backend e frontend)

A autorização é feita por RBAC baseado em grupos e tags de ACL, e não por papéis fixos no código. Um usuário pertence a um grupo; o grupo recebe tags de permissão (por exemplo, users:manage, privacy:manage ou m08:read). Existem quatro grupos de sistema — superadmin, admins, technicians e users — e um catálogo com cerca de 68 tags organizadas por categoria: account, users, module, security, privacy e admin.

No backend, todo endpoint privado nasce protegido por ensure_acl, e a sessão carrega o group_id para resolver a ACL no middleware. O frontend reflete exatamente a mesma ACL em navegação, páginas e ações: o usuário não vê o que não pode executar, e a guarda fica na própria página — não apenas no filtro de menu.

Os perfis previstos incluem Administrador Master, Técnico de Segurança (SST/SESMT), Gestor de RH, Médico do Trabalho, membro da CIPA, Gestor de Área, Colaborador (portal) e Auditor Externo com acesso somente leitura. Cada perfil enxerga apenas os dados e as ações compatíveis com as suas tags.

Multi-tenancy e proteção contra IDOR

Cada organização (empresa) é um tenant. Toda entidade de negócio carrega organization_id, e as consultas passam por um guard de tenant que injeta automaticamente a cláusula organization_id igual ao contexto atual; sem contexto de organização, a operação falha. Essa é a proteção contra IDOR (Insecure Direct Object Reference): um usuário de uma organização não consegue ler nem alterar registros de outra, mesmo manipulando identificadores na requisição.

Além da ACL da pessoa, cada rota de módulo nasce atrás de uma verificação de habilitação (ensure_module_entitlement): se a organização não tem o módulo ativo, a resposta é 403 module_not_enabled. O isolamento é comprovado por testes automatizados de isolamento e pelo gate itest, que roda contra um schema descartável e é parte obrigatória do pipeline de deploy.

Trilha de auditoria imutável com hash-chain e selos diários

Mudanças relevantes — status, prazos, responsabilidades e ações sensíveis — geram trilha auditável em log imutável. A tabela de auditoria é encadeada: cada entrada guarda o prev_hash (hash da entrada anterior) e o entry_hash (hash da entrada atual), ambos calculados em SHA-256. Alterar um registro no meio quebraria a cadeia dos hashes seguintes, o que torna a trilha verificável e resistente a adulteração silenciosa.

Diariamente, um worker sela o dia anterior: grava selos assinados por HMAC-SHA256, com chave de assinatura dedicada carregada de arquivo protegido, e um digest do log de acesso. Não há hard-delete operacional, e os jobs de retenção da LGPD atuam sobre o dado operacional sem adulterar a cadeia de auditoria. Essa trilha de auditoria hash-chain serve tanto à fiscalização da NR-01 quanto à prestação de contas exigida pela LGPD.

Residência de dados no Brasil

Os dados da plataforma residem em servidor no Brasil. Para empregadores sob a LGPD — e especialmente para autarquias federais e conselhos profissionais que prestam contas ao TCU — a residência nacional dos dados, combinada com a auditoria imutável, reduz risco jurídico e facilita a fiscalização. É um diferencial ante soluções hospedadas em nuvem internacional, cuja geografia de dados nem sempre é publicada e pode implicar transferência internacional de dados pessoais.

A residência no Brasil também simplifica a resposta a auditorias e a órgãos de controle: as evidências, os documentos e a própria trilha de auditoria ficam sob jurisdição nacional, sem depender de acordos de transferência internacional para serem apresentados quando um fiscal ou um titular solicita.

Consentimento e solicitações do titular (DSR)

A plataforma registra consentimentos com finalidade, canal, indicação de concessão ou recusa, versão, data, user agent e IP, e atende às solicitações do titular previstas no art. 18 da LGPD. Cada solicitação entra com status aberta e é tratada por quem tem a tag privacy:manage, com todo o fluxo na trilha de auditoria e sem apagar histórico — retificações preservam o registro anterior.

Os tipos de solicitação do titular (DSR) suportados são:

• Acesso aos dados
• Correção de dados
• Exclusão de dados
• Anonimização
• Portabilidade
• Oposição ao tratamento
• Revogação de consentimento