Yetkilendirme Nedir? Kullanıcı Rolleri (RBAC) Nasıl Kurulur

Yetkilendirme, sisteme giriş yapmış bir kullanıcının hangi ekranı görebileceğine, hangi kaydı açabileceğine ve hangi işlemi yapabileceğine karar veren katmandır. Kimlik doğrulama "sen kimsin" sorusunu, yetkilendirme "ne yapabilirsin" sorusunu cevaplar. Rol tabanlı erişim kontrolü (RBAC) bunun en yaygın modelidir: izinler tek tek kullanıcıya değil rollere bağlanır, kullanıcıya rol atanır. Doğru kurulduğunda yeni bir çalışan dakikada yetkilendirilir, işten ayrılan tek tıkla kapatılır; yanlış kurulduğunda ise her ekrana yama gibi eklenen "bunu yalnız müdür görsün" koşulları birkaç ay içinde kimsenin anlamadığı bir yapıya dönüşür.

Kimlik doğrulama ile yetkilendirme farkı

İki kavram sık karıştırılır çünkü ikisi de "giriş" ekranıyla ilişkilendirilir. Kimlik doğrulama (authentication) kullanıcının iddia ettiği kişi olduğunu kanıtlar: şifre, SMS ile doğrulama kodu, tek oturum açma (SSO). Yetkilendirme (authorization) ise kimliği kanıtlanmış kullanıcının sınırlarını çizer. Kimlik doğrulama bir kez yapılır; yetkilendirme ise her istekte, her kayıtta yeniden sorulur. Bu yüzden güvenlik açıklarının önemli bölümü giriş ekranında değil, girişten sonra "bu kaydı gerçekten bu kullanıcı mı görmeli" sorusunun atlandığı yerde çıkar.

Rol tabanlı erişim kontrolü (RBAC) nedir?

RBAC üç parçadan oluşur: kullanıcı, rol ve izin. İzin, sistemdeki en küçük yetki birimidir ve "ne üzerinde hangi işlem" biçiminde adlandırılır: fatura görüntüleme, fatura oluşturma, fatura iptal etme gibi. Rol, birlikte anlamlı olan izinlerin paketidir: muhasebe uzmanı, satış temsilcisi, depo sorumlusu. Kullanıcıya rol atanır, kullanıcı o rolün izinlerini otomatik kazanır. Kritik kural şudur: kod asla "kullanıcı yönetici mi" diye sormaz, "kullanıcının fatura iptal etme izni var mı" diye sorar. Rol adı değişebilir, yeni rol eklenebilir ama kod izin düzeyinde yazıldığı için dokunulması gerekmez.

• Kullanıcı: sisteme giriş yapan gerçek kişi ya da entegrasyon hesabı.
• Rol: işletmedeki bir görevin karşılığı (satış, muhasebe, depo, yönetici).
• İzin: tek bir işlem hakkı (sipariş görüntüleme, sipariş onaylama, fiyat düzenleme).
• Atama: kullanıcıya bir ya da birden fazla rol verilmesi; izinler rol üzerinden gelir.
• Kapsam: rolün hangi şube, bölge ya da departman için geçerli olduğu.

Yetkilendirmede en pahalı hata, izinleri rollere değil doğrudan kişilere bağlamaktır. Üç ay sonra "Ayşe neden bu ekranı görüyor" sorusunun cevabı kimsede olmaz ve işten ayrılan çalışanın yetkisi sistemde kalır.

Rol ve izin yapısı nasıl tasarlanır?

Tasarım kodla değil bir tabloyla başlar: yetki matrisi. Satırlarda roller, sütunlarda izinler, hücrelerde evet/hayır. Bu tabloyu yazılım firması değil işletme doldurur, çünkü "iade onayını kim verir" sorusunun cevabı iş kuralıdır. Matris, proje brief’inin parçası olarak teslim edildiğinde geliştirme sırasında ekran başına tartışma yaşanmaz. İyi bir matris için birkaç ilke vardır:

• Önce işlem listesi, sonra rol: sistemde yapılabilecek her işi listeleyin, rolleri bu listeye bakarak oluşturun; tersi yapılırsa roller kişilere göre şekillenir.
• En az yetki ilkesi: her rol işi için gereken en dar izin setiyle başlar; ihtiyaç çıktıkça genişletilir, baştan "her şeyi görsün" verilmez.
• Görüntüleme ile değiştirme ayrı izinlerdir: raporu gören herkesin kaydı düzenleyebilmesi gerekmez.
• Onay işlemleri ayrı izindir: siparişi oluşturan ile onaylayan aynı kişi olmasın (görev ayrılığı).
• Beş ile on arası rol çoğu işletmeye yeter: yirmi rol varsa büyük ihtimalle izinler yerine kişiler modellenmiştir.

Ekran yetkisi yetmez: kayıt bazlı erişim

RBAC "satış temsilcisi siparişleri görebilir" der; ama hangi siparişleri? Çoğu kurumsal sistemde cevap "yalnızca kendi müşterilerinin" ya da "yalnızca kendi şubesinin" olur. Buna kayıt bazlı ya da satır düzeyinde erişim denir ve RBAC tek başına bunu çözmez. Çözüm, rolün yanına kapsam eklemektir: temsilci rolü + Ankara bölgesi. Sunucu her sorguya bu kapsamı filtre olarak ekler. Bu filtrenin arayüzde değil sunucuda uygulanması şarttır; arayüzde gizlenen bir buton, adres satırına doğrudan yazılan bir kayıt numarasıyla aşılır. Mobil uygulama güvenliği yazısında anlattığımız IDOR açığı tam olarak bu kontrolün atlanmasından doğar. B2B bayi sistemlerinde bayinin yalnızca kendi siparişlerini görmesi de aynı mekanizmayla sağlanır.

Kodda yetki kontrolü nasıl görünür?

Aşağıdaki örnek, izin kontrolünün rol adına değil izin adına yazılmasını ve kapsam filtresinin sorguya eklenmesini gösterir. Kontrol tek bir fonksiyonda toplanır; ekranlar ve API uçları bu fonksiyonu çağırır, kendi koşullarını yazmaz.

type Permission = 'order:view' | 'order:approve' | 'price:edit';

type User = {
  id: string;
  roles: string[];
  branchIds: string[];
};

const rolePermissions: Record<string, Permission[]> = {
  sales: ['order:view'],
  salesManager: ['order:view', 'order:approve', 'price:edit'],
};

export const can = (user: User, permission: Permission) =>
  user.roles.some(role => rolePermissions[role]?.includes(permission));

export const approveOrder = async (user: User, orderId: string) => {
  if (!can(user, 'order:approve')) {
    throw new Error('FORBIDDEN');
  }
  const order = await db.order.findFirst({
    where: { id: orderId, branchId: { in: user.branchIds } },
  });
  if (!order) {
    throw new Error('NOT_FOUND');
  }
  return db.order.update({
    where: { id: order.id },
    data: { status: 'approved', approvedBy: user.id },
  });
};

İki ayrıntıya dikkat edin: kapsam dışındaki kayıt için "yetkiniz yok" değil "bulunamadı" dönülür, böylece kaydın varlığı sızdırılmaz. Onaylayan kullanıcının kimliği kayda yazılır; bu, bir sonraki bölümün konusu olan denetim kaydının başlangıcıdır.

Denetim kaydı (audit log) neden zorunlu?

Yetki vermek kadar kimin ne zaman ne yaptığını kaydetmek de gerekir. Denetim kaydı; fiyat değişikliği, iade onayı, kullanıcıya rol atanması gibi kritik işlemleri kullanıcı, zaman, eski değer ve yeni değer ile saklar. Bu kayıt yalnızca güvenlik için değil, iş anlaşmazlıkları için de en güçlü kanıttır. Kişisel veri içeren sistemlerde erişim kaydı tutmak KVKK uyumunun de parçasıdır: hangi çalışanın hangi müşteri kaydını ne zaman görüntülediği sorulduğunda cevap verilebilmelidir. Denetim kaydının silinemez olması, en yetkili yöneticinin bile kendi izini temizleyememesi gerekir.

Sık yapılan hatalar

• Tek "admin" ve tek "kullanıcı" ile başlamak: ikinci ay "muhasebe her şeyi görmesin" dendiğinde her ekran yeniden açılır.
• Yetki kontrolünü yalnızca arayüzde yapmak: gizlenen menü, API’ye doğrudan istekle aşılır.
• Rol adını koda gömmek: "if role === manager" yazan her yer, rol adı değişince kırılır.
• Kapsamı unutmak: aynı rolde iki şube müdürü birbirinin verisini görür.
• İşten ayrılma akışının olmaması: hesap kapatılmaz, yalnızca şifre değiştirilir; entegrasyon anahtarları açık kalır.
• Süper kullanıcıyı günlük işte kullanmak: her işlemi yapabilen hesap, her hatayı da yapabilir.

Hazır çözüm mü, özel tasarım mı?

Hazır paketlerde rol yapısı sabittir; işletmenin onay zinciri pakete uymuyorsa süreç yazılıma uydurulur. Hazır çözüm ile özel yazılım kararında yetki yapısı çoğu zaman belirleyici kriterdir: çok şubeli, çok kademeli onaylı ya da bayi/müşteri gibi dış kullanıcıya açılan sistemlerde yetki modeli işin kendisidir. Kurumsal çözümlerde biz rol ve izin tasarımını analiz aşamasında, yetki matrisiyle birlikte teslim ediyoruz; kod bu tablodan üretiliyor.

Sonuç

Yetkilendirme, sonradan eklenen bir güvenlik özelliği değil, çok kullanıcılı her sistemin omurgasıdır. İzinleri rollere bağlayın, kodu izin adıyla yazın, kapsamı sunucuda filtreleyin ve kritik işlemleri denetim kaydına alın. Bu dört kural uygulandığında yeni şube açmak ya da yeni bir görev tanımlamak kod değişikliği değil, yönetim panelinde bir ayar olur. Yetki yapısı karmaşık bir sistem planlıyorsanız özel yazılım hizmetimize göz atabilir ya da teklif alabilirsiniz.