MAC, DAC and RBAC 비교
From Partout.NET
MAC(Mandatory Access Control)은 사용자와 객체에게 부과된 보안 레이블(Security Label) 기반으로 접근통제를 수행하며 DAC(Discretionary Access Control)은 객체에 부여된 허가, 거부 정책에 기반하여 객체에 대한 접근을 통제한다. 상용 환경에서는 정보의 변경 가능성이 불법 사용자에 의한 정보의 접근 가능성인 비밀성보다 더 중요한 관심사가 될 수 있다. 예를 들어 은행 업무에서 예금 계좌에 대한 정보 변경에 관련된 위협이 예금 계좌에 관련된 정보의 접근보다 더 위협적일 수 있다. 그런데, MAC은 등급화된 정보의 기밀성을 위한 보안에 촛점이 맞춰져 있고 DAC은 접근 권한이 객체의 소유자(owner) 의해 임의로 변경될 수 있어서 기업이나 정부 조직과 같이 무결성을 요구하는 상업적 응용의 정보 보안에는 부적절하다. 그래서 무결성 제어가 필요한 상용 환경에서는 RBAC(Role-Based Access Control) 방식이 MAC, DAC의 대안으로 주목받고 있다.
RBAC은 필요할 때 MAC, DAC과 함께 사용될 수 있는 접근통제의 독자적인 요소이다. 그럴 경우 접근은 RBAC, MAC, DAC에 의해 허가되었을 경우에 허락된다. 물론 RBAC 그 자체 만으로도 존재할 수 있다.
RBAC 자체는 임의적, 또는 강제적인 메커니즘인가? 이 대답은 RBAC 시스템에서 사용자, 역할, 허가의 정확한 본질과 설정뿐만 아니라 임의적인 것과 강제적인 것의 정확한 정의에 달려있다. 강제적인 것은 각 사용자가 어떤 허가 또는 사용자가 역할에 할당되는가에 대한 선택권을 가지지 못하는 것이고 반면에 임의적인 것은 각 사용자가 이러한 결정을 만들 수 있다는 것을 의미한다. 앞에서 언급한 것처럼 RBAC은 자체로서는 정책 중립적이다. RBAC의 특정한 설정에 따라 강제적인 요소를 가지게 되고 또한 임의적인 요소를 가질 수도 있게 된다.
RBAC 개념
평범한 UNIX 시스템에서, 루트(root)는 모든 파일을 읽고 쓸 수 있으며 모든 프로그램을 실행시킬 수 있고 모든 프로세스에 종료 신호를 보낼 수 있는 권한을 가진다. 실제적인 말로, 이것은 슈퍼유저가 될 수 있는 모든 사람은 사이트의 방화벽을 수정하고, 회계 보고서를 바꾸고, 직원들의 급여와 다른 비밀 기록을 읽을 수 있고, 심지어 전체 네트워크를 못쓰게 할 수도 있다. 그렇기 때문에, 조직들이 더 이상 그들이 그래왔던 것처럼 루트의 암호를 자유롭게 놔 두지 않는다는 것은 의심할 여지가 없다.
RBAC는 모든 권한을 갖거나 권한을 전혀 갖지 않게 되는 슈퍼유저 모델에 대한 대안이다. RBAC는 가장 특권이 적은 보안 원리에 따라 유지되며, 그것은 어떤 사용자도 그 사람의 일을 수행하는데 필요한 권한 이상을 가지지 않는다는 것을 말한다. RBAC는 한 조직이 슈퍼유저의 능력들을 분리할 수 있게 해주고 그것들을 특정 개인들을 그들의 일의 필요에 따라 할당하기 위한 특별 사용자 계정 혹은 역할로 포장할 수 있게 해준다. 이것은 다양한 보안 정책을 가능하게 해 준다. 계정들은 보안, 네트워킹, 방화벽, 백업, 그리고 시스템 운영과 같은 영역에서 특정 목적의 관리자를 위해 설정될 수 있다. 한명의 강력한 관리자를 선호하고 좀 더 복잡하게 사용자들이 그들 자신의 시스템의 일부를 고칠 수 있도록 하길 원하는 사이트는 상급 사용자(Advanced User) 역할을 설정할 수 있다. 보안의 많은 측면에서, RBAC는 단지 기술만은 아니다. 그것은 산업을 수행하는 방식이다. RBAC는 시스템 제어를 재할당 하는 수단을 제공하지만, 그 구현을 결정하는 것은 그 조직이다.
RBAC모델은 2004년에 ANSI 표준으로 등재되었으며, 모델의 설명, 기능, 스펙까지 표준문서에 정리되어 있어 개발자에게 좋은 가이드가 될 것이다. 표준에서는 RBAC을 세가지 모델로 구분하고 있다.
- Core RBAC 모델
- Hierarchical RBAC 모델
- Constrained RBAC 모델
자세한 사항을 표준문서를 참고하기 바란다.
참조 사이트
1. NIST 의 RBAC 페이지:
http://csrc.nist.gov/rbac/#intro
2. RBAC
http://en.wikipedia.org/wiki/RBAC
Chapter 2.3 The Role( 역활 ) of Rules
SElinux는 또한 role-based access control(RBAC)를 제공한다.SElinux의 RBAC (ex: root 사용자가 가진 권한을 일반 사용자에게 일부만 허용하게 하는 역할 기반 접근 제어를 사용) 는 타입 시행를 토대로 되어 있다. Selinux에서의 접근제어는 타입 시행을 첫번째로 거친다. Roles은 프로세스의 보안 문맥에서의 rule식별자에 기초된 변환되는 한계를 가진다.
이런식으로 정책 작성자는 domain 타입들의 설정으로의 변환을 허용하는 규칙을 만들 수 있다.( 타입 시행 규칙이 변환을 허용한다는 가정하에.)
그 때문에 규칙의 제한을 정의한다. 타입 시행 규칙에 따르면 비록 패스워드 프로그램은 새로운 passwd_t domain에 들어간 user_t domain에 의해 실행되지만 또한 변환이 일어나기 위한 새로운 domain 타입과의 결합되는 것을 허용할 수 있다.
<FIGURE 2-6> p-30
우리는 보안적인 문맥의 role부분( user_r )추가했다. 또한 우리는 새로운 규칙인 특별한 role statement를 추가했다.
role user_r type passwd_t;
이 role statement은 role 식별자( user_r )를 선언하고 미리 선언된 role( passwd_t )와 결합시킨다.이 선언의 의미는 이러하다.
" passwd_t 타입은 user_r role을 지닌 보안 문맥과 동시에 존재하도록 허용된다. "
이 role statement 없이 새로운 문맥인 joe:user_r:passwd_t 는 만들어 질 수 없다. 그리고 execve() 시스템 콜은 실패 할 것이다. 심지어 TE정책이 모든 접근을 가진 user_t 타입을 allow할지라도.
정책 작성자는 한층더 강요된?? 규칙을 정의하고 특정한 유저들에게 그 규칙들을 결합할 수 있다. 예를 들어 passwd_t 타입과는 결합되지 않은 user_r과 동일한 restricted_user_r을 생성한다고 했을 때 user_r대신에 restricted_user_r이 joe의 role(역활)이라고 한다면 Joe는 패스워드 프로그램을 실행할 수 있는
권한을 부여받지 못한다. 심지어 TE규칙이 그의 domain 타입( user_t ? )의 접근을 허용 한다고 할지라도.
( 지환 생각 : 어떠한 유저에 대해 권한이 부여된 user_t 타입에 user_r라는 역활권한을 더 추가하여 작업을 수행할 수 있도록 하는 접근제어 권한을 말하는 듯하다. )
Rss Feed