RBAC

 

 

 

RBAC(Role-based access control)는:

사용자에게 직접 권한을 주는 게 아니라,
"역할(Role)"에 권한을 묶어서 관리하는 방식

 

이다.

실무에서 가장 많이 쓰이는 권한 관리 방식이다.

---

가장 쉬운 예시

회사 시스템 생각하면 쉽다.

---

직접 권한 부여 방식 (비효율)

예:

홍길동:
- 주문조회
- 주문수정
- 회원조회
- 정산조회

 

이렇게 사용자마다 하나씩 넣으면:

사람 늘수록 지옥

 

된다.

---

RBAC 방식

권한들을 역할(Role)에 묶는다.

---

역할 생성

Role	권한
USER	조회
MANAGER	조회 + 수정
ADMIN	전체

---

사용자에게 역할 부여

사용자	역할
홍길동	USER
김팀장	MANAGER
관리자	ADMIN

---

핵심 구조

사용자
↓
역할(Role)
↓
권한(Permission)

 

이다.

---

즉 핵심은

권한을 사용자에 직접 안 붙임

 

이다.

---

왜 실무에서 RBAC 많이 쓰나?

엄청 관리하기 쉽기 때문.

---

예시

직원 1000명 있다고 가정.

---

권한 정책 변경

예:

MANAGER는 삭제 불가로 변경

 

---

RBAC면

MANAGER Role 하나만 수정

 

하면 끝.

---

직접 권한 방식이면

1000명 전부 수정해야 할 수도 있음.

---

실제 시스템 예시

쇼핑몰

Role	권한
CUSTOMER	상품조회
SELLER	상품등록
ADMIN	전체관리

---

ERP

Role	권한
STAFF	조회
ACCOUNTING	회계
HR	인사관리

---

Spring Security 실무

엄청 많이 사용.

---

예시

 

.hasRole("ADMIN")

 

또는:

 

@PreAuthorize("hasRole('ADMIN')")

 

---

흐름

로그인 후:

JWT / Session 안에 Role 저장

 

예:

 

{
  "userId":"hoon",
  "roles":["ADMIN"]
}

 

---

API 접근 시

ADMIN Role 있는가?

 

검사.

---

DB 구조도 보통 이렇게 감

---

1. USER

user_id	name
1	홍길동

---

2. ROLE

role_id	role_name
1	ADMIN

 

---

3. PERMISSION

perm_id	perm_name
1	ORDER_READ

---

4. USER_ROLE

user_id	role_id
1	1

---

5. ROLE_PERMISSION

role_id	perm_id
1	1

---

즉 연결 구조

USER ↔ ROLE ↔ PERMISSION

 

---

RBAC 장점

장점	설명
관리 쉬움	권한 중앙관리
확장 쉬움	역할만 추가
실무 적합	조직 구조와 잘 맞음
보안성 향상	최소권한 구성 쉬움

---

단점도 있음

조직이 복잡해지면:

Role 폭발

 

문제 생길 수 있음.

예:

SEOUL_MANAGER
BUSAN_MANAGER
HQ_MANAGER
...

 

끝없이 늘어남.

---

그래서 등장한 게

모델	특징
ACL	객체 단위 권한
ABAC	속성 기반 권한

---

ACL 예시

"이 문서는 홍길동만 수정 가능"

 

---

ABAC 예시

부서=회계
지역=서울
근무시간=업무시간

 

조건 기반.

---

하지만 현실에서는

대부분:

RBAC + 약간의 추가 정책

 

조합이 가장 많다.

---

실무 핵심 포인트

1. 최소 권한 원칙

필요한 권한만 부여

 

---

2. 서버에서 인가 검사

프론트 버튼 숨김만 하면 안 됨.

반드시 서버에서:

Role 체크

 

해야 한다.

---

3. JWT 위조 검증 중요

JWT role 믿기 전에:

• 서명 검증
• 만료 검사

필수.

---

핵심 한 줄

RBAC는:

권한을 사용자에게 직접 주지 않고,
역할(Role)에 묶어서 사용자에게 역할을 부여하는 권한 관리 방식

 

이다.