RBAC

개념

RBAC는 **역할(role)**을 중간 층으로 두는 접근 제어 모델이다. 사용자에게 권한을 직접 주는 대신 역할을 부여하고, 역할에 권한을 묶는다. 웹 서비스·클라우드 인프라에서 가장 흔히 쓰는 모델.

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

admin/editor/viewer처럼 나누고 새 사용자에겐 역할만 부여한다. 권한 관리 단위가 "사람 수"에서 "역할 수"로 줄어드는 게 핵심.

왜 필요한가

권한을 사용자마다 직접 주면 두 가지 문제가 생긴다.

• 관리 비용 — 사용자 100명에 권한 50개면 개별 매핑이 5000개. 역할로 묶으면 "admin/editor/viewer" 3개만 관리
• 일관성 — "editor는 글 수정 가능"을 한 곳에서 정의하니 실수가 줄어든다

예시

• admin — 모든 API 접근 가능
• editor — 글 작성, 수정, 삭제
• viewer — 읽기만 가능

장단점

• 단순하고 관리하기 쉬움
• 조건이 복잡해지면 역할이 폭발적으로 늘어남 (role explosion)
• "engineering 부서의 시니어만 프로덕션 배포 가능"처럼 속성 조합 조건은 RBAC만으로 어려움

role explosion이 시작되면 ABAC나 OPA 같은 속성/정책 기반 모델을 섞는 걸 검토한다.

쓰는 곳

• Kubernetes RBAC (사용자 → role → verb/resource)
• AWS IAM (정책을 role에 attach)
• Keycloak realm/client role
• 대부분의 웹 서비스 권한 시스템

더 보기

• ABAC — 역할이 아니라 속성 조합으로 판단하는 모델
• OPA — 정책을 코드에서 분리해서 관리하는 엔진
• 멀티테넌트-RBAC-설계 — 테넌트 격리와 역할 계층을 분리하는 패턴
• OAuth-OIDC-SAML — RBAC의 "사용자"가 어떻게 인증되는가