[OSTEP] 스터디 22주차 Security Access

1. 도입

우리는 우리의 보안 목표가 무엇인지 알고 있고, 우리가 강제하고자 하는 보안 정책에 대한 최소한의 일반적인 감을 잡았으며, 우리의 정책을 위반할 수도(혹은 위반하지 않을 수도) 있는 다양한 시스템 서비스를 요청하는 주체가 누구인지에 대한 증거를 가지고 있다. 이제 우리는 그 정보를 가져와서 소프트웨어가 우리를 대신해 수행할 수 있는 실질적으로 실행 가능한 무언가로 전환해야 한다.

여기에는 두 가지 중요한 단계가 있다:

1. 해당 요청이 우리의 보안 정책 내에 적합한지 판단한다.
2. 적합하다면 작업을 수행하고, 그렇지 않다면 작업이 수행되지 않도록 확실히 보장한다.

첫 번째 단계를 일반적으로 접근 제어(Access Control)라고 부른다. 우리는 어떤 시스템 자원이나 서비스가 어떤 주체에 의해, 어떤 방식으로, 어떤 상황에서 접근될 수 있는지 결정할 것이다. 기본적으로 이것은 컴퓨팅 패러다임에 잘 맞는 이진 결정(Yes 또는 No)으로 귀결된다.

이 섹션은 접근 제어가 단순히 "허용하느냐 마느냐"의 결정임을 강조한다. 예시로
open("/var/foo", O_RDWR)
시스템 콜을 호출했을 때, OS는 내부적으로 이 요청을 승인할지 거부할지 결정해야 한다. 이때 기준이 되는 것이 바로 접근 제어 결정(Access Control Decision)이다.

---

2 The Access Control Matrix (접근 제어 행렬)

이 결정을 내리는 가장 간단하고 개념적인 방법은 접근 제어 행렬을 사용하는 것이다. 이 행렬의 행(Row)은 접근을 요청하는 주체(사용자 등)를 나타내고, 열(Column)은 접근 대상이 되는 객체(파일 등)를 나타낸다. 각 칸(Entry)에는 해당 주체가 해당 객체에 대해 수행할 수 있는 권한이 나열된다.

 

• 구조: 행(User 1, User 2...) × 열(File A, File B...).
• 권한: 칸 안에 'Read', 'Write', 'Execute' 등이 들어간다.
• 한계: 개념적으로는 완벽하지만 실무적으로는 희소성(Sparsity) 문제가 발생한다. 수만 명의 사용자와 수백만 개의 파일이 있는 시스템에서 대부분의 칸은 비어 있게 되어 메모리 낭비가 엄청나다. 따라서 OS는 이를 효율적으로 저장하기 위한 다른 방식을 택한다.

---

3 Access Control Lists (ACL, 접근 제어 리스트)

행렬을 효율적으로 저장하는 첫 번째 방법은 열(Column)을 따라 쪼개는 것이다. 각 객체(파일)와 연관된 리스트를 저장하는데, 이를 접근 제어 리스트(ACL)라고 한다. 각 리스트의 항목은 주체와 해당 주체가 그 객체에 대해 가진 권한을 나타낸다.

 

• 저장 방식: 파일 자체에 "이 파일을 읽을 수 있는 사람들의 명단"을 붙여둔다.
• UNIX의 예: ls -l 명령어로 보는 권한(-rwxr-xr-x)은 아주 단순화된 형태의 ACL이다. 현대적인 시스템은 특정 유저나 그룹을 지정할 수 있는 더 정교한 ACL을 지원한다.
• 장점: 특정 파일의 보안 상태를 확인하거나 변경하기 매우 쉽다.

---

4 Capabilities (권한 기반 시스템)

행렬을 저장하는 두 번째 방법은 행(Row)을 따라 쪼개는 것이다. 각 주체는 자신이 접근할 수 있는 객체와 그에 대한 권한 목록을 가진다. 이를 권한(Capability) 또는 케이퍼빌리티 리스트라고 부른다. 이것은 마치 사용자가 가지고 다니는 '티켓'이나 '열쇠'와 같다.

 

• 저장 방식: 사용자가 자산에 대한 입장권을 주머니에 넣고 다니는 방식이다.
• 장점: "이 유저가 무엇을 할 수 있는가?"를 파악하기 매우 빠르다.
• 단점 (중요): 권한 취소(Revocation)가 매우 어렵다. 특정 파일에 대한 접근권을 뺏으려면, 그 파일의 티켓을 가진 모든 유저의 주머니를 뒤져서 티켓을 회수해야 하기 때문이다.

---

5 Roles and Groups (역할과 그룹)

수천 명의 사용자를 개별적으로 관리하는 것은 비효율적이다. 그래서 우리는 그룹(Groups)이나 역할(Roles) 개념을 사용한다. 접근 제어 결정은 이제 특정 개인(Alice)이 아니라 특정 역할(Engineer)에 대해 내려진다.

• RBAC (Role-Based Access Control): 현대 기업용 소프트웨어의 표준이다. 유저를 역할에 할당하고, 역할에 권한을 부여함으로써 관리 포인트를 획기적으로 줄인다.

---

6 Multilevel Security (다단계 보안)

때로는 단순히 "누구인가"를 넘어 더 엄격한 보안 모델이 필요하다. 군대나 정보 기관에서 쓰이는 다단계 보안(MLS)이 그 예다. 이는 데이터에 비밀 등급(Clearance)을 매긴다.

• No Read Up (Simple Security Property): 낮은 등급의 유저는 높은 등급의 데이터를 읽을 수 없다.
• No Write Down ($\star$-Property): 높은 등급의 유저는 정보를 보호하기 위해 낮은 등급의 객체에 글을 쓸 수 없다.

---

7 Design Principles (설계 원칙)

접근 제어를 구현할 때 반드시 지켜야 할 원칙들이 있다.

1. 완전한 중재 (Complete Mediation): 어떤 자원에 접근하든 예외 없이 반드시 접근 제어 검사를 거쳐야 한다. 캐싱된 권한 정보가 보안 사고의 원인이 되기도 하다.
2. 최소 권한 (Least Privilege): 사용자나 프로세스는 업무를 수행하는 데 필요한 최소한의 권한만 가져야 한다.