PPSK 12: comparación de características y modelos de implementación

Bienvenido a la sesión técnica de Purple. Hoy cubriremos PPSK 12 - que es Private Pre-Shared Key con una longitud mínima de clave de 12 caracteres - comparando sus características y modelos de implementación para desarrolladores inmobiliarios, arrendadores y operadores de propiedades de alquiler (build-to-rent). Comencemos con el contexto. Si administra un edificio residencial con 50, 100 o 300 unidades, tiene un problema de WiFi que ni una contraseña compartida ni una implementación empresarial completa de 802.1X resuelven de manera limpia. Una contraseña compartida significa que todos los residentes están en la misma red. Si una persona se muda, usted cambia la contraseña y afecta la configuración del hogar inteligente de todos los demás residentes. Un sistema 802.1X completo es el estándar de oro para dispositivos gestionados por empresas, pero requiere una infraestructura de clave pública, gestión de certificados y configuración de suplicante en cada dispositivo. Los Chromecast, altavoces inteligentes y consolas de videojuegos de sus residentes simplemente no pueden hacer eso. PPSK se sitúa precisamente entre esos dos extremos. Cada residente obtiene su propia clave compartida única (con un mínimo de 12 caracteres, mezclando mayúsculas, minúsculas, números y símbolos). Todos los residentes se conectan al mismo SSID. Desde la perspectiva del residente, se siente exactamente como la red WiFi de su hogar. Desde su perspectiva como operador, cada conexión se identifica de forma individual, se cifra de forma individual y se puede revocar de forma individual. Sección uno: la arquitectura técnica. Cuando un dispositivo se conecta a un SSID habilitado para PPSK, el controlador de LAN inalámbrica intercepta el intento de conexión y reenvía la dirección MAC del dispositivo a un servidor RADIUS. RADIUS - Remote Authentication Dial-In User Service - es el motor de autenticación. El servidor RADIUS busca esa dirección MAC en su almacén de identidad y devuelve una respuesta Access-Accept. En esa respuesta se incluye la clave precompartida única para ese residente, además de una asignación de VLAN. El controlador valida la clave que presentó el dispositivo frente a la clave que devolvió el servidor RADIUS. Si coinciden, el dispositivo se autentica y entra en el segmento de red correcto. El resultado es lo que llamamos una burbuja de WiFi por residente. Cada dispositivo en la clave del residente A ve a todos los demás dispositivos en la clave del residente A. Su teléfono descubre su Chromecast. Su altavoz inteligente se vincula con sus focos inteligentes. Su consola encuentra su televisor. Ningún dispositivo en la clave del residente A ve ningún dispositivo en una clave diferente. Los dispositivos del residente B son invisibles para el residente A, aunque estén en el mismo punto de acceso físico. Los principales proveedores implementan esto de manera ligeramente diferente. Cisco Meraki lo llama iPSK - Identity PSK. HPE Aruba lo llama MPSK - Multi-PSK. Ruckus lo llama DPSK - Dynamic PSK. Juniper Mist utiliza PPSK. El principio fundamental es idéntico en los cuatro. Los detalles de implementación difieren en cómo se estructuran los atributos de RADIUS y cuántas claves únicas puede admitir un solo SSID. Sobre la longitud de la clave: el mínimo de 12 caracteres no es arbitrario. Las claves WPA2-PSK se derivan usando PBKDF2 con 4,096 iteraciones de HMAC-SHA1. Una clave de menos de 12 caracteres es vulnerable a ataques de diccionario offline, particularmente con herramientas de descifrado aceleradas por GPU modernas. Con 12 caracteres y clases de caracteres combinadas, el espacio de claves es lo suficientemente grande como para que los ataques de fuerza bruta sean computacionalmente inviables. Algunas plataformas, incluyendo UniFi, aplican este mínimo a nivel de UI. Debe aplicarlo en su política de generación de claves, independientemente de si la plataforma lo requiere. Sección dos: modelos de implementación. Existen tres arquitecturas de implementación para PPSK, y elegir la adecuada depende de su cartera de propiedades y de la capacidad de su equipo. La primera es cloud RADIUS. Sus puntos de acceso se autentican contra un servicio RADIUS alojado en la nube, generalmente a través de múltiples zonas de disponibilidad. Esta es la opción correcta para carteras de múltiples sitios - un operador de BTR con propiedades en varias ciudades, por ejemplo. Cloud RADIUS elimina el hardware por sitio, automatiza la rotación de certificados y escala de forma elástica. La plataforma de Purple ofrece un 99.999% de tiempo de actividad en su infraestructura de autenticación. La desventaja es la dependencia de la WAN: si la conexión a internet en un sitio se cae, los nuevos dispositivos no podrán autenticarse hasta que se restaure la conectividad. Mitigue esto con SD-WAN y almacenamiento en caché de credenciales locales en el controlador. La segunda es RADIUS local. Un servidor RADIUS - generalmente Microsoft NPS o FreeRADIUS - se ejecuta en hardware o en una máquina virtual en la propiedad. Esto le ofrece una latencia de autenticación de menos de un milisegundo, soberanía total de los datos y ninguna dependencia de la WAN. Es la opción correcta para una sola propiedad grande con requisitos estrictos de residencia de datos, o para entornos donde la conectividad a internet no es confiable. El costo operativo es mayor: su equipo gestiona los parches, la rotación de certificados y el estado del servidor. El vencimiento de los certificados es la causa más común de caídas completas de autenticación en implementaciones locales. Integre la renovación automatizada de certificados en su manual de procedimientos desde el primer día. La tercera es la híbrida. Cloud RADIUS gestiona los SSID de invitados e IoT. El RADIUS local gestiona cualquier SSID corporativo o de personal que se autentique contra un Active Directory interno. Este es un modelo pragmático para desarrollos de uso mixto - un edificio BTR con locales comerciales en la planta baja o espacio de coworking, por ejemplo. La plataforma de Purple es compatible con este modelo híbrido de forma nativa, ejecutándose en puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Sección tres: gestión del ciclo de vida de las claves. La tecnología es la parte fácil. La gestión del ciclo de vida de las claves es donde las implementaciones tienen éxito o fracasan operativamente. Al momento de la mudanza, se genera y aprovisiona automáticamente una clave única para el residente, idealmente a través de la integración de la API con su sistema de gestión de propiedades. El residente recibe la clave mediante un correo electrónico de bienvenida o la aplicación para residentes. Todos sus dispositivos se conectan utilizando esa única clave. Al momento de la mudanza de salida, la clave se revoca. Ningún otro residente se ve afectado. Sin rotación de contraseñas. Sin tickets de soporte. A mitad del contrato de arrendamiento, los residentes añaden dispositivos. Un portal de autoservicio o una aplicación para residentes que emita la clave existente del residente a un nuevo dispositivo - sin exponer esa clave a otros residentes - es el enfoque correcto. La plataforma de Purple proporciona este flujo de trabajo de forma nativa. El riesgo operativo crítico es la aleatorización de direcciones MAC. iOS 14 y versiones posteriores, Android 10 y versiones posteriores, y Windows 11 aleatorizan las direcciones MAC por defecto por razones de privacidad. Si un dispositivo presenta una MAC aleatoria, su servidor RADIUS no encontrará un registro coincidente y rechazará la conexión. La solución consiste en configurar su SSID para exigir a los clientes que utilicen la dirección MAC permanente de su dispositivo, o implementar un flujo de trabajo de prerregistro. Esto debe estar en su plan de despliegue desde el primer día, no descubrirse durante la puesta en marcha. Sección cuatro: WPA3 y la consideración de 6 GHz. Un comentario sobre WPA3, porque aquí es donde veo a los operadores cometer errores de planificación. PPSK tal como se implementa actualmente se basa en el saludo de cuatro vías de WPA2-PSK. WPA3 introduce SAE - Simultaneous Authentication of Equals - lo que cambia el mecanismo de saludo. Actualmente, SAE admite solo una clave por SSID. Eso significa que un SSID puro de WPA3 no puede admitir múltiples claves precompartidas únicas. En la banda de 6 GHz, introducida con WiFi 6E, WPA3 es obligatorio. No se puede ejecutar WPA2 en la banda de 6 GHz en absoluto. Por lo tanto, si está desplegando puntos de acceso WiFi 6E o WiFi 7 y desea utilizar la banda de 6 GHz, PPSK no está disponible allí hoy en día. La recomendación práctica para los despliegues de 2025 y 2026 es una estrategia de doble banda. Ejecute su SSID PPSK en 2.4 GHz y 5 GHz en modo de transición WPA2 o WPA2/WPA3. Utilice un SSID WPA3-Enterprise separado en 6 GHz para los dispositivos gestionados que lo admitan. Esto le ofrece el aislamiento por residente de PPSK para la amplia flota de dispositivos, y la seguridad mejorada de WPA3 para los dispositivos que pueden utilizarlo. Los proveedores que incluyen a Cisco Meraki, HPE Aruba y Juniper Mist están trabajando activamente en implementaciones de PPSK compatibles con WPA3. Sección cinco: cumplimiento y privacidad de datos. Los despliegues de PPSK en entornos residenciales se sitúan en un contexto de privacidad más sensible que el WiFi para invitados. Los residentes tienen una relación continua con usted, y la exposición de datos se extiende a lo largo de años en lugar de minutos. El aislamiento de residentes es en sí mismo un requisito de privacidad bajo el GDPR. Usted tiene el deber de diligencia de evitar que un residente descubra o interactúe con los dispositivos de otro residente. PPSK es el mecanismo técnico que ofrece esto. La asignación de VLAN por residente garantiza el aislamiento de Capa 2 incluso en una infraestructura física compartida. Los registros de autenticación deben conservarse únicamente durante el tiempo necesario para la seguridad y las operaciones. Seis meses es un límite común para implementaciones residenciales. Purple almacena datos en regiones seleccionables, lo que es compatible con los requisitos de residencia de datos de Reino Unido, la UE y EE. UU. Para los operadores de BTR con inquilinos de comercio minorista o alimentos y bebidas en la planta baja, PCI-DSS es relevante. PPSK con asignación de VLAN por inquilino le permite demostrar que los dispositivos de procesamiento de pagos se encuentran en un segmento criptográficamente aislado, incluso en una infraestructura física compartida. Esa es una ventaja de cumplimiento significativa en comparación con una implementación de contraseña compartida. Sección seis: preguntas rápidas. ¿Cuántas claves únicas puede admitir un solo SSID? Esto depende del controlador. Cisco Meraki admite hasta 5,000 iPSKs por SSID sin RADIUS, y de manera ilimitada con RADIUS. Ruckus DPSK admite miles por zona. En la práctica, el factor limitante es la capacidad de la base de datos de su servidor RADIUS y el rendimiento de las consultas, no el controlador inalámbrico. ¿Funciona PPSK con dispositivos IoT? Sí. Los dispositivos IoT - bocinas inteligentes, termostatos, sensores, cerraduras - se conectan utilizando la clave del residente exactamente como lo hace cualquier otro dispositivo. Estos llegan a la VLAN del residente y pueden descubrir otros dispositivos con la misma clave. Esta es la razón principal por la que PPSK es la arquitectura correcta para implementaciones de BTR y MDU, donde de 15 a 25 dispositivos por hogar es ahora la norma. ¿Cuál es el caso de negocio? Un servicio de WiFi administrado con aislamiento por residente genera una prima de alquiler de £15 a £30 por unidad al mes según investigaciones de BTR de la British Property Federation. Los periodos de inactividad se reducen de cinco a diez días cuando el WiFi para la mudanza está listo desde el primer día. El volumen de tickets de soporte para problemas de Chromecast y hogares inteligentes disminuye casi a cero cuando PPSK se implementa correctamente. Resumen y próximos pasos. PPSK con una longitud mínima de clave de 12 caracteres es la arquitectura de autenticación de WiFi correcta para implementaciones de BTR, MDU, alojamiento estudiantil y vivienda social. Ofrece aislamiento por residente, soporte completo de IoT y gestión automatizada del ciclo de vida de las claves sin la sobrecarga de infraestructura de 802.1X. Elija RADIUS en la nube para portafolios de múltiples sitios. Elija RADIUS local para propiedades grandes individuales con requisitos de soberanía de datos. Utilice un modelo híbrido para desarrollos de uso mixto. Planifique para la aleatorización de direcciones MAC desde el primer día. Desarrolle una estrategia de doble banda para implementaciones de WiFi 6E y WiFi 7 mientras maduran las implementaciones de PPSK compatibles con WPA3. Las tres cosas que debe hacer este trimestre: auditar su modelo de autenticación actual con respecto a estos criterios, evaluar su infraestructura RADIUS y definir su flujo de trabajo de gestión del ciclo de vida de las claves, incluida la integración con su sistema de gestión de propiedades. La plataforma Multi-Tenant WiFi de Purple se ejecuta en los puntos de acceso que ya posee, a través de 80,000 sitios activos, y ofrece un tiempo de actividad del 99.999% en su infraestructura de autenticación. Gracias por unirse a esta sesión informativa técnica de Purple.