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

Rol Bazlı Yetkilendirme (RBAC) Nedir?

RBAC, kurumsal sistemlerde erişim kontrolünün temel yapısinı oluşturur

Rol bazlı yetkilendirme (Role-Based Access Control – RBAC), kullanıcılara tek tek yetki atamak yerine, önceden tanimlanmis rollere yetki bağlamanın ve kullanıcıları bu rollere atamanin sistemlestirildigi bir erişim kontrol modelidir.

Geleneksel yetkilendirmede her kullanıcıya ayrı ayrı “fatura görür”, “stok değiştirir”, “rapor indirir” gibi yetkiler atanır. Kullanıcı sayısı artinca bu yaklaşim yönetilemez hale gelir. RBAC’te işe:

• Roller tanımlaniir: “Muhasebe Uzmanı”, “Depo Sorumlusu”, “Satış Temsilcisi” gibi
• Rollere yetkiler bağlanır: Her rol, belirli işlemleri yapabilir
• Kullanıcılar rollere atanır: Ahmet Bey “Muhasebe Uzmanı” rolüne atanır, o rolün tüm yetkilerini otomatik alır

RBAC vs Diğer Erişim Modelleri

RBAC, erişim kontrol modellerinden sadece biri. Diğer yaklaşimlarla kiyaslandiginda:

• DAC (Discretionary Access Control): Kaynak sahibi yetkiyi belirler. Esnektir ama merkezi kontrol zayıftır
• MAC (Mandatory Access Control): Sistem yöneticisi tüm yetkiileri belirler. Çok katıdir, esneklik düşüktür
• ABAC (Attribute-Based Access Control): Yetki, kullanıcı/kaynak/ortam özelliklerine göre dinamik belirlenir. Karmaşıktır
• RBAC: Rol temelli, yönetimi kolay, çoğu kurumsal ihtiyaça uygun

Kurumsal ERP, CRM ve is uygulamalarının büyük çoğunluğu RBAC modelini kullanır veya destekler.

Neden Bu Kadar Önemli?

Doğru yetkilendirme, hem güvenliği hem de operasyonel verimliliği arttırır

Yetki yönetiminin “sonra hallederiz” kategorisine atilmasinin bedeli, çoğu zaman geç fark edilir. İşte RBAC’in neden kritik olduğunu gösteren bazı gerçekler:

Güvenlik Boyutu

• Veri sızıntısı riskı: Herkesn her veriyi goredildigi sistemlerde, bir çalışanin hesabının ele geçirilmesi tüm verinin tehlikeye girmesi demek
• Ic tehditler: Kasıtlı veya kazara yapılan hatalar, aşırı yetkili kullanıcılardan gelir
• Uyumluluk gereklilikleri: KVKK, ISO 27001 ve sektörel regülasyonlar, yetki yönetimini zorunlu kılar

Operasyonel Boyut

• Hata önleme: Depo çalışaninin fiyat degistirememesi, muhasebecinin stok silememesi, onarım/düzeltme maliyetlerini düşürur
• İ̇ş akış güvencesi: Onay mekanizmaları, tek kişinin kritik işlemleri tamamlayamamasını sağlar
• Sorumluluk netiligi: Kim neyi yapabilir net olunca, “bu kimin isi” tartışmaları azalır

Yönetim Boyutu

• Ölçeklenebilirlik: Yeni çalışan geldiğinde tek tek yetki vermek yerine, rol atamak yeterli
• Degisiklik yönetimi: Bir roldeki yetki değişikliği, o roldeki tüm kullanıcılara otomatik yansır
• Denetim kolaylığı: “Faturaya kim erişebilir?” sorusunun cevabı saniyeler içinde alınabilir

Temel Kavramlar ve Terminoloji

RBAC dünyasında sik kullanılan terimleri anlamak, doğru tasarım için zorunludur:

Kullanıcı (User/Subject)

Sisteme erişen birey veya servis hesabı. Her kullanıcının benzersiz bir kimlik bilgisi (kullanıcı adı, e-posta, çalışan numarası) vardır.

Rol (Role)

Is fonksiyonunu temsil eden, yetkiler kümesini taşıyan yapısal birim. “Satış Muduuru”, “Stok Operatörü”, “Finans Analisti” gibi.

Yetki/Izin (Permission)

Belirli bir kaynak üzerinde belirli bir işlemi yapabilme hakkı. “Fatura_Okuma”, “Fatura_Oluşturma”, “Fatura_Iptal” gibi granüler tanımlar.

Kaynak/Nesne (Resource/Object)

Yetkilendirme kapsamındaki veri veya işlem. Faturalar, siparişler, müşteriler, raporlar birer kaynaktır.

Oturum (Session)

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

Yetki Devri (Delegation)

Bir kullanıcının yetkilerinin bir kısmını veya tamaminı, geçici olarak başka bir kullanıcıya aktarması. Izin/tatil dönemlerinde kullanılır.

Rol Kalitimi (Role Inheritance)

Üst rollerin alt rollerin yetkilerini miras almasını. “Satış Müdürü” rolü, “Satış Temsilcisi” rolünün tüm yetkilerini + ek yetkileri içererk.

Yetki Matrisi Oluşturma

Yetki matrisi, rollerin ve yetkilerin kesisimini görselleştirir

Yetki matrisi, RBAC tasarımininn belkemiği olan, rollerin satırda, işlemlerin (veya tersi) sütunda yer aldığı bir tablodur. Her kesisim noktasi, o rolün o işlem üzerindeki yetkisini gösterir.

Matris Oluşturma Adimleri

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

Sistemdeki tüm işlemleri belirleyin. Modül bazlı düşünmek faydalıdı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şlem için 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
• Iptal (X): İ̇şlem/kaydı iptal etme

3. Rolleri Tanimlayin

Organizasyondaki is fonksiyonlarını temel alın ancak birebir kopyalamayin. Aynı unvandaki kişiler farklı yetkiler gerektirebilir.

4. Matrisi Doldurun

Her rol-işlem kesişimi için gereken minimum yetkiyi belirleyin.

Ö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ı (SoD – Segregation of Duties), aynı kişinin birbiiriyle çatışmali olabilecek yetkilere sahip olmasını onleyen ilkedir. RBAC’in en kritik güvenlik katmanıdır.

Temel Çatışma Türleri

Oluşturma vs Onaylama Çatışması

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

• Satın alma talebi oluşturan kişi, o talebi onaylayamaz
• Ödeme emri hazırlayan kişi, ödemeyi onaylayamaz
• Yeni tedarikçi tanımlayan kişi, o tedarikçiye sipariş açamaz

Kayıt vs Muhafaza Çatışması

Fiziksel varlikla ilgilenen kişi, o varligin kayıtlarını tutamaz:

• Kasayi yöneten kişi, kasa mutabakatini yapamaz
• Depoda mal teslim alan kişi, stok kayıtlarını degistiremez

İ̇ş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 zor olabilir. Bu durumda telafi edici kontroller (compensating controls) devreye girer: duzzenli denetim, üst yönetim gözetimi, otomatik uyarılar
• Acil durum prosedürü: SoD’yi asmayi gerektiren acil durumlarda, kim yetkili, nasıl loglanacak, sonradan nasıl denetlenecek tanimli olmalı
• Rol biriktirme (Role creep): Zamanla aynı kişiye birden fazla rol atanması, SoD’yi zayıflatır. Düzenli gözden geçirme şart

En Az Yetki Ilkesi (Least Privilege)

En az yetki ilkesi: Sadece gereken kadar, ne fazla ne eksık

En az yetki ilkesi (Principle of Least Privilege – PoLP), her kullanıcının yalnızca işini yapmak için gereken minimum yetkiye sahip olması gerektiğini belirler. “Belki lazım olur” mantığıyla fazla yetki vermek, güvenlik açıklarına davetiye cikarir.

Uygulama Prensipleri

1. Varsayılan Olarak Reddet (Default Deny)

Yeni bir kullanıcı veya rol oluşturulduğunda, baslangicta hiçbir yetkisi olmamalı. Yetkiler, ihtiyaç doğruldugunda 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 atanmak yerine, ihtiyaç anında talep edilmeli ve süre sınırı ile verilmeli.

3. Düzenli Gözden Geçirme

Her kullanıcının yetkileri periyodik olarak (3-6 ayda bir) incelenmeli. Artık kullanılmayan, değişen is tanımından dolayı gereksiz hale gelen yetkiler kaldırılmalı.

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

Çalışan departman veya görev degistirdiginde, eski yetkiler otomatik kaldırılmalı, yeni yetkiler yeni role göre atanmali.

En Az Yetki Uygulama Örnekleri

• Raporlama: Her kullanıcı yalnızca kendi bölgesinin/departmanının verilerini gorebilmeli
• Zaman sınırı: Geçici proje ekibi üyeleri, proje bitiş tarihinde yetkilerini otomatik kaybetmeli
• İ̇şlem limiti: Satış temsilcisi %10’a kadar iskonto yetkisine sahipken, üstu için müdür onayı gerekeli
• Veri maskeleme: TCKN, banka hesap numarası gibi hassas alanlar, yetkisi olmayan kullanıcılara maskelenmeli

Rol Hiyerarşisi Tasarımi

Rol hiyerarşisi, rollerin birbirinden yetki miras almasını sağlayan yapıdır. Doğru kurgulandiginda yönetimi kolaylaştırır; yanlis kurgulandiginda karmasaya yol açar.

Hiyerarşi Türleri

Düz (Flat) Yapı

Roller arasında hiyerarşi yok, her rol bağımsız. Basit ama tekrara yol açar.

Kısıtlı Hiyerarşi

Sadece bir üst rol tanimlı. “Satış Müdürü” rolü “Satış Temsilcisi” rolünü içerir, başka bir hiyerarşi yok.

Genel Hiyerarşi

Çok katmanlı, bir rol birden fazla alt rolü miras alabilir. Karmaşık ama esnektir.

Hiyerarşi Tasarım Ilkeleri

• Organizasyon semesini bire bir kopyalamayin: Yetki ihtiyacı ve organizasyon yapısi her zaman ortusemez
• Temel rolleri tanimlayin: “Okuyucu”, “Operatör”, “Yönetici” gibi ortak yetki kümelerini temel roller olarak oluşturun
• Is fonksiyonu bazlı ilerleyin: “Muhasebe Okuyucu”, “Muhasebe Operatör” gibi fonksiyon + seviye kombinasyonları kullanın
• Rol sayısını makul tutun: 20-50 arası rol, çoğu orta ölçekli işletme için yeterli. Yüzlerce rol yönetilemez
• Rol isimlendirmede tutarlı olun: “[Departman]_[Seviye]” veya “[Fonksiyon]_[Yetki Kapsamı]” gibi standart kullanın

Örnek Hiyerarşi Yapısi

Denetim Izi (Audit Trail)

Denetim izi (audit trail veya audit log), sistemde yapılan işlemlerin kim tarafından, ne zaman, nereden, nasıl yapıldiginin kaydı altına alinmesidir. RBAC’in tamamlayici unsurudur; yetki vermek yetmez, yetki kullanımını izlemek gerekir.

Loglanması Gereken İ̇şlemler

Zorunlu Loglanacaklar

• Kimlik doğrulama: Başarıli/başarısiz giriş denemeleri, şifre değişiklikleri, oturum kapanis
• 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: Import, export, 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 bulunması gereken bilgiler:

• Kim: Kullanıcı kimliği (ID, kullanıcı adı, çalışan numarası)
• Ne zaman: Tarih ve saat (timezone bilgisiyle)
• Nereden: IP adresi, cihaz bilgisi, lokasyon (mümkünse)
• Ne: İ̇şlem türü, etkilenen kayıt/kayıtlar
• Önce/Sonra: Degisiklik yapılan alanların önceki ve yeni değerleri
• Sonuç: İ̇şlem başarıli mi, başarısiz mi (ve neden)

Log Yönetimi En Iyi Pratikleri

• Degistirilemezlik: Loglar, yazildiktan sonra degistirilememeli (WORM – Write Önce Read Many)
• Merkezi toplama: Loglar, farklı sistemlerden merkezi bir noktaya akmali
• Saklama süresi: Yasal gerekliliklere göre (genellikle 5-10 yıl) saklanmalı
• Alarm mekanizmesi: Anormal aktiviteler (gece vakti toplu silme, çok sayıda başarısiz giriş) için otomatik uyarı
• Düzenli inceleme: Loglar sadece sorun anında değil, periyodik olarak denetlenmeli

Sahadan Örnek: Yetki Kaosundan Çıkış

Sikca Sorulan Sorular (SSS)