İzin Verilen IP Listesi

Sadece belirlenen IP adreslerinden, IP gruplarından veya coğrafi konumlardan gelen istekleri kabul edebilir, diğer tüm istekleri engelleyebilirsiniz

Bu doküman spesifik bir politikanın detaylı kullanımını anlatır. Eğer Apinizer politika yapısını ilk kez kullanıyorsanız veya politikaların genel çalışma prensiplerini öğrenmek istiyorsanız, öncelikle Politika Nedir? sayfasını okumanızı öneririz.

​

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

1. İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemcinin kaynak IP adresi tespit edilir.
2. 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?
3. 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)
4. 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).
5. 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: Variable Kullanımı	- Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilirsiniz. - Context/global variable ifadeleri sayesinde politika parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz. - Bu kullanım, değişen değerlerde manuel güncelleme ihtiyacını azaltır ve operasyonel kolaylık sağlar. - Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz.
Adım 4: IP Listesi Yapılandırması	Use Apinizer Default: ☑️ Açıkken platformun varsayılan istemci IP algılama mekanizmasını kullanırsınız. 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 5: 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 6: 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 7: 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 8: 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 [e-mail] for access." }
Adım 9: 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.

Koşullar ve Hata Mesajı Özelleştirme panellerinin açıklaması için Politika Nedir? sayfasındaki Koşullar ve Hata Mesajı Özelleştirme (Error Message Customization) bölümlerini inceleyebilirsiniz.

Hata mesajı yapılandırmasının tüm katmanları, öncelik sırası ve senaryo örnekleri için Hata Mesajı Yapılandırma Rehberi sayfasına bakın.

​

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ı isimler En İ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.

Bu doküman Apinizer ürün dokümantasyonunun bir parçasıdır. © 2025 Apinizer - Tüm hakları saklıdır.