콘텐츠로 이동

RBAC 모델 — 역할·권한·세션의 관계

RBAC(Role-Based Access Control)의 정체를 한 문장으로 말하면 "권한을 사람이 아니라 역할에 매긴다"예요. 그런데 실제 시스템을 설계하려면 "사용자, 역할, 권한, 세션"이 서로 어떻게 엮이는지 구조로 알아야 해요. 그래서 NIST가 정리한 RBAC 모델을 기준으로 그 관계를 짚어볼게요.

개요

NIST가 제안한 RBAC 표준 모델은 개념을 핵심(Core), 계층(Hierarchical), 제약(Constrained) 세 수준으로 나눠 설명해요. 이 중 먼저 핵심 모델의 구성 요소와 그 관계를 이해하는 게 출발점입니다.

핵심 개념

다섯 가지 기본 요소가 엮여요. 사용자(User), 역할(Role), 권한(Permission), 세션(Session), 그리고 객체·연산이 있어요. 권한은 "어떤 객체에서 어떤 연산을 할 수 있는가"(예: "문서를 읽는다")로 정의되고, 역할이 권한의 묶음 역할을 해요.

사용자 ──> (세션) ──> 역할 ──> 권한
                        권한: (객체, 연산)

권한-역할, 역할-사용자의 이중 할당. RBAC의 핵심은 "사용자에게 권한을 직접 주지 않는다"는 거예요. 대신 역할에 권한을 부여하고, 사용자에게 역할을 부여해요. 이렇게 권한과 사용자를 역할로 분리하면, 관리 대상이 "사람 × 권한"이 아니라 "역할"로 줄어듭니다.

세션(Session)이 역할을 "활성화"해요. 사용자가 로그인하면 세션이 생기고, 그 세션은 사용자가 가진 역할 중 일부를 활성화해요. 즉 사용자가 "모든 역할"을 항상 쓰는 게 아니라, 세션에 맡긴 역할만큼만 권한을 행사할 수 있어요. 한 사용자가 여러 역할을 가졌어도 세션에서 골라 활성화하는 식이죠.

최소 권한과 직무 분리. NIST 모델은 역할의 설계 원칙도 함께 얘기해요. 사용자에게 직무에 필요한 만큼만 역할을 주는 최소 권한, 그리고 상충하는 직무를 한 사람이 다 못 하게 하는 직무 분리(SoD)가 대표적이에요. 예를 들어 "신청하는 자"와 "승인하는 자"가 같은 역할에 들어가면 안 되죠.

실제 적용(데이터스케쳐스)

멀티테넌트 구조에서는 테넌트(고객)별로 역할을 나눠 관리해요. 같은 "관리자" 역할이라도 테넌트가 다르면 다른 테넌트의 데이터에는 접근할 수 없게 권한(객체)을 테넌트와 묶어서 정의해요. 사용자는 자기 테넌트 안에서만 역할을 받아요.

백엔드는 요청이 들어올 때 사용자의 세션(또는 토큰)에 활성화된 역할을 확인하고, 그 역할에 속한 권한인지를 판단해요. 역할과 권한의 매핑을 코드(또는 설정)로 관리하면 "누가 어떤 권한인지"를 감사 로그로도 되짚을 수 있어요.

더 알아보기