Yazılım yetkilendirme: Rol listesi neden tek başına yetmez?

Yönetim panelinde üç rol tanımlanmış: yönetici, çalışan ve müşteri. İlk bakışta yetkilendirme tamamlanmış görünür. Sonra aynı müşteri grubundaki iki kullanıcının birbirinin kayıtlarını görmemesi gerektiği anlaşılır. Bir çalışan yalnızca kendisine atanan işi değiştirebilirken ekip yöneticisi belirli kayıtları onaylayabilir. Rol adları bu ayrıntıları tek başına anlatmaz. Yazılım yetkilendirme tasarımı, kişinin kim olduğunu bilmekle hangi işlem için hangi kayda erişebileceğini belirlemeyi birbirinden ayırmalıdır.

Bu yazı, kurgusal bir hizmet portalı üzerinden ilerliyor. Müşteri talep açıyor, çalışan işi yürütüyor ve yetkili kişi bazı durumlarda onay veriyor. Örnek, belirli bir ürünün güvenlik değerlendirmesi değildir. Amaç rol listesini iş kuralları, kayıt ilişkileri ve test senaryolarıyla tamamlamaktır. Yetkilendirme yalnızca ekranda düğme gizleme işi olarak ele alınamaz. Kullanılan teknoloji ve ortam için teknik uygulama ayrıca değerlendirilir; iş tarafının kararları da geliştiricinin tahminine bırakılmamalıdır.

Kimlik doğrulama ile işlem yetkisini ayırın

Kullanıcının giriş yapmış olması, sistemdeki her kaydı okuyabileceği veya değiştirebileceği anlamına gelmez. Kimlik doğrulama hesabın kimliğine, yetkilendirme ise istenen işlemin uygunluğuna ilişkin farklı kontrollerdir. Portal örneğinde müşteri kendi talebini görebilir ama başka müşterinin talebini göremez. Aynı kullanıcı bir projede yetkili, başka projede izleyici olabilir. Bu ilişkiler rol adının yanında değerlendirilmelidir. Giriş ekranının çalışması erişim kurallarının doğru uygulandığını kanıtlamaz.

İşletme tarafında bu ayrımı örneklerle konuşun. Bir kişi hangi veriyi neden görmeli, hangi işlemi neden yapmamalı? “Bizim ekip görsün” ifadesi bazen fazla geniş kalır. Aynı ekipte farklı görevler olabilir. İşi yapmak için gereken yetki seçilir; gereksiz kapsam varsayılan olarak eklenmez. Tanımlanmamış durumda erişimin nasıl ele alınacağı da açık olmalıdır. Yeni bir ekran veya veri türü geldiğinde kontrolün unutulmaması için bu kararlar ortak bir tasarım yaklaşımına bağlanır.

Kayıt, işlem ve koşulu aynı cümlede tarif edin

Yetki tanımını yalnızca “talep modülüne erişim” diye yazmak eksiktir. Okuma, oluşturma, düzenleme, onaylama, iptal etme ve dışarı aktarma farklı işlemlerdir. Hangisinin hangi kayıtta yapılabildiği belirtilmelidir. Örneğin çalışan kendisine atanan açık talebi güncelleyebilir; kapanmış talebin sonucunu değiştirmek ayrı yetki gerektirebilir. Bu koşul, işlemin adıyla birlikte yazıldığında geliştirici ve işletme aynı durumu değerlendirebilir. Genel bir izin kutusunun arkasındaki davranış görünür olur.

Zaman veya kayıt durumu bazı işlerde önemlidir. Bir belge onaylandıktan sonra kimin değiştirebileceği, geçici görevlinin erişiminin ne zaman biteceği belirlenir. Her projeye karmaşık bir koşul sistemi eklemek gerekmez. Gerçek ihtiyacın hangi değişkene bağlı olduğu anlaşılmalıdır. Fazla ayrıntılı ama kullanılmayan yetki ayarları yönetimi zorlaştırabilir. Aşırı basit rol listesi ise kritik ayrımı saklayabilir. Doğru tasarım, işin gerçek kurallarını anlaşılır ve sürdürülebilir biçimde uygulamayı hedefler.

Müşteri ve kurum sınırlarını açıkça kurun

Bir uygulama birden fazla kurum veya müşteri için çalışıyorsa verinin hangi sınıra ait olduğu önemlidir. Kullanıcının hangi çalışma alanına bağlı olduğu, bir kaydın hangi kuruma ait bulunduğu ve geçiş yetkileri değerlendirilir. Kullanıcının gönderdiği bir tanımlayıcı tek başına erişim hakkı sayılmamalıdır. Uygulamanın güvenilir bağlamı ve kayıt ilişkileri kontrol edilmelidir. Aksi hâlde aynı role sahip kullanıcılar arasında bile yanlış görünürlük oluşabilir. Teknik ekip sınırın her ilgili işlemde korunduğunu sınamalıdır.

Kurgusal portalda iki müşterinin aynı “müşteri” rolünde olması birbirlerinin taleplerine erişebilecekleri anlamına gelmez. Aynı şekilde bir kurum içindeki şube veya proje ayrımı da önem taşıyabilir. Hangi ayrımın zorunlu olduğunu işletme açıkça tarif eder. Tasarımda ortak liste kullanılıyorsa filtreleme ve erişim kontrolünün farkı unutulmamalıdır. Kullanıcıya dar liste göstermek, arka plandaki bütün erişim yollarını kendiliğinden sınırlandırmaz. İş kuralı veri ve servis tarafında uygun biçimde uygulanmalıdır.

Görünmeyen erişim yollarını da inceleyin

Arayüzde düğmeyi kaldırmak kullanıcı deneyimini düzenleyebilir; fakat yetki kararı yalnızca tarayıcıdaki görünüme dayanmamalıdır. Sunucunun işlem için uygun kontrolü yapması gerekir. API, dosya indirme, arama ve rapor gibi yollar da aynı veri sınırını korumalıdır. Bir ekran doğru davranırken dışarı aktarma bütün kayıtları döndürüyorsa kural eksik uygulanmış olabilir. Bu yüzden kaynakları ve işlemleri birlikte envantere almak yararlıdır. Görsel inceleme tek test yöntemi olarak kalmamalıdır.

Dosyalar özel dikkat gerektirebilir. Bir belgenin kayıtta görünmemesi, doğrudan erişim yolunun da uygun biçimde korunduğunu göstermeyebilir. Hangi dosyanın herkese açık, hangisinin kullanıcı veya kayıt yetkisine bağlı olduğu belirlenir. Aynı düşünce arka planda oluşturulan raporlar için geçerlidir. Sonuç dosyası kimin adına ve hangi veri kapsamıyla üretildi? Yetki, üretim anında ve sonuca erişimde gerekli koşullarla değerlendirilmelidir. Uygun teknik yöntem, dosyanın ve sistemin kullanımına göre seçilir.

Toplu işler tek kayıt kontrolünü atlamasın

Kullanıcı birden fazla kaydı seçip işlem yaptığında her kaydın uygunluğu düşünülmelidir. Tek bir doğru yetki kontrolü, listedeki bütün kayıtlar için yeterli olmayabilir. Arka plan işi daha sonra çalışıyorsa yetki değişikliği veya kayıt durumu etkisi de değerlendirilir. Bu senaryolar bazı projelerde önemli, bazılarında kapsam dışı olabilir. Önemli olan varsayımı açık etmektir. Görünürde küçük bir toplu işlem, farklı veri sınırlarını bir araya getirebilir. Tasarım ve test buna göre planlanmalıdır.

Yetki matrisini gerçek senaryolara bağlayın

Kullanıcı türü, kayıt kapsamı, işlem, koşul ve beklenen sonuç alanlarıyla bir çalışma tablosu hazırlanabilir. Her hücreye genel izin işareti koymak yerine örnek yazın. Müşteri kendi açık talebine ek bilgi ekleyebilir; başka müşterinin talebine erişemez. Çalışan atandığı kaydı günceller; onay yetkisi yoksa sonucu onaylayamaz. Bu cümleler hem kapsamı hem test beklentisini anlatır. İşletme, soyut güvenlik terimleri kullanmadan kurallarını doğru aktarabilir.

Matrisin sahibi belli olsun. Yeni rol veya işlem eklendiğinde hangi kayıtlar güncellenecek? İzinler farklı ekiplerin ayrı tablolarında tutulursa çelişki oluşabilir. Ortak tanım, teknik uygulamanın izlenebilir referansı olabilir. Özel Yazılım Projeleri kapsamında bu işi ihtiyaç analizi ve kabul koşullarıyla birlikte ele almak, yetkinin sonradan eklenen belirsiz ayar olmasını önler. İşin kapsamı değiştiğinde erişim beklentisi de aynı karar sürecinde değerlendirilir.

İzin verilen kadar reddedilmesi gerekeni test edin

Kullanıcının kendi kaydını açabilmesi olumlu senaryodur. Başka kullanıcının kaydına erişememesi de ayrıca sınanmalıdır. Yanlış rol, farklı kurum ve uygun olmayan kayıt durumu gibi örnekler seçilir. Testler yalnızca ekrandaki menüye bakmaz; ilgili işlem ve veri yollarını da kontrol eder. İnceleme uygun test ortamında ve yetkili kapsamda yürütülür. Amaç sistemi tahminle güvenli kabul etmek değil tasarlanan sınırın gerçekten uygulandığını gösteren kanıt oluşturmaktır.

Bir hata bulunduğunda benzer yollar da değerlendirilir. Tek bir ekrandaki düzeltme bütün kaynakları kapsamayabilir. Yetki kuralının ortak uygulanması ve uygun testlerin tekrar çalıştırılması sürdürülebilirliği destekler. Otomatik kontrol yararlı olabilir; fakat işletmenin yanlış tarif edilmiş kuralını doğru uygulaması yine yanlış iş sonucu oluşturabilir. Bu yüzden iş senaryosu incelemesiyle teknik test birbirini tamamlar. Hangi davranışın beklenmesi gerektiği ve bunun nasıl doğrulandığı birlikte anlaşılmalıdır. Test kaydı, gelecekteki değişikliklerde referans olur.

Rol değişimi ve erişim kapanışı günlük işin parçasıdır

Çalışan görev değiştirdiğinde eski erişimi sürmemelidir diye düşünülüyorsa bunun nasıl uygulanacağı tasarlanır. Yeni görev eklenmesi eski yetkileri otomatik koruyabilir; bu davranış kontrol edilmelidir. Geçici görevlendirme ve dış ekip erişimi için uygun bitiş düzeni bulunabilir. Her işletmeye aynı yöntem önerilmez. Önemli olan erişimin yalnızca verildiği gün değil ihtiyaç değiştiğinde de yönetilmesidir. Yetkinin sahibi ve değişikliği onaylayacak kişi belli olmalıdır.

Oturum, önbellek veya devam eden işler yetki değişikliğinin ne zaman etkili olacağını değiştirebilir. Teknik ekip gerekli davranışı ve sınırı açıklar. İşletme hangi işlemlerde anında kapanış beklendiğini belirtir. Bu konu varsayımla bırakılırsa ekranda rol değişmiş görünürken başka yol eski bilgiyle devam edebilir. İlgili senaryolar test planına alınır. Erişim yönetimi, tek bir kullanıcı kaydını düzenlemekten daha geniş bir yaşam döngüsüdür; başlangıç, değişim ve kapanış birlikte düşünülmelidir.

Kayıt tutma ve inceleme uygun kapsamda yapılsın

Önemli yetki değişiklikleri ve reddedilen işlemler araştırma için bilgi sağlayabilir. Hangi olayın kaydedileceği, kimin inceleyebileceği ve hassas bilginin nasıl korunacağı belirlenir. Kayıt dosyasına gereksiz müşteri ayrıntısı veya erişim sırrı eklenmez. Amaç her hareketi yığmak değil gerektiğinde hangi kontrolün hangi işlemde devreye girdiğini anlayabilmektir. Uygun gözlem olmadan yetki sorununu teşhis etmek zorlaşabilir. Bununla birlikte kayıt tutma da kendi erişim ve bakım sorumluluğunu gerektirir.

Portal örneğimize dönersek “müşteri” rolünün oluşturulması işin başlangıcıdır. Kendi kayıtları, izinli işlemler, dosyalar, raporlar ve görev değişiklikleriyle ilişkisi tanımlandığında kullanılabilir bir yetki düzeni ortaya çıkar. Yeni iş eklendiğinde aynı sorular yeniden sorulur. Kullanıcı ne yapabilir, hangi kayıtta, hangi koşulla ve hangi kontrolle? Bu soruların cevabı tasarımda, uygulamada ve testte aynı anlama geldiğinde rol listesi gerçek bir erişim politikasına dönüşür. Yönetim ekranı da bu politikanın anlaşılır uygulama yolu olur.

Aynı talepte üç kullanıcıyı karşılaştırın

Kabul incelemesinde bir örnek talebi müşteri, atanmış çalışan ve onay yetkilisi açısından ele alın. Müşteri ek bilgi sunabilir ama çalışan sonucunu onaylayamaz. Çalışan işi güncelleyebilir ama yetkisi yoksa onay veremez. Yetkili kişi uygun durumdaki sonucu inceler. Sonra aynı işlemleri başka müşteriye ait örnekte değerlendirin. Bu basit karşılaştırma, rol adının yanında kayıt ilişkisi ve işlem koşulunun neden gerekli olduğunu gösterir. Beklenen davranışlar önceden yazılır; inceleme, yalnızca ekranda hangi düğmenin göründüğünü saymakla sınırlı kalmaz.

Sık Sorulan Sorular

Kullanıcı giriş yaptıysa erişim kontrolü tamam mı?

Hayır. Kimlik doğrulama kişinin hesabını tanımaya, yetkilendirme ise istediği işlemin uygunluğunu değerlendirmeye yöneliktir. Giriş yapan kişi her kaydı veya işlemi kullanamaz. Kendi verisi, başka kullanıcının verisi ve farklı kurum sınırları ayrı değerlendirilmelidir. Testler bu ayrımları gerçek senaryolarla göstermelidir; yalnızca giriş ekranının çalışması yeterli kanıt değildir.

Menü veya düğme gizlemek yeterli mi?

Arayüz düzeni kullanıcıya rehberlik eder, fakat yetki kontrolü yalnızca görünüme dayanmamalıdır. İlgili servis, veri ve dosya erişimleri uygun biçimde korunmalıdır. API ve dışarı aktarma gibi yollar da incelenir. Bir ekranda görünmeyen bilginin başka yoldan erişilebilir kalmaması gerekir. Teknik uygulama kullanılan sistemin yapısına göre değerlendirilir.

Her iş için yeni rol açmalı mıyız?

Gereksinime bağlıdır. Çok sayıda rol yönetimi zorlaştırabilir; tek geniş rol de gerekli ayrımları gizleyebilir. Kayıt ilişkisi, işlem ve durum koşulları birlikte düşünülmelidir. Hangi kuralın rol ile, hangisinin başka bağlamla ifade edileceği teknik tasarımda seçilir. Amaç isim sayısını artırmak değil işin erişim sınırını anlaşılır biçimde uygulamaktır.

Yetki testlerinde neye bakmalıyız?

İzin verilen ve reddedilmesi gereken örnekleri birlikte seçin. Farklı kullanıcı, kurum, işlem ve kayıt durumu senaryoları önem taşıyabilir. Dosya ve rapor yolları da kapsamda değerlendirilir. İnceleme yetkili test ortamında yürütülür. Beklenen davranış işletmeyle birlikte açık tanımlanırsa teknik sonuç doğru bir iş kuralına karşı kontrol edilebilir.

Görev değişince yetkiler nasıl güncellenmeli?

Eski görevin erişimleriyle yeni ihtiyacı birlikte inceleyin. Kimin onaylayacağı ve değişikliğin ne zaman etkili olacağı belirli olsun. Oturum veya devam eden işler gibi teknik etkiler değerlendirilir. İşletmenin erişim kapanışı beklentisi açık yazılır ve uygun senaryoyla doğrulanır. Bir rol adının değişmesi bütün erişim yaşam döngüsünün tamamlandığını tek başına göstermez.