[73일 차] 21.11.05 : DevOps 14

AWS Certificate Manager

SSL/TLS

---

1교시

 

 

어제 마지막 시간은 Node.js 애플리케이션 코드 문제인지 에러 찾다가 끝났다.

어쨌건 전체 구조는

사용자가 URI를 전송하고 ID를 받음

-> Node.js 생산자가 메시지를 큐로 전송. Payload에 ID에 URL 포함.

-> Node.js 소비자가 메시지를 수신하고 URL에서 PNG 이미지 생성. 그리고 S3에 이미지 저장(ID는 이미지 이름)

-> 사용자는 알려준 ID로 S3에서 이미지 다운로드

 

 

인프라 디커플링 요약

- 종속성을 줄이기 위한 작업. 일을 쉽게 만든다

- 동기 디커플링은 양측이 동시에 가용해야 하지만, 서로를 알지는 못한다.

- 비동기 디커플링은 다른 쪽이 가용하지 않아도 통신 가능

- 대부분의 애플리케이션은 ELB 서비스가 제공하는 로드 밸런서를 이용, 코드를 건드리지 않고 디커플링 가능

- 비동기 디커플링은 비동기 프로세스에만 가능. 대부분의 동기 프로세스는 비동기 프로세스로 수정 가능

- SQS로 비동기 디커플링을 하려면 적절한 AWS SDK를 활용해 SQS를 사용하도록 프로그래밍해야 한다.

 

• HTTP + SSL/TLS = HTTPS

HTTPS는 단일 프로토콜이 아니다. HTTP로 만들어진 평문을 SSL/TLS로 암호화하는 것이 HTTPS.

어떨게 평문을 암호화할 것이며, 어떻게 암호문을 복호화할 것인지에 대한 협약(or 알고리즘) 필요.

-> SSL/TLS는 비대칭 암호화 알고리즘으로 인증, 대칭 암호화 알고리즘으로 암호화

 

 

HTTPS에는 2가지가 있다.

1. 인증

2. 암호

 

 

아무리 들어도 모자란...

• 비대칭 키 암호화(인증) : 개인 키와 공개 키

송신 측이 가지고 있는 개인 키를 암호화(서명) 용도로 쓰고

수신 측이 가지고 있는 공개 키를 복호화(인증) 용도로 사용

 

비대칭 키 알고리즘을 데이터 암호화 용도로 사용할 때에는 반대!

-> 개인 키가 복호화, 공개 키가 암호화 용도

---

2교시

 

 

PKI(Public Key Infra) : 공개 키 기반 구조 - 인증서 관리 구조

CA(Certificate Authority)의 역할 : 인증서 생성/관리/폐기

 

CA와 서버 구조를 보면

CA는 개인 키/공개 키를 가지고 있고, 서버도 자신의 개인 키/공개 키를 가지고 있다.

웹 브라우저에서 서버로 접속하는 경우를 보자.

브라우저는 접속하려는 서버가 신뢰할만한지(국가로부터 인증을 받았는지) 알고자 한다.

웹 브라우저는 CA의 공개 키를 가지고 있다.

1. 서버는 자신의 공개 키를 CA에 보낸다(인증서 요청)

2. CA는 서버의 공개 키를 CA의 개인 키로 서명(암호화)해준다. 이걸 인증(복호화)하려면 CA의 공개 키가 있어야 한다.

-> CA의 개인 키 + 서버의 공개 키 = 공인 인증서

3. 클라이언트가 서버의 공인 인증서를 받아서 가지고 있던 CA의 공개 키로 복호화하고 서버의 공개 키를 얻는다.

-> 이 서버는 신뢰할 수 있다!

(예전에 대충 만든 인증서를 사용했을 때 브라우저에 경고가 뜬 것은? 브라우저가 가지고 있던 CA의 공개 키로 안 풀리니까 뜨는 것)

 

• 클라이언트(웹)와 서버 간의 SSL 통신을 예시로 들어보자.

1. Client hello(클라->서버)

클라이언트가 생성한 랜덤 데이터 전송. 사용 가능한 암호화 방식 후보들을 서버에게 알려준다.

2. Server hello(서버->클라)

서버가 생성한 랜덤 데이터 전송. 서버가 선택한 클라이언트 암호화 방식을 클라이언트에게 알려준다.

인증서를 클라이언트에게 보낸다.

3. 클라이언트가 서버로부터 받은 인증서 확인

가지고 있던 CA의 공개 키로 받은 인증서 복호화 시도.

성공했다면 인증서로부터 서버의 공개 키를 얻는다(+ 이 서버는 신뢰할 수 있다는 것을 인지)

이제부터는 서버의 공개 키를 암호화 용도로 사용할 것이다.

4. pre master secret(= Session key)

인증서 안에 들어있는 공개 키를 이용, pre master secret 값을 암호화하여 서버로 전송

5. pre master secret 복호화

서버는 자신의 비공개 키로 복호화

 

여기까지가 SSL handshake 과정

 

6. master secret 및 session key(대칭 키) 생성

클라이언트와 서버 양쪽에서 대칭 키 생성. 이제 이 대칭 키를 사용해서 데이터를 암호화한 후에 통신할 것이다.

이러면 제 3자가 데이터를 가로챌 수 없다.

 

 

CA는 퍼블릭/사설이 있는데, ACM을 위해 AWS는 국가에 퍼블릭 CA로 등록했다.

 

 

• 인증서 관리 : ACM(AWS Certificate Manager)

AWS 웹 사이트와 애플리케이션을 보호하는 퍼블릭 및 프라이빗 SSL/TLS X.509 인증서와 키를 만들고, 저장하고, 갱신하는 복잡성을 처리한다.

ACM에서 직접 발행하거나 서드 파티 인증서를 ACM 관리 시스템으로 가져오는 방법으로 통합 AWS 서비스에 대한 인증서를 제공할 수 있다. ACM 인증서는 단일 도메인 이름, 여러 특정 도메인 이름, 와일드카드 도메인 또는 이러한 도메인의 조합을 보호할 수 있다.

ACM 와일드카드 인증서는 원하는 만큼의 하위 도메인을 보호할 수 있다. 내부 PKI의 모든 위치에서 사용할 수 있도록 ACM Private CA로 서명한 ACM 인증서를 내보낼 수도 있다.

 

* AWS는 관리형 X.509 인증서를 배포하는 고객에게 2가지 옵션을 제공한다.

1. AWS Certificate Manager(ACM) - 퍼블릭

TLS를 사용하는 보안 웹이 필요한 기업 고객을 위한 인증서 관리. ACM 인증서는 ELB, CloudFront, API Gateway 및 기타 통합 AWS 서비스를 통해 배포된다. 이런 종류의 가장 일반적인 앱은 중요한 트래픽 요구 사항을 가진 안전한 공개 웹 사이트다.

ACM은 만료되는 인증서의 갱신을 자동화하여 보안 관리를 단순화한다.

 

2. ACM Private CA

AWS 클라우드 내부에 PKI(Public Key Infra)를 구축하는 기업 고객을 대상으로 하며, 조직 내에서 비공개로 사용할 수 있도록 고안되었다. ACM Private CA를 사용하여 고유한 CA(인증 기관) 계층을 만들고 사용자 컴퓨터, 앱, 서비스, 서버, 기타 디바이스를 인증하기 위해 인증서를 발급할 수 있다. 사설 CA에서 발급한 인증서는 인터넷에서 사용할 수 없다.

 

 

ELB-EC2 구조에 ACM을 연동하면

클라이언트가 ELB에게 인증서 요청 -> ELB가 ACM에게 인증서 받아서 클라이언트에게 보내준다

EC2에 인증서를 저장하는 구조가 아니다!

HTTPS 사용을 위해 리스너 포트나 타깃 그룹 포트에 443번 포트를 등록하면 인증서를 등록해야 한다.

---

3교시

 

 

• ACM 특징

1. 도메인 검증(DV)

ACM 인증서의 도메인 검증. ACM 인증서의 제목 필드는 도메인 이름만 나타낸다. ACM 인증서를 요청할 때 사용자는 요청을 통해 지정한 모든 도메인에 대해 사용자가 소유하거나 관리 권한을 보유하고 있는지 검증해야 한다. 이메일/DNS를 통해 소유권을 검증

 

2. 유효 기간

ACM 인증서의 유효 기간은 약 13개월

 

3. 관리형 갱신 및 배포

ACM은 인증서 갱신 프로세스와 갱신 후 인증서 프로비저닝 프로세스를 관리한다. 자동 갱신을 사용하면 잘못된 구성, 취소 또는 만료된 인증서로 인한 가동 중지를 방지할 수 있다.

 

4. 브라우저 및 애플리케이션 신뢰

모든 주요 브라우저에서 ACM 인증서를 신뢰한다. ACM 인증서를 신뢰하는 브라우저에서는 SSL/TLS를 통해 ACM 인증서를 사용하는 사이트에 연결하면 상태/주소 표시줄에 자물쇠 아이콘이 표시된다. Java에서도 ACM을 신뢰한다.

 

5. 여러 도메인 이름

ACM 인증서에서는 하나 이상의 GQDN이 포함되어 있으며 원한다면 이름 추가 가능.

 

6. 와일드카드 이름

ACM을 사용하면 도메인 이름에 *를 사용하여 동일한 도메인에서 여러 사이트를 보호할 수 있는 와일드카드 이름을 포함하는 ACM 인증서 생성 가능.

 

 

• ACM 실습

CIDR이 좀 틀린 부분이 있는데 알아서 수정하자.

 

ACM 구성 전 기본 구조

VPC에 서브넷 2개(다른 가용 영역), 각 서브넷에 웹 인스턴스 1개씩

Route 53으로 도메인을 ALB로 연결하는 레코드 생성, 작동 확인

일단은 HTTP(80)으로

---

4교시

 

 

구조 설명하신 거 혹시 모르니 다시 듣고

ACM으로 이동 : Certificate Manager

인증서 요청 > 퍼블릭 인증서 요청 > 도메인 이름 작성(와일드카드 형식으로 작성해도 무방), 나머지 기본값으로 두고 요청

요청 후에 보면 검증 대기 중 상태.

인증서 클릭 > 도메인 탭 > Route 53에서 레코드 생성 > 도메인 체크 후 레코드 생성

좀 기다리면 Route 53에 레코드가 추가된다. 그리고 인증서 상태가 발급됨으로 바뀌고, 도메인 상태가 성공으로 바뀐다.

 

이제 발급받은 인증서를 사용해 보자.

ALB로 이동 > 리스너 탭 > 기존 리스너 편집 > 프로토콜 HTTPS로 변경(타깃 그룹은 내버려두어도 상관없다), Secure listener settings 부분에서 Default SSL certificate를 아까 만든 인증서로 지정 > 수정 사항 저장

ALB에 부착된 보안 그룹의 인바운드 규칙에 HTTPS(443) 추가

 

끝! 이제 도메인을 https://로 접속할 수 있다.

 

ACM 삭제하려면 연동했던 ALB에서 연동을 해제하거나 ALB 삭제 후에 삭제해야 한다.

---

5~8교시

 

 

자습 + 복습 시간

 

월요일은 마이그레이션 서비스

---

1교시(09:50~10:00)

4교시(12:40~12:45)