Section 30. AWS 보안 및 암호화: KMS, 암호화 SDK, SSM 파라미터 스토어, IAM 및 STS

암호화

전송 중 암호화는 TLS 또는 SSL이라고 부른다.(TSL는 SSL의 가장 최근 버전)

데이터 전송 전에 암호화가 되고 받은 후에 해독되는 원리로 작용한다.

이는 네트워크와 서버의 소통을 위해 사용된다.

• TLS 인증서가 암호화를 지원한다.

전송 중 암호화를 하는 이유?

• 데이터를 전송할 때 공공 네트워크를 사용하는 경우도 있고,
  데이터가 여러 다른 서버를 통해 지나가기 때문에 중간자 공격을 방어할 필요가 있기 때문이다.
• "중간자 공격"은 중간의 서버가 데이터를 받고 서버로 전송 중인 패키지를 관찰해버리는 것을 말한다.
• 이러한 이유로 우리는 HTTPS나 TLS, SSL을 원한다!

TLS를 이용한 데이터 전송

전송하고자 하는 데이터를 TLS 암호화하여 전송한다!

• 암호화와 해독을 위한 키는 어딘가에서 관리가 일어나고, 서버가 이 키에 대한 접근을 할 수 있어야 함을 나타낸다.

클라이언트 측 암호화

• 데이터가 클라이언트 측에서 암호화와 해독이 되며 서버는 이 데이터를 해독할 수 없어야 한다.
  왜냐하면 서버를 신뢰할 수 없는 경우이기 때문이다.

대상 서버 조차 데이터 내용을 해독할 수 없다!

---

AWS KMS(Key Management Service)

AWS 서비스의 암호화에 대해 들을 때는 대부분이 KMS 암호화를 의미할 것이다.

기본적으로 암호화 키를 관리해주기 때문에 할 일이 줄어든다는 장점이 있다.

KMS는 권한 부여를 위해 IAM과 완전히 통합되어 있으며 KMS로 암호화하면 데이터 액세스를 쉽게 제어할 수 있다.

 

KMS 특징

• CloudTrail을 통해 키를 사용하기 위해 수행된 모든 API 호출을 검사할 수 있다.
• 대부분의 AWS 서비스에서 사용할 수 있다.
• 기밀 정보가 있는 경우에 일반 텍스트 그대로 코드에 저장해서는 안된다.
  • 이는 민감한 정보는 KMS 키로 암호화할 수 있다는 의미이다.

1. KMS Keys Types

KMS 키의 유형들을 알아보자.

1. Symmetric

• 데이터를 암호화 및 해독하는 오직 하나의 키를 사용한다.
• KMS와 통합된 모든 서비스는 대칭 키는 사용하는데 기본적으로 KMS 대칭 키를 만들거나 사용하면 키 자체에 액세스할 수 없게 된다.
  이를 사용하기 위해서는 AWS API 호출을 사용해야 한다.

2. Asymmetric

• 키가 두 개로 암호화와 해독에 사용되는 키가 나뉘어져 있다.(암호화는 공개 키, 복호화는 개인 키)
• 암호화, 복호화나 작업에 대한 서명 또는 확인 작업을 할 때 사용하는데,
  공개 키는 KMS에서 다운로드할 수 있지만, 개인 키에는 액세스할 수 없다. 개인 키는 오로지 API 호출을 통해서만 얻을 수 있다.

3. AWS Owned Keys

• 무료이며, SSC, S3 유형의 암호화나 DynamoDB 소유 키를 선택 가능한 옵션이 있는 SSC DynamoDB를 사용할 때 사용한다.

4. AWS Managed Key

• 무료이며 aws/ 뒤에 서비스명이 붙는 형태이다.

5. Customer managed keys

• 사용자 지정 키는 월 1달러의 비용이 청구된다.

🌈 Automatic Key rotation

• AWS 관리형 KMS 키는 매 1년마다 자동으로 교체된다.
• 사용자 지정 관리형 KMS 키는 매 1년마다 교체되도록 해야하며,
  가져온 KMS 키는 수동으로만 교체가 가능하며 별칭을 사용해야만 한다.

Copying Snapshots across regions

생성된 스냅샷의 KMS 키는 복제한 것과 같다!

3. KMS Key Policies

S3 버킷 정책과 비슷하지만 키에 대한 KMS 정책이 없으면 아무도 해당 키에 액세스할 수 없다.

• 기본 키 정책
  • 특정한 사용자 지정 KMS 키 정책이 제공되지 않는 경우에 생성된다.
  • 기본적으로 계정의 모든 사람이 이 키에 액세스할 수 있도록 허용하는 것으로,
    사용자나 역할이 해당 키 정책에 액세스할 수 있도록 허용하는 IAM 정책이 있으면 된다!
• 사용자 지정 KMS 키 정책
  • 구체적으로 제어하고 싶을 때 사용한다.
  • KMS 키에 액세스할 수 있는 사용자, 역할을 정의하고 키를 관리할 수 있는 사람을 정의할 수 있다.
  • 다른 계정에 KMS 키를 사용할 권한을 부여할 수 있기 때문에 KMS 키에 대한 교차 계정 접근을 수행하려는 경우에 유용하다.

Copying Snapshots across accounts

계정간 스냅샷을 복제하기 위해서는 다음과 같은 과정이 필요하다.

1. KMS 키로 암호화된 스냅샷을 생성한다.
2. 교차 계정 액세스를 허가하기 위해 KMS 키 정책을 추가한다.
3. 암호화된 스냅샷을 대상 계정과 공유하고 대상 계정에서 스냅샷 복사본을 생성하여 해당 계정의 다른 고객 관리 키로 암호화한다.
4. 대상 계정의 스냅샷에서 볼륨을 생성한다.

---

KMS 암호화 패턴 및 봉투 암호화

1. API - 암호화와 복호화

복호화 API는 어느 키가 암호화에 사용되었는지 찾는다.

2. 봉투 암호화

• KMS 암호화 API는 4 KB의 제한을 가지고 있다.
• 4KB 이상을 암호화 하려면, 봉투 암호화를 사용할 필요가 있다.
  이 때, "GenerateDataKey API"를 기억하자!

봉투 암호화

KMS에서는 암호화 키와 데이터 키, 암호화 된 데이터 키를 받는다.

봉투 복호화

IAM 권한이 확인되면 DEK를 해독하여 암호화된 파일과 평문 DEK를 볼 수 있다!

 

봉투 암호화의 목적은 KMS를 원래 장점대로 키를 생성하는 데에 쓰고 암호화와 복호화는 클라이언트 측에서 한다는 것이다.

 

3. 암호화 SDK

AWS 암호화 SDK는 봉투 암호화를 하기 위해 사용되며 또한 CLI 도구로도 존재한다!

암호화 SDK에는 데이터 키 캐싱 기능이 존재한다.

• Data Key Caching:
  
  • 각각의 암호화를 위해 새로운 키를 생성하는 것 대신 데이터를 재사용한다.
  • KMS에 호출을 적게 하기 위한 것이 목적이다.
  • 데이터 키 캐싱은 "LocalCryptoMaterialsCache"를 사용하는데 이는 데이터 키의 캐시가 얼마나 커야하는지 나타낸다.

---

KMS 한도

요청 할당량을 초과하게 되면, "ThrottlingException"이 발생한다.

이를 대처하기 위해서는 지수 백오프 전략을 사용한다.

• 각 암호화 작업마다 해독이나 암호화는 할당량을 공유한다.
• 이때 계정 간 리전 간에 할당량을 공유하는 것은 키를 자주 사용한다는 것인데,
  이 말은 ThrottlingException이 발생하기 쉽다는 것이다.!

해결 방안

1. GenerateDataKey API를 가지고 있다면 DEK 캐싱을 사용하자.

• 데이터 암호화 키를 로컬에서 캐시해서 API 호출의 수를 줄인다.

2. 요청 할당량을 늘리자.

• 할당량 증가는 현재 API 호출이나 문의를 통해 진행할 수 있다.

---

S3 버킷 키

SSE-KMS 암호화와 함께 S3 버킷을 사용할 수 있는 새로운 설정을 알아보자.

새로운 설정을 적용하기 위해서는 SSE-KMS 유형 암호화를 사용하여 S3로부터 KMS로 보내지는 API 호출의 양을 99%나 감소시킬 수 있다. 그렇게 되면 비용 또한 99%나 절약될 수 있다!!

작동 원리를 알아보자.

S3 버킷 키는 많이 새로운 데이터 키를 생성하여 KMS 오브젝트를 암호화하는데 사용된다!

이러한 과정으로 우리는 CloudTrail 내에서 KMS와 관련된 CloudTrail 이벤트를 줄일 수 있다!!

---

CloudHSM

KMS를 통해 우리는 암호화 소프트웨어를 관리하고 암호화 키를 제어하였다.

그러나 CloudHSM을 사용하면 AWS는 일부 암호화 하드웨어를 프로비저닝한다!

• AWS가 아닌 클라우드 개발자가 직접 암호화 키를 완전히 관리하게 된다!
• HSM 장치는 FIPS 104-2 레벨 3 규정을 준수하여 변조 방지 기능을 갖추고 있는데,
  이는 누구든지 HSM에 수동으로 접근하려고 할 때 중지되고 차단하기 위함이다.
• HSM은 symmetric, asymmetric을 지원하기에 그 위에 SSL 및 TLS 키 등을 포함할 수 있다.
• 프리 티어는 없으며 상당히 복잡하다!

CloudHSM 다이어그램

CloudHSM 소프트웨어 사용 시, 키를 관리하고 사용자와 그들의 키 액세스 권한을 관리하게 된다.

 

CloudHSM 고가용성

CloudHSM 클러스터는 고가용성을 제공하며 여러 AZ에 분산되어 있다.

이를 통해 클라이언트는 여러 AZ 중 하나를 골라 사용할 수 있다.

 

CloudHSM - AWS 서비스와 통합

CloudHSM은 AWS KMS와 통합할 수 있다.

그리고 CloudHSM을 갖고 KSM 사용자 정의 키 스토어를 구성한다.

CloudHSM vs. KMS

---

SSM 파라미터 스토어

SSM 파라미터 스토어는 구성 및 보안 암호를 안전하게 보관하기 위한 저장소이다.

구성 데이터를 암호화해 좀 더 안전하게 보관하고 싶다면 KMS를 이용할 수도 있다.

 

• SSM 파라미터 스토어는 서버리스이고, 확장성, 내구성을 갖고 있으며 SDK를 사용하기 쉽다.
• 구성을 업데이트할 때마다 버전이 생성되어 버전 관리가 가능하다.
• IAM으로 보안설정이 가능하고 EventBridge로 알람 횟수를 지정할 수 있다.

Standard and advanced parameter tiers

시스템 매니터에는 두 종류의 파라미터 티어가 있다.

표준 티어와 고급 티어로, 그 차이를 알아보자.

 

파라미터 정책

파라미터 정책으로 파라미터의 지속 시간을 설정할 수 있다.

이를 통해 사용자가 암호 등의 민감 데이터를 업데이트하거나 삭제하도록 강요할 수 있다.

---

Secret Manager

비밀을 저장하기 위한 서비스로 매 지정한 일마다 비밀이 순환되도록 강제할 수 있다.

이 기능으로 인해 비밀 관리 스케줄이 개선될 수 있다.

• Secret Manager는 RDS와 통합이 가능하다는 특징이 있다.
• 또한 비밀들은 KMS를 사용하여 암호화할 수 있다는 특징이 있다.

Multi-Region Secrets

다수의 AWS 리전에 걸쳐 비밀을 복제할 수 있는 개념으로 기본 비밀과 동기화하여 복제본들을 읽어나간다.

복제본을 왜 생성하여 읽어나가는 것일까?

그 이유는 메인 리전에 오류가 생길 수 있다.

• 오류 발생 시 복제본 비밀을 독립된 비밀로 승격시킬 수 있다.
• 재해 복구 전략을 세울 수도 있으며 RDS에 복제된 내용도 비밀을 공유할 수가 있다.

---

SSM 파라미터 스토어 vs. Secret Manager

SSM 파라미터 스토어와 시크릿 매니저를 비교해 보자.

1. Secret Manager:

• AWS 람다를 이용한 비밀 자동 순환
• 람다 함수는 RDS, Redshift 등의 서비스들을 제공받는다.
• KMS 암호화는 의무적이어야한다.
• CloudFormation과 통합할 수 있다.

2. SSM Parameter Store:

• 간단한 API로 구현된다.
• 비밀 순환 기능이 없다.
• KMS 암호화가 선택 사항이다.
• CloudFormation과 통합할 수 있다.
• SSM 파라미터 스토어 API를 사용하여 Secret Manager의 암호를 풀링할 수 있다.

순환 측면에서 둘을 그림으로 비교해보자.

SSM 파라미터 스토어에 저장된 값을 변경하게끔 람다 함수를 직접 생성해야한다!

---

CloudWatch 로그 암호화

KMS 키를 이용하여 CloudWatch 로그를 암호화할 수 있다!

암호화는 로그 그룹 레벨에서 일어나며, CMK를 기존의 로그 그룹과 연결할 수도 있고 새 로그 그룹을 연결할 수도 있다.

반드시 CloudWatch Logs API를 사용해야 함을 명시하자.

API는 두 가지를 기억하자.

• associate-kms-key | KMS 키를 기존의 로그 그룹과 연결한다.
• create-log-group | KMS 키를 새로 생성한 로그 그룹과 연결한다.

---

CodeBuild Security

• VPC 내에 있는 리소스에 접근하기 위해서는 CodeBuild의 VPC 설정을 명시해야 한다.
• CodeBuild 암호는 당연하지만 환경 변수 내에서 평문으로 저장해서는 안된다.
  대신 2가지 방안이 있다.
  1. 환경 변수가 파라미터 스토어의 파라미터들을 참조할 수 있다.
  2. 환경 변수가 Secrets Manager의 암호를 참조할 수도 있다.

---

AWS Nitro Enclaves

독립된 컴퓨터 환경 내에서 민감한 데이터를 처리해야 할 때가 있다.

(민감 데이터는 PII 데이터나 건강 관리 데이터 등이 될 수도 있다.)

우리는 Nitro Enclaves를 사용하여 완전 독립형 가상 머신을 만들 수 있다.

• 영구 스토리지도 없고, 대화형 액세스가 없어 SSH로 접근할 수 없다.
• 민간 데이터를 처리하는 앱에서 공격에 노출되는 면을 줄일 수 있다.
• 암호화 증명으로 인증받은 코드만 Enclave에서 실행하도록 할 수 있다.
  • 추가로 KMS 암호화를 사용할 수도 있다.