최소 권한 원칙이 현장에서 실패하는 이유

클라우드 보안 진단에서 가장 많이 나오는 지적은 언제나 같습니다. 과도한 IAM 권한. 그리고 조치 계획서에는 늘 같은 문장이 적힙니다. "최소 권한 원칙을 적용하겠음."

1년 뒤 재진단을 가면 권한은 대체로 그대로입니다. 담당자가 게을러서가 아니라, 최소 권한을 유지하는 절차가 없기 때문입니다.

왜 실패하는가

권한을 좁히면 어딘가에서 업무가 막힙니다. 그때 담당자에게는 두 가지 선택지가 있습니다. 필요한 권한을 정확히 찾아서 추가하거나, 넓은 정책을 붙여서 일단 돌아가게 하거나. 급한 상황에서는 후자가 선택됩니다.

그리고 그 넓은 정책은 아무도 지우지 않습니다. 지웠을 때 무엇이 깨지는지 모르기 때문입니다.

로그에서 권한을 만든다

추측으로 정책을 쓰지 않습니다. CloudTrail 로그에서 해당 주체가 실제로 호출한 API 목록을 뽑아 정책을 생성합니다. AWS 는 IAM Access Analyzer 로 이 기능을 제공하지만, 관찰 기간이 짧으면 월말 배치나 분기 작업 같은 드문 호출이 빠집니다.

실무에서는 최소 90일을 관찰합니다. 분기 마감 작업이 한 번은 들어가야 합니다. 관찰 기간 동안은 넓은 권한을 유지하되 모든 호출을 기록합니다.

모든 예외에 만료일을 붙인다

넓은 권한이 필요한 순간은 반드시 생깁니다. 장애 대응이 대표적입니다. 이때 권한을 주지 않는 것이 아니라, 만료되는 권한을 줍니다.

• 임시 권한은 세션 기반으로 부여하고 최대 4시간
• 영구 정책 변경은 만료일 태그를 필수로 요구
• 만료일이 지난 정책은 주간 배치로 목록화해 담당자에게 통보

핵심은 삭제를 자동화하지 않는 것입니다. 자동 삭제는 운영 사고를 만들고, 사고가 나면 그 절차 자체가 폐기됩니다. 목록화와 통보까지만 자동화하고 삭제는 사람이 판단합니다.

깨지는 것을 미리 안다

정책을 좁히기 전에 차단 모드가 아닌 기록 모드로 먼저 검증합니다. 서비스 제어 정책(SCP)이나 권한 경계에서 거부될 호출을 시뮬레이션해 목록으로 만들고, 그 목록을 각 팀에 보냅니다. 이 단계 없이 적용하면 반드시 새벽에 전화가 옵니다.

정리

최소 권한은 한 번 하는 작업이 아니라 유지되는 절차입니다. 로그에서 산출하고, 예외에 만료일을 붙이고, 만료된 것을 사람에게 보여주는 것. 이 세 가지가 없으면 1년 뒤 같은 지적을 다시 받습니다.