[AWS] S3 보안

https://jeidiiy.notion.site/S3-4f591d299d5744b3a4d8ad01001d8c60?pvs=4 

S3 보안

💡노션에 최적화된 글입니다. 위 링크를 통해 접근해 주세요.

S3 보안

1. 암호화

Server-Side Encryption (SSE)

Amazon S3-Managed Keys (SSE-S3)

• AWS에 의해 관리되는 키를 사용하여 S3 객체 암호화
• 서버 측에서 객체 암호화
• 암호 알고리즘으로 AES-256 사용
• 요청 헤더에 “x-amz-server-side-encryption”: “AES256” 설정해야 함
• 새 버킷이나 새 객체에 기본적으로 활성화 가능

AWS KMS (SSE-KMS)

• AWS KMS에서 관리하는 키를 사용한 암호화
• KMS 이점
  • AWS User 제어
  • CloudTrail을 사용한 키 사용 감시
• 서버 측에서 객체 암호화
• 요청 헤더에 “x-amz-server-side-encryption”: “aws:kms” 설정해야 함
• 암호화 키 순환 정책에 관한 제어권은 이용자에게 있음

⚠️ SSE-KMS 사용 시에는 제한 사항이 있다. 객체 업로드 시 KMS API 중 GenerateDataKey를 호출한다. 그리고 다운로드 시 KMS API 중 Decrypt를 호출한다. KMS는 리전에 따라 초당 5500, 10000, 30000개의 요청을 처리한다. 이는 콘솔에서 한도를 늘릴 수 있다. 이러한 API 호출은 초당 비용을 유발하므로 주의해야 한다. 또한 처리량이 매우 높은 S3 버킷을 KMS로 암호화한다면 쓰로틀링 오류 등을 발생시킬 수 있으므로 주의하자.

SSE-C

• AWS 외부의 고객이 완전히 관리하는 키를 사용한 암호화
• 서버 측에서 암호화
• S3는 고객이 제공한 키를 저장하지 않음
• HTTPS 필수
• 모든 요청의 HTTP 헤더에 키를 포함하여 전달해야 함

Client-Side Encryption

• Amazon S3 클라이언트 사이드 암호화 라이브러리와 같은 클라이언트 라이브러리를 사용한 암호화
• 클라이언트는 반드시 S3에 업로드하기 전에 데이터를 암호화해야 함
• 클라이언트는 반드시 S3에서 데이터를 받았을 때 복호화해야 함
• 즉, 클라이언트가 암호화 사이클을 완전 관리

전송 중 암호화 (SSL/TLS)

• S3는 HTTP, HTTPS 엔드포인트 지원
• HTTPS 권장
• SSE-C 사용 시 필수
• 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트 지원
• HTTPS만을 지원하려면 S3 정책 설정

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

기본 암호화 vs 버킷 정책

• SSE-S3 암호화는 S3 버킷에 저장되는 새로운 객체에 자동으로 적용
• 암호화를 강제하기 위해 버킷 정책 사용 가능
  • 암호화 헤더(SSE-KMS, SSE-C) 없이 S3 객체를 넣는 API 호출 거부 가능
  • 버킷 정책 대신 암호화되지 않은 객체의 API 호출 거부 가능

💡 버킷 정책은 기본 암호화 이전에 평가된다.

2. CORS

CORS란?

• Cross-Origin Resource Sharing
• Origin = scheme (protocol) + host (domain) + port
• 웹 브라우저 기반 보안 메커니즘
• 메인 오리진을 방문하는 동안 다른 오리진에 요청을 보내는 것에 대한 보안 정책

같은 오리진

• http://example.com/app1
• http://example.com/app2

다른 오리진

• http://example.com
• http://other.com

💡 메인 오리진에서 다른 오리진으로 요청했을 시 다른 오리진에서 CORS 헤더가 설정되어 있을 경우 정상적으로 동작한다. 귀찮은 작업같지만 외부 서비스에 무단으로 API 요청을 보내 데이터를 받아오는 문제 등을 방지한다.

S3 CORS

• 클라이언트에서 S3 버킷에서 cross-origin 요청을 해야 한다면 CORS 헤더 설정을 해야 함
• 시험 자주 출제
• Amazon S3 > Buckets > my-bucket > Permission > Edit cross-origin resource sharing 설정

[
    {
        "AllowedHeaders": [ "Authorization" ],
        "AllowedMethods": [ "GET" ],
        "AllowedOrigin": [ "http://mydomain.com" ],
        "ExposeHeaders": [],
        "MaxAgeSeconds": 3000
    }
]

3. MFA Delete

• MFA를 활용하여 S3에서 중요한 작업 수행 전 코드 삽입을 통한 보안 강화
• MFA Delete를 사용하려면 버킷의 버저닝이 반드시 활성화되어있어야 함

MFA가 필요한 작업

• 객체 영구 삭제
• 버킷 버저닝 중단

MFA가 필요 없는 작업

• 버저닝 활성화
• 삭제된 버전 리스팅

💡 오직 버킷 주인(루트 계정)만 MFA Delete 기능을 활성화/비활성화할 수 있다.

4. S3 Access Logs

• 감사 목적으로 S3 버킷에 대한 모든 접근을 로깅할 수 있음
• S3에 대한 요청, 계정 접근, 인가 승인 및 거부 등을 로깅
• 로그 데이터는 데이터 분석 툴을 통해 분석 가능
• 로깅 버킷은 반드시 같은 리전에 있어야 함
• 로그 포맷
• Amazon S3 server access log format - Amazon Simple Storage Service

Amazon S3 server access log format - Amazon Simple Storage Service

⚠️ 로깅 버킷과 애플리케이션 버킷을 함께 사용하면 안 된다. 예를 들어 버킷에 데이터를 추가하면 로그를 남기기 위해 앱 버킷에 로그를 추가하고 데이터가 추가되어 다시 로그를 추가하는 무한 루프가 발생하기 때문이다. 이런 경우 버킷 크기가 엄청나게 커지고 비용 또한 많이 부가될 것이다.

5. Pre-Signed URLs

• S3 콘솔, AWS CLI 또는 SDK를 활용하여 Pre-Signed URL 생성 가능
• 버킷을 private으로 유지하면서 데이터 제공 가능
  • 보안 향상

URL 만료

• S3 콘솔 - 720분 (12시간)
• AWS CLI - 기본 3600초 ~ 최대 604800초 (168시간)
• GET 또는 PUT 작업에 대한 권한을 생성된 URL을 통해 유저에게 상속

사용 사례

• S3 버킷에 있는 프리미엄 동영상 다운르도 제공
• 사용자 목록이 계속 변하는 경우 URL을 동적으로 생성한 파일 다운로드
• 일시적으로 사용자가 S3 버킷의 특정 위치에 파일을 업로드하도록 허용

6. S3 잠금 정책

Glacier Vault Lock

• WORM (Write Once Read Many)모델을 적용시킴

순서

1. Glacier 위에 Vault Lock 정책 생성
2. 향후 편집을 위하 정책 잠금

💡 볼트 잠금 정책 설정 후 잠근 뒤에는 누구도 변경/삭제하지 못한다. 따라서 규정 준수 및 데이터 보존에 아주 유용하다. 관리자나 AWS를 사용해도 삭제할 수 없다.

Object Lock - (버저닝 활성화 필수)

• WORM 모델 적용
• S3 버킷 전체 수준이 아니라 각각의 객체 수준에서 적용 가능한 잠금 방식
• 특정 객체 버전을 특정 시간 동안 삭제 차단 가능

Retention mode - Compliance

• S3 Glacier Vault Lock과 매우 유사
• 사용자를 포함한 누구도 객체 버전을 덮어쓰거나 삭제 불가
• 누구도 객체 변경 불가
• Retention mode 및 Retention Period 변경 불가
• 규정을 엄격히 준수해야 할 때 사용

Retention mode - Governance

• 대부분의 사용자에 대해 객체 버전 덮어쓰기 및 삭제, 로그 설정 변경 불가
• 관리자와 같은 일부 사용자는 IAM을 통해 부여받은 특별 권한으로 Retention Period 변경 및 객체 삭제 가능

Retention Period

• Retention mode에 대한 기간 설정
• 원하는 만큼 기간 연장 가능

Legal Hold

• 설정 시 S3 버킷 내 모든 객체를 무기한으로 보호
• Retention Period와 무관하기 때문에 아주 중요한 객체에 설정
  • 재판에서 사용될 수 있는 중요한 객체
• 설정 시 Retention mode나 Retention Period에 상관없이 객체 영구 보호

💡 `s3:PutObjectLegalHold` IAM 권한을 가진 사용자는 어떤 객체에든 Legal Hold를 설정하거나 제거할 수 있다. 이 권한을 사용하여 법적 조사가 시작되면 Legal Hold를 적용하고 끝나면 해제할 수 있다.

7. S3 Access Point

• S3 버킷에 대한 보안 정책을 간단하게 할 수 있는 방법
• 규모가 커질수록 복잡해지는 S3 정책을 대신해 사용 가능
• 하나의 AP에 대해 하나의 정책만을 가지므로 관리 용이
• 각 AP는 다음을 가짐
  • DNS (Internet Origin or VPC Origin)
  • Access Point 정책 (버킷 정책과 비슷한)

VPC Origin

• VPC 내에서의 AP 접근만 허용 가능
• AP(게이트웨이 또는 인터페이스 엔드포인트)에 접근을 위한 VPC 엔드포인트 생성 필수
• VPC Endpoint 정책은 반드시 타겟 버킷과 AP의 접근을 허용해야 함

8. S3 Object Lambda

• S3 버킷의 객체를 호출한 애플리케이션에 응답하기 전에 수정이 필요한 경우 사용
• S3 버킷 필요
  • 그 상위 수준에 S3 AP를 생성하여 S3 Object Lambda와 연결
  • S3 Object Lambda에도 AP를 생성하여 S3 Object Lambda에 대한 보안 정책 설정 가능

사용 사례

• 분석이나 비프로덕션 환경을 위해 개인 식별 정보와 같은 PII 데이터 삭제
• XML에서 JSON으로의 데이터 변환 또는 원하는 변환 실행
• 상황에 따른 이미지 변환 또는 워터마킹
  • 워터마크는 객체를 요청한 사용자를 적용