사용자, 역할 및 권한이있는 데이터베이스 모델

사용자 테이블과 역할 테이블이있는 데이터베이스 모델이 있습니다. 최대 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 개의 권한 테이블-액세스를 제어하려는 각 요소마다 하나씩.

요소 당 하나의 권한 테이블과 하나의 권한 테이블의 장단점은 무엇입니까? -아니면 더 적합한 방법입니까?

우선, 어떤 유형의 보안 모델을 구현할 계획입니까? RBAC (역할 기반 액세스 제어) 또는 DAC (임의 액세스 제어)?

RBAC (역할 기반 액세스 제어) 모델의 RBAC에서 리소스에 대한 액세스는 사용자에게 할당 된 역할을 기반으로합니다. 이 모델에서 관리자는 사용자에게 미리 결정된 특정 권한이있는 역할을 할당합니다. 사용자는 역할과 연관되어 있기 때문에 특정 자원에 액세스하고 특정 작업을 수행 할 수 있습니다. RBAC는 비 임의적 액세스 제어라고도합니다. 사용자에게 할당 된 역할은 중앙에서 관리됩니다.

DAC DAC (임의 액세스 제어) 모델에서 리소스에 대한 액세스는 사용자의 신원을 기반으로합니다. 자원과 연관된 ACL (액세스 제어 목록)에 배치하여 자원에 대한 권한을 사용자에게 부여합니다. 자원 ACL의 항목을 ACE (Access Control Entry)라고합니다. 사용자 (또는 그룹)가 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)
    ...
)

각 요소에 대한 권한 테이블을 사용하여 요소를 추가하자마자 테이블을 추가해야합니다. 이것은 응용 프로그램 유지 관리에 추가됩니다.

모든 것을 하나의 테이블에 배치하는 단점은 스케일링 문제가 발생할 수 있지만 파티셔닝, 구체화 된 뷰 및 / 또는 가상 열을 사용하여 완화 할 수 있다는 것입니다. 아마도 그러한 조치는 필요하지 않을 것입니다.

테이블 디자인에 이르기까지 이것이 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 시퀀스를 사용하여 필요에 따라 Users 테이블의 Id와 Roles 테이블의 Id를 채울 수 있습니다. 그런 다음 권한 테이블에 사용자에게 할당 된 역할에 할당 된 요소 및 / 또는 사용자에게 직접 할당 된 요소가있을 수 있습니다.