Hospital Guest WiFi: Patient Experience and Network Separation

WiFi para Hóspedes de Hospitais: Experiência do Paciente e Separação de Rede Um Briefing Técnico da Purple — aproximadamente 10 minutos [INTRODUÇÃO — aproximadamente 1 minuto] Bem-vindo à série de Briefings Técnicos da Purple. Sou o vosso anfitrião e hoje vamos abordar uma das implementações de WiFi mais sensíveis a nível operacional que irá encontrar nas redes empresariais: o WiFi para hóspedes de hospitais. Se é um gestor de TI clínico, um CIO de um hospital ou um engenheiro de redes de saúde, já sabe que o que está em jogo aqui é diferente de qualquer outro local. Isto não é um hotel onde um hóspede não consegue transmitir a Netflix. Este é um ambiente onde uma VLAN mal configurada poderia, teoricamente, colocar sistemas clínicos — plataformas EHR, bombas de infusão, equipamentos de imagem — no mesmo domínio de difusão que o smartphone de um paciente. Isso não é um risco teórico. Já aconteceu. E as consequências variam desde a violação regulamentar até incidentes de segurança do paciente. Por isso, hoje vamos abordar três coisas: como estruturar a separação total entre as redes clínica e de hóspedes, como proporcionar uma experiência de WiFi genuinamente boa para pacientes e visitantes, e como medir se está a funcionar. Vamos a isso. [APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos] Comecemos pela arquitetura. O princípio fundamental do design de WiFi hospitalar é que o tráfego clínico e o de hóspedes nunca devem partilhar um domínio de difusão de Camada 2. Ponto final. Isto é não negociável ao abrigo do Data Security and Protection Toolkit do NHS Digital e está alinhado com os requisitos de salvaguarda técnica da HIPAA nos Estados Unidos. A abordagem padrão é a segmentação por VLAN. Atribui-se uma VLAN dedicada — chamemos-lhe VLAN 10 — aos sistemas clínicos: estações de trabalho EHR, sistemas de chamada de enfermeiros, dispositivos IoT médicos, servidores de imagem PACS. Uma segunda VLAN — VLAN 20 — transporta todo o tráfego de WiFi de hóspedes e pacientes. Estas VLANs são agregadas (trunked) através da sua infraestrutura de comutação e terminadas numa firewall de próxima geração, onde o encaminhamento inter-VLAN é totalmente bloqueado ou rigidamente controlado com regras de permissão explícitas. Agora, é aqui que muitas implementações falham. As equipas assumem que a separação por VLAN na camada de comutação é suficiente. Não é. É necessário aplicar isto a três níveis: na camada de acesso, na camada de distribuição e na firewall. Se os seus pontos de acesso forem de duplo SSID — transmitindo tanto um SSID clínico como um SSID de hóspedes —, esses SSIDs devem mapear para VLANs separadas, sem qualquer ponte entre eles. O seu controlador de LAN sem fios deve ser configurado para impedir a comunicação de cliente para cliente na VLAN de hóspedes, e deve ativar o isolamento de AP por predefinição. Isso significa que um paciente na cama sete não pode sondar o dispositivo na cama oito, mesmo estando no mesmo SSID de hóspedes. A autenticação é a camada seguinte. Na rede clínica, pretende-se IEEE 802.1X com EAP-TLS ou PEAP-MSCHAPv2, suportado por um servidor RADIUS — Microsoft NPS, FreeRADIUS ou um serviço RADIUS baseado na nuvem. Cada dispositivo clínico deve ter um certificado ou uma credencial de domínio. Sem PSK nas redes clínicas. Nunca. As chaves pré-partilhadas são um ponto único de falha — uma credencial comprometida e todos os dispositivos nesse SSID ficam expostos. Para a rede de convidados, o modelo é diferente. Estamos a lidar com doentes que podem ser idosos, estar doentes ou não ter confiança técnica. A experiência de autenticação tem de ser simples. Um Captive Portal com aceitação num clique ou uma verificação simples por SMS é adequado aqui. Não vai pedir a um doente a recuperar de uma cirurgia para configurar o 802.1X no seu dispositivo pessoal. O que pode fazer é utilizar WPA3-SAE no SSID de convidados para garantir a encriptação over-the-air sem exigir credenciais por utilizador. O WPA3 Simultaneous Authentication of Equals elimina a vulnerabilidade da chave pré-partilhada ao utilizar uma troca de prova de conhecimento zero, pelo que, mesmo que alguém capture o handshake, não conseguirá decifrar a frase de acesso offline por força bruta. Agora vamos falar sobre a largura de banda. É aqui que muitas equipas de TI dos hospitais subestimam os requisitos. Um único doente numa cama hoje em dia pode ter um smartphone, um tablet e uma smart TV ou unidade de entretenimento de cabeceira. Estão a transmitir Netflix ou BBC iPlayer, a fazer videochamadas para a família e, potencialmente, a utilizar um portal do doente do hospital. O Netflix HD requer cinco megabits por segundo. Uma transmissão em 4K requer vinte e cinco. Uma videochamada no FaceTime ou Teams requer entre um e três megabits por segundo em cada sentido. Portanto, por cama, deve planear um débito mínimo disponível de vinte e cinco megabits por segundo — e isto antes de contabilizar os fatores de concorrência. Num hospital de duzentas camas onde sessenta por cento dos doentes estão a utilizar ativamente o WiFi nas horas de ponta — por exemplo, às sete da tarde —, estamos a falar de três gigabits por segundo de procura agregada na rede de convidados. A sua capacidade de uplink e a densidade dos seus pontos de acesso precisam de ser dimensionadas em conformidade. A regra geral que utilizo é: um ponto de acesso por enfermaria, não um por ala. Numa enfermaria de seis camas, pretende-se um AP a menos de dez metros de cada cama, a operar na banda de cinco gigahertz para clientes sensíveis ao débito, com a banda de dois vírgula quatro gigahertz a gerir dispositivos IoT legados e telemóveis mais antigos. O planeamento de canais é extremamente importante num hospital. Existem ambientes de RF densos — paredes de betão espessas, estruturas de camas metálicas, equipamento médico a gerar interferências. Utilize uma ferramenta de levantamento de local sem fios antes da implementação, não depois. Planeie o seu padrão de reutilização de canais na banda de cinco gigahertz utilizando canais que não se sobreponham das bandas UNII-1 e UNII-3. Defina a potência de transmissão de forma conservadora — pretende-se que as células se sobreponham em cerca de quinze a vinte por cento, não cinquenta por cento. APs com potência excessiva causam interferência de canal partilhado e, na verdade, degradam o débito. Para a rede clínica, as considerações de design de RF são ainda mais críticas porque está a suportar aplicações em tempo real. O VoIP em sistemas de chamada de enfermeiros, a transmissão de telemetria a partir de monitores de pacientes e a leitura de códigos de barras na distribuição de medicamentos exigem baixa latência e um sinal consistente. Defina como objetivo menos sessenta e cinco dBm de RSSI em cada endpoint clínico, com uma relação sinal-ruído superior a vinte e cinco decibéis. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos] Deixe-me apresentar os três principais erros de implementação que vejo em projetos de WiFi hospitalar. Primeiro: assumir que a sua configuração de VLAN está correta sem a testar. Já vi implementações em que uma porta trunk mal configurada permitiu que o tráfego da VLAN de convidados passasse para a VLAN clínica. A forma de detetar isto é através de um teste de intrusão pós-implementação — especificamente, tentar aceder a endereços de sub-rede clínica a partir de um cliente convidado. Se conseguir fazer ping a qualquer elemento na gama clínica, a sua segmentação falhou. Este deve ser um critério de aprovação obrigatório antes da entrada em funcionamento. Segundo: negligenciar a experiência do Captive Portal. Os hospitais tratam frequentemente o portal de WiFi de convidados como algo secundário. Mas um portal mal concebido — que expira, não é renderizado em dispositivos móveis ou exige demasiados passos — afeta diretamente as pontuações de satisfação dos pacientes. Nos Estados Unidos, os resultados do inquérito HCAHPS incluem pontuações de comunicação e ambiente que são influenciadas pela qualidade do WiFi. No NHS, as respostas ao Friends and Family Test citam frequentemente o WiFi como um fator. Uma plataforma como a solução de Guest WiFi da Purple oferece-lhe um portal de marca, otimizado para dispositivos móveis e com análises integradas, para que não esteja apenas a fornecer conectividade — está a recolher dados sobre padrões de utilização que informam o planeamento de capacidade. Terceiro: não ter uma política de gestão de largura de banda. Sem QoS e limitação de largura de banda na rede de convidados, um único paciente a executar um cliente BitTorrent pode saturar o uplink e degradar a experiência de todos os outros. Implemente a limitação de largura de banda por cliente — normalmente cinco a dez megabits por segundo de download por dispositivo — e utilize a marcação DSCP para priorizar o tráfego de videochamadas em detrimento de downloads volumosos. Bloqueie protocolos peer-to-peer ao nível da firewall na VLAN de convidados. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me responder rapidamente a algumas perguntas que me fazem regularmente. "Podemos utilizar os mesmos pontos de acesso físicos para a rede clínica e de convidados?" Sim, absolutamente — APs com dual-SSID são uma prática padrão. A separação é lógica, ao nível da VLAN, e não física. Certifique-se apenas de que o firmware do seu AP suporta etiquetagem de VLAN e que o seu WLC impõe a separação. "Precisamos de um uplink de internet separado para o tráfego de convidados?" Não necessariamente, mas deve utilizar a modelação de tráfego para garantir que o tráfego de gestão clínica — atualizações de software, acesso remoto — nunca seja prejudicado pela utilização de convidados. Um uplink de convidados dedicado é uma abordagem de prevenção total se o orçamento o permitir. "Como lidamos com dispositivos IoT médicos no WiFi?" O IoT médico — bombas de infusão, monitores de telemetria — deve estar numa terceira VLAN dedicada, separada tanto das estações de trabalho clínicas como dos dispositivos de convidados. Isto limita o raio de impacto caso um dispositivo seja comprometido. "E em relação ao GDPR e aos dados recolhidos através do Captive Portal?" Quaisquer dados pessoais recolhidos no login — email, número de telefone — devem ser processados sob uma base legal, normalmente o consentimento. Garanta que os termos do seu portal são claros, que a sua política de retenção de dados está documentada e que tem um acordo de processamento de dados com o seu fornecedor de plataforma de WiFi. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para concluir: o WiFi para convidados de hospitais não é apenas um projeto de conectividade. É uma iniciativa de experiência do paciente, um requisito de conformidade e uma consideração de segurança clínica, tudo em um. A arquitetura é simples — segmentação de VLAN, 802.1X na rede clínica, WPA3 na rede de convidados, Captive Portal para acesso, QoS para gestão de largura de banda — mas a execução exige rigor em todas as camadas. Os seus próximos passos: encomende um estudo de cobertura wireless (site survey) se não realizou nenhum nos últimos dois anos. Reveja a sua configuração de VLAN e teste o isolamento inter-VLAN. Compare a sua satisfação atual com o WiFi dos pacientes com os dados do HCAHPS ou do Friends and Family Test. E se estiver a avaliar plataformas de WiFi para convidados, consulte a solução de Healthcare da Purple — esta combina com o guia de conformidade HIPAA para lhe dar uma visão completa do panorama regulamentar. Obrigado por ouvir. A documentação técnica completa, os diagramas de arquitetura e as listas de verificação de implementação estão disponíveis no guia que acompanha no website da Purple.