# RBAC의 이해와 구현 가이드 RBAC(Roles-Based Access Control)은 사용자(User)에게 직접 권한을 부여하기보다는 사용자에게 역할(Role)을 부여하고, 각 역할에 필요한 권한(Permission)을 할당하는 접근 제어 모델이다. 이를 통해 대규모 시스템에서도 권한 관리의 복잡성을 줄이고, 최소 권한 원칙(Least Privilege)을 실무에 적용하기 쉽게 만든다. 본 문서는 RBAC의 기본 개념부터 설계 원칙, 구현 방법, 운영 관리까지 체계적으로 정리한다. ## 1. 개요 - 목적: 조직의 자원에 대한 접근을 역할 중심으로 관리하여 보안 강화와 관리 효율성 향상을 달성한다. - 핵심 아이디어: User → Role → Permission의 계층적 매핑으로 권한을 결정한다. - 핵심 이점: - 관리 용이성: 사용자 수의 증가에도 역할 재배치로 권한 관리가 용이 - 일관성: 동일 역할을 가진 사용자 간 권한 일관성 보장 - 규정 준수: 최소 권한 원칙과 Separation of Duties(SoD)의 구현이 용이 RBAC의 기본 구조를 간단히 표현하면 다음과 같다. - 역할 기반 권한 매핑: Role에 Permission이 연결되고, User가 Role에 소속된다. - 사용자에게 직접 권한을 부여하는 대신 역할에 권한을 부여하므로 변경 관리가 단순해진다. 특히 인증(Authentication)과 인가(Authorization)는 분리되어 다루어진다. 인증이 사용자 신원을 확인하는 과정이라면, 인가는 확인된 신원에 대해 어떤 자원에 접근할 수 있는지 결정하는 과정이다. RBAC는 인가 단계에서 역할 기반의 권한 매핑을 활용한다. - 예: 특정 시스템에서 파일에 대한 읽기 권한이 필요하다면, 해당 권한은 특정 역할에 연결되어 있으며, 사용자는 그 역할을 통해 간접적으로 권한을 획득한다. - 산출물 예시: 권한 매핑은 주로 다음과 같은 관계로 표현된다. - $UR \subseteq U \times R$ (User-Role 할당) - $RP \subseteq R \times P$ (Role-Permission 할당) - 사용자 $u$의 권한 집합은 $P_u = \{ p \in P \mid \exists r \in R: (u,r) \in UR \land (r,p) \in RP \}$ 이와 같은 수식은 인가 정책의 명확성을 높이고, 감사 시 추적 가능성을 보장한다. --- ## 2. 핵심 용어(Glossary) - User: 시스템에 접근하는 주체 - Role: 특정 업무 책임을 반영하는 권한 묶음 - Permission: 자원에 대한 구체적 행위를 나타내는 권한 - Session: 사용자가 로그인한 동안 활성화된 역할의 집합 - User-Role Assignment (URA): 사용자와 역할의 연결 관계 - Role-Permission Assignment (RPA): 역할과 권한의 연결 관계 - Role Hierarchy: 역할 간 상속 관계를 통해 상위 역할의 권한을 하위 역할이 자동으로 상속하는 구조 - Constraint: SoD(Separation of Duties)와 같은 제약 조건 - SSD: Static Separation of Duties, 인스턴스 시점에서의 역할 분리 제약 - DSD: Dynamic Separation of Duties, 실행 중 시점에서의 역할 분리 제약 - Least Privilege: 필요한 최소 권한만 부여하는 원칙 - RBAC0, RBAC1, RBAC2, RBAC3: RBAC 계층의 확장 버전으로, 최소 권한 보장, 역할 계층, 제약 조건 등을 포함하는 모델 시퀀스 --- ## 3. 기본 개념과 관계 RBAC는 다음 주요 구성 요소를 통해 권한 관리를 구현한다. - User: 시스템에 접근하는 주체 - Role: 다수의 권한을 묶은 집합 단위 - Permission: 자원에 대한 접근 가능 행위 - URA: 사용자의 역할 부여 관계 - RPA: 역할과 권한의 부여 관계 - Session: 로그인 기간 동안 활성화된 역할의 집합 권한 산출의 일반적 흐름은 다음과 같다. - 사용자는 한 개 또는 다수의 역할에 배정될 수 있다. - 각 역할은 하나 이상의 권한을 보유한다. - 특정 사용자가 시스템에 접근하려 할 때, 활성화된 세션에서 연결된 역할들의 권한 합집합이 사용자의 권한이 된다. 또한 역할 계층(Role Hierarchy)을 도입하면, 상위 역할의 모든 권한이 하위 역할에 상속될 수 있다. 예를 들어, 관리자(Admin) 역할이 읽기(Read), 쓰기(Write), 삭제(Delete) 권한을 보유하고 있다면, 하위 역할인 운영자(Operator)가 Admin의 일부 권한을 상속받도록 구성할 수 있다. - 수식 예시: - $P_u = \{ p \in P \mid \exists r \in R : (u,r) \in UR \land (r,p) \in RP \}$ - 만약 RoleHierarchy가 존재하면, 상위 역할의 권한도 자동으로 하위 역할에 포함될 수 있다. --- ## 4. RBAC 모델 유형과 차이 - RBAC0: 기본 모델로, URA와 RPA만 존재. 권한의 계층이나 제약 조건은 없다. - RBAC1: Role Hierarchy를 포함하여 역할 간 상속이 가능하다. - RBAC2: Separation of Duties(SoD) 제약을 포함한다. 예를 들어, 한 사용자가 하나의 프로세스에서 상충되는 역할을 동시에 가지지 않도록 한다. - RBAC3: 문맥 제약, 다중 속성 제약 등 다양한 고급 제약 조건을 포함한다. 가장 강력하고 일반적으로 가장 복잡한 구성이다. 현실 시스템에서는 RBAC2 또는 RBAC3의 구성을 많이 사용하며, SoD 제약과 역할 계층을 통해 관리의 체계를 강화한다. --- ## 5. 구성 요소 및 데이터 모델 주요 엔티티와 관계를 간단히 정리하면 다음과 같다. - 엔티티 - User(사용자) - Role(역할) - Permission(권한) - Session(세션) - RoleHierarchy(역할 계층, 선택적) - Constraint(제약) - 관계 - URA: User ↔ Role - RPA: Role ↔ Permission - Session: User가 활성화한 Role의 집합 - 데이터 모델 예시(간단한 관계형 스키마) - Users(UserID, UserName, Active) - Roles(RoleID, RoleName) - Permissions(PermissionID, PermissionName) - UserRoles(UserID, RoleID) - RolePermissions(RoleID, PermissionID) - RoleHierarchy(AncestorRoleID, DescendantRoleID) -- 선택적 - SSDConstraints(RoleID, ForbiddenRoleID) -- 선택적 - DSDConstraints(UserID, AllowedRoleID1, AllowedRoleID2) -- 선택적 - 간단한 SQL 예시(주요 부분) - CREATE TABLE Users (UserID BIGINT PRIMARY KEY, UserName VARCHAR(100), Active BOOLEAN); - CREATE TABLE Roles (RoleID BIGINT PRIMARY KEY, RoleName VARCHAR(100)); - CREATE TABLE Permissions (PermissionID BIGINT PRIMARY KEY, PermissionName VARCHAR(100)); - CREATE TABLE UserRoles (UserID BIGINT, RoleID BIGINT, PRIMARY KEY (UserID, RoleID), FOREIGN KEY (UserID) REFERENCES Users(UserID), FOREIGN KEY (RoleID) REFERENCES Roles(RoleID)); - CREATE TABLE RolePermissions (RoleID BIGINT, PermissionID BIGINT, PRIMARY KEY (RoleID, PermissionID), FOREIGN KEY (RoleID) REFERENCES Roles(RoleID), FOREIGN KEY (PermissionID) REFERENCES Permissions(PermissionID)); - 간단한 권한 산출 예시 - $P_u = \{ p \in P \mid \exists r \in R: (u,r) \in UR \land (r,p) \in RP \}$ - 위 수식을 통해 한 사용자의 최종 권한 집합을 명확하게 표현할 수 있다. --- ## 6. 구현 설계 원칙 - 최소 권한 원칙(Least Privilege): 각 역할은 업무 수행에 필요한 최소 권한만 보유하도록 설계한다. - 역할 최적화: 역할 폭발(role explosion)을 방지하기 위해 역할의 수를 적정하게 유지하고, 중복되는 권한은 가능하면 하나의 역할로 합친다. - SoD(Separation of Duties) 적용: 작업 흐름에서 권한 남용을 방지하기 위해 상충되는 역할은 같은 사용자가 가지지 않도록 제약한다. - 역할 계층 설계의 명확성: 상위 역할의 권한이 하위 역할에 자동으로 상속된다는 점을 문서화하고, 계층 구성을 직관적으로 유지한다. - 감사와 가시성: 어떤 사용자가 어떤 역할에서 어떤 권한을 얻었는지, 언제 변경되었는지를 추적 가능하도록 로깅하고 주기적인 리뷰를 실시한다. - 정책 변경 관리: 역할 업데이트, 권한 추가/제거, 제약 조건 변경 시 변경 이력을 남기고 승인 프로세스를 거친다. --- ## 7. 구현 가이드라인 및 절차 - 1단계: 요구사항 수집 - 어떤 자원(Resource)이 있으며, 어떤 행위(Permission)가 필요한지 목록 작성 - 업무 프로세스와 역할 간의 매핑 초안 구성 - 2단계: RBAC 모델 설계 - RBAC0/1/2/3 중 조직에 맞는 모델 결정 - 역할 정의, 권한 매핑, 역할 계층 구조 설계 - SoD/SSD/DSD 제약 정의 - 3단계: 데이터 모델링 및 마이그레이션 계획 - 기존 권한 데이터를 RBAC 형식으로 매핑 - 데이터 이관 전략과 롤백 계획 수립 - 4단계: 프로비저닝(Provisioning) 프로세스 정의 - 신규 직원, 역할 변경, 이직에 대한 프로비저닝 워크플로우 - 정책 기반 자동 프로비저닝 도구 도입 여부 판단 - 5단계: 운영 및 거버넌스 - 정기적인 권한 리뷰 주기 설정 - SoD 제약의 검토 및 갱신 - 감사 로그 및 변경 이력 관리 - 6단계: 보안 및 성능 고려 - 역할 수 최소화 및 역할 병합 전략 - 대용량 시스템에서의 조회 성능 및 인덱스 전략 - 캐시 전략과 세션 관리 - 7단계: 검증 및 테스트 - 권한 부여/해지 시나리오 테스트 - 긴급 상황에서의 즉시 롤백 시나리오 점검 --- ## 8. 구현 예시: 간단한 스키마와 흐름 - 기본 흐름 - 사용자가 시스템에 로그인 → 세션 생성 → 활성화된 역할에 따른 권한 부여 - 권한은 RolePermissions(RP)을 통해 결정되며, 필요 시 RoleHierarchy를 통해 상위 역할의 권한까지 확장된다 - inline 수식 예시 - 사용자의 최종 권한 집합: $P_u = \{ p \in P \mid \exists r \in R : (u,r) \in UR \land (r,p) \in RP \}$ - 역할 상속이 적용된 경우: $P_u = \bigcup_{r \in ActiveRoles(u)} P_r$, 여기에 $P_r$는 RolePermissions(r)의 권한 집합 - 간단한 예시 데이터 - Users: Alice, Bob - Roles: Admin, Engineer, Auditor - Permissions: ReadCode, WriteCode, Deploy, ViewLogs - UserRoles: (Alice, Admin), (Bob, Engineer) - RolePermissions: (Admin, {ReadCode, WriteCode, Deploy, ViewLogs}), (Engineer, {ReadCode, WriteCode}) --- ## 9. 운영 및 거버넌스 - 역할 관리 프로세스 - 신규 역할 생성 시 업무 분석을 통한 목적 정의 - 역할 간 격차 분석 및 중복 제거 - 변경 관리 체계를 통한 이력 관리 - 정기적 권한 리뷰 - 최소 주기: 분기별 혹은 반기별 - SoD 위반 여부 점검 및 필요 시 즉시 조치 - 로깅 및 감사 - 권한 변경 이력, 로그인/세션 이벤트, 비정상 시도에 대한 모니터링 - 규정 준수 보고서 자동 생성 - 도구 및 연계 - IAM 시스템, Directory 서비스(예: LDAP/AD)와의 연계 - DevOps 파이프라인에서의 자동 프로비저닝 지원 --- ## 10. 보안 고려사항 - 권한 남용 위험 관리 - SoD 제약으로 권한 남용 가능성 감소 - 다중 승인이 필요한 작업에 대한 별도 정책 도입 - Role Explosion 방지 - 역할의 세분화가 필요한 경우에도 관리 가능성을 고려해 계층 구조를 명확히 한다 - 공통 권한은 공통 역할로 묶고, 특수한 권한만 서브 역할로 분리 - 변경 관리와 감사성 - 모든 권한 변경은 기록되고 승인을 거치도록 한다 - 비정상 접근 시도에 대한 알림 및 차단 정책 적용 --- ## 11. 사례 연구 요약 - 대기업의 RBAC 도입 사례에서는 초기에는 RBAC0 수준의 단순 매핑으로 시작하였고, 점진적으로 Role Hierarchy와 SSD/DSD 제약을 도입했다. - 결과적으로 관리 비용이 크게 감소하고, 신규 프로젝트 시 역할 재배치가 빠르게 이루어져 프로젝트 일정이 단축되었다. - 감사 요구사항 충족과 보안 정책 준수의 측면에서도 가시성이 크게 향상되었다. --- ## 12. FAQ(자주 묻는 질문) - Q: RBAC와 ABAC의 차이는 무엇인가요? - A: RBAC는 역할(Role) 중심으로 권한을 관리하고, ABAC은 속성(Attribute) 기반으로 접근을 정의한다. RBAC는 관리 용이성과 일관성을 제공하는 반면, ABAC는 더 세밀하고 동적인 제어가 가능하지만 관리가 복잡할 수 있다. - Q: 역할이 너무 많아지면 어떻게 하나요? - A: 역할 합치기, 역할 계층 정리, 공통 권한을 가진 역할의 재구성, SoD 제약 재정비 등을 통해 관리의 복잡도를 낮춘다. - Q: 변경 이력은 어떻게 관리하나요? - A: 변경 요청, 승인, 적용 시점을 기록하고, 변경 로그를 감사 시스템과 연계한다. --- --- 관련 문서: [[RBAC 개념과 원칙]], [[최소 권한 원칙과 RBAC]], [[RBAC 설계 팁과 도구]], [[Zero Trust에서의 RBAC 연계]]