IAM 권한이 없는 사용자는 S3 버킷을 만들 수 있을까: 정책 연결 전후 비교

AWS에서 "누가 무엇을 할 수 있는지"는 IAM이 정합니다. 개념을 정리한 뒤, 권한이 없는 사용자와 있는 사용자가 S3에서 어떻게 다르게 동작하는지 직접 확인했습니다.

결과: 권한이 없는 사용자는 버킷 생성에 실패했고, AmazonS3FullAccess 정책을 연결한 뒤에는 생성·업로드·다운로드·삭제가 모두 됐습니다.

IAM이 하는 일

**IAM(Identity and Access Management)**은 AWS 리소스에 대한 접근을 제어하는 서비스입니다. AWS 계정에 대한 인증과 권한 부여에 필요한 기반을 제공하고, 접근 여부뿐 아니라 언제, 어디서, 누가, 무엇을, 어떻게 할 수 있는지까지 정할 수 있습니다.

리소스: AWS 클라우드 안에서 만들거나 쓰는 개별 서비스의 객체 (예: S3 버킷, EC2 인스턴스)

루트 사용자는 일상 작업에 쓰지 않는다

AWS 계정을 처음 만들면 모든 서비스와 리소스에 완전한 권한이 있는 루트 사용자로 시작합니다.
루트 사용자는 일반 작업이 아니라 루트만 할 수 있는 작업에만 쓰고, 그 자격 증명은 따로 보호해야 합니다. 그래서 실습도 IAM 사용자를 새로 만들어 진행했습니다.

구성 요소

구성 요소	의미
IAM 사용자	한 사람 또는 한 애플리케이션에 대한 특정 권한을 가진 ID
IAM 사용자 그룹	IAM 사용자 여러 명을 묶은 것
IAM 역할	권한이 없는 사용자나 서비스에 일시적으로 권한을 위임. 장기 로그인 정보 대신, 역할을 맡는 동안만 쓰는 임시 자격 증명이 발급됨
IAM 정책	무엇이 허용·거부되는지 정의한 객체. 대부분 JSON 문서

역할은 이런 경우에 씁니다.

다른 계정의 리소스에 접근해야 할 때
모바일 앱에 AWS 키를 넣지 않고 리소스를 쓰게 하고 싶을 때
회사 디렉터리처럼 AWS 밖에서 이미 자격 증명을 가진 사용자에게 접근을 줄 때
외부 업체가 감사를 위해 계정에 접근해야 할 때

정책 종류

정책	하는 일	권한을 주나
ID 기반 정책	사용자·그룹·역할에 연결	준다
리소스 기반 정책	리소스에 연결, 다른 계정의 보안 주체에게도 줄 수 있음	준다
Organizations SCP	조직·OU 안 계정의 사용자·역할이 가질 수 있는 최대 권한	제한만
Organizations RCP	조직 안 계정의 리소스에 대한 최대 권한	제한만
ACL	다른 계정의 보안 주체가 리소스에 접근할 수 있는지 제어. JSON을 쓰지 않는 유일한 정책	교차 계정 접근 제어
세션 정책	역할·페더레이션 사용자를 위임할 때 세션 권한을 제한	제한만

ID 기반 정책은 다시 둘로 나뉩니다.

관리형 정책: 여러 사용자·그룹·역할에 붙일 수 있는 독립 정책. AWS가 관리하는 것과 고객이 직접 만드는 것이 있고, 고객 관리형이 더 세밀하게 제어됩니다.
인라인 정책: 한 사용자·그룹·역할에 직접 넣는 정책. ID와 1:1이라 ID를 지우면 같이 지워집니다.

S3 기본 개념

**S3(Simple Storage Service)**는 파일과 데이터를 저장하는 AWS 스토리지 서비스입니다. 데이터는 버킷 안에 객체로 저장됩니다.

객체 = 파일 + 그 파일을 설명하는 메타데이터. 버킷 안에서 고유한 키로 식별됩니다.
버킷 이름은 전체에서 유일해야 하고, 만들 때 리전을 정해야 합니다.
주소 형태: https://버킷이름.s3.리전.amazonaws.com

항목	의미
Key	파일 이름. 접두어와 `/`로 폴더처럼 쓸 수 있음
Value	파일 데이터
Version ID	같은 파일의 다른 버전을 구분. 이전 버전으로 복원 가능
Metadata	수정일, 타입, 소유자, 크기 등
ACL	접근·수정 권한

실습: 정책 연결 전후 비교

1. 권한 없는 사용자 만들기

콘솔 검색창에 IAM → 왼쪽 메뉴 [사용자] → [사용자 생성]
생성 후 그 사용자의 권한 정책을 보면 아무 권한도 없습니다.

2. 권한 없이 버킷 만들기 → 실패

새로 만든 사용자로 로그인
S3 → [버킷 만들기]
**"버킷 생성 실패"**가 뜨고 버킷이 만들어지지 않습니다.

3. 정책 연결

관리자 계정으로 돌아와 IAM → 그 사용자 → 권한 정책 → [권한 추가]
[직접 정책 연결] → AmazonS3FullAccess 검색해 추가

4. 권한 있는 상태로 다시 → 성공

작업	결과
버킷 생성	성공
파일 업로드 ([업로드] → [파일 추가])	성공
다운로드·열기	성공
삭제 (파일 체크 → [삭제])	성공

공격자 관점에서 보면

이 실습에서 쓴 AmazonS3FullAccess는 이름 그대로 S3 전체에 대한 모든 권한입니다. 확인용으로는 편했지만, 실제로는 이 사용자의 자격 증명이 새면 계정 안의 모든 버킷을 읽고 지울 수 있게 됩니다.

필요한 작업과 버킷만 허용하는 고객 관리형 정책이 더 안전합니다.
오래 쓰는 키 대신, 필요한 동안만 쓰는 역할의 임시 자격 증명을 쓰는 이유도 여기에 있습니다.
루트 사용자를 일상 작업에 쓰지 않는 것도 같은 이유입니다.

정리

IAM 사용자는 만든 직후 권한이 없고, 정책을 연결해야 리소스를 쓸 수 있습니다.
SCP·RCP·세션 정책은 권한을 주는 게 아니라 최대 범위를 제한합니다.
실습용 FullAccess는 확인용일 뿐이고, 실제로는 필요한 만큼만 허용해야 합니다.