Hesap Yönetimi (devam)
Önceki yazıda kullanıcının kim olduğunu aldıktan sonra kullanıcının erişim yetkilerinin kontrolü aşamasına geliyoruz. Soru şu: X kullanıcısı Y işlemini yapmaya yetkili mi?
2. RBAC vs ABAC: X kullanıcısı Y işlemini yapmaya yetkili mi?
Brute force bir kod yazma sürecine başlarsanız aklınıza ilk gelecek olan şey X kullanıcıları ve Y işlemlerini birbirine bağlayan bir mekanizma kurmak olacaktır. İlişkisel veritabanı kullanmaya alışkınsanız ilk olarak bir ISLEM tablosu oluşturmak ve bunu KULLANICI tablosu ile ilişkilendirmeyi deneyebilirsiniz. Ancak many-to-many bir ilişki olduğundan bir ISLEM_KULLANICI_MAPPING tablosu oluşturmayı, kullanıcı id’si ve işlem id’si ile bağlanan bir eşleştirme işlemiyle kontrolü sağlayabilirsiniz.
Ancak uygulama geliştikçe yeni özellikler gelecek, mevcut özellikler değişecek ya da silinecektir. Bunun yanında kullanıcıların sayısı da artınca tek tek kontrol etmek masraflı bir hale gelecektir. Zira m adet kullanıcı ve n adet ilişkiyi kontrol etmek m x n kez kontrol gerektirir. Karmaşıklığı O(n²) olacaktır ve takdir edersiniz ki bu pek arzu edilen bir durum değildir.
Bu konuda bir soyutlamaya gideceğiz ve kullanıcıları doğrudan işlemlere yetkilendirmek yerine bir rol mekanizması kurabiliriz. Örneğin bir CMS için kullanıcı hesapları ve site ayarlarını yöneten bir siteAdmin, alt sayfaların tasarımı ve içeriğinden sorumlu bir pageAdmin, yalnızca duyuru, etkinlik gibi içerik girmekle yetkili bir author rolü başlangıç için yeterli olabilir. Bu durumda
- KULLANICI
- ROL
- ISLEM
tabloları ve
- KULLANICI_ROL
- ROL_ISLEM
mapping tabloları ile çok basit bir erişim kontrol düzeneği sağlanmış olacaktır. İstenirse yetkiler de içeriğe göre kategorilere ayrılabilir.
Bu şekilde uyguladığımız erişim kontrol sistemlerine Role Based Access Control (RBAC, Rol Tabanlı Erişim Kontrolü) diyoruz. Peki başlıkta yanında yer alan ABAC ne?
Attribute Based Access Control (ABAC, Nitelik Tabanlı Erişim Kontrolü), ise niteliklere dayanır. Bunlar, kullanıcılara ait nitelikler (çalıştığı departman, şube, bayii vs.), erişilecek uygulamaya ait nitelikler (uygulamanın taşıdığı verinin neleri kapsadığına göre, uygulamanın hangi veriyi değiştirebileceğine göre vs.), ve çevresel koşullar (mesai saatleri ve günleri, resmi tatiller gibi zamansal, bağlanılan cihaz gibi fiziksel vs.) nitelikler olabilir. Bu durumda yukarıdaki soruya verilecek cevaplara bakmak gerekir.
SORU: X kullanıcısı Y işlemini yapmaya yetkili mi?
RBAC: X kullanıcısı R rolüne sahiptir. R rolüne sahip kullanıcılar Y işlemini yapabilirler. Dolayısıyla sorunun cevabı EVET’tir.
ABAC: X kullanıcısı D departmanında çalışmaktadır. Y işlemi D departmanının verilerine ekleme yapmayı gerektirir. İşlem mesai saatleri içinde yapılmak istenmiştir. Bu koşullarda sorunun cevabı EVET’tir.
Bu durumda ne zaman hangisi tercih edilmelidir sorusu gündeme gelecektir. Cevapları şöyle sıralayabiliriz.
- Hesap yönetimi mekanizması kurulması durumunda kaba bir yönetim yeterliyse RBAC, daha detaylı kontrollere ihtiyaç duyuluyorsa ABAC tercih edilmelidir.
- Sadelik önemlidir. Eğer karmaşık RBAC ve ya ABAC sorguları yazmaya başlamışsanız mimarinizi yeniden gözden geçirmeniz gereklidir.
- Tasarım aşamasında öncelikle RBAC tercih edilmelidir. Yetmez ise ABAC tercih edilebilir.
- İkisi bir arada kullanılabilir. Örneğin sayfalara yetkilendirme RBAC ile yapılabilirken, sayfalarda yapılacak tasarım değişikliği, içerik ekleme, güncelleme ve silme işlemleri ABAC ile gerçekleştirilebilir.
Parola Yönetimi ve Şifreleme
Sonraki yazımda kullanıcı parolalarının saklanmasında dikkat edilmesi gereken hususlara değineceğim.
