Müşteri Portalında Yetki ve Veri Görünürlüğü

Bir siparişi görmek isteyen kullanıcı hangi kurum adına çalışıyor, sipariş hangi kuruma ait ve bu kişinin o siparişi görüntüleme yetkisi var mı? Bu sorular yalnızca giriş ekranında cevaplanamaz. İstenen kayda ve yapılacak işleme göre değerlendirme gerekir.

Bir kişinin birden fazla kurumda görevi varsa aktif kurum seçiminin nasıl doğrulandığını belirleyin. Tarayıcıdan gönderilen kurum kimliği tek başına erişim kanıtı değildir. Davet, üyelikten çıkarma ve rol değişikliği bu ilişkinin yaşam döngüsüne dahil edilmelidir.

“Yönetici” ve “kullanıcı” etiketleri yerine erişilecek veri ve yapılabilecek işlemleri yazın. Aynı rol içinde kayıt sahibine göre değişen koşullar varsa matriste belirtin. Destek ekibinin müşteri adına yaptığı işlemler ayrıca sınırlandırılmalıdır.

OWASP, en az yetki verilmesini, açık izin yoksa erişimin reddedilmesini ve her istekte izin kontrolünü önerir. Menüde bir düğmeyi gizlemek kullanım deneyimini düzenler; aynı işlemin API üzerinden çağrılmasını tek başına engellemez.

Listeleme, tek kayıt okuma, düzenleme, toplu işlem ve dışa aktarma yollarını aynı politika kapsamında ele alın. Bir siparişe erişemeyen kullanıcının o siparişi arama sonucu, rapor toplamı veya dosya bağlantısı üzerinden öğrenip öğrenemediğini de sınayın. Projenin kullandığı önbellek ve arama sistemi bu incelemeye dahil olsun.

Bir dosyanın tahmin edilmesi zor adrese sahip olması yetkilendirme yerine geçmez. İndirme isteğinin ilgili kayıt yetkisini denetlemesini veya erişimin süre ve kapsamla sınırlandığı uygun bir mekanizma kullanmasını sağlayın. Paylaşılan bağlantının süresi ve iptal davranışı tasarımda açıklansın.

Rapor dışa aktarımları ve arka planda hazırlanan dosyalar için de aynı kurum sınırı korunmalıdır. Kullanıcının rolü rapor hazırlanırken değişirse dosyanın teslim anında nasıl kontrol edileceğini belirleyin. Bildirim metinlerinin yetkisiz kişiye kayıt içeriği taşımamasına dikkat edin.

İşten ayrılan çalışan veya yanlışlıkla davet edilen kişi için üyeliği kaldırma akışı bulunmalıdır. Oturum, erişim anahtarı ve önbellekteki izinlerin ne zaman geçersizleşeceğini yazın. Politika değişirken açık kalan bir sekmeden kritik işlem yapılıp yapılamadığını test edin.

Yetki değişikliği kaydında kim, hangi kapsamı, ne zaman değiştirdi bilgisi bulunabilir. Gereksiz kişisel veriyi kayda taşımadan olay takibi yapın. Destek erişimi geçici veriliyorsa başlangıç, bitiş ve inceleme sorumlusu belli olsun.

Yetkili kişinin işlem yapabildiğini görmek yeterli değildir. En az iki farklı kurum ve farklı yetki seviyeleriyle hazırlanmış kurgu test verisi kullanın. Testteki kullanıcıların gerçekten farklı kurumlara bağlı olduğunu doğrulayın.

Gereksinim analizi rehberi ile rolleri ve istisnaları belgeleyin; kabul testleri içinde olumsuz senaryoları çalıştırın. Portal başka sistemlerden veri alıyorsa API entegrasyonu kapsamını aynı sınırlarla değerlendirin.