Role-Based Access Control (RBAC)

기존 DAC 문제점

- 임의접근제어가 너무 유연함

- 정보흐름 통제 어렵다. => 트로이 목마

 

분산 시스템에서의 ACL

 

- ACL은 일반적으로 사용자(목록)와 그룹(목록)으로 구성됨

- 사용자와 그룹이 정의가 되고 관리 도메인 내에서 등록이 됨

- 만약에 ACL에서 그룹이 없으면 관리 하기 힘듬, 사용자들의 긴 리스트를 관리해야됨

- 관리 도메인 안에서 그룹의 이름은 사용자들의 목록으로 확장될 수 있음 => 한그룹에 여러 사용자

 

- 그룹이 등록 되었으나, 도메인 밖(그룹이 등록되지 않은 위치)에서 사용해야 한다면? => ACL은 힘듬

다른방법으로 Capability list가 잇음 or 그룹을 일반화 시킴 

 

따라서 역할기반제어기법

ACL은 사용자에게 바로 권한을 주었다.

 

RBAC은 주체, 객체사이에 역할을 두어 접근 허가의 개수를 줄이고 관리해야하는 자격의 개수를 줄였다.

Vendor Management는 세사람이 하나의 역할을 하게 해준다.

그리고 유저의 권한이 바뀔때 => 대리에서 과장으로 승진되었을때 역할만 바꾸어주면 된다. 

 

RBAC

 

사용자와 자원을 분리시킴 중간에 역할을 추가함

사용자는 자주 바뀌는 반면에 역할은 자주 바뀌지 않음

 

- 서비스 입장에서는 client들은 어떤 이름이 붙여진 역할로 분류할 수 있다.

- 역할에 따라 권한을 할당하는 것이 가능하다.  

- DAC보다 훨씬 더 세밀한 접근제어가 개별적인 객체에 주어질 수 있다. => A는 하나의 role만 가지게하고 그 role의 권한을 줄일 수 있음 

- 역할 범위는 local domain, 분산환경 둘다 가능하다. 

 

* 주체와 객체 분리

- principals -> roles : 주체가 역할에 할당

- roles -> privileges : 역할이 권한가짐

 

- 역할 개념에 따라서 권한을 명시할 수 잇음

- 주체는 역할이 배정되고 실제권한은 역할에 준다. => 관리가 편해짐

 

* 역할 세분화 가능

- fine-grained access control 가능

-

접근을 주거나 접근을 제한할 수 있다

 

ACL은 개인을 상호배타적으로 제외시킬 수 있는가? => 어려움

 

 

RBAC은 Matrix가 두개 필요하다. 

user - role

role -(접근제어)- object 

사용자는 할당된 역할에 기반하여 객체에 접근함

역할은 직무에 따라 정의됨

 

Role : 조직내에서 직무를 나타낸다.

한 유저는 여러 역할을, 여러 유저는 한 역할을 할 수 있다.

 

Session : 일시적으로 어떤 사용자가 어떤 역할을 가지게 될때, session을 통해서 할당이 이루어진다. (동적)

=> 최소 권한 원칙을 집행하는데 의미가 있다, session을 통해 최소권한 원칙 강제 가능

=> 각 세션은 한 유저를 여러역할에 매핑함.. 

e.g A는 대리이면서 TF팀의 팀장이다 => 역할이 두가지

Session을 통해서 동적으로 역할을 할당한다.

사용자와 역할간, 역할과 permission간에는 one-to-many, many-to-many가능

유연성도 제공하고 접근허가 단위 세분화 가능

 

RBAC은 4가지 모델이 있음 

 

Role 계층구조 => 상속

 

RBAC 구성요소 설계할때 혹은 구성할때 제약을 가한다.

e.g 어떤 사용자는 하나의 역할만 가져야한다.        ->이러한 것을들 미리 정해야한다.

     한 역할에 포함 될 수 있는 사람은 00명이다

     이 역할은  ~~한 권한을 가져야한다.

 

SOD => Speration of Duty : 이해 충돌이 나는 절차가 있으면 분리해서 다른사람에게 맡긴다. (시험내는사람, 푸는 사람, 검토하는 사람 다 달라야)

 

RBAC0 = base model

RBAC1 = 역할에 계층적 구조 지원 -> 상속 허용

RBAC2 = 제한가함, -> SOD, Cardinality(한 사용자는 한역할만 or 한 역할에 포함되는 사람의 수는 00이다.), 필수조건(최소권한 원칙을 지정하는데 필요함, 어떤 일을 하기전 어떤 역할을 가져야함) 

RBAC3 = RBAC1+ RBAC2

 

RBAC1

---------------------------------------------------------------------------------------------------------------------------------

상위 역할은 하위역할을 상속받는다. 

e.g Director는 프로젝트 리더1,2의 권한을 다 상속 받음

 

 

RBAC2  - 제약조건

---------------------------------------------------------------------------------------------------------------------------------

1. 상호배타적인 역할 => 유저는 집합안에서 하나의 역할만 가질 수 있다. 어떤 permission은 어떤 역할에만 주어라

 - SOD를 지원하기 위한 것

 - 결탁, 공모 어렵게한다.

 

 - Static Exclusion : 어떤 사용자도 두개 이상 역할을 가질 수 없다. 하나만

 - Dynamic Exclusion : 역할을 활성화 시킬때, 하나의 session에 하나의 역할만 활성화 시켜야한다.

 

2. cardinality => 한 역할에 포함될 수 있는 사용자의 최대수 한정 or 한 사용자가 가질 수 있는 역할 제한

 - 정적 

   역할 최대 사용자

   역할 최소 사용자

   역할에 0명의 사용자만

 - 동적

   session을 통해서 일시적으로

 

3. 선수조건 만족역할 => e.g 과대표가 되려면? 00대학교의 학생이여야한다.

 - 조건이 만족되어야 어떤 역할의 멤버가 될 수 있다.

 

3가지 제약조건이 있음

 

 

Role permission relationship은 미리 정의된다.

 

SELinux에서의 Role(SELinux는 DTE도 지원하고 RBAC도 지원한다.)

seinfo -r명령어로 role정보를 볼 수 있다.

id -Z

system_u:unconfined_r:unconfined_t:s0

system_u : 유저

unconfied_r : 역할

unconfined_r : 타입 => 도메인 (어떤 파일을 접근할 수 있는지에 대한 집합)

역할은 도메인에 연결되어잇음

 

 

NIST RBAC Model

============================================================================

1. 관리자 업무 => RBAC의 구성요소들을 생성하거나 삭제하거나 유지하는 것, 역할과 permission간의 관계를 생성하고 삭제하고 관리하는 역할

 - 유저집합으로부터 유저들을 삭제하거나 추가

 - 사용자와 역할관계 생성하거나 삭제

 - permission과 역할 관계 삭제하거나 생성

 

2. 시스템을 지원하는 업무 => 세션 관리에 관계되는 내용(세션 일시적으로 동적으로 사용자와 역할간의 관계)

 - 사용자 세션생성과 관리

 - 세션에 액티브한 역할 추가

 - 세션에 있는 역할 제거

 

3. 검사하는 업무 

 

object = 자원

operation = 사용자를 위해 어떤 업무를 실행하는 것

operation을 할 수 있는지 허가하거나 불허하는 것

 

계층 RBAC => 상위역할은 하위역할 권한 상속가능

계층에 제약을 줄 수도 있음

 

Dynamic Separation of Dutiys (DSD)

긴급한 일 처리하기위해서 일시적으로 만드는 어떤 역할에 사용자 매핑 = 세션

사용자 세션과 관계된다.

 

SSD모델에서는 이해충돌이 나는 2가지 역할 가지는 것 불가

DSD 모델에서는 2가지 역할을 가질 순 있지만, 같은 시점에 두가지 역할 가지는 것 안됨

다른 시점에 다른 역할 가지는 것 허용

e.g 6개월 전에는 수행자였지만, 6개월 후에는 평가자임. A프로젝트 수행자이면서 B프로젝트 평가자

 

계층이 없으면 정보가 중복되서 관리되고 저장공간도 많이 필요하고 어려워진다.

계층으로 상속을 지원하면 권한을 상속받고 Application도 달라진다.

 

 

RBAC 장점

 - 효율적인 보안 관리 지원

 - 역할의 계층구조 지원

 - 동적으로 역할 상속 지원

 - 역할보다 유저가 자주 바뀜, 권한을 주는 것은 쉬움(역할을 사용하여서 => 역할만 바꾸면 댐)

 - 최소권한원칙 지원 = 역할을 세분화

 - SOD 지원

 - 회사레벨에서 전체적인 관점지원

 - 조직레벨에서 접근제어해결에 도움을 줌

 - 서로다른 플랫폼에서 지원

 - DAC/ MAC 정책 포함가능

 - 정책 검증이 쉬움

 - RBAC을 이용해서 DAC/MAC구현 가능

 

RBAC 단점

 - 최소권한 원칙을 위해서 역할 너무 세분화시 역할이 폭발함 => role explosion

 - 자원에 대한 ownership 표현 불가 (누가 만들었는지)

 - 역할 너무 세분화시 비효율적임

 => RBAC + ownership을 함께 사용함(리눅스 DAC/ RBAC둘다 사용가능 따라서 실용적)

 

SELinux (Role vased Access Control)

SELinux는 DAC/RBAC/MAC 모두 지원한다.

 

 

SELinux 유저는 사용자 세션(로그인 -로그아웃까지 시간) 바뀌지 않는다.

리눅스 유저는 su나 sudo명령어로 바뀔 수 있다.

SELinux 유저는 하나 이상의 역할(정책에 의해 정의)에 할당된다.

object_r : 파일을 위해 사용되는 일반적인 역할

webadm_r : 오직 apache 서버와 관련된 관리를 함

...

각 관리자들을 세분화 하였다. => 전지전능한 권한을 갖는 role은 없다 => SOD, 최소권한 원칙 지원

 

seinfo -r => 이용가능한 역할 보여줌

 

seinfo로 정보 볼 수 잇다.

 

보안 문맥 : 주체와 객체는 보안 문맥을 가진다. => label이라고 한다.

주체(프로세스 일반적으로 os에서) 가 객체를 어떻게 접근할 수 있는지를 결정하는데 사용한다.

프로세스가 갖는 문맥과 file이 갖는 문맥이 다르다.

 

SELinux 보안 문맥은 SELinux user, rol, type은 필수 필드이며, MLS range는 옵션이다.

 

유저 swift는 user_u에 매핑되고 user_u는 user_r에 user_r은 user_t에 매핑된다.

유저는 user_t 도메인안에 있다. 도메인에서 지정된 자원만 접근가능하다.

 

루트 유저는 sysadam_t도메인 안에 있다.

 

일반 유저 도메인 (user_t)는 권한이 낮은 도메인이다.

따라서 어떠한 관리 task도 허용하지 않는다.

sudo나 su 명령 접근 가능해도, 시스템에 손상을 가할 수 없다.

=> user_t라는 도메인 내에서 허용된 일만 한다. 

 - 어떤 사용자가 어떤 역할, 도메인에 할당이 되면, 거기에 국한된다.(할 수 있는일 제한)

=> 사용자가 user_t 도메인에 있기도 하지만, 역할 자체가 user_r이기 때문이다.

 - 두가지 측면에서 나쁜영향을 막는다. 1. 도메인. 2. 역할

DAC에서는 위와 같은 일이 일어날 수 잇지만 SELinux RBAC은 막음

 

SELinux role은 유저가 자유롭게 도메인을 선택할 수 있다는 것을 의미하지 않음 => 관리자가 정한 policy, rule에 따라 결정됨

 

seinfo 툴로 어떤 도메인에 그 역할이 할당될 수 있는지 그역할이 어떤  도메인에 매핑될 수 있는지 알아볼 수 있다.

"user_r이 가질 수 ㅣㅇㅆ는 도메인 은 두가지이다.

 

Switching role

사용자는 역할을 바꿀 수 있다. => SELinux정책에따라 허용 될 때만

semange 명령어는 관리자만이 사용할 수 있고, 어떤 사용자가 어떤 역할을 가질 수 있는지 보여준다.

newrole -r <역할>로 바꿀 수 있다. 

DSD와 같이 예를 들어 staff유저는 A,B역할이 잇을대, A역할 담당자가 휴가를 가면 다른 사람이 A역할을 잠깐 맡아서 할 수 있다.