En el Reino Unido, el 98% de las organizaciones afirman que planean implementar o ya han implementado zero trust, sin embargo, solo el 15% reporta una implementación completa. La brecha no es la concientización. Es la ejecución. La investigación sobre zero trust en el Reino Unido muestra que muchos equipos han comenzado con la planificación, la segmentación o proyectos de identidad aislados sin conectar esos controles en un solo modelo operativo.
La pregunta práctica no es si zero trust es importante. Es cómo implementar zero trust sin interrumpir los servicios activos, frustrar a los usuarios o crear otra colección de productos de seguridad desconectados. La respuesta es secuenciar la migración en torno a la identidad, el estado del dispositivo, el ciclo de vida del directorio, el WiFi seguro, la segmentación y la verificación continua.
Por qué se estanca la implementación de Zero Trust en las empresas
El 51% de las organizaciones se encuentra todavía en una etapa inicial de planificación, mientras que solo el 15% afirma haber realizado una implementación completa, y el 80% se ha enfrentado a barreras técnicas u operativas. El informe de las organizaciones del Reino Unido muestra la brecha entre seleccionar una dirección y operar los controles requeridos. Los equipos suelen comenzar con proyectos aislados, para luego descubrir que la identidad, los dispositivos, los directorios, las aplicaciones y las redes dependen unos de otros.
Zero trust elimina la confianza inherente de los sistemas, redes y servicios. Una conexión interna no debe proporcionar un acceso amplio. Una cuenta antigua no debe conservar permisos después de que la persona o el proveedor ya no los necesite. Un servicio no debe seguir siendo confiable indefinidamente solo por haber aprobado una verificación de autenticación.
El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) define zero trust como una migración por etapas, no como la compra de un producto. Su guía de arquitectura define ocho principios de diseño, que incluyen decisiones de acceso guiadas por la identidad y comunicaciones protegidas. La colección zero trust del NCSC se publicó en 2021, y la guía de implementación se amplió en septiembre de ese año. Los principios de diseño de arquitectura del NCSC son útiles porque requieren que los equipos definan las decisiones de arquitectura y confianza antes de elegir la tecnología.
El modo de falla centrado en el producto
El patrón de falla suele comenzar con la compra de una plataforma. Un equipo implementa un producto de identidad, una herramienta de segmentación o una puerta de enlace ZTNA, y luego descubre que las cuentas de servicio, los dispositivos no administrados, las aplicaciones heredadas, la autenticación de WiFi y la baja de usuarios en el directorio nunca se mapearon.
El resultado es una lista de excepciones en constante crecimiento. Los usuarios reciben soluciones temporales, los administradores conservan credenciales compartidas y los equipos de seguridad no pueden saber si la política se está aplicando de manera coherente. El WiFi expone esta debilidad rápidamente. La segmentación de red puede separar el tráfico, pero no crea un acceso basado en la identidad si los usuarios aún se conectan a través de contraseñas compartidas o si los dispositivos siguen siendo desconocidos. El WiFi sin contraseña con autenticación basada en certificados, vinculado a los registros de dispositivos y al estado del directorio, proporciona a la política una señal de identidad confiable. La revocación automática del directorio debería eliminar el acceso cuando se deshabilite una cuenta, en lugar de esperar una limpieza manual.
Los controles de perímetro tradicionales todavía juegan un papel, pero no pueden responder a todas las preguntas de acceso. El artículo sobre por qué falla la seguridad de TI tradicional explica cómo los servicios en la nube, el acceso remoto y los dispositivos distribuidos debilitan la suposición de que una red interna es automáticamente segura.
Regla práctica: No escriba políticas de aplicación hasta que sepa qué dependencias de identidad, dispositivo, WiFi y servicios podría interrumpir dicha política.
Una migración viable sigue este orden:
- Descubra el entorno: Identifique usuarios, dispositivos, aplicaciones, servicios y flujos de datos.
- Defina límites: Decida qué recursos requieren aislamiento y qué rutas de acceso son legítimas.
- Construya el plano de control: Conecte la identidad, MFA, el acceso a dispositivos basado en certificados, las verificaciones de estado y el ciclo de vida del directorio.
- Aplique en el extremo: Aplique la política a las aplicaciones, las redes y el WiFi, no solo a las sesiones de VPN.
- Observe y expanda: Comience con cargas de trabajo controladas, revise las decisiones de acceso y extienda el modelo gradualmente.
Esta secuencia convierte a zero trust en un modelo operativo en lugar de una colección de herramientas. También permite que los equipos de operaciones protejan la disponibilidad mientras maduran los controles de identidad, el WiFi seguro y la segmentación.
Sentar las bases con el descubrimiento y los límites de confianza
Comience con un inventario que refleje cómo funciona la organización, no cómo dice el diagrama de red que funciona. El NCSC recomienda identificar a los usuarios, los permisos requeridos, los dispositivos y los servicios, para luego diseñar la gestión de identidades y accesos en torno a esos hallazgos. La guía de migración del NCSC también orienta a los equipos a mapear las dependencias heredadas y a modelar las amenazas de la arquitectura propuesta antes del despliegue.
El resultado debe ser un catálogo funcional, no una hoja de cálculo estática. Registre el propietario, el propósito comercial, el método de autenticación, las dependencias, la sensibilidad de los datos, los usuarios previstos y el impacto de fallas para cada recurso importante.
Construir cuatro inventarios
Los usuarios e identidades son lo primero. Incluya a empleados, contratistas, administradores con privilegios, cuentas de servicio e identidades de automatización. Separe el estado laboral de una persona de su necesidad de acceso. Un contratista puede necesitar acceso a una aplicación durante un periodo definido, mientras que una cuenta de servicio puede requerir autenticación de máquina pero ningún inicio de sesión interactivo.
Los dispositivos necesitan su propia clasificación. Registre laptops administradas, dispositivos móviles, terminales compartidas, impresoras, cámaras, sistemas de automatización de edificios y otros equipos IoT. Tome nota de qué dispositivos admiten certificados, cifrado moderno e informes de postura de seguridad. El equipo heredado a menudo no puede cumplir con los requisitos de autenticación del personal, por lo que necesita una estrategia de contención explícita en lugar de una excepción sin registrar.
Las aplicaciones y los servicios deben mapearse de acuerdo con sus requisitos de identidad y transporte. Documente si cada aplicación admite SSO, MFA, protocolos modernos, certificados, acceso por proxy o solo un nombre de usuario y contraseña heredados. Identifique directorios ascendentes, bases de datos, servicios DNS, API y dependencias de registro.
Los flujos de datos y los recorridos empresariales revelan los límites de confianza. Trace cómo un miembro del personal llega a un sistema clínico, cómo un contratista accede a un portal de mantenimiento o cómo un dispositivo de punto de venta se comunica con los servicios aprobados. Un segmento no es significativo si una dependencia no documentada obliga a tener un acceso sin restricciones a través de él.
Definir límites antes de las políticas
Un límite de confianza debe responder a tres preguntas: qué se está protegiendo, quién necesita acceso y bajo qué condiciones. Las condiciones pueden incluir la garantía de identidad, el estado de salud del dispositivo, el contexto de red, la sensibilidad de la aplicación y la aprobación con límite de tiempo.
El WiFi de invitados, el IoT y los sitios multi-inquilino merecen especial atención. Los invitados nunca deben depender de las credenciales de red del personal. Los dispositivos IoT deben comunicarse únicamente con los servicios requeridos para su función. Los inquilinos pueden compartir la infraestructura física manteniendo el aislamiento lógico y una administración de identidad independiente.
El transporte seguro es importante en todos los límites. Si el equipo necesita un repaso en un lenguaje sencillo sobre certificados, cifrado y confianza del navegador, la guía de SSL de Adwave Digital es una referencia útil antes de documentar los supuestos de transporte de las aplicaciones y del WiFi.
Finalice el descubrimiento con un modelo de amenazas. Pruebe qué sucede si una cuenta de directorio se ve comprometida, un dispositivo administrado deja de ser seguro, se revoca un certificado, un controlador inalámbrico no está disponible o un servicio heredado no puede autenticarse con el nuevo proveedor de identidad. Esas rutas de falla deben definir el orden de implementación.
La construcción de la identidad y la postura del dispositivo como su plano de control
Las decisiones de zero trust necesitan una fuente de verdad. En la mayoría de las organizaciones, esto significa seleccionar el directorio que gobierna a las personas, los grupos y los eventos del ciclo de vida, como Microsoft Entra ID, Google Workspace o Okta. La decisión de diseño importante no es solo la marca. Es si cada sistema de acceso puede consumir el mismo estado de identidad y reaccionar cuando ese estado cambie.
Un usuario que deja la organización debe perder el acceso en todos los lugares importantes. Un contratista cuya asignación termina no debe permanecer activo en un sistema inalámbrico porque un administrador olvidó eliminar una cuenta separada. El aprovisionamiento y la revocación automáticos convierten los cambios de directorio en controles operativos en lugar de recordatorios administrativos.
Autenticar a la persona y al dispositivo
Comience con SSO y MFA para las aplicaciones de la fuerza laboral. MFA aumenta la garantía, mientras que SSO reduce la cantidad de credenciales que los usuarios y las mesas de ayuda deben administrar. El NCSC recomienda específicamente diseñar el IAM en torno a MFA y considerar la autenticación sin contraseña cuando sea adecuada. Los métodos sin contraseña pueden mejorar tanto la seguridad como la usabilidad, pero necesitan procedimientos de recuperación, controles de registro de dispositivos y soporte para los usuarios que pierden el acceso a su autenticador principal.
Para el WiFi del personal, la autenticación basada en certificados suele ser operativamente más sólida que las contraseñas compartidas. Con WPA2 o WPA3-Enterprise y 802.1X, la red puede vincular el acceso a una identidad registrada o a un certificado de dispositivo. Esto elimina la necesidad de distribuir una clave común y hace que la revocación sea precisa.
La postura del dispositivo añade la segunda mitad de la decisión. Verifique si el dispositivo está administrado, cifrado, actualizado, en cumplimiento y si utiliza un certificado aprobado. Un usuario válido en una laptop no administrada no debería recibir automáticamente el mismo acceso que ese usuario en un dispositivo corporativo en buen estado.
La identidad demuestra quién solicita el acceso. La postura del dispositivo determina si esa solicitud de acceso es lo suficientemente segura como para ser aprobada.
Diseñar eventos de ciclo de vida, no solo el inicio de sesión
La incorporación debe crear la identidad en el directorio, asignar los grupos correctos, registrar el dispositivo y emitir el certificado requerido a través de un flujo de trabajo automatizado. La desincorporación debe deshabilitar la identidad, revocar las sesiones y certificados, y eliminar el acceso a la red sin tener que esperar a un administrador de WiFi independiente.
Los contratistas necesitan un camino diferente. Otorgueles una membresía de grupo con un alcance limitado, un proceso de vencimiento o aprobación, y acceso únicamente a las aplicaciones y segmentos de red que requiere su trabajo. No resuelva la comodidad del contratista colocándolo en una red de personal general.
Los dispositivos heredados requieren contención. Cuando una impresora, sensor o terminal especializada no pueda utilizar la autenticación basada en certificados, utilice un segmento dedicado, reglas de firewall con alcance estricto y un mecanismo de identidad controlado como una clave individual precompartida. Esto mantiene la excepción visible y limita su radio de impacto.
Los equipos que evalúan el acceso a la red vinculado a la identidad pueden revisar el identity-based networking como un patrón de implementación. El principio de arquitectura sigue siendo el mismo, independientemente de la plataforma: el estado del directorio, la fuerza de la autenticación y el estado del dispositivo deben influir juntos en la decisión de acceso.
Segmentación y WiFi seguro que hace cumplir las políticas
La segmentación es necesaria, pero no puede imponer un acceso basado en la identidad por sí sola. El 92% de las organizaciones encuestadas en el Reino Unido afirman que segmentan sus redes hasta cierto punto, mientras que el 98% dice que planea implementar o ya ha implementado zero trust. La investigación del Reino Unido indica que la zonificación de redes está muy extendida, pero la garantía de identidad, la verificación continua y la aplicación de políticas siguen requiriendo atención.
Una VLAN separa el tráfico. No decide si una persona, dispositivo o sesión debe conservar el acceso. Si un usuario pasa de una laptop que cumple con las políticas a un dispositivo no administrado, el dispositivo puede permanecer en el mismo segmento a menos que el sistema de acceso evalúe la identidad y la postura de seguridad nuevamente.
Comparar los niveles de madurez
| Área de control | Implementación parcial | Madurez de Zero Trust |
|---|---|---|
| Diseño de red | VLANs o zonas amplias separan a invitados, personal y dispositivos | Políticas detalladas restringen el acceso a recursos y flujos específicos |
| Autenticación WiFi | Contraseñas compartidas, Captive Portals o claves estáticas | WPA2 o WPA3-Enterprise, 802.1X y acceso basado en certificados o identidad |
| Ciclo de vida del usuario | Los administradores crean y eliminan cuentas manualmente | Los cambios en el directorio aprovisionan y revocan el acceso de forma automática |
| Garantía del dispositivo | Un dispositivo se conecta si tiene la credencial de red correcta | El estado de salud y el certificado del dispositivo influyen en cada decisión de acceso |
| Respuesta a políticas | El acceso permanece activo hasta que una sesión o cuenta se modifica manualmente | Los cambios de contexto activan la reevaluación, restricción o revocación |
| Visibilidad | Los registros del controlador muestran eventos de conexión | Los eventos de identidad, dispositivo, política y recursos se correlacionan para su revisión |
Tratar el WiFi como un límite de identidad
El WiFi suele ser la primera decisión de acceso empresarial que encuentra un dispositivo. Dejarlo para el final del programa crea una brecha entre la política del directorio y la conectividad física.
Para el personal, utilice WPA2 o WPA3-Enterprise con 802.1X, respaldado por certificados u otro método de identidad sólido. El WiFi sin contraseña elimina los secretos compartidos de la experiencia del usuario, mientras que la autenticación basada en certificados vincula la conectividad a una identidad y un dispositivo registrados. Passpoint y OpenRoaming pueden admitir el roaming seguro al permitir que un dispositivo registrado se autentique sin tener que introducir una contraseña repetidamente.
El objetivo es una conectividad cifrada y vinculada a la identidad desde el primer paquete. Un Captive Portal que otorga acceso amplio después de que un usuario acepta los términos no proporciona ese control.
Para una revisión práctica de la seguridad WiFi empresarial, evalúe la distribución de certificados, la integración del proveedor de identidad, el manejo de revocaciones y la compatibilidad de los controladores. El diseño debe funcionar en toda la infraestructura, incluido el equipamiento Meraki, Aruba, Ruckus, Juniper Mist o UniFi.
Los invitados requieren una experiencia y una política independientes. Proporcione acceso a internet sin privilegios de personal. Los dispositivos IoT necesitan políticas restringidas que permitan únicamente los destinos y servicios requeridos para su operación.
Reevaluar el acceso de forma continua
El NCSC destaca la revaluación continua, la observabilidad y la resiliencia como requisitos explícitos de zero trust. Su guía de implementación de ZTNA respalda el cambio de acceso cuando cambia el contexto, en lugar de dejar los permisos fijos durante toda la sesión.
La integración del directorio debe admitir la revocación automática. Una cuenta deshabilitada, la eliminación de la membresía de un grupo o un certificado revocado deben activar actualizaciones de políticas sin esperar a que intervenga un administrador de WiFi independiente. El resultado puede ser una autenticación de paso mejorada, el traslado a una red restringida, el bloqueo de aplicaciones o la revocación inmediata del acceso.
La segmentación contiene el incidente. La identidad, el estado del dispositivo y la telemetría actual determinan si el acceso continúa. Esa combinación cierra la brecha entre la separación de red y el control real basado en la identidad.
Implementar el monitoreo y verificar cada decisión de acceso
Un despliegue seguro es controlado, observable y reversible. No comience aplicando una nueva política en cada usuario, sitio y categoría de dispositivo. Seleccione un grupo o ubicación de bajo riesgo que aún contenga suficiente complejidad real para exponer problemas, luego compruebe la ruta de acceso antes de expandirla.
Comience en modo de monitoreo donde la tecnología lo admita. Capture lo que la política permitiría y denegaría, compare esas decisiones con los requisitos comerciales e investigue las dependencias desconocidas. El modo de monitoreo no reemplaza la aplicación de políticas. Es una forma de eliminar sorpresas evitables antes de que la aplicación afecte a la producción.
Utilizar una migración por etapas
Una secuencia práctica se ve de la siguiente manera:
- Elija un piloto delimitado: Seleccione una aplicación, sitio o grupo de usuarios de bajo riesgo con un propietario conocido y una ruta de soporte clara.
- Registre el punto de partida: Capture la autenticación exitosa y fallida, el estado del dispositivo, el estado del certificado, la ubicación de la red, el resultado de la política y el resultado de la aplicación.
- Pruebe las rutas de denegación: Confirme que se bloqueen la MFA fallida, los certificados revocados, las identidades de directorio deshabilitadas y los dispositivos no conformes.
- Aplique de forma estricta: Aplique la política al piloto, con una condición de reversión documentada y un administrador que pueda revertir el cambio.
- Expanda por dependencia: Agregue grupos, sitios o servicios solo después de que la etapa anterior tenga registros estables y un proceso de soporte acordado.
La prueba piloto debe incluir pruebas de fallas. Desactive una identidad de prueba, elimine su membresía de grupo, marque un dispositivo como no conforme y revoque su certificado. Confirme que el acceso a la red, el acceso a las aplicaciones y las sesiones activas respondan según lo diseñado.
Hacer que la telemetría sea útil
Recopile eventos que expliquen las decisiones, no solo eventos que demuestren que se produjo una conexión. Como mínimo, correlacione la identidad solicitante, el identificador del dispositivo, el resultado de la autenticación, el estado del certificado, el resultado de la postura de seguridad, el segmento de red, el recurso de destino, la versión de la política y la decisión final.
Busque patrones que requieran revisión humana:
- Uso inesperado de identidad: un usuario accede a un recurso fuera de su rol normal o grupo aprobado.
- Cambios de postura: un dispositivo que antes cumplía con las normas pierde el estado de administración, cifrado o certificado.
- Fallos repetidos: ocurren fallos de autenticación o de postura en múltiples cuentas o ubicaciones.
- Excepciones de políticas: un dispositivo o servicio heredado depende repetidamente de una regla amplia.
- Retrasos en la revocación: una identidad de directorio deshabilitada sigue recibiendo acceso a la red o a la aplicación.
Utilice la descripción general de datos y seguridad de Purple al evaluar cómo una plataforma de WiFi basada en identidad maneja los datos de acceso, los controles de seguridad y la visibilidad operativa. Cualesquiera que sean las herramientas que seleccione, los dashboards deben respaldar las decisiones. Un registro que nadie revisa no mejorará la aplicación de las políticas.
Condición de reversión: Revierta una política cuando bloquee un proceso empresarial crítico, cree una dependencia insegura o produzca fallas de acceso inexplicables. Conserve la evidencia, corrija el diseño y vuelva a probar. No deje una excepción de emergencia abierta de forma permanente.
Proteger la disponibilidad como parte de la seguridad
El zero trust depende de los directorios, los servicios de certificados, los motores de políticas, los controladores de red y la conectividad. Incorpore resiliencia en cada dependencia. Defina qué sucede si el proveedor de identidad no está disponible, si los certificados no se pueden validar, si un controlador falla o si un servicio de políticas deja de estar disponible.
Utilice el diseño de servicio a prueba de fallas con cuidado. Algunos entornos necesitan que las sesiones existentes continúen brevemente durante una interrupción del servicio de identidad. Otros deben restringir el acceso de inmediato para recursos confidenciales. La elección correcta depende del recurso, del modelo de amenazas y de la consecuencia operativa.
Comunique antes de aplicar las medidas. Informe a los usuarios sobre qué cambiará, qué métodos de inicio de sesión utilizarán, cómo funciona el registro de dispositivos y dónde reportar fallas. Realice un seguimiento de los temas del helpdesk y los análisis de acceso después de cada fase. La reducción de la administración manual de cuentas, una menor cantidad de credenciales compartidas y una revocación más rápida son indicadores prácticos de que el modelo operativo está mejorando.
Su lista de verificación de implementación de Zero Trust y siguientes pasos
Un plan de implementación viable debería incluirse en el orden del día de la próxima reunión de arquitectura:
- Descubrir: Inventariar personas, cuentas de servicio, dispositivos, aplicaciones y servicios.
- Mapear dependencias: Documentar flujos de datos, métodos de autenticación, limitaciones heredadas y propietarios operativos.
- Definir límites: Separar el acceso de empleados, invitados, IoT y usuarios temporales según la necesidad de recursos.
- Reforzar la identidad: Seleccionar una fuente de verdad del directorio, exigir MFA e implementar SSO.
- Adoptar una autenticación más sólida: Guiar a los usuarios y dispositivos aptos hacia el acceso sin contraseña y basado en certificados.
- Automatizar el ciclo de vida: Aprovisionar desde grupos de directorios y revocar el acceso cuando cambien las identidades o los certificados.
- Evaluar la postura de seguridad: Verificar la gestión, el estado y el cumplimiento antes de otorgar acceso confidencial.
- Proteger el WiFi: Utilizar autenticación empresarial vinculada a la identidad en lugar de contraseñas compartidas para el personal.
- Contener dispositivos heredados: Colocar excepciones en segmentos restringidos con políticas de alcance limitado.
- Monitorear primero: Ejecutar políticas piloto en modo de observación y luego aplicarlas con criterios de reversión.
- Verificar continuamente: Probar el acceso denegado, la revocación, los cambios de postura de seguridad y las fallas del servicio.
- Expandir deliberadamente: Agregar sitios y cargas de trabajo solo cuando los registros, la propiedad y los procesos de soporte estén listos.
La decisión de implementación más importante es la secuenciación. No comience con el producto más visible o el segmento de red más grande. Comience con un trayecto que pueda comprender, medir y revertir. Para la hotelería y el comercio minorista, eso puede significar separar al personal, a los invitados y a los dispositivos operativos en un lugar físico en vivo. Para el sector salud, puede significar priorizar los controles de identidad y de dispositivos en torno a una aplicación confidencial. Para las viviendas multifamiliares, puede significar ofrecer un acceso simple a los residentes mientras se preserva el aislamiento entre los inquilinos y los sistemas del edificio.
Elija una plataforma cuando elimine una barrera de migración real. Si su infraestructura necesita WiFi sin contraseña, acceso para el personal integrado con el directorio, revocación automática y menor dependencia de un RADIUS de instalación local, evalúe si una plataforma como Purple se adapta a la arquitectura de red e identidad existente. Mantenga la decisión vinculada a sus objetivos de control, requisitos de integración y propiedad operativa.
Mida el progreso a través de evidencia, no de anuncios de implementación. Debería poder mostrar qué identidades tienen acceso, qué dispositivos son de confianza, qué políticas denegaron solicitudes, con qué rapidez surtió efecto la revocación y dónde permanecen las excepciones. Así es como zero trust se convierte en una capacidad operativa en lugar de otro programa de seguridad estancado.
Purple proporciona WiFi y redes basadas en la identidad que conectan al personal y los dispositivos con los directorios existentes, admite el acceso sin contraseña y de nivel de certificado, y puede automatizar el aprovisionamiento y la revocación a medida que cambia el estado del directorio. Visite Purple para evaluar cómo su autenticación de WiFi, postura de dispositivo e integraciones de red podrían respaldar una implementación gradual de zero trust.
