WiFi para Visitantes em Conformidade com a HIPAA para Provedores de Saúde

WiFi para Visitantes em Conformidade com a HIPAA para Provedores de Saúde. Um Informativo Técnico da Purple. Bem-vindo. Se você é um diretor de TI de saúde, gerente de rede de hospital ou oficial de conformidade, provavelmente já teve esta conversa pelo menos uma vez: alguém na área de instalações ou de experiência do paciente quer implantar WiFi para visitantes em todo o hospital, e alguém da sua equipe jurídica ou de conformidade pergunta imediatamente — isso afeta a HIPAA? A resposta curta é: depende. E essa dependência é exatamente o que vamos abordar hoje. Vou orientá-lo pelas principais questões de conformidade, pela arquitetura técnica que você precisa acertar e pelas etapas práticas de implantação que permitirão oferecer uma excelente experiência de WiFi para visitantes sem criar uma responsabilidade regulatória. Isso não é teoria — é a mesma estrutura que apresentamos aos clientes de saúde quando eles estão definindo o escopo de uma implantação. Vamos começar com a pergunta fundamental. O WiFi para visitantes se enquadra na HIPAA? A Regra de Segurança da HIPAA se aplica a informações eletrônicas de saúde protegidas — o que a regulamentação chama de ePHI. O gatilho crítico é se a sua infraestrutura de rede armazena, processa ou transmite ePHI. Uma rede WiFi para visitantes pura — que oferece aos pacientes e visitantes acesso à internet e nada mais — não toca inerentemente no ePHI. Pacientes navegando na web, transmitindo vídeos ou verificando e-mails em sua rede de visitantes não estão gerando ePHI por meio dessa conexão. No entanto, no momento em que sua rede de visitantes compartilha qualquer infraestrutura com sistemas que lidam com ePHI — seu prontuário eletrônico, seu sistema de imagem PACS, sua plataforma de comunicação clínica — o cenário muda completamente. E é aqui que a maioria das organizações de saúde se depara com problemas. Não porque conectaram as duas intencionalmente, mas porque implantaram o WiFi para visitantes em hardware compartilhado, ou usaram a mesma VLAN, ou falharam em implementar regras de firewall adequadas entre os segmentos. Portanto, o primeiro princípio é este: a questão da conformidade não é sobre o WiFi para visitantes em si. É sobre o que esse WiFi para visitantes pode alcançar. Agora vamos falar sobre arquitetura. O padrão-ouro para WiFi de visitantes na área da saúde é o que chamamos de modelo de segmentação de três zonas. A zona um é a sua rede de visitantes. É aqui que os dispositivos de pacientes e visitantes se conectam. Ela tem acesso à internet, nada mais. Sem rota para sistemas internos. Sem acesso a VLANs clínicas. O tráfego desta zona sai pelo seu gateway de internet e por nenhum outro lugar. A zona dois é a sua DMZ, ou camada de isolamento. É aqui que ficam o seu Captive Portal, seus sistemas de autenticação e qualquer coleta de dados de visitantes. Se você estiver executando uma plataforma de WiFi analytics — capturando dados de conexão, tempo de permanência, frequência de visitas — essa infraestrutura vive aqui, isolada tanto da rede de visitantes quanto da rede clínica. A zona três é a sua rede clínica. Servidores de prontuário eletrônico, dispositivos médicos, PACS, sistemas de chamada de enfermagem, bombas de infusão — qualquer coisa que toque no cuidado ao paciente. Esta zona é completamente isolada das zonas um e duas no nível da rede. Sem roteamento entre elas. Regras de firewall com uma postura de negação por padrão. Qualquer tráfego que precise cruzar as zonas passa por caminhos explícitos, registrados e auditados. A implementação técnica disso usa uma combinação de VLANs, ACLs de firewall e — idealmente — autenticação baseada em porta 802.1X em sua rede clínica para garantir que apenas dispositivos autorizados possam se conectar. Para a rede de visitantes, o WPA3 Personal ou uma rede aberta com um Captive Portal é o padrão. O WPA3 é fortemente preferido porque fornece criptografia de dados individualizada mesmo em redes abertas, o que protege o tráfego dos visitantes contra interceptações. Agora, uma palavra sobre o Captive Portal em si. É aqui que muitas organizações de saúde criam inadvertidamente uma exposição à HIPAA. Se o seu Captive Portal solicitar que os usuários insiram seu nome, endereço de e-mail ou data de nascimento — e se algum desses usuários for um paciente — você agora tem um conjunto de dados que poderia potencialmente ser vinculado a um atendimento de saúde. Essa vinculação é o que cria o ePHI. A mitigação prática aqui é usar uma abordagem de coleta de dados mínima — apenas endereço MAC e carimbo de data/hora da conexão — ou garantir que a coleta de dados seja genuinamente anonimizada e não possa ser vinculada ao registro de atendimento de um indivíduo específico. Se você coletar dados identificáveis, precisará avaliar se o seu fornecedor de WiFi está agindo como um Business Associate sob a HIPAA e, em caso afirmativo, precisará de um Business Associate Agreement em vigor antes de entrar em operação. Deixe-me passar um momento sobre a questão do BAA porque ela confunde muitas equipes. Um Business Associate é qualquer fornecedor que cria, recebe, mantém ou transmite ePHI em seu nome. A palavra-chave é "em seu nome". Se a plataforma do seu fornecedor de WiFi armazena logs de conexão que incluem nomes e endereços de e-mail de pessoas que foram pacientes em sua instalação, e esses logs são mantidos na infraestrutura de nuvem do fornecedor, esse fornecedor provavelmente é um Business Associate. Você precisa de um BAA. Se a sua plataforma de WiFi coleta apenas dados anonimizados e não vinculáveis — identificadores de dispositivos que não podem ser associados a um indivíduo, contagens agregadas de fluxo de pessoas, duração da sessão sem identidade — então o requisito de BAA é muito menos claro. Mas você ainda deve documentar sua linha de raciocínio. Os auditores querem ver que você tomou uma decisão deliberada e informada, e não que apenas não pensou sobre o assunto. A estrutura de decisão que utilizo com os clientes consiste em três perguntas. Primeira: a plataforma de WiFi coleta algum dado que possa identificar um indivíduo? Segunda: esse indivíduo poderia ser um paciente em sua instalação? Terceira: o fornecedor armazena ou processa esses dados em sua infraestrutura? Se a resposta para as três for sim, você precisa de um BAA. Se qualquer resposta for não, documente o motivo e prossiga. Agora vamos falar sobre os requisitos de registro de logs, porque esta é outra área onde as implantações de WiFi na área da saúde frequentemente falham. A Regra de Segurança da HIPAA exige que as entidades cobertas implementem controles de auditoria — mecanismos de hardware, software e procedimentais que registram e examinam a atividade em sistemas que contêm ou usam ePHI. Para a sua rede de visitantes, se ela não toca no ePHI, o requisito de registro de logs da HIPAA não se aplica diretamente. Mas existem duas razões pelas quais você deve registrar logs de qualquer maneira. Primeiro, você precisa ser capaz de demonstrar, no caso de uma auditoria ou incidente, que sua rede de visitantes estava devidamente isolada e que nenhum ePHI passou por ela. Sem logs, você não pode provar isso. Segundo, o NIST e as melhores práticas gerais de segurança exigem o registro de logs de toda a atividade de rede para fins de resposta a incidentes, independentemente da aplicabilidade da HIPAA. No mínimo, o registro de logs do seu WiFi de visitantes deve capturar: carimbos de data/hora de conexão, endereços MAC dos dispositivos, eventos de autenticação, atribuições de DHCP e quaisquer eventos de negação de firewall na fronteira entre as zonas de visitantes e clínicas. Retenha esses logs por um período mínimo de seis anos, o que se alinha com os requisitos de retenção de registros da HIPAA. Armazene-os em um sistema controlado por acesso e à prova de adulterações. Deixe-me apresentar dois cenários reais de implementação para tornar isso concreto. Cenário um: um hospital regional de 400 leitos implantando WiFi para visitantes em enfermarias, áreas de espera e um café. A equipe de rede usa switches Cisco Catalyst com marcação de VLAN para criar três redes lógicas separadas: visitante, funcionários e clínica. A VLAN de visitantes é terminada em uma saída de internet dedicada, sem roteamento para o núcleo interno. Um Captive Portal coleta apenas o endereço de e-mail para aceitação dos termos, e a plataforma de WiFi analytics é dimensionada para agregar apenas dados de fluxo de pessoas — sem perfis individuais. O fornecedor fornece um BAA cobrindo os dados de endereço de e-mail. Os logs do firewall são encaminhados para o SIEM do hospital e retidos por sete anos. Resultado: auditoria da HIPAA limpa, WiFi para visitantes ativo em oito semanas. Cenário dois: um grupo de saúde multi-site — doze clínicas ambulatoriais — que deseja uma experiência unificada de WiFi para visitantes com branding consistente e analytics centralizado. O desafio aqui é que cada clínica possui uma infraestrutura de rede subjacente diferente. A solução é uma plataforma de WiFi gerenciada na nuvem com configuração de VLAN por site, todas terminando em um controlador de nuvem compartilhado. As redes clínicas de cada site permanecem totalmente locais e nunca são conectadas ao plano de gerenciamento de nuvem. A coleta de dados de visitantes é limitada a identificadores de dispositivos anonimizados e metadados de sessão. Nenhum BAA é necessário porque nenhum dado identificável é coletado. A equipe de conformidade documenta essa decisão no registro de riscos da organização. Implantação concluída em todas as doze unidades em doze semanas. Ambos os cenários compartilham o mesmo princípio subjacente: a rede de visitantes é projetada desde o início para não ter caminho para os sistemas clínicos, e a coleta de dados é limitada ao mínimo necessário. Agora, deixe-me apresentar os modos de falha comuns — as coisas que dão errado e como evitá-las. Modo de falha um: pontos de acesso compartilhados. Muitas instalações de saúde mais antigas possuem pontos de acesso que atendem a múltiplos SSIDs no mesmo hardware. Se esses pontos de acesso não estiverem configurados corretamente com marcação de VLAN e regras de firewall, o tráfego do SSID de visitantes pode potencialmente alcançar la VLAN clínica. A correção é auditar cada ponto de acesso e verificar a separação de VLAN no nível do hardware, não apenas no controlador. Modo de falha dois: a rede de visitantes "temporária". Alguém na área de instalações configura um roteador de nível doméstico para o WiFi de uma sala de espera, conectado diretamente ao switch de rede principal. Isso é surpreendentemente comum e cria uma lacuna imediata de conformidade. A correção é um processo formal de gestão de mudanças que exige que qualquer novo dispositivo de rede passe por revisão de TI antes da implantação. Modo de falha três: desvio de retenção de dados do fornecedor. Você contrata uma plataforma de WiFi analytics, configura-a para coleta mínima de dados e, seis meses depois, alguém ativa um novo recurso que começa a coletar perfis de usuário mais ricos. Sem um processo de revisão regular, isso pode passar despercebido. A correção é incluir a configuração da plataforma de WiFi em sua avaliação anual de risco da HIPAA e revisar as notas de lançamento do fornecedor para quaisquer alterações no manuseio de dados. Modo de falha quatro: nenhum BAA em vigor. Você assumiu que seu fornecedor de WiFi não precisava de um, mas eles estão armazenando logs de conexão com endereços de e-mail em sua nuvem. Esta é uma violação notificável prestes a acontecer. A correção é voltar ao seu fornecedor, revisar o contrato de processamento de dados deles e executar um BAA, se necessário. Deixe-me encerrar com as perguntas rápidas que recebo com mais frequência. Os pacientes podem usar o WiFi de visitantes para acessar seu portal do paciente? Sim, mas essa é uma sessão segura do próprio paciente — a rede WiFi em si não precisa lidar com ePHI para suportar esse caso de uso. O WPA3 nos torna em conformidade com a HIPAA? Não. O WPA3 é um bom controle de segurança, mas a conformidade com a HIPAA diz respeito a toda a arquitetura — segmentação, registro de logs, manuseio de dados, BAAs — e não apenas ao protocolo de criptografia. Precisamos criptografar o tráfego de WiFi dos visitantes? O WPA3 fornece criptografia por sessão. Se você estiver executando uma rede aberta com um Captive Portal, considere implementar uma exigência de VPN ou, no mínimo, a aplicação de HTTPS para quaisquer páginas de coleta de dados. E quanto aos dispositivos médicos IoT no WiFi? Eles nunca devem estar na rede de visitantes. Eles pertencem a uma VLAN IoT dedicada dentro da zona clínica, com seus próprios controles de segurança. Para resumir: o WiFi para visitantes na área da saúde é absolutamente realizável de forma compatível com a HIPAA. A arquitetura é bem compreendida. As principais decisões são: segmentação de rede adequada sem roteamento entre as zonas de visitantes e clínicas; uma abordagem de minimização de dados para o que seu Captive Portal coleta; uma decisão clara de BAA documentada e executada onde necessário; e uma estratégia de registro de logs e retenção que apoie a auditoria e a resposta a incidentes. As organizações que acertam nisso tratam o WiFi para visitantes como um projeto de infraestrutura com um componente de conformidade, e não como um problema de conformidade que por acaso envolve WiFi. Acerte na arquitetura primeiro, e a conformidade virá naturalmente. Se você quiser explorar como a plataforma de WiFi para visitantes da Purple é implantada em ambientes de saúde — incluindo nossa abordagem para minimização de dados e Business Associate Agreements — visite purple.ai ou fale com um de nossos arquitetos de soluções. Obrigado por ouvir.