Cloudflare a anunțat pe 15 octombrie 2026 acțiunea Forward, în beta public, și funcțiile custom pentru Gateway și DLP, care permit rularea de cod propriu direct în calea de evaluare a politicilor de securitate. Modelul clasic allow, block, isolate, log nu dispare, dar încetează să mai fie singura variantă pentru medii complexe, conform anunțului Cloudflare.

Ce s-a anunțat, concret

Vestea are două componente distincte, cu status diferit, iar asta contează pentru oricine planifică un proiect.

Prima este acțiunea Forward, disponibilă începând de astăzi în beta public. O regulă de politică HTTP poate ruta cererea potrivită către un Cloudflare Worker care acționează ca middleware inline. Worker-ul primește headerele complete și corpul cererii, poate modifica oricare dintre ele, poate trimite cererea către origin, poate modifica răspunsul primit și îl returnează utilizatorului. Cloudflare se ocupă de conexiunile TCP, terminarea TLS, managementul certificatelor și negocierea versiunii HTTP. Codul clientului se ocupă doar de logica de transformare.

A doua componentă este funcția custom, anunțată pentru disponibilitate până la finalul anului 2026, deci nu astăzi. O funcție custom apelează un Worker inline în timpul evaluării politicii și returnează o valoare tipizată, string, număr sau boolean. Valoarea devine un selector folosibil în condiția oricărei reguli Gateway, la fel cum funcționează azi selectori precum IP sursă sau categorie de conținut. Contractul e simplu: date intră, valoare iese.

Un detaliu de reținut: la disponibilitatea generală, ambele vor fi accesibile pentru toate planurile, iar traficul trimis către Workers se facturează ca cereri standard de Worker.

De ce limitele actuale contează mai mult decât pare

Argumentul central al Cloudflare este unul structural, nu de marketing. Gateway-urile clasice funcționează prin potrivire de condiții și acțiuni terminale. Pentru cazurile comune e suficient. Pentru medii complexe, plafonul apare repede, iar soluția improvizată e întotdeauna aceeași: încă o bucată de infrastructură de întreținut la nesfârșit.

Exemplele din anunț sunt ilustrative pentru tiparul problemei. Un echipaj care trebuie să injecteze headere HTTP pe baza unor claim-uri JWT din furnizorul de identitate nu poate face asta cu Gateway, așa că ridică un pool de proxy-uri NGINX doar pentru transformare. Alt echipaj vrea notificare în Slack când un angajat se înscrie la un serviciu SaaS nou; motorul de politici vede evenimentul, dar poate doar să permită sau să blocheze, așa că se construiește o conductă Logpush către SIEM către Slack, cu întârziere de 5 până la 15 minute și fără garanție de livrare.

Aici e miezul discuției. Fiecare dintre aceste soluții ocolitoare adaugă suprafețe de atac, patch-uri, monitorizare și oameni care trebuie să le știe. Securitatea nu devine mai bună, devine doar mai fragmentată.

Ce se poate construi efectiv

Anunțul listează câteva scenarii care nu sunt teoretice, ci cerute de clienți de ani de zile.

Pagini de justificare a accesului. Un Worker interceptează cererea către o destinație sensibilă și returnează o pagină intermediară în care utilizatorul trebuie să scrie un motiv. Worker-ul scrie sesiunea cu TTL în KV, ca solicitarea să apară o singură dată per perioadă configurată, și înregistrează identitatea și justificarea în D1 sau, prin Hyperdrive, în orice bază de date internă existentă. Rezultatul e un audit trail real, nu o promisiune.

Injectare dinamică de headere. O funcție custom parsează JWT-ul din header-ul Authorization, extrage rolul sau grupul utilizatorului și îl returnează ca valoare de selector. O regulă Gateway potrivește acea valoare și setează header-ul X-App-Role pe cererea către upstream. Fără pool de NGINX, fără infrastructură suplimentară.

Inspecție și logare de fișiere. La descărcarea unui fișier care îndeplinește anumite criterii, un Worker poate trimite documentul către un serviciu terț de sandboxing pentru detonare și analiză, sau îl poate scrie integral în R2 ca înregistrare permanentă, fără ca fișierul să părăsească rețeaua Cloudflare.

Alerte în timp real. Un Worker legat de o politică Forward primește trafic ori de câte ori se potrivește un profil DLP și trimite mesaj către Slack sau PagerDuty cu email-ul utilizatorului, regula declanșată și URL-ul destinației. Fără întârzierea de 5 până la 15 minute a unei conducte Logpush.

Logică complexă de evaluare. Sistemele interne de scoring de risc care fac analiză comportamentală pe mai multe surse de date, sau hărțile complexe de utilizatori, grupuri și apartenențe condiționate, pot fi evaluate de o funcție custom care returnează o singură valoare către Gateway. Constructorii clasici de expresii nu sunt proiectați pentru astfel de calcule.

Ce rămâne de verificat, nu de presupus

Aici trebuie făcută o distincție clară între ce e măsurat și ce e ipoteză.

Afirmația Cloudflare că trimiterea către un Worker nu introduce un salt de rețea, pentru că Gateway și Workers rulează pe aceleași mașini, este o afirmație a furnizorului, nu o măsurătoare independentă. E plauzibilă arhitectural, dar impactul real de performanță depinde de codul pe care îl scrie clientul. Cine susține că nu există niciun cost de latență ar trebui să măsoare în propriul mediu înainte să planifice un rollout.

La fel, disponibilitatea în România nu este detaliată explicit în materialul sursă. Beta public sugerează acces, dar nu confirmă condiții locale de facturare, suport sau limite de plan. Verificați în cont, nu pe baza unui anunț.

Comportamentul la eroare este configurabil per funcție, cu valori implicite obligatorii în contract, ceea ce e un semn bun de design. Dar modul în care fallback-ul interacționează cu politicile existente în medii mari e exact tipul de lucru care se dovedește doar la testare.

Ce înseamnă pentru tine, ca antreprenor sau marketer în România

Dacă ai un business online cu echipă distribuită și accesezi un panou de administrare Shopify, un cont de ads sau un CRM cu date de clienți, această schimbare te privește indirect, dar te privește.

Astăzi, dacă vrei ca un contractor să vadă doar rapoartele de campanie, nu și datele de facturare, alegerea e binară: îi dai acces complet sau deloc. Cu funcții custom care citesc rolul din token și îl folosesc ca selector de politică, scenariul devine fezabil fără să construiești un proxy intern. Pentru un business de 10 sau 50 de oameni, asta înseamnă mai puțin timp pierdut pe administrare de acces și mai puțin risc de scurgere de date prin conturi prea permisive.

Al doilea câștig, mai puțin evident, e auditul. Paginile de justificare cu trail în baza de date transformă întrebarea „cine a accesat ce” dintr-o discuție în ceva verificabil. Pentru orice business care lucrează cu date de clienți și vrea să demonstreze control, asta are valoare reală, nu doar pentru echipele de securitate enterprise.

Un avertisment: nu confunda anunțul cu o soluție gata de implementat. Forward e în beta, funcțiile custom vin până la finalul anului, ambele fără termene ferme. Dacă ai nevoie de control de acces granular astăzi, planifică, nu presupune.

Pentru context mai larg despre cum se leagă securitatea infrastructurii de munca de marketing, merită citit și materialul despre autonomia agenților AI fără haos, unde aceeași tensiune între flexibilitate și control apare din alt unghi, plus analiza despre ce poate și ce nu poate face un audit automat, relevantă pentru oricine e tentat să creadă că o unealtă rezolvă singură o problemă de proces.

FAQ

Forward e disponibil acum sau doar anunțat?

Acțiunea Forward este în beta public începând cu 15 octombrie 2026. Funcțiile custom sunt anunțate pentru disponibilitate până la finalul anului 2026, dar fără o dată fermă. La disponibilitatea generală, ambele vor fi accesibile pe toate tipurile de plan, iar traficul către Workers se facturează ca cereri standard.

Trebuie să fiu pe un plan enterprise ca să le folosesc?

Materialul sursă spune că la disponibilitatea generală ambele vor fi pentru toate planurile, incluzând Workers Free, Paid și Enterprise, fără restricții de funcționalitate. Totuși, nu sunt detaliate limitele concrete de execuție sau costurile reale pentru volume mari, deci verificarea în propriul cont rămâne necesară.

Care e diferența practică între Forward și funcția custom?

Funcția custom e o evaluare scurtă, stateless, care primește date și returnează o valoare folosită în condiția unei reguli. Forward e transformare inline pe cererea live a utilizatorului, pe egress și pe retur, și trebuie proiectată atent ca să nu afecteze experiența utilizatorului final.

Concluzia ALLSoft Agency

Uneltele programabile mută munca de la configurare manuală către cod scris o dată și întreținut corect. AI-ul ajută la analiză și planning: poate schița logica unui Worker, poate propune structura de politici, poate verifica consistența. Dar decizia despre ce acces primește cine, ce date ies din organizație și unde se pune fallback-ul rămâne a operatorului, nu a modelului. Execuția cere un om care înțelege mediul.

Noi nu vindem promisiuni de la furnizori. Când un anunț ca acesta apare, îl citim, separăm beta de general availability, măsurăm în cont înainte să recomandăm ceva și spunem clar ce nu știm încă. Pasul concret îl face un media buyer sau un operator care verifică, nu un slide.

Dacă vrei să discutăm despre controlul accesului și securitatea infrastructurii tale, începe de la ALLSoft Agency.