Todas las plataformas de seguridad se enfrentan en algún momento a la misma cuestión fundamental:
¿Cómo deben organizarse las normas de seguridad?
A primera vista, esto parece una simple elección de modelado de datos. En la práctica, define la realidad diaria de las operaciones de seguridad: la rapidez con la que pueden depurarse los incidentes, la seguridad con la que pueden evolucionar las políticas, la facilidad con la que pueden incorporarse nuevas oficinas o comunidades de usuarios y si el crecimiento conduce a la claridad… o al caos.
Durante la última década, las plataformas SASE y SSE han convergido en un pequeño conjunto de patrones arquitectónicos. Estos patrones se mezclan a menudo en productos del mundo real, pero cada uno representa una filosofía de diseño distinta con sus propios puntos fuertes y modos de fallo.
Comprender estos modelos -y las dimensiones en las que difieren- explica por qué las plataformas modernas se están alejando del pensamiento centrado en el motor y adoptando enfoques más estructurados y escalables.
Dimensión 1: Cómo se agrupan las normas
(El eje principal del diseño de políticas)
1. Base de reglas por motor de seguridad
(El modelo fragmentado)
Este es el enfoque más antiguo y aún ampliamente utilizado.
Cada capacidad de seguridad posee su propia base de reglas independiente :
- Cortafuegos
- IDS / IPS
- DLP
- Escaneado de malware
- Filtrado de URL y categorías
- Controles SaaS
- Múltiples barandillas GenAI / LLM
En los entornos modernos, ya no se trata sólo de un puñado de motores. La «seguridad GenAI» por sí sola se expande en múltiples submotores especializados, como:
- detección rápida de la inyección,
- validación de entrada/salida de herramientas
- detección de código
- Seguridad del contenido
- Categorización y filtrado de contenidos
- seguridad de URL incrustadas
- DLP semántica
Cada motor tiene su propia lógica de concordancia, acciones, ciclo de vida y propietario operativo.
Puntos fuertes
- Control profundo y especializado
- Propiedad clara por parte de expertos en la materia
- Evolución independiente de los motores de seguridad
Límites estructurales
- Visibilidad fragmentada de los flujos de tráfico
- Decisiones conflictivas entre motores
- Elevados gastos operativos
- Escasa escalabilidad a medida que se multiplican los motores
Este modelo refleja los equipos de seguridad en silos y hereda los mismos retos de coordinación y operatividad.
2. Una única base de reglas unificada
(El modelo consolidado)
A medida que las plataformas se unificaban, muchas viraron hacia el extremo opuesto: colocar todas las decisiones en una tabla de reglas global.
Cada regla define:
- Condiciones de coincidencia (usuario, aplicación, destino, contexto)
- Referencias a perfiles de inspección para DLP, malware, GenAI y otros motores
Puntos fuertes
- Una norma explica una decisión
- Auditoría y resolución de problemas más fáciles
- Se alinea bien con el pensamiento de Confianza Cero («una intención = una regla»)
Límites estructurales
- Las tablas de reglas crecen mucho en entornos complejos
- Los cambios de perfil pueden tener un amplio radio de explosión
- Los especialistas pierden autonomía
- La gobernanza se convierte en un cuello de botella
Este modelo optimiza la visibilidad y la simplicidad, pero a menudo tiene dificultades para escalar con seguridad en organizaciones grandes o que cambian rápidamente.
3. Base de reglas por tipo de destino
(El modelo del destino primero)
Una evolución más reciente organiza las reglas en torno a dónde va el tráfico, en lugar de qué motor lo inspecciona.
Las categorías de destinos típicos incluyen:
- Internet
- Aplicaciones SaaS
- Aplicaciones privadas
Cada tipo de destino tiene su propia base de reglas de control de acceso, que refleja diferentes modelos de confianza, riesgos y semántica. Las reglas siguen evaluando ricas condiciones de coincidencia y producen una decisión de permitir o denegar a nivel de sesión, pero la agrupación se alinea de forma natural con la intención del tráfico.
Puntos fuertes
- Separación clara de la intención de acceso
- Modelo mental más intuitivo para los administradores
- Características de rendimiento predecibles
- Reducción de la mezcla de lógicas políticas no relacionadas
Límites estructurales
- No resuelve por sí sola la dispersión política
- Requiere una estructura adicional para escalar limpiamente a través de grandes organizaciones
La organización basada en el destino mejora la claridad, pero se necesita otra dimensión para gestionar el alcance y la reutilización.
Dimensión 2: Cómo se amplían y reutilizan las políticas
(Ortogonal a la agrupación de reglas)
Los siguientes modelos responden a una pregunta diferente:
¿Cómo se empaquetan, reutilizan y aplican las políticas entre ubicaciones, usuarios o entornos?
Pueden combinarse con cualquiera de los enfoques de agrupación de reglas anteriores.
4. Perfiles de configuración
(La política como objeto de primera clase)
Los perfiles de configuración introducen una abstracción de nivel superior que contiene la política, en lugar de ser la política en sí misma.
Un perfil de configuración suele agrupar:
-
- Una o varias bases de reglas de control de acceso
- Perfiles de inspección (lógica «permitir pero escanear»)
Objetos de seguridad específicos del motor (objetos DLP, controles GenAI, firmas IDS, etc.)
El perfil se convierte en una postura de seguridad portátil que puede aplicarse a:
- Oficinas físicas
- Regiones
- Sitios lógicos
- Comunidades de usuarios
En lugar de incrustar la lógica del ámbito (como el sitio o la región) en cada regla, la política se delimita aplicando el perfil de configuración adecuado.
Por qué es importante
- Reduce la explosión de reglas
- Mejora la legibilidad y la mantenibilidad
- Permite límites RBAC más claros
- Hace que los cambios de política sean más seguros y predecibles
Este enfoque es cada vez más común en las plataformas SASE y SSE modernas, incluso cuando no están explícitamente etiquetadas como tales.
5. Herencia de políticas
(Modelos de control por capas)
Otro patrón muy extendido -aunque a menudo implícito- es la herencia.
Las políticas están estructuradas jerárquicamente:
- Una línea de base global
- Superposiciones regionales o funcionales
- Anulaciones específicas del sitio o del grupo
La herencia permite a las organizaciones compartir los valores predeterminados al tiempo que permite una especialización controlada.
Compromisos
- Potente pero complejo
- La depuración requiere comprender el orden de resolución
- Una herencia mal diseñada puede ocultar una política eficaz
La herencia se combina a menudo con perfiles de configuración para equilibrar la reutilización con la claridad.
Reunir las dimensiones
Las plataformas de seguridad modernas rara vez se basan en un único modelo.
En su lugar, se combinan:
- Organización de reglas basadas en el destino (claridad de intenciones)
- Perfiles de configuración (alcance y reutilización de políticas)
- Herencia (especialización controlada)
- Inspección basada en perfiles (modularidad del motor)
Este enfoque por capas refleja una realización fundamental:
La complejidad de la seguridad no puede eliminarse, sólo estructurarse.
Dónde encaja AI>Secure
AI>Secure de Aryaka hace explícitas sus elecciones arquitectónicas en estas dos dimensiones:
- Dimensión 1 – Organización de reglas: modelo de reglas basado en el destino, que organiza el control de acceso en torno a Internet, SaaS y aplicaciones privadas.
- Dimensión 2 – Alcance y reutilización de políticas: Enfoque basado en perfiles de configuración, en el que las bases de reglas de acceso, los perfiles de inspección y los objetos de seguridad específicos del motor se agrupan en unidades de políticas reutilizables y se aplican a sitios lógicos.
Dentro de esta estructura:
- Cada regla evalúa un gran número de condiciones de coincidencia (atributos de red, URL y contexto de la aplicación, identidad del usuario, señales de reputación).
- Primero se toma una decisión de permitir o denegar a nivel de sesión.
- La inspección a nivel de datos sólo se realiza si la sesión está permitida, lo que garantiza una aplicación predecible y un uso eficaz de los motores de inspección profunda.
- La intención de la inspección es explícita, a través de los perfiles de inspección adjuntos a las reglas, no implícita por cadenas de reglas ocultas.
Al combinar la organización de las reglas en función del destino con el ámbito basado en el perfil de configuración, AI>Secure evita ambos extremos:
Fragmentación en bases de reglas específicas de cada motor
Expansión y radio de explosión de una única tabla de reglas global
Por qué esta arquitectura importa ahora
El auge del SaaS, las aplicaciones privadas y los flujos de trabajo impulsados por la GenAI han cambiado radicalmente los requisitos de seguridad:
- Las decisiones dependen de un contexto más rico
- La inspección es cara y debe ser intencionada
- Muchos motores de seguridad
- La política debe escalar a través de ubicaciones, usuarios y cargas de trabajo
La arquitectura de las normas ha tenido que evolucionar en consecuencia.
El futuro del diseño de políticas de seguridad no consiste en más reglas o motores más inteligentes. Se trata de una clara separación de preocupaciones, una intención explícita y arquitecturas que escalen sin colapsar bajo su propia complejidad.
Esa es la dirección en la que se mueve la industria y la base arquitectónica sobre la que se construye AI>Secure.