핵심 인사이트 (3줄 요약)
- 본질: RBAC(Role-Based Access Control)는 사용자에게 직접 권한을 주는 대신 역할(Role)에 권한을 묶어 관리하는 접근 통제 방식이다.
- 가치: 역할 기반으로 권한을 묶으면 최소 권한 원칙과 직무 분리(SoD, Separation of Duties)를 쉽게 적용할 수 있다.
- 판단: 감사는 권한이 "있느냐"보다 "과도하지 않느냐"를 봐야 하며, 접근 통제 매트릭스가 핵심 증적이 된다.
Ⅰ. 개요 및 필요성
권한 관리는 시스템 보안의 기본이다. 권한이 너무 많으면 사고가 커지고, 너무 적으면 업무가 막힌다.
RBAC는 역할을 기준으로 권한을 묶어, 사람의 변동이 있어도 정책을 유지하기 쉽게 만든다.
- 📢 섹션 요약 비유: 열쇠를 사람마다 따로 주지 않고, 사무실 역할별로 묶어 두는 방식이다.
Ⅱ. 아키텍처 및 핵심 원리
User
↓
Role
↓
Permission
↓
Object / Resource
| 구성 요소 | 역할 |
|---|---|
| User | 실제 사용자 |
| Role | 업무 단위의 역할 |
| Permission | 수행 가능한 행위 |
| Object | 보호 대상 자원 |
접근 통제 매트릭스는 "누가 어떤 자원에 어떤 권한을 갖는지"를 표로 나타낸다. RBAC는 이 표를 역할 중심으로 정리해 관리 부담을 줄인다.
- 📢 섹션 요약 비유: 사람 이름이 아니라 직책별로 문 열쇠를 묶어 두는 회사 사물함과 같다.
Ⅲ. 비교 및 연결
| 모델 | 기준 | 장점 | 한계 |
|---|---|---|---|
| DAC | 소유자 중심 | 유연함 | 통제가 약함 |
| MAC | 보안 등급 중심 | 강한 통제 | 경직됨 |
| RBAC | 역할 중심 | 관리 쉬움 | 역할이 많아지면 복잡 |
| ABAC | 속성 중심 | 정교함 | 정책 복잡도 높음 |
RBAC는 감사에서 특히 유용하다. 역할이 명확하면 누가 어떤 권한을 가져야 하는지 빠르게 검토할 수 있기 때문이다.
- 📢 섹션 요약 비유: 반장, 부반장, 청소 당번처럼 역할이 정해져 있으면 할 일이 덜 헷갈린다.
Ⅳ. 실무 적용 및 기술사 판단
체크리스트
- 역할이 업무 기준으로 잘 분리되어 있는가?
- 최소 권한 원칙이 적용되는가?
- 직무 분리(SoD) 위반이 없는가?
- 권한 부여와 회수 절차가 있는가?
- 로그와 감사 증적이 남는가?
안티패턴
- 개인별로 예외 권한을 무한히 주는 설계
- 역할 수가 너무 많아 관리가 깨지는 설계
- 감사 없이 권한만 계속 늘리는 설계
- 권한 회수 절차가 없는 설계
기술사 관점에서는 RBAC를 "권한 테이블"이 아니라 "조직 운영 구조"로 봐야 한다. 역할 설계가 곧 보안 설계다.
- 📢 섹션 요약 비유: 열쇠를 아무에게나 주지 말고, 맡은 일에 맞게 나눠야 한다.
Ⅴ. 기대효과 및 결론
RBAC는 권한 관리를 단순화하고, 감사와 운영의 예측 가능성을 높인다. 그래서 엔터프라이즈 시스템의 기본 패턴으로 널리 쓰인다.
결론적으로 RBAC는 역할을 통해 권한 오남용을 줄이는 실용적 통제 방식이다.
- 📢 섹션 요약 비유: 일할 사람과 열쇠를 맞춰 주면 관리가 훨씬 쉬워진다.
관련 개념 맵
Access Control Matrix
↓
Role
↓
RBAC
↓
Audit Evidence
관련 키워드 및 발전 흐름도
DAC / MAC
↓
RBAC
↓
ABAC
↓
Zero Trust
어린이를 위한 3줄 비유 설명
문 열쇠를 사람마다 따로 주면 복잡해요.
역할별로 열쇠를 나누면 쉬워져요.
RBAC는 그런 역할별 열쇠 관리예요.