Parece que 802.1x sobre WPA2 es el camino a seguir. No diré que esto es necesariamente fácil de configurar, pero puede ajustarse a sus requisitos.
Necesitarás una CA. Este podría ser su servidor de AD por simplicidad, su empresa podría tener uno ya, o podría designar cualquier servidor en el que confíe lo suficiente como para ser una CA interna (si realmente es un mártir, incluso podría usar una CA pública durante tanto tiempo) ya que no le importa llevar semanas agregar nuevos clientes y acumular miles de dólares en tarifas). Esto tendrá que firmar certificados para su servidor y clientes RADIUS.
Necesitarás un servidor RADIUS. Este puede ser el servicio NPS en Windows Server, FreeRADIUS en RHEL, pfsense, incluso algunos enrutadores pueden hacerlo (Pero si convierte su enrutador en un servidor RADIUS, no lo admitiría en el intercambio de pilas de InfoSec). Esto necesitará un certificado firmado para validar su identidad a sus clientes. Esto servirá para autenticar a sus clientes, se puede configurar para hacerlo por nombre de usuario / contraseña, o podría hacerlo validando si el cliente posee un certificado válido y firmado. En algunos casos, puede configurar el servidor RADIUS para verificar un directorio LDAP (como AD, IPA, openLDAP, etc.) que asocia cada identidad (certificado en este caso) con un conjunto de grupos. Estos grupos podrían controlar a qué redes está autorizado el usuario para conectarse.
Sus APs deberán configurarse para usar WPA2 Enterprise y configurarse para enrutar las solicitudes de autenticación al servidor RADIUS. La configuración varía enormemente según la marca de tu AP.
Sus clientes deberán tener un certificado firmado cargado en su sistema y configurado para proporcionar ese certificado como autenticación 802.1x para la conexión WiFi a su AP (s). De nuevo, esto varía enormemente según el dispositivo y la configuración se deja como un ejercicio para el lector. Esto es usar TLS de autenticación de cliente sobre EAP y, por lo tanto, generalmente está decorado como la opción EAP-TLS en muchas de las configuraciones que he visto.
Anti-Patterns
Los problemas con esto dependen de su entorno y de la aceptación de riesgos. Pero estas preocupaciones deben ser abordadas.
Obtención de certificados para el cliente
Necesitará una forma de obtener certificados en el dispositivo cliente. En un entorno sin contraseña, ese certificado permite el acceso a la red y debe estar protegido como una contraseña y, por lo tanto, debe diseñarse un método de transmisión seguro (en este sentido, podría socavar la razón por la que está considerando esta opción).
Para las computadoras portátiles, si puede conectarlo a la red, hacer una validación automática (dirección MAC, credenciales de Active Directory o lo que diseñe), entonces puede cargar un certificado firmado en el sistema (o hacer que el sistema genere el certificado). cert y enviar un CSR a su CA).
Pero si su entorno tiene teléfonos / tabletas, el problema se vuelve más complicado. Las opciones pueden ser transferir certificados mediante unidades flash USB conectadas a conectores OTG (asegúrese de desinfectar esa unidad cada vez que la conecte a un dispositivo de usuario asqueroso). Tal vez podría proporcionar una red WiFi más fácil de acceder en su propia red / VLAN aislada, esto podría usar un solo PSK que gire según sea necesario, y en esta red todo lo que puede hacer es validar su dispositivo y recibir un certificado. Estas opciones vienen con sus compensaciones, envíenlas a través de su propio análisis de riesgo.
Cert Compromise
La otra preocupación es que los certificados se comprometan. Lo más probable es que esto solo sucedería si el sistema de un usuario es de su propiedad, pero podría haber algunos otros escenarios en los que se filtre un certificado válido. Si puede identificar este compromiso antes, puede hacer que su servidor RADIUS se valide contra OCSP o una CRL. Para luchar contra compromisos desconocidos, puede configurar los certificados para que caduquen rápidamente, pero debe tener una infraestructura configurada para renovar e instalar automáticamente los certificados de los usuarios y garantizar que la mayoría de los usuarios se conecten al menos una vez antes de que caduquen sus certificados. La mejor idea es probablemente un poco de ambos y el bloqueo de los recursos de la red para que estar en la red no necesariamente le dé acceso a nada (es decir, no utilice los mismos certificados de cliente para autenticarse en otros recursos de la red).
P.S.
Esta no es una configuración rápida y fácil, pero puede ser sólida si encuentra un buen nivel de concesiones entre proporcionar acceso a los usuarios y proteger el acceso de los atacantes. Y puede brindarle oportunidades para expandir y agregar funcionalidad adicional una vez que se sienta más cómodo con su implementación.