Bir yönetim panelinde bütün çalışanlara aynı hesabı vermek başlangıçta kolay görünür. Ancak bir fiyat değiştiğinde, kayıt silindiğinde veya müşteri bilgisi dışarı aktarıldığında sorumluluk belirsizleşir. Rol ve yetki tasarımı, çalışanların işini yapmasını sağlarken gereksiz erişimi sınırlamaktır. Bu çalışma yalnızca güvenlik ekibine ait değildir; süreç sahiplerinin hangi işlemin kim tarafından yapılacağını tarif etmesi gerekir.
Ekranlardan önce işlem matrisini çıkarın
Görüntüleme, oluşturma, düzenleme, yayınlama, silme ve dışarı aktarma farklı yetkilerdir. Bir editör yazı hazırlayabilir ama yayına alamayabilir. Bir destek çalışanı siparişi görebilir ama fiyat politikasını değiştiremez. Her rolün gerçekten ihtiyaç duyduğu işlemleri listeleyin. “Yönetici” gibi geniş adların içine bütün hakları koymadan önce daha dar sorumlulukların yeterli olup olmadığını değerlendirin.
Kayıt düzeyindeki sınırları unutmayın
Aynı tür işlem farklı kayıtlar için farklı yetki gerektirebilir. Şube çalışanı kendi şubesinin başvurularını görebilir, diğer şubeninkini göremeyebilir. Müşteri portalında her müşteri yalnızca kendi belgelerine erişmelidir. Bu kurallar sunucuda doğrulanmalıdır; menüyü veya düğmeyi saklamak tek başına erişimi engellemez. API üzerinden yapılan istekte de aynı sınırlar uygulanmalıdır.
Örnek bir içerik ekibinde taslak hazırlama, görsel ekleme ve yayın onayı ayrılabilir. Acil bir düzeltme için kimin yetkili olduğu da belli olsun. Her işlemde ikinci onay istemek işi gereksiz yavaşlatabilir; buna karşılık bütün katalog fiyatını değiştiren toplu işlem daha güçlü kontrol gerektirebilir. Onay ihtiyacını işlemin etkisine ve geri alınabilirliğine göre seçin.
Kişisel hesap ve erişim yaşam döngüsü kurun
Yeni çalışan eklendiğinde, rolü değiştiğinde ve işten ayrıldığında uygulanacak adımları yazın. Paylaşılan şifre yerine kişiye ait hesaplar kullanın. Kritik rollerde uygun ek doğrulama yöntemlerini değerlendirin. Oturum süresi ve yeniden doğrulama ihtiyacı işin bağlamına göre belirlenmelidir. Bir hesabın devre dışı bırakılmasının mevcut oturumlara etkisini test edin; yalnızca listede pasif görünmesi yeterli olmayabilir.
Önemli değişiklikleri izlenebilir tutun
Kim, ne zaman, hangi kaydı ve hangi işlemle değiştirdi bilgisi sorun araştırmada değerlidir. Günlüklere şifre, erişim anahtarı veya gereksiz kişisel veri yazmayın. Kayıtların kendisine de erişim kontrolü gerekir. Değişiklik geçmişi kullanıcıyı suçlamak için değil, hatanın kapsamını anlamak ve gerektiğinde düzeltmek için tasarlanmalıdır. Kritik toplu işlemlerde önceki değerleri güvenli biçimde koruma ihtiyacını değerlendirin.
- Her rolün işlem ve kayıt sınırları yazılı mı?
- Yetki sunucuda, her ilgili istekte kontrol ediliyor mu?
- Pasif hesapların eski oturumları uygun biçimde sonlanıyor mu?
- Toplu ve geri dönüşü zor işlemler ayrı ele alınıyor mu?
- Denetim kayıtları sır veya gereksiz kişisel veri içeriyor mu?
İzin verilen kadar reddedileni de deneyin
Test hesabıyla normal görevleri tamamlayın; ardından o rolün görmemesi gereken örnek kayda erişimi kontrol edin. Bir rolün hiçbir şey yapamaması da gereğinden fazla yetki kadar işlevsel bir sorundur. Yetki matrisini kabul testlerine bağlayın. Yeni bir API veya ekran eklendiğinde aynı kuralların uygulanması gerektiğini teslim kontrolüne ekleyin; yetki modeli yazılım büyürken kendiliğinden korunmaz.
Teknik yaklaşım için OWASP yetkilendirme rehberi kullanılabilir. Kabul testi rehberi rol senaryolarını teslim kapsamına taşır. Yönetim paneli projelerimizde yetkiyi ilk tasarım kararlarından biri yapıyoruz.