Sitelerde Rol Bazlı Yetkilendirme: Kim Neyi Görsün?

Sitelerde rol bazlı yetkilendirme neden tek "yönetici" rolüyle yetinmiyor?

Rol bazlı yetkilendirme, bir site yönetim sisteminde her kullanıcının hangi modülü görebildiğini, hangisine veri girebildiğini ve hangisinde değişiklik yapabildiğini ayrı ayrı tanımlamak demektir. Küçük bir yönetim ofisinde bu ihtiyaç görünmez kalabilir — herkes zaten birbirini tanıyor, herkes her şeyi görüyor. Ama site sayısı ve personel sayısı arttıkça bu rahatlık bir güvenlik açığına dönüşür: muhasebeci güvenlik kayıtlarına, stajyer banka bilgilerine, saha personeli kat maliki iletişim geçmişine erişebiliyorsa, kimin neyi görmesi gerektiği sorusu artık bir tercih değil, bir risk yönetimi meselesidir.

Sorun genelde tek bir "yönetici" hesabı ile "tüm diğerleri" ayrımına indirgenmiş sistemlerde ortaya çıkar. Böyle bir yapıda ya herkes her şeyi görür ya da hiçbir şey görmez; ara bir seçenek yoktur. Oysa gerçek bir yönetim ofisinde muhasebeci, saha personeli, güvenlik görevlisi ve yönetim şirketi sahibi tamamen farklı bilgilere ihtiyaç duyar — ve tamamen farklı bilgilerden korunmalıdır.

Yetki matrisinin somut olarak ne çözdüğü

Rol-modül yetki matrisi, her rolün her modül üzerindeki görme, ekleme, düzenleme ve silme haklarını ayrı hücrelerde tanımlar. Pratikte bu şu sorunları ortadan kaldırır:

• Gereksiz veri görünürlüğü: Güvenlik görevlisinin kat maliki bakiyelerini, muhasebecinin ziyaretçi kayıtlarını görmesine gerek yoktur. Yetki matrisi bu görünürlüğü modül bazında kapatır.
• Kazara veya kasıtlı değişiklik riski: Düzenleme yetkisi olmayan bir kullanıcı bir borçlandırma tutarını değiştiremez; hata ya da kötü niyet ihtimali baştan daralır.
• Devir ve işten ayrılma karmaşası: Personel değiştiğinde erişimi tek tek elle kapatmak yerine, rolü değiştirmek yeterli olur — kişiye özel yetki takibi ölçeklenmez.
• Denetimde belirsizlik: "Bu değişikliği kim yapabilirdi" sorusunun cevabı, kim düzenleme yetkisine sahipti sorusuyla aynıdır; bu da denetim kaydının anlamlı olmasının ön koşuludur. Yetki matrisi olmadan denetim izi sadece "biri değiştirdi" der, matrisle birlikte "değiştirebilecek kişiler şunlardı" listesi daralır.

Bu son madde özellikle önemlidir: denetim kaydı kim yaptı sorusuna cevap verir, yetki matrisi ise kim yapabilirdi sorusuna. İkisi birlikte çalıştığında hem geriye dönük izlenebilirlik hem de ileriye dönük risk azaltımı sağlanır.

Tipik roller ve ihtiyaç duydukları erişim

Bir yönetim şirketinde görülen roller genelde şu şekilde ayrışır:

• Yönetim şirketi sahibi / genel yönetici: Tüm siteleri açar, kullanıcıları tanımlar, rol yetki matrisini ve aktif modül paketini belirler. Bu rol genelde tam erişime sahiptir ama yine de her işlemi denetim izine düşer.
• Site yöneticisi: Kendi sitesindeki borçlandırma, tahsilat, talep/arıza ve toplantı modüllerine erişir; başka bir sitenin verisini görmez.
• Muhasebeci: Finansal modüllere (borçlandırma, tahsilat, banka mutabakatı, raporlama) erişir; genelde güvenlik ve saha operasyon kayıtlarına ihtiyacı yoktur.
• Güvenlik personeli: Ziyaretçi kaydı, kartlı geçiş ve tur kontrolü modüllerini kullanır; finansal verilere erişimi kapalı tutulur.
• Teknik/saha personeli: Kendisine atanan görevleri, kontrol listelerini ve sayaç okumalarını görür; kat maliki iletişim geçmişine ya da muhasebe kayıtlarına erişimi yoktur.

Bu ayrım sadece gizlilik için değil, aynı zamanda kullanılabilirlik için de gereklidir: bir kullanıcı yalnızca işiyle ilgili modülleri gördüğünde arayüz sadeleşir, yanlış modülde işlem yapma riski azalır. Site talep ve arıza süreçlerinde anlattığımız "tek giriş noktası" mantığının bir benzeri burada da geçerlidir: her rol kendi işine ait ekranı görür, geri kalan karmaşa arka planda kalır.

Çok siteli bir yönetim şirketinde bu roller bir kat daha karmaşıklaşır: aynı unvana sahip iki site yöneticisi bile farklı sitelerin verisine erişmemeli, hatta bazı büyük şirketlerde bölge müdürü gibi ara bir rol birden fazla siteyi görüp yalnızca özet raporlara erişebilmelidir. Rol tanımının modül bazında değil site bazında da esnek olması, işte tam bu noktada devreye girer.

Yetki matrisi kurarken dikkat edilmesi gerekenler

Rol bazlı yetkilendirmeyi kurarken göz ardı edilen birkaç nokta, sistemin pratikte işe yaramasını engelleyebilir:

• Görme yetkisi ile düzenleme yetkisi ayrı tutulmalı. Bir kullanıcının bir kaydı görebilmesi, onu değiştirebileceği anlamına gelmemeli; bu iki yetki her modülde bağımsız açılıp kapatılabilmeli.
• Çok siteli yönetim şirketlerinde erişim site bazında da sınırlanmalı. Bir site yöneticisinin başka bir sitenin verisini görmemesi, sadece modül bazlı değil site bazlı izolasyon da gerektirir.
• Varsayılan yetki dar başlamalı, gerektikçe açılmalı. Yeni bir rol tanımlanırken önce hiçbir modüle erişim vermeyip ihtiyaç oldukça açmak, tersine göre çok daha güvenlidir.
• Yetki değişiklikleri kendi başına denetim izine düşmeli. Kimin, ne zaman, hangi rolün yetkisini değiştirdiği kayıt altında olmalı; aksi halde yetki matrisinin kendisi denetlenemeyen bir alan haline gelir.
• Rol tanımı iş değişikliğiyle güncel tutulmalı. Bir personel görev değiştirdiğinde eski yetkilerin elle kaldırılmayı beklemesi, zamanla aşırı yetkili hesapların birikmesine yol açar.

Bu noktaların çoğu, kurulumdan sonra unutulan ayrıntılardır — sistem ilk kurulduğunda doğru tanımlanan bir yetki matrisi, aylar sonra personel değişiklikleriyle sessizce bozulabilir. Bu yüzden yetki matrisini periyodik olarak (örneğin yıl sonu kapanışıyla birlikte) gözden geçirmek, kurulumun kendisi kadar önemlidir.

Sonuç

Rol bazlı yetkilendirme, site yönetiminde görünmeyen ama her gün çalışan bir güvenlik katmanıdır. Doğru kurulduğunda hem yanlışlıkla yapılan hatalı işlemleri hem de yetkisiz erişim riskini azaltır, hem de denetim kaydını anlamlı kılan zemini hazırlar. Yanlış kurulduğunda ise fark edilmesi genelde bir itiraz ya da inceleme anına kadar gecikir.

Site-Park'ta her rolün her modüle erişimi ayrı hücrelerde açılıp kapatılır ve her yetki değişikliği kendi denetim izini bırakır — bkz. Site-Park ürün sayfası. Mevcut sisteminizde yetkilendirme hâlâ tek "yönetici/diğerleri" ayrımına dayanıyorsa, iletişim sayfamızdan bize ulaşın, kendi rol yapınıza uygun bir yetki matrisini birlikte tasarlayalım.