Amazon S3 - Object Encryption
- Server-Side Encryption (SSE)
- Amazon S3 관리형 키를 사용하는 서버 측 암호화 (SSE-S3)
- KMS 키를 사용해서 암호화 키를 관리 (SSE-KMS)
- 고객이 제공하는 키를 사용 (SSE-C)
- Client-Side Encrytion
- 클라이언트 측 암호화 (클라이언트 측에서 모든 것을 암호화한 다음에 S3에 업로드)
Amazon S3 Encryption - SSE-S3
- AWS에서 처리, 관리 및 소유하는 키를 암호화를 진행
- 사용자는 키에 접근 할 수 없다
- Encryption type으로는 AES-256
- header을 “x-amz-server-side-encryption”:”AES256”으로 설정해서 SSE-S3 매커니즘으로 객체를 암호화하도록 S3에게 요청
Amazon S3 Encryption - SSE-KMS
- AWS와 S3 서비스가 소유한 키에 의존하는 대신 KMS (Key Management Service)로 자신의 키를 직접 관리
- KMS를 통해 사용자가 키를 제어할 수 있다 (KMS 내에서 직접 키를 생성)
- CloudTrail(누군가 KMS에서 키를 사용하면 AWS에서 발생하는 모든 일을 기록)을 사용해서 사용량을 감시할 수 있다
- header을 “x-amz-server-side-encryption”:”aws:kms”으로 설정하면 서버에서 객체를 암호화
- S3 버킷에서 해당 파일을 읽으려면 객체 자체에 대한 액세스 뿐만 아니라 객체를 암호화하는 데 사용한 KMS 키에 대한 액세스도 필요해 보안이 한 단계 추가된 상황
SSE-KMS Limitation
- Amazon S3에서 파일을 업로드하고 다운로드 할 때 KMS 키를 사용해야 한다
- KMS 서비스에 API 호출을 수행해야 하는데 각 API 호출은 초당 KMS 할당량에 포함되며 리전에 따라 초당 5,500 - 30.000개의 요청을 처리할 수 있지만 서비스 할당량 콘솔로 한도를 늘릴 수 있다
- 처리량이 매우 높은 S3 버킷이 있고 모든 파일이 KMS 키로 암호화되어있다면 스로틀링 오류 등의 사례가 발생한다
Amazon S3 Encryption - SSE-C
- 키가 AWS 외부에서 관리되지만 AWS로 키를 보내기 때문에 서버 측 암호화이다
- 제공된 키는 S3에 저장되지 않고 사용 후 폐기된다
- S3로 키를 보내기 때문에 HTTPS를 사용해야 한다
Amazon S3 Encryption -Client-Side Encryption
- 클라이언트 라이브러리로 쉽게 구현할 수 있다
- S3로 데이터를 보내기 전에 클라이언트가 직접 암호화해야한다
- 데이터 복호화는 S3 외부의 클라이언트에서 수행
Amazon S3 - Encryption in transit (SSL/TLS)
- 전송 중 암호화는 SSL 또는 TLS라고도 한다
- S3 버킷에는 두 개의 엔드포인트가 있는데 암호화되지 않은 HTTP 엔드포인트와 전송 중 암호화인 HTTPS 엔드포인트이다
Amazon S3 - Default Encryption vs Bucket Policies
- 암호화를 강제할 수 있는 방법은 버킷 정책을 사용하는 것이다
- 정책을 사용해 지정된 암호화 해더가 없는 S3 객체를 버킷에 넣는 API 호출을 거부한다
- S3에서 기본 암호화 옵션을 사용하면 암호화되지 않은 객체의 API 호출을 거부하도록 설정 할 수 있다
- 객체가 암호화디지 않은 채로 업로드되더라도 업로드 후에 S3에 의해 암호화 된다
- 버킷 정책은 항상 기본 암호화 전에 평가되므로 둘 다 설정하면 암호화 안 된 객체를 업로드하면 거부된다
What is CORS (Cross-Origin Resource Sharing)?
- CORS는 웹 브라우저 기반 보안 메커니즘
- 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 허용하거나 거부한다
- Origin = scheme (protocol) + host (도메인) + port
Amazon S3 - CORS
- 클라이언트가 S3 버킷에서 CORS를 요청을 하면 정확한 CORS 헤더를 활성화해야 한다
- 작업을 빠르게 수행하려면 특정 오리진을 허용하거나 모든 오리진을 허용한다
Amazon S3 - MFA Delete
- MFA - Multi-Factor Authentication : 사용자가 장치에서 코드를 생성하도록 강제
- 객체 버전을 영구적으로 삭제할 때 필요하며 영구 삭제에 대한 보호 설정이다
- 버킷에서 Versioning을 중단할 때도 필요하다 (MFA Delete를 사용하려면 Versioning을 활성화 해야한다)
- 루트 계정만이 MFA Delete를 활성화하거나 비활성화할 수 있다
CLI를 이용해 S3조회 & MFA Delete
aws configure --profile {{profile-name}}
aws s3 ls --profile {{profile-name}}
aws s3api put-bucket-version --bucket {{bucket-name}} --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "{{arn붙여넣기}}" --profile {{profile-name}}
aws s3api put-bucket-version --bucket {{bucket-name}} --versioning-configuration Status=Enabled,MFADelete=Disabled --mfa "{{arn붙여넣기}}" --profile {{profile-name}}
S3 Access Logs
- 감사 목적으로 S3 버킷에 대한 모든 액세스를 기록
- 어떤 계정에서든 S3로 보낸 모든 요청은 승인 또는 거부 여부와 상관 없이 다른 S3 버킷에 파일로 기록된다
- 해당 데이터는 Amazon Athena 같은 데이터 분석 도구로 분석할 수 있다
- 주의할 점은 로깅 버킷과 모니터링하는 버킷을 동일하게 설정하면 안된다
- 동일하게 설정될 경우 로깅 루프가 생성되며 무한 반복된다
Amazon S3 - Pre-Signed URLs
- S3 콘솔,CLI, SDK를 사용하여 생성할 수 있는 URL
- S3 콘솔 사용 시 최대 12시간, CLI로 사용 시 168시간 까지 사용
- URL을 받은 사용자는 URL을 생성한 사용자의 GET 또는 PUT에 대한 권한을 상속
S3 Glacier Vault Lock
- WORM 모델 (Write Once Read Many)을 채용하기 위해 Glacier 볼트를 잠구는 것
- 객체를 가져와서 S3 Glacier 볼트에 넣은 다음 수정하거나 삭제할 수 없도록 함
- 규정 준수와 데이터 보존에 유용
S3 Object Lock
- Versioning 활성화가 필수
- WORM 모델을 채택할 수 있다
- 객체 잠금은 전체 S3 버킷 수준의 잠금 정책이 아니라 버킷 내의 모든 객체에 각각 적용할 수 있는 잠금
- Compliance (규정 준수 모드)
- S3 Glacier valut lock과 유사하며 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제 할 수 없다
- 보존 모드 자체도 변경할 수 없다
- Governance
- 객체 버전을 덮어쓰거나 삭제하거나 로그 설정을 변경할 수 없다
- 관리자 같은 일부 사용자는 IAM을 통해 부여받은 특별 권한으로 보존 기간을 변경하거나 객체를 바로 삭제할 수 있다
- Legal Hold
- S3 버킷 내 모든 객체를 무기한으로 보호한다
- s3:PutObjectLegalHold IAM 권한을 가진 사용자는 어떤 객체에든 법적 보존을 설정하거나 제거할 수 있다
S3 - Access Points
- 그룹에 따라 액세스할 액세스 포인트를 정의하는 특정 정책을 액세스 포인트마다 연결할 수 있다
- 최종적으로는 S3 버킷에 액세스
- 각 액세스 포인트마다 고유의 DNS와 정책이 존재
S3 - Lambda
- S3 버킷의 객체를 호출한 애플리케이션이 회수하기 전에 수정하기 위함
- 각 객체를 다른 버전으로 만들기 위해 버킷을 복사하는 대신 S3 객체 Lambda를 사용
