마이크로서비스 시대에 RBAC만으로는 표현 불가능한 접근 제어 요구사항을 ABAC와 ReBAC로 단계별 해결

Context

RBAC는 사용자에게 역할을 할당하고 역할에 권한을 부여하는 단순한 구조로, 관리자 입장에서 직관적이고 비전문가도 이해하기 쉬웠다. 하지만 조직 규모가 증가하면서 직무(50개) × 위치(20개) × 프로젝트(10개) 조합으로 10,000개 이상의 역할이 필요한 Role Explosion 문제가 발생했다. RBAC의 제한된 표현력으로는 속성 기반 제어나 리소스 계층 구조 기반의 복잡한 권한 요구를 처리할 수 없었다.

Technical Solution

• RBAC 기초 모델 유지: Kubernetes RBAC처럼 Namespace 범위와 함께 User → Role → Permission 구조로 평면 역할 기반 제어 적용
• NIST 4단계 모델 도입: Level 1(평면) → Level 2(계층형 역할 상속) → Level 3(분리된 의무, 상충 역할 방지) → Level 4(권한에서 역할 역조회) 단계별 확장
• ABAC 추가: AWS IAM Condition 블록처럼 속성(시간, 위치, 컨텍스트)과 조건을 정책에 포함시켜 세밀한 제어 구현
• ReBAC 도입: SpiceDB, OpenFGA처럼 문서 공유 관계와 계층 구조를 그래프로 표현하여 리소스 기반 권한 관리
• 하이브리드 모델 선택: Cedar v4(Amazon Verified Permissions)로 RBAC + ABAC + ReBAC 기능을 통합

Key Takeaway

접근 제어 모델 선택은 "어느 것이 가장 강력한가"가 아니라 "무엇을 제어하고 싶은가"를 기준으로 판단해야 한다. RBAC에서 시작해 역할이 증가하면 ABAC를 추가하고, 리소스 공유와 계층 구조 요구사항이 생기면 ReBAC를 도입하는 점진적 접근이 실무에서 가장 효과적이다.