[컴보] 4강 - Access Control

ITU-T Recommendation X.800의 Access Control 정의

- 인가받지 않은 자원 사용을 막기 + 인가받지 않은 방법으로 자원 접근 막기

RFC 2828의 computer security 정의

- security service를 보장하고 구현하는 방법, 특히 access control service를 보장

 

Relationship Among Access Control and Other Security Function

User가 System Resource를 사용하려고 할 때

1) Authentication 통과 (Authentication Function 통해)

2) Access Control 통과 (Access Control Function으로 Authorization DB 참조하여)

- Authorization DB는 Security administrator가 관리하고 1, 2 과정의 log를 남겨 Auditing(감사) 함

(여기서 Authentication, Access Control, Auditing이 AAA에 해당)

 

Access Control Ppolicies (접근 통제 정책) - 각각 겹치는 부분 존재

- Discretionary Access Control(DAC), Mandatory Access Control(MAC), Role-Based Access Control(RBAC)

 

Access Control Requirements(접근 통제 요구사항)

- reliable input(믿을 수 있는 입력)

- support for fine and coarse specifications(통제를 세밀하게 하거나 큰 단위로 하거나 둘 다 가능해야 함)

- least privilege(***필요한 최소한의 권한만 주어야 함***)

- separation of duty(중요한 업무를 분할해야 함)

- open & closed policies(공개 & 비공개 보안 정책)

- policy combinations and conflict resolution(정책 업데이트나 정책 간 충돌 시 해결방법)

- administrative policies(관리자 정책)

- dual control(중요한 업무는 둘이서)

 

Access Contorl Basic Elements

- Subject : 접근을 할 개별 사용자 + 사용자 프로세스(주로 owner, group, world라는 3 클래스로 나뉨)

- Object : 접근 제한을 받아야 하는 자원(or 프로세스)

- Access right : Subject가 Object에 접근할 수 있는 권한의 종류 (ex. read, write, execute, delete, create, search)

 

Mandatory Access Control (MAC) - more restrictive scheme

- Resource(Object)와 User(Subject)가 각각 security level이 존재 - 각각의 레벨을 보고 접근 가능성 결정 (ex. 군대 문서 열람 권한)

- Security-Enhanced Linux (SELinux)에서 사용됨.

 

Discretionary Access Control (DAC)

- 주로 Access Matrix를 제공, matrix에 있는 각 entry들이 특정 subject가 특정 object에 어떤 access right를 가지고 있는지를 가리킴

문제점 : Subject 수가 늘어남에 따라 Object의 수가 엄청 늘어나고 Matrix 사이즈가 거대해진다. 또한 대부분의 Object들은 하나의 Subject하고만 Access Right을 가지게 되므로 Access Matrix가 Sparse Matrix가 된다. 즉, 비효율적이다. 또한 사용자 추가/제거, 파일 생성/제거도 그 숫자만큼의 row와 column을 추가해줘야하므로 overhead가 크다.

-> Matrix 대신 Linked List로 대체

(b)는 File 기준으로 Access Right이 있는 User를 Linked List로 관리한 것이고 (c)는 반대로 User 기준으로 Access Right가 있는 File을 Linked List로 관리

 

Authorization Table for Files : Subject, Access Mode, Object의 column으로 구성된 테이블

 

Extended Access Control Matrix

하나의 Subject에 대해서 파일 뿐 아니라 다른 Subject, files, processes, disk drives에 대한 Access Control도 관리

 

Access Control Function

File 접근시 : File System이 Access Matrix를 참조해서 컨트롤

Process Wakeup 요청시 : Process Manager가 Access Matrix 참조해서 컨트롤

Sa가 Sb에게 X object에게 a라는 권한을 줄 때(박탈할 때) : Access Matrix Monitor가 Sa의 grant 또는 delete 권한을 보고 권한을 수정

 

Access Control System Commands

Access Control Monitor에 요청할 수 있는 commands

 

Protection Domains

- 개별 object가 아닌 object set을 묶어서 Access right를 표시 ->capability를 더 유연하게 나타낼 수 있음

- Access Matrix의 한 row가 Protection Domain을 나타낼 수 있음.

- 사용자가 새로운 프로세스를 fork해서 만들었을 때 Protection Domain의 Access rights의 subset을 부여할 수 있음.

 

UNIX File Access Control

- i-nodes (index nodes)

  - 특정 file에 대한 key information을 담고있는 control structure

  - 여러 파일 이름이 하나의 i-node에 할당될 수 있음.

  - 하나의 active한 i-node는 하나의 파일에 할당됨.

  - file attributes, permissions, control information 등이 저장되어 있음.

  - disk가 i-node table or i-node list를 가지고 있어서 file system 관리

  - 파일 열 때 i-node 정보를 load해 처리할 수 있음.

- directories (hierarchical tree)

  - 디렉토리도 파일처럼 관리되며 특정 파일이나 디렉토리가 포함될 수 있음.

  - 특정 파일의 삭제에 대한 권한은 해당 파일의 permission 말고 directory의 write 권한이 있어야 가능

Owner / Group / Other 의 read, write, execute 권한을 9bit로

set user ID - SetUID bit (ex. rwsr--r--)

set group ID - setGID bit (ex. rwxr-sr--)

= 일반적인 x라면 파일을 실행한 user나 group의 권한으로 실행하지만 s라면 일시적으로 파일 원래 소유자 권한으로 실행

-> 대표적으로 root가 소유한 passwd에 설정되어 있음(r-s) -> 그렇기 때문에 일반 사용자가 password를 변환할 때 root의 권한으로 수정할 수 있게 됨.

sticky bit : directory에 설정되어 있으면 해당 directory 내부의 파일 소유자만 해당 파일의 rename, move, delete 가능

-> 대표적으로 /tmp directory -> 사용자만 해당 폴더의 임시 파일을 수정 가능.

superuser : 시스템의 모든 권한이 존재

 

Access Control Lists(ACLs) in UNIX

- 최근 UNIX 계열 OS는 ACLs만 지원 : FreeBSD(Setfacl command로 리스트 할당 가능), OpenBSD, Linux, Solaris 등

- 파일 시스템 object에 대한 access 요청 시 처리 단계

  1) 가장 적절한 ACL을 선택해서 권한 확인 -> 2) 권한이 없으면 permission bit 확인

 

Role-Based Access Control (RBAC)

- Role에 따른 접근 권한을 설정해두고 User를 해당 Role에 할당시켜서 접근권한을 주는 방식

- 하나의 User는 1개 이상의 Role에 할당 가능.

- 하나의 Role에는 1명 이상의 User가 할당 가능.

신규 User가 추가시 Role에 할당만 시켜주면 됨 - ex) 학생 추가시 학생의 role에 할당해주면 됨

RBAC의 Access Control Matrix

RBAC의 Access Control Matrix는 User와 Role의 관계를 표시하는 Matrix와 Role과 Objects의 접근권한을 표시하는 Matrix로 나뉨

- Role은 Hierarchy가 존재할 수 있음 (ex. 직원 - 관리자)

- Role에 대한 Permission을 줄 수 있음.

- User가 Login하면 session이 생기는데 이 session을 role과 매핑해줌.

- User와 session, role과 session, role과 permission과의 관계 등에서 Constraints(제약사항)를 줄 수 있음. ex) 세션 개수 제한, 하나의 role만 permission을 가질 수 있다 등

 

Contraints - RBAC

- 기관의 보안 정책에 따라 제약 조건을 걸 수 있음.

- 종류 :

  - mutually exclusive roles : ex) 하나의 사람이나 permission은 mutually exclusive한 set에 있는 하나의 role에만 할당.

  - cardinality : maximum을 정하는 제약 조건 ex) 최대 몇개까지의 role에 할당 가능한가

  - prerequisite roles : 어떤 role을 하기 위해 사전에 가져야 하는 role에 대한 제약 조건 ex) 선수강

 

NIST RBAC Model

UA나 RH는 Static하게 제약조건 할당 / Session-Role은 Dynamic하게 제약조건 할당

 

Basic Definitions

- Object : Subject가 접근하는 System resocrce (파일, 프린터, 터미널, DB 레코드 등)

- Operation : Executable image of a program. 작업을 하기 위한 연산

- Permission : Subject가 Object에 Operation을 수행하는 것을 허락하는 것

 

Core RBAC

- administrative function : 사용자 / role / user-role 할당 / role-permission 할당 등 추가 및 삭제

- supporting system function : user session 생성 / session에 role을 추가 및 삭제 / session이 object의 operation에 대한 permission이 있는지 확인

- review function : 관리자가 role assignment, permission assignment를 보고 관리

 

Hierarchical RBAC

- general role hierarchies : role hierarchy 사이에 partial ordering이 가능하도록

- limited role hierrarchies : 간단한 tree structure가 되도록 cycle이 발생하지 않도록 제어. ascendanat 노드는 1개 이상 가질 수 있지만 descendant는 하나만 갖도록

 

Static Separation of Duty Relations (SSD)

- 정적, mutually exclusive role이나 role에 대한 cardinality 등...

 

Dynamic Separation of Duty Relations (DSD)

- 동적, user session에 대한 제약사항. session에 대한 cardinality

 

 

Attribute-based Access Control (ABAC)

- attribute를 결합해서 policy를 결정

- ex) 사용자 속성(나이, role, job 등), 자원 속성(read, delete, view ..), 환경 속성(object type ..) 등

-Example : Policy(매니저는 자신이 속한 지역의 거래내역만 볼 수 있다) -> role == manager은 action == SELECT on table == TRANSACTIONS if user.region == transaction.region 을 할 수 있음.