운영체제 접근 제어 모델: DAC·MAC·RBAC의 차이와 적용
DAC, MAC, RBAC의 권한 결정 방식과 장단점, SELinux·Windows·엔터프라이즈 환경에서의 혼합 적용 방식을 정리한다.
2026-08-14 · 최초 발행 2026-01-16
접근 요청은 주체와 객체 사이에서 판정된다
운영체제 접근 제어는 권한이 없는 사용자나 프로세스가 시스템 자원에 닿지 못하게 하는 보안 메커니즘이다. 여기서 주체는 사용자, 프로세스, 애플리케이션이고 객체는 파일, 디렉터리, 메모리, 네트워크 소켓처럼 보호할 대상이다. 읽기, 쓰기, 실행, 삭제 같은 요청은 정책에 따라 허용하거나 거부한다.
접근 제어 설계에는 최소 권한, 직무 분리, 기본 거부 원칙이 함께 따라온다. 작업에 필요한 범위를 넘는 권한을 주지 않고, 중요한 작업은 여러 역할로 나누며, 명시적으로 허용하지 않은 요청은 막는 방식이다.
소유자가 권한을 정하는 DAC
DAC(Discretionary Access Control)는 객체 소유자가 자신의 재량으로 접근 권한을 설정하는 모델이다. 유연한 권한 변경이 필요한 파일 시스템에서 널리 쓰이며, Unix/Linux의 파일 퍼미션과 Windows ACL이 대표적이다.
Unix/Linux는 rwx 권한 비트를 소유자, 그룹, 기타의 3그룹에 적용한다. 숫자 표현에서는 r=4, w=2, x=1을 사용하며 755는 rwxr-xr-x를 뜻한다. SetUID(4), SetGID(2), Sticky(1) 같은 특수 비트도 있다.
기본 퍼미션보다 세밀한 제어가 필요하면 ACL을 사용한다. 사용자나 그룹별로 추가 권한을 줄 수 있으며, 예를 들어 아래 명령은 bob에게 report.txt의 읽기·쓰기 권한을 부여한다. 설정 결과는 getfacl로 확인한다.
setfacl -m u:bob:rw report.txt
getfacl report.txtWindows의 DACL(Discretionary ACL)은 SID(Security Identifier)와 ACE(Access Control Entry)로 구성된다. ACE에는 Allow와 Deny가 있으며, 평가는 Deny 다음 Allow 순서로 이뤄져 거부가 우선한다. 부모 디렉터리의 권한은 자식 객체로 상속될 수 있고, 명시적 권한은 상속 권한보다 우선한다. 필요하면 특정 객체에서 상속을 해제할 수도 있다.
DAC의 장점은 소유자가 즉시 권한을 조정할 수 있는 유연성과 단순한 운영 방식, 최소한의 오버헤드다. 반면 사용자가 악성 파일에 권한을 부여하는 트로이 목마 공격, 과도한 권한 부여에 따른 정보 유출, 조직 차원의 일관된 정책 적용이 어렵다는 문제가 남는다.
시스템 정책으로 강제하는 MAC
MAC(Mandatory Access Control)은 시스템 정책이 접근을 강제하는 방식이다. 객체 소유자가 임의로 정책을 바꿀 수 없으며, 기밀성과 무결성 보호를 중심에 둔다. SELinux, AppArmor, TrustedBSD가 대표적인 시스템이다.
다단계 보안(MLS)에서는 Top Secret > Secret > Confidential > Unclassified처럼 보안 레이블을 둔다. Bell-LaPadula 모델은 “읽기 하향, 쓰기 상향”(No Read Up, No Write Down)을 따르므로 Secret 사용자는 Confidential 파일을 읽을 수 있지만 Top Secret 파일은 읽을 수 없다. Biba 모델은 무결성을 중심으로 반대 방향인 “읽기 상향, 쓰기 하향”을 적용한다.
SELinux는 user:role:type:level 형태의 보안 컨텍스트를 사용한다. 예를 들어 system_u:object_r:httpd_sys_content_t:s0가 그 형식이다. 정책에는 Type Enforcement(TE), RBAC, MLS가 통합되며 Enforcing, Permissive, Disabled 모드를 제공한다.
Type Enforcement 정책은 다음처럼 프로세스 타입과 파일 타입의 허용 관계를 명시한다.
allow httpd_t httpd_sys_content_t:file { read open };
이 정책은 httpd_t 타입 프로세스가 httpd_sys_content_t 타입 파일에 read, open을 수행하도록 허용한다.
MAC는 트로이 목마와 권한 상승 공격 방어, 조직 전체에 동일한 정책 적용, 모든 접근 시도의 감사 추적에 강점이 있다. 그만큼 정책 설계와 유지보수가 복잡하고, 긴급 상황에서 유연하게 대응하기 어렵다. 모든 접근 때 정책을 평가하므로 성능 오버헤드도 고려해야 한다.
역할에 권한을 묶는 RBAC
RBAC(Role-Based Access Control)는 권한을 역할에 부여하고 사용자를 역할에 할당한다. 개인별 권한을 직접 관리하는 대신 직무 단위로 제어하므로 최소 권한 원칙을 적용하기 좋다. Oracle DBMS, Windows Active Directory, AWS IAM이 대표 사례다.
기본 요소는 사용자, 역할, 권한, 세션이다. 사용자는 alice나 bob 같은 개인 계정이고, 역할은 Developer·Manager·Auditor 같은 직무 단위다. 권한은 read_file, deploy_app처럼 작업 단위로 정의하며, 세션은 사용자가 활성화한 역할 집합을 뜻한다.
역할 계층에서는 상위 역할이 하위 역할의 권한을 상속한다. Manager 역할이 Developer 역할을 상속하면 코드 읽기와 쓰기 권한도 함께 갖는다.
RBAC에는 권한 집중을 막기 위한 제약도 둔다. 정적 직무 분리는 Developer와 Auditor처럼 상호 배타적인 역할을 동일 사용자에게 동시에 할당하지 않는다. 동적 직무 분리는 세션 안에서 상호 배타적 역할을 함께 활성화하지 못하게 하며, 개발자가 감사 작업을 수행할 때 Developer 역할을 비활성화하는 경우가 이에 해당한다. 카디널리티 제약은 역할별 사용자 수를 제한하는 방식으로, Admin 역할을 최대 3명으로 제한할 수 있다.
역할 단위 관리는 권한 관리의 복잡도를 낮추고, 새 사용자를 추가할 때 역할만 할당하면 되므로 확장하기 쉽다. 역할별 권한 추적도 수월하다. 다만 권한을 지나치게 세분화하면 역할 수가 급증하는 역할 폭발이 일어날 수 있고, 역할 변경 뒤 이전 권한을 회수하지 못하는 권한 크립도 발생한다. 시간이나 위치 같은 동적 조건을 표현하기 어렵다는 한계도 있다.
권한 결정 방식에 따른 선택
| 항목 | DAC | MAC | RBAC |
|---|---|---|---|
| 권한 결정자 | 소유자 | 시스템 정책 | 역할 정의 |
| 유연성 | 높음 | 낮음 | 중간 |
| 보안 강도 | 낮음 | 높음 | 중간 |
| 관리 복잡도 | 낮음 | 높음 | 중간 |
| 활용 분야 | 일반 파일 시스템 | 군사/정부 | 엔터프라이즈 |
실제 시스템에서는 하나의 모델만으로 요구사항을 충족하기보다 조합해서 적용하는 경우가 많다. SELinux는 Type Enforcement에 RBAC 역할을 더할 수 있으며, 웹 서버 프로세스인 httpd_t를 Developer 역할로 실행하도록 제한하는 식으로 활용한다.
Windows AD에서도 파일 시스템은 DACL(DAC), 그룹 정책은 RBAC(도메인 역할), Windows Defender Application Control은 MAC(화이트리스트)으로 나누어 적용할 수 있다.
속성과 컨텍스트까지 포함하는 접근 제어
ABAC(Attribute-Based Access Control)는 사용자, 자원, 환경의 속성으로 권한을 동적으로 결정한다. “오전 9시-5시에 사무실 IP에서 접근 시 허용”처럼 시간과 접속 위치를 정책 조건에 포함할 수 있다. RBAC만으로 표현하기 어려운 세밀한 제어를 보완하며 AWS IAM Policy와 Azure AD Conditional Access에서 활용된다.
제로 트러스트는 “절대 신뢰하지 말고, 항상 검증하라”는 원칙을 따른다. 모든 접근마다 인증과 인가를 다시 수행하고 마이크로 세그먼테이션을 적용하며, RBAC와 ABAC, 컨텍스트 인식을 함께 사용한다. 접근 제어 모델의 선택은 유연성, 강제성, 역할 기반 관리 효율 사이에서 보안 요구사항에 맞는 조합을 찾는 문제다.