Kullanıcılar, roller ve haklar içeren veritabanı modeli

40

Bir kullanıcı tablosu ve rol tablosu ile bir veritabanı modeli var. 10 farklı öğeye erişimi (hakları) kontrol etmek istiyorum. Erişim, bir role veya tek bir kullanıcıya verilebilir. Aşağıda kullanıcıların, rollerin ve öğelerin tablo tanımı verilmiştir:

CREATE TABLE users
(
  id serial NOT NULL PRIMARY KEY,
  username character varying UNIQUE,
  password character varying,
  first_name character varying,
  last_name character varying,
  ...
);

CREATE TABLE roles
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

CREATE TABLE element_1
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

...

Şimdi hakları tasarlamak için iki farklı yolum var. Hak türü sütununa sahip bir tablo veya 10 hak tablosu - erişimi kontrol etmek istediğim her öğe için bir tane.

Öğe başına bir hak tablosuna karşı bir hak tablosunun artıları ve eksileri nelerdir? - ya da bunu yapmanın en uygun yolu mu?

database-design best-practices

— taudorf
kaynak

1

Bunu yapan ASP.NET kullanıcıları veritabanını gördünüz mü? (ne sorduğunuzu anladığım kadarıyla tho olabilirim)

— jcolebrand

35

Öncelikle, ne tür bir güvenlik modeli uygulamayı düşünüyorsunuz? Rol Tabanlı Erişim Kontrolü (RBAC) veya İsteğe Bağlı Erişim Kontrolü (DAC)?

Rol Tabanlı Erişim Kontrolü (RBAC) modelindeki RBAC, kaynaklara erişim bir kullanıcıya atanan role dayanmaktadır. Bu modelde, bir yönetici, önceden belirlenmiş belirli haklara ve ayrıcalıklara sahip bir role kullanıcı atar. Kullanıcının rolle ilişkisi nedeniyle, kullanıcı belirli kaynaklara erişebilir ve belirli görevleri gerçekleştirebilir. RBAC ayrıca isteğe bağlı olmayan erişim denetimi olarak da bilinir. Kullanıcılara atanan roller merkezi olarak yönetilir.

DAC İsteğe Bağlı Erişim Kontrolü (DAC) modelinde, kaynaklara erişim kullanıcının kimliğine dayanır. Kullanıcıya, kaynakla ilişkilendirilmiş bir erişim kontrol listesine (ACL) yerleştirilerek bir kaynağa izin verilir. Bir kaynağın ACL'sindeki bir giriş Erişim Kontrol Girişi (ACE) olarak bilinir. Bir kullanıcı (veya grup) DAC modelinde bir nesnenin sahibi olduğunda, kullanıcı diğer kullanıcılara ve gruplara izin verebilir. DAC modeli kaynak sahipliğine dayanmaktadır.

kaynağı gör

1) RBAC'da: rol hakkını atamak için ElementType tablosuna ihtiyacınız vardır (kullanıcılar rollere atanır). RBAC şunları tanımlar: "Bu rol / kullanıcı ne yapabilir". Yönetici roller için roller için haklar ve roller için izinler atar, kullanıcıları kaynaklara erişmek için rollere atar. 2) DAC’de: kullanıcılar ve rollerin erişim kontrol listesi (mülkiyet) üzerinden öğeler üzerinde hakları vardır. DAC şunları tanımlamaktadır: "verilerime kimin erişimi var". Kullanıcı (sahip) sahip olduğu kaynağa izin verir.

Herhangi bir şekilde bu veri modelini öneririm:

CREATE TABLE ElementType
(
    Id (PK)
    Name
    ...
)

CREATE TABLE ElementBase
(
    Id (PK)
    Type (FK to ElementType)
    ...
)

(bire bir ilişki)

CREATE TABLE Element_A
(
    Id (PK, FK to ElementBase)
    ...
)

CREATE TABLE Element_B
(
    Id (PK, FK to ElementBase)
    ...
)

1) RBAC (çoktan çoğa ilişki)

CREATE TABLE ElementType_To_Role_Rights
(
    RightId (PK)
    RoleId  (FK to Role)
    ElementTypeId (FK to ElementType)
    ...
)

2) DAC (çoktan çoğa ilişki)

CREATE TABLE ElementBase_To_Actor_Rights
(
    RightId (PK)
    ElementBaseId (FK to ElementBase)
    ActorId (FK to Actor)
    ...
)

CREATE TABLE Actor
(
    Id (PK)
    Name
)

CREATE TABLE User
(
    Id (PK, FK to Actor)
    Password
    ...
)

CREATE TABLE Role
(
    Id (PK, FK to Actor)
    ...
)

— garik
kaynak

1

İlişkili olmayan Element_xxx varlıklarının ElementBase'den türetilmesi iyi bir fikir midir? Örneğin, hem ürünlerim hem de müşterilerim için erişim denetimini izlemem gerekiyor. Genel bir ElementBase oluşturmamı ve ilgisiz olmalarına rağmen element_base_id'nin product_id ve customer_id için birincil anahtar olmasına izin vermemi ister misiniz?

— Parth Shah

1

RBAC vs DAC, +1

— Irfan

@ParthShah, sorununuz için ne gibi bir yaklaşım uyguladınız?

— Vivek Vardhan

5

Her eleman için bir haklar tablosuyla, bir element eklediğiniz anda bir tablo eklemeniz gerekir. Bu uygulama bakımına katkıda bulunur.

Her şeyi bir tabloya koymanın dezavantajı, ölçeklendirme sorunlarıyla karşılaşabilmenizdir, ancak bunlar bölümleme, materyalize görünümler ve / veya sanal sütunlar kullanılarak azaltılabilir. Muhtemelen bu tür önlemler gerekli olmaz.

Masa tasarımına gelince, eğer bu Oracle’daysa, şöyle bir şey önerebilirdim:

CREATE SEQUENCE UserRoleID;

CREATE TABLE USERROLE 
(
  USERID NUMBER(7) NOT NULL 
, ROLEID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    USERID 
  , ROLEID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

CREATE TABLE PERMISSIONS 
(
  ID NUMBER(7) NOT NULL 
, ELEMENTID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    ID 
  , ELEMENTID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

Paket kodu, Kullanıcılar tablosundaki Kimliği ve Roller tablosundaki Kimliği gerektiği gibi doldurmak için UserRoleID dizisini kullanabilir. İzinler tablosu daha sonra sırasıyla kullanıcılara atanan ve / veya doğrudan kullanıcılara atanan öğelere sahip olan rollere atanmış öğeler içerebilir.

— Leigh Riffel
kaynak