โมเดลฐานข้อมูลพร้อมผู้ใช้บทบาทและสิทธิ์


40

ฉันมีโมเดลฐานข้อมูลพร้อมโต๊ะผู้ใช้และตารางบทบาท ฉันต้องการควบคุมการเข้าถึง (สิทธิ์) ให้มากถึง 10 องค์ประกอบที่แตกต่างกัน การเข้าถึงสามารถได้รับทั้งบทบาทหรือผู้ใช้คนเดียว ด้านล่างนี้เป็นคำจำกัดความของตารางของผู้ใช้บทบาทและรายการ:

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

...

ตอนนี้ฉันมีสองวิธีที่แตกต่างกันในการออกแบบสิทธิ หนึ่งตารางที่มีคอลัมน์ประเภทสิทธิ์หรือ 10 ตารางสิทธิ์ - หนึ่งตารางสำหรับแต่ละองค์ประกอบที่ฉันต้องการควบคุมการเข้าถึง

ข้อดีและข้อเสียของตารางสิทธิ์หนึ่งตารางเทียบกับสิทธิหนึ่งตารางต่อองค์ประกอบคืออะไร - หรือเป็นวิธีที่เหมาะสมกว่าในการทำเช่นนี้?


1
คุณเห็นฐานข้อมูลผู้ใช้ ASP.NET ที่ทำสิ่งนี้หรือไม่? (ตามที่ฉันเข้าใจในสิ่งที่คุณถามฉันอาจผิด
ถนัด

คำตอบ:


35

ก่อนอื่นรูปแบบความปลอดภัยประเภทใดที่คุณวางแผนที่จะใช้ การควบคุมการเข้าถึงตามบทบาท (RBAC) หรือการควบคุมการเข้าถึงตามอำเภอใจ (DAC)

RBAC ในรูปแบบการควบคุมการเข้าถึงตามบทบาท (RBAC) การเข้าถึงทรัพยากรนั้นขึ้นอยู่กับบทบาทที่กำหนดให้กับผู้ใช้ ในรุ่นนี้ผู้ดูแลระบบกำหนดผู้ใช้ให้กับบทบาทที่มีสิทธิ์และสิทธิ์ที่กำหนดไว้ล่วงหน้า เนื่องจากการเชื่อมโยงของผู้ใช้กับบทบาทผู้ใช้สามารถเข้าถึงทรัพยากรบางอย่างและทำงานที่เฉพาะเจาะจง RBAC ยังเป็นที่รู้จักกันในนามการควบคุมการเข้าถึงโดยไม่ต้องมีการตัดสินใจ บทบาทที่กำหนดให้กับผู้ใช้จะได้รับการดูแลจากส่วนกลาง

DAC ในโมเดล Discretionary Access Control (DAC) การเข้าถึงทรัพยากรนั้นขึ้นอยู่กับตัวตนของผู้ใช้ ผู้ใช้จะได้รับอนุญาตให้ใช้ทรัพยากรโดยการวางไว้ในรายการควบคุมการเข้าถึง (ACL) ที่เกี่ยวข้องกับทรัพยากร รายการใน ACL ของทรัพยากรรู้จักกันในชื่อ Access Control Entry (ACE) เมื่อผู้ใช้ (หรือกลุ่ม) เป็นเจ้าของวัตถุในโมเดล DAC ผู้ใช้สามารถให้สิทธิ์แก่ผู้ใช้และกลุ่มอื่น โมเดล DAC ขึ้นอยู่กับความเป็นเจ้าของทรัพยากร

ดูแหล่งที่มา

1) ใน RBAC: คุณต้องใช้ตาราง ElementType เพื่อกำหนดสิทธิ์ให้กับบทบาท (ผู้ใช้ถูกกำหนดให้กับบทบาท) RBAC กำหนด: "บทบาท / ผู้ใช้นี้ทำอะไรได้บ้าง" ผู้ดูแลระบบกำหนดสิทธิ์สำหรับบทบาทและการอนุญาตให้กับบทบาทกำหนดผู้ใช้ให้กับบทบาทเพื่อเข้าถึงทรัพยากร 2) ใน DAC: ผู้ใช้และบทบาทมีสิทธิ์ในองค์ประกอบผ่านรายการควบคุมการเข้าถึง (ความเป็นเจ้าของ) DAC กำหนด: "ผู้ที่สามารถเข้าถึงข้อมูลของฉัน" ผู้ใช้ (เจ้าของ) ให้สิทธิ์แก่ทรัพยากรที่เป็นเจ้าของ

วิธีใดที่ฉันแนะนำตัวแบบข้อมูลนี้:

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

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

(ความสัมพันธ์แบบหนึ่งต่อหนึ่ง)

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

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

1) RBAC (หลายต่อหลายความสัมพันธ์)

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

2) DAC (หลายต่อหลายความสัมพันธ์)

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
เป็นความคิดที่ดีหรือไม่ที่จะทำให้เอนทิตี Element_xxx ที่ไม่เกี่ยวข้องมาจาก ElementBase ตัวอย่างเช่นฉันต้องติดตามการควบคุมการเข้าถึงสำหรับผลิตภัณฑ์และลูกค้าของฉัน คุณแนะนำให้ฉันสร้าง ElementBase ทั่วไปและให้ element_base_id เป็นคีย์หลักสำหรับ product_id และ customer_id แม้ว่าพวกเขาจะไม่เกี่ยวข้องกันหรือไม่?
Parth Shah

1
RBAC กับ DAC, +1
Irfan

@ParthShah คุณจัดการปัญหาของคุณอย่างไร?
Vivek Vardhan

5

ด้วยตารางสิทธิ์สำหรับแต่ละองค์ประกอบทันทีที่คุณเพิ่มองค์ประกอบคุณจะต้องเพิ่มตาราง สิ่งนี้จะเพิ่มในการบำรุงรักษาแอปพลิเคชัน

ข้อเสียของการวางทุกอย่างในตารางเดียวคือคุณอาจพบปัญหาเกี่ยวกับการปรับขนาด แต่สิ่งเหล่านั้นสามารถลดลงได้โดยใช้การแบ่งพาร์ติชันมุมมองที่ปรากฏและ / หรือคอลัมน์เสมือน ดูเหมือนว่ามาตรการดังกล่าวจะไม่จำเป็น

เท่าที่มีการออกแบบโต๊ะถ้าสิ่งนี้อยู่ใน Oracle ฉันอาจแนะนำสิ่งนี้:

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;

รหัสแพ็คเกจสามารถใช้ลำดับ UserRoleID เพื่อเติมข้อมูลรหัสในตารางผู้ใช้และรหัสในตารางบทบาทตามความจำเป็น ตารางสิทธิ์อาจมีองค์ประกอบที่กำหนดให้กับบทบาทที่ได้รับมอบหมายให้กับผู้ใช้และ / หรือมีองค์ประกอบที่กำหนดให้กับผู้ใช้โดยตรง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.