OS 보안과 접근 제어

OS 보안 (접근제어, ACL, 권한)

운영체제의 마지막 핵심 책임이 보안이다. 여러 사용자가 한 시스템을 공유하고, 외부 네트워크로 노출되며, 악성 코드가 끊임없이 침입 시도를 한다. 이 모든 위협으로부터 자원을 보호하면서도 정당한 사용자에게는 매끄러운 접근을 보장해야 하는 모순적 책임이 OS 보안의 핵심이다. 본 글은 인증·인가의 차이, 접근 제어 모델(DAC·MAC·RBAC), 유닉스 권한 비트와 ACL, 그리고 능력(capability) 기반 보안까지 OS 보안의 핵심 모델을 세심하게 정리한다(출처: 위키백과 — Computer security model). 제가 학교 리눅스 실습에서 처음 chmod 755 한 줄로 같은 디렉터리에 사용자별로 접근이 달라지는 모습을 봤을 때 "권한은 운영체제 안에 비트 몇 개로 정확히 인코딩되어 있다"는 사실이 비로소 손에 잡혔다.

 

인증과 인가 — Authentication vs Authorization

OS 보안의 가장 기본 두 단어가 인증(Authentication)과 인가(Authorization)이다. 두 단어가 일상 대화에서 자주 혼용되지만, 책임과 시점이 완전히 다른 두 단계의 메커니즘이다. 인증은 "당신이 누구인가"를 확인하는 절차이며, 인가는 "당신이 무엇을 할 수 있는가"를 결정하는 절차이다.

비교 항목	인증(Authentication)	인가(Authorization)
묻는 질문	"당신은 누구인가"	"무엇을 할 수 있는가"
시점	로그인 시점	자원 접근 시점마다
결과	사용자 ID 부여	허용 / 거부
대표 도구	비밀번호·OTP·생체·인증서	권한 비트·ACL·RBAC

여기서 인증과 인가의 분리란 두 책임을 같은 코드 경로에서 섞지 않고 별개의 단계로 처리해 권한 상승 취약점을 구조적으로 막는 설계 원칙을 가리킨다. 두 개념을 혼동하면 "로그인만 했으면 다 된다"는 식의 안일한 권한 검사로 이어져 보안 사고의 가장 흔한 통로가 된다. 솔직히 제 경험상 학교 보안 동아리에서 처음 OWASP Top 10을 봤을 때 가장 자주 등장하는 사고 카테고리가 정확히 "Broken Authentication"과 "Broken Access Control" 두 가지였고, 두 단어를 분리해 외운 후로는 코드 리뷰에서 권한 검사 누락이 거의 보이게 되었다.

접근 제어 모델 — DAC·MAC·RBAC

자원에 누가 어떤 동작을 할 수 있는지를 결정하는 정책이 접근 제어(Access Control)이며, 세 가지 표준 모델이 있다. 시험에서 자주 출제되는 항목이다.

모델	정책 결정자	특징	대표 채택
DAC (Discretionary)	자원 소유자	소유자가 자유롭게 권한 설정	Linux 파일 권한, Windows NTFS
MAC (Mandatory)	시스템 관리자·정책	라벨·등급 기반 강제 분리	SELinux, Bell-LaPadula, 군·금융
RBAC (Role-Based)	관리자가 정의한 역할	사용자 → 역할 → 권한 매핑	AWS IAM, 기업 ERP, K8s RBAC

여기서 DAC(Discretionary Access Control)는 자원의 소유자가 권한을 임의로 부여·회수할 수 있는 가장 유연한 모델이며, 우리가 일상에서 만나는 chmod·chown이 정확히 DAC의 구현체이다. MAC(Mandatory Access Control)는 사용자나 소유자가 권한을 임의로 바꿀 수 없고 시스템 정책이 강제하는 모델로, 군·정부·금융처럼 정보 등급이 명확한 환경에서 채택된다. RBAC(Role-Based Access Control)는 사용자에게 직접 권한을 주지 않고 "개발자·관리자·뷰어" 같은 역할을 부여한 뒤 역할에 권한을 묶는 방식으로, 사용자 수가 폭증하는 대규모 조직에서 사실상 표준이 되었다(출처: NIST RBAC Standard).

# Linux DAC — chmod로 권한 비트 직접 조작
$ ls -l report.txt
-rw-r--r-- 1 dongwon staff 2048 May 19 14:23 report.txt
   ^^^^^^^^^^
   소유자(rwx) 그룹(r--) 다른(r--)

$ chmod 640 report.txt    # 그룹은 읽기만, 다른 사람은 접근 금지
$ chmod u+x,g-r report.txt # 소유자 실행 권한 +, 그룹 읽기 -

# RBAC 스타일 (K8s) — 역할에 권한 묶음
$ kubectl create role pod-reader \
    --verb=get,list,watch --resource=pods
$ kubectl create rolebinding alice-reader \
    --role=pod-reader --user=alice

세 모델은 서로 배타적이지 않으며 실제 시스템은 거의 항상 혼합 형태로 운영된다. 예를 들어 리눅스는 기본적으로 DAC를 쓰지만 SELinux를 켜면 MAC가 위에 얹히고, 클라우드 환경은 IAM의 RBAC가 그 위를 다시 감싼다.

유닉스 권한 비트와 ACL

유닉스 계열의 가장 기본적인 접근 제어 단위가 9비트 권한이다. 파일마다 소유자(user)·그룹(group)·다른 사람(other) 세 주체에 대해 읽기(r)·쓰기(w)·실행(x) 세 권한을 비트로 부여한다. 시험에서 8진수와 기호 표기의 변환이 자주 출제되는 영역이다.

rwx  rwx  rwx          기호 표기
 7    7    7           8진수 표기
─── ─── ───
사용자 그룹 다른사람

예: chmod 755 script.sh
   → rwxr-xr-x  → 소유자 모두, 그룹/다른 사람 읽기·실행만

여기서 SUID(Set User ID)·SGID(Set Group ID)·Sticky bit 같은 특수 권한이 시험에 자주 출제된다. SUID가 켜진 실행 파일은 그 파일을 실행한 사용자가 아니라 파일 소유자의 권한으로 실행되며, /usr/bin/passwd가 대표적인 SUID 바이너리다. 일반 사용자가 자기 비밀번호를 바꾸려면 /etc/shadow(root 소유)에 써야 하는데, SUID 비트 덕분에 root 권한으로 실행되어 그것이 가능해진다. 이 메커니즘이 잘못 설정되면 권한 상승 공격의 통로가 되므로 보안 점검에서 가장 먼저 확인하는 항목 중 하나이기도 하다.

9비트 권한의 한계는 단 세 주체(소유자·그룹·다른)만 표현 가능하다는 점이다. "Alice는 읽기·쓰기, Bob은 읽기만, Carol은 접근 금지"처럼 사용자별로 다른 권한을 주려면 표현이 부족하다. 이를 보강하는 도구가 ACL(Access Control List)이며, 한 자원에 임의 수의 (사용자, 권한) 쌍을 따로 저장할 수 있게 해 준다.

# Linux ACL — setfacl / getfacl
$ setfacl -m u:alice:rw report.txt
$ setfacl -m u:bob:r   report.txt
$ getfacl report.txt
# owner: dongwon
# group: staff
user::rw-
user:alice:rw-
user:bob:r--
group::r--
mask::rw-
other::r--

ACL은 NTFS·ext4·XFS·ZFS가 모두 지원하며, 클라우드의 S3 버킷 정책·Google Drive의 공유 설정도 모두 같은 원리의 ACL이다. 솔직히 이건 예상 밖이었는데, 학교 실습에서 9비트 권한만 알다가 처음 ACL을 만져 본 후로는 "유닉스 권한은 사실 단순 도구일 뿐, 실세계는 거의 모두 ACL"이라는 점을 받아들였다.

능력(Capability) 기반 보안과 최소 권한 원칙

전통적인 접근 제어가 "자원이 누구를 허용하는가"를 자원 측에 저장한다면, 능력(Capability) 기반 보안은 그 반대로 "사용자가 무엇을 할 수 있는 토큰을 가지고 있는가"를 사용자 측에 저장하는 모델이다. 여기서 능력(Capability)이란 특정 자원과 그 자원에 허용된 동작을 묶은 위조 불가능한 토큰을 가리키며, 사용자가 그 토큰을 제시할 때만 동작이 허용된다.

리눅스 커널은 root의 거대한 권한을 잘게 쪼개 약 40개의 capability로 나누어 두었다. 예를 들어 네트워크 인터페이스를 설정하는 CAP_NET_ADMIN, 시스템 시간을 바꾸는 CAP_SYS_TIME, 메모리 잠금에 사용되는 CAP_IPC_LOCK 같은 식이다. 한 프로세스에 필요한 capability만 정확히 주면 root 전체 권한을 주지 않고도 같은 작업을 수행할 수 있다.

# 일반 사용자는 80번 포트 못 엶 → 보통 root로 실행
# 대신 nginx 바이너리에 CAP_NET_BIND_SERVICE만 부여
$ sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx
$ /usr/sbin/nginx   # 일반 사용자도 80번 포트 바인딩 가능

이는 보안 설계의 가장 핵심 원칙인 최소 권한 원칙(Principle of Least Privilege, PoLP)의 실전 구현이다. 최소 권한 원칙이란 한 주체에게 그 일을 수행하기 위해 꼭 필요한 권한만 부여하고 그 이상은 거부하는 보안 설계의 기본 원칙을 의미한다. 사고가 발생해도 침해 범위가 제한되며, 의도하지 않은 행위가 시스템 전체를 위협하는 일을 막아 준다.

마지막으로 시험 답안에서 자주 쓰이는 정형 표현을 정리하면, "OS 보안은 인증(누구인가)과 인가(무엇을 할 수 있는가) 두 단계로 구성되며, 접근 제어 모델은 DAC·MAC·RBAC 세 가지가 표준이다. 유닉스는 9비트 권한과 ACL의 결합으로 DAC를 구현하고, 최소 권한 원칙에 따라 capability를 잘게 쪼개 부여하는 것이 현대 보안 설계의 표준이다"는 두 문장이 표준 답안 표현으로 통한다. OS 시리즈는 이로써 7편(프로세스·스레드 / 동기화 / 메모리 / 스케줄링 / 파일시스템 / I/O / 보안)을 채웠으며, 다음 후보는 네트워크·분산·가상화·시스템 콜·부트로더로 10편 시리즈를 마무리해 갈 예정이다.

---

메타 디스크립션: OS 보안의 기본인 인증과 인가의 차이, 접근 제어 모델 3종(DAC·MAC·RBAC), 유닉스 9비트 권한과 ACL, capability 기반 보안과 최소 권한 원칙까지 OS 입문자 관점에서 세심하게 정리합니다.