Parece que fue ayer cuando oímos hablar por primera vez de SSE. La propuesta de consumir servicios de red y seguridad desde la nube era atractiva y resonaba en el mercado. No es de extrañar que los proveedores de servicios de Internet (ISP) empezaran a explorar cómo podían ofrecer un conjunto de servicios SASE. Avancemos hasta hoy y todos estamos observando cómo las empresas reciben el Servicio de Seguridad en el Borde (SSE) como una nueva categoría de producto. Gartner anunció recientemente el primer Cuadrante Mágico para SSE y los departamentos de gestión de producto de los ISP están debatiendo lo que significa SSE para su negocio. ¿Se trata de otra amenaza competitiva de los proveedores de servicios en la nube? ¿O es una oportunidad para introducir un nuevo servicio en el mercado? O, espere, ¿qué significa esto para el servicio SASE gestionado que acabo de lanzar?
Como probablemente ya sabe, SSE es una mitad del entorno SASE. Es el cerebro que integra un conjunto específico de servicios de seguridad como el agente de seguridad de acceso a la nube (CASB), la gateway de seguridad web (SWG), el acceso a la red basado en confianza cero (ZTNA), el aislamiento remoto del navegador (RBI), y un firewall en la nube (CFW). La otra mitad de SASE se compone de Servicios WAN en el Borde—SD-WAN, optimización de aplicaciones, conectividad y todo lo relacionado con la red. En pocas palabras, SSE + Servicios WAN en el Borde = SASE.
Por qué los proveedores de servicios están bien posicionados para un entorno SASE
La simple lógica nos lleva a la conclusión de que, si un proveedor de servicios ofrece SASE gestionado, debería tener capacidades SSE como parte de él. Pero los problemas, como siempre, se esconden detrás de los detalles. Gartner, que acuñó los términos SASE y SSE, esboza las siguientes propiedades de una estrategia SASE con garantía de futuro basada en SSE:
- Aplicación coherente de las políticas, independientemente de la ubicación
- Plano de control de políticas consolidado
- Visibilidad y control de los datos sensibles
Por lo tanto, si ya ofrece un servicio SASE gestionado, ahora es un buen momento para comparar sus capacidades con estos requisitos para asegurarse de que su servicio va más allá de ofrecer productos separados y cumple con las últimas exigencias.
Pero, ¿y si no tiene una oferta SASE y, sin embargo, ve la demanda del mercado? Su departamento de ventas habla de las consultas de los clientes en torno a SASE. Su departamento de marketing comparte emocionantes previsiones sobre cómo crecerá el tamaño del mercado SASE durante los próximos cinco años. Y como autoridad en el diseño de servicios, usted se pone delante de la pizarra y se pregunta: ¿cómo puedo ofrecer un servicio atractivo? ¿Cómo utilizo los puntos fuertes de mi empresa—los servicios de conectividad amplios y maduros—para mantenerme a la vanguardia?
La buena noticia es que los proveedores de servicios están muy bien posicionados para dar vida al entorno SASE ofreciendo un servicio integral. En lugar de ofrecer un mosaico de varias soluciones que aborden casos de uso de nicho, puede utilizar el amplio alcance de su red y su experiencia en el servicio a grandes mercados para introducir un servicio coherente que siga el espíritu de SASE—conectar a CUALQUIER usuario con CUALQUIER servicio en la nube y garantizar la protección de los datos. Puede abarcar todo tipo de tecnologías de acceso y proporcionar el mismo nivel de visibilidad y gestión de políticas con un SLA obligado por contrato. Utilizando la terminología SD-WAN, al controlar tanto la parte interior como la capa exterior de la conectividad del cliente, puede ofrecer un mejor SLA y resolver cualquier problema más rápidamente.
Cómo los proveedores de servicios pueden integrar capacidades SSE en SASE
Para tratar de reducir el tiempo de comercialización, podría considerar la posibilidad de posicionar sus capacidades actuales de Servicios WAN en el Borde como SSE. Es probable que su oferta actual de SD-WAN cuente con algunas capacidades de seguridad, como el firewall o UTM (de nueva generación)—sin embargo, no se equivoque, esas capacidades por sí solas no podrían considerarse SSE.
SSE va mucho más allá de las capacidades de las capacidades puntuales de un firewall, ofreciendo más controles de seguridad para un conjunto más amplio de casos de uso. La combinación de CASB y SWG permite crear una política única para controlar el tráfico de la nube y la web para cualquier aplicación y cualquier usuario. El aislamiento remoto del navegador y el acceso a la red basado en confianza cero forman parte de esta política, aprovechando el contexto de los datos recogidos por CASB/SWG. Todos estos servicios están estrechamente integrados en SSE en torno al concepto de protección de datos.
Entonces, ¿cómo se despliega un servicio SSE? ¿A qué segmentos de clientes piensa dirigirse? ¿Va a utilizar diferentes soluciones para diferentes tipos de clientes? ¿Qué stack de tecnología debe utilizarse? ¿Puede implementarse SSE utilizando los principios de NFV (o virtualización de las funciones de red) como una cadena de servicio de VNFs (funciones de red virtualizadas) y seguridad o CNFs (funciones de red nativas en la nube)? ¿Debe ejecutarse en una nube pública, en una nube privada o en un modelo híbrido, apoyándose en algo como AWS Outpost, Azure Stack o Google Anthos? ¿O tal vez merezca la pena echar un vistazo a las soluciones SSE existentes y considerar la posibilidad de integrarlas en su línea de productos?
Para ayudarle a responder a estas preguntas, repasemos las expectativas del usuario final sobre SSE que influirán en su proceso de decisión:
- Consola única, conjunto único de políticas, lago de datos único para los registros de log. La idea de SSE surgió de la consolidación en el mercado de los componentes SWG, CASB y ZTNA. Lo último que quieren sus usuarios es gestionar varios productos utilizando varias consolas y API. Además, como proveedor de servicios, probablemente no quiere que sus operaciones repliquen las mismas políticas entre varias herramientas, lo que aumenta los costes operativos internos.
- Visibilidad de las actividades en la nube que sea fácil de entender.Sus clientes apreciarán los cuadros de mando intuitivos que les ayuden a comprender las áreas de riesgo y dónde deben centrar su atención. ¿Qué aplicaciones se utilizan? ¿Comparten los empleados los datos de la empresa utilizando instancias personales de SaaS (como Gmail u Office365)? ¿Dónde están los datos sensibles? ¿Hay indicios de comportamientos de riesgo entre mis usuarios? Ser capaz de responder a estas preguntas demuestra cómo se pueden ofrecer capacidades muy complejas de una manera fácil de usar.
- No hay impacto en el rendimiento con todos los controles de seguridad activados. Al consumir servicios de seguridad de un proveedor de servicios en la nube, sus clientes esperan un rendimiento constante, independientemente de dónde se encuentren. Para garantizarlo, un proveedor de servicios debe tener en cuenta desde qué puntos de presencia (PoP) se prestarán los servicios de seguridad y cómo afecta la ubicación del PoP al mercado al que se dirige. Al mismo tiempo, dentro de cada PoP, el rendimiento no debería depender del tipo de controles de seguridad que se habiliten. Deben preferirse las arquitecturas de "paso único" en lugar de las "cadenas de servicios", en las que el tráfico de los usuarios pasa por una pila de múltiples funciones de seguridad en serie.
- Costo. Según diversas previsiones (1,