A Cloudflare anunciou a integração do Cloudflare Gateway e do Data Loss Prevention à plataforma de computação de borda Cloudflare Workers, em uma medida que leva o gateway web seguro de um modelo de decisões fixas, como permitir, bloquear e isolar, à execução de código personalizado dentro do próprio fluxo de avaliação da política de segurança.
Essa integração está disponível para os planos Zero Trust e oferece dois caminhos principais para chamar um Worker a partir das políticas do Gateway: uma nova ação chamada Forward, atualmente disponível em fase beta pública, e as Custom Functions, cujo lançamento está previsto para antes do fim de 2026.
Encaminhar solicitações ou executar lógica personalizada
A ação Forward funciona como um intermediário inline para as solicitações que correspondem à política. O Worker recebe os cabeçalhos e o corpo da solicitação HTTP e pode modificá-los antes de enviá-los ao serviço de origem, além de modificar a resposta antes de devolvê-la ao usuário. Já o Gateway cuida das conexões TCP, do término do TLS e da nova criptografia, do gerenciamento de certificados e da negociação da versão do HTTP, deixando ao Worker apenas a lógica de transformação.
O Forward também pode ser usado para executar ações secundárias sem interromper o fluxo da solicitação, como enviar um alerta ao Slack ou ao PagerDuty, registrar dados no R2, chamar um webhook ou atualizar um armazenamento KV. A Cloudflare afirma que a chamada do Worker ocorre na mesma infraestrutura que executa o Gateway e por meio de uma chamada local que não exige encaminhar o tráfego por uma rede separada.
Já as Custom Functions chamam um Worker durante a avaliação da política e retornam um valor do tipo texto, número ou booleano. Esse valor pode ser usado como seletor em políticas HTTP ou de rede. O Worker pode receber um contexto que inclui o endereço IP de origem, a identidade do usuário, o estado do dispositivo, os cabeçalhos HTTP e os dados da conexão, de acordo com a etapa da política.
Exemplos de uso
A Cloudflare explica que uma função personalizada pode ler uma reivindicação JWT e extrair a função ou o grupo do usuário, usando então o resultado para permitir o acesso ou adicionar um cabeçalho como X-App-Role à solicitação direcionada ao serviço de origem. Também é possível criar páginas de intercepção que solicitem ao usuário uma justificativa para acessar um destino sensível, salvando a sessão no KV e o registro de auditoria no D1 ou em um banco de dados interno por meio do Hyperdrive.
Outros usos incluem verificar arquivos por meio de um serviço externo de sandbox, enviar alertas instantâneos quando uma regra de DLP for correspondida e executar cálculos de risco baseados em várias fontes internas. A Cloudflare diferencia claramente os dois caminhos: as Custom Functions são adequadas para avaliações rápidas, específicas e sem estado, enquanto o Forward se destina à transformação de solicitações em tempo real e ao processamento da solicitação e da resposta.
Ampliando os recursos de DLP
A Cloudflare também anunciou a disponibilização de funções de validação personalizadas para o DLP. Essas funções permitem que os clientes usem sua própria fonte de verdade para verificar o resultado da detecção antes de tomar uma decisão de aplicação. Um exemplo é verificar se uma chave do GitHub detectada está realmente ativa, em vez de se limitar a corresponder a um padrão semelhante a segredos ou tokens.
A função de validação recebe um trecho dos dados e a localização da parte correspondente; em seguida, pode chamar uma interface externa e retornar um resultado que inclua uma pontuação de correspondência ou uma decisão de veto. Assim, torna-se possível diferenciar a existência de um padrão sensível de uma situação específica que represente um vazamento real ou um uso não autorizado.
O que muda na prática?
A Cloudflare busca reduzir a necessidade de uma infraestrutura intermediária gerenciada pelas equipes de segurança, como grupos NGINX usados apenas para ler reivindicações JWT ou modificar cabeçalhos. No entanto, a nova flexibilidade transfere parte da responsabilidade para o código do cliente: os aplicativos que usam o Forward devem ser projetados com cuidado para não afetar negativamente a experiência do usuário, e a falha de uma Custom Function ou o término do seu tempo de execução exigem que um comportamento de fallback seja definido previamente.
O tráfego encaminhado para o Workers é contabilizado como solicitações comuns do Workers. As funções funcionam com Workers Free, Workers Paid e Workers for Enterprise, mas o plano gratuito impõe limites ao tempo de execução e ao número diário de solicitações. A Cloudflare afirma que a disponibilidade geral dos dois caminhos será oferecida a todos os clientes e em todos os tipos de planos, enquanto planeja ampliar os pontos de integração dentro do conjunto Cloudflare One, com o Email Security como próximo passo.