Section 14. S3 보안

Object Encryption

다음 네 가지 방법 중 하나로 S3 버킷의 객체를 암호화 할 수 있다!

1. Server-Side Encryption(SSE)
   • S3 Managed Keys로 암호화 한다.
     1. 이것은 버킷과 객체에 기본적으로 활성화되어 있다.
   • KMS 키로 암호화 키를 관리해서 암호화 하는 SSE-KMS가 있다.
   • 사용자 제공 키인 SSE-C도 있다. 직접 암호화 키를 제공하는 방식이다.
2. Client-Side Enccryption
   • 클라이언트 측에서 암호화한 다음 S3에 업로드 하는 방식이다.

1. SSE-S3

• 이 암호화에서 사용되는 키는 AWS에서 관리하고 소유한다. 사용자는 건드릴 수 없으며 AWS 서버 측에서 객체를 암호화한다.
• 암호화 보안 유형은 AES-256
• 헤더에 반드시 'x-amz-server-side-encryption':'AES256'을 설정해야 한다.
• 그러면 새로운 버킷과 객체에는 기본적으로 SSE-S3가 활성화된다.

2. SSE-KMS

• AWS MDS 서비스가 가지고 있는 키에 의존하는 대신 KMS 서비스를 이용해 자신의 키는 직접 관리한다.
• KMS 사용 시 키로 사용자를 제어할 수 있다는 장점이 존재한다.
  • 누군가 KMS에서 키를 사용하면 서비스에 로그가 남는다.(=CloudTrail)
• 헤더에 반드시 'x-amz-server-side-encryption':'aws:kms'을 설정해야 한다.
• 그러면 서버 측에서 객체가 암호화 된다.

KMS의 한계

• S3에 파일을 업로드하거나 다운로드 할 때 KMS 키를 활용해야 한다.
• KMS키는 자체 API가 있다. 그래서 복호화 할때는 복호화 API를 사용해야 한다.
• KMS 서비스에 API 호출을 해야하는데 이러한 API 호출은 KMS의 초당 API 호출 할당량에 포함된다.
  • 리전에 따라 초당 5000~30000 요청을 처리할 수 있다.
  • 콘솔에서 서비스를 늘릴 수도 있다.
• 만일 처리량이 아주 많은 S3 버킷이 있다면, KMS 키를 사용하여 모든 것이 암호화 되므로 주의해야 한다!

KMS의 한계점.

3. SSE-C

• 키는 AWS 외부에서 관리되지만 서버 측 암호화에 포함된다. AWS에 키를 보내기 때문이다.
• S3에 키를 보내기에 HTTPS 통신을 사용해야 하며, 모든 HTTP 요청의 헤더에 키를 전달해야 한다.

4. Client-Side Encryption

• 클라이언트 측 암호화는 클라이언트가 데이터를 직접 암호화한다는 방식이다.
• S3에서 데이터를 찾아서 데이터 복호화는 S3 외부 클라이언트에서 발생한다.
• 클라이언트가 키를 비롯한 암호화 주기 전체를 관리해야 한다는 특징이 있다.

Encryption in transit(SSL/TLS)

Amazon S3에는 두 개의 엔드포인트가 존재한다.
하나는 HTTP, 다른 하나는 HTTPS이고 암호화의 가능 여부가 차이이다.

S3를 사용할 때에는 HTTPS가 권장된다.
SSE-C 유형의 방법을 사용하는 경우에도 HTTPS의 사용이 반드시 필요하다.

Force Encrytpion in Transit aws:SecureTransport

• 전송 중에 암호화를 강제하고 싶다면 버킷 정책을 이용하면 된다.
  • 버킷 정책을 추가하고 Statement에 아래와 같이 추가한다.
  • 만일 aws:SecureTransport가 false라면, HTTPS를 사용하면 true가 될 것이다.
  • HTTP 사용자는 모두 차단된다.

Force Encryption Statement

---

Default Encryption vs. Bucket Policies

• 기본적으로 모든 버킷은 기본 암호화인 SSE-S3를 사용하는데 이는 새로운 버킷에 저장된 새로운 객체에 자동으로 적용된다.
• 하지만 SSE-KMS 같은 다른 기본 암호화로 변경할 수 있다. 버킷 정책을 통해 올바른 암호화 헤더가 없는 S3 객체에 적용되는 API 호출을 거부하도록 하여 암호화를 강제로 적용할 수도 있다.

명시해야 할 점은 버킷 정책은 항상 '기본 암호화 설정 이전'에 평가된다!

---

CORS

Cross-Origin Resource Sharing의 약자이다.
CORS 중 Origin, 이 오리진은 프로토콜, 도메인, 포트로 구성되어 있다.

CORS는 기본 오리진에 방문할 때 다른 오리진에 대한 요청을 허용/거부하는 웹 브라우저 기반 보안 메커니즘이다.

• 웹 브라우저가 한 웹 사이트에 방문하고 요청 체계의 일부로 다른 웹 사이트에 요청한다고 가정할 때, 이 요청은 다른 오리진에서 CORS 헤더를 사용한 요청을 허용하지 않는 한 충족되지 않는다. 이를 'Access-Control-Allow-Origin'이라고 한다.

S3에 적용되는 방식

• 클라이언트가 S3 버킷에 교차 오리진 요청을 보낼 경우 올바른 CORS 헤더를 활성화해야 한다.
  • 이를 빠르게 처리하는 방법에는 특정 오리진을 허용하거나, 모든 오리진을 허용해야 하는 방법이 있다.

---

MFA Delete

MFA란?
멀티 팩터 인증을 나타내며 S3에서 중요한 작업을 하기전에 사용자가 디바이스에서 코드를 작성하도록 하는 방법이다.

• MFA 사용 시기
  • 한 객체 버전을 영구적으로 삭제할 때
  • 버전 관리를 일시적으로 중단할 때
• MFA가 필요하지 않은 시기
  • 버전 관리를 활성화할 때
  • 삭제된 버전을 나열할 때
  • 어려운 작업이 아니라서 필요하지 않음!
• MFA Delete를 사용하려면, 버킷에서 버전 관리를 할 수 있어야만 한다.
• 루트 계정은 MFA Delete를 활성화하거나 비활성화 할 수 있다.

MFA Delete는 특정 객체 버전이 영구적으로 삭제되지 않도록 하는 추가 보호 작업이다!

---

S3 Access Logs

감사를 목적으로 S3 버킷의 모든 액세스를 기록하고자 할 수 있다.

다시 말해 모든 계정에서 S3 버킷에 보낸 모든 요청이 승인 유무에 관계없이 다른 S3 버킷에 파일로 기록된다는 의미아다.

 

• 대상 로그 버킷은 동일한 AWS 영역에 있어야만 한다.
  • S3 버킷에 요청을 보내고 모든 요청이 로킹 버킷에 기록되도록 액세스 로그를 활성화하고자 한다고 가정해보자.
  • 이 로그의 형식은 URL에서 찾을 수 있다.
• 주의할 점
  • 로깅 버킷을 모니터링하는 버킷과 동일한 버킷으로 설정해서는 안된다.
    • 무한 로깅 루프가 생기고 버킷의 크기가 기하급수적으로 늘어난다.
    • 많은 비용이 지출됨..

로깅 버킷과 모니터링 버킷을 동일시 할 때 발생하는 문제..

---

사전 로그인된 URL

Pre-Signed URLs는 S3 콘솔, AWS CLI나 SDK를 사용하여 생성할 수 있는 URL이며 만료 기한이 존재한다.

• 콘솔을 사용하는 경우에는 12시간, AWS CLI를 사용하는 경우 최대 168시간을 사용할 수 있다.
• 미리 서명된 URL을 생성하면 해당 URL을 받게 되는 사용자에게 GET이나 PUT 작업에서 생성된 URL의 사용자 권한이 상속된다!
• 이를 통해 프라이빗한 객체이더라도 누구나 url을 통해 객체에 액세스할 수 있다.

---

Access Point

 예를 들어, 많은 데이터가 저장된 S3 버킷이 있다고 가정하자.

재무 데이터, 영업 데이터 등이 있고 데이터가 액세스하고자하는 여러 사용자나 그룹이 존재한다.

우리는 복잡한 S3 정책을 만들고 시간이 지나면서 성장하도록 할 수 있다. 하지만 사용자가 많아지고 데이터가 많아질수록 점점 관리하는데 어려움이 생기게 된다.

이를 해결하려면 어떻게 해야할까?

 

• 우리는 S3 액세스 포인트를 만들 수 있으며, 특정 데이터에 접근할 수 있는 특정 액세스 포인트를 만들 수 있다.
• 이때 특정 데이터에 대한 액세스 포인트 정책을 정의하는데 이 정책은 S3 버킷 정책과 매우 비슷하고 특정 접두사에 대한 액세스를 승인하고 읽고, 쓰는 권한을 관리한다.
• 각 액세스 포인트에는 각 정책이 부여되어 있고, IAM 권한이 있는 경우에 사용자는 특정 액세스 포인트에 접근할 수 있으며 버킷의 특정 부분에만 접근할 수 있다.
• 각 액세스 포인트는 각자의 DNS 이름이 있고 이것은 프라이빗 트래픽의 오리진이나 VPC로 인터넷에 연결되도록 할 수 있다.

Access Points - VPC Origin

• VPC Origin은 프라이빗 액세스로 정의한다.
• VPC Origin에 대한 액세스 권한을 얻으려면 액세스 포인트에 액세스하려 할 때 VPC 액세스 포인트라는 것을 생성해야한다.
  • 이는 VPC에 내장된 것으로 VPC Origin을 통해 액세스 포인트에 프라이빗하게 연결할 수 있게 하는 요소이다.
• VPC 엔드포인트에는 정책이 존재하며, 이 정책은 대상 버킷과 액세스 포인트를 허용해야만 한다.

Access Points - S3 Object Lambda

• 호출 애플리케이션에 의해 객체가 호출되기 전에 Lambda 함수를 이용하여 객체를 변환해야한다.
• 오로지 하나의 S3 버킷만 필요하며, S3 액세스 포인트와 S3 객체 람다 액세스 포인트를 생성한다.