Cloudflare Gateway y DLP: Programabilidad en el Edge con Workers

El problema fundamental que aborda esta evolución es la rigidez inherente de los Secure Web Gateways (SWG) tradicionales y las soluciones de seguridad perimetral. Durante décadas, estos sistemas han operado bajo un modelo binario de 'condición-acción' (permitir, bloquear, aislar, registrar), lo que limita severamente la capacidad de las organizaciones para implementar lógicas de seguridad personalizadas y dinámicas. Esta limitación obliga a las empresas a elegir entre la alta sobrecarga de mantenimiento de una infraestructura de seguridad autogestionada (proxies NGINX, SIEMs complejos) o la inflexibilidad de las soluciones de proveedores con funcionalidades predefinidas.

La tesis central es que la seguridad perimetral moderna, especialmente en entornos Zero Trust, requiere una programabilidad arbitraria y de baja latencia en el punto de decisión de la política. La aparición de plataformas de edge computing distribuidas globalmente, como Cloudflare Workers, ha creado una oportunidad para fusionar la evaluación de políticas de seguridad con la ejecución de código personalizado. Esto permite a los ingenieros extender las capacidades del SWG y DLP con lógica específica de negocio, sin introducir latencia adicional ni la complejidad operativa de sistemas externos, resolviendo así el dilema histórico entre personalización y simplicidad operativa.

Arquitectura del Sistema

La arquitectura se basa en la co-localización de Cloudflare Gateway/DLP y Cloudflare Workers en la misma infraestructura de edge global. Cuando una política de Gateway o DLP coincide, el tráfico puede ser dirigido a un Worker de dos maneras principales: a través de una acción 'Forward' o una 'Custom Function'.

La acción 'Forward' opera como un proxy en línea. Una vez que una política HTTP de Gateway permite el tráfico y una regla 'Forward' coincide, la solicitud HTTP completa (headers y body) se envía a un Worker. Este Worker actúa como middleware, pudiendo modificar la solicitud antes de enviarla al origen, recibir la respuesta del origen, modificarla y devolverla al usuario. Gateway gestiona las conexiones TCP, terminación/re-encriptación TLS, y negociación de versiones HTTP, delegando al Worker solo la lógica de transformación. La invocación del Worker es una llamada de función local, sin cruce de límites de red, minimizando la latencia.

Las 'Custom Functions' son invocadas en línea durante la evaluación de políticas de Gateway o DLP. Reciben un contexto enriquecido de la solicitud (IP de origen, destino, identidad del usuario, postura del dispositivo, headers HTTP, metadatos de conexión L4) y devuelven un valor tipado (string, number, boolean). Este valor se utiliza como un selector en las condiciones de las reglas de Gateway, similar a los selectores incorporados. El Worker puede realizar llamadas a APIs externas, leer de KV o D1, o invocar Workers AI, pero desde la perspectiva de Gateway, la función es determinista (entrada de datos, salida de valor). Para DLP, las 'Custom Functions' permiten lógica de validación personalizada, por ejemplo, verificando la validez de un secreto detectado contra una API externa antes de aplicar una política de prevención de pérdida de datos. La infraestructura subyacente de Workers se basa en el motor V8 de Chrome, proporcionando un entorno de ejecución aislado y de alto rendimiento.

import { WorkerEntrypoint } from "cloudflare:workers";
import type {
  GatewayMiddlewareContext,
  GatewayMiddlewareNext,
} from "@cloudflare/zt-types";

export class GatewayMiddleware extends WorkerEntrypoint {
  async handle(
    request: Request,
    context: GatewayMiddlewareContext,
    next: GatewayMiddlewareNext,
  ): Promise<Response> {
    const clientIP = context.srcIp;
    request.headers.set("X-Gateway-Client-IP", clientIP);
    const response = await next(request);
    response.headers.set("X-Processed-By", "gateway-middleware");
    return response;
  }
}

export class GatewayCustomSelector extends WorkerEntrypoint {
  async compute(ctx: GatewayContext): Promise<string> {
    const authHeader = ctx.request.headers.get("Authorization");
    if (!authHeader) return "anonymous";
    const token = authHeader.replace("Bearer ", "");
    const payload = JSON.parse(atob(token.split(".")[1]));
    return payload.groups?.[0] ?? "unknown";
  }
}

import {
  DlpValidation,
  type DlpValidationInput,
  type DlpValidationResult,
} from "@cloudflare/zt-types";

export class DlpValidationEntrypoint extends DlpValidation {
  async validate({ excerpt, start, end }: DlpValidationInput): Promise<DlpValidationResult> {
    const bytes = Uint8Array.from(atob(excerpt), (c) => c.charCodeAt(0));
    const token = new TextDecoder().decode(bytes.slice(start, end));
    const res = await fetch("https://api.GitHub.com/user", {
      headers: {
        Authorization: `Bearer ${token}`,
        "User-Agent": "dlp-GitHub-validator",
        Accept: "application/vnd.GitHub+json",
      },
    });
    if (res.ok) return { score: 1.0 };
    if (res.status === 401) return { score: "veto" };
    return { score: 0 };
  }
}

Fundamentos Teóricos

Este enfoque resuena con principios de sistemas distribuidos y seguridad que han sido explorados en la academia. La idea de mover la lógica de procesamiento y decisión al 'edge' o cerca de la fuente de datos se alinea con el concepto de 'fog computing' o 'edge computing', que busca reducir la latencia y el ancho de banda al procesar datos más cerca de donde se generan, en lugar de centralizarlos en un datacenter. Aunque no es un paper específico, la filosofía de 'programabilidad en el punto de decisión' es una extensión de los principios de 'policy-based management' en redes y sistemas distribuidos, donde las políticas se definen de forma declarativa y se aplican mediante motores de ejecución. La capacidad de inyectar lógica arbitraria en la ruta de datos también se relaciona con conceptos de 'programación de red' (network programmability) y 'software-defined networking' (SDN), donde la capa de control se desacopla de la capa de datos y se expone a la programación para una mayor flexibilidad y adaptabilidad. La ejecución de código en un entorno aislado y seguro como Workers (basado en V8) también se conecta con la investigación en sandboxing y virtualización ligera para entornos de ejecución de funciones sin servidor (serverless functions), buscando eficiencia y seguridad.