Model basis data dengan pengguna, peran dan hak


40

Saya memiliki model database dengan tabel pengguna dan tabel peran. Saya ingin mengontrol akses (hak) hingga 10 elemen yang berbeda. Akses dapat diberikan ke peran atau pengguna tunggal. Di bawah ini adalah definisi tabel pengguna, peran dan item:

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,
  ...
);

...

Sekarang saya memiliki dua cara berbeda dalam mendesain hak. Satu tabel dengan kolom jenis hak atau 10 tabel hak - satu untuk setiap elemen yang ingin saya kontrol aksesnya.

Apa pro dan kontra dari satu tabel hak vs satu tabel hak per elemen? - atau apakah cara yang lebih cocok untuk melakukan ini?


1
Pernahkah Anda melihat database pengguna ASP.NET yang melakukan hal ini? (Seperti yang saya mengerti apa yang Anda minta, saya mungkin salah tho)
jcolebrand

Jawaban:


35

Pertama-tama, jenis model keamanan apa yang Anda rencanakan untuk implementasikan? Kontrol Akses Berbasis Peran (RBAC) atau Discretionary Access Control (DAC)?

RBAC dalam model Kontrol Akses Berbasis Peran (RBAC), akses ke sumber daya didasarkan pada peran yang diberikan kepada pengguna. Dalam model ini, administrator menetapkan pengguna ke peran yang memiliki hak dan hak istimewa tertentu yang telah ditentukan. Karena keterkaitan pengguna dengan peran, pengguna dapat mengakses sumber daya tertentu dan melakukan tugas tertentu. RBAC juga dikenal sebagai Kontrol Akses Non-Diskresioner. Peran yang diberikan kepada pengguna dikelola secara terpusat.

DAC Dalam model Discretionary Access Control (DAC), akses ke sumber daya didasarkan pada identitas pengguna. Pengguna diberikan izin ke sumber daya dengan ditempatkan pada daftar kontrol akses (ACL) yang terkait dengan sumber daya. Entri pada ACL sumber daya dikenal sebagai Entri Kontrol Akses (ACE). Ketika pengguna (atau grup) adalah pemilik objek dalam model DAC, pengguna dapat memberikan izin kepada pengguna dan grup lain. Model DAC didasarkan pada kepemilikan sumber daya.

lihat sumber

1) Di RBAC: Anda perlu tabel ElementType untuk menetapkan hak atas peran (pengguna ditugaskan ke peran) RBAC mendefinisikan: "Apa yang bisa dilakukan peran / pengguna ini". Administrator memberikan hak untuk peran dan izin ke peran, menetapkan pengguna ke peran untuk mengakses sumber daya. 2) Di DAC: pengguna dan peran memiliki hak atas elemen melalui daftar kontrol akses (kepemilikan). DAC mendefinisikan: "siapa yang memiliki akses ke data saya". Pengguna (pemilik) memberikan izin ke sumber daya yang dimiliki.

Cara saya menyarankan model data ini:

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

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

(hubungan satu lawan satu)

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

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

1) RBAC (hubungan banyak ke banyak)

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

2) DAC (hubungan banyak ke banyak)

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)
    ...
)

1
Apakah ide yang baik untuk membuat entitas Element_xxx yang tidak terkait berasal dari ElementBase? Misalnya, saya perlu melacak kontrol akses untuk produk dan pelanggan saya. Apakah Anda merekomendasikan saya untuk membuat ElementBase generik dan membiarkan element_base_id menjadi kunci utama untuk product_id dan customer_id meskipun mereka tidak terkait?
Parth Shah

1
RBAC vs DAC, +1
Irfan

@ ParthShah pendekatan apa yang Anda ambil untuk masalah Anda?
Vivek Vardhan

5

Dengan tabel hak untuk setiap elemen, segera setelah Anda menambahkan elemen, Anda perlu menambahkan tabel. Ini akan menambah pemeliharaan aplikasi.

Kelemahan dari menempatkan segala sesuatu dalam satu tabel adalah bahwa Anda mungkin mengalami masalah penskalaan, tetapi hal itu dapat dikurangi dengan menggunakan partisi, pandangan terwujud, dan / atau kolom virtual. Kemungkinan tindakan seperti itu tidak perlu dilakukan.

Sejauh desain tabel, jika ini pada Oracle saya mungkin menyarankan sesuatu seperti ini:

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;

Kode paket bisa menggunakan urutan UserRoleID untuk mengisi Id di tabel Users dan Id di tabel Roles yang diperlukan. Tabel Izin kemudian dapat memiliki elemen yang ditugaskan untuk peran yang pada gilirannya ditugaskan untuk pengguna dan / atau memiliki elemen yang ditugaskan langsung ke pengguna.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.