최소 권한 원칙
더 많은 작업
- Principle of Least Privilege; PoLP; 최소 권한 원칙, 최소 권한
- 사용자와 프로세스, 서비스 계정 같은 모든 주체에게 맡은 일을 수행하는 데 필요한 최소한의 권한만, 필요한 기간 동안만 부여한다는 보안 원칙
최소 권한 원칙은 1975년 솔처(Saltzer)와 슈뢰더(Schroeder)가 제시한 보호 메커니즘 설계 원칙 가운데 하나로, "모든 프로그램과 사용자는 작업을 마치는 데 필요한 최소한의 권한 집합으로 동작해야 한다"는 문장으로 처음 정리되었다. 두 사람은 이 원칙이 우선 사고나 오류로 생길 수 있는 피해를 제한하고, 특권 프로그램끼리의 상호작용 수를 줄여 감사해야 할 범위를 작게 만든다고 설명했다. NIST 용어집도 "시스템이 사용자(또는 사용자를 대신하는 프로세스)의 접근 권한을 할당된 업무 수행에 필요한 최소 수준으로 제한해야 한다는 보안 원칙"으로 정의한다.
침해는 결국 누군가의 권한으로 일어난다. 피싱으로 탈취된 계정, 취약한 웹 애플리케이션의 실행 계정, 악성 패키지가 설치된 빌드 서버가 가진 권한이 곧 공격자의 권한이 된다. 최소 권한은 침해 가능성보다 침해됐을 때의 피해 범위(blast radius)를 줄이는 통제이며, 심층 방어와 제로 트러스트의 기초이다.
CISSP 출제 기준에서는 두 곳에 나온다. 도메인 3.1은 보안 설계 원칙으로서의 최소 권한을, 도메인 7.4는 보안 운영의 기본 개념으로서 "알 필요(need-to-know)와 최소 권한"을 묶어 다룬다. 설계 단계에서 권한 구조를 최소화하고, 운영 단계에서 그 상태가 유지되는지 관리한다는 흐름으로 이해하면 된다.
알 필요(need-to-know) 원칙은 업무 수행에 그 정보가 필요하다고 판단된 사람에게만 정보 접근을 허용한다는 원칙이다. 군과 정부의 비밀 취급 제도에서 나왔으며, NIST 용어집(CNSSI 4009 인용)은 "정당한 정보 보유자가, 받는 사람이 공식 업무를 수행하기 위해 특정 정보에 접근할 필요가 있다고 내리는 판단"으로 정의한다. 비밀취급인가(clearance)가 어느 등급까지 볼 수 있는지 정한다면, 알 필요는 그 등급 안에서 어떤 정보를 볼 수 있는지 정한다. 1급 비밀 취급 인가자라도 담당 사업과 무관한 1급 비밀은 볼 수 없다. 솔처와 슈뢰더도 군의 알 필요 규칙을 최소 권한의 한 예로 들었다.
| 구분 | 최소 권한 | 알 필요 |
|---|---|---|
| 다루는 대상 | 권한(행위): 읽기·쓰기·실행·삭제·관리 등 무엇을 할 수 있는가 | 정보(내용): 어떤 데이터·문서를 볼 수 있는가 |
| 주체 | 사용자, 프로세스, 서비스 계정, 기기, AI 에이전트 | 주로 사람(정보 이용자) |
| 적용 수준 | 시스템·애플리케이션 권한 설계, OS·DB 권한 | 데이터 분류와 업무 배정, 구획(compartment) |
| 예 | 백업 운영자에게 백업·복원 권한만 주고 데이터 열람 권한은 주지 않는다 | 인사팀원이라도 자기 담당 부서 직원의 급여 자료만 본다 |
| 관계 | 알 필요는 정보 접근에 최소 권한을 적용한 것이다. 둘 다 "업무상 필요"가 판단 기준이며 함께 적용한다 | |
| 대상 | 흔한 과잉 권한 | 최소 권한 적용 |
|---|---|---|
| 일반 사용자 | 로컬 관리자 권한, 전사 공유 폴더 전체 쓰기 | 표준 사용자 계정, 부서·역할별 폴더 권한 |
| 관리자 | 업무 계정 하나로 메일·웹과 서버 관리를 모두 수행 | 일반 업무 계정과 관리자 계정 분리, 관리 작업은 전용 단말에서 |
| 서비스 계정 | 도메인 관리자 그룹 소속, 비밀번호 만료 없음 | 해당 서비스에 필요한 권한만, 대화형 로그인 금지, 관리형 서비스 계정 사용 |
| 애플리케이션 프로세스 | 웹 서버가 root로 실행, DB 계정이 DBA 권한 | 비특권 계정 실행, 필요한 테이블·작업만 허용된 DB 계정 |
| 클라우드 워크로드 | 와일드카드(*) 권한 정책, 장기 액세스 키 | 리소스·작업 단위 정책, 임시 자격 증명 |
| AI 에이전트 | 사용자 권한을 그대로 위임받아 모든 도구 호출 가능 | 에이전트별 신원(비인간 신원) 부여, 허용된 도구·데이터만, 고위험 작업은 사람 승인 |
AI 에이전트는 프롬프트 주입으로 의도와 다른 도구 호출을 유도당할 수 있으므로, 에이전트가 가진 권한이 곧 공격자가 얻을 수 있는 최대 권한이라고 보고 설계해야 한다.
권한 누적(privilege creep, 권한 크리프)은 직원이 부서를 옮기거나 업무가 바뀔 때 새 권한은 추가되고 예전 권한은 회수되지 않아 시간이 지날수록 권한이 쌓이는 현상이다. 오래 근무한 직원일수록 과잉 권한을 가지게 되며, 그 계정이 탈취되거나 본인이 악의를 품으면 피해가 커진다. 직무 분리도 깨질 수 있다. 방지 수단은 다음과 같다.
- 입사·이동·퇴사(joiner-mover-leaver) 절차에 권한 회수를 포함한다. 이동 시에는 기존 권한을 먼저 회수하고 새 권한을 부여한다(계정 수명 주기 관리).
- 주기적인 접근 권한 검토에서 관리자와 데이터 소유자가 권한을 재승인하게 한다.
- 개인에게 직접 권한을 주지 않고 역할에 권한을 묶어 역할 변경만으로 권한이 바뀌게 한다.
- 쓰지 않는 계정과 권한을 사용 기록으로 찾아 회수한다.
- 강제 휴가와 직무 순환으로 한 사람이 권한을 독점한 상태를 드러낸다.
| 방법 | 설명 |
|---|---|
| 역할 기반 접근통제(RBAC) | 직무에 맞춘 역할에 권한을 묶고 사용자는 역할을 받는다. 역할 설계가 넓으면 최소 권한이 깨지므로 역할을 업무 단위로 잘게 나눈다 |
| 속성 기반 접근통제(ABAC) | 부서, 데이터 등급, 시간, 위치 같은 속성으로 요청마다 판단해 더 세밀하게 제한한다 |
| 적시 접근(JIT, Just-in-Time) | 상시 관리자 권한(standing privilege)을 없애고 필요할 때 승인을 받아 정해진 시간만 권한을 올린다. 적시 접근 권한 참고 |
| 특권 계정 관리(PAM) | 관리자 계정 비밀번호 금고 보관, 세션 기록, 자동 교체. 특권 계정 관리 참고 |
| sudo 제한 | 리눅스에서 root 로그인을 막고 sudoers에 사용자별로 허용 명령을 명시한다. 셸 탈출이 가능한 명령이나 ALL 허용은 피한다 |
| Windows 권한 분리 | 사용자 계정 컨트롤(UAC)로 관리자도 평소에는 표준 권한으로 실행하고, 관리 작업 때만 권한 상승을 승인한다 |
| 컨테이너 비루트 실행 | 컨테이너 이미지에서 비루트 사용자로 실행하고, 불필요한 리눅스 capability를 제거하며, 특권(privileged) 모드와 호스트 경로 마운트를 금지한다 |
| 서비스 계정 관리 | 서비스별 전용 계정, 최소 권한, 자격 증명 자동 교체. 서비스 계정 관리 참고 |
| 강제적 접근통제 | SELinux 같은 MAC로 root 프로세스도 정책 밖의 행동을 못 하게 제한한다 |
- 설계(3.1): 시스템을 처음부터 권한이 작게 나뉜 구조로 만든다. 특권이 필요한 기능을 작은 구성 요소로 분리(권한 분리)하고, 기본값은 권한 없음(안전한 기본값)으로 둔다. 보안 설계 원칙 참고.
- 운영(7.4): 그렇게 만든 구조가 시간이 지나도 유지되게 한다. 권한 요청·승인 절차, 특권 계정 관리, 권한 검토, 직무 순환, 모니터링이 운영 단계의 수단이다.
- 측정: 상시 관리자 계정 수, 90일 이상 미사용 권한 수, 권한 검토 완료율 같은 지표로 최소 권한 상태를 관리한다.
- 최소 권한은 권한(무엇을 할 수 있나), 알 필요는 정보(무엇을 볼 수 있나)에 관한 원칙이다. 둘을 구분하되 함께 적용한다.
- 비밀취급인가가 있어도 알 필요가 없으면 접근할 수 없다. "인가 등급이 충분하므로 접근 허용"은 흔한 오답이다.
- 부서 이동 후 이전 권한이 남아 있는 상황은 권한 누적이다. 해결책은 접근 권한 검토와 이동 시 권한 회수이다.
- 관리자에게도 평상시 업무용 일반 계정을 따로 주는 것이 최소 권한의 적용이다.
- 서비스 계정과 AI 에이전트 같은 비인간 신원(non-human identity)도 최소 권한의 적용 대상이다.