Cloudflare Gateway, programlanabilir Forward aksiyonu ve özel policy fonksiyonları kazandı

Cloudflare, secure web gateway ürününü müşteri tarafından yazılan kodun etrafında yeniden yapılandırdı. Cloudflare blog'una göre şirket, Gateway policy'lerinden Cloudflare Workers çağırmanın iki yolunu ekliyor: şu anda public beta aşamasında olan yeni Forward aksiyonu ve yıl sonundan önce beklenen özel doğrulama fonksiyonları. Her ikisi de tüm Zero Trust planlarında kullanıma sunuluyor.

Statik gateway'lere karşı gerekçe

Cloudflare'in çerçevesi şöyle: Piyasadaki her secure web gateway — şu ana kadar Cloudflare'inki de dahil — bir koşul artı terminal bir aksiyona (allow, block, isolate veya log) indirgeniyor. Bu model yaklaşık 30 yıldır ağ güvenliğinin temelini oluşturuyor ama karmaşık ortamlarda yetersiz kalıyor. Yazıda ayrıca sektörün "programlanabilirlik" kelimesini ne kadar gevşek kullandığına dikkat çekilerek public API'lerin, Terraform provider'ların, webhook'ların ve alerting'in buna dahil olmadığı savunuluyor. Cloudflare'in tanımına göre gerçek programlanabilirlik, bir güvenlik kararının verildiği anda, tam o anda, rastgele müşteri mantığını inline çalıştırmak anlamına geliyor.

Forward aksiyonu ne yapıyor

Forward, eşleşen bir HTTP isteğini bağlı bir Worker'a proxy'leyen yeni bir policy aksiyonu. HTTP policy'leri tarafından zaten allow edilmiş trafik için değerlendiriliyor ve ilk eşleşen Forward kuralı uygulanır. Worker burada inline bir middleware gibi davranıyor: header'ların tamamını ve istek gövdesini görüyor, ikisini de yeniden yazabiliyor, origin'i çağırabiliyor, dönüş yolunda yanıtı düzenleyebiliyor ve kullanıcıya geri döndürebiliyor.

Gateway, altyapı işlerinin sahipliğini elinde tutuyor — TCP bağlantıları, TLS termination ve yeniden şifreleme, sertifika yönetimi ve HTTP sürüm müzakeresi — yani Worker yalnızca dönüşüm mantığını taşıyor. Cloudflare bunu, geleneksel bir proxy barındırmanın operasyonel maliyeti olmadan proxy benzeri bir genişletme noktası olarak sunuyor.

Bir Forward kuralının bir şeyi dönüştürmesi gerekmiyor. Cloudflare, bir kuralın yalnızca bir isteğin bağlamını asenkron şekilde dağıtmak için var olabileceğini belirtiyor: trafik hedefine dokunulmadan devam ederken Slack'e mesaj göndermek, R2'ye yazmak, KV'yi güncellemek veya bir webhook çağırmak.

Özel fonksiyonlar dış veriyi policy'ye taşıyor

İkinci mekanizma olan özel fonksiyonlar, policy değerlendirmesi sırasında bir Worker'ı inline çağırıyor ve döndürdüğü değeri Gateway policy builder'da bir selector olarak kullanıyor. Bu selector herhangi bir ağ veya HTTP Gateway kuralının koşulunda yer alabiliyor; böylece ekipler kendi verilerini — kimlik öznitelikleri, risk sinyalleri, varlık envanterleri — olayları başka bir yerde sonradan işleme tabi tutmak yerine doğrudan allow ve block kararlarına taşıyabiliyor.

Cloudflare'in bunun ortadan kaldırdığını söylediği sorunlar

Blog, Gateway'i altı yıl boyunca geliştirme deneyiminden tekrarlayan senaryolara değiniyor: yalnızca kimlik sağlayıcısındaki JWT claim'lerinden türetilen HTTP header'larını enjekte etmek için bir NGINX proxy havuzu çalıştırmak zorunda kalan bir ekip; SaaS kayıtlarında uyarı vermek için Logpush, bir SIEM ve Slack'i bir araya getirip 5 ila 15 dakikalık bir gecikmeyi ve teslimat garantisi olmamasını kabul eden bir diğeri; ve hassas hedeflere erişmeden önce kullanıcılardan gerekçelerini isteyen dinamik uyarı sayfaları isteyen kurumsal firmalar. Her durum, güvenlik ekiplerinin güvenlik duvarlarının varlığından beri karşılaştığı aynı ödünleşimi ortaya koyuyor: maksimum kontrol için özel proxy veya tespit altyapısı sürdürmek ya da bakım yükünden kurtulmak için satıcının sabit özellik setini kabul etmek.

Birlikte konumlandırulmuş compute iddiası

Cloudflare, bunu çözmede kendine özgü bir konumda olduğunu savunuyor; çünkü Gateway policy'yi uyguluyor ve Workers aynı 330'dan fazla veri merkezinde, aynı makinelerde çalışıyor. Şirkete göre trafiği bir Worker'a yönlendirmek, bir ağ sınırı geçişi nedeniyle ekstra gecikme olmadan yerel olarak bir fonksiyon çağrısı olarak ele alınıyor. Yazıya göre compute platformu olmayan bağımsız SASE satıcılarıysa müşterileri ayrı bulutlara, manuel webhook yapılandırmasına ve gidiş-dönüş yüküne itiyor. Bunlar bağımsız olarak kıyaslanmış rakamlar değil, satıcı iddiaları.

Neden önemli

Secure web gateway'ler her zaman yapılandırabileceğiniz ama programlayamadığınız policy motorları olmuştur. Müşteri kodunu uygulama yoluna taşımak — proxy çiftlikleri veya olay boru hatları işletmeden — esneklik ile yönetilen altyapı arasındaki köklü bir ya da'yı ortadan kaldırıyor ve tehdit faaliyeti hızlandıkça tespit ve müdahale döngülerini kısaltabilir. Bu aynı zamanda stratejik bir farklılaştırıcı: birlikte konumlandırulmuş compute ve güvenlik uygulaması pratikte tutarsa, bağlantısız sistemleri birbirine dikmek zorunda kalan SASE rakipleri için çıtayı yükseltir. Şimdilik yalnızca Forward aksiyonu public beta'da; özel fonksiyonlar henüz yayınlanmadı, dolayısıyla tamamen programlanabilir gateway hikâyesinin doğrulanması yıl sonunu bulacak.