Access control

for 중간고사 정리는 학기끝나고,,

Access control

매우 넓은 의미에서 접근제어는 보안의 모든것을 포함할 수 있는데 좁은 의미로는, 특정 시스템 리소스에 대한 접근을 허용할 수 있는 주체(사용자 또는 프로세스)와 각 접근의 허용 유형을 규정하는 보안 정책을 구현하는 것을 의미합니다.

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

접근제어 맥락

접근제어의 주요 요소는 세가지인데, Authentification, Authorization, Audit으로 이루어져있다. 사용자가 본인임을 확인하는 과정을 Authentification이라고 하는데, 사용자는 시스템에 접근하기 위해 본인임을 인증해야한다. 본인임을 인증하기 위해 사용자는 시스템에 로그인하거나, 자격증명(id, 비밀번호, 인증토큰) 등을 제출하는데, Authentification function이 이를 받아, 인증 데이터를 참조하여 사용자의 신원을 확인함. 이 단계에서 본인임이 밝혀졌으면, 해당 사용자에게 어떠한 권한을 넘겨줄지 Authorization의 단계로 넘어가고, 실패하면 접근이 차단됨.
// 그래 너 본인인건 알겠어 이제 너가 요청하는 시스템에 대한 접근이 너가 가진 권한과 일치하는지 확인 한 다음에 부여해줄게 의 과정이 필요한 것임 //
Authorization단계로 넘어가면, Access control function 은 사용자가 접근하려는 시스템 리소스에 대해 해당 사용자가 어떤 권한을 가지고 있는지 Authorization DB를 확인함.
Authorization DB에는 사용자가 가진 역할, 정책, 권한등을 저장하고 있는데, 사용자의 접근 요청이 데이터베이스 속의 권한과 동일한지 비교하여 요청한 권한을 부여할 것인지 결정함.
Audit은 말그대로 도청을 의미함. 이 모든 과정은 기록된다. 사용자의 모든 접근시도를 기록하고, 시스템 자원에 대한 접근을 추적하는 과정인데, 성공했거나 실패 시도 모두 Audit System에 기록하여, 관리자는 추후에 시스템 내 활동을 검토하고, 의심스러운 행동이 있었는지 확인할 용도임.

접근제어 방식의 네가지 유형

접근 제어 방식에는 네가지 유형이 존재함. 위로 갈수록 상위버전
DAC, MAC, RBAC, ABAC

DAC (Discretionary Access Control)

사용자가 자신이 소유한 리소스에 대한 다른 사용자의 접근 권한을 제어할 수 있음. 즉, 자원의 소유자가 자율적으로 타인의 접근 권한을 임의로 바꿀 수 있는데, 임의로 설정하다보니 보안에 취약함. 전통적인 접근제어방식.
더 쉽게 말하면 subject는 스스로가 다른 subject의 권한을 변경할 수 있음.
보안에 취약하다보니 MAC을 도입함.

Mac (Mandatory Access Control)

mandatory : 인가된 엔터티가 자의적으로 다른 엔터티에게 접근을 허용할 수 없다는것을 의미함. 시스템 내에서 자신의 보안 인가 수준에 맞는 자원에만 접근할 수 있고, 시스템은 사용자의 인가 수준과 자원의 보안 레벨을 비교하여 접근을 허용하거나 거부함. 높은 보안 수준으로 군대에서 사용함.

Mac vs Dac

둘은 공통적으로 subject 관점에서 관리되는데, subject가 다른 subject에 대한 접근 권한을 제어할 수 있는지 없는지에 대한 차이가 존재한다.

DAC: subject는 다른 subject에게 권한을 바꿀 수 있다.
MAC: subject는 system administrator에게 권한을 부여받고, 해당 권한은 다른 사람에 의해 변경될 수 없다.

RBAC (Role-Based Access Control)

사용자의 역할을 기반으로 접근권한을 부여하는 방식이다.
사용자는 시스템에서 역할이 부여되고, 해당 역할에 따른 어떤 접근권한이 있는지에 기반하여 접근을 제어함. 이는 이전의 접근 제어 방식과는 완전히 비교되는데, mac, dac 과의 가장 큰 차이점은 subject identity 에 따라 권한이 부여되는것이 아닌, 역할에 의해 권한이 부여되는것이다.

가장 유명한 접근제어방식임

dac, mac vs rbac, abac
mac, dac = ( 특정 subject는 어떠한 행위를 할 수 있다/없다) subject identifier가 존재하는데, user의 권한을 정의하기 위해 필요함
RBAC = role user id 나 user subject를 이용해서 정의하지 않고, role를 이용해 define함.

subject관점에서 rule들을 만들다 role based으로 바뀌게 된 이유

예를 들어 DB에
P(subject Id)에게 공대(object)에서 Space allocation(action)을 할 수 있다고 권한을 부여함 -> DB에 기록.
P가 떠나고 새로운 사람이 P2가 되는 경우, subjectID가 바뀌기때문에 기존의 DB기록을 수정해줘야한다.

이 방식이 반복되는 이유는 **subjectId기반으로 rule이 정의되었기 때문이다.

이 문제를 해결하기 위해선 Rbac을 이용해서, subject identifier 대신에 role기반으로 어떤 action을 할 수 있는지 권한을 부여하면 subject 이 바뀔때마다 db를 수정하지 않아도 된다.

subjectId에 따른 role을 알맞게 매칭하는 과정이 필요하고, 사람과 role이 바뀌었을때 테이블만 업데이트 해주면 됨

더 발전한건 ABAC. Attribute가 key factor이다. user의 Attribute에 의해 access control rule이 정의되는데, 예를 들어 의료관련진, 성별 등으로 구별하거나, environmental condition으로도 rule을 정의할 수 있음.

접근 제어에서 가장 베이직 element 은 subject이다.

subject: an entity capable of accessing objects

• owner // 주인이 될수도 있고
• Group // 그룹이 될수도 있음
• World

Object : 접근이 controll되는 resource 를 의미함. 예를 들어 파일 디렉토리 프로그램 등등 접근을 제어하고자 하는 시스템상의 모든 자원을 의미함

Access right : 대표적으로 read(copy or print),write(add, modify, delete, read), Delete, Create( file, record, field를 생성 ), Search(list a file in directory or Search for the directory)

Dac

1. Access Matrix으로 정의할 수 있음.

행과 열은 subject와 object으로 이루어져있는데, 행에는 시스템상의 모든 user으로 이루어져있고, 열에는 시스템 상에서 자원을 표현하고 있음.

matrix는 sparse하게 듬성듬성 빈 부분이 존재하기 떄문에 메모리 공간 효율 문제 해결을 위해 matrix보다는 List의 형태인 ACL을 이용함.

matrix의 공간효율문제를 list로 해결 _ ACL

2. ACL ( Access Control List ) _ matrix의 열

Matrix에서 열 을 뽑아내어 해당 자원에 대한 접근 권한을 Object wise하게 LinkedList 으로 만든것이다.

각각의 object에 대해 ACL list은 User와 해당 user가 가지고 있는 접근권한을 가지고 있음

장점 :
1. fileA 에 대해 a,b,c가 권한을 가지고 있고 각 user에 대한 권한은 어디까지 부여됐는지 확인 가능
2. resource wise하게 파일별로 어떤 권한이 어떤 사람에게 부여됐는지 바로 찾아낼 수 있음.
단점:
특정 subject가 어떤 자원에 권한을 가지고 있는지 확인하기 위해서는 list를 모두 탐색해야됨.

3. Capability Ticket _ matrix의 행
   access matrix를 행으로 나누어 본 것 . subject별로 분리했으니 각 subject가 어떤 권한을 가지고있는지 확인하기 좋음. 반대로, resource wise하게 확인하기는 어렵다. 특정 파일에 누가 접근권한을 가지고 있는지 확인하기 위해선 모든 ticket을 확인해야함

정리하자면, Access Matrix 의 행은 subject, 열은 object으로 이루어져 각각의 접근 권한에 대한 정보가 기록되어있는데, sparse하기 때문에 공간 효율을 위해 행렬의 열을 기준으로 잘라 list형태로 표현한 ACL이 존재하고, 행을 기준으로 잘라 표현한 Capability ticket이 존재한다.
열(object)을 기준으로 자르면, object별 관찰이 용이해지지만, 사용자에 대한 정보를 찾기 위해선 모든 리스트를 탐색해야함.
행(subject)을 기준으로 자르면, subject별 관찰이 용이해지지만, object별 정보를 확인하려면 모든 티켓을 확인해야함.

Authorization table

General model for Dac

Extended access Control matrix

앞의 기술들을 Dac에 적용시키고, object과 object 에 대한 접근권한을 확장시켜 생각해보자. Process, device, memory allocation등이 object이 될 수 있는데, 각각의 권한으로는 프로세스를 delete, block, wake up 할 수 있는 권한, 혹은 device를 read/write, 운영체제를 control, block/unblock 메모리의 특정 영역에 대한 read/write 권한등으로 확장시켜 생각할 수 있음.

이것을 똑같이 matrix으로 표현

차이점:

subject를 열에도 두어 특정 subject가 subject에 가지는 권한을 나타냄.

Dac에서는 subject가 특정 subject에 대한 권한을 바꿀 수 있으니, 바꾸려는 대상 subject를 object으로 보아 각 사용자가 사용자에게 가진 접근권한을 표현함.

이것을 더 포멀한 방법으로 표현할 수 있는데,

예를들어 $S_0$ 는 file1에 대한 읽기권한 a를 req했다.

요청이 들어오면, 메세지가 access control system에 의해 생성되고, 해당 형태의 메세지는 x에 대한 controller에 넘어간다.

controller은 matrix를 읽어, 접근 권한 유형이 행렬에 존재하는지 즉, $S_0$ 의 X에 대한 a권한이 존재하는지 확인함. 만약 있다면 allowed됨.

여기서 some subject은 자기 자신에 대한 access matrix에 대한것을 바꿀 수 있음
admin이나 root은 자기가 다른 사람에 대한 권한을 matrix을 바꿀 수 있음

copy flag

권한이 다른사람에게 부여될 가능성이 있음을 나타냄

a * 으로 표현한다.

a라는 권한은 s0에 의해 다른 subject에게도 해당 a라는 권한을 부여할 수 있는데, 만약 권한을 수정하여 다른 subject에게 a권한을 부여하는 경우, 권한을 부여받은 사용자도 또 다른 subject에게 권한을 부여할 수 있을지 없을지 copy flag을 이용해 지정해줄 수 있음.
만약 같이 받으면, 부여받은 s2도 다른 사용자에 대한 권한 변경 가능.

Unix file system

Unix file system

• inode :인덱스노드
  -특정 파일에 대한 주요 정보를 포함하는 구조체
  파일 시스템의 핵심 개념 중 하나로 파일의 메타데이터를 저장함
  활성화된 inode 과 파일은 1:1로 대응됨.
• 디렉터리
  디렉터리는 계층구조의 트리형태로 구성되어있는데 각 디렉터리는 파일 또는 하위디렉터리를 포함함. 디렉터리 자체도 파일이며, 파일 이름과 해당 파일에 대한 inode 포인터 목록을 가지고 있는데, 디렉터리 내 파일을 연결하는 역할을 한다.
  A directory is simply a file containing a list of file names + pointers to associated inodes.

Unix file access control

UID : 각 사용자는 고유한 사용자 식별번호를 가짐
GID : 사용자는 여러 그룹에 속할 수 있으며, 각 그룹은 고유한 그룹 식별 번호인 GID를 가짐
보호비트 : 각 파일에 대한 접근권한을 나타내는 비트필드. 최소 12bit으로 구성되어있음. (read/write/execute) + 나머지 3비트

파일이 생성되면, 특정 사용자가 소유자로 지정되고 생성한 사용자의 기본 그룹에 속하게 됨. 이때, UID, GID, 보호비트는 모두 inode에 저장된다.

아래처럼 9bit으로 이루어져 있는데
순서대로 Owner, Group, Other 임

예를들어 사진에서는 group에게 읽기 권한이 부여되어있는것을 확인할 수 있는데, 이 경우는 그룹 내의 사람들은 read할 수 있음을 의미함.

디렉터리에 대한 접근제어

유닉스 파일에는 일반파일과 디렉터리 파일이 있는데, directory는 list of file을 의미함. 디렉터리 파일에도 read, write, execute 권한이 있는데,
read: 디릭터리 내 파일 목록을 열람할 수 있는 권한 ex) ls dir
write : 디렉터리 내에서 파일을 생성, 이름 변경 또는 삭제할 수 있는 권한
execute : 디렉터리 안으로 이동하거나, 디렉터리에서 파일 이름을 검색할 수 있는 권한

이때, 디렉터리에 대한 실행권한이 없으면 해당 디렉터리로 진입도 못하고, 파일 목록조차 열람할 수 없음. 즉 실행권한이 없다면 read write권한이 있어도 기능을 제대로 사용하지 못할수도 있음

디렉터리 관련 명령어

ls -l : 현재 디렉터리 파일과 디렉터리 목록을 자세히 출력하는 명령어

drwxr-xr-x 3 aaram staff 96 Aug 29 2018 bin
d : 디렉터리다.
소유자인 아람은 staff그룹에 속해있으며, 소유자는 읽기, 쓰기, 실행권한을 모두 가지고 있으며, 소유자가 속한 그룹인 staff그룹에 속한 사람들은 읽기, 실행권한을 가진다. 그리고 그 외 사용자들은 읽기와 실행권한만 가지고 있음
3 : 디렉터리가 포함하고있는 하위 디렉터리 또는 파일의 수
아람 : 소유자
staff : 디렉터리가 속한 그룹 명
96 : 파일 크기 (바이트)
마지막 수정 날짜
bin : 디렉터리의 이름

ls bin
bin 디렉터리 안의 파일목록을 출력하는 명령어
foobar : bin디렉터리 안에 있는 파일 또는 디렉터리이름

chmod 655 bin

bin 디렉터리의 권한을 655로 바꾼다.
아람은 6(4+2+0 = 읽기,쓰기) 권한을 가지고, 디렉터리가 속한 그룹은 5(4+0+1 = 읽기, 실행) 권한을 가지고, others도 마찬가지.

또다시 ls-l해서 찍어보면
아람에 대한 실행권한이 사라져있는것을 확인할 수 있음

이때 cd bin하여 bin디렉터리 내부로 진입하게되면, 이동할 수 없는데 이는 아람의 bin디렉토리에 대한 실행권한이 사라졌기 때문이다.

디렉터리에 대한 실행권한이 없으면 해당 디렉터리로 진입할 수 없음

setUID / setGID

SetUID: 프로그램이 실행될 때, 해당 파일 소유자의 권한으로 실행되도록 설정.
SetGID: 프로그램이 실행될 때, 해당 파일이 속한 그룹의 권한으로 실행되도록 설정.
Sticky Bit: 주로 디렉터리에서 사용되며, 파일을 이동하거나 삭제할 수 있는 권한을 제어하는 기능인데 주로 공유디렉터리에서 사용됨

setUID는 파일을 실행하는 동안 사용자가 해당 파일의 소유자 권한으로 작업을 수행할 수 있게 만듬 예를들어, 파일 x의 소유자 $S_0$가 존재함. 그리고 다른사람 S가 파일을 실행하려고 하면 만약 해당 setUID를 on한 상태이면 소유자의 권한이 일시적으로 주어짐

setUID 예시

$ ls -l /etc/shadow
-rw------- 1 root root 823 Dec 7 19:59 /etc/shadow

/etc/shadow
password file은 해싱된 형태로 shadow폴더 안에 존재한다.

그리고 보면, root만이 읽거나 쓸 수 있는 권한을 가지고 있는것을 확인할 수 있음
이 상태로는 일반사용자는 섀도우파일에 접근할 수 없다.

이 상태에서, 일반사용자가 비밀번호를 바꾸고 싶어서 passwd명령어를 통해 setUID를 설정할 수 있음.

passwd를 열어 확인해보면 루트의 실행권한 비트 부분이 s로 되어있는것을 확인할 수 있는데, 이는 setUID이 설정됨을 의미함.
// passwd는 명령어이고, 해당 파일을 ls을 통해 파일속성을 보면 s가 켜져있는것을 확인 가능

$ ls -la /usr/bin/passwd /// 이 자체가 명령어임 setUID가 설정된 명령어 passwd
-rwsr-xr-x 1 root root 42824 Sep 13 2012 /usr/bin/passwd

결과는 이렇게 뜨는데, 루트소유자에게 setUID권한이 있는것을 확인할 수 있다.

일반사용자가 passwd명령어를 사용한다면, 루트 사용자 권한으로 일시적으로 동작하여 일반사용자는 루트 권한을 이용해 섀도우 파일의 비밀번호를 변경할 수 있음
이또한 ls를 통해 파일속성을 뽑아 확인해보면 아래와 같이 setUID권한 비트가 on상태인것을 확인할 수 있다.

ls -l /usr/bin/sudo
-r-sr-x--x 1 root wheel 370720 Nov 30 16:37 /usr/bin/sudo

명령어 sudo는 사용자가 특정 명령어를 실행할때 일시적으로 임시로 루트권한을 부여받을 수 있도록 하는 명령어이다.

비밀번호를 바꾸고싶으면 sudo passwd 명령어를 사용해야됨

정리하자면, setUID를 설정할 수 있는 명령어는 passwd와 sudo명령어이고 해당 파일을 ls를 이용해 보면 해당 파일이 setUID비트를 on상태로 가지고있는것을 확인할 수 있음 즉. 접근권한이 존재하지 않는 사용자가 권한을 일시적으로 부여받기 위해 사용할 수 있는 명령어는 passwd 와 sudo이다.

setGID

SetGID가 디렉터리에 설정되면, 해당 디렉터리에서 새로 생성되는 파일들은 그 디렉터리의 그룹을 상속받아 그룹 기반으로 파일 접근권한을 쉽게 관리할 수 있음.

일반적으로 새로 생성된 파일은 생성한 사용자의 기본 그룹에 속하게 되지만, SetGID가 설정된 디렉터리 내에서 파일을 생성할 경우 그 디렉터리의 그룹에 속하게 됩니다.

예를들어 어떤 사용자는 자신의 기본 그룹이 "developers"이고, 다른 사용자는 "designers"일 수 있습니다. 하지만 SetGID가 설정된 디렉터리에서는 두 사용자 모두 파일을 생성할 때 "project-team" 그룹을 상속받아, 그룹 소유권이 통일됩니다

Sticky bit

원래 용도는 파일을 실행한 후에도 파일의 내용을 메모리에 유지하라는 의미였음.
현대의 시스템에서는 이 기능이 더 이상 사용되지 않습니다. 오늘날 Sticky Bit은주로 디렉터리에서 사용하는데,

Sticky Bit이 설정된 디렉터리에서는 해당 디렉터리 내의 파일을 소유한 사용자만 그 파일을 삭제하거나 이름을 변경할 수 있습니다.

정리하자면 각각의 파일에는 일대일로 대응되는 inode가 있는데 각각의 inode에는 12비트의 보호비트가 존재함. 앞의 9비트는 각각 소유자, 그룹, others에 대한 접근권한을 나타내고 나머지 3비트로는 특수권한비트로 setUID, getUID, stocky bit을 나타내고 각각이 1비트씩 차지함.

RBAC

RBAC (Role-Based Access Control): 사용자 ID보다는, 사용자가 수행하는 역할(roles)을 기반으로 접근 권한을 부여하는 시스템입니다. 사용자는 시스템에서 자신에게 할당된 역할(role)에 따라 접근 권한을 얻게 됩니다. 접근 권한은 개별 사용자가 아닌 역할(role)에 할당됩니다.
사용자는 자신의 책임에 따라 서로 다른 역할에 할당될 수 있음
역할과 자원의 관계는 자주 변하지 않으므로, 정적이고, 사용자가 맡은 역할은 상황에 따라 바뀔 수 있으므로 다소 동적임.

Role-Resource 관계는 상대적으로 정적:
User-Role 관계는 더 동적:
이 또한 행렬로 표현할 수 있는데, 사용자와 역할간의 관계를 나타내고, 다대다 관계이다.다대다가 될 수 있는 이유는 여러 사용자가 하나의 역할을 가질 수 있고, 하나의 사용자가 여러 역할을 가질 수 있기 때문.
일반적으로 많은 사용자가 적은 수의 역할을 공유하는 방식임.

행렬로 나타내면, 행에는 역할, 열에는 자원을 표시하는데 S따윈 찾아볼 수 없는것을 확인할 수 있음. 즉, 해당 행렬은 user과는 무관하게 role이 바뀌지 않는 이상 보통 static하다.
이때, 불필요한 권력의 남용을 방지하기 위해서 최소한의 접근권한만을 부여하는 principle of least privilege가 있음.

principle of least privilege

사용자에게 그들이 맡은 역할을 수행하는 데 필요한 최소한의 접근 권한만 부여하는 방식이다.

사용자에게는 최소한의 역할만 할당되어야 하며, 다수의 사용자가 동일한 역할을 공유하면 그 역할에 따른 최소 권한만 부여받습니다.

RBAC 모델

User: 시스템에 접근할 수 있는 사용자. 사용자 ID를 가진다.
Role: 조직 내에서 수행하는 특정 직무 또는 기능을 나타내는데 각 역할은 조직의 정책에 따라 특정 권한을 가짐

Permission: 사용자가 특정 리소스나 객체에 대해 특정 작업을 수행할 수 있는 허가를 받았는지를 나타내는 것
Session: 사용자가 특정 시간 동안 활성화한 역할들의 하위 집합.

사용자는 여러 역할을 가지고 있을 수 있고, 세션 동안 특정 역할만 활성화하고 그에 따른 권한을 사용하게 됨.

세션은 사용자와 역할의 매핑을 정의하는데, 세션을 통해 활성화된 역할에 따른 권한을 가지고, 허용된 작업을 수행함.
활성화된 역할에 따라 권한을 동적으로 변경할 수 있음

사용자가 User1이고, 이 사용자는 관리자 역할과 개발자 역할을 가지고 있습니다.
세션 1: User1이 시스템에 로그인하고 관리자 역할만 활성화하여 세션을 시작합니다. 이 세션에서 사용자는 관리자 권한으로 시스템을 관리할 수 있습니다.
세션 2: User1이 다른 시점에서 로그인하고, 이번에는 개발자 역할만 활성화하여 세션을 시작합니다. 이 세션에서 사용자는 개발자 권한으로 코드를 작성하거나 빌드 작업을 할 수 있습니다.

세션의 중요성:
유연성: 세션을 통해 사용자는 필요에 따라 자신에게 할당된 여러 역할 중 일부만 활성화하여 시스템에서 작업할 수 있습니다.
보안 강화: 세션을 사용하여 불필요한 역할을 활성화하지 않도록 제한함으로써 보안을 강화할 수 있습니다. 예를 들어, 사용자가 특정 작업에 관리자 권한이 필요 없다면, 개발자 역할만 활성화하여 작업을 수행할 수 있습니다.

요약하자면, 세션은 사용자가 RBAC 시스템에서 활성화된 역할들의 하위 집합과의 관계를 관리하는 단위입니다. 이는 사용자에게 필요한 역할만 활성화하여, 최소한의 권한으로 작업을 수행하게 함으로써 보안과 유연성을 동시에 제공합니다.

RBAC모델

user role permission session

role을 기반으로 접근권한을 부여받는데, 사용자가 시스템에 로그인해서 세션을 시작할때, 사용자는 세션을 통해 할당된 역할만을 활성화하고, 활성화된 역할에 따른 권한을 사용하여 시스템 자원에 접근할 수 있음.
세션은 사용자와 사용자가 한 세션에서 활성화 할 수 있는 역할들을 매핑하는 역할을 하다. 사용자는 세션을 통해 본인의 역할 중 일부만을 활성화하여 접근 권한을 갖게 됨.
이때, 한 세션 내에서 활성화된 역할을 session role이라고 부른다.
그리고 사용자가 시스템에 로그인 한 이후, 시스템과 상호작용하는 전체 기간을 user session이라고 부른다. 각각의 사용자는 반드시 하나 이상의 role을 부여받는데, 이를user assignment이라고 부른다.
RH(Role Hierarchy) : role은 계층을 가질 수 있는데, 이는 상위역할이 하위 역할의 권한을 상속받음을 의미한다.
각 role은 특정 권한을 할당받는데 이를 permission assignment이라고 말 함.

이러한 RBAC에 역할계층구조를 추가한 모델이 존재하는데 $RABC_1$ 모델이다.

책임이 많으면 권한도 많음. 즉, 상위역할은 하위역할의 접근권한을 상속받는다.

RBAC모델에 제약조건을 추가확장한 모델이 있는데
세가지가 존재함

1. mutually exculsive role
2. cardinality
3. prerequisite roles

1. mutually exculsive role

• 사용자는 하나의 role만을 갖는데, 이 role은 고정이거나, 세션에 따라 변경가능하다.

2. cardinality

• 역할에 할당되는 최대 user수를 제한
• user가 할당받을 수 있는 최대역할수를 제한
• 특정 권한을 부여받을 수 있는 최대역할수를 제한

3. prerequisite roles

• 어떠한 role을 부여받기 위해선, 선행되는 role을 부여받아야만 한다.

ABAC

자원과 subject의 속성에 기반한 접근제어방식을 의미한다.
예를들어, creater에게만 접근권한을 줌.
ABAC의 ket element

Attribute
Policy model : 속
Architecture model

속성에는 주체(subject), 객체(object), 환경(environment)의 속성을 말할 수 있는데, 이러한 속성은 미리 정의된다.
Subject: Subject는 정보를 객체로 전달하거나, 시스템의 상태를 변경할 수 있는 활동적인 entity를 의미하는데, 각 Subject의 속성으로는 식별자, 이름, 조직, 역할, 지위, 소속등이 있을 수 있음.

객체: Object는 시스템에서 접근할 수 있는 모든 자원을 의미하는데, 장치, 파일, records, table, 프로세스, 네트워크 도메인들을 말 하는데 이들의 특성으로는 파일의 제목, subject, 파일의 작성자, 작성일, 파일 타입, 등등이 있고 메타데이터에서도 뽑아낼 수 있음

환경적 속성 : 정보접근이 발생하는 상황적 맥락을 설명하는데, 예를들어 현재 날짜와 시간, 네트워크 보안상태를 나타냄.
환경속성은 정책 적용 시 중요한 요소가 될 수 있음

ABAC의 특징

subject, object, environment 과 관련된 속성에 대한 규칙을 평가하여 접근을 결정함
이는 여러 접근 제어모델을 구현하여 사용할 수 있음

Subject (User):

사용자는 특정 자원에 접근하려고 요청합니다. 여기서 사용자는 주체(Subject)라고 불리며, 접근 제어 메커니즘을 통해 자원에 접근할 수 있는지 여부를 확인하려 합니다.
Subject Attributes:

사용자(주체)에 대한 속성들이 저장된 곳입니다. 속성에는 사용자의 이름(Name), 보안 등급(Clearance), 소속(Affiliation) 등이 있습니다. 이러한 속성은 주체가 시스템에서 어떤 역할을 가지고 있는지 또는 어떤 권한을 부여받았는지를 결정합니다.
Object Attributes:

자원(객체)에 대한 속성들이 저장된 곳입니다. 객체 속성에는 자원의 유형(Type), 소유자(Owner), 분류(Classification) 등이 포함될 수 있습니다. 예를 들어, 파일, 데이터베이스, 네트워크 자원 등은 객체의 일부분이 될 수 있습니다.
Environmental Attributes:

환경적인 속성들이 저장된 곳입니다. 여기에는 시간(Time), 온도(Temperature), 보안 수준(Security) 등 외부 환경과 관련된 정보들이 포함됩니다. 이 속성은 특정 상황에서만 접근이 가능하도록 제한할 때 유용합니다.
Access Control Mechanism:

이 메커니즘은 주체와 객체, 그리고 환경 속성을 바탕으로 접근을 허가할지, 거부할지를 결정합니다.
단계는 다음과 같이 이루어집니다:
1단계: 사용자의 요청이 접근 제어 메커니즘으로 들어갑니다.
2a 단계: 접근 정책이 이 메커니즘에 로드됩니다.
2b, 2c, 2d 단계: 주체의 속성, 객체의 속성, 그리고 환경 속성들이 메커니즘으로 전달되어 검토됩니다.
3단계: 최종적으로 접근 허용(Permit) 또는 거부(Deny) 여부가 결정됩니다.
Access Control Policies:

접근 정책이 저장된 곳입니다. 정책은 주체, 객체, 그리고 환경 조건에 따라 접근 권한을 허용할지, 거부할지 결정하는 규칙을 포함하고 있습니다. 이러한 정책이 2a 단계에서 접근 제어 메커니즘에 제공됩니다.