2023-11-20-TIL
Today I Learned
RBAC DB Modeling
RBAC(Role-Based Access Control)는 권한을 사용자에게 직접 주지 않고 역할에 묶어 두는 접근 제어 모델이다. NIST의 RBAC 프로젝트 페이지는 이렇게 요약한다.
“Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role.”
사용자에게는 하나 이상의 역할을, 역할에는 하나 이상의 권한을 부여한다는 뜻이다. NIST 모델은 ANSI/INCITS 359 표준으로 채택됐다.
권한을 사용자마다 직접 주면, 직원 100명에게 같은 권한을 하나 추가할 때 100건을 고쳐야 한다. 역할을 거치면 역할 하나에 권한을 추가하는 것으로 끝난다. 입사, 부서 이동, 퇴사도 역할을 붙이고 떼는 일로 바뀐다.
DB로 옮기면 기본 구조는 세 개의 엔티티와 두 개의 연결 테이블이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE users (id BIGINT PRIMARY KEY, name VARCHAR(100));
CREATE TABLE roles (id BIGINT PRIMARY KEY, name VARCHAR(50) UNIQUE);
CREATE TABLE permissions (id BIGINT PRIMARY KEY, name VARCHAR(100) UNIQUE); -- 예: order:read
CREATE TABLE user_roles (
user_id BIGINT REFERENCES users(id),
role_id BIGINT REFERENCES roles(id),
PRIMARY KEY (user_id, role_id)
);
CREATE TABLE role_permissions (
role_id BIGINT REFERENCES roles(id),
permission_id BIGINT REFERENCES permissions(id),
PRIMARY KEY (role_id, permission_id)
);
사용자와 역할, 역할과 권한이 모두 다대다 관계라서 연결 테이블이 둘 필요하다. “이 사용자가 order:read 권한을 가졌는가”는 user_roles와 role_permissions를 조인해서 확인한다. 요청마다 조인하지 않으려고 로그인 시점에 권한 목록을 계산해 토큰이나 세션에 담아 두기도 한다. 이 경우 역할의 권한을 바꿔도 이미 발급된 토큰에는 반영되지 않는다는 점을 감안해야 한다.
NIST 모델에는 이 기본형(Core RBAC) 위에 역할 사이의 상속을 다루는 계층형 RBAC, 직무 분리 같은 제약을 거는 제약형 RBAC도 있다. 계층을 넣으려면 roles에 부모 역할을 가리키는 컬럼이나 별도 계층 테이블을 둔다.
- https://docs.bmc.com/docs/decisionsupportserverautomation/89/role-based-access-control-rbac-domain-661332200.html
댓글
아직 댓글이 없습니다