
“권한은 기능보다 먼저 설계되어야 한다”
1. 최소 권한 원칙이란 무엇인가
Principle of Least Privilege (PoLP), 최소 권한 원칙은
시스템의 사용자·계정·프로그램이
자신의 역할을 수행하는 데 필요한 최소한의 권한만 갖도록 설계하는 보안 원칙이다.
여기서 중요한 건 두 가지다.
- “최소한”
- “필요한 범위 내에서”
이 원칙은 단순히 권한을 줄이자는 이야기가 아니다.
기능 중심 설계가 아니라 ‘위험 통제 중심 설계’로 전환하자는 철학에 가깝다.
2. 왜 ‘최소’여야 하는가
많은 조직은 편의성을 이유로 권한을 넓게 준다.
- “관리자니까 다 보게 하자”
- “어차피 내부니까 괜찮다”
- “나중에 정리하자”
하지만 보안 사고는 보통
권한이 과도하게 열려 있는 지점에서 시작된다.
최소 권한 원칙의 핵심 논리는 단순하다.
“권한이 적을수록, 피해 범위도 작아진다.”
즉,
침해 가능성 자체를 없애는 것이 아니라
침해 시 영향을 통제하는 전략이다.
3. 최소 권한은 ‘사람’만의 문제가 아니다
많은 사람들이 최소 권한을
“직원 계정 권한 관리” 정도로 이해한다.
하지만 실제 적용 범위는 더 넓다.
- 사용자 계정
- 관리자 계정
- 서버 간 통신 계정
- API 토큰
- 데이터베이스 접근 권한
- 자동화 스크립트 계정
즉, 시스템에 존재하는 모든 ‘접근 주체’가 대상이다.
이 개념을 이해하지 못하면
보안은 “운영팀 일”로 밀려나게 된다.
4. 최소 권한은 ‘통제 설계’다
기획 관점에서 보면
최소 권한은 기능 설계의 일부가 아니라
위험을 설계하는 방식이다.
어떤 기능을 만들 때
보통 우리는 이렇게 생각한다.
- 이 기능은 무엇을 할 수 있는가?
- 어떻게 더 편리하게 만들 것인가?
하지만 최소 권한 관점에서는 질문이 달라진다.
- 이 기능은 누가 반드시 사용해야 하는가?
- 이 기능을 잘못 사용하면 어떤 위험이 발생하는가?
- 삭제, 수정, 조회 중 무엇이 가장 위험한가?
- 모든 사람이 볼 필요가 있는가?
이 질문을 던지는 순간,
기획은 UX 설계를 넘어 리스크 설계가 된다.
5. 최소 권한 원칙의 핵심 구조
최소 권한 원칙은 보통 다음 구조 위에서 작동한다.
1) 역할(Role) 정의
개인이 아니라 “역할 단위”로 권한을 설계한다.
- 운영 담당자
- CS 담당자
- 마케팅 담당자
- 데이터 분석가
2) 권한(Permission) 세분화
권한은 보통 다음과 같이 나뉜다.
- 조회(Read)
- 생성(Create)
- 수정(Update)
- 삭제(Delete)
여기서 가장 위험한 권한은
보통 Delete와 Update다.
3) 최소 매핑
각 역할에 필요한 권한만 매핑한다.
이 구조가 바로
Role-Based Access Control(RBAC)의 기본 논리다.
6. 최소 권한이 깨지는 순간
최소 권한 원칙이 무너지는 대표적인 패턴은 다음과 같다.
1. 긴급 대응을 이유로 최고 권한 부여
2. 테스트용 계정을 운영에 그대로 사용
3. 퇴사자 계정 방치
4. 로그 추적 기능 부재
이런 작은 누수가
대형 사고로 이어진다.
최소 권한은 한 번 설계했다고 끝나는 개념이 아니다.
지속적인 점검과 권한 회수 과정까지 포함하는 원칙이다.
7. 최소 권한과 기획자의 역할
기획자는 코드를 작성하지 않는다.
하지만 권한 구조는 대부분 기획 문서에서 시작된다.
예를 들어,
- “관리자는 모든 회원 정보 조회 가능”
- “운영자는 유저 정보 수정 가능”
이 문장은 단순 기능 정의처럼 보이지만
사실상 보안 정책 선언이다.
기획자가 최소 권한을 이해하고 있다면
문서는 이렇게 바뀐다.
- 운영자: 회원 상태값 변경 가능 (삭제 불가)
- CS: 개인정보 일부 마스킹 조회만 가능
- 삭제 기능은 2단계 승인 필요
기획 단계에서 이미
위험이 70% 줄어든다.
8. 최소 권한과 신뢰 구조
조직이 커질수록
“사람을 믿는 구조”에서
“시스템이 통제하는 구조”로 이동해야 한다.
최소 권한 원칙은
사람을 의심하는 철학이 아니라,
사람의 실수 가능성을 전제로
피해를 통제하는 설계 방식이다.
보안은 신뢰의 문제가 아니라
구조의 문제다.
9. 정리
Principle of Least Privilege는
단순한 보안 용어가 아니다.
- 기능 설계 방식
- 권한 구조 설계 철학
- 위험 통제 전략
- 조직 신뢰 체계
를 모두 포함하는 개념이다.
기획자가 이 원칙을 이해한다는 것은
“무엇을 만들 것인가”를 넘어서
“어디까지 허용할 것인가”
를 설계할 수 있다는 뜻이다.
'기타 (회고, 생각, 기획 등)' 카테고리의 다른 글
| 토스 인앱(Toss Mini App) 기획 및 개발 후기 (0) | 2026.03.06 |
|---|---|
| IA(Information Architecture)란 무엇인가 (0) | 2026.02.27 |
| Single Source of Truth (SSOT) (0) | 2026.02.10 |
| WBS, 간트차트, 마일스톤의 차이 (2) | 2026.01.13 |
| 기획자인데, 카피라이팅 앞에서 자꾸 멈췄다 (0) | 2026.01.08 |