Resoluções — Segurança da Informação em Saúde (Turma B)
Este arquivo destina-se exclusivamente ao uso do professor. Ele contém as resoluções comentadas das três atividades da Turma B do Módulo 11, com orientações pedagógicas detalhadas, indicações dos erros mais frequentes esperados dos estudantes e roteiros para a condução da discussão coletiva em sala. Não distribua este arquivo aos estudantes antes ou durante a realização das atividades.
Atividade 1 — Resolução
Resolução modelo
A atividade pede que o estudante percorra quatro dimensões analíticas para cada cenário: identificar o vetor de ataque, reconstruir a cadeia de eventos, localizar os pontos de interrupção preventiva e derivar lições para o projeto de uma HealthTech. O que o professor deve avaliar não é se o estudante memorizou o nome do ataque, mas se ele demonstra compreender por que cada elo da cadeia foi possível e o que especificamente o teria impedido.
Cenário A — análise completa
O vetor de ataque do Cenário A é phishing direcionado — mais especificamente uma variante denominada spear-phishing — combinado com captura de credenciais por keylogger. A identificação do vetor parte de dois elementos do enunciado: a mensagem foi enviada aparentemente pelo departamento de recursos humanos de dentro da própria organização, o que indica personalização para parecer legítima; e o link instalava silenciosamente um programa de captura de teclas, o que é o mecanismo técnico típico de exfiltração de credenciais por malware. O estudante que classifica o cenário apenas como “phishing genérico” está correto na classe geral, mas incompleto na especificação, e deve ser orientado a identificar o elemento de personalização interna que eleva o nível de sofisticação e a taxa de sucesso.
A cadeia de eventos que tornou o ataque possível tem seis elos distintos. O primeiro elo é o envio do e-mail fraudulento, que foi suficientemente convincente — assunto sobre benefícios com prazo de 48 horas, aparente origem interna no RH — para induzir urgência e confiança. O segundo elo é o clique de 17 funcionários, número que revela a ausência de treinamento consistente de conscientização sobre segurança: em qualquer organização de saúde que conduza treinamentos regulares de simulação de phishing, a taxa de cliques em mensagens simuladas diminui substancialmente. O terceiro elo é a instalação silenciosa do keylogger, que foi possível porque os computadores clicados não tinham proteção de endpoint capaz de detectar o comportamento do instalador, ou a proteção existente não estava atualizada. O quarto elo é a captura de credenciais ao longo de três semanas — período longo o suficiente para capturar credenciais de múltiplos funcionários, caso o malware estivesse instalado em mais de uma máquina. O quinto elo é o acesso remoto ao sistema de prontuários eletrônicos usando as credenciais roubadas, o que foi possível porque o sistema de prontuários aceitava autenticação apenas com usuário e senha, sem segundo fator. O sexto elo é a persistência do acesso não autorizado por 19 dias antes da detecção, o que demonstra que os mecanismos de monitoramento de acesso existentes não estavam configurados para disparar alertas sobre acessos de localizações geográficas incomuns, horários atípicos ou volumes de acesso fora do padrão do usuário.
Os pontos de interrupção preventiva devem ser associados a elos específicos da cadeia, não apresentados como lista genérica de “boas práticas”. O filtro de e-mail com verificação SPF e DMARC teria atuado no primeiro elo, identificando que o domínio remetente não correspondia ao servidor legítimo do hospital. O treinamento de conscientização teria atuado no segundo elo, reduzindo a probabilidade de clique. A proteção avançada de endpoint com análise comportamental teria atuado no terceiro elo, detectando a tentativa de instalação silenciosa de um programa de captura de teclas. A autenticação multifator — MFA — teria atuado no quinto elo e é, de todos os controles listados, o de maior impacto isolado: mesmo com a senha correta em mãos, o atacante não teria conseguido autenticar-se no sistema de prontuários sem o segundo fator, que permaneceria exclusivamente com o funcionário legítimo. Um SIEM configurado com regras de anomalia — acesso de IP externo, horário fora do expediente, volume de registros consultados acima da média do usuário — teria atuado no sexto elo, reduzindo o período de acesso não detectado de 19 dias para horas ou minutos.
A lição para HealthTechs derivada do Cenário A tem duas dimensões. A primeira é técnica: qualquer sistema de HealthTech que permita acesso remoto a dados de saúde de pacientes deve ter MFA implementado como requisito não negociável — não como opção disponível, mas como obrigação para todo acesso externo à rede. A segunda dimensão é cultural: a segurança técnica é necessária mas insuficiente quando os usuários do sistema — médicos, enfermeiros, funcionários administrativos — não foram treinados para reconhecer engenharia social. Phishing é um ataque ao ser humano, não à máquina, e o único controle que atua nessa dimensão é a formação contínua.
Cenário B — análise completa
O vetor de ataque do Cenário B é a exploração de vulnerabilidades em dispositivos médicos conectados em rede, categoria que o material denomina IoMT — Internet of Medical Things. A identificação do vetor parte de três elementos convergentes: os equipamentos tinham seis anos de uso e o fabricante havia interrompido as atualizações de segurança dois anos após a compra; eles estavam conectados a uma rede acessível por Wi-Fi a partir do estacionamento; e o pesquisador externo conseguiu acessá-los, visualizar dados clínicos em tempo real e — hipotética mas concretamente — alterar parâmetros de alerta de eventos críticos.
A cadeia de eventos tem quatro elos. O primeiro é a decisão de compra de equipamentos sem cláusula contratual de suporte de segurança de longo prazo: ao adquirir os equipamentos, a clínica não negociou ou garantiu contratualmente o fornecimento de atualizações de segurança por um período compatível com a vida útil clínica esperada do equipamento. O segundo elo é a interrupção das atualizações de segurança pelo fabricante dois anos após a compra, deixando os sistemas operacionais dos equipamentos com vulnerabilidades conhecidas e não corrigidas acumulando-se por quatro anos. O terceiro elo é a ausência de segmentação de rede: os equipamentos de ECG estavam na mesma infraestrutura de rede Wi-Fi acessível ao estacionamento, sem isolamento por VLAN dedicada ou firewall que bloqueasse acessos originados de fora da rede interna confiável. O quarto elo é a ausência de auditorias periódicas de segurança de dispositivos conectados, que poderia ter detectado as vulnerabilidades antes de um pesquisador externo fazê-lo.
Os pontos de interrupção preventiva acompanham os elos. No primeiro elo, a interrupção seria contratual: incluir na especificação de compra de equipamentos médicos conectados uma cláusula de suporte de segurança de no mínimo oito a dez anos, e fazer da disponibilidade de atualizações um critério de seleção de fornecedor. No segundo elo, a interrupção seria o gerenciamento ativo do ciclo de vida de firmware: ao detectar que o fabricante interrompeu o suporte, a clínica deveria iniciar um processo de substituição ou isolamento imediato dos equipamentos. No terceiro elo — e este é o controle de maior impacto para o cenário específico — a segmentação de rede por VLAN isolada para dispositivos médicos teria impedido o acesso do pesquisador a partir do Wi-Fi do estacionamento mesmo que as vulnerabilidades dos equipamentos permanecessem não corrigidas: sem rota de rede até os dispositivos, a vulnerabilidade não é explorável remotamente. No quarto elo, auditorias periódicas de segurança de IoT teriam antecipado a descoberta.
A lição para HealthTechs derivada do Cenário B tem uma dimensão que é particularmente relevante para startups que desenvolvem produtos com hardware conectado — wearables, monitores, sensores: o ciclo de vida de segurança do dispositivo precisa ser planejado no momento do design do produto, não após o lançamento. Uma startup que coloca um dispositivo conectado no mercado sem definir por quantos anos fornecerá atualizações de segurança, como notificará os usuários sobre vulnerabilidades descobertas e o que acontecerá quando o hardware for descontinuado está criando exatamente o tipo de vulnerabilidade que o Cenário B ilustra — mas do lado do fabricante, não do usuário.
Dicas de resolução para o professor
O erro mais frequente na Atividade 1 é o estudante que identifica o vetor de ataque corretamente — “phishing” no Cenário A, “dispositivo desatualizado” no Cenário B — mas trata a cadeia de eventos como uma recontagem cronológica do enunciado, sem identificar os elos de falha. A distinção que o professor deve provocar é entre descrever o que aconteceu e analisar por que cada etapa foi possível. A pergunta que resolve isso é: “o que precisaria ser verdadeiro no ambiente para que esse passo fosse possível?” Aplicada ao quinto elo do Cenário A, por exemplo, a resposta é: “o sistema de prontuários precisaria aceitar autenticação só com senha, sem MFA, e precisaria estar acessível pela internet.” Esse nível de especificidade é o que distingue uma análise de uma narração.
O segundo erro frequente é a lista de medidas preventivas sem ancoragem em elos específicos da cadeia. O estudante escreve “implementar firewall, usar antivírus, treinar funcionários e ativar MFA” como se fossem recomendações intercambiáveis e igualmente urgentes. O professor deve insistir: “qual dessas medidas teria impedido especificamente o quinto elo, que é o acesso remoto com credenciais roubadas?” A resposta é somente o MFA, e identificar isso é o que a atividade pede. O raciocínio de interrupção por elo específico é a competência central.
O terceiro ponto de atenção é a tendência, no Cenário B, de os estudantes focarem exclusivamente na necessidade de atualizar o firmware, negligenciando a segmentação de rede. O professor deve provocar: “suponha que o fabricante tivesse continuado fornecendo atualizações. O equipamento ainda seria acessível do estacionamento?” A resposta — que sim, a vulnerabilidade de rede seria independente do estado do firmware — demonstra que os dois controles atuam em elos distintos e ambos são necessários. Um não substitui o outro.
O que distingue uma resposta mediana de uma excelente nessa atividade é a articulação da lição para HealthTech como princípio de design — não como lista de regras de segurança. Uma resposta mediana diz “a startup deve usar MFA”. Uma resposta excelente diz “toda autenticação remota a dados de saúde de pacientes deve exigir segundo fator, porque o Cenário A demonstra que credenciais podem ser roubadas sem que o usuário perceba, e a única proteção residual é torná-las insuficientes por si só para autenticar.”
Como explicar a resolução aos estudantes
O professor pode abrir a discussão sobre o Cenário A com a seguinte questão: “quantas pessoas nesta sala já recebeu um e-mail de phishing e quase clicou?” A maioria responderá positivamente, e isso estabelece a premissa pedagógica central: phishing funciona não porque as vítimas são negligentes, mas porque os atacantes são bons em simular contextos de confiança. Isso direciona a discussão para a questão do design do controle — se pessoas bem-intencionadas e inteligentes clicam em phishing, qual controle deve ser projetado para funcionar mesmo quando o clique acontece?
Para o Cenário A, o professor pode construir o argumento da supremacia do MFA de forma dedutiva: “suponha que todos os 17 funcionários tenham clicado, o keylogger tenha capturado todas as senhas e o atacante tenha tentado logar. O que acontece se o sistema exige um segundo fator que só existe no celular do funcionário?” A conclusão — que o ataque para nesse ponto e não avança para o acesso ao prontuário — demonstra por que MFA é o controle de maior retorno por unidade de esforço em autenticação remota.
Para o Cenário B, o professor pode usar a analogia da separação física: “se os equipamentos de ECG estivessem numa sala trancada com acesso restrito, o pesquisador do estacionamento chegaria até eles?” A resposta óbvia é não — e a VLAN é o equivalente digital da sala trancada. O isolamento de rede não depende de o equipamento estar atualizado; ele impede o acesso independentemente do estado do firmware. Essa separação entre controles de rede e controles de endpoint é um conceito de defesa em profundidade que o professor pode introduzir aqui.
A síntese que o professor deve garantir ao final é que os dois cenários ilustram que a segurança em saúde tem duas dimensões irredutíveis: a dimensão humana — treinar, conscientizar, criar cultura — e a dimensão técnica — implementar controles que funcionem mesmo quando a dimensão humana falha. A defesa eficaz não aposta em que nenhum funcionário vai clicar em phishing; ela projeta o sistema para que o clique, quando acontecer, produza o menor dano possível.
Atividade 2 — Resolução
Resolução modelo
A atividade exige que o estudante vá além da memorização dos nomes dos padrões e demonstre compreender por que cada padrão é adequado para cada tipo de integração — o que implica entender o contexto técnico de cada parceiro, o contexto regulatório brasileiro e as implicações de segurança e privacidade que cada escolha de padrão introduz.
Integração A — HL7 v2
A Integração A envolve receber resultados de exames laboratoriais de laboratórios que utilizam sistemas de gestão laboratorial com infraestrutura da década de 2000. O enunciado descreve explicitamente um “protocolo de mensagens clínicas consolidado e amplamente adotado” — descrição que aponta diretamente para o HL7 v2, o padrão de mensagens clínicas legado desenvolvido desde os anos 1980 e dominante nos sistemas hospitalares e laboratoriais instalados antes de 2010. O tipo de mensagem específico para resultados de laboratório no HL7 v2 é o ORU_R01 (Observation Result Unsolicited), que é a mensagem que os sistemas legados de gestão laboratorial tipicamente emitem ao concluir um exame.
A justificativa para a escolha do HL7 v2 não é que seja o melhor padrão disponível em termos de design — ele não é — mas que é o padrão que os sistemas parceiros já falam. Forçar laboratórios com infraestrutura da década de 2000 a adotar FHIR implicaria que eles desenvolvessem ou adquirissem uma camada de tradução, o que é inviável como pré-requisito de parceria para uma startup. O HL7 v2 permite que o MedTrack se conecte onde os parceiros já estão.
A implicação técnica mais importante da escolha de HL7 v2 é a ausência de criptografia nativa: mensagens HL7 v2 são texto puro transmitido sobre TCP/IP, sem encriptação embutida no padrão. Isso significa que a transmissão precisa ser encapsulada em TLS (MLLP sobre TLS é o mecanismo padrão) para que os dados não trafeguem em claro pela rede. O estudante que identifica esse ponto demonstra que entende que a escolha do padrão não encerra a análise de segurança — ela abre um conjunto de requisitos técnicos adicionais.
A implicação sob a LGPD é a necessidade de formalizar a relação entre o MedTrack e cada laboratório parceiro por meio de um contrato de processamento de dados: os laboratórios são controladores dos dados dos pacientes em relação a seus próprios sistemas; ao enviar os dados para o MedTrack, eles atuam como operadores transferindo dados a outro operador ou controlador, e a LGPD exige que essa relação seja formalizada com cláusulas específicas sobre finalidade, segurança e responsabilidade.
Integração B — FHIR R4
A Integração B envolve permitir que prontuários eletrônicos modernos acessem e atualizem dados do paciente no MedTrack por meio de API padronizada. O enunciado fornece duas pistas determinantes: “prontuários modernos” e “padrão reconhecido internacionalmente e incentivado pelo Ministério da Saúde brasileiro por meio da RNDS”. A RNDS — Rede Nacional de Dados em Saúde — foi estabelecida pela Portaria GM/MS 1.434/2020 e adotou o FHIR como padrão de troca de dados, especificamente o perfil FHIR R4 (Release 4). Sistemas de prontuário eletrônico modernos progressivamente expõem endpoints FHIR, e qualquer integração que precise ser compatível com a infraestrutura nacional de interoperabilidade de saúde do Brasil deve usar FHIR.
A implicação técnica mais relevante da escolha de FHIR para a análise integrada de segurança é o mecanismo de autorização. FHIR é uma API REST que, na especificação SMART on FHIR — a extensão de segurança padrão para FHIR — utiliza OAuth 2.0 para autorização. Isso significa que o MedTrack precisa implementar um servidor de autorização OAuth 2.0 que emita tokens de acesso com escopo definido para cada recurso FHIR solicitado. Os tokens devem ter vida curta, e os logs de cada acesso a recursos FHIR devem ser mantidos para auditoria. O estudante que identifica a necessidade de OAuth 2.0 corretamente implementado — não apenas FHIR como padrão de dados — demonstra compreensão da diferença entre o padrão de dados e o mecanismo de segurança que o envolve.
A implicação sob a LGPD é que os recursos FHIR Patient e Observation contêm dados sensíveis de saúde; cada acesso de um prontuário parceiro ao dados do paciente no MedTrack constitui uma operação de tratamento de dados pessoais sensíveis que precisa ter base legal clara, ser registrada em log de auditoria e estar coberta por contrato de processamento de dados com o parceiro.
Integração C — TISS
A Integração C envolve enviar solicitações de autorização prévia para operadoras de saúde suplementar e receber respostas no formato exigido pela ANS. Esse caso não admite escolha alternativa: a Resolução Normativa 305/2012 da ANS torna o uso do TISS — Troca de Informação de Saúde Suplementar — obrigatório para a comunicação entre prestadores e operadoras de saúde suplementar no Brasil. Não existe alternativa regulatoriamente válida para esse tipo de integração.
A implicação técnica do TISS que merece análise é a estrutura de assinatura digital: as mensagens TISS são arquivos XML com assinatura digital, o que garante integridade e autoria da mensagem. O estudante deve reconhecer que a assinatura digital resolve o problema de integridade — é possível verificar que a mensagem não foi alterada em trânsito — mas não substitui a necessidade de criptografar o canal de transmissão. A confidencialidade depende de TLS no transporte; a integridade é garantida pela assinatura XML.
A implicação sob a LGPD é o princípio da minimização de dados: a solicitação de autorização prévia enviada à operadora deve conter apenas os dados estritamente necessários para a análise da autorização. A LGPD exige que o volume de dados pessoais sensíveis compartilhados com terceiros seja o mínimo indispensável para a finalidade declarada. Compartilhar dados além do necessário — histórico médico completo quando apenas o procedimento solicitado é relevante para a autorização, por exemplo — configura violação do princípio de minimização.
Integração D — ausência de padrão; estratégias para contextos sem interoperabilidade
A Integração D é o caso que exige o maior nível de análise porque não tem uma resposta única correta: não existe um padrão de interoperabilidade clínica consolidado para wearables com APIs proprietárias, e o estudante deve demonstrar que entende as implicações de cada estratégia disponível.
A primeira estratégia é construir adaptadores customizados para cada fabricante de wearable — um conector específico para a API da marca A, outro para a marca B, e assim por diante. Essa abordagem é funcional no curto prazo mas extremamente custosa de manutenção: cada vez que um fabricante modifica sua API, o adaptador precisa ser atualizado; cada novo modelo de dispositivo que o produto queira suportar requer novo desenvolvimento; e o código cresce de forma não estruturada com o número de integrações. Do ponto de vista de segurança, cada adaptador representa uma superfície de ataque adicional: bugs na lógica de integração podem expor dados ou criar vulnerabilidades de injeção.
A segunda estratégia é adotar uma plataforma de agregação — um middleware que consolida dados de múltiplos dispositivos e os disponibiliza num formato normalizado. Plataformas como Apple HealthKit e Google Fit atuam como essa camada de abstração: o fabricante do wearable integra com a plataforma, e o MedTrack integra apenas com a plataforma. Isso reduz o número de integrações que o MedTrack precisa manter, mas cria dependência de terceiros que são empresas de tecnologia de consumo, não de saúde, com políticas de privacidade orientadas ao consumidor, não ao setor regulado de saúde. O estudante deve identificar que usar uma plataforma de consumo para agregar dados de saúde de pacientes levanta questões de base legal sob a LGPD.
A terceira estratégia é limitar a compatibilidade declarada do produto apenas a dispositivos que já expõem dados em FHIR Observation — tendência crescente em wearables de saúde de nível clínico — e usar FHIR como padrão único mesmo para essa integração. Essa estratégia tem a vantagem da consistência arquitetural e da sustentabilidade regulatória, mas limita o catálogo de dispositivos compatíveis no curto prazo.
A implicação de segurança e privacidade que atravessa todas as estratégias é a mesma: dados coletados de wearables — frequência cardíaca, padrão de sono, atividade física, saturação de oxigênio — são dados pessoais sensíveis de saúde nos termos do Art. 5, XI da LGPD mesmo quando não acompanhados de diagnóstico médico, porque podem revelar condições de saúde e identificar indivíduos. O tratamento desses dados exige base legal específica, consentimento informado e todas as medidas técnicas de segurança aplicáveis a dados sensíveis — independentemente de qual estratégia de integração seja adotada.
Dicas de resolução para o professor
O erro mais frequente na Atividade 2 é o estudante que memoriza a regra “laboratório velho usa HL7 v2, prontuário moderno usa FHIR, plano de saúde usa TISS” sem conseguir explicar o raciocínio por trás de cada escolha. O professor deve insistir em perguntas de “por quê”: “por que não usar FHIR para o laboratório legado também?” A resposta correta — que o laboratório legado não tem capacidade de falar FHIR sem desenvolvimento adicional, e que forçar a adoção do padrão moderno como pré-requisito elimina o parceiro — demonstra que a escolha do padrão não é um julgamento de qualidade técnica mas uma decisão de viabilidade de integração.
O segundo erro frequente é tratar a Integração D como um caso sem resolução — “não há padrão, então não há o que analisar”. O professor deve reorientar: o valor da Integração D está exatamente em explorar o que acontece quando a interoperabilidade padronizada não existe, porque esse é o contexto mais frequente no desenvolvimento real de HealthTechs com hardware. As três estratégias — adaptadores customizados, plataforma de agregação, restrição a dispositivos FHIR-compatíveis — têm trade-offs reais que a atividade pede que sejam analisados.
O terceiro ponto de atenção é a tendência de separar a análise de segurança da análise de escolha do padrão, tratando-os como questões independentes. O professor deve insistir que a implicação de segurança é consequência direta do padrão escolhido: HL7 v2 não criptografa nativamente — portanto TLS é obrigatório; FHIR usa OAuth 2.0 — portanto o servidor de autorização precisa ser implementado corretamente; TISS usa assinatura XML — portanto a integridade está garantida no nível da mensagem, mas a confidencialidade ainda depende do canal. Esse encadeamento é o que a atividade espera.
O que distingue uma resposta mediana de uma excelente é a análise das implicações para a LGPD com especificidade de artigo e princípio. Uma resposta mediana diz “é preciso ter cuidado com dados do paciente”. Uma resposta excelente identifica: que os dados de wearables são sensíveis nos termos do Art. 5, XI mesmo sem diagnóstico; que a relação com cada laboratório parceiro precisa de contrato de processamento de dados; e que a minimização de dados no TISS é obrigação do princípio de adequação do Art. 6, III.
Como explicar a resolução aos estudantes
O professor pode abrir a discussão com uma questão provocativa: “a startup MedTrack poderia simplesmente usar FHIR para todas as quatro integrações e resolver tudo de uma vez?” Deixar os estudantes debaterem por alguns minutos antes de revelar que laboratórios legados simplesmente não têm capacidade de falar FHIR sem desenvolvimento adicional é mais eficaz do que simplesmente afirmar a limitação. O exercício mental de imaginar o laboratório recebendo um contrato com requisito de FHIR — e a resposta provável que daria — torna a restrição concreta.
Para a Integração C, o professor pode explorar a dimensão regulatória como exemplo de como regulação e tecnologia interagem: “se a ANS exige TISS por resolução normativa, o que acontece com a startup que decide usar FHIR para se comunicar com os planos de saúde porque acha FHIR mais moderno?” A resposta — que a startup simplesmente não conseguiria processar autorizações previamente, porque a operadora não aceita outro formato — demonstra que conformidade regulatória não é opcional e precede qualquer consideração de preferência técnica.
Para a Integração D, o professor pode pedir que os estudantes, em duplas, debatam qual das três estratégias adotariam se fossem os fundadores do MedTrack com seis meses de runway e precisassem lançar um MVP. Isso cria o contexto de restrição de recursos real que as startups enfrentam, e a discussão sobre trade-offs de cada estratégia — velocidade de desenvolvimento versus manutenibilidade versus consistência arquitetural — tem mais qualidade quando há uma pressão fictícia de tempo.
Atividade 3 — Resolução
Resolução modelo
A Atividade 3 é uma auditoria integrada que exige que o estudante aplique simultaneamente o referencial técnico de segurança — a Tríade CIA, controles de autenticação, criptografia, gestão de credenciais — e o referencial legal da LGPD, incluindo artigos específicos. A qualidade da resposta é avaliada pela precisão com que o estudante conecta cada vulnerabilidade técnica ou falha organizacional a sua consequência concreta para os pacientes e para a empresa.
Primeira dimensão — análise da base legal
Os dados coletados pela PsychConnect incluem resultados de questionários PHQ-9 e GAD-7 e registros das consultas de telepsiquiatria. Esses dados são inequivocamente dados sensíveis de saúde nos termos do Art. 5, XI da LGPD, que define como dado sensível “dado pessoal sobre saúde ou vida sexual”. Resultados de escalas psicométricas de ansiedade e depressão revelam condições de saúde mental e permitem inferir diagnósticos clínicos — o PHQ-9 é uma escala validada de triagem para transtorno depressivo maior e o GAD-7 para transtorno de ansiedade generalizada, com pontos de corte publicados. Os registros das consultas em formato de texto estruturado pelo profissional são documentos clínicos de saúde mental. Não há margem para classificação diferente.
O tratamento de dados sensíveis de saúde pela LGPD é regido pelo Art. 11, que estabelece que esses dados só podem ser processados nas hipóteses previstas em seus incisos. O inciso I do Art. 11 permite o tratamento com consentimento do titular, “de forma específica e destacada, para finalidades específicas”. O Art. 8, § 1.º estabelece que o consentimento deve ser fornecido de forma “livre, informada e inequívoca”. O Art. 8, § 4.º estabelece que o consentimento deve ser “para finalidades determinadas” e que “autorizações genéricas para o tratamento de dados pessoais serão nulas”.
O “Termo de Uso e Privacidade” descrito no cenário — duas páginas que autorizam genericamente “o uso dos dados para melhoria dos serviços” — viola diretamente todas essas exigências. Ele não é específico: não descreve que dados psicométricos sensíveis são coletados. Não é destacado: dados sensíveis exigem consentimento “de forma específica e destacada”, não enterrado em cláusula genérica. Não tem finalidades determinadas: “melhoria dos serviços” é uma finalidade indeterminada, vaga e abrangente. O uso de resultados psicométricos por um algoritmo para recomendar nível de cuidado é uma finalidade automatizada com efeitos sobre o titular — o que ativa obrigações adicionais do Art. 20 da LGPD sobre decisões automatizadas. O consentimento atual não menciona nenhum desses elementos.
Para que a base legal fosse válida, o termo de consentimento precisaria: identificar explicitamente que resultados de PHQ-9 e GAD-7 são coletados e que constituem dados sensíveis de saúde mental; descrever especificamente como esses dados são usados pelo algoritmo de recomendação de nível de cuidado; indicar quais profissionais parceiros têm acesso aos registros das consultas e sob quais condições; especificar se os dados são usados para treinamento de modelos de IA e, em caso afirmativo, com qual base legal autônoma; e apresentar os dados de contato do encarregado de dados (DPO) e o canal para exercício de direitos do titular.
Segunda dimensão — análise de vulnerabilidades técnicas
O estudante deve identificar pelo menos quatro vulnerabilidades, associar cada uma a um pilar da Tríade CIA e propor medida específica de mitigação.
A primeira vulnerabilidade é a ausência de autenticação multifator. A Tríade CIA comprometida é a confidencialidade: sem segundo fator, qualquer credencial comprometida — por phishing, reutilização de senha, vazamento de banco de dados de outro serviço — produz acesso total à conta do paciente ou do profissional, incluindo todos os registros de consultas e resultados psicométricos. A confidencialidade de dados de saúde mental de mais de dois mil pacientes fica condicionada à robustez de uma única senha. A mitigação é implementar TOTP — senhas de uso único baseadas em tempo — ou autenticação por SMS como segundo fator obrigatório para todos os acessos, com prioridade para o acesso de profissionais que visualizam registros de múltiplos pacientes.
A segunda vulnerabilidade é a ausência de criptografia em repouso no banco de dados. O pilar comprometido é a confidencialidade: uma violação de banco de dados — por ataque externo, acesso indevido de funcionário ou falha de configuração do provedor de nuvem — expõe todos os dados de saúde mental de todos os pacientes cadastrados em texto puro. Para dados de telepsiquiatria — diagnósticos de depressão e ansiedade, registros de consultas, histórico de crises — a exposição representa dano grave e potencialmente irreversível à privacidade e à saúde dos pacientes. A mitigação é implementar criptografia AES-256 para dados em repouso, com gerenciamento de chaves separado do banco de dados — as chaves de criptografia não devem estar armazenadas no mesmo ambiente que os dados criptografados.
A terceira vulnerabilidade é o uso de plataforma de videoconferência de uso geral sem acordo de processamento de dados. O pilar comprometido é a confidencialidade: a plataforma de videoconferência genérica processa o conteúdo das consultas de telepsiquiatria — o que o paciente relata, o que o profissional registra verbalmente — sem que haja garantia contratual de que esses dados são tratados em conformidade com normas de privacidade em saúde, sem que haja um DPA (Data Processing Agreement) formalizado e sem que a plataforma assuma responsabilidades como operadora de dados sensíveis nos termos da LGPD. A mitigação é migrar para uma plataforma de videoconferência com funcionalidade específica para saúde — que ofereça criptografia de ponta a ponta verificável, DPA compatível com LGPD e que não use os dados das sessões para finalidades próprias da plataforma.
A quarta vulnerabilidade é a política de senha mínima de seis caracteres. O pilar comprometido é a confidencialidade: senhas de seis caracteres são altamente suscetíveis a ataques de força bruta e, especialmente, a ataques de credential stuffing — o uso de combinações de usuário e senha vazadas de outros serviços para tentar acesso no serviço-alvo. Considerando que a maioria das pessoas reutiliza senhas, uma senha de seis caracteres usada no PsychConnect provavelmente é idêntica a senhas usadas em outros serviços que já sofreram vazamentos. A mitigação é elevar o requisito mínimo para doze caracteres, implementar verificação contra listas de senhas conhecidas comprometidas — um serviço como HaveIBeenPwned fornece API para essa verificação — e bloquear temporariamente contas após um número configurável de tentativas falhas consecutivas.
A quinta vulnerabilidade, que completa uma análise mais abrangente, é o uso de credenciais compartilhadas entre sistemas pelo profissional parceiro. Os pilares comprometidos são confidencialidade e integridade: se as mesmas credenciais que o profissional usa para acessar registros no PsychConnect são usadas em outros sistemas, uma violação em qualquer um desses sistemas — cujo nível de segurança está fora do controle do PsychConnect — compromete também o acesso ao PsychConnect. Além disso, o uso de credenciais compartilhadas dificulta o rastreamento de auditoria: se múltiplos sistemas usam as mesmas credenciais, não é possível determinar com precisão se uma ação no PsychConnect foi realizada pelo profissional legítimo ou por um atacante que comprometeu suas credenciais em outro sistema. A mitigação é exigir credenciais únicas e dedicadas para acesso ao PsychConnect, e implementar controle de acesso baseado em perfil com o princípio de menor privilégio — o profissional só deve ter acesso aos registros dos pacientes que atende, não a todos os registros da plataforma.
Terceira dimensão — análise de conformidade organizacional
A ausência de DPO — Encarregado de Proteção de Dados — viola o Art. 41 da LGPD, que determina que o controlador deve indicar um encarregado “pelo tratamento de dados pessoais”. A regulamentação da ANPD — especificamente a Resolução CD/ANPD 2/2022 — indica que controladores que realizam tratamento em larga escala de dados sensíveis ou que tenham como atividade principal o tratamento de dados pessoais devem designar um DPO. A PsychConnect processa dados de saúde mental de mais de dois mil pacientes de forma sistemática como atividade central do negócio: a exigência de DPO aplica-se com alta probabilidade. Para entrar em conformidade, a startup precisa designar formalmente um encarregado — que pode ser um profissional interno ou externo — e publicar seus dados de contato de forma clara no site e nos materiais de comunicação com os titulares.
A ausência de RIPD — Relatório de Impacto à Proteção de Dados Pessoais — viola o Art. 38 da LGPD combinado com as diretrizes da ANPD. O RIPD é exigido quando o tratamento de dados pessoais pode gerar riscos às liberdades civis e aos direitos fundamentais — e o tratamento de dados de saúde mental de pacientes com transtornos de ansiedade e depressão por um algoritmo que determina o nível de cuidado recomendado enquadra-se diretamente nessa hipótese: o processamento automatizado de dados psiquiátricos sensíveis com efeitos diretos sobre a assistência ao paciente é exatamente o tipo de atividade para a qual o RIPD foi concebido. Para entrar em conformidade, a startup precisa conduzir o RIPD antes de lançar o produto em produção — ou imediatamente, se o produto já estiver em operação — descrevendo os fluxos de dados, os riscos identificados e as medidas de mitigação adotadas.
A ausência de procedimento documentado de resposta a incidentes viola o Art. 48 da LGPD, que exige que o controlador comunique à ANPD e aos titulares a ocorrência de incidentes de segurança que possam acarretar risco ou dano relevante. Sem um procedimento documentado, a startup não tem como cumprir o prazo e o conteúdo exigidos para a notificação — que deve incluir a descrição da natureza dos dados afetados, o número de titulares impactados, as medidas técnicas e de segurança adotadas para proteção dos dados e as medidas tomadas para reverter ou mitigar o incidente. Para entrar em conformidade, a startup precisa elaborar um plano de resposta a incidentes que defina papéis, responsabilidades, procedimentos de contenção, comunicação interna e comunicação à ANPD e aos titulares.
Quarta dimensão — recomendação priorizada
A priorização de três ações com recursos limitados exige que o estudante aplique um critério explícito — o material propõe a combinação de gravidade do risco para os pacientes com exposição legal da empresa.
A primeira ação prioritária é a implementação de MFA. A justificativa pela prioridade máxima é a combinação de alto impacto com baixo custo de implementação: autenticação multifator pode ser implementada em dias usando bibliotecas padrão como TOTP (RFC 6238), protege imediatamente todos os dois mil pacientes com uma única intervenção técnica e resolve a vulnerabilidade de maior probabilidade de exploração — credential stuffing e phishing de senhas são ataques automatizados e contínuos, não requerem sofisticação do atacante. No contexto de uma startup de telepsiquiatria, um acesso não autorizado a registros de saúde mental tem potencial de dano severo ao paciente — estigma, discriminação trabalhista, impacto em relacionamentos — e exposição legal significativa para a empresa.
A segunda ação prioritária é a correção da base legal de consentimento. A justificativa é que o consentimento inválido é a falha com maior exposição legal imediata: a PsychConnect não tem nenhuma base legal válida para o tratamento de dados sensíveis de saúde mental de seus pacientes. Se a ANPD instaurar uma fiscalização — o que pode ocorrer a partir de denúncia de um único titular insatisfeito — a ausência de base legal válida é uma violação autônoma independente de qualquer incidente de segurança, sujeita a sanções administrativas que incluem multa de até 2% do faturamento, limitada a R$50 milhões por infração, além de possível ordem de suspensão do tratamento dos dados. Corrigir o consentimento não requer desenvolvimento técnico — requer revisão jurídica e redesign do fluxo de onboarding — e resolve a exposição legal mais imediata.
A terceira ação prioritária é a implementação de criptografia em repouso no banco de dados. A justificativa pela terceira posição — e não primeira — é que ela tem custo de implementação maior do que MFA e pode exigir migração do banco de dados existente, mas tem um perfil de risco catastrófico: uma violação de banco de dados sem criptografia expõe simultaneamente todos os registros de saúde mental de todos os pacientes de uma vez, com dano irreversível à privacidade dos titulares e obrigação imediata de notificação à ANPD nos termos do Art. 48. Para dados de psiquiatria — diagnósticos de depressão e ansiedade, relatos de crises, histórico de tratamento — a magnitude do dano por paciente justifica o esforço de implementação como a terceira ação mais urgente depois das duas primeiras, que têm menor custo de execução e exposição imediata igualmente grave.
Dicas de resolução para o professor
O erro mais frequente na Atividade 3 é a análise da base legal que conclui “o termo não é adequado” sem especificar por que artigo e por quê. O professor deve insistir que o referencial legal é artigo específico, não impressão geral. A pergunta que corrige esse desvio é: “qual artigo da LGPD exige que o consentimento para dados sensíveis seja específico e destacado?” A resposta — Art. 11 combinado com Art. 8, §4.º — é o nível de especificidade que a atividade espera. Estudantes que chegam a essa especificidade demonstram que leram o material com atenção analítica, não apenas como narrativa.
O segundo erro frequente é identificar vulnerabilidades técnicas sem associá-las a um pilar específico da Tríade CIA, produzindo listas de “problemas” sem estrutura analítica. O professor deve perguntar, para cada vulnerabilidade levantada: “se esse controle falhar — se o atacante explorar essa fraqueza com sucesso — o que acontece com os dados? Eles ficam inacessíveis, são alterados ou são expostos a quem não deveria tê-los?” A resposta a essa pergunta mapeia automaticamente a vulnerabilidade ao pilar afetado: inacessibilidade é disponibilidade; alteração é integridade; exposição indevida é confidencialidade.
O terceiro ponto de dificuldade é a priorização. Muitos estudantes listam as três ações prioritárias sem justificar o critério de prioridade, ou justificam com base em critério único — geralmente “o mais grave para o paciente” ou “o mais fácil de implementar” — sem combinar os dois. O professor deve provocar: “entre a criptografia em repouso e o MFA, qual protege mais pacientes por unidade de esforço de implementação?” Esse tipo de pergunta força o estudante a articular que MFA tem custo de implementação menor e raio de proteção imediato mais amplo — protege contra todos os ataques de credencial comprometida — enquanto a criptografia em repouso tem custo maior mas protege contra violação total do banco de dados. Ambos são urgentes, mas o critério de prioridade combina impacto e viabilidade.
O quarto ponto de atenção é a tendência de tratar a análise organizacional como menos importante do que a técnica. Estudantes com formação mais técnica frequentemente expandem a análise de vulnerabilidades e comprimem a análise de DPO, RIPD e notificação de incidentes. O professor deve reforçar que, do ponto de vista da exposição legal, a ausência de DPO e RIPD são violações autônomas da LGPD — não dependem de que haja um incidente para serem configuradas — e que a ANPD pode aplicar sanções administrativas com base nessas ausências independentemente de qualquer violação de segurança ocorrida. A lição é que conformidade organizacional não é acessório da segurança técnica: é uma dimensão autônoma de risco.
Como explicar a resolução aos estudantes
O professor pode abrir a discussão da Atividade 3 com a seguinte questão: “como paciente de uma plataforma de telepsiquiatria, o que você consideraria mais grave — que seu CPF fosse vazado, ou que seu diagnóstico de depressão e os relatos das suas consultas fossem vazados?” A resposta quase universal — que os dados de saúde mental são mais sensíveis do que o CPF — cria o contexto emocional necessário para que as vulnerabilidades técnicas que seguem não sejam abstratas.
Para a análise da base legal, o professor pode fazer o exercício de ler em voz alta a cláusula do termo de uso — “o uso dos dados para melhoria dos serviços” — e perguntar: “isso explica o que a plataforma faz com os resultados do seu PHQ-9? Isso descreve que um algoritmo usará os seus escores de depressão para decidir se você precisa de psicólogo ou psiquiatra?” A inadequação do consentimento torna-se óbvia quando confrontada com o que o algoritmo realmente faz com os dados, e o estudante internaliza que a especificidade não é formalismo jurídico — é o que permite ao titular decidir com informação adequada se quer ou não consentir.
Para a análise de vulnerabilidades, o professor pode propor a dinâmica do “atacante hipotético”: um ator externo com acesso apenas à rede pública — sem nenhuma credencial, sem acesso privilegiado — quais dos pontos fracos do PsychConnect consegue explorar? A lista que emergir — credential stuffing habilitado pela senha fraca sem MFA, acesso ao banco de dados via plataforma de nuvem mal configurada porque não há criptografia — demonstra que os ataques mais prováveis não requerem sofisticação, e que os controles básicos omitidos são exatamente os que teriam impedido os ataques mais prováveis.
Para a priorização, o professor pode estruturar a discussão como uma reunião de conselho da startup: “vocês têm dois desenvolvedores, seis meses de runway e precisam decidir o que implementar primeiro para não matar a empresa — por violação de dados, sanção da ANPD ou processo judicial de paciente. Por onde começam?” Esse enquadramento de restrição de recursos transforma a priorização de um exercício acadêmico em uma decisão de negócio, que é o contexto em que as decisões de segurança são tomadas em startups reais.
A síntese que o professor deve garantir ao final da Atividade 3 é que segurança e conformidade legal não são duas auditorias separadas: são dois instrumentos de análise que, quando aplicados ao mesmo objeto, produzem um mapa de risco mais completo do que qualquer um dos dois isoladamente. Uma HealthTech com segurança técnica impecável mas sem base legal para tratar dados sensíveis não está protegida — está exposta a sanções administrativas. Uma HealthTech com conformidade legal formal mas sem controles técnicos básicos também não está protegida — está exposta a violações com dano real para os pacientes. O objetivo de uma auditoria integrada é identificar onde as duas dimensões se reforçam mutuamente e onde uma não compensa a falha da outra.