보안
Last updated
Last updated
어떤 설정이든 버킷을 생성할 때 설정해둔 블록 공개 액세스에 관한 버킷 설정이 활성화되어 있다면 S3 버킷 정책을 설정하여 공개로 만들더라도 버킷에 접근하지 못한다.
사용자에게는 IAM 정책을 통해 어떤 API 호출이 특정 IAM 사용자를 위해 허용되는지 지정할 수 있다.
IAM 권한에서 허용되거나 리소스 정책에서 허용되고, 전체적으로 거부 규칙이 작성되어 있지 않을 때 사용자는 S3 객체에 접근할 수 있다.
올바른 IAM 권한을 가진 EC2 인스턴스 역할을 생성하여 EC2 인스턴스가 Amazon S3 버킷에 접근 가능하도록 할 수 있다.
특정 IAM 사용자에게 교차 계정 액세스를 허용하기 위해 추가 버킷 정책을 생성할 수 있다.
Amazon S3 버킷의 보안을 관리하는 가장 일반적인 JSON 기반의 정책이다.
S3 버킷 정책을 통해 특정 사용자가 들어올 수 있게 하거나 다른 계정의 사용자를 허용할 수 있다.
버킷 정책이 S3 버킷에 첨부되면 그 안에 있는 모든 객체에 액세스할 수 있다.
S3 콘솔에서 직접 할당할 수 있는 전체 버킷 규칙이다.
Resource: 이 정책이 적용되는 버킷과 객체를 정책에 알려준다.
Effect: 허용/거부 여부를 지정한다.
Action: 허용/거부할 API 집합을 지정할 수 있다.
Principal: 정책을 적용할 사용자를 지정할 수 있다.
ACL이라고 하는 객체 액세스 제어 목록이 존재한다. 버킷 정책보다 세밀한 보안이며 비활성화할 수 있다.
버킷 ACL이 있는데, 거의 쓰이지 않으며 비활성화할 수 있다.
Amazon S3 보안을 관리하기 위해 암호 키를 사용하여 객체를 암호화하는 방식이다.
서버 암호화는 AWS S3에서 저장 직전 암호화하는 방식이다.
SSE-S3
Amazon S3에서 관리하는 키를 이용해 암호화한다. 이 때 사용자는 키에 접근할 수 없다.
암호화의 보안 유형은 AES-256이다.
기본적으로 새로운 버킷과 객체에 대해 활성화되어 있다.
"x-amz-server-side-encryption":"AES256" 라는 헤더를 추가해주어야 이 방식이 사용된다.
SSE KMS
KMS 키를 이용해서 암호화한다.
KMS 서비스를 이용해 직접 사용자가 키를 관리할 수 있다. 누군가가 KMS에서 키를 사용할 때마다 CloudTrail에 로깅할 수 있다.
"x-amz-server-side-encryption":"aws:kms" 헤더를 추가해주어야 이 방식이 사용된다.
S3 버킷에서 객체 조회 시 KMS의 복호화 API를 호출하게 되므로, KMS 권한이 필요하다.
KMS 서비스에 API 호출을 하면 모두 KMS의 초당 API 호출 쿼터에 합산된다. 서비스 쿼터 콘솔을 이용해서 쿼터를 늘릴 수 있다. 리전에 따라 초당 5,000, 10000, 30000 건의 요청을 처리할 수 있다.
S3 버킷의 처리량이 매우 많고 모든 객체가 KMS 키로 암호화되어 있다면 스로틀링될 수 있다.
SSE-C
고객이 제공한 키를 사용해 암호화한다.
키는 AWS 외부에서 관리되지만, S3에 요청을 보낼 때 HTTP 헤더에 키를 함께 보낸다.
키가 노출되지 않도록 반드시 HTTPS를 사용해야 한다.
클라이언트 측 암호화
클라이언트 측에서 데이터를 암호화한 후 Amazon S3에 바로 업로드한다.
클라이언트 라이브러리를 활용하면 쉽게 암호화할 수 있다.
전송 중 암호화
SSL 또는 TLS
Amazon S3 버킷에는 기본적으로 HTTP, HTTPS 엔드포인트가 존재한다.
Amazon S3를 사용할 때는 물론 데이터 송신 보안을 위해 HTTPS를 사용하도록 권장한다.
S3 버킷 정책에서 aws:SecureTransport가 false라면 GetObject 작업을 거부하도록 하면 버킷에 HTTP를 사용하려는 모든 사용자가 차단된다.
기본값 암호화는 SSE-S3로 제공되는데, 버킷 정책이 먼저 적용되는 것을 이용해 원하는 암호화를 사용하도록 강제할 수 있다.
Cross-Origin Resource Sharing
Origin이란 scheme(protocol) + host + port 를 의미한다.
웹 브라우저는 메인 오리진을 방문 중일 때 다른 오리진에 대해 요청을 보내는 것을 허용할 지에 대한 규칙이다.
즉, 웹 브라우저가 한 웹사이트를 방문하는 동안 요청 체계의 일부로 다른 웹사이트에 요청을 보내야 할 때, 다른 오리진이 CORS 헤더를 사용해 요청을 허용하지 않는 한 해당 요청은 수행되지 않는다.
클라이언트가 S3 버킷에서 교차 오리진 요청을 하면 CORS 헤더를 활성화해야 한다. 특정 오리진을 허용하거나 *를 붙여 모든 오리진을 허용해야 한다.
CORS는 웹 브라우저 보안 메커니즘으로 다른 오리진에서 한 S3 버킷에 들어 있는 이미지, 자산, 파일을 요청할 수 있게 해 준다.
Multi Factor Authentication
객체 버전을 영구적으로 삭제할 때, 버킷에서 버저닝을 중단할 때 등 중요한 작업을 진행할 때 MFA 하드웨어에서 인증하도록 한다.
MFA Delete를 사용하려면 먼저 버킷에서 버저닝을 활성화해야 한다. 버킷 소유자, 즉 루트 계정만이 MFA Delete를 활성화하거나 비활성화할 수 있다.
현재는 AWS CLI로만 설정 가능하다. 미리 MFA 장치를 등록해두고 다음 명령을 수행하면 MFA Delete가 활성화된다.
MFA delete 기능이 활성화되면 console을 통해서는 객체의 특정 버전을 제거할 수 없다. 따라서 AWS CLI를 통해서만 제거 요청을 보낼 수 있다.
MFA를 비활성화할 경우 다음 명령을 수행하면 된다.
모니터링 목적으로 S3 버킷에 대한 모든 액세스를 기록할 수 있다.
어떤 계정에서든 S3로 보낸 모든 요청은 승인 또는 거부 여부와 상관없이 다른 S3 버킷에 파일로 기록된다.
로그는 Amazon Athena 같은 데이터 분석 도구로 분석 가능하다.
로깅 대상 버킷은 로그가 축적되는 버킷과 동일한 AWS 리전에 있어야 한다. 두 버킷은 서로 다른 버킷이어야 한다. (만약 같을 경우 로깅 루프가 생성되어 버킷 크기가 기하급수적으로 증가하므로 문제가 발생한다.)
S3 버킷에 요청할 경우 액세스 로그를 활성화해서 모든 요청이 로깅 버킷에 기록되도록 설정하면 된다.
API 호출, 성공률, 액세스한 사람, 버킷 종류, 시간 등 많은 정보를 제공한다.
Pre-Signed URL
S3 콘솔, CLI, SDK를 사용하여 생성할 수 있는 URL이다.
URL에는 만료 기한이 있다. S3 콘솔로 생성하면 최대 12시간이고, CLI로 생성하면 최대 168시간까지 사용 가능하다.
미리 서명된 URL을 받는 사용자는 URL을 생성한 사용자의 GET 또는 PUT에 대한 권한을 상속받는다.
프라이빗 S3 버킷에 있는 파일에 대한 접근 권한을 일부 AWS 외부의 사용자에게 부여해야 할 때, 퍼블릭 파일로 설정하는 대신 버킷 소유자 또는 사용자로서 해당 파일에 대한 Pre-Signed URL을 생성해 제공하면 된다.
다운로드 또는 업로드를 위해 특정 파일에 임시로 접근할 때 널리 사용된다.
버킷을 비공개로 유지하면서 로그인한 사용자만 S3 버킷에서 프리미엄 비디오를 다운로드할 수 있도록 허용하거나 사용자 목록이 계속 변하는 경우 URL을 동적으로 생성해서 파일을 다운로드할 수 있다. 일시적으로 사용자가 S3 버킷의 특정한 위치에 파일을 업로드하도록 허용할 수 있다.
WORM(Write Once Read Many) 모델을 사용하기 위해 Glacier Vault Lock Policy를 생성할 수 있다.
S3 Glacier Vault Lock Policy를 생성하고 객체를 Glacier Vault에 두면, 객체를 더 이상 수정하거나 삭제할 수 없게 된다. 관리자나 AWS 서비스를 사용해도 삭제할 수 없다.
규정 준수와 데이터 보존에 유용하다.
S3 객체 잠금
버저닝을 활성화해야 S3 객체 잠금을 활성화할 수 있다.
WORM 모델을 채택한다.
객체 잠금은 전체 S3 버킷 수준의 잠금 정책이 아니라 버킷 내의 모든 객체에 각자 적용할 수 있다.
특정 객체 버전이 특정 시간 동안 삭제되는 걸 차단할 수 있다.
두 가지 보존 모드가 존재한다. 이 때 보존 기간을 함께 설정해야 한다.
규정 준수 모드
S3 Glacier 볼트 잠금과 유사하게 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제할 수 없다.
보존 모드, 보존 기간 자체도 변경할 수 없다.
거버넌스 보존 모드
대부분의 사용자는 객체 버전을 덮어쓰거나 삭제하거나 로그 설정을 변경할 수 없다.
관리자 같은 일부 사용자는 IAM을 통해 부여받은 특별 권한으로 보존 기간을 변경하거나 객체를 바로 삭제할 수 있다.
객체에 '법적 보존' 상태를 설정하면 S3 버킷 내 모든 객체를 무기한으로 보호한다. 보존 기간과는 무관하므로 법적으로 중요한 객체에 사용한다. s3:PutObjectLegalHold IAM권한을 가진 사용자는 어떤 객체에든 법적 보존을 설정하거나 제거할 수 있다.
S3 버킷 정책을 생성하고 시간이 지나면 점점 커져 관리가 어려워질 수 있다.
S3 액세스 포인트 정책을 정의해 특정 접두어에 읽기 및 쓰기 권한을 부여할 수 있다.
버킷 정책은 단순하게 두고, 액세스 포인트를 각 팀 마다 세밀하게 부여하여 보안 정책을 쉽게 관리할 수 있다.
S3 버킷에 대한 접근을 스케일링할 수 있다.
각 액세스 포인트는 고유한 DNS 이름을 가진다. 이를 통해 액세스 포인트에 접속할 수 있다.
액세스 포인트는 인터넷 오리진에 연결되거나 프라이빗 트래픽이라면 VPC 오리진에 연결되도록 할 수 있다.
S3 액세스 포인트의 VPC 오리진을 정의하여 VPC 엔드포인트를 통해 S3 버킷에 접근하도록 한다. 이 때 VPC 엔드포인트 정책에서 타깃 버킷과 액세스 포인트에 대한 접근을 허용해 줘야 한다.
결국 VPC 엔드포인트 보안, 액세스 포인트 정책의 보안, S3 버킷 수준 보안이 함께 존재하게 된다.
S3 버킷에서 객체를 조회할 때 객체를 반환하기 직전에 수정 과정을 거치기 위해 람다 함수를 사용할 수 있다.
S3 액세스 포인트가 필요하다.
원본 객체에서 일부 데이터가 삭제된 객체에 접근하고자 하는 경우 새로운 S3 버킷에 객체를 따로 저장하는 대신, S3 객체 람다 액세스 포인트에 요청을 보내도록 하고, 람다 함수는 S3 액세스 포인트를 통해 조회한 객체를 수정한 후 반환한다.
분석 애플리케이션이나 비프로덕션 환경을 위해 개인식별정보를 삭제하는 경우, 데이터 형식을 XML에서 JSON으로 변환하는 경우, 이미지 크기를 조정하거나 워터마크를 추가하는 경우 등에 사용된다.
