Rol ve Yetki Yönetimi: Sonradan Eklenmesi En Pahalı Özellik

Neden baştan kurulmalı?

Yetki kontrolü, sisteme sonradan eklenen bir özellik değil, her ekranı ve her uç noktayı etkileyen bir katmandır.

Yüz ekranlı bir sisteme sonradan yetki eklemek, yüz ekranı tek tek gözden geçirmek demektir. Baştan kurulduğunda bu maliyet neredeyse sıfırdır.

İki farklı yetki türü

Aksiyon yetkisi: kullanıcı bu işlemi yapabilir mi? Teklif oluşturma, fiyat değiştirme, silme gibi.

Veri yetkisi: kullanıcı bu kaydı görebilir mi? Kendi müşterileri, kendi şubesi, tüm kayıtlar gibi.

Çoğu sistem birincisini yapar, ikincisini atlar. Oysa veri düzeyinde sızıntı daha tehlikelidir.

Sabit roller yetmez

"Yönetici, satış, muhasebe" gibi sabit üç rol, ilk yıl yeterli görünür. Sonra istisna talepleri gelir.

Esnek model şudur: roller tanımlanabilir olsun ve her role aksiyon listesi üzerinden yetki verilsin.

Kullanıcı bir role bağlanır, rolün yetkileri değiştiğinde tüm kullanıcılar etkilenir. İstisna gerekiyorsa yeni rol açılır, koda dokunulmaz.

Fiyat ve maliyet gizleme

Ticari sistemlerde en sık istenen özel yetki, maliyet ve kâr bilgisinin gizlenmesidir.

Bu, alan düzeyinde bir yetkidir ve hem ekranda hem de veri servislerinde uygulanmalıdır.

Alanı yalnız arayüzde gizlemek yeterli değildir; veri isteği doğrudan yapıldığında bilgi yine döner.

En kritik kural: kontrol sunucuda

Arayüzde düğmeyi gizlemek kullanıcı deneyimidir, güvenlik değildir.

Her uç nokta, çağıranın yetkisini kendisi kontrol etmelidir. Bu kontrolü çağıran katmana bırakan tasarımlar, eninde sonunda açık verir.

Kendi kod tabanlarımızda bu tür bir atlatma riskini denetleyip kapattık; bir uç noktanın "zaten sadece yetkili ekrandan çağrılıyor" varsayımıyla yazılması yaygın ve tehlikeli bir hatadır.

Menü ve navigasyon

Kullanıcı yetkisi olmayan menüleri görmemelidir. Erişemeyeceği sayfaları göstermek kafa karıştırır ve sistemin kapsamı hakkında bilgi sızdırır.

Menünün rollere göre dinamik üretilmesi, sabit menü tanımından daha sürdürülebilirdir.

Denetim kaydı

Kim ne zaman hangi kaydı değiştirdi? Bu bilgi, yetki sisteminin tamamlayıcısıdır.

Özellikle fiyat, stok ve finansal kayıtlarda değişiklik geçmişi tutmak, hem uyuşmazlıkları çözer hem de kötüye kullanımı caydırır.

Test edin

Her rol için bir test kullanıcısı oluşturun ve erişmemesi gereken sayfalara doğrudan adresle girmeyi deneyin.

Bu basit test, arayüzde gizlenmiş ama sunucuda korunmamış uç noktaları hızla ortaya çıkarır.

Yetki değişikliklerinin izlenmesi

Kimin kime hangi yetkiyi verdiği kayıt altında olmalıdır.

Yetki yükseltme işlemleri özellikle izlenmelidir; bir kullanıcının yönetici yetkisi alması denetlenebilir bir olay olmalıdır.

Ayrılan çalışanların erişimlerinin kapatılması için bir kontrol listesi bulundurun. Aktif kalan eski hesaplar, denetimlerde en sık bulunan açıklardan biridir.

Dış entegrasyonlarda yetki

Sisteminize bağlanan dış servisler için ayrı kimlikler tanımlayın, insan hesapları kullanmayın.

Bu kimliklere yalnız ihtiyaç duydukları yetkiyi verin. Entegrasyon için açılan tam yetkili hesaplar, en tehlikeli kısayollardandır.

Dış erişim anahtarlarının süresi olmalı ve dönemsel olarak yenilenmelidir.

Hangi anahtarın nerede kullanıldığı belgelenmelidir; belgelenmeyen anahtar, yenilenmesi gerektiğinde neyi bozacağı bilinmediği için yenilenmez.