Rol Tabanli Erişim Kontrolu (RBAC), kullanicilara dogrudan izin vermek yerine rollere izin atayip kullanıcıları rollere baglayan olgun bir yetkilendirme modelidir. Küçük ekiplerde basit admin/user ayrimi yeterli görünür; ancak organizasyon buyudukce yetki patlamasi, tutarsiz erişim ve denetim zorlugu ortaya cikar. Yetki matrisi, hangi rolun hangi kaynak uzerinde hangi işlemi yapabilecegini açık tablo halinde tanimlar ve RBAC tasarımının temel artefaktidir.
RBAC terminolojisi
- Subject: Erişim talep eden aktor (kullanıcı, servis hesabi).
- Role: Is fonksiyonuna karşılık gelen izin grubu (BillingAdmin, SupportAgent).
- Permission: Atomik eylem (invoice:read, invoice:void).
- Resource: Korunan varlık (API endpoint, veri kaydi, UI modulu).
- Scope: Erişim kapsami (tenant, department, own-records-only).
NIST RBAC modeli Core RBAC, Hierarchical RBAC (rol kalitimi), ve Constrained RBAC (Separation of Duty) seviyelerini tanimlar. Hierarchical RBAC'ta Manager rolu Employee rolunun tüm izinlerini devralir; SoD ile ayni kullanıcıya hem odeme hem onay yetkisi verilmez.
Yetki matrisi tasarımı
Yetki matrisi satirlarda rolleri, sutunlarda kaynak/eylem ciftlerini listeler. Hucre degerleri Allow, Deny veya Conditional olabilir. Matris dokumani ürün, güvenlik ve uyumluluk ekipleri arasinda sözleşme gorevi görür; kod ve policy bu matrise uygun olmalidir.
| Rol | orders:read | orders:write | orders:refund | users:admin |
|----------------|-------------|--------------|---------------|-------------|
| SupportAgent | Allow (own) | Deny | Deny | Deny |
| SupportLead | Allow | Allow (own) | Deny | Deny |
| FinanceAdmin | Allow | Allow | Allow | Deny |
| SystemAdmin | Allow | Allow | Allow | Allow |
Own gibi qualifier'lar Attribute-Based Access Control (ABAC) ile birlestirildiginde gerçek is kurallarini yansitir: destek temsilcisi yalnizca atandigi müşterinin siparislerini görür.
Rol patlamasi ve çözümü
Her özel durum icin yeni rol oluşturmak rol patlamasina yol acar: 200 rol, 50 kullanıcı, yonetilemez matris. Çözüm stratejileri:
- Rol birlestirme: Benzer izin profillerini tek rol altinda toplayin.
- ABAC tamamlayici: Statik rol + dinamik attribute (department, region).
- Policy as code: Open Policy Agent (OPA) veya AWS Cedar ile merkezi karar motoru.
- Permission set: Rol yerine atanabilir izin paketleri (AWS IAM Permission Set modeli).
Uygulama katmaninda RBAC
Yetki kontrolu yalnizca UI'da buton gizlemekle sinirli kalamaz; her API endpoint'i sunucu tarafinda dogrular. Defense in depth: gateway coarse-grained, servis fine-grained kontrol yapar.
[Authorize(Roles = "FinanceAdmin")]
[HttpPost("orders/{id}/refund")]
public async Task<IActionResult> Refund(Guid id, ...)
{
var order = await _repo.GetAsync(id);
if (!_authz.Can(User, "orders:refund", order))
return Forbid();
// ...
}
[Authorize] attribute rol string'ine bağımlıdır; fine-grained permission icin custom IAuthorizationHandler veya policy-based authorization tercih edilir. Policy adi (CanRefundOrder) yetki matrisindeki satirla birebir eslesmelidir.
Veritabanı ve performans
Rol ve izin tablolari normalize edilir: Users, Roles, Permissions, UserRoles, RolePermissions. Her istekte bes join pahali olabilir; çözümler:
- Login'de izinleri JWT claim veya session'a yükle (değişiklik gecikmesi kabul edilebilir ise)
- Redis'te kullanıcı izin cache'i (TTL + invalidation on role change)
- Permission bitmap veya compact set representation
Denetim ve uyumluluk
Her yetki degisikligi audit log'a yazilir: kim, kime, hangi rol, ne zaman, hangi onay ile. SOC2 ve ISO 27001 periyodik access review gerektirir; kullanıcının aktif rolleri is goreviyle hala uyumlu mu sorulur. Orphan account (ayrilmis calisanin aktif hesabi) otomatik deprovision workflow ile kapatilir.
Separation of Duty (SoD)
SoD kurallari matriste açıkça tanimlanir: payment:create ve payment:approve ayni subject'te bulunamaz. SoD ihlali role assignment sirasinda statik analiz ile engellenir; runtime'da da policy engine kontrol eder. Violation attempt audit'e duser ve güvenlik ekibine alert gider.
Mikroservislerde merkezi yetkilendirme
Her servisin kendi RBAC tablosu tutmasi tutarsizliga yol acar. Merkezi identity provider rol ve scope bilgisini token'a koyar; servisler local policy ile dogrular. Karmaşık kurallar icin sidecar veya dedicated authorization servisi (Google Zanzibar modeli, SpiceDB) dusunulur. gRPC interceptor veya ASP.NET middleware ile karar tek noktadan alinir.
Test stratejisi
Yetki matrisinin her Allow hucresi icin pozitif test, her Deny hucresi icin negatif test yazilir. Property-based test ile rastgele rol kombinasyonlari denenebilir. Regression: yeni özellik eklendiginde matris guncellenmeden deploy engellenir (CI gate).
Yaygın hatalar
- Default allow: Açık izin tanimi olmayan endpoint açık kalir; default deny ilkesi uygulayin.
- IDOR: Rol kontrolu var ama kaynak sahipligi kontrol edilmiyor.
- Role string magic: Kodda daginik
"Admin"string'leri; merkezi sabitler veya enum kullanın. - Matris-kod sapmasi: Doküman guncellenmez; periyodik otomatik export ile matris koddan uretilir.
RBAC ve yetki matrisi, erişim kontrolunu yönetilebilir ve denetlenebilir kilar. Rol patlamasini onlemek, ABAC ile tamamlamak, sunucu tarafinda zorunlu kontrol ve SoD kurallari olgun RBAC mimarisinin temelidir. Büyük olcekte policy-as-code ve merkezi authorization servisi, dagitik sistemlerde tutarlılığı korur.
Delegasyon ve geçici yetki
Izindeki yonetici yerine vekalet senaryosunda time-bound delegation tanimlanir: belirli baslangic-bitis tarihi, belirli izin alt kumesi, vekalet veren onay kaydi. Delegation zinciri derinligi sinirlandirilir; sonsuz vekalet devri denetim dışi kalir. Break-glass emergency access ayri prosedurle acilir; otomatik ticket ve post-incident review zorunludur.
Matris evrimi ve versiyonlama
Yetki matrisi yasayan dokumandir; her ürün release'inde matris diff'i review edilir. Git'te versiyonlanan CSV veya YAML matris, CI'da policy kodu ile karsilastirilir. Breaking change (SupportAgent'tan orders:write kaldirilmasi) migration plani ve kullanıcı bildirimi gerektirir. Matris versiyon numarasi audit log'da saklanir; gecmis erişim kararlari hangi matris surumune gore alindigi izlenebilir olmalidir.
ABAC ile hibrit model
Saf RBAC statik is kurallarini yakalamakta yetersiz kalir. Attribute-Based Access Control, subject, resource ve environment attribute'larina gore karar verir: subject.department == resource.ownerDepartment. Hibrit modelde rol coarse-grained erişim sağlar, ABAC fine-grained filtre uygular. XACML veya OPA Rego policy dili attribute kurallarini ifade eder. Policy evaluation latency düşük tutulmali; karmaşık policy cache veya decision log ile optimize edilir.
UI ve API tutarlılığı
Kullanıcının goremeyecegi bir işlemi API'nin yapabilmesi güvenlik acigidir. UI permission check yalnizca UX icindir; authoritative karar sunucudadir. Frontend route guard ve backend endpoint authorization ayni permission tanimini paylasir; merkezi permission catalog tek kaynak olur. GraphQL'de field-level authorization resolver seviyesinde uygulanir; schema introspection production'da kisitlanabilir.
Büyük ölçek operasyonu
On bin kullanicili kuruluslarda rol atama degisikligi event-driven yayilir: Identity Provider'dan Kafka event, tüm servisler cache invalidate eder. Bulk import (yeni departman onboarding) batch job ile yapilir; her atama audit trail birakir. Periyodik recertification kampanyasi yonetici onayina sunulur; onaylanmayan erişim otomatik geri alinir. Bu operasyonel disiplin RBAC'in teknik tasarım kadar önemli oldugunu gösterir.
Compliance raporlama
Denetim aninda "kim hangi role sahipti" sorusuna aninda cevap verilebilmelidir. RBAC veritabanı ve audit log birlestirilerek erişim raporu uretilir. Segregation of Duties ihlal taramasi otomatik çalışır; yeni rol atamasi oncesi SoD check zorunlu kilinir. Rapor çıktı formati denetci beklentisiyle uyumlu (CSV, PDF, imzali arsiv) hazirlanir.
