Multiempresa, segurança e LGPD no SGQ: isolamento de dados por organização

Plataforma multiempresa (um usuário, várias empresas)

O SGQ é uma única aplicação multitenant: todas as organizações compartilham a mesma instalação, mas cada uma acessa somente as próprias informações. O mesmo usuário, identificado pelo e-mail, pode participar de mais de uma organização por meio de vínculos de participação; a organização ativa na sessão define o conjunto de dados, módulos e bibliotecas de requisitos disponíveis. É o modelo que atende grupos econômicos e empresas com mais de um CNPJ sem misturar informação entre elas.

Isolamento de dados por organização provado por teste, não presumido

Cada tabela operacional carrega a coluna organization_id, e toda consulta é filtrada pelo contexto do tenant. Esse contexto de tenant viaja com a requisição: um filtro obrigatório injeta a condição por organization_id nas queries e um guardião de tenant recusa qualquer consulta a tabela multiempresa que não esteja escopada — falha fechada, em vez de vazar. A cadeia global de auditoria fica de fora desse guardião de propósito, por ser append-only e não pertencer a um único tenant.

O isolamento não fica na promessa. Um teste de integração real cria duas organizações (A e B) sobre o mesmo requisito da ISO 9001 e prova que a organização B não lê o status nem as evidências da organização A, e que as contagens não vazam entre tenants. Esse teste roda como gate obrigatório no CI, contra um schema descartável, além de poder ser executado localmente. Isolamento é verificado, não presumido.

ACL por grupo e tags: controle de acesso por perfil (frontend e backend alinhados)

Dentro de cada organização, o acesso é controlado por perfil. Cada usuário pertence a um grupo e cada grupo recebe um conjunto de permissões (tags). Existem quatro grupos de sistema (superadmin, admins, technicians e users) e um catálogo de cerca de 68 tags — por exemplo biblioteca:read ou users:manage — organizadas em seis categorias: conta, usuários, módulo, segurança, privacidade e administração.

Todo endpoint privado nasce protegido por uma verificação de ACL e só libera quando o grupo tem ao menos uma das tags exigidas; a tag curinga (asterisco) e o papel root são exceções de bootstrap, nunca base de regra nova. O frontend reflete exatamente a mesma regra — menu, páginas, botões e ações — com guarda na própria página, e não apenas um filtro de menu. Não se depende de um 403 como experiência primária.

Entitlements: módulos e bibliotecas por plano, sem hard-delete

A autorização tem duas camadas complementares e independentes. O entitlement decide se um módulo ou biblioteca existe para a organização (o gating comercial do plano); a ACL decide o que cada pessoa pode fazer dentro dela. O catálogo reúne os módulos M01 a M28 e oito bibliotecas de requisitos (ISO 9001, ISO 14001, ISO 45001, ISO 13485, RDC 665/2022, RDC 430/2020, PALC e ONA). Os planos são pacotes nomeados que se materializam em linhas por organização, auditáveis e ajustáveis.

• Essential reúne os módulos base (sem biblioteca); Professional inclui uma biblioteca (ISO 9001 como padrão); Compliance traz o pacote ISO (9001, 14001 e 45001); Healthcare inclui PALC e ONA; Medical Devices reúne ISO 13485, RDC 665/2022 e RDC 430/2020; Enterprise habilita todas as bibliotecas do catálogo e os módulos da plataforma de qualidade.
• Falha fechada: sem entitlement ativo, o backend responde 403 (module_not_enabled) e o módulo some da interface (menu e mapa de módulos), sem bypass de root.
• Sem hard-delete: revogar é marcar o item como inativo, preservando o histórico do que já foi concedido; cada plano aplicado fica registrado no histórico de planos da organização.
• Aplicar um plano no modo substituição deixa a organização exatamente com aquele conjunto de módulos e bibliotecas.

O detalhamento de cada plano e das bibliotecas incluídas está nas páginas de Planos e de Bibliotecas de requisitos.

Trilha de auditoria imutável das operações

As ações sensíveis são auditadas e o histórico é encadeado e selado de forma verificável. Cada registro de auditoria referencia o hash do registro anterior (prev_hash e entry_hash), formando uma cadeia de hash (hash-chain) em que reescrever um evento antigo quebra todos os seguintes. Uma vez por período, um selo diário guarda o intervalo, a contagem de eventos, o hash-raiz (SHA-256) e uma assinatura; em paralelo, digests diários do log de acesso tornam qualquer adulteração evidente (tamper-evident).

Somado à regra de não fazer hard-delete de entidades operacionais — usa-se status e marcação de inativação, e retificações preservam as tentativas anteriores —, isso mantém a cadeia de evidências íntegra, útil quando a auditoria de certificação ou de acreditação chega.

LGPD: consentimentos, solicitações do titular (DSR) e classificação de dados

A base já traz os instrumentos da LGPD (Lei nº 13.709/2018). Os consentimentos são registrados com finalidade, canal, versão do texto aceito e prova (data e hora, IP e user agent). As solicitações do titular (DSR — direitos previstos no art. 18 da LGPD, como acesso, correção e eliminação) guardam tipo, status, canal de recebimento e data de resolução, para dar tratamento rastreável a cada pedido. Esses registros também são isolados por organização e ficam sob a tag de privacidade da ACL.

Todo dado é classificado como Público, Pessoal ou Sensível. Dados sensíveis (saúde ocupacional, psicossocial, denúncias) exigem controle de acesso estrito, trilha reforçada e minimização de propagação, com preferência por agregados; documentos carregam a classificação e os prazos de guarda e descarte para o ciclo de retenção. A plataforma apoia a conformidade e não substitui a avaliação jurídica nem a consultoria da sua organização.

Autenticação: senha, TOTP, passkeys e Google OAuth

O login aceita senha (com troca obrigatória no primeiro acesso quando aplicável), segundo fator TOTP em aplicativo autenticador (o emissor exibido é SGQ Conformidade), passkeys no padrão WebAuthn (chaves por dispositivo, sem senha) e Google OAuth. A conta é considerada com segundo fator forte quando há um TOTP ou uma passkey configurada. A sessão é persistida e carrega o grupo do usuário, o que permite resolver a ACL de forma rápida a cada requisição.

Cripto em descanso (AES-256-GCM) e backups criptografados

Campos sensíveis são cifrados em descanso com AES-256-GCM, em colunas dedicadas com sufixos _encrypted e _iv — o que cobre, por exemplo, as instruções e a telemetria detalhada do motor de IA e o conteúdo bruto de OCR antes da revisão humana. Os backups são criptografados antes de ir para o armazenamento externo (S3 ou MinIO), com agendamento, retenção (por padrão, os 30 backups mais recentes) e verificação de integridade por checksum registrados; as próprias credenciais do storage ficam cifradas na base, nunca em texto puro.