[Case Study] Role-Based Access Control 시스템

아래 본문 내용은 SACMAT 2001에서 발표된 "The Role-Based Access Control System of a European Bank: A Case Study and Discussion" 내용을 요약하여 작성한 내용입니다.

 

"SACMAT 2001 The Role-Based Access Control System of a European Bank: A Case Study and Discussion" 키워드로 검색을 하시거나 https://www.semanticscholar.org/paper/The-role-based-access-control-system-of-a-European-Schaad-Moffett/da4d8abe8fc28677affa920a852b43ce9577b70c URL을 참조하시면 영문 발표 원본 자료를 보실 수 있습니다.

 

역할 기반 액세스 제어 분야의 연구는 지난 몇 년 동안 빠르게 발전해왔으ㄴ나, 대규모 조직 내에서 기존 역할 기반 액세스 제어 시스템을 식별하고 설명하기 위해 수행된 작업은 거의 없습니다.

이 문서는 주요 유럽 은행의 액세스 제어 시스템에 대해 설명하고 있으며, 시스템의 구조, 관리 및 관리를 제한하는 기존 제어 원칙에 대한 개요를 제공합니다. 

 

1. 개요

역할 기반 접근 제어 (RBAC, Role Based Access Control) 는 잘 정의된 연구 영역이며,널리 인정되는 접근 제어 모델로  존재합니다.

이 문서에서 설명하는 시스템은 단일 어플리케이션이나 운영 체제에 국한되지 않고 접근 제어를 제공한다는 사실을 강조하며, 다양한 시스템 및 어플리케이션들에 대한 전사적 수준의 접근 제어 서비스를 제공합니다.

이 문서의 나머지 부분은 다음과 같이 구성됩니다. 

• 섹션 2에서는 주요 유럽 은행에서 사용되는 실제 접근 제어 시스템의 사례 연구를 제공하며, 섹션 2.1 ~ 2.3에서는 배경과 구조를 설명하고 적용 사례를 제공합니다.
• 사용자, 역할 및 권한의 수와 이들의 관계는 섹션 2.4에서 제공되고, 섹션 2.5에서 시스템의 관리와 직무 분리, 이중 제어 및 최소 권한과 같은 제약에 의해 시스템이 제어되는 방법을 설명합니다.
• 현재 시스템의 약점을 해결하기 위한 시스템의 추가 개발 목표는 섹션 2.6에서 논의됩니다.
• 섹션 3에서는 이 시스템을 Sandhu의 RBAC96 액세스 제어 모델과 비교 및 ​​대조하여 섹션 3.1의 접근 권한 상속 문제와 섹션 3.2의 사용자 그룹화 문제를 다룹니다.

2. FUB 출입 통제 시스템

2.1 배경

이 백서에서 소개하는 특정 사례 연구는 전 세계적으로 50,659명의 직원과 1,459개의 지점을 보유한 유럽의 주요 은행인 Dresdner 은행과 협력하여 수행되었습니다. 약 650만 명의 개인 고객과 1,000개 지점을 보유한 주요 사업은 독일에 있으며 나머지는 유럽 및 해외에 있습니다.

• 해당 은행은 비즈니스를 지원하기 위해 다양한 컴퓨팅 애플리케이션을 사용하고 있으며, 그 중 많은 애플리케이션이 메인프레임 세계에서 시작되었지만 최근에 배포된 클라이언트-서버 기반 시스템도 있습니다.
• 1990년 이전에는 대부분의 호스트 기반 응용 프로그램에서 해당 호스트에서 관리하는 로컬 액세스 제어 파일을 사용하여 액세스 권한을 결정했으며, 개별 직원들에 대해 개별 어플리케이션 수준에서 접근 권한을 수동으로 관리해야 했습니다. 그러나, applicaiton을 사용하는 사용자 수가 증가함에 따라 막대한 관리 오버헤드가 발생했습니다. 또한, 개별 사용자들에 대한 여러 appliction 수준 보안 파일의 유지 관리는 오류가 발생하기 쉬운 프로세스임과 동시에 일반 보안 정책 프레임워크 내에서 정당화될 수 없었습니다.
• 당시에는 적절한 상용 솔루션인 없어던 관계로, 이러한 상황을 개선하기 위해 FUB(= Funktionale Berechtigung)라고 하는 시스템이 당시 은행에 의해 개발되었습니다.
• 이 시스템에서 접근 권한은 개별 사용자의 직무 기능과 조직 내 직위의 조합에 따라 부여됨에 따라, 어플리케이션 수준에서 개별 사용자에 대한 접근 권한을 직접 할당한 것이 중단되었습니다.
• FUB는 전사적 역할 기반 접근 제어 시스템의 한 예입니다. 개별 application들은 자체적으로 접근 제어 결정을 내릴 수 없게 되었으며, 중앙에서 제공되는 보안 프로파일을 기반으로 데이터에 대한 접근 권한을 부여합니다. 개별 appliction 들은 먼저 자신을 식별하고 인증하는 사용자에 의해 시작됩니다. 처음에 어플리케이션은 사용자가 소유할 수 있는 관련 접근 권한에 대해 알지 못하며, 이 정보를 얻기 위해서는 현재 사용자의 보안 프로파일에 대해 FUB에 쿼리합니다.
• FUB는 하루 평균 42,000개의 보안 프로파일을 배포하며, 시스템이 하나의 개별 보안 프로파일을 결정하는 데 필요한 시간은 약 85ms이고, 시스템의 가용성 비율은 연간 99%입니다.

 

2.2 기본 시스템 구조 (The Basic System Structure)

• FUB는 역할 기반 접근 제어 시스템으로, 내부의 역할은 직위 (official position) 및 직무 (job function)의 조합으로 정의됩니다. 일반적인 직위 (official position)는 일반 서기(ordinary Clerk), 그룹 관리자 또는 지역 관리자가 될 수 있으며, 직무 (job function)는 재무 분석가, 공유 기술자 또는 내부 소프트웨어 엔지니어와 같은 일상 업무를 나타냅니다. 또한, 사용자가 속한 조직 단위는 특정 어플리케이션에 대한 접근 제어 기준으로 사용됩니다.
• 직위와 직무에 관련된 모든 데이터는 인사 시스템 데이터베이스에서 정의되고 유지 관리되며, 매일 밤 인사 시스템과 FUB 사이에서 배치 작업이 실행됩니다.
• 따라서, FUB 접근 제어 시스템은 현재 조직 상태와 기존 역할에 대한 매우 정확한 이미지를 가지고 있으며, 인사 시스템과 연계된 FUB 내의 인적 자원 데이터베이스의 데이터들은 일반 어플리케이션들에 연결됩니다. 접근 권한은 어플리케이션에 할당됩니다.
• 사용자가 어플리케이션을 시작할 때 FUB는 사용자가 소유한 개별 접근 권한을 개별 어플리케이션에 알려주는 보안 프로파일을 제공합니다.
• 그림 1은 시스템의 기본 아키텍처와 인적 자원 데이터베이스 및 개별 어플리케이션에 대한 인터페이스를 보여줍니다.

<그림 1> FUB 시스템의 기본 구조

직원은 단일 조직 단위에 포함되며, 이상적으로 각 직원은 하나의 역할에만 할당되나, 특별한 경우에는 최대 4개까지의 역할을 부여할 수 있습니다. (예: 동료가 질병으로 인한 경우).
역할을 통해 여러 애플리케이션에 접근할 수 있으며, 개별 어플리케이션에는 할당된 접근 권한 집합이 있습니다. 단순화된 기본 데이터 모델이 그림 2에 나와 있습니다.

 

<그림 2> FUB 시스템 데이터 모델링

 

2.3 어플리케이션 사례 (An Application Example)

위의 기술적인 설명을 보다 구체적으로 만들기 위해 Dresdner Bank의 지점에서 일상적인 비즈니스를 반영하는 시나리오를 제공합니다(그림 3). 기존 은행 고객이 지점의 재무 고문(Financial Advisor) 과 개인 저축 상황에 대해 논의하기를 원합니다. 재무 고문과 클라이언트는 개인용 컴퓨터가 있는 회의실로 이동한 뒤, 재무 고문은 스마트카드와 비밀번호를 사용하여 기계에 대해 자신을 식별하고 인증합니다. 그는 중앙 서버에 저장된 클라이언트의 기록을 입력할 수 있는 어플리케이션을 시작합니다.

어플리케이션이 시작되면 응용 프로그램 도메인 내에서 해당 재무 고문이 어떤 권한을 가지고 있는지 쿼리하여 호스트에 요청을 보냅니다. 지원 신청서에는 본인확인 및 본인인증 과정에서 부여된 담당자번호가 포함되어 있습니다.
또한, 어플리케이션에 대한 관련 권한 부여 프로필을 얻기 위해 어플리케이션 식별자가 제출됩니다.
FUB가 이러한 데이터를 사용하여 보안 프로파일을 전달하면 해당 개별 어플리케이션은 사용자 역할에 할당된 접근 권한을 알고 그에 따른 접근 권한을 실행할 수 있도록 합니다.

이 특별한 경우 재무 고문이 속한 관련 조직 단위(여기서는 지점)에 대한 정보는 재무 고문이 지점 외부의 계정 데이터에 접근하는 것을 금지합니다. 그의 접근 권한은 지점의 조직 도메인 내에서 제한됩니다.
그러나, 다른 어플리케이션은 은행 전역의 접근 포인트에서 사용할 수 있으며, 접근 권한이 로컬 정보에 의존하지 않기 때문입니다.

 

<그림 3> 접근권한 요청 Flow

현재 FUB 시스템의 한 가지 약점은 그림 2에서 볼 수 있듯이 사용자가 둘 이상의 역할에 할당될 수 있다는 것입니다.

이것은 동료가 아프거나 휴일에 있을 때 발생할 수 있지만, 해당 점원이 오전에 지점 A에서 일하고 오후에 지점 B에서 일하는 보다 영구적인 경우에도 발생할 수 있습니다.

RBAC96 모델에서 사용자는 세션에 대해 활성화할 역할을 선택해야 합니다. 그러나, 세션 개념은 FUB에 존재하지 않음에 따라, 사용자가 시스템에 로그온할 때 할당된 모든 역할의 모든 액세스 권한을 가집니다. 이는 최소 권한 및 직무 분리 원칙과 관련하여 문제를 야기합니다.

따라서, 보안 위반 및 충돌을 방지하기 위해 사용자/역할 할당에 대한 세심한 관리 및 모니터링이 필요합니다.

 

2.4 역할의 수 (The Number of Roles)

FUB 시스템의 역할은 조직 계층 내의 공식 직위 ((Official Position)와 직무(Function)에 대한 설명을 사용하여 정의되며, 이러한 데이터는 인사 시스템을 통해서 제공됩니다.

이제부터는 구성 기능(Construct function) /공식 직위(Official Position) 를 사용하여 역할을 참조하겠습니다.
Fuction에는 소문자를 사용하고, Position 에는 제목 대소문자를 사용합니다. 예를 들어, 재무 분석가/그룹 관리자 (financial analyst/Group Manager)는 해당 사용자가 분석가 직무를 수행하며, 그룹 관리자의 직위를 보유하고 있음을 나타냅니다. 이론적으로 총 역할 수는 모든 공식 직위와 모든 직무의 산물입니다.

그러나, 비서/이사회 구성원과 같은 특정 가능한 역할은 실제로 발생하지 않기 때문에 실제 역할 수는 이것의 하위 집합이 됩니다.

은행 내에는 지점의 일반 서기부터 지점장을 거쳐 이사회 위원까지 65개의 공식 직위가 있습니다. 이것은 부분 순서로 나타낼 수 있습니다. 계층은 비용 센터, 부서 또는 프로젝트 그룹과 같은 추가 조직 지표와 함께 발생합니다.

이러한 직위는 인적 자원 데이터베이스에서 제공하는 368개의 다른 직무 기능과 결합됩니다. 23,920 (직위 65 * 직무 368 = 23,920) 개의 역할 집합이 가능하지만 현재 사용 중인 역할의 수는 약 1,300개입니다. 

또한, 매일 밤 직원, 기능, 직급 및 조직 단위에 대한 인적 자원 데이터가 FUB로 전송되고 있으나, 모든 직원이 실제로 FUB 시스템의 활성 사용자로 볼 수 있는 것은 아님에 따라 (예: 청소 직원, 케이터링, 내부 우편 서비스 등), FUB의 사용자는 약 40,000명에 불과합니다.

이 수치는 RBAC2000 Workshop[10]에서 제공된 구두 추정치와 일치하며, 이는 역할 기반 시스템의 역할 수가 전체 사용자 수의 약 3-4%임을 시사합니다.

40,000명의 FUB 사용자와 1,300명의 역할을 통해 우리는 약 3.2%의 역할/사용자 비율을 얻습니다. 그러나 이 분포는 모든 조직의 피라미드 모양의 공식 직위 계층으로 인해 실제로 균등하지 않습니다.
조직에는 항상 사업부장보다 서기(Clerk) 업무를 담당자가 상대적으로 많음에 따라, 재무 분석가/사업부 책임자 역할보다 재무 분석가/서기와 같은 역할이 더 많습니다. 

시스템 관리의 또 다른 문제는 정규 직원으로 간주될 수 없는 사용자에 대한 접근 제어 서비스도 제공해야 한다는 것입니다. 이 사용자 그룹에는 타사 컨설턴트, 임시 직원 및 프리랜서가 포함되며, 몇 주에서 몇 년까지 다양한 기간의 프로젝트 동안 은행에서 일합니다.
필요한 인력을 확보하는 것 외에도 컨설턴트 또는 프리랜서를 고용하는 것도 아웃소싱의 한 형태입니다.

이상적으로는 이 사용자 그룹이 작업을 시작할 때 항상 새 계정을 가져와야 하며 프로젝트를 떠날 때 해당 계정을 삭제해야 하나, 이것은 오버헤드를 생성합니다. 따라서 이 그룹에 대한 정보는 인적 자원 데이터베이스에 보관되지 않고 FUB 직원이 로컬에서 관리합니다. 그들 중 많은 사람들이 프로젝트 기간 동안 왔다가 휴가를 갔다가 종종 프로젝트가 끝난 직후 다시 돌아와 때로는 동일하거나 관련된 다른 프로젝트를 위해 일합니다.

따라서, 이러한 외부 사용자 그룹에 대한 정보는 인사 시스템 데이터베이스에 보관되지 않고, FUB 시스템 관리 직원이 로컬에서 관리합니다.
한 번에 수백 명의 사용자를 포함하는 이러한 외부 사용자 그룹은 지속적으로 변경될 수 있으므로 이러한 사용자를 관리할 때 발생하는 오버헤드를 과소평가해서는 안 됩니다.

그러나, 위의 수치를 제공할 때 이 문제를 고려하지 않음에 따라, 역할/사용자 비율은 상근 직원에게만 적용됩니다.

 

2.5 역할 관리 및 제어 원칙 (Role Administration and Control Principles)

역할의 실제 정의와 사용자 및 역할에 대한 접근 권한 할당은 조직 내 여러 수준에서 발생합니다(그림 4).

• 인사팀 - 역할 정의 및 사용자/역할 할당
• 어플리케이션 관리 - 접근 권한 정의 및 어플리케이션/접근 권한 할당.
• FUB 관리 - 역할/어플리케이션 할당.

사용자 및 역할은 처음에 인사 부서에서 생성되며, 사용자에게는 사용자 식별 번호 역할을 하는 고유 번호가 부여됩니다. 또한, 기능 (Function)과 직위 (Position)를 유지하고 결합하는 역할이 정의됩니다. 그런 다음에 사용자가 역할에 할당됩니다.

이는 역할 기반 접근 제어와 인적 자원 및 조직과 같은 기타 영역 간의 긴밀한 관계를 반영하는 것으로 의미를 갖게 됩니다.

역할에 대한 접근 권한 부여는 어플리케이션 관리자를 통해 개별 어플리케이션에 대해 수행됩니다. 이는 특정 접근 권한을 나타내는 일련의 숫자를 애플리케이션 식별자(예: PKI = Private Customer Instruments)에 할당하는 형식을 취하며, 이 숫자의 의미는 애플리케이션 관리자만 알고 있습니다. (예: 203 = Private Customer Instruments 애플리케이션에서 새 계정 생성).

이것의 장점은 역할/어플리케이션 할당을 담당하는 FUB 관리자가 어플리케이션 도메인 내에서 특정 번호가 나타내는 접근 권한을 알 수 없다는 것입니다(그림 5).

또한 지원 관리 프로세스는 이중 통제 원칙에 따르게 하여, 한 사람은 데이터를 변경할 수 있지만 다른 두 번째 사람은 이러한 데이터를 확인만 가능하도록 합니다.

<그림 4> 접근 권한 관리

 

FUB 관리자는 역할/응용 할당만 수행할 수 있으므로 전체 관리 프로세스에서 강력한 수준의 직무 분리가 있으며, 모든 이벤트 처리를 내역을 기록하여 증거를 생성하는 것은 의무적이며 기록 및 증거 생성에 대한 은행의 정책을 따라야 합니다.

그러나 섹션 2.4(그림 4에는 표시되지 않음)에 설명된 대로 프리랜서 또는 컨설턴트 관리와 관련하여 이러한 제어 원칙 중 일부는 분명히 위반됩니다. 이 그룹은 FUB 직원이 현지에서 관리하게 되고, FUB 관리자는 사용자의 신원을 알고 있습니다.  관리자와 어플리케이션에서 사용자 식별자를 해당 사용자에게 제공하며 컨설턴트가 프로젝트에서 작업할 때 필요에 따라 할당됩니다.

은행은 이 문제를 인지하고 있으며 앞으로 해결할 것입니다.

이 맥락에서 직무 분리 원칙과 이중 통제 원칙 간의 차이점에 유의해야 하며, 직무 분리는 작업을 별도의 하위 작업으로 분할하도록 하여 하위 작업을 수행하는 데 다른 사람들이 필요하게 됩니다. 반면, 이중 통제의 원칙은 하나의 작업을 완료하는 데 최소 두 사람이 참여해야 합니다.

역할 및 권한 할당 취소 작업은 은행 시스템에서 매우 우아하게 수행됩니다. 인사 부서에서 제공한 정보를 결합하면 사용자가 회사를 떠날 때 사용자/역할 할당이 더 이상 존재하지 않으며, 조직 구조가 변경되면 모든 사용자/역할, 역할/응용 프로그램 할당이 무효화됩니다.

인사 시스템 데이터베이스에서 사용자를 삭제하면 해당 사용자가 시스템에 더 이상 존재하지 않게 되었을 때에 모든 작업이 삭제되기 때문에 이러한 긴밀한 결합력은 특정 위험을 수반하게 됨에 따라, 귀중한 작업이 손실되지 않도록 추가 제어 및 조직적 조치가 필요합니다.

<그림 5> FUB 관리 시스템 스크린샷

 

2.6 시스템 개발 목표 (System Development Goals)

 

2.6.1 접근 권한 할당 (Access right allocation)
현재 시스템에서 접근 권한은 직무(Function)/계층적 직위(Hierarchical Position) 와 조직 단위의 조합을 통해 할당할 수 있습니다. 특히, 사용자별로 접근 권한을 직접 할당할 수 있는 추가 가능성은 존재하지 않습니다. 이는, 역할을 통해 사용자와 접근 권한을 분리하는 원칙에 위배되는 기능이기 때문입니다. 그러나, 특정 접근 권한(예: 직원의 위임장을 나타내는 액세스 권한 집합)의 경우 사용자에게 직접 할당하는 것이 바람직합니다.

2.6.2 그룹화 메커니즘 (Grouping mechanisms)

(a) 직원 그룹화
현재 시스템에서 직원은 직무(Function)/계층적 직위(Hierarchical Position)와 조직 단위의 조합에 따라서만 그룹화될 수 있습니다. 다른 기준에 따라 직원을 그룹화하고 그룹별 접근 권한을 할당하는 것은 불가능합니다.
그룹화 메커니즘은 개별 개인이 아닌 그룹에만 역할을 할당하면 되므로 관리가 용이합니다.

(b) 접근 권한 그룹화
현재 시스템은 자연스럽게 함께 속하는 접근 권한의 그룹화를 허용하지 않습니다. 접근 권한에 대한 그룹화에 대해 예를 들면, 계정 생성을 위한 접근 권한 101과 계정 삭제를 위한 102를 계정 조작을 위한 단일 그룹 G1으로 그룹화하는 것으로, 이러한 그룹화된 권한을 통해 역할에 대한 접근 권한을 더 쉽게 할당할 수 있습니다.

2.6.3 적용/입장 규정 (Covering/Standing-in regulations)
현행 시스템에서는 한 직원이 다른 직원(예: 휴일 또는 질병)을 보호하는 규정이 존재하지 않습니다. 해결되지 않은 다양한 문제가 있는데, 어플리케이션별 접근 권한을 부분적으로만 위임하는 기능도 그 중 하나입니다. 또, 다른 문제는 한 사람이 동시에 두 명의 다른 사람을 대신할 수 있는 능력을 고려합니다. 이는 직무 분리 요구 사항을 위반할 수 있습니다.

2.6.4 역량 및 제약 (Competences and Constraints)
현재 시스템은 보안 프로파일에서 역량 및 제약 조건의 사양을 허용하지 않습니다 (예 : 최대 DM 100,000 계약에 서명할 수 있는 권한).

2.6.5 조직 구조에 대한 접근 제어 시스템의 매핑 (Mapping of access control system to
organisational structure) 
접근 제어 시스템을 기존 조직 구조에 매핑할 때 다음 사항을 염두에 두어야 합니다.

(a) 지속적인 조직 변화
Dresdner Bank 규모의 조직은 구조적 및 기능적 조직에서 지속적인 변화 프로세스를 따르게 되는 데, 이는 은행의 비즈니스가 시장 요구에 지속적으로 맞춰져 있기 때문입니다. 또한,  예상치 못한 인수 또는 합병으로 인해 조직이 크게 바뀔 수 있습니다.
현재 접근 제어 시스템은 큰 관리 노력 없이 이러한 변경 사항을 충족할 수 있는 유연성을 제공하고 있지는 못합니다.

(b) 비즈니스 전략의 유연한 지원
개인 고객 비즈니스의 특정 전략에서는 직원이 특정 조직 구조와 관련될 수 있어야 합니다.
이는 지점 또는 비용 센터(Cost Center)의 형태일 수 있지만 전사적 작업 그룹, 태스크 포스 또는 프로젝트와 같은 보다 추상적인 구조일 수도 있습니다. 출입 통제 시스템은 이러한 구조를 반영할 수 있어야 합니다.

3. FUB 시스템과 RBAC 모델

분명한 질문은 은행의 접근 통제 시스템이 역할 기반 접근 통제의 다른 모델과 얼마나 비교할 수 있는지입니다.
비교 대상은 Sandhu의 RBAC96 모델[2]로, 잘 정의되고 사용하기 쉬우며 가장 중요한 것은 특정 요구 사항에 따라 다양한 접근 제어 정책을 지원하도록 구성할 수 있다는 것과 제안된 NIST 표준[1]의 기초를 형성하고 있기 때문입니다.

다음 두 가지 문제를 고려합니다.
• 역할 계층을 통한 접근 권한 상속
• 사용자 그룹

 

3.1 역할 계층을 통한 접근 권한 상속 (Access Right Inheritance through a Role Hierarchy)

RBAC96 모델은 역할 계층을 통한 접근 권한 상속의 개념을 가지고 있습니다. 역할의 부분 순서가 정의되면 상위 역할은 하위 역할에 대해 접근 권한을 상속합니다. 그림 2를 보면 이러한 종류의 역할 상속 구조가 없음을 즉시 알 수 있습니다.

은행의 접근 통제 시스템은 상속 기능을 제공하지 않습니다. 왜 이런 경우가 있으며 변경해야 할까요 ?

RBAC96 모델에서 "역할"은 "..조직 내 명명된 직무 기능 .."으로 정의되는 원자적 개념입니다.
그러나, FUB 시스템의 자연스러운 대응은 직무(Function)와 직위(Position) 모두로 구성된 FUB 역할입니다. 표 1의 예를 참조하십시오.

따라서 FUB 역할의 부분적 순서는 직무(Function)와 직위(Position) 중 하나 또는 둘 모두에 대해 정의될 수 있습니다. 아래에서 두 가지 가능한 주문에 대해 설명합니다.

<표 1> 직무 및 직위

 

3.1.1 직위의 계층 (Hierarchy of Official Positions)
조직에서의 공식 직위(Official Posistions)에는 엄격한 부분적 순서가 있습니다(> 기호로 표시됨).

예: 사업부장 > 그룹 관리자 > 서기 (Clerk)

이것은 그 자체로는 거의 의미가 없지만 직무 (Function)와 결합될 때 실제 권력의 실제 계층에 의해 종종 반영됩니다. 예를 들어, 재무 분석가/그룹 관리자 역할(financial analyst/Group Manager) (역할 B라고 함)은 재무 분석가/서기 역할financial analyst/Clerk (역할 A)보다 더 많은 권한을 갖습니다. 표 2는 역할 B가 단기 금융 상품, 파생 상품 거래 및 이자 상품 어플리케이션에 대한 접근 권한과 같은 수 이상의 접근 권한과 하나 이상의 어플리케이션(Private Customer Instruments, 개인 고객 상품)에 대한 접근 권한을 갖고 있음을 보여줍니다. 반면에 사무실 뱅킹/그룹 관리자와 재무 분석가/서기 사이에는 기능 영역이 다르기 때문에 유사한 계층적 권력 관계가 없습니다.

따라서 한 역할이 다른 역할보다 우월하고 직위(Position)가 우월하고 기능(Function)이 동일한 경우, 역할 계층을 정의할 수 있습니다.

즉, 동일힌 직무인 재무분석가 (financial analyst) 이나, 다른 직위 그룹 관리자(Group Manager) & 서기 (Clerk) 

더 공식적으로 "."를 사용합니다. 선택기로 기호:

Role(x) > Role(y) ⇔ Role(x).Position > Role(y).Position ∧ Role(x).Function = Role(y).Function

<표 2> 역할, 어플리케이션 및 접근권한 (Roles, Applications and access rights)

위의 예에서 Group Manager > Clerk가 주어지면 접근 권한 정의를 절약할 수 있고 Table 2를 Table 3과 같이 다시 작성할 수 있습니다.

 

<표 3> B가 A로부터 액세스 권한을 상속한다고 가정하여 표 2를 다시 작성

 

3.1.2 기능의 계층
기능(Function)의 부분적 순서도 있을 수 있습니다. 두 가지 기능(Function) 검사관 및 재무 회계사의 예는 다음과 같습니다.

예: 검사관 (inspector) > 재무 회계사 (finance accountant)

이것은 "isa" 계층 구조로, 검사원(inspector)의 기능(Function)을 수행하려면 재무 회계사(finance accountant)여야 하고 모든 접근 권한이 필요하며, 검사관이 재무 회계사라는 것은 항상 사실입니다. 그렇지 않으면 그 기능을 수행할 능력이 없기 때문입니다.

따라서 공식적인 직위(Official Position)에 관계없이 기능(Fuction)을 기반으로 역할 계층을 생성하는 것이 좋습니다. (직위와 관계 없이). 그래야 상위 기능이 하위 기능으로부터 접근 권한을 상속받을 수 있습니다.

이 대안적인 역할 계층은 직위(Position)에 관계없이 기능(Fuction)이 우월한 경우 한 역할이 다른 역할보다 우월한 것으로 정의됩니다. 더 공식적으로:

역할(x) > 역할(y) ⇔ 역할(x).기능 > 역할(y).기능

 

3.1.3 토론
은행에서 상속 구조를 사용할 때의 장단점을 논의할 때 고려해야 할 몇 가지 문제가 있습니다.
(a) 역할 계층의 선택
(b) 다른 조직 요구와 역할 계층의 호환성
(c) 세분화된 접근 제어
(d) 업무의 분리 및 기타 통제 원칙

(a) 역할 계층의 선택

실용적인 이유로 은행은 역할 계층 구조에 대해 한 가지만 선택해야 합니다(RBAC96 모델은 다중 계층 구조를 허용하지만). 우리는 위에서 두 명의 후보자를 언급했습니다.

• 매칭 기능이 있는 직위(Position) 계층(3.1.1)
• 직무 (Fuction) 계층(3.1.2)

우리는 대부분 어떤 조직이 최선의 선택인지 알 만큼 조직에 대한 충분한 지식이 없음에 따라, 조직의 접근 제어 구조를 자세히 연구하고 각 경우에서 얻은 단순화와 바로 아래에서 논의할 다른 문제에 특히 주의를 기울일 필요가 있습니다.

(b) 역할 계층과 다른 조직 요구의 호환성

 충돌이 발생할 수 있으므로 기존 조직 계층을 단순히 선택하여 RBAC 시스템으로 가져오는 것이 불가능하다는 것이 인식되었습니다. 위의 예(섹션 3.1.1)에서 역할 계층에 대해 동일한 직무(Function)가 있는 직위(Position) 계층을 사용하면 그룹 관리자에 대한 접근 권한 테이블이 단순화됩니다. 그러나 이것이 사업부장에게도 적합한지 여부는 알 수 없습니다.

아마도 접근 권한 상속으로 인해 해당 사용자에게 자신의 작업을 수행하는 데 필요한 것보다 더 많은 권한을 부여하여 최소 권한 원칙을 위반할 수 있습니다.

이러한 종류의 문제를 해결하려면 RBAC96 모델에서 제안된 개인 역할 개념을 사용하여 원래 계층 구조와 호환되지만 동일하지 않은 계층 구조를 생성해야 할 수 있습니다.

(b) 세분화된 접근 제어 (Fine grained access control)
접근 권한 상속을 도입한 후 재무 분석가/서기(financial analyst/Clerk)에게는 필요하지만 재무 분석가/그룹 관리자(financial analyst/Group Manager) 역할에는 필요하지 않은 접근 권한이 있는 것으로 판명되면 전체 또는 부분적으로 이 부분을 분해해야 합니다. 역할 계층.

부정적인 권리는 아래쪽으로 상속되기 때문에 RBAC 모델에서는 우월한 직위에 부정적인 권리를 부여하는 것만으로는 문제를 해결할 수 없습니다

다. 직무의 분리
접근권한 상속은 업무분장 원칙에 위배될 수 있습니다. 예를 들어, 프로젝트 관리자가 시니어 프로그래머로부터 저장소를 읽을 수 있는 권한을 상속받는 것은 바람직하지 않습니다. 프로젝트 관리자는 반드시 기술 지식이 있는 것은 아니며 수석 프로그래머가 릴리스하기 전에 액세스할 수 있는 경우 잘못된 코드를 배송하는 것을 고려할 수 있습니다.

우리는 <표 2>의 사례에서 은행이 엄격한 내부통제 절차를 갖고 있기 때문에 업무분장 충돌을 피했음을 확신할 수 있다. 접근 권한 상속이 도입된다면 은행은 이러한 종류의 충돌이 발생하지 않도록 권한 테이블을 자세히 재검토해야 할 것입니다. 이것은 상속이 도입될 수 있는 범위를 심각하게 제한할 가능성이 있습니다.

3.1.4 장점과 단점
우리는 지식도 권한도 없기 때문에 이 특정한 경우에 대해 어떤 결론에 도달할 수 없습니다. FUB에 대한 역할 계층 도입에 찬성하는 것은 이것이 가져올 접근 권한의 경제입니다. 그러나, 우리는 이러한 이점을 감소시키는 여러 요소를 지적했으며 결정에 도달하기 전에 자세히 검토해야 합니다.

 

3.2 그룹화 (Grouping)

섹션 2.6.2에서 언급했듯이 은행은 직원 그룹화 메커니즘 도입을 고려하고 있습니다. 그룹화 메커니즘은 각 개인이 아닌 역할에 그룹만 할당하면 되므로 관리가 용이합니다.

RBAC96 모델에서는 역할에 그룹 할당을 허용하지 않습니다. 역할에 대한 사용자 할당은 (개별) 사용자와 역할 간의 관계임을 명시적으로 명시합니다. 그러나, RBAC에 대한 다른 접근 방식으로 역할 정의의 기초로 그룹을 사용하거나, 도메인의 개념을 통해 사용자를 그룹화하는 메커니즘을 제공하는 데 사용할 수 있습니다.

4. 결론

4.1 FUB 시스템
이 문서에서는 역할 기반 접근 방식을 사용하여 사용자가 애플리케이션 도메인 내에서 소유한 접근 권한을 결정하는 주요 유럽 은행의 접근 제어 시스템에 대한 사례 연구를 제공했습니다. 이 시스템에서 역할은 조직 내 기능(Fuction)과 직위(Position)에 의해 정의됩니다.

이 접근 제어 시스템은 인사 시스템 데이터베이스와 밀접하게 연결되어 있어 특정 조직 변화에 유연하게 대처할 수 있으며, 전사적 조직 수준에서 작동하므로 서로 다른 플랫폼의 다양한 어플리케이션들에 대해 서비스를 제공합니다.

우리는 10년 넘게 사용되어 온 시스템에서 구체적인 역할(Role) 수를 지정했으며, 이 수치는 도구 개발자에게 도구가 실제 조건에서도 작동한다는 추가 증거를 제공할 수 있는 기회를 제공해야 합니다.
또한, 상속 문제에 대한 논의를 하였고, 직위(Position)에 따라 발생하는 상속과 기능(Function) 간 상속에 대하여 차이점을 구분했습니다.

4.2 RBAC 모델
이 사례 연구는 역할기반 접근제어(RBAC) 모델에 대한 몇 가지 사항을 제시했습니다.

우선, 역할기반 접근제어 (RBAC) 모델과 높은 수준의 호환성을 가진 크고 실제적인 시스템이 존재하기 때문에 역할 기반 접근 제어 접근 방식에 대한 근본적인 정확성에 대해 더 확신할 수 있게 되었습니다.

그러나, 표준화에 의해 "고정"되기 전에 고려해야 하는 RBAC 모델의 한계가 있습니다.

 

• 상속 메커니즘과 제어 원칙, 특히 직무 분리의 잠재적 충돌은 역할 계층 사용에 장애물을 만듭니다. 이를 해결하기 위한 한 가지 접근 방식은 제약 조건을 RBAC 모델에 통합하는 것입니다. 

• 다루기 쉬운 RBAC 모델의 또 다른 측면은 역할을 할당할 수 있는 사용자 그룹을 정의하기 위한 메커니즘을 도입해야 한다는 것입니다.