O que é o Monitor de Privacidade do Paciente e por que qualquer aplicativo de saúde deve tê-lo

Quando você fala sobre segurança em aplicativos médicos, quase todos pensam sobre a mesma coisa: criptografia, MFA, HTTPS, BAA com o provedor de infraestrutura. Tudo o que é necessário. Mas há uma camada que quase ninguém discute publicamente e que, no entanto, é a que mais falhas reais param no dia a dia.

A pergunta estranha não é "Os dados estão criptografados?". É:

Se ligarmos agora mesmo e perguntarmos quem concordou com os prontuários de Juan Pérez nos últimos 30 dias, você pode nos responder em menos de um minuto?

Para responder a essa pergunta, há uma categoria de sistemas com seu próprio nome na indústria: Monitoramento de Privacidade do Paciente, uma aplicação específica de UEBA (Use & Entity Behavior Analytics) para o contexto de saúde. Neste artigo dizemos o que é, por que HIPAA requer isso, como funciona tecnicamente e como o implementamos no Brauni.

O verdadeiro perfil de ameaça à saúde

Quando você imaginar uma violação de dados médicos, pense em um hacker com capuz digitando comandos em um teclado escuro. A realidade é muito menos cinematográfica.

De acordo com os relatórios anuais de OCR (Office for Civil Rights, U. S. regulador HIPAA) e Verizon DBIR, a maioria dos incidentes de PHI não vêm de um atacante externo quebrando criptografia. Eles vêm de contas legítimas fazendo perguntas que não devem:

• Um funcionário curioso revisando o arquivo de um paciente conhecido ou famoso
• Uma conta que exporta 200 fichas para 3 de manhã
• Um ex-trabalhador de sessão activa que ninguém revogou no momento da quitação
• Alguém tentando mudar IDs no URL para ver o que é retornado (que é chamado de IDOR, Insegura Referência de Objeto Direto)
• Um terapeuta a aceder a arquivo que não são dos seus pacientes.

Nenhuma destas ameaças para com a criptografia. A criptografia protege contra alguém que entra à força. Ela não protege contra alguém que tem a chave.

O que é o Monitor de Privacidade do Paciente?

É uma categoria de sistemas dedicados a observar como os dados clínicos são utilizados dentro da aplicação e detectar padrões que estão longe do normal. Na literatura técnica é conhecido por vários nomes de acordo com o ângulo:

• UEBA (Use & Entity Behavior Analytics): O grande guarda-chuva, usado por Gartner e fornecedores como Splunk, Exabeam ou Microsoft Sentinel
• Monitoramento de privacidade do paciente ou Intelligence de privacidade do paciente (PPI): o nome usado por provedores de saúde (Protenus, Imprivata FairWarning, Miize Analytics)
• Insider Threat Detection & Response (ITDR): nome do ângulo de segurança cibernética pura
• Monitorização do registo de audiências: o nome mais antigo e técnico, sem sabor de marketing

Na linguagem HIPAA, este tipo de sistema abrange três requisitos formais:

Não é opcional, é lei.

Como funciona: as nove perguntas do sistema

No Brauni, cada acesso à informação de saúde protegida (PHI) é registrado em um registro de auditoria imutável. Nesse registro, um motor de detecção executa nove regras em paralelo, cada uma respondendo a uma pergunta específica:

1. Alguém está tentando mudar IDs no URL? (IDOR_ATTEMPT)

Severidade: HIGH

Se uma conta acumula vários eventos ACCESS_DENIED em uma janela curta, provavelmente está testando manualmente para alterar IDs do paciente para ver quais deles respondem a ela. É o padrão clássico de descoberta de IDOR (Insecure Direct Object Reference). A regra agrupa o negado por user_id e dispara quando cruza um limite.

2. Alguém está abrindo muitas histórias em pouco tempo? (BULK_ACCESS)

Severidade: HIGH

Um terapeuta normal verifica entre os arquivos 5 e 20 por dia, o seu. Se uma conta abre 30+ prontuários diferentes em uma janela curta, algo não está certo. Pode ser um raspador, uma conta comprometida, ou um funcionário que faz a visita. A regra conta pacientes diferentes (não acessos repetidos ao mesmo paciente, que é uso normal).

3. Alguém está exportando maciçamente? (BULK_EXPORT)

Severidade: Crítico

Exportar é a operação mais perigosa: tira o PHI do perímetro controlado do aplicativo e o transforma em um arquivo que pode viver em qualquer disco. Uma única exportação legítima é normal. Dez em uma hora é um sinal de alarme vermelho. É por isso que esta regra é a única com gravidade CRITICA.

4. Existe um ataque de força bruta? (LOGIN_BURST)

Severidade: MÉDIO

Ele detecta quando um único IP acumula muitas falhas de login. A sutileza técnica importante: esta regra não é indexada por usuário mas por IP original, porque um ataque de força bruta ou de sufocamento credencial desencadeia muitas tentativas diferentes: às vezes contra e-mails que não existem, às vezes com a senha incorreta de um usuário que existe. É por isso que ele agrupa tentativas falhadas por IP independentemente de se o e-mail corresponde a um usuário real ou não, e é a única regra do motor que não precisa de um user_id válido para filmar.

5. A conta fez "teleport"? (IMPOSSIBLE_TRAVEL)

Severidade: HIGH

Se a mesma conta entra em Buenos Aires no 14:00 e dez minutos depois em Madrid, há um problema físico: ninguém viaja para 60.000 km/h. O sistema calcula a velocidade implícita entre duas sessões consecutivas e dispara quando excede um limite configurável. É um dos indicadores mais fortes de conta comprometida.

6. A conta entrou de um novo país? (NEW_GEO)

Severidade: MÉDIO

Uma conta que historicamente só entrou da Argentina e de repente logins da Romênia merece uma revisão. Não é sempre um ataque (pode ser uma viagem), mas merece atenção.

7. É um dispositivo novo? (NEW_DEVICE)

Severidade: MÉDIO

Brauni atribui um identificador estável a cada dispositivo (cookie assinado + pegada mínima). Se uma conta usa um dispositivo que nunca viu antes, ele é registrado como um evento. Útil para detectar contas compartilhadas ou sessões sequestradas.

8. Houve acesso fora do horário? (OFF_HOURS)

Severidade: LOW

Uma leitura de PHI na 3 de manhã não é necessariamente suspeita, mas é informação útil para correlacionar. Se você também cruzar com IMPOSSIBLE_TRAVEL ou BULK_ACCESS, a pontuação total sobe.

9. A conta está no processo de desactivação? (AFTER_TERMINATION)

Severidade: LOW

Se um usuário tem uma data baixa programada e continua a acessar o PHI, ele é sinalizado. É uma das ameaças mais comuns e piores cobertas: o ex-empregado com sessão ao vivo.

Como eles se combinam: pontuação adicionada

Cada regra adiciona pontos para uma pontuação por janela de tempo. Uma única regra baixa não escala. Três Baixo + um MEDIUM na mesma janela pode cruzar o limiar de alerta global e marcar o evento como alerted=true, que é o que desencadeia a notificação para o painel de administração e CloudWatch.

Isso evita dois extremos ruins: alerte fadiga (tudo é urgente, então nada é) e subdetecção (cada regra separadamente não se alarma, mas a soma deve).

Auditoria em vidro de ruptura: a outra metade do problema

Detectar o suspeito é apenas metade do trabalho. A outra metade é reconstruir a história depois.

Em qualquer instituição de saúde há momentos em que é necessário quebrar a regra normal de acesso: uma emergência, uma investigação interna, uma ordem judicial. Chama-se acesso de vidro quebra, "quebrar o vidro". O HIPAA permite, mas exige que seja registrado quem o fez e quando.

Brauni exibe uma visão de vidro de quebra por paciente. Dado um patient_id, ele retorna quem acessou seus prontuários, em que data e hora, a partir do qual IP, a partir de qual dispositivo, e que operação ele realizou (READ, EXPORT, UPDATE...).

O problema do observador observado

Há um detalhe técnico fácil de ignorar que aprendemos rapidamente: o sistema que você olha também tem que ser visto.

Quando um administrador consulta a linha do tempo de um paciente, essa consulta é em si um acesso ao PHI. Se não for auditado, o painel de administração se torna o único lugar onde os dados podem ser acessados sem deixar um rastro. Esse é exatamente o buraco que o sistema vem para plugar.

No Brauni, cada consulta em vidro de ruptura:

1. É registado como um diário de auditoria próprio (READ sobre audit_timeline)
2. É excluída das suas próprias estatísticas de detecção, de modo que um administrador que investiga 30 diferentes timelines não se auto-incrimine com um BULK_ACCESS
3. Validar a existência do paciente antes de escrever, para evitar registros de "fantasma" em pacientes que não existem

Resposta imediata: quatro ações do painel

Detectar é necessário, mas não suficiente. Se o administrador vir um alerta CRÍTICO no 2 de manhã, ele precisa agir agora, para não abrir três abas diferentes.

É por isso que quatro ações de resposta podem ser demitidas do próprio evento:

1. Revogação de todas as sessões do usuário - invalida o JWT activo (bomba do token_version) e apaga todos os tokens de atualização. 401.
2. Reset 2FA - exclui TOTP, WebAuthn e códigos de backup. O usuário legítimo terá que reconfigurar; o atacante com a chave física roubada é deixado de fora.
3. Desbloquear conta - útil no cenário inverso: após um LOGIN_BURST acidental por conta de um usuário legítimo.
4. Force reset de senha - desencadeia fluxo de e-mail com link de mudança obrigatório.

Cada ação requer confirmação explícita (confirm: true, token CSRF e deixa um rastro no evento. Um administrador não pode agir por conta própria user_id (autodefesa contra contas de administrador comprometidas).

Ciclo de Vida do Evento

Um evento passa por estados: OPEN → ACKNOWLEDGED → RESOLVED ou FALSE_POSITIVE. A primeira ação bem-sucedida move-o automaticamente para ACKNOWLEDGED (então a equipe vê que alguém está trabalhando nele). Um evento fechado rejeita novas ações até que um administrador o reabre. Isso evita "reabrir a ferida" sem querer após o incidente ter sido formalmente fechado.

Como se encaixa na arquitetura Brauni

O sistema funciona em dois níveis:

• Plano de captura: cada operação no PHI escreve um AuditLog em uma tabela somente de apêndices. Isso acontece de forma sincrônica com a solicitação do usuário, na mesma transação: é uma decisão deliberada para garantir atomicidade (se o acesso não for registrado, a mudança no PHI não é concreta) e perda zero de eventos por queda do trabalhador. Custo é uma escrita extra no caminho crítico de cada solicitação; se o volume vier a justificá-lo, o passo natural é derivar esse registro para uma cauda intermediária persistente, sem renunciar à durabilidade ou imutabilidade.
• Plano de definição: Uma tarefa do APScheduler executa o motor de detecção através de janelas de tempo configuráveis. Ele é executado pelo processo de trabalho (separado da API), com a escolha do líder PostgreSQL por bloqueio de conselheiro, de modo que apenas uma instância o executa de cada vez, mesmo que existam várias réplicas.

Cada evento detectado também emite uma métrica para CloudWatch via filtro métrico, que ativa alarmes SNS para a equipe de guarda. Assim, um evento CRITICO não depende de alguém olhando para o painel 3 pela manhã: o painel notifica o telefone, não o contrário.

Dados do sistema de monitoramento não contém PHI: apenas IDs internos, IPs, geolocalização, identificadores e contagem de dispositivos. A regra é estrita: o sistema que monitora o acesso a dados sensíveis não pode ser uma segunda cópia desses dados.

Como escolher um provedor de software clínico, olhando para isso

Se você estiver avaliando uma plataforma para sua clínica ou prática, pergunte isso antes de assinar:

1. Eles mantêm um registro de auditoria imutável de cada acesso a dados clínicos? Se a resposta é "logs estão no CloudWatch", não é suficiente: CloudWatch está operacional, não é um registro de auditoria retido seis anos como o HIPAA requer.
2. Você tem regras de detecção ativa nesse registro ou apenas mantê-lo? Salvar sem olhar é como ter câmeras de segurança desligadas.
3. Você pode me mostrar qual linha do tempo acessou o arquivo de um determinado paciente? Se a resposta leva mais de um minuto, eles não têm vidro de ruptura real.
4. E se um funcionário meu se demitir hoje? Como sei que nenhum dado foi tomado antes de sair? A regra BULK_EXPORT e a resposta revoke-sessions devem fazer parte da resposta.
5. O sistema de monitoramento faz auditoria em si? Se a pergunta os leva de surpresa, eu presumi que não.

O que é que isto significa para ti?

Isso significa que quando você mantém uma nota de sessão no Brauni, esse ato é gravado permanentemente. Se amanhã você suspeitar que um dado vazou, há uma maneira de reconstruir exatamente o que aconteceu, quem o viu e de onde. Se uma conta de computador se comporta de forma estranha, o sistema o detecta antes de alguém verificar os registros à mão. E se um incidente for confirmado, o acesso pode ser cortado em segundos.

Criptografia, BAA com provedor de infraestrutura, não use dados para treinar IA, encriptação de campo a campo. Tudo isso são condições necessárias. Monitoramento de privacidade do paciente é a camada que faz confiança verificável.

Porque no final, na saúde, a questão certa não é "São os dados seguros?". É "Como você sabe que eles são?" E essa pergunta só é respondida com evidência.

Você tem alguma dúvida sobre como proteger a privacidade ou você quer mergulhar em algum aspecto técnico deste sistema? Escreva para soporte@brauni.io. Estamos aqui para lhe dar paz de espírito.

---

Brauni cumpre com os princípios da Lei de Proteção de Dados Pessoais 25.326 da Argentina e está alinhada com os padrões internacionais do HIPAA para a gestão de informações de saúde protegidas (PHI). O sistema de Monitorização da Privacidade do Paciente abrange os requisitos dos Controles de Auditoria (45 CFR §164.312(b)), Revisão da Atividade do Sistema de Informação (§164.308(a)(1)(D))) e Procedimentos de Incidente de Segurança (§164.308(a)(6). O Brauni fornece as ferramentas de infraestrutura e monitoramento compatíveis com essas normas; a responsabilidade pelo processamento de dados e ativação de protocolos de resposta cabe a cada profissional ou instituição, em seu papel de controlador.