Genel Bakış
Amacı Nedir?
- Erişim Güvenliğini Artırmak: API Gateway (API Vekil Sunucusu) üzerinden sunulan servislere yalnızca güvenilir IP adreslerinden erişim sağlanmasını garanti eder.
- Yetkisiz Erişimi Engellemek: Beyaz listede yer almayan kaynaklardan gelen istekleri otomatik olarak reddederek güvenlik açıklarını minimize eder.
- Coğrafi Kısıtlama Uygulamak: Belirli ülke ve şehirlerden gelen istekleri kabul ederek veya engelleyerek coğrafi bazlı güvenlik politikaları oluşturur.
- Merkezi IP Yönetimi: IP grupları kullanarak aynı IP setlerini farklı politikalarda tekrar kullanılabilir hale getirir.
- Dinamik IP Yönetimi: Variable (değişken) mekanizması ile runtime’da IP listesini dinamik olarak değiştirme imkanı sağlar.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemcinin kaynak IP adresi tespit edilir.
- Politika Kontrolü: IP Beyaz Listesi 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 mi?
- IP Doğrulama: İstemci IP adresi şu kaynaklardan biriyle eşleşiyor mu kontrol edilir:
- Manuel tanımlanan IP listesi (ipList)
- IP Gruplarındaki IP’ler (ipGroupIdList)
- Geolocation ayarları (geoLocationDataList)
- Karar Verme:
- Eşleşme Var: İstek bir sonraki politika adımına veya backend servisine yönlendirilir.
- Eşleşme Yok: İstek reddedilir ve özelleştirilmiş hata mesajı döndürülür (default: 403 Forbidden).
- Hata İşleme: Politika kuralına uymayan isteklere özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Özellikler ve Yetenekler
Temel Özellikler
- Manuel IP Listesi Yönetimi: IPv4 adresleri ve CIDR notasyonu (örn: 192.168.1.0/24) ile IP aralıklarını tanımlama. Her IP adresi virgül ile ayrılarak eklenebilir ve gerçek zamanlı doğrulama yapılır.
- IP Grubu Entegrasyonu: Önceden tanımlanmış IP gruplarını politikaya ekleme. Birden fazla IP grubunu aynı anda seçme ve yönetme imkanı. IP grupları merkezi olarak güncellenir, politikada otomatik yansır.
- Global ve Local Politika Desteği: Global olarak tanımlanıp birden fazla API Proxy’de kullanılabilir veya spesifik bir API Proxy için local politika olarak yapılandırılabilir.
- Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırma 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
- Geolocation (Coğrafi Konum) Desteği: Geolocation servis entegrasyonu ile ülke ve şehir bazında IP kontrolü. Tüm ülke veya spesifik şehirlerden gelen istekleri kabul etme/engelleme. Birden fazla ülke ve şehir kombinasyonu tanımlama imkanı.
- Variable (Değişken) Mekanizması: Variable kullanarak IP listesini runtime’da dinamik olarak değiştirme. Harici sistemlerden (database, cache, API) IP listesi alma. Variable ile merge etme veya override etme seçenekleri.
- Hata Mesajı Özelleştirme: HTTP durum kodu özelleştirme (default: 403). Custom JSON veya XML hata mesajı tanımlama. Farklı hata senaryoları için farklı mesajlar yapılandırma.
- 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ç |
|---|---|---|---|
| Kurumsal Ağdan Erişim | Yalnızca şirket içi ağdan (192.168.0.0/16) API’lere erişim izni verilmesi gerekiyor | IP listesine 192.168.0.0/16 CIDR bloğunu ekleyin. Politikayı ilgili API Proxy’ye lokal veya global olarak atayın. | Sadece 192.168.x.x ağından gelen istekler kabul edilir. Diğer IP’lerden 403 hatası döner. |
| Üçüncü Parti Entegrasyon | Belirli bir partner firmanın sabit IP’lerinden (203.0.113.10, 203.0.113.11) gelen isteklere izin vermek | IP listesine 203.0.113.10 ve 203.0.113.11 adreslerini ekleyin. Gerekirse “Partner IP Grubu” oluşturup tekrar kullanın. | Sadece partner IP’lerinden gelen istekler kabul edilir. Entegrasyonlar güvenli şekilde çalışır. |
| Coğrafi Kısıtlama | Sadece Türkiye’den (TR) gelen isteklerin kabul edilmesi | Geolocation ayarlarını etkinleştirin. “Ülke Seç” listesinden Türkiye’yi seçin ve politikaya ekleyin. | İstemci IP’si Türkiye coğrafyasına ait değilse 403 hatası döner. TR IP’leri kabul edilir. |
| Şehir Bazlı Erişim | Yalnızca İstanbul ve Ankara şehirlerinden gelen istekleri kabul etme | Geolocation bölümünden Türkiye’yi seçin. Şehir listesinden İstanbul ve Ankara’yı seçin. “Ekle” butonuna tıklayın. | Sadece İstanbul ve Ankara şehirlerinden gelen IP’ler kabul edilir. Diğer şehirler reddedilir. |
| Geliştirme/Test Ortamı | Test ortamında sadece QA ekibinin IP’lerinden erişim izni | ”QA Team IPs” adında bir IP Grubu oluşturun. Bu grubu politikaya ekleyin. Test ortamına özel global politika yapın. | QA ekibi test API’lere erişebilir. Üretim ortamında farklı politika uygulanır. |
| Dinamik IP Yönetimi | IP listesi düzenli olarak değişiyor (günlük güncelleme) | Variable mekanizması kullanın. Variable’ı external sistemden (database, API) besleyin. Politikada “Use Apinizer Default” kapatıp variable seçin. | Her istek geldiğinde variable’dan güncel IP listesi alınır. Manuel güncelleme gerekmez. |
| Acil Durum Erişimi | Belirli bir kritik IP’den gelen istekleri her zaman kabul etme | Manuel IP listesine kritik IP’yi ekleyin. Koşul bölümünde acil durum header’ı kontrolü ekleyin (opsiyonel). | Kritik IP her zaman erişim sağlar. Acil durumlarda politika bypass edilebilir. |
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. Tanımlanan parametreler, politikanın çalışma şeklini (örneğin hangi IP’lerin izinli olacağı, coğrafi kısıtlamalar, koşullu aktivasyonlar vb.) doğrudan etkiler. Bu sayede politika hem kuruma özel gereksinimlere göre özelleştirilebilir hem de merkezi olarak yönetilebilir.Yeni Allowed IP List 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 → Allowed IP List 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_IP_Whitelist- 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: “Prod ortamı için yalnızca kurum içi ve partner sistemlerinden gelen isteklere izin verir.” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: IP Listesi Yapılandırması | Use Apinizer Default: ☑️ Varsayılan IP algılama mekanizmasını kullanır. Kendi değişkeninizi (Variable) tanımlamanız gerekir. IP Ekleme: - Tekil IP: 192.168.1.100 → Enter veya ✓ ile eklenir.- CIDR: 192.0.2.0/24 → 192.0.2.0–192.0.2.255 arası kapsanır./24 → 256 IP, /30 → 4 IP, /32 → tekil IP. IP Silme: IP etiketine veya ✕ simgesine tıklayın. IP aralığı belirtmek için (’*’ ve ’-’) karakterleri kullanılabilir. Örnekler: - 10.0.0.1 → Tek IP- 192.168.1.0/24 → 256 IP- 172.16.0.0/12 → 1.048.576 IP- 203.0.113.0/30 → 4 IP (.0-.3)- 10.3.10.* değeri ‘10.3.10.0’ ile ‘10.3.10.255’ arasındaki IP’leri belirtir.- 10.3.10.4-18 değeri ‘10.3.10.4’ ile ‘10.3.10.18’ arasındaki IP’leri ifade eder (4 ve 18 dahil).IP ekledikten sonra enter tuşuna basılmalıdır. |
| Adım 4: IP Grupları Kullanımı (İsteğe Bağlı) | - “Click to add IP Groups” butonuna tıklayın. - Sol tarafta mevcut IP grupları, sağda seçilenler görünür. Ekleme: - Sol listeden grup seçin → [Select]. - Sağ tarafa taşınır. - Bir grup birden fazla politikada kullanılabilir. Kaldırma: - Sağ listede 🗑️ simgesine tıklayın → sol listeye döner. Avantaj: - IP listelerini merkezi yönetin. - Tek güncelleme tüm politikalara yansır. - Partner erişimi için idealdir. |
| Adım 5: Coğrafi Konum Filtresi (İsteğe Bağlı) | - Country (Ülke) dropdown’ından ülke seçin (örnek: Turkey). - City (Şehir) dropdown’ı ülke seçilince aktif olur (örnek: Istanbul, Ankara, Izmir). - [+ Add] ile tabloya eklenir. - Satırlar 🗑️ ile tekil, üstteki 🗑️ ile toplu silinebilir. Örnek Senaryolar: - Yalnızca Türkiye: Country: Turkey, City: — - Türkiye büyük şehirler: Istanbul, Ankara, Izmir, Bursa - Birden fazla ülke: Turkey (tümü), Germany (Berlin, Munich), USA (tümü) |
| 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ımlanmazsa politika her zaman aktiftir. |
| 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": "Access denied: IP not whitelisted" }Özel: { "statusCode": 403, "errorCode": "ACCESS_DENIED", "message": "You do not have permission to access this API.", "details": "Your IP address is not on the allowed list. Please contact [email protected] for access." } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir IP veya grup 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 Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.Politikayı Dışa/İçe Aktarma
Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına 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 Adımlar |
|---|---|
| Variable ile Dinamik IP Yönetimi | - Öncelikle bir Variable oluşturun (Variables menüsünden). Variable tipi “String List” veya “JSON” olmalıdır. - Variable’ı external sistem ile besleyin (Database, Redis, API vb.). - Politika oluşturma/düzenleme sayfasında “Use Apinizer Default” toggle’ını kapatın. - “Variable” bölümünden ilgili variable’ı seçin. - Kaydedin. Artık her istek geldiğinde IP listesi variable’dan okunur. - Manuel güncelleme gerektirmez, gerçek zamanlı IP listesi yönetimi. |
| IP Grubu ile Merkezi Yönetim | - IP Group menüsünden yeni bir IP Grubu oluşturun (örn: “Partner IPs”). - IP grubuna IP’leri ekleyin (aynı mantık, IPv4 ve CIDR destekli). - Farklı IP Beyaz Listesi politikalarında bu grubu kullanın. - IP Grubunu güncelleyin (yeni IP ekle/çıkar). - Değişiklik otomatik olarak bu grubu kullanan tüm politikalara yansır. Avantaj: Bir IP setini birden fazla politikada kullanma, tek noktadan güncelleme. |
| Geolocation ile Ülke Bazlı Engelleme | Ön Gereksinim: Geolocation Settings’den Geolocation servisinin aktif edilmiş olması. - Politika sayfasında “Geolocation” bölümünde ülke dropdown’ını açın. - İstenen ülkeyi seçin (örn: Germany). - Şehir seçmeden [ Add ] butonuna tıklayın (tüm ülke için geçerli olur). - Birden fazla ülke ekleyebilirsiniz. Avantaj: IP bilgisine gerek kalmadan coğrafi lokasyon bazlı erişim kontrolü |
| Geolocation ile Şehir Bazlı Engelleme | - Ülke seçtikten sonra “City” dropdown’ı aktif olur. - Bir veya birden fazla şehir seçin (multi-select destekler). - [ Add ] butonuna tıklayın. - Eklenen şehirler tablo formatında görünür. Örnek: “Türkiye - İstanbul” ve “Türkiye - Ankara” seçilirse sadece bu iki şehirden istekler kabul edilir. Dikkat: Şehir verisinin doğruluğu Geolocation sağlayıcısına bağlıdır. |
| Condition ile Koşullu IP Kontrolü | - Politika düzenleme sayfasında “Condition” sekmesine geçin. - Query Builder’da koşul oluşturun (örn: path='/admin' OR header.X-Admin-Request='true').- Koşul sağlandığında IP kontrolü yapılır, sağlanmazsa politika atlanır. - Kaydedin. - Admin endpoint’lere özel IP kısıtlaması, public API’lere IP kontrolü yok. Avantaj: Aynı API Proxy’de farklı endpoint’ler için farklı politika davranışları. |
| Hata Mesajı Özelleştirme | - “Error Message Customization” sekmesine geçin. - Hata tipi seçin (örn: “IP Not Whitelisted”). - HTTP Status Code değiştirin (örn: 403 yerine 401). - Custom JSON mesajı girin: { "error": "Erişim Reddedildi", "message": "IP adresiniz beyaz listede değil", "code": "IP_NOT_ALLOWED" }- Dil bazlı mesajlar ekleyin (TR, EN). - Kaydedin. Avantaj: Kullanıcıya daha anlamlı hata mesajları, custom error tracking. |
| Export/Import ile Politika Taşıma | Export: - Politika listesinde ”…” menüsünden [ Export ] seçin. - ZIP dosyası indirilir (format: DD-MMM-YYYY-policy-[name]-export.zip).Import: - Liste sayfasında [ Import ] butonuna tıklayın. - Export edilmiş ZIP dosyasını seçin. - Import ayarlarını yapın (override, yeni ad vb.). - Import işlemini tamamlayın. Avantaj: Geliştirme → Test → Canlı ortam arasında politika taşıma, yedekleme. |
| Policy Group ile Toplu Yönetim | - “Policy Group” menüsünden yeni bir grup oluşturun. - IP Beyaz Listesi politikası dahil birden fazla politikayı gruba ekleyin. - Policy Group’u bir veya birden fazla API Proxy’ye atayın. - Grup içindeki tüm politikalar toplu olarak uygulanır. Avantaj: Birden fazla politikayı paket olarak yönetme, toplu deploy. |
İpuçları ve En İyi Uygulamalar
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| IP Formatı ve Tanımlama | Kötü: 192.168.1 (eksik format)İyi: 192.168.1.100 (tam IPv4 adresi)En İyi: 192.168.1.0/24 (CIDR ile IP aralığı, 254 adresi tek tanımla) |
| IP Grubu Kullanımı | Kötü: Her politikada aynı IP listesini manuel eklemek İyi: IP grubunu bir kez tanımlamak En İyi: İlgili IP’leri kategorize ederek gruplamak (örn: “Partner IPs”, “Office IPs”, “QA Team IPs”) |
| Global vs Local Politika Seçimi | Kötü: Her API Proxy için ayrı local IP Beyaz Listesi politikası oluşturmak İyi: Ortak güvenlik politikası olarak global politika kullanmak En İyi: Genel kurallar için global, özel durumlar için local politika kullanmak |
| Geolocation Kullanımı | Kötü: Tüm ülke IP bloklarını manuel eklemek İyi: Geolocation servisini aktif etmek En İyi: Ülke ve şehir kombinasyonlarını kullanarak hassas kontrol sağlamak |
| Variable ile Dinamik Yönetim | Kötü: Her IP değişikliğinde politikayı güncellemek İyi: Variable kullanarak harici sistemden IP listesi almak En İyi: Variable’ı Redis/Database’de cache’leyerek yüksek performans sağlamak |
| Hata Mesajı Özelleştirme | Kötü: Default 403 hatası kullanmak İyi: Custom JSON mesajı ile detaylı açıklama yapmak En İyi: Farklı hata senaryoları için farklı mesajlar, log ID eklemek |
| Politika Adlandırma | Kötü: policy1, ipwhite gibi belirsiz isimlerİyi: IP_White_List_Production gibi açıklayıcı isimlerEn İyi: [ENV]_[Purpose]_IP_White formatı (örn: PROD_Partner_API_IP_White) |
| Condition Kullanımı | Kötü: Tüm endpoint’lere aynı IP kısıtlaması uygulamak İyi: Public ve private endpoint’leri ayırmak En İyi: Condition ile /admin/* path’lerine özel IP kontrolü, /public/* path’lerine IP kontrolü yapmamak |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| En Az Yetki Prensibi (Least Privilege) | Kritik: IP Beyaz Listesine sadece gerçekten gerekli IP’leri ekleyin. Geniş CIDR blokları (örn: 0.0.0.0/0) kullanmaktan kesinlikle kaçının.Öneri: /32 (tek IP) veya en fazla /24 (256 IP) kullanın. |
| IP Spoofing ve Proxy Güvenliği | Uyarı: Eğer API Gateway önünde bir Load Balancer veya Reverse Proxy varsa, gerçek istemci IP’sini almak için X-Forwarded-For veya X-Real-IP header’larını doğru yapılandırın.Risk: IP spoofing ile beyaz listeyi bypass etme riski. |
| Geolocation Güvenilirliği | Not: Geolocation servisleri %100 doğru değildir. VPN ve Proxy kullanımı ile atlatılabilir. Öneri: Geolocation’ı tek başına değil, diğer güvenlik katmanları (JWT, API Key vb.) ile birlikte kullanın. |
| Variable Güvenliği | Güvenlik Riski: Variable içeriği harici sistemden geliyorsa, bu sistemin güvenliğini sağlayın. Öneri: Variable datasource’u için authentication, encryption ve access control uygulayın. |
| Hata Mesajı Bilgi Sızıntısı | Dikkat: Hata mesajlarında sistem mimarisi veya internal IP’ler hakkında bilgi vermeyin. Kötü: “Your IP 203.0.113.5 is not in whitelist. Allowed range: 192.168.1.0/24” İyi: “Access denied. Your IP address is not authorized.” |
| Düzenli Güncelleme ve Gözden Geçirme | Best Practice: IP Beyaz Listesini düzenli olarak gözden geçirin (örn: aylık). Aksiyon: Kullanılmayan, eski partner IP’lerini kaldırın. Değişen IP’leri güncelleyin. Audit log’larını kontrol edin. |
| Multi-Factor Security | Öneri: IP Beyaz Listesini tek güvenlik katmanı olarak kullanmayın. Best Practice: IP kontrolü + API Key/JWT + Rate Limiting kombinasyonu kullanın. |
| Production Ortam İzolasyonu | Kritik: Production ortamı için ayrı global politika oluşturun. Test/Development ortamlarının IP’lerini production politikasına asla eklemeyin. Öneri: Ortam bazlı Policy Group kullanın. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Geniş CIDR Blokları Kullanma | Neden kaçınılmalı: 10.0.0.0/8 gibi geniş bloklar milyonlarca IP’yi kapsayabilir ve güvenlik riskini artırır.Alternatif: Spesifik subnet’ler kullanın (örn: 10.10.50.0/24). İhtiyaç duyulan IP’leri teker teker veya küçük CIDR bloklarla ekleyin. |
| Variable Kullanırken Fallback Tanımlamama | Neden kaçınılmalı: Variable servisi down olursa veya boş dönerse tüm istekler engellenebilir. Alternatif: Variable + Manuel IP listesini birlikte kullanın. Variable okunamazsa manuel listeye fallback yapılandırması ekleyin. Monitoring ve alerting kurun. |
| Politikayı Pasif Durumda Bırakma | Neden kaçınılmalı: Pasif politika trafiğe uygulanmaz, unutulması durumunda güvenlik açığı oluşabilir. Alternatif: Geçici olarak test etmek için kısa süreliğine pasif yapın. Test tamamlandıktan sonra aktif edin veya silin. |
| Hata Mesajında IP Bilgisi Vermek | Neden kaçınılmalı: Hata mesajında istemcinin veya izin verilen IP’lerin gösterilmesi saldırganlara bilgi verir. Alternatif: Genel hata mesajları kullanın: “Access denied” veya “Unauthorized”. Detaylı logları sadece sunucu tarafında tutun. |
| Local Politika ile Yönetimi Karmaşıklaştırma | Neden kaçınılmalı: Her API Proxy için ayrı local IP Beyaz Listesi politikası oluşturmak, yönetimi zorlaştırır ve IP güncellemelerinde tutarsızlık yaratır. Alternatif: Global politika kullanın. Sadece gerçekten farklı IP gereksinimlerine sahip API Proxy’ler için local politika oluşturun. |
| Geolocation’a Aşırı Güvenmek | Neden kaçınılmalı: VPN, Tor, Proxy kullanımı ile coğrafi konum atlatılabilir. Hassas işlemler için yeterli değildir. Alternatif: Geolocation’ı ek güvenlik katmanı olarak kullanın. Kritik işlemler için IP + Authentication + MFA kombinasyonu uygulayın. |
| Politika Güncellemelerini Deploy Etmemek | Neden kaçınılmalı: Global politikada yapılan değişiklikler deploy edilmeden canlı ortama yansımaz. Alternatif: Politika güncellendikten sonra Deploy butonunu kullanın. Deploy işlemini CI/CD pipeline’a entegre edin. |
| Test Etmeden Production’a Geçiş | Neden kaçınılmalı: Yanlış IP yapılandırması tüm kullanıcıların engellenmesine neden olabilir. Alternatif: Test ortamında politikayı doğrulayın. Önce passive modda deploy edin, logları kontrol edin. Sonra aktif edin. Rollback planı hazırlayın. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| IP Grubu Boyutu | Öneri: IP gruplarını maksimum 100-200 IP ile sınırlayın. Daha fazla IP gerekiyorsa birden fazla grup oluşturun. Etki: Her istekte tüm IP listesi kontrol edilir. Çok büyük listeler performansı düşürür (her IP için O(n) karşılaştırma). |
| CIDR Bloklarını Tercih Etme | Öneri: Mümkün olduğunca IP aralıkları için CIDR notasyonu kullanın. Performans Farkı: 192.168.1.1, 192.168.1.2, ..., 192.168.1.254 (254 entry) yerine 192.168.1.0/24 (1 entry) kullanmak 100x daha hızlıdır. |
| Variable Cache Stratejisi | Öneri: Variable datasource’unda cache mekanizması kullanın (Redis, Memcached). Etki: Her istekte database query yerine cache’den okuma milisaniyelik gecikmeyi mikrosaniyeye düşürür. TTL 5-10 dakika olabilir. |
| Geolocation Performansı | Not: Geolocation lookup her istekte gerçekleşir ve ek gecikme yaratır (ortalama 1-5ms). Öneri: Yüksek trafikli API’lerde geolocation yerine sabit IP listesi kullanmayı tercih edin. Geolocation sonuçlarını cache’leyin (IP → Country/City mapping). |
| Condition Karmaşıklığı | Öneri: Basit ve optimize edilmiş koşullar yazın. Gereksiz karmaşık regex veya nested condition’lardan kaçının. Etki: Basit koşul ( path='/' AND method='GET') < 0.1ms. Karmaşık regex koşul > 1-2ms. |
| Politika Sıralaması | Best Practice: Policy Group içinde IP Beyaz Listesi politikasını önce çalıştırın. Mantık: Yetkisiz IP’lerden gelen istekler erken aşamada engellenirse, diğer politikalar (Rate Limiting, JWT vb.) gereksiz yere çalışmaz. |
| Log Seviyesi Ayarı | Production: Log seviyesini ERROR veya WARN’da tutun. Development: DEBUG veya TRACE kullanabilirsiniz. Etki: Aşırı logging (her istekte IP kontrolü loglanması) disk I/O ve performans sorununa yol açabilir. |
| Aktif Olmayan Politikaları Silme | Öneri: Kullanılmayan veya pasif durumdaki politikaları düzenli olarak silin. Etki: Veritabanı ve in-memory policy registry’nin küçük kalması, politika lookup süresini azaltır. |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | IP Beyaz Listesi politikası kaç tane IP destekler? | Teknik olarak sınır yoktur ancak performans için 500-1000 IP önerilir. Daha fazla IP için IP grupları ve CIDR blokları kullanın. Çok büyük listeler için Variable ile external cache (Hazelcast) kullanımı önerilir. |
| Genel | IPv6 adresleri destekleniyor mu? | Mevcut implementasyonda IPv4 ve CIDR blokları desteklenmektedir. IPv6 desteği için ürün yol haritasında yer almaktadır. Geçici çözüm olarak IPv6 trafiği için reverse proxy seviyesinde yönlendirme yapabilirsiniz. |
| Genel | Politikayı pasif yapsam bile API Proxy deploy edilmeli mi? | Evet. Global politikalarda yapılan her değişiklik (aktif/pasif dahil) deploy edilmelidir. Local politikalarda API Proxy’nin kendisi deploy edilmelidir. |
| Teknik | X-Forwarded-For header’ından IP nasıl alınır? | API Gateway otomatik olarak X-Forwarded-For, X-Real-IP header’larını kontrol eder. Gateway ayarlarından “Use Forwarded IP” seçeneğini aktif etmelisiniz. Header yoksa direkt socket IP’si kullanılır. |
| Teknik | Variable ile IP listesi nasıl formatlanmalı? | Variable tipi “String List” ise:["192.168.1.1", "192.168.1.2", "10.0.0.0/8"]Variable tipi “JSON” ise: {"ipList": ["192.168.1.1", "192.168.1.2"], "allowAll": false}Variable her istek geldiğinde okunur veya cache’den alınır. |
| Teknik | CIDR bloğu nasıl hesaplanır? | CIDR notasyonu: IP_ADDRESS/PREFIX_LENGTHÖrnekler: - 192.168.1.0/32 = Tek IP (192.168.1.0)- 192.168.1.0/24 = 256 IP (192.168.1.0 - 192.168.1.255)- 10.0.0.0/8 = 16,777,216 IP (10.0.0.0 - 10.255.255.255)Online CIDR hesaplayıcıları kullanabilirsiniz. |
| Teknik | Politika uygulandığında hangi HTTP header’lar eklenir? | Politika başarılı olduğunda herhangi bir header eklenmez. Başarısız olduğunda (IP reddedildi) custom hata mesajı döner. Debugging için X-Apinizer-Policy-Status: REJECTED gibi custom header’lar ekleyebilirsiniz. |
| Kullanım | Hem IP listesi hem de Geolocation kullanırsam mantık AND mi OR mu? | OR mantığı çalışır. Yani istemci IP’si şu kaynaklardan herhangi birine uyuyorsa kabul edilir: - Manuel IP listesi - IP Gruplarındaki IP’ler - Geolocation ülke/şehir kuralları - Variable’dan gelen IP’ler Hiçbirine uymuyorsa reddedilir. |
| Kullanım | Global politikayı güncelledim ama API’de yansımadı, neden? | Global politika değişiklikleri deploy edilmelidir. İşlem adımları: - Politikayı kaydedin. - Politika detay sayfasındaki “Deploy” butonuna tıklayın. - Deploy edilecek ortamları (DEV, TEST, PROD) seçin. - Deploy işlemini onaylayın. - Deploy sonrası 1-2 dakika içinde değişiklikler canlıya yansır. |
| Kullanım | IP Grubunu silersem politika ne olur? | Dikkat: IP Grubu silinirse, bu grubu kullanan politikalar geçersiz hale gelir (⚠️ validation warning gösterilir). Politika ipGroupIdList’inde silinen grup ID’si kalır ancak IP’ler eşleşmez. Öneri: IP Grubu silmeden önce hangi politikalarda kullanıldığını kontrol edin. Gerekirse politikaları önce güncelleyin. |
| Kullanım | Geolocation servisi nasıl aktifleştirilir? | - Admin menüsünden “Geolocation Settings” sayfasına gidin. - Geolocation sağlayıcısını seçin (örn: MaxMind GeoIP2). - API Key veya lisans bilgilerini girin. - “Test Connection” ile bağlantıyı test edin. - “Enable Geolocation” toggle’ını açın ve kaydedin. - Geolocation database’i düzenli güncellenmelidir (aylık). |
| Kullanım | Bir API Proxy’de hem global hem local IP Beyaz Listesi politikası kullanabilir miyim? | Teknik olarak evet, ancak önerilmez. İki politika da aktif ise AND mantığı çalışır (her iki listeye de uyması gerekir). Karmaşık yönetim ve beklenmeyen bloklamalara yol açabilir. Best Practice: Global politika kullanın. Spesifik durum varsa global politikayı localize edin ve özelleştirin. |
| Hata Giderme | ”Invalid IP address format” hatası alıyorum, neden? | IP adresi formatı hatalıdır. Geçerli formatlar: ✅ 192.168.1.100 (IPv4)✅ 10.0.0.0/8 (CIDR)❌ 192.168.1 (eksik oktet)❌ 192.168.1.300 (300 > 255, geçersiz)❌ 192.168.1.0/33 (CIDR prefix 0-32 arasında olmalı)IP’nizi bu formatlara göre düzenleyin. |
| Hata Giderme | Whitelist’e eklediğim IP hala 403 alıyor, ne yapmalıyım? | Troubleshooting adımları: - Politika aktif mi kontrol edin (active=true). - Global politika ise deploy edilmiş mi kontrol edin. - API Gateway loglarında istemcinin gerçek IP’sini görün (Load Balancer arkasındaysa X-Forwarded-For). - Condition tanımlı mı? Koşul sağlanıyor mu kontrol edin. - IP doğru formatta mı? CIDR bloğu doğru hesaplanmış mı? - Variable kullanılıyorsa variable içeriğini kontrol edin. - Cache temizliği yapın (politika cache’i reload). Hala sorun varsa destek ekibine log dosyalarını iletin. |
| Hata Giderme | Geolocation kontrolü çalışmıyor, ne yapmalıyım? | Kontrol listesi: - Geolocation Settings’de servis aktif mi? - Geolocation database güncel mi? (Son güncelleme tarihini kontrol edin) - İstemci IP’si public IP mi? (Private IP’ler için geolocation çalışmaz: 192.168.x.x, 10.x.x.x) - VPN veya Proxy kullanılıyor olabilir (gerçek lokasyonu gizler). - API Gateway loglarında geolocation lookup sonucunu kontrol edin (hangi ülke/şehir tespit edilmiş). - Geolocation sağlayıcısının API limit’ine ulaşılmış olabilir. |