Cedar vs Rego vs OpenFGA: Politika Dili Karşılaştırması

Abstract

Yetkilendirme için seçtiğin politika dili, güvenlik mimarinin tamamını şekillendirir. Politikaların nasıl yazılacağını, test edileceğini, dağıtılacağını ve denetleneceğini belirler. Daha sonra dil değiştirmek, tüm politikaları yeniden yazmak demektir. Bu yazı, dört ana yetkilendirme politika dilinin — Cedar, Rego, OpenFGA DSL ve Cerbos YAML/CEL — söz dizimi, performans özellikleri, biçimsel doğrulama, araç desteği ve TypeScript entegrasyon kalıpları açısından derinlemesine teknik karşılaştırmasını sunuyor. Amaç, geçiş maliyeti engelleyici hale gelmeden önce bilinçli bir dil seçimi yapmanı sağlamak.

Note: Bu yazı, Harici Yetkilendirme Sistemleri serisinin 4. bölümüdür. Ana yazı platform seçimi ve mimari kalıpları kapsar. Bu yazı özellikle politika dillerinin kendilerine odaklanır.

Politika Dilinin Önemi

Yetkilendirme mantığı, güvenlik açısından kritik koddur. Uygulama servisleri arasında if-else ifadeleri ve middleware kontrolleri olarak dağılmış halde durduğunda, denetlenmesi, kapsamlı test edilmesi ve üzerinde düşünülmesi imkansız hale gelir. Politikayı koddan ayırmak bu sorunu doğrudan çözer.

Politikayı Koddan Ayırma

Ayrılmış bir politika dili net bir sınır oluşturur: uygulama kodu kullanıcının ne yapmak istediğini tanımlar, politika motoru ise bunu yapıp yapamayacağına karar verir. Bu ayrım şu anlama gelir:

• Güvenlik ekipleri politikaları uygulama kodunu okumadan inceleyebilir
• Politika değişiklikleri uygulama sürümlerinden bağımsız olarak dağıtılır
• Denetim izleri politika kararlarını standart bir formatta yakalar
• Politika testi sistematik hale gelir, entegrasyon testlerine dağılmış olmak yerine

Denetlenebilirlik ve Uyumluluk

SOC 2, HIPAA ve GDPR denetimleri, gösterilebilir erişim kontrolü gerektirir. Politikalar özel bir dilde ifade edilip sürüm kontrolünde saklandığında, denetçiler temel uygulama kodunu anlamadan bir sistemin tüm yetkilendirme mantığını inceleyebilir. Bu, uygulama koduna gömülü yetkilendirme mantığına göre anlamlı bir avantajdır.

Biçimsel Doğrulama

Cedar, politika kümeleri üzerinde yetkilendirme odaklı özellik analizi ve biçimsel akıl yürütme için birinci parti Cedar Analyzer araçlarıyla gelir (örneğin, belirli bir koşulu karşılamayan bir sorumluya erişim veren politika olmadığını göstermek). Başka ekosistemlerde de biçimsel yöntemler vardır; ancak yaygın kullanılan yetkilendirme politika dilleri arasında bu kapsamda sürdürülen bir analizör daha az rastlanır. Garantiler, yalnızca kapsamlı testle aynı türde değildir.

Cedar (AWS)

Cedar, Amazon tarafından geliştirilen ve AWS Verified Permissions tarafından kullanılan bildirimsel bir politika dilidir. Biçimsel doğrulama temel bir tasarım hedefi olarak, yetkilendirme için sıfırdan tasarlanmıştır.

Söz Dizimi ve Model

Cedar, permit/forbid (izin ver/yasakla) modeli kullanır. Her politika bir eylemi ya izin verir ya da yasaklar. Herhangi bir forbid politikası bir istekle eşleşirse, kaç tane permit politikası da eşleşse istek reddedilir. Bu “reddetme öncelikli” davranış, uygulama düzeyinde bir kural değil, dil semantiğine yerleşiktir.

// Editörlerin kendi departmanlarındaki belgeleri düzenlemesine izin ver
permit(
  principal in Role::"Editor",
  action == Action::"EditDocument",
  resource
)
when {
  principal.department == resource.department
};

// Mesai saatleri dışında tüm erişimi yasakla -- herhangi bir permit'i geçersiz kılar
forbid(
  principal,
  action,
  resource
)
when {
  context.currentTime.hour < 9 ||
  context.currentTime.hour >= 17
};

Cedar’ın temel özellikleri:

• Varlık tipleri ve şema: Cedar, varlık tiplerini, özniteliklerini ve ilişkilerini tanımlayan tipli bir şema gerektirir. is operatörü (Cedar dil sürümü 3.0+, RFC 5), politikalar içinde tip tabanlı eşleştirmeyi sağlar.
• Permit/forbid modeli: Açık reddetme önceliği. Bu, politika sonuçları hakkında düşünmeyi öngörülebilir kılar.
• when ve unless ile koşullar: Sorumlu, kaynak, eylem ve bağlam özniteliklerine referans veren boolean koşullar.
• Yan etkisiz: Cedar politikaları saf fonksiyonlardır. Durum değiştiremez, harici servisleri çağıramaz veya yan etki üretemez. Biçimsel doğrulamayı mümkün kılan da budur.

Biçimsel Doğrulama

Cedar Analyzer şöyle sorulara yanıt verebilir:

• “Admin olmayan birinin bir production kaynağını silmesi mümkün mü?”
• “Bu politika deposundaki herhangi iki politika çelişiyor mu?”
• “İzin verilen her eylem, sorumluyu en az bir gruba üye olmaya zorluyor mu?”

Bunlar test senaryoları değil. Tüm politika alanı üzerinde matematiksel kanıtlardır. Doğrulama, otomatik akıl yürütme (SMT çözücüler) kullanılarak gerçekleştirilir ve bireysel test girdileri üzerinde değil, politika seti bütünü üzerinde çalışır.

Performans

Cedar, Rust ile yazılmıştır ve politikaları verimli bir dahili temsile derler. Teleport SPEF kıyaslamalarında Cedar, politika değerlendirmesinde OpenFGA’dan 28.7x-35.2x, Rego’dan 42.8x-80.8x daha hızlı ölçülmüştür.

Önemli bir not: bu kıyaslamalar temelden farklı işlemleri karşılaştırır. Cedar, bir isteğe karşı yerel öznitelik tabanlı politikaları değerlendirir. OpenFGA bir ilişki grafiğini dolaşır. Rego, bir belge modeli üzerinde Datalog tarzı sorgular değerlendirir. Ham değerlendirme hızlarını karşılaştırmak, bir SQL sorgusunun hızını bir graf dolaşımıyla karşılaştırmak gibidir — mimariler farklı sorunları çözer. Cedar’ın hız avantajı ABAC iş yükleri için gerçektir, ancak bu Cedar’ın ilişki tabanlı erişim kontrolü için OpenFGA’dan “daha iyi” olduğu anlamına gelmez.

AWS Verified Permissions ile Entegrasyon

Cedar, AWS Verified Permissions (AVP) için yerel politika dilidir. AVP, yönetilen bir politika deposu, toplu yetkilendirme API’leri ve Cognito, API Gateway ve AppSync ile yerel entegrasyon sağlar. Cedar, açık kaynak Cedar SDK aracılığıyla AWS dışında da kullanılabilir.

Rego (OPA)

Rego, bir CNCF mezun projesi olan Open Policy Agent (OPA) için politika dilidir. Cedar’ın yetkilendirmeye özgü tasarımının aksine, Rego yetkilendirme kuralları, Kubernetes kabul kontrolü, Terraform plan doğrulaması ve altyapı uyumluluk kontrolleri ifade edebilen genel amaçlı bir politika dilidir.

Söz Dizimi ve Model

Rego, bildirimsel bir mantık programlama dili olan Datalog’dan ilham almıştır. Politikalar, doğru veya yanlış olarak değerlendirilen kurallar halinde ifade edilir. input belgesi istek bağlamını, data ise OPA’ya yüklenen harici verileri içerir.

package document.authz

import rego.v1

default allow := false

# Editörlerin kendi departmanlarındaki belgeleri düzenlemesine izin ver
allow if {
  input.user.role == "editor"
  input.user.department == input.resource.department
  is_business_hours
}

# Mesai saatleri kontrolü için yardımcı kural
is_business_hours if {
  hour := time.clock(time.now_ns())[0]
  hour >= 9
  hour < 17
}

# Reddetme geçersiz kılması -- ayrıca kontrol edilmeli
deny if {
  input.resource.classification == "restricted"
  not input.user.clearance == "top-secret"
}

Rego’nun temel özellikleri:

• Datalog ilhamı: Kurallar örtük olarak AND ile birleştirilir (bir kural gövdesindeki tüm koşullar doğru olmalıdır). Aynı isimle birden fazla kural tanımı OR ile birleştirilir.
• Belge modeli: Input ve data JSON belgeleridir. Politikalar bu belgelerde yol ifadeleri kullanarak gezinir.
• Genel amaçlı: Rego herhangi bir politikayı ifade edebilir, sadece yetkilendirme değil. Bu esneklik, daha dik bir öğrenme eğrisi pahasına gelir.
• Kısmi değerlendirme: OPA politikaları kısmen değerlendirebilir, mümkün olan yerlerde sonuçları önceden hesaplayarak bilinmeyen değerler için yer tutucular bırakır. Bu, verimli sorgu derlemeyi sağlar.
• Yerleşik fonksiyonlar: Rego; string manipülasyonu, zaman işlemleri, HTTP istekleri, JSON Web Token doğrulaması ve daha fazlası için fonksiyonlar içerir.

Öğrenme Eğrisi

Rego’nun Datalog kökleri, çoğu uygulama geliştiricisi için onu tanıdık olmaktan çıkarır. Kural gövdelerindeki örtük bağlantı (AND), kural tanımları arasındaki örtük ayrışma (OR) ve birleştirme semantiği, zorunlu veya hatta çoğu bildirimsel dilden farklı bir zihinsel model gerektirir. Yeterlilik genellikle 30-40 saatlik özel çalışma gerektirir.

import rego.v1 direktifi (ileriye uyumluluk için tanıtıldı) bazı varsayılan davranışları değiştirir, bu da farklı dönemlerden Rego örnekleri okuyan geliştiriciler için kafa karışıklığı yaratır.

OPA/Styra Durumu

Apple, Styra’nın kurucu ortaklarını ve çekirdek ekibini işe aldı. Styra DAS (ticari OPA yönetim platformu), kurumsal ticari desteğin sona ermesiyle birlikte topluluk tarafından sürdürülen açık kaynağa geçiş yapıyor. OPA’nın kendisi CNCF yönetişimi altında kalmaya devam ediyor ve topluluk aktif. Ancak, politika yaşam döngüsü yönetimi için Styra DAS’a güvenen kurumsal kullanıcıların artık alternatif araçlara ihtiyacı var. Bu durum, bazı OPA kullanıcıları arasında Cerbos, Cedar ve Permit.io gibi alternatiflerin değerlendirilmesini hızlandırdı.

Ekosistem Gücü

Styra geçişine rağmen, Rego herhangi bir politika dilinin en geniş ekosistemine sahiptir:

• Kubernetes: Kabul kontrolü için OPA Gatekeeper
• Terraform: Plan doğrulaması için Conftest ve Rego politikaları
• Envoy: Harici yetkilendirme filtresi olarak OPA
• API gateway’ler: Kong, Traefik ve diğerleri OPA entegrasyonunu destekler
• CI/CD: Build pipeline’larında politika kontrolleri

Bu ekosistem genişliği, Rego’nun en güçlü avantajıdır. Altyapı ve uygulama yetkilendirmesi genelinde tek bir politika diline ihtiyacın varsa, Rego en çok yönlü seçimdir.

OpenFGA DSL

OpenFGA DSL, Auth0/Okta FGA’yı besleyen açık kaynak Zanzibar ilhamı yetkilendirme motoru OpenFGA için modelleme dilidir. Kurallar ifade eden Cedar ve Rego’dan farklı olarak, OpenFGA DSL ilişkileri ve tip tanımlarını ifade eder.

Söz Dizimi ve Model

OpenFGA DSL, yetkilendirme modellerini tip sistemleri olarak tanımlar. Erişim, özniteliklere karşı koşulların değerlendirilmesiyle değil, varlıklar arasındaki ilişkilerin varlığıyla belirlenir.

model
  schema 1.1

type user

type department
  relations
    define member: [user]

type document
  relations
    define department: [department]
    define owner: [user]
    define editor: [user] or member from department
    define viewer: editor or owner
    define can_edit: editor
    define can_view: viewer

OpenFGA DSL’in temel özellikleri:

• Tip sistemi: Her varlığın bir tipi vardır. İlişkiler tipler arasında tanımlanır. Bu, güçlü tipli bir yetkilendirme modeli oluşturur.
• İlişki operatörleri: Doğrudan atama ([user]), hesaplanmış ilişkiler (editor or owner) ve tuple-to-userset eşlemeleri (member from department).
• Modelde öznitelik koşulları yok: Çekirdek model, koşullu mantık değil yapısal ilişkiler ifade eder. Bu, Zanzibar paradigmasıyla uyumlu kasıtlı bir tasarım tercihidir.

Koşullar (Schema 1.1+)

Schema 1.1’den itibaren, OpenFGA Google’ın Common Expression Language (CEL) kullanarak koşul desteği ekledi. Koşullar, ilişki tip kısıtlamalarına eklenebilir:

model
  schema 1.1

type user

type document
  relations
    define viewer: [user]
    define time_limited_viewer: [user with non_expired_grant]

condition non_expired_grant(current_time: timestamp, grant_expires: timestamp) {
  current_time < grant_expires
}

Bu önemli bir eklentidir, ancak OpenFGA’daki koşullar hala ilişki atamalarıyla sınırlıdır, rastgele politika kurallarıyla değil. Örnek senaryodaki mesai saatleri kontrolünün, bağımsız bir politika kuralı değil, ilişkiye eklenmiş bir koşul olması gerekir.

SpiceDB Şeması ile Karşılaştırma

SpiceDB benzer ancak farklı bir şema dili kullanır. Her ikisi de Zanzibar ilhamlıdır, ancak söz dizimi ve bazı yetenekler açısından farklılık gösterirler:

// SpiceDB şeması -- aynı kavramlar, farklı söz dizimi
definition user {}

definition department {
  relation member: user
}

definition document {
  relation department: department
  relation owner: user
  relation editor: user | department#member
  permission can_edit = editor
  permission can_view = editor + owner
}

SpiceDB şeması type yerine definition, define yerine permission kullanır ve birleşim için + operatörünü kullanır. SpiceDB ayrıca OpenFGA’nın yapmadığı tam Zanzibar tutarlılık modelini ZedToken’larla uygular.

OpenFGA DSL Ne Zaman Kullanılmalı

OpenFGA DSL, yetkilendirmenin temelde “kim neyle ne ilişkisine sahip” olduğuyla ilgili olduğu durumlarda başarılıdır. Paylaşım modelleri (Google Docs tarzı “Kullanıcı X, Belge Y’yi düzenleyebilir”), hiyerarşik yapılar (klasör izinlerinin belgelere miras kalması) ve organizasyonel modeller (departman tabanlı erişim) olan uygulamalar, doğal olarak OpenFGA’nın ilişki modeline eşlenir.

Öznitelik tabanlı koşullar için daha az uygundur. Yetkilendirme kuralların büyük ölçüde zaman, konum, risk puanı veya diğer bağlamsal özniteliklere bağlıysa, OpenFGA ya koşulları kullanmayı (sınırlı) ya da yanına bir ABAC sistemi katmanlamayı gerektirir.

Cerbos (YAML + CEL)

Cerbos farklı bir yaklaşım benimser: politikalar koşullar için CEL (Common Expression Language) ile YAML’de yazılır. Öğrenilecek özel bir dil yoktur. YAML ve temel ifade söz dizimini biliyorsan, Cerbos politikaları yazabilirsin.

Söz Dizimi ve Model

Cerbos, kaynak merkezli bir model kullanır. Politikalar kaynak tiplerine bağlanır ve hangi rollerin hangi eylemleri gerçekleştirebileceğini, isteğe bağlı olarak koşullarla tanımlar.

# Belgeler için kaynak politikası
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: "document"
  version: "default"
  rules:
    - actions: ["edit"]
      effect: EFFECT_ALLOW
      roles: ["editor"]
      condition:
        match:
          all:
            of:
              - expr: "request.resource.attr.department == request.principal.attr.department"
              - expr: "now().getHours() >= 9 && now().getHours() < 17"

    - actions: ["delete"]
      effect: EFFECT_ALLOW
      roles: ["admin"]
      # Koşul yok -- admin'ler her zaman silebilir

Cerbos YAML/CEL’in temel özellikleri:

• Kaynak merkezli: Politikalar kaynak tipine göre organize edilir. Her kaynak tipinin kendi politika dosyası vardır.
• YAML yapısı: Politika yapısı bildirimsel YAML’dir. Öğrenilecek özel bir gramer veya ayrıştırıcı yoktur.
• CEL ifadeleri: Koşullar, Kubernetes, Firebase ve Google Cloud IAM tarafından da kullanılan Google’ın Common Expression Language’ini kullanır. CEL, iyi belgelenmiş, geniş çapta desteklenen bir ifade dilidir.
• Türetilmiş roller: İstek zamanında bağlama dayalı olarak hesaplanan roller. Örneğin, “employee” rolüne sahip bir kullanıcı, kaynağın departmanını yönetiyorsa “department_manager” rolünü alır.

Türetilmiş Roller

Türetilmiş roller, Cerbos’un ayırt edici bir özelliğidir. Uygulamanın rolleri önceden hesaplamasına gerek kalmadan dinamik rol hesaplamaya olanak tanırlar:

# Türetilmiş rol tanımı
apiVersion: "api.cerbos.dev/v1"
derivedRoles:
  name: "document_roles"
  definitions:
    - name: "document_owner"
      parentRoles: ["user"]
      condition:
        match:
          expr: "request.resource.attr.ownerId == request.principal.id"

    - name: "department_member"
      parentRoles: ["employee"]
      condition:
        match:
          expr: "request.resource.attr.department == request.principal.attr.department"

Bu türetilmiş roller daha sonra kaynak politikalarında referans alınabilir ve iki katmanlı bir sistem oluşturur: uygulama temel rolleri sağlar, Cerbos ise değerlendirme zamanında bağlama özgü rolleri hesaplar.

Ödünleşimler

YAML/CEL yaklaşımı, ifade gücünü erişilebilirlik karşılığında takas eder. Cerbos politikaları, geliştiricilerin özel eğitim almadan okuması ve yazması için basittir. Öğrenme eğrisi yaklaşık 5-10 saattir, Rego için 30-40 saat ile karşılaştırıldığında. Ancak YAML, Rego’nun kısmi değerlendirmesi, Cedar Analyzer tarzı özellik analizi veya OpenFGA’nın ilişki grafi dolaşımı gibi gelişmiş özellikleri desteklemez. Karmaşık yetkilendirme mantığı için YAML politikaları derin iç içe geçmiş ve bakımı zor hale gelebilir.

Aynı Senaryo Dört Dilde

Karşılaştırmayı somutlaştırmak için, işte aynı yetkilendirme kuralı uç durumlar dahil dört dilde uygulanmış hali.

Kural: “Editörler, mesai saatleri içinde kendi departmanlarındaki belgeleri düzenleyebilir. Departman yöneticileri, kendi departmanlarındaki herhangi bir belgeyi her zaman düzenleyebilir. Arşivlenmiş belgeleri kimse düzenleyemez.”

Cedar

// Editörler: departman eşleşmesi + mesai saatleri
permit(
  principal in Role::"Editor",
  action == Action::"EditDocument",
  resource
)
when {
  principal.department == resource.department &&
  context.currentTime.hour >= 9 &&
  context.currentTime.hour < 17
};

// Departman yöneticileri: departman eşleşmesi, zaman kısıtlaması yok
permit(
  principal in Role::"DepartmentManager",
  action == Action::"EditDocument",
  resource
)
when {
  principal.department == resource.department
};

// Reddetme geçersiz kılması: arşivlenmiş belgeleri kimse düzenleyemez
forbid(
  principal,
  action == Action::"EditDocument",
  resource
)
when {
  resource.status == "archived"
};

Cedar, reddetme geçersiz kılmasını doğal olarak işler. Arşivlenmiş belgeler için forbid politikası, rol veya zaman fark etmeksizin her iki permit politikasını da geçersiz kılar.

Rego

package document.authz

import rego.v1

default allow := false

# Editörler: departman eşleşmesi + mesai saatleri
allow if {
  input.user.role == "editor"
  input.user.department == input.resource.department
  is_business_hours
  not is_archived
}

# Departman yöneticileri: departman eşleşmesi, zaman kısıtlaması yok
allow if {
  input.user.role == "department_manager"
  input.user.department == input.resource.department
  not is_archived
}

is_business_hours if {
  hour := time.clock(time.now_ns())[0]
  hour >= 9
  hour < 17
}

is_archived if {
  input.resource.status == "archived"
}

Rego’da arşivlenmiş kontrolü her allow kuralına açıkça dahil edilmelidir (not is_archived kullanılarak). Yerleşik bir reddetme geçersiz kılma mekanizması yoktur — uygulamanın hem allow hem de herhangi bir deny kuralını sorgulaması gerekir.

OpenFGA DSL

model
  schema 1.1

type user

type department
  relations
    define member: [user]
    define manager: [user]

type document
  relations
    define department: [department]
    define editor: [user] or member from department
    define department_manager: manager from department
    define can_edit: editor or department_manager but not archived
    define archived: [user:*]

OpenFGA yapısal ilişkileri modelleyebilir ancak mesai saatleri koşulunu DSL içinde ifade edemez. Zamana dayalı kısıtlama, uygulama katmanında veya bir koşul aracılığıyla işlenmesi gerekir:

condition during_business_hours(current_hour: int) {
  current_hour >= 9 && current_hour < 17
}

type document
  relations
    define editor: [user with during_business_hours] or member from department

Bu temel bir farkı gösterir: OpenFGA “kimin neyle ne ilişkisi var” sorusunu yanıtlar, zamana dayalı koşullar ise ek bağlam gerektirir.

Cerbos YAML/CEL

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: "document"
  version: "default"
  rules:
    # Editörler: departman eşleşmesi + mesai saatleri
    - actions: ["edit"]
      effect: EFFECT_ALLOW
      derivedRoles: ["department_editor"]
      condition:
        match:
          all:
            of:
              - expr: "now().getHours() >= 9 && now().getHours() < 17"

    # Departman yöneticileri: departman eşleşmesi, her zaman
    - actions: ["edit"]
      effect: EFFECT_ALLOW
      derivedRoles: ["department_manager"]

    # Reddetme geçersiz kılması: arşivlenmiş belgeler
    - actions: ["edit"]
      effect: EFFECT_DENY
      roles: ["*"]
      condition:
        match:
          expr: "request.resource.attr.status == 'archived'"

Cerbos, Cedar’ın forbid mekanizmasına benzer şekilde EFFECT_ALLOW kurallarını geçersiz kılan açık EFFECT_DENY kurallarını destekler. Türetilmiş roller (department_editor, department_manager) ayrı tanımlanır ve departman eşleştirme mantığını işler.

Performans Kıyaslamaları

Performans yetkilendirme için önemlidir — her API isteğinin kritik yolunda yer alır. Ancak kıyaslama sayıları dikkatli yorumlanmalıdır.

Ham Sayılar

Teleport SPEF framework’ü, rastgele oluşturulmuş girdilerde şunları ölçtü:

Motor	Göreli Hız	Mimari
Cedar	1x (temel)	Yerel öznitelik değerlendirmesi
OpenFGA	28-35x daha yavaş	İlişki grafi dolaşımı
Rego (OPA)	42-80x daha yavaş	Datalog sorgu değerlendirmesi

Doğrudan Karşılaştırma Neden Yanıltıcıdır

Bu motorlar temelden farklı sorunları çözer:

• Cedar, bilinen özniteliklere sahip tek bir isteğe karşı bir politika setini değerlendirir. Değerlendirme durumsuz ve yereldir.
• OpenFGA, bir konu ile nesne arasında yol olup olmadığını belirlemek için bir ilişki grafiğini dolaşır. Hız, graf derinliğine ve genişliğine bağlıdır.
• Rego/OPA, bir belge modeli üzerinde Datalog ilhamlı sorguları değerlendirir. Rego’nun genelliği, özel amaçlı bir yetkilendirme değerlendiricisinden değerlendirme başına daha fazla iş yapması anlamına gelir.

Hızlarını karşılaştırmak, bir hash tablosu aramasını bir graf BFS ile bir SQL sorgusunu karşılaştırmak gibidir. Her biri kendi amaçlanan işlemi için hızlıdır.

Gerçek Dünya Performans Değerlendirmeleri

Pratikte, yetkilendirme gecikmesi ham değerlendirme hızından daha fazlasına bağlıdır:

• Ağ yükü: Bir sidecar PDP mikrosaniyeler ekler. Merkezi bir PDP milisaniyeler ekler. Çoğu uygulama için ağ gecikmesi, değerlendirme süresine baskın gelir.
• Önbellek: Yetkilendirme kararlarını önbelleğe almak (uygun TTL ile) daha yavaş değerlendirme motorlarının etkisini azaltır. Önbelleğe alınmış bir karar, motor ne olursa olsun hızlıdır.
• Toplu değerlendirme: Cedar (AVP aracılığıyla) ve Cerbos, toplu yetkilendirmeyi destekler — tek bir istekte birden fazla izni kontrol eder. Bu, ağ yükünü amorti eder.
• İlişki grafi boyutu: OpenFGA ve SpiceDB performansı ilişki grafinin derinliğine bağlıdır. Sığ graflar hızlıdır; derin iç içe geçmiş hiyerarşiler daha fazla dolaşım gerektirir.

Tip: Genel girdileri değil, kendi özel yetkilendirme kalıplarını kıyasla. 50 ABAC politikası olan bir sistem, 5 milyon ilişkisi olan bir sistemden farklı performans özelliklerine sahip olacaktır.

Araç Desteği ve Geliştirici Deneyimi

Politika dili kullanılabilirliği söz diziminden daha fazlasına bağlıdır. CLI araçları, test framework’leri, playground’lar ve IDE desteği gibi çevreleyen araçlar, günlük geliştirici deneyimini şekillendirir.

CLI Araçları

Dil	CLI Aracı	Temel Özellikler
Cedar	cedar CLI	Politika doğrulama, değerlendirme, biçimlendirme, analiz
Rego	opa CLI	Değerlendirme, test, biçimlendirme, derleme, kontrol
OpenFGA	fga CLI	Model doğrulama, ilişki sorguları, depo yönetimi
Cerbos	cerbos CLI	Derleme, test, yerel olarak çalıştırma

Test

Dört dil de politika testini destekler, ancak yaklaşımlar farklıdır:

Cedar: Cedar CLI bir check-parse komutu içerir ve analiz araçları politika özelliklerini doğrulayabilir. Entegrasyon testi, Cedar SDK kullanarak test fixture’larına karşı politikaları değerlendirir.

Rego: OPA’nın yerleşik bir test framework’ü vardır. Testler Rego’nun kendisinde yazılır, bu hem güçlüdür hem de öğrenme eğrisine eklenir:

package document.authz_test

import rego.v1

test_editor_allowed_during_business_hours if {
  allow with input as {
    "user": {"role": "editor", "department": "engineering"},
    "resource": {"department": "engineering"},
    "time": {"hour": 10}
  }
}

test_editor_denied_outside_business_hours if {
  not allow with input as {
    "user": {"role": "editor", "department": "engineering"},
    "resource": {"department": "engineering"},
    "time": {"hour": 22}
  }
}

OpenFGA: OpenFGA, CLI ve playground aracılığıyla model doğrulama ve assertion testi sağlar. Testler, belirli ilişkilerin beklenen yetkilendirme sonuçlarını ürettiğini doğrular.

Cerbos: Cerbos’un YAML test dosyaları kullanan özel bir test framework’ü vardır:

name: "Document edit tests"
input:
  principals:
    - id: "user1"
      roles: ["editor"]
      attr:
        department: "engineering"
  resources:
    - kind: "document"
      id: "doc1"
      attr:
        department: "engineering"
        status: "active"
  actions: ["edit"]
expected:
  - principal: "user1"
    resource: "doc1"
    actions:
      edit: EFFECT_ALLOW

Playground ve IDE Desteği

Dil	Playground	VS Code Eklentisi	IntelliJ Plugin
Cedar	cedarpolicy.com	Evet	Hayır
Rego	play.openpolicyagent.org	Evet (OPA eklentisi)	Evet
OpenFGA	play.fga.dev	Evet	Evet
Cerbos	play.cerbos.dev	Evet	Hayır

Dokümantasyon Kalitesi

• Cedar: İyi yapılandırılmış referans dokümantasyonu. Akademik makale (OOPSLA 2024) derin teknik arka plan sağlar ancak pratik kullanım için gerekli değildir.
• Rego: Kapsamlı dokümantasyon, ancak hacim bunaltıcı olabilir. Başlangıçtan yeterliliğe öğrenme yolu her zaman net değildir.
• OpenFGA: Adım adım modelleme rehberleriyle net, örnek odaklı dokümantasyon. Playground entegrasyonu kavramları somutlaştırır.
• Cerbos: Aşamalı eğitimler ve OPA’dan geçiş rehberleriyle pratik, geliştirici odaklı dokümantasyon.

Entegrasyon Kalıpları

Her dilin uygulama koduyla nasıl entegre olduğu, benimseme ve bakım için önemlidir. İşte her biri için TypeScript entegrasyon örnekleri.

Cedar (AWS Verified Permissions aracılığıyla)

import {
  VerifiedPermissionsClient,
  IsAuthorizedCommand,
} from "@aws-sdk/client-verifiedpermissions";

const avpClient = new VerifiedPermissionsClient({ region: "eu-central-1" });

async function canEditDocument(
  userId: string,
  documentId: string,
  userDept: string,
  docDept: string
): Promise<boolean> {
  const command = new IsAuthorizedCommand({
    policyStoreId: "ps-store-id",
    principal: {
      entityType: "MyApp::User",
      entityId: userId,
    },
    action: {
      actionType: "MyApp::Action",
      actionId: "EditDocument",
    },
    resource: {
      entityType: "MyApp::Document",
      entityId: documentId,
    },
    entities: {
      entityList: [
        {
          identifier: { entityType: "MyApp::User", entityId: userId },
          attributes: {
            department: { string: userDept },
          },
        },
        {
          identifier: { entityType: "MyApp::Document", entityId: documentId },
          attributes: {
            department: { string: docDept },
          },
        },
      ],
    },
  });

  const response = await avpClient.send(command);
  return response.decision === "ALLOW";
}

Rego (OPA REST API aracılığıyla)

async function canEditDocument(
  userId: string,
  documentId: string,
  userRole: string,
  userDept: string,
  docDept: string
): Promise<boolean> {
  const response = await fetch("http://localhost:8181/v1/data/document/authz/allow", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      input: {
        user: { id: userId, role: userRole, department: userDept },
        resource: { id: documentId, department: docDept },
      },
    }),
  });

  const result = await response.json();
  return result.result === true;
}

OpenFGA (SDK aracılığıyla)

import { OpenFgaClient } from "@openfga/sdk";

const fgaClient = new OpenFgaClient({
  apiUrl: "http://localhost:8080",
  storeId: "store-id",
  authorizationModelId: "model-id",
});

async function canEditDocument(
  userId: string,
  documentId: string
): Promise<boolean> {
  const { allowed } = await fgaClient.check({
    user: `user:${userId}`,
    relation: "can_edit",
    object: `document:${documentId}`,
  });

  return allowed ?? false;
}

// İlişki yaz (editör ataması)
async function assignEditor(
  userId: string,
  documentId: string
): Promise<void> {
  await fgaClient.write({
    writes: [
      {
        user: `user:${userId}`,
        relation: "editor",
        object: `document:${documentId}`,
      },
    ],
  });
}

Cerbos (SDK aracılığıyla)

import { GRPC as Cerbos } from "@cerbos/grpc";

const cerbos = new Cerbos("localhost:3593");

async function canEditDocument(
  userId: string,
  documentId: string,
  userRoles: string[],
  userDept: string,
  docDept: string,
  docStatus: string
): Promise<boolean> {
  const decision = await cerbos.checkResource({
    principal: {
      id: userId,
      roles: userRoles,
      attr: { department: userDept },
    },
    resource: {
      kind: "document",
      id: documentId,
      attr: {
        department: docDept,
        status: docStatus,
      },
    },
    actions: ["edit"],
  });

  return decision.isAllowed("edit");
}

Karar Matrisi

Aşağıdaki tablo, dört dil arasındaki temel farkları özetler. Bunu kesin bir cevap olarak değil, bir başlangıç noktası olarak kullan — özel gereksinimlerin seçimi yönlendirmelidir.

Kriter	Cedar	Rego	OpenFGA DSL	Cerbos YAML/CEL
Paradigma	Bildirimsel politika	Datalog ilhamlı	İlişki modelleme	Bildirimsel YAML + CEL
Öğrenme Eğrisi	Orta (~15-20s)	Yüksek (~30-40s)	Orta (~10-15s)	Düşük (~5-10s)
İfade Gücü	ABAC odaklı	Genel amaçlı	ReBAC odaklı	ABAC odaklı
Biçimsel Doğrulama	Evet	Hayır	Hayır	Hayır
Reddetme Önceliği	Yerleşik (forbid)	Manuel	Sınırlı (but not)	Yerleşik (EFFECT_DENY)
Yönetilen Servis	AWS Verified Permissions	Sonlandırılıyor*	Auth0/Okta FGA	Cerbos Hub
Açık Kaynak	Cedar SDK	OPA (CNCF)	OpenFGA	Cerbos PDP
Performans	En hızlı (kıyaslamalarda)	Yetkilendirme için en yavaş	Orta	Hızlı
En İyi Kullanım	ABAC + biçimsel garantiler	Altyapı + uygulama politikası	Ölçekte ReBAC	Hızlı benimseme, uygulama ABAC
IDE Desteği	VS Code	VS Code + IntelliJ	VS Code + IntelliJ	VS Code
Test Framework’ü	SDK tabanlı	Yerleşik (Rego testleri)	CLI assertion’lar	YAML test dosyaları
Ekosistem Genişliği	AWS servisleri	En geniş (K8s, Terraform)	Zanzibar ekosistemi	Uygulama yetkilendirmesi

*Styra DAS (yönetilen OPA seçeneği) topluluk tarafından sürdürülen açık kaynağa geçiş yapıyor.

Karar Akış Şeması

Yaygın Tuzaklar

Sadece Kıyaslamalara Göre Seçim Yapmak

Cedar’ın performans rakamları etkileyicidir, ancak performans nadiren politika dili seçimi için belirleyici faktördür. Yetkilendirme modelin ilişki tabanlıysa, Cedar’ın hız avantajı alakasızdır çünkü Cedar yerel olarak ilişki grafi dolaşımını desteklemez. Önce yetkilendirme modeline uygun dili seç, sonra performans için optimize et.

Dil Kilitlenmesini Hafife Almak

Politika dili değiştirmek, her politikayı yeniden yazmak, her geliştiriciyi yeniden eğitmek ve her entegrasyon testini yeniden oluşturmak demektir. Bu bir framework değişikliği değildir — veritabanı sorgu dilini değiştirmeye daha yakındır. Taahhüt etmeden önce dili değerlendirmeye zaman yatır.

Ekosistemi Görmezden Gelmek

Bir politika dili izole olarak var olmaz. Dil yığının için SDK kalitesini, topluluk aktivitesini, dokümantasyon olgunluğunu ve uzun vadeli yönetişim modelini değerlendir. Rego’nun geniş ekosistemi (Kubernetes, Terraform, Envoy), belirli kullanım durumun için başka bir dilin daha iyi söz dizimine sahip olsa bile onu değerli kılar.

Tablo veya Diyagramın Daha İyi Olacağı Yerde Kod Kullanmak

Yetkilendirme karar mantığı, sözde kod yerine karar tabloları ve akış şemaları aracılığıyla daha iyi iletilir. Yetkilendirme modelini paydaşlara belgelerken, kuralları kod örnekleri yerine tablolar veya diyagramlar olarak ifade et. Kodu gerçek politika uygulaması için sakla.

Politika Testini Atlamak

Her büyük politika dili testi destekler. Cedar SDK tabanlı test, Rego yerleşik test framework’ü, OpenFGA assertion’lar ve Cerbos YAML test süitleri sunar. Test edilmemiş yetkilendirme politikaları bir güvenlik yükümlülüğüdür. Politika testine, uygulama kodu testi ile aynı titizliği göster.

Sonuç

Her politika dili, yetkilendirme hakkında farklı bir felsefeyi yansıtır:

• Cedar güvenlik ve analiz edilebilirliği önceliklendirir. Politikalar üzerinde birinci parti özellik tarzı analiz (Cedar Analyzer) gerekiyorsa, bu dört dil arasında en güçlü uyum Cedar’dadır.
• Rego genelliği önceliklendirir. Altyapı politikası, Kubernetes kabul kontrolü ve uygulama yetkilendirmesi için tek bir dile ihtiyacın varsa, Rego’nun genişliği rakipsizdir.
• OpenFGA DSL ilişki modelemeyi önceliklendirir. Yetkilendirmen temelde “kim neyle ne ilişkisine sahip” ile ilgiliyse, OpenFGA’nın tip sistemi doğrudan alanına eşlenir.
• Cerbos YAML/CEL erişilebilirliği önceliklendirir. “Harici yetkilendirmeye ihtiyacımız var”dan “production’da politikalarımız var”a en hızlı yolu istiyorsan, Cerbos öğrenme eğrisini minimize eder.

Doğru seçim, kıyaslama rakamlarına veya dil popülaritesine değil, yetkilendirme modeline bağlıdır. Önce yetkilendirme gereksinimlerini tanımla — hangi modellere ihtiyacın var (RBAC, ABAC, ReBAC), hangi garantiler önemli (biçimsel doğrulama, reddetme önceliği) ve hangi ekosistemde çalışıyorsun (AWS, Kubernetes, çoklu bulut). Sonra bu gereksinimlere uyan dili seç.

Platform seçimi ve mimari kalıpların daha geniş bir görünümü için bu serinin ana yazısına bakabilirsin.

Kaynaklar

• Cedar Policy Language Documentation - Resmi Cedar dil referansı, gramer spesifikasyonu ve politika yazma rehberleri
• Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization - Cedar’ın tasarımı, biçimsel doğrulama yaklaşımı ve kıyaslamalar üzerine Amazon Science makalesi
• Open Policy Agent Documentation - OPA resmi dokümantasyonu, Rego dil referansı ve politika testi rehberleri
• OpenFGA Documentation - OpenFGA modelleme dili referansı, koşullar ve entegrasyon rehberleri
• OpenFGA Conditions - OpenFGA schema 1.1+‘da CEL tabanlı koşullar
• Cerbos Documentation - Cerbos politika yazımı, türetilmiş roller ve test framework’ü dokümantasyonu
• Cerbos Derived Roles - Dinamik rol hesaplama için Cerbos türetilmiş roller rehberi
• Teleport - Security Benchmarking Authorization Policy Engines - Rego, Cedar, OpenFGA ve Teleport ACD kıyaslayan SPEF framework’ü
• Permit.io - Policy Engine Showdown: OPA vs. OpenFGA vs. Cedar - Politika motoru söz dizimi, performans ve kullanım durumlarının karşılaştırmalı analizi
• Oso - OPA vs Cedar vs Zanzibar: Policy Engine Guide - Büyük politika motoru yaklaşımları arasında paradigma karşılaştırması
• Cloud Native Now - Apple Buys Styra Brains, OPA Remains Open - Styra işe alımı sonrası OPA ekosistemi geçişinin kapsamı
• AuthZed SpiceDB GitHub Repository - SpiceDB şema dili referansı ve Zanzibar uygulama detayları