Harici Yetkilendirme Yönetim Sistemleri: Mimarınız İçin Doğru Platformu Seçmek

Özet#

Özel yetkilendirme sistemleri geliştirmek birçok uygulama için işe yarıyor. Ancak dağıtık sistemler giderek daha fazla, politika değerlendirme, ilişki yönetimi ve ayrıntılı erişim kontrolünü bir servis olarak sunan özel yetkilendirme altyapılarından fayda görüyor. Bu yazı mevcut platform haritasını çıkarıyor, mimari yaklaşımları karşılaştırıyor ve AWS Verified Permissions, SpiceDB, OpenFGA, Cerbos, OPA ve diğer platformlar arasında seçim yapmak için bir karar çerçevesi sunuyor. Bu yazı, belirli platformlara ve politika dillerine daha derinlemesine dalan bir serinin ilk yazısıdır.

Not: Bu yazı, TypeScript ve CASL ile dahili yetkilendirme geliştirmeyi ele alan Ölçeklenebilir İzin Sistemleri serisi ile birbirini tamamlayıcı niteliktedir. Burada "ne zaman geliştirmeyi bırakıp harici bir yetkilendirme sistemini entegre etmelisiniz?" sorusunu ele alıyoruz.

Yetkilendirme Ortamı#

Harici yetkilendirme alanı önemli ölçüde değişti. Bu değişimleri anlamak, platform seçiminin neden her zamankinden daha önemli olduğunu çerçevelemeye yardımcı oluyor.

Önemli Sektörel Değişimler#

OPA/Styra kesintisi: Apple, Styra'nın kurucu ortaklarını ve çekirdek ekibini satın aldı. Styra DAS (ticari OPA yönetim platformu) kurumsal ticari destek sona ererken topluluk tarafından sürdürülen açık kaynağa geçiş yapıyor. OPA, CNCF yönetimi altında kalmaya devam ediyor ancak kurumsal kullanıcılar belirsiz ticari destekle karşı karşıya. Birçoğu Cerbos, Cedar ve Permit.io gibi alternatifleri değerlendiriyor.

ReBAC yaygın benimsenmesi: Google Zanzibar'dan esinlenen sistemler (SpiceDB, OpenFGA, Permify) akademik bir ilgi alanından üretim altyapısına dönüştü. OpenAI, ChatGPT Enterprise bağlayıcıları için SpiceDB kullanıyor ve on milyarlarca ayrıntılı izni yönetiyor.

Politika dili parçalanması: Cedar (AWS), Rego (OPA/CNCF), Polar (Oso), OpenFGA DSL ve Cerbos YAML/CEL, politika dillerinde bir çeşitlilik patlamasını temsil ediyor. Sektör henüz bir standarda yakınsamadı, ancak Cedar ve OpenFGA DSL ivme kazanıyor.

İnsan dışı kimlik patlaması: Yapay zeka ajanları, servis hesapları ve makine kimlikleri birçok kurumda insan kullanıcılarını önemli ölçüde aşıyor. Yetkilendirme sistemleri, ajan-ajan delegasyonunu ve sürekli politika uygulamasını desteklemeli -- çoğu eski sistemin tasarlanmadığı gereksinimler.

AWS Verified Permissions fiyat indirimi: AWS, tek yetkilendirme API'leri (IsAuthorized, IsAuthorizedWithToken) için fiyatları yayındaki ABD tarifesinde milyon başına 5 dolara kadar %97'ye varan oranda düşürdü. Toplu (batch) API'ler (BatchIsAuthorized, BatchIsAuthorizedWithToken) ve politika yönetimi API'leri ayrı istek başına veya kademeli tarifelerle faturalandırılır. Ayrıntılar: Amazon Verified Permissions Pricing. Doğru API karışımını seçtiğinizde bu, birçok yüksek hacimli uygulama için bulut tabanlı ayrıntılı yetkilendirmeyi ekonomik kılar.

Pazar konsolidasyonu: Permify, FusionAuth tarafından satın alındı. WorkOS, Warrant'ı (Zanzibar tabanlı FGA) satın aldı. Auth0 FGA artık Okta FGA olarak pazarlanıyor. Alan, iyi finanse edilmiş birkaç oyuncu etrafında konsolide oluyor.

Yetkilendirme Modelleri#

Platformları değerlendirmeden önce, destekledikleri yetkilendirme modellerini anlamak faydalıdır. Çoğu üretim sistemi birden fazla modeli birleştirerek kullanır.

RBAC (Rol Tabanlı Erişim Kontrolü)#

Roller kullanıcılara atanır. İzinler rollere bağlanır. Roller istikrarlı olduğunda ve erişim kaynak bağlamına bağlı olmadığında iyi çalışır. Dinamik erişim gereksinimleri, çok kiracılılık ve kaynak düzeyinde paylaşımla birlikte yetersiz kalır. Her platform temel olarak RBAC'ı destekler. Asıl soru, bunun ötesinde neye ihtiyacınız olduğudur.

ABAC (Öznitelik Tabanlı Erişim Kontrolü)#

Kararlar kullanıcı, kaynak, eylem ve ortam özniteliklerine dayanır. ABAC koşullu mantıkta öne çıkar: zamana dayalı erişim, konum kısıtlamaları, uyumluluk kuralları. Cedar, Rego ve Cerbos YAML/CEL gibi politika dilleri ABAC'ı iyi ifade eder. Ödünleşim: ABAC, RBAC'a göre daha ifade gücüne sahip ancak denetlemesi ve akıl yürütmesi daha zordur.

ReBAC (İlişki Tabanlı Erişim Kontrolü)#

Erişim, varlıklar arasındaki ilişkilerle belirlenir. Bu, Google Zanzibar paradigmasıdır: "Kullanıcı X, Klasör Z'deki Belge Y'nin editörüdür." SpiceDB, OpenFGA ve Auth0 FGA gibi platformlar ReBAC'ı doğal olarak uygular. Ödünleşim: ReBAC işbirlikçi uygulamalar için mükemmeldir ancak bir ilişki grafiği sürdürmeyi gerektirir ve çift yazma problemini ortaya çıkarır.

Birleşik Yaklaşım#

Pratikte olgun sistemler birden fazla modeli birleştirir:

• RBAC temel çerçeve olarak
• ABAC bağlamsal koşullar için (zaman, IP, risk puanı)
• ReBAC kaynak düzeyinde paylaşım ve miras için
• ACL belirli kaynaklar üzerinde yerel geçersiz kılma olarak

Permit.io ve Oso Cloud gibi platformlar açıkça bu birleşik yaklaşım için tasarlanmıştır. Diğerleri birden fazla sistemi katmanlamayı gerektirir.

Platform Genel Bakışı#

Bulut Tabanlı Platformlar#

AWS Verified Permissions + Cedar

Cedar deklaratif, biçimsel olarak doğrulanmış ve hızlıdır. Karşılaştırmalı testler Cedar'ın politikaları OpenFGA'dan 28-35 kat ve Rego'dan 42-80 kat daha hızlı değerlendirdiğini gösteriyor. Bu testlerin temelden farklı mimarileri karşılaştırdığını unutmayın: Cedar yerel politikaları değerlendirirken OpenFGA bir ilişki grafiği üzerinde gezinir; doğrudan hız karşılaştırmaları bu bağlamla yorumlanmalıdır. Tek yetkilendirme API'leri indirimden sonra milyon başına 5 USD; batch ve politika yönetimi çağrıları farklıdır. Maliyet dökümü için bkz. Amazon Verified Permissions Pricing ve SaaS İçin AWS Cognito + Verified Permissions.

Cognito, API Gateway, AppSync ve Lambda ile doğal entegrasyona sahiptir. Ana kısıtlama, Cedar'ın yerleşik ilişki grafiği olmadan ABAC odaklı olmasıdır. Google Docs tarzı paylaşıma ihtiyacınız varsa, tek başına Cedar yetersizdir.

En uygun: Biçimsel garantili politika-kod yaklaşımına ihtiyaç duyan AWS tabanlı uygulamalar.

AWS tabanlı SaaS ürünleri için Cognito ve Verified Permissions eksiksiz bir yetkilendirme yığını oluşturur. Cognito kimlik doğrulama ve kiracı farkındalıklı token üretimini yönetirken, Verified Permissions bu token'ları kullanarak ince taneli yetkilendirme kararları verir. Bu entegrasyon desenine derinlemesine bir bakış için SaaS İçin AWS Cognito + Verified Permissions yazısına bakın.

Microsoft Entra ID

Entra ID, kaba taneli yetkilendirme yeteneklerine sahip bir kimlik platformudur. İnce taneli bir yetkilendirme motoru değildir. Koşullu Erişim motoru sinyalleri gerçek zamanlı değerlendirir: kullanıcı kimliği, cihaz durumu, IP konumu, oturum açma riski ve uygulama bağlamı. "Bu kullanıcı bu uygulamaya erişebilir mi?" sorusunu yanıtlar -- "Bu kullanıcı bu belirli belgeyi düzenleyebilir mi?" sorusunu değil.

Entra'nın sunduğu özellikler: basit RBAC için JWT claim'leri olarak uygulama rolleri, grup tabanlı yetkilendirme, özel güvenlik öznitelikleri (P2 özelliği), B2C/B2B için Entra External ID, insan olmayan kimlikler için Workload ID ve AWS, Azure, GCP genelinde Permissions Management (CIEM).

Entra'nın sunmadığı şeyler: ince taneli uygulama düzeyinde yetkilendirme (ABAC/ReBAC), politika-kod motorları veya ilişki tabanlı erişim kontrolü. "X kullanıcısı Z kiracısındaki Y satırını düzenleyebilir mi?" gibi kaynak düzeyinde kararlar için harici bir yetkilendirme sistemine ihtiyaç vardır.

Üretim ortamı deseni hibrit bir yapıdır: Entra, kimlik doğrulama, oturum yönetimi ve risk değerlendirmesi yapar. Harici bir PDP (Cerbos, OPA, AWS Verified Permissions veya SpiceDB) Entra'nın JWT token claim'lerini ve kaynak bağlamını kullanarak ince taneli yetkilendirme kararları verir.

En uygun: İşgücü kimliği, Koşullu Erişim ve uyumluluk gerektiren Microsoft ekosistemi kuruluşları -- ince taneli kararlar için harici bir yetkilendirme sistemiyle birlikte.

Google Cloud IAM + Identity Platform

Firebase Authentication ve Identity Platform yükseltmesi SAML, OIDC, çok kiracılılık ve MFA'yı destekler. Ancak Google, AWS Verified Permissions ile karşılaştırılabilir özel bir ayrıntılı yetkilendirme servisi sunmuyor. Token'lardaki özel talepler basit RBAC için çalışır ancak karmaşık yetkilendirme modelleri için ölçeklenmez.

En uygun: Daha basit yetkilendirme gereksinimlerine sahip Firebase/GCP uygulamaları.

Üçüncü Taraf Platformlar#

Auth0/Okta FGA -- OpenFGA (açık kaynak, Zanzibar esinli) üzerine inşa edilmiştir. 100 milyar ilişki ve saniyede 1 milyon istek desteğiyle %99,99 SLA sunar. Sınırlı ABAC yeteneğiyle ReBAC odaklıdır. Zaten Auth0/Okta kullanan kuruluşlar için en uygundur.

SpiceDB/Authzed -- En olgun açık kaynak Zanzibar uygulamasıdır. OpenAI tarafından ChatGPT Enterprise için kullanılıyor ve on milyarlarca izni yönetiyor. ZedToken'lar tutarlılık garantileri sağlar. ReBAC odaklıdır; ABAC geçici çözümler gerektirir. Self-hosted, PostgreSQL/CockroachDB ve Kubernetes uzmanlığı gerektirir. Auth0 FGA ile ayrıntılı bir karşılaştırma için SpiceDB vs Auth0 FGA: İlişki Tabanlı Yetkilendirme yazısına bakın.

Cerbos -- YAML ve CEL kullanan amaca yönelik bir uygulama yetkilendirme motorudur. Tek ikili dosya, konteyner veya sidecar olarak dağıtılır. Düşük öğrenme eğrisi. Yerleşik ilişki grafiği yoktur; ReBAC için başka bir sistemle eşleştirilmelidir. Rego veya Cedar öğrenmeden politika-kod yaklaşımı isteyen ekipler için en uygundur.

OPA (Open Policy Agent) -- CNCF mezunu bir proje ve genel amaçlı bir politika motorudur. Rego güçlüdür ancak yüksek bir öğrenme eğrisine sahiptir (yeterlilik için ~30-40 saat). Styra satın alması ticari destek konusunda belirsizlik yaratmıştır. Güçlü ekosistem desteğinin olduğu altyapı politikası (Kubernetes giriş kontrolü) için en uygundur.

Permit.io -- OPAL üzerine inşa edilmiş yetkilendirme-servis-olarak platformudur. Çoklu motor desteği: OPA, OpenFGA veya Cedar arka plan motoru olarak. Tam yeniden yazma olmadan motor değiştirme esnekliği isteyen ekipler için en uygundur.

Keycloak -- Kimlik ve erişim yönetimi için bir CNCF kuluçka projesidir. Java tabanlı ve kaynak yoğundur (örnek başına 512MB-2GB RAM). Ayrıntılı yetkilendirme için amaca yönelik olarak tasarlanmamıştır. Yerleşik yetkilendirme yetenekleriyle self-hosted IAM'e ihtiyaç duyan kuruluşlar için en uygundur.

WorkOS FGA -- Warrant'ı (Zanzibar tabanlı FGA) satın almıştır. Hiyerarşik, kaynak kapsamlı erişim kontrolüyle RBAC'ı genişletir. SSO (SAML), Directory Sync (SCIM) ve Denetim Günlükleri ile entegredir. Entegre kimlik ve ayrıntılı yetkilendirmeye ihtiyaç duyan B2B SaaS uygulamaları için en uygundur.

Mimari Desenler#

Yetkilendirme motorunu nasıl dağıttığınız, hangi motoru seçtiğiniz kadar önemlidir. Beş yaygın desen vardır ve çoğu üretim sistemi hibrit bir yaklaşımla sonuçlanır.

Merkezi PDP#

Tek bir yetkilendirme servisi tüm istekleri değerlendirir. Tüm servisler API aracılığıyla çağrı yapar.

• Artıları: Tek doğruluk kaynağı, denetimi kolay, basit politika yönetimi
• Eksileri: Tek hata noktası, her istekte ağ gecikmesi, ölçekleme darboğazı
• Ne zaman kullanılır: Düşük yetkilendirme hacmi, basit dağıtımlar, az sayıda servis

Sidecar PDP#

Yetkilendirme motoru, her servisin yanına bir sidecar konteyneri olarak dağıtılır. Politikalar merkezi bir yönetim düzleminden senkronize edilir.

• Artıları: Düşük gecikme (yerel değerlendirme), dayanıklı (karar için ağ bağımlılığı yok), servislerle birlikte ölçeklenir
• Eksileri: Pod başına kaynak yükü, politika senkronizasyon karmaşıklığı, nihai tutarlılık
• Ne zaman kullanılır: Kubernetes ortamları, yüksek yetkilendirme hacmi, gecikmeye duyarlı iş yükleri

Gömülü Kütüphane PDP#

Yetkilendirme mantığı süreç içi bir kütüphane olarak çalışır (Casbin, CASL, Cedar SDK). Yetkilendirme kararları için ağ çağrısı yoktur.

• Artıları: En hızlı değerlendirme (IPC veya ağ yükü yok), ek altyapı gerektirmez
• Eksileri: Dile özgü, servisler arasında politika yönetimi zor, merkezi denetim yok
• Ne zaman kullanılır: Tek dil yığını, basit politikalar, performans kritik yollar

API Gateway Yetkilendirmesi#

Gateway düzeyinde kaba taneli yetkilendirme ile servis düzeyinde ayrıntılı yetkilendirmenin birleşimi. İki katmanlı yaklaşımda gateway "bu kullanıcı bu API'ye erişebilir mi?" sorusunu, servis ise "bu kullanıcı bu belirli eylemi gerçekleştirebilir mi?" sorusunu yanıtlar.

• Uygulamalar: AWS API Gateway + Cognito Authorizer + Verified Permissions, Kong + OPA eklentisi

Hibrit Desen#

Çoğu olgun kuruluşun kullandığı budur. Birden fazla deseni birleştirir:

• API gateway'de kaba taneli RBAC
• Sidecar veya gömülü PDP ile ayrıntılı ABAC/ReBAC
• Merkezi bir yetkilendirme servisinden senkronize edilen ilişki verileri
• Merkezi olarak toplanan denetim izi

Hibrit desen, performans, esneklik ve operasyonel yönetilebilirlik arasında en iyi dengeyi sağlar. Kaba kontroller için API gateway ile başlamak, ayrıntılı yetkilendirme hacmini yönetilebilir tutar.

Maliyet Analizi#

Maliyet, yetkilendirme hacmine, operasyonel yüke ve ekip uzmanlığına bağlıdır. Aşağıdaki tablo, ayda 100 milyon yetkilendirme kararında yaklaşık aylık maliyetleri karşılaştırır.

İpucu: Bu rakamlar yalnızca altyapı maliyetlerini temsil eder. Politika dili için ekip öğrenme süresini, entegrasyon geliştirme ve sürekli politika bakımını da hesaba katın. Operasyonelleştirmek için 3 aylık mühendislik süresi gerektiren "ücretsiz" bir açık kaynak çözüm ücretsiz değildir.

Karar Çerçevesi#

Geliştir mi Entegre mi#

İlk karar, harici bir yetkilendirme sistemine gerçekten ihtiyacınız olup olmadığıdır.

Yönetilen mi Self-Hosted mı#

Platform Seçim Matrisi#

*Styra DAS (OPA için yönetilen seçenek), Apple satın almasının ardından kurumsal ticari destek sona ererken topluluk tarafından sürdürülen açık kaynağa geçiş yapıyor.

İpucu: Politika dili seçimi bu alandaki en belirleyici kararlardan biridir. Rego'dan Cedar'a (veya tam tersi) geçiş, her politikayı yeniden yazmak demektir. Cedar, Rego, OpenFGA DSL ve Cerbos YAML/CEL'in yan yana kod örnekleriyle ayrıntılı bir karşılaştırması için Politika Dili Karşılaştırması: Cedar vs Rego vs OpenFGA yazısına bakın.

Yaygın Tuzaklar#

Modelinizi Anlamadan Önce Platform Seçmek#

Ekipler genellikle önce bir araç seçer, sonra gereksinimlerini ona uydurmaya çalışır. Kulağa etkileyici geldiği için SpiceDB seçen bir ekip, yetkilendirmeleri ağırlıklı olarak öznitelik tabanlıysa zorlanacaktır. Önce yetkilendirme modelinizi (RBAC, ABAC, ReBAC veya hibrit) tanımlayın, ardından onu doğal olarak destekleyen platformu seçin.

Çift Yazma Problemini Hafife Almak#

Harici ilişki depoları, yetkilendirme durumunu uygulama verileriyle senkronize tutmayı gerektirir. Bir strateji (outbox deseni, CDC, uzlaştırma) olmadan yetkilendirme kararları uygulama gerçekliğinden sapacaktır. Bunun için anlamlı mühendislik zamanı ayırın. Çift yazma probleminin uygulama desenleriyle ayrıntılı bir açıklaması için SpiceDB vs Auth0 FGA: İlişki Tabanlı Yetkilendirme yazısına bakın.

Basit Uygulamalar İçin Aşırı Mühendislik#

Basit rollere sahip monolitik bir uygulama SpiceDB veya AWS Verified Permissions'a ihtiyaç duymaz. CASL gibi bir kütüphane veya basit bir middleware tabanlı yaklaşım yeterlidir. Harici sistemler, yetkilendirme servis sınırlarını aştığında değer katar.

Politika Dili Kilitlenmesini Görmezden Gelmek#

Politika dillerini değiştirmek her politikayı yeniden yazmak demektir. Yıllarca bağlı kalabileceğiniz bir politika dili seçin veya birden fazla motoru destekleyen bir soyutlama katmanı (Permit.io gibi) kullanın. Ekibin öğrenme yatırımını bu karara dahil edin.

Politika Testini İhmal Etmek#

Yetkilendirme politikaları koddur. Birim testlerine, entegrasyon testlerine ve CI/CD hatlarına ihtiyaç duyarlar. Tüm büyük platformlar politika testini destekler, ancak ekipler sıklıkla bunu atlar. Test edilmemiş yetkilendirme politikaları bir güvenlik zafiyetidir.

Satıcı İstikrarını Görmezden Gelmek#

OPA/Styra satın alması, ticari destekçilere sahip açık kaynak projelerin kesintiye uğrayabileceğini gösteriyor. Platform seçerken yönetim modelini (CNCF, bağımsız vakıf, tek satıcı) değerlendirin. Güçlü açık kaynak temelleri, satıcı istikrarsızlığına karşı sigorta sağlar.

RBAC Tavanı#

RBAC ile başlamak sorun değildir, ancak kaçınılmaz "bir istisnaya ihtiyacımız var" anına hazırlanın. Yalnızca RBAC çözümleri yerine birden fazla yetkilendirme modelini destekleyen platformları seçin. Yalnızca RBAC sisteminden çoklu model platforma geçiş maliyeti zamanla katlanarak artar.

Sonuç#

Evrensel olarak en iyi yetkilendirme platformu yoktur. Doğru seçim, yetkilendirme modelinize, bulut ortamınıza, ekip uzmanlığınıza ve ölçek gereksinimlerinize bağlıdır.

Ortamın değerlendirilmesinden elde edilen temel içgörüler:

1. Cedar ve OpenFGA DSL öncü politika dilleri olarak öne çıkıyor -- Cedar biçimsel doğrulama gerektiren ABAC odaklı iş yükleri için, OpenFGA DSL ölçekte ReBAC odaklı iş yükleri için.

2. Harici yetkilendirme, mikroservis sınırında değer katar. Monolitik uygulamalar için CASL ve Casbin gibi gömülü kütüphaneler daha basit ve yeterlidir.

3. İnsan dışı kimlikleri ilk günden planlayın. Yapay zeka ajanları ve servis hesapları yetkilendirme politikalarına ihtiyaç duyar. Yalnızca insan kullanıcılar için tasarlanan sistemler pahalı bir yeniden düzenleme gerektirecektir.

4. Çift yazma problemi harici yetkilendirmenin gizli maliyetidir. Senkronizasyon, tutarlılık ve uzlaştırma için mühendislik zamanı ayırın.

5. Politika-kod yaklaşımı tartışmasızdır. Platform seçiminden bağımsız olarak, yetkilendirme politikaları sürüm kontrollü, test edilmiş ve CI/CD üzerinden dağıtılmalıdır.

6. Pazar konsolide oluyor. Küçük oyuncular satın alınıyor ve ticari sponsorlar değişiyor. Güçlü yönetimi veya açık kaynak temelleri olan platformları seçin.

Yetkilendirme modelinizi tanımlayarak başlayın. Ardından platformları bu modele göre değerlendirin. Taahhütte bulunmadan önce en karmaşık yetkilendirme senaryonuzla bir kavram kanıtı çalıştırın. Üretimdeki yetkilendirme platformlarını değiştirmenin maliyeti önemlidir -- doğru seçimi yapmak için baştan zaman yatırın.

Bu yazı Harici Yetkilendirme Sistemleri serisinin ilk yazısıdır. Serinin devamında SaaS İçin AWS Cognito + Verified Permissions, SpiceDB vs Auth0 FGA ve Cedar vs Rego vs OpenFGA politika dili karşılaştırması konuları ele alınacaktır.

Kaynaklar#

• Cedar Policy Language Documentation - Resmi Cedar dil referansı, gramer spesifikasyonu ve politika yazma rehberleri
• AuthZed SpiceDB GitHub Repository - Açık kaynaklı Google Zanzibar esinli yetkilendirme sistemi, dokümantasyon ve örnekler
• OpenFGA Documentation - Auth0/Okta FGA'yı destekleyen açık kaynaklı Zanzibar esinli yetkilendirme motoru
• Okta Fine Grained Authorization - Auth0/Okta FGA ürün genel bakışı ve mimari dokümantasyonu
• Cloud Native Now - Apple Buys Styra Brains, OPA Remains Open - Apple'ın satın almasının ardından OPA ekosistemindeki kesintinin haberi
• Cerbos - Framework for Evaluating Authorization Providers - Yetkilendirme platformları için tarafsız değerlendirme kriterleri
• Permit.io - Policy Engine Showdown: OPA vs. OpenFGA vs. Cedar - Sözdizimi örnekleriyle kapsamlı politika motoru karşılaştırması
• Teleport - Security Benchmarking Authorization Policy Engines - Rego, Cedar, OpenFGA ve Teleport ACD karşılaştırmalı SPEF çerçevesi
• OWASP Microservices Security Cheat Sheet - PDP/PEP/PIP dahil mikroservisler için yetkilendirme desenleri
• Amazon Verified Permissions Pricing - Tek ve batch yetkilendirme ile politika yönetimi tarifeleri
• AWS - Amazon Verified Permissions reduces authorization request price - Tek yetkilendirme API fiyat indirimi duyurusu (yaklaşık %97'ye varan)
• Microsoft Learn - Conditional Access Overview - Entra ID Koşullu Erişim politikaları, sinyal değerlendirmesi ve Sıfır Güven uygulaması