Hospital Guest WiFi: Experiência do Doente e Separação de Redes

WiFi de Clientes em Hospitais: Experiência do Paciente e Separação de Rede Uma Sessão Técnica da Purple - aproximadamente 10 minutos [INTRODUÇÃO - aproximadamente 1 minuto] Bem-vindo à série de Sessões Técnicas da Purple. Eu sou o seu anfitrião e hoje vamos abordar uma das implementações de WiFi operacionalmente mais sensíveis que encontrará nas redes empresariais: o WiFi de clientes em hospitais. Se é um gestor de TI clínica, um CIO hospitalar 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 Netflix. Este é um ambiente onde uma VLAN mal configurada poderia, teoricamente, colocar os sistemas clínicos - plataformas EHR, bombas de infusão, equipamentos de imagiologia - 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 infrações regulamentares a incidentes de segurança do paciente. Por isso, hoje vamos abordar três coisas: como estruturar uma separação completa entre as redes clínicas e de clientes, como proporcionar uma experiência de WiFi genuinamente boa para pacientes e visitantes, e como medir se está a funcionar. Vamos a isso. [ANÁLISE TÉCNICA DETALHADA - aproximadamente 5 minutos] Vamos começar com a arquitetura. O princípio fundamental do design de WiFi hospitalar é que o tráfego clínico e o de clientes 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 alinha-se com os requisitos de salvaguarda técnica da HIPAA nos Estados Unidos. A abordagem padrão é a segmentação por VLAN. Atribui 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 imagiologia PACS. Uma segunda VLAN - VLAN 20 - transporta todo o tráfego de WiFi de clientes 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 entre VLANs é completamente bloqueado ou muito 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 é. Precisa de 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 SSID duplo - transmitindo tanto um SSID clínico como um SSID de clientes - esses SSIDs devem ser mapeados para VLANs separadas, sem qualquer ponte entre eles. O seu controlador de rede sem fios deve ser configurado para impedir a comunicação de cliente para cliente na VLAN de clientes, 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, embora estejam no mesmo SSID de clientes. A autenticação é a camada seguinte. Na rede clínica, pretende-se o IEEE 802.1X com EAP-TLS ou PEAP-MSCHAPv2, apoiado 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. Nada de 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 precisa de ser simples. Um Captive Portal com aceitação num clique ou uma verificação simples por SMS é apropriado 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 é usar WPA3-SAE no SSID de convidados para garantir a encriptação over-the-air sem exigir credenciais por utilizador. O WPA3-SAE elimina a vulnerabilidade da chave pré-partilhada ao utilizar uma troca de prova de conhecimento zero, de modo que mesmo que alguém capture o handshake, não consiga decifrar a palavra-passe offline por força bruta. Agora vamos falar de largura de banda. É aqui que muitas equipas de TI dos hospitais subestimam o requisito. Um único doente numa cama hoje em dia pode ter um smartphone, um tablet e uma smart TV ou unidade de entretenimento à 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 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 mínimo de vinte e cinco megabits por segundo de débito disponível - e isto antes de contabilizar os fatores de simultaneidade. Num hospital de duzentas camas onde sessenta por cento dos doentes estão a utilizar ativamente o WiFi em horas de ponta - digamos, às sete da tarde - estamos a olhar para 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 prática que utilizo é: um ponto de acesso por enfermaria, não um por hospital. Numa enfermaria de seis camas, quer 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 lidar com dispositivos IoT legados e telemóveis mais antigos. O planeamento de canais é de enorme importância num hospital. Existem ambientes RF densos - paredes de betão espessas, estruturas de cama 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 sobrepõem das bandas UNII-1 e UNII-3. Defina a potência de transmissão de forma conservadora - quer que as células se sobreponham em cerca de quinze a vinte por cento, não cinquenta por cento. Os APs com excesso de potência causam interferência de canal partilhado e, na verdade, degradam o débito. Para a rede clínica, as considerações de design 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 telemetria em tempo real de monitores de pacientes e a leitura de códigos de barras na distribuição de medicamentos exigem uma latência baixa e um sinal consistente. Defina como meta menos sessenta e cinco dBm de RSSI em cada ponto de extremidade 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] Permita-me apresentar os três principais erros de implementação que observo em projetos de WiFi hospitalar. Primeiro: assumir que a configuração da sua VLAN está correta sem a testar. Já vi implementações em que uma porta de trunk incorretamente configurada permitiu que o tráfego da VLAN de convidados se infiltrasse na 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 dispositivo convidado. Se conseguir efetuar um ping para qualquer endereço 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 expire a sessão, que não seja renderizado em dispositivos móveis ou que exija 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 personalizado com a sua 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 a ligação ascendente e degradar a experiência de todos os outros. Implemente a limitação de largura de banda por dispositivo - normalmente de 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 abordar algumas perguntas rápidas que me são colocadas regularmente. "Podemos usar os mesmos pontos de acesso físicos para a rede clínica e de convidados?" Sim, absolutamente - os APs com dual-SSID são uma prática standard. 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 marcação de VLAN e que o seu WLC impõe a separação. "Precisamos de uma ligação ascendente de internet separada 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 dos convidados. Uma ligação ascendente dedicada para convidados é uma abordagem de prevenção adicional, se o orçamento o permitir."Como lidamos com dispositivos IoT médicos em WiFi?" Os dispositivos IoT médicos - bombas de infusão, monitores de telemetria - devem estar numa terceira VLAN dedicada, separados tanto das estações de trabalho clínicas como dos dispositivos de convidados. Isto limita o raio de impacto se um dispositivo for comprometido. "E quanto ao GDPR e aos dados recolhidos através do captive portal?" Quaisquer dados pessoais recolhidos no início de sessão - e-mail, número de telefone - devem ser processados sob uma base jurídica lícita, 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 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 doente, 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 em clínica, WPA3 em 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 levantamento de site sem fios 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 de doentes 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 Healthcare da Purple - esta associa-se ao respetivo guia de conformidade HIPAA para lhe dar uma visão completa do panorama regulamentar. Obrigado por nos 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 de acompanhamento no website da Purple.