Como protegemos seus dados

01 · Seção

O que esta página é

A SIM guarda prontuário de saúde ocupacional: ASO, resultado de exame, CAT, restrição médica. É o tipo de dado que a LGPD classifica como sensível e que, se vazar, não tem como ser desfeito. Esta página descreve os controles que sustentam essa responsabilidade.

Duas regras na redação deste documento, para que ele sirva a uma avaliação de fornecedor: só entra controle que já está em produção, e a lista não é exaustiva. Nenhum item aqui é aspiracional. Cliente em processo formal de compliance review pode pedir o detalhamento completo, incluindo o que está em evolução, pelo canal no final da página.

02 · Seção

Criptografia

• Em trânsito. Todo tráfego passa por TLS, com certificado renovado automaticamente e Strict-Transport-Security ativo — o navegador se recusa a abrir a aplicação em conexão não cifrada.
• CPF cifrado no banco. O CPF do funcionário é gravado em coluna dedicada com AES-256-GCM, cifra autenticada que detecta alteração do dado em repouso. A migração que remove a coluna legada em texto puro está em andamento.
• Busca sem decifrar. Procurar um funcionário por CPF exigiria comparar o texto puro, o que anularia a cifra. Em vez disso, gravamos um blind index: um HMAC-SHA256 com chave secreta derivada da chave mestra. Serve para encontrar o registro pelo valor exato, e não é reversível nem vulnerável a tabela pré-computada, ao contrário de um hash sem chave.
• Senhas. Armazenadas como hash bcrypt com fator de custo 12. Não há caminho de leitura da senha original, nem para a nossa equipe.
• Chaves. Validadas no start da aplicação, com tamanho mínimo exigido. A aplicação se recusa a subir em produção com chave fraca ou ausente, em vez de seguir com fallback silencioso.

03 · Seção

Isolamento entre organizações

A SIM é multi-tenant: várias consultorias operam sobre a mesma infraestrutura. O isolamento não depende de cada desenvolvedor lembrar de filtrar a consulta — ele é imposto na camada de acesso ao banco, por uma extensão do cliente de banco de dados que injeta o filtro da organização em toda leitura e escrita dos modelos sensíveis, e preenche a organização de origem em todo registro criado.

Na prática, uma consulta escrita sem o filtro dentro de uma requisição autenticada recebe o filtro de qualquer forma. As exceções, para rotina administrativa e job de sistema, precisam declarar o escopo de forma explícita no código, e são pontos revisados em code review.

O isolamento é coberto por teste automatizado de tentativa de acesso cruzado, que roda contra banco real a cada mudança.

04 · Seção

Auditoria de acesso ao dado sensível

Num sistema de saúde ocupacional, saber quem leu importa tanto quanto saber quem alterou. Por isso a auditoria cobre leitura, e não só escrita.

• Endpoints que expõem dado pessoal de funcionário — detalhe do cadastro, ASO, exame — registram cada consulta com o usuário que leu, a organização, o titular consultado e o identificador da requisição.
• O registro de auditoria de leitura tem retenção própria, separada da dos logs operacionais: 1 ano para o registro de leitura e 5 anos para o de alterações.
• Ação administrativa sobre dado de cliente é registrada em log imutável, e a sessão assumida em nome de outro usuário, quando usada em suporte, fica registrada.

05 · Seção

Dado pessoal fora dos logs

Vazamento por log é dos mais comuns e dos mais silenciosos: o dado sai do banco cifrado e reaparece em texto puro na ferramenta de observabilidade. A remoção é aplicada em quatro caminhos distintos, porque cada um tem um jeito próprio de vazar:

• Log da aplicação — CPF, RG, telefone, e-mail, endereço, token e senha são removidos por regra no logger, antes de a linha ser escrita.
• Monitoramento de erro — cada evento passa por uma limpeza antes do envio, que alcança mensagem, breadcrumb, corpo da requisição e campos extras.
• Integração com o SOC — os envelopes SOAP, que carregam dado cadastral completo, são redigidos antes de qualquer registro.
• WhatsApp — o número de destino é mascarado no log de envio.

Em produção, a resposta de erro devolvida pela API é sanitizada: o cliente recebe código, mensagem e identificador da requisição, nunca stack trace ou detalhe interno.

06 · Seção

Proteção na camada da aplicação

• Validação na borda. Todo dado que entra por controller ou formulário é validado contra um schema declarado, compartilhado entre o back-end e o front-end — a mesma regra vale nos dois lados, sem divergência.
• Rate limit. Limite de requisições por janela de tempo, com contagem centralizada, aplicado globalmente e endurecido nos endpoints de autenticação para conter tentativa de força bruta.
• Upload verificado pelo conteúdo. O tipo do arquivo é determinado pelos magic bytes do próprio conteúdo, não pelo que o navegador declara. Executável, script e arquivo poliglota são recusados na confirmação do envio, e o objeto é removido do armazenamento.
• Cabeçalhos de segurança. X-Frame-Options: DENY contra clickjacking, Referrer-Policy restritiva, e Permissions-Policy desligando câmera, microfone e geolocalização.
• Content-Security-Policy em observação. A política está publicada em modo de relatório, que reporta violação sem bloquear. É o estágio anterior ao bloqueio, e está descrito aqui como é, e não como pretendemos que fique.
• Sourcemaps fora do bundle público. O mapa de código não é servido ao navegador, o que evita entregar a estrutura interna da aplicação a quem a inspeciona.
• Rotas de teste inacessíveis em produção. Os helpers de teste, que incluem reset de base, só são registrados quando o ambiente é de teste, e um guard independente recusa a chamada mesmo que uma rota seja exposta por engano.

07 · Seção

Remoção, anonimização e retenção

• Remoção reversível por padrão. Modelos sob obrigação legal de guarda usam remoção lógica: o registro sai da interface e a obrigação continua cumprida. A remoção física direta nesses modelos falha em tempo de execução — é preciso optar por ela explicitamente.
• Anonimização irreversível. Quando um titular é anonimizado, o dado pessoal é sobrescrito, e não anulado: não há cópia de onde recuperar, e a chave que permitiria reencontrar o registro pelo CPF é destruída. O hash de senha é invalidado, de modo que a conta não pode ser reutilizada, e a foto é removida do armazenamento. Os documentos sob guarda legal permanecem, com os rótulos que identificavam o titular sobrescritos.
• Retenção por categoria, com prazo monitorado. Cada categoria de dado tem política própria, com a base legal registrada junto, e uma rotina agendada acompanha os vencimentos e os reporta ao encarregado. Dado de saúde ocupacional segue os 20 anos da NR-7, e a eliminação nessa faixa depende de aprovação formal, em vez de ser automática — apagar antes do prazo é que seria a infração.

08 · Seção

Onde o dado fica

A aplicação e o banco de dados rodam em infraestrutura no Brasil. Para os serviços de apoio, a região é fixada deliberadamente fora dos Estados Unidos quando o fornecedor permite: monitoramento de erro e analytics na União Europeia, e o armazenamento de arquivo com seleção automática de região pelo fornecedor, com indicação de localidade configurável.

Essa escolha é verificada no start da aplicação: se a configuração apontar para uma região dos Estados Unidos em produção, um alerta é emitido no log de inicialização em vez de passar despercebido.

As transferências internacionais que restam, quais dados envolvem e sob qual mecanismo do Capítulo V da LGPD ocorrem estão descritas em Transferência internacional.

09 · Seção

Rastreamento e consentimento

O analytics de produto só é inicializado depois do consentimento, e não apenas deixa de registrar evento: a biblioteca não é carregada antes do aceite. O banner separa três categorias — essencial, preferências e analytics — e analytics começa negado. A escolha é versionada, e uma mudança relevante de política invalida o consentimento anterior em vez de herdá-lo. Não usamos cookie de publicidade de terceiros.

10 · Seção

Relatar vulnerabilidade

Encontrou uma falha? Escreva para dpo@simtechnology.com.br com a descrição e o passo a passo para reproduzir. Respondemos o recebimento e mantemos você informado da correção.

Pedimos apenas o que qualquer programa de divulgação responsável pede: não acessar dado de titular real, não degradar o serviço e nos dar prazo de correção antes de publicar. Pesquisa feita nesses termos é bem-vinda, e não vira caso jurídico.

Para tratamento de dado pessoal e exercício de direitos, os documentos são a política de privacidade e a página de LGPD e direitos do titular.