AWS S3 보안

객체 암호화

4가지 방법이 있다

 

SSE(서버사이드 암호화)

• Amazon S3 관리형 키를 사용 → SSE-S3
• KMS 키를 사용해서 암호화 키를 관리하는 → SSE-KMS
• 고객이 제공하는 키 → SSE-C

 

클라이언트 암호화

• 클라이언트에서 암호화해서 업로드

어느 것이 어떤 상황에 해당하는지 이해해야한다

 

S3 SSE-S3

• AWS에서 처리, 관리 및 소유하는 키로 암호화를 진행
• 사용자는 접근 불가
• AWS에 의해 서버측에서 암호화 AES-256 방식
• 헤더를 "x-amz-server-side-encryption": "AES256"로 설정해서 SSE-S3 매커니즘으로 객체를 암호화하도록 S3에 요청해야한다

 

SSE-KMS

• AWS에서 소유하는 키에 의존하는 대신 KMS(Key Management Service)로 자신의 키를 직접 관리하는 방식
• 사용자가 키를 제어 가능한다는 장점과 CloudTrail을 통해 사용량 감사 가능
  • KMS 키를 AWS에서 사용하면 여기서 발생하는 모든 일을 기록하는 역할을 담당하는 서비스가 CloudTrail
• • "x-amz-server-side-encryption": "aws:kms"
• 객체 자체에 대한 엑세스 뿐만 아니라 암호화하는데 사용한 AWS KMS 키에도 엑세스를 해야함
  • 보안이 한단계 추가

 

 

SSE-KMS의 제한사항

• 업로드, 다운로드할 때 KMS키를 사용해야함
• 단순히 암호화 복호화 할때마다 API 호출이 필요함, KMS API는 초당 KMS 할당량에 포함된다
  • 리전에따라 5,500, ~ 30,000개를 처리할 수 있고 콘솔을 통해 늘릴 수 있다
• 처리량이 매우 높은 S3 버킷이 KMS로 암호화되었다면 쓰로틀링이 발생할 수 있다

 

SSE-C

• 키가 AWS 외부에서 관리되지만 AWS로 키를 보내기 때문에 서버 측 암호화
• 암호화 키는 AWS S3에 저장되지 않고 사용 후 폐기함
• HTTPS가 반드시 사용되어야하고 업로드, 다운로드시 HTTP 헤더에 키를 포함하여 전달해야함

 

클라이언트 측 암호화

• 클라이언트 암호화로 간단하게 구현가능(Amazon S3 Client-Side Encryption Library)
• 데이터를 S3로 보내기전에 클라이언트가 직접 암호화해야함
• 복호화는 S3 외부의 클라이언트 측에서 실행
• 클라이언트가 전적으로 키와 암호화 주기를 관리해야한다

 

AWS 전송 중 암호화 (SSL/TLS)

• S3 버킷에는 두 개의 엔드포인트가 있다
  • HTTP, HTTPS
• S3를 사용하는 경우 HTTPS가 권장됨
• SSE-C의 경우 반드시 HTTPS가 반드시 필요함

 

실습 참고

암호화는 객체의 특정 버전 ID에 적용된다

클라이언트 사이드 암호화는 S3 콘솔에서 실제 암호화되었는지 확인할 수 없다

 

기본 암호화 vs 버킷 정책간 차이점

기본 암호화 → 내장 암호화 방식, 버킷 안에서만 암호화가 유효

버킷 정책 → 버킷에 대해 액세스 및 권한을 제어하는 데 사용

• 암호화를 강제할 수 있도록 하는 것이 버킷 정책
  • 정책을 설정한다면 지정된 암호화 헤더가 없는 S3 객체를 버킷에 넣는 API 호출을 거부한다
  • Condition 항목을 보면 된다
  • 오른쪽은 암호화 되지않은 객체만 강제시킨다
• 헤더가 AES-256과 같지 않으면 API 호출을 거부한다
• 버킷 정책을 사용하는 대신 암호화되지 않은 객체의 API 호출을 거부하도록 설정도 가능
  • 기본 암호화 옵션을 사용하면 객체가 암호화 되지 않은채로 업로드되도 S3에 의해 함호화됨
• 버킷 정책은 기본 암호화전에 평가된다
  • 따라서 기본 암호화, 버킷 정책 두가지 다 설정하고 암호화되지 않은 객체를 업로드하면 거부된다 → 기본 암호화 단계에 도달할 수 없기 때문임

 

S3 CORS Cross-Origin Resourse Sharing (CORS)

• Origin = scheme (protocol) + host (domain) + port
  • https://www.example.com:443
    • protocol ⇒ HTTP , Domain ⇒ ww.exmaple.com
• 웹브라우저 기반 보안 매커니즘
• 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 허용하거나 거부하는 정책 중 하나
  • Same origin: http://example.com/app1 & http://example.com/app2
  • Different origins: http://www.example.com & http://other.example.com
  • 프로토콜, 도메인, 포트가 동일할 때 오리진이 같다고 말한다
• 요청 프로토콜의 일부로 다른 웹사이트에 요청을 보내야 할 때 다른 오리진이 CORS 헤더를 사용해서 요청을 허용하지 않는 한 해당 요청은 이행되지 않는다
  • 이것을 Access-Control-Allow-Origin Header라고 한다
  • Preflight에서 CORS 헤더 확인 가능

 

 

Amazon S3에서 CORS - 시험에 자주 나오는 유형

• 클라이언트가 S3 버킷에서 cross origin 요청을 하면 정확한 CORS 헤더를 활성화해야 함
• 작업을 빠르게 수행 하려면 특정 오리진을 허용하거나 * (모든 오리진)을 허용

 

첫 HTML을 반환한 웹사이트가 Origin이 되고 이미지를 주는 버킷이 Host가 된다

 

그러니까 다른 오리진에 대한 요청을 받는 쪽이 Host이다 헷갈리는거 주의

Host가 되는 S3 버킷에도 CORS 헤더를 잘 설정해놔야 다른 오리진에서 S3 버킷에 있는 이미지, 파일을 요청할 수 있게 해준다

 

CORS 실습

S3 버킷 객체를 get하는 요청을 퍼블릭으로 만듬

 

S3 MFA Delete - 추가 보호 기능

• MFA란 멀티팩터 인증으로 사용자가 장치에서 코드를 생성하도록 강제
• MFA를 통해 S3에서 중요한 작업을 수행하기 전 S3에 코드를 삽입하도록 만들 수 있다
• MFA는 언제 필요할까
  • 객체 버전을 영구적으로 삭제할 때 → 영구 삭제에 대한 보호 설정
  • 버킷에서 버저닝을 중단할 때
  • 파괴적인 기능을 수행할 때 MFA 보호가 필요하다
• 버저닝 활성화, 삭제된 버전 나열은 파괴적인 작업이라고 보기 어려우므로 확인 절차가 굳이 필요하진 않다.
• 버킷 소유자, 루트 계정만이 MFA Delete를 활성/비활성화 할 수 있다

 

S3 Access Logs

• 감사 목적으로 버킷에 대한 모든 엑세스를 기록할 수 잇다
• 어떤 계정에서든 S3로 보내는 요청을 승인 또는 거부 여부와 상관없이 다른 S3버킷에 파일로 기록된다
• 데이터 분석 도구로 분석도 가능한데 대상 로깅 버킷은 서로 같은 리전에 있어야 한다
  • 모든 요청이 버킷에 기록하도록 설정하면 된다

 

• 로그형식 확인 가능 https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html

 

엑세스로그 주의사항

• 로깅 버킷을 모니터링 되는 버킷과 동일하게 설정하면 안된다.
  • 로깅 루프가 설정되어 로깅 로그가 무한루프 걸린다
  • 요금도 많이 나오니 주의

 

 

S3 - 사전 서명된 URL (Pre-Signed URLs)

• 공용 이미지를 만드는 방법
• S3 콘솔,CLI, SDK를 사용하여 생성할 수 있는 URL
  • 만료기간이 있다 콘솔의 경우 최대 12시간
  • CLI의 경우 최대 168시간
• 미리 서명된 URL을 생성할 때 URL을 받는 사용자는 URL을 생성하는 사용자의 GET 또는 PUT에 대한 권한을 상속한다
• 프라이빗 버킷을 공개설정하지 않고 URL을 생성하여 해당 파일에 엑세스할 수 있는 URL을 제공한다 (노션 API를 사용하여 확인해봄)
• 특정 파일에 임시로 엑세스할 떄 많이 사용
• 예시
  • 로그인한 사용자만 버킷에서 프리미엄 비디오를 다운받을 수 있도록 함
  • 사용자 목록이 계속 변하는 경우 URL을 동적으로 생성해서 파일을 다운로드하면 접근에 대한 통제 가능
  • 일시적으로 사요자가 S3 버킷의 특정한 위치에 파일을 업로드하도록 허용할 수 있다

 

S3 Glacier Vault Lock(볼트 잠금)

• WORM 모델을 채용하기 위해 Glacier 볼트를 잠근다
  • WORM ( Write Once Read Many ) → 한번 쓰고 여러 번 읽는다
• 객체를 가져와서 S3 Glacier 볼트에 넣고 수정, 삭제 할 수 없도록 잠금
• 볼트 잠금 정책을 생성하고 편집을 위해 정책을 잠금 → 일단 설정하고 잠근 뒤에는 누구도 수정하고 삭제할 수 없다
  • 관리자나 AWS 서비스를 사용하더라도 삭제 불가
• 규정 준수나 데이터 보존같은 법률적인 사항에 매우 유용

 

S3 Object Lock - 두 가지 보존 모드의 차이점 중요

• 객체 잠금을 활성화 하려면 버저닝 활성화 필요
• WORM 모델 채택 가능 → 전체 버킷 수준이 아닌 모든 객체에 각각 적용할 수 있는 잠금
  • 단일객체 잠금 가능
• 특정 객체 버전이 특정 시간 동안 삭제되는 것을 차단 가능
• Retention mode (보존 모드) → Compliance Mode
  • 볼트 잠금과 비슷한데 그 누구도 덮어쓰거나 삭제할 수 없다.
  • 보존 모드, 보존 기간조차 줄일 수 없다
  • 엄격히 적용할 때 사용
• Retention mode (보존 모드) → Governance
  • 대부분의 사용자는 객체를 덮어쓰거나 삭제 하거나 로그 설정을 변경할 수 없다
  • 관리자 같은 일부 사용자는 IAM을 통한 특별 권한으로 보존 기간 변경이나 삭제 가능
  • 컴플라이언스보다 유연성이 있다 → 일부 권한을 갖고 삭제할 수 있음
• 두가지 모드 모두 보존 기간 설정 필요하며 고정된 기간동안 객체를 보호할 수 있다
• 원하는만큼 기간을 연장할 수 있다

Legal Hold (법적 보존)

• 모든 객체를 무기한으로 보호 → 아주 중요한 객체에 보존을 설정 (재판에 사용될 수 있는 것들)
• 모드나 기간에 상관없이 영구 보존
• s3:PutObjectLegalHold라는 IAM 권한을 가진 사용자는 어떤 객체에든 법적 보존을 설정하거나 제거할 수 있다
• 유연한 모드로 객체를 보호하고 싶을 때 권한을 사용하고 법적 조사가 끝난 경우 법적 보존을 제거

 

S3 Access Points

• 그룹과 사용자 별로 버킷 정책 설정해야하는데 많으면 많을수록 더욱 복잡해진다
• 따라서 버킷 정책 대신 Access Points를 사용
  • 팀별로 Access Points를 설정해서 특정 팀이 엑세스 포인트를 통해 버킷에 엑세스 했을 때만 R/W를 할 수 있다
  • 특정 접두사에 대해 읽기/쓰기를 설정 가능
• 특정 정책을 엑세스 포인트마다 연결해서 최종적으로 S3 버킷에 엑세스 하는 방식을 관리하는 방식이다
• 엑세스 포인트마다 고유의 DNS와 정책이 있다
  • 특정 IAM/그룹으로 제한 가능
• 엑세스 포인트마다 하나의 정책을 가짐

 

S3 Object Lambda

• 버킷의 객체를 호출한 애플리케이션이 회수하기 전에 수정한다
• 쉽게 말해 객체에 대한 추가적인 처리를 수행하는 것
  • 객체가 S3로 업로드되거나 읽힐 때마다 실행되어 객체에 대한 추가적인 가공 또는 변형 작업
• S3 엑세스 포인트가 필요하다
• 사용 사례
  • 분석 애플리케이션의 경우 새 S3 버킷을 사용하는 것보단 람다 함수를 실행하는 Lambda 엑세스 포인트에 접근해 데이터를 가져와 코드를 실행시켜 가공된 데이터를 얻는다
  • 마케팅 앱의 경우 마찬가지로 다른 버킷을 만드는 것보단 Lambda를 통해 DB 데이터를 가져오는 작업을 수행해 가져온다
• S3 Object Lambda Access Point가 만들어진다는 것을 알아둬야한다
• Lambda를 서포팅하는 버킷의 S3 Access Point는 하나밖에 없다
• Use Cases
  • 분석이나 비프로덕션 환경을 위해 개인 식별 정보와 같은 Pll 데이터를 삭제해야하는 경우
  • XML에서 JSON으로 데이터 변환작업을 수행하는 경우
  • 상황에 맞춰 이미지 크기를 바꾸거나 워터마크를 남겨야하는 경우, 이때 워터마크는 요청한 사용자를 적용해야하는 동적인 요청인 경우