Özel yazılım projelerinde kullanıcı yetkilendirme, çoğu zaman arayüz tamamlandıktan sonra gündeme gelen bir başlık gibi görülür. Oysa erişim modeli geç tasarlanırsa hem güvenlik açıkları hem de operasyonel karmaşa kısa sürede büyür. Özellikle çok kullanıcılı ERP, CRM, bayi portalı, insan kaynakları uygulamaları ve saha operasyon sistemlerinde aynı ekranın farklı kullanıcılar için farklı davranması gerekir. Bu noktada temel yaklaşım çoğunlukla rol bazlı yetkilendirme modelidir.

İyi kurgulanmış bir yetkilendirme yapısı yalnızca “kim neyi görür” sorusunu çözmez. İşlem onayı, kayıt silme, fiyat değiştirme, toplu veri dışa aktarma, log takibi ve denetim izi gibi başlıkları da kapsar. Örneğin bir satın alma uygulamasında talep açma ile ödeme onayı aynı kullanıcıda toplanırsa görevler ayrılığı bozulur. Bu, denetim açısından zayıf bir tasarımdır. Sağlıklı bir modelde roller, izinler, kapsam sınırları ve kayıt altına alma mekanizması daha proje başlangıcında tanımlanmalıdır.

Rol bazlı yetkilendirme nedir, neyi çözer?

Rol bazlı yetkilendirme, kullanıcıya tek tek izin vermek yerine izinlerin önce rollere atanması, kullanıcıların da bu rollere bağlanması prensibine dayanır. En basit örnekte 4 rol düşünelim: yönetici, operasyon uzmanı, muhasebe kullanıcısı ve sadece görüntüleme yetkisine sahip denetçi. Her rolün ekran, işlem ve veri kapsamı farklıdır. Böyle bir yapı, 200 kullanıcı için tekil izin yönetmekten çok daha sürdürülebilirdir.

Bu model üç somut problemi çözer. İlki ölçeklenebilirliktir. Kullanıcı sayısı 20’den 2.000’e çıktığında izin matrisinin yönetilebilir kalmasını sağlar. İkincisi hata riskidir. Tek tek yetki vermek yerine standart rol şablonları kullanıldığında yanlış erişim verme olasılığı azalır. Üçüncüsü ise denetim kolaylığıdır. İç denetim veya ISO 27001 gibi çerçeveler açısından “hangi rol hangi işlemi yapabiliyor?” sorusuna net cevap üretmek mümkün hale gelir.

Yine de her projede yalnızca RBAC yeterli olmayabilir. Aynı role sahip iki satış temsilcisinin sadece kendi bölgesindeki müşterileri görmesi istenebilir. Bu durumda role ek olarak kapsam kısıtı gerekir. Yani “Satış Temsilcisi” rolü aynı kalır, fakat veri erişimi bölge_id = 34 ya da müşteri_portföyü = kullanıcıya bağlı kayıtlar gibi koşullarla sınırlandırılır.

Temel mimari: kullanıcı, rol, izin ve kapsam katmanları

Sağlam bir yetkilendirme modeli en az 4 temel nesne içerir: kullanıcı, rol, izin ve kapsam. Bunlar veritabanında ayrı tablolar olarak kurgulanır. Örnek bir yapı şöyle olabilir:

  • users: kullanıcı kimliği, durum bilgisi, organizasyon bağı
  • roles: Sistem Yöneticisi, Depo Sorumlusu, Bölge Müdürü gibi iş rolleri
  • permissions: order.create, invoice.approve, customer.export gibi teknik izinler
  • role_permissions: hangi rolün hangi izinlere sahip olduğu
  • user_roles: bir kullanıcının birden fazla role sahip olabilmesi

Burada kritik ayrım şudur: rol iş dilidir, izin ise sistem dilidir. “Muhasebe Uzmanı” bir roldür. “invoice.view” veya “payment.approve” ise uygulama izinleridir. Bu ayrım yapılmadığında ekipler zamanla ekran isimlerini rol yerine kullanmaya başlar ve model dağılır.

Kapsam katmanı çoğu projede sonradan eklenmek istendiği için ek maliyet çıkarır. Oysa ilk tasarımda düşünülürse yapı temiz kalır. Örnek olarak bir servis yönetim yazılımında teknisyen rolü aynı olabilir; ancak sadece atandığı iş emirlerini görebilir. SQL seviyesinde bu, sorguya kullanıcı bağlamı eklenmesi anlamına gelir. Basit bir örnek:

SELECT * FROM work_orders
WHERE company_id = :companyId
  AND assigned_user_id = :currentUserId;

Bu kontrol sadece arayüzde yapılmamalıdır. API ve veritabanı sorgu katmanında da aynı mantık korunmalıdır. Aksi halde istemci tarafı manipülasyonuyla yetki aşımı oluşabilir.

Yetkilendirme modeli nasıl çıkarılır?

Başarılı projelerde yetki matrisi yazılım ekibi tarafından tek başına üretilmez. Süreç sahipleri, operasyon yöneticileri ve bilgi güvenliği sorumluları birlikte çalışır. Pratikte 60 ila 90 dakikalık 2 atölye oturumu bile yeterli olabilir. Amaç, ekran listesinden başlamak değil; iş akışlarını ve kritik karar noktalarını ortaya çıkarmaktır.

1. İşlem envanteri çıkarılır

İlk adımda sistemdeki kritik işlemler listelenir: kayıt oluşturma, güncelleme, silme, onaya gönderme, onaylama, iptal etme, dışa aktarma, fiyat değiştirme, kullanıcı tanımlama. Burada özellikle silme ve dışa aktarma işlemleri ayrı değerlendirilmelidir. Pek çok kurumda kayıt silme yerine pasife alma tercih edilir. Bu karar denetim izi açısından önem taşır.

2. Görevler ayrılığı belirlenir

Finans, satın alma, stok ve insan kaynakları süreçlerinde tek kişinin talep oluşturup aynı kaydı onaylaması çoğu zaman risklidir. Örneğin 100.000 TL üzeri satın alma taleplerinde iki aşamalı onay kurgulanabilir. İlk onay birim yöneticisinden, ikinci onay finans veya satın alma direktöründen gelir. Bu eşik uygulamaya parametre olarak işlenmelidir; sabit kod olmamalıdır.

3. Veri kapsamı tanımlanır

Aynı rol her veriye erişmez. Kısıtlar organizasyon, şirket, şube, bölge, proje, müşteri portföyü veya kayıt sahibi bazında olabilir. B2B platformlarda çok kiracılı yapı varsa tenant_id filtresi zorunludur. Bu filtre, en temel güvenlik katmanlarından biridir.

4. İstisnalar kontrollü tasarlanır

Her kurumda standart dışı ihtiyaçlar çıkabilir. Geçici proje ekibi, dış denetçi veya bölgesel yönetici gibi kullanıcılar için istisna erişimler gerekebilir. Bunları kalıcı manuel müdahalelerle çözmek yerine süreli yetki mekanizması tasarlamak daha güvenlidir. Örneğin bir kullanıcıya 7 gün boyunca ek rapor erişimi tanımlanabilir ve süre sonunda yetki otomatik olarak kaldırılır.

Güvenlik açısından kritik kontroller

Rol bazlı yetkilendirme tek başına tam güvenlik anlamına gelmez. Kimlik doğrulama, oturum yönetimi, parola politikaları ve denetim kayıtlarıyla birlikte düşünülmelidir. Özellikle yönetici rollerinde çok faktörlü kimlik doğrulama ciddi fark yaratır. Yönetici paneline sadece kullanıcı adı ve parola ile erişim verilmesi artık zayıf bir yaklaşım olarak kabul edilir.

API tabanlı sistemlerde her uç nokta için açık yetki kontrolü gerekir. Sık yapılan hatalardan biri, menüde görünmeyen bir işlemin erişilemez sanılmasıdır. Oysa kullanıcı doğrudan ilgili API isteğini gönderirse ve arka uç gerekli kontrolü yapmıyorsa işlem gerçekleşebilir. Bu yüzden UI gizleme ile yetkilendirme aynı şey değildir.

Bir diğer kritik alan loglamadır. En azından şu olaylar kayıt altına alınmalıdır: oturum açma denemeleri, başarısız girişler, rol değişiklikleri, yetki atamaları, kritik veri güncellemeleri, onay işlemleri ve dışa aktarımlar. Log kaydında zaman damgası, kullanıcı kimliği, IP bilgisi veya istemci bilgisi, işlem türü ve etkilenen kayıt kimliği bulunması denetim açısından büyük kolaylık sağlar.

Silme işlemlerinde “soft delete” yaklaşımı çoğu projede daha güvenlidir. Bir kaydın veritabanından tamamen silinmesi yerine deleted_at alanı ile işaretlenmesi, yanlış işlemlerin geri alınmasını ve geçmişin izlenmesini sağlar. Özellikle insan kaynakları, sözleşme ve finans kayıtlarında bu tercih yaygındır.

Operasyon kontrolü ve denetim izi nasıl sağlanır?

Yetkilendirme tasarımının gerçek değeri günlük operasyonda ortaya çıkar. Bir saha servis uygulamasında teknisyen iş emrini kapatabilir; ancak ücret değişikliği yapamaz. Çağrı merkezi kullanıcısı müşteri kaydı açabilir; ama KVKK açısından hassas alanları dışa aktaramaz. Bölge müdürü kendi ekibinin raporunu görebilir; tüm ülke verisine erişemez. Bu sınırlar net çizildiğinde hem hata azalır hem de ekipler sistem üzerinde daha rahat çalışır.

Denetim izi için her rol değişikliğinin versiyonlu tutulması faydalıdır. Örneğin bir kullanıcının 12 Mart 2026 tarihinde “Operasyon Uzmanı” rolünden “Operasyon Yöneticisi” rolüne geçtiği ve bu değişikliği hangi yöneticinin yaptığı kaydedilmelidir. İç denetim sırasında belirli bir tarihte kullanıcının hangi yetkilere sahip olduğu sorulabilir. Sadece mevcut durumun tutulması bu soruya cevap vermez.

Kurumsal projelerde onay akışları da yetki modelinin bir parçasıdır. İzin matrisinden ayrı ele alınırsa çakışmalar oluşur. Örneğin teklif onayı için rol yetkisi vardır; fakat sadece 500.000 TL altı teklifler tek kademede onaylanır, üstü için ikinci onay gerekir. Bu tür kural setleri ya iş akışı motorunda ya da merkezi yetki servisinde yönetilmelidir.

Teknik uygulamada sık yapılan hatalar

İlk hata, rolleri ekran isimlerine göre tanımlamaktır. “Rapor ekranı kullanıcısı” gibi roller iş karşılığı taşımadığı için zamanla çoğalır ve bakım maliyeti yükselir. İkinci hata, tüm kontrolleri istemci tarafına bırakmaktır. React, Vue veya mobil uygulamada butonu gizlemek yeterli değildir; API tarafı mutlaka karar vermelidir.

Üçüncü hata ise “süper admin” rolünün gereğinden fazla geniş ve izinsiz kullanılmasıdır. Her problemi süper admin ile çözmek kısa vadede kolay görünür. Birkaç ay sonra ise kimin hangi veriye neden eriştiği belirsizleşir. Süper admin erişimi gerekiyorsa ayrı log, MFA ve mümkünse IP kısıtıyla korunmalıdır.

Dördüncü hata, test senaryolarında yetkilendirmeyi yüzeysel ele almaktır. En azından her kritik işlem için pozitif ve negatif test gerekir. Yani işlemi yapabilen rol kadar, yapamaması gereken rol de test edilmelidir. 30 ana izin bulunan bir projede, yetki regresyon testleri CI/CD hattına dahil edildiğinde sürüm sonrası güvenlik hataları belirgin biçimde azalır.

Özel yazılım projelerinde sürdürülebilir yaklaşım

Yetkilendirme modeli yaşayan bir yapıdır. Şirket organizasyonu değişir, yeni şubeler açılır, farklı onay seviyeleri gerekir, dış sistem entegrasyonları devreye girer. Bu nedenle erişim modelinin kod içine dağılmış koşullarla değil, merkezi ve yönetilebilir bir yapı ile ele alınması gerekir. Küçük projelerde veritabanı tabanlı RBAC yeterli olabilir. Daha kompleks yapılarda merkezi kimlik sağlayıcı, SSO, grup senkronizasyonu ve politika tabanlı kontroller gündeme gelir.

Önemli olan en gelişmiş modeli baştan kurmak değil, gereksiz karmaşıklık oluşturmadan doğru temeli atmaktır. Net rol tanımları, işlem bazlı izinler, veri kapsamı filtreleri, denetim logları ve görevler ayrılığı; çoğu kurum için güçlü bir başlangıç sağlar. İyi tasarlanmış rol bazlı yetkilendirme, güvenlik ekibinin beklentisini karşılar, operasyon ekibinin işini yavaşlatmaz ve yazılımın ileride büyümesine engel olmaz.

Özel yazılım geliştirme sürecinde bu yapının analiz aşamasında ele alınması ciddi zaman kazandırır. Sonradan eklenen yetki katmanı çoğunlukla daha maliyetlidir. Projenin ilk sprintlerinde erişim matrisi, onay kuralları ve log stratejisi netleştirildiğinde hem teknik borç azalır hem de canlıya geçiş daha kontrollü ilerler.