El término "confianza cero" sigue confundiendo a la gente—y con razón.Aunque el término transmite cierta autoridad absoluta ("cero", "no", "nada"), los enfoques contemporáneos ofrecen capacidades mucho más matizadas. Y aunque hoy en día la confianza cero se asocia típicamente a las iniciativas de seguridad, los conceptos tienen su origen en la definición de los perímetros de la red, a quién se le concede acceso y cómo se proporciona ese acceso.
La evolución de la seguridad no ha sido de la confianza implícita a la no confianza, sino más bien hacia controles contextuales que conceden a las personas adecuadas el acceso adecuado a los recursos adecuados en el momento adecuado y por las razones adecuadas. Pero, en última instancia, para dar sentido a la confianza cero es necesario comprender cómo ha cambiado el papel de la red y la infraestructura con respecto a los objetivos críticos de la seguridad en los últimos años.
El papel cambiante de la red: una breve historia
En los primeros tiempos de la construcción de redes y la definición del perímetro corporativo, todas las empresas eran esencialmente islas. Construían redes corporativas para facilitar las interacciones entre los empleados y los datos que estaban todos en las instalaciones locales. Cuando llegó Internet, todo el mundo quiso participar en ella. Pero las empresas se dieron cuenta rápidamente de que la confianza implícita por defecto de Internet iba a causar problemas a la hora de protegerse de personas ajenas con intenciones maliciosas.
El primer paso natural fue utilizar la red para crear puntos de demarcación. Las arquitecturas evolucionaron hasta incluir algo llamado DMZ, que tiene una función similar a la de las zonas desmilitarizadas del mundo físico (como la franja de tierra de 2,5 millas de ancho entre Corea del Norte y Corea del Sur, cuyo aislamiento natural creó un parque involuntario que ahora se considera una de las zonas con un hábitat tranquilo mejor conservadas del mundo). Este tipo de arquitectura de "castillo y foso" funcionó realmente durante mucho tiempo. Pero luego, a medida que las empresas evolucionaban y requerían una conectividad constante con otras empresas, socios, proveedores e incluso con sus propios clientes en determinadas circunstancias—se necesitaban nuevos modelos.
Hubo muchos intentos de crear estos nuevos patrones a lo largo de los años. El Foro de Jericó promovió la “desperimetrización” a principios de la década de 2000. Unos años más tarde, escribí sobre "la muerte de la DMZ" y realicé algunas presentaciones en Microsoft TechEd en las que abogaba por autenticar a cada persona y sistema, autorizar todas las acciones y comportamientos, auditar cada actividad y transacción, y cifrar cuando fuera necesario. (Aunque hoy en día, cambiaría esto último por cifrar todo el tiempo).
Luego llegó la red basada en confianza cero . Esto era útil—pero todavía se estaba pensando más en algo parecido a controlar con “puertas” el acceso a las redes. La iniciativa BeyondCorp de Google proponía: "¿Qué pasaría si la gente estuviera siempre en Internet, aunque estuviera en la oficina?". En realidad, sólo obtienen una conexión a Internet; todas las solicitudes para interactuar con las aplicaciones deben fluir a través de algún tipo de intermediario. Entonces apareció Zero Trust eXtended (ZTX) de Forrester. Gartner ofreció su propia versión inicial del concepto, que se denominó CARTA (por sus siglas en inglés, evaluación adaptativa continua de riesgos y confianza).
Luego, la aparición de la arquitectura del perímetro definido por software hizo que el concepto de confianza cero fuera mucho más relevante. El perímetro definido por software ligó las personas a las aplicaciones—independientemente de cómo fuera la infraestructura de red subyacente. Esto abrió nuevas posibilidades.
Como resultado, pronto surgió el mercado de Zero Trust Netwok Access (acceso a la red basado en confianza cero o ZTNA). Ahora mismo, estamos viendo mucho énfasis en el ZTNA—que surgió a raíz de la COVID, cuando de repente todo el mundo tenía que trabajar desde casa. Aunque la mayoría de las empresas intentaron inicialmente ampliar su VPN para hacer frente a este cambio inmediato, lo que encontraron fue que sus concentradores VPN eran frágiles. No habían sido actualizados o parcheados en un tiempo, lo que significaba que podían ser vulnerables. Pero incluso si las empresas podían ampliar con seguridad sus capacidades de concentración de VPN, seguían enfrentándose a las limitaciones de ancho de banda derivadas del retorno del tráfico a sus instalaciones para la seguridad. Y era especialmente ineficaz porque la mayor parte de ese tráfico tenía que volver a salir a las aplicaciones de software como servicio (SaaS) o a la web.
Dejar que la red haga lo que mejor sabe hacer
ZTNA trascendió las limitaciones de las VPN. Me equivoqué en 2019 cuando dije que ZTNA sustituiría a las VPN. Cambié mi opinión en 2020 para decir que ZTNA mejoraría las VPN porque todavía hay razones legítimas cuando alguien necesita una VPN para acceder a la red (como para la administración de la red o cuando se hace un análisis de rendimiento). Pero en la gran mayoría de los casos, no es necesario estar en la red, sólo se necesita acceder a una aplicación. ZTNA le da ese acceso sin ningún tipo de dependencia de la arquitectura de red subyacente.
Esta desvinculación (y desahogo) supuso que los responsables de la red no tuvieran que preocuparse por las políticas individuales de control de acceso a las aplicaciones. El propietario de la aplicación crea las políticas y define a quién se le permite interactuar, así como las condiciones que indican el nivel de acceso (por ejemplo, completo, reducido, aislado, ninguno). Esa responsabilidad ya no tiene que recaer en el gestor de la red—que de todos modos puede no estar preparado para tomar esas decisiones para las aplicaciones.
Al mismo tiempo, los responsables de la red pueden centrarse más en las cosas que hacen realmente bien, como la alta disponibilidad, asegurándose de que la red es fiable y de que funciona bien a la hora de llevar los bits a donde tienen que ir. Además, el departamento de redes también puede ayudar a los propietarios de las aplicaciones a garantizar experiencias más consistentes. Las personas interactúan con las aplicaciones exactamente de la misma manera, estén donde estén: en la oficina—en una cafetería, en un avión o en casa.
El curioso caso del descubrimiento del IoT
Reflexionemos por un momento sobre el Internet de las cosas (IoT). Si una empresa afirma haber resuelto el problema de descubrir todos sus dispositivos IoT, yo diría que es una afirmación de ignorancia. La mayoría de las empresas tienen un conocimiento limitado de los dispositivos IoT en sus redes hoy en día. La mala visibilidad es la raíz—y las raíces llegan lejos.
Más allá de encontrar todos esos dispositivos, la visibilidad efectiva requiere averiguar con qué están hablando y qué está respondiendo. Aunque esto es algo muy natural para los responsables de las redes, encontrar al propietario de un dispositivo IoT puede ser muy difícil. Los dispositivos IoT son como los conejos—se multiplican y luego se olvidan de su parentesco. La forma tradicional de gestionar los dispositivos IoT (trasladarlos a su propia subred) no ofrece ningún alivio. Mientras que el propietario de una aplicación puede tener sólo una o dos aplicaciones a su cargo, las personas que gestionan dispositivos IoT pueden tener miles. Una vez desplegados, suelen perder la pista de al menos algunos de ellos. ¿Quién se hace responsable de su administración?
Si hubiera una forma de que un gestor de redes (re)descubriera automáticamente todos los dispositivos IoT y, sobre todo, los flujos de comunicación entre ellos, entonces podríamos asignarlos en diferentes clasificaciones con los correspondientes niveles de protección requeridos. Los responsables de la red podrían proponer si un dispositivo IoT es "seguro" o "de riesgo" (o incluso definir un espectro de diferentes clases de control entre "seguro" y "de riesgo").
Un objetivo: la red es la seguridad
Los departamentos de seguridad no quieren preocuparse por los detalles de la conectividad y los responsables de la red no quieren preocuparse por las políticas de seguridad. Por eso, si se separan y se permite que cada dominio se concentre en sus tareas especializadas, cada departamento puede ayudar al otro a tener éxito sin pisar ningún pie.
La seguridad debería ayudar a los responsables de las redes a ofrecer ubicuidad, resiliencia y rendimiento. En el peor de los casos, si los departamentos se equivocan en los aspectos de acceso y rendimiento, el riesgo de que la gente se salte los controles de seguridad es grande. E incluso en el mejor de los casos, la seguridad en islas es un cuello de botella que obstaculiza el negocio, disminuye la agilidad de las TI y reduce la productividad y la capacidad de respuesta a los clientes. Los servicios de ZTNA facilitan la convergencia de la red y la seguridad, al igual que herramientas como la gestión de la experiencia digital (DEM), que facilitan la resolución de problemas y garantizan que sus usuarios se mantengan seguros mientras disfrutan de una experiencia superior. DEM reduce el tiempo que se tarda en diagnosticar y cerrar un ticket del servicio de soporte, agilizando las operaciones de seguridad y de red.
El objetivo final es que la seguridad se centre en los controles, que las redes se centren en la experiencia—y que todos en la empresa se mantengan seguros, felices y productivos.
