Web Uygulamalarında Erişim Kontrolü: RBAC, ABAC, OAuth ve Modern Yaklaşımlar

Erişim kontrolü (access control), bir web uygulamasının güvenliğinin merkezindedir. Hangi kullanıcının hangi kaynağa, hangi koşullarda erişebileceğini belirlemek; hem uygulama mantığı hem de uyumluluk açısından kritik öneme sahiptir. Bu makalede klasik RBAC yaklaşımlarından başlayıp, ABAC, OAuth 2.0 ve OpenID Connect gibi protokollere ve günümüzün mikroservis/Cloud tabanlı mimarilerinde tercih edilen modellere kadar pratik bir yol haritası sunuyorum.

Neden Erişim Kontrolü (Access Control) Önemlidir?

Erişim kontrolü, sadece kimlik doğrulamayı (authentication) değil, kimlik doğrulandıktan sonra yetkilendirme (authorization) sürecini de kapsar. Kimlik doğrulama size "bu kullanıcı gerçekten o mu?" sorusunun cevabını verirken, yetkilendirme "bu kullanıcı ne yapabilir?" sorusunu yanıtlar. Bu ayrım sistem tasarımında sıkça gözardı edilir ve sonrasında ciddi güvenlik açıklarına yol açar.

Kötü tanımlanmış veya dağıtılmış erişim kuralları veri sızıntılarına, yetkisiz işlemlere ve hukuki sorunlara neden olabilir. Özellikle mikroservis mimarilerinde yetki kontrollerinin merkezi mi yoksa dağıtık mı olacağı önemli bir tasarım kararıdır. Bu karar performans, bakım maliyeti ve güvenlik seviyesini doğrudan etkiler.

RBAC (Role-Based Access Control): Basit ve Sık Kullanılan Yaklaşım

RBAC, roller üzerinden yetkilendirme modelidir. Kullanıcılara roller atanır; roller ise kaynaklar ve izinlerle ilişkilendirilir. Kurumsal uygulamalarda en sık tercih edilen modeldir çünkü kavramsal olarak basittir ve yönetimi kolaydır. Örneğin "admin", "editor", "viewer" gibi rollere farklı izin kümeleri atanır.

RBAC'ın avantajı yönetimsel sadeliği ve anlaşılabilirliğidir. Dezavantajı ise esnekliğinin sınırlı olmasıdır; bağlam yüküne (context) dayalı kararlar ve karmaşık iş kuralları RBAC ile zor yönetilir. Kurallar çoğaldıkça roller patlaması (role explosion) yaşanabilir ve bakım zorluğu artar.

<!-- Basit bir RBAC kontrol örneği (Node.js / Express benzeri pseudocode) -->
function authorize(requiredRole) {
  return (req, res, next) => {
    const userRoles = req.user.roles || [];
    if (userRoles.includes(requiredRole)) return next();
    return res.status(403).send('Erişim reddedildi');
  }
}

app.get('/admin', authorize('admin'), (req,res) => res.send('Yönetici paneli'));

ABAC (Attribute-Based Access Control): Bağlam ve Esneklik

ABAC, yetkilendirme kararlarını kullanıcı, kaynak, işlem ve ortam gibi niteliklere (attributes) dayanarak verir. Örneğin "kullanıcı.department == 'Finans' ve belge.confidentiality <= kullanıcı.clearance" gibi kurallar oluşturabilirsiniz. ABAC, dinamik politikaların uygulanmasında güçlüdür ve kurumsal politikaların çoğuna doğal uyum sağlar.

ABAC'ın zor yanı politika yazımının karmaşıklığıdır. Uygulama mantığı ve politikaların ayrıştırılması için iyi bir policy engine (ör. OPA - Open Policy Agent) kullanılması önerilir. OPA gibi araçlar sayesinde yetki kararlarını koddan ayırıp merkezi olarak yönetebilirsiniz.

# OPA (Rego) örneği: belgeye erişim izni
package authz

default allow = false

allow {
  input.user.department == input.document.ownerDepartment
  input.user.clearance >= input.document.classification
}

OAuth 2.0 ve OpenID Connect: Erişim Delegasyonu ve Kimlik Sağlama

OAuth 2.0, kaynaklara erişimi üçüncü taraf istemcilere güvenli şekilde devretmek için kullanılan yetkilendirme çerçevesidir. OpenID Connect (OIDC) ise OAuth 2.0'ın üzerine kimlik katmanı ekler ve kimlik doğrulama için standart bir yol sağlar. Mikroservis veya SPA (Single Page Application) mimarilerinde bu protokoller yaygın olarak kullanılır.

OAuth/OIDC, token tabanlı bir yaklaşıma dayanır: access token kaynak sunucuya erişim için kullanılır; refresh token access token süresi dolduğunda yeniden erişim almak içindir. OIDC ise id_token ile kullanıcının kimliğine dair güvenli bir iddia sunar. Token doğrulama, token türü (JWT vb.) ve token yönetimi konuları mimari tasarımda kritik rol oynar.

// JWT örneği (kısmi, açıklayıcı):
{
  "iss": "https://auth.example.com",
  "sub": "user-123",
  "aud": "api.example.com",
  "exp": 1710000000,
  "scope": "read:orders write:orders"
}

Merkezi vs Dağıtık Yetkilendirme: Hangi Durumda Hangisi?

Merkezi yetkilendirme (ör. API Gateway + policy engine) yönetimi kolaylaştırır; politikaları tek noktadan güncelleyebilirsiniz. Ancak tek bir merkezi nokta performans ve yüksek erişilebilirlik gereksinimleriyle baskı altına girebilir. Dağıtık yetkilendirme ise her servis kendi kararını verecek şekilde tasarlanır; bu, gecikmeyi azaltır ve bağımsız ölçeklendirmeye imkan tanır fakat politika tutarlılığı sağlamak daha zor olabilir.

Pratik öneri: Kritik iş kuralları ve ortak politikalar için merkezi bir policy engine kullanın (örn. OPA + Gatekeeper). Performansın kritik olduğu, çok yüksek çağrı trafiği olan yollar için token üzerindeki iddiaları (claims) kullanarak hızlı yerel kontroller sağlayın. Böylece merkezi yönetim ve dağıtık hız dengesini kurmuş olursunuz.

Migrasyon: Eski RBAC Tabanlı Sistemden Modern Bir Sisteme Geçiş Stratejisi

Eski RBAC sistemlerinden ABAC/OAuth/OIDC tabanlı mimarilere geçiş yaparken adım adım ilerlemek en sağlıklısıdır. İlk adım mevcut rollerin ve izinlerin envanterini çıkarmaktır. Hangi roller hangi kaynaklara erişiyor, hangi iş kuralları rol tanımının ötesine geçiyor bunu netleştirin.

Sıralı bir geçiş önerisi: 1) Authentication'ı OIDC ile değiştirip token tabanlı hale gelin; 2) Merkezi policy engine koyun ve RBAC kurallarını burada tanımlayın; 3) ABAC kurallarına ihtiyaç duyulan alanlarda kademeli olarak attribute'ları ekleyin; 4) Operasyonel testler ve canary rollout ile üretime alın. Bu süreçte kullanıcı deneyimini bozmamak için geri dönüş (rollback) planları hazırlayın.

Uygulamada Pratik İpuçları ve Örnek Senaryolar

Küçük uygulamalar için JWT + basit rol/claim kontrolleri yeterli olabilir. Orta-büyük ölçekli sistemlerde OIDC ile kimlik doğrulama, OAuth 2.0 ile delegasyon ve OPA gibi bir policy engine kullanımını öneririm. Loglama ve audit (denetim) kayıtlarını iyi tasarlamak, hangi erişim isteğinin neden reddedildiğini anlamayı kolaylaştırır.

Yetki kontrollerini API katmanında bir middleware ile merkezi hale getirmek, UI ve servisler arasındaki tutarlılığı sağlar. Ancak karmaşık bağlam kuralları (örn. zaman, lokasyon, veri sınıflandırması) için policy engine'e başvurun. Ayrıca token sürelerini ve refresh politikalarını risk bazlı düşünün; kısa ömürlü access token + güvenli refresh mekanizması genelde dengeli bir çözümdür.

Sık Sorulan Sorular

1. Hangi durumda RBAC yerine ABAC seçmeliyim?

Kuralların kullanıcı rollerinden ziyade kullanıcı, kaynak ve çevresel niteliklere göre değiştiği durumlarda ABAC tercih edilmelidir. Örneğin belge erişimi departman, yetki seviyesi ve belgenin gizlilik derecesine göre dinamik değişiyorsa ABAC daha uygundur.

2. OAuth 2.0 mı yoksa OpenID Connect mi kullanmalıyım?

Kimlik doğrulama (kullanıcı oturum açma) gerekiyorsa OpenID Connect tercih edin; yalnızca üçüncü taraf uygulamalara kaynak erişimi yetkilendirecekseniz OAuth 2.0 yeterli olabilir. OIDC, OAuth 2.0'ın üzerine kimlik katmanını eklediği için kimlik ihtiyaçları varsa OIDC tavsiye edilir.

3. Policy engine kullanmak performansı düşürür mü?

Doğru tasarlanmış bir policy engine mimarisi performansı kabul edilebilir seviyede tutar. Sık çağrılan kontroller için cache mekanizmaları, local policy snapshot'ları ve önbelleklenmiş token claim'leri kullanılabilir. Kritik yol üzerindeki kararları basit token kontrolleri ile yapıp daha karmaşık kararları merkezi engine'e yönlendirmek iyi bir denge sağlar.

Sonuç

Erişim kontrolü, hem güvenlik hem de uygulama mimarisi açısından çok katmanlı düşünülmesi gereken bir alan. RBAC hızlı ve basit çözümler için uygundur; ancak kurallar karmaşıklaşınca ABAC veya policy-engine tabanlı yaklaşımlar daha sürdürülebilir olur. OAuth 2.0 ve OpenID Connect, modern uygulamalarda kimlik ve yetkilendirme için standartlaşmış çözümlerdir. Geçiş stratejisinde adım adım ilerlemek, merkezi ve dağıtık yaklaşımlar arasında denge kurmak ve iyi bir audit/log altyapısı kurmak başarı anahtarlarıdır.

Eğitim bağlantısı eklenecek.