उपयोगकर्ताओं, भूमिकाओं और अधिकारों के साथ डेटाबेस मॉडल

Question

मेरे पास एक उपयोगकर्ता तालिका और भूमिका तालिका के साथ एक डेटाबेस मॉडल है। मैं 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 अधिकार तालिकाओं के साथ एक तालिका - प्रत्येक तत्व के लिए जो मैं पहुंच को नियंत्रित करना चाहता हूं।

एक अधिकार तालिका बनाम एक अधिकार तालिका प्रति तत्व के पेशेवरों और विपक्ष क्या हैं? - या ऐसा करने के लिए अधिक उपयुक्त तरीका है?

Comments

क्या आपने ASP.NET उपयोगकर्ता डेटाबेस को देखा है जो ऐसा करता है? (जैसा कि मैं समझता हूँ कि तुम क्या कह रहे हैं, मैं गलत यद्यपि हो सकता है)

— jcolebrand

Answer 1

सबसे पहले, आप किस प्रकार के सुरक्षा मॉडल को लागू करने की योजना बनाते हैं? भूमिका आधारित अभिगम नियंत्रण (RBAC) या विवेकाधीन अभिगम नियंत्रण (DAC)?

रोल-बेस्ड एक्सेस कंट्रोल (RBAC) मॉडल में RBAC, संसाधनों तक पहुंच उपयोगकर्ता को सौंपी गई भूमिका पर आधारित है। इस मॉडल में, एक व्यवस्थापक उपयोगकर्ता को एक ऐसी भूमिका सौंपता है जिसमें कुछ पूर्वनिर्धारित अधिकार और विशेषाधिकार होते हैं। भूमिका के साथ उपयोगकर्ता के जुड़ाव के कारण, उपयोगकर्ता कुछ संसाधनों का उपयोग कर सकता है और विशिष्ट कार्य कर सकता है। RBAC को गैर-विवेकाधीन अभिगम नियंत्रण के रूप में भी जाना जाता है। उपयोगकर्ताओं को सौंपी गई भूमिकाएं केंद्र द्वारा प्रशासित हैं।

DAC, डिस्क्रिटरी एक्सेस कंट्रोल (DAC) मॉडल में, संसाधनों तक पहुंच उपयोगकर्ता की पहचान पर आधारित है। उपयोगकर्ता को संसाधन से जुड़े एक्सेस कंट्रोल लिस्ट (ACL) पर रखकर किसी संसाधन को अनुमति दी जाती है। एक संसाधन के ACL पर एक प्रवेश एक एक्सेस कंट्रोल एंट्री (ACE) के रूप में जाना जाता है। जब कोई उपयोगकर्ता (या समूह) डीएसी मॉडल में किसी वस्तु का मालिक होता है, तो उपयोगकर्ता अन्य उपयोगकर्ताओं और समूहों को अनुमति दे सकता है। DAC मॉडल संसाधन स्वामित्व पर आधारित है।

स्रोत देखें

1) RBAC में: आपको भूमिका के अधिकार प्रदान करने के लिए ElementType तालिका की आवश्यकता होती है (उपयोगकर्ताओं को भूमिका के लिए असाइन किया गया है)। RBAC परिभाषित करता है: "यह भूमिका / उपयोगकर्ता क्या कर सकता है"। प्रशासक भूमिकाओं के लिए भूमिकाओं और अनुमतियों के अधिकार प्रदान करता है, उपयोगकर्ताओं को संसाधनों तक पहुंचने के लिए भूमिका (एस) प्रदान करता है। 2) डीएसी में: उपयोगकर्ताओं और भूमिकाओं का एक्सेस कंट्रोल लिस्ट (स्वामित्व) के माध्यम से तत्वों पर अधिकार है। डीएसी परिभाषित करता है: "जिनके पास मेरे डेटा तक पहुंच है"। उपयोगकर्ता (स्वामी) स्वामित्व वाले संसाधन को अनुमति देता है।

किसी भी तरह से मैं इस डेटा मॉडल का सुझाव देता हूं:

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) आरबीएसी (कई-कई रिश्ते)

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

2) डीएसी (कई-कई रिश्ते)

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

Comments

क्या यह एक अच्छा विचार है कि असंबंधित एलिमेंट_एक्सएक्सएक्स इकाइयां एलीमेंटबेस से प्राप्त करें? उदाहरण के लिए, मुझे अपने उत्पादों और ग्राहकों दोनों के लिए अभिगम नियंत्रण को ट्रैक करने की आवश्यकता है। क्या आप मुझे एक जेनेरिक एलिमेंटबेस बनाने की सलाह देते हैं और एलिमेंट_बेज_एड प्रॉडक्ट_ड और कस्टमर_ड के लिए प्राथमिक कुंजी होते हैं, भले ही वे असंबंधित हों?

— पार्थ शाह

RBAC बनाम DAC, +1

— इरफान

@ParthShah आपने अपनी समस्या के लिए क्या दृष्टिकोण अपनाया?

— विवेक वर्धन

Answer 2

प्रत्येक तत्व के लिए एक अधिकार तालिका के साथ, जैसे ही आप एक तत्व जोड़ते हैं, आपको एक तालिका जोड़ने की आवश्यकता होगी। यह अनुप्रयोग रखरखाव में जोड़ देगा।

एक तालिका में सब कुछ डालने का नकारात्मक पक्ष यह है कि आप स्केलिंग के मुद्दों में भाग सकते हैं, लेकिन विभाजन, भौतिक विचारों और / या आभासी स्तंभों का उपयोग करके इन्हें कम किया जा सकता है। इस तरह के उपाय आवश्यक नहीं होंगे।

जहां तक ​​टेबल डिजाइन की बात है, अगर यह ओरेकल पर होता तो मैं कुछ इस तरह का सुझाव दे सकता था:

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;

पैकेज कोड उपयोगकर्ता तालिका में आईडी और Roles तालिका में आईडी को आवश्यक रूप से पॉप्युलेट करने के लिए UserRoleID अनुक्रम का उपयोग कर सकता है। अनुमतियाँ तालिका में उपयोगकर्ता को सौंपी गई भूमिकाओं के लिए असाइन किए गए तत्व हो सकते हैं और / या उपयोगकर्ताओं को सीधे असाइन किए गए तत्व हो सकते हैं।