오늘은 NIST(미국 국립표준기술연구소)에서 발표한 "The NIST Model for Role-Based Access Control: Towards A Unifed Standard" 논문을 바탕으로 RBAC(Role-Based Access Control)에 대해 정리해보려고 합니다.
여러분이 웹 서비스나 애플리케이션을 개발해 보셨다면, 아마도 이미 RBAC를 구현하고 계셨을 겁니다. 예를 들어, 쇼핑몰 시스템에서 '관리자', '판매자', '일반 사용자'와 같은 역할을 만들고 각 역할에 따라 다른 기능을 제공하는 것이 바로 RBAC의 기본적인 형태입니다. 사실 RBAC의 개념은 컴퓨터가 널리 보급되기 이전부터 존재했습니다. 예를 들어, 회사에서 특정 문서에 접근할 수 있는 권한을 직급이나 부서에 따라 부여하는 것도 일종의 RBAC라고 볼 수 있죠. 컴퓨터 시스템에서는 초기에 파일 시스템의 접근 권한을 관리할 때 사용자, 그룹, 기타 사용자로 구분하여 읽기, 쓰기, 실행 권한을 부여하는 방식으로 RBAC의 개념이 구현되었습니다. (chmod 777과 같은 무서운 명령어가 생각나시나요?)
그렇다면 RBAC란 정확히 무엇이며, 왜 필요할까요?
RBAC란 무엇인가?
RBAC는 사용자의 역할을 기반으로 시스템 접근 권한을 관리하는 방법입니다. 예를 들어, 회사 내에서 '인사 관리자'라는 역할이 있다고 가정해봅시다. 이 역할에는 직원 정보 조회, 급여 정보 수정 등의 권한이 부여될 수 있습니다. RBAC를 사용하면, 새로운 인사 관리자가 입사할 때 일일이 권한을 설정할 필요 없이, 단순히 '인사 관리자' 역할을 할당하는 것만으로 필요한 모든 권한을 부여할 수 있습니다.
RBAC의 중요성은 시스템이 복잡해지고 사용자 수가 늘어날수록 더욱 커집니다. 예를 들어, 수천 명의 직원이 있는 대기업의 ERP 시스템이나, 수백만 명의 사용자가 있는 소셜 미디어 플랫폼에서는 개별 사용자마다 권한을 일일이 설정하는 것이 거의 불가능합니다. RBAC를 사용하면 이러한 복잡한 환경에서도 효율적으로 접근 제어를 관리할 수 있습니다.
RBAC는 매우 간단한 것에서부터 상당히 복잡하고 정교한 것에 이르기까지 다양한 개념을 포함하는 풍부하고 개방적인 개념입니다. RBAC에 대한 단일 모델을 정의한다면 너무 많이 포함하거나 제외할 것입니다. 이를 의식하여 NIST에서는 기능 순으로 네 단계를 나눠 RBAC 모델을 구성했습니다. 이 Level은 누적되며 각 Level은 이전 Level의 요구 사항을 포함합니다.
Level 1. Flat RBAC
Level 2. Hierarchical RBAC
Level 3. Constrained RBAC
Level 4. Symmetric RBAC
이제 각 모델에 대해 자세히 알아보겠습니다.
Flat RBAC
Flat RBAC는 RBAC의 가장 기본적인 형태입니다. 여기서는 사용자, 역할, 권한 간의 관계를 정의합니다.
- 사용자는 여러 역할을 가질 수 있습니다.
- 역할은 여러 권한을 가질 수 있습니다.
- 사용자는 자신의 역할을 통해 권한을 얻습니다.
예를 들어, '마케팅 매니저'와 '프로젝트 리더'라는 두 역할이 있다고 가정해봅시다. 한 사용자가 이 두 역할을 모두 가질 수 있으며, 각 역할에 해당하는 권한을 모두 사용할 수 있습니다.
Flat RBAC의 주요 특징은 사용자-역할 검토 기능입니다. 이를 통해 특정 사용자가 어떤 역할을 가지고 있는지, 또는 특정 역할이 어떤 사용자들에게 할당되어 있는지를 쉽게 확인할 수 있습니다.
NIST 모델에서는 대규모 분산 시스템에서의 권한-역할 검토 요구 사항 구현의 어려움을 인식하여 Level 4로 연기합니다.
Hierarchical RBAC
Hierarchical RBAC는 Flat RBAC의 개념을 확장하여 역할 간의 계층 구조를 도입합니다. 이는 많은 조직의 실제 구조를 더 잘 반영할 수 있게 해줍니다.
예를 들어, '부서장'이라는 역할이 '팀장' 역할의 모든 권한을 상속받고, '팀장' 역할은 '팀원' 역할의 모든 권한을 상속받는 구조를 만들 수 있습니다. 이렇게 하면 상위 역할은 자동으로 하위 역할의 모든 권한을 가지게 됩니다.
Hierarchical RBAC는 두 가지 형태로 나뉩니다.
- Limited Hierarchical RBAC : 단일 상속만을 허용합니다. 즉, 각 역할은 하나의 상위 역할로부터만 권한을 상속받을 수 있습니다.
- General Hierarchical RBAC : 다중 상속을 허용합니다. 역할은 여러 상위 역할로부터 권한을 상속받을 수 있어, 더 복잡한 조직 구조를 표현할 수 있습니다.
Constrained RBAC
Constrained RBAC는 Hierarchical RBAC에 직무 분리(SOD, Separation of Duty) 개념을 추가합니다. 이는 한 사용자가 너무 많은 권한을 가져 발생할 수 있는 보안 위험을 줄이기 위한 것입니다.
예를 들어, 회계 시스템에서 '지출 승인' 역할과 '지출 집행' 역할을 동시에 가질 수 없도록 제한할 수 있습니다. 이렇게 하면 한 사람이 불법적인 지출을 승인하고 실행하는 것을 방지할 수 있습니다.
Constrained RBAC는 두 가지 형태의 SOD를 지원합니다.
- 정적 SOD(SSD): 사용자에게 역할을 할당할 때 적용되는 제약입니다.
- 동적 SOD(DSD): 사용자가 역할을 활성화할 때 적용되는 제약입니다.
Symmetric RBAC
Symmetric RBAC는 Constrained RBAC에 권한-역할 검토 기능을 추가합니다. 이를 통해 특정 권한이 어떤 역할에 할당되어 있는지, 또는 특정 역할이 어떤 권한을 가지고 있는지를 쉽게 확인할 수 있습니다.
양방향 검토 기능
기존의 RBAC 모델에서는 주로 '특정 역할이 어떤 권한을 가지고 있는지'를 확인하는 것이 쉬웠습니다. 하지만 Symmetric RBAC에서는 그 반대, 즉 '특정 권한이 어떤 역할들에 할당되어 있는지'도 쉽게 확인할 수 있습니다.
- 역할 → 권한: "관리자" 역할이 어떤 권한들을 가지고 있는지 확인
- 권한 → 역할: "고객 정보 수정" 권한이 어떤 역할들에 부여되어 있는지 확인
이런 양방향 검토 기능을 통해 권한 관리가 훨씬 더 명확해집니다.
직접 할당과 상속 구분
Symmetric RBAC의 또 다른 중요한 특징은 직접 할당된 권한과 상속된 권한을 명확히 구분할 수 있다는 점입니다.
예를 들어, "팀장" 역할이 가진 권한 중에서
- 직접 할당된 권한: "팀 성과 보고서 작성"
- 상속된 권한: "팀원" 역할로부터 상속받은 "일일 업무 보고 열람"
이렇게 구분함으로써, 각 권한이 어디서 왔는지 쉽게 추적할 수 있습니다. 예를 들면 '고객 정보 조회' 권한이 어떤 역할들에 할당되어 있는지 한 번에 확인할 수 있습니다. 이는 권한 관리의 투명성을 높이고, 불필요한 권한을 식별하여 제거하는 데 매우 유용합니다.
RBAC는 복잡한 시스템에서 접근 제어를 효과적으로 관리할 수 있는 방법입니다. RBAC를 적절히 구현하면 보안을 강화하고, 관리 효율성을 높일 수 있습니다. 특히 대규모 조직이나 복잡한 시스템에서 RBAC의 이점은 더욱 두드러집니다.
그러나 RBAC도 한계가 있습니다.
- 동적인 환경에서 유연성이 부족할 수 있습니다. 사용자의 역할이 자주 변경되거나, 상황에 따라 다른 권한이 필요한 경우 RBAC만으로는 대응하기 어려울 수 있습니다.
- 세분화된 접근 제어가 필요한 경우, 역할의 수가 급격히 증가하여 관리가 복잡해질 수 있습니다.
- 사용자의 속성(예: 위치, 시간, 디바이스 유형 등)이나 자원의 특성에 따른 세밀한 접근 제어를 구현하기 어렵습니다.
이러한 한계를 극복하기 위해, 보다 유연하고 상황에 맞는 접근 제어 모델들이 등장하고 있습니다. 그중 대표적인 것이 ABAC(Attribute-Based Access Control)와 ReBAC(Relationship-Based Access Control)입니다.
- ABAC는 사용자, 자원, 환경의 다양한 속성을 기반으로 접근 제어 결정을 내립니다. 이를 통해 더욱 동적이고 세밀한 접근 제어가 가능해집니다.
- ReBAC은 사용자 간의 관계나 사용자와 자원 간의 관계를 기반으로 접근 제어를 수행합니다. 이는 소셜 네트워크의 공유와 같은 복잡한 관계 구조를 가진 시스템에서 특히 유용할 수 있습니다.
이중, 다음 글에서 ReBAC에 대해서도 이야기를 해보도록 하겠습니다. 감사합니다.
댓글