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)
- 고객이 제공하는 키를 사용하는 암호화
- Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
- 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으로 변환하는 등 데이터 형식을 변환
- 호출자별로 이미지를 동적으로 크기 조정하고 워터마킹. (호출한 사용자와 같은 세부 정보를 사용.)
안녕하세요