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

윤학·2023년 3월 27일
0

Aws

목록 보기
4/6
post-thumbnail

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 keysecret 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는 각 객체에 적용할 수 있는 객체 레벨에 해당하는 동작이기 때문이다.

그리고 다시 백엔드 사용자로 돌아가보면 아까 볼 수 없었던 버킷 내의 객체가 보인다!

6. IAM 역할 생성

이번에는 EC2에 연결할 역할을 생성하기 위해 먼저 IAM 서비스에 들어가 새 역할을 만들자

EC2에서 실행하고 있는 애플리케이션에 역할을 부여할 것이므로 EC2를 선택

나는 아까 만든 IAM 정책을 연결할 것이다.

한 개의 EC2 인스턴스에는 하나의 역할만 부여할 수 있지만 여러 인스턴스에 동일한 역할을 부여할 수 있고 하나의 역할에 여러 정책을 연결할 수 있다.

이후 이름과 설명만 설정하고 생성하면 역할이 생성된다!

7. EC2에 역할 연결

연결을 원하는 인스턴스의 보안 탭에 들어가 역할을 추가해주자

방금 만든 역할을 추가해주면 완료!

원래는 역할을 추가하면 인스턴스 프로필을 추가로 구성해줘야 하는데 콘솔에서 작업하면 인스턴스 프로필에 대해선 신경을 쓰지 않아도 된다.

8. PassRole

한가지 아쉬운 점이 있다.

만약 백엔드 사용자가 인스턴스를 시작할 권한S3에 작업할 수 있는 권한이 있다고 할 때, 백엔드 사용자가 인스턴스를 시작하면서 연결한 역할에 더 높은 권한이나 S3 말고 다른 서비스를 작업할 수 있는 권한이 있을 수 있다.

이 때, 백엔드 사용자는 자신에게 원래 부여되지 않았던 권한을 EC2 내에서 부여받아 해당 서비스에 대해 작업을 수행할 수 있게 된다.

이런 상황을 막기 위해, 해당 백엔드 사용자가 EC2에 연결하는 역할이 적절한지 여부를 판단해주는게 PassRole이다.

적용 시키기 위해선 PassRole에 대한 정책을 만들어서 백엔드 사용자에게 추가시키면 되는데 Resource에는 백엔드 사용자가 넘겨줄 수 있는 권한이 담긴 역할을 지정해 주면 된다.

그 과정을 살펴보자!

1) RolePass에 관한 정책 생성

테스트를 위해 EC2에 대한 권한과 지정한 사용자가 넘겨줄 수 있는 역할을 지정해주고 난 이후 해당 정책을 백엔드 사용자에게 추가해준다.

2) 많은 권한이 부여된 역할 생성

테스트 용으로 역할을 만들고 해당 역할에 백엔드 사용자한테 부여되지 않았던 정책들을 추가해보자.

그리고 루트 계정으로 역할을 연결할 인스턴스에 방금 생성한 역할을 연결해두자.

3) 다른 사용자로 역할 변경

이제 백엔드 사용자로 로그인을 해서 해당 인스턴스의 역할을 변경하려하면 루트 계정에서 설정한 역할이 연결되어 있을 것이다.

그럼 이 역할을 PassRole 정책을 통해 백엔드 사용자가 넘겨줄 수 있도록 지정한 역할로 변경해보자.

그럼 위와 같이 성공적으로 역할을 변경할 수 있다.

4) 권한이 없는 역할로 변경

변경을 성공하고 나서 다시 권한이 더 많은 역할로 변경을 해보면 백엔드 사용자는 변경에 실패했다고 나온다.

매세지를 디코딩 해보면

S3-BackEnd 사용자가 EC2PassRoleTest역할에 대해 iam:PassRole 작업을 수행할 권한이 없다는 소리이다.

이렇게 하면 자신의 권한보다 더 많은 권한을 얻어 EC2를 실행하는 것을 방지할 수 있을 것이다.

마치면서...

S3에 대해서 작성한 것 보다 IAM에 대해서 작업한 것이 많은 느낌인데 IAM을 통해 AWS내의 모든 서비스에 대해 사용자나 그룹마다 정책을 달리해 관리 할 수 있다는 점에서 충분히 공부해볼만 한 것 같다.

또한, S3에 대해서도 버전 관리, 수명 주기, 람다와의 연결등 S3를 더 잘 이용할 수 있는 기능들에 대해서도 공부가 많이 필요해 보인다.

추후에는 액세스 키를 발급 받아 Nest에서 이미지와 영상을 올렸던 내용들을 정리해 보겠다.

참고

Blocking public access to your Amazon S3 storage
Using an IAM role to grant permissions to applications running on Amazon EC2 instances
What is Amazon S3?
Access control best practices
Control object ownership and disable ACLs on buckets
Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket
Access control list (ACL) overview

profile
해결한 문제는 그때 기록하자

0개의 댓글