Müşteri portalında kim hangi belgeyi görebilmeli?
Bir müşteri portalında fiyat teklifi, çizim ve teslim belgesi aynı menüde bulunabilir. Ancak bu belgelerin aynı kişiler tarafından görülmesi gerekmez. Tasarım başlamadan “müşteri giriş yapar ve dosyaları görür” cümlesini daha küçük kararlara ayırın. Kullanıcının hangi firmaya bağlı olduğu, neyi yapabildiği ve hangi belge üzerinde işlem yaptığı birlikte düşünülmelidir. Buradaki firma ve kişiler tamamen temsili çalışma örnekleridir.
İşe ekranlardan değil görevlerden başlayın
İlk toplantıda menü listesini çıkarmak yerine üç gerçek iş tarif edin: satın alma sorumlusu teklif indirir, teknik çalışan onaylı çizimi açar, firma yöneticisi çalışma arkadaşını davet eder. Bu görevlerin her birinin sahibi ve sınırı farklıdır. Herkese yönetici vermek kısa süreli bir kolaylık sağlayabilir, fakat daha sonra hangi erişimin gerekli olduğunu ayırmayı zorlaştırır. Başlangıç tablosunu küçük ve okunabilir tutun.
Giriş yapmak ile izinli olmak farklıdır
OWASP yetkilendirme rehberi, kimlik doğrulama ile kaynak erişimini ayırır. Gerekli en düşük yetkiyi vermeyi, tanımlanmamış erişimi varsayılan olarak reddetmeyi ve izni her istekte denetlemeyi önerir. Menüden bir bağlantıyı gizlemek sunucudaki izin kontrolünün yerine geçmez. Kontrol, istenen belgeyi ve kullanıcıyla ilişkisini de kapsamalıdır.
Firma ve görevi aynı tabloda gösterin
Temsili A firmasının satın alma çalışanı A firmasına ait teklifi görebilir; B firmasının teklifini göremez. A firmasının teknik çalışanına yalnız onaylı çizimler açılabilir. Kullanıcı davet etme yetkisi ayrıca tanımlanır. Tabloya “belge görme”, “belge yükleme” ve “kullanıcı yönetme” sütunları ekleyin. Bu düzen, tasarım ekibinin tek bir geniş “müşteri” rolüyle bütün işlemleri eşitlemesini önlemeye yardımcı olur.
İstisnayı sessiz bir kalıcı yetkiye dönüştürmeyin
Dışarıdan çalışan bir uzmana tek proje için erişim gerekiyorsa bunu genel firma üyeliğiyle karıştırmayın. Hangi proje, hangi belgeler ve hangi çalışma dönemi için erişim gerektiğini yazın. Süre sonunda kimin kontrol edeceği belli olsun. Bir kişi iki firmayla çalışıyorsa aktif firma seçimi açık görünmelidir. Kullanıcı arayüzündeki bu açıklık, sunucu denetimiyle desteklenmesi gereken bir tasarım kararıdır.
Olumsuz senaryoyu teslim testine ekleyin
Yalnız yetkili kişinin dosyayı açması başarı ölçütü değildir. Test ortamında temsili A ve B hesaplarıyla, başka firmaya ait bilinen bir belge bağlantısının reddedildiğini kontrol edin. Gerçek müşterilerin özel belgelerini test verisi yapmayın. Reddedilen ekranda belgenin adı veya içeriği gereksiz yere açığa çıkmasın. İzin verilmeyen durumda kullanıcının kendi alanına dönebileceği anlaşılır bir yol sunun.
Görev değişikliğini bir bakım işi olarak tanımlayın
Bir çalışan ayrıldığında veya görevi değiştiğinde hangi erişimlerin gözden geçirileceğini teslim belgesine yazın. Yetkiyi kaldırma, bekleyen davetler ve mevcut paylaşım bağlantıları ayrı kontrol noktalarıdır. Yeni bir rol eklendiğinde eski rollerin kendiliğinden genişlememesi için tabloyu yeniden değerlendirin. Tasarımın yalnız ilk kurulumdaki personel listesine uygun olması yeterli değildir; sonraki değişiklikleri yönetecek kişi ve işlem de belli olmalıdır.
Kapsamı teklif aşamasında görünür kılın
Erişilebilir giriş rehberi kimlik bilgilerinin kullanılmasını ele alır; bu yazı girişten sonraki izin sınırlarını tanımlar. Web projesi kapsamına rol tablosunu, belge sınırlarını ve test senaryolarını ekleyin. Bu belge tek başına güvenlik denetimi veya tam güvenlik garantisi değildir. Ancak ekiplerin aynı portal davranışını tarif etmesini ve eksik kararları uygulamadan önce görmesini sağlar.
Sık sorulan sorular
Gizli menü öğeleri yeterli mi?
Hayır. Doğrudan belge isteğinde de sunucu tarafında yetki kontrolü yapılmalıdır; görünürlük yalnız arayüzün bir parçasıdır.
Küçük bir portalın rol tablosuna ihtiyacı var mı?
İki farklı belge kapsamı veya görev varsa küçük bir tablo bile kararları netleştirir. Gereksiz rol çeşitliliği oluşturmadan başlayabilirsiniz.