콘텐츠로 이동

RBAC (역할 기반 접근 제어)

사용자 한 명 한 명에게 권한을 개별로 주다 보면, 누가 무엇을 볼 수 있는지 통제하기 어려워져요. RBAC(Role-Based Access Control, 역할 기반 접근 제어)는 개인이 아니라 '역할(Role)' 단위로 권한을 묶어 사람에게 그 역할을 부여하는 방식이에요. 역할 하나만 관리하면 그 역할을 가진 모든 사람의 권한이 한 번에 정리되죠.

회사에서도 "관리자", "편집자"처럼 직책 단위로 권한을 나누듯, 접근 제어도 같은 사고방식이에요. 사람이 아니라 역할에 권한을 매기니까, 구성원이 바뀌어도 역할만 다시 부여하면 됩니다.

하위 챕터

  • RBAC 모델 — 역할·권한·세션의 관계 (NIST 표준 기준)
  • RBAC 설계 — 계층·상속·제약으로 역할을 조직화하는 법

핵심 개념

역할과 권한의 분리. "데이터 볼 수 있음", "배포할 수 있음" 같은 권한(Permission)을 역할에 묶고, 사용자에게는 역할만 부여해요. 사용자마다 권한을 일일이 넣지 않고 역할을 바꾸는 것만으로 접근 범위가 바뀝니다.

사용자 ──> 역할 ──> 권한

최소 권한 원칙. 사람이 맡은 일에 필요한 만큼만 권한을 주는 원칙이에요. 불필요하게 넓은 권한을 주지 않아서, 권한이 악용되거나 실수로 잘못 쓰일 여지를 줄여요.

역할 계층과 정도. 조직 구조에 맞게 역할을 몇 단계로 나누기도 해요. 예를 들어 관리자, 편집자, 뷰어처럼 역할을 층층이 두고, 역할마다 접근 가능한 범위를 다르게 정합니다. 역할이 많아지면 각자에게 최소한의 권한만 주는지 점검하는 계기가 되기도 해요.

감사와 운영. 누가 어떤 역할을 갖고 있는지, 역할이 바뀌면 언제 바뀌었는지를 기록하면 접근 권한을 되짚기 쉬워져요. 역할과 권한 목록을 코드로 관리하면 변경 이력도 남아요.

일반적으로 사용자 → 역할 → 권한의 관계가 정해지고, 기능 코드는 "이 역할이면 허용" 같은 식으로 이 권한을 참조해요. 그래서 비즈니스 로직과 접근 제어가 느슨하게 연결됩니다.

사용 사례 / 실제 적용

멀티테넌트 구조에서는 고객(테넌트)별로 역할을 나눠 관리해요. 부서마다 접근 범위가 다르고, 사용자 개개인은 그 테넌트 안의 역할을 받아요. 같은 역할이어도 테넌트가 다르면 다른 데이터에만 접근하게 되죠. 이런 방식으로 "남의 고객 데이터를 못 보게" 합니다.

백엔드에서는 Spring Security 같은 프레임워크가 요청마다 사용자의 역할을 확인해 권한을 판단해요. 역할은 감사 로그와 함께 남겨서, 누가 언제 어떤 권한으로 접근했는지 되짚을 수 있도록 해요.

요약하면 RBAC는 "권한을 개인에게 매기지 말고 역할에 매기고, 사람은 역할만 받게 하자"는 원칙이에요. 이 원칙 아래에서 역할 목록이 곧 접근 통제의 지도가 됩니다. 이렇게 역할과 권한을 분리해 두면, 제품 기능이 늘어도 접근 제어는 역할과 권한 표만 고치면 되는 구조가 유지돼요.

더 알아보기