[정보시스템보안] 벼락치기 #04

Access control은 process of granting or denying specific requests to obtain and use information and related information processing services; and enter specific physical facilities이다.

A process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities(users, programs, process, or other systems).

 

Access control은 접근 제어로, 누가 무엇이 각각의 시스템 자원에 접근할 수 있는지 여부와 그리고 각 경우에 허용되는 접근의 방식을 기술하는 보안 정책의 구현이다.

 

Access control context는 authentication, authorization, audit이 있다. user가 authentication function을 거쳐서 access control function에 접근할 때 authenticaion을 거치고, access control function통해서 system resources에 접근할 때 access control 과정을 거친다.

 

Access control policies는 DAC(discretionary access control, 임의적 접근 제어), MAC(Mandatory access control, 강제적 접근 제어), RBAC(Role-based access control, 역할 기반 접근 제어), ABAC(Attribute-based access control, 속성 기반 접근 제어)등이 있다. 

 

DAC은 전통적인 접근 제어 기법으로 요청자의 신원과 무엇을 해도 된다고 허용되었는지를 기술하는 접근 규칙에 의한 제어법이다. Discretionary은 임의적이라는 뜻인데, 어떤 대상은 원한다면 다른 대상의 접근 권한을 변경할 수 있는 권한을 가질 수 있기 때문이다.

신원에 기반한 접근 제어로, Access matrix(주체x객체)에 의해서 규정된다. 근데, Access matrix가 대부분 sparse할 것이므로, 자원 기준으로(column기준) 접근 가능한 사용자를 기술하기도 한다. 반대로 Capability tickets은 접근 행렬을 subject 기준으로(row 별로)나누어서 사용자의 권한을 확인하기에 편리하다. 이를 모두 섞어놓은 것은 Authorization table이다 subject, access mode, object로 구성된 테이블이다.

 

DAC를 general model로 하려면, 객체가 확장되어야 하는데, processes(delete, stop(block), wake up), devices(read, write, control, block, unblock), memory locations(read, write(Default is disaalow access)), subjects(권한 상속)으로 확장될 수 있다. obj에 process, device, memory location, subject가 추가되어야 한다는 뜻임. 

이를 토대로 Extended access control matrix를 만들어보면 obj에 subjects, files, processes, disk drives가 포함된다. 각각의 객체의 종류별로 controller가 있는데, 주체S가 객체 X에 대해 유형a의 요청을 하면, X의 controller에게 (S, a, X)형태의 메시지를 보내고, 접근 행렬을 읽어서 a가 행렬[S,X]인지의 여부를 확인할 수 있다. 접근 행렬 자체를 변경할 수 있는데, 행렬에 대한 접근으로 간주된다. (???) 테이블의 값으로 들어가는 곳에 *(copy flag)가 있으면 이 유형의 접근 속성을 가지면서 권한 상속이 가능하다는 뜻이다. 책갈피 테이블 보기...

보다 일반적으로 사용자 대신 protection domain들에 권한을 부여한다. 한 사용자가 여러 개의 protection domain을 생성해서 사용이 가능하고, 탄력적인 접근 제어가 가능하다.

 

MAC은 security label과 security clearance에 의한 접근 제어로, 군용시스템에서 발전 하였다. mandatory는 강제적이라는 뜻인데, 어떤 자원에 접근 가능한 보안 등급을 가진다 해도 다른 대상에게 접근을 허용할 수 있는 것은 아니라는 것이다.

 

RBAC은 사용자의 시스템에서의 역할과 주어진 역할에 대해 어떤 접근이 허용되는지를 기술하는 규칙에 의한 접근 제어이다. 사용자가 시스템에서 갖는 역할에 기반해서 접근 권한을 정의하고, 사용자는 다수의 role을 갖고, role이 개별 자원에 접근 권한을 가지는 것이다. 역할-자원은 대체로 정적이지만, 사용자-역할은 보다 동적이므로 사용자 관리에 편리하다. 사용자와 역할을 연결하는 행렬은 다대다 대응이지만, 다수의 사용자와 상대저그로 소수의 역할이 존재한다. 그리고 역할과 자원을 연결하는 행렬도 존재하고, 역시 역할이 소수이고, 자원이 다수이다. 

 

principle of least privilege는 최소 권한의 원리 구현을 위한 좋은 방법이다. 각 역할에 최소한의 권한을 제공하고, 각 사용자에게 쵯소한의 역할만 제공하고 같은 역할을 부여받는 사용자는 동일한 최소 권한을 가지는 것이다. 

 

RBAC은 RBAC0, RBAC1, RBAC2, RBAC3로 나눌 수 있는데, RBAC0은 기본 RBAC이고, RBAC1은 role hierarchy 를 포함한 모델이며, RBAC2는 constraint를 포함한 모델이고, RBAC3는 둘 다 포함한 것이다. 

RBAC 모델의 user은 시스템 사용자로 고유 ID가 부여된다, ROLE은 해당 시스템을 통제하는 조직에서의 직무이고 permission은 하나 또는 다수의 객체에 대한 특정 방식의 접근을 허용하는 것이다. 마지막으로 세션Session은 사용자와, 사용자에게 부여된 역할의 집합의 활성화 부분 집합 간의 대응이라고 하는데 책을 봐야할듯.

 

Role hierarchy는 역할 계층으로 실제 조직에서는 직위에 의한 역할의 위계가 있다. 일반적으로 상급자는 하급자의 모든 권한을 가지고 추가 권한을 가진다는 것을 적용한 것이 RBAC1이다. 

 

Permission은 mutually exclusive roles와 cardinality, prerequisite roles가 있다.

mutally exclusive roles는 상호 배타적인 역할인데, 한 사용자는 하나의 역할만을 부여받을 수 있다는 것이다. static은 원래 단 하나만 부여받는 것이고, dynamic은 한 세션에서 하나만 활성화 된다는 뜻이다. mutually exclusive permission assignments는 추가적 조치로 각 역할이 서로 배타적인 퍼미션을 배정받는 것이다. 

cardinality는 최대 개수를 뜻한다. prerequisite roles는 특정 역할을 받으려면 반드시 다른 역할을 배정받아야 한다는 것이다. 예를 들어 프로젝트 리더 역할을 배정받으려면 엔지니어 역할을 배정받은 후에 가능하다는 식이다. 만약 리더 역할이 갖는 권한이 반드시 필요하지 않으면, 하위 역할만 사용하는 세션에서 작업을 한다.

RBAC 구현 사례로는 dresdner bank가 있는데, 은행 시스템으로 다양한 appliation을 수행하면서 DAC으로 개별 사용자 권한을 개별 기기 개별 application마다 설정하다가 RBAC으로 접근 제어를 재구현 한 것이다. DAC의 테이블은 role, function, official position으로 구성된다. RBAC은 사용자당 최대 4개 역할을 받고 특정 application 사용시 하나의 역할을 선택하는 식이다.  테이블은 role, application, access right으로 구성된다. 

RBAC은 직무와 직책을 곱한 역할의 개수가 생성되는데, 쓰이는 것은 별로 없다. 공간 낭비가 심함...

 

ABAC은 속성에 기반한 접근 제어이다. 주체와 자원의 속성의 조건을 기술하는 방식이다. 융통성과 표현력이 좋지만, 각 접근마다 복잡한 predicate을 계산해야한다. 따라서 웹 페이지에서는 괜찮지만, 파일 시스템에서는 부담스럽다. ABAC의 핵심요소로는 attributes, policy model, architecture model이 있다. attribute는 속성이 주는 정보의 종류, 이름 값 등의 정보를 포함하는데, 주체 속성, 개게 속성, 환경 속성으로 나눌 수 있다. 주체 속성으로는 identifier, name, organization, job title, role등등이 있으며, 객체 속성으로는 title, subject, datee, author 등 주로 metadata로 저장된다. 환경 속성은 접근이 이루어지는 조작적, 상황적, 기술적, 문맥 등이 포함되는데, 현재 날짜나 바이러스/해커 활동 상황, 보안 레벨 등이 포함된다. ABAC은 속성에 의한 rule evaluation에 기반하므로 boolean operation을 이용해 복잡한 논리 규칙을 만들 수 있다. 또한, flexible하게 , DAC, RBAC, MAC등도 구현가능하고, 바꿀 수도 있고 RBAC위에 구현할 수도 있다.

궁극적인 신뢰 근원은 object owner로 특정 사용자가 ACL에 등록되서 객체에 접근이 가능하려면 owner가 필요하다. 그치만 또 다른 신뢰 근원은 object owner가 통제하지 못하는 많은 주체들인데, subject attribute authorities나 policy develpers, credential issuers가 있다. 기업의 ABAC 구현은 기구를 구성할 것을 권고함..(SP-800-162)

ABAC policy 모델은 함수 형태로도 적을 수 있는데, policy rule base(policy store)은 여러개의 rule들로 이루어진다. 

코드 보기 넷플릭스...

 

 

Subject는 object에 액세스할 수 있는 entity인데, owner, group, world가 있다.

object는 access에 의해 컨트롤되는 자원으로, 파일, 디렉토리, 프로그램이 있다.

 

Access right는 sub가 obj에 접근하는 방식으로, read, write, excute가 있다. 

read는 copy, print를 포함하며, wirte는 add, modify, delete와 함께 read를 포함하는 개념이다.

search한다는 것은, list the files한다는 것임.

 

UNIX 파일 시스템에서의 inode(index node)는 특정 파일에 대한 핵심적인 정보를 담고 있는 구조이며 active inode와 file은 일대일 대응이다. Directory는 계층적 트리로 구성되고, 각 directory 밑에는 파일 혹은 subdirectory가 존재한다. 단순히, file name과 대응 되는 inode로의 포인터들의 목록을 담은 하나의 파일으로 볼 수도 있음.

 

UNIX의 접근 제어에서의 UID는 사용자가 갖는 고유의 user identificaion number이다. 

GID는 사용자가 다수의 group에 속할 수 있는데, 그 group이 갖는 number이다.

Protection bits는 각 파일의 접근 권한을 나타내기 위한 bitfield로 최소 12비트이다.

파일 생성 시 특정 사용자의 소유가 되고 그 사용자의 ID에 속하게되고, 특정 group에 속하게 된다.

이러한 UID, GID, protection bits는 inode에 저장된다.

 

디렉토리의 경우 read는 파일 목록을 읽을 권한, write는 디렉토리에 파일을 생성/이름변경/삭제할 권한을 나타낸다. execute는 디렉토리로 들어가거나 내부를 검색할 권한을 말한다.

 

보호 비트가 12비트라고 했는데 나머지 3비트는 setUID, setGID, sticky bit을 나타낸다.

setUID는 user class 부분에 x대신 s로 나타나고, 파일에만 적용된다. 

디렉토리에 setGID가 부여될 경우에 해당 디렉토리에 신규 생성된 파일은 해당 디렉토리의 group을 따른다.

이 친구는 group class 부분에 s로 나타난다.

 

sticky bit은 원래는 실행 후 파일의 내용을 메모리에 보존하라는 의미로 쓰인다. 네트워크로 일일이 가져오기에 시간이 너무 오래 걸렸던 옛날에는 이렇게 쓰였다고 한다. 현재는 그렇게 쓰이기 보다는 해당 디렉토리 내의 파일의 소유자만이 그 파일을 개명/이동/삭제할 수 있다는 뜻으로 쓰인다. /tmp /var /tmp등의 777permission을 가지는 공용 디렉토리에서 함부로 남의 파일을 삭제하지 못하게 하기 위해 쓰인다.

other class 부분에 s로 나타난다. 

 

정리하자면, 전통적인 UNIX 접근제어는 user, group, world 기준으로 접근 허용/불허이고, 대체로 DAC을 따르지만, 단순화되고 제약이 있는 버전의 모델을 사용하며 많은 현대적인 Unix-like os들은 이를 보완하기 위해서 ACL을 추가로 포함한다.