Rol Bazlı Yetkilendirme (RBAC) Nedir? Rol Tasarımı, En Az Yetki ve Denetim Rehberi

Bayi portalına giren satın alma görevlisi fiyat listesini değiştirebiliyor, depo çalışanı faturaları görebiliyor, işten ayrılan bir satış temsilcisinin hesabı aylardır açık duruyor. Bu tablo çoğu zaman kötü niyetten değil, yetkilerin tek tek ve dağınık verilmesinden doğar. Rol bazlı yetkilendirme (RBAC, Role-Based Access Control) yetkiyi kişiye değil role bağlayarak bu dağınıklığı düzene çevirir.

Bu rehberde rol bazlı yetkilendirmenin ne olduğunu, ACL ve nitelik bazlı modelden farkını, en az yetki ve görev ayrımı ilkelerini, rol tasarımının altı adımını, rol patlaması sorununu, kullanıcı yaşam döngüsünü, denetim kayıtlarını ve düzenli gözden geçirmeyi anlatıyoruz. Örnek rakamlar temsilîdir; belirli bir ürünün ya da işletmenin ölçümü değildir.

Rol Bazlı Yetkilendirme (RBAC) Nedir?

Rol bazlı yetkilendirme, bir uygulamadaki işlem yetkilerinin kullanıcılara tek tek değil, görev tanımına karşılık gelen rollere verildiği yetki modelidir. Kullanıcı bir ya da birkaç role atanır ve yalnızca bu rollerin içerdiği izinleri kullanabilir.

Modelin dört kavramı vardır: kullanıcı (kişi ya da hesap), rol (görev tanımı, örneğin "Bayi muhasebe"), izin (tek bir işlem, örneğin "faturayı görüntüle") ve kapsam (hangi kayıtlar üzerinde, örneğin yalnızca kendi bayisi). Kimlik doğrulama kullanıcının kim olduğunu, yetkilendirme ise ne yapabileceğini belirler; API tarafındaki kimlik ve token konularını API güvenliği rehberimizde ayrıca ele aldık. Bu yazı, iş uygulamasının kendi rol modeline odaklanıyor.

Okumanızı öneririz: Özel yazılım hizmetimiz

RBAC, ACL ve Nitelik Bazlı Yetkilendirme Arasındaki Fark Nedir?

Üç model aynı soruyu farklı yerden çözer. ACL kaynağa, RBAC göreve, nitelik bazlı model ise koşula bakar. Çoğu iş uygulaması için RBAC temel alınır, kapsam gerektiğinde nitelik eklenir.

Pratikte karma yol işe yarar: rol "ne yapabilir" sorusunu, nitelik "hangi kayıtlarda" sorusunu yanıtlar. Örneğin "Bayi siparişçi" rolü sipariş açabilir; bölge niteliği yalnızca kendi bölgesindeki müşterileri gösterir.

RBAC Neden Gerekli? Yetki Sayısı Nasıl Değişir?

Gerekçe yönetilebilirliktir. Yetkiyi kişiye tek tek vermek, kullanıcı ve izin sayısı çarpıldıkça yönetilemez hale gelir. Temsilî örnek: portalda 50 kullanıcı ve 20 izin var.

• Bireysel atama: 50 × 20 = 1.000 olası atama kararı.
• Rol bazlı: 6 rol × 20 izin = 120 rol-izin ilişkisi, artı 50 kullanıcı-rol ataması = 170.
• Fark: 1.000 − 170 = 830 kayıt daha az; 830 ÷ 1.000 = %83 azalma.

Asıl kazanç sayıdan çok değişiklik kolaylığıdır: bir izin kaldırılacağında bireysel modelde onlarca kullanıcıya tek tek dokunulur, rol modelinde ilgili rolün tanımı değişir. Bayi portalı gibi çok kullanıcılı sistemlerin kapsamını B2B e-ticaret rehberimizde anlattık.

En Az Yetki İlkesi Nedir?

En az yetki ilkesi, her kullanıcıya yalnızca görevini yapmak için gereken izinlerin verilmesidir; fazlası risk yaratır. Hesap ele geçirilse, yanlışlıkla işlem yapılsa ya da çalışan kötü niyetli olsa, hasarın sınırı o hesabın yetkisi kadardır.

• Varsayılan ret: Açıkça verilmeyen izin yoktur. Yeni rol boş başlar, gerekenler eklenir.
• Okuma ile yazmayı ayırın: Raporu görmek, kaydı değiştirmekten ayrı izindir.
• Yönetici rolünü az tutun: Tam yetkili hesap sayısı olabildiğince az olsun ve günlük işte kullanılmasın.
• Süreli yetki: Geçici görev için verilen izne bitiş tarihi koyun, yoksa kalıcı hale gelir.

Görev Ayrımı Nedir ve Neden Önemlidir?

Görev ayrımı, riskli bir işin baştan sona tek kişinin elinde olmamasıdır. Aynı kişi hem talebi açıp hem onaylıyorsa, hata ya da kötüye kullanım kimseye görünmeden ilerleyebilir.

Kural basittir: çakışan izin çiftlerini tanımlayın ve aynı role ya da aynı kullanıcıya birlikte vermeyin. Tipik çiftler: sipariş oluşturma ile onaylama, fiyat listesi düzenleme ile sipariş açma, ödeme hazırlama ile ödeme onaylama, kullanıcı oluşturma ile yetki atama. Gözden geçirmede "çatışan çifte sahip kullanıcı" sayısı ölçülür. Satın alma gibi onay zincirli süreçleri iş süreçleri otomasyonu rehberimizde ele aldık.

Rol Tasarımı Nasıl Yapılır? Altı Adım

İyi rol modeli ekranlardan değil, işlerden yola çıkar. Aşağıdaki altı adım, yeni bir uygulamada da mevcut sistemin temizliğinde de uygulanır.

1. İzin envanteri: Uygulamadaki tüm işlemleri tek tek listeleyin (siparişi görüntüle, fatura indir, fiyat düzenle). Örnekte 20 izin çıktı.
2. Gruplama: Aynı işi yapan kişilerin ihtiyaçlarını bir araya getirip rolleri adlandırın. Örnekte 6 rol: Bayi sahibi, Bayi siparişçi, Bayi muhasebe, İç satış temsilcisi, Depo sorumlusu, Sistem yöneticisi.
3. Rol matrisi: Satırda izin, sütunda rol olan bir tablo çıkarın; her hücre bilinçli karar olsun.
4. Çatışma kontrolü: Görev ayrımı gerektiren çiftleri matriste işaretleyin ve aynı rolde birleşmesini engelleyin.
5. Atama: Kullanıcıları rollere bağlayın; kapsam (bayi, bölge) niteliğini ekleyin.
6. Gözden geçirme: Üç ayda bir roller ve atamalar yeniden kontrol edilsin.

Matriste dikkat edin: sipariş oluşturan "Bayi siparişçi" onay veremez (görev ayrımı), sistem yöneticisi ticari işlem yapamaz (en az yetki), fiyat listesi ise ayrı bir "Fiyat yöneticisi" rolüne bırakılabilir. Gereksinimlerin bu düzeye indirilmesi için gereksinim analizi rehberimize bakabilirsiniz.

Rol Patlaması Nedir ve Nasıl Önlenir?

Rol patlaması, her istisna için yeni bir rol açıldıkça rol sayısının kullanıcı sayısına yaklaşmasıdır; model dağınık bireysel yetkiye geri döner. Genellikle bölge, tutar sınırı ya da müşteri gibi koşulların role gömülmesinden çıkar.

Temsilî örnek: 6 temel rolü 4 bölgeyle çarparsanız 6 × 4 = 24 rol, üç tutar sınırı kademesi eklerseniz 24 × 3 = 72 rol olur. Aynı iş, 6 rol ve iki nitelikle (bölge ve limit) çözülür: rol "ne yapar", nitelik "nerede ve ne kadarına" sorusunu yanıtlar.

• Rol sayısını düzenli sayın; kullanıcı sayısının üçte birini aşıyorsa tasarımı gözden geçirin.
• Tek kişilik rolü istisna olarak işaretleyin ve gerekçesini yazın.
• Rol hiyerarşisinde (üst rolün alt rolü kapsaması) yetki devrini sade tutun.
• Rolleri ekran adıyla değil, iş tanımıyla adlandırın.

Kullanıcı Yaşam Döngüsünde Yetki Nasıl Yönetilir?

Yetki sorunlarının büyük kısmı kullanıcı yaşam döngüsünün üç anında çıkar: işe giriş, görev değişikliği ve işten ayrılış. Her biri için yazılı bir adım olmalıdır.

Görev değişikliğinde yetkilerin birikmesi ("yetki sürünmesi") en sinsi sorundur: iki kez görev değiştiren kullanıcı üç rolün izinlerini birden taşır. Atama ve kaldırma işlemlerini tek bir kişinin değil, İK ya da yönetici talebine bağlı bir sürecin yapması iyidir.

Yetkilendirme Kuralı Nerede Uygulanmalıdır?

Her yetki denetimi sunucuda yapılmalıdır; arayüzde bir düğmeyi gizlemek yalnızca kullanım kolaylığıdır. Sunucu denetlemiyorsa, doğrudan istek gönderen biri gizli işlemi yapabilir.

• Her istekte denetim: Rol ve kapsam her işlemde sunucuda kontrol edilir; ekran durumuna güvenilmez.
• Merkezî kural: Yetki mantığı tek bir katmanda toplanır; dağınık ekran kontrolleri tutarsızlık doğurur.
• Kayıt kapsamı: Rol izin verse bile, kullanıcı yalnızca kendi bayisinin kaydına ulaşır. Başkasının kayıt numarasını yazmak çalışmamalı.
• Yetki değişikliği etkisi: Rol değişince açık oturumlar da yeni yetkiyle çalışmalı.

Bu denetimlerin kapsamını test aşamasında doğrulamak için yazılım testi rehberimizdeki senaryo mantığını yetki kontrollerine de uygulayın: her rol için yapabileceği ve yapamayacağı işlemler ayrı test durumudur.

Denetim Kayıtları ve Düzenli Gözden Geçirme Nasıl Yapılır?

Denetim kaydı, kimin hangi kaydı ne zaman değiştirdiğini ve yetki değişikliklerini saklar; gözden geçirme ise bu verinin ve atamaların düzenli kontrolüdür. İkisi birlikte çalışır.

• Ne kaydedilir? Giriş denemeleri, yetki atama ve kaldırma, hassas kayıtlara erişim, silme ve toplu işlemler.
• Kayıt değiştirilemez olmalı: Yönetici bile kendi kaydını silememeli.
• Kişisel veri: Kayıtta ne tutulacağı ve ne kadar saklanacağı KVKK kapsamında hukuk danışmanınızla netleştirilmelidir.
• Yedekleme: Yetki ve kayıt verisi de yedekleme planına dahil olmalı; veri yedekleme rehberimizdeki RPO ve RTO mantığını burada da kullanın.

Üç ayda bir yapılan gözden geçirme dört ölçüyü verir. Temsilî örnek, 50 hesaplı portal:

Bu örnekte yedi atıl hesap kapatıldığında 50 − 7 = 43 aktif hesap kalır; saldırı yüzeyi %14 küçülür. Dördüncü ölçüdeki ihlal (üç ayrılandan biri) en önemli bulgudur: ayrılan kişinin açık hesabı, gizli bir kapıdır.

RBAC'ta Sık Yapılan Hatalar Nelerdir?

• Kontrolü yalnızca arayüzde yapmak: Gizlenen düğme yetki denetimi yerine geçmez.
• Herkese yönetici vermek: "Çalışsın diye" geniş yetki, en az yetki ilkesini bozar.
• Kişiye özel rol açmak: Her istisna için yeni rol, rol patlamasına yol açar.
• Yetkiyi kopyalamak: Yeni gelene "eskisi gibi" yetki vermek gereksiz izinleri taşır.
• Ayrılanı unutmak: Hesap kapatma adımı yazılı değilse aylarca açık kalır.
• Gözden geçirmemek: Roller yılda bir bile bakılmazsa görev değişikliğiyle uyumsuzlaşır.
• Denetim kaydı tutmamak: Olay olduğunda kimin ne yaptığı bilinmez.

Okumanızı öneririz: Müşteri portalı nedir? Self-servis kapsamı, güvenlik ve geri dönüş rehberi

İnovabil ile Rol Bazlı Yetkilendirme

İnovabil olarak ağırlığımız sıfırdan, firmaya özel yazılım geliştirmektir: özel yazılım, ERP, CRM, e-ticaret, web, mobil ve entegrasyon. Geliştirdiğimiz iş uygulamalarının kayıtlı yetenekleri arasında rol bazlı yetki, denetim kayıtları ve güvenli barındırma yer alır. Rol modelinin gereksinim aşamasında, yani ekranlar çizilmeden önce yazılı hale getirilmesini öneriyoruz; böylece izin envanteri, rol matrisi ve görev ayrımı kuralları baştan netleşir.

Avcılar İnşaat için CRM, satın alma ve mobil; İZBAN için satın alma sistemi; Karyak için lojistik ve sevkiyat planlama ile toptan sipariş yönetimi; Sleepy için depo yönetimi ile şikâyet ve destek yönetim sistemi geliştirdik. Kullanıcı gruplarınız ve riskli işlemleriniz hakkında kısa bir özet gönderin; birlikte ilk rol matrisini çıkaralım.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular