Segurança de Dados Clínicos: Criptografia, RBAC e Audit Trail

# Segurança de Dados Clínicos: Criptografia, RBAC e Audit Trail

Dados de saúde são o alvo mais valioso para cibercriminosos. Segundo relatórios do setor de segurança, registros médicos no mercado negro valem significativamente mais que dados financeiros — porque contêm informações permanentes (diagnósticos, genética) que não podem ser simplesmente "canceladas" como um cartão de crédito.

Para instituições de saúde, proteger esses dados não é apenas obrigação ética e legal (LGPD) — é questão de sobrevivência operacional. Um ataque de ransomware que compromete o acesso ao prontuário paralisa o atendimento.

Criptografia: protegendo dados em repouso e trânsito

Dados em trânsito

Toda comunicação entre cliente (navegador, aplicativo) e servidor deve ser criptografada. O padrão mínimo é TLS 1.2, com recomendação de TLS 1.3 para novas implementações.

Na prática: A criptografia de dados clínicos em trânsito e em repouso é requisito mínimo de segurança — sem ela, qualquer interceptação pode expor informações sensíveis de saúde dos pacientes.

Isso protege contra:

• Interceptação em redes Wi-Fi
• Man-in-the-middle attacks
• Sniffing de tráfego em redes compartilhadas

Verificações importantes:

• Certificados SSL/TLS válidos e renovados
• HSTS (HTTP Strict Transport Security) habilitado
• Cipher suites atualizadas (desabilitar protocolos obsoletos como TLS 1.0/1.1)

Dados em repouso

Dados armazenados em banco de dados, filesystems e backups devem ser criptografados mesmo quando não estão sendo transmitidos.

Padrão recomendado: AES-256 para criptografia simétrica de dados em repouso.

Implementações comuns:

• Transparent Data Encryption (TDE) em bancos de dados
• Criptografia de disco (BitLocker, LUKS)
• Criptografia a nível de aplicação (campos específicos como diagnósticos, resultados)

Gerenciamento de chaves

A criptografia é tão forte quanto o gerenciamento de suas chaves. Boas práticas:

• Chaves separadas do dado criptografado (nunca na mesma máquina)
• Rotação periódica de chaves
• Hardware Security Modules (HSM) para chaves críticas
• Acesso às chaves restrito e auditado

RBAC: Controle de Acesso Baseado em Funções

Princípio do menor privilégio

Cada usuário deve ter acesso apenas aos dados necessários para sua função. Implementar RBAC significa definir papéis (roles) e vincular permissões a esses papéis:

Exemplos de papéis em saúde:

Quebra de vidro (break-the-glass)

Em emergências, um profissional pode precisar acessar dados fora de seu escopo normal (ex.: médico plantonista acessando prontuário de paciente de outro serviço). O mecanismo de "break-the-glass" permite esse acesso, mas:

• Exige justificativa registrada
• Gera alerta ao gestor de segurança
• É auditado retrospectivamente
• Uso indevido é sancionável

Segregação de dados sensíveis

Certos dados exigem controle ainda mais restritivo:

• Registros psiquiátricos
• Resultados de HIV/ISTs
• Informações sobre saúde reprodutiva de adolescentes
• Dados genéticos

Esses dados podem ter RBAC adicional, mesmo dentro do prontuário do mesmo paciente.

Audit Trail: trilha de auditoria inviolável

O que registrar

Toda interação com dados clínicos deve ser logada:

• Quem acessou (identificação do usuário)
• Quando (timestamp preciso)
• O que acessou (recurso, prontuário, campo específico)
• Que ação realizou (visualizar, criar, editar, excluir, imprimir)
• De onde (IP, dispositivo)
• Resultado (sucesso, falha, negação de acesso)

Características essenciais

• Imutabilidade: Logs não podem ser alterados ou deletados, mesmo por administradores do sistema.
• Completude: Toda ação é registrada, sem exceção.
• Disponibilidade: Logs devem estar acessíveis para investigações por período mínimo igual ao prazo de guarda do prontuário.
• Integridade: Mecanismos de hash encadeado (similar a blockchain) podem garantir que logs não foram adulterados.

Monitoramento ativo

Audit trail não serve apenas para investigação retrospectiva. Monitoramento em tempo real pode detectar:

• Acesso em horários incomuns
• Volume anormal de visualizações (possível extração de dados)
• Tentativas repetidas de acesso negado
• Padrões de acesso incompatíveis com a função

Resposta a incidentes

Plano documentado

Toda instituição de saúde deve ter um plano de resposta a incidentes de segurança que inclua:

1. Detecção: Como incidentes são identificados (monitoramento, alertas, denúncia)
2. Contenção: Ações imediatas para limitar o dano (isolamento de sistemas, revogação de acessos)
3. Erradicação: Remoção da causa raiz
4. Recuperação: Restauração dos sistemas e dados
5. Notificação: Comunicação à ANPD e titulares afetados (obrigatória pela LGPD)
6. Lições aprendidas: Análise pós-incidente para prevenir recorrência

Ransomware: ameaça específica à saúde

Hospitais são alvos preferenciais de ransomware porque:

• A indisponibilidade de sistemas impacta diretamente vidas
• A pressão para restaurar acesso rapidamente favorece pagamento de resgate
• Sistemas legados frequentemente não recebem patches de segurança

Mitigações essenciais:

• Backups offline (air-gapped) testados regularmente
• Segmentação de rede
• Patching disciplinado
• Treinamento anti-phishing para toda equipe
• Simulações periódicas de incidentes

Segurança física

Dados clínicos não vivem apenas no digital:

• Servidores em sala com acesso controlado
• Estações de trabalho com bloqueio automático
• Impressoras em áreas restritas (prontuários impressos não ficam expostos)
• Descarte seguro de mídias e equipamentos

Conformidade regulatória

A segurança de dados clínicos no Brasil deve atender:

• LGPD: Medidas técnicas e administrativas para proteger dados sensíveis
• Resolução CFM 2.218/2018: Requisitos de segurança para sistemas de prontuário
• SBIS: Requisitos de segurança para certificação de PEP
• ANS/ANVISA: Requisitos setoriais aplicáveis

Perguntas Frequentes

Qual a infraestrutura mínima para um prontuário eletrônico?

O mínimo inclui: conexão de internet confiável (preferencialmente redundante), computadores/dispositivos para os pontos de atendimento, servidor ou serviço em nuvem com backup, certificados digitais para assinatura e política de segurança documentada. Muitos sistemas modernos em nuvem (SaaS) reduzem significativamente a infraestrutura local necessária.

Como escolher um sistema de prontuário eletrônico?

Critérios essenciais: conformidade regulatória (CFM, LGPD), interoperabilidade (FHIR, TISS), usabilidade validada com profissionais clínicos, suporte técnico responsivo, roadmap de evolução, referências de clientes similares, custo total de propriedade (incluindo treinamento e migração) e portabilidade de dados em caso de troca.

Sistemas de prontuário open-source são viáveis para uso clínico?

Sim, existem opções maduras (OpenMRS, GNU Health, Bahmni). Vantagens incluem custo de licença zero, auditabilidade do código e flexibilidade de customização. Desvantagens incluem necessidade de equipe técnica para implantação e manutenção, e menor disponibilidade de suporte comercial. A viabilidade depende da capacidade técnica da instituição.

Conclusão

Segurança de dados clínicos não é um projeto com data de término — é um processo contínuo que exige investimento constante em tecnologia, processos e capacitação. A combinação de criptografia robusta, controle de acesso granular e trilha de auditoria completa forma a base mínima de proteção. Sobre essa base, monitoramento ativo e resposta preparada a incidentes completam a postura de segurança.

O custo de investir em segurança é sempre menor que o custo de um incidente. Quando dados de saúde são comprometidos, o dano é irreversível — diferente de um cartão de crédito, um diagnóstico vazado não pode ser cancelado.