역할 기반 접근 제어(RBAC) - 권한 관리의 핵심 완전 정복하기 🔐

여러분이 회사에서 일할 때를 상상해보세요. 모든 직원이 CEO의 이메일을 볼 수 있거나, 인턴이 회사의 재무 데이터를 마음대로 수정할 수 있다면 어떨까요? 😱 아마 큰 혼란이 일어날 거예요. 이럴 때 필요한 것이 바로 역할 기반 접근 제어(RBAC)입니다!

등장 배경

과거에는 어떻게 접근 제어를 했을까요? 🤔 초기 컴퓨터 시스템에서는 접근 제어가 매우 단순했습니다. 1970년대까지만 해도 대부분의 시스템은 단일 사용자이거나 소수의 사용자만을 지원했죠.

하지만 시스템이 복잡해지면서 문제가 생기기 시작했습니다:

초기 접근 제어 방식들:

1. ACL (Access Control List) - 1960년대

• 각 리소스마다 접근 가능한 사용자 목록을 관리
• 문제점: 사용자가 늘어날수록 관리가 기하급수적으로 복잡해짐

2. MAC (Mandatory Access Control) - 1970년대

• 미국 국방부에서 개발한 중앙집중식 보안 모델
• 문제점: 너무 엄격하고 유연성이 부족함

3. DAC (Discretionary Access Control) - 1980년대

• 리소스 소유자가 접근 권한을 부여
• 문제점: 보안이 느슨하고 악성 프로그램에 취약함

이런 문제들을 해결하기 위해 1992년, David Ferraiolo와 Rick Kuhn이 RBAC를 제안했습니다! 🎉 이후 1996년에 Sandhu 등이 발전시켜 오늘날 우리가 아는 RBAC의 형태가 완성되었죠. 2004년에는 미국 표준 협회(ANSI)에서 공식 표준으로 채택되었습니다.

핵심 원리

RBAC의 작동 원리를 시각적으로 이해해볼까요?

┌─────────────────────────────────────────────────────────┐
│                    RBAC 구조도                           │
├─────────────────────────────────────────────────────────┤
│                                                         │
│    사용자(User)        역할(Role)        권한(Permission)│
│    ┌─────────┐       ┌─────────┐       ┌─────────┐    │
│    │  Alice  │──────►│ Manager │──────►│  Read   │    │
│    └─────────┘       └─────────┘       │  Write  │    │
│                            │            │  Delete │    │
│    ┌─────────┐            │            └─────────┘    │
│    │   Bob   │────────────┘                           │
│    └─────────┘                                        │
│                      ┌─────────┐       ┌─────────┐    │
│    ┌─────────┐      │Employee │──────►│  Read   │    │
│    │ Charlie │──────►└─────────┘       └─────────┘    │
│    └─────────┘                                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

RBAC의 3가지 핵심 규칙 📋

1. 역할 할당 (Role Assignment): 사용자는 역할이 할당되어야만 권한을 행사할 수 있습니다
2. 역할 인가 (Role Authorization): 사용자의 활성 역할은 반드시 인가되어야 합니다
3. 권한 인가 (Permission Authorization): 사용자는 활성 역할에 부여된 권한만 행사할 수 있습니다

RBAC 모델의 3가지 유형

모델 유형	설명	특징
Core RBAC	기본 RBAC 모델	• 사용자-역할-권한의 기본 관계 • 모든 RBAC의 기초
Hierarchical RBAC	계층적 역할 구조	• 상위 역할이 하위 역할 권한 상속 • 조직 구조 반영 가능
Constrained RBAC	제약 조건 추가	• 업무 분리(SoD) 구현 • 충돌하는 역할 동시 할당 방지

주의사항 및 팁 💡

⚠️ 이것만은 주의하세요!

1. 역할 폭발(Role Explosion) 문제
   • 조직이 커질수록 역할이 기하급수적으로 증가할 수 있습니다
   • 해결 방법: 역할을 단순하게 유지하고, 계층 구조를 활용하세요
2. 과도한 권한 부여
   • 편의를 위해 필요 이상의 권한을 부여하는 실수
   • 해결 방법: 최소 권한 원칙(Principle of Least Privilege)을 철저히 지키세요
3. 정기적인 검토 부재
   • 한 번 설정하고 잊어버리는 경우가 많습니다
   • 해결 방법: 정기적인 접근 권한 검토 프로세스를 수립하세요

💡 꿀팁

• 역할 네이밍 규칙 정하기: 부서_직급_권한수준 형식으로 일관성 있게 명명하세요 (예: SALES_MANAGER_FULL)
• 템플릿 역할 활용: 자주 사용되는 권한 조합을 템플릿으로 만들어 재사용하세요
• 모니터링 도구 활용: 사용자의 실제 권한 사용 패턴을 분석해 불필요한 권한을 제거하세요

실제 구현 예시 🔧

AWS Cedar 언어를 사용한 RBAC 정책 예시:

permit(
    principal in Role::"admin",
    action in [
        Action::"task:update",
        Action::"task:retrieve", 
        Action::"task:list"
    ],
    resource in ResourceType::"task"
);

전자상거래 플랫폼의 RBAC 구현:

• 고객: 제품 조회, 구매 가능
• 영업 관리자: 제품 목록 편집, 판매 보고서 접근, 고객 주문 관리
• 시스템 관리자: 모든 데이터 접근, 사용자 관리, 시스템 설정

마치며

지금까지 역할 기반 접근 제어(RBAC)에 대해 알아보았습니다. 처음에는 어렵게 느껴질 수 있지만, 결국 RBAC는 "누가 무엇을 할 수 있는가?"라는 단순한 질문에 체계적으로 답하는 방법입니다. 🎯

여러분의 조직에서도 RBAC를 구현하고 계신가요? 아니면 다른 접근 제어 방식을 사용하고 계신가요?

참고 자료 🔖

• Role-based access control - Wikipedia
• What Is Role-Based Access Control (RBAC)? - IBM
• The Definitive Guide to Role-Based Access Control (RBAC) - StrongDM

---