Access Control?
Access control이란 누군가의 권한을 통제하는 것이다.
대학교로 예를 들면 A과목을 듣는 학생들만 A과목에 대해서 접근 가능한 것과 유사하다.
앞에서 배운 인증은 시스템에 들어올지 말지 허용하였다면 권한 통제는 이후 더 세세하게 통제하는 것이다.
종류에는 DAC, RBAC, ABAC, MAC가 있다.
종류를 알아보기 앞서 기본 지식을 배우고 가자
Subject : Object에 접근하려 하는 객체, 그냥 사용자라고 생각하면 편하다.
Object : 리소스, 파일이라고 생각하면 편하다.
Access right : 접근 권한
DAC(Discretionary Access Control)
파일 소유주가 접근 권한을 설정할 수 있는 것을 뜻한다.
이 방식에서 모든 판단은 access matrix를 기준으로 이루어진다.
Access matrix
메트릭스를 이렇게 표현하면 매우 커지기 때문에(100명의 사람이 각각 100개 파일만 가진다고 해도 엄청 커짐)
다른 표현방식들이 존재한다.
이렇게 자르면 접속하고 있는 사람만 표현하면 되기 때문에 전보다 효율적일 수 있다.
앞에서 빈 공간이 있었는데 이런 빈 공간을 줄이기 위해 나온 것이 이 테이블이다. 또한 정렬이 가능해 편리하다.
이 메트릭스는 전에 있던 메트릭스들보다 확장된 버전이다.
보면 Objects 중에서 subjects가 있는데 이는 사용자 간의 권한을 의미한다(상사와 부하관계로 이해하면 편함)
예로 S1은 S2와 S3에 대해 owner을 가지고 있는데 S2와 S3를 부하직원으로 두고 있는 것이다.
또한 *가 붙어져 있는 것도 있는데 이는 다른 사람에게 권한을 넘길 수 있는 것을 뜻한다("Discretionary" Access Control).
파일에 대해서 owner권한이면 *가 없어도 상대방한테 권한을 넘겨줄 수 있다.
또한 이러한 접근 통제를 담당하는 것이 matrix controller이다(보통 os에 있다).
이들은 각각의 object에 존재하며 Access matrix에 기반해 판단한다.
Access matrix는 항상 바뀌는데 이를 누군가가 임의로 바꾸게 된다면 큰일이 날 수 있다.
그래서 이를 통제하는 Access matrix monitor도 존재한다.
어떤 객체에 접근하고 싶으면 시스템 메시지를 생성해 시스템에 전달한다(X 파일에 접근하고 싶다)
시스템은 이를 확인해 메트릭스에 권한이 있으면 허용하고, 없으면 거부한다.
명령어
** 명령하는 사람을 S0라 칭함
R1 : S라는 사용자에게 X파일의 권한 a 또는 a*을 준다(단, S0가 a* 권한을 가지고 있어야 함)
R2 : S라는 사용자에게 X파일의 권한 a 또는 a*을 준다(단, S0가 owner 권한을 가지고 있어야 함)
R3 : S라는 사용자에게서 X파일의 권한 a를 뺏는다
(단, S0가 S에 대해서 control 또는 S0가 파일 X에 대해서 owner 권한이 여야함)
R4 : 사용자 S가 X파일의 어떤 권한을 가지는지 읽어온다.
(단, S0가 S에 대해서 control 또는 S0가 파일 X에 대해서 owner 권한이 여야함)
R5 : 파일 X를 생성한다.
R6 : 파일 X를 제거한다.
R7 : 사용자 S를 생성한다.
R8 : 사용자 S를 제거한다.
UNIX File Access Control
유닉스 시스템은 inode를 사용해 파일을 관리한다.
이때 inode는 리눅스 시스템에서 파일에 대한 정보를 가진 일종의 자료구조이다.
파일마다 inode가 생겨나고 파일을 열면 메인 메모리에 inode가 올라간다.
각각의 파일은 12개의 보호 비트를 가진다. 이들 중 9개는 읽기, 쓰기 및 실행 권한을 지정한다.
먼저 첫 3비트는 owner에 관한 권한이고 다음은 group, 마지막은 other에 관한 권한이다.
그리고 마지막 3비트는 다른 역할을 지정할 때 사용한다.
먼저 3비트 중 첫 번째는 Set user ID(SetUID), 다음은 Set group ID(SetGID), 마지막은 Sticky bit를 의미한다.
보통 실행파일을 켜면 나의 권한으로 실행된다(만약 내가 권한이 없으면 실행이 안됨).
하지만 SetUID, SetGID를 설정하면 실행파일을 킬 때만 생성한 소유주의 권한으로 실행되는 것이다.
Sticky bit는 사용자만 그 파일을 만질 수 있는 것을 뜻한다.
마지막으로 Superuser이 있는데 이는 절대적인 권한을 가진 사람이라고 생각하면 된다.
주로 ACL을 사용한다.
RBAC (Role-Based Access Control)
우리가 처음 본 메트릭스들은 아무리 줄여도 크기 마련이다.
그래서 세로축을 Subjects에서 Role로 바꾸는 것이다.
이러한 방식은 메트릭스의 열을 줄이는 장점이 있지만 역할이 어떤 권한을 가지는지에 대한 테이블이 하나 더 필요하다.
RBAC의 모델
먼저 사용자가 Role과 매핑되고 Object에 접근할 때 Operation이 동작해 허용할지 말지 결정한다.
이때 화살표가 2개 있는 것(A ←→ → B)은 A 한 개가 여러 개에 B에 대응된다는 것이다.
Hierarchies?
Hierarchy란 상급자가 하급자의 권한을 포함해 가지는 것이다.
예를 들어 Engineer 2가 볼 수 있는 파일이 있다고 하자. 그러면 그 위에 있는 상관들은 모두 그 파일을 볼 수 있는 것이다.
Constraints?
Constraint란 몇 가지 제약을 거는 것이다.
먼저 Mutually exclusive는 한 명의 유저는 하나의 역할만 가질 수 있는 것이다. 또한 어떤 권한이든 하나의 Role에만 할당하는 것이다.
두 번째로 Cardinality는 role에 할당되는 유저의 수 또는 권한의 수를 제한하는 것이다.
마지막으로 Prerequisite roles는 순차적으로 역할을 배정받아야 하는 것이다. 예를 들어 Engineer 1을 할당하기 위해선 먼저 Engineering Dept를 거치고 가야 하는 것이다.
ABAC(Attribute-Based Access Control)
앞에 두 가지에서 핵심은 메트릭스였다. 하지만 지금 배울 ABAC는 좀 다르다.
사용자의 속성과 접근하려는 리소스의 속성을 함수로 만들어서 접근이 가능한지 불가능한지 알려주는 것이다.
이때 고려하는 요소는 Subject attribute, Object attribute, Environment attribute가 있다.
Subject attribute에는 이름, 집주소, 직업, 등등을 모두 포함한다.
Object attribute에는 파일 이름, 생성날짜, 생성인 등등이 포함된다.
마지막으로 Environment attribute에는 현재 날짜, 시간 등이 포함된다. 이를 통해 접속가능한 시간, 유효기간 등을 정할 수 있다.
ABAC Policies
Role의 집합을 Policies라고 생각하면 편하다.
ABAC 예시
영화 등급이 세 단계로 나뉘어있다고 하자. 이를 ABAC를 적용하자.
R1 : can_access (u, m, e)
(Age(u) ≥ 17 ^ Rating(m) ∈ {R, PG-13, G}) v
(Age(u) ≥ 13 ^ Age(u) < 17 ^ Rating(m) ∈ {PG-13, G}) v
(Age(u) < 13 ^ Rating(m) ∈ {G})
이를 풀어서 설명하면
나이가 17 이상이고 볼 영화의 Rating이 R, PG-13, G 이면 접근허용
또는 나이가 13살~16이고 볼 영화의 Rating이 PG-13, G 이면 접근허용
또는 나이가 13살 미만이고 볼 영화의 Rating이 G 이면 접근허용
라는 뜻이다.
BLP(Bell- LaPadula) Model
1970년도에 개발되었고, 접근 통제에 대한 기본적인 모델 중 하나이다.
이 모델에서 Subject와 Object는 security class를 부여받는다.
Top secret > secret > confidential > restricted > unclassified 순으로 큼
이때 security class에 따라 접근 허용 여부를 결정한다.
권한
권한은 Read, Append, Write, Execute가 있다.
Read 권한은 오직 읽을 수만 있고
Append 권한은 오직 쓸 수만 있으며
Write 권한은 읽고 쓸 수 있다.
마지막으로 Execute 권한은 실행할 수 있는 권한이다.
Multilevel security
- No read up : 파일의 레벨이 나의 레벨보다 높으면 읽을 수 없다(simple security property, ss-property).
만약 내 security 레벨이 3이라고 하면 security 레벨이 3보다 같거나 낮은 파일만 읽을 수 있다.
- No write down : 파일의 레벨이 나의 레벨보다 낮으면 쓸 수 없다(*-property).
만약 내 security 레벨이 3이라고 하면 security 레벨이 3보다 같거나 높은 파일만 쓸 수 있다.
BLB의 한계
낮은 레벨의 사람이 높은 레벨의 사람에게 악성코드를 보내게 되면 높은 레벨의 사람이 실행할 수도 있다.
만약 실행한다면 그 사람의 권한에 따르므로(이때는 setuid와 같은 개념이 없었음) 그 권한으로 볼 수 있는 파일들이 유출될 가능성이 있다.
또한 이 N등급 파일이 있다고 하자, 이 기준은 N이 커지거나 작아질 때마다 같이 움직이게 된다.(권한들)
그래서 세세한 제어가 불가능하다는 단점이 있다.
Biba Integrity Model
이 모델은 앞서 알아본 BLP와 유사한 모델이다.
하지만 BLP는 Confidentiality, 즉 기밀성에 초점을 맞추었다면
Biba Integrity 모델은 Integrity, 즉 무결성에 초점이 맞추어진 모델이다.
이 모델에는 Strict integrity policy라는 규칙이 존재한다.
1. I(S) ≥ I(O)인 경우에만 파일을 수정할 수 있다.( I(S)는 subject의 레벨, I(O)는 object의 레벨 )
2. I(S) ≤ I(O)인 경우에만 파일을 읽을 수 있다.
3. I(S1) ≥ I(S2) 인 경우에만 (S1 → S2) 의사소통이 가능하다.
Chinese Wall Model
Chinese Wall(만리장성) Model은 이전에 알아본 것들과는 조금 차이가 있는 모델이다.
이 모델을 알아보기 전 알아야 할 개념이 있는데 바로 Conflict of interest(이해 상충)이다.
이해상충이란 개인이 특정한 직무, 의무, 역할 등을 수행하는 과정에서 자신의 사적 이익과 공적 의무 또는 책임이 충돌하는 상황을 말한다.
예시로 부모가 면접하는 학교에 아들이 지원한것을 예로 들 수 있다. 이제 계속 알아보자.
일단 먼저 사진에 보이는 Conflict of interest classes는 같은 업종이라고 이해하면 된다(은행, 가스, 오일...)
개인은 각각의 정보들에 접근이 가능하지만 한 업종 안에서 한가지 회사에만 접근할 수 있다.
여기서 문제가 발생하게 된다.
존과 제인이 이러한 접근 권한을 가지고있다고 하자(겹치는 부분이 존재한다).
이때 존과 제인이 결탁한다면 정보가 유출 될 우려가 있다.
만약 존이 Oil A 의 정보를 Bank A에 덮어씌운다면 제인은 이를 접근할 수 있게된다.
이러한 문제를 해결한 모델이 Chinese Wall Model이다.
Chinese Wall Model에서는 몇가지 규칙을 적용하여 이 문제를 해결하였다.
1. 이러한 경우에만 S는 O를 읽을 수 있다.
- O가 이전에 접근한 파일의 Dataset에 있는 경우(Dataset : Bank A, Gas A와 같은것들) 또는
- O가 이전에 접근하지 않았던 업종에 있는 경우
2. 이러한 경우에만 S는 O를 쓸 수 있다.
- S가 O를 읽을 수 있는 경우(1번 규칙) 그리고
- S가 읽을 수 있는 모든 O가 하나의 업종에만 있는 경우(양다리 걸치면 쓰기 권한 X)
'시스템 보안' 카테고리의 다른 글
| [시스템 보안] Trusted Systems (1) | 2024.12.12 |
|---|
