Security Service Edge: cuatro principios básicos para el viaje SASE

El Servicio de Seguridad en el Borde (Security Service Edge - SSE) es un concepto transcendental para entender el viaje hacia la arquitectura de borde de servicio de acceso seguro o SASE. Gartner acuñó este término para referirse a los cambios que son necesarios realizar en la pila de seguridad para lograr con éxito una arquitectura SASE. De este modo, SSE incluye el agente de seguridad de acceso a la nube (CASB), el gateway de seguridad web (SWG), el cortafuegos como servicio y el acceso a la red basado en confianza cero (ZTNA); todos ellos requisitos fundamentales para esa pila.

Sin embargo, alejémonos un poco y entendamos qué tiene que ocurrir con SSE más allá de la discusión de los requisitos tecnológicos básicos, y examinemos su relevancia para las grandes informaciones en torno a SASE y a la confianza cero.

SSE: cómo mantener los datos seguros

Hace años, los dispositivos de inspección de seguridad más importantes eran los cortafuegos, los proxies web locales, los sandbox, los sistemas de gestión de eventos e información de seguridad (SIEM) y las herramientas de seguridad para dispositivos de usuarios. Sin embargo, ahora, cuando la cantidad de datos que se encuentra fuera del cortafuegos corporativo crece rápidamente -y este último, además, no puede entender el tráfico de la nube- y muchos endpoints que se conectan tanto a la Web como a los recursos corporativos y a los datos son BYOD, los puntos de control heredados no pueden proporcionar una imagen completa de lo que ocurre con los datos.

Seguridad en la nube, por principio

Para analizar cómo SSE resuelve lo que la seguridad debe hacer en este nuevo mundo en el que es crucial mantener los datos protegidos en la nube, deben seguirse varios principios.

La seguridad debe seguir a los datos: En la actualidad existe gran cantidad de tráfico que un proxy web o un cortafuegos tradicional no puede entender o incluso ver. Asimismo, hay usuarios en todas partes, aplicaciones que están en múltiples nubes y datos a los que se accede desde cualquier lugar. Por ello, es importante disponer de un punto de inspección de seguridad que siga a los datos allá donde estos vayan, de forma absoluta. Por tanto, este punto de inspección tiene que estar en la nube para que sus beneficios puedan llegar a los usuarios y a las aplicaciones.

La seguridad debe ser capaz de decodificar el tráfico en la nube: Decodificar el tráfico de la nube significa que la seguridad debe permitir visualizar e interpretar el tráfico JSON de la API, algo que los proxies web tradicionales y los cortafuegos no pueden hacer.

La seguridad debe posibilitar la comprensión del contexto del acceso a los datos: Es preciso ir más allá del mero control de quién tiene acceso a la información y avanzar hacia controles de acceso y políticas continuos y en tiempo real que se adapten de forma permanente en función de factores como los propios usuarios, los dispositivos que utilizan, las aplicaciones a las que acceden, la actividad, la instancia de la aplicación (empresa o personal), la sensibilidad de los datos, las señales del entorno como la geolocalización y la hora del día, y las amenazas presentes. Todo esto forma parte de la comprensión, en tiempo real, del contexto con el que intentan acceder a los datos.

La seguridad no puede ralentizar la red: El usuario requiere obtener sus datos rápidamente, y la red tiene que ser fiable. Si la seguridad ralentiza el acceso o la operatividad, la productividad se resentirá y los empleados comenzarán a cambiar los controles de seguridad por la velocidad y la fiabilidad de la red. Uno podría pensar que mantener la seguridad rápida es tan sencillo como trasladar los controles de seguridad a la nube, pero no es tan sencillo. En última instancia, la nube acaba atravesando un lugar sucio llamado Internet, y eso puede causar toda una serie de problemas de enrutamiento y exposición. Aquí es donde entran en juego las redes privadas, que pueden garantizar una ruta fluida y eficiente desde el usuario final hasta el destino, y viceversa.

SSE permite  recuperar la ventaja

A causa de todas estas necesidades, el perímetro tradicional ha desaparecido, y es necesario mover el punto de inspección. SSE proporciona ese punto de inspección, o más bien muchos puntos de inspección distribuidos que se acercan lo más posible a dónde y cómo se accede a los datos, ya sea en la nube o en una aplicación privada.

Esto tiene profundas implicaciones en la forma de diseñar la seguridad y la infraestructura, y explica por qué ahora son necesarios SSE y SASE para organizarla. De hecho, se ha de plantear así: Si el 90% del gasto en seguridad se destina a proteger lo que está dentro de las instalaciones, pero el 50% de las aplicaciones y el 90% de los usuarios están fuera de ella, la seguridad se está estirando como una goma elástica. Claramente, esta estrategia creará tensión para el negocio y conducirá a una eventual ruptura de la seguridad. No funcionará.

También, y en relación con el último principio que hace referencia a la red, es necesario asumir que, si antes los datos corporativos se encontraban en la red interna, y esta era segura, ahora, muchos datos y usuarios están fuera de esa red, por lo que hay que llegar más allá. Esto no obvia, no obstante, la necesidad de la seguridad de la red ni margina la importancia de cosas como el control de acceso. Sólo significa que algunas de las líneas se están desdibujando y tenemos que tenerlo en cuenta.

Con SSE, los puntos de inspección de Internet están en su sitio, está consolidando sus capacidades de inspección de la nube y de la Web y de los datos y, lo que es más importante, todas esas capacidades de inspección se disparan de manera simultánea: todas al mismo tiempo, no secuencialmente o de una en una.

Jason Clark, Chief Security Officer & Chief Strategy Officer, Netskope