Guest WiFi em Conformidade com a HIPAA para Prestadores de Cuidados de Saúde

Wi-Fi de Convidados em Conformidade com a HIPAA para Prestadores de Cuidados de Saúde. Um Briefing Técnico da Purple. Bem-vindo. Se é um diretor de TI de cuidados de saúde, gestor de rede hospitalar ou responsável pela conformidade, provavelmente já teve esta conversa pelo menos uma vez: alguém nas instalações ou na equipa de experiência do paciente quer implementar Wi-Fi de convidados em todo o hospital, e alguém na sua equipa jurídica ou de conformidade pergunta imediatamente — isso interfere com a HIPAA? A resposta curta é: depende. E essa dependência é exatamente o que vamos abordar hoje. Vou guiá-lo pelas principais questões de conformidade, pela arquitetura técnica que precisa de estruturar corretamente e pelas etapas práticas de implementação que lhe permitirão oferecer uma excelente experiência de Wi-Fi de convidados sem criar uma responsabilidade regulamentar. Isto não é teoria — é a mesma estrutura pela qual orientamos os nossos clientes de cuidados de saúde quando estão a planear uma implementação. Comecemos pela questão fundamental. O Wi-Fi de convidados enquadra-se na HIPAA? A Regra de Segurança da HIPAA aplica-se a informações eletrónicas de saúde protegidas — o que a regulamentação designa por ePHI. O gatilho crítico é se a infraestrutura da sua rede armazena, processa ou transmite ePHI. Uma rede Wi-Fi de convidados pura — que oferece aos pacientes e visitantes acesso à internet e nada mais — não interfere inerentemente com a ePHI. Os pacientes que navegam na web, transmitem vídeo ou verificam o e-mail na sua rede de convidados não estão a gerar ePHI através dessa ligação. No entanto, no momento em que a sua rede de convidados partilha qualquer infraestrutura com sistemas que processam ePHI — o seu EHR, o seu sistema de imagiologia PACS, a sua plataforma de comunicação clínica — o cenário muda por completo. E é aqui que a maioria das organizações de saúde se depara com problemas. Não porque tenham ligado as duas intencionalmente, mas porque implementaram o Wi-Fi de convidados em hardware partilhado, ou usaram a mesma VLAN, ou falharam na implementação de regras de firewall adequadas entre segmentos. Portanto, o primeiro princípio é este: a questão da conformidade não diz respeito ao Wi-Fi de convidados em si. Diz respeito ao que esse Wi-Fi de convidados consegue alcançar. Agora vamos falar de arquitetura. O padrão de excelência para o Wi-Fi de convidados na área da saúde é o que chamamos de modelo de segmentação em três zonas. A zona um é a sua rede de convidados. É aqui que os dispositivos dos pacientes e visitantes se ligam. Tem acesso à internet e nada mais. Sem rota para os sistemas internos. Sem acesso a VLANs clínicas. O tráfego desta zona sai através do seu gateway de internet e para mais lado nenhum. A zona dois é a sua DMZ, ou camada de isolamento. É aqui que se encontra o seu Captive Portal, os seus sistemas de autenticação e qualquer recolha de dados de convidados. Se estiver a executar uma plataforma de análise de Wi-Fi — capturando dados de ligação, tempo de permanência, frequência de visitas — essa infraestrutura reside aqui, isolada tanto da rede de convidados como da rede clínica.A zona três é a sua rede clínica. Servidores EHR, dispositivos médicos, PACS, sistemas de chamada de enfermeiros, bombas de infusão — tudo o que toca nos cuidados ao paciente. Esta zona está completamente isolada (air-gapped) das zonas um e dois ao nível da rede. Sem encaminhamento entre elas. Regras de firewall com uma postura de negação por defeito (default-deny). Qualquer tráfego que precise de cruzar zonas passa por caminhos explícitos, registados e auditados. A implementação técnica disto utiliza uma combinação de VLANs, ACLs de firewall e — idealmente — autenticação baseada em porta 802.1X na sua rede clínica para garantir que apenas dispositivos autorizados se possam ligar. Para a rede de convidados, o WPA3 Personal ou uma rede aberta com um Captive Portal é o padrão. O WPA3 é fortemente preferido porque fornece encriptação de dados individualizada mesmo em redes abertas, o que protege o tráfego de convidados contra escutas. Agora, uma palavra sobre o próprio Captive Portal. É aqui que muitas organizações de saúde criam inadvertidamente uma exposição ao HIPAA. Se o seu Captive Portal solicitar aos utilizadores que introduzam o seu nome, endereço de e-mail ou data de nascimento — e se algum desses utilizadores for um paciente — passa a ter um conjunto de dados que pode potencialmente ser associado a um encontro de cuidados de saúde. Essa ligação é o que cria ePHI. A mitigação prática aqui é usar uma abordagem de recolha mínima de dados — apenas endereço MAC e carimbo de data/hora de ligação — ou garantir que a sua recolha de dados é genuinamente anonimizada e não pode ser associada ao registo de cuidados de um indivíduo específico. Se recolher dados identificáveis, precisa de avaliar se o seu fornecedor de WiFi está a agir como um Business Associate sob o HIPAA e, em caso afirmativo, precisa de um Business Associate Agreement (BAA) em vigor antes de entrar em funcionamento. Deixe-me dedicar um momento à questão do BAA porque ela confunde muitas equipas. Um Business Associate é qualquer fornecedor que crie, receba, mantenha ou transmita ePHI em seu nome. A palavra-chave é "em seu nome". Se a plataforma do seu fornecedor de WiFi armazena registos de ligação que incluem nomes e endereços de e-mail de pessoas que foram pacientes nas suas instalações, e esses registos são mantidos na infraestrutura de nuvem do fornecedor, esse fornecedor é provavelmente um Business Associate. Precisa de um BAA. Se a sua plataforma WiFi recolher apenas dados anonimizados e não associáveis — identificadores de dispositivos que não podem ser vinculados a um indivíduo, contagens agregadas de tráfego pedonal, duração da sessão sem identidade — então a exigência de BAA é muito menos clara. Mas deve, ainda assim, documentar o seu raciocínio. Os auditores querem ver que tomou uma decisão deliberada e informada, e não que simplesmente não pensou no assunto. O modelo de decisão que utilizo com os clientes consiste em três perguntas. Uma: a plataforma WiFi recolhe quaisquer dados que possam identificar um indivíduo? Duas: esse indivíduo pode ser um paciente nas suas instalações? Três: o fornecedor armazena ou processa esses dados na sua infraestrutura? Se a resposta a todas as três for sim, precisa de um BAA. Se qualquer resposta for não, documente o motivo e prossiga. Agora vamos falar sobre os requisitos de registo de dados (logging), porque esta é a outra área onde as implementações de WiFi na área da saúde falham frequentemente. A Regra de Segurança da HIPAA exige que as entidades abrangidas implementem controlos de auditoria — hardware, software e mecanismos procedimentais que registem e examinem a atividade nos sistemas que contêm ou utilizam ePHI. Para a sua rede de convidados, se esta não interagir com ePHI, o requisito de registo de dados da HIPAA não se aplica diretamente. Mas existem duas razões pelas quais deve registar os dados de qualquer forma. Primeiro, precisa de ser capaz de demonstrar, no caso de uma auditoria ou incidente, que a sua rede de convidados estava devidamente isolada e que nenhum ePHI passou por ela. Sem registos, não o consegue provar. Segundo, a NIST e as boas práticas de segurança geral exigem o registo de toda a atividade de rede para fins de resposta a incidentes, independentemente da aplicabilidade da HIPAA. No mínimo, o registo de dados do seu WiFi de convidados deve capturar: carimbos de data/hora de ligação, endereços MAC dos dispositivos, eventos de autenticação, atribuições de DHCP e quaisquer eventos de recusa de firewall na fronteira entre a zona de convidados e as zonas clínicas. Guarde estes registos por um período mínimo de seis anos, o que se alinha com os requisitos de retenção de registos da HIPAA. Armazene-os num sistema inviolável e com controlo de acessos. Deixe-me apresentar dois cenários reais de implementação para tornar isto prático. Cenário um: um hospital regional com 400 camas que implementa WiFi de convidados nas alas de pacientes, áreas de espera e uma cafetaria. A equipa de rede utiliza switches Cisco Catalyst com marcação de VLAN para criar três redes lógicas separadas: convidados, funcionários e clínica. A VLAN de convidados é terminada numa saída de internet dedicada, sem encaminhamento para o núcleo interno. Um Captive Portal recolhe apenas o endereço de e-mail para aceitação dos termos, e a plataforma de análise de WiFi está configurada para agregar apenas dados de fluxo de visitas — sem perfis individuais. O fornecedor fornece um BAA que cobre os dados de endereço de e-mail. Os registos de firewall são encaminhados para o SIEM do hospital e guardados por sete anos. Resultado: auditoria da HIPAA limpa, WiFi de convidados ativo em oito semanas. Cenário dois: um grupo de saúde multi-site — doze clínicas de ambulatório — que pretende uma experiência unificada de WiFi de convidados com uma imagem de marca consistente e análises centralizadas. O desafio aqui é que cada clínica tem uma infraestrutura de rede subjacente diferente. A solução é uma plataforma de WiFi gerida na nuvem com configuração de VLAN por site, todas terminando num controlador de nuvem partilhado. As redes clínicas de cada site permanecem inteiramente locais (on-premises) e nunca são ligadas ao plano de gestão na nuvem. A recolha de dados de convidados limita-se a identificadores de dispositivos anonimizados e metadados de sessão. Não é necessário BAA porque não são recolhidos dados identificáveis. A equipa de conformidade documenta esta decisão no registo de riscos da organização. Implementação concluída nos doze sites em doze semanas. Ambos os cenários partilham o mesmo princípio subjacente: a rede de convidados é concebida de raiz para não ter qualquer ligação aos sistemas clínicos, e a recolha de dados limita-se ao mínimo necessário. Agora deixe-me apresentar-lhe os modos de falha comuns — as coisas que correm mal e como evitá-las. Modo de falha um: pontos de acesso partilhados. Muitas instalações de saúde mais antigas têm pontos de acesso que servem múltiplos SSIDs no mesmo hardware. Se esses pontos de acesso não estiverem corretamente configurados com VLAN tagging e regras de firewall, o tráfego do SSID de convidados pode potencialmente alcançar a VLAN clínica. A solução é auditar cada ponto de acesso e verificar a separação de VLAN ao nível do hardware, e não apenas no controlador. Modo de falha dois: a rede de convidados "temporária". Alguém nas instalações configura um router de consumo para o WiFi de uma sala de espera, ligado diretamente ao comutador de rede principal. Isto é surpreendentemente comum e cria uma lacuna imediata de conformidade. A solução é um processo formal de gestão de alterações que exige que qualquer novo dispositivo de rede passe por uma revisão de TI antes da implementação. Modo de falha três: o desvio de retenção de dados do fornecedor. Subscreve uma plataforma de análise de WiFi, configura-a para uma recolha mínima de dados e, seis meses mais tarde, alguém ativa uma nova funcionalidade que começa a recolher perfis de utilizador mais ricos. Sem um processo de revisão regular, isto pode passar despercebido. A solução é incluir a configuração da plataforma de WiFi na sua avaliação anual de risco HIPAA e rever as notas de lançamento do fornecedor para quaisquer alterações ao processamento de dados. Modo de falha quatro: ausência de um BAA em vigor. Assumiu que o seu fornecedor de WiFi não precisava de um, mas eles estão a armazenar registos de ligação com endereços de e-mail na sua cloud. Isto é uma violação passível de notificação prestes a acontecer. A solução é voltar ao seu fornecedor, rever o acordo de processamento de dados e assinar um BAA se for necessário. Deixe-me encerrar com as perguntas rápidas que recebo com mais frequência. Os doentes podem utilizar o WiFi de convidados para aceder ao seu portal do doente? Sim, mas essa é uma sessão segura do próprio doente — a rede WiFi em si não precisa de processar ePHI para suportar este caso de utilização. O WPA3 torna-nos conformes com a HIPAA? Não. O WPA3 é um bom controlo de segurança, mas a conformidade com a HIPAA diz respeito a toda a arquitetura — segmentação, registo de dados, processamento de dados, BAAs — e não apenas ao protocolo de encriptação. Precisamos de encriptar o tráfego do WiFi de convidados? O WPA3 fornece encriptação por sessão. Se estiver a disponibilizar uma rede aberta com um Captive Portal, considere implementar um requisito de VPN ou, no mínimo, a aplicação de HTTPS para todas as páginas de recolha de dados. E quanto aos dispositivos médicos IoT em WiFi? Esses nunca devem estar na rede de convidados. Pertencem a uma VLAN IoT dedicada dentro da zona clínica, com os seus próprios controlos de segurança. Em resumo: o WiFi de convidados nos cuidados de saúde é absolutamente viável de uma forma conforme com a HIPAA. A arquitetura é bem compreendida. As decisões fundamentais são: segmentação de rede adequada sem encaminhamento entre as zonas de convidados e clínicas; uma abordagem de minimização de dados relativamente ao que o seu Captive Portal recolhe; uma decisão clara sobre o BAA documentada e executada onde necessário; e uma estratégia de registo e retenção de dados que apoie a auditoria e a resposta a incidentes. As organizações que acertam nesta abordagem tratam o WiFi de convidados como um projeto de infraestrutura com uma componente de conformidade, e não como um problema de conformidade que por acaso envolve WiFi. Acerte na arquitetura primeiro, e a conformidade surgirá naturalmente. Se gostaria de explorar como a plataforma de WiFi de convidados da Purple é implementada em ambientes de cuidados de saúde — incluindo a nossa abordagem à minimização de dados e Acordos de Parceiro Comercial (Business Associate Agreements) — visite purple.ai ou fale com um dos nossos arquitetos de soluções. Obrigado por ouvir.