RBAC vs ABAC: 접근 제어 전략 선택 가이드

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

보안

대상자

• 소프트웨어 개발자, 보안 전문가, 시스템 설계자
• 중간 수준 이해가 필요 (보안 모델 설계 및 구현 경험이 있는 사람)

핵심 요약

• RBAC는 역할 기반으로 접근 권한을 할당하는 간단한 모델로, Admin, HR Manager와 같은 고정된 역할을 사용합니다.
• ABAC는 사용자, 자원, 환경 등 다양한 속성을 기반으로 접근을 동적으로 결정하며, user.department == resource.department과 같은 복잡한 조건을 지원합니다.
• 혼합 접근(RBAC + ABAC)이 가장 현명한 선택으로, 기초 권한은 RBAC, 세부 조건은 ABAC로 처리합니다.

섹션별 세부 요약

1. RBAC 정의 및 특징

• 역할 기반 접근: 사용자에게 Admin, HR Manager 같은 역할을 할당하고, 역할에 권한(edit_employee, view_ticket)을 매핑합니다.
• 장점: 구조가 간단하고, 조직 내 역할이 명확한 환경에서 효과적입니다.
• 단점: 사용자가 여러 역할을 가질 경우, 부서나 시간 등 추가 조건이 필요할 때 한계가 있습니다.

2. ABAC 정의 및 특징

• 속성 기반 접근: 사용자 속성(부서, 시간), 자원 속성(파일 유형), 환경(시간, IP)을 조합해 접근을 결정합니다.
• 장점: user.department == resource.department AND working hours와 같은 복잡한 조건을 표현 가능하며, 다국적 SaaS 시스템에 적합합니다.
• 단점: 정책 엔진이 필요하고, 속성 데이터 관리가 복잡합니다.

3. RBAC vs ABAC 비교

| 항목 | RBAC | ABAC |

|---------------|--------------------------|---------------------------|

| 간결성 | ✅ 간단한 구조 | ❌ 복잡한 정책 필요 |

| 세부 조건 | ❌ 역할 기반만 지원 | ✅ 속성 기반 다중 조건 지원 |

| 확장성 | 🚫 역할 폭증 가능성 | ✅ 다국적 환경에 적합 |

| 유연성 | ❌ 고정된 역할 중심 | ✅ 동적 조건 적용 가능 |

4. 혼합 접근(RBAC + ABAC)

• 기초 권한: RBAC로 can_view_dashboard 같은 기본 역할을 설정합니다.
• 세부 조건: ABAC로 user.tenant_id == resource.tenant_id 같은 속성 기반 제어를 추가합니다.
• 도구 예시: AWS IAM(기본 RBAC + 속성 기반 정책), Open Policy Agent(ABAC 정책 엔진).

결론

• RBAC는 조직 구조가 명확한 내부 시스템에 적합하고, ABAC는 다국적 SaaS나 복잡한 접근 조건이 필요한 환경에서 효과적입니다.
• 대부분의 현대 시스템은 혼합 접근을 추천하며, 기본 역할과 속성 기반 조건을 결합해 유연하게 설계해야 합니다.