Hospital Guest WiFi: Patient Experience and Network Separation

Hospital Guest WiFi: Patient Experience and Network Separation Una sesión informativa técnica de Purple — aproximadamente 10 minutos [INTRODUCCIÓN — aproximadamente 1 minuto] Bienvenido a la serie de sesiones informativas técnicas de Purple. Soy su anfitrión, y hoy abordaremos una de las implementaciones de WiFi más sensibles a nivel operativo que encontrará en las redes empresariales: el WiFi para invitados en hospitales. Si usted es un gerente de TI clínica, un CIO de hospital o un ingeniero de redes de atención médica, ya sabe que lo que está en juego aquí es diferente a cualquier otro lugar. Este no es un hotel donde un huésped no puede transmitir Netflix. Este es un entorno donde una VLAN mal configurada podría, teóricamente, colocar los sistemas clínicos (plataformas EHR, bombas de infusión, equipos de imagenología) en el mismo dominio de difusión que el teléfono inteligente de un paciente. Ese no es un riesgo teórico. Ha sucedido. Y las consecuencias van desde el incumplimiento regulatorio hasta incidentes de seguridad del paciente. Así que hoy vamos a cubrir tres cosas: cómo diseñar una separación completa entre las redes clínicas y de invitados, cómo ofrecer una experiencia de WiFi genuinamente buena para pacientes y visitantes, y cómo medir si está funcionando. Comencemos. [ANÁLISIS TÉCNICO PROFUNDO — aproximadamente 5 minutos] Comencemos con la arquitectura. El principio fundamental del diseño de WiFi para hospitales es que el tráfico clínico y el de invitados nunca deben compartir un dominio de difusión de Capa 2. Punto final. Esto no es negociable bajo el Data Security and Protection Toolkit de NHS Digital, y se alinea con los requisitos de salvaguardas técnicas de HIPAA en los Estados Unidos. El enfoque estándar es la segmentación por VLAN. Se asigna una VLAN dedicada (llamémosla VLAN 10) a los sistemas clínicos: estaciones de trabajo EHR, sistemas de llamada a enfermeras, dispositivos IoT médicos, servidores de imágenes PACS. Una segunda VLAN (VLAN 20) transporta todo el tráfico de WiFi de invitados y pacientes. Estas VLAN se conectan mediante un enlace troncal a través de su infraestructura de conmutación y terminan en un firewall de próxima generación, donde el enrutamiento inter-VLAN está completamente bloqueado o controlado de manera muy estricta con reglas de permiso explícitas. Ahora, aquí es donde muchas implementaciones fallan. Los equipos asumen que la separación de VLAN en la capa del switch es suficiente. No lo es. Es necesario aplicar esto en tres niveles: la capa de acceso, la capa de distribución y el firewall. Si sus puntos de acceso son de doble SSID (transmitiendo tanto un SSID clínico como un SSID de invitados), esos SSIDs deben mapearse a VLANs separadas sin puenteo entre ellos. Su controlador de LAN inalámbrica debe estar configurado para evitar la comunicación de cliente a cliente en la VLAN de invitados, y debe habilitar el aislamiento de AP de forma predeterminada. Eso significa que un paciente en la cama siete no puede sondear el dispositivo en la cama ocho, aunque estén en el mismo SSID de invitados. La autenticación es la siguiente capa. En la red clínica, se requiere IEEE 802.1X con EAP-TLS o PEAP-MSCHAPv2, respaldado por un servidor RADIUS — Microsoft NPS, FreeRADIUS o un servicio RADIUS basado en la nube. Cada dispositivo clínico debe tener un certificado o una credencial de dominio. No use PSK en redes clínicas. Nunca. Las claves precompartidas son un punto único de falla: una sola credencial comprometida y todos los dispositivos en ese SSID quedan expuestos. Para la red de invitados, el modelo es diferente. Se trata de pacientes que pueden ser de edad avanzada, estar enfermos o no tener confianza técnica. La experiencia de autenticación debe ser sencilla. Un Captive Portal con aceptación de un solo clic o una verificación simple por SMS es lo adecuado aquí. No le va a pedir a un paciente que se recupera de una cirugía que configure 802.1X en su dispositivo personal. Lo que puede hacer es usar WPA3-SAE en el SSID de invitados para garantizar el cifrado inalámbrico sin requerir credenciales por usuario. WPA3 Simultaneous Authentication of Equals elimina la vulnerabilidad de la clave precompartida mediante el uso de un intercambio de prueba de conocimiento cero, por lo que incluso si alguien captura el saludo de conexión (handshake), no podrá descifrar la frase de contraseña por fuerza bruta fuera de línea. Ahora hablemos del ancho de banda. Aquí es donde muchos equipos de TI de hospitales subestiman los requisitos. Un solo paciente en una cama hoy en día puede tener un smartphone, una tableta y una smart TV o unidad de entretenimiento junto a la cama. Están transmitiendo Netflix o BBC iPlayer, realizando videollamadas a familiares y, potencialmente, utilizando un portal para pacientes del hospital. Netflix en HD requiere cinco megabits por segundo. Una transmisión en 4K requiere veinticinco. Una videollamada en FaceTime o Teams requiere entre uno y tres megabits por segundo en cada dirección. Por lo tanto, por cama, debería planificar un rendimiento mínimo disponible de veinticinco megabits por segundo, y eso es antes de tener en cuenta los factores de concurrencia. En un hospital de doscientas camas donde el sesenta por ciento de los pacientes utilizan activamente el WiFi en las horas pico —por ejemplo, a las siete de la tarde—, se calcula una demanda agregada de tres gigabits por segundo en la red de invitados. La capacidad de su enlace ascendente y la densidad de sus puntos de acceso deben dimensionarse en consecuencia. La regla general que utilizo es: un punto de acceso por sala de hospitalización, no uno por pabellón. En una sala de seis camas, se requiere un AP a menos de diez metros de cada cama, operando en la banda de cinco gigahertz para clientes sensibles al rendimiento, mientras que la banda de dos punto cuatro gigahertz maneja dispositivos IoT heredados y teléfonos más antiguos. La planificación de canales es sumamente importante en un hospital. Se tienen entornos de RF densos: paredes de concreto gruesas, estructuras de camas metálicas y equipos médicos que generan interferencias. Utilice una herramienta de estudio de cobertura inalámbrica (site survey) antes de la implementación, no después. Planifique su patrón de reutilización de canales en la banda de cinco gigahertz utilizando canales que no se superpongan de las bandas UNII-1 y UNII-3. Ajuste la potencia de transmisión de forma conservadora: se busca que las celdas se superpongan entre un quince y un veinte por ciento, no un cincuenta por ciento. Los AP con exceso de potencia causan interferencia de canal adyacente y, de hecho, degradan el rendimiento. Para la red clínica, las consideraciones de diseño de RF son aún más críticas porque se están soportando aplicaciones en tiempo real. VoIP en sistemas de llamada a enfermeras, transmisión de telemetría desde monitores de pacientes y escaneo de códigos de barras en la dispensación de medicamentos requieren baja latencia y una señal constante. Apunte a un RSSI de menos sesenta y cinco dBm en cada punto final clínico, con una relación señal-ruido superior a veinticinco decibelios. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Permítame compartirle los tres principales errores de implementación que veo en los proyectos de WiFi para hospitales. Primero: asumir que la configuración de su VLAN es correcta sin haberla probado. He visto implementaciones donde un puerto troncal mal configurado permitió que el tráfico de la VLAN de invitados se filtrara a la VLAN clínica. La forma de detectar esto es mediante una prueba de penetración posterior a la implementación; específicamente, intente alcanzar direcciones de subred clínicas desde un cliente de invitados. Si puede hacer ping a cualquier elemento en el rango clínico, su segmentación ha fallado. Este debería ser un criterio de aprobación obligatorio antes de la puesta en marcha. Segundo: descuidar la experiencia del Captive Portal. Los hospitales suelen tratar el portal de WiFi para invitados como algo secundario. Pero un portal mal diseñado (uno que expira, que no se renderiza en dispositivos móviles o que requiere demasiados pasos) afecta directamente los puntajes de satisfacción del paciente. En los Estados Unidos, los resultados de la encuesta HCAHPS incluyen puntajes de comunicación y entorno que se ven influenciados por la calidad del WiFi. En el NHS, las respuestas de la Friends and Family Test citan con frecuencia al WiFi como un factor. Una plataforma como la solución de Guest WiFi de Purple le brinda un portal de marca optimizado para dispositivos móviles con analíticas integradas, de modo que no solo está proporcionando conectividad, sino que está capturando datos sobre patrones de uso que informan la planificación de la capacidad. Tercero: no contar con una política de gestión de ancho de banda. Sin QoS y limitación de velocidad en la red de invitados, un solo paciente que ejecute un cliente BitTorrent puede saturar el enlace ascendente y degradar la experiencia de todos los demás. Implemente una limitación de velocidad por cliente (normalmente de cinco a diez megabits por segundo de descarga por dispositivo) y utilice el marcado DSCP para priorizar el tráfico de videollamadas sobre las descargas masivas. Bloquee los protocolos peer-to-peer a nivel de firewall en la VLAN de invitados. [PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto] Permítame repasar algunas preguntas rápidas que me hacen con regularidad. "¿Podemos usar los mismos puntos de acceso físicos para la red clínica y la de invitados?" Sí, absolutamente; los AP con doble SSID son una práctica estándar. La separación es lógica, a nivel de VLAN, no física. Solo asegúrese de que el firmware de su AP admita el etiquetado de VLAN y que su WLC aplique la separación. "¿Necesitamos un enlace ascendente de internet independiente para el tráfico de invitados?" No necesariamente, pero debe utilizar el modelado de tráfico para garantizar que el tráfico de gestión clínica (actualizaciones de software, acceso remoto) nunca se vea afectado por el uso de los invitados. Un enlace ascendente dedicado para invitados es un enfoque de máxima seguridad si el presupuesto lo permite. "¿Cómo manejamos los dispositivos IoT médicos en el WiFi?" El IoT médico (bombas de infusión, monitores de telemetría) debe estar en una tercera VLAN dedicada, separada tanto de las estaciones de trabajo clínicas como de los dispositivos de invitados. Esto limita el radio de impacto si un dispositivo se ve comprometido. "¿Qué pasa con el GDPR y los datos recopilados a través del Captive Portal?" Cualquier dato personal recopilado al iniciar sesión (correo electrónico, número de teléfono) debe procesarse bajo una base legal, que normalmente es el consentimiento. Asegúrese de que los términos de su portal sean claros, que su política de retención de datos esté documentada y que tenga un acuerdo de procesamiento de datos con su proveedor de plataforma de WiFi. [RESUMEN Y PRÓXIMOS PASOS — aproximadamente 1 minuto] Para concluir: el WiFi para invitados de hospitales no es solo un proyecto de conectividad. Es una iniciativa de experiencia del paciente, un requisito de cumplimiento y una consideración de seguridad clínica, todo en uno. La arquitectura es sencilla (segmentación de VLAN, 802.1X en la red clínica, WPA3 en la de invitados, Captive Portal para el acceso, QoS para la gestión del ancho de banda), pero la ejecución requiere rigor en cada capa. Sus próximos pasos: solicite un estudio de cobertura inalámbrica si no ha realizado uno en los últimos dos años. Revise su configuración de VLAN y pruebe el aislamiento entre VLAN. Compare su satisfacción actual con el WiFi para pacientes con los datos de HCAHPS o del Friends and Family Test. Y si está evaluando plataformas de WiFi para invitados, eche un vistazo a la solución de Healthcare de Purple; se complementa con su guía de cumplimiento de HIPAA para ofrecerle un panorama completo del entorno regulatorio. Gracias por escuchar. La documentación técnica completa, los diagramas de arquitectura y las listas de verificación de implementación están disponibles en la guía complementaria en el sitio web de Purple.