[AWS] S3(Simple Storage Service)

AWS에서는 저장공간만 제공하는 서비스가 있습니다. 그걸 S3라고 부릅니다.

S3

Simple Storage Service의 앞 글자인 S가 3개라서 S3라고 부르는 것 같습니다. 

S3의 특징은 여러가지가 있는데,

 

1. 파일을 5TB까지 지원합니다. 

2. 저장공간을 알아서 조절합니다. 오토스케일링 기능이 내장 되어있습니다. 그리고 저장공간이 무한합니다.

3. Bucket이라는 이름을 사용합니다.

4. 버킷의 이름은 리전, 가용 영역 내에서 고유해야 합니다. ( 버킷 이름 지정 규칙 - Amazon Simple Storage Service )

 

S3에 OS를 올릴 수는 없지만 웹서비스 호스팅은 가능하다고 하다. 웹서비스를 올린 버킷에 Route53으로 도메인을 주면 버킷에 접근하여 웹서비스 사용이 가능하다고 하다.

 

S3의 구성요소

- key : 파일명

- value : 파일의 내용

- version ID : 파일의 버전(test.txt를 두번 올리면 먼저 올린 test.txt는 버전1, 그 다음에 올린 test.txt는 버전2)

- metadata : 데이터의 데이터(파일 업로드 날짜, 소유주 등)

- CORS(Cross Origin Resource Sharing) : 버킷에 있는 파일을 다른 버킷에서도 접근 가능하도록 해주는 기능( 교차 오리진 리소스 공유(CORS) 사용 - Amazon Simple Storage Service )

  cors는 웹 취약점 진단할 때 봤었는데 사용자가 다른 곳에 있는 리소스를 불러올 때 Access-Control-Allow-Origin 헤더를 보내주지 않으면 리소스를 거부한다.

인프런의 페이지 중 Access-Control-Allow-Origin 헤더를 보면 출처가 www.inflearn.com 일때만 리소스 허용해준다는 것을 뜻한다.

 

S3 Data Consistency

S3는 데이터 일관성, 변경한 내용이 즉각적으로 반영하는 등 사용자의 액션마다 데이터 일관성을 다르게 가져간다.

 

1. Read after Write Consistency(PUT) -> 파일 쓰기 후 읽기의 경우 데이터 일관성을 보장해준다. 파일을 올리면 바로바로 사용이 가능하다. 하지만 여러 사용자가 동시에 접근하면 타임스탬프를 기준으로 순차적으로 접근을 허용할지 검사한다.

 

2. Eventual Consistencty(Update / Delete) -> 버킷에 올라간 파일을 변경하거나 삭제할 경우 그 결과가 바로 나타나지 않습니다. 육안으로 볼때는 그래보여도 내부적으로는 그렇지 않습니다. 실제로는 그 시간이 아주 짧다고 합니다.(1초 미만)

하지만 트래픽이 많은 서비스의 경우 1초동안 누군가가 업데이트 한 뒤, 그것이 처리되기 전에 접근하는 경우도 있을 수 있습니다. 그럼 파일을 읽은 사람은 업데이트 전의 파일을 읽는 것이 됩니다.

보통 이런 성질은 NoSQL에서 나타난다고 합니다. NoSQL의 경우 빠른 데이터 처리가 주 목적이고 RDB의 경우 동시성을 중요시 하기 때문입니다.

 

S3의 종류

1. 일반 S3 -> 가용성, 내구성 좋음

 가용성: 문제가 생기면 고쳐서 서비스 제공 / 내구성: 문제가 생기면 우회하여 서비스 제공

 

2. S3 -IA(Infrequent Access)

 자주 접근하지는 않지만 접근 시 빠른 통신이 필요한 경우 / 멀티 AZ를 통해 데이터를 저장함

 

3. S3 - One Zone IA

 단일 AZ에 저장, 그렇기 때문에 가용성이 낮음

 

4. Glacier

 거의 접근하지 않을 데이터를 저장할 때 유용함, 아주 저렴하지만 접근 속도가 매우 느림 / 분리보관 데이터 넣을 때 사용하지 않을까 싶다..

 

5. Intelligent Tiering

 데이터 접근 주기가 불규칙할 때 사용함, 자동으로 본인이 알아서 저장소를 변경한다.

 접근이 많아지면 일반 S3로 옮기고 접근이 적어지만 S3-IA로 옮기는 등.. 

 

버킷 암호화

1. SSE-S3

• Amazon S3 표준 서버 측 암호화를 사용합니다.
• AWS에서 키를 관리합니다.

1. SSE-KMS

• AWS Key Management Service(AWS KMS)를 사용하여 암호화합니다.
• 고객이 키를 생성하고 관리합니다.

1. SSE-C

• 클라이언트가 제공한 키를 사용하여 암호화합니다.
• 키를 직접 생성하고 관리해야 합니다.

추가적으로 DSSE-KMS 방식도 존재한다. 이중 계층 서버 측 암호화(DSSE-KMS)를 출시합니다. 이 옵션은 Amazon S3의 새로운 암호화 옵션으로 S3 버킷에 객체를 업로드할 때 객체에 두 계층의 암호화를 적용합니다. DSSE-KMS는 두 계층의 CNSA 암호화에 대한 FIPS 규정 준수 및 DAR CP(미사용 데이터 기능 패키지) 버전 5.0 지침을 위한 국가 안보국 CNSSP 15를 충족하도록 설계되었습니다. DSSE-KMS를 사용하면 데이터에 여러 계층의 암호화를 적용하기 위한 규제 요건을 충족할 수 있습니다. ( Amazon S3 이중 계층 서버측 암호화(DSSE-KMS) 기능 출시 | Amazon Web Services 한국 블로그)

 

그리고 버킷을 만들 때 맨 밑에 보면 bucket key 옵션이 존재하는데 내용은 아래와 같다.

 

장점

1. 암호화 비용 절감

• AWS KMS에 대한 호출을 줄여 암호화 비용을 절감할 수 있습니다.

1. 키 관리 용이성

• 버킷 키는 버킷 수준에서 생성 및 관리되기 때문에, 키 관리가 용이합니다.

1. 보안 강화

• 키 유출 시 모든 객체가 노출되는 것을 방지할 수 있습니다.

단점

1. 키 관리 복잡성

• 버킷 키는 버킷 수준에서 생성 및 관리되기 때문에, 키 관리가 복잡해질 수 있습니다.

1. 키 유출 위험

• 키가 유출되면 해당 버킷에 저장된 모든 데이터가 노출될 수 있습니다.

1. 단일 장애 지점

• 버킷 키가 손상되거나 분실되면 해당 버킷에 저장된 모든 데이터에 접근할 수 없게 됩니다.

1. AWS KMS와 별도로 관리

• AWS KMS와 별도로 관리해야 하므로, 키 관리에 추가적인 노력이 필요합니다.

 

버킷 만들기

버킷은 글로벌 서비스이기 때문에 리전에 관계없이 고유해야 한다. 만약 고유하지 않으면 아래와 같이 이미 존재하는 이름이라며 버킷 생성이 안된다. 또 다른 버킷의 설정을 copy 할 수도 있다.

 

 

버킷의 소유권을 설정할 수 있다. 기본적으로 aws에서는 버킷을 private하게 생성하는 것이 원칙인 것 같다. 아무래도 글로벌 서비스이기 때문에 버킷의 소유권을 제한하지 않으면 누군가가 비정상적인 행위를 저지를 수도 있기 때문이다. 하지만 정상적으로 사내에서 다수가 사용해야하는 버킷이라면 ACL을 통해 권한을 제어할 수 있다.

 

버킷 버전관리 옵션은 동일한 이름의 파일을 버킷에 올리는 경우, 해당 옵션이 활성화 되어있으면 파일을 덮어씌우는 것이 아니라 별도의 파일로 관리를 한다.

 

대충 버킷을 만들어주고 안에 들어가면 아래와 같은 화면이 나온다. 폴더를 만들 수 있는데 한번 만들어보자.

 

폴더를 만들때도 암호화 옵션 적용이 가능하다.

 

그 다음 해당 폴더에 파일을 올려보았다.

위에 버킷을 만들 때 설정했던 내용들을 볼 수 있고

역시나 암호화 또한 가능하다. 그리고 checksum이라는 것도 있는데 보통 S3 객체들에는 MD5 체크섬을 가지고 있는데 이것을 이용해 데이터 무결성을 확인한다. 추가적인 check sum을 사용하면 기본으로 사용하는 MD5가 아닌 다른 함수를 사용한 체크섬을 이용한다는 뜻이다.

 

중간에 저장소 종류도 선택 가능하다.

 

올린 이미지를 보려면 안으로 들어가서 open 버튼을 누르면 된다. 또한 object url을 통해 접근이 가능한데 이는 public 접근 권한이 있을 때만 사용이 가능하다.

지금은 access denied가 나온다.

 

방금 만든 버킷을 public으로 변경해보자

 

edit을 눌러 모든 퍼블릭 액세스 차단 체크박스를 해제하고 confirm을 해주면 아래와 같이 나오고 버킷에 public access를 허용해주었다.

 

그 다음 파일의 설정도 변경해주어야 한다. 하지만 아래 그림처럼 edit가 비활성화 되어있는데 이는 버킷을 처음 생성할 때 ACL을 사용하지 않겠다고 설정해주었기 때문이다.

 

버킷 설정을 아래처럼 바꿔주면 오브젝트 Edit이 활성화 되어있는 것을 볼 수 있다.

 

그 다음 public access에 read 권한을 준다면? URL을 통해 이미지 접근이 가능해진다.

 

버킷 정책 편집기를 써보자

버킷 설정에 permissions 탭을 가보면 버킷 정책을 볼 수 있다. 여기에 JSON으로 버킷 정책 지정이 가능하다.

JSON을 몰라도 정책 생성기를 통해 생성이 가능하다.

 

적용하고자 하는 서비스를 선택해준다. 그리고 effect와 principal(IAM ARN 주소를 넣어 정책을 적용할 사용자 지정이 가능)을 이용하여 사용자를 지정해준다.

IAM에 가서 ARN을 확인하고 넣어주자.

 

그리고 버킷 ARN도 넣어준다. actions에는 GetbucketPolicy를 선택했는데 actions는 종류가 엄청 많으니 개인적으로 찾아보는 것을 추천

 

그리고 마지막으로 생성해주면 끝.. 나온걸 복붙해주자.

 

이 정책을 설정하여 암호화 방식을 강제할 수도 있다. AWS-KMS 방식이 아니면 업로드를 차단한다는 등 ...