역할 기반 접근통제
더 많은 작업
- RBAC, Role Based Access Control
- DAC와 MAC의 단점을 보완한 접근통제 정책
- 권한을 사용자가 아닌 역할(직무 단위의 그룹)에 부여하고, 그 역할이 수행하여야 할 일을 정의한다.
- 초기 관리의 오버헤드를 줄이고, 직무를 기반으로 하는 접근통제 정책이다.
- 각 주체에 할당된 역할과, 그 역할에 부여된 권한(객체에 대한 연산 허가)에 근거하여 접근 통제를 운영한다.
- 역할과 권한에 대한 정의는 관리자에 의해 설정 및 변경이 가능하다.
- 비 임의적(Non-Discretionary) 접근통제 정책 또는 임무 기반(Task-Based) 접근통제 정책으로 불리기도 한다.
- 요즘 나오는 업무 시스템들은 대부분 RBAC이다. 인사담당자, 총무담당자 등과 같이 권한 그룹을 통해 접근을 제어한다.
- 리눅스의 그룹 퍼미션 또한 RBAC라고 할 수 있다. 다만 엄밀히는 그룹과 역할에 차이가 있다(아래 그룹과 역할의 차이 참고).
역할 기반 접근통제는 1992년 데이비드 페라이올로(David Ferraiolo)와 릭 쿤(Rick Kuhn)이 NIST에서 정식화한 모델이다. 2000년 샌두(Sandhu) 등의 RBAC96 틀과 합쳐 NIST RBAC 모델로 발표되었고, 2004년 2월 미국 국가 표준 ANSI/INCITS 359-2004로 채택되었으며 2012년 INCITS 359-2012로 개정되었다. 사용자마다 권한을 따로 주던 방식은 사용자가 수천 명이 되면 관리가 불가능해지고 실수가 쌓인다. RBAC는 "이 직무를 맡은 사람은 이 일을 할 수 있다"는 조직 구조를 그대로 권한 구조로 옮기므로, 입사·전보·퇴사 때 역할만 바꾸면 권한이 따라 바뀐다. 이 때문에 최소 권한 원칙과 직무 분리를 대규모로 적용하기에 알맞다.
NIST는 RBAC를 MAC·DAC와 별개의 독립된 모델로 보며, RBAC로 MAC과 DAC를 흉내 낼 수 있다는 연구 결과도 소개한다.
INCITS 359의 참조 모델은 네 가지 구성 요소로 이루어진다. 아래로 갈수록 앞 단계를 포함하며 기능이 늘어난다.
| 구성 요소 | 내용 | 예 |
|---|---|---|
| 핵심 RBAC (Core RBAC) | 사용자(user), 역할(role), 권한(permission = 연산 + 객체), 세션(session)의 기본 요소. 사용자-역할, 역할-권한 할당이 모두 다대다 관계이며, 사용자는 세션에서 자신에게 할당된 역할 중 일부만 활성화할 수 있다. | 홍길동에게 '구매 담당' 역할 할당, '구매 담당'에 '발주서 작성' 권한 부여 |
| 계층적 RBAC (Hierarchical RBAC) | 역할 사이에 상속 관계를 둔다. 상위 역할은 하위 역할의 권한을 물려받는다. 임의의 계층을 허용하는 일반 계층과 트리 같은 제한된 구조만 허용하는 제한 계층이 있다. | '팀장' 역할이 '팀원' 역할의 권한을 모두 포함 |
| 정적 직무 분리 (SSD, Static Separation of Duty) | 사용자에게 역할을 할당하는 시점에 제약을 건다. 서로 충돌하는 역할을 한 사람이 동시에 가질 수 없다. | '발주 요청'과 '발주 승인' 역할을 한 사람에게 함께 할당 금지 |
| 동적 직무 분리 (DSD, Dynamic Separation of Duty) | 두 역할을 모두 할당받을 수는 있지만 한 세션 안에서 동시에 활성화하지 못하게 한다. | 출납 담당과 출납 감사 역할을 모두 가졌어도 같은 세션에서 함께 쓰지 못함 |
- 정적 직무 분리는 할당 단계의 통제, 동적 직무 분리는 실행(세션) 단계의 통제이다. 동적 직무 분리가 더 유연하지만 구현이 복잡하다.
CISSP 출제 기준 5.2의 '그룹과 역할(Groups and Roles)' 항목과 이어지는 내용이다. 겉보기에는 비슷하지만 NIST는 다음과 같이 구분한다.
| 구분 | 그룹 (Group) | 역할 (Role) |
|---|---|---|
| 정의 | 사용자의 모음 | 권한의 모음이자 직무의 표현 |
| 권한 연결 | 그룹과 사용자 개인 모두에 권한을 직접 붙일 수 있다 | 권한은 역할에만 붙고, 사용자는 역할을 통해서만 권한을 얻는다 |
| 세션 | 개념 없음. 소속된 모든 그룹의 권한이 항상 적용된다 | 세션마다 필요한 역할만 활성화할 수 있다 |
| 결과 | 사용자에게 직접 붙은 예외 권한이 쌓여 "누가 무엇을 할 수 있는가"를 파악하기 어렵다 | 역할만 보면 권한을 알 수 있어 검토와 감사가 쉽다 |
실무에서는 윈도우 액티브 디렉터리 보안 그룹이나 리눅스 그룹을 역할처럼 운영하는 경우가 많다. 이때 개인 계정에 권한을 직접 주는 예외를 금지해야 RBAC의 장점이 살아난다. 사람이 아닌 서비스·워크로드도 역할을 받는다. 클라우드 IAM의 역할(예: AWS IAM 역할)이 대표적이다.
역할 폭증(role explosion)은 조직의 세부 사정을 모두 역할로 표현하려다 역할 수가 사용자 수에 가까울 만큼 늘어나는 현상이다. '서울 지점 + 야간 + 계약직 + 영업 담당'처럼 부서, 지역, 시간, 고용 형태 조합마다 역할을 만들면 관리 부담이 RBAC 도입 이전으로 돌아간다.
- 원인: 상황 조건(시간, 위치, 기기 상태)을 역할로 표현하려 함, 예외 요청마다 새 역할 생성, 퇴역한 역할 미정리
- 대책: 역할 공학(role engineering)으로 직무 분석에 근거해 역할을 설계, 역할 계층 활용, 정기적인 접근 권한 검토로 쓰지 않는 역할 정리, 상황 조건은 속성 기반 규칙으로 분리
- 역할 설계는 사람이 새 역할을 맡거나(전보) 떠날 때의 처리와 함께 계정 수명 주기 관리에 포함된다. 전보자가 이전 역할을 그대로 가지는 권한 누적(privilege creep)도 RBAC 운영의 대표적인 문제이다.
| 구분 | RBAC | ABAC |
|---|---|---|
| 판단 근거 | 사용자에게 할당된 역할 | 주체·객체·행위·환경의 속성과 이를 조합한 정책 |
| 정책 예 | "인사 담당 역할은 인사 기록을 읽을 수 있다" | "인사 부서 소속이고, 근무 시간이며, 회사 관리 기기에서 접속하면, 같은 지역 직원의 인사 기록을 읽을 수 있다" |
| 장점 | 이해하기 쉽고, 검토·감사가 쉽다 | 세밀하고 상황에 따라 바뀌는 통제가 가능, 역할 폭증을 피할 수 있다 |
| 단점 | 세밀한 조건을 표현하려면 역할 폭증 | 정책이 복잡해지고, "누가 무엇에 접근 가능한가"를 미리 파악하기 어렵다 |
| 적합한 환경 | 직무 구조가 안정적인 조직 내부 시스템 | 조직 간 협업, 클라우드, 제로 트러스트 환경 |
실무에서는 둘을 함께 쓰는 경우가 많다. 역할로 기본 권한을 주고, 속성 규칙으로 시간·위치·기기 조건을 덧붙인다. NIST SP 800-162도 역할을 주체 속성의 하나로 볼 수 있다고 설명한다.
- RBAC는 직무(역할)를 기준으로 권한을 준다. 이직·전보가 잦은 조직에서 관리 부담을 줄이는 데 가장 알맞다.
- RBAC는 비임의적(non-discretionary) 접근통제이다. 사용자가 자기 판단으로 권한을 넘길 수 없다.
- 보안 등급(clearance)과 객체 등급(classification)을 비교하는 것은 MAC이다. 흔한 오답: RBAC를 레이블 비교로 설명한 선택지.
- 정적 직무 분리(할당 시점)와 동적 직무 분리(세션 활성화 시점)를 구분한다.
- 역할 폭증이 문제이면 ABAC 결합이나 역할 공학·정기 검토를 고른다.
- 그룹은 사용자의 모음, 역할은 권한의 모음이다. 개인 계정에 직접 붙은 권한은 RBAC를 무너뜨린다.