Kurallardan önce aktörleri tasarlayın

Her kayda dokunan insanları ve sistemleri sıralayın: sahip, ekip üyesi, davetli, destek çalışanı, otomatik görev ve ziyaretçi. Ardından okuma, oluşturma, değiştirme, onaylama, arşivleme veya dışa aktarma gibi yetenekleri tanımlayın. “Giriş yapan kullanıcı” nadiren yeterli bir modeldir.

İlişkileri bilgi modeline koyun

Sahiplik ve üyelik açık olduğunda kurallar okunabilir olur. Sınırları belirli bir ekip rolünü anlamak, ilgisiz profil alanlarından çıkarılan erişimden daha kolaydır. Ayrıcalıklı işlemleri dar ve sıradan erişimden ayrı tutun.

  • Varsayılanı erişimsiz yapın ve yetenekleri bilinçli ekleyin.
  • Okuma, oluşturma, değiştirme ve silmeyi ayrı tanımlayın.
  • Yalnızca mutlu yolu değil, başka kişinin kimliklerini de test edin.
  • Davetli, askıda, arşivlenmiş ve silinmiş durumları ekleyin.
Ürün sonucu: destek ekibinin bir kaydı incelemesi gerekiyorsa bu yeteneği açıkça modelleyin. İç aracı kolaylaştırmak için herkesin erişimini gevşetmeyin.

Yetkiler arayüz davranışını değiştirir

Reddedilen güncelleme yalnızca sunucu hatası değildir. Arayüz erişimin değiştiğini, kaydın arşivlendiğini veya oturumun sona erdiğini açıklamalıdır. Yetki farkındalığı olan ürünler mevcut rolü gösterir ve imkânsız işlemleri istek başarısız olmadan açıklar.

Matrisi sürekli test edin

Ürün kurallarının yanında küçük erişim matrisi tutun ve sürekli çalıştırın. Her yeni ilişki veya durum yeni örnekler eklemelidir. Testler altyapı ayrıntısı yerine ürün kuralı gibi okunduğunda güvenlik anlaşılır kalır.

Bu kararları Ortiva vaka çalışmasında görün →