최소 권한 원칙, 설명

최소 권한은 말로 꺼내놓으면 자명해 보인다: 계정, 프로세스, 사용자에게 업무 수행에 필요한 접근 권한만 주고 그 이상은 주지 말 것. 말하는 것과 실제로 시스템을 그렇게 운영하는 것 사이의 간격이 바로 대부분의 침해가 사소한 사건에서 도메인 전체 손상으로 확대되는 지점이다.

실제 의미

최소 권한 원칙(PoLP)은 시스템의 모든 주체 — 사용자, 서비스 계정, 애플리케이션, 컨테이너 — 가 기능을 완수하는 데 필요한 최소 권한 집합으로 작동해야 한다고 말한다. 편의상 주어지는 권한이 아니다. 3년 전에 누가 부여했다가 취소하지 않은 권한이 아니다. 최소한만이다.

이는 모든 계층에 적용된다: 파일 시스템 권한, 데이터베이스 역할, API 스코프, 클라우드 IAM 정책, 방화벽 규칙, sudo 접근. 정적 파일을 읽는 웹 서버 프로세스는 /etc에 대한 쓰기 접근이 필요 없다. SELECT 쿼리만 실행하는 보고서 스크립트는 DROP TABLE 권한이 있는 데이터베이스 역할이 필요 없다. 마케팅 인턴은 IT가 문제 해결을 위해 한 번 설정했다고 해서 도메인 관리자 권한이 필요 없다.

들리는 것보다 중요한 이유

공격자가 계정이나 프로세스를 손상시키면, 그 계정이 할 수 있는 모든 것을 상속한다. 피싱된 직원의 노트북이 그들 팀과 관련된 파일 공유에만 접근 가능하면, 피싱의 영향 범위는 제한된다. 같은 계정이 IT가 문제 해결을 위해 설정했다가 롤백하지 않은 도메인 관리자 권한을 우연히 가지고 있다면, 공격자는 이제 네트워크를 소유한다.

대부분의 침해 후 포렌식 보고서의 논리가 바로 이것이다: 초기 접근은 낮은 가치였지만, 과도한 권한을 가진 계정을 통한 횡적 이동이 전체 환경의 랜섬웨어로 변했다. 과도한 권한이 초기 침해를 야기하지는 않지만, 침해를 비용이 많이 드는 사건으로 만드는 것은 거의 항상 과도한 권한이다.

실제 사례

Cloud IAM. AWS, Azure, GCP는 주의하지 않으면 모두 허용적 동작을 기본값으로 한다 — "Action": "*"와 "Resource": "*"를 가진 IAM 정책은 검증을 통과하고 잘 작동하지만, 유출된 액세스 키가 공격자에게 전체 계정 제어를 넘길 때까지는 말이다. 와일드카드에 의존하지 말고 정책을 특정 작업과 리소스 ARN으로 제한하라.

Service accounts. 인간 계정처럼 검토되지 않아서 가장 심각한 문제가 되는 경우가 많다. 하나의 S3 버킷에 배포하는 CI/CD 파이프라인이 계정의 모든 버킷을 읽을 수 있는 자격 증명을 보유해서는 안 된다.

Database roles. 읽기 전용 보고서 역할을 INSERT/UPDATE가 필요한 애플리케이션 역할과 분리하고, 이들을 스키마를 변경할 수 있는 DBA 역할과 분리하라. PostgreSQL과 MySQL 둘 다 세분화된 GRANT 문을 지원한다 — 모든 애플리케이션 연결에 루트 권한을 주는 대신 이를 사용하라.

Sudo와 로컬 관리자. Just-in-time 승격(접근 요청, 제한된 기간 동안 획득, 자동으로 소실)이 항상 상설 관리자 권한을 이긴다. 시간 제한이 있는 규칙이 있는 sudo, 또는 엔터프라이즈 환경의 PAM 솔루션 같은 도구들이 정확히 이 목적을 위해 존재한다.

다음의 긴장 관계