1. GİRİŞ

Erişim kontrolü (authorization) sistemlerinin tasarımı güvenlik, uyumluluk ve operasyonel verimliliğin temelidir. İki popüler model—Rol Tabanlı Erişim Kontrol (RBAC) ve Attribute‑Based Access Control (ABAC)—genellikle birbirleriyle kıyaslanır. Her iki yaklaşımın da güçlü ve zayıf yönleri vardır; doğru seçimi yapmak, organizasyonun büyüklüğü, uyumluluk gereksinimleri, uygulama karmaşıklığı ve operasyonel yetkinliklerle yakından ilişkilidir.

Bu konu neden bugün önemli?

• Mikroservisler, SaaS ve çok kiracılı uygulamalar erişim kararlarını daha dinamik hâle getiriyor—basit roller çoğu zaman yetersiz kalıyor.
• Regülasyonlar ve audit gereksinimleri (ör. GDPR, PCI, HIPAA) erişim denetimini detaylı şekilde belgelemeyi zorunlu kılıyor.
• Bulut‑native altyapılarda policy as code, merkezi policy engine ve runtime kararları entegrasyonu artıyor—bu da model seçimini stratejik hâle getiriyor.

Kimler için önemli?

• Güvenlik mühendisleri, platform ve IAM ekipleri
• Yazılım mimarları ve SRE
• SaaS ürün takımları, kurumsal BT ve uyumluluk sorumluları

Hangi problemleri çözüyor?

• Hangi principal'in hangi kaynağa hangi şartlarda erişebileceğini belirleme
• Least privilege (en az yetki) prensibini yönetilebilir hale getirme
• Policy yönetimi, auditability ve değişim kontrolü sağlama

2. KAVRAMSAL TEMELLER

2.1 RBAC — Temel tanım

Rol Tabanlı Erişim Kontrol (RBAC) modelinde izinler roller (role) üzerine atanır; kullanıcılar veya servisler bu rollere atanarak dolaylı yoldan izin kazanır. RBAC; basit, anlaşılır, işletmeye uygun ve yönetilebilir olması nedeniyle kurumsal ortamlarda yaygın bir ilk tercihtir.

2.2 ABAC — Temel tanım

Attribute‑Based Access Control (ABAC) kararları attribute'lar (özellikler) üzerinden verir: principal attribute'ları (ör. departman, seniority), resource attribute'ları (ör. ownerId, sensitivity), action ve environmental/context attribute'ları (time, IP, device posture). ABAC, dinamik ve bağlam tabanlı politikalarla çok daha ince‑tane kontrol sağlar.

2.3 İkisi arasındaki temel fark

RBAC basitleştirilmiş bir eşleştirme sunar: "kullanıcı A rol R'ye sahipse izin verir". ABAC ise kararları attribute'ların kombinasyonuna göre değerlendirir: "kullanıcının department=finance ve resource.sensitivity=low ve requestTime within business hours ise izin ver" gibi. Dolayısıyla RBAC deterministik ve daha az kural gerektirirken, ABAC daha esnek fakat daha karmaşıktır.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 RBAC mimarisi

RBAC genelde üç ana tabana dayanır: kullanıcı ↔ rol ilişki tablosu, rol ↔ izin map'i ve kaynak tanımları. Authorization flow şu şekilde işler: kullanıcı kimlik doğrulandıktan sonra rol kümeleri belirlenir, istek geldiğinde ilgili rolün izinleri kontrol edilir. RBAC uygulaması hem uygulama içinde statik yetki kontrolleri şeklinde (middleware) hem de merkezi IAM çözümlerinde (AD/LDAP, Keycloak) uygulanabilir.

3.2 ABAC mimarisi

ABAC'te policy engine (ör. OPA — Open Policy Agent) principal, resource ve environment attribute'larını alır, bu attribute'lara dayalı policy'leri (Rego, CEL vb.) değerlendirir. Data flow: istek → enforcer → PDP (policy decision point) sorgusu → PIP (policy information point) attribute'ları sağlar → PDP karar verir → enforcer uygulama yapar. ABAC tipik olarak merkezi PDP/PAP mimarisi ile birlikte kullanılır.

3.3 Token ve claim tabanlı kombinasyonlar

Birçok sistem hibrit yaklaşım kullanır: RBAC rol bilgilerini token claim'lerinde taşırken, ABAC talepler için ekstra context attribute'larını PIP'ten alır. Örneğin JWT içinde roles claim'leri bulunur ve PDP gerektiğinde ekstra attribute'ları sorgular. Bu hibrit yapı, performans ve esneklik arasında denge sağlar.

3.4 Performans, cache ve offline değerlendirme

RBAC genelde hızlıdır—rol eşleştirmesi lokal cache veya DB sorgusuyla hızlı şekilde yapılır. ABAC ise attribute toplanması ve policy evaluation nedeniyle ek gecikme getirebilir. Performansı iyileştirmek için decision caching, policy precompilation ve edge/local policy enforcement (wasm, rego wasm) yaygın stratejilerdir. Ayrıca offline ya da disconnected senaryolar için capability‑based token'lar tercih edilebilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Kurumsal ERP/HR — RBAC önceliği

Birçok kurumsal ERP ve HR uygulaması RBAC ile başlar: belirli rollere (HR Admin, Payroll Processor, Manager) göre yetkiler tanımlanır. Bu model audit ve uyumluluk için yeterli olur; organizasyon yapısına paralel rol hiyerarşileriyle yönetim kolaylaşır.

4.2 Finans ve regüle sektör — ABAC gereksinimi

Bankacılık ve finans gibi alanlarda transaction context, amount thresholds, two‑step approval ve separation of duties gereksinimleri vardır. ABAC, transaction amount, initiator role, time of day ve device posture gibi attribute'ları bir araya getirip dinamik kararlar almayı sağlar.

4.3 SaaS — Hibrit ve tenant‑aware modeller

SaaS platformları genelde başlangıçta RBAC ile başlar; müşteriler büyüdükçe tenant‑specific role mapping veya PBAC talepleri ortaya çıkar. Önemli SaaS sağlayıcıları genelde RBAC'ı baseline olarak sunarken, büyük müşteriler için ABAC veya policy as code entegrasyonları teklif eder.

4.4 Cloud platformları ve servis mesh'ler

Büyük bulut sağlayıcıları ve servis mesh'ler (Istio, AWS IAM) attribute‑based karar mekanizmalarını destekler. Örneğin IAM policy'leri çoğunlukla attribute tabanlı (resource tags, request context) kurallarla çalışır—bu da ABAC'e benzeyen davranış sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

RBAC Avantajları

• Basit, hızlı uygulanır ve anlaşılır.
• İş birimleri için yönetilebilir; organizasyonel rollere doğrudan bağlanır.
• Audit ve raporlama daha sade; rol değişiklikleri izlenebilir.

RBAC Dezavantajları

• Contextual veya dinamik kararlar için sınırlı esneklik.
• Rol explosion: çok özel durumlar için çok fazla rol gerekebilir, yönetim maliyeti artar.
• Multitenancy ve tenant‑specific policy'lerde her tenant için rol tasarımına ihtiyaç doğabilir.

ABAC Avantajları

• Çok daha esnek, bağlam‑duyarlı ve dinamik politikalar tanımlamaya uygundur.
• Policy reuse ve composability—aynı policy farklı kombinasyonlarda çalışabilir.
• Tenant, device, risk ve zaman bazlı kuralları aynı çatı altında yönetebilir.

ABAC Dezavantajları

• Policy kompleksitesi: politikaların yazılması, test edilmesi ve yorumlanması zordur.
• Operasyonel yük: PIP'ler, attribute store ve PDP yönetimi gerektirir.
• Performans maliyeti: gerçek zamanlı attribute toplama ve değerlendirme gecikmelere sebep olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Başlangıçta RBAC ile MVP'ye başlayın; iş gereksinimleri arttıkça ABAC/PBAC özelliklerini ekleyin.
• Policy as code prensibini benimseyin—policy'leri versiyonla, test et ve CI/CD süreçlerine dahil et.
• Decision caching ve lokal enforcement ile PDP çağrılarını minimize edin; cache invalidation stratejileri tanımlayın.

Performans optimizasyonu

• Hot‑path policy'leri optimize edip precompile edin; kritik kuralları daha hızlı değerlendirecek yollar sağlayın.
• Attribute store'ları için düşük latanslı cache katmanları (Redis gibi) kullanın.
• Gateway veya sidecar seviyesinde ön doğrulamalar yaparak downstream servisleri hafifletin.

Güvenlik ve operasyon

• Change management: policy değişikliklerini canary ile deploy edin ve etkilerini izleyin.
• Explainability: her izin/ret kararı için "neden" bilgisini loglayın (hangi attribute, hangi rule).
• Revocation ve emergency kill switch: hatalı policy veya ihlal durumunda hızlı geri alma mekanizmaları oluşturun.

8. SIK YAPILAN HATALAR

• Erken aşamada ABAC'e atlamak—gereksiz kompleksite ve maliyet yaratır.
• Policy'leri dokümante etmemek—iyi bir policy catalog ve changelog olmadan yönetim kaosa dönüşür.
• Cache invalidation stratejisini ihmal etmek—yeni policy'ler uygulansa da eski kararlar geçerli kalabilir.
• Explainability'i ihmal etmek—audit taleplerinde, hata analizinde kararların nedenini bulmak zorlaşır.

9. GELECEK TRENDLER

1. AI‑assisted policy generation: Telemetry ve usage verilerinden otomatik policy önerileri ve optimizasyon araçları yükselecek.
2. Risk‑based ve adaptive authorization: Gerçek‑zamanlı risk skorları (behavioral, device posture) politikaları dinamik olarak etkileyip access kararlarını şekillendirecek.
3. Standardized policy formats: Rego, CEL gibi dillerin olgunlaşmasıyla birlikte interoperable policy paketleri yaygınlaşacak.
4. Edge/wasm based local enforcement: Policy evaluation'ın yanıt süresini azaltmak için wasm tabanlı local evaluation stratejileri artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. RBAC mi yoksa ABAC mi daha güvenli?

   Güvenlik doğrudan modelden ziyade nasıl uygulandığına bağlıdır. RBAC doğru yönetilirse güvenli olabilir; ABAC daha ince‑tane kontrol sunar fakat yanlış yazılmış politikalar risk oluşturabilir. Önemli olan least privilege ve iyi test edilmiş policy'dir.

2. 2. Küçük bir startup için hangi modeli önerirsiniz?

   Başlangıçta RBAC daha pratiktir—hızlı uygulama, düşük operasyonel maliyet. Zamanla ihtiyaç artarsa ABAC veya PBAC'e geçiş planlanabilir.

3. 3. ABAC'e geçiş maliyetli midir?

   Evet—attribute store, PDP/PIP altyapısı, policy yönetim tooling ve test süreçleri gerekir. Bu yüzden kademeli ve ölçümlü geçiş önerilir.

4. 4. Policy as code neden gerekli?

   Policy as code policy'leri test edilebilir, revize edilebilir, review edilebilir ve CI ile deploy edilebilir hale getirir—governance için kritik bir pratiktir.

5. 5. Decision caching ne kadar güvenli?

   Decision caching performans için gereklidir ancak TTL, invalidation ve revocation mekanizmaları dikkatle planlanmalıdır. Kritik yetkiler için kısa TTL veya no‑cache tercih edilebilir.

6. 6. ABAC politikalarını nasıl test edersiniz?

   Unit test, policy simulation (what‑if), integration test ve property‑based test'ler kullanılmalı; test dataset'leri edge case'leri içermelidir.

7. 7. Rol explosion nasıl önlenir?

   Role taxonomy ve role templating ile; iş gereksinimleri net tanımlanmalı, RBAC rolleri minimal tutulmalı ve izinler fine‑grained policy'lerle değil rol seviyesinde kontrol edilmeli.

8. 8. Open source hangi araçlar yararlıdır?

   Open Policy Agent (OPA), Rego, Casbin, Keycloak (authorization services), Envoy external authorization gibi projeler farklı ihtiyaçlara uygun çözümler sunar.

Anahtar Kavramlar

RBAC

Rol tabanlı erişim kontrol; kullanıcılar rollere atanır ve roller izinleri kapsar.

ABAC

Attribute tabanlı erişim kontrol; kararlar principal, resource ve environment attribute'larına göre verilir.

PDP / PEP

Policy Decision Point / Policy Enforcement Point—karar veren ve uygulayan bileşenler.

Policy as Code

Politikaların kod olarak versiyonlandığı ve CI/CD ile yönetildiği yaklaşım.

Decision cache

Policy evaluation sonucu cache'leyerek performansı artırma tekniği.

Öğrenme Yol Haritası

1. 0–1 ay: RBAC ve temel authorization kavramlarını öğrenin; küçük bir uygulamada RBAC implementasyonu yapın.
2. 1–3 ay: OPA/Rego veya Casbin ile basit ABAC politikaları yazın ve test edin; attribute store konseptlerini uygulayın.
3. 3–6 ay: Policy as code, decision caching, explainability ve audit logging üzerine pratik projeler geliştirin.
4. 6–12 ay: Tenant‑aware policy yönetimi, risk‑based authorization ve AI destekli policy optimizasyonu konularında deneyim kazanın.