사고는 대부분 "일단 되게 하려고" AdministratorAccess를 붙인 키가 유출되면서 터집니다. 최소 권한 원칙(least privilege)은 각 주체가 자기 일에 꼭 필요한 권한만 갖게 하는 것입니다. 말은 쉽지만 실무에서는 "어디까지 좁혀야 하는가"가 늘 문제라, 원리부터 절차까지 정리합니다.
IAM 정책은 4개 요소로 읽는다
IAM 정책은 JSON 문서이고, 핵심은 네 가지입니다.
| 요소 | 의미 | 예 |
|---|---|---|
| Effect | 허용/거부 | Allow / Deny |
| Action | 무엇을 하는가 | s3:GetObject |
| Resource | 어디에 | arn:aws:s3:::my-bucket/* |
| Condition | 어떤 조건에서 | 특정 IP, MFA 사용 시 |
JSON
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::reports-2026/*",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
이 정책은 "reports-2026 버킷의 객체를, MFA가 켜진 상태에서만 읽고 쓰게" 합니다. Resource를 *로 두지 않은 것이 핵심입니다.
사용자에게 권한을 직접 주지 않는다
실무의 첫 원칙은 역할(Role) 기반 접근입니다.
- 사람 → IAM 사용자/그룹, 또는 SSO로 임시 자격 증명을 받음
- 애플리케이션/EC2 → IAM Role을 부여(키를 코드에 박지 않음)
- 권한은 그룹·역할에 붙이고, 개인 사용자에는 직접 붙이지 않음
EC2가 S3에 접근해야 하면 액세스 키를 인스턴스에 심는 대신 Role을 연결합니다. 키가 코드나 깃 저장소로 새어나갈 일이 사라집니다.
좁혀가는 절차 — 넓게 주고 줄이지 않는다
| 상황 | 권장 접근 |
|---|---|
| 새 서비스 시작 | 필요한 Action만 명시하고 시작, * 금지 |
| 권한이 부족해 막힘 | 에러 메시지의 Action을 정책에 하나씩 추가 |
| 기존 과한 권한 정리 | IAM Access Analyzer로 실제 사용 권한 확인 후 축소 |
핵심은 "넓게 주고 나중에 줄이자"가 거의 실패한다는 것입니다. 한 번 넓게 준 권한은 "혹시 쓰일까 봐" 못 줄입니다. 처음부터 좁게 시작하고, 막히면 그때 필요한 Action만 더하는 방향이 안전합니다. 루트 계정은 일상 작업에 쓰지 않고 MFA로 잠가둡니다.
요점 정리
- 정책은 Effect·Action·Resource·Condition으로 읽고,
Resource: *를 피한다. - 사람·앱 모두 역할 기반으로, 키를 코드에 박지 않는다.
- 권한은 좁게 시작해 막힐 때 더한다. Access Analyzer로 사용 실태를 본다.
IAM 정책을 직접 작성하고 권한 오류를 좁혀가는 실습은 클라우드 트랙에서 무료로 할 수 있습니다.