Simplifique la seguridad: Racionalice las políticas en Unified SASE

El servicio Secure Access Service Edge (SASE), junto con su arquitectura asociada, comprende una potente amalgama de múltiples componentes de seguridad.
Entre ellos se incluyen un cortafuegos de inspección de estado, un sistema de detección y prevención de intrusiones (IDPS), seguridad DNS, protección DoS/DDoS, Secure Web Gateway (SWG), arquitectura de red de confianza cero (ZTNA), Cloud Access Security Broker (CASB) y muchos más.
Estos componentes otorgan a los administradores la capacidad de configurarlos mediante políticas, ofreciendo un sólido escudo para proteger los activos de una organización frente a las amenazas, al tiempo que se cumplen los requisitos de acceso específicos.

El papel de la configuración de políticas

La configuración de políticas desempeña un papel indispensable en la aplicación de la seguridad dentro del marco SASE.
Las repercusiones de unas políticas mal configuradas pueden ir desde amenazas a los recursos y fugas de datos hasta accesos involuntarios y excesivamente permisivos.
En el panorama actual de la industria, las organizaciones lidian con dos enfoques predominantes para la gestión de las políticas de seguridad:

1. El enfoque de tabla única: Una tabla de políticas consolidada que contiene una miríada de políticas que abarcan la gestión de amenazas y varios escenarios de control de acceso en todos los componentes de SASE.
2. El enfoque de tablas múltiples: Múltiples tablas de políticas, cada una de las cuales aborda aspectos específicos como la protección frente a amenazas, el control de acceso, las diferentes aplicaciones y los grupos de usuarios.

Encontrar el equilibrio en la gestión política

La expectativa de SASE es clara: debe ofrecer políticas de seguridad fácilmente manejables y procedimientos simplificados de resolución de problemas.
Conseguirlo requiere un enfoque equilibrado.
Una estrategia eficaz para mitigar la complejidad de las políticas se basa en los requisitos de las organizaciones.
Las organizaciones más grandes pueden requerir una compartimentación con un enfoque de tablas múltiples en el que la granularidad de las tablas de políticas se defina en función de las funciones de seguridad, los recursos de la aplicación y el sujeto (usuarios/grupos).
Las organizaciones más pequeñas pueden preferir la compartimentación con un número menor de tablas de políticas combinando varios tipos de controles de acceso o incluso combinando la protección contra amenazas con el control de acceso.
Este enfoque flexible minimiza el número de políticas que requieren una gestión simultánea, haciéndolas más manejables.
Sin embargo, es importante actuar con cautela para evitar una compartimentación excesiva, que puede introducir su propio conjunto de desafíos.
Los administradores pueden encontrarse navegando a través de múltiples tablas de políticas para identificar y abordar los problemas, lo que puede causar retrasos en la resolución.

Comprender los requisitos clave

Antes de profundizar en los entresijos de la gestión de políticas, es crucial comprender los requisitos específicos que las organizaciones deben abordar dentro del marco SASE.
Las áreas clave incluyen:

Necesidad de una gestión de la configuración de seguridad basada en roles en entornos SASE

Los componentes de Secure Access Service Edge (SASE) ofrecen una seguridad integral, que abarca la protección frente a amenazas y el control de acceso para una amplia gama de recursos en diversas organizaciones, incluidos sus empleados, socios e invitados.
Dentro de este marco de seguridad, las organizaciones suelen tener distintas categorías de administradores responsables de diferentes aspectos de la seguridad.
Por ejemplo, una organización puede tener un grupo de administradores dedicados a gestionar la protección contra amenazas, mientras que otro grupo se centra en los controles de acceso.
Dentro de estas amplias categorías, es habitual que las organizaciones establezcan diversas funciones administrativas adaptadas a tipos específicos de protección contra amenazas y control de acceso.
Profundicemos en algunos ejemplos prácticos:

Funciones de protección frente a amenazas:

• Detección de Intrusos y Configuración del Cortafuegos: Los administradores con el «threat-protection-ngfw-role» tienen acceso para configurar la Detección de Intrusos y los ajustes del cortafuegos dentro del entorno SASE.
• Controles de reputación: Los administradores que posean el rol «threat-protection-reputation-role» pueden gestionar los ajustes relacionados con los controles de reputación IP, los controles de reputación basados en URL, los controles de reputación basados en dominios, los controles de reputación de archivos, así como los controles de reputación de servicios en la nube y de organizaciones en la nube.
• Protección contra malware: Los administradores con el rol «threat-protection-malware-protection-role» tienen autoridad para configurar ajustes específicamente relacionados con los controles de protección contra malware.

Funciones de control de acceso:

• Configuración de SWG: Los administradores designados como «access-control-Internet-role» son los responsables de gestionar las configuraciones de Secure Web Gateway (SWG).
• Control de acceso específico para aplicaciones SaaS: Roles como «access-control-saas1app-role» y «access-control-saasNapp-role» se centran en la configuración de políticas de control de acceso para aplicaciones específicas (SaaS Service 1 y SaaS Service N), garantizando un control de grano fino.
• Gestión de aplicaciones empresariales: Roles como «access-control-hostedapp1-role» y «access-control-hostedappM-role» se dedican a gestionar las configuraciones de control de acceso para las aplicaciones de nivel empresarial, app1 y appM.

En los casos en los que una organización utilice aplicaciones multi-arrendatario, pueden introducirse roles adicionales para gestionar eficazmente las configuraciones de seguridad.
Por ejemplo, pueden establecerse roles para configurar políticas para la plantilla de la organización, la plantilla por inquilino e incluso los invitados.
Considere una aplicación «X» con configuraciones de seguridad gestionadas por diferentes conjuntos de administradores:

• Seguridad de la plantilla del propietario: Los administradores con «access-control-hostedappX-role» y «access-control-owner-workforce-role» colaboran para gestionar las configuraciones de control de acceso a la aplicación «X» para la fuerza de trabajo del propietario.
• Fuerza de trabajo específica del arrendatario de la aplicación: Roles como «access-control-hostedAppX-role» y «access-control-owner-tenantA-workforce-role» permiten a los administradores configurar los ajustes de control de acceso para la plantilla del arrendatario A.
• Mano de obra específica del arrendatario de la aplicación para el arrendatario B: Para una aplicación multiarrendatario «X», varios roles, como «access-control-hostedAppX-role» y «access-control-owner-tenantB-workforce-role», facilitan la gestión de las configuraciones de control de acceso para la mano de obra del arrendatario B.

Además, incluso las aplicaciones empresariales no multiusuario pueden requerir administradores separados para los distintos segmentos de personal.
Por ejemplo:

• Departamento de Ingeniería: Los administradores con «access-control-hostedappY-role» y «access-control-eng-role» se centran en gestionar las configuraciones de control de acceso para la aplicación «Y» dentro del departamento de ingeniería.
• Ventas y marketing: Roles como «access-control-hostedappY-role» y «access-control-sales-role» están designados para configurar los ajustes de control de acceso para los equipos de ventas y marketing.
• Departamento de TI: Los administradores con «access-control-hostedappY-role» y «access-control-it-role» tienen responsabilidades sobre las configuraciones de control de acceso pertenecientes al departamento de TI.

Una ventaja significativa de la gestión de la configuración de seguridad basada en roles es su capacidad para proporcionar un control granular adaptado a responsabilidades específicas.
Contrasta este enfoque con los retos que pueden surgir cuando se utiliza una tabla de políticas única y omnicomprensiva:

• Propenso a errores: Múltiples administradores trabajando con la misma tabla de políticas y permisos solapados pueden introducir errores inadvertidamente al añadir, eliminar o modificar políticas.
• Complejidad de la resolución de problemas: La resolución de problemas en una tabla de políticas monolítica puede llevar mucho tiempo y suponer un reto.
• Sobrecarga de políticas: Consolidar todas las políticas en una única tabla, que abarque varias aplicaciones y escenarios de protección contra amenazas, puede dar lugar a una experiencia de gestión de políticas engorrosa y poco manejable, así como a posibles problemas de rendimiento durante la evaluación de las políticas.

En conclusión, la adopción de una gestión de la configuración de la seguridad basada en roles dentro de los entornos SASE permite a las organizaciones delegar responsabilidades de forma eficaz, mejorar la seguridad y agilizar la gestión de políticas, al tiempo que se evitan las complejidades asociadas a los enfoques de tabla única.

Colaboración con la gestión del control de cambios en la configuración

Las organizaciones están adoptando cada vez más la gestión del control de cambios para todas las configuraciones, incluida la configuración SASE, para detectar y rectificar proactivamente los errores de configuración antes de que se implementen.
Esta práctica no sólo sirve como salvaguarda, sino que también introduce una capa secundaria de escrutinio, permitiendo que un segundo par de ojos revise y apruebe las configuraciones antes de que entren en vigor.
Las configuraciones de las políticas de seguridad se aplican directamente dentro del flujo de tráfico, por lo que cualquier error en las políticas puede perturbar los servicios y acarrear consecuencias financieras directas.
Para hacer frente a la complejidad inherente a la configuración de las políticas de seguridad, es práctica común serializar los cambios.
Esto significa que cuando se modifica un tipo de configuración, no se inician otras sesiones de configuración del mismo tipo hasta que se aplica o revoca la anterior.
Sin embargo, cuando se utiliza una única tabla de políticas que engloba todas las funciones de control de amenazas y accesos, la serialización de los cambios puede introducir retrasos en los ajustes de configuración realizados por otros administradores.
Por el contrario, un enfoque basado en varias tablas puede resolver eficazmente este escenario, permitiendo que diferentes administradores trabajen simultáneamente en tablas distintas, agilizando así el proceso de cambio de configuración.

No todas las organizaciones comparten los mismos requisitos:

El SASE se ofrece normalmente como un servicio, y los proveedores de SASE pueden servir a múltiples organizaciones como clientes.
Estas organizaciones pueden variar significativamente en términos de tamaño, requisitos normativos y diversidad de funciones dentro de sus estructuras.
Algunas organizaciones pueden alojar múltiples aplicaciones, ya sea in situ o en la nube, mientras que otras pueden depender exclusivamente de los servicios de los proveedores de SASE, y algunas pueden incorporar una combinación de ambos.
Además, algunas organizaciones pueden no tener necesidad de varios roles administrativos o de múltiples usuarios administrativos.
En escenarios en los que las organizaciones sólo tienen un número limitado de aplicaciones y carecen de la complejidad de múltiples roles administrativos, pueden encontrar valor en el uso de menos tablas de políticas.
Se espera que SASE esté diseñado para ofrecer la flexibilidad requerida para acomodar estas diversas necesidades, incluyendo la opción de utilizar tablas de políticas consolidadas para múltiples funciones y aplicaciones de seguridad relevantes.

Evitar configuraciones confusas:

Algunas soluciones SASE, en su búsqueda de la simplificación antes comentada, optan por una tabla de políticas única y omnicomprensiva en la que las políticas pueden configurarse con valores para varios atributos coincidentes.
Durante el procesamiento del tráfico, la selección de políticas se basa en cotejar los valores del tráfico entrante y otra información contextual con los valores de los atributos especificados en las políticas.
Sin embargo, es crucial reconocer que durante el procesamiento del tráfico, no todos los atributos del tráfico son fácilmente conocidos.
Por ejemplo, en el caso de los cortafuegos de inspección de estado, sólo puede extraerse un conjunto limitado de valores del tráfico, como la información de las 5 tuplas (IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo IP).
Mientras tanto, para los componentes de seguridad basados en proxy como SWG, ZTNA y CASB, la extracción de los valores de los atributos puede variar e implicar distintas fases, en particular las fases de inspección previa y posterior a la inspección TLS.
Antes de la inspección/descifrado TLS, muchos atributos HTTP permanecen desconocidos.
Sólo después del descifrado TLS están disponibles para su evaluación atributos adicionales, como la ruta URI de acceso, el método HTTP y las cabeceras de solicitud.
Como administradores responsables de configurar las políticas de seguridad, resulta poco práctico esperar que los administradores lleven la cuenta de qué atributos son válidos en las distintas fases del procesamiento de paquetes mientras definen las políticas.
Aunque algunas soluciones de seguridad afirman que los atributos irrelevantes no se tienen en cuenta en la evaluación de las políticas, determinar qué atributos son pertinentes y cuáles no puede ser todo un reto cuando se inspeccionan políticas complejas.
Creemos firmemente que amalgamar tablas de políticas de varias etapas en una única tabla crea complejidad y confusión para los administradores.
Un enfoque de este tipo puede resultar difícil de comprender y dar lugar a configuraciones potencialmente desconcertantes.
Para garantizar la claridad, es aconsejable crear políticas dentro de una tabla determinada que incluyan sólo los atributos relevantes para que las evaluaciones sean coherentes y sencillas.

Optimización de las tablas de políticas Denegar y Permitir:

Algunas soluciones de seguridad adoptan una estructura en la que mantienen tablas de políticas «Denegar» y «Permitir» separadas.
Dentro de esta configuración, las políticas definidas en la lista «Denegar» tienen prioridad y se evalúan en primer lugar.
Si no se encuentra ninguna política coincidente en la tabla «Denegar», la evaluación procede a la tabla de políticas «Permitir».
Sin embargo, esta división de las políticas en dos tablas distintas puede plantear dificultades a los administradores.
Abogamos firmemente por un enfoque más racionalizado, en el que cualquier tabla de políticas se presente como una lista ordenada de políticas.
En esta disposición, cada política especifica explícitamente su acción, ya sea «Denegar», «Permitir» o cualquier otra acción deseada.
Durante el procesamiento del tráfico, la evaluación de las políticas sigue una progresión lógica desde la política de mayor prioridad a la de menor prioridad hasta que se encuentra una coincidencia.
Una vez identificada una política coincidente, se aplica la acción correspondiente al tráfico.
En los casos en los que no se encuentra ninguna política coincidente, se activa una acción por defecto, como «fail open» o «fail close», según defina la política de seguridad de la organización.
Este enfoque simplifica la gestión de políticas y aumenta la claridad para los administradores al consolidar las políticas dentro de una lista única y ordenada independientemente de los valores de acción de la política, minimizando así la complejidad y agilizando el proceso de evaluación de políticas.
El hecho de no separar las tablas de políticas en función de los valores de acción también permite a los proveedores de soluciones SASE introducir nuevos valores de acción en el futuro con relativa facilidad.

Creación de políticas flexibles y expresivas:

Como habrá deducido, los administradores elaboran las políticas definiendo conjuntos de valores para los atributos coincidentes.
Tradicionalmente, ha habido un entendimiento común de cómo opera la coincidencia de políticas durante las evaluaciones de tráfico: una política se considera coincidente sólo cuando todos los valores de atributos especificados en la política se alinean perfectamente con los valores de la sesión de tráfico entrante.
Estos valores pueden extraerse directamente del tráfico o inferirse a partir de información contextual, como el contexto del usuario autenticado y el contexto del dispositivo responsable de iniciar el tráfico.
Esencialmente, este proceso de correspondencia implica una operación «Y» a través de todos los atributos de la política.
Sin embargo, a medida que las tecnologías de seguridad han evolucionado, muchos dispositivos de seguridad han introducido un enfoque más flexible, concediendo a los administradores la capacidad de asignar múltiples valores a los atributos.
En este paradigma evolucionado, se establece una coincidencia si la información de contexto en tiempo de ejecución se alinea con cualquiera de los valores especificados para los atributos de la política.
En esencia, el proceso de correspondencia combina ahora una operación «Y» a través de los atributos con una operación «O» a través de los valores asociados a dichos atributos.
Las organizaciones pueden beneficiarse significativamente de esta flexibilidad a la hora de crear políticas integrales.
Reduce el número total de políticas necesarias al tiempo que mantiene la legibilidad.
Sin embargo, estos atributos multivalor son sólo un paso en la dirección correcta, y a menudo son necesarias más mejoras para satisfacer los requisitos exclusivos de las organizaciones: Compatibilidad con la decoración «NO»: Los administradores requieren la capacidad de definir valores de atributos de políticas con una decoración «NOT».
Por ejemplo, debería ser posible especificar un valor de atributo «IP de origen» como «NOT 10.1.5.0/24», indicando que la política coincidirá con éxito cuando la IP de origen de la sesión de tráfico no pertenezca a la subred 10.1.5.0/24. Soporte para múltiples instancias de un atributo: Muchos dispositivos de seguridad tradicionales sólo admiten una instancia de un atributo determinado dentro de una política. Para crear políticas completas, es esencial la capacidad de incluir múltiples instancias del mismo atributo dentro de una misma política.
Por ejemplo, un administrador puede querer permitir sesiones desde cualquier dirección IP de la subred 10.0.0.0/8 mientras que simultáneamente deniega sesiones de tráfico desde la subred 10.1.5.0/24.
Esto debería poder conseguirse dentro de una única política, quizás especificando los valores de «IP de origen» dos veces: «IP de origen == 10.0.0.0/8» y «IP de origen == NO 10.1.5.0/24».
Esto evita la necesidad de crear dos políticas separadas y permite una gestión de políticas más intuitiva. Soporte de decoraciones para valores de tipo cadena: Los atributos que aceptan valores de tipo cadena, como las rutas URI, los nombres de dominio y muchas cabeceras de peticiones HTTP, se benefician de decoraciones como ‘exact’, ‘starts_with’ y ‘ends_with’.
Estas decoraciones mejoran la creación de políticas expresivas. Compatibilidad con patrones de expresiones regulares: En algunos casos, las políticas requieren la coincidencia de patrones dentro de los valores de tráfico. Por ejemplo, una política puede dictar que sólo se permita una sesión de tráfico si un patrón específico está presente en cualquier parte del valor de la cabecera de la solicitud «agente de usuario».
El soporte para patrones de expresiones regulares es esencial en tales escenarios. Soporte para atributos dinámicos: Mientras que los atributos tradicionales en las políticas son fijos y predefinidos, los entornos SASE a veces requieren atributos dinámicos.
Considere las cabeceras de solicitud y respuesta o las reclamaciones JWT, donde los estándares coexisten con numerosas cabeceras y reclamaciones personalizadas.
SASE debería facultar a los administradores para crear políticas que den cabida a cabeceras y reclamaciones personalizadas.
Por ejemplo, SASE debería permitir la creación de políticas con la cabecera de petición ‘X-custom-header’ como atributo y el valor ‘matchme’. En el momento del tráfico, cualquier sesión HTTP con ‘X-custom-header’ como una de las cabeceras de petición y ‘matchme’ como valor debería coincidir con la política. Soporte para objetos: Esta función permite la creación de varios tipos de objetos con valores que pueden utilizarse como valores de atributo en las políticas, en lugar de especificar valores inmediatos.
Se puede hacer referencia a los objetos en varias políticas, y cualquier cambio futuro en los valores se puede realizar a nivel de objeto, lo que simplifica las modificaciones de las políticas y garantiza su coherencia.
Estas mejoras contribuyen a la creación de políticas de seguridad flexibles, expresivas y eficaces, lo que permite a las organizaciones adaptar sus políticas a necesidades y escenarios de seguridad únicos de forma eficaz.

Mejora de la integración de políticas con modificaciones del tráfico

Ciertas funciones de seguridad requieren modificaciones en el tráfico, y los casos de uso más comunes implican la adición, eliminación o modificación de las cabeceras de solicitud/respuesta HTTP y sus valores, los parámetros de consulta y sus valores, e incluso el cuerpo de la solicitud/respuesta.
Estas modificaciones pueden variar significativamente en función de las configuraciones de los administradores.
A menudo, las modificaciones específicas dependen de los valores del tráfico, como la aplicación/servicio de destino, así como de la información contextual disponible durante la ejecución del tráfico.
En lugar de mantener una tabla de políticas separada para las modificaciones del tráfico, a menudo resulta más eficaz incluir estos objetos de modificación dentro de las propias políticas de acceso.
Este enfoque agiliza la gestión de las políticas y garantiza que las modificaciones estén directamente alineadas con las políticas que rigen el comportamiento del tráfico.
Un escenario destacado en el que la modificación del tráfico es esencial es en el contexto de las soluciones Cloud Access Security Broker (CASB), especialmente cuando las organizaciones requieren restricciones multi-tenancy.
Estas restricciones a menudo implican la adición de cabeceras y valores de solicitud específicos para hacer cumplir las políticas específicas de colaboración.
Además, hay otros casos, como la adición de cabeceras personalizadas para la resolución de problemas de extremo a extremo y el análisis del rendimiento, en los que las modificaciones del tráfico desempeñan un papel crucial.
En consecuencia, las organizaciones esperan que las soluciones SASE soporten políticas que se integren perfectamente con los objetos de modificación.
Durante el procesamiento del tráfico, las modificaciones del tráfico se ejecutan cuando la política coincidente se asocia con los objetos de modificación adecuados, lo que proporciona un enfoque unificado y eficaz de la gestión del tráfico y la aplicación de las políticas.

Mejorar la observabilidad:

Es práctica habitual registrar cada sesión de tráfico al término de la misma a efectos de observabilidad.
En los casos de sesiones sustanciales o «elefantes», también es habitual registrar periódicamente la información de acceso.
Estos registros de sesión suelen contener datos valiosos, como metadatos de tráfico, acciones realizadas durante la sesión y detalles sobre los paquetes y bytes transferidos entre el cliente y el servidor.
Un avance significativo que ofrece SASE es la consolidación de las funciones de seguridad y la adopción de arquitecturas de paso único y finalización en tiempo de ejecución, lo que da como resultado un registro de sesión unificado.
Esto contrasta con los despliegues de seguridad que no utilizan SASE, en los que cada componente de seguridad individual genera su propio registro de sesión, que a menudo contiene información sobre la política que se ha cotejado y los valores de atributos críticos utilizados en el proceso de cotejo.
Es importante destacar que, aunque SASE genera un único registro, existe la expectativa de que no comprometa la inclusión de información crítica.
Cuando una sesión de tráfico es permitida debido a múltiples evaluaciones de políticas a través de varias funciones de seguridad y tablas de políticas, el registro resultante debería incluir información sobre cada política que fue emparejada.
Además, si una política coincide debido a los valores de atributos específicos del tráfico o del contexto, el registro debe proporcionar detalles precisos sobre los valores de los atributos que condujeron a la coincidencia de la política.
Dado que las organizaciones dependen de registros exhaustivos para una observabilidad eficaz, se espera que las soluciones SASE proporcionen información exhaustiva en los registros, garantizando que los administradores tengan acceso a los datos que necesitan para supervisar y analizar el tráfico de la red con eficacia.

Enfoque SASE de la gestión política:

Es importante reconocer que no todas las soluciones SASE son idénticas.
Las organizaciones deben evaluar cuidadosamente si una solución SASE concreta se ajusta a sus requisitos organizativos específicos sin sacrificar la facilidad de uso.
Aunque puede que las organizaciones no posean inicialmente todos los requisitos enumerados anteriormente, es sólo cuestión de tiempo que estos requisitos sean cada vez más relevantes y esenciales para sus operaciones.
Las organizaciones que poseen todos los requisitos mencionados obtienen la ventaja de una flexibilidad total a la hora de adaptar sus políticas SASE a sus necesidades específicas.
Por otro lado, las organizaciones que actualmente no cuentan con todos estos requisitos suelen buscar una experiencia de usuario más sencilla sin perder de vista la introducción de funcionalidades adicionales a medida que evolucionen sus requisitos.
Este enfoque permite a las organizaciones encontrar un equilibrio entre sus necesidades actuales y su crecimiento futuro, garantizando que su solución SASE siga siendo adaptable y responda a las circunstancias cambiantes. A menos que las soluciones SASE proporcionen una flexibilidad total, la personalización se convierte en un reto.
Por lo tanto, creemos que las soluciones SASE deben proporcionar las siguientes capacidades básicas:

1. Gestión modular de políticas: Las soluciones SASE abarcan múltiples funciones de seguridad, cada una con su propio conjunto de configuraciones de políticas.
   Estas configuraciones deben incluir opciones para activar/desactivar, establecer la acción por defecto en caso de no coincidencia de políticas, gestionar la recopilación de múltiples tablas de políticas, definir múltiples políticas dentro de cada tabla de políticas, establecer una lista ordenada de políticas y establecer configuraciones de acción, objetos de modificación, atributos de coincidencia y valores para cada política.
2. Encadenamiento de políticas: Para permitir políticas más específicas y granulares, las soluciones SASE deben soportar el encadenamiento de políticas.
   Esto significa permitir la disposición de políticas a través de múltiples tablas de políticas en una colección.
   Por ejemplo, las organizaciones pueden tener tablas de políticas separadas para diferentes aplicaciones, con las políticas de la tabla principal utilizando nombres de aplicaciones/dominios como criterios de coincidencia para seleccionar las tablas de políticas apropiadas.
   Esto se consigue normalmente mediante el uso de políticas que incorporan una acción denominada «Saltar», que redirige la evaluación de la política a la tabla de políticas referenciada.
   El concepto de encadenamiento de políticas ganó popularidad con Linux IPTables, y muchas soluciones de seguridad incorporaron posteriormente esta funcionalidad.

La amplitud de las funciones de seguridad dentro de SASE puede ser extensa y puede incluir:

• NGFW (Cortafuegos de nueva generación): Proporcionando control de acceso L3/L4, protección DDoS, reputación IP, reputación de dominio y, Sistema de Detección y Prevención de Intrusiones (IDPS)
• SWG (Secure Web Gateway): Ofrece inspección TLS, control de acceso web pre-TLS, control de acceso web post-TLS, reputación de URL, reputación de archivos y protección contra malware.
• ZTNA (Acceso a la red de confianza cero): Similar al SWG pero centrado en la seguridad de las aplicaciones alojadas.
• CASB (Corredor de seguridad de acceso a la nube): Cubre la reputación del servicio en la nube y el control de acceso al servicio en la nube.
• DLP (Prevención de Pérdida de Datos): Implantación de un control de acceso basado en la información personal identificable (IPI), los documentos confidenciales estándar y los documentos sensibles específicos de la empresa.

La flexibilidad de la gestión de políticas para cada función de seguridad, junto con la capacidad de gestionar políticas dentro de cada función a través de múltiples tablas de políticas con encadenamiento de políticas, es una potente característica.
Las organizaciones geodistribuidas con diversos requisitos normativos pueden beneficiarse especialmente de esta flexibilidad.
Sin embargo, las organizaciones más pequeñas pueden preferir algún tipo de consolidación de las tablas de políticas.
En tales casos, debería ser posible personalizar la configuración:

• Consolidación de todas las configuraciones de funciones de seguridad pre-TLS en una única colección de tablas de políticas a través de múltiples componentes SWG/ZTNA.
• Consolidación de todas las configuraciones de funciones de seguridad post-TLS en otra única colección de tablas de políticas a través de múltiples componentes SWG/ZTNA.
• Mantener las funciones CASB, malware y DLP como entidades separadas, ya que requieren complejas definiciones de políticas.
• Optar por una única tabla de políticas dentro de la colección de tablas de políticas, evitando así el encadenamiento de políticas.

Por lo tanto, las organizaciones deben buscar servicios SASE que proporcionen una flexibilidad total y, al mismo tiempo, ofrezcan controles personalizados para consolidar las configuraciones de las funciones de seguridad relevantes.
Este enfoque garantiza que las políticas SASE se adapten a las necesidades específicas de una organización, al tiempo que se mantiene la facilidad de gestión y la escalabilidad a medida que evolucionan los requisitos.

Equilibrar la experiencia del usuario con una flexibilidad a prueba de futuro

La gestión de políticas de seguridad ha sido históricamente una tarea compleja.
Muchos productos se especializan en la gestión de políticas para dispositivos de seguridad específicos, lo que resulta en un panorama fragmentado.
SASE aborda esta complejidad consolidando múltiples dispositivos de seguridad en una solución unificada.
Aunque esta consolidación ofrece ventajas, también introduce complejidades propias.
Los enfoques tradicionales de la gestión de políticas, como una única tabla de políticas, pueden parecer atractivos inicialmente.
Sin embargo, presentan numerosos retos y a menudo se quedan cortos a la hora de cumplir los requisitos expuestos en este artículo.
A la inversa, disponer de un número excesivo de motores de políticas también puede generar complejidad.
Lograr el equilibrio adecuado entre flexibilidad y sencillez es primordial.
Un reto importante en el sector es la proliferación de políticas.
Un número excesivo de políticas no sólo degrada la experiencia del usuario y la resolución de problemas, sino que también conlleva implicaciones para el rendimiento.
El enfoque multi-tabla y la expresividad de las políticas, como se ha descrito anteriormente, son estrategias esenciales para reducir el volumen de políticas dentro de las tablas de políticas.
Las soluciones SASE abordan cada vez más estas complejidades proporcionando una mayor sofisticación en la gestión de políticas.
Creemos que las soluciones SASE seguirán evolucionando, implementando muchos de los requisitos detallados en este artículo en un futuro muy próximo.
Esta evolución permitirá a las organizaciones encontrar el equilibrio óptimo entre la experiencia del usuario, la flexibilidad y el rendimiento, garantizando que sus políticas de seguridad sigan siendo eficaces y adaptables en un panorama de amenazas que cambia rápidamente.

• Blog CTO Insights

  La serie de blogs Aryaka CTO Insights proporciona liderazgo de pensamiento para temas de red, seguridad y SASE.
  Para conocer las especificaciones de los productos Aryaka, consulte Aryaka Datasheets.