역할 기반 접근 제어

컴퓨터 시스템 보안에서 역할 기반 접근 제어(role-based access control, RBAC)^[1][2] 또는 역할 기반 보안(role-based security)^[3]은 권한이 있는 사용자로 시스템 접근을 제한하고, 강제적 접근 제어(MAC) 또는 재량적 접근 제어(DAC)를 구현하는 접근 방식이다.

역할 기반 접근 제어는 역할과 권한을 중심으로 정의된 정책 중립적인 접근 제어 메커니즘이다. 역할-권한, 사용자-역할 및 역할-역할 관계와 같은 RBAC의 구성 요소는 사용자 할당을 간단하게 수행하도록 한다. NIST의 연구에 따르면 RBAC는 상업 및 정부 조직의 많은 요구 사항을 충족한다.^[4] RBAC는 수백 명의 사용자와 수천 개의 권한을 가진 대규모 조직에서 보안 관리를 용이하게 하는 데 사용될 수 있다. RBAC는 MAC 및 DAC 접근 제어 프레임워크와 다르지만, 이러한 정책을 복잡하지 않게 적용할 수 있다.

설계

조직 내에서 다양한 직무를 위해 역할이 생성된다. 특정 작업을 수행할 수 있는 권한은 특정 역할에 할당된다. 사용자는 직접 권한을 할당받는 것이 아니라 역할(또는 여러 역할)을 통해서만 권한을 얻으므로, 개별 사용자 권한 관리는 단순히 사용자의 계정에 적절한 역할을 할당하는 문제로 바뀐다. 이는 사용자 추가 또는 사용자 부서 변경과 같은 일반적인 작업을 간소화한다.

RBAC에는 세 가지 주요 규칙이 정의되어 있다.

1. 역할 할당: 주체는 역할을 선택하거나 할당받은 경우에만 권한을 행사할 수 있다.
2. 역할 승인: 주체의 활성 역할은 주체에게 승인되어야 한다. 위 규칙 1과 함께 이 규칙은 사용자가 승인된 역할만 맡을 수 있도록 한다.
3. 권한 승인: 주체는 해당 주체의 활성 역할에 대해 권한이 승인된 경우에만 권한을 행사할 수 있다. 규칙 1과 2와 함께 이 규칙은 사용자가 승인된 권한만 행사할 수 있도록 한다.

추가적인 제약 조건도 적용될 수 있으며, 역할은 상위 역할이 하위 역할이 소유한 권한을 포함하는 계층으로 결합될 수 있다.

역할 계층 및 제약 조건의 개념을 통해 RBAC를 제어하여 격자 기반 접근 제어(LBAC)를 생성하거나 시뮬레이션할 수 있다. 따라서 RBAC는 LBAC의 상위 집합으로 간주될 수 있다.

RBAC 모델을 정의할 때 다음 규칙이 유용하다.

• S = 주체 = 사람 또는 자동화된 에이전트
• R = 역할 = 권한 수준을 정의하는 직무 또는 직함
• P = 권한 = 리소스에 대한 접근 모드 승인
• SE = 세션 = S, R 및 P를 포함하는 매핑
• SA = 주체 할당
• PA = 권한 할당
• RH = 부분 순서 역할 계층. RH는 ≥ 로도 쓸 수 있다. (표기법: x ≥ y는 x가 y의 권한을 상속함을 의미한다.)
  • 주체는 여러 역할을 가질 수 있다.
  • 역할은 여러 주체를 가질 수 있다.
  • 역할은 여러 권한을 가질 수 있다.
  • 권한은 여러 역할에 할당될 수 있다.
  • 작업은 여러 권한에 할당될 수 있다.
  • 권한은 여러 작업에 할당될 수 있다.

제약 조건은 반대되는 역할에서 권한의 잠재적인 상속에 제한적인 규칙을 적용한다. 따라서 이는 적절한 업무 분리를 달성하는 데 사용될 수 있다. 예를 들어, 동일한 사람이 로그인 계정을 생성하고 계정 생성을 승인하는 것이 허용되어서는 안 된다.

따라서 집합론 표기법을 사용하면 다음과 같다.

• ${\displaystyle PA\subseteq P\times R}$이고 다대다 권한-역할 할당 관계이다.
• ${\displaystyle SA\subseteq S\times R}$이고 다대다 주체-역할 할당 관계이다.
• ${\displaystyle RH\subseteq R\times R}$

주체는 다른 역할을 가진 여러 개의 동시 세션을 가질 수 있다.

역할 기반 접근 제어 요소 다이어그램

표준화된 수준

 NIST RBAC 모델 문서를 참고하십시오.

NIST/ANSI/INCITS RBAC 표준(2004)은 세 가지 수준의 RBAC를 인정한다.^[5]

1. 핵심 RBAC
2. 계층적 RBAC, 역할 간의 상속 지원 추가
3. 제약된 RBAC, 업무 분리 추가

다른 모델과의 관계

RBAC는 DAC^[6] 또는 MAC^[7]을 구현할 수 있는 유연한 접근 제어 기술이다. 그룹이 있는 DAC(예: POSIX 파일 시스템에서 구현된 방식)는 RBAC를 모방할 수 있다.^[8] 역할 그래프가 부분 순서 집합 대신 트리로 제한되면 MAC은 RBAC를 시뮬레이션할 수 있다.^[9]

RBAC가 개발되기 전에는 벨-라파둘라 (BLP) 모델이 MAC의 동의어였고 파일 시스템 권한은 DAC의 동의어였다. 이들은 접근 제어를 위한 유일한 알려진 모델로 간주되었다. 즉, 모델이 BLP가 아니면 DAC 모델로 간주되었고 그 반대도 마찬가지였다. 1990년대 후반의 연구는 RBAC가 이 두 가지 범주 중 어느 쪽에도 속하지 않음을 보여주었다.^[10][11] 상황 기반 접근 제어(CBAC)와 달리 RBAC는 메시지 컨텍스트(예: 연결 소스)를 고려하지 않는다. RBAC는 또한 역할 폭발^[12] 문제로 비판받았는데, 이는 역할이 본질적으로 작업 및 데이터 유형에 할당되므로 RBAC가 제공할 수 있는 것보다 더 세분화된 접근 제어가 필요한 대규모 엔터프라이즈 시스템에서 발생하는 문제이다. CBAC와 유사하게, 개체-관계 기반 접근 제어 시스템은 실행 주체와의 연관성을 고려하여 데이터 인스턴스를 보호할 수 있다.^[13]

ACL과의 비교

접근 제어 목록(ACL)은 기존의 재량적 접근 제어(DAC) 시스템에서 저수준 데이터 객체에 영향을 미치기 위해 사용된다. RBAC는 여러 개체 간의 직접적인 관계를 변경하는 작업에 권한을 할당한다는 점에서 ACL과 다르다(아래 ACLg 참조). 예를 들어, ACL은 특정 시스템 파일에 대한 쓰기 접근을 허용하거나 거부하는 데 사용될 수 있지만, 해당 파일이 어떻게 변경될 수 있는지는 지시하지 않는다. RBAC 기반 시스템에서 작업은 금융 애플리케이션에서 '신용 계정 생성' 트랜잭션이거나 의료 애플리케이션에서 '혈당 수치 테스트' 기록을 채우는 것일 수 있다. 따라서 역할은 더 큰 활동 내의 일련의 작업이다. RBAC는 중요한 작업 승인에 두 명 이상의 사람이 참여해야 하는 업무 분리(SoD) 요구 사항에 특히 적합한 것으로 나타났다. RBAC에서 SoD의 안전성에 대한 필요충분조건이 분석되었다. SoD의 기본 원칙은 이중 특권으로 인해 보안 침해를 일으킬 수 있는 개인이 없어야 한다는 것이다. 더 나아가, 어떤 사람도 동시에 보유하는 다른 역할에 대한 감사, 통제 또는 검토 권한을 행사하는 역할을 가질 수 없다.^[14][15]

다시 말해, "최소 RBAC 모델", RBACm은 ACL에 그룹만 엔트리로 허용되는 ACLg라는 ACL 메커니즘과 비교될 수 있다. 바클리(1997)^[16]는 RBACm과 ACLg가 동등하다고 밝혔다.

데이터 교환 및 "고수준 비교"를 위해 ACL 데이터는 XACML로 변환될 수 있다.

속성 기반 접근 제어

속성 기반 접근 제어(ABAC)는 RBAC에서 발전하여 역할 및 그룹 외에 추가 속성을 고려하는 모델이다. ABAC에서는 다음 속성을 사용할 수 있다.

• 사용자 속성(예: 시민권, 보안 허가)
• 리소스 속성(예: 분류, 부서, 소유자)
• 작업 속성
• 컨텍스트 속성(예: 시간, 위치, IP)

ABAC는 허용되거나 허용되지 않는 것을 정의하기 위해 정적 권한 대신 정책을 사용한다는 점에서 정책 기반이다.

관계 기반 접근 제어

관계 기반 접근 제어(ReBAC)는 RBAC에서 발전한 모델이다. ReBAC에서 주체가 리소스에 접근할 수 있는 권한은 해당 주체와 리소스 간의 관계 존재 여부에 따라 정의된다.

이 모델의 장점은 세분화된 권한을 허용한다는 것이다. 예를 들어, 사용자가 특정 다른 사용자와 게시물을 공유할 수 있는 소셜 네트워크에서 그렇다.^[17]

사용 및 가용성

단일 시스템 또는 애플리케이션 내에서 사용자 권한(컴퓨터 권한)을 관리하기 위한 RBAC의 사용은 모범 사례로 널리 받아들여지고 있다. 리서치 트라이앵글 인스티튜트가 NIST를 위해 작성한 2010년 보고서는 기업을 위한 RBAC의 경제적 가치를 분석하고, 직원 가동 중단 시간 감소, 보다 효율적인 프로비저닝, 보다 효율적인 접근 제어 정책 관리를 통해 직원 1인당 혜택을 추정했다.^[18]

이질적인 IT 인프라와 수십 또는 수백 개의 시스템 및 애플리케이션에 걸쳐 있는 요구 사항을 가진 조직에서 충분한 역할을 관리하고 적절한 역할 멤버십을 할당하기 위해 RBAC를 사용하는 것은 역할의 계층적 생성 및 권한 할당 없이 극도로 복잡해진다.^[19] 최신 시스템은 이전 NIST RBAC 모델^[20]을 확장하여 전사적 배포를 위한 RBAC의 한계를 해결한다. NIST 모델은 INCITS에 의해 ANSI/INCITS 359-2004로 표준으로 채택되었다. NIST 모델의 일부 설계 선택에 대한 논의도 발표되었다.^[21]

잠재적 취약성

역할 기반 접근 제어 간섭은 보안 애플리케이션에서 비교적 새로운 문제로, 동적 접근 수준을 가진 여러 사용자 계정이 암호화 키 불안정성을 유발하여 외부 사용자가 이 취약점을 악용하여 무단 접근을 할 수 있다. 동적 가상화 환경 내의 키 공유 애플리케이션은 이 문제를 해결하는 데 일부 성공을 거두었다.^[22]

같이 보기

• 접근 제어 목록 (ACL)