Rol Tabanlı Yetkilendirme (RBAC) Nedir? Web Uygulamasında Nasıl Kurulur?

Rol tabanlı yetkilendirme (RBAC — Role-Based Access Control), bir web uygulamasında kimin hangi ekranı görebileceğini ve hangi işlemi yapabileceğini kullanıcı tek tek değil, rol üzerinden tanımlayan bir erişim modelidir. On kullanıcılı bir sistemde bile izinleri kişi başına ayarlamak, her yeni çalışanla birlikte yeniden çözülmesi gereken bir bulmacaya dönüşür; RBAC bu bulmacayı sabit sayıda role indirger. Bu yazıda RBAC'ın nasıl çalıştığını, hangi projede gerçekten gerekli olduğunu, kurulum adımlarını ve en sık düşülen tuzakları sırayla anlatıyoruz.

RBAC tam olarak nasıl çalışır?

RBAC dört yapı taşından oluşur ve her biri farklı bir soruya cevap verir: kim, ne, hangi kaynak üzerinde ve hangi işlemi yapabilir. İzin doğrudan kullanıcıya değil role bağlanır; kullanıcıya yalnızca bir veya birkaç rol atanır. Bu ayrım küçük görünür ama sonucu büyüktür — bir çalışanın görevi değiştiğinde tek yapılması gereken rolünü güncellemektir, düzinelerce izni tek tek elden geçirmek değil.

• Kullanıcı. Sisteme kimlik bilgisiyle giriş yapan gerçek kişi.
• Rol. "Editör", "muhasebe", "şube yöneticisi" gibi bir iş tanımını temsil eden etiket.
• İzin. Bir role bağlı, belirli bir eylemi (görüntüleme, düzenleme, onaylama, silme) yapma hakkı.
• Kaynak. İznin uygulandığı varlık — sipariş, fatura, kullanıcı kaydı, rapor gibi.

Hangi işaretler RBAC'a gerçekten ihtiyaç olduğunu gösterir?

Her uygulamanın karmaşık bir yetki sistemine ihtiyacı yok. Aşağıdaki işaretlerden birkaçı aynı anda görülüyorsa, RBAC bir lüks değil bir gerekliliktir.

1. Birden fazla kullanıcı tipi aynı panelde çalışıyor. Satış, muhasebe ve yönetim aynı sistemde farklı ekranlara ihtiyaç duyuyorsa, tek bir "kullanıcı" tanımı yetmez.
2. Hassas veri söz konusu. Maaş bilgisi, müşteri kişisel verisi veya finansal rapor gibi alanlara kimin erişebileceği net olmalı.
3. Denetim veya uyumluluk gereksinimi var. KVKK ve sektörel denetimler, kimin hangi veriye ne zaman eriştiğinin kayıt altında olmasını ister.
4. Ekip büyüyor. Beş kişilik bir ekipte elle takip edilebilen izinler, elli kişide sürdürülemez hale gelir.

Basit yetkilendirme ile RBAC arasındaki fark

Örnek: küçük bir ekibin rol matrisi neye benzer?

Soyut kalmasın diye tipik bir hizmet işletmesindeki dört rolü örnekleyelim; buradaki sayılar değil mantık önemlidir.

Dört rolün her biri bir işi temsil ediyor, bir kişiyi değil — aynı role birden fazla kişi atanabilir, bir kişi de gerekirse birden fazla role sahip olabilir.

RBAC tasarımının 5 adımı

Kurulum sırası önemlidir; her adım bir öncekinin çıktısına dayanır.

1. Rolleri iş tanımından çıkarın, ekran listesinden değil. Rol, birinin gerçekte yaptığı işi yansıtmalı; ekranlara bakarak rol türetmek gereksiz roller doğurur.
2. Kaynak × eylem matrisini çıkarın. Her rolün hangi kaynakta görüntüleme, oluşturma, düzenleme ve silme yapabileceğini bir tabloda netleştirin.
3. En az yetki ilkesini uygulayın. Bir rol, işini yapmak için gereken izinden fazlasına sahip olmamalı — varsayılan erişim kapalı, gerekçeyle açık olmalı.
4. Gerekiyorsa rol hiyerarşisi kurun. "Şube yöneticisi" rolünün "personel" rolünün tüm izinlerini otomatik devralması, aynı izinleri iki kez tanımlamayı önler.
5. Denetim kaydı (audit log) ekleyin. Kim, ne zaman, hangi kaynağa hangi izinle eriştiği kayıt altına alınmalı; bu hem güvenlik hem uyumluluk için gerekli.

RBAC her zaman yeterli mi?

Çoğu proje için evet, ama bir sınırı var: RBAC rol bazında karar verir, veriye özel bağlam bazında değil. "Bir satış temsilcisi yalnızca kendi oluşturduğu teklifleri görebilsin" gibi bir kural, saf RBAC ile zor ifade edilir çünkü bu, kaynağın *sahibiyle* ilgilidir, roldeki kişiyle değil. Bu tür durumlarda RBAC'a sahiplik (ownership) tabanlı ek bir kural katmanı eklenir; nadiren de olsa özellik/koşul tabanlı yetkilendirmeye (ABAC) geçilir. Pratikte çoğu iş uygulaması RBAC'ı temel alıp üstüne birkaç sahiplik kuralı ekleyerek ihtiyacın tamamını karşılar.

RBAC hangi katmanda uygulanmalı?

Yalnızca arayüzde saklamak yeterli değildir; bir butonu gizlemek erişimi kapatmaz, yalnızca görünmez yapar. Doğru kurulum iki katmanda birden çalışır: arayüz izne göre neyin gösterileceğine karar verir, sunucu ve veritabanı ise her isteği bağımsız olarak yeniden doğrular. Postgres tabanlı sistemlerde satır düzeyi güvenlik (Row Level Security), bu ikinci kontrolü veritabanının kendisine taşır — bir geliştirici API tarafında bir kontrolü unutsa bile veritabanı yetkisiz sorguyu reddeder.

• Arayüz katmanı. Kullanıcıya yalnızca yetkisi olan menüyü ve butonu gösterir; deneyimi sadeleştirir ama tek başına güvenlik önlemi değildir.
• Sunucu/API katmanı. Her istekte izni yeniden kontrol eder; arayüz atlatılsa bile bu katman durur.
• Veritabanı katmanı. Satır düzeyi güvenlik kurallarıyla, yanlışlıkla yazılmış bir sorgu bile yetkisiz veriye erişemez.

RBAC kurulumunda en sık yapılan 4 hata

• Rolleri kişiye göre tanımlamak. "Ahmet'in rolü" diye bir şey olmamalı; roller kişiden bağımsız, işe bağlı olmalı.
• Varsayılan erişimi geniş bırakmak. Yeni bir kaynak eklendiğinde herkese açık başlaması, sonradan daraltmaktan çok daha risklidir.
• Denetim kaydını sona ertelemek. Audit log'u sistem büyüdükten sonra eklemek, geçmişe dönük hiçbir veri sağlamaz.
• Test ortamında yetki kontrolünü atlamak. Geliştirme sırasında "herkes her şeyi görsün" kolaylığı, üretime taşınan unutulmuş bir açık kapıya dönüşebilir.

Ne kadar sürer?

Süre, rol sayısına ve kaynak çeşitliliğine göre değişir. Web ve uygulama geliştirme hizmetimizde üç-dört rollü standart bir yetkilendirme kurulumu tipik olarak 1–2 hafta sürüyor; çok kiracılı (multi-tenant) bir yapıda rol hiyerarşisi ve sahiplik kuralları birlikte kurulacaksa bu süre 3–5 haftaya çıkabiliyor. Gözcü projesinde kurduğumuz rol tabanlı erişim sistemi, envanter ve bakım modüllerinde farklı ekiplerin aynı panelde birbirinin verisine karışmadan çalışmasını sağlıyor.

Kapsamı ve bütçeyi belirleyen kalemleri yazılım projesi maliyeti rehberimizde ayrıca ele aldık — rol/yetki matrisinin karmaşıklığı bu kalemlerden biri. Kendi uygulamanız için kaç role ihtiyacınız olduğundan emin değilseniz, mevcut süreçlerinizi birlikte gözden geçirelim — kısa bir görüşme talep edin.