Yetenek

İçerik Farkındalıklı Kurallar

Header'ın ötesine geçin; JSON, XML, multipart ve GraphQL içeriği trafik kararının parçası olsun.

TR7 İçerik Farkındalıklı Kurallar, uygulama trafiğinde karar verici değerin artık yalnızca URL, header veya IP olmadığını kabul eder. Modern API isteklerinde kritik bilgi çoğu zaman body içindedir: JSON'da kullanıcı rolü, XML zarfında servis adı, multipart formda tenant alanı veya GraphQL işlem adı. TR7, bu içerikleri tek bir FX ifade dili altında okunabilir, eşleştirilebilir ve aksiyona bağlanabilir hale getirir. JSONPath, XPath, form alanı, JWT claim, map/list eşleştirme ve regex kontrolleri aynı kural modelinde birleşir; aynı ifade hem trafik yönetimi hem WAAP skor değerlendirmesi için kullanılabilir. ADC modunda body içeriği okunabilir ve belirli senaryolarda response body üzerinde rewrite yapılabilir. WAAP modunda body bütünlüğü korunur; içerik okunur, skorlanır ve eşik aşıldığında engelleme uygulanır. Sonuç: TR7, header tabanlı kararların yetmediği API dünyasında, body içindeki veriyi doğrudan yönlendirme, koruma ve politika kararının parçası yapar.

4
Body parser tipi: JSON, XML, multipart, form-url-encoded
10+
Map ve list eşleştirme türü
1
Ortak FX dili — ADC trafiği ve WAAP skoru

Modern API trafiğinde asıl karar verisi header'da değil, body içindedir.

Geleneksel katman 7 trafik yönetimi çoğu zaman URL, metod, header ve kaynak adresi üzerinden karar verir. Bu model klasik web uygulamaları için yeterli olabilir; ancak modern API mimarisinde kritik ayrım çoğu zaman request body içindeki alanlarda yapılır. Tenant kimliği, kullanıcı rolü, işlem tipi, servis adı veya dosya yükleme bilgisi header'da değil, JSON, XML, form veya multipart içerikte bulunur.

Bu görünürlük olmadığında operatör kötü seçeneklere zorlanır. Ya trafik yönetimi önüne ayrı bir API katmanı koyar ve mimariye yeni hop, yeni lisans, yeni operasyon yükü ekler; ya da mevcut uygulamayı değiştirerek karar bilgisini header'a taşımaya çalışır. Eski ve kritik kurum servislerinde bu değişiklik çoğu zaman mümkün değildir.

Body inspection yalnızca güvenlik tarafında kalırsa da sorun çözülmez. WAAP içeriği okuyabilir ama trafik yönlendirme motoru aynı değeri kullanamıyorsa, güvenlik politikası ile trafik politikası iki ayrı dünyada yaşar. Bu da tutarsız kural yazımına, tekrar eden mantığa ve hata riskine yol açar.

Doğru model, body parser yeteneklerinin kural dilinin doğal parçası olmasıdır. JSONPath, XPath, form alanı, JWT claim, regex ve map/list kontrolleri aynı ifade ağacında çalışmalı; aynı ifade hem trafik aksiyonuna hem WAAP skoruna bağlanabilmelidir.

TR7 İçerik Farkındalıklı Kurallar bu boşluğu kapatır: body içindeki alanları yalnızca kontrol edilen veri değil, doğrudan karar veren sinyal haline getirir.

Yaklaşımımız

TR7, içerik farkındalığını ayrı bir eklenti gibi değil, trafik ve güvenlik kural dilinin yerleşik parçası olarak ele alır.

Body parser fonksiyonları doğrudan FX ifade diline gömülüdür

JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER ve JWTPAYLOAD gibi fonksiyonlar kural yazımının doğal parçasıdır. Operatör body içeriğini ayrı kod yazmadan koşula dönüştürür ve bu koşulu trafik veya güvenlik aksiyonuna bağlar.

JSON, XML ve multipart ayrıştırma modülleri runtime içinde çalışır

JSON, XML ve multipart içerikler runtime seviyesinde ayrıştırılır ve kural motoruna okunabilir değerler olarak sunulur. Böylece operatör her byte üzerinde kaba regex çalıştırmak yerine, anlamlı alanlara göre karar verir.

Aynı DSL trafik yönetimi ve WAAP skorunda kullanılır

TR7'de body alanına yazılan ifade yalnızca yönlendirme için değil, WAAP imza ve skor mantığı için de kullanılabilir. Bu ortak model, trafik kuralları ile güvenlik kuralları arasında tekrar eden mantığı azaltır.

ADC ve WAAP modları farklı bütünlük ilkeleriyle çalışır

ADC modunda body okunabilir ve uygun senaryolarda response tarafında rewrite uygulanabilir. WAAP modunda body değiştirilmez; içerik okunur, skorlanır ve politika eşiğine göre engelleme yapılır.

Yetenekler

İçerik Farkındalıklı Kurallar, body içindeki yapısal veriyi okunabilir koşullara ve uygulanabilir aksiyonlara dönüştürür.

JSONPath sorguları ile API body alanlarına doğrudan kural yazılır

JSONQUERY fonksiyonu, JSON body içindeki alanları standart JSONPath mantığıyla sorgular. Operatör `$.user.role`, `$.items[0].sku` veya `$.tenant_id` gibi değerleri doğrudan koşul olarak kullanabilir. Bu koşul bir vService yönlendirme kararına, header set etme aksiyonuna veya WAAP skor değerlendirmesine bağlanabilir. Böylece API trafiği yalnızca endpoint'e göre değil, isteğin gerçek iş anlamına göre yönetilir.

XML XPath kontrolleri SOAP ve kurumsal servis trafiğini görünür kılar

XMLQUERY, XMLPATHTYPE ve XMLPATHEXISTS fonksiyonları XML body üzerinde XPath tabanlı sorgular çalıştırır. SOAP zarfındaki servis adı, aksiyon düğümü veya işlem alanı trafik kararında kullanılabilir. Bu özellikle eski kurum servislerini değiştirmeden, servis bazlı dispatch ve güvenlik politikası uygulamak için değerlidir. XML içeriği kural motorunda yapısal veri olarak ele alınır; kör regex bağımlılığı azalır.

Form ve multipart alanları tenant, dosya ve işlem kararına bağlanır

PARAM fonksiyonu query string, form-encoded body ve form alanlarını kural koşuluna dönüştürür. Multipart parser, dosya yükleme senaryolarında form alanı, içerik tipi ve boyut gibi bilgilerin politika içine alınmasını sağlar. Bu yapı SaaS portalları, belge yükleme ekranları ve kullanıcı bazlı işlem ayrımları için kullanışlıdır. Trafik, formun taşıdığı iş bağlamına göre yönlendirilebilir veya engellenebilir.

JWT header ve payload değerleri tek fonksiyonla sorgulanır

JWTHEADER ve JWTPAYLOAD fonksiyonları token içindeki header ve payload alanlarını JSONPath ile sorgulanabilir hale getirir. Kullanıcı rolü, tenant, yetki seviyesi veya özel claim değerleri trafik ve güvenlik kararında kullanılabilir. Örneğin belirli bir claim yoksa istek reddedilebilir veya belirli role sahip kullanıcılar farklı bir kurum servisi grubuna yönlendirilebilir. Bu yaklaşım, erişim bilgisini uygulama koduna gömmeden edge seviyesinde politika üretir.

Map ve list eşleştirmeleri büyük veri kümeleriyle çalışır

MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG ve MAP_END gibi eşleştirme türleri büyük değer kümeleri üzerinde hızlı karar üretmek için kullanılır. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG ve LIST_END seçenekleri de benzer şekilde liste tabanlı kontroller sağlar. Tenant listeleri, izinli servis adları, IP aralıkları veya pattern grupları bu yapılarla yönetilebilir. Büyük kural setleri, tek tek manuel koşullar yerine merkezi veri kümelerine bağlanır.

Body boyutu, derinlik ve alan sayısı limitleri parsing öncesi kontrol edilir

BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT ve XML_NODE_COUNT kontrolleri body ayrıştırma öncesinde koruyucu sınırlar koyar. Çok büyük, aşırı derin veya şişirilmiş payload'lar kurum servisine ulaşmadan reddedilebilir. JSON_DEPTH için varsayılan değer 32'dir; ihtiyaç halinde politika seviyesinde ayarlanabilir. Bu özellik hem kaynak tüketimini kontrol eder hem de parser seviyesindeki kötüye kullanım riskini azaltır.

Allowed ve Must Args kontrolleri pozitif güvenlik modeli kurar

JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS ve FORM_ALLOWED_ARGS kontrolleri beklenen alanların varlığını ve beklenmeyen alanların yokluğunu doğrular. Bu model, yalnızca kötü pattern aramak yerine izin verilen request şeklini tanımlamaya odaklanır. Eksik zorunlu alanlar veya beklenmeyen parametreler politika gereği reddedilebilir. API sözleşmesine yakın çalışan bu yaklaşım, özellikle kritik işlem endpoint'lerinde güvenlik disiplinini artırır.

Response body rewrite ADC modunda maskeleme ve dönüşüm sağlar

ADC modunda modifyResponse aksiyonu response body üzerinde regex tabanlı substitution uygulayabilir. Kişisel veri maskeleme, link dönüştürme veya kurum içi adreslerin dış kullanıcıya uygun hale getirilmesi gibi senaryolarda kullanılabilir. WAAP modunda ise body değiştirilmez; yalnızca okunur ve skorlanır. Bu ayrım, trafik yönetimi esnekliği ile güvenlik bütünlüğünü aynı platformda dengeler.

Operasyonel derinlik

İçerik farkındalığı yalnızca kural yazımı değil; buffer yönetimi, tekrar parse önleme, audit ve edge case davranışlarıyla birlikte düşünülür.

01

Body buffer yönetimi

Body içeriği parse edilmeden önce buffer'a alınır ve ilgili JSON, XML veya multipart parser bu içerik üzerinde çalışır. Varsayılan body buffer değeri 16 KB'dir; büyük JSON veya XML gövdeleri için sistem parametreleri artırılabilir. Limit aşımı durumunda istek 413 ile reddedilerek kurum servisine yük bindirilmez.

02

Parse sonucu önbellekleme

Aynı request içinde okunan JSONPath veya XPath sonuçları işlem kapsamındaki geçici alanda saklanır. Bir kural body'yi okuduğunda, sonraki kurallar aynı alan için tekrar parse çalıştırmak zorunda kalmaz. Bu yaklaşım çoklu kural zincirlerinde gecikmeyi ve gereksiz işlem maliyetini azaltır.

03

WAAP bütünlük modeli

WAAP modunda body okunur ancak değiştirilmez. İçerik, imza, skor ve eşik mantığına girer; eşik aşıldığında istek engellenir. Böylece güvenlik katmanı request bütünlüğünü korurken içerik farkındalıklı karar verebilir.

04

Chunked request davranışı

Chunked POST isteklerinde parse işlemi chunk birleştirme tamamlandıktan sonra başlar. Bu, body alanlarının doğru ve bütün halde değerlendirilmesini sağlar. Chunked trafiklerde küçük ek gecikme oluşabilir; buna karşılık kurum servisine parçalı ve kontrolsüz payload aktarılması engellenir.

05

GraphQL görünürlüğü

GraphQL trafiğinde mevcut yaklaşım JSONPath tabanlıdır; operation name ve field listesi gibi body içindeki alanlar kural koşulunda kullanılabilir. Bu sayede mutation ve query ayrımı gibi pratik yönlendirme kararları edge seviyesinde alınabilir. Derin şema doğrulama bu sayfanın kapsamına alınmaz.

06

Audit ve SIEM izi

Hangi kuralın hangi body alanını okuduğu audit loglarına yazılabilir. Operasyon ekipleri, belirli bir isteğin neden yönlendirildiğini, reddedildiğini veya skorlandığını SIEM üzerinde takip edebilir. Bu izlenebilirlik, içerik farkındalıklı kuralların kara kutu gibi çalışmasını engeller.

Hangi senaryolarda kullanılır

JSON tenant değerine göre servis yönlendirme

SaaS ekipleri, JSON body içindeki tenant_id alanına göre trafiği farklı kurum servisi havuzlarına yönlendirebilir. Uygulama kodunu değiştirmeden tenant bazlı ayrım yapılır ve trafik politikası edge seviyesinde yönetilir.

SOAP aksiyonuna göre kurumsal servis ayrımı

Bankacılık ve kamu sistemlerinde XML zarfı içindeki aksiyon düğümü farklı servis gruplarına dispatch için kullanılabilir. Eski servis yapısı korunurken, trafik kararları içerik farkındalıklı hale gelir.

GraphQL işlem tipine göre trafik dağıtımı

Teknoloji ekipleri, operationName alanına göre query ve mutation trafiğini farklı kaynaklara yönlendirebilir. Okuma ağırlıklı istekler ayrı, yazma ağırlıklı istekler ayrı kurum servisi gruplarına aktarılır.

JWT claim değerine göre erişim kararı

Kritik uygulamalarda JWT payload içindeki rol veya tenant claim'i edge seviyesinde kontrol edilebilir. Gerekli claim yoksa istek kurum servisine ulaşmadan reddedilir; doğru claim varsa ilgili trafik politikasına alınır.

Sık sorulanlar

Body parser yetenekleri hangi içerik tiplerini destekler?
JSON, XML, multipart ve form-url-encoded içerikler runtime seviyesinde ayrıştırılır. JSON için JSONPath, XML için XPath, form ve multipart için PARAM fonksiyonu doğrudan FX ifadesi olarak kullanılır. GraphQL trafiğinde mevcut yaklaşım JSONPath tabanlıdır; operation name ve field listesi gibi body içindeki alanlar kural koşulunda değerlendirilir.
Aynı kural hem ADC trafiği hem WAAP politikasında çalışabilir mi?
Evet. TR7'de body alanına yazılan ifade yalnızca yönlendirme veya header değiştirme aksiyonu için değil, WAAP imza ve skor mantığı için de kullanılabilir. Aynı DSL iki katmanda da geçerli olduğundan trafik kuralı ile güvenlik kuralı arasında tekrar eden mantık azalır.
ADC modu ve WAAP modu arasındaki bütünlük farkı nedir?
ADC modunda body okunur ve uygun senaryolarda response body üzerinde rewrite uygulanabilir. WAAP modunda ise body değiştirilmez; yalnızca okunur, imza ve skor mantığına girer ve politika eşiği aşıldığında istek engellenir. Bu ayrım, trafik esnekliği ile güvenlik bütünlüğünü aynı platformda dengeler.
JWT içeriği kural yazımında nasıl kullanılır?
JWTHEADER ve JWTPAYLOAD fonksiyonları token'ın header ve payload alanlarını JSONPath ile sorgulanabilir hale getirir. Kullanıcı rolü, tenant, yetki seviyesi veya özel claim değerleri trafik ve güvenlik kararında kullanılabilir. Eksik veya beklenmeyen claim'lerde istek kurum servisine ulaşmadan reddedilebilir.
Büyük veya derin body içerikleri sistemi nasıl etkiler?
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT ve XML_NODE_COUNT kontrolleri parse öncesinde koruyucu sınırlar koyar. JSON_DEPTH varsayılan değeri 32'dir; aşırı büyük veya şişirilmiş payload'lar kurum servisine ulaşmadan reddedilir. Body buffer varsayılan değeri 16 KB'dir ve sistem parametreleriyle artırılabilir.
Aynı body alanı birden fazla kural tarafından okunduğunda parse tekrar çalışır mı?
Hayır. Aynı request içinde okunan JSONPath veya XPath sonuçları işlem kapsamındaki geçici alanda saklanır. Bir kural body'yi okuduğunda sonraki kurallar aynı alan için tekrar parse yapmak zorunda kalmaz. Bu yaklaşım çoklu kural zincirlerinde gecikmeyi ve işlem maliyetini düşürür.

API trafiğinizi body içeriği kararına bağlayın

JSON, XML, multipart ve JWT alanları üzerinde içerik farkındalıklı yönlendirme ve güvenlik politikası. Kendi servislerinizle canlı bir kurulumda gezdirelim.