IAM 정책 vs 리소스 정책: 프로덕션(및 체육관)에서 얻은 교훈

발행: 16시간 전 (2025년 12월 9일 오후 10:08 GMT+9)

8 min read

원문: Dev.to

Source: Dev.to

배경

AWS 여정을 시작했을 때, 몇 시간 동안 머리를 싸매게 만든 문제가 있었습니다.

프론트엔드 엔지니어가 저에게 다가와 말했습니다:

“Tony, 우리 앱 로고와 이미지를 사용자들이 볼 수 있게 하고 싶은데 작동하지 않아요. 계속 거부당하고 있어요.”

IAM 권한을 다시 한 번 확인했지만—모든 것이 정상으로 보였습니다. 사용자는 올바른 접근 권한을 가지고 있었습니다. 그럼에도 불구하고 왜 여전히 차단되는 걸까요?

문제는 IAM이 아니라 S3 버킷의 리소스 정책이었습니다.

그때 깨달았습니다: AWS 접근 관리는 체육관을 관리하거나 규칙적인 피트니스 루틴을 지키는 것과 많이 닮아 있다는 것을.

IAM 정책은 개인 트레이너와 같습니다. 당신(정체성)이 무엇을 할 수 있는지를 정의합니다:

AWS에서는 IAM 정책이 사용자, 그룹, 혹은 역할에 연결됩니다. 이 정책은 정체성이 수행할 수 있는 행동과 해당 행동을 할 수 있는 리소스를 제어합니다.

실제 운영 환경에서는 모든 IAM 사용자에게 MFA를 적용했습니다. 이것은 VIP 체육관 구역에 들어가기 전에 두 번째 체크포인트를 추가하는 것과 같습니다—키카드(비밀번호)는 가지고 있어도 지문(MFA) 없이는 들어갈 수 없습니다. 간단하지만 보안을 크게 높여줍니다.

리소스 정책은 체육관 벽에 붙어 있는 규칙과 같습니다. 트레이너가 허가를 주더라도, 규칙이 여전히 접근을 제한할 수 있습니다:

AWS에서는 리소스 정책이 리소스(S3 버킷, Lambda 함수, SQS 큐 등)에 직접 연결됩니다. 이 정책은 누가 해당 리소스에 접근할 수 있는지를 정의하며, 다른 AWS 계정이나 공개 접근도 포함할 수 있습니다.

ALB 로그 – 버킷 정책을 수정해 애플리케이션 로드 밸런서가 추가 권한 없이도 접근 로그를 안전하게 전송하도록 했습니다.
프론트엔드 이미지/로고 – 사용자가 로고와 이미지를 읽을 수 있도록 버킷 정책을 만들고, 민감한 파일에 대한 접근은 차단했습니다. 사용자는 정확히 필요한 것만 얻었습니다.

제가 빨리 깨달은 점은 규모가 모든 것을 바꾼다는 것입니다.

IAM 정책은 정체성에 대해 확장성이 가장 좋습니다. 하나의 정책으로 여러 사용자, 그룹, 역할을 관리할 수 있어 내부 팀에 최적입니다.
리소스 정책은 리소스에 대해 확장성이 가장 좋습니다. 계정 간 공유나 공개 접근이 필요할 때, 리소스 정책은 리소스 자체가 접근을 제어하도록 합니다.

두 가지를 함께 사용하는 것이 필수적입니다. IAM은 사용자가 해야 할 일만 하도록 보장하고, 리소스 정책은 IAM 권한이 있더라도 리소스 자체를 보호합니다.

예시: 우리 재무 보고서 버킷은 재무 사용자에게 IAM 권한을 부여했지만, 리소스 정책은 우리 AWS 계정만 접근하도록 제한했습니다. 계층형 보안 덕분에 실수나 악의적인 접근을 방지하고 안심할 수 있었습니다.

AWS 접근 제어의 성공은 피트니스와 마찬가지로 훈련의 층에서 나옵니다:

두 가지를 함께 사용하면 지속 가능한 결과를 얻고 실수, 누출, 오용을 방지할 수 있습니다. 한 층을 무시하는 것은 유산소 운동을 빼먹거나 칼로리를 기록하지 않는 것과 같습니다—일시적인 진전은 보일 수 있지만 나중에 문제가 드러납니다.

AWS에서는 IAM만 의존하고 리소스 정책을 무시하면 “알 수 없는 거부” 오류와 좌절한 사용자를 마주하게 됩니다.