끊임없는 학습

CORS 교차 오리진 리소스 공유

​

CORS mean Cross-Origin Resource Sharing

An origin is a scheme (protocol), host (domain) and port

ex) https://www.example.com (implied port is 443 for HTTPS, 80 for HTTP)

​

-Web Browser based mechanism to allow requests to other origins while visiting the main origin

-Same origin : http://example.com/app1 & http://example.com/app2

-Different origins : http://www.example.com & http://other.example.com

​

-the requets won't be fulfilled unless the other origin allows for the requests, using CORS Headers(ex:Access-Control-Allow-Origin)

​

CORS는 교차 오리진 리소스 공유이다.

즉, 리소스를 다른 오리진에서 얻을 수가 있는 것이다.

오리진이란 체계(프로토콜), 호스트(도메인), 포트이다.

예시 : https://www.example.com은 체계가 hhtps이고, 호스트가 www.example.com, 포트가 443이다.

​

웹 브라우저에는 기본적인 보안으로 CORS를 갖추고 있는데 이는 웹사이트를 방문했을 때 오리진이 허락 할 때에만 요청을 보낼 수 있도록

허락하는 설정이다. 브라우저 기반 보안인 것.

같은 오리진은 첫 번째와 두 번째 URL끼리 웹 브라우저 요청이 가능하다.

example.com에서 other.example.com에 대한 요청을 할 경우 이를 교차 오리진 요청이라고 하며 이때 올바른 CORS 헤더가 없으면

웹 브라우저가 해당 요청을 차단한다.

​

S3 CORS

​

-If a client does a cross-origin request on our S3 bucket, we need to enable the correct CORS headers

-You can allow for a specific origin or for *(all origins)

​

클라이언트가 웹사이트로 활성화된 S3 버킷에 대해 교차 오리진을 요청하는 경우 올바른 CORS 헤더를 활성화 해야 한다.

특정 오리진에 대해 허용할 수 있거나 혹은 *(아스테리스크)로 전체 오리진을 허용할 수도 있다.

S3 Security

​

User based

-IAM policies - which API calls should be allowed for a specific user from IAM console

​

Resource Based

-Bucket Policies - bucket wide rules from the S3 console - allow cross account

-Object Access Control List (ACL) - finer grain

-Bucket Access Control List (ACL) - less common

​

Note : an IAM principal can access an S3 object if

the user IAMm permissions allow it OR the resource policy ALLOWS it

AND there's no explicit DENY

​

S3 보안

​

사용자 기반 보안

-IAM 정책 : 어떤 API 호출이 허용될지 결정함

만약 유저가 IAM 정책을 통해 S3 버킷으로의 액세스 방법을 승인받게 되면 실행 가능해짐

​

리소스 기반 보안

버킷 정책 : S3 콘솔에서 설정 가능한 버킷 전반의 규칙, S3 버킷으로의 교차 계정 액세스 활성화가 가능함

객체 ACL

버킷 ACL - 이 둘은 시험에 잘 나오지 않음

​

참고

-IAM 보안 주체인 유저나 역할은 IAM 권한이 허용할 경우, S3 객체에 액세스 할 수 있다.

->IAM 정책이 S3 버킷에 액세스를 허용하는 보안 주체와 연결돼 있는 경우 or S3 버킷 정책이 허용하는 경우에도 액세스 가능함

동시에 버킷 정책이 사용자 액세스의 명시적 거부가 없어야 함.

​

S3 Bucket Policies

​

JSON based policies

-Resources : bucekts and objects

-Actouons : Set of API to Allow or Deny

-Effect : Allow / Deny

-Principal : The account or user to apply the policy to

​

Use S3 bucket for policy to :

-Grant public access to the bucket

-Force objects to be encrypted at upload

-Grant access to another account(Cross Account)

​

-버킷 정책은 사용자의 버킷이나 객체 둘 다 적용 할 수 있다.

-Action은 API 허가/거부 설정

-Effect 허용/거부 설정

-Principal : 해당 S3 버킷의 정책을 적용할 계정(유저)

​

S3 버킷 정책 사용하는 경우

-버킷에 퍼블릭 액세스 권한을 승인

-업로드 시점에 객체 암호화 할 경우

-교차 계정 S3 버킷 정책 사용하여 다른 계정에 액세스 권한 주는 경우

​

Bucket settings for Block Public Access

​

Block public access to buckets and objects granted through

-new access control list (ACLs)

-any access control list (ACLs)

-new public bucket or access point policies

​

Block public and cross-account access to buckets and objects through any public bucket or access point policies

​

These settings were created to prevent compnay data leaks

If you know your bucket should never be public, leave these on

​

블록 퍼블릭 액세스 (버킷 설정)

​

객체가 퍼블릭으로 노출 되는 것을 차단하는 설정

​

네 가지 종류의 액세스 차단 설정이 있으니 참고

퍼블릭으로 두고 싶지 않다면 해당 설정을 활성화시켜야 한다.

​

S3 Security - Other (기타 보안)

​

Networking :

-Support VPC Endpoints (for instances in VPC without www internet)

​

Logging and Audit :​

-S3 Access Logs can be stored in other S3 bucket

-API calls be logged in AWS CloudTrail

​

User Security :

-MFA Delete : MFA can be required in versioned buckets to delete objects

-Pre-Signed URLs : URLs that are valid only for a limited time

​

네트워킹 :

VPC 엔드포인트로 S3에 비공개 액세스 가능하다.

(VPC에 EC2 인스턴스가 있고 인터넷 액세스가 없는 경우 VPC 엔드포인트를 통해 비공개로 S3에 액세스)

​

로깅 및 감사 :

S3 액세스 로그를 사용하면 다른 S3 버킷에 해당 로그가 저장됨

API 호출은 CloudTrail에 저장된다.

​

사용자 보안 :

MFA 삭제 : MFA로 인증이 되어야만 객체 삭제 가능

사전 서명된 URL : AWS의 자격증명으로 서명된 URL, 한정된 시간 동안만 유효하다.

There are 4 methods of encrypting objects in S3

• SS3-S3 : encrypts S3 objects usung keys handled & managed by AWS
• SSE-KMS : leverage AWS key Management Service to manage encryption keys
• SSE-C : when you want to manage your own encryption keys
• Client Side Encryption

​

It's important to understand which ones are adapted to which situation for the exam.

​

S3에 객체를 업로드 할 경우, 객체들은 AWS 내의 서버가 되므로 객체로 접근할 때 보호하려 할 것이다.

누군가가 Amazon 서버에 들어오거나, 회사에서 설정한 보안 기준을 준수하기 등이 예시이다.

​

SSE-S3는 AWS가 다루고 관리하는 키를 사용해 S3 객체를 암호화하는 방법

SSE-KMS는 AWS 키 관리 서비스를 사용해 암호화 키를 관리하는 방법

SSE-C는 사용자가 만든 암호화 키를 관리할 때 쓰이는 방식

클라이언트 측 암호화가 있다.

​

특정 상황에서 어떤 방법을 적용해야 할지 아는 것이 중요하다.

SSE-S3

• SSE-S3 : encyption using keys handled & managed by Amazon S3
• Object is encrypted server side
• AES-256 encryption type
• Must ste header : "X-amz-server-side-encryption":'AES256"

​

Amazon S3에서 처리하고 관리하는 키를 암호화에 사용하는 방식이다.

객체는 서버 측에서 암호화 된다.

암호화 유형은 AES-256 알고리즘이다.

"X-amz-server-side-encryption":'AES256" 헤더가 설정된다.

​

SSE-KMS

​

SSE-KMS : encryption using keys handled & managed by KMS

KMS Advantages : user control + audit trail

Object is encrypted server side

Must ser header : "x-amz-server-side-encryption": "aws:kms"

​

KMS는 키 관리 서비스를 의미하며 암호화 서비스들 중 하나이다.

• 암호화 키는 KMS 서비스에서 처리 및 관리한다.
• SSE-S3 대신 KMS를 사용하는 이유가 무엇일까?
  • 누가 어떤 키에 접근할 수 있을지 제어 가능 + 감사 추적을 할 수 있다.

​

• 객체는 서버 측에서 암호화 된다.
• 헤더는 "x-amz-server-side-encryption": "aws:kms" 로 지정해야 한다

​

원리는 SSE-S3와 동일하며 키만 다르다. KMS Customer Master Key(미리 지정해둔) 키를 사용한다.

​

SSE-C

​

SSE-C : server-side encryption using data keys fully managed by the customer outside of AWS

-Amazon S3 does not store the encryption key you provide

-HTTPS must be used

-Encryption key must provieded in HTTP headers, for every HTTP request made

​

SSE-C는 서버측 암호화 방식, AWS가 외부에서 customer가 관리하는 키를 사용한다.

• S3는 고객이 제공한 암호화 키를 저장하지 않는다. (사용 후 키를 폐기한다.)
• 데이터를 AWS로 전송할 때는 HTTPS를 사용해여 한다. (전송 중 암호화)
• 암호화 키가 HTTP 헤더에 제공되어야 함. 모든 HTTP 요청마다 매번 제공되어야 함. (사용 후 폐기되어서)

​

클라이언트 측이 데이터 키를 제공해야 해서 관리하는 것이 더 많아짐.

​

Client Side Encryption

​

Client library such as th Amazon S3 Encryption Client

Clients must encrypt data themselves before sending to S3

Clinets must decrypt data themselves when retrieving from S3

Customer fully manages the keys and encryption cycle

​

• S3에 객체를 업로드 하기 전, 클라이언트가 객체를 암호화를 한다.
• 클라이언트 라이브러리를 사용할 수 있는데 Amazon S3 Encryption Client 등으로 클라이언트 측 암호화를 수행할 수 있다.
• 클라이언트는 데이터를 S3에 보내기 전에 암호화 해야 한다.
• 또한 데이터를 해독할 채임도 클라이언트의 책임이다.
• 클라이언트 측 암호화에서는 키와 암호화 cycle 전체를 클라이언트가 전부 관리해야 한다.

​

Encryption in transit (SSL/TLS)

​

Amazon S3 exposes:

HTTP endpoint : non encrypted

HTTPS endpoint : encryption in flight

​

You're free to use the endpoint you want, but HTTPS is recommended

Most clients would use the HTTPS endpoint by default

​

HTTPS is mandatory for SSE-C

Encryption in flight is also called SSL / TLS

​

• 전송 중 암호화
• SSL 및 TLS 연결이 해당된다.
• S3가 이 서비스를 주도한다.
  • 암호화되지 않은 HTTP 엔드포인트를 노출
  • 암호화된 HTTPS 엔드포인트를 노출해 전송 중 암호화 서비스를 제공한다.

이때 SSL과 TLS 인증서의 도움을 받게 된다.

​

• 사용자는 원하는 엔드포인트를 사용해도 된다. 하지만 대부분 사용자들은 HTTPS를 기본적으로 사용한다.
• SSE-C 서버 측 암호화를 사용해 클라이언트가 키를 제공하는 경우에는 HTTPS 사용이 의무이다.
• 전송 중 암호화는 SSL/TLS라고도 불린다.