최소 권한 원칙이란?

서론

보안 관련 글을 읽다 보면 자주 등장하는 개념 중 하나가 최소 권한 원칙(Principle of Least Privilege) 입니다.
이 원칙은 단순하면서도, 잘 지키기만 해도 보안 사고를 크게 줄일 수 있는 강력한 아이디어입니다.

이 글에서는 초보 개발자의 관점에서,
왜 최소 권한 원칙이 중요한지, 코드와 인프라에서 어떻게 적용할 수 있는지 간단한 예시로 살펴보겠습니다.

1. 최소 권한 원칙이란?

정의는 아주 간단합니다.

한 주체(사용자, 서비스, 프로세스 등)는
자신의 역할을 수행하는 데 꼭 필요한 권한만 가져야 한다.

즉:

• "혹시 몰라서" 넉넉하게 권한을 주는 것이 아니라,
• "정말 필요한 만큼만" 권한을 부여하자는 철학입니다.

2. 권한을 많이 줄수록 왜 위험할까?

예를 들어:

• 단순히 글을 읽기만 하는 서비스 계정에
• DB 전체 쓰기/삭제 권한까지 줬다고 해 보겠습니다.

이 계정이 탈취되면:

• 공격자는 단순 조회를 넘어서
• 데이터 수정/삭제까지 할 수 있게 됩니다.

권한 범위가 넓을수록:

• 하나의 계정/토큰이 털렸을 때 피해 범위도 같이 커집니다.

3. 애플리케이션에서의 최소 권한

3.1 사용자 역할 설계

서비스를 만들 때:

• "관리자", "일반 사용자" 정도만 나누는 경우가 많습니다.

하지만 관리자에게:

• 정말 모든 기능(데이터 삭제, 설정 변경, 결제 관련 기능 등)을 한 번에 맡기는 것이 맞는지 고민해 볼 필요가 있습니다.

가능하다면:

• 관리 기능도 역할/기능별로 더 쪼개서 권한을 나누는 것이 좋습니다.

3.2 API 설계

각 API 엔드포인트에 대해:

• "이 작업을 누가 할 수 있어야 하는가?"
• "이 리소스를 읽기만 가능해야 하는가, 쓰기도 가능해야 하는가?"

를 명확하게 정의한 뒤:

• 코드 상에서 그 정책을 체크해야 합니다.

4. 인프라에서의 최소 권한

4.1 클라우드 IAM

AWS, GCP, Azure 같은 클라우드에서는 IAM(Identity and Access Management)을 통해 권한을 관리합니다.

여기서 자주 보게 되는 안 좋은 패턴:

• Administrator, Owner 같은 최상위 권한을 광범위하게 부여하는 것

좋은 습관:

• 서비스/마이크로서비스마다 별도의 서비스 계정을 만들고
• 그 서비스가 실제로 사용하는 리소스(S3 버킷, DB 등)에만 권한을 부여

4.2 데이터베이스 계정

개발 초기에:

• 애플리케이션이 DB에 접속할 때 root 같은 계정을 쓰는 경우가 많습니다.

하지만 실제로는:

• 서비스별로 읽기/쓰기 권한을 나눠서 계정을 만들고
• 스키마/테이블 단위로 권한을 제한하는 것이 안전합니다.

5. "조금 귀찮음"과 "사고 났을 때의 후회"

최소 권한 원칙을 적용하는 과정은:

• 처음에는 다소 귀찮고 시간이 더 걸리지만,
• 사고가 발생했을 때 "그래도 여기까지만 털리고 끝났다" 라고 말할 수 있게 해 줍니다.

반대로:

• 권한을 넉넉하게 열어 두면 개발은 잠시 편할 수 있지만,
• 나중에 사고가 나면 "이 권한만 줄였어도…" 라는 후회를 남기기 쉽습니다.

마무리

최소 권한 원칙은 보안의 가장 기본적인 철학 중 하나입니다.

정리하면:

• "혹시 몰라서 넉넉하게"가 아니라,
• "정말 필요한 만큼만" 권한을 주는 것이 핵심

앞으로 서비스를 설계하거나 권한을 설정할 때, "이 계정/서비스/사용자에게 과한 권한을 주고 있지는 않은가?"를
한 번만 더 점검해 본다면,
그것만으로도 보안 수준을 크게 끌어올릴 수 있을 것입니다.