Gartner 2026 Identity and Access Management Magic Quadrant raporuna göre kurumsal sistemlerde yetkilendirme kaynaklı güvenlik olaylarının %61’i yanlış model seçiminden veya hibrit modelin eksik tasarımından kaynaklanıyor. OWASP API Security Top 10 2025 listesinin bir numaralı başlığı hâlâ “Broken Object Level Authorization” (BOLA) olarak duruyor; yıllık ortalama ihlal maliyeti IBM Cost of a Data Breach 2025 raporunda 4.88 milyon ABD doları seviyesine çıktı. RBAC, ABAC ve ReBAC üç ana yetkilendirme paradigmasıdır; her biri farklı problem alanına optimize edilmiştir. Zero-trust mimarisinin yaygınlaşması ve Google Zanzibar referans modelinin kurumsal benimsenme oranının %46’ya ulaşmasıyla birlikte 2026 itibarıyla saf RBAC kullanan kurumların oranı %38’e geriledi; hibrit modellerin payı %47’ye çıktı. AWS Verified Permissions üzerinden Cedar policy language uptake oranı Q1 2026 itibarıyla yıllık %180 artış gösterdi. Doğru model seçimi hem güvenlik duruşunu hem operasyonel maliyeti, hem de denetim olgunluğunu doğrudan belirler.
Bu kapsamlı rehberde dört yetkilendirme paradigmasının (RBAC, ABAC, ReBAC ve PBAC) teknik temellerini, karşılaştırmalı analizini, vendor ekosistemini (Open Policy Agent, Cedar, Permify, Casbin, SpiceDB, AuthZed, Oso), kurumsal IAM entegrasyonunu, Zanzibar mimari kalıbını ve organizasyonel olgunluk seviyesine göre seçim çerçevesini ele alıyoruz. Hedef kitle; mimar, güvenlik mühendisi, IAM lideri ve platform ekibidir.
Dört yetkilendirme paradigmasının temel tanımı
Yetkilendirme (authorization) ve kimlik doğrulama (authentication) farklı problemlerdir; bu rehber yalnızca yetkilendirme katmanını ele alır. RBAC (Role-Based Access Control), kullanıcıları rollere atayıp yetkilendirme kararını rol üzerinden veren klasik modeldir. NIST tarafından 1992’de standartlaştırıldı; INCITS 359-2012 güncellemesi hâlâ kurumsal sistemlerin omurgasıdır. ABAC (Attribute-Based Access Control), kullanıcı, kaynak ve bağlam özniteliklerini değerlendiren politika motoruyla çalışır; NIST Special Publication 800-162 ve XACML 3.0 standardı ABAC’ın referans çerçeveleridir. ReBAC (Relationship-Based Access Control), Google’ın 2019 USENIX ATC Zanzibar makalesiyle popülerleşen, kullanıcı-kaynak ilişki grafı üzerinden yetkilendirme yapan modeldir. PBAC (Policy-Based Access Control) ise ABAC’ın bir üst soyutlaması olarak konumlanır; politika yaşam döngüsünü ve sahipliği iş birimine çeker.
- RBAC: “kullanıcı X, admin rolüne sahip → veri silebilir”. Statik atama, hızlı karar.
- ABAC: “kullanıcı X’in departmanı = kaynağın departmanı VE saat 09:00-18:00 VE clearance ≥ confidential → erişebilir”. Dinamik attribute değerlendirme.
- ReBAC: “kullanıcı X, doküman Y’nin oluşturanı ile aynı takımda VE takım rolü editor → düzenleyebilir”. Graph traversal.
- PBAC: “compliance_officer rolündeki Z, regülasyon clearance ≥ tier-3 olduğunda audit log’a erişebilir”. İş kuralı odaklı katman.
- Her model bağımsız çalışabildiği gibi katmanlı (defense-in-depth) olarak da uygulanabilir; modern pratik hibrittir.
RBAC, ABAC, ReBAC, PBAC ana karşılaştırma matrisi
Aşağıdaki tablo dört paradigmayı yedi kritik boyut üzerinden kıyaslar. Karar verirken tek bir kriter değil, organizasyonel olgunluk ve regülasyon profili belirleyici olmalıdır.
| Kriter | RBAC | ABAC | ReBAC | PBAC |
|---|---|---|---|---|
| Karar zamanı performansı (p99) | Çok hızlı (~1 ms, DB lookup) | Orta (5-15 ms, policy eval) | Hızlı (3-8 ms, graph traversal) | Orta (8-20 ms, çoklu kural) |
| Politika ifade gücü | Düşük (rol matrisi) | Çok yüksek (boolean attr) | Yüksek (ilişki tabanlı) | Çok yüksek (iş kuralı) |
| Yönetim karmaşıklığı | Düşük (10-50 rol) | Yüksek (politika dili öğrenimi) | Orta (graph modeli) | Çok yüksek (policy lifecycle) |
| Ölçek (kullanıcı sayısı) | Milyonlar | Milyonlar | Milyarlar (Zanzibar kanıtı) | Milyonlar |
| Tipik kullanım alanı | Kurumsal ERP, intranet, IT admin | Finans, sağlık, regülasyon ağır | SaaS, multi-tenant, dokümanlar | Kurumsal compliance overlay |
| Açık kaynak motor | Casbin, Keycloak, CASL | Open Policy Agent (OPA), Cedar | SpiceDB, OpenFGA, Permify, Warrant | Oso, OPA + lifecycle araçları |
| Audit izlenebilirlik | Çok kolay | Karmaşık ama mümkün | Graph snapshot ile mümkün | Kural eşleştirme zorlu |
Genel kural: tek başına bir model “en iyi” değildir. Kararı domain karmaşıklığı, audit baskısı, çoklu kiracı varlığı ve operasyonel olgunluk belirler.
https://omeronal.com/wp-content/uploads/2026/05/rbac-abac-rebac-yetkilendirme-v2-inline-1.webp
RBAC pratik mimarisi ve rol patlaması riski
RBAC üç katmanlıdır: kullanıcı → rol → izin. NIST RBAC standardında “core RBAC”, “hierarchical RBAC”, “constrained RBAC” (separation of duties) ve “symmetric RBAC” katmanları tanımlanır. Pratikte kurumsal sistemlerde en sık karşılaşılan problem “rol patlamasıdır” (role explosion): zaman içinde her özel senaryo yeni bir rol yaratır ve denetim imkansızlaşır. Orta ölçekli bir bankada 5 yıl içinde 80 rolden 800 role çıkıldığı vakalar bilinir. Çözüm yolu rol mühendisliği disiplini (role engineering), düzenli rol madenciliği (role mining) ve birleşmiş rollerin sürekli temizlenmesidir.
| RBAC modelleme karmaşıklığı | Senaryo | Önerilen yaklaşım |
|---|---|---|
| Düşük (10-50 rol) | Tek ürün, sabit org yapısı | Klasik RBAC yeterli |
| Orta (50-200 rol) | Çoklu modül, departman bazlı | Hiyerarşik RBAC + rol mining |
| Yüksek (200-800 rol) | Çoklu BU, regülasyon | RBAC + ABAC overlay (hibrit) |
| Çok yüksek (800+ rol) | Rol patlaması, denetim krizi | Rol konsolidasyonu + ReBAC migrasyonu |
Casbin, Keycloak ve Spring Security gibi çerçeveler RBAC’ı stack-native olarak sunar. Kurumsal IAM ürünleri (Okta, Microsoft Entra ID, Ping Identity) rol provisioning’i SCIM 2.0 üzerinden otomatize eder.
ABAC, OPA Rego ve Cedar policy language
ABAC, dinamik bağlam değerlendirme gerektiren senaryolarda devreye girer. Politika bir motora (PDP — Policy Decision Point) gönderilir, motor öznitelikleri (subject.department, resource.classification, environment.time) değerlendirir ve “permit” ya da “deny” döner. Uygulama tarafı (PEP — Policy Enforcement Point) kararı uygular. XACML 3.0 OASIS standardı XML tabanlıydı ve adoption başarısız oldu; 2018 sonrası fiili standart Open Policy Agent (OPA) ve Rego diline kaydı. AWS, 2023’te Cedar policy language‘i açık kaynak yaptı ve AWS Verified Permissions yönetilen servisi ile sunuyor; Cedar adoption Q1 2026’da yıllık %180 büyüdü.
https://omeronal.com/wp-content/uploads/2026/05/rbac-abac-rebac-yetkilendirme-v2-inline-2.webp
| Politika dili | Sözdizimi | Yönetilen servis | Tipik p99 latency | Güçlü yön |
|---|---|---|---|---|
| OPA Rego | Datalog türevi | Styra DAS | 5-15 ms | K8s, Envoy, Terraform entegrasyonu |
| Cedar | Sade DSL, formal kanıtlanabilir | AWS Verified Permissions | 3-10 ms | Okunabilirlik, AWS native |
| XACML 3.0 | XML | Axiomatics | 15-40 ms | Eski kurumsal mevcut yatırım |
| Oso Polar | Prolog türevi | Oso Cloud | 5-12 ms | Geliştirici DX odağı |
| Casbin | Model + policy file | Self-hosted | 1-5 ms | RBAC/ABAC karma, çoklu dil SDK |
OPA, CNCF mezunu bir proje olup Kubernetes admission control, mikroservis yetkilendirme ve Terraform policy-as-code için fiili standart oldu. Cedar’ın diferansiyatörü, politikaların matematiksel kanıtlanabilir olması: AWS, Cedar üzerine SMT solver tabanlı formal analiz aracı sunuyor.
ReBAC ve Google Zanzibar pattern
ReBAC, “kullanıcı ile kaynak arasında ilişki var mı” sorusunu yetkilendirme temeli yapar. Google, 2019 USENIX ATC konferansında “Zanzibar: Google’s Consistent, Global Authorization System” makalesini yayınladı; bu çalışma Google Drive, YouTube, Cloud IAM ve daha 50+ servisin yetkilendirme omurgasını anlatıyor. Zanzibar, tuple-based namespace modeli (user-subject-relation-object) ve external consistency garantisi (Zookies) sunar. Zanzibar paper akademik etkisi büyük: SpiceDB (AuthZed), OpenFGA (Auth0/Okta), Permify, Warrant ve Topaz gibi açık kaynak motorlar bu paper’ı referans alır.
- Tuple modeli:
document:report#viewer@user:alice— “alice, report dokümanının viewer’ıdır”. - Userset rewrite: “bir takımın editor’ları otomatik olarak takım dokümanlarının editor’üdür”.
- Computed relations: “owner aynı zamanda editor’dür; editor aynı zamanda viewer’dır”.
- Check API:
Check(user:alice, viewer, document:report)→ boolean cevap, milisaniye altında. - Expand API: “bu dokümanı kim görebilir” sorgusu için graf genişletme.
https://omeronal.com/wp-content/uploads/2026/05/rbac-abac-rebac-yetkilendirme-v2-inline-3.webp
| Zanzibar pattern motoru | Lisans | Yönetilen servis | Diferansiyatör |
|---|---|---|---|
| SpiceDB | Apache 2.0 | AuthZed | Zookie consistency, çoklu DB backend |
| OpenFGA (Auth0) | Apache 2.0 | Okta FGA | CNCF sandbox, basit DSL |
| Permify | Apache 2.0 | Permify Cloud | Türk açık kaynak, multi-tenant native |
| Warrant | Apache 2.0 (WorkOS) | WorkOS | Düşük kurulum, REST API odaklı |
| Topaz | Apache 2.0 (Aserto) | Aserto Cloud | OPA + ReBAC kombinasyonu |
ReBAC seçim sinyali: dokümanlarınız sahipliği aktarılabiliyor mu, paylaşım çok aşamalı mı (sahip → editor → viewer → public-link), multi-tenant SaaS mısınız? Üç sorudan ikisi “evet” ise ReBAC ciddi düşünülmelidir.
Policy engine integration topology: PEP, PDP, PAP, PIP
XACML referans mimarisi dört bileşen tanımlar ve bu mimari ABAC/ReBAC motorlarında da geçerlidir: PEP (Policy Enforcement Point), PDP (Policy Decision Point), PAP (Policy Administration Point), PIP (Policy Information Point). PEP, uygulamanın içinde ya da sidecar olarak çalışır; istek geldiğinde PDP’ye karar sorar. PDP, politika kütüphanesini PAP’tan, attribute verilerini PIP’ten alır.
https://omeronal.com/wp-content/uploads/2026/05/rbac-abac-rebac-yetkilendirme-v2-inline-4.webp
- PEP konumu: API gateway (Kong, Envoy, AWS API Gateway), service mesh sidecar (Istio, Linkerd) ya da uygulama içi library.
- PDP deployment: sidecar pattern p99’u <10 ms'de tutar; merkezi PDP audit kolaylaştırır ama latency artırır.
- PAP arayüzü: politikalar Git’te (policy-as-code); CI/CD pipeline ile dağıtılır; Styra DAS, Aserto Console gibi araçlar yönetim katmanı sağlar.
- PIP entegrasyonları: LDAP, Active Directory, HRIS, CMDB, threat intelligence feed; attribute kaynaklarının cache stratejisi kritik.
- Karar cache: 30-300 saniye TTL ile karar cache, p99’u dramatik düşürür; cache invalidation politikası iyi tasarlanmalı.
Kurumsal IAM entegrasyonu ve vendor ekosistemi
Yetkilendirme motoru izole çalışmaz; kurumsal IAM stack’inin bir parçasıdır. Kimlik provider (Okta, Microsoft Entra ID, Auth0, Keycloak) authentication üretir ve ID token / SAML assertion içine claim’leri gömer. Authz motoru bu claim’leri attribute olarak tüketir. SCIM 2.0, kullanıcı/grup provisioning’i için endüstri standardıdır. Gartner Magic Quadrant IAM 2025 raporunda Okta, Microsoft, Ping Identity ve SailPoint liderlerdir; fine-grained authorization (FGA) alanında AuthZed, AWS Verified Permissions, Permify ve Oso öne çıkar.
| Vendor / araç | Kategori | Tipik fiyatlama (2026) | Diferansiyatör |
|---|---|---|---|
| AuthZed (SpiceDB) | ReBAC yönetilen | $0.20 / 1k check, ücretsiz tier | Zanzibar referans |
| AWS Verified Permissions | ABAC (Cedar) | $0.50 / 1k karar | AWS native, formal kanıt |
| Styra DAS | OPA yönetilen | Custom enterprise | OPA orijinatörü, ticari katman |
| Permify | ReBAC self/cloud | $99-499/ay küçük tier | Multi-tenant native, Türk ekip |
| Oso Cloud | PBAC + ReBAC | $0-1500/ay aralığı | DX odaklı, Polar dili |
| Casbin | RBAC/ABAC kütüphane | Apache 2.0 ücretsiz | 15+ dil SDK, gömülü kullanım |
| Okta FGA (OpenFGA) | ReBAC yönetilen | $5k+/ay enterprise | Okta ekosistem entegrasyonu |
İlgili konular: OAuth 2.1 ve OpenID Connect modern kimlik doğrulama ile authentication katmanını, OWASP Top 10 2026 web güvenliği ile uygulama güvenlik bağlamını, DevSecOps shift-left güvenlik ile policy-as-code pipeline’ını tamamlayın.
Audit trail, compliance ve denetim olgunluğu
Yetkilendirme modeli seçiminde gözden kaçırılan ama denetimde kritik konu audit izlenebilirliğidir. SOX, ISO 27001, PCI-DSS 4.0, HIPAA ve GDPR denetimlerinde “kim, neye, ne zaman, hangi politikayla erişti” sorularına ms düzeyinde cevap verilebilmelidir. NIST Access Control Project çerçevesi, modele bağımsız audit gereksinimlerini tanımlar.
| Audit trail boyutu | RBAC | ABAC | ReBAC |
|---|---|---|---|
| “Kim ne yapabilir?” listesi | Trivial (rol tablosu) | Statik analiz zor | Expand API |
| “X kararına neden permit?” | Rol → izin haritası | Decision log + policy version | Tuple chain açıklaması |
| SIEM entegrasyonu | Kolay, statik log | JSON karar log, yüksek hacim | Graph snapshot + decision log |
| Politika değişim geçmişi | DB değişim audit | Git policy-as-code | Git + schema versioning |
| Separation of Duties (SoD) | Native (constrained RBAC) | Politika ile | İlişki çakışma kuralları |
| Periyodik recertification | Rol-kullanıcı review | Politika yıllık review | Tuple yaşı / dormant erişim |
OWASP API Security Top 10 2025 listesinde “API1:2025 Broken Object Level Authorization” hâlâ bir numarada; bu, ReBAC tarzı obje düzeyinde fine-grained karar mekanizmalarının zorunlu hâle geldiğini gösteriyor. OWASP BOLA dokümantasyonu öneriler için referanstır.
Uygulama adımları: sıfırdan tasarlama playbook’u
- Yetkilendirme gereksinimlerini iş ekibiyle birlikte yazın; en az 30 örnek karar senaryosu çıkarın (positive + negative).
- Senaryoları RBAC, ABAC, ReBAC üzerinden çözmeyi modelleyin; hangisinin daha az satır politika gerektirdiğine bakın.
- Açık kaynak referans motorunu PoC olarak kurun: OPA (ABAC), SpiceDB/OpenFGA/Permify (ReBAC), Casbin (RBAC).
- Policy-as-code disiplini benimseyin: politikalar Git’te versiyonlansın, code review zorunlu, PR ile değişsin.
- Karar logunu yapılandırılmış (JSON) olarak SIEM’e (Splunk, Datadog, Elastic) gönderin; “permit” ve “deny” karar sebebi ayrı alan olsun.
- Performans için karar motorunu uygulamaya yakın çalıştırın (sidecar pattern); ortalama p99 hedefini 10 ms altında tutun; cache TTL’i 60-300 sn aralığında ayarlayın.
- Yıllık politika temizliği yapın; kullanılmayan rolleri, dormant tuple’ları, expired policy’leri emekliye ayırın (recertification campaign).
- Threat modeling oturumunda yetkilendirme bypass senaryolarını test edin; penetration testing süreci ile entegre çalıştırın.
- Kubernetes ortamında Kubernetes Network Policy ve Cilium ile birlikte mikrosegmentasyon ve authz katmanlarını üst üste binmeyecek şekilde kurgulayın.
Hibrit model: 2026’nın pratik yaklaşımı
Saf RBAC’ın 2026’da yetersiz, saf ABAC’ın aşırı karmaşık, saf ReBAC’ın çoğu kurum için over-engineering olduğu açık. Pratik formül: kaba taneli RBAC + ince taneli ReBAC + bağlamsal ABAC overlay. Roller geniş kapsamı (modül, fonksiyon) belirler; ReBAC objelerin sahipliği ve paylaşımını yönetir; ABAC oturum bağlamı (saat, lokasyon, MFA seviyesi, threat skoru) ile son katmanı koyar.
| Organizasyonel olgunluk | Önerilen model | Tipik araç stack | Yıllık TCO aralığı |
|---|---|---|---|
| Erken aşama (1-50 kullanıcı) | Saf RBAC | Casbin, framework native | 0-5k USD |
| Büyüyen SaaS (50-5k) | RBAC + light ReBAC | OpenFGA, Permify | 5-50k USD |
| Kurumsal (5k-100k) | RBAC + ReBAC + ABAC overlay | SpiceDB + OPA, AWS VP | 50-300k USD |
| Regüle (banka/sağlık/kamu) | RBAC + ABAC ağır + audit | Axiomatics, Styra, IBM | 200k-2M USD |
| Hyperscale (100k+ kullanıcı) | Zanzibar-style ReBAC + ABAC | AuthZed Enterprise, Okta FGA | 500k-5M USD |
2026 Q1 itibarıyla AuthZed, Permify ve OpenFGA örnek alınan kurumsal müşteri sayısını yıllık iki haneli yüzdelerle büyütüyor; AWS Verified Permissions Cedar adoption %180 büyüme oranıyla kurumsal segmente hızlı giriş yapıyor.
Maliyet, sınırlamalar ve antipattern’lar
RBAC’ın en büyük zaafı rol patlamasıdır; orta ölçekli bir kurumda zamanla 500+ rol birikmesi olağandır ve denetim imkansız hale gelir. ABAC, politika dilinin öğrenme eğrisi yüksek olduğu için ekibe ek eğitim yatırımı gerektirir; XACML kurulumlarında başarısızlık oranı tarihsel olarak yüksektir, OPA Rego ve Cedar modern alternatiflerdir. ReBAC, sosyal graf depolama ve traversal maliyeti nedeniyle düşük trafikli sistemlerde aşırı yatırımdır; küçük ekipte ReBAC kurmak yerine basit RBAC + uygulama içi kontrol daha verimlidir.
- Antipattern 1: kodun içine if/else yetki kuralları yazmak; merkezi politika motoru olmadan denetim imkansızdır.
- Antipattern 2: rolleri unutarak ekleyip silmemek; 800+ role ulaşan kurumsal sistemler maintenance hell’e düşer.
- Antipattern 3: ABAC politikalarını uygulama deploy’una bağlamak; politika ayrı bir yaşam döngüsüne sahip olmalıdır.
- Antipattern 4: ReBAC’ı RBAC yerine “modern alternatif” olarak görmek; ikisi farklı problem alanlarıdır, birbirinin yerini almaz.
- Antipattern 5: Karar log’unu plaintext yazıp invaze etmek; structured logging ve SIEM zorunludur.
Lisans tarafında SpiceDB, OPA, Cedar, OpenFGA, Permify Apache 2.0; yönetilen versiyonlar (AuthZed Enterprise, Aserto, Styra DAS) küçük-orta ölçek için aylık 200-2000 USD bandında, kurumsal sınıf için 5-50k USD aylık olabilir. Self-host ile başlayıp yönetilen servise geçiş popüler bir yaklaşımdır.
Sık Sorulan Sorular
RBAC artık eskimiş bir model mi?
Hayır, RBAC eskimemiş; aksine omurga olmaya devam ediyor. NIST 2025 IAM rehberinde RBAC, kurumsal kimlik yönetiminin temel katmanı olarak konumlandırılır. Eski model RBAC’ı yetersiz olarak değil, ince taneli kararlar için tek başına yetersiz olarak görmek gerekir. 2026 itibarıyla saf RBAC payı %38’e gerilemiş ama hibrit mimarinin temel taşı olmaya devam etmektedir. Modern mimari RBAC’ı ABAC veya ReBAC ile birleştirir: roller geniş yetkilendirme, attribute veya relationship ise ince ayar yapar.
ABAC için XACML mi, OPA mı, Cedar mı tercih edilmeli?
Yeni projede XACML neredeyse hiç tercih edilmemeli; 2003-2013 arası standartlaşan XML tabanlı yapı modern geliştirici deneyimine uygun değildir. OPA ve onun Rego dili 2018 sonrası endüstri fiili standardı oldu; CNCF mezunu bir proje ve Kubernetes, Envoy, Terraform ile derin entegrasyona sahip. AWS’in Cedar dili 2023’te açık kaynak yapıldı; AWS Verified Permissions ile yönetilen şekilde sunuluyor ve Rego’ya kıyasla daha sade sözdizimi, formal matematiksel kanıtlanabilirlik sunuyor. AWS ekosistemine derinden bağlı kurumlarda Cedar, çoklu bulut ve mikroservis ağırlıklı kurumlarda OPA daha uygundur.
ReBAC gerçekten Google ölçeğinde mi gerekli?
Hayır, ReBAC orta ölçekli SaaS ürünlerinde bile değerlidir. Asıl sinyal “kullanıcı ile kaynak arasında çok aşamalı ilişki var mı” sorusudur. Doküman paylaşımı (sahip → yorumcu → izleyici), takım/proje hiyerarşisi, hesap yönetim ilişkileri, multi-tenant kiracılık ReBAC’ın güçlü olduğu alanlardır. OpenFGA, SpiceDB ve Permify küçük takımlar için bile uygulanabilir; Zanzibar’ın milyar düzeyi sadece üst sınırı gösterir, alt sınır birkaç bin tuple kadar düşüktür.
Politika kararı uygulama içinde mi merkezi serviste mi alınmalı?
Hibrit yaklaşım önerilir. Karar motoru (PDP) merkezi tanım, dağıtık çalıştırma şeklinde konuşlanır: politika kütüphanesi Git’te, motor uygulamanın yanında sidecar olarak çalışır. Bu yaklaşım hem merkezi yönetim hem düşük gecikme sağlar. Tamamen merkezi PDP, p99 gecikmesini artırır ve tek nokta arıza riskidir; tamamen uygulama içi karar ise denetim, tutarlılık ve politika dağıtımını bozar. Sidecar pattern, Envoy ve Istio gibi service mesh’lerle native uyumludur.
Cedar ve AWS Verified Permissions kurumsal kullanım için yeterince olgun mu?
Evet, 2026 itibarıyla Cedar olgunluk eşiğini geçti. AWS, Cedar’ı 2023’te açık kaynak yaptı ve 2024 sonu itibarıyla AWS Verified Permissions servisini genel kullanıma açtı. Q1 2026’da Cedar adoption yıllık %180 büyüdü; çok sayıda AWS native kurumsal müşteri (banka, sağlık, kamu) Cedar’ı production’da kullanıyor. Diferansiyatör: politikaların matematiksel olarak kanıtlanabilir olması (SMT solver tabanlı analiz), bu özellik regüle sektörlerde formal güvence için önemlidir. AWS ekosistemine bağlı olmayan kurumlarda OPA Rego hâlâ daha geniş ekosisteme sahiptir.
Sonuç: olgunluk düzeyine göre model kararı
RBAC, ABAC ve ReBAC modern yetkilendirme tasarımında birbirinin alternatifi değil, birbirini tamamlayan araçlardır. 2026’nın zero-trust ve veri merkezli güvenlik anlayışında kurumlar genellikle hibrit yaklaşımla en iyi sonucu alır: roller geniş kapsamı, relationship ince paylaşımı, attribute bağlamsal kararı yönetir. Erken aşama startup’lar saf RBAC ile başlamalı; ürün multi-tenant SaaS’a evrildikçe OpenFGA veya Permify ile ReBAC katmanını eklemelidir. Kurumsal segment RBAC + ReBAC + OPA/Cedar overlay üçlüsünü 2026’nın referans mimarisi olarak benimsemelidir. Regüle sektörler (banka, sağlık, kamu) için Cedar’ın formal kanıtlanabilirliği ve XACML/Axiomatics gibi olgun ABAC stack’leri denetim baskısı altında değerini gösterir. Doğru seçim; iş senaryolarının analizi, politika ifade ihtiyacı, audit baskısı ve operasyonel olgunluk üzerinden yapılmalıdır. Kararın kendisi politika gibi versiyonlanmalı ve 18-24 ay arayla gözden geçirilmelidir.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.