WiFi para invitados de hospital: experiencia del paciente y separación de redes

Hospital Guest WiFi: Patient Experience and Network Separation Una sesión informativa técnica de Purple - aproximadamente 10 minutos [INTRODUCCIÓN - aproximadamente 1 minuto] Le damos la bienvenida a la serie de sesiones informativas técnicas de Purple. Soy su anfitrión, y hoy abordaremos uno de los despliegues de WiFi más delicados desde el punto de vista operativo que encontrará en las redes empresariales: el WiFi para huéspedes en hospitales. Si es usted gestor de TI clínicas, director de TI de un hospital o ingeniero de redes sanitarias, ya sabe que lo que está en juego aquí es diferente a cualquier otro entorno. Esto no es un hotel donde un huésped no puede ver Netflix. Este es un entorno donde una VLAN mal configurada podría, teóricamente, poner los sistemas clínicos - plataformas EHR, bombas de infusión, equipos de imagen diagnóstica - en el mismo dominio de difusión que el smartphone de un paciente. No es un riesgo teórico. Ha ocurrido. Y las consecuencias van desde el incumplimiento normativo hasta incidentes de seguridad del paciente. Así que hoy vamos a cubrir tres aspectos: cómo diseñar una separación completa entre las redes clínicas y de huéspedes, cómo ofrecer una experiencia de WiFi realmente buena para pacientes y visitantes, y cómo medir si está funcionando. Vamos a ello. [ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos] Comencemos con la arquitectura. El principio fundamental del diseño de WiFi en hospitales es que el tráfico clínico y el de huéspedes 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 salvaguarda técnica 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 de EHR, sistemas de llamada a enfermería, dispositivos IoT médicos, servidores de imagen PACS. Una segunda VLAN - VLAN 20 - transporta todo el tráfico WiFi de huéspedes y pacientes. Estas VLAN se conectan mediante un enlace troncal (trunk) a través de su infraestructura de conmutación y terminan en un firewall de última generación, donde el enrutamiento inter-VLAN está completamente bloqueado o controlado de forma muy estricta con reglas de permiso explícitas. Ahora bien, aquí es donde fallan muchos despliegues. Los equipos asumen que la separación de VLAN en la capa de conmutación 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 huéspedes -, esos SSID deben asignarse a VLAN independientes sin puenteo (bridging) entre ellos. Su controlador de LAN inalámbrica debe estar configurado para evitar la comunicación de cliente a cliente en la VLAN de huéspedes, 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 huéspedes. 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 en la nube. Cada dispositivo clínico debe tener un certificado o una credencial de dominio. Nada de PSK en las redes clínicas. Nunca. Las claves precompartidas son un único punto de fallo - una credencial comprometida y todos los dispositivos de 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 conocimientos técnicos. La experiencia de autenticación debe ser sencilla. Un Captive Portal con aceptación mediante un solo clic o una verificación simple por SMS es lo adecuado aquí. No se le va a pedir a un paciente que se recupera de una cirugía que configure 802.1X en su dispositivo personal. Lo que sí se puede hacer es usar WPA3-SAE en el SSID de invitados para garantizar el cifrado en el aire sin requerir credenciales por usuario. WPA3 Simultaneous Authentication of Equals elimina la vulnerabilidad de las claves precompartidas al utilizar un intercambio de pruebas de conocimiento cero, por lo que incluso si alguien captura el saludo de conexión, no podrá descifrar la frase de paso mediante fuerza bruta de forma offline. 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 tablet y una smart TV o un equipo de entretenimiento junto a la cama. Están reproduciendo contenido de Netflix o BBC iPlayer, realizando videollamadas a familiares y potencialmente utilizando un portal del paciente del hospital. Netflix 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, se debería planificar un mínimo de veinticinco megabits por segundo de rendimiento disponible - 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 punta - por ejemplo, a las siete de la tarde - se prevé una demanda agregada de tres gigabits por segundo en la red de invitados. La capacidad del enlace ascendente y la densidad de los puntos de acceso deben dimensionarse en consecuencia. La regla general que utilizo es: un punto de acceso por sección de la sala de hospitalización, no uno por sala completa. En una sección de seis camas, se necesita un AP a menos de diez metros de cada cama, funcionando en la banda de cinco gigahercios para clientes sensibles al rendimiento, mientras que la banda de dos coma cuatro gigahercios gestiona los dispositivos IoT heredados y los teléfonos móviles más antiguos. La planificación de canales es de enorme importancia en un hospital. Existen entornos de radiofrecuencia densos - paredes de hormigón grueso, estructuras metálicas de camas, equipos médicos que generan interferencias. Utilice una herramienta de estudio de cobertura inalámbrica antes de la implementación, no después. Planifique su patrón de reutilización de canales en la banda de cinco gigahercios utilizando canales no superpuestos 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 un exceso de potencia causan interferencias de canal adyacente y, en realidad, reducen el rendimiento. Para la red clínica, las consideraciones de diseño de RF son aún más críticas porque se da soporte a aplicaciones en tiempo real. La VoIP en los sistemas de llamada de enfermería, la transmisión de telemetría desde los monitores de pacientes y el escaneo de códigos de barras en la dispensación de medicamentos requieren una baja latencia y una señal constante. Establezca como objetivo 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 detallar los tres principales errores de implementación que observo en los proyectos de WiFi para hospitales. Primero: asumir que la configuración de su VLAN es correcta sin probarla. He visto despliegues en los que un puerto troncal mal configurado permitía que el tráfico de la VLAN de invitados se filtrara a la VLAN clínica. La forma de detectar esto es realizar una prueba de penetración posterior al despliegue; específicamente, intente alcanzar direcciones de la subred clínica desde un cliente invitado. Si puede hacer ping a cualquier elemento del 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 WiFi de invitados como algo secundario. Sin embargo, un portal mal diseñado (que agota el tiempo de espera, no se renderiza en dispositivos móviles o requiere demasiados pasos) afecta directamente a las puntuaciones de satisfacción de los pacientes. En los Estados Unidos, los resultados de las encuestas HCAHPS incluyen puntuaciones de comunicación y entorno que se ven influenciadas por la calidad del WiFi. En el NHS, las respuestas del Friends and Family Test suelen citar el WiFi como un factor. Una plataforma como la solución de Guest WiFi de Purple le ofrece un portal personalizado con su marca, optimizado para móviles y con analíticas integradas, de modo que no solo ofrece conectividad, sino que recopila datos sobre patrones de uso que ayudan a planificar la capacidad. Tercero: no disponer de una política de gestión del ancho de banda. Sin QoS y limitación de ancho de banda en la red de invitados, un solo paciente que ejecute un cliente BitTorrent puede saturar el enlace de subida 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] Repasemos algunas preguntas rápidas que me hacen con frecuencia. "¿Podemos utilizar los mismos puntos de acceso físicos para la red clínica y la de invitados?" Sí, por supuesto; los AP con SSID dual 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 sea compatible con el etiquetado de VLAN y que su WLC aplique la separación. "¿Necesitamos un enlace de subida a 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 (como las actualizaciones de software o el acceso remoto) nunca se vea privado de recursos por el uso de los invitados. Un enlace de subida exclusivo para invitados es un enfoque de máxima seguridad si el presupuesto lo permite. "¿Cómo gestionamos los dispositivos IoT médicos en la red 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 los 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, normalmente 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 de que disponga de un acuerdo de procesamiento de datos con su proveedor de plataforma WiFi. [RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto] Para terminar: el WiFi para invitados de un hospital 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: encargue 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 Healthcare de Purple - se complementa con su guía de cumplimiento de HIPAA para ofrecerle una visión completa del panorama normativo. Gracias por escucharnos. La documentación técnica completa, los diagramas de arquitectura y las listas de comprobación para la implementación están disponibles en la guía adjunta en el sitio web de Purple.