접근 제어 목록

**접근 제어 목록**(, ACL) 또는 **액세스 제어 목록**은 시스템 리소스(객체 또는 기능)와 관련된 권한 목록이다. ACL은 어떤 사용자 또는 시스템 프로세스에게 리소스에 대한 접근 권한이 부여되는지, 그리고 주어진 리소스에 대해 어떤 작업이 허용되는지를 지정한다. 일반적인 ACL의 각 항목은 주체와 작업을 지정한다. 예를 들어:
* 파일 객체가 를 포함하는 ACL을 가지고 있다면, 앨리스에게는 파일을 읽고 쓸 권한이 주어지고, 밥에게는 파일을 읽을 권한만 주어진다.
* 자원 접근 제어 기능(RACF) 프로필 CONSOLE CLASS(TSOAUTH)가 를 포함하는 ACL을 가지고 있다면, ALICE에게는 TSO CONSOLE 명령을 사용할 권한이 주어진다.

## 구현
많은 종류의 운영체제가 ACL을 구현하거나 역사적인 구현을 가지고 있다. ACL의 첫 구현은 1965년 멀틱스의 파일 시스템에 있었다.

### 파일 시스템 ACL
파일 시스템 ACL은 프로그램, 프로세스, 파일과 같은 특정 시스템 객체에 대한 개별 사용자 또는 그룹의 권한을 지정하는 항목을 포함하는 자료 구조(일반적으로 테이블)이다. 이 항목들은 마이크로소프트 윈도우 NT, OpenVMS, 그리고 리눅스, MacOS, 솔라리스와 같은 유닉스 계열운영체제에서 접근 제어 항목(ACE)으로 알려져 있다. 각 접근 가능한 객체는 해당 ACL에 대한 식별자를 포함한다. 특권 또는 권한은 사용자가 객체를 읽고, 쓰고, 실행할 수 있는지와 같은 특정 접근 권한을 결정한다. 일부 구현에서는 ACE가 사용자 또는 사용자 그룹이 객체의 ACL을 변경할 수 있는지 여부를 제어할 수 있다.

파일 시스템 ACL을 제공한 최초의 운영 체제 중 하나는 멀틱스였다. 프라이모스는 적어도 1984년에 ACL을 포함했다.

1990년대에는 ACL 및 역할 기반 접근 제어(RBAC) 모델이 광범위하게 테스트되고 파일 권한 관리에 사용되었다.

#### POSIX ACL
POSIX 1003.1e/1003.2c 워킹 그룹은 ACL 표준화를 위한 노력을 기울였으며, 그 결과 현재 "POSIX.1e ACL" 또는 단순히 "POSIX ACL"로 알려진 것이 탄생했다. POSIX.1e/POSIX.2c 초안은 프로젝트 자금 지원에 대한 참여자들의 관심 상실과 NFSv4 ACL과 같은 더 강력한 대안으로 전환하면서 1997년에 철회되었다.  현재 초안의 살아있는 소스는 인터넷에서 찾을 수 없지만, 인터넷 아카이브에서 여전히 찾을 수 있다.

대부분의 유닉스 및 유닉스 계열 운영 체제(예: 2.5.46 또는 2002년 11월 이후의 리눅스, FreeBSD, 솔라리스)는 POSIX.1e ACL(반드시 초안 17은 아님)을 지원한다. ACL은 일반적으로 이러한 시스템의 파일의 확장 파일 속성에 저장된다.

#### NFSv4 ACL
NFSv4 ACL은 POSIX 초안 ACL보다 훨씬 강력하다. POSIX 초안 ACL과 달리 NFSv4 ACL은 실제로 게시된 표준인 네트워크 파일 시스템의 일부로 정의된다.

NFSv4 ACL은 많은 유닉스 및 유닉스 계열 운영 체제에서 지원된다. 예를 들어 AIX, FreeBSD, 버전 10.4 ("타이거")부터의 맥 OS X, 또는 ZFS 파일 시스템을 사용하는 솔라리스는 NFSv4 표준의 일부인 NFSv4 ACL을 지원한다. 리눅스를 위한 NFSv4 ACL의 두 가지 실험적인 구현이 있다. Ext3 파일 시스템을 위한 NFSv4 ACL 지원과 Ext4 파일 시스템을 위한 NFSv4 ACL 지원을 제공하는 더 최근의 Richacls가 있다. POSIX ACL과 마찬가지로 NFSv4 ACL은 일반적으로 유닉스 계열 시스템에서 확장 속성으로 저장된다.

NFSv4 ACL은 NTFS에서 사용되는 윈도우 NT ACL과 거의 동일하게 구성된다. NFSv4.1 ACL은 NT ACL과 POSIX 초안 ACL의 상위 집합이다. 삼바는 SMB 공유 파일의 NT ACL을 여러 방식으로 저장하는 것을 지원하며, 그 중 하나는 NFSv4 인코딩 ACL로 저장하는 것이다.

### 액티브 디렉터리 ACL

마이크로소프트의 액티브 디렉터리 서비스는 도메인의 사용자 및 컴퓨터에 대한 구성 정보를 저장하고 전파하는 LDAP 서버를 구현한다. 액티브 디렉터리는 윈도우 NT가 NTFS 파일 시스템에 사용하는 것과 동일한 유형의 접근 제어 목록 메커니즘을 추가하여 LDAP 사양을 확장한다. 이후 윈도우 2000은 접근 제어 항목의 구문을 확장하여 전체 LDAP 객체뿐만 아니라 이러한 객체 내의 개별 속성에도 접근을 허용하거나 거부할 수 있도록 했다.

### 네트워킹 ACL
일부 유형의 독점 컴퓨터 하드웨어(특히 라우터 및 네트워크 스위치)에서 접근 제어 목록은 호스트 또는 다른 레이어 3에서 사용 가능한 포트 번호 또는 IP 주소에 적용되는 규칙을 제공하며, 각 규칙에는 서비스를 사용할 수 있는 호스트 및 네트워크 목록이 포함된다. 네트워크 도메인 네임을 기반으로 접근 제어 목록을 구성하는 것도 가능하지만, 개별 TCP, UDP, ICMP 헤더에 도메인 네임이 포함되어 있지 않으므로 이는 의문스러운 아이디어이다. 결과적으로 접근 제어 목록을 강제하는 장치는 이름을 숫자 주소로 별도로 확인해야 한다. 이는 접근 제어 목록이 보호하는 시스템의 보안을 침해하려는 공격자에게 추가적인 공격 표면을 제공한다. 개별 서버와 라우터 모두 네트워크 ACL을 가질 수 있다. 접근 제어 목록은 일반적으로 인바운드 및 아웃바운드 트래픽을 모두 제어하도록 구성할 수 있으며, 이 맥락에서 방화벽과 유사하다. 방화벽과 마찬가지로 ACL은 PCI DSS와 같은 보안 규정 및 표준의 적용을 받을 수 있다.

### SQL 구현
ACL 알고리즘은 SQL 및 관계형 데이터베이스 관리 시스템으로 포팅되었다. 많은 "현대적인"(2000년대와 2010년대) SQL 기반 시스템, 예를 들어 전사적 자원 관리 및 저작물 관리 시스템은 관리 모듈에서 ACL 모델을 사용했다.

### 스키마 인덱스 ACL
2024년에는 스키마 인덱스 ACL 모델이 기존의 JSON 기반 권한 저장 방식의 가벼운 대안으로 등장했다. 주목할 만한 제안 중 하나는 전체 권한 트리 대신 허용된 작업의 인덱스만 저장하는 아이디어를 도입했다. 나중에 SCode ACL로 공식화된 이 기술은 미리 정의된 평면화된 스키마를 기반으로 접근 권한(예: `"0 2 5"`)을 압축적으로 인코딩할 수 있게 하여, JWT 토큰이나 세션 쿠키와 같은 무상태 시스템에서 특히 효율적이다. 이 접근 방식은 최소주의와 성능으로 개발자 커뮤니티에서 초기에 인기를 얻었으며, 이후 소규모 및 프로덕션급 시스템 모두에 채택되었다.

## 역할 기반 접근 제어와 비교
ACL 모델의 주요 대안은 역할 기반 접근 제어(RBAC) 모델이다. "최소 RBAC 모델"인 RBACm은 그룹만이 ACL 항목으로 허용되는 ACL 메커니즘인 ACLg와 비교할 수 있다. Barkley (1997)는 RBACm과 ACLg가 동등함을 보여주었다.

현대 SQL 구현에서 ACL은 그룹 계층 구조에서 그룹 및 상속을 관리하기도 한다. 따라서 "현대 ACL"은 RBAC가 표현하는 모든 것을 표현할 수 있으며, 특히 관리자가 조직을 보는 방식 측면에서 접근 제어 정책을 표현하는 능력에서 (구식 ACL에 비해) 강력하다.

데이터 교환 및 "고수준 비교"를 위해 ACL 데이터는 XACML로 변환될 수 있다.

## 같이 보기
* 확장 파일 속성
* 파일 시스템 권한
* 역할 기반 접근 제어(RBAC)

## 내용주

## 각주

## 참고 문헌

* 
* 
* 
* 
* 
* 
* 
* 

분류:컴퓨터 접근 제어