Genel Bakış
HTTP Basic Authentication standardını kullanarak API isteklerini güvenli bir şekilde doğrulamak. İsteklerde gönderilen kullanıcı adı ve şifre bilgilerini base64 ile decode ederek kimlik kontrolü yapmak.Amacı Nedir?
- HTTP Basic Authentication standardını kullanarak API isteklerini güvenli bir şekilde doğrulamak. İsteklerde gönderilen kullanıcı adı ve şifre bilgilerini base64 ile decode ederek kimlik kontrolü yapmak.
- Secret Manager, LDAP, veritabanı veya harici API entegrasyonları ile merkezi kimlik doğrulama altyapısına bağlanmak. Kullanıcı bilgilerini güvenli şekilde Identity/Role Group servisleri üzerinden doğrulamak.
- Kullanıcının rollerini ve yetkilerini kontrol ederek endpoint bazında veya method bazında erişim kontrolü sağlamak. Authorization yapılandırması ile sadece yetkili kullanıcıların belirli API’lere erişmesini garanti etmek.
- Kimlik doğrulaması yapılan kullanıcı bilgilerini (username, user ID vb.) backend servislerine özel header ile iletmek. Backend’in kullanıcı bağlamında işlem yapmasını sağlamak.
- IP adresi kontrolü, clear auth ve error message özelleştirme gibi gelişmiş güvenlik katmanları ekleyerek çok katmanlı güvenlik sağlamak.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin
Authorizationheader’ı kontrol edilir veBasicprefix ile base64 encoded credentials (kullanıcı adı:şifre) aranır. - Politika Kontrolü: Base64 Authentication 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ı?
- Kimlik Doğrulama Kontrolü: Authorization header’ı decode edilir ve username/password çıkarılır. Identity Role Group servisi (Secret Manager, LDAP, Database veya API) ile kimlik bilgileri doğrulanır. Eğer
checkClientIpAddressaktifse, istemci IP adresi de kontrol edilir. - Karar Verme:
- Doğrulama Başarılı: Kullanıcı doğrulanırsa, opsiyonel olarak authorization (rol kontrolü) yapılır.
addUserToHeaderaktifse kullanıcı bilgisi backend’e özel header ile iletilir.clearAuthaktifse, Authorization header backend’e gönderilmez. - Doğrulama Başarısız: Kullanıcı kimlik bilgileri geçersizse veya yetkisi yoksa HTTP 401/403 hatası döndürülür.
- Doğrulama Başarılı: Kullanıcı doğrulanırsa, opsiyonel olarak authorization (rol kontrolü) yapılır.
- 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
- HTTP Basic Authentication Desteği: RFC 7617 standardına uygun base64 encoded username:password formatında kimlik doğrulama. Authorization header’ından otomatik decode ve credential extraction.
- Identity/Role Group Entegrasyonu: Secret Manager, LDAP, Database veya harici API servisleri ile merkezi kimlik yönetimi. Kullanıcı bilgilerini güvenli şekilde doğrulama ve rol bilgilerini alma.
- Username Variable Desteği: Doğrulanan kullanıcı adını Apinizer değişkenlerine yazma. Policy chain boyunca kullanıcı bilgisine erişim ve backend’e aktarım imkanı.
- 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
- Authorization (Yetkilendirme) Yapılandırması: Method bazlı erişim kontrolü (GET, POST, PUT, DELETE vb.). Rol bazlı yetkilendirme ve credential role listesi tanımlama. Rolleri backend’e header olarak iletme (addRolesToHeader).
- IP Adresi Kontrolü: Secret Manager modunda kullanıcı kimlik bilgilerine ek olarak istemci IP adresi doğrulaması. Çift faktörlü güvenlik katmanı.
- Clear Auth ve Header Manipülasyonu: Authorization header’ını backend’e göndermeme (clearAuth). Doğrulanmış kullanıcı bilgisini özel header ile backend’e iletme (addUserToHeader). Header adını özelleştirme (userHeaderName).
- 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 Kimlik Doğrulama | Şirket içi API’ler için LDAP tabanlı kimlik doğrulama gerekli. Tüm kullanıcılar Active Directory’de tanımlı. | Identity Role Group olarak LDAP servisi seçilir. Username variable tanımlanır. Politika tüm API’lere atanır. | Her istekte Authorization header’ı kontrol edilir. LDAP’tan kullanıcı doğrulanır. Başarılı ise backend’e istek iletilir. |
| Mikroservis Kimlik Aktarımı | Backend mikroservisler kullanıcı bilgisine ihtiyaç duyuyor ancak şifre bilgisi gönderilmemeli. | addUserToHeader=true ve clearAuth=true ayarlanır. Header adı X-Authenticated-User olarak belirlenir. | Gateway kimlik doğrulaması yapar, Authorization header’ı backend’e göndermez. Sadece kullanıcı adını X-Authenticated-User header’ı ile iletir. |
| Rol Bazlı Erişim Kontrolü | Admin kullanıcıları tüm method’lara erişebilsin, normal kullanıcılar sadece GET ve POST yapabilsin. | Authorization yapılandırması aktif edilir. Method Access tanımlanır: Admin rolü: ALL, User rolü: GET, POST. | Her istekte kullanıcının rolü kontrol edilir. Admin DELETE yapabilir ancak User rolü 403 hatası alır. |
| IP Kısıtlamalı Doğrulama | Secret Manager’da tanımlı kullanıcılar sadece belirli IP’lerden erişebilmeli. | Secret Manager Identity seçilir. checkClientIpAddress=true ayarlanır. Secret Manager’da credential tanımlarken IP listesi girilir. | İstek geldiğinde hem kullanıcı adı/şifre hem de IP adresi kontrol edilir. IP uyuşmazsa 401 hatası döner. |
| Test ve Production Ayrımı | Test ortamında kimlik doğrulama yapılmasın, production’da yapılsın. | Condition tanımlanır: Header = X-Environment, Equals, production. Politika aktif olarak atanır. | Test ortamında X-Environment header’ı olmadığı için politika atlanır. Production’da header varsa kimlik doğrulama yapılır. |
| External API Kimlik Doğrulama | Kullanıcı bilgileri harici bir REST API’de tutuluyor. | Identity Role Group olarak API servisi seçilir. API endpoint ve parametreleri yapılandırılır. | Her istekte API Gateway harici API’ye kullanıcı bilgilerini gönderir. API’den dönen response’a göre doğrulama yapılır. |
| Çoklu Kimlik Kaynağı | Bazı kullanıcılar LDAP’ta, bazıları Database’de tanımlı. | İki ayrı Base64 Authentication politikası oluşturulur. Condition ile ayrılır: LDAP kullanıcıları için Header = X-Auth-Source, Equals, LDAP. | İsteğe göre uygun kimlik kaynağı seçilir. LDAP veya Database’den doğrulama yapı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. 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 Base64 Authentication 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 → Base64 Authentication 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_Basic_Auth- 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: “Production ortamı için LDAP tabanlı kimlik doğrulama” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Identity Role Group Seçimi (Zorunlu) | - Identity Role Group alanında [Click to Select] butonuna tıklayın. - Açılan dialogda kimlik kaynağını seçin: Secret Manager: Apinizer’da tanımlı kullanıcı/şifre/IP listeleri LDAP: Active Directory veya OpenLDAP entegrasyonu Database: Kullanıcı bilgilerini veritabanından sorgulama API: Harici REST API ile kimlik doğrulama - Seçim yaptıktan sonra [Select] butonuna tıklayın. - Yanlış seçim yaparsanız [X] butonu ile temizleyebilirsiniz. |
| Adım 4: Username Variable Tanımlama (Zorunlu) | - Variable for Authorization alanında değişken seçimi yapın. - İki seçenek mevcuttur: 1. Mevcut Variable Seçme: [Select Different] butonuna tıklayın. Variable listesinden username bilgisinin yazılacağı değişkeni seçin. 2. Variable Güncelleme: Seçili variable’ın [Update Variable] butonuna tıklayarak özelliklerini düzenleyebilirsiniz. - Doğrulanan kullanıcı adı bu variable’a yazılır. - Policy chain’de sonraki politikalar veya backend bu değişkeni kullanabilir. |
| Adım 5: Opsiyonel Güvenlik Ayarları | Check Client IP Address (sadece Secret Manager): - Checkbox aktif edilirse, Secret Manager’da tanımlı IP listesi ile istemci IP’si karşılaştırılır. - IP uyuşmazsa 401 hatası döner. Clear Auth: - Checkbox aktif edilirse, Authorization header backend’e iletilmez. - Mikroservis mimarilerinde backend’in şifre bilgisine erişmesini engellemek için kullanılır. Add User to Header: - Toggle aktif edilirse, doğrulanan kullanıcı bilgisi özel header ile backend’e iletilir. - User Header Name alanı açılır (varsayılan: X-Authenticated-UserId).- Backend bu header’ı okuyarak kullanıcı bağlamında işlem yapabilir. |
| 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": 401, "message": "Unauthorized: Invalid credentials" }Özel: { "statusCode": 401, "errorCode": "AUTH_FAILED", "message": "Kimlik doğrulama başarısız. Kullanıcı adı veya şifre hatalı." } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: - Benzersiz isim - Zorunlu alanlar dolu - En az bir Identity Role Group seçili 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 |
|---|---|
| Authorization (Yetkilendirme) Yapılandırması | - Politika düzenleme sayfasında Enable Authorization toggle’ını aktif edin. - Authorization Type seçin (API, Database, LDAP veya Secret Manager). - Enable Method Access aktif edilirse, method bazlı yetkilendirme yapılır. Her HTTP method (GET, POST, PUT, DELETE vb.) için izinli roller tanımlanır. - Add Roles to Header aktif edilirse, kullanıcının rolleri backend’e header olarak iletilir. |
| Çoklu Kimlik Kaynağı Desteği | - Farklı kimlik kaynakları için ayrı politikalar oluşturun (örn: LDAP_Auth, Database_Auth). - Her politikaya Condition tanımlayın: Header = X-Auth-Type, Equals, LDAP veya Header = X-Auth-Type, Equals, DB.- Aynı API’ye her iki politikayı da ekleyin. Gateway isteğe göre uygun politikayı çalıştırır. |
| Cascading Authentication (Zincirleme Doğrulama) | - İlk politika (Base64 Authentication) ile kimlik doğrulama yapın. - İkinci politika (örn: IP Whitelist) ile ek güvenlik kontrolü ekleyin. - Politika sıralamasını doğru yapın. Kimlik doğrulama önce, diğer kontroller sonra gelmelidir. |
İpuçları ve En İyi Uygulamalar
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| Kimlik Kaynağı Seçimi | Kötü: Her API için ayrı Secret Manager credential tanımlamak. İyi: Secret Manager’da grup credential tanımları kullanmak. En İyi: Merkezi LDAP veya Identity Provider (IdP) entegrasyonu kullanmak. - Tüm kullanıcılar tek noktadan yönetilir, şifre değişiklikleri otomatik yansır. |
| Variable Kullanımı | Kötü: Username variable tanımlamamak ve backend’in kullanıcı bilgisine erişememesi. İyi: Username variable tanımlayıp addUserToHeader ile backend’e göndermek. En İyi: Username variable + User ID variable + Roles variable tanımlayıp tüm kullanıcı bağlamını backend’e aktarmak. - Policy chain’de sonraki politikalar da bu bilgiyi kullanabilir. |
| Clear Auth Kullanımı | Kötü: Authorization header’ını backend mikroservislere göndermek. Şifre bilgisi gereksiz yere iletilir. İyi: clearAuth=true ayarlayıp Authorization header’ını temizlemek.En İyi: clearAuth=true + addUserToHeader=true kombinasyonu.- Backend şifre görmez, sadece doğrulanmış kullanıcı bilgisini alır. |
| Condition Kullanımı | Kötü: Tüm API’lere aynı politikayı condition olmadan atamak. İyi: Production ve test ortamlarını condition ile ayırmak. En İyi: Path, method, header ve query parameter kombinasyonları ile granüler kontrol. - Örn: Admin endpoint’leri için ayrı condition, public endpoint’ler için ayrı condition. |
| Error Message Customization | Kötü: Varsayılan hata mesajlarını kullanmak. Kullanıcı neyin yanlış gittiğini anlamaz. İyi: Türkçe hata mesajları tanımlamak: “Kimlik doğrulama başarısız”. En İyi: Detaylı hata kodları ve yönlendirme bilgileri: { "errorCode": "AUTH_001", "message": "Kullanıcı adı veya şifre hatalı", "supportUrl": "https://support.example.com/auth" } |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| HTTPS Zorunluluğu | Kritik: Base64 Authentication sadece HTTPS üzerinden kullanılmalıdır. HTTP’de base64 encoding kolayca decode edilebilir ve credentials açığa çıkar. Gateway’de HTTPS enforcement aktif olmalı, HTTP istekleri otomatik olarak HTTPS’e yönlendirilmeli veya reddedilmelidir. |
| IP Kısıtlaması (Defense in Depth) | Öneri: Secret Manager kullanılıyorsa checkClientIpAddress=true ayarlayın. Hem credential hem de IP kontrolü yapılır. Saldırganlar credentials çalsa bile farklı IP’den erişemez. Çok katmanlı güvenlik (defense in depth) prensibi uygulanmış olur. |
| Credential Rotation | Uyarı: Secret Manager’da tanımlı kullanıcı şifrelerini düzenli olarak değiştirin (30-90 gün). LDAP/Database kullanılıyorsa şifre expiration policy aktif olmalıdır. Eski şifreler revoke edilmeli, yeni şifreler güçlü olmalıdır (min 12 karakter, karmaşık). |
| Brute Force Koruması | Öneri: Rate Limiting politikası ile aynı IP’den gelen başarısız authentication denemelerini sınırlayın. Örnek: 5 başarısız denemeden sonra 15 dakika IP block. Log’larda başarısız authentication denemelerini izleyin, anomali tespiti yapın. |
| Authorization Kontrolü | Kritik: Sadece kimlik doğrulama yeterli değildir, yetkilendirme de yapılmalıdır. enableAuthorization=true ayarlayın ve method bazlı rol kontrolü ekleyin. Aksi halde doğrulanmış her kullanıcı tüm endpoint’lere erişebilir (privilege escalation riski). |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| HTTP Üzerinden Basic Auth | Neden kaçınılmalı: HTTP trafiği şifrelenmez. Base64 encoding sadece encoding’dir, şifreleme değildir. Network sniffing ile credentials kolayca çalınabilir. Alternatif: Sadece HTTPS üzerinden Basic Auth kullanın. Gateway’de HTTP isteklerini reddedin veya HTTPS’e yönlendirin. |
| Authorization Header’ını Backend’e İletme | Neden kaçınılmalı: Backend mikroservislerin şifre bilgisine ihtiyacı yoktur. Şifre bilgisi backend log’larına yazılabilir veya 3. parti entegrasyonlarda açığa çıkabilir. Alternatif: clearAuth=true + addUserToHeader=true kullanın. Backend sadece doğrulanmış kullanıcı bilgisini alır. |
| Global Politikada Dikkatli Olmama | Neden kaçınılmalı: Global politika değişiklikleri tüm API’leri etkiler. Yanlış yapılandırma tüm servislerin erişilemez hale gelmesine neden olabilir. Alternatif: Global politika değişikliklerini test ortamında deneyin. Production’a deploy etmeden önce “Used Proxies” kontrolü yapın. |
| Username Variable Tanımlamamak | Neden kaçınılmalı: Backend kullanıcı bilgisine erişemez. Audit log, user tracking ve personalization özellikleri çalışmaz. Alternatif: Mutlaka username variable tanımlayın ve backend’e header ile iletin. User context tüm mikroservisler arasında tutarlı olmalı. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| Identity Service Cache | Öneri: LDAP veya Database kimlik doğrulaması kullanılıyorsa, Gateway’de credential caching aktif edilmelidir. Her istekte harici servis çağrısı performans kaybına neden olur. Etki: Cache süresi 5-15 dakika arası olabilir. Cache hit rate %80+ ise response time 50-100ms azalır. |
| Connection Pooling | Öneri: LDAP veya Database bağlantılarında connection pool kullanın. Her istekte yeni connection açmak overhead yaratır. Etki: Connection pool size 10-50 arası ayarlanabilir. Connection reuse ile 20-30ms kazanç sağlanır. |
| Condition Değerlendirme Sırası | Öneri: Condition kurallarını basit → karmaşık sırasına göre yazın. Hızlı sonuç veren condition’ları önce değerlendirin (örn: header check → regex check). Etki: Condition evaluation time %30-40 azalır. |
| Authorization Cache | Öneri: Rol bazlı yetkilendirme kullanılıyorsa, kullanıcı rollerini cache’leyin. Her istekte rol sorgulama yapmak gereksizdir. Etki: Cache TTL 10-30 dakika. Cache kullanımı ile authorization overhead %60-70 azalır. |
| Lightweight Identity Service | Öneri: Mümkünse Secret Manager kullanın. LDAP veya Database’e göre 3-5x daha hızlıdır çünkü local memory’de çalışır. Etki: Secret Manager response time 5ms’den az. LDAP/Database response time 20-50ms arası. Kritik performans gereksinimleri için Secret Manager tercih edilmelidir. |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | Base64 Authentication ile JWT Authentication arasındaki fark nedir? | Base64 Authentication her istekte kullanıcı adı ve şifre gönderilir, Gateway Identity Service’i sorgular. JWT Authentication’da ise token tabanlı çalışır, kullanıcı bir kez login olur ve sonraki isteklerde token gönderir. JWT stateless’tır ve daha performanslıdır. Base64 Auth daha basittir ancak her istekte kimlik doğrulama overhead’i vardır. |
| Genel | Base64 Authentication güvenli midir? | HTTPS üzerinden kullanıldığında güvenlidir. HTTP’de kesinlikle kullanılmamalıdır çünkü base64 sadece encoding’dir, şifreleme değildir. HTTPS trafiği TLS ile şifrelenir, credentials güvende kalır. Ek güvenlik için IP restriction ve rate limiting eklenmelidir. |
| Teknik | X-Forwarded-For header’ından IP nasıl alınır? | Kurumsal ortamlarda LDAP (Active Directory) tercih edilir çünkü merkezi kullanıcı yönetimi sağlar. Küçük ölçekli projelerde Secret Manager yeterlidir. External kullanıcılar için 3. parti Identity Provider (IdP) API entegrasyonu kullanılabilir. Database option legacy sistemler için uygundur. |
| Teknik | Identity Role Group olarak hangi servis seçilmeli? | Kurumsal ortamlarda LDAP (Active Directory) tercih edilir çünkü merkezi kullanıcı yönetimi sağlar. Küçük ölçekli projelerde Secret Manager yeterlidir. External kullanıcılar için 3. parti Identity Provider (IdP) API entegrasyonu kullanılabilir. Database option legacy sistemler için uygundur. |
| Teknik | checkClientIpAddress ne zaman kullanılmalı? | Yüksek güvenlik gerektiren senaryolarda (örn: admin paneli, finansal işlemler) kullanılmalıdır. Kullanıcının IP adresi sabitlenebiliyorsa (örn: ofis IP) etkilidir. Mobil kullanıcılar veya dinamik IP’li senaryolarda kullanışlı değildir çünkü IP sık değişir. |
| Kullanım | clearAuth ne zaman kullanılmalı? | Mikroservis mimarisinde backend’in şifre bilgisine ihtiyacı yoksa mutlaka kullanılmalıdır. Gateway kimlik doğrulama yapar, backend sadece doğrulanmış kullanıcı bilgisini alır. Security best practice olarak backend’e credentials gönderilmemelidir (least privilege principle). |
| Kullanım | Global politika mı Local politika mı kullanmalıyım? | Çoğu API aynı kimlik doğrulama kuralını kullanıyorsa Global politika kullanın. Merkezi yönetim ve tutarlılık sağlar. Sadece 1-2 API’de farklı kural gerekiyorsa Local politika oluşturun. Local politika test ve geliştirme aşamasında daha esnektir. |