KR100447511B1 - 역할기반 접근제어 방법 - Google Patents

Abstract

본 발명은 시스템 해킹을 방지 및 차단하기 위해 커널 수준에서 사용자 역할을 기반으로 하여 접근을 제어하는 접근제어 기법에 관한 것이다. 본 발명은 상업적 분야의 요구사항에 적합하고 안전한 시스템 보안을 위해 역할기반 접근제어를 커널 수준에서 제공하는 데에 목적이 있다. 상기 목적을 달성하기 위한 본 발명에 따른 역할기반 접근제어 방법은 프로세스가 현재 가지고 있는 역할들 중에서 유효한 역할들만을 선별하는 제1 단계와, 그 프로세스의 그 유효한 역할들에 대해 역할정보 파일에 있는 생성번호와 객체보안 DB에 있는 역할들의 생성번호를 서로 비교하는 제2 단계와, 그 역할정보 파일에 있는 역할들의 생성번호와 객체보안 DB에 있는 역할들의 생성번호가 같지 않으면 객체에 정의된 역할의 퍼미션 값을 무의미한 값으로 여기는 제3 단계와, 프로세스가 멤버로 속해 있는 역할들 중 유효한 역할들에 대해 해당 객체에 정의된 속성 값들 중에 요청한 속성 값이 있는지를 검사하여 접근여부 결과를 출력하는 제4 단계를 포함한다.

Description

역할기반 접근제어 방법 {Job-based Access Control Method}

본 발명은 사용자 역할을 기반으로 한 커널 수준의 접근제어 기법에 관한 것으로서, 특히 시스템 해킹을 방지 및 차단하기 위해 커널 수준에서 사용자 역할을기반으로 하여 접근을 제어하는 접근제어 기법에 관한 것이다.

안전한 운영체제를 이루기 위해 기존의 접근제어 방법에는 신분기반 접근제어(DAC) 방법과 강제적 접근제어(MAC) 방법인 다중등급 보안(MLS) 방법이 있었다. DAC 방법은 기존의 유닉스에서 제공하는 사용자(user), 그룹(group) 및 기타(other)의 퍼미션으로 주체의 신분에 근거를 두어 객체의 퍼미션을 할당하는 방법이었다. 그러나 이 DAC의 문제점은 먼저 접근의 허용여부를 주체의 신분을 기반으로 하여 판단하므로 다른 사람의 신분을 도용하여 해킹하면 DAC 방법은 무의미해진다. 또한, 기존의 유닉스의 접근제어는 루트에게는 모든 권한이 주어져 있기 때문에 요즘과 같이 버퍼 오버플로우 등의 해킹 기술을 통하여 루트 권한을 획득하면 시스템 전체는 무방비 상태로 파괴될 수밖에 없는 것이다. 또한 이와 함께 트로이 목마 공격에 취약성을 가지게 된다. 이러한 문제점들을 보완하고 군이나 정부의 보안 요구사항에 맞추어 개발된 것이 MLS 방법이었다. 이 MLS 방법은 객체 즉, 파일(file)에 포함된 정보의 비밀성과 주체(user or process)가 갖는 권한에 근거하여 객체에 대한 접근을 제한하는 강제적 접근제어 방법이다. 상위 등급에서 하위 등급의 객체로 정보의 흐름을 방어하기 때문에 흐름제어 정책으로 정의될 수도 있다. 흐름제어를 위해 적용되는 두 가지 규칙은 No-Read-Up 과 No-Write-Down 이 있다. No-Read-Up은 낮은 등급의 주체가 높은 등급의 객체를 읽을 수 없는 규칙을 말하고, No-Write-Down은 높은 등급의 주체가 낮은 등급의 객체에 쓰기를 할 수 없는 규칙을 말한다. 이 두 규칙을 이용하여 정보의 비밀성 및 기밀성을 제공한다. 하지만, MLS 방법은 정부나 군 기관의 접근제어 정책 요구사항에 부합되는 것으로 상업적인 분야의 접근제어에는 잘 맞지 않는다는 문제점이 있다. 예를 들어, 외부의 사용자에 대하여 읽기만 가능하고 쓰기가 가능하지 않은 정보를 제공하려 할 경우에 이 정보를 생산한 내부 사용자보다 외부 사용자의 등급을 높게 설정해야 하는데, 이러한 경우 외부 사용자는 내부 사용자가 만든 모든 정보를 읽을 수 있는 권한을 가지게 되는 문제가 있는 것이다.

즉, 기존의 DAC 방법은 사용자의 신분기반의 접근제어로서 사용자의 신분을 바꿈으로 쉽게 침입이 되는 안전하지 못한 접근제어이고, 이를 보안하기 위해 개발된 MAC 방법은 강제적 규칙에 의한 접근제어로 군이나 정부 등의 요구사항 들에 부합되어 나온 접근제어 모델로 상업적인 분야에서의 응용성이 떨어지는 단점을 가지고 있다.

이러한 종래기술의 문제점을 극복하기 위하여 본 발명은 상업적 분야의 요구사항에 적합하고 안전한 시스템 보안을 위해 역할기반 접근제어를 커널 수준에서 제공하는 데에 그 목적이 있다.

또한, 본 발명은 상업적 분야의 유연성과 안정성을 도모하는 보안을 위해 역할을 기반으로 하는 접근제어 방법을 제공하고, 특정 응용 서비스에만 종속되는 역할 기반 접근제어 방법이 아닌 다양한 응용 서비스에 즉각적으로 호환이 가능한 역할기반 접근제어 방법을 제공하기 위해 커널 수준에서 제공하는 데에 또 다른 목적이 있다.

도 1은 역할기반 접근제어 모델을 도시한 도면.

도 2는 사용자, 역할 및 퍼미션의 실제관계의 구성을 도시한 도면.

도 3은 역할기반 접근제어 검사 알고리듬을 설명한 흐름도.

도 4는 보안 정보 파일의 구조도.

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

1: 사용자 2: 역할

3: 퍼미션 4: 역할계층

5: 제약사항

상기 목적을 달성하기 위한 본 발명에 따른 역할기반 접근제어 방법은 프로세스가 현재 가지고 있는 역할들 중에서 유효한 역할들만을 선별하는 제1 단계와, 그 프로세스의 그 유효한 역할들에 대해 역할정보 파일에 있는 생성번호와 객체보안 DB에 있는 역할들의 생성번호를 서로 비교하는 제2 단계와, 그 역할정보 파일에 있는 역할들의 생성번호와 객체보안 DB에 있는 역할들의 생성번호가 같지 않으면 객체에 정의된 역할의 퍼미션 값을 무의미한 값으로 여기는 제3 단계와, 프로세스가 멤버로 속해 있는 역할들 중 유효한 역할들에 대해 해당 객체에 정의된 속성 값들 중에 요청한 속성 값이 있는지를 검사하여 접근여부 결과를 출력하는 제4 단계를 포함한다.

그 제1 단계에서는 그 역할정보 파일로부터 현재 프로세스가 멤버로 되어 있는 역할들이 존재하는 역할인지 검사하는 과정을 포함한다. 그 역할정보 파일은 모든 생성되어 있는 그 역할들의 정보들을 가지고 있고, 그 역할들의 정보들은 역할 이름, 역할의 존재 유무, 역할의 생성번호, 상호배제 역할들의 정보, 멤버 수를 포함하며, 그 해당 객체에 정의된 그 속성 값들은 읽기, 쓰기 및 실행 중 하나 이상을 포함한다. 그 제4 단계에서 그 해당 객체에 정의된 그 속성 값들에 대하여 OR 연산을 함으로써 요청한 속성 값이 있는지를 검사한다.

본 발명의 역할기반 접근제어 방법은 기업이나 상업적 분야에서의 조직에 맞게 역할을 나누어 편리하고 효율적으로 접근제어를 수행하도록 하는 기능이다. 역할기반 접근제어 방법은 DAC에서와 같이 루트 권한을 획득하면 모든 것을 할 수 있도록 허용되지 않고 루트일지라도 할당된 역할에 허용된 권한만을 가지기 때문에 루트 권한획득으로 인한 피해를 줄일 수 있고 기업의 그룹웨어, 웹서버 등과 같은 여러 상업적 응용 분야의 요구사항에 부합되는 접근제어 모델이다. 응용 프로그램 수준에서 역할기반 접근제어 기능을 제공하는 것이 아니라, 커널 내부에서 역할기반 접근제어를 제공한다. 그래서 응용 프로그램 수준에서의 역할기반 접근제어 기능의 보안의 한계를 극복할 수 있다. 운영체제 레벨에서의 역할 기반접근제어를 수행함으로써, 역할 기반 접근제어를 이용하여 다양한 응용 서비스에 대해 보안을 제공할 때, 커널내부에 있는 역할들을 그 서비스에 맞게 구성함으로써 호환이 가능하다. 따라서, 본 발명은 커널 내부에서 근본적으로 접근제어를 수행하여 안전한 운영체제를 제공할 수 있다.

본 발명의 역할기반 접근제어 방법은 정보에 대한 사용자의 접근을 개별적인 신분이 아니라 조직 내에서 개인의 역할(role) 또는 직무에 따라 결정되도록 한 것으로서 상업적인 분야에서의 접근제어 요구사항에 적합한 접근제어 정책이다. 사용자, 역할, 그리고 퍼미션의 3가지 기본 요소를 가지고 실제 접근제어 검사시 해당 파일에 권한을 가지고 있는 역할에 사용자가 구성원으로 속해 있을 경우에만 해당 파일에 접근 가능하도록 하는 것이다. DAC 방법에서는 해커가 루트 권한을 획득하면 모든 것을 파괴할 수 있지만, 역할기반 접근제어 방법에서는 역할(role)을 기반으로 하여 루트의 권한을 분산 및 제한하기 때문에 시스템이 해커에 의해 해킹되는경우에 피해를 최소화할 수 있다.

상업적 분야에 적합한 장점을 보면 역할을 기반으로 하여 접근을 제어하기 위해 미리 정의된 업무에 역할을 정의하고 사용자에 대한 접근 검사가 아닌 역할(role)에 대한 접근을 제어하므로 시스템의 보안 관리 및 유지 보수가 용이해진다. 예를 들어, 종래의 방법에서는 직장의 인사부장의 자리에 사용자가 A라는 사람에서 B라는 사람으로 바뀌었을 경우에 A라는 사람이 인사부장으로 있을 때에 생성하고 관리했던 많은 파일들의 소유자는 A라는 사람으로 되어 있고 A라는 사람의 등급을 가지고 있다. 따라서, B라는 사람이 새로 인사 부장의 자리에 왔지만 해당 파일들에 대한 접근 권한이 없으므로 관리자가 관련된 모든 파일들에 대한 변경을 수행해야 하는 번거로움이 있다. 하지만 역할기반 접근제어 방법에서는 A라는 사용자를 인사부장 역할(role)의 멤버에서 제거하고 B라는 사람을 인사부장의 역할에 넣어주기만 하면 되므로 관리가 훨씬 용이하다. 그런데, 조직에서 역할(role)은 빈번하지는 않지만 역할이 바뀌는 경우도 있고 또한 커널 수준에서 여러 다양한 응용 서비스를 위한 역할기반 접근제어를 제공해야 하므로 역할(role)은 새로 정의되고 삭제되는 일이 있을 수 있다. 물론 사용자 계정을 생성하고 삭제하는 것보다는 적겠지만 역할의 생성 및 삭제하는 일이 발생 할 수 있다는 것이다. 이때에는, 앞에서 나온 문제점과 같이 인사부장과 관련되었던 모든 파일의 접근제어 정보를 수정해야 하는 것처럼 새로 정의되거나 삭제되는 역할(role)과 관련된 모든 파일의 접근제어 정보 또한 바뀌어야 하는 문제점이 발생한다. 하지만, 본 발명에서는 역할의 생성번호를 사용하여 역할이 생성될 때의 생성 번호를 역할의 정보에 저장하고객체에 해당 역할에 대한 퍼미션을 지정할 때, 이 생성번호를 그 객체에 저장하여 나중에 접근제어 검사시 해당 역할이 가지고 있는 생성 번호와 객체가 그 해당 역할에 대해 가지고 있는 생성 번호를 비교하여 다른 경우는 의미 없는 접근제어 정보로 간주하여 접근제어 검사시 고려해 주기 때문에 생성되거나 삭제되는 역할과 관련된 모든 파일들의 접근제어 정보를 고칠 필요 없이 생성 번호를 사용하면 된다.

역할 기반 접근제어(RBAC) 에는 기본적으로 사용자, 역할 및 퍼미션 부분이 있고, 그 외에 역할 계층(Role Hierarchy) 및 제약사항(Constraints) 등의 구성 요소들로 이루어진다.

도 1은 역할기반 접근제어 모델을 도시한 도면이다. 먼저, 사용자(1)는 시스템에서 작업을 수행하는 사용자들로서, 실제 시스템 내에서는 작업을 수행하는 프로세스에 해당한다. 역할(2)은 조직에서 정의된 업무를 말하고 그 역할에 속해 있는 멤버들의 권한 및 책임을 의미한다. 퍼미션(3)은 시스템에 있는 하나 또는 그 이상의 객체에 대한 특정 접근 속성에 대한 승인을 의미한다. 역할계층(4)은 역할간의 계층 구조를 말한다. 즉, 상위 역할은 하위 역할에게 주어진 퍼미션들을 모두 상속받는다. 예를 들어, 인사부장의 역할은 일반직원 역할의 상위 역할로서 일반직원 역할이 가지고 있는 모든 퍼미션들을 가지게 된다. 제약사항(constraints)(5)은 상호 배제 역할과 중요도(cardinality)가 있다. 먼저 상호 배제 역할은 한 사용자에게 동시에 허용될 수 없는 역할들을 말한다. 한 예로 구매요청 역할과 지급 역할을 한 사용자에게 동시에 허용되는 경우에 구매 조작의 피해가 발생할 수 있는 경우를 방지하는 기능을 수행한다. 중요도는 해당 역할의 멤버가 될 수 있는 사용자의 수를 정의한다. 예를 들어 중요도가 1인 경우는 단지 한 사용자만이 그 역할의 멤버가 될 수 있다.

이하, 첨부한 도면을 참조하여 본 발명의 실시예를 상세히 설명한다.

도 2는 사용자, 역할 및 퍼미션의 실제관계의 구성을 도시한 도면이다. 도 2는 역할기반 접근제어의 사용자, 역할, 그리고 퍼미션들의 실제 구성 관계를 보여준다. 10이 가리키는 것은 사용자와 역할간의 관계를 나타낸다. 사용자는 역할의 구성원이 되어 역할이 가지는 권한을 가지게 된다. 20이 가리키는 것은 역할과 객체의 퍼미션과의 관계를 나타낸다. 20에서와 같이 각 객체에는 각 역할에 대해 읽기 권한, 쓰기 권한 및 실행 권한이 주어지게 된다. 그래서 주체가 해당 객체에 접근하기 위해서는 해당 객체에 대해 접근 속성을 가지는 역할의 구성원이 되어야 한다.

도 3은 역할기반 접근제어 검사 알고리듬을 설명한 흐름도이다. 접근제어 검사가 시작되면 S1에서는 프로세스가 현재 가지고 있는 역할들 중에서 유효한 역할들만을 선별하는 작업을 수행한다. 모든 생성되어 있는 역할들의 정보들(역할 이름, 역할의 존재 유무, 역할의 생성 번호, 상호배제 역할들의 정보, 멤버수 등)을 가지고 있는 역할정보 파일로부터 현재 프로세스가 멤버로 되어 있는 역할들이 삭제되지 않고 존재하는 역할인지 검사한다. 이때, 존재하는 역할들만을 다음 단계의 검사에서 사용한다. S2에서는 S1에서 나온 프로세스의 유효한 역할들에 대해 역할정보 파일에 있는 역할들의 생성번호와 객체보안 DB에 있는 역할들의 생성번호를 서로 비교하여 같지 않은 경우 객체에 정의된 역할의 퍼미션 값을 무의미한 값으로 여긴다. S3에서는 프로세스가 멤버로 속해 있는 역할들 중 S2까지 수행해서 나온 유효한 역할들에 대해 해당 객체에 정의된 속성 값들(read, write, execute)을 OR 연산을 취해 요청한 속성 값이 있는지를 검사하여 접근여부 결과를 출력한다.

도 4는 보안 정보 파일의 구조도이다. 본 발명에서 중요한 요소 중 하나인 보안정보들을 저장하는 방식에 대해 보여준다. 본 발명에서 역할기반 접근제어를 응용 프로그램 수준이 아니라 커널 내부에서 제공하므로 커널에서 직접 보안정보 파일들을 읽고 쓴다. 30에서와 같이 파일은 논리적인 블록으로 각 객체의 inode 값으로 인덱싱 되어 있어서 해당 객체의 보안정보에 접근하기 위해서는 해당 객체의 inode 값을 인덱스로 하여 찾으면 된다. 이렇게 inode로 된 인덱싱은 보안정보 파일에 수천 또는 수만 개의 파일의 보안정보가 저장되어 있더라도 아주 빠른 속도로 접근하여 해당 파일의 보안 정보를 얻거나 설정할 수 있다. 40에서는 inode가 102인 파일의 보안정보를 가지고 있는 블록의 자세한 내용들을 표시한다. inode가 102인 파일은 R1 역할에 대해 읽기(r)와 쓰기(w)가 주어진 상태이다. 그리고 R2 역할에 대해서는 읽기(r)만 주어진 상태이고(3)에서는 R2 역할의 생성번호가 1500을 가지고 있는 것을 나타낸다. R2에게 주어진 읽기(r) 권한이 접근제어 검사시 사용되기 위해서는 이 생성 번호가 모든 생성된 역할의 정보를 가지고 있는 역할정보 파일에 저장되어 있는 R2의 실제 생성번호와 같아야 한다.

보안 정보들을 보안정보 파일에 저장하고 각 객체의 inode 값을 인덱스로 하여 해당 보안 정보의 논리적 블록을 접근하여 객체의 보안 정보를 획득 및 설정한다. 삭제되거나 변경된 역할과 관련된 모든 파일의 보안 정보들을 변경할 필요 없이 역할의 생성번호를 이용하여 유효성을 검사하여 접근제어 검사시 적용시키는 것으로 관리자의 보안 정보 관리를 간단하고 용이하게 한다.

또한 각 객체의 보안정보를 가지는 보안정보 파일들을 이용하고 커널에서 직접 보안정보들을 읽고 쓸 수 있도록 하여 빠르고 안전하게 또 다양하게 역할기반 접근제어를 위해 필요한 보안정보들을 관리 할 수 있다. 보안정보를 보관하는 보안 파일들은 각 파일 시스템마다 가지게 되고 각 객체들 즉, 파일(file), 디렉토리(dir) 및 장치(device) 등의 INODE 값은 보안 파일에서 객체 자신의 값을 찾기 위한 인덱스로 사용되어 빠르게 원하는 객체의 보안정보를 읽을 수 있다. 또한 각 파일 시스템별로 보안 정보파일이 있고 파일 시스템별로 접근제어의 적용여부를 구분할 수 있다.

본 발명은 역할기반 접근제어를 제공함으로써 기업 조직이나 인터넷 서버 등의 상업적 분야의 요구사항에 적합한 보안을 제공할 수 있고 응용수준에서 제공되는 역할기반 접근제어가 아닌 운영체제 커널 내부에서 제공되는 역할기반 접근제어로 보다 안전하고 근본적인 보안을 이룰 수 있다. 또한, 특정 응용 서비스를 위한 역할기반 접근제어가 아니라 여러 다양한 응용 서비스에 역할기반 접근제어 기능을 제공할 수 있다.

본 발명은 기업의 조직을 근본으로 하는 그룹웨어나 웹서버, 파일서버 등의 상업적 분야에서의 요구사항에 적합한 안전한 운영체제를 제공하기 위해 역할기반 접근제어를 제공하는 것이다.

본 발명은 응용 프로그램 수준에서의 역할기반 접근제어가 아니라 커널 수준에서의 역할기반 접근제어가 수행되어 응용 프로그램 수준에서 제공될 때의 보안의 한계성을 극복할 수 있고 근본적인 접근제어가 이루어져 안전한 운영체제를 이룰 수 있다.

본 발명은 커널 수준에서 역할기반 접근제어가 제공되어 특정 시스템 예를 들어 DBMS 나 Workflow 시스템 같은 특정 응용 시스템에 맞추어 한정되게 역할기반 접근제어가 제공하는 것이 아니라 이를 포함한 모든 용용 서비스에 효율적이고 유동적으로 역할기반 접근제어 기능을 제공할 수가 있다.

Claims (6)

1. 프로세스가 현재 가지고 있는 역할들 중에서 유효한 역할들만을 선별하는 제1 단계와,

   상기 프로세스의 상기 유효한 역할들에 대해 역할정보 파일에 있는 생성번호와 객체보안 DB에 있는 역할들의 생성번호를 서로 비교하는 제2 단계와,

   상기 역할정보 파일에 있는 역할들의 생성번호와 객체보안 DB에 있는 역할들의 생성번호가 같지 않으면 객체에 정의된 역할의 퍼미션 값을 무의미한 값으로 여기는 제3 단계와,

   프로세스가 멤버로 속해 있는 역할들 중 유효한 역할들에 대해 해당 객체에 정의된 속성 값들 중에 요청한 속성 값이 있는지를 검사하여 접근여부 결과를 출력하는 제4 단계를 포함하는 것을 특징으로 하는 역할기반 접근제어 방법.
2. 제1 항에 있어서,

   상기 제1 단계에서는 상기 역할정보 파일로부터 현재 프로세스가 멤버로 되어 있는 역할들이 존재하는 역할인지 검사하는 과정을 포함하는 것을 특징으로 하는 역할기반 접근제어 방법.
3. 제1 항 또는 제2 항에 있어서,

   상기 역할정보 파일은 모든 생성되어 있는 상기 역할들의 정보들을 가지고 있는 것을 특징으로 하는 역할기반 접근제어 방법.
4. 제3 항에 있어서,

   상기 역할들의 정보들은 역할 이름, 역할의 존재 유무, 역할의 생성번호, 상호배제 역할들의 정보, 멤버수를 포함하는 것을 특징으로 하는 역할기반 접근제어 방법.
5. 제1 항에 있어서,

   상기 해당 객체에 정의된 상기 속성 값들은 읽기, 쓰기 및 실행 중 하나 이상을 포함하는 것을 특징으로 하는 역할기반 접근제어 방법.
6. 제1 항 또는 제5 항에 있어서,

   상기 제4 단계에서 상기 해당 객체에 정의된 상기 속성 값들에 대하여 OR 연산을 함으로써 요청한 속성 값이 있는지를 검사하는 것을 특징으로 하는 역할기반 접근제어 방법.