접근제어는 특정요청에 대해 권한을 부여하거나 거부하는 과정을 말 하는데, 시스템 리소스를 보안 정책에 따라 규제하는 과정입니다. 이는 권한이 있는 사용자, 프로그램 또는 시스템만이 정책에 따라 접근할 수 있도록 합니다.

Authentification 은 사용자가 본인임을 인증하는 과정입니다.
사용자는 시스템에 접근하기 위해 본인임을 인증해야 하는데, 본인임을 인증하기 위해 사용자는 시스템에 로그인하거나, 자격증명(id, 비밀번호, 인증토큰) 등을 제출합니다.
Authentification function이 이를 받아, 인증 데이터를 참조하여 사용자의 신원을 확인합니다. 이 단계에서 본인임이 밝혀졌으면, 해당 사용자에게 권한을 넘겨줄지 Authorization의 단계로 넘어가고 실패하면 접근이 차단됩니다.
Authorization단계로 넘어가면, Access control function 은 사용자가 접근하려는 시스템 리소스에 대해 해당 사용자가 어떤 권한을 가지고 있는지 Authorization DB를 확인합니다.
Authorization DB에는 사용자가 가진 역할, 정책, 권한등을 저장하고 있는데, 사용자의 접근 요청이 데이터베이스 속의 권한과 동일한지 비교하여 요청한 권한을 부여할 것인지 결정합니다.
그리고 이 모든 과정은 기록되는데, 사용자의 모든 접근시도를 기록하고, 시스템 자원에 대한 접근을 추적합니다. 성공했거나 실패한 기록 모두 Audit System에 기록하여, 관리자는 추후에 시스템 내 활동을 검토하고, 의심스러운 행동이 있었는지 확인할 용도입니다.
접근 제어 방식에는 네가지 유형이 존재하는데, DAC, MAC, RBAC, ABAC 이고 오른쪽으로 갈수록 상위버전입니다.
간략하게 각각의 주요 특징을 설명해보자면,
DAC, MAC 은 subject 기반으로 rule을 정의한 접근 제어방식입니다.
RBAC은 subject의 role 기반으로 rule을 정의한 접근제어 방식입니다.
ABCA은 subject의 Attribute 기반으로 rule을 정의한 접근제어 방식입니다.
DAC은 Discretionary Access Control 의 약자로 전통적인 접근제어 방식입니다.
사용자가 자신이 소유한 리소스에 대한 다른 사용자의 접근 권한을 제어할 수 있습니다. 즉, 자원의 소유자가 자율적으로 타인의 접근 권한을 임의로 바꿀 수 있는데, 임의로 설정하다보니 보안에 취약합니다.
DAC의 방식이 보안에 취약하다보니 도입한게 MAC입니다.
Mac은 Mandatory Access Control의 약자로, 시스템 내에서 사용자는 시스템관리자에게 권한을 미리 부여받습니다.
DAC과 달리, subject은 다른 subject 의 접근을 제어할 수 없습니다. Mandatory 의 의미는, 인가된 엔터티가 자의적으로 다른 엔터티에게 접근을 허용할 수 없다는것을 의미합니다.
즉, 시스템 내에서 자신의 보안 인가 수준에 맞는 자원에만 접근할 수 있고, 시스템은 사용자의 인가수준과 자원의 보안레벨을 비교하여 접근을 허용하거나 거부합니다.
DAC, MAC 은 subject 기반으로 rule을 정의한 접근 제어방식입니다.
즉, user based로 권한을 부여하거나 부여하지 않고, 각 user의 권한을 정의하기 위해 subject identify가 필요합니다.
이 둘의 차이점은
DAC방식은 소유자 subject가 특정 subject의 권한을 바꿀 수 있습니다.
MAC방식은 subject는 system administrator에게 권한을 부여받고, 해당 권한은 다른 사람에 의해 변경될 수 없습니다.
예전에는 이렇게 subject관점에서 권한을 부여하다 role based로 접근권한을 부여하는 RBAC이 도입되었고 가장 많이 쓰이는 방식입니다.
이렇게 role기반으로 접근제어를 하게 된 배경이 있는데, subject Id기반으로 rule을 정의하게되면 subject identifier가 바뀔 때마다 접근 권한 Database 를 계속해서 업데이트 해주어야 하기 때문입니다.
예를들어 subject1은 사장이여서 A건물에서 공간예약 권한을 가지고 있었습니다.
그리고 이 권한은 데이터베이스에 저장해놓고 Authorization 의 단계에서 가져와 쓰고있었습니다.
이 상황에서, 사장이 subject2 으로 바뀌는 경우 데이터베이스 내의 해당 권한에 대한 subjectId 를 subject2의 것으로 변경하여 subject2에게 접근권한을 부여해야합니다. 또한, subject1 의 접근권한은 지워야 할 것입니다.
이렇게 수고로운 과정이 user가 바뀔때마다 반복되는 이유는 subject Id기반으로 rule을 정의하였기 때문입니다.
만약, 같은 상황에서 role을 기반으로 접근 권한을 부여하게 된다면, 즉 사장은 A 건물에서 공간예약 권한을 가진다. 라는 내용만을 DB에 저장해준다면 사람이 바뀌어도 사람에 대한 role 테이블만 업데이트 해주면 될 뿐 접근 권한 DB를 업데이트 해줄 필요가 없게 됩니다.
subject와 object의 관계를 다음과 같이 matrix로 표현할 수 있습니다. 각각의 내용엔 user가 특정 system resouce에 수행할 수 있는 action들을 담고있습니다.

그러나, matrix은 sparse한 공간들이 있기때문에 비효율적입니다.
그래서 이 matrix 를 열단위로 분리한 ACL(Access Control List) 으로 만들어 사용하거나, 행단위로 분리한 Capability tickets 을 이용합니다.

열단위인 object별로 분리했기 때문에, 특정 자원에 어떤 user가 어떠한 권리를 가지고 있는지 object wise하게 확인하기 좋습니다.
그러나, subject별로 보려면 모든 list를 순회해야 하므로 비효율적입니다.
행단위인 subject 단위로 분리했기 때문에, subject가 가지고 있는 리소스에 대한 접근권한을 보기 좋습니다.
반대로, object wise하게 특정 파일에 누가 접근권한을 가지고 있는지 확인하기 위해선 모든 Capability tickets 을 확인해야 합니다.
권한과 시스템 지원을 확장시켜 생각해보면, user가 접근할 수 있는 시스템 자원에는
Processes, Devices, Memory locations, Subjects 가 있을 수 있습니다.
Subjects 가 object으로 존재하는 이유는, DAC방식에서는 특정 subject가 다른 subject의 권한을 제어할 수 있기 때문에 Subjects를 일종의 자원으로 본 것 입니다.

이를 똑같이 행렬로 표현할 수 있습니다.
그리고 DAC방식에서는 특정 subject가 다른 user에 대한 권한을 변경하게 됩니다.
이 행렬은 authorizatoin 과정에서 쓰이는데, user가 file1 에 대해 읽기권한을 요청하면, 요청이 access control system으로 넘어가 메세지가 생성되고, 해당 메세지는 해당 자원에 대한 controller으로 넘어가 matrix를 읽고 file1 에 대해 읽기권한이 user에게 존재하는지 확인 후에 권한을 부여할 지 결정합니다.
표에서 보이는 * 은 copy flag 을 의미합니다.

DAC에서는 자원의 소유자 subject가 해당 자원에 대한 접근권한을 타인에게 부여할 수 있는데, action 옆에 copy flag을 붙어있다면, 권한이 다른사람에게 부여될 가능성이 있음을 나타냅니다.
예를들어, a라는 권한은 s0에 의해 다른 subject에게도 해당 a라는 권한을 부여할 수 있는데, 만약 권한을 수정하여 다른 subject에게 a권한을 부여하는 경우, 권한을 부여받은 사용자도 또 다른 subject에게 권한을 부여할 수 있을지 없을지 copy flag을 이용해 지정해줄 수 있습니다.
즉, 타인에게 권한을 넘겨줄 권리를 포함하여 copy flag 붙여서 줄수도 있고, copy flag 를 붙이지 않고 접근 권한만 부여할 수 있습니다.
만약 flag를 같이 받으면, 권한을 부여받은 s2도 다른 사용자의 a에 대한 권한을 변경할 수 있습니다.