[AWS 하드닝 02] 역할을 맡을 수 있는 사람과 할 수 있는 작업: IAM 최소 권한

About this offer

파일 하나를 읽으려고 붙인 권한이 어느새 버킷 전체 삭제까지 허용하고 있으면, 애플리케이션 오류도 보안 사고가 될 수 있습니다. IAM 하드닝은 허용 목록을 짧게 만드는 데서 끝나지 않습니다. 누가 역할을 맡을 수 있는지와, 그 역할로 무엇을 할 수 있는지 를 함께 확인해야 합니다. 기존 AWS 시리즈 에서 서비스별 역할을 정리한 데 이어, 이번에는 정상 업무를 유지하면서 접근 범위를 줄이는 방법을 살펴봅니다. IAM 역할과 S3 객체 이름을 알고 있다는 전제로, reports/ 아래 파일을 읽는 가상 업무를 살펴보겠습니다. 두 정책은 다른 질문을 받습니다 역할의 신뢰 정책은 어떤 주체가 그 역할을 맡을 수 있는지 정합니다. 역할에 붙은 권한 정책은 역할 세션으로 어떤 API 작업과 리소스에 접근할 수 있는지 정합니다. S3를 읽도록 권한을 붙였다고 누구나 그 역할을 맡을 수 있는 것은 아닙니다. 반대로 역할을 맡을 수 있다고 S3 읽기가 자동 허용되는 것도 아닙니다. 역할 신뢰 정책 관리 그림은 검토 순서를 나타냅니다. 실제 AWS 평가 과정에는 리소스 정책, 세션 정책, 권한 경계, 조직 정책 등이 더 들어갈 수 있습니다. 이 글의 작은 예제를 전체 IAM 엔진으로 확대해서 읽지 않습니다. 한 경로만 읽는 권한 정책 다음은 가상 S3 버킷에 대한 자격 증명 기반 권한 정책 입니다. 역할 신뢰 정책이나 버킷 정책은 포함하지 않았습니다. { "Version": "2012-10-17", "Statement": [ { "Sid": "ListReportNames", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-hardening", "Condition": {"StringLike": {"s3:prefix": ["reports/*"]}} }, { "Sid": "ReadReportObjects", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-hardening/reports/*" } ] } ListBucket 은 버킷의 객체 이름 목록을 조회하는 작업이라 버킷 ARN을 사용합니다. GetObject 는 객체 내용 읽기이므로 객체 경로가 붙은 ARN을 사용합니다. 파일 이름 목록과 파일 내용은 같은 권한이 아닙니다. S3 자격 증명 기반 정책 예제에서는 요청의 prefix가 reports/ 아래일 때만 목록을 허용하려고 reports/* 를 적었습니다. 콘솔이나 다른 도구는 빈 prefix로 목록을 먼저 요청할 수 있습니다. 그 요청이 거부된다고 바로 버킷 전체 목록 권한을 추가하기보다, 사용하는 클라이언트의 실제 호출을 확인합니다. 버전 객체 읽기나 KMS 복호화도 이 정책만으로 제공되지 않습니다. Allow가 있는데 왜 거부될까요? 적용되는 정책에 명시적인 Deny 가 있으면 해당 Allow 보다 우선합니다. 권한 경계는 권한을 새로 주는 정책이 아니라, 자격 증명 기반 정책이 부여할 수 있는 최대 범위를 제한합니다. 다만 리소스 정책이 누구에게 권한을 주는지에 따라 평가의 세부 규칙이 달라집니다. 모든 경우를 단순 교집합 하나로 설명하지 않습니다. IAM 정책 평가 실무 검토용 질문은 세 가지로 정리할 수 있습니다. 이 호출자는 예상한 역할인가요? 요청한 작업과 리소스가 필요한 범위 안인가요? 이 역할 외의 정책이 더 넓은 허용이나 거부를 만들고 있나요? 범위를 줄일 때 확인할 것 업무에서 실제 호출하는 작업과 리소스를 분리해 적습니다. 관측 기간에 호출이 없었다는 이유만으로 비상 복구 작업까지 불필요하다고 단정하지 않습니다. 테스트 역할에 정책을 붙여 정상 경로와 금지 경로를 함께 검사합니다. reports/a.json 읽기, 다른 경로 읽기, 객체 삭제를 서로 다른 시험으로 다룹니다. 승인된 다른 역할로 정책을 복구할 수 있는지 확인하고 적용 대상을 넓힙니다. 정책 오류로 조회가 끊겼다면 수정한 정책 버전이나 연결을 이전 검토 상태로 되돌립니다. 오류 메시지가 보인다는 이유만으로 s3:* 와 Resource: "*" 를 붙이면 무엇이 필요한지 확인할 근거가 사라집니다. 로컬 검증: JSON을 파싱하고 버킷/객체 ARN 구분, 두 작업, prefix 조건을 검사했습니다. 객체 범위를 버킷 전체로 넓힌 반례와 DeleteObject 를 추가한 반례는 학습용 기준을 통과하지 못했습니다. 이는 문자열과 구조 검사입니다. AWS IAM Policy Simulator, Access Analyzer, 실제 S3 요청은 실행하지 않았습니다. 자주 하는 오해 “읽기 전용이니 민감하지 않다”는 판단도 조심해야 합니다. 읽을 수 있는 보고서 안에 고객 정보가 있다면 쓰기 권한이 없어도 유출이 가능합니다. 최소 권한은 작업 종류뿐 아니라 데이터 범위까지 좁히는 일입니다. 확인 문제 신뢰 정책에 S3 읽기를 적으면 역할의 작업 권한이 되나요? 버킷 ARN과 객체 ARN을 나누는 이유는 무엇인가요? 새 요구사항이 reports/monthly/ 읽기뿐이라면 어디를 더 좁힐까요? 답과 해설 아닙니다. 역할 진입과 역할의 작업 권한은 별도 정책입니다. 작업이 대상으로 삼는 리소스 종류가 다르기 때문입니다. 목록 prefix와 객체 ARN을 함께 좁힙니다. 다른 정책이 더 넓은 접근을 허용하는지도 확인합니다. 복습과 다음 목표 오늘은 두 Statement가 받는 요청을 각각 써 보세요. 내일은 금지 경로 하나를 추가해 왜 거부돼야 하는지 설명해 보세요. 일주일 뒤에는 IAM 허용과 네트워크 도달 가능성을 함께 구분해 보세요. 확인일: 2026-10-04, 한국 시간 . IAM 정책 언어 2012-10-17 , S3 작업을 기준으로 작성했습니다. 예제 이름은 가상이며 그대로 운영에 적용한 정책이 아닙니다.