RBAC 및 ABAC: 알아야 할 액세스 제어 모델

소개#

액세스 제어는 시스템 보안의 중요한 측면입니다. 이를 통해 승인된 사용자만이 리소스에 액세스하고 작업을 수행할 수 있습니다. 역할 기반 액세스 제어 (RBAC) 및 특성 기반 액세스 제어 (ABAC)는 현대 시스템에서 널리 사용되는 두 가지 인기 있는 액세스 제어 모델입니다. 두 모델 모두 널리 채택되어 있으며 액세스 제어 정책을 효과적으로 시행하는데 사용될 수 있습니다. 그렇다면 이 모델들은 무엇이며 어떻게 다른가요?

역할 기반 액세스 제어 (RBAC)#

역할 기반 액세스 제어 (RBAC)는 1990년대 초반에 처음 도입되었습니다. 이 모델의 공식화는 1992년 발표된 논문에서 David Ferraiolo와 Rick Kuhn에게 인정받았습니다. 그 이후로 RBAC는 업계에서 가장 널리 사용되는 액세스 제어 모델 중 하나가 되었습니다.

RBAC에서 액세스 제어 정책은 권한의 모음인 역할을 기반으로 합니다. 사용자는 역할(예: 관리자, 편집자, 뷰어)에 할당되고, 특정 리소스(예: 파일, 데이터베이스, 애플리케이션)에 대한 권한(예: 생성, 편집, 삭제)에 따라 액세스 권한이 결정됩니다. 사용자를 역할에 기반으로 그룹화하고 역할에 권한을 할당함으로써 액세스 제어 정책 관리를 단순화합니다. 사용자를 역할에 추가하거나 제거하는 것은 간단하며, 변경사항은 액세스 제어 정책에 자동으로 반영됩니다.

RBAC의 주요 구성 요소#

• 리소스: 리소스는 사용자가 액세스할 수 있는 엔티티입니다. 리소스는 파일, 데이터베이스, API, 또는 보호할 필요가 있는 다른 시스템 엔티티일 수 있습니다.
• 권한: 권한은 사용자가 리소스에 대해 수행할 수 있는 특정 작업입니다. 예를 들어, 생성, 편집, 삭제, 보기 등이 있습니다. 권한의 정의는 시스템에 따라 달라질 수 있습니다. 대부분의 경우 권한은 최소한의 세분성으로 리소스 수준에서 정의됩니다.
• 역할: 역할은 사용자가 수행할 수 있는 작업의 집합을 정의하는 권한 모음입니다. 예를 들어, 관리자 역할은 리소스를 생성, 편집 및 삭제할 수 있는 권한을 가질 수 있는 반면, 뷰어 역할은 리소스를 볼 수 있는 권한을 가질 수 있습니다.
• 사용자: 사용자는 하나 이상의 역할을 할당받을 수 있는 엔티티입니다. 사용자는 할당받은 역할과 관련된 권한에 따라 리소스에 대한 액세스 권한을 받습니다.

RBAC 변형#

RBAC는 기본 모델을 확장하여 더 복잡한 액세스 제어 요구사항을 수용하는 여러 변형을 가지고 있습니다:

• RBAC0: 사용자에게 역할이 할당되고 역할이 권한을 할당받는 기본 모델입니다.
• RBAC1: 역할 계층의 개념을 추가합니다. 역할은 다른 역할에서 권한을 상속받을 수 있습니다. 이는 계층적 RBAC라고도 불립니다.
• RBAC2: 역할에 제약 조건을 추가합니다. 제약 조건은 사용자가 역할에 할당되기 위해 만족해야 하는 추가 조건을 정의하는 데 사용할 수 있습니다. 이는 제약 기반 RBAC라고도 불립니다.
• RBAC3: RBAC1과 RBAC2의 기능을 결합합니다. 역할 계층과 제약 모두를 지원합니다.

이 변형에 대한 자세한 내용은 RBAC 모델 및 그 발전을 참고하세요.

RBAC의 장점#

• 간단함: RBAC는 이해하고 구현하기 쉽습니다. 권한을 역할에 할당하고 역할을 사용자에게 할당하는 것은 간단합니다.
• 효율성: RBAC는 사용자를 역할에 기반으로 그룹화함으로써 액세스 제어 정책 관리를 단순화합니다. 액세스 제어 정책을 변경하지 않고도 사용자 추가나 제거가 쉽습니다. 특히 잘 정의된 권한 구조를 가진 대규모 조직에서는 RBAC가 매우 효율적일 수 있습니다.
• 투명성: RBAC는 역할, 권한 및 사용자 간의 명확한 매핑을 제공합니다. 액세스 제어 정책을 감사하고 검토하기가 쉽습니다.

RBAC의 단점#

• 경직성: RBAC는 복잡한 액세스 제어 정책을 정의할 때 경직될 수 있습니다. 액세스 제어 정책이 더 역동적이고 컨텍스트 인식이 필요한 시스템에는 적합하지 않을 수 있습니다.
• 세분성: RBAC는 세분화된 액세스 제어에 필요한 세분성을 결여할 수 있습니다. 액세스 제어 정책은 잘 정의된 역할에 묶여 있으며, 더 세분화된 수준에서 권한을 정의하려면 추가적인 노력이 필요할 수 있습니다.
• 역할 폭증: 복잡한 권한 구조를 가진 대규모 조직에서는 역할의 수가 급격히 증가하여 역할 폭증으로 이어질 수 있습니다. 많은 수의 역할을 관리하는 것은 도전적일 수 있습니다.

특성 기반 액세스 제어 (ABAC)#

2000년대 후반, 시스템이 더 복잡하고 역동적이 되면서 점점 더 많은 조직이 역할 기반 액세스 제어 (RBAC)를 대체할 수 있는 대안으로 특성 기반 액세스 제어 (ABAC)를 채택하기 시작했습니다. ABAC의 공식화에서 주목할 만한 이정표는 2014년 발표된 NIST Special Publication 800-162입니다.

ABAC는 RBAC와 비교하여 더 유연한 액세스 제어 모델입니다. ABAC는 사용자의 특성, 리소스, 행동 및 환경에 기반한 액세스 제어 정책을 정의하는 허가 모델입니다. 이는 조직이 다양한 컨텍스트와 조건에 맞게 적응할 수 있는 세분화된 액세스 제어 정책을 정의할 수 있도록 합니다.

ABAC의 주요 구성 요소#

• 주체: 주체는 리소스에 대한 액세스를 요청하는 엔티티입니다. 사용자, 디바이스, 애플리케이션 또는 리소스에 액세스할 필요가 있는 기타 엔티티일 수 있습니다.
• 리소스: RBAC에서와 마찬가지로, 리소스는 주체가 액세스할 수 있는 엔티티입니다. 파일, 데이터베이스, API, 또는 시스템 엔티티일 수 있습니다.
• 행동: 행동은 주체가 리소스에 대해 수행할 수 있는 특정 작업입니다. 생성, 읽기, 수정, 삭제 또는 제어해야 하는 기타 작업일 수 있습니다.
• 환경: 환경은 액세스 요청이 이루어지는 컨텍스트입니다. 시간, 위치, 네트워크, 디바이스 등의 특성을 포함할 수 있습니다.
• 특성: 특성은 주체, 리소스, 행동 또는 환경의 특성입니다. 사용자 역할, 부서, 위치, IP 주소, 디바이스 유형 등 다양할 수 있습니다.
• 정책: 정책은 액세스가 허용 또는 거부되는 조건을 정의하는 규칙입니다. 정책은 특성을 기반으로 정의됩니다.

ABAC의 장점#

• 유연성: ABAC는 다중 특성에 기반한 복잡한 액세스 제어 정책을 수용할 수 있습니다. 다양한 컨텍스트와 조건에 맞게 적응할 수 있는 세분화된 정책을 정의할 수 있도록 합니다.
• 동역성: ABAC 정책은 동적이고 컨텍스트 인식적일 수 있습니다. 액세스 제어 결정은 위치, 시간, 디바이스 유형 등과 같은 실시간 특성을 기반으로 할 수 있습니다.
• 세분성: ABAC는 다중 특성 기반으로 정책을 정의하여 세분화된 액세스 제어를 제공합니다. 역할과 권한을 정의하는 것과 달리, 특성 기반 정책은 더 세분화될 수 있습니다.

ABAC의 단점#

• 복잡성: ABAC는 RBAC와 비교하여 구현 및 관리가 더 복잡할 수 있습니다. 특성과 정책을 정의하는 데 더 많은 노력과 전문 지식이 필요할 수 있습니다. 역할과 권한이 잘 구조화된 RBAC와 달리 특성은 더 역동적일 수 있으며, 정책 또한 그렇습니다. 복잡한 시스템에서 많은 특성과 정책을 관리하는 것은 도전적일 수 있습니다. 종종 정책 평가 엔진이 필요하게 됩니다.
• 성능: 특성을 평가하는 것은 특정 환경에서 성능에 영향을 줄 수 있습니다. 다중 특성과 실시간 조건에 기반한 정책은 액세스 제어 결정에 지연을 초래할 수 있습니다.

비교 테이블#

비교 테이블에서 분명히 알 수 있듯이, RBAC는 잘 정의된 권한 구조를 가진 시스템 및 액세스 제어 정책이 비교적 정적인 경우에 가장 적합합니다. 반면 ABAC는 액세스 제어 정책이 동적이고, 컨텍스트 인식적이며, 세분화 되어야 하는 시스템에 보다 적합합니다.

예시#

시나리오: 병원 시스템이 각기 다른 직원들의 환자 기록에 대한 액세스를 관리해야 하는 경우.

• 직원: 의사, 간호사, 관리자
• 리소스: 환자 기록
• 권한: 읽기, 쓰기, 삭제

사례 1#

액세스 제어 정책이 비교적 간단한 경우:

1. 의사는 환자 기록을 읽고 쓸 수 있습니다.
2. 간호사는 환자 기록을 읽을 수 있습니다.
3. 관리자는 환자 기록을 읽고, 쓰고, 삭제할 수 있습니다.

RBAC 모델#

이 경우, RBAC는 간단하고 효과적입니다. 우리는 의사, 간호사, 관리자에 대한 역할을 정의하고 각 역할에 적절한 권한을 할당할 수 있습니다.

액세스 제어 평가가 간단합니다:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC 모델#

이 경우 ABAC는 과하지만, 여전히 부서, 역할 등과 같은 특성에 기반한 세분화된 정책을 정의하는데 사용할 수 있습니다.

특성:

• user.role: 의사, 간호사, 관리자
• resource.name: 환자 기록
• action: 읽기, 쓰기, 삭제

정책:

• 정책 1: user.role 및 resource.name에 기반한 읽기 액세스를 허용
  • subject: 역할이 의사, 간호사, 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 읽기
  • effect: 허용
  • rationale: "모든 역할의 환자 기록에 읽기 액세스 허용"
• 정책 2: 의사 및 관리자의 편집 액세스 허용
  • subject: 역할이 의사, 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 쓰기
  • effect: 허용
  • rationale: "의사 및 관리자에게 환자 기록에 대한 쓰기 액세스 허용"
• 정책 3: 관리자에게 삭제 액세스 허용
  • subject: 역할이 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 삭제
  • effect: 허용
  • rationale: "관리자에게 환자 기록 삭제 액세스 허용"

각 읽기/쓰기/삭제 요청 시, 정책 엔진은 특성에 기반한 모든 관련 정책을 평가하고 액세스 제어 결정을 내립니다.

비교#

이 경우 액세스 제어 정책은 간단하고 잘 구조화되어 있습니다. 사용자가 리소스에 대한 액세스를 가지는 지 결정하는 데 단일 수준의 권한 검사가 필요합니다. 병원 시스템의 구조가 복잡해지고 여러 부서, 역할 및 권한이 존재한다고 상상해 보세요:

• RBAC 모델에서 환자 기록 리소스의 액세스 제어 평가 프로세스는 사용자가 읽기, 쓰기, 또는 삭제 권한을 가지고 있는 지와 상관없이 여전히 간단하고 직관적일 것입니다.
• 반면 ABAC는 부서-id 및 의사-id와 같은 추가 특성을 포함해야 합니다. 만약 IoT 디바이스가 환자 기록에 액세스할 필요가 있다면, 디바이스-id라는 새로운 특성이 정책 평가에 포함되어야 할 것입니다. 인턴 의사에게 임시로 읽기 권한을 부여하려면 어떻게 해야 할까요?

결론적으로, RBAC가 더 잘 맞습니다. RBAC는 잘 정의된 권한 구조와 액세스 제어 정책이 정적인 시스템에 대해 간단하고 효율적입니다.

사례 2#

같은 병원 시스템에서 이제 새로운 역할 환자와 새로운 특성 환자-id를 도입합시다.

액세스 제어 정책은 다음과 같습니다:

1. 의사는 환자 기록을 읽고 쓸 수 있습니다.
2. 간호사는 환자 기록을 읽을 수 있습니다.
3. 관리자는 환자 기록을 읽고, 쓰고, 삭제할 수 있습니다.
4. 환자는 자신의 기록을 읽을 수 있습니다.

RBAC 모델#

이 경우, 기존의 읽기 권한 이외에 자신의 기록 읽기라는 새로운 권한을 도입해야 합니다. 우리는 의사, 간호사, 관리자, 환자에 대한 역할을 정의하고 각 역할에 적절한 권한을 할당할 수 있습니다.

이제 액세스 제어 평가는 특히 읽기 환자 기록 작업에 대해 약간 더 복잡해졌습니다:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC 모델#

이제 새로운 요구사항에 맞춰 ABAC 모델의 특성과 정책을 업데이트합시다.

특성:

• user.role: 의사, 간호사, 관리자, 환자
• user.id: 환자-id
• resource.name: 환자 기록
• resource.patient-id: 환자-id
• action: 읽기, 쓰기, 삭제

정책:

• 정책 1: 모든 환자 기록에 대한 읽기 액세스 허용
  • subject: 역할이 의사, 간호사, 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 읽기
  • effect: 허용
  • rationale: "모든 직원 및 환자 본인의 환자 기록에 읽기 액세스 허용"
• 정책 2: 의사 및 관리자에게 모든 환자 기록에 대한 쓰기 액세스 허용
  • subject: 역할이 의사, 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 쓰기
  • effect: 허용
  • rationale: "의사 및 관리자에게 환자 기록에 대한 쓰기 액세스 허용"
• 정책 3: 관리자에게 모든 환자 기록에 대한 삭제 액세스 허용
  • subject: 역할이 관리자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 삭제
  • effect: 허용
  • rationale: "관리자에게 환자 기록 삭제 액세스 허용"
• 정책 4: 자신의 환자 기록에 대한 읽기 액세스 허용
  • subject: 역할이 환자인 사용자
  • resource: 이름이 환자 기록인 리소스
  • action: 읽기
  • condition: user.id === resource.patient-id
  • effect: 허용
  • rationale: "자신의 환자 기록에 대한 읽기 액세스 허용"

비교#

이 경우 액세스 제어 정책은 더 복잡하고 컨텍스트 인식적입니다. 환자 기록 리소스의 액세스 제어 평가 프로세스는 사용자가 리소스에 액세스할 수 있는 지의 여부를 결정하기 위해 여러 수준의 권한 검사가 필요합니다.

• RBAC 모델에서는 환자 기록 리소스의 액세스 제어 평가 프로세스는 사용자가 리소스에 액세스할 수 있는 지의 여부를 결정하기 위해 여러 수준의 권한 검사가 필요합니다. 예를 들어, 환자가 자신의 기록에 액세스할 수 있는 지 결정하려면, 시스템은 사용자가 자신의 기록 읽기 권한을 가지고 있는지, 그리고 사용자 ID가 환자 ID와 일치하는지를 확인해야 합니다.
• ABAC 모델에서는 액세스 제어 평가 프로세스가 더 간단할 수 있습니다. 정책은 사용자, 리소스, 행동의 특성에 따라 정의될 수 있습니다. 예를 들어, 환자가 자신의 기록에 액세스할 수 있는 지 결정하려면, 정책 엔진이 사용자 ID와 환자 ID 기반으로 정책을 평가할 수 있습니다.

이 경우, ABAC가 더 적합할 수 있습니다. ABAC는 액세스 제어 정책이 동적이고, 컨텍스트 인식적이며, 세분화되어야 하는 시스템에 더 적합합니다.

결론#

RBAC와 ABAC 중 선택은 시스템의 특정 요구사항에 따라 달라집니다. RBAC는 잘 정의된 권한 구조를 가진 시스템 및 액세스 제어 정책이 정적인 경우에 가장 적합합니다. ABAC는 액세스 제어 정책이 동적이고, 컨텍스트 인식적이며, 세분화되어야 하는 시스템에 더 적합합니다. 실제로 조직은 원하는 수준의 액세스 제어를 달성하기 위해 두 모델을 결합하여 사용할 수 있습니다.