Hospital Guest WiFi: Patient Experience and Network Separation

Wi-Fi para Visitantes em 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 seu anfitrião e hoje vamos abordar uma das implantações de Wi-Fi mais sensíveis do ponto de vista operacional que você encontrará em redes corporativas: o Wi-Fi para visitantes em hospitais. Se você é um gerente de TI clínica, um CIO de hospital ou um engenheiro de rede de saúde, já sabe que os riscos aqui são diferentes de qualquer outro local. Este 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 de EHR, bombas de infusão, equipamentos de imagem — no mesmo domínio de broadcast que o smartphone de um paciente. Isso não é um risco teórico. Já aconteceu. E as consequências variam de violação regulatória a incidentes de segurança do paciente. Portanto, hoje vamos cobrir três coisas: como arquitetar a separação completa entre as redes clínica e de visitantes, como oferecer uma experiência de Wi-Fi genuinamente boa para pacientes e visitantes e como medir se ela está funcionando. Vamos começar. [APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos] Vamos começar com a arquitetura. O princípio fundamental do design de Wi-Fi hospitalar é que o tráfego clínico e o de visitantes nunca devem compartilhar um domínio de broadcast de Camada 2. Ponto final. Isso é inegociável sob o Data Security and Protection Toolkit do NHS Digital e se alinha com os requisitos de salvaguarda técnica da HIPAA nos Estados Unidos. A abordagem padrão é a segmentação por VLAN. Você atribui uma VLAN dedicada — vamos chamá-la de VLAN 10 — para os sistemas clínicos: estações de trabalho de EHR, sistemas de chamada de enfermagem, dispositivos IoT médicos, servidores de imagem PACS. Uma segunda VLAN — VLAN 20 — transporta todo o tráfego de Wi-Fi de visitantes e pacientes. Essas VLANs são interligadas por meio de sua infraestrutura de switching e terminadas em um firewall de próxima geração, onde o roteamento inter-VLAN é completamente bloqueado ou rigidamente controlado com regras de permissão explícitas. Agora, é aqui que muitas implantações dão errado. As equipes assumem que a separação de VLAN na camada de switch é suficiente. Não é. Você precisa impor isso em três níveis: na camada de acesso, na camada de distribuição e no firewall. Se os seus pontos de acesso forem dual-SSID — transmitindo tanto um SSID clínico quanto um SSID de visitante —, esses SSIDs devem ser mapeados para VLANs separadas, sem ponte entre eles. Seu controlador de LAN sem fio deve ser configurado para impedir a comunicação de cliente para cliente na VLAN de visitantes, e você deve habilitar o isolamento de AP por padrão. Isso significa que um paciente no leito sete não pode sondar o dispositivo no leito oito, mesmo que estejam no mesmo SSID de visitante. A autenticação é a próxima camada. Na rede clínica, você deseja IEEE 802.1X com EAP-TLS ou PEAP-MSCHAPv2, apoiado por um servidor RADIUS — Microsoft NPS, FreeRADIUS ou um serviço RADIUS baseado em nuvem. Cada dispositivo clínico deve ter um certificado ou uma credencial de domínio. Sem PSK em redes clínicas. Nunca. Chaves pré-compartilhadas 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. Você está lidando com pacientes que podem ser idosos, doentes ou sem confiança técnica. A experiência de autenticação precisa ser simples. Um Captive Portal com aceitação em um clique ou uma verificação simples por SMS é apropriado aqui. Você não vai pedir a um paciente em recuperação de cirurgia para configurar o 802.1X em seu dispositivo pessoal. O que você pode fazer é usar WPA3-SAE no SSID de convidados para garantir a criptografia no ar sem exigir credenciais por usuário. O WPA3 Simultaneous Authentication of Equals elimina a vulnerabilidade da chave pré-compartilhada usando uma troca de prova de conhecimento zero, de modo que, mesmo que alguém capture o handshake, não poderá quebrar a senha por força bruta offline. Agora vamos falar sobre largura de banda. É aqui que muitas equipes de TI de hospitais subestimam o requisito. Um único paciente em um leito hoje pode ter um smartphone, um tablet e uma smart TV ou unidade de entretenimento à beira do leito. Eles estão transmitindo Netflix ou BBC iPlayer, fazendo chamadas de vídeo para a família e, potencialmente, usando um portal do paciente do hospital. O Netflix HD requer cinco megabits por segundo. Uma transmissão em 4K requer vinte e cinco. Uma chamada de vídeo no FaceTime ou Teams requer entre um e três megabits por segundo em cada direção. Portanto, por leito, você deve planejar um mínimo de vinte e cinco megabits por segundo de taxa de transferência disponível — e isso antes de considerar os fatores de concorrência. Em um hospital de duzentos leitos onde sessenta por cento dos pacientes estão usando ativamente o WiFi no horário de pico — digamos, sete da noite — você está olhando para três gigabits por segundo de demanda agregada na rede de convidados. Sua capacidade de uplink e sua densidade de pontos de acesso precisam ser dimensionadas de acordo. A regra prática que utilizo é: um ponto de acesso por enfermaria, não um por ala. Em uma enfermaria de seis leitos, você quer um AP a dez metros de cada leito, operando na banda de cinco gigahertz para clientes sensíveis à taxa de transferência, com a banda de dois vírgula quatro gigahertz lidando com dispositivos IoT legados e aparelhos mais antigos. O planejamento de canais importa enormemente em um hospital. Você tem ambientes de RF densos — paredes grossas de concreto, estruturas de metal de leitos, equipamentos médicos gerando interferência. Use uma ferramenta de pesquisa de local sem fio antes da implantação, não depois. Planeje seu padrão de reutilização de canais na banda de cinco gigahertz usando canais que não se sobrepõem das bandas UNII-1 e UNII-3. Defina a potência de transmissão de forma conservadora — você quer que as células se sobreponham em cerca de quinze a vinte por cento, não cinquenta por cento. APs com excesso de potência causam interferência de canal compartilhado e, na verdade, degradam a taxa de transferência. Para a rede clínica, as considerações de design de RF são ainda mais críticas porque você está dando suporte a aplicações em tempo real. VoIP em sistemas de chamada de enfermagem, streaming de telemetria de monitores de pacientes e escaneamento de código de barras na dispensação de medicamentos exigem baixa latência e sinal consistente. Tenha como meta menos sessenta e cinco dBm de RSSI em cada endpoint clínico, com uma relação sinal-ruído acima de vinte e cinco decibéis. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — aproximadamente 2 minutos] Deixe-me apresentar as três principais armadilhas de implementação que vejo em projetos de WiFi hospitalar. Primeira: assumir que a configuração da sua VLAN está correta sem testá-la. Já vi implantações em que uma porta de tronco mal configurada permitiu que o tráfego da VLAN de visitantes vazasse para a VLAN clínica. A maneira de detectar isso é um teste de invasão pós-implantação — especificamente, tentar alcançar endereços de sub-rede clínica a partir de um cliente visitante. Se você conseguir dar ping em qualquer coisa na faixa clínica, sua segmentação falhou. Este deve ser um critério de aprovação obrigatório antes do go-live. Segunda: negligenciar a experiência do Captive Portal. Os hospitais costumam tratar o portal de WiFi para visitantes como algo secundário. Mas um portal mal projetado — que expira, não renderiza no celular ou exige etapas demais — afeta diretamente as pontuações de satisfação do paciente. Nos Estados Unidos, os resultados da pesquisa HCAHPS incluem pontuações de comunicação e ambiente que são influenciadas pela qualidade do WiFi. No NHS, as respostas do Friends and Family Test frequentemente citam o WiFi como um fator. Uma plataforma como a solução de Guest WiFi da Purple oferece um portal personalizado com a sua marca, otimizado para dispositivos móveis e com análises integradas, para que você não esteja apenas fornecendo conectividade — você está capturando dados sobre padrões de uso que informam o planejamento de capacidade. Terceira: não ter uma política de gerenciamento de largura de banda. Sem QoS e limitação de taxa na rede de visitantes, um único paciente executando um cliente BitTorrent pode saturar o uplink e prejudicar a experiência de todos os outros. Implemente limitação de taxa por cliente — normalmente de cinco a dez megabits por segundo de download por dispositivo — e use marcação DSCP para priorizar o tráfego de chamadas de vídeo em relação a downloads em massa. Bloqueie protocolos ponto a ponto no nível do firewall na VLAN de visitantes. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me passar por algumas perguntas rápidas que recebo regularmente. "Podemos usar os mesmos access points físicos para a rede clínica e de visitantes?" Sim, com certeza — APs com dual-SSID são uma prática padrão. A separação é lógica, no nível da VLAN, não física. Apenas certifique-se de que o firmware do seu AP suporte marcação de VLAN e que seu WLC imponha a separação. "Precisamos de um uplink de internet separado para o tráfego de visitantes?" Não necessariamente, mas você deve usar modelagem de tráfego para garantir que o tráfego de gerenciamento clínico — atualizações de software, acesso remoto — nunca seja prejudicado pelo uso dos visitantes. Um uplink dedicado para visitantes é uma abordagem de segurança extra se o orçamento permitir. "Como lidamos com dispositivos IoT médicos no WiFi?" A IoT médica — bombas de infusão, monitores de telemetria — deve estar em uma terceira VLAN dedicada, separada tanto das estações de trabalho clínicas quanto dos dispositivos de visitantes. Isso limita o raio de impacto caso um dispositivo seja comprometido. "E quanto ao GDPR e aos dados coletados por meio do Captive Portal?" Quaisquer dados pessoais coletados no login — e-mail, número de telefone — devem ser processados sob uma base legal, normalmente o consentimento. Certifique-se de que os termos do seu portal estejam claros, sua política de retenção de dados esteja documentada e que você tenha um acordo de processamento de dados com o provedor da sua plataforma de WiFi. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para resumir: o WiFi para visitantes 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 só lugar. A arquitetura é simples — segmentação de VLAN, 802.1X na rede clínica, WPA3 na de visitantes, Captive Portal para acesso, QoS para gerenciamento de largura de banda —, mas a execução exige rigor em todas as camadas. Seus próximos passos: encomende um levantamento de local sem fio (site survey) se não tiver feito um nos últimos dois anos. Revise sua configuração de VLAN e teste o isolamento entre VLANs. Compare a satisfação atual do paciente com o WiFi em relação aos dados do HCAHPS ou do Friends and Family Test. E se você estiver avaliando plataformas de WiFi para visitantes, conheça a solução de Healthcare da Purple — ela se integra ao guia de conformidade com a HIPAA para oferecer uma visão completa do cenário regulatório. Obrigado por ouvir. A documentação técnica completa, os diagramas de arquitetura e os checklists de implementação estão disponíveis no guia complementar no site da Purple.