1. GİRİŞ

Erişim kontrolü (authorization) modern yazılımlarda güvenliğin ve iş mantığının merkezindedir. Doğru authorization modeli seçimi, sadece sistemin güvenliğini etkilemez; geliştirici deneyimini, operasyonel yükü, performansı ve uyumluluğu doğrudan şekillendirir. Bulut‑native uygulamalar, mikroservisler, çok kiracılı SaaS ürünleri ve regüle sektörlerde erişim kararlarının doğruluğu ve izlenebilirliği kritik hâle gelmiştir.

Bu konu neden bugün önemli?

• Dağıtık ve mikroservis mimarileri ile erişim kararları merkezi hale getirilemediğinde tutarsızlıklar ortaya çıkar.
• Regülasyonlar (GDPR, HIPAA, PCI, finans regülasyonları) erişim denetimini ve audit izini zorunlu kılar.
• Dinamik yetkilendirme ihtiyaçları (contextual, time‑bound access) klasik sabit rollerin ötesine geçmeyi gerektirir.

Kimler için önemli?

• Yazılım mimarları ve güvenlik mühendisleri
• Platform ve SRE ekipleri
• SaaS ürün takımları, uyumluluk ve risk yönetimi ekipleri

Hangi problemleri çözüyor?

• Hangi kullanıcı/servisin hangi kaynağa hangi şartlarda erişeceğini belirleme
• Least privilege prensibini uygulama ve denetleme
• Audit, inceleme ve forensics için yeterli logging sağlama

2. KAVRAMSAL TEMELLER

2.1 Authorization nedir — net tanım

Authorization, doğrulanmış bir kimliğin (authenticated principal) belirli bir kaynağa (resource) belirli bir eylem (action) yapıp yapamayacağını belirleme sürecidir. Bu karar genelde kimlik, rol, policy, kaynak özellikleri ve çalışma zamanı bağlamına (context) dayanır.

2.2 Temel terimler

• Principal: Erişim talebinde bulunan kullanıcı, servis veya cihaz.
• Resource: Erişime tabi olan nesne: API endpoint, dosya, veri satırı vb.
• Action: Kaynak üzerinde yapılmak istenen işlem: read, write, delete, approve vb.
• Policy: Erişim kararlarını tanımlayan kurallar kümesi.
• Enforcer: Policy'leri değerlendiren ve karar veren bileşen (middleware, gateway, PDP/PIP/PDP modeli).

2.3 Yaygın authorization modelleri

• ACL (Access Control Lists): Kaynak bazlı listeleme; hangi principal'in hangi izinlere sahip olduğunu saklar.
• RBAC (Role‑Based Access Control): Kullanıcılar rollere atanır; roller izinleri kapsar.
• ABAC (Attribute‑Based Access Control): Attributelara dayalı kurallar; principal, resource ve environment attribute'ları kullanır.
• PBAC / Policy‑Based Access Control: Merkezi policy engine (ör. OPA) ile ifade edilen politikalar.
• Capability‑based: Yetkiler (capabilities) token veya capability objesi olarak taşınır.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — merkezi vs dağıtık

Authorization kararlarını uygulamada iki ana yaklaşım vardır: merkezi PDP/PAP/PIP/PEP (Policy Decision Point/Policy Administration Point/Policy Information Point/Policy Enforcement Point) mimarisi veya dağıtık enforcement (her servis kendi policy'sini uygular). Merkezi modelde kararlar merkezi bir PDP tarafından verilirken enforcer'lar kararları sorgular. Dağıtık modelde enforcer'lar cache'li policy veya token tabanlı yetkilerle çalışır.

3.2 Veri akışı ve çalışma mantığı

1. Principal kimlik doğrulanır (authentication).
2. Enforcer, request metadata (principal, resource id, action, context) ile PDP'ye policy decision request (PDR) gönderir.
3. PDP, PIP'den (attribute store) ek bilgiler alarak policy evaluate eder ve izin/ret kararı döner.
4. Enforcer karara göre isteği kabul veya reddeder; audit log kaydı oluşturulur.

3.3 Caching, latency ve performans

Merkezi PDP sık çağrıldığında latency ve availability sorunları ortaya çıkabilir. Bu nedenle cache stratejileri (decision cache, policy cache), local policy compilation (Wasmtime/rego) ve token‑based capabilities (JWT içinde scopes/claims) ile trade‑off'lar yönetilir. Cache invalidation, policy change propagation ve TTL belirleme kritik operasyonel problemlerdir.

3.4 Contextual ve dynamic authorization

Günümüz gereksinimleri bağlam (time, IP, location, device posture, risk score) bazlı kararları gerektirir. ABAC ve PBAC modelleri bu esnekliği sağlar; örneğin "finansal işlem yalnızca iş saatleri içinde ve VPN üzerinden yapılabilir" türünden politikalar tanımlanabilir.

3.5 Tenant-aware ve multi‑tenant gereksinimler

Çok kiracılı uygulamalarda policy tasarımı tenant ayrıştırmasını ve tenant‑specific override'ları desteklemelidir. Tenant bazlı rol mapping, tenant sınırlandırılmış kaynak ID'leri ve per‑tenant policy paketleri yaygın stratejilerdir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Finans sektörü — ince‑tane kontrol ve uyumluluk

Bankacılık uygulamaları sıkı yetkilendirme gerektirir: transaction limits, separation of duties, approval workflows. PBAC/ABAC modelleri context‑aware kurallar ve audit trail sunarak regülasyon gereksinimlerini karşılamada etkilidir.

4.2 Sağlık sektörü — veri gizliliği ve consent management

Sağlık verisi erişimi için fine‑grained authorization ve hasta consent yönetimi gerekir. ABAC politikaları, patient consent claim'lerini dikkate alarak belirli veri alanlarını kısıtlayabilir.

4.3 SaaS platformları — tenant isolation ve self‑service RBAC

SaaS sağlayıcılar genelde RBAC ile başlar; zamanla tenant ihtiyaçları arttıkça PBAC veya ABAC'e geçiş yaparak daha esnek izinler sunar. Self‑service admin UI'ları ile tenant yöneticilerine rol yönetimi imkânı sağlamak yaygın bir gereksinimdir.

4.4 Büyük ölçekli platformlar — policy as code

Netflix, Google ve diğer büyük platformlar policy as code yaklaşımını benimsemiştir. Policy'ler versiyon kontrolünde tutulur, CI ile test edilir ve merkezi policy engine'ler (ör. OPA, Kyverno) pipeline içinde dağıtılır. Bu yaklaşım güvenlik, test ve governance için uygundur.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• ABAC/PBAC ile çok daha esnek ve bağlam‑duyarlı politikalar uygulanabilir.
• Policy as code ile test, review ve audit süreçleri otomasyona alınabilir.
• Merkezi PDP ile tutarlı karar verme ve merkezi logging sağlanır.

Sınırlamalar

• Merkezi PDP tek başına bir bottleneck ve single‑point‑of‑failure olabilir; HA ve caching gerek.
• ABAC ve PBAC karmaşıklığı artırır — policy explosion (çok sayıda kural) ve yönetim zorluğu.
• Performans: sık policy evaluation yüksek gecikme getirebilir; local decision ve cache stratejileri gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Least privilege prensibini baştan uygula; varsayılan deny ile başla.
• Policy as code: policy'leri versiyon kontrolünde tut, review ve automated tests ekle.
• Decision caching ve local evaluation: merkezi PDP çağrılarını minimize etmek için local cache veya compiled policies kullan.
• Audit ve explainability: her karar için gerekçelendirme (why allowed/denied) ve detaylı log tut.

Performans optimizasyonu

• Decision cache: aynı principal/resource/action üçlüsü için kısa TTL ile cache kullan.
• Policy partitioning: hot-path policy'leri optimize et ve precompile et.
• Asenkron denetimler: kritik olmayan izin kontrollerini asenkron audit veya background check olarak planla.

Güvenlik

• Policy değişikliklerini canary ile deploy et: küçük kullanıcı grupları üzerinde test et.
• Policy drift detection: runtime ile deployed policy'ler arasındaki farklılıkları izle.
• Revocation stratejileri: capability/token tabanlı modellerde hızlı revoke yolları sağla.

8. SIK YAPILAN HATALAR

• Gereğinden fazla kompleks policy yazmak — yönetilemez kurallar havuzu oluşur.
• Policy değişikliklerini test etmeden üretime almak — beklenmeyen deny/allow olayları.
• Audit/instrumentation yetersizliği — kararların izlenebilir olmaması forensics'i zorlaştırır.
• Cache invalidation ihmal edilmesi — yeni policy'ler uygulanmaz veya stale decisions oluşur.

9. GELECEK TRENDLER

1. AI‑assisted policy generation: Telemetry'den öğrenip öneriler ve otomatik policy şablonları üreten araçlar artacak.
2. Contextual and risk‑based authorization: Real‑time risk scoring, device posture ve behavioral signals ile dinamik yetki kararları yaygınlaşacak.
3. Policy as data ve standardized policy formats: Regüle ve enterprise entegrasyonları kolaylaştırmak için daha fazla standardizasyon bekleniyor (Rego, Common Policy Language).
4. Decentralized authorization: Capability‑based ve blockchain/tabanlı erişim modelleri bazı senaryolarda daha fazla ilgi görecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. RBAC mi ABAC mi seçmeliyim?

   Başlangıç için RBAC hızlı ve yeterli olabilir. Ancak bağlam‑duyarlı gereksinimler, dinamik politikalar veya tenant‑specific kurallar gerektiriyorsa ABAC veya PBAC'e geçiş düşünülmelidir.

2. 2. Merkezi PDP performans sorunlarına yol açar mı?

   Tek başına evet — merkezi PDP yüksek çağrı hacminde latency yaratabilir. Decision cache, local evaluation ve HA PDP ile bu sorunlar yönetilmelidir.

3. 3. Policy as code neden önemli?

   Policy as code policy'leri test edilebilir, review edilebilir ve CI/CD ile deploy edilebilir hale getirir; governance ve audit için şarttır.

4. 4. Capability‑based model nerede avantajlıdır?

   Offline veya disconnected senaryolarda, kısa‑lived capability token'ların taşınması ile local authorization sağlamak adına avantajlıdır.

5. 5. Policy testing için hangi yaklaşımlar kullanılmalı?

   Unit test, integration test ve property‑based testlerinin yanı sıra policy simulation (what‑if) ve kontrat bazlı testler uygulanmalıdır. Test verileri ve edge caseler policy testleri için kritik.

6. 6. Tenant‑specific policy'leri nasıl yönetmeliyim?

   Policy inheritance, overrides ve tenant policy paketleri ile yönetim sağlanmalı; merkezi policy registry ve templateler kullanışlıdır.

7. 7. Decision explainability neden önemlidir?

   İzin/ret kararlarının nedenlerini (which rule matched, which attributes were evaluated) loglamak güvenlik incelemeleri ve kullanıcı itirazları için gereklidir.

8. 8. Authorization için hangi open source araçlar uygundur?

   Open Policy Agent (OPA), Keycloak (authorization services), Envoy + external authorization, Casbin gibi projeler farklı ihtiyaçlara cevap verir. Seçim gereksinim, ekosistem ve operasyonel yetkinliğe göre yapılmalıdır.

Anahtar Kavramlar

RBAC

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

ABAC

Attribute tabanlı kontrol — principal, resource ve environment attribute'larına göre dinamik kararlar.

PDP / PEP

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

Policy as Code

Politikaların kod olarak versiyonlandığı, test edildiği ve CI/CD ile dağıtıldığı yaklaşım.

Capability

Belirli hakları temsil eden taşınabilir yetki objesi veya token.

Öğrenme Yol Haritası

1. 0–1 ay: Authorization temel kavramlarını öğrenin (ACL, RBAC) ve küçük bir uygulamada RBAC uygulayın.
2. 1–3 ay: ABAC ve PBAC modellerini öğrenin; Open Policy Agent (OPA) ile basit policy'ler yazıp test edin.
3. 3–6 ay: Policy as code, decision caching, explainability ve audit logging konularında uygulamalar oluşturun; tenant ve scale senaryolarını test edin.
4. 6–12 ay: Real‑time contextual authorization, risk‑based access decisions ve AI destekli policy önerileri içeren production uygulamalar geliştirin.