La lógica ACL clásica de ADC y firewall se construyó durante mucho tiempo sobre IP, subred, puerto y protocolo. Ese modelo es suficiente para el control de acceso a redes simple, pero el tráfico moderno de web, API, bots y WAAP no es tan simple.
Al tomar una decisión hoy, preguntar solo «¿cuál es la IP de origen?» no es suficiente. ¿De qué país viene la solicitud? ¿De qué ASN? ¿A qué ruta va? ¿Qué cookie está presente? ¿Qué rol está escrito en el JWT? ¿El conjunto de headers se parece a un navegador real? ¿Es sospechosa la huella TLS? ¿Cuántos puntos de score WAAP recibió esta solicitud? ¿Cómo clasificó el motor de bots a este usuario?
En la mayoría de los productos estas señales viven en lugares separados. La regla de enrutamiento está en un lugar, el score WAAP en otro, la decisión de bot en otro, la reescritura de headers en otro, y la limitación de tasa en otro lugar más. Esto complica las operaciones y produce decisiones inconsistentes.
El problema mayor es que las condiciones complejas suelen requerir código. Escribir una regla como «si este header está presente, esta cookie está ausente, la ruta comienza con /api/, el score WAAP está por encima de 5, pero el origen no es un bot conocido» requiere scripts, lenguajes de política propietarios o programación específica del proveedor en la mayoría de los productos.
La capa Smart ACL Conditions de TR7 ADC resuelve este problema: las decisiones de tráfico se definen desde la UI usando más de 60 criterios, cadenas de Smart Functions y grupos AND/OR/NOT. La regla se convierte no solo en una lista IP sino en una estructura de decisión que lee el significado del tráfico.
TR7 trata las condiciones ACL como la unidad fundamental de las decisiones de aplicación y seguridad — no como un filtro de dirección de red.
El motor Smart ACL va mucho más allá de IP y puerto. La IP de origen, el país, la ciudad, la IP de destino, el puerto de destino, el método HTTP, la URL, la ruta, la consulta, el header, la cookie, el cuerpo de solicitud, el cuerpo de respuesta, el TLS SNI, el cifrado TLS, el protocolo TLS, la huella JA3, el ID de ataque WAAP, el grupo de ataque WAAP, la clase de bot, la categoría de lista negra y el estado de caché pueden usarse todos como condiciones. Esto permite que las decisiones de seguridad y enrutamiento se tomen en pleno contexto de la aplicación.
Una ACL puede usarse sola o combinarse con otras ACLs en grupos lógicos. Un grupo interno funciona con AND u OR; una condición puede invertirse para dar comportamiento NOT. Por ejemplo: «La ruta comienza con /login» AND «El país de origen no está en la lista de permitidos» AND «El score de bot es alto» PERO «No es un bot conocido» — esta estructura hace legibles las políticas de seguridad complejas.
Las Smart Functions de TR7 convierten los valores de tráfico en bruto en entradas accionables. Las operaciones de decodificación Base64, consulta de ruta JSON, análisis de header/payload JWT, consulta XML, coincidencia de regex, reemplazo de cadena, minúsculas/mayúsculas, digest, máscara IP, IP a país y búsqueda en map/list pueden encadenarse todas. La ACL ya no solo pregunta «¿coincide este valor de header?»; analiza el JSON dentro del header, extrae un claim JWT o consulta un campo dentro del cuerpo.
Las condiciones de uso frecuente se definen una vez y se reutilizan en diferentes reglas. Las ACLs integradas o personalizadas como «¿es una extensión de archivo estático?», «¿hay una cookie de autenticación presente?», «¿es un cache hit?» o «¿fue bloqueada por el WAAP?» pueden compartirse entre muchas reglas. Este patrón reduce la duplicación de reglas, centraliza los cambios y reduce el riesgo de error operacional.
Smart ACL Conditions convierte las señales de tráfico en condiciones legibles y acciones ejecutables a través de más de 60 criterios.
TR7 puede escribir condiciones contra la ruta, ruta+consulta, URL completa y método HTTP. Los tipos de coincidencia pueden ser prefijo, sufijo, subcadena o regex. Las solicitudes que comienzan con /api/, la ruta /admin, el método POST o patrones de URL específicos que contienen una cadena de consulta se expresan todos dentro de una única definición ACL.
Los headers de solicitud, los headers de respuesta, las cookies de usuario y las cookies provenientes del backend pueden usarse todos dentro de una ACL. La selección de ruta basada en el header X-Tenant-ID, la redirección al login cuando la cookie session_id está ausente, la comprobación de bots basada en el contenido de User-Agent y el comportamiento de seguridad personalizado basado en una cookie de respuesta se escriben todos en esta capa.
Los criterios ACL no se limitan a la IP de origen o CIDR. También pueden definirse condiciones basadas en país, ciudad y ASN. Se soportan la restricción de acceso a países específicos, el enrutamiento personalizado para usuarios de ciudades específicas, la verificación adicional para tráfico de ASNs específicos o una política de bots más agresiva para ASNs de centros de datos.
Las señales TLS SNI, cifrado TLS, protocolo TLS, presencia de SNI y huella JA3 pueden incluirse en las condiciones. Se pueden expresar la asignación de un score de confianza más bajo a clientes que usan TLS 1.0, el rechazo de conexiones sin SNI, el envío de tráfico que coincide con una lista de huella JA3 conocida como mala a CAPTCHA, o la colocación de clientes que usan cifrados débiles en modo monitor.
La ACL puede operar sobre contenido muestreado del cuerpo de solicitud o respuesta. Se soporta la coincidencia de cadenas o regex dentro del cuerpo. La comprobación de transacciones de alto valor dentro de un cuerpo JSON, la captura de un patrón específico en un campo de formulario, la adición de un header cuando un marcador específico está presente en el cuerpo de respuesta o la aplicación de limitación de tasa basada en el contenido del payload de la API son todos posibles.
Con Smart Functions, el contenido JSON, XML y JWT puede convertirse en condiciones ACL. JWT payload.role == "admin", transaction.amount > 10000 en un cuerpo JSON, comprobar si una ruta específica existe en XML o verificar el algoritmo en un header JWT son todas condiciones que proporcionan flexibilidad significativa para la seguridad de API y la política de acceso.
El motor Smart ACL también puede usar las decisiones WAAP como condiciones: ID de ataque WAAP, grupo de ataque WAAP, score WAAP, si el WAAP bloqueó la solicitud, si fue marcada como ataque WAAP. Mostrar CAPTCHA cuando el score WAAP es 5+, enrutar las solicitudes del grupo SQL injection a un formato de log especial o enviar los hallazgos WAAP en modo monitor a un backend separado son escenarios de ejemplo.
Las clasificaciones de navegador, móvil, bot y agente de usuario pueden usarse dentro de una ACL. Se puede definir el envío de usuarios móviles a un backend móvil, la aplicación de un límite de tasa más bajo al tráfico marcado como bot, la concesión de excepciones a motores de búsqueda conocidos y la aplicación de un perfil de seguridad diferente a clientes que no son navegadores.
El motor ACL puede usar señales de volumen y tamaño de tráfico: tamaño de solicitud, tamaño de respuesta, recuento de conexiones frontend, tasa de solicitudes, tasa de sesiones, tiempo de respuesta, recuento de servidores backend activos y código de estado HTTP. Mover el nuevo tráfico a un pool de fallback cuando el recuento de backends activos cae a 1, o almacenar en caché un endpoint específico cuando el tiempo de respuesta aumenta, se expresan ambos a través de estos criterios.
Se soportan las coincidencias basadas en map y list. Se usa para grandes listas IP, listas de dominios, listas de URL, listas de IDs de cliente o tablas de clave-valor personalizadas. El enrutamiento diferente basado en una lista de clientes VIP, el bloqueo de IPs en una lista de bloqueo o la aplicación de una política CORS basada en una lista de dominios de socios se gestionan todos con este patrón.
La reputación IP o las categorías de lista negra pueden incluirse en las condiciones. Las categorías de botnet, proxy, Tor, malware o spam pueden vincularse a diferentes comportamientos. Servir CAPTCHA a una IP de categoría proxy abierto, colocar los nodos de salida Tor en modo monitor o rechazar directamente las IPs de la categoría malware son usos de ejemplo.
TR7 proporciona varias ACLs comunes listas para usar: si es una extensión de archivo estático, si hay una cookie de autenticación presente, si es un cache hit, si fue bloqueada por el WAAP. Estas ACLs integradas evitan que los operadores reescriban sus condiciones más frecuentemente necesarias y mantienen los conjuntos de reglas más compactos.
En casos extremos donde los criterios estándar de la UI no son suficientes, un usuario experto puede escribir una condición manual. Esto preserva el motor de reglas visual de TR7 mientras proporciona flexibilidad de válvula de escape. Este modo no es para uso diario — está destinado a operaciones avanzadas e integraciones personalizadas.
Los valores de tasa de solicitudes por usuario, tasa de conexión y tasa de errores pueden usarse dentro de una ACL. Cuando se combina con un claim JWT, una cookie, un header o un ID de usuario, pueden construirse políticas de limitación de tasa a nivel de tenant o usuario.
Pueden activarse diferentes comportamientos en función de si una solicitud o respuesta es un cache hit. La presencia de cookie de autenticación o los valores de autenticación HTTP también pueden usarse en el motor ACL. Esto unifica el comportamiento de AAM y ADC bajo la misma lógica de reglas.
Smart ACL Conditions no es solo sintaxis de reglas — cubre la estructura de grupos de condiciones, tipos de coincidencia, modelo de actualización y límites de muestreo del cuerpo.
Las condiciones Smart ACL se definen en grupos. Las condiciones dentro de un grupo se combinan con AND u OR. Una condición puede invertirse para dar comportamiento NOT. Los grupos externos forman una estructura lógica más amplia. Este enfoque divide las políticas complejas en piezas pequeñas y legibles.
Cada ACL se identifica por un ID único. Las reglas hacen referencia a este ID. La misma ACL puede reutilizarse en diferentes reglas de tráfico, políticas de limitación de tasa, reglas de redirect o acciones de seguridad. Cuando la ACL cambia, la actualización se propaga automáticamente a todas las reglas vinculadas.
Se soportan diferentes tipos de coincidencia para condiciones basadas en texto: coincidencia de prefijo, coincidencia de sufijo, coincidencia de subcadena, coincidencia de regex y coincidencia sensible o insensible a mayúsculas y minúsculas. Esta flexibilidad cubre tanto estructuras de reglas simples como complejas.
Las Smart Functions pueden usarse individualmente o encadenadas. Por ejemplo: analizar el payload JWT, extraer el campo de rol, convertir a minúsculas, comparar contra una lista específica. Esto convierte los datos de tráfico en bruto en entradas de decisión significativas.
La inspección del cuerpo de solicitud y respuesta opera sobre un tamaño de contenido muestreado. Esto proporciona un modelo equilibrado entre rendimiento y conciencia del contenido. Para cuerpos muy grandes, se usan por separado capacidades dedicadas de modificación o enmascaramiento del cuerpo.
Las condiciones Smart ACL pueden usarse en diferentes capas. Las reglas en el lado L7 pueden requerir un soft-reload en el cambio de configuración. Las reglas en el lado del firewall L3 se aplican a través de su propio ciclo de sincronización de firewall. No cada cambio se aplica a través del mismo mecanismo — se aplica un modelo de actualización por capa.
Las extensiones comunes para la detección de contenido estático se proporcionan de serie: .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx y tipos de archivo similares. Esto se usa frecuentemente en escenarios de caché, reducción de logs y excepciones de limitación de tasa.
Algunas Smart Functions funcionan directamente con el motor de tráfico integrado; algunas funciones especializadas se ejecutan a través de una capa de conversor adicional. Esto da a las operaciones JSON, XML, JWT y de cadenas personalizadas una superficie de expresión más amplia.
En una capa de API, los usuarios admin reciben un límite más alto y los usuarios regulares uno más bajo. Smart ACL lee el campo de rol desde el payload JWT y selecciona la política de limitación de tasa en consecuencia. JWTPAYLOAD(role) == admin → límite de tasa alto; de lo contrario → límite de tasa estándar.
Una solicitud es marcada como sospechosa por el WAAP pero no lo suficientemente clara como para bloquearse directamente. Smart ACL evalúa el score WAAP y la clase de bot juntos. Cuando wafScore >= 5 AND NOT knownBot, se presenta CAPTCHA.
Los usuarios móviles se enrutan a un backend y los usuarios de escritorio a otro. Smart ACL usa el agente de usuario y la señal de clasificación móvil. mobile == true → backend móvil; mobile == false → backend de escritorio.
Se define un map personalizado de huellas de clientes maliciosos conocidos como ACL. Cuando la huella TLS entrante coincide con esta lista, el tráfico se bloquea o se envía a CAPTCHA. ja3 in bad_fingerprint_list → deny / captcha.
En una API financiera, el importe de transferencia se lee desde el cuerpo JSON. Cuando el importe supera un umbral definido, se activa MFA adicional en el lado AAM o la transacción se enruta a un backend separado. JSONQUERY(transaction.amount) > 10000 → step-up MFA.
El tráfico de ciertos países está normalmente permitido, pero cuando el mismo tráfico proviene de un ASN de hosting y el score WAAP es elevado, se aplica un desafío adicional. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Seguridad, enrutamiento y limitación de tasa en un motor de reglas — a través de más de 60 criterios, cadenas de Smart Functions y grupos AND/OR/NOT. Permítanos guiarle por una configuración en vivo en su propio entorno.