Rol Bazlı Yetkilendirme: Herkes Her Şeyi Görmesin Rehberi

Rol Bazlı Yetkilendirme (RBAC) Nedir?

Erişim kontrolünün oturduğu zemin, çoğu kurumda fark edilmeden kurulur

Rol bazlı yetkilendirme (kısaca RBAC), yetkiyi kullanıcıya tek tek dağıtmak yerine önce rolleri tanımlayıp yetkileri bu rollere bağlayan, kullanıcıyı da uygun role oturtan bir yaklaşımdır. Kulağa basit gelir; işletmeyi asıl rahatlatan da bu basitliktir.

Klasik yöntemde her kullanıcıya ayrı ayrı “fatura görür”, “stok değiştirir”, “rapor indirir” gibi yetkiler tanımlanır. Beş kişilik ekipte sorun çıkmaz, ama kullanıcı sayısı büyüdükçe bu tablo elde tutulamaz hale gelir. RBAC’te işleyiş şöyle kurulur:

• Roller tanımlanır: “Muhasebe Uzmanı”, “Depo Sorumlusu”, “Satış Temsilcisi” gibi
• Rollere yetkiler bağlanır: Her rol, yalnızca kendi işini yapabilir
• Kullanıcılar rollere atanır: Ahmet Bey “Muhasebe Uzmanı” rolüne atanır, o rolün bütün yetkilerini tek hamlede devralır

RBAC vs Diğer Erişim Modelleri

RBAC tek erişim modeli değil. Diğerleriyle yan yana koyunca farkı daha net görülür:

• DAC (Discretionary Access Control): Yetkiyi kaynağın sahibi belirler. Esnektir ama merkezi kontrol zayıf kalır
• MAC (Mandatory Access Control): Tüm yetkileri sistem yöneticisi belirler. Çok katıdır, esneklik neredeyse yoktur
• ABAC (Attribute-Based Access Control): Yetki; kullanıcı, kaynak ve ortam özelliklerine göre anlık belirlenir. Güçlü ama kurulumu ve bakımı zahmetlidir
• RBAC: Rol temelli, yönetmesi kolay, kurumsal ihtiyaçların çoğuna cuk oturur

Piyasadaki ERP, CRM ve iş uygulamalarının büyük bölümü ya doğrudan RBAC ile çalışır ya da onu destekler.

Neden Bu Kadar Önemli?

Doğru kurgulanmış yetki, güvenlikle verimliliği aynı anda kazandırır

Yetki yönetimini “sonra hallederiz” rafına kaldırmanın bedeli, genellikle iş işten geçtikten sonra ortaya çıkar. RBAC’in neden ertelenemeyecek bir başlık olduğunu birkaç noktadan görelim:

Güvenlik Boyutu

• Veri sızıntısı riski: Herkesin her veriyi gördüğü bir sistemde, tek bir çalışanın hesabı ele geçirilirse bütün veri açığa çıkmış demektir
• İç tehditler: Kasıtlı ya da kazara yapılan hataların çoğu, gereğinden fazla yetkili kullanıcılardan gelir
• Uyumluluk gereklilikleri: KVKK, ISO 27001 ve sektörel regülasyonlar yetki yönetimini zorunlu tutar

Operasyonel Boyut

• Hata önleme: Depo çalışanının fiyat değiştirememesi, muhasebecinin stok silememesi; onarım ve düzeltme maliyetlerini doğrudan aşağı çeker
• İş akışı güvencesi: Onay mekanizmaları sayesinde tek kişi kritik bir işlemi baştan sona kapatamaz
• Sorumluluk netliği: Kim neyi yapabiliyor belli olunca, “bu kimin işi” tartışmaları kendiliğinden azalır

Yönetim Boyutu

• Ölçeklenebilirlik: Yeni çalışan geldiğinde yetkileri tek tek girmek yerine rol atamak yeter
• Değişiklik yönetimi: Bir roldeki yetki değişikliği, o roldeki herkese anında yansır
• Denetim kolaylığı: “Faturaya kim erişebiliyor?” sorusunun cevabı saniyeler içinde gelir

Temel Kavramlar ve Terminoloji

RBAC’te sık geçen terimlere hakim olmadan sağlıklı bir tasarım yapmak zor. Kısaca üzerinden geçelim:

Kullanıcı (User/Subject)

Sisteme erişen kişi ya da servis hesabı. Her kullanıcının benzersiz bir kimliği olur: kullanıcı adı, e-posta, çalışan numarası gibi.

Rol (Role)

Bir iş fonksiyonunu temsil eden, yetki kümesini üstünde taşıyan yapısal birim. “Satış Müdürü”, “Stok Operatörü”, “Finans Analisti” gibi.

Yetki/İzin (Permission)

Belirli bir kaynak üzerinde belirli bir işlemi yapabilme hakkı. “Fatura_Okuma”, “Fatura_Oluşturma”, “Fatura_İptal” gibi ince taneli tanımlar.

Kaynak/Nesne (Resource/Object)

Yetkilendirmenin kapsadığı veri ya da işlem. Faturalar, siparişler, müşteriler, raporlar; hepsi birer kaynaktır.

Oturum (Session)

Kullanıcının sisteme girişinden çıkışına kadar geçen süre. Oturum bazlı yetkilendirmede kullanıcı, tek bir oturumda birden fazla rolü aktive edebilir.

Yetki Devri (Delegation)

Bir kullanıcının yetkilerinin bir kısmını veya tamamını geçici olarak başka bir kullanıcıya aktarması. Genelde izin ve tatil dönemlerinde işe yarar.

Rol Kalıtımı (Role Inheritance)

Üst rollerin, alt rollerin yetkilerini miras almasıdır. Örneğin “Satış Müdürü” rolü, “Satış Temsilcisi” rolünün tüm yetkilerini üzerine kendi ek yetkilerini de ekleyerek taşır.

Yetki Matrisi Oluşturma

Yetki matrisi, rollerle işlemlerin kesiştiği yeri tek bakışta gösterir

Yetki matrisi, RBAC tasarımının belkemiğidir: rollerin satırda, işlemlerin sütunda (ya da tam tersi) yer aldığı bir tablo. Her kesişim, o rolün o işlem üzerindeki yetkisini söyler.

Matris Oluşturma Adımları

1. İş Süreçlerini ve İşlemleri Listeleyin

Sistemdeki tüm işlemleri çıkarın. Modül modül ilerlemek işi kolaylaştırır:

• Satış: Teklif oluşturma, sipariş girişi, fiyat güncelleme, iskonto uygulama
• Satın alma: Talep oluşturma, sipariş açma, tedarikçi tanımlama, fiyat görme
• Stok: Hareket girişi, sayım, transfer, fire kaydı, maliyet görme
• Finans: Fatura kesme, ödeme kaydı, vade değiştirme, cari ekstresi

2. Yetki Türlerini Belirleyin

Her işlemin altında farklı yetki seviyeleri olabilir:

• Okuma (R): Görme, listeleme, raporlama
• Oluşturma (C): Yeni kayıt ekleme
• Güncelleme (U): Mevcut kaydı değiştirme
• Silme (D): Kaydı kaldırma
• Onaylama (A): Kaydı aktive etme, onay verme
• İptal (X): İşlemi/kaydı iptal etme

3. Rolleri Tanımlayın

Organizasyondaki iş fonksiyonlarını temel alın, ama birebir kopyalamayın. Aynı unvanı taşıyan iki kişi pekâlâ farklı yetkiler isteyebilir.

4. Matrisi Doldurun

Her rol-işlem kesişiminde gereken minimum yetkiyi işaretleyin; fazlası değil.

Örnek Yetki Matrisi (Temsili)

C: Oluşturma, R: Okuma, U: Güncelleme, D: Silme, A: Onaylama, – : Yetki Yok

Görevler Ayrımı (Segregation of Duties)

Görevler ayrımı (kısaca SoD), aynı kişinin birbiriyle çelişebilecek yetkileri elinde toplamasını engelleyen ilkedir. RBAC’in en kritik güvenlik katmanı da budur.

Temel Çatışma Türleri

Oluşturma vs Onaylama Çatışması

Bir kaydı oluşturan kişi, aynı kaydı onaylayamaz. Örnekler:

• Satın alma talebini açan kişi, o talebi onaylayamaz
• Ödeme emrini hazırlayan kişi, ödemeyi onaylayamaz
• Yeni tedarikçiyi tanımlayan kişi, o tedarikçiye sipariş açamaz

Kayıt vs Muhafaza Çatışması

Fiziksel varlıkla ilgilenen kişi, o varlığın kayıtlarını tutamaz:

• Kasayı yöneten kişi, kasa mutabakatını yapamaz
• Depoda mal teslim alan kişi, stok kayıtlarını değiştiremez

İşlem vs Denetim Çatışması

Bir işlemi yapan kişi, o işlemi denetleyemez:

• Fatura kesen kişi, fatura denetim raporunu hazırlayamaz
• Yetki tanımlayan kişi, yetki denetimini yapamaz

SoD Uygulamasında Dikkat Edilecekler

• Küçük ekip sorunu: Az kişili işletmelerde tam SoD kurmak zor olabilir. Böyle durumlarda telafi edici kontroller devreye girer: düzenli denetim, üst yönetim gözetimi, otomatik uyarılar
• Acil durum prosedürü: SoD’yi aşmayı gerektiren acil hallerde kimin yetkili olduğu, işlemin nasıl loglanacağı ve sonradan nasıl denetleneceği önceden yazılı olmalı
• Rol biriktirme (Role creep): Zamanla aynı kişiye birden fazla rol yığılması SoD’yi içten çürütür. Düzenli gözden geçirme şart

En Az Yetki İlkesi (Least Privilege)

En az yetki: ne bir fazla, ne bir eksik; tam gerektiği kadar

En az yetki ilkesi (kısaca PoLP), her kullanıcının yalnızca işini yapacak kadar yetkiye sahip olması gerektiğini söyler. “Belki lazım olur” diyerek fazladan verilen her yetki, aslında güvenlik açığına açılan bir kapıdır.

Uygulama Prensipleri

1. Varsayılan Olarak Reddet (Default Deny)

Yeni bir kullanıcı ya da rol oluşturulduğunda başlangıçta hiçbir yetkisi olmamalı. Yetkiler, ihtiyaç doğrulandıkça tek tek eklenmeli.

2. Just-In-Time (JIT) Erişim

Yüksek riskli yetkiler (admin işlemleri, toplu silme, veri aktarımı) kalıcı olarak verilmek yerine ihtiyaç anında talep edilmeli ve süreyle sınırlanmalı.

3. Düzenli Gözden Geçirme

Her kullanıcının yetkileri belirli aralıklarla (3-6 ayda bir) elden geçirilmeli. Artık kullanılmayan ya da iş tanımı değiştiği için gereksizleşen yetkiler kaldırılmalı.

4. İş Değişikliğinde Yetki Sıfırlaması

Çalışan departman ya da görev değiştirdiğinde eski yetkileri otomatik kaldırılmalı, yeni yetkileri yeni role göre atanmalı.

En Az Yetki Uygulama Örnekleri

• Raporlama: Her kullanıcı yalnızca kendi bölgesinin/departmanının verisini görebilmeli
• Zaman sınırı: Geçici proje ekibi üyeleri, proje bitiş tarihinde yetkilerini otomatik kaybetmeli
• İşlem limiti: Satış temsilcisi %10’a kadar iskonto verebiliyorsa, üstü için müdür onayı gerekmeli
• Veri maskeleme: TCKN, banka hesap numarası gibi hassas alanlar, yetkisi olmayan kullanıcıya maskeli görünmeli

Rol Hiyerarşisi Tasarımı

Rol hiyerarşisi, rollerin birbirinden yetki miras almasını sağlayan yapıdır. Doğru kurulduğunda yönetimi ferahlatır; yanlış kurulduğunda karmaşanın kaynağı olur.

Hiyerarşi Türleri

Düz (Flat) Yapı

Roller arasında hiyerarşi yoktur, her rol bağımsızdır. Basittir ama aynı yetkileri tekrar tekrar tanımlamaya zorlar.

Kısıtlı Hiyerarşi

Yalnızca bir üst rol tanımlıdır. “Satış Müdürü” rolü “Satış Temsilcisi” rolünü içerir, başka katman yoktur.

Genel Hiyerarşi

Çok katmanlıdır; bir rol birden fazla alt rolü miras alabilir. Esnektir ama karmaşıklığı da beraberinde getirir.

Hiyerarşi Tasarım İlkeleri

• Organizasyon şemasını bire bir kopyalamayın: Yetki ihtiyacıyla organizasyon yapısı her zaman örtüşmez
• Temel rolleri tanımlayın: “Okuyucu”, “Operatör”, “Yönetici” gibi ortak yetki kümelerini temel rol olarak kurun
• İş fonksiyonu bazlı ilerleyin: “Muhasebe Okuyucu”, “Muhasebe Operatör” gibi fonksiyon + seviye kombinasyonları kullanın
• Rol sayısını makul tutun: Orta ölçekli işletmelerin çoğu için 20-50 arası rol yeter. Yüzlerce rol elde tutulamaz
• İsimlendirmede tutarlı olun: “[Departman]_[Seviye]” ya da “[Fonksiyon]_[Yetki Kapsamı]” gibi bir standarda bağlı kalın

Örnek Hiyerarşi Yapısı

Denetim İzi (Audit Trail)

Denetim izi (audit trail ya da audit log), sistemde yapılan işlemlerin kim tarafından, ne zaman, nereden ve nasıl yapıldığının kayıt altına alınmasıdır. RBAC’i tamamlayan parçadır: yetki vermek tek başına yetmez, o yetkinin nasıl kullanıldığını da görmeniz gerekir.

Loglanması Gereken İşlemler

Zorunlu Loglanacaklar

• Kimlik doğrulama: Başarılı/başarısız giriş denemeleri, şifre değişiklikleri, oturum kapanışı
• Yetki değişiklikleri: Rol atama/kaldırma, yetki ekleme/çıkarma
• Kritik veri işlemleri: Finansal kayıtlar, müşteri verileri, stok hareketleri
• Sistem konfigürasyonu: Parametre değişiklikleri, entegrasyon ayarları
• Toplu işlemler: İçe/dışa aktarma, toplu güncelleme, toplu silme

Önerilen Loglanacaklar

• Rapor indirme/paylaşma
• Arama sorguları (özellikle hassas verilerde)
• Ekran/modül erişim kayıtları

Log İçeriği

Her log kaydında şunlar bulunmalı:

• Kim: Kullanıcı kimliği (ID, kullanıcı adı, çalışan numarası)
• Ne zaman: Tarih ve saat (zaman dilimi bilgisiyle birlikte)
• Nereden: IP adresi, cihaz bilgisi, mümkünse lokasyon
• Ne: İşlem türü, etkilenen kayıt ya da kayıtlar
• Önce/Sonra: Değişen alanların önceki ve yeni değerleri
• Sonuç: İşlem başarılı mı, başarısız mı; başarısızsa nedeni

Log Yönetimi En İyi Pratikleri

• Değiştirilemezlik: Loglar yazıldıktan sonra değiştirilememeli (WORM – Write Once Read Many)
• Merkezi toplama: Farklı sistemlerin logları tek bir merkezi noktada toplanmalı
• Saklama süresi: Yasal gerekliliklere göre (çoğunlukla 5-10 yıl) saklanmalı
• Alarm mekanizması: Gece vakti toplu silme ya da art arda başarısız giriş gibi anormallikler için otomatik uyarı
• Düzenli inceleme: Loglar yalnızca sorun çıkınca değil, periyodik olarak da denetlenmeli

Sahadan Örnek: Yetki Kaosundan Çıkış

Sıkça Sorulan Sorular (SSS)