Yazılımda rol ve yetki yönetimi nasıl kurulur?

Çok kullanıcılı bir sistemde en sık ertelenen konu yetkilendirmedir. Başlangıçta herkes aynı ekranları görür, çünkü ekip küçüktür ve kimse kimseden bir şey saklamaz. Ekip büyüdükçe bu kurgu iki ayrı sorun üretir: kullanıcılar işleriyle ilgisi olmayan ekranlar arasında kaybolur ve bir hata yapıldığında kimin yaptığı bulunamaz.

Rol tabanlı yetkilendirme

Yetkiyi kullanıcıya tek tek vermek, kullanıcı sayısı arttığında yönetilemez hâle gelir. Doğru model rol tabanlıdır: yetkiler rollere bağlanır, kullanıcılar rollere atanır. Yeni bir depo görevlisi işe başladığında ona tek tek yetki verilmez, "depo" rolüne eklenir.

Rollerin iş unvanlarıyla birebir aynı olması gerekmez. Bir kişi birden fazla rol taşıyabilir; küçük işletmelerde muhasebe ve satın alma rolleri aynı kişide olabilir. Önemli olan rolün bir görevi tanımlaması, bir kişiyi değil. Kişiye özel açılan roller zamanla çoğalır ve modelin sağladığı düzeni ortadan kaldırır.

En az yetki ilkesi

Yetkilendirmede başlangıç noktası "herkese her şey açık, gerekirse kapatırız" olmamalıdır. Tersi doğrudur: varsayılan kapalıdır, iş için gereken açılır. Buna en az yetki ilkesi denir ve etkisi iki yönlüdür.

Birincisi güvenliktir: bir hesabın ele geçirilmesi hâlinde erişilebilecek veri, o hesabın yetkisiyle sınırlı kalır. İkincisi sadeliktir: kullanıcı yalnızca işini yapacağı ekranları görür, menüde aradığını bulması kolaylaşır ve yanlış ekranda işlem yapma ihtimali düşer.

Yetki yalnızca menüde değil, sunucuda kontrol edilir

Sık yapılan bir hata, yetkilendirmeyi yalnızca arayüzde yapmaktır: kullanıcının yetkisi yoksa menüde o bağlantı görünmez. Ama bağlantı görünmüyor olması adresin çalışmadığı anlamına gelmez. Adresi bilen bir kullanıcı doğrudan yazarak sayfaya ulaşabilir.

Bu yüzden her yetki kontrolü sunucu tarafında, işlem yapılmadan hemen önce tekrarlanmalıdır. Arayüzdeki gizleme bir kolaylıktır, bir güvenlik önlemi değildir. Aynı kural veri okuma için de geçerlidir: bir listeyi getiren uç, kullanıcının görmeye yetkili olduğu kayıtlarla sınırlı sonuç dönmelidir.

Satır bazlı yetki

Bazı durumlarda ekran yetkisi yetmez. Bir satış temsilcisinin sipariş ekranını görmesi gerekir ama yalnızca kendi müşterilerinin siparişlerini. Bir şube müdürünün stok ekranını görmesi gerekir ama yalnızca kendi şubesinin stoğunu.

Buna satır bazlı yetki denir ve ekran yetkisinden ayrı tasarlanmalıdır. Kullanıcıya bir kapsam tanımlanır (hangi şube, hangi müşteri grubu, hangi bölge) ve tüm sorgular bu kapsama göre süzülür. Bu süzme tek bir yerde, veri erişim katmanında yapılmalıdır; her ekranda ayrı ayrı yazılan süzgeçlerden biri unutulduğunda sızıntı oluşur.

Hassas işlemler için ek onay

Bazı işlemler geri alınamaz ya da parasal etkisi büyüktür: fiyat değişikliği, iade onayı, stok düzeltmesi, kullanıcı yetkisi verme. Bu işlemler için yetki vermek yeterli değildir; ikinci bir onay adımı eklenmesi mantıklıdır.

Onay mekanizması basit tutulabilir: işlem oluşturulur, onay bekleyen listesine düşer, yetkili kişi onaylar ve ancak o zaman uygulanır. Kritik işlemlerde onaylayanın işlemi oluşturan kişiden farklı olması şart koşulmalıdır. Bu ayrım, iç kontrolün en temel kuralıdır ve küçük ekiplerde bile uygulanabilir.

İz kaydı: kim, ne zaman, neyi değiştirdi

Yetkilendirmenin tamamlayıcısı iz kaydıdır. Her önemli değişiklik için kimin yaptığı, ne zaman yaptığı, hangi kaydı değiştirdiği ve değerin eski ile yeni hâli saklanmalıdır.

Bu kayıt silinebilir olmamalıdır. Kullanıcıların kendi iz kayıtlarını düzenleyebildiği bir sistem, iz kaydı tutmuyor demektir. Ayrıca iz kaydını görüntüleme yetkisi ayrı bir yetki olmalıdır; herkesin herkesin ne yaptığını görmesi gerekmez.

Ayrılan kullanıcı ve düzenli gözden geçirme

Yetki yönetiminin en çok ihmal edilen tarafı kapatmadır. İşten ayrılan kullanıcının hesabı silinmemeli, pasife alınmalıdır: hesap silinirse geçmiş kayıtlardaki "bu işlemi kim yaptı" bilgisi de kaybolur.

Ayrıca yetkiler düzenli aralıklarla gözden geçirilmelidir. Görev değiştiren kullanıcıların eski yetkileri çoğu zaman kaldırılmaz ve zamanla birkaç kişi farkında olmadan neredeyse tam yetkili hâle gelir. Altı ayda bir alınacak basit bir rapor, kimin hangi rolde olduğunu ve son ne zaman giriş yaptığını göstererek bu birikmeyi önler.

Kişisel veriye erişim ayrı düşünülür

Müşteri adı, telefonu, adresi ve kimlik bilgisi kişisel veridir ve bunlara erişim, diğer yetkilerden ayrı ele alınmalıdır. Bir raporu alabilmek için müşterinin telefon numarasını görmek gerekmiyorsa, o alan rapor ekranında maskelenmelidir.

Maskeleme basit bir önlem gibi görünür ama etkisi büyüktür: dışarı çıkan ekran görüntülerinde, paylaşılan raporlarda ve destek taleplerinde kişisel veri yayılmaz. Tam numaranın gerektiği durumlar için ayrı bir "göster" yetkisi tanımlanır ve bu yetkinin her kullanımı iz kaydına yazılır.

Oturum süresi ve ikinci doğrulama

Yetkilendirmenin bir de zaman boyutu vardır. Açık kalan bir oturum, bilgisayarın başından kalkan kullanıcının yetkisini o makineyi kullanan herkese devreder. Bu yüzden hareketsiz kalan oturumlar belirli bir süre sonra kapanmalı, süre yetkinin genişliğine göre kısaltılmalıdır.

Yönetici yetkisi taşıyan hesaplarda ikinci bir doğrulama adımı önerilir. Parolaya ek olarak telefondaki bir uygulamadan okunan kodun istenmesi, parolanın ele geçirilmesi hâlinde bile girişi engeller. Bu önlem yalnızca geniş yetkili hesaplar için zorunlu tutulsa bile riskin büyük kısmını kapatır.