# RBAC (역할 기반 접근 제어)

## 1. 개요
**RBAC(Role-Based Access Control, 역할 기반 접근 제어)**는 사용자의 개별 신원이 아닌, 조직 내에서 수행하는 '역할(Role)'에 따라 시스템 자원에 대한 접근 권한을 부여하는 보안 모델이다.

전통적인 접근 제어 방식인 **DAC(Discretionary Access Control, 임의적 접근 제어)**는 자원 소유자가 임의로 권한을 부여하므로 관리가 파편화되고 보안 취약점이 발생하기 쉽다. 반면, **MAC(Mandatory Access Control, 강제적 접근 제어)**는 시스템이 정한 엄격한 보안 등급에 따라 접근을 통제하여 매우 안전하지만, 설정이 복잡하고 유연성이 떨어진다는 단점이 있다. RBAC는 이러한 두 모델의 절충안으로서, 권한 관리를 '역할'이라는 추상화된 계층으로 통합함으로써 대규모 조직에서도 효율적이고 일관된 보안 정책을 적용할 수 있도록 설계되었다.

## 2. 동작 원리 및 구조
RBAC의 핵심은 사용자에게 직접 권한을 부여하지 않고, **사용자 $\rightarrow$ 역할 $\rightarrow$ 권한**으로 이어지는 간접 할당 구조를 사용하는 것이다.

### 2.1 권한 할당 프로세스
권한 부여 과정은 다음과 같은 논리적 흐름을 따른다.
`사용자(User)` $\xrightarrow{할당}$ `역할(Role)` $\xrightarrow{부여}$ `권한(Permission)` $\rightarrow$ `[자원(Object)에 대한 작업(Operation)]`

**[권한 할당 다이어그램]**
```mermaid
graph LR
    U1[사용자 A] --> R1[팀장 역할]
    U2[사용자 B] --> R1[팀장 역할]
    U3[사용자 C] --> R2[팀원 역할]
    
    R1 --> P1[문서 읽기/쓰기/삭제]
    R1 --> P2[결재 승인]
    R2 --> P1[문서 읽기/쓰기]
```

### 2.2 매핑 테이블 예시
다음은 실제 시스템에서 구현될 때의 논리적 매핑 구조이다.

| 사용자 (User) | 할당된 역할 (Role) | 역할별 권한 (Permission) | 접근 가능 자원 (Resource) |
| :--- | :--- | :--- | :--- |
| 김철수 | 관리자 (Admin) | 모든 권한 (Full Access) | 시스템 전체 설정, 사용자 계정 |
| 이영희 | 편집자 (Editor) | 읽기, 수정, 게시 | 콘텐츠 DB, 게시판 |
| 박지민 | 뷰어 (Viewer) | 읽기 전용 (Read-only) | 공개 게시물, 공지사항 |

## 3. RBAC의 주요 모델 및 계층
RBAC는 요구사항의 복잡도에 따라 여러 단계의 모델로 발전해 왔다.

### 3.1 모델별 특징 비교
| 모델 | 주요 특징 | 핵심 개념 | 비고 |
| :--- | :--- | :--- | :--- |
| **Core RBAC (RBAC0)** | 가장 기본적인 형태 | 사용자-역할-권한의 단순 매핑 | 기본 권한 관리 |
| **Hierarchical RBAC (RBAC1)** | 역할 간의 상속 관계 도입 | 상위 역할이 하위 역할의 권한을 포함 | 조직도 반영 가능 |
| **Constrained RBAC (RBAC2)** | 역할 수행에 제약 조건 추가 | 상호 배제(SoD), 시간 제한 등 | 보안 강화 및 부정 방지 |

*참고: **RBAC3**는 위 세 가지 모델(RBAC0, RBAC1, RBAC2)의 모든 특성을 통합한 완전한 모델을 의미한다.*

- **계층적 RBAC (Hierarchical RBAC):** 예를 들어 '팀장' 역할은 '팀원' 역할이 가진 모든 권한을 자동으로 상속받으며, 추가적으로 '결재 권한'을 더 갖는 구조이다.
- **제약 조건 RBAC (Constrained RBAC):** **SoD(Separation of Duties, 직무 분리)** 개념이 적용된다. 예를 들어, '결제 요청자' 역할과 '결제 승인자' 역할을 한 사람이 동시에 가질 수 없도록 제한하여 내부 부정행위를 방지한다.

## 4. RBAC의 장점과 한계

### 4.1 장점
1. **관리 효율성:** 수천 명의 사용자에게 개별 권한을 부여하는 대신, 몇 개의 역할만 정의하여 할당하면 되므로 관리 비용이 획기적으로 감소한다.
2. **보안성 향상:** '최소 권한 원칙(Principle of Least Privilege)'을 적용하기 쉬우며, 인사 이동 시 역할만 변경하면 즉시 권한이 갱신된다.
3. **규정 준수(Compliance):** 누가 어떤 역할을 통해 어떤 권한을 가졌는지 명확히 감사(Audit)할 수 있다.

### 4.2 한계: 역할 폭발 (Role Explosion)
RBAC의 가장 큰 운영상 한계는 **역할 폭발(Role Explosion)** 현상이다. 이는 세부적인 권한 제어가 필요해질수록 역할의 수가 기하급수적으로 늘어나는 현상을 말한다.

**[역할 폭발 예시]**
- 서울 지점 $\times$ 영업팀 $\times$ 대리
- 부산 지점 $\times$ 영업팀 $\times$ 대리
- 서울 지점 $\times$ 인사팀 $\times$ 대리
$\rightarrow$ **위와 같이 지역, 부서, 직급의 모든 조합마다 새로운 역할을 생성해야 하는 상황**

### 4.3 역할 폭발 해결 방안
역할 폭발을 방지하기 위해 다음과 같은 전략을 사용한다.
- **역할 계층화:** 공통 권한을 하위 역할로 묶고 상위 역할이 이를 상속받게 하여 중복 정의를 줄인다.
- **매개변수화된 역할:** 역할에 변수(예: 지역, 부서)를 도입하여 하나의 역할 정의로 여러 상황에 대응한다.
- **ABAC로의 전환:** 정적인 역할 대신 동적인 속성(Attribute) 기반 제어를 혼합하여 사용한다.

## 5. 실제 구현 및 활용 사례

### 5.1 활용 사례
- **클라우드 서비스 (AWS IAM):** AWS에서는 'IAM Role'을 통해 EC2 인스턴스나 Lambda 함수에 특정 권한 세트를 부여하여 서비스 간 안전한 통신을 구현한다.
- **기업 인사 시스템:** 신입 사원 입사 시 '사원' 역할을 부여하고, 승진 시 '과장' 역할로 변경함으로써 접근 가능한 결재 라인과 문서를 자동으로 제어한다.
- **Kubernetes (K8s):** `ClusterRole`과 `RoleBinding`을 통해 클러스터 내 리소스(Pod, Service 등)에 대한 접근 권한을 제어한다.

### 5.2 설정 예시 (YAML 형식)
다음은 Kubernetes 스타일의 역할 정의 및 할당 예시이다.

```yaml
# 1. 역할 정의 (Role Definition)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["get", "watch", "list"] # 리소스에 대해 수행 가능한 작업 (get: 단일 조회, list: 목록 조회 등)

---
# 2. 역할 할당 (Role Binding)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-user
subjects:
- kind: User
  name: "alice@company.com" # 사용자 Alice에게
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # 위에서 정의한 pod-reader 역할 할당
  apiGroup: rbac.authorization.k8s.io
```

### 5.3 DB 스키마 설계 예시
RBAC를 데이터베이스로 구현할 때는 일반적으로 다음과 같은 다대다(N:M) 관계의 테이블 구조를 설계한다.

- **Users**: 사용자 정보 (`user_id`, `username`, `email`)
- **Roles**: 역할 정의 (`role_id`, `role_name`, `description`)
- **Permissions**: 세부 권한 (`perm_id`, `perm_name`, `resource`, `action`)
- **User_Roles**: 사용자-역할 매핑 (`user_id`, `role_id`)
- **Role_Permissions**: 역할-권한 매핑 (`role_id`, `perm_id`)

## 6. 관련 개념 및 발전 방향

### 6.1 RBAC vs ABAC
RBAC의 정적인 한계를 극복하기 위해 **ABAC(Attribute-Based Access Control, 속성 기반 접근 제어)**가 등장하였다.

| 구분 | RBAC (역할 기반) | ABAC (속성 기반) |
| :--- | :--- | :--- |
| **판단 기준** | 사용자가 어떤 **역할**인가? | 사용자의 **속성**이 무엇인가? |
| **제어 요소** | 역할 (Role) | 사용자, 자원, 환경 속성 (Attribute) |
| **유연성** | 낮음 (역할 변경 필요) | 높음 (조건식으로 제어 가능) |
| **복잡도** | 낮음 (설계가 단순함) | 높음 (정책 엔진 필요) |
| **예시** | "관리자는 모든 파일을 읽을 수 있다." | "인사팀 소속이며, 근무 시간 내에, 서울 IP로 접속한 사용자만 읽을 수 있다." |

### 6.2 현대적 트렌드
최근의 보안 트렌드는 **제로 트러스트(Zero Trust)** 모델로 이동하고 있다. 단순히 역할이 맞다고 해서 신뢰하는 것이 아니라, 접속할 때마다 사용자의 기기 상태, 접속 위치, 인증 수준 등 다양한 속성을 실시간으로 검증하는 **RBAC와 ABAC의 하이브리드 모델**이 주를 이루고 있다.