KR100399581B1 - 액션을 이용한 역할 기반 접근 제어 방법 - Google Patents

Abstract

본 발명은 계층적 구조를 갖는 시스템에 적용할 수 있는 액션을 이용한 확장된 역할 기반 접근 제어 방법에 관한 것이다.

본 발명은, 특정 객체에 접근하고자 하는 사용자에 대한 접근 제어 방법에 있어서, 사용자가 특정 클래스에 속한 특정 객체에 대하여 특정 액션 수행을 요구하면, 상기 사용자가 속한 모든 역할들을 포함하는 역할집합과, 상기 역할집합내의 각 역할들에 속한 권한들을 포함하는 권한집합과, 상기 권한집합내의 각 권한들에 속한 모든 액션들을 포함하는 액션집합을 각각 생성하고, 사용자가 요구한 특정 액션이 상기 액션집합에 포함되는지 확인하여, 포함되면 상기 권한집합에 포함된 각 권한에 할당된 모든 클래스들을 포함하는 클래스 집합을 생성한 다음, 사용자가 요구한 특정 클래스가 상기 클래스집합에 포함되는지 확인한다. 이 후, 상기 특정 클래스가 상기 클래스 집합에 포함되면 상기 사용자의 접근을 허락하고, 상기 특정 클래스가 상기 클래스 집합에 포함되지 않으면 상기 권합집합의 각 권한에 할당된 모든 객체들을 포함하는 객체집합을 생성한 후, 사용자가 요구한 특정 객체가 상기 객체 집합에 포함되는지 확인한다. 확인 결과, 상기 특정 객체가 상기 객체집합에 포함되면 상기 사용자의 접근을 허락하고, 상기 특정 액션이 상기 액션집합에 포함되지 않거나, 상기 특정 객체가 상기 객체집합에 포함되지 않으면 사용자의 접근을 거부한다.

이로 인해, 권한에 적용될 객체를 클래스와 액션이라는 개념을 통해 일반화함으로써, 대규모 기업환경에 적용할 수 있다.

Description

액션을 이용한 역할 기반 접근 제어 방법 {Role-Based Access Control Method using Actions}

본 발명은 액션(action)을 이용한 역할 기반 접근 제어 방법에 관한 것으로서, 보다 상세하게 설명하면, 권한(permission)에 적용될 객체(object)를 클래스(class) 및 액션(action)이라는 개념을 통해 일반화함으로써, 대규모 기업 환경 및 계층적 구조를 갖는 시스템에 적용할 수 있는 액션(action)을 이용한 역할 기반 접근 제어 방법에 관한 것이다.

접근 제어(Access Control)란, 특정 시스템 내의 접근 제어 정책에 따라, 시스템 내의 객체에 접근하고자 하는 사용자에게 객체(object)에 대한 허가된 접근을 허용하는 것을 말한다. 이러한 접근 제어 방식에는 미 국방성에서 사용하는 객체의 소유자가 해당 객체에 대한 다른 사용자의 접근 여부를 임의로 결정하는 임의 접근 통제(Discretionary Access Control; DAC)방식, 사용자와 객체를 보안 등급에 따라 분류하고 이를 기반으로 접근 제어를 실행하는 강제적 접근 제어(Mandatory Access Control; MAC)방식, 1970년대 멀티 유저(Multi-user)와 멀티 어플리케이션(Multi-application) 환경에서의 보안 처리 요구를 만족시키기 위해 제안된 방법으로 사용자와 객체 사이에 역할(role)이라는 개념을 제공하여 이를 통해 접근 제어를 하는 역할 기반 접근 제어 방식(Role-Based Access Controlling Method)등이 있다.

이 중, 강제적 접근 제어 방식은 시스템 내에 있는 객체와 이에 접근하고자하는 사용자(혹은 주체)에게 부여된 보안 등급(security level)에 기본을 두고 있다. 객체에 부여된 보안 등급은 해당 객체가 포함하고 있는 정보의 중요도 및 해당 정보가 누출되었을 시 발생하는 피해 정도에 따라 설정되며, 사용자에 부여된 보안 등급은 해당 사용자가 민감한 정보에 접근하는데 있어서의 신용 정도를 나타낸다.

예를 들어, 미 국방부 경우의 보안 등급은 크게 Top Secret(매우 중요 : TS), Secret(중요 : S), Confidential(보통 : C), Unclassified(보안없음 : U)이라는 네 등급으로 분류하며, 이들 간의 관계는 TS > S > C > U 이다. 또한, 사용자가 객체에 대해 접근하려고 할 때에는 다음과 같은 조건이 만족되어야 접근이 가능하다.

·조건 1(Read down) : 사용자의 보안 등급이 읽고자 하는 객체의 보안 등급보다 높거나 같은 경우 읽기(read) 연산 허용된다.

·조건 2(Write up) : 사용자의 보안 등급이 쓰고자 하는 객체의 보안 등급보다 낮은 경우 쓰기(write) 연산 허용된다.

위의 두 조건은 보안 수준이 높은 객체의 정보가 보안 수준이 낮은 객체로 전이되는 것을 방지하기 위한 것이다. 이와 같은 특징들을 포함하는 강제 접근 방식은 구현이 쉬운 반면, 객체에 대한 효과적인 제어가 어렵다는 단점이 있다.

한편, 임의 접근 제어 방식은 사용자의 식별자(Identity)와 해당 사용자가 접근할 수 있는 객체와 접근 방식(access mode)을 명시한 권한(Authorization)에 기초를 두고 있다. 사용자가 객체에 접근하려고 할 때 해당 사용자에게 미리 정의된 권한 집합이 검사된다. 미리 정의된 권한 집합 내에 주어진 객체에 대한 사용자의 액세스가 허가되어 있으면 주어진 객체에 대한 액세스가 허가되며, 그렇지 않으면 거부된다. 임의 접근 제어 방식은 접근 제어에 유연성을 제공하는 반면, 자원에 대한 접근 제어가 원래의 시스템 관리자의 의도와 상반될 수 있다.

마지막으로, 역할 기반 접근 제어 방식은 사용자와 객체 사이에 역할이라는 개념을 추가한 것이다. 이 때의 역할이란, 사용자가 수행해야 할 업무 혹은 직무를 나타낸다.

즉, 대규모의 기업 환경에서 각 사용자는 역할에 의해 구분되며, 역할에 따라 접근이 허용되는 데이터도 다르게 되는데, 각 사용자에게는 하나 이상의 역할이 할당된다. 이러한 역할 기반 접근 제어 방식은 사용자와 객체 사이에 역할이라는 개념을 도입함으로써, 사용자의 역할에 쉽게 대응할 수 있을 뿐만 아니라, 그에 따라 권한 관리도 쉬워진다.

또한, 기업의 업무 프로세스를 위한 소프트웨어를 개발할 경우, 다양한 형태의 접근 제어가 요구된다. 즉, 팀장의 역할을 수행하는 사람은 해당 팀원의 인사 고과 문서를 보거나 수정할 수 있으며, 팀원은 해당 문서를 볼 수 없다는 식의 요구 사항이 발생하게 된다. 이러한 접근 제어 관련 요구 사항은 소프트웨어 개발 전 뿐만 아니라 소프트웨어를 사용하는 과정에서 수시로 변하게 되므로, 이러한 작업을 효율적으로 수행하기 위해서는 사용자 및 사용자가 접근하는 객체에 대한 동적인 접근 제어가 요구된다.

이와 같은 특징을 포함하는 접근 제어 방식에 대해, 예를 들어 설명하면 다음과 같다.

사용자 명	접근 가능 객체	수행 가능한 액션
길동	인사관리 문서	읽기, 수정
철수	인사관리 문서	읽기, 수정
영이	근태관리 문서	읽기, 수정
영미	근태관리 문서	읽기, 수정

위와 같은 [표 1]은 각 사용자 별로 해당 사용자가 읽거나 혹은 수정할 수 있는 문서에 대한 정보를 기록하여 접근 제어에 이용하는 방식으로서, 이러한 방식은 해당 사용자가 다른 업무를 수행하는 경우, 그 사용자에 대한 접근 제어 정보를 모두 지우고 새로운 업무에 맞는 접근제어 정보를 다시 입력해 주어야 한다. 또한, 위의 예제에서 길동과 철수 사용자처럼 사용자의 업무가 같은 경우 두 사용자에 대한 똑같은 접근 제어 정보를 저장해야만 한다. 이러한 단점을 보완하기 위해 역할 기반 접근제어 방식이 도입되었는데, 예를 들어 설명하면 다음과 같다.

역할명	접근가능객체	수행 가능한 액션	사용자
인사관리	인사관리 문서	읽기, 수정	길동, 철수
근태관리	근태관리 문서	읽기, 수정	영이, 영미

위와 같이, 인사관리 및 근태관리라는 역할에 접근 가능한 객체인 인사관리문서 또는 근태관리 문서에 대한 수행 가능한 액션을 할당한 다음 해당 역할을 수행하는 사람을 할당하는 형식이다. 만약, 길동과 영이의 역할이 바뀌게 되면, 인사관리라는 역할에서 길동을 제거하고 근태관리라는 역할에 추가하며, 근태관리라는 역할에서 영이를 삭제한 후, 인사관리라는 역할에 영이를 추가하면 된다.

즉, 역할 기반 접근 제어 방식은 어떤 조직내에서 어떤 역할을 담당하는 담당자는 수시로 바뀌지만, 그 역할 자체가 쉽게 변하지 않는 경우에 자주 사용되며, 일반적으로, 사용자, 역할, 액션(또는 권한, 권한) 및 객체(예를 들어, 관련 문서파일)와 같은 구성요소로 이루어진다.

다른 종래 기술로는, 저자가 Ravi Sandhu, Edward Coyne, Hal Feinstein Charles Youman인 [논문제목 : Role-Based Access Control Models, 게제지 : IEEE Computer, Volume 29, Number 2, 발표년도 : 1996년]의 논문이 있다. 이는, 역할 기반 접근 제어의 기본 구성 요소와 확장된 요소 및 이들 간의 관계를 기술한 것으로써, 기존에 알려진 역할 기반 접근 제어 방법을 체계적으로 분석하였다.

상기한 종래 기술의 문제점을 해결하기 위한 본 발명의 목적은 권한에 적용될 객체를 클래스 및 액션이라는 개념을 통해 일반화함으로써, 대규모 기업 환경에 용이하게 적용할 수 있을 뿐만 아니라, 이러한 권한 개념을 기반으로 한 역할 기반 접근 제어 방법을 대규모 시스템 내에서 효과적으로 사용할 수 있는 액션을 이용한역할 기반 접근 제어 방법을 제공하기 위한 것이다.

도 1은 기본적인 역할 기반 접근 제어 방법을 개략적으로 설명하기 위한 도면,

도 2는 역할의 계층 구조를 포함하는 역할 기반 접근 제어 방법을 개략적으로 설명하기 위한 도면,

도 3은 본 발명의 일 실시예에 따른 액션을 이용한 역할 기반 접근 제어 방법을 설명하기 위한 도면,

도 4는 본 발명에 따른 액션을 이용한 역할 기반 접근 제어 알고리즘을 설명하기 위한 도면이다.

※ 도면의 주요 부분에 대한 부호의 설명 ※

310 : 사용자(user) 320 : 역할(role)

330 : 권한(permission) 340 : 객체(object)

350 : 액션(action) 360 : 클래스(class)

상기한 목적을 달성하기 위한 본 발명은 특정 객체에 접근하고자 하는 사용자에 대한 접근 제어 방법에 있어서, 사용자가 특정 클래스에 속한 특정 객체에 대하여 특정 액션 수행을 요구하면, 상기 사용자가 속한 모든 역할들을 포함하는 역할집합을 생성하는 제1 단계; 상기 역할집합내의 각 역할들에 속한 권한들을 포함하는 권한집합을 생성하는 제2 단계; 상기 사용자의 허가된 권한들로만 이루어진 상기 권한집합내의 각 권한들에 속한 모든 액션들을 포함하는 액션집합을 생성하는 제3 단계; 상기 제1 단계에서 사용자가 요구한 특정 액션이 상기 액션집합에 포함되는지 확인하는 제4 단계; 상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되면, 상기 권한집합에 포함된 각 권한에 할당된 모든 클래스들을 포함하는 클래스 집합을 생성하는 제5 단계; 상기 제1 단계에서 사용자가 요구한 특정 클래스가 상기 클래스집합에 포함되는지 확인하는 제6 단계; 상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되면 상기 사용자의 접근을 허락하는 제7 단계; 상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되지 않으면 상기 권합집합의 각 권한에 할당된 모든 객체들을 포함하는 객체집합을 생성하는 제8 단계; 상기 제1 단계에서 사용자가 요구한 특정 객체가 상기 객체 집합에 포함되는지 확인하는 제9 단계; 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되면 상기 사용자의 접근을 허락하는 제10 단계; 및 상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되지 않거나, 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되지 않으면 상기 사용자의 접근을 거부하는 제11 단계를 포함한다.

양호하게는, 본 발명은 컴퓨터에서, 사용자가 특정 클래스에 속한 특정 객체에 대하여 특정 액션 수행을 요구하면, 상기 사용자가 속한 모든 역할들을 포함하는 역할집합을 생성하는 제1 단계; 상기 역할집합내의 각 역할들에 속한 권한들을 포함하는 권한집합을 생성하는 제2 단계; 상기 사용자의 허가된 권한들로만 이루어진 상기 권한집합내의 각 권한들에 속한 모든 액션들을 포함하는 액션집합을 생성하는 제3 단계; 상기 제1 단계에서 사용자가 요구한 특정 액션이 상기 액션집합에 포함되는지 확인하는 제4 단계; 상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되면, 상기 권한집합에 포함된 각 권한에 할당된 모든 클래스들을 포함하는 클래스 집합을 생성하는 제5 단계; 상기 제1 단계에서 사용자가 요구한 특정 클래스가 상기 클래스집합에 포함되는지 확인하는 제6 단계; 상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되면 상기 사용자의 접근을 허락하는 제7 단계; 상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되지 않으면 상기 권합집합의 각 권한에 할당된 모든 객체들을 포함하는 객체집합을 생성하는 제8 단계; 상기 제1 단계에서 사용자가 요구한 특정 객체가 상기 객체 집합에 포함되는지 확인하는 제9 단계; 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되면 상기 사용자의 접근을 허락하는 제10 단계; 및 상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되지 않거나, 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되지 않으면 상기 사용자의 접근을 거부하는 제11 단계를 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체가 제공된다.

본 발명에 따른 액션을 이용한 역할 기반 접근 제어 방법에 대해 언급하기에 앞서, 본 발명에서 중요시되는 액션(action)이란 개념에 대해 알아보면 다음과 같다.

종래 기술에 따른 역할 기반 접근 제어 방식은 역할이라는 개념에 중점을 두었으며, 각 객체에 수행하는 액션은 소홀히 하였다. 하지만, 최근 들어 사용자가 접근하는 객체의 종류는 일반 문서에서 기업 내부의 데이터베이스에 저장되어 있는 인사관리 정보 및 개인 정보에 이르기까지, 점점 더 다양화되어 가고 있을 뿐만 아니라, 그로 인한 액션의 종류 또한 점점 더 다양해지고 있다.

이와 같은 특징의 액션에 대해, 기업 내 문서관리 시스템의 여러 객체와 해당 객체 상에서 이루어 질 수 있는 액션들을 예를 들어 설명하면 아래와 같다. 기업 내의 문서관리 시스템은 해당 문서들을 마이크로소프트사의 윈도우98과 같은 폴더라는 형태로서 체계적으로 관리하며, 이러한 폴더 내에 해당 문서들이 보관된다. 보관된 문서들은 특정 권한이 있는 사용자만이 조회나 수정, 삭제 등이 가능하며, 문서 수정시, 타 사용자의 동시 수정을 방지하기 위해 체크아웃이라는 액션을 수행해야 한다. 또한, 특정 문서에 자신의 의견을 기재한다거나, 문서를 승인하는 액션도 존재할 수 있으며, 이러한 액션은 기업의 문서관리 시스템에 따라 다를 뿐만 아니라, 프로그램의 운영 중에도 변경될 수 있다. 아래의 [표 3]은 기업 내 문서관리 시스템에서의 접근 제어 방식에 따른 객체 및 그에 따른 액션을 분류한 것이다.

객체 클래스 명	액션	기타
문서 폴더 정보	조회, 수정, 삭제, 변경요청
문서	조회, 수정, 삭제, 체크 아웃, 체크 인,의견달기, 문서승인

위와 같은 액션별 분류로 인해, 사용자의 특정 객체에 대한 액션 수행시, 위의 정보를 통해 접근 가능 여부를 판단하면 된다.

이하 첨부된 도면을 참조하면서 본 발명의 일 실시예에 따른 액션을 이용한 역할 기반 접근 제어 방법을 보다 자세하게 설명하기로 한다.

도 1은 일반적인 역할 기반 접근 제어 방법을 개략적으로 설명하기 위한 도면으로서, 사용자(User, 110), 역할(Role, 120), 권한(Permission, 130)간의 관계를 이용한 접근 제어 방법을 특징으로 한다.

사용자(110)는 사람 또는 사람 역할을 대행하는 시스템 내의 에이전트(agent)이며, 역할(120)은 해당 역할에 속하는 사용자들에게 할당된 직무 또는 업무이며, 권한(130)은 해당 객체에 대한 접근 권리(Access rights) 및 특권(Privilege)으로서, 시스템 내의 하나 또는 그 이상의 객체에 대한 접근 모드의 승인 여부를 나타낸다.

이와 같은 특징을 포함하는 일반적인 역할 기반 접근 제어 방법에 대해 설명하면 다음과 같다. 일반적인 역할 기반 접근 제어 방법은 사용자(110)를 해당 역할(120)에 할당하는 사용자 할당(User Assignment : UA)과 권한(130)을 역할(120)에 할당하는 권한 할당(Permission Assignment : PA)이라는 두 개의 관계(Relation)를 특징으로 한다. 이 때, 한 사용자(110)는 다양한 역할(120)을 가질 수 있으며, 하나의 역할(120) 역시, 여러 사용자(110)를 포함할 수 있다. 또한, 하나의 역할(120)은 여러 권한(130)을 가질 수 있으며, 동일한 권한이 여러 역할에 할당될 수도 있다.

이와 같은 특성을 특징으로 하는 구성 요소간의 포함 관계에 대해 언급하기에 앞서, 본 발명에서 사용하는 기호 및 구성 요소에 대해 간단히 언급하면 다음과 같다.

U는 사용자이며 R은 역할, P는 권한, S는 어떤 기능(세션의 기본 기능)을 수행하는 세션을 의미하는 것으로서, 예를 들면, 사용자 U를 대신하여 현재 실행되고 있는 프로그램 등을 의미한다.

위와 같은 구성요소간의 연결 관계 및 특징으로 설명하기 위한 기호에 대해 예를 들어 정리하면 다음과 같다.

집합 A={a1,a2}, B={b1,b2}가 있다고 할 때,

·∈ : 어떤 원소가 어떤 집합에 포함되는 것을 의미하는 것으로서, 예를 들면, a1은 집합 A의 원소이므로, al ∈ A 와 같이 나타낼 수 있다.

·⊆ 혹은 ⊇ : 집합간의 포함 관계를 나타내는 것을 의미하는 것으로서, 예를 들면, 집합 C = {a1}라고 하면 집합 C는 집합 A에 포함되므로, C ⊆ A 혹은 A ⊇ C 와 같이 나타낼 수 있다.

·× : 두 집합을 이용하여 두 집합내 원소의 쌍으로 이루어진 새로운 집합을 의미하는 것으로서, 예를 들면, A ×B = {(a1,b1),(a1,b2),(a2,b1),(a2,b2)}가 된다. 또한, 이 기호는 두 집합간의 관계(Relation)를 나타내는 데 사용된다.

·∃ : 이 기호는 집합 내 원소의 존재 유무를 나타내는 기호로서, 예를 들면, ∃a1∈A 이면, a1이라는 원소가 집합 A에 존재하므로 참이 되며, ∃b1∈A 는 거짓이 됨을 의미한다.

위에서 언급한 구성 요소 및 그들간의 연결관계에 대해 예를 들어 설명하면다음과 같다.

·PA ⊆ P×R : 권한(P)을 역할(R)에 할당하기 위한 관계로서, 예를 들면, PA = {('파일 A 읽기','과장')} 이면, '과장'이라는 역할이 '파일 A 읽기' 라는 권한과 관계를 가진다는 의미이며, 이때, P×R은 권한과 역할간에 맺을 수 있는 모든 관계를 포함하는 집합을 나타낸다.

·UA ⊆ U×R : 사용자(U)를 역할(R)에 할당하기 위한 관계로서, 예를 들면, UA = {('홍길동','과장')}이면, '홍길동'이라는 사용자가 '과장'이라는 역할과 관계를 가진다라는 의미이며. 이때, U×R은 사용자와 역할간에 맺을 수 있는 모든 관계를 포함하는 집합을 나타낸다.

·사용자(user) : S->U, 세션(s)을 사용자에게 할당하기 위한 함수로서, user(s)와 같이 표현한다.

·역할(roles) : S->2^R, 각 세션 s를 역할의 집합,role(s)⊆{r|(user(s),r) ∈UA}에 할당하기 위한 함수로서, 세션 s의 권한 집합은 U_r∈roles(s){p|(p,r)∈PA}가 된다. 사용자들은 해당 시스템을 여러 번 사용할 수 있는데, 그때마다 해당 시스템으로부터 새로운 세션을 할당받게 된다. 일반적으로, 할당받게 되는 세션은 사용자가 가지고 있는 역할에 따라 접근 권한이 제어되지만, 다수의 역할(예를 들어, 과장이면서 팀리더인 경우)을 수행하는 사람이 시스템을 사용할 경우, 특정 세션이 할당되고 해당되는 세션에 그 사람의 역할 모두를 사용하는 경우와 특정 역할만 사용하게 하는 경우가 있다. 즉, 해당 세션에 할당된 역할이 해당 세션을 가진 사용자에 할당된 역할과 동일할 수도 있으며, 그 역할의 일부분일 수 있다. 이를 표현하기 위해 role(s)라는 세션과 역할과의 관계 집합이 사용된다. 또한, 해당 세션에 부여된 권한을 얻기 위해 해당 권한에 할당된 역할을 구하고 이 역할에 할당된 권한을 구해야 한다. 이를 표현한 수식이 U_r∈roles(s){p|(p,r)∈PA}에 해당되면, r∈roles(s)은 세션 s에 포함된 역할을 의미하며, {p|(p,r)∈PA}은 해당 역할에 포함된 권한 p로 이루어진 집합을 의미한다.

도 2는 역할의 계층 구조를 포함한 역할 기반 접근 제어 방법을 개략적으로 도시한 도면으로서, 도 1에 비해, 역할의 계층적 구조를 포함한다.

역할의 계층 구조(Role Hierarchy, 250)란, 역할(220)들간의 관계를 계층적으로 표현한 것으로서, 상위의 역할이 하위의 역할에 속해 있는 권한을 상속받는 것을 특징으로 하며, 이러한 특징을 포함하는 역할 기반의 계층구조는 수학적으로 부분순서 관계를 이룬다. 이때의 부분순서 관계란, 쉽게 설명하면 자연수 1,2,3,..과 같이 한 방향으로만 순서가 있는 관계를 의미하는데, 즉, (1,2)란 관계는 1<2<3라는 순서를 이루지만 1>2라는 순서 관계는 이루지 못한다. 역할 기반 계층 구조 역시, 상위 노드가 있고 그것에 대한 자식들이 있는 트리 구조로 되어 있다는 것을 의미한다.

위와 같은 특징의 역할 기반 계층 구조에 대해, 간단히 언급하면 다음과 같다.

·RH⊆R ×R : 역할의 계층 관계를 나타낸 것으로서, 부분 순서 관계를 이루고 있으며, ≥으로 표시한다. 예를 들어 설명하면, 역할의 계층구조란, 역할을 분류하기 위한 구조로서, 사장 -> 부장 -> 과장 -> 대리 -> 평사원과 같은 역할 기반의 계층 구조가 있는데, 이중, 사장이라는 역할은 부장이나 과장, 대리 및 평사원보다 상위의 역할로 분류될 뿐만 아니라, 사장 이하의 역할이 가지는 권한들을 모두 가질 수 있다는 것을 의미한다.

·역할(roles) : S -> 2^R, role(s)⊆{r|(∃r'≥r) [user(s),r')∈UA]}, 이 때, 세션 s의 권한 집합은 U_r∈roles(s){p|(∃r"≥r)[(p,r")∈PA]}가 된다.

여기서, role(s)⊆{r|(∃r'≥r) [user(s),r')∈UA]}은 특정 세션을 가지고 있는 사용자(user(s))에 할당된 역할(r')을 포함한 역할, r'의 모든 하위 역할(r)들로 구성된 집합을 의미하며, U_r∈roles(s){p|(∃r"≥r)[(p,r")∈PA]}은 앞에서 구한 role(s)에 포함된 모든 역할에 할당된 권한((p,r")∈PA)들로 이루어진 집합을 의미한다. 예를 들어 '사장-부장-과장-대리-평사원'의 역할기반 계층구조가 있고, 홍길동이 '부장'이라는 역할을 가지고 어떤 시스템을 사용하고자 할 때, 홍길동에게는 특정 세션 s가 할당되며, 해당 세션 s는 '부장'이라는 역할을 갖게 된다. 이때, role(s)는 '부장' 뿐만 아니라, 부장이 포함한 모든 하위 역할{'부장','과장','대리','평사원'}을 포함하게 되고, 이는 결국, 홍길동이라는 사람은 역할 role(s)내에 할당된 모든 권한을 갖게 된다.

한편, 기업 내에서는 위에서 언급한 문서관리 시스템뿐만 아니라, ERP(Enterprise Resource Planning : 전사적 자원 관리)시스템 등과 같은 많은 시스템들이 운용되고 있으며, 이로 인해, 이들 시스템들이 운용 관리하는 데이터 역시 방대하다. 또한, 기업 특성상 자료에 대한 접근 정책이 수시로 변할 수 있으며, 자료의 특성이 변화하여 자료상에서 수행될 수 있는 액션도 변화될 수 있다.

이로 인해, 본 발명에 따른 액션을 이용한 역할 기반 접근 제어 방법은 기존의 역할 기반 접근 제어 방법을 사용자, 역할, 권한, 액션, 클래스 및 객체의 개념으로 확장하였으며, 기존에 소홀히 다루어졌던 권한(permission)을 클래스와 액션이라는 개변을 통해 체계적으로 분류 및 활용한다.

도 3은 본 발명에 따른 액션을 이용한 역할 기반 접근 제어 방법을 설명하기 위한 도면으로서, 도시된 바와 같이, 사용자(User, 310), 역할(Role, 320), 권한(Privilege, 330), 객체(Object, 340), 액션(Action, 350), 클래스(Class, 360) 및 이들간의 포함관계를 특징으로 한 접근 제어 방법이다.

객체(340)는 시스템 내 접근 제어의 대상이 되는 객체로서, 다양한 종류들이 있으며, 그러한 여러 종류들 중, 유사한 객체들의 모임이 하나의 클래스(360)가 된다. 각 클래스에는 적용 가능한 액션(혹은 오퍼레이션, 350)이 존재하며, 권한(330)은 그러한 액션들(350)의 집합으로서, 어떤 클래스에 어떠한 액션이 가능한지를 나타낸다.

사용자(310)는 시스템을 사용하는 일반사용자 혹은 사용자를 대행하는 시스템 내의 에이전트이며, 역할(320)은 상기 역할(320)에 포함되는 사용자(310)가 행하는 직무 또는 업무를 대표하는 개념이다. 역할(320)은 권한(330)과 상기 권한(330)에 포함된 액션(350)을 수행할 객체(340)와의 관계를 표현한 것이다.

이 때, 특정 역할에 포함된 사용자(310)는 상기 특정 역할에 포함된 객체(340)에 대해서도 특정한 권한(330)을 가진다.

권한(330)은 특정 액션들로 구성되며, 이는, 해당 액션들을 수행할 수 있는 능력을 의미한다. 액션(350)은 특정 객체 혹은 클래스 상에 수행될 수 있는 행위를 의미하는데, 여기서, 클래스 상에 정의된 액션은 해당 클래스에 속하는 모든 객체에 대해 수행 가능한 액션을 의미한다.

이와 같은 특징을 기반으로 한 구성요소간의 포함 관계 및 특성에 대해 알아보면 다음과 같다.

·RU(Role User Relation : 역할과 사용자간의 관계)⊆R×U : 역할(R)을 사용자(U)에게 할당하기 위한 관계로서, 예를 들면, RU = {('과장','홍길동')}이면, '과장' 이라는 역할이 '홍길동'이라는 사람과 관계를 가진다라는 것이며, 이때, R×U는 역할과 사용자간에 맺을 수 있는 모든 관계를 포함하는 집합을 나타낸다.

·PR(Privilege Role Relation : 권한과 역할과의 관계)⊆P×R : 권한(P)을 역할(R)에 할당하기 위한 관계로서, 예를 들면, PR = {('파일 관리 권한','과장')} 이면, '과장'이라는 역할이 '파일관리권한'이라는 권한을 가진다라는 것이며, 이때, P×R은 권한과 역할간에 맺을 수 있는 모든 관계를 포함하는 집합을 나타낸다.

·AP(Action Privilege Relation : 액션과 권한과의 관계)⊆A×P : 액션을 권한에 할당하기 위한 관계로서, 예를 들면, AP = {('읽기','인사문서읽기권한')} 이면, '인사문서읽기권한'이라는 권한이 '읽기'라는 액션과 관계를 가진다라는 것이며, 이때, A×P은 액션과 권한간에 맺을 수 있는 모든 관계를 포함하는 집합을 나타낸다.

·OC(Object Class Function : 객체와 클래스간의 함수) , O -> C : 특정 객체와 그 객체의 클래스(타입)를 매핑하는 함수로서, 특정 객체가 속한 클래스를 반환하는 함수이다.

·PC(Privilege Class Function : 권한과 클래스간의 함수) , P -> C : 클래스(객체 타입)를 권한에 할당하기 위한 함수로서, 예를 들면, AP={('파일 관리 권한','읽기'), ('파일 관리 권한','쓰기')}, PR = {('파일 관리 권한','과장')}, PC = {('파일 관리 권한','파일')}이면, '과장'이라는 역할이 '파일'이라는 클래스에 속하는 모든 파일 객체에 대해 읽기 및 쓰기가 가능하다는 것을 의미한다.

·AC(Action Class Relation : 액션과 클래스간의 관계), A×C : 특정 액션이 수행될 수 있는 클래스를 나타내기 위한 관계에 대한 것으로서, 예를 들면, AC = {('조회','문서'),('수정','문서'),('의견달기','문서')}이면, '문서'라는 클래스에 행할 수 있는 모든 액션을 나열한 것이다.

·OP(Object Privilege Relation : 객체와 권한과의 관계)⊆O×P, where (o,p)∈OP ⇒∃c∈C [(a,p)∈AP and(a,c)∈AC and OC(o) = c] : 객체를 권한에 할당하기 위한 관계로서, 이러한 관계를 만족하기 위해서는 권한에 포함된 액션이 권한에 할당되는 객체의 클래스상에 수행 가능해야 한다. 예를 들면, AP={('파일 관리 권한','읽기'), ('파일 관리 권한','쓰기')}, PR = {('파일 관리 권한','인사과장')}, OP = {('인사문서파일','파일 관리 권한')}이면, '과장'이라는 역할이 '파일'이라는 클래스에 속하는 '인사문서파일' 객체에 대해 읽기/쓰기가 가능하다는 것을 의미한다.

이와 같은 포함관계를 특징으로 하는 역할 기반의 접근 제어 방법에 대해 설명하면 다음과 같다. 즉, 한 사용자가 특정 객체에 대해 어떤 액션을 수행하려고할 때, 먼저 사용자가 속해 있는 역할에 할당된 권한과 그에 대응되는 객체를 가져온다. 이후, 가져온 정보를 이용하여 사용자가 주어진 객체에 접근 가능한지를 판단하게 되는데, 만약, 권한이 클래스에 할당되었다면, 그 클래스에 속하는 모든 객체에 주어진 액션이 수행 가능하게 된다. 이를 예를 들어 설명하면 다음과 같다.

클래스 집합(C) = {문서}

클래스와 액션과의 관계(AC) = {(문서,문서읽기), (문서,문서수정), (문서,문서의견달기), (문서,문서전체읽기), (문서,문서전체수정)}

참고적으로, 위의 클래스와 액션과의 관계에서 '문서전체읽기' 또는 '문서전체수정'이라는 액션은 '문서'라는 클래스에 속한 모든 객체에 대해 '읽기'나 '수정'이 가능한 액션을 나타낸다.

·객체와 클래스와의 관계(OC)= {(인사문서파일,문서)}

·권한 집합(P) = {문서전체읽기권한, 인사문서파일관리권한}

·액션과 권한과의 관계(AP) = {(문서전체읽기권한,문서전체읽기), (인사문서파일관리권한,문서읽기), (인사문서파일관리권한,문서수정)}

·권한과 클래스와의 관계(PC) = {(문서전체읽기권한,문서)}

·권한과 객체와의 관계(OP) = {(인사문서파일,인사문서파일관리권한), (인사문서파일,인사문서파일관리권한)}

·사용자 집합(A) = {홍길동, 김철수}

·역할과 사용자와의 관계(RU) = {(사장,홍길동), (인사과장,김철수)}

·권한과 역할과의 관계(PR) = {(문서전체읽기권한,사장), (인사문서파일관리권한,김철수)}

즉, '사장'이라는 역할을 가진 '홍길동'이라는 사용자는 '문서전체읽기권한'을 가지며, 따라서 '문서'라는 클래스에 속하는 모든 문서 객체('인사문서파일' 객체를 포함한)에 대해 읽기가 가능하다. 또한, '인사과장'이라는 역할을 가진 '김철수'라는 사용자는 '인사문서파일관리권한'을 가지며, 따라서 '문서' 클래스에 속하는 하나의 객체인 '인사문서파일'이라는 객체에 '읽기'와 '수정'이 가능하다. 만약, 인사 과장이 '김철수'라는 사용자에서 '김영이'라는 사용자로 변경되면, 권한과 역할과의 관계(PR)내 내용중, (인사문서파일관리권한,김철수)에서 (인사문서파일관리권한,김영이)로 수정하면 된다.

위와 같은 상황에서, 'DB'(Database : 데이터베이스)라는 새로운 형태의 클래스의 추가가 필요하고, 인사과장이 이 'DB' 클래스 내의 '인사DB'의 '읽기' 및 '쓰기' 액션을 수행해야 한다면, 위의 시스템은 '김철수' 라는 사용자가 새로운 형태의 문서인 '인사기록파일'에 대한 접근이 필요할 경우,

클래스 집합(C) = {문서, DB}

클래스와 액션과의 관계(AC) = {(문서,문서읽기),(문서,문서수정),(문서,문서의견달기),(문서,문서전체읽기),(문서,문서전체수정),(DB,DB생성), (DB,DB읽기), (DB,DB수정), (DB,DB전체생성),(DB,DB전체읽기), (DB,DB전체수정)}

객체와 클래스와의 관계(OC)= {(인사문서파일,문서), (인사DB,DB)}

권한 집합(P) = {문서전체읽기권한, 인사문서파일관리권한, 인사DB관리권한}

액션과 권한과의 관계(AP) = {(문서전체읽기권한,문서전체읽기), (인사문서파일관리권한,문서읽기), (인사문서파일관리권한,문서수정), (인사DB관리권한,DB생성), (인사DB관리권한,DB읽기), (인사DB관리권한,DB수정)}

권한과 클래스와의 관계(PC) = {(문서전체읽기권한,문서)}

권한과 객체와의 관계(OP) = {(인사문서파일,인사문서파일관리권한), (인사DB,인사DB관리권한)}

사용자 집합(A) = {홍길동, 김철수}

역할과 사용자와의 관계(RU) = {(사장,홍길동), (인사과장,김철수)}

권한과 역할과의 관계(PR) = {(문서전체읽기권한,사장), (인사문서파일관리권한,김철수), (인사DB관리권한,김철수)}

와 같은 데이터 변경을 통해, 해당 프로그램 수정 없이 새로운 형태의 클래스 및 객체에 대한 접근 제어를 수행 할 수 있다.

도 4는 본 발명에 따른 액션을 이용한 역할 기반 접근 제어 방법에 대해, 순차적으로 도시한 흐름도로서, 이를 상세히 설명하면 다음과 같다.

먼저, 역할 기반에 따른 접근 제어시 사용되는 일반적인 함수에 대해 알아보면 다음과 같다.

즉, 접근 제어시 사용되는 함수는 isAllowed(String userID, String objID,String objType, String actionID)와 같은 형태로서, 여기서의 userID는 사용자의 login ID 이며, objID는 사용자가 접근하려고 하는 객체의 ID, objType는 해당 객체의 타입(클래스) ID, actionID는 사용자가 해당 객체에 수행하려고 하는 액션의 ID이다.

이와 같은 형태의 함수가 의미하는 것은 "해당 사용자(userID)가 클래스 형태가 objType인 객체(objID)에 대해, 어떠한 액션(actionID)을 수행하려고 하는데 가능한가?"라는 의미를 내포한다. 예를 들면,

- isAllowed('tchan','123','1','22')

- userID : 'tchan'

- objID : '123' ( '매뉴얼'이라는 폴더 객체를 나타낸다고 하자)

- objType : '1' ('폴더'를 나타냄)

- actionID : '22' ('폴더 정보 수정' 액션을 나타냄)

상기와 같은 함수가 의미하는 것은 " 'tchan' 이라는 사용자가 '매뉴얼' 이라는 폴더의 정보를 수정하려고 하는데 가능한가?" 이다.

이와 같은 특징들을 포함하는 함수의 수행절차에 대해 간략히 설명하면 다음과 같다. 먼저, 해당 사용자의 역할리스트(해당 사용자에 속하는 역할들의 목록)에서 해당 객체(objType)에 해당되는 권한을 가져온 후, 클래스에 적용할 수 있는 액션을 비교하여 접근이 가능하면 해당 액션이 수행되는 반면, 접근이 가능하지 않으면, 해당 객체에 적용할 수 있는 액션을 비교하여 접근이 가능하면 해당 액션이 허가된다. 즉, 해당 클래스에 액션이 허가되면 그 클래스에 속하는 모든 객체에 대한 액션이 허가되므로 객체에 대한 액션 여부 검사를 수행하지 않는 반면, 해당 클래스에 대해 액션이 허가되지 않는 경우에만 해당 객체에 대한 액션 검사를 수행한다.

이와 같은 특징의 역할 기반 접근 제어 방법의 기본적인 개념에 대해 설명하면 다음과 같다.

·accessible(u,o,c,a) : 사용자 u가 클래스가 c인 객체 o에 대해 액션 a를 수행할 수 있으면 true, 그렇지 않으면 false인 함수를 의미한다.

·accessible(u,o,c,a) = true (u∈U, o∈O, c∈C, a∈A) ⇒

∃r∈R [(r,u)∈ RU], ∃p∈P [(p,r)∈ PR],

∃a∈A [(a,p)∈ AP], ∃c∈C [PC(p) = c], ∃o∈O [(o,p)∈OP]이면,

·accessible(u,o,c,a) = true (u∈U, o∈O, c∈C, a∈A) ⇒

∃rR [(r,u)∈RU] and ∃p∈P[(p,r)∈PR] and ∃a∈A[(a,p)∈AP] and {∃c∈C[PC(p) = c] or ∃o∈O [(o,p)∈OP]}이다.

이와 같은 의미를 기반으로 한 본 발명에 따른 액션을 이용한 역할 기반 접근 제어 방법을 도 4를 통해 설명하면 다음과 같다.

사용자 u가 클래스 c에 속하는 객체 o에 대하여 액션 a의 수행을 요구하면(S411), 먼저, 사용자 u가 속하는 역할들을 테이블을 참조하여 가져와 역할집합(r_set)에 저장(S412)한 후, 상기 역할집합(r_set)내의 각 역할들에 속한 권한들을 테이블을 참조하여 모두 가져와 권한집합(p_set)에 저장한다(S413). 이후, 상기 사용자의 허가된 권한들로만 이루어진 p_set내의 각 권한들에 속한 모든 액션들을 테이블을 참조하여 가져와 액션집합(a_set)에 저장(S414)한다. 그런 다음, 사용자가 수행하려는 액션 a가 상기 저장한 액션집합(a_set)에 포함되는지 여부를 검사한다(S415).

검사 결과, 사용자가 수행하려는 액션이 상기 액션집합내에 포함된 액션이 아니라면, 해당 사용자의 접근을 거부한다(S421). 하지만, 상기 검사 결과, 사용자가 수행하려는 액션이 상기 액션집합내에 포함된 액션이라면, 해당 액션이 허가된 클래스나 객체에 대한 검사를 위해, 상기 저장한 권한집합(p_set)에 포함되어 있는 각 권한에 할당된 모든 클래스를 수집하여 클래스집합(c_set)에 저장한다(S416).

이후, 사용자가 접근하려는 객체를 포함한 클래스 c가 상기 클래스집합(c_set)에 포함되는지 검사한다(S417). 검사결과, 상기 클래스 c가 상기 클래스집합에 포함된 클래스라면, 이는 클래스 c에 속한 모든 객체에 대해 액션 a를 수행할 수 있는 경우이므로, 사용자의 접근을 허가한다(420). 하지만, 상기 검사결과, 상기 클래스 c가 상기 클래스집합에 포함되지 않은 클래스이면, 클래스 내 객체 o에 대한 액션 a가 수행 가능한지를 검사하기 위해, 상기 권한집합(p_set)에 포함되어 있는 각 권한에 할당된 모든 객체를 가져와 객체집합(o_set)에 저장(S418)한다. 그런 다음, 사용자가 접근하려는 객체 o가 상기 객체집합(o_set)에 포함되어 있는지, 즉 접근이 허가된 객체인지를 검사한다(S419).

검사결과, 접근이 허가된 객체라면, 해당 객체 o에 대한 사용자의 액션 a를 허가(S420)하는 반면, 검사결과, 접근이 허가된 객체가 아니라면, 해당 사용자의 접근을 거부한다(S421).

위에서 양호한 실시예에 근거하여 이 발명을 설명하였지만, 이러한 실시예는이 발명을 제한하려는 것이 아니라 예시하려는 것이다. 이 발명이 속하는 분야의 숙련자에게는 이 발명의 기술사상을 벗어남이 없이 위 실시예에 대한 다양한 변화나 변경 또는 조절이 가능함이 자명할 것이다. 그러므로, 이 발명의 보호범위는 첨부된 청구범위에 의해서만 한정될 것이며, 위와 같은 변화예나 변경예 또는 조절예를 모두 포함하는 것으로 해석되어야 할 것이다.

이상과 같이 본 발명에 의하면, 권한(permission)에 적용될 객체(object)를 클래스(class) 및 액션(action)이라는 개념을 통해 일반화함으로써, 대규모 기업 환경에 적용할 수 있는 접근 제어 방법을 구현할 수 있을 뿐만 아니라, 상기 클래스 및 액션이라는 개념을 단순화함으로써, 기업 환경의 변화에 쉽게 대응할 수 있는 접근 제어 방식을 구현할 수 있는 효과가 있다.

Claims (8)

1. 특정 객체에 접근하고자 하는 사용자에 대한 접근 제어 방법에 있어서,

   사용자가 특정 클래스에 속한 특정 객체에 대하여 특정 액션 수행을 요구하면, 상기 사용자가 속한 모든 역할들을 포함하는 역할집합을 생성하는 제1 단계;

   상기 역할집합내의 각 역할들에 속한 권한들을 포함하는 권한집합을 생성하는 제2 단계;

   상기 사용자의 허가된 권한들로만 이루어진 상기 권한집합내의 각 권한들에 속한 모든 액션들을 포함하는 액션집합을 생성하는 제3 단계;

   상기 제1 단계에서 사용자가 요구한 특정 액션이 상기 액션집합에 포함되는지 확인하는 제4 단계;

   상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되면, 상기 권한집합에 포함된 각 권한에 할당된 모든 클래스들을 포함하는 클래스 집합을 생성하는 제5 단계;

   상기 제1 단계에서 사용자가 요구한 특정 클래스가 상기 클래스집합에 포함되는지 확인하는 제6 단계;

   상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되면 상기 사용자의 접근을 허락하는 제7 단계;

   상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되지 않으면 상기 권합집합의 각 권한에 할당된 모든 객체들을 포함하는 객체집합을 생성하는 제8 단계;

   상기 제1 단계에서 사용자가 요구한 특정 객체가 상기 객체 집합에 포함되는지 확인하는 제9 단계;

   상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되면 상기 사용자의 접근을 허락하는 제10 단계; 및

   상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되지 않거나, 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되지 않으면 상기 사용자의 접근을 거부하는 제11 단계를 포함하는 것을 특징으로 하는 접근 제어 방법.
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 제 1 항에 있어서,

   상기 역할(role)은 상위 역할과 하위 역할로 구분되며, 상기 상위 역할은 상기 하위 역할이 속해있는 모든 권한을 상속받는 것을 특징으로 하는 접근 제어 방법.
8. 컴퓨터에서,

   사용자가 특정 클래스에 속한 특정 객체에 대하여 특정 액션 수행을 요구하면, 상기 사용자가 속한 모든 역할들을 포함하는 역할집합을 생성하는 제1 단계;

   상기 역할집합내의 각 역할들에 속한 권한들을 포함하는 권한집합을 생성하는 제2 단계;

   상기 사용자의 허가된 권한들로만 이루어진 상기 권한집합내의 각 권한들에 속한 모든 액션들을 포함하는 액션집합을 생성하는 제3 단계;

   상기 제1 단계에서 사용자가 요구한 특정 액션이 상기 액션집합에 포함되는지 확인하는 제4 단계;

   상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되면, 상기 권한집합에 포함된 각 권한에 할당된 모든 클래스들을 포함하는 클래스 집합을 생성하는 제5 단계;

   상기 제1 단계에서 사용자가 요구한 특정 클래스가 상기 클래스집합에 포함되는지 확인하는 제6 단계;

   상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되면 상기 사용자의 접근을 허락하는 제7 단계;

   상기 제6 단계에서 상기 특정 클래스가 상기 클래스 집합에 포함되지 않으면 상기 권합집합의 각 권한에 할당된 모든 객체들을 포함하는 객체집합을 생성하는 제8 단계;

   상기 제1 단계에서 사용자가 요구한 특정 객체가 상기 객체 집합에 포함되는지 확인하는 제9 단계;

   상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되면 상기 사용자의 접근을 허락하는 제10 단계; 및

   상기 제4 단계에서 상기 특정 액션이 상기 액션집합에 포함되지 않거나, 상기 제9 단계에서 상기 특정 객체가 상기 객체집합에 포함되지 않으면 상기 사용자의 접근을 거부하는 제11 단계를 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.