Rol Tabanlı Erişim Kontrolü: Roller, Yetkiler ve Örnekler

Role dayalı erişim kontrolü, izinleri kişilere değil rollere atar; böylece erişim bireyi değil işi izler. Çoğu iş yazılımı için doğru varsayılandır. Yetersiz kaldığı yer, izinlerin role değil kayda bağlı olduğu durumlardır, bir yöneticinin kendi ekibini görüp başkasını görememesi ya da bir kullanıcının bir belgeyi yalnızca taslak halindeyken düzenleyebilmesi gibi.

Bu rehber gerçek bir kurumla temasa dayanan rollerin nasıl tasarlanacağını, niteliğe dayalı kuralların ne zaman ekleneceğini ve her ekrana dokunan sonradan eklemeden nasıl kaçınılacağını kapsar.

Önemli noktalar

• İzinleri ilk ekrandan önce modelleyin: Erişim kontrolünü sonradan eklemek yazılımda en pahalı geç değişikliklerden biridir.
• Roller organizasyon şemasından değil iş işlevlerinden gelir: Unvanlar, insanların fiilen yaptığı işten çok daha sık değişir.
• Gerçek sistemlerin çoğu melezdir: Ne yapabileceğiniz için roller, hangi kayıtlarda yapabileceğiniz için nitelikler.
• Sorgunun altında zorlayın: Uygulama düzeyindeki kontroller, biri unuttuğu gün başarısız olur.

Rolleri insanların yaptığı işten tasarlayın

Unvanlarla değil görevlerle başlayın. Her görev için kimin yaptığını, hangi veriye ihtiyaç duyduğunu ve neyi değiştirdiğini yazın. Roller, hep birlikte hareket eden görev kümelerinden ortaya çıkar.

Rolleri organizasyon şemasından kurmak, ilk yeniden yapılanmada kırılan bir izin modeli üretir. İş işlevlerinden kurmak ise buna dayanan bir model üretir; çünkü raporlama hattı değişse de iş aynı kalır.

Sayıyı küçük tutun. Beş ile dokuz rol çoğu iş sistemini kapsar. Bir düzineyi aştığında bir rolün neyi verdiğini kimse söyleyemez, yöneticiler sonuç almak için bir kişiye birkaç rol atamaya başlar ve model gerçekliği anlatmayı bırakır.

Dört unsuru kapsayın

Kayıt kapsamı, tasarım anında en sık atlanan ve pahalı yeniden çalışmaya yol açan unsurdur. "Siparişleri görebilir" bir izindir; "yalnızca kendi şubesine ait siparişleri görebilir" izin artı kapsamdır ve ikisi farklı mekanizma gerektirir.

Modeli zor gerçek vakalara karşı test edin

Her kurumda temiz bir role sığmayan insanlar vardır. Tasarımı uygulamadan önce kendinizinkilere karşı sınayın:

• Kendi ekibinin taleplerinde aynı zamanda onaycı olan bir yönetici
• Tek bir projeye süreli erişimi olan bir taşeron
• Müşteri adına işlem yapan bir destek temsilcisi
• İki hafta bir meslektaşının yerine bakan biri
• Üç şubeyi gören ama dördüncüyü görmeyen bir bölge müdürü
• Her şeye okuma, hiçbir şeye yazma erişimi olan bir denetçi

Model bunları kişi başına rol icat etmeden ifade edemiyorsa bitmemiştir. Özellikle devir ve geçici yetki yükseltme neredeyse her zaman gerekir ve neredeyse hiç belirtilmez.

Kararı kayıt veriyorsa nitelik ekleyin

Saf roller "bu kişi ne yapabilir" sorusunu yanıtlar. Birçok sistem ayrıca "hangi kayıtlarda" sorusuna ihtiyaç duyar; bu da kullanıcının ve kaydın niteliklerine bağlıdır: şube, sahiplik, proje üyeliği, belge durumu.

Pratik desen melezdir: eylemler için roller, kapsam için nitelikler. "Editörler makaleleri güncelleyebilir" roldür; "yalnızca sahibi oldukları ve yalnızca taslak halindeyken" nitelik kuralıdır. İkisini ayrı tutmak modeli okunabilir kılar ki bu önemlidir, kimsenin anlamadığı bir izin modeli, aşırı geniş yetkilerle atlatılır.

Uygulamanın altında zorlayın

Doğruluk, her sorgunun filtrelemeyi hatırlamasına bağlı olamaz. Zorlamayı aşağı itin: veritabanında satır düzeyi güvenlik, oturuma bağlı bir kapsam veya kapsamsız sorguyu reddeden bir veri erişim katmanı.

Sonra kasıtlı olarak yetkisiz erişim deneyen testler yazın. Yalnızca izinli eylemleri kapsayan bir paket, bir kontrolün eksik olduğu gün de geçecektir.

Normal istek akışının dışındaki yollara özellikle dikkat edin: arka plan işleri, dışa aktarmalar, raporlar, yönetim araçları ve entegrasyonlar. Bunlar izinlerin normalde bulunduğu kullanıcı oturumunun dışındadır ve erişim sızıntılarının bulunduğu yerdir.

Bunları baştan kurun

Varsayılan olarak en az yetki. Yeni roller hiçbir şeyle başlar ve işin gerektirdiğini kazanır. Mevcut bir rolün kopyasından başlamak, izinlerin yayılma biçimidir.

Kayıtlı olarak kullanıcı adına işlem. Destek ekiplerinin buna ihtiyacı vardır. Sonradan eklendiğinde genellikle denetlenemez olur.

Süreli erişim. Taşeron ve vekâlet düzenlemeleri, birinin hatırlamasına bağlı olmak yerine kendiliğinden sona ermelidir.

Tam denetim izi. Kimin neyi, ne zaman ve hangi izinle yaptığı: yalnızca günlük dosyasında değil kaydın üzerinde görünür. Daha geniş izinleri güvenle vermenizi sağlayan budur ve bu da insanları hızlandırır.

Erişim incelemesi. Kimin neye sahip olduğuna dair, bir sahibin onaylayacağı periyodik bir rapor. İzinler birikir; biri bakmadıkça hiçbir şey onları kaldırmaz.

Sonradan eklemek pahalıdır, o yüzden eklemeyin

Her kullanıcının her şeyi görebildiğini varsayan bir sisteme erişim kontrolü eklemek, tüm ekranlarda, sorgularda ve raporlarda yeniden çalışma gerektirir. Yapılabilecek en pahalı geç değişikliklerden biridir ve modele erken bir öğleden sonra ayırarak tamamen önlenebilir.

Tasarım anında izinlerin role mi, niteliğe mi yoksa hiyerarşiye mi dayandığına ve bir kişinin birden fazla rol taşıyıp taşıyamayacağına karar verin. Bu üç yanıt veri modelini şekillendirir ve sonradan değiştirmek üzerine kurulan her şeyi değiştirmek demektir.

Uyumun tasarımla kesiştiği yer

KVKK ve GDPR kapsamında kişisel veriye erişim, ihtiyaç duyanlarla sınırlı olmalı ve bu sınırlamayı gösterebilmelisiniz. Net kapsamı ve inceleme süreci olan bir erişim modeli, bu kanıtın büyük bölümüdür.

Düzenlemeye tabi işlerde, sağlık, finans, kamu, yalnızca erişimin kontrol edildiğini değil, incelendiğini de göstermeniz beklenir. Denetim kaydı ve periyodik erişim incelemesi iyi uygulama olmaktan çıkıp sizden istenen belge haline gelir.

İlgili rehberler

• Burada açık kalan soruyu şu yazı yanıtlıyor: Yapay Zeka İş Akışı Otomasyonu: Kullanım Alanları ve Riskler.
• Karar vermeden önce okunacak yazı: Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.

Rol Tabanlı Erişim Kontrolü: Roller, Yetkiler ve Örnekler yazısındaki mimari soruların bir kez ve doğru yanıtlanması gerekiyorsa Platform Temelinizi Konuşalım.