OpenFGA vs SpiceDB vs Cerbos vs OPA vs AWS Verified Permissions: Hangisini Seçmeli

Özel yetkilendirme sistemleri geliştirmek birçok uygulama için işe yarıyor. Dağıtık sistemler ise politika değerlendirme, ilişki yönetimi ve ince taneli erişim kontrolünü servis olarak sunan özel yetkilendirme altyapılarından giderek daha fazla fayda görüyor. Makul bir başlangıç noktası: yetkilendirmeyi tek bir servisin içinde kaldığı sürece gömülü bir kütüphanede tutun, servis sınırını aştığı anda harici bir motora geçin.

Hangi motoru seçeceğiniz baskın modelinize bağlı. AWS üzerinde öznitelik ağırlıklı kararlar için Cedar ve AWS Verified Permissions uygun. Erişim, kullanıcı ile kaynak arasındaki ilişkilerden türüyorsa SpiceDB veya OpenFGA öne çıkıyor. Geri kalanını maliyet, operasyonel yük ve politika dili kilitlenmesi belirliyor.

Yetkilendirme Pazarında Ne Değişti#

OPA/Styra sarsıntısı: 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’ın yaygınlaşması: 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 ince taneli 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ışı kimliklerde patlama: 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. Eski sistemlerin çoğu bu iki gereksinim düşünülerek tasarlanmadı.

AWS Verified Permissions fiyat indirimi: AWS, tek yetkilendirme API’leri (IsAuthorized, IsAuthorizedWithToken) için fiyatı %97’ye varan oranda düşürdü; yayındaki ABD tarifesinde milyon istek başına 5 USD. 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 (yeni sekmede açılır). Doğru API karışımını seçtiğinizde bu, birçok yüksek hacimli uygulama için bulut tabanlı ince taneli 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.

RBAC, ABAC ve ReBAC#

Platform seçimi elinizdeki erişim modelinden çıkar; bu yüzden herhangi bir özellik tablosuna bakmadan önce o modeli adlandırmakta fayda var.

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; bu yüzden RBAC tek başına listeyi daraltmaz.

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. Bedeli: ABAC’ın ifade gücü RBAC’tan yüksektir ama denetlemesi ve üzerinde 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. Bedeli: 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.

Modelleri Tek Sistemde Katmanlamak#

Üretimdeki sistemler bunları genelde katmanlar: RBAC temeli taşır, ABAC zaman, IP veya risk puanı gibi bağlamsal koşulları ekler, ReBAC ise kaynak düzeyinde paylaşımı ve mirası kapsar. Belirli bir kaynağa konan ACL de yerel geçersiz kılma görevi görür. Permit.io ve Oso Cloud bu katmanlama için tasarlanmıştır; diğer platformlarda sistemleri kendiniz üst üste koyarsınız.

Bulut Sağlayıcı 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 (yeni sekmede açılır) ve SaaS İçin AWS Cognito + Verified Permissions.

Cognito, API Gateway, AppSync ve Lambda ile doğal entegrasyona sahiptir. SaaS ürünlerinde Cognito kimlik doğrulamayı ve kiracı farkındalıklı token üretimini üstlenir, Verified Permissions da ince taneli kararı bu token’lardan verir. 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.

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 ve orada durur. “Bu kullanıcı bu belirli belgeyi düzenleyebilir mi?” gibi kaynak düzeyindeki sorular kapsamının dışında kalır.

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).

İnce taneli uygulama düzeyinde yetkilendirme (ABAC/ReBAC), politika-kod motorları ve ilişki tabanlı erişim kontrolü bu kapsamın dışında kalır. “X kullanıcısı Z kiracısındaki Y satırını düzenleyebilir mi?” gibi kaynak düzeyinde bir karar için harici bir yetkilendirme sistemi gerekir: Entra kimlik doğrulamayı, oturum yönetimini ve risk değerlendirmesini üstlenir; harici bir PDP (Cerbos, OPA, AWS Verified Permissions veya SpiceDB) kararı Entra’nın JWT claim’leri ve kaynak bağlamıyla verir.

Entra; işgücü kimliği, Koşullu Erişim ve uyumluluk arayan Microsoft ekosistemi kuruluşlarında yerini hak eder, ince taneli kararı ise arkasındaki motor verir.

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 ince taneli yetkilendirme servisi sunmuyor. Token’lardaki özel claim’ler basit RBAC için çalışır ancak karmaşık yetkilendirme modelleri için ölçeklenmez. Daha basit ihtiyaçları olan Firebase ve GCP uygulamaları için bu çoğu zaman yeterlidir.

Bağımsız Satıcılar ve Açık Kaynak#

Auth0/Okta FGA: Token’larınızı zaten Auth0 veya Okta üretiyorsa FGA eklentisi aynı hesabın içinde kalır. OpenFGA (açık kaynak, Zanzibar esinli) üzerine kuruludur; 100 milyar ilişkiye ve saniyede 1 milyon isteğe kadar destek ile %99,99 SLA sunar, sınırlı ABAC yeteneğiyle ReBAC odaklıdır.

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; ekibi Rego veya Cedar öğrenmekten kurtarır. Tek ikili dosya, konteyner veya sidecar olarak dağıtılır, öğrenme eğrisi düşüktür. Yerleşik ilişki grafiği yoktur; ReBAC için başka bir sistemle eşleştirilmesi gerekir.

OPA (Open Policy Agent): CNCF mezunu bir proje ve genel amaçlı bir politika motorudur; en güçlü ekosistemi altyapı politikası (Kubernetes giriş kontrolü) tarafındadır. 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.

Permit.io: OPAL üzerine inşa edilmiş, servis olarak yetkilendirme sunan bir platformdur; arka planda OPA, OpenFGA veya Cedar çalışır. Bu çoklu motor katmanı sayesinde sonradan motor değiştirmek tam bir yeniden yazma gerektirmez.

Keycloak: Kimlik ve erişim yönetimi için bir CNCF kuluçka projesidir; self-hosted çalışır ve yetkilendirmeyi paket içinde getirir. Java tabanlı ve kaynak yoğundur (örnek başına 512MB-2GB RAM). İnce taneli yetkilendirme için özel olarak tasarlanmamıştır.

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 tek bir B2B SaaS paketinde birleşir.

Karar Noktası Nerede Çalışır#

Politika karar noktasının nerede çalıştığı, hangi motorun çalıştığı kadar önemlidir. Bu seçim gecikme tabanını, motor erişilemez olduğunda etkilenen alanı ve yetkilendirmenin tükettiği altyapıyı belirler.

Merkezi Servis, Sidecar veya Süreç İçi#

Dağıtım	Güçlü yanı	Zayıf yanı	Uygun olduğu yer
Ağ üzerinden çağrılan merkezi PDP servisi	Tek doğruluk kaynağı, kolay denetim ve politika yönetimi	Tek hata noktası, her kararda bir ağ turu	Düşük karar hacmi, az sayıda servis
Her servisin yanında sidecar konteyner, politikalar yönetim düzleminden senkronize	Yerel değerlendirme, karar için ağ bağımlılığı yok	Pod başına kaynak maliyeti, senkronizasyon karmaşıklığı, nihai tutarlılık	Kubernetes, yüksek hacim, gecikmeye duyarlı yollar
Süreç içi gömülü kütüphane (Casbin, CASL, Cedar SDK)	En hızlı yol, ek altyapı yok	Dile özgü, servisler arası politika yönetimi zor, merkezi denetim yok	Tek dil yığını, basit politikalar

Gateway’de Kaba, Serviste İnce#

Bu iki katman iyi birleşir; yukarıdaki diyagram da ikisini birlikte gösteriyor. Gateway, “bu kullanıcı bu API’ye erişebilir mi?” sorusunu JWT ve rol kontrolüyle yanıtlar. Servis ise “bu kullanıcı bu kayıtta bu eylemi yapabilir mi?” sorusunu sidecar veya gömülü bir PDP ile yanıtlar; ilişki verisi merkezi bir yetkilendirme servisinden senkronize edilir, denetim kayıtları merkezde toplanır. AWS API Gateway + Cognito Authorizer + Verified Permissions bir uygulama örneği, Kong + OPA eklentisi bir diğeri. Baştaki kaba kontroller, ince taneli karar hacmini ve maliyetini yönetilebilir tutar.

Ayda 100 Milyon Kararda Maliyet#

Maliyet, liste fiyatından çok karar hacmine, operasyonel yüke ve ekip uzmanlığına bağlıdır. Yaklaşık aylık rakamlar:

Platform	Aylık Maliyet	Altyapı	Operasyonel Yük
AWS Verified Permissions	~$500	Yok (yönetilen)	Düşük
SpiceDB (self-hosted)	$500-2.000	K8s + DB kümesi	Orta-Yüksek
Authzed (yönetilen)	Özel fiyatlandırma	Yok (yönetilen)	Düşük
Auth0 FGA	Paketli/Özel	Yok (yönetilen)	Düşük
Cerbos (self-hosted)	$100-500	Minimal konteynerler	Orta
OPA (sidecar)	$200-800	Pod başına sidecar	Orta
Keycloak	$300-1.000	Java VM’ler	Yüksek

Listeyi Daraltmak#

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#

Kriter	AVP/Cedar	Auth0 FGA	SpiceDB	Cerbos	OPA	Oso Cloud	Permit.io	Keycloak
RBAC	İyi	İyi	İyi	İyi	İyi	İyi	İyi	İyi
ABAC	Mükemmel	Sınırlı	Sınırlı	Mükemmel	Mükemmel	İyi	İyi	İyi
ReBAC	Sınırlı	Mükemmel	Mükemmel	Sınırlı	Sınırlı	Mükemmel	İyi	Sınırlı
Öğrenme Eğrisi	Orta	Orta	Orta	Düşük	Yüksek	Orta	Düşük	Yüksek
Self-Hosted	Hayır	Hayır	Evet	Evet	Evet	Hayır	Kısmen	Evet
Yönetilen Seçenek	Evet	Evet	Evet (Authzed)	Evet (Hub)	Sonlanıyor*	Evet	Evet	Hayır
Çoklu Bulut	Hayır	Evet	Evet	Evet	Evet	Evet	Evet	Evet
Biçimsel Doğrulama	Evet	Hayır	Hayır	Hayır	Hayır	Hayır	Hayır	Hayır
Açık Kaynak	Yalnızca motor	OpenFGA	Evet	Evet	Evet	Hayır	Yalnızca OPAL	Evet

*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.

Bu Projeler Nerede Tökezler#

Modeli Adlandırmadan Araç 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. Tersi hata da en az onun kadar yaygın: basit rollere sahip monolitik bir uygulama SpiceDB veya AWS Verified Permissions’a ihtiyaç duymaz, CASL ya da bir middleware kontrolü işi görür. Harici sistemler maliyetini ancak yetkilendirme servis sınırını aştığında çıkarır. Önce modelinizi (RBAC, ABAC, ReBAC veya katmanlı bir karışım) tanımlayın, ardından onu doğal olarak destekleyen platformu seçin.

Çift Yazma Problemi#

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. Uygulama desenleriyle ayrıntılı bir açıklama için SpiceDB vs Auth0 FGA: İlişki Tabanlı Yetkilendirme yazısına bakın.

Politika Dili ve Satıcı Kilitlenmesi#

Politika dilleri birbirinin yerine geçmez: bir geçiş, her kuralı ve onu koruyan her testi yeniden yazmak demektir. Yıllarca bağlı kalabileceğiniz bir dil seçin ya da birden fazla motoru destekleyen bir soyutlama katmanı (Permit.io gibi) kullanın; ekibin öğrenme yatırımını da fiyatın parçası sayın. Aynı dikkat dilin arkasındaki proje için de geçerli. OPA/Styra satın alması, tek ticari destekçisi olan açık kaynağın o destekçiyi kaybedebileceğini gösterdi; bu yüzden yönetim modeli (CNCF, bağımsız vakıf, tek satıcı) değerlendirmenin parçası olmalı.

Platform kararından sonra iki sorun daha gün yüzüne çıkıyor. Yetkilendirme politikaları koddur; birim testine, entegrasyon testine ve bir CI/CD hattına ihtiyaç duyarlar. Bütün büyük platformlar politika testini destekler, ekipler yine de atlar. Bir de yalnızca RBAC kullanan sistemler er geç “bir istisnaya ihtiyacımız var” talebiyle karşılaşır; rollerden fazlasını ifade edebilen bir platformu istisna gelmeden seçmek bu yüzden değerli.

Kararı Verdikten Sonra#

Gömülü kütüphane varsayılanı, yetkilendirme tek bir servisin içinde kaldığı ve roller istikrarlı olduğu sürece geçerlidir. Erişim servis sınırlarını aştığında, kullanıcılar tek tek kaynakları paylaşmaya başladığında veya bir uyumluluk kuralı uygulama katmanının taşımadığı öznitelikleri gerektirdiğinde varsayılanı bırakın. Karar vermeden önce en karmaşık yetkilendirme senaryonuzla bir kavram kanıtı çalıştırın; üretimde platform değiştirmek pahalı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ı yazıları yer alıyor.

Kaynaklar#

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