En el Reino Unido, el 98 % de las organizaciones afirman que planean implementar o ya han implementado zero trust, aunque solo el 15 % informa de una implementación completa. La brecha no es la concienciación. Es la ejecución. La investigación sobre zero trust en el Reino Unido muestra que muchos equipos han comenzado la planificación, la segmentación o proyectos de identidad aislados sin conectar esos controles en un único modelo operativo.
La pregunta práctica no es si el modelo zero trust es importante. Es cómo implementar zero trust sin interrumpir los servicios en directo, frustrar a los usuarios o crear otra colección de productos de seguridad desconectados. La respuesta consiste en 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 fase inicial de planificación, mientras que solo el 15% afirma haber completado la implementación, y el 80% se ha enfrentado a barreras técnicas u operativas. El informe de las organizaciones del Reino Unido muestra la brecha que existe entre elegir una dirección y operar los controles necesarios. Los equipos suelen empezar con proyectos aislados y luego descubren que la identidad, los dispositivos, los directorios, las aplicaciones y las redes dependen unos de otros.
El modelo 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 necesiten. Un servicio no debe seguir siendo de confianza indefinidamente solo por haber superado un control de autenticación único.
El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) define el zero trust como una migración por etapas y no como la compra de un producto. Su guía de arquitectura define ocho principios de diseño, que incluyen decisiones de acceso basadas en 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 obligan a los equipos a definir las decisiones de arquitectura y confianza antes de elegir la tecnología.
El modo de fallo centrado en el producto
El patrón de fallo suele comenzar con la compra de una plataforma. Un equipo implementa un producto de identidad, una herramienta de segmentación o una pasarela ZTNA, y luego descubre que las cuentas de servicio, los dispositivos no gestionados, las aplicaciones heredadas, la autenticación de red inalámbrica y la baja de directorios nunca se habían mapeado.
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 uniforme. 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 se siguen uniendo 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, vinculada a los registros del dispositivo y al estado del directorio, proporciona a la política una señal de identidad fiable. La revocación automática del directorio debería entonces eliminar el acceso cuando se deshabilita una cuenta, en lugar de esperar a una limpieza manual.
Los controles perimetrales tradicionales siguen desempeñando un papel, pero no pueden responder a todas las preguntas de acceso. 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 redacte políticas de aplicación de control hasta que sepa qué identidades, dispositivos, WiFi y dependencias de 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 los límites: decida qué recursos requieren aislamiento y qué rutas de acceso son legítimas.
- Construya el plano de control: conecte la identidad, la MFA, el acceso a dispositivos basado en certificados, las comprobaciones 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 amplíe el modelo gradualmente.
Esta secuencia convierte zero trust en un modelo operativo en lugar de una colección de herramientas. También permite a los equipos de operaciones proteger la disponibilidad mientras maduran los controles de identidad, el WiFi seguro y la segmentación.
Sentando las bases con el descubrimiento y los límites de confianza
Comience con un inventario que refleje cómo funciona la organización en la realidad, 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 función de esos resultados. 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 de trabajo, no una hoja de cálculo estática. Registre el propietario, el propósito empresarial, el método de autenticación, las dependencias, la sensibilidad de los datos, los usuarios previstos y el impacto de un posible fallo para cada recurso importante.
Elabore 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 período 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 los portátiles gestionados, los dispositivos móviles, las terminales compartidas, las impresoras, las cámaras, los sistemas del edificio y otros equipos de IoT. Anote qué dispositivos admiten certificados, cifrado moderno e informes de estado de seguridad. El equipamiento 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 no rastreada.
Las aplicaciones y los servicios deben asignarse a sus requisitos de identidad y transporte. Documente si cada aplicación admite SSO, MFA, protocolos modernos, certificados, acceso proxy o únicamente un nombre de usuario y contraseña antiguos. Identifique los directorios ascendentes, las bases de datos, los servicios DNS, las API y las dependencias de registro.
Los flujos de datos y los trayectos empresariales revelan los límites de confianza. Trace cómo accede un miembro del personal a un sistema clínico, cómo accede un contratista a un portal de mantenimiento o cómo se comunica un dispositivo de punto de venta con los servicios autorizados. Un segmento no es útil si una dependencia no documentada obliga a permitir un acceso sin restricciones a través de él.
Defina los límites antes que 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 del dispositivo, el contexto de red, la sensibilidad de la aplicación y la aprobación de duración limitada.
El WiFi de invitados, el IoT y los entornos multiinquilino 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 necesarios para su función. Los inquilinos pueden compartir la infraestructura física manteniendo el aislamiento lógico y una gestión de identidad independiente.
El transporte seguro es importante en todos los límites. Si el equipo necesita un repaso sencillo sobre certificados, cifrado y confianza del navegador, la guía de SSL de Adwave Digital es una referencia útil antes de documentar las premisas de transporte de WiFi y aplicaciones.
Finalice la fase de descubrimiento con un modelo de amenazas. Pruebe qué ocurre si se ve comprometida una cuenta de directorio, si un dispositivo gestionado deja de estar en un estado correcto, si se revoca un certificado, si una controladora inalámbrica no está disponible o si un servicio heredado no puede autenticarse ante el nuevo proveedor de identidad. Esas rutas de fallo deberían definir el orden de implantación.
La identidad y el estado del dispositivo como plano de control
Las decisiones de zero trust necesitan una fuente de verdad. En la mayoría de las infraestructuras, eso significa seleccionar el directorio que gestiona 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 cambia.
Un usuario que abandona la organización debería perder el acceso en todos los lugares importantes. Un contratista cuya asignación finaliza no debería seguir activo en un sistema inalámbrico porque un administrador olvidó eliminar una cuenta independiente. El aprovisionamiento y la revocación automáticos convierten los cambios de directorio en controles operativos en lugar de recordatorios administrativos.
Autentique a la persona y al dispositivo
Comience con SSO y MFA para las aplicaciones de los empleados. El MFA aumenta la seguridad, mientras que el SSO reduce el número de credenciales que deben gestionar los usuarios y los equipos de soporte. El NCSC recomienda específicamente diseñar el IAM en torno al MFA y considerar la autenticación sin contraseña cuando sea adecuado. Los métodos sin contraseña pueden mejorar tanto la seguridad como la usabilidad, pero requieren 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 robusta 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 permite realizar revocaciones precisas.
El estado de seguridad del dispositivo completa la otra mitad de la decisión. Verifique si el dispositivo está gestionado, cifrado, actualizado, cumple con las directivas y utiliza un certificado aprobado. Un usuario válido en un ordenador portátil no gestionado no debería recibir automáticamente el mismo nivel de acceso que ese mismo usuario en un dispositivo corporativo en estado óptimo.
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ñe eventos de ciclo de vida, no solo de 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 mediante un flujo de trabajo automatizado. La baja debe deshabilitar la identidad, revocar sesiones y certificados, y eliminar el acceso a la red sin tener que esperar a que intervenga un administrador de WiFi.
Los contratistas necesitan un camino diferente. Concédales una pertenencia a grupos con un alcance estrictamente delimitado, un proceso de caducidad o aprobación y acceso únicamente a las aplicaciones y segmentos de red que requiera su trabajo. No resuelva la comodidad de los contratistas colocándolos en una red general para el personal.
Los dispositivos heredados necesitan contención. Cuando una impresora, un sensor o un terminal especializado no pueda utilizar la autenticación basada en certificados, utilice un segmento dedicado, reglas de cortafuegos de ámbito estricto y un mecanismo de identidad controlado, como una clave precompartida individual. 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 las redes basadas en la identidad en 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 seguridad de la autenticación y el estado del dispositivo deben influir juntos en la decisión de acceso.
Segmentación y WiFi segura que aplica las políticas
La segmentación es necesaria, pero no puede imponer por sí sola un acceso basado en la identidad. El 92 % de las organizaciones del Reino Unido encuestadas afirman que segmentan sus redes en cierta medida, mientras que el 98 % declara que tiene previsto implementar o ya ha implementado zero trust. La investigación en el 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 mantener el acceso. Si un usuario pasa de un portátil conforme a un dispositivo no gestionado, el dispositivo puede permanecer en el mismo segmento a menos que el sistema de acceso evalúe de nuevo la identidad y la postura.
Compare los niveles de madurez
| Área de control | Implementación parcial | Madurez de Zero Trust |
|---|---|---|
| Diseño de red | VLAN o zonas amplias que separan a los invitados, al personal y a los dispositivos | Políticas detalladas que restringen el acceso a recursos y flujos específicos |
| Autenticación WiFi | Contraseñas compartidas, Captive Portal o claves estáticas | Acceso basado en WPA2 o WPA3-Enterprise, 802.1X y 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 del dispositivo y el del certificado influyen en cada decisión de acceso |
| Respuesta de políticas | El acceso permanece activo hasta que una sesión o cuenta se modifica manualmente | Los cambios de contexto activan la reevaluación, la restricción o la revocación |
| Visibilidad | Los registros del controlador muestran eventos de conexión | Se correlacionan los eventos de identidad, dispositivo, política y recursos para su revisión |
Trate la WiFi como un límite de identidad
La WiFi suele ser la primera decisión de acceso empresarial que encuentra un dispositivo. Dejarla 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 las claves compartidas 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 introducir repetidamente una contraseña.
El objetivo es una conectividad cifrada y vinculada a la identidad desde el primer paquete. Un Captive Portal que concede un acceso amplio después de que el usuario acepte los términos no proporciona ese control.
Para una revisión práctica de la seguridad de WiFi empresarial, evalúe la distribución de certificados, la integración del proveedor de identidad, la gestión de revocaciones y la compatibilidad de las controladoras. El diseño debe funcionar en toda la infraestructura, incluido el equipamiento de Meraki, Aruba, Ruckus, 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 solo permitan los destinos y servicios requeridos para su funcionamiento.
Vuelva a evaluar 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 desactivada, la eliminación de la pertenencia a 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 reforzada, 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 la red y el control real basado en la identidad.
Implementación de la monitorización y verificación de cada decisión de acceso
Un despliegue seguro debe ser controlado, observable y reversible. No empiece aplicando una política nueva a todos los usuarios, sedes y categorías de dispositivos. Seleccione un grupo o ubicación de bajo riesgo que contenga suficiente complejidad real como para revelar problemas, y luego valide la ruta de acceso antes de expandirla.
Comience en modo de monitorización cuando la tecnología lo admita. Registre lo que la política permitiría y denegaría, compare esas decisiones con los requisitos empresariales e investigue las dependencias desconocidas. El modo de monitorización no sustituye a la aplicación de políticas. Es una forma de eliminar sorpresas evitables antes de que la aplicación afecte a producción.
Utilice una migración gradual
Una secuencia práctica tiene el siguiente aspecto:
- Elija un piloto acotado: seleccione una aplicación, sitio o grupo de usuarios de bajo riesgo con un propietario conocido y una ruta de soporte clara.
- Registre la línea base: capture las autenticaciones exitosas y fallidas, el estado del dispositivo, el estado de los certificados, la ubicación en 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 las MFA fallidas, los certificados revocados, las identidades de directorio deshabilitadas y los dispositivos no compatibles.
- 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.
El piloto debe incluir pruebas de fallos. Desactive una identidad de prueba, elimine su pertenencia al 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.
Haga 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 del solicitante, el identificador del dispositivo, el resultado de la autenticación, el estado del certificado, el resultado del análisis de postura, 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 la identidad: un usuario accede a un recurso fuera de su rol habitual o de su grupo aprobado.
- Cambios en el estado de seguridad: un dispositivo que antes cumplía con las normativas pierde su estado de gestión, cifrado o certificado.
- Fallos repetidos: se producen fallos de autenticación o de estado en múltiples cuentas o ubicaciones.
- Excepciones de políticas: un dispositivo o servicio heredado depende continuamente de una regla demasiado amplia.
- Retrasos en la revocación: una identidad de directorio desactivada sigue teniendo acceso a la red o a las aplicaciones.
Utilice la descripción general de datos y seguridad de Purple al evaluar cómo una plataforma de WiFi basada en la identidad gestiona los datos de acceso, los controles de seguridad y la visibilidad operativa. Sean cuales sean las herramientas que seleccione, los paneles de control deben servir para respaldar las decisiones. Un registro que nadie revisa no mejorará la aplicación de las políticas.
Condición de reversión: revoque una política cuando bloquee un proceso empresarial crítico, cree una dependencia insegura o produzca fallos de acceso inexplicables. Conserve las pruebas, corrija el diseño y vuelva a realizar las pruebas. No deje abierta una excepción de emergencia de forma permanente.
Proteja la disponibilidad como parte de la seguridad
El modelo zero trust depende de directorios, servicios de certificados, motores de políticas, controladores de red y conectividad. Diseñe cada dependencia pensando en la resiliencia. Defina qué ocurre si el proveedor de identidad no está disponible, si no se pueden validar los certificados, si falla un controlador o si un servicio de políticas deja de estar accesible.
Diseñe con cuidado los mecanismos de seguridad ante fallos. Algunos entornos requieren que las sesiones existentes continúen activas brevemente durante una caída del servicio de identidad. Otros deben restringir el acceso de inmediato para los recursos sensibles. La elección correcta depende del recurso, del modelo de amenazas y de las consecuencias operativas.
Comuníquese antes de aplicar las medidas. Explique a los usuarios qué va a cambiar, qué métodos de inicio de sesión utilizarán, cómo funciona el registro de dispositivos y dónde informar de los fallos. Realice un seguimiento de las tendencias del servicio de asistencia y de las analíticas de acceso después de cada fase. La reducción de la administración manual de cuentas, el menor uso de credenciales compartidas y la revocación más rápida son indicadores prácticos de que el modelo operativo está mejorando.
Su lista de comprobación para la 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 del personal, los invitados, IoT y los inquilinos según las necesidades de recursos.
- Reforzar la identidad: Seleccionar una fuente de verdad del directorio, imponer MFA e introducir SSO.
- Adoptar una autenticación más sólida: Llevar a los usuarios y dispositivos adecuados hacia un 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: Comprobar la gestión, el estado y el cumplimiento antes de conceder acceso sensible.
- Proteger la WiFi: Utilizar la autenticación corporativa vinculada a la identidad en lugar de contraseñas compartidas del personal.
- Contener dispositivos heredados: Colocar las excepciones en segmentos restringidos con políticas de ámbito estrecho.
- 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 y los fallos del servicio.
- Expandir deliberadamente: Añadir 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 empiece con el producto más visible o el segmento de red más grande. Comience con un recorrido que pueda comprender, medir y revertir. Para el sector hotelero y de retail, eso puede significar separar al personal, a los invitados y los dispositivos operativos en un espacio físico real. Para el sector sanitario, puede significar priorizar los controles de identidad y de dispositivos en torno a una aplicación sensible. Para las viviendas de alquiler compartido, puede significar ofrecer un acceso sencillo a los residentes preservando al mismo tiempo el aislamiento entre los inquilinos y los sistemas del edificio.
Elija una plataforma cuando elimine una barrera de migración real. Si sus instalaciones necesitan WiFi sin contraseña, acceso del personal integrado en el directorio, revocación automática y una menor dependencia de un RADIUS 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 evidencias, no mediante anuncios de implementación. Debería poder demostrar 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 se mantienen las excepciones. Así es como zero trust se convierte en una capacidad operativa en lugar de en 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 con calidad 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 WiFi, el estado de seguridad de los dispositivos y las integraciones de red podrían respaldar un despliegue progresivo de zero trust.
