Rol tabanlı erişim kontrolü nasıl tasarlanır?


15

Kullanıcıların sistemimde neler yapabileceğini veya yapamayacağını kısıtlamak için rol temelleri erişim kontrol modelini izlemeye çalışıyorum.

Şimdiye kadar aşağıdaki varlıklar var:

kullanıcılar - Sistemi kullanacak kişiler. Burada kullanıcı adları ve şifreler var. roller - Kullanıcıların sahip olabileceği rollerin toplanması. Yönetici, yönetici vb. Kaynaklar - Kullanıcıların manipüle edebileceği şeyler. Sözleşmeler, kullanıcılar, sözleşme taslakları vb. İşlemler gibi - Kullanıcıların kaynaklarla yapabileceği şeyler. Oluşturma, okuma, güncelleme veya silme gibi.

Şimdi, şüphe burada böyle bir ilişki var şemada yükselir:

işlemleri (0 .. *) , izinler olarak adlandırdığım ve işlemi ve kaynağı depolayacak bir tablo oluşturan kaynaklar (0 .. *) üzerinde yürütülür .

İzinler tablosu şöyle görünecektir (bir satırı): ID: 1, işlem: create, kaynak: contract.

Ki bu demektir izin için yaratmak bir sözleşme .

Bu şekilde yaptım çünkü bazı kaynakların her türlü operasyona sahip olmayabileceğini hissediyorum. Örneğin, sözleşmeleri kaydetmek için kullanıcılar dosya yükleyebilir , ancak bu işlem bir sağlayıcıyı kaydetmek için kullanılamaz .

Dolayısıyla, yönetici bir role izin verecek olduğunda , sistemde kayıtlı her bir işlemle kaynak listesi olmayacaktır.

Bence her kaynağın kendi üzerinde gerçekleştirilebilecek kendi operasyon koleksiyonu vardır .

Bir şey anlaşılabilir değilse açıklığa kavuşturabilirim.

Bu rbac'ı uygulamak için doğru yol mu?

DÜZENLE

Demek istediğim, operasyon ve kaynak olan bir izinler tablosuna sahip olarak, kaynakları işlemler ile ilişkilendirmek istediğim için fazladan iki tablom var . Ben de az önce yaptığı olabilirdi kaynaklar var izinleri izinleri masa izinlerini saklanacak.

Ama sonra ne olurdu, bazı kaynaklar için mevcut olmayan bazı izinler, yönetici bunları atadığında ortaya çıkacaktı.

Bu yüzden bir veritabanı işlemi açısından bir sütun işlemi ve başka bir kaynak olan bu tablo izni doğru olup olmadığını bilmek istiyorum? Böyle kalırsa sorunla karşılaşır mıyım?


2
"Doğru" ile ne demek istiyorsun? Not: "en iyi uygulama" gibi bir totoloji ile cevap vermeyin. Özel gereksinimlerinizi belirtin.
Robert Harvey

1
"Doğru" tanımım genellikle "yazılımınızın işlevsel ve işlevsel olmayan gereksinimlerini en etkili şekilde karşılayan" tanımımdır. NIST'in rol tabanlı güvenlik için ayrıntılı yönergeler ve en iyi uygulamalar sunduğunu unutmayın. Bkz. Csrc.nist.gov/groups/SNS/rbac
Robert Harvey

Pundit projesinde nasıl yapıldığına bakmak isteyebilirsiniz .
Antarr Byrd

1
Bunun için bir kütüphane kullanmayı düşünmelisiniz.
RibaldEddie

Sizin için RBAC veya ABAC yapacak çok sayıda kütüphane var
David Brossard

Yanıtlar:


11

Tasarımın bana oldukça yakın görünüyor. Sadece birkaç öneri.

kullanıcılar - Sistemi kullanacak kişiler. Burada kullanıcı adları ve şifreler var.

İnce

roller - Kullanıcıların sahip olabileceği rollerin toplanması. Yönetici, yönetici vb.

Çok iyi. Ancak, hangi kullanıcıların hangi rollere sahip olduğunu size bildiren bir "UserRoles" varlığına / tablosuna da ihtiyacınız olacaktır. Belirli bir kullanıcının iki veya daha fazla rolü olabilir.

kaynakları - Kullanıcıların manipüle edebileceği şeyler. Sözleşmeler, kullanıcılar, sözleşme taslakları vb.

Sadece bir anlambilim meselesi olabilir. Kullanıcıların kaynakları doğrudan manipüle ettiğini düşünmüyorum; rolleri yapar. Böylece kullanıcı gider -> kullanıcı rolü -> rol -> operasyon -> kaynak

işlemleri - Kullanıcıların kaynaklarla yapabileceği şeyler. Oluşturma, okuma, güncelleme veya silme gibi.

evet, "kullanıcılar" yerine "roller" hariç

İzinler tablosu şöyle görünecektir (bir satırı): ID: 1, işlem: create, kaynak: contract. Bu, sözleşme oluşturma izni anlamına gelir.

Hmmm. Bununla devam etmenin iki yolu var. Açıkladığınız izinler tablosuna sahip olabilirsiniz, ancak RolePermissionshangi rolün hangi izne sahip olduğunu bildiren ek bir tabloya / varlığa da ihtiyacınız olacaktır . Ama bunun gerekli olduğundan emin değilim.

Bunu yapmanın daha basit bir yolu, şu sütun / özniteliklere sahip bir izinler tablosu / varlıktır: Rol Kimliği, İşlem Kimliği, KaynakKimliği. Bu şekilde, işlemler x kaynak bileşimleri, bir role atanan izne yüklenmek yerine doğrudan bir role atanır. Bir varlığı ortadan kaldırır. Hangi izin kombinasyonlarına izin verilip hangilerinin izin verilmediğini önceden tanımlamak istemiyorsanız, gerçekten ayrı bir rol agnostik izinler tablosuna gerek yoktur.


Her şeyden önce, "kullanıcılar" düzeltmesi yerine "roller" ile tamamen aynı fikirdeyim. Demek istediğim de buydu. Şimdi, kaynakları operasyonlarla da ilişkilendirmek istiyorum. Örneğin: bir sözleşme kaynağının upload_file gibi bir işlemi vardır. Yani ne istemiyorum upload_file işlemi de bir rol izinleri atarken sağlayıcıları (başka bir kaynak) gibi upload_file işlemi olmayan başka bir kaynakta görünmesi.
imran.razak

13

Ben RBAC kullanmak veya uygulamak olmaz. Bunun yerine ABAC kullanırdım. Açıklamama izin ver...

  • RBAC veya rol tabanlı erişim kontrolü, kullanıcı yönetimi ve rol ataması ile ilgilidir. RBAC'de Alice'in yönetici olduğunu söyleyebilirsin. Bununla birlikte statik izinler tanımlayabilirsiniz. Örneğin, bir yönetici kredileri onaylayabilir. Bu yüzden Alice'den yöneticiyi onaylamak için yöneticiye bir bağlantı var. Bunu yapmanıza izin verecek birçok sistem vardır, böylece kendi tablolarınızı uygulamanız gerekmez. LDAP'nin bile sınırlı RBAC setleri için desteği vardır. Nispeten küçük bir rol ve izin kümesine sahip olduğunuz sürece sorun olmaz. Ancak, durumunuz gibi belirli izinleri dikkate almak isterseniz ne olur? Görüntüleme, silme, ekleme? İlişkileri hesaba katmak isterseniz ne olur?
  • ABAC veya özniteliğe dayalı erişim kontrolü, politika temelli, ayrıntılı yetkilendirme ile ilgilidir. ABAC ile RBAC'da tanımlandığı gibi roller kullanabilir ve politikalar yazabilirsiniz.
    • Yöneticiler bölümlerindeki belgeleri görüntüleyebilir
    • Çalışanlar sahip oldukları belgeleri düzenleyebilir

Sorunuzda, temel olarak bilgi modelini tanımladınız. Nesneleriniz ve nitelikleri, örneğin bir kullanıcı (ad, şifre, departman ...); bir nesne (örneğin bir sözleşme) vb.

Bilgi modeli

Bu nedenle ABAC'de, uygulama kodunuzu / mantığınızı yetkilendirme mantığından tamamen ayırırsınız; bu daha sonra öznitelikleri kullanan politikalar olarak saklanır. İzinlerin kendileri doğrudan politikada saklanır (yukarıdaki örneğe bakın). ABAC dağıtım mimarisi aşağıdakine benzer

Özellik Tabanlı Erişim Kontrol Mimarisi

Mesele şu ki, bir ABAC yaklaşımı alırsanız, ABAC (XACML veya ALFA'da - bunun için çok sayıda araç vardır) için politikalar yazarsınız ve RBAC'yi özel olarak kodlamanız veya tekrar uygulamak zorunda kalmazsınız.


1
Politika örneğinizde, Yöneticilerin bölümlerindeki belgeleri görüntüleyebileceğini söylüyor. Sistemin önceden tanımlanmış izinlere, rollere ve kaynak türlerine sahip olacağı anlamına mı geliyor?
imran.razak

Hayır. Bu, bir kullanıcıyı (Alice) rollerine (yönetici ...) bağlayan bir şeyin (LDAP? Tablo?) Olacağı anlamına gelir. Daha sonra belge meta verilerini içeren bir tablonuz olur (bu, genellikle koruduğunuz uygulama içindeki bir tablodur). İznin kendisi (görüntüleme, düzenleme, silme) ilkede saklanır.
David Brossard
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.