강제적 접근 제어

**강제적 접근 제어**(mandatory access control, MAC)는 컴퓨터 보안에서 운영체제나 데이터베이스의 주체나 개시자가 개체나 대상에 액세스하거나 일반적으로 일종의 작업을 수행하는 능력을 제한하는 접근 제어 유형을 의미한다. 운영체제의 경우 주제는 일반적으로 프로세스 또는 스레드이다. 객체는 파일, 디렉터리, TCP/UDP 포트, 공유 메모리 세그먼트, IO 장치 등과 같은 구성물이다. 주체와 객체는 각각 일련의 보안 속성을 갖는다. 주체가 객체에 액세스하려고 시도할 때마다 운영 체제 커널에 의해 시행되는 권한 부여 규칙은 이러한 보안 속성을 검사하고 액세스가 발생할 수 있는지 여부를 결정한다. 개체에 대한 주체의 모든 작업은 작업이 허용되는지 확인하기 위해 일련의 권한 부여 규칙(즉, 정책)에 대해 테스트된다. 데이터베이스 관리 시스템은 액세스 제어 메커니즘에서 강제적 접근 제어를 적용할 수도 있다. 이 경우 개체는 테이블, 뷰, 프로시저 등이다.

강제적 접근 제어를 사용하면 이 보안 정책은 보안 정책 관리자가 중앙에서 제어한다. 사용자는 정책을 무시할 수 없으며, 예를 들어 제한될 파일에 대한 액세스 권한을 부여할 수 없다. 대조적으로, 객체에 접근하는 주체의 능력을 통제하는 임의 접근 제어(DAC)는 사용자가 정책 결정을 내리거나 보안 속성을 할당할 수 있는 능력을 허용한다. (사용자, 그룹 및 읽기-쓰기-실행 권한으로 구성된 기존 유닉스 시스템이 DAC의 예이다.) MAC 지원 시스템을 사용하면 정책 관리자가 조직 전체의 보안 정책을 구현할 수 있다. MAC에서는(DAC와는 달리) 사용자가 실수로든 의도적으로든 이 정책을 재정의하거나 수정할 수 없다. 이를 통해 보안 관리자는 원칙적으로 모든 사용자에게 시행되도록 보장되는 중앙 정책을 정의할 수 있다.

역사적으로나 전통적으로 MAC는 다단계 보안(MLS) 및 특수 군사 시스템과 밀접하게 연관되어 왔다. 이러한 맥락에서 MAC는 MLS 시스템의 제약 조건을 충족하기 위한 높은 수준의 엄격함을 의미한다. 그러나 최근에는 MAC가 MLS 틈새 시장에서 벗어나 더욱 주류가 되기 시작했다. 리눅스용 SELinux 및 AppArmor, 윈도우용 필수 무결성 제어(Mandatory Integrity Control)와 같은 최신 MAC 구현을 통해 관리자는 MLS의 엄격함이나 제약 없이 네트워크 공격 및 맬웨어와 같은 문제에 집중할 수 있다.

## 역사 및 배경
역사적으로 MAC은 미국 기밀정보를 보호하기 위한 수단으로 다단계 보안 (MLS)과 강하게 연관되어 있었다. 이 주제에 대한 기초적인 작업이며 종종 오렌지 북으로 알려진 컴퓨터 보안 평가 지침서(TCSEC)는 MAC의 원래 정의를 "객체에 포함된 정보의 민감도(레이블로 표시됨)와 그러한 민감도의 정보에 접근하기 위한 주체의 공식적인 권한(즉, 허가)을 기반으로 객체에 대한 접근을 제한하는 수단"이라고 제공했다. 허니웰의 SCOMP, 미국 공군의 SACDIN, 미국 국가안보국의 블랙커, 보잉의 MLS LAN과 같은 MAC의 초기 구현은 강력한 시행을 통해 군사 중심 보안 분류 수준을 보호하기 위한 MLS에 중점을 두었다.

MAC의 "강제적"이라는 단어는 군사 시스템과의 사용에서 파생된 특별한 의미를 얻었다. 이 맥락에서 MAC은 제어 메커니즘이 어떤 종류의 전복에도 저항할 수 있음을 보장하는 극도로 높은 수준의 견고성을 의미하며, 이를 통해 행정명령 12958과 같은 정부 명령에 의해 의무화된 접근 제어를 시행할 수 있게 한다. 시행은 상업용 애플리케이션보다 더 필수적이어야 한다. 이는 최선 노력 메커니즘에 의한 시행을 배제한다. 명령의 절대적 또는 거의 절대적인 시행을 제공할 수 있는 메커니즘만이 MAC에 허용된다. 이는 어려운 과제이며, 고보증 전략에 익숙하지 않은 사람들에게는 비현실적이라고 간주되기도 하고, 익숙한 사람들에게는 매우 어렵다.

일부 시스템에서 사용자는 다른 사용자에게 접근 권한을 부여할지 여부를 결정할 권한이 있다. 이를 허용하기 위해 모든 사용자는 모든 데이터에 대한 허가를 가지고 있다. 이는 MLS 시스템에 반드시 해당되는 것은 아니다. 시스템 환경 내의 어떤 데이터에 대한 접근이 거부될 수 있는 개인이나 프로세스가 존재한다면, 시스템은 MAC을 시행하도록 신뢰되어야 한다. 데이터 분류 및 사용자 허가 수준이 다양할 수 있으므로, 이는 견고성에 대한 정량화된 척도를 의미한다. 예를 들어, "일급비밀" 정보와 무허가 사용자가 있는 시스템 환경은 "비밀" 정보와 최소 "기밀" 허가를 받은 사용자가 있는 시스템 환경보다 더 높은 견고성이 요구된다. 견고성 정도의 일관성을 증진하고 주관성을 제거하기 위해, 이 주제에 대한 광범위한 과학적 분석 및 위험 평가를 통해 시스템의 보안 견고성 기능을 정량화하고 다양한 보안 환경에 대해 보증되는 신뢰 수준에 매핑하는 획기적인 벤치마크 표준화가 이루어졌다. 그 결과는 CSC-STD-004-85에 문서화되었다. 견고성의 두 가지 상대적으로 독립적인 구성 요소가 정의되었다: 보증 수준과 기능성. 둘 다 이러한 기준에 기반한 인증에 상당한 신뢰를 보증하는 정밀도로 명시되었다.

공통평가기준 표준은 이 과학을 기반으로 하며, 보증 수준을 EAL 수준으로, 기능성 사양을 보호프로파일로 보존하는 것을 목표로 한다. 객관적인 견고성 벤치마크의 이 두 가지 필수 구성 요소 중 EAL 수준만이 충실하게 보존되었다. 한 가지 예로, TCSEC 레벨 C2 (MAC 지원 범주가 아님)는 통제된 접근 보호 프로파일(CAPP)로서 공통평가기준에 상당히 충실하게 보존되었다. MLS 보호 프로파일(B2와 유사한 MLSOSPP와 같은)은 B2보다 더 일반적이다. 이들은 MLS에 따르지만, 오렌지 북 이전 버전의 상세한 구현 요구사항은 부족하며, 목표에 더 중점을 둔다. 이는 인증기관이 평가된 제품의 기술적 특징이 목표를 적절히 달성하는지 여부를 결정하는 데 더 주관적인 유연성을 부여하여, 평가된 제품의 일관성을 약화시키고 신뢰도가 낮은 제품의 인증을 더 쉽게 획득하게 할 수 있다. 이러한 이유로 보호 프로파일의 기술적 세부 사항은 제품의 적합성을 결정하는 데 매우 중요하다.

이러한 아키텍처는 특정 분류 또는 신뢰 수준의 인증된 사용자나 프로세스가 다른 수준의 정보, 프로세스 또는 장치에 접근하는 것을 방지한다. 이는 알려진 사용자 및 프로세스, 그리고 알려지지 않은 사용자 및 프로세스 모두를 위한 격리 메커니즘을 제공한다. 알 수 없는 프로그램은 시스템이 장치 및 파일에 대한 접근을 모니터링하거나 제어해야 하는 신뢰할 수 없는 애플리케이션을 포함할 수 있다.

유니시스의 블랙커 프로젝트와 같은 일부 MAC 구현은 지난 세기 말에 일급비밀 정보를 미분류 정보와 분리할 만큼 견고하다고 인증되었다. 그들의 기반 기술은 구식화되었고 갱신되지 않았다. 오늘날 그 수준의 견고한 구현으로 TCSEC에 의해 인증된 현재 구현은 없다. 그러나 덜 견고한 일부 제품은 존재한다.

## 운영체제에서

### 마이크로소프트

윈도우 비스타 및 서버 2008부터 마이크로소프트는 필수 무결성 제어 (MIC)를 윈도우 운영체제에 통합하여 실행 중인 프로세스에 무결성 수준(IL)을 추가했다. 목표는 덜 신뢰할 수 있는 프로세스의 민감한 정보 접근을 제한하는 것이다. MIC는 낮음, 중간, 높음, 시스템, 신뢰할 수 있는 설치자라는 다섯 가지 무결성 수준을 정의한다. 기본적으로 프로세스는 중간 IL로 시작된다. 상위 권한 프로세스는 높은 IL을 받는다. 자식 프로세스는 기본적으로 부모의 무결성을 상속하지만, 부모 프로세스는 더 낮은 IL로 자식 프로세스를 시작할 수 있다. 예를 들어, 인터넷 익스플로러 7은 낮은 IL로 서브프로세스를 시작한다. 윈도우는 IL을 기반으로 객체 접근을 제어한다. 파일, 레지스트리 키 또는 다른 프로세스 및 스레드를 포함한 명명된 객체는 객체를 사용할 수 있는 프로세스의 최소 IL을 나타내는 ACL에 항목을 가지고 있다. MIC는 프로세스가 객체의 IL보다 크거나 같을 때만 객체에 쓰거나 삭제할 수 있도록 강제한다. 또한, 메모리의 민감한 데이터에 대한 접근을 방지하기 위해, 프로세스는 더 높은 IL을 가진 프로세스를 읽기 접근으로 열 수 없다.

### 애플
애플은 iOS 및 macOS 운영체제에 TrustedBSD 프레임워크의 구현을 통합했다. ("macOS"의 "mac"은 "매킨토시"의 약어이며, "강제적 접근 제어"의 약어와는 관련이 없다.) 명령줄 함수 `sandbox_init`은 제한된 상위 수준의 샌드박스 인터페이스를 제공한다.

### 구글
구글이 개발한 안드로이드 운영체제 버전 5.0 이상은 SELinux를 사용하여 원래의 UID 기반 DAC 접근 방식 위에 MAC 보안 모델을 적용한다.

### 리눅스 계열
리눅스 및 기타 많은 유닉스 배포판은 CPU(멀티 링), 디스크 및 메모리에 대한 MAC을 가지고 있다. OS 소프트웨어가 권한을 잘 관리하지 못할 수도 있지만, 리눅스는 1990년대에 비유닉스 대안보다 더 안전하고 훨씬 더 안정적이라는 점으로 유명해졌다. MAC을 구현하는 세 가지 주요 리눅스 보안 모듈은 SELinux, AppArmor, 그리고 TOMOYO Linux이다.

보안 강화 리눅스 (SELinux)는 원래 미국 국가안보국이 개발하여 2000년에 오픈 소스 커뮤니티에 공개되었다.
이는 리눅스를 위한 최초의 MAC 구현 중 하나이며 가장 인기 있는 구현 중 하나이기도 하다.
v2.4부터 리눅스 커널에 통합되었으며, 안드로이드 5.0+ 및 Red Hat/Fedora에서 기본적으로 활성화되어 있다. SELinux는 강력하고 세밀한 제어를 제공하여 고보안 환경에 적합하지만, 많은 사용자는 그 강력함과 세분화가 높은 복잡성과 가파른 학습 곡선을 동반한다고 생각한다.

TOMOYO Linux는 NTT 데이터 코퍼레이션이 개발한 리눅스 및 임베디드 리눅스를 위한 경량 MAC 구현이다. 2009년 6월에 리눅스 커널 메인라인 버전 2.6.30에 병합되었다. SELinux가 사용하는 레이블 기반 접근 방식과 달리, TOMOYO Linux는 프로세스 호출 기록(시스템 동작을 설명함)에 따라 보안 도메인을 분리하는 경로명 기반의 강제적 접근 제어를 수행한다. 정책은 경로명으로 설명된다. 보안 도메인은 단순히 프로세스 호출 체인에 의해 정의되며 문자열로 표현된다. 비활성화, 학습, 허용, 강제라는 4가지 모드가 있다. 관리자는 다른 도메인에 다른 모드를 할당할 수 있다. TOMOYO Linux는 "학습" 모드를 도입했는데, 이 모드에서는 커널에서 발생한 접근이 자동으로 분석되고 저장되어 MAC 정책을 생성한다. 이 모드는 정책 작성의 첫 번째 단계가 될 수 있으며, 나중에 쉽게 사용자 정의할 수 있도록 한다.

AppArmor는 리눅스 2.6의 리눅스 보안 모듈 (LSM) 인터페이스를 활용하는 MAC 구현이며, 수세 리눅스 및 우분투 7.10에 통합되어 있다. LSM은 API를 제공하여 커널 코드 모듈이 ACL (DAC ACL)을 관리할 수 있게 한다. AppArmor는 모든 프로그램을 제한할 수 없으며, 버전 2.6.36부터 리눅스 커널에 선택적으로 포함되어 있다.

아몬 오트(Amon Ott)의 RSBAC (Rule Set Based Access Control)은 여러 가지 다른 보안 정책/결정 모듈을 허용하는 리눅스 커널용 프레임워크를 제공한다. 구현된 모델 중 하나는 강제적 접근 제어 모델이다. RSBAC 설계의 일반적인 목표는 (구식) 오렌지 북 (TCSEC) B1 수준에 도달하는 것이었다. RSBAC에서 사용되는 강제적 접근 제어 모델은 유닉스 시스템 V/MLS, 버전 1.2.1 (1989년 미국 국립 컴퓨터 보안 센터에서 B1/TCSEC 분류로 개발)과 거의 동일하다. RSBAC는 순정 커널에 대한 일련의 패치를 필요로 하며, 이는 프로젝트 소유자에 의해 잘 관리되고 있다.

Smack (Simplified Mandatory Access Control Kernel)은 간결성을 주요 설계 목표로 하여 일련의 사용자 정의 강제적 접근 제어 규칙을 사용하여 데이터 및 프로세스 상호 작용을 악의적인 조작으로부터 보호하는 리눅스 커널 보안 모듈이다. 리눅스 2.6.25 릴리스 이후 공식적으로 병합되었다.

`grsecurity`는 MAC 구현을 제공하는 리눅스 커널용 패치이다 (정확히 말하면 RBAC 구현이다). `grsecurity`는 LSM API를 통해 구현되지 않는다.

러시아군을 위해 개발된 Astra Linux OS는 자체 강제적 접근 제어를 가지고 있다.

### 기타 OS
FreeBSD는 TrustedBSD 프로젝트의 일부로 구현된 강제적 접근 제어를 지원한다. FreeBSD 5.0에서 도입되었으며, FreeBSD 7.2부터 MAC 지원이 기본적으로 활성화되어 있다. 이 프레임워크는 확장 가능하며, 다양한 MAC 모듈은 비바 및 다단계 보안과 같은 정책을 구현한다.

선(Sun)의 Trusted Solaris는 강제적이고 시스템 강제적인 접근 제어 메커니즘(MAC)을 사용하며, 여기서 권한 및 레이블은 보안 정책을 적용하는 데 사용된다. 그러나 레이블 관리 기능이 커널이 다단계 보안 모드에서 작동하는 데 필요한 커널 강도를 의미하지는 않는다. 레이블 및 제어 메커니즘에 대한 접근은 커널이 유지하는 보호 도메인 내에서 손상으로부터 강력하게 보호되지 않는다. 사용자가 실행하는 응용 프로그램은 세션에서 사용자가 작업하는 보안 레이블과 결합된다. 정보, 프로그램 및 장치에 대한 접근은 약하게만 제어된다.

## 같이 보기
* 접근 제어 목록
* 역할 기반 접근 제어
* 기밀정보
* 필수 무결성 제어
* Smack (소프트웨어)

## 각주

## 출처
* P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. *[https://web.archive.org/web/20070621155813/http://jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments]*. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998.
* P. A. Loscocco, S. D. Smalley, *[http://www.nsa.gov/selinux/papers/ottawa01-abs.cfm Meeting Critical Security Objectives with Security-Enhanced Linux] * Proceedings of the 2001 Ottawa Linux Symposium.
* ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993
* Robert N. M. Watson. "A decade of OS access-control extensibility". Commun. ACM 56, 2 (February 2013), 52–63.

## 외부 링크
* Weblog post on the how virtualization can be used to implement Mandatory Access Control.
* Weblog post from a Microsoft employee detailing Mandatory Integrity Control and how it differs from MAC implementations.
* GWV Formal Security Policy Model A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.

분류:컴퓨터 접근 제어
분류:운영체제 보안
분류:접근 제어