임의적 접근통제
IT 위키
더 많은 작업
- DAC, Discretionary Access Control
- 객체에 접근하고자 하는 주체(또는 주체가 속한 그룹)의 접근 권한에 따라 접근을 통제하는 접근통제 정책
- 개인 기반 정책과 그룹기반 정책을 포함
- 특정 접근 허가를 가진 주체는 임의의 다른 주체에게 자신의 접근 권한을 넘겨줄 수 있다.
- TCSEC에서는 신분-기반 접근 통제 정책으로 DAC를 분류한다. Orange Book C등급
- DAC의 대표적인 구현 예로 ACL(Access Control List)가 있다.
- 방화벽 정책이나 TCP Wrapper 등 리눅스의 네트워크 서비스의 접근제어가 대부분 DAC를 따른다. 다만 이들은 ACL 형태로 구현될 뿐, 객체 소유자가 아니라 관리자가 정한 전체 규칙을 모든 요청에 똑같이 적용하므로 CISSP에서는 규칙 기반 접근통제의 예로 분류한다.
- "이 자원은 누구누구가 접근 가능하다." 또는 "누구누구는 이 자원에 접근 가능하다." 라는 식의 정의
임의적 접근통제는 객체(파일, 폴더, 데이터베이스 테이블 등)의 소유자가 누구에게 어떤 권한을 줄지 스스로 결정하는 방식이다. '임의적(discretionary)'은 소유자의 재량에 맡긴다는 뜻이다. 미국 국방부의 TCSEC(1985)은 C1 등급의 요구사항으로 DAC를 정의하며, 시스템이 사용자로 하여금 객체의 공유를 개인이나 그룹 단위로 지정·통제할 수 있게 해야 한다고 하고, 구현 수단의 예로 소유자·그룹·전체(self/group/public) 제어와 접근 제어 목록을 든다. 오늘날 대부분의 범용 운영체제와 파일 공유 서비스가 기본으로 쓰는 방식이다.
NIST IR 7316은 DAC의 판단이 접근을 요청한 주체의 신원에 근거하며, ACL과 소유자·그룹·기타(owner/group/other) 방식이 가장 흔한 구현이라고 설명한다.
| 구현 방식 | 구조 | 특징 |
|---|---|---|
| 접근 제어 목록 (ACL) | 객체마다 "누가 무엇을 할 수 있는가" 목록을 붙인다 (객체 중심) | 한 객체에 누가 접근할 수 있는지 보기 쉽다. 한 사용자의 전체 권한을 파악하려면 모든 객체를 뒤져야 한다. |
| 권한 목록 (capability list) | 주체마다 "무엇에 무엇을 할 수 있는가" 목록을 준다 (주체 중심) | 한 사용자의 권한을 보기 쉽다. 특정 객체의 접근자를 모으기 어렵다. |
| 접근 제어 행렬 (access control matrix) | 행은 주체, 열은 객체, 칸은 권한 | 이론 모델이다. ACL은 행렬의 열, 권한 목록은 행에 해당한다. |
- 권한 위임: 소유자는 다른 사용자에게 읽기·쓰기 권한을 주고, 경우에 따라 "권한을 다시 줄 수 있는 권한"(예: SQL의 GRANT OPTION, NTFS의 사용 권한 변경 권한)까지 넘길 수 있다. 위임이 이어지면 원래 소유자가 모르는 사이에 접근 범위가 넓어진다.
- 소유권: 객체를 만든 사용자가 보통 소유자가 된다. 소유권 이전이 가능한 시스템도 있다.
DAC의 가장 큰 약점은 정보 흐름을 통제하지 못한다는 것이다.
- 프로그램은 실행한 사용자의 신원과 권한을 그대로 물려받는다. 사용자가 트로이 목마를 실행하면, 그 프로그램은 사용자가 읽을 수 있는 모든 파일을 읽어 공격자가 읽을 수 있는 곳에 복사할 수 있다. 시스템 입장에서는 정당한 사용자의 정당한 접근으로 보인다.
- 읽기 권한을 받은 사용자가 파일 내용을 복사해 자기 소유의 새 파일로 만들면, 원래 소유자가 정한 접근 제한이 복사본에는 적용되지 않는다.
- NIST IR 7316도 DAC의 단점으로 정보 흐름에 대한 실질적인 보증이 없고, 사용자가 정보를 받은 뒤의 사용에 제한이 없으며, 트로이 목마 공격에 취약하다는 점을 든다.
- 이 문제를 시스템 수준에서 막기 위해 레이블로 정보 흐름을 강제하는 강제적 접근통제가 나왔다.
| 구현 | 설명 |
|---|---|
| 리눅스 권한(퍼미션) | 파일마다 소유자(user), 그룹(group), 기타(other) 세 부류에 대해 읽기(r)·쓰기(w)·실행(x) 권한을 둔다. chmod로 권한을 바꾸는 일은 파일 소유자나 특권 프로세스만 할 수 있다. 더 세밀한 통제가 필요하면 POSIX ACL(setfacl·getfacl)로 특정 사용자·그룹 항목을 추가한다. |
| 윈도우 NTFS ACL | 객체의 보안 설명자(security descriptor)에 소유자와 임의 접근 제어 목록(DACL, Discretionary Access Control List)이 들어 있다. DACL은 허용·거부 항목(ACE)의 목록이며, DACL 자체가 없으면 모두에게 전체 접근을 허용하고, 비어 있는 DACL은 누구에게도 접근을 허용하지 않는다. 폴더의 ACE는 하위 객체로 상속될 수 있다. |
| 클라우드 파일 공유 | 문서 소유자가 "링크가 있는 모든 사용자" 또는 특정 사람에게 보기·편집 권한을 준다. 소유자의 재량으로 외부 공유가 일어나기 쉬워 DLP·공유 정책으로 보완한다. |
| 데이터베이스 | 테이블 소유자가 GRANT·REVOKE로 다른 사용자에게 권한을 주고 회수한다. |
- 윈도우의 DACL이라는 이름 자체가 '임의(discretionary)' 접근 제어 목록이다. 이와 별도로 감사 기록용 시스템 접근 제어 목록(SACL)이 있다.
| 구분 | 임의적 접근통제 (DAC) | 강제적 접근통제 (MAC) |
|---|---|---|
| 누가 결정하나 | 객체 소유자 | 시스템 보안 정책 |
| 판단 근거 | 주체의 신원과 ACL | 보안 레이블(등급·범주) 비교 |
| 권한 위임 | 가능 | 불가능 |
| 정보 흐름 통제 | 없음 (복사본에 제한이 따라가지 않음) | 있음 (낮은 등급으로 흐름 차단) |
| 트로이 목마 | 취약 | 강함 |
| 장점 | 유연하고 구현·사용이 쉬움 | 중앙 통제, 높은 보증 |
| 단점 | 권한 관리가 분산되어 일관성이 떨어지고 권한이 쉽게 누적됨 | 경직되고 관리 부담이 큼 |
| TCSEC | C 등급(C1, C2) | B 등급 이상 |
- DAC의 핵심어는 소유자, 재량, 신원, ACL이다. "데이터 소유자가 접근을 결정한다"는 선택지는 DAC이다.
- DAC의 대표적인 약점은 트로이 목마와 권한 전파이다. 정보 흐름을 강제로 막아야 하면 MAC을 고른다.
- ACL은 객체 중심(열), 권한 목록(capability)은 주체 중심(행)이다.
- 방화벽 규칙, 라우터 ACL처럼 관리자가 모든 요청에 같은 규칙을 적용하는 것은 규칙 기반 접근통제이다. 흔한 오답: "ACL이니까 DAC".
- 리눅스 퍼미션과 NTFS ACL은 DAC의 대표 구현이다. 단, 같은 시스템에 SELinux나 무결성 수준 같은 강제 정책이 함께 있을 수 있다.
- NIST IR 7316, Assessment of Access Control Systems – NIST
- DoD 5200.28-STD, Trusted Computer System Evaluation Criteria – 미국 국방부(NIST CSRC 보관본)
- DACLs and ACEs – Microsoft Learn
- chmod(2) Linux manual page – Linux man-pages project