https://aws.amazon.com/ko/certificate-manager/
- 인증서를 발급하기 위해 사용하는 서비스
- 인증서는 public한 공인 인증서 또는 private한 사설 인증서로 구분
- public 인증서는 AWS 서비스와 integration이 되어 있어 cloudfront, alb/nlb와 결합하여 사용 가능
- private 인증서는 aws native service로 활용하고 싶은 경우 활용
https://aws.amazon.com/ko/kms/
- AWS 서비스 전체에 대해 암호화 키를 생성/관리/제어
- 중앙집중형
- 사용 권한 부여 시 policy와 grant를 통해 권한 부여
- 이 부분이 AWS IAM과 연동
- AWS의 API 기반으로 동작하기 때문에 관련 기록은 CloudTrail에 적재
- KMS의 이용 방식은 server side 암호화, client side 암호화 두 가지 방식으로 나눌 수 있음
- AWS의 서비스에서 KMS를 사용하는 이유는 server side 암호화 목적
- 사용자 또는 애플리키에션에서 사용하는 것은 client side 암호화를 이용
- KMS의 키가 애플리케이션으로 전달되고, 클라이언트 측에서 해당 키를 통해 데이터를 암호화
- 목적에서 따라서 암호화 방식은 하나만 사용할 수도 있고, 둘 다 사용할 수도 있음
CMK (Customer Managed Key)
- 고객이 만드는 KMS Key
- KMS 내부에서 CMK를 이용하여 암호화/복호화 활용
봉투암호화
- 클라이언트 사이드에서 데이터 암호화 시에는 데이터 키를 사용하여 평문을 암호화 (이후 데이터키 삭제)
- 편지에 내용물을 담고, 주소/목적지를 적는 것처럼 데이터키로 암호화한 암호문과 함께 암호화된 데이터키를 함께 보관
- 이런 컨셉을 AWS에서는 봉투암호화로 표현
Encryption Context
- AWS KMS로 보호된 데이터와 연관시키고자 하는 부가정보(Key-value pair)
- 암호문과 별개로 암호문이 어떠한 유형의 문서인지, 어떤 내용을 포함하고 있는 메타데이터 (Condition 필드에 추가)
- 평문으로 저장됨
Policy와 Grant
- policy: CMK에 대한 정책
- iam에서는 identity에 정책(id based policy)을 부여할 수도 있고, resource에 정책(resource based policy)을 부여할 수도 있음
- KMS에서도 동일한 컨셉 적용, identity 기반으로 정책을 부여할 수도 있고, CMK에 대해서 정책을 부여할 수 있음
- grant: 일종의 토큰 개념
- CMK에 대한 사용 권한을 identity 또는 CMK로 얻는 것이 아니라 grant(token)을 통해 부여받을 수 있음
KMS 인프라는 내부적으로 HSM과 고가용성이 보장된 스토리지 영역이 존재
KMS를 사용하기 위해서는 CMK가 필요
- HSM을 통해 CMK를 생성 (= HSM이 KMS를 생성)
- CMK는 요청 시 HSM에 생성되고, 평문의 CMK가 HSM 영역의 메모리 상에 적재
HSM 내부적으로는 평문의 CMK를 암호화하기 위한 별도의 도메인 키 존재
- 암호화 목적은 메모리에 있는 평문의 CMK를 메모리 상에서 암호화하기 위함이 아닌 CMK를 사용하지 않는 환경에서는 메모리에 CMK가 내려와야 되는데 저장소에 저장해야 함, 이 때 암호화하여 저장하기 위해 도메인 키를 사용 (암호화된 CMK를 스토리지에 저장)
- 이러한 원리로 인해 KMS의 CMK는 외부로 나갈 때 평문 형태로 유출되지 않음
그렇다면 외부의 클라이언트는 KMS 서비스를 어떻게 사용하는가?
- 클라이언트는 API 요청(GenerateDataKey)을 하면 KMS에서 데이터 키를 전달받게 됨
- KMS 내부적으로 데이터 키를 생성하고, 평문의 데이터 키와 CMK로 암호화한 데이터 키를 클라이언트에게 쌍으로 전달
계층적인 구조
- KMS에서 발급해서 최종적으로 데이터를 암호화하는 키는 데이터 키
- 이 데이터 키의 보안을 위해 CMK가 사용
- 데이터 키는 CMK를 통해 암호화
- 이 CMK의 보호를 위해 도메인 키 사용
- CMK는 도메인 키를 통해 암호화
데이터 키를 요청하는 GenerateDataKey는 대칭키를 요청하는 API
데이터 암호화 시에는 데이터 키를 사용하여 암호화
- 더 이상 암호화할 데이터가 없거나 필요 없는 경우 데이터 키 삭제
이후 클라이언트는 데이터를 사용할 때 암호화된 데이터 키를 통해 데이터 복호화
이 경우에 데이터의 암호화는 클라이언트 사이드에서 진행
데이터 키를 발급받아서 클라이언트 사이드에서 암호화를 제공하기 하지만 KMS를 통해서 서버 사이드 암호화를 할 수 있음 (Encrypt API)
KMS를 통해 비대칭키도 발급받을 수 있음 (GenerateDataKeyPair)
- 전자서명 또는 암호화 활용 가능
대칭키의 경우 두 개의 키(평문의 데이터 키, 암호화된 데이터 키)가 반환됐던 반면, 비대칭키의 경우 세 개의 키(공개키, 비밀키, 암호화된 비밀키 by CMK)발급
요약
클라이언트 사이드에서 데이터 암호화 시에는 데이터 키를 사용하여 평문을 암호화
- 더 이상 암호화할 데이터가 없거나 필요 없는 경우 데이터 키 삭제
- 암호문으로 보관
이렇게 암호문으로 보관할 때 복호화 시에 사용할 암호화된 데이터키를 메타데이터로 함께 보관
- 편지에 내용물을 담고, 주소/목적지를 적는 것처럼 데이터키로 암호화한 암호문과 함께 암호화된 데이터키를 함께 보관
- 암호화에 사용한 데이터키는 삭제하기 때문
AWS KMS로 보호된 데이터와 연관시키고자 하는 부가정보(Key-value pair)
- 암호문과 별개로 암호문이 어떠한 유형의 문서인지, 어떤 내용을 포함하고 있는 메타데이터 (Condition 필드에 추가)
- 평문으로 저장
https://aws.amazon.com/ko/cloudhsm/
대체로 KMS와 기능은 유사하지만 CloudHSM이 필요한 경우가 존재
- 높은 수준의 인증이 요구되는 경우
- KMS는 FIPS 140-2 Level 2 인증
- 단일 테넌트(single tenant) 기반
- KMS는 멀티 테넌트(multi tenant) 기반
- 표준 기술 적용이 필요한 경우
- KMS는 AWS API 기반으로 동작하기 때문에 표준 기술을 지원하지 않는 경우 있음
- 그 외 KMS에서 지원하지 않는 기능이 필요한 경우
CloudHSM은 IaaS 같은 서비스로 생각
- AWS가 관리하는 영역보다 사용자가 관리하는 영역의 범위가 큼
백업의 경우 사용자가 직접 관리하지 않아도 자동 백업 지원
- 이를 통해 다른 리전에서 복원도 가능
- 다만 교차 리전간 동기화는 지원하지 않음 (리전 별로 독립적으로 운영)
KMS와 연계해서 사용도 가능
- KMS에서 발급한 CMK를 CloudHSM에 저장
https://aws.amazon.com/ko/kms/
https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/concepts.html
https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/iam-policies.html