AWS S3를 사용하기 위한 정책과 역할 설정을 해보자!

윤학·2023년 3월 27일

AWS IAM AWS S3

Aws

목록 보기

4/7

S3는 무엇인가요?

S3는 확장성, 강력한 일관성, 보안 및 성능을 제공하는 객체 스토리지 서비스이다.

S3는 데이터를 버킷이라고 불리는 객채들에 대한 컨테이너 안에 객체로 저장하는데 여기서 객체는 해당 파일을 설명하는 모든 메타데이터이며 개별 Key를 통해 버킷 내에서 고유하게 식별된다.

이 메타데이터는 파일에 대한 데이터와 시스템에서 제어하는 메타데이터 및 객체 업로드시 사용자가 정의한 메타데이터로 구성이 되는데 시스템 메타데이터에는 마지막 수정날짜와 같은 기본 메타데이터 및 Content-Type같은 HTTP 메타데이터가 포함된다고 한다.

그럼 하나의 버킷 내에 모든 객체가 저장되나요?

하나의 버킷 내의 저장 용량이나 객체 수에는 제한이 없지만 한 계정에는 100개까지만 만들 수 있다.

그리고 동일한 버킷 내의 객체라도 객체마다 연결된 스토리지 클래스가 있는데 간단하게만 살펴보자

S3 Standard: 빠른 액세스 시간과 자주 액세스 되는 데이터를 위한 기본 스토리지 클래스
S3 Standard-IA: 객체 데이터를 여러 가용 영역에 중복되게 저장해 가용 영역이 손실 되더라도 복원이 가능한 스토리지 클래스
S3 One Zone-IA: 객체 데이터를 하나의 가용 영역에만 저장하해 저렴하지만 지진과 같은 재해에 의해 손실 되었을 때 복구 불가한 스토리지 클래스
- 두 IA 스토리지 클래스의 공통점은 액세스 시간은 빠른 시간을 보장하지만 객체 검색 시 검색 비용, 보관을 적게 해도 30일치 비용 계산등 오래 자주 검색되지 않는 데이터에 적합
S3 Glacier: 데이터 아카이브를 위한 스토리지 클래스

그럼 스토리지 관리는 어떻게 하나요?
수명 주기 정책을 구성해서 객체를 관리하고 다른 스토리지 클래스로 전환할 수 있게 해주는 수명 주기, 객체의 삭제 또는 덮어쓰기를 방지 해주는 객체 잠금등의 관리 기능을 제공한다.

그럼 객체나 버킷은 누구나 접근 가능한가요?
이를 관리하기 위해 AWS에서는 퍼블릭 액세스 차단, 버킷 정책, 액세스 포인트와 같은 여러가지 기능을 제공하는데 여기선 IAM 정책을 통해 관리하는 방법을 소개한다.

과정은 다음과 같다.

AWS 권장 옵션들로 버킷 생성
IAM 사용자 생성
IAM 정책 생성 및 사용자에게 연결
IAM 역할 생성 및 EC2에 연결
PassRole 설정

그럼 시작!!

1. 버킷 생성

1) 이름과 지역 설정

여기에 나와있는 이름 규칙을 잘 설정하고 자신이 원하는 지역으로 설정!

2) 객체 소유권

ACL을 비활성화 하면 버킷의 소유자가 모든 객체를 소유하면서 소유권과 통제권을 가질 수 있는데 AWS에서 권장하는 옵션이며 한 계정 내에서 IAM 사용자를 추가해 사용자별로 액세스를 관리하기 위해 비활성화를 선택했다.

3) 퍼블릭 액세스 차단 설정

퍼블릭 액세스는 버킷 정책이나 ACL등을 통해 버킷 및 객체에 부여할 수 있는데 AWS에서는 기본적으로 모든 퍼블릭 액세스를 차단하는 것을 권장하고 있고,
지금은(3월) 새 버킷을 생성할 때 4가지의 각각 다른 설정을 통해 개별적으로 설정할 수 있지만 4월부터는 4가지가 전부 활성화 되어 차단된 상태로 버킷이 생성된다고 한다.

각 설정에 대한 설명은 여기서 잘 읽어보자.

그러니 나도 차단한 상태로 설정!

이후 항목들은 만지지 않고 생성 버튼을 누르면

퍼블릭이 아닌 상태로 버킷이 생성되는 것을 확인할 수 있다.

2. 폴더 생성

폴더는 간단히 폴더 이름을 지정해서 만들면 된다.

3. IAM 사용자 생성

지금까지 루트 계정으로 버킷을 생성했다면 이제 루트 계정 내에 각 역할별로 IAM 사용자를 생성해보자.

내가 루트 계정이고 백엔드 개발자에게 줄 IAM 사용자를 추가하는 과정이다.

1) 사용자 추가

IAM 서비스에 들어가 사용자 추가를 눌러보자

사용자의 이름을 설정해주고

이후에 정책을 생성해서 연결할 것이기 때문에 직접 정책 연결을 선택 후 아무것도 선택하지 않는다.

이후에 나타나는 사항들은 기본 설정으로 선택을 하면 사용자가 추가가 된다.

2) 액세스 키 만들기

처음 생성이 되면 액세스 키가 활성화 되지 않은 채로 생성이 된다.

나는 이후에 AWS SDK를 사용해 S3에 접근할 예정이기 때문에 액세스 키가 필요하므로 액세스 키를 만들어 보겠다.

해당 화면을 밑으로 내리면 보안 자격 증명탭에서 만들 수 있다.

보면 위와 같이 액세스 키를 어떤 용도로 사용할지에 따라 대안을 추천해주고 있다.

근데 AWS에서는 액세스 키와 같은 장기 자격 증명 방식을 사용하지 말도록 권장하고 있다.

애플리케이션 코드에서 AWS API를 호출할 때 AWS 자격 증명을 포함해야 하는데 액세스 키를 만들면 부여된 access key와 secret key로 자격 증명을 하고 AWS API를 호출할 수 있다.

사실 나도 이번 프로젝트에서 액세스 키를 만들어서 config 파일에 저장하고 필요할 때 로드해서 사용하였는데 이번에는 AWS에서 권장하고 있는 방식인 EC2 인스턴스에 IAM 역할을 연결해서 해당 인스턴스에서 실행되는 애플리케이션에 권한(역할 자격 증명)을 부여해 액세스 키를 만들지 않고도 API에 요청할 수 있도록 해보자.

이런 방식을 사용하면 아래와 같은 이점이 있다.

역할 자격 증명은 일시적이고 자동으로 교체되기 때문에 자격 증명 관리와 장기적 보안위험에 대해 걱정할 필요가 없다.
여러 인스턴스에서 단일 역할을 사용하는 경우 해당 역할 하나를 변경할 수 있으며 변경 사항은 모든 인스턴스에 자동으로 전파된다.
애플리케이션 코드에 노출되면 안되는 키 값들이 어디에도 저장 되지 않고 필요도 없다.

그럼 빨리 만든 IAM 사용자의 정책을 설정해주자.

4. IAM 정책 생성

버킷 정책이 아닌 IAM 정책을 선택한 이유는 프론트/백엔드 유저로 나누어서 IAM 사용자를 만들고 각 사용자별로 관리하기 위해서이다.

만약 버킷 단위로 액세스 권한을 다르게 주려면 버킷 정책을 사용하면 될 것 같다.

그럼 IAM 서비스에 들어가 정책 생성을 눌러준다.

일단 AWS 웹 페이지 콘솔 상에서 백엔드 사용자가 모든 버킷 목록을 볼 수 있도록 다음과 같이 작성한다.

Sid: 설명
Effect: 밑에 Action에 명시된 동작들을 Allow할지 Deny할지
Action: {AWS 서비스: 원하는 동작}
Resoucre: 적용 대상

나는 백엔드를 위한 정책 설정을 했으므로 이름과 설명을 위와 같이 적었다.

그럼 정책이 생성되는 것을 볼 수 있다!

5. IAM 정책 연결

이제 정책을 생성했으면 다시 아까 만든 사용자에게 권한을 추가해주자

방금 만든 정책을 검색해서 선택 후 연결!

그럼 해당 사용자에게 만든 정책이 연결 되었다!

연결 되었는지 확인하기 위해 백엔드 사용자로 로그인을 해보면 버킷 목록만 보게 정책을 설정했기 때문에 버킷 내의 객체에 대해서는 접근할 수 없다.

이제 콘솔과 코드 상에서 S3에 접근할 수 있도록 정책을 다시 수정해보자.

1) 정책 편집

정책 편집 메뉴를 누른 이후 수정!

수정 내용은 버킷의 객체 리스트를 볼 수 있고, 각 객체에 대해서 읽기 및 쓰기 동작 중 일부를 허용했다.

여기서 Resource가 버킷과 버킷 내의 모든 객체로 나뉜 이유는 ListBucket은 버킷 내의 객체 리스트를 보는 것이기 때문에 버킷 레벨에 해당하는 동작이고, Get, Put, Delete는 각 객체에 적용할 수 있는 객체 레벨에 해당하는 동작이기 때문이다.