# RBAC(Roles Based Access Control) 개념과 원칙 RBAC는 조직의 역할(role)을 기준으로 사용자의 접근 권한을 관리하는 접근 제어 모델이다. 사용자는 하나 이상의 역할을 부여받고, 각 역할은 하나 이상의 권한(permission)을 보유한다. 이를 통해 복잡한 권한 부여를 간소화하고, 최소 권한 원칙(Least Privilege)과 역할 분리(SOD, Separation of Duties)를 실현한다. --- ## 1. 핵심 용어 및 기본 관계 - User (U): 시스템에 접속하는 개별 사용자. - Role (R): 직무나 책임에 따른 권한의 묶음. 여러 사용자에 공유될 수 있다. - Permission (P): 시스템 리소스에 대한 접근 권한. 예: 읽기, 쓰기, 실행, 삭제 등. - Session (S): 사용자가 시스템에 로그인한 상태에서 활성화된 Role의 부분집합. - User-Role Assignment (UA): 특정 사용자에게 하나 이상의 역할을 할당하는 관계. - Role-Permission Assignment (PA): 특정 역할에 권한을 할당하는 관계. - Roles(u): 사용자 u가 보유한 역할들의 집합. - Permissions(roles): 각 역할이 가지는 권한들의 합집합. - ActiveRoles(u, t): 시점 t에 사용자 u가 활성화한 역할들. 수식 예시(선언적 모델): - 역할 기반 권한 구성: $P(u) = \bigcup_{r \in Roles(u)} Permissions(r)$ - 활성 세션의 역할: $ActiveRoles(u) \subseteq Roles(u)$ - 데이터 관리 관점의 모델링: UA ⊆ U × R, PA ⊆ R × P --- ## 2. RBAC의 기본 원칙 - 최소 권한 원칙(Lowest Privilege): 사용자에게 필요한 최소한의 권한만 부여한다. - 역할 분리(SOD, Separation of Duties): 특정 작업의 부정행위를 방지하기 위해 충돌하는 역할의 동시 보유를 제한한다. - 중복 최소화: 직접 사용자에게 권한을 부여하기보다 역할에 권한을 연결한다. - 역할 재사용성: 직무 변경이나 조직 구조의 변화에 따라 역할을 재사용하고 재배치한다. - 감사 가능성(Auditability): 어떤 사용자가 어떤 역할과 권한을 가졌는지 히스토리를 남겨 추적 가능하게 한다. --- ## 3. RBAC 모델의 유형 - RBAC0 (Flat RBAC): 기본 모델로, UA와 PA만 존재. 역할 간의 상속이나 제약은 없다. - RBAC1 (Core RBAC): 역할 간의 관계(Role Hierarchy)를 도입하여 상속 구조를 허용한다. 예: role ≤ superior_role. - RBAC2 (Hierarchical RBAC): 정교한 역할 계층 구조를 공식화하며, 하위 역할의 권한은 상위 역할에 상속된다. - RBAC3 (Constrained RBAC): 제약 조건(SOD 및 기타 제약)을 명시적으로 도입하여 보안성을 강화한다. 개별 특성 요약 - Role Hierarchy: 상하위 관계를 통해 권한 상속을 구현한다. - Constraints: SOD, mutual exclusion, cardinality 제한 등을 정의한다. - Dynamic vs Static: 세션 동안의 활성 역할은 동적으로 변경될 수 있다. --- ## 4. 설계 원칙 및 모범 사례 - 도메인 기반 설계: 업무 도메인에 맞춰 역할을 정의하고, 권한은 역할 단위로 묶는다. - 역할의 크기 관리: 역할은 과도하게 큰 집합이 되지 않도록 분해하고, 필요 시 역할 합성(composition)으로 확장한다. - 역할 축소와 철회 정책: 필요하지 않은 역할은 주기적으로 재검토하고 제거한다. - 규칙적 감사 및 변경 관리: 역할의 변경은 기록되고 승인 절차를 거친다. - 정책 분리: 인증(Identity)과 권한 부여(Permission) 정책을 구분하고, PDP(Policy Decision Point)와 PEP(Policy Enforcement Point)로 구성한다. - 동적 권한 관리: 업무 변화에 따라 세션 중 활성 рол를 재설정할 수 있도록 한다. --- ## 5. 구현 관점 - 데이터 모델 - User 테이블: 사용자 정보 - Role 테이블: 역할 정보 - Permission 테이블: 권한 정보 - UserRole(UA) 테이블: 사용자-역할 매핑 - RolePermission(PA) 테이블: 역할-권한 매핑 - Session 자료구조: 활성화된 Role 목록 및 시점 - 정책 엔진과 컴포넌트 - PEP(Policy Enforcement Point): 요청에 대한 권한 판단을 수행한다. - PDP(Policy Decision Point): 정책을 평가하고 허가/거부를 반환한다. - IAM 시스템과의 연계: 디렉터리 서비스(예: LDAP/AD)와의 통합, SSO 및 인증과의 연결. - 수식적 모델링 예시 - 특정 사용자 u의 권한: $P(u) = \bigcup_{r \in Roles(u)} Permissions(r)$ - 세션 활성화 시점의 역할: $ActiveRoles(u) \subseteq Roles(u)$ - 충돌 제약(SOD) 예시: 특정 쌍 (r_i, r_j) 은 동일 사용자에 할당될 수 없음. --- ## 6. 운영상의 고려사항 - 역할 유지 관리의 자동화: 역할 갱신, 새 직무 도입 시의 역할 추가를 자동 워크플로우로 처리. - 변경 관리 프로세스: 권한 변경은 승인, 기록, 검토의 순서를 준수. - 감사 로그: 누가 언제 어떤 역할/권한을 부여받았는지 추적 가능하게 저장. - 도메인 지향 RBAC: 제조, 금융, 헬스케어 등 도메인별 규제 요구를 반영한 커스텀 역할 설계. - 성능 고려: 대규모 시스템에서의 조인 연산이나 패킷 단위 검증 시간을 최소화하는 인덱싱 및 캐싱 전략. --- ## 7. 예시 도메인 - 기업 내부 시스템: 인사(HR), 재무(FI), 영업(Sales) 등 부문별 역할과 권한 구성. - 클라우드 기반 서비스: 프로젝트(Project) 기반의 역할과 리소스 권한 매핑. - 공공 시스템: 보안 요구 사항과 감사 규정에 맞춘 역할 설계. --- ## 8. 위험 관리 및 보완책 - 과도한 권한 누적 위험: 정기 점검 및 권한 축소 - 역할 남용 위험: 이중 확인, 감사 리뷰, SOD 정책 강화 - 계정 탈취 대응: 다단계 인증, 비정상 활동 모니터링 - 역할 설계의 변화 관리: 조직 구조 변화에 맞춘 역할 재설계 및 이관 --- ## 9. 수식과 모델링의 예시 - 기본 집합론적 모델: - $U$: 모든 사용자 집합 - $R$ : 모든 역할 집합 - $P$ : 모든 권한 집합 - UA ⊆ U × R - PA ⊆ R × P - Roles(u) = { r ∈ R | (u, r) ∈ UA } - P(u) = ∪_{r ∈ Roles(u)} Permissions(r) - 세션 및 활성 역할: - ActiveRoles(u) ⊆ Roles(u) - 제약 조건 예시(Separation of Duties): - 특정 쌍 (r1, r2) 은 같은 사용자에 중복 부여 불가 - 수식으로 표현하면: For all u, not(both u has r1 and r2) --- ## 10. 미국식 예시와 도입 시 고려점 - 도메인에 따른 역할 정의의 중요성: 직무를 정확히 반영해야 권한 남용을 줄일 수 있다. - 점진적 도입: RBAC0 → RBAC1/2/3 순으로 단계적으로 도입하며, 점진적으로 제약을 강화한다. - 도구 선택: IAM 솔루션, 디렉터리 서비스, 정책 엔진의 상호 운용성 확인. --- ## 11. 요약 RBAC는 역할 중심으로 사용자의 권한을 관리하는 강력한 접근 제어 모델이다. 올바른 Role 설계와 엄격한 제약을 통해 최소 권한 원칙을 실현하고, 감사 가능성과 관리 효율성을 높일 수 있다. 조직의 업무 도메인에 맞춘 체계적 설계와 운영 정책이 RBAC의 성공적인 도입의 핵심이다. --- 다음 관련 문서 also 참고하면 좋습니다: - [[RBAC 기본 원칙과 구성요소]], [[최소 권한 원칙과 정책 관리]], [[IAM 시스템에서의 정책 엔진]], [[역할 설계 패턴과 모범 사례]]