Genel Bakış
Amacı Nedir?
API Proxy (API Vekil Sunucusu)çağrılarında gelen isteklerin başlık, parametre ve gövde içeriklerini tarayarak kötü amaçlı ifadelerin sisteminize ulaşmasını engeller.- Hassas veya kişisel verilerin backend sistemlerine iletilmeden önce anonimleştirilmesini ya da tamamen çıkarılmasını sağlar.
- Regülasyon uyumluluğu için isteklerdeki politikaya aykırı içerikleri tespit edip merkezi şekilde yönetilebilir hale getirir.
- Önceden tanımlı filtre kurallarıyla tutarlı bir güvenlik katmanı oluşturarak manual hataları azaltır.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin kaynak IP adresi tespit edilir.
- Politika Kontrolü: İçerik Filtresi politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
- Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
- Politika aktif mi (active=true)?
- Variable kullanılıyor mu yoksa Apinizer default mı?
- İçerik İnceleme Kuralları: Tanımlı her filtre kuralı için header, parametre ve gövde alanları regex tabanlı taranır; gövde için isteğe bağlı XPath veya JSONPath ile hedef alan izole edilir.
- Karar Verme:
- Eşleşme Var:
BLOCKseçilmişse istek 403 yanıtıyla sonlandırılır;DELETEseçilmişse eşleşen değer başlıktan, parametreden veya gövdeden çıkarılarak akış devam eder. - Eşleşme Yok: İstek orijinal biçimiyle bir sonraki politikaya iletilir.
- Eşleşme Var:
- Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Özellikler ve Yetenekler
Temel Özellikler
- Regex Tabanlı Kural Motoru: Kural ifadeleri ile başlık, parametre veya gövdede geçen şüpheli içerikler yakalanır ve işlendiği alanlardan kaldırılır ya da engellenir.
- Çoklu Uygulama Alanı Seçimi: Aynı kuralın header, query parametresi ve gövde üzerinde eş zamanlı uygulanmasını destekleyerek tutarlı koruma sağlar.
- İçerik Yolu Hedefleme: Gövde kontrollerinde XPath veya JSONPath ile belirli node/alanlar seçilebilir, böylece hedefe yönelik filtreleme yapılır.
- Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
- Koşul Bazlı Uygulama: Query Builder ile karmaşık koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint’lere veya header değerlerine göre).
İleri Düzey Özellikler
- Ön Tanımlı Kural Kütüphanesi: Hazır filtre kuralları listesinden seçim yaparak doğrulanmış regex ifadelerini politikaya hızla ekleme.
- İçerik Dönüşüm Testi: XPath/JSONPath ifadelerini Test Transformation modalı ile canlı veride doğrulama ve gerektiğinde iyileştirme.
- Kural Düzeyinde Eylem Seçimi: Her kural için
BLOCKveyaDELETEkararı belirlenerek farklı alanlara farklı davranış atama. - Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
- Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme. Proxy Group’lara toplu politika atama. Merkezi güncelleme ve deploy işlemleri.
- Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama deploy etme. Hangi API Proxy’lerde kullanıldığını görme (Policy Usage). Proxy Group ve Policy Group kullanım raporları.
Kullanım Senaryoları
| Senaryo | Durum | Çözüm (Politika Uygulaması) | Beklenen Davranış / Sonuç |
|---|---|---|---|
| SQL Injection Engelleme | Parametrelerde union select gibi kalıplar görülebilir | ruleValue = (?i)union.+select, paramActive = true, action = BLOCK | Kural eşleştiğinde istek 403 ile reddedilir ve backend korunur |
| Kredi Kartı Maskesi | JSON gövdesinde kart numarası taşınıyor | JSONPath $..cardNumber, regex \\b\\d{12,19}\\b, action = DELETE | Kart numarası gövdeden çıkarılır, istek kalan verilerle devam eder |
| Zararlı Header Temizliği | X-Forwarded-For başlığında yasak IP listesi var | headerActive = true, regex yasak blok, action = DELETE | Header silinir, kayıt altına alınır |
| XML Script Engelleme | XML isteğinde <script> tag’i gönderiliyor | XPath ile ilgili node seçilir, regex <script> ve altı, action = BLOCK | İstek anında bloklanır ve özel hata mesajı döner |
| DLP - Kimlik Numarası | İstek gövdesinde TC kimlik numarası paylaşılıyor | JSONPath $..identityNo, regex \\b\\d{11}\\b, action = DELETE | Kimlik numarası çıkarılır; loglarda temizlenmiş içerik görünür |
| Bot İzi Kaldırma | trackingId parametresi sistemler arası taşınmasın | Parametre seçimi, regex .+, action = DELETE | Parametre tamamen silinir, backend gereksiz veriyi görmez |
| Coğrafi Kısıtlı Mesaj | Belirli coğrafyadan gelen isteklerde hassas alan temizlensin | Condition ile ülke bazlı koşul, gövde yolu seçimi, action = DELETE | Sadece koşulu sağlayan isteklerde alan kaldırılır |
Politika Parametrelerini Yapılandırma
Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir.Yeni İçerik Filtresi Politikası Oluşturma
Yapılandırma Adımları
| Adım | Açıklama / İşlem |
|---|---|
| Adım 1: Oluşturma Sayfasına Gitme | - Sol menüden Development → Global Settings → Global Policies → Content Filtering bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın. |
| Adım 2: Temel Bilgileri Girme | Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_ContentFilter- Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: “Giriş isteklerinden hassas veriyi temizler.” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Filtre Kuralı Tanımlama | - Rule Name: İnsan tarafından okunabilir kural adı belirleyin. - Rule Expression: Regex ifadesini girin veya hazır listeden seçin. - Apply On: Header, Parameter ve Body seçeneklerini işaretleyerek kuralın etki alanını belirleyin. |
| Adım 4: Gövde İçeriği Hedefini Belirleme | - Body seçiliyse ilgili XPath veya JSONPath’i tanımlayın. - XML/JSON radyo butonları ile içerik tipini seçin. - Code editor içinde yolu düzenleyin. |
| Adım 5: Eylem ve Test Seçimi | - BLOCK ile isteği sonlandırın, DELETE ile içeriği temizleyin.- Gerekirse [Choose] ile hazır kural seçin. - [Test Data Transformation] ile XPath/JSONPath ifadesini doğrulayın. |
| Adım 6: Koşul Tanımlama (İsteğe Bağlı) | - Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production- API Key bazlı: Header = X-API-Key, Starts With = PROD-- Endpoint bazlı: Path = /api/admin/*Koşul tanımlamazsa politika her zaman aktif |
| Adım 7: Hata Mesajı Özelleştirme (İsteğe Bağlı) | - Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 403, "message": "[Default hata mesajı]" }Özel: { "statusCode": 403, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Özel mesaj]" } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir filtre kuralı mevcut Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır. |
Politikayı Silme
Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Nedir? sayfasındaki Politikayı Silme bölümüne bakabilirsiniz.Politikayı Dışa/İçe Aktarma
Bu politikanın dışa aktarma (Export) adımları ve kullanılabilecek seçenekler için Politika Nedir? sayfasındaki Politikayı Dışa/İçe Aktarma bölümüne bakabilirsiniz.Politikayı API’ye Bağlama
Bu politikanın API’lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API’ye Bağlama bölümüne bakabilirsiniz.İleri Düzey Özellikler
| Özellik | Açıklama ve Kullanım Adımları |
|---|---|
| Regex Şablon Yönetimi | - Politika düzenleme ekranında kural listesine gidin. - [Choose] bağlantısıyla hazır regex’i seçin veya manuel girin. - Kaydetmeden önce test edip onaylayın. |
| XPath/JSONPath Doğrulama | - Body seçeneğini aktif edin ve içerik tipini belirleyin. - Code editor’de yolu tanımlayın. - [Test Data Transformation] ile ifadenin doğru değer döndürdüğünü doğrulayın. |
| Kural Bazlı Eylem Ayrımı | - Her kural için BLOCK veya DELETE seçeneğini belirleyin.- Bloklanan kurallar için hata mesajını Error Message sekmesinden özelleştirin. - Delete seçeneği kullanılan kuralların log’larını gözden geçirin. |
Best Practices
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| Regex Yönetimi | Kötü: Tüm saldırıları tek bir geniş regex ile yakalamaya çalışmak. İyi: Saldırı tipine göre ayrı regex’ler tanımlamak. En İyi: Hazır şablonları baz alıp proje ihtiyaçlarına göre küçük eklemeler yapmak. |
| İçerik Yolu Tanımları | Kötü: Gövdeyi tamamen hedef almak. İyi: Kritik alanlar için XPath/JSONPath belirlemek. En İyi: Hem path hem regex kullanıp minimum kapsamda maksimum koruma sağlamak. |
| Eylem Seçimi | Kötü: Her kuralı BLOCK yapmak ve hatalı pozitiflerde istekleri kesmek.İyi: Silinebilir alanlar için DELETE, riskli durumlar için BLOCK seçmek.En İyi: Delete sonrası log izleme ve gerektiğinde blok moduna geçiş planlamak. |
| Ön İzleme ve Test | Kötü: Üretime almadan test yapmamak. İyi: Geliştirme ortamında test verileriyle denemek. En İyi: Test Transformation aracı ve pre-prod trafik shadowing ile doğrulama yapmak. |
| Politika Koşulları | Kötü: Politikayı her isteğe uygulamak. İyi: Ortam veya endpoint bazlı koşullar tanımlamak. En İyi: Riskli endpoint’ler için dar kapsamlı koşullar, düşük riskli alanlar için hafif kurallar belirlemek. |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| DLP Koruması | Hassas veri (kimlik, kart, IBAN) regex’lerini düzenli olarak güncelleyin ve Delete modunda saklayın. |
| Header Sağlamlığı | Zincir proxy’lerde gelen başlıklarda güvenilmeyen değerleri filtreleyin, delete sonrası loglayın. |
| Regex Performansı | ReDoS’a yol açabilecek kompleks regex’lerden kaçının; gerekirse atomic gruplar kullanın. |
| Hata Mesajı İçeriği | Block durumunda dönen mesajlarda iç yapıyı ifşa etmeyin; genel ama takip edilebilir kodlar kullanın. |
| Log Hijyenini Koruma | Delete edilen içerikleri loglamayın; anonimleştirilmiş maskeleri tercih edin. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Aşırı Genel Regex | Neden kaçınılmalı: Yanlış pozitiflere yol açarak meşru trafiği durdurur. Alternatif: Spesifik saldırı imzaları kullanın. |
| Path Tanımlamamak | Neden kaçınılmalı: Tüm gövdeyi silme riskini artırır. Alternatif: XPath/JSONPath ile noktasal alanı hedefleyin. |
| Koşulsuz Global Uygulama | Neden kaçınılmalı: Düşük riskli endpointlerde gereksiz yük oluşturur. Alternatif: Query Builder ile hedefli koşullar tanımlayın. |
| Test Etmeden Deploy | Neden kaçınılmalı: Üretimde blokaj veya veri kaybı yaşanır. Alternatif: Test aracında regex/path kombinasyonunu doğrulayın. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| Regex Karmaşıklığı | Öneri: Non-greedy desenler ve sınırlı lookaround kullanın. Etki: CPU kullanımını azaltır, throughput artar. |
| Kural Sayısı | Öneri: Kuralları risk seviyesine göre gruplandırın, gereksiz kopyaları temizleyin. Etki: İstek başına değerlendirme süresi kısalır. |
| Body İşleme | Öneri: Mümkün olduğunca path ile alt içerikleri seçin. Etki: Büyük gövdelerde parse maliyeti azalır. |
| Koşul Kullanımı | Öneri: Politikanın çalışmadığı durumları koşulla hariç tutun. Etki: Gereksiz regex çalıştırmaları engellenir. |
| Log ve İzleme | Öneri: Delete edilen alanları sayısal metrik olarak toplayın, tam içeriği loglamayın. Etki: I/O yükü düşer, gizlilik korunur. |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | İçerik Filtresi Politikası hangi tür verileri denetler? | Header, query parametreleri ve JSON/XML gövdeleri regex tabanlı olarak taranır. Body için isteğe bağlı XPath/JSONPath hedeflenebilir. |
| Genel | Politika global ve local farklı çalışır mı? | Davranış aynıdır; global politika tüm proxy’lere uygulanabilirken local politika yalnızca belirlenen API Proxy (API Vekil Sunucusu) üzerinde çalışır. |
| Teknik | Regex ifadesi olarak hangi standart kullanılır? | Java regular expression söz dizimi kullanılır; Pattern.compile() ile derlenir ve Matcher.find() ile eşleşme aranır. |
| Teknik | DELETE eylemi body’de nasıl uygulanıyor? | Path tanımlıysa ilgili node silinir, tanımsızsa gövde boş string’e çekilir ve istek devam eder. |
| Kullanım | Hata mesajı nasıl özelleştirilir? | Error Message sekmesinde durum kodu, mesaj ve hata kodu alanları düzenlenebilir; bloklanan kural adı parametre olarak kullanılabilir. |
| Kullanım | Hazır filtre kuralları nereden geliyor? | Admin → Predefined Filter Rules bölümünde yönetilen global kural kütüphanesinden çekilir ve seçim dialogunda listelenir. |