[AWS] Amazon S3 Security

Amazon S3 Security - 암호화 방식

S3에서 데이터를 보호하는 4가지 방법

 

1. SSE-S3(S3 Managed Keys)

• AWS가 키를 완전히 관리하는 가장 간단한 방식
• 객체는 서버 측에서 암호화됨
• AES-256 알고리즘 사용
• 각 개체마다 고유한 키로 암호화되고, 그 키 자체도 정기적으로 교체되는 마스터 키로 암호화됨
• 무료
• 헤더 : x-amz-server-side-encryption: AES256

 

2. SSE-KMS(KMS Keys)

• AWS KMS(Key Management Service)를 통해 처리되고 관리되는 키를 사용해 암호화
• 사용자가 키 제어 가능 + CloudTrail을 사용해 키 감사
• 객체는 서버 측에서 암호화 됨
• 헤더: x-amz-server-side-encryption: aws:kms
• KMS API 호출 비용 발생
• KMS 키 정책으로 누가 키를 사용할 수 있는지 제어 가능
• 키에 대한 세밀한 접근 제어가 필요할 때 사용

 

3. SSE-C(Customer-Provided Keys)

• 고객이 직접 암호화 키를 관리하고 제공
• AWS는 키를 저장하지 않음 -> 사용 후 즉시 삭제
• 반드시 HTTPS 사용
• 모든 요청마다 HTTP 헤더로 암호하 키를 전달
• AWS CLI나 SDK를 통해서만 사용 가능
• 키를 잃어버리면 객체 볼구 불가능

 

4. Client Side Encryption

• S3에 업로드하기 전 클라이언트 측에서 직접 암호화
• AWS는 이미 암호화된 데이터만 받음 -> AWS는 데이터를 볼 수 없음
• Amazon S3 Client-Side Encryption Library 사용
• 가장 강력한 보안 수준

---

Encryption in Transit : 전송 중 암호화

• HTTP : 암호화 X
• HTTPS : SSL/TLS 암호화
• SSE-C는 반드시 HTTPS 사용

---

Default Encryption vs Bucket Policies

버킷 정책은 항상 "기본 암호화" 전에 평가된다.

 

API 요청 -> Bucket Policy 평가 -> Default Encryption 적용

• Bucket Policy가 먼저 평가됨
• Bucket Policy에서 거부되면 Default Encryption까지 갈 수 없음

 

버킷 정책 예시

{
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

-> 헤더가 AES256이 아니면 업로드 거부

 

{
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Condition": {
    "Null": {
      "s3:x-amz-server-side-encryption": "true"
    }
  }
}

-> 암호화 헤더가 아예 없으면 업로드 거부

---

CORS

Cross-Origin Resource Sharing 기본 개념

웹 브라우저는 보안상 Same Origin Policy를 적용한다.

• 기본적으로 다른 Origin으로의 요청을 차단
• JavaScript에서 다른 도메인의 리소스에 접근하려면 허가가 필요

 

Amazon S3 - CORS

상황 예시

> 웹사이트: https://www.myapp.com 

> S3 버킷: https://mybucket.s3.amazonaws.com

> 웹사이트의 JavaScript가 S3의 이미지/파일을 직접 요청

 

-> 브라우저가 다른 Origin(S3)으로의 요청을 차단하므로 S3 버킷에 CORS 설정 추가가 필요!

 

CORS 설정 주요 항목

• AllowedOrigins : 어떤 Origin에서의 요청을 허용할지 지정
• AllowedMethods : 허용할 HTTP 메서드 지정 -> GET, PUT, POST
• AllowedHeaders : 클라이언트가 보낼 수 있는 헤더 지정 -> 보통 "*"로 모든 헤더 허용

---

S3 Access Logs

• S3 버킷에 대한 모든 액세스 요청을 기록
• 누가, 언제, 무엇을, 어떻게 접근했는지 추적 가능
• 로깅 대상 버킷은 동일한 AWS 리전에 있어야 함
• 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하면 안 됨 -> 로깅 루프가 생성되고 무한 반복되어 버킷의 크기가 기하급수적으로 증가..
• 무료
• 로그 분석 도구 : Amazon Athena, Amazon QuickSight 등

---

Pre-Signed URLs

• 미리 서명된 URL
• 임시로 S3 객체에 접근할 수 있는 URL -> S3 콘솔, AWS CLI, SDK로 생성 가능
• IAM 자격 증명 없이도 특정 객체에 접근 가능
• 보안을 유지하면서 제한된 시간 동안 접근 허용
• ex) 로그인한 사용자만 S3 버킷에서 프리미엄 비디오 다운 허용

 

URL 만료 기한

• S3 콘솔 : 1분 ~ 720분(12시간)
• AWS CLI : 1초 ~ 168시간(7일)
• SDK : 1초 ~ 168시간(7일)

---

S3 Glacier Vault Lock & Object Lock

둘다 WORM 모델 사용하나 적용 대상과 방식이 다르다.

 

1. S3 Glacier Vault Lock

• Glacier 볼트 전체에 적용되는 정책
• 한번 잠그면 절대 변경, 삭제 불가(AWS도 불가능)
• 장기 아카이빙 + 규정 준수 목적
• ex) 금융 기록 보관, 의료 기록, 법적 증거 자료 등

 

2. Object Lock

• 개별 객체에 적용
• 버전 관리 필수
• 더 유연한 보호 메커니즘
• 규정 준수 모드와 거버넌스 모드 존재

Compliance(규정 준수 모드)

• 가장 엄격한 보호
• 절대 삭제, 수정 불가(루트 권한도 불가)
• 보존 기간 단축 불가 -> 연장만 가능
• 보존 모드 변경 불가

Governance(거버넌스 모드)

• 유연한 보호
• 특별 권한이 있으면 수정, 삭제 가능
• 보존 기간 변경 가능
• 테스트나 내부 정책용

Retention Period(보관 기간)

• 객체가 보호되는 기간으로 고정된 기간 설정
• 연장은 언제나 가능
• 규정 준수 모드는 단축 불가
• 연장은 둘다 가능

Legal Hold(법적 보관)

• 보관 기간과 무관하게 무기한 보호
• On, Off 스위치 처럼 작동 -> 수동 해제
• 보관 모드와는 독립적

---

S3 Object Lambda

• S3에서 객체를 가져올 때 실시간으로 데이터를 변환하는 기능
• S3 버킷 상위수준에 S3 액세스 포인트를 생성하고 람다 함수와 연결
• ex) 분석이나 비프로덕션 환경에서 개인 식별 정보 삭제

 

* 액세스 포인트

S3 버킷에 대한 여러 진입점(Entry Point)을 만들어 접근 관리를 단순화 하는 기능

 

-> 각 액세스 포인트마다 고유의 DNS 이름과 정책을 가짐

 

 

 

 

 

출처 : https://velog.io/@gagaeun/AWS-Amazon-S3-Security