Cloudflare hace programable su gateway SASE con Workers

Cloudflare abre su gateway de seguridad a código propio

Cloudflare lleva seis años construyendo su gateway de seguridad y ahora lo conecta directamente con su plataforma de cómputo en el edge: cualquier cliente puede ejecutar código propio dentro del camino de evaluación de políticas, en más de 330 ubicaciones de su red. El anuncio del 15 de octubre incluye la acción Forward en beta pública y funciones de validación personalizada para DLP, disponibles desde ya en todos los planes de Zero Trust.

Para un founder con equipo de TI pequeño, la traducción es simple: deja de montar proxies propios para resolver casos raros de su entorno. Ahora escribe unas líneas de código y las ejecuta donde ya se decide si el tráfico pasa o no.

¿Qué es la acción Forward y qué cambia frente a un firewall tradicional?

Todo gateway seguro del mercado funciona igual desde hace casi 30 años: el tráfico cumple una condición y dispara una acción terminal — permitir, bloquear, aislar o registrar. Ese modelo cubre el caso común, pero tiene un techo, y los entornos complejos lo golpean seguido.

La acción Forward rompe ese esquema. Cuando una política HTTP permite el tráfico, la regla lo envía a un Cloudflare Worker que actúa como middleware en línea: recibe los encabezados y el cuerpo completos de la petición, puede modificarlos, reenviarla al origen, alterar la respuesta y devolver el resultado final al usuario.

Cloudflare se encarga de las conexiones TCP, la terminación y recifrado TLS, la gestión de certificados y la negociación de versión HTTP. El Worker solo ejecuta la lógica de transformación. Es un punto de extensión tipo proxy sin el costo operativo de mantener un proxy HTTP propio.

El caso más citado por la propia compañía es concreto: un equipo necesita inyectar encabezados HTTP basados en los claims de un JWT que emite su proveedor de identidad. El dato existe en el contexto de la petición, pero el gateway no puede leerlo ni escribirlo. La solución habitual era levantar un pool de proxies NGINX solo para esa transformación, con parcheo, monitoreo y seguridad indefinidos. Con Forward, eso es una función.

Funciones personalizadas: lógica propia dentro de la decisión de seguridad

El segundo mecanismo son las Custom Functions, que estarán disponibles antes de que termine el año. A diferencia de Forward, no transforman tráfico: se invocan en línea durante la evaluación de la política y devuelven un valor tipado —string, número o booleano— que el gateway usa como condición.

El contrato es deliberadamente simple: entran datos, sale un valor. El Worker recibe contexto de la petición (IP de origen, destino, identidad del usuario, postura del dispositivo, encabezados) y devuelve el resultado. Ese resultado se expone como un selector en el constructor de políticas y se puede combinar con selectores nativos como IP de origen o categoría de contenido.

La ventaja práctica aparece cuando la lógica de decisión vive fuera del firewall. Si tu equipo mantiene un sistema interno de scoring de riesgo que cruza varias fuentes, o mapas de usuarios y grupos con membresías condicionales, ya no hay que traducir todo eso a expresiones del proveedor: se calcula en el Worker y vuelve un único valor.

Las funciones personalizadas también aplican a tráfico de red, no solo HTTP. Como reciben identidad, postura del dispositivo y metadatos de conexión, funcionan en el constructor de políticas de red con tráfico arbitrario de capa 4.

Validación personalizada en DLP: el fin de los falsos positivos

La parte menos comentada del anuncio puede ser la más útil para equipos chicos. Las funciones de validación personalizada para DLP ya están disponibles y atacan un problema estructural: la mayoría de los productos de seguridad de datos detectan patrones, no relevancia.

Una expresión regular te dice que algo parece un secreto de GitHub. No te dice si ese secreto sigue activo. La alternativa clásica es el exact data match, que obliga a preparar, mantener y transferir datasets de referencia, además de decidir cuánta confianza depositas en el proveedor para gestionar datos de tus sistemas más sensibles.

Con validación personalizada, el Worker consulta tu propia fuente de verdad antes de que la política se aplique. El ejemplo que da Cloudflare: si detectas el uso de secretos de GitHub, el Worker consulta el estado real de la clave contra el endpoint correspondiente y decide si el perfil de DLP debe activarse o descartarse. Menos ruido, menos alertas que nadie revisa.

¿Por qué Cloudflare puede hacer esto y sus competidores no?

La respuesta está en la arquitectura, y es la parte que conviene entender antes de firmar con cualquier proveedor de SASE. Gateway y Workers corren en las mismas máquinas, en los mismos data centers. Cuando el gateway reenvía tráfico a un Worker, esa llamada es local: no hay salto de red ni latencia adicional más allá del tiempo de ejecución del código.

Los proveedores de SASE que no tienen plataforma de cómputo propia obligan a desplegar la automatización en otra nube, configurar webhooks a mano y aceptar la latencia de ida y vuelta de sistemas desconectados. Según SDxCentral, la red de Cloudflare opera en 300 ciudades de más de 100 países e interconecta 12.500 redes, y cada punto de presencia ejecuta el stack completo de seguridad.

Ese contexto importa porque el mercado se está moviendo rápido. Gartner proyecta que el mercado global de SASE superará los US$18.000 millones en 2026, con una tasa de crecimiento anual compuesta del 23% entre 2025 y 2030, según reportó SDxCentral. En el Magic Quadrant de Plataformas SASE más reciente, Netskope lidera en ejecución, Cato Networks subió al segundo lugar y Zscaler entró a los líderes, mientras Cloudflare quedó sola en el cuadrante de visionarios, reconocida por su enfoque en IA y criptografía post-cuántica.

Ese posicionamiento es la clave del anuncio: Cloudflare no compite por tener el firewall más completo, compite por ser la única plataforma donde el cómputo del cliente y el gateway de seguridad viven en el mismo lugar.

¿Qué significa esto para tu startup?

Si tu empresa ya usa Cloudflare One o está evaluando consolidar seguridad y red en un solo proveedor, el anuncio cambia el cálculo de dos maneras.

• Audita tus parches de infraestructura. Haz una lista de los proxies, scripts y pipelines que mantienes solo para adaptar el tráfico a tu entorno: inyección de encabezados, notificaciones a Slack, páginas de advertencia. Cada uno de esos es candidato a convertirse en un Worker con la acción Forward, y cada uno que eliminas es infraestructura que dejas de parchear.
• Mide el costo real de tus alertas de DLP. Si tu equipo ignora las alertas porque la mayoría son falsos positivos, la validación personalizada es la vía para conectar la detección con tu fuente de verdad. Empieza por el caso de mayor volumen y menor valor: secretos inactivos, credenciales revocadas, datos de clientes que ya no están vigentes.
• Revisa tu plan de Workers antes de escalar. El tráfico enviado a Workers se factura como peticiones estándar y funciona en los planes Free, Paid y Enterprise sin restricciones de funcionalidad. Pero el plan Free tiene límites de tiempo de ejecución y de peticiones diarias: si vas a enrutar volumen alto de tráfico corporativo, calcula ese costo antes y no después.

Un punto de cautela: las Custom Functions todavía no están en disponibilidad general. La acción Forward está en beta pública y las funciones personalizadas llegarán antes de fin de año. Si tu operación depende de ellas, conviene planificar la migración con margen y no apagar la infraestructura vieja el mismo día.

Conclusión

Durante décadas, los equipos de seguridad eligieron entre mantener su propio motor de detección —máxima personalización, máximo costo operativo— o aceptar los límites de un proveedor. Cloudflare apuesta a que ese dilema se puede romper cuando el cómputo y la seguridad comparten la misma red.

Para una startup con un equipo de TI de dos personas, la promesa es atractiva: menos piezas que mantener, más lógica propia donde importa. La letra chica es la de siempre —beta, límites de plan y dependencia de un solo proveedor. La decisión inteligente no es adoptarlo todo de golpe, sino identificar el parche de infraestructura que más te cuesta hoy y probar ahí primero.

Fuentes

• A fully programmable secure web gateway
• Gartner SASE 2026 rankings: Netskope leads, Cato Networks leaps, and Palo Alto Networks falls
• Cloudflare takes on single-vendor SASE with a homegrown approach
• Cloudflare 'Rapidly Scaling' With MSSP Partners Around SASE: Channel Chief