참고 자료

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/

🔒 Encryption

Amazon S3에서는 4가지 방법으로 S3 버킷의 객체를 암호화할 수 있다.

• Server-Side Encryption (SSE)
  • Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
    • Amazon S3 관리형 키를 사용하는 서버 측 암호화
  • Server-Side Encryption with KMS Keys stored in AWS KMS (SSE-KMS)
    • AWS KMS 키를 사용하는 서버 측 암호화
  • Server-Side Encryption with Customer-Provided Keys (SSE-C)
    • 고객이 제공하는 키를 사용하는 암호화
• Client-Side Encryption

SSE-S3

• AWS에서 처리, 관리, 및 소유하는 키를 사용하여 암호화
• 객체는 서버 측에서 암호화됨
• AES-256 보안 유형으로 암호화
• "x-amz-server-side-encryption": "AES256" 로 header 설정해야 함
• 새로운 버킷 및 새로운 객체에 대해서는 기본적으로 활성화되어 있음

SSE-KMS

• AWS KMS(Key Management Service)를 통해 처리되고 관리되는 키를 사용하여 암호화
• 장점: 사용자가 키를 제어할 수 있음 + CloudTrail을 사용하여 키 감사
• 객체는 서버 측에서 암호화
• "x-amz-server-side-encryption": "aws:kms"

SSE-KMS Limitation

• KMS 제한 사항에 영향을 받을 수 있다.
• 업로드할 때 GenerateDataKey KMS API를 호출
• 다운로드할 때 Decrypt KMS API 호출
• 따라서 KMS 서비스에 API 호출을 수행해야 하는데 각 API 호출은 초당 KMS 초당 할당량(지역에 따라 5,500, 10,000, 30,000 req/s)에 포함됨
• 서비스 할당량 콘솔을 사용하여 할당량 증가를 요청할 수 있음

즉, 처리량이 매우 높은 S3 버킷이 있고 모든 파일이 KMS 키로 암호화되어 있다면 스로틀링 오류 등의 사례가 발생할 수 있음

SSE-C

• 키는 AWS 외부에서 관리되지만 AWS로 키를 보내기 때문에 서버 측 암호화
• Amazon S3는 제공된 암호화 키를 저장하지 않음
• HTTPS를 사용해야 함
• HTTP 요청마다 암호화 키를 HTTP 헤더에 제공해야 함

Client-Side Encryption

• Amazon S3 Client-Side Encryption Library와 같은 클라이언트 라이브러리 사용
• 클라이언트는 데이터를 Amazon S3로 전송하기 전에 직접 암호화해야 함
• 클라이언트는 Amazon S3에서 검색할 때 직접 데이터를 복호화해야 함
• 고객은 키와 암호화 주기를 전적으로 관리함

Encryption in transit (SSL/TLS)

• 전송 중 암호화는 SSL 또는 TLS라고 함
• Amazon S3는 두 개의 엔드포인트가 있음
  • HTTP 엔드포인트: 암호화되지 않음
  • HTTPS 엔드포인트: 전송 중 암호화
• HTTPS가 권장됨
• SSE-C의 경우 HTTPS 프로토콜을 꼭 사용해야 함
• 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용함

Default Encryption vs. Bucket Policies

• 버킷 정책을 사용하여 "강제 암호화"를 적용하고 암호화 헤더가 없는 S3 객체를 버킷에 넣는 API 호출을 거부할 수 있다.
  
• 왼쪽 정책은 SSE-S3 암호화를 강제로 적용한다. 헤더가 AES256이 아니면 API 호출을 거부하도록 구성되어 있다.
• 오른쪽 정책은 암호화되지 않은 객체만 전부 강제로 적용한다.

• 다른 방법은 "기본 암호화" 옵션을 사용하는 것이다.
• 참고: 버킷 정책은 항상 "기본 암호화" 전에 평가된다. 따라서 둘 다 설정하고 암호화가 되지 않은 객체를 업로드하면 거부된다. (기본 암호화 단계에 도달할 수 없기 때문)

🔐 CORS

• Cross-Origin Resourse Sharing (CORS)
• Origin = scheme (protocol) + host (domain) + port
  • ex. https://www.example.com (HTTPS의 기본 포트인 443이 사용되는 www.example.com이라는 도메인의 출처(origin))
• 웹 브라우저에서 메인 오리진(main origin)을 방문하면서 다른 오리진으로의 요청을 허용하기 위한 기능
• Same origin: http://example.com/app1 & http://example.com/app2
  • 프로토콜, 호스트, 포트가 동일할 때 오리진이 같다고 말함
• Differnet origins: http://www.example.com & http://other.example.com
• 요청 프로토콜의 일부로 다른 웹사이트에 요청을 보내야할 때 다른 오리진이 CORS Headers를 사용해서 요청을 허용하지 않는 한 해당 요청은 이행되지 않음 (ex. Access-Control-Allow-Origin)

Amazon S3 - CORS

• 만약 클라이언트가 S3 버킷에서 교차 출처 요청 (cross-origin request)을 보내는 경우, 정확한 CORS 헤더를 활성화해야 한다. - 시험에 자주 나옴!!
• CORS 헤더를 설정함으로써 특정 출처를 허용하거나 * (모든 출처)를 허용할 수 있음
  

CORS는 웹 브라우저 보안 매커니즘으로 다른 출처에서 한 S3 버킷에 들어있는 검색된 이미지, 자산, 파일을 요청할 수 있게 해줌!

🔑 MFA Delete

• MFA (Multi-Factor Authentication): 사용자가 중요한 S3 작업을 수행하기 전에 장치(일반적으로 휴대폰이나 하드웨어)에서 코드를 생성하도록 요구하는 기능
• MFA가 필요한 작업:
  • 객체 버전을 영구적으로 삭제
  • 버킷에서 버전 관리를 중단할 때
• MFA가 필요하지 않은 작업:
  • 버전 관리 활성화
  • 삭제된 버전 목록 나열
• MFA Delete를 사용하려면 버킷에서 버전 관리를 활성화해야 함
• MFA Delete 기능을 활성화/비활성화할 수 있는 권한은 버킷 소유자 (루트 계정)에게만 있음.

MFA Delete는 추가 보호 기능이며 특정 객체 버전의 영구 삭제를 방지하는 역할을 한다.

📄 S3 Access Logs

• 감사 목적으로 S3 버킷의 모든 액세스를 로깅할 수 있다.

• 승인 또는 거부 여부와 상관없이 모든 계정에서 S3에 대한 요청이 로그로 남는다.

• 이 데이터는 데이터 분석 도구로 분석할 수 있다.

• 로깅 대상 버킷은 동일한 AWS 리전에 있어야 한다.

• Amazon S3 서버 액세스 로그 형식: https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html

S3 Access Logs:Warning

• 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하지 말 것.
• 동일하게 설정하면 로깅 루프가 생성되고 로그를 반복적으로 기록하고 무한 반복되어 버킷의 크기가 기하급수적으로 증가함. 요금도 많이 나옴. 집에서는 절대 시도하지 말 것!!

✍️ Pre-Signed URLs

• S3 콘솔, AWS CLI 또는 SDK를 사용하여 생성할 수 있는 URL
• URL 만료 기한
  • S3 콘솔: 1분부터 720분(12시간)까지
  • AWS CLI: --expires-in 매개변수로 만료 시간을 지정할 수 있으며, 초 단위로 설정됨 (기본값은 3600초, 최대 604800초 - 168시간)
• 미리 서명된 URL을 받은 사용자는 GET / PUT에 대한 권한을 URL을 생성한 사용자로부터 상속받음.

• 예시:
  • 로그인한 사용자만 S3 버킷에서 프리미엄 비디오를 다운로드할 수 있도록 허용
  • URL을 동적으로 생성하여 계속 변경되는 사용자 목록이 파일을 다운로드할 수 있도록 허용
  • 일시적으로 사용자가 S3 버킷의 특정 위치에 파일을 업로드할 수 있도록 허용

🧊 S3 Glacier Vault Lock

• WORM (Write Once Read Many) 모델
  • 볼트 잠금 정책 생성한 다음 향후 편집을 위해 정책을 잠금 (더 이상 변경하거나 삭제할 수 없음)
  • 규정 준수 및 데이터 보존에 유용

S3 Object Lock (versioning must be enabled)

• WORM (Write Once Read Many) 모델
• 지정된 기간 동안 특정 객체 버전 삭제되는 것을 차단함
• 객체 잠금은 전체 S3 버킷 수준의 잠금 정책이 아니라 버킷 내의 모든 객체에 각각 적용할 수 있는 잠금이다. 단일 객체를 잠금할 수 있다.
• Retention mode - Compliance (보관 모드 - 규정 준수):
  • 루트 사용자를 포함한 어떤 사용자도 객체 버전을 덮어쓰거나 삭제할 수 없음
  • 객체 보존 모드 자체도 변경할 수 없으며 보존 기간을 줄일 수 없음
• Retention mode - Governance (보관 모드 - 거버넌스):
  • 대부분의 사용자는 객체 버전을 덮어쓰거나 삭제하거나 잠금 설정을 변경할 수 없음
  • 일부 사용자는 보존 기간을 변경하거나 객체를 삭제할 수 있는 특별한 권한을 가지고 있음
• Retention Period 보관 기간: 고정된 기간 동안 객체 보호, 필요에 따라 연장 가능
• Legal Hold 법적 보관
  • 객체를 보관 모드나 보관 기간과는 상관없이 무기한으로 보호
  • s3:PutObjectLegalHold IAM 권한을 가진 사용자는 어떤 객체에든 법적 보관을 설정하거나 제거할 수 있음

👆 S3 Access Points

• 각 액세스 포인트마다 고유의 DNS 이름과 정책을 가지고 있다. 이를 통해 사용자나 그룹의 액세스를 제한할 수 있다.
  • 특정한 IAM 사용자 / 그룹
  • 액세스 포인트마다 하나의 정책만을 가지기 때문에 복잡하고 고유한 버킷 정책보다 훨씬 다루기 쉬움

🧐 S3 Object Lambda

• AWS Lambda 함수를 사용하여 호출한 애플리케이션이 객체를 회수하기 전에 객체를 수정한다.
• 한 개의 S3 버킷만 필요하며, S3 버킷 상위 수준에 S3 액세스 포인트를 생성하고 Lambda 함수과 연결한다.
• 사용 사례:
  • 분석이나 비프로덕션 환경에서 개인 식별 정보 삭제
  • XML을 JSON으로 변환하는 등 데이터 형식을 변환
  • 호출자별로 이미지를 동적으로 크기 조정하고 워터마킹. (호출한 사용자와 같은 세부 정보를 사용.)