[AWS] aws 강의 섹션 30 (KMS, SSM Parameter Store, CloudHSM, Nitro Enclaves)

Encryption i flight (TLS / SSL)

• 암호화를 해서 전송하고, 수신측에서 받은 후 디코딩을 하는 방식
• 데이터를 암호화 하기 위해 TLS 인증서가 사용된다 (HTTPS)
• 중간자 공격을 방어하기 위해 암호화를 통해 데이터를 전송한다.
• 전송을 목표로하는 대상 서버만이 데이터를 해독할 수 있도록 한다.

 

Server-side encryption

• 서버에서 수신한 데이터를 암호화 시켜 저장하는 것이다.
• 클라이언트에게 송신하기 전 디코드를 진행하고 전송한다.
• 보통 키를 사용해 암호화와 디코딩 작업이 일어난다.
  • 서버는 해당 키에 접근이 가능해야한다.

 

Client-side encryption

• 데이터가 클라이언트 측에서 암호화, 해독이 이뤄진다.
• 서버는 이 데이터를 해독할 수 없어야 한다.
• 마찬가지로 키를 사용해 암호화한다.
  • 오로지 암호화된 데이터만 전송을 하며, 서버에서도 암호화된 데이터를 저장한다.
  • 디코딩은 클라이언트 측에서만 가능하다.

 

AWS KMS (Key Management Service)

• 키 관리 서비스다.
• 대부분의 AWS 암호화는 KMS를 사용해서 일어난다.
• KMS는 권한 부여를 위해 IAM과 완전히 통합되어 있으며(IAM에서 특정 KMS 키에 접근 가능한 권한을 조정 가능하다.)
  KMS로 암호화 하면, 데이터에 대한 액세스를 아주 쉽게 제어할 수 있다.
• Cloud Trail을 활용해 키를 사용하기 위해 호출한 모든 API호출을 트래킹할 수 있다.
• EBS, S3, RDS, SSM 거의 모든 서비스와 통합해서 암호화가 가능하다.
• KMS는 API 호출을 통해 사용할 수도 있고, AWS CLI, SDK를 통해서도 사용이 가능하다.

KMS Keys Types

• 대칭키 (AES-256 keys)
  • 한 개의 키를 사용해 암호화 복호화를 진행
  • KMS와 통합된 모든 서비스는 대칭 키를 사용한다.
  • 기본적으로 KMS 대칭 키를 사용하면 절대 키 자체에 액세스가 불가능하다.
  • API 호출을 통해 사용해야 한다.
• 비대칭 키 (RSA & ECC key pairs)
  • 데이터 암호화에 사용되는 공개키, 복호화에 사용되는 개인키가 존재한다.
  • 공개키는 KMS에서 다운로드할 수 있지만, 개인키에는 액세스가 불가능하다.
  • API 호출을 통해서만 개인키에 액세스 가능하다.
  • 비대칭 유형의 키는 KMS키에 액세스할 수 없거나, 액세스 권한이 없는 사용자가
    클라우드 외부에서 암호화를 수행하려는 경우에 사용되며, 
    공개 키를 사용하여 암호화한 데이터는 오로지 개인키를 사용해서만 복호화가 가능하다.

AWS KMS (Key Management Service)

• AWS Owned Keys (free): SSE-S3, SSE-SQS, SSE-DDB (default key)
  • 무료이며, S3, SQS, DDB등을 사용할 때 사용된다.
  • AWS에서 완전 관리하는 키이기 때문에 존재를 알 수도 없고 관리할 필요도 없다.
• AWS Managed Key: free (aws/service-name, example: aws/rds or aws/ebs)
  • 마찬가지로 무료이며, aws/ 뒤에 서비스명이 붙는 형태라서 어떤 서비스를 사용하는 알 수 있다.
  • 할당된 서비스에만 사용 가능하다.
  • AWS 관리하는 키이지만 키의 존재를 확인할 수 있고, 어떤 서비스에서 사용하는 지도 알 수 있다는 차이점이 있다.
• Customer managed keys
  • created in KMS: $1 / month
  • API 호출 10000회당 0.03$
  • 사용자가 완전히 제어하는 키다.
• 키 교체 주기
  • AWS managed key: 의 경우 1년마다 자동으로 교체된다.
  • Customer managed key: 1년마다 교체 옵션을 활성화 시켜야한다.
    • 외부에서 가져온 키를 사용할 땐, 수동으로만 교체 가능하며 별칭을 사용해야한다.

Copying snapshots across regions

•  KMS 키는 리전별로 범위가 지정된다.
• 즉, 특정 리전에서 KMS 키로 암호화된 EBS 볼륨인 eu-west-2를 다른 리전으로 복사하려면 몇 가지 단계를 거쳐야한다.
  • 먼저 EBS 볼륨의 스냅샷을 생성해야 한다. 암호화된 볼륨에서 스냅샷을 생성하면
    해당 스냡샷 자체도 동일한 KMS 키로 암호화 되어 있다.
  • 다른 지역으로 이동시킬 땐 다른 KMS 키로 재 암호화 시켜야한다.
    • 내부적으로 복호화 이후 새 키로 암호화 시킨다고 함
  • 동일한 지역에 같은 KMS 키는 존재할 수 없기 때문이다.

KMS key Policies

• 키에 대한 액세스를 컨트롤 하기 위한 정책이다.
• S3 정책과 비슷하지만, 키에 대한 KMS 키 정책이 없으면 아무도 해당 키에 접근할 수 없다.
  • 기본 키 정책
    • 특정한 사용자 지정 KMS키 정책이 제공되지 않는 경우에 생성된다.
    • 계정의 모든 사람이 키에 접근할 수 있도록 허용한다.
  • 사용자 지정 키 정책
    • 키에 접근할 수 있는 사용자, 역할을 정의하고 키를 관리할 수 있는 사람을 정의할 수 있다.
    • 다른 계정 사용자에게 키 접근을 허용시키려는 경우에 특히 유용하다.
    • 이 정책은 다른 계정에 스냅샷을 공유할 때 유용하다.
    • 사용자 정책으로 키를 다른 계정에 허용시키고,
      해당 키로 볼륨을 암호화 한다. 암호화된 스냅샷을 넘기고
      받은 사람은 허용된 키로 복호화 시키면 된다.

API - Encryption, Decryption

• 우선 암호화 할 데이터를 API 호출을 통해 전송한다.
• IAM을 통해 KMS에서 키를 사용할 권한이 있는지 확인하고 사용 권한이 있다면 암호화 하여 반환한다.
• 반환된 데이터는 복호화 API를 통해 복호화한다.
• 복호화에 사용될 키는 KMS에서 자동으로 매칭한다.
• 이후 똑같이 IAM 권한을 확인하고, 복호화 권한이 있다면, 평문을 반환한다.
• 크기 제한은 4KB이다.

Envelope Encryption

• 4KB이상을 암호화 하려면 봉투를 사용해서 암호화 해야한다.
• GenerateDataKey API를 호출하면 된다.

• 처음 과정은 동일하다. 키 사용 권한이 있는지 확인하고, 권한이 있다면 평문 DEK와 암호화된 DEK를 반환한다.
  • 평문 DEK는 데이터 암호화에 사용되고, 암호화된 DEK는 복호화에 사용된다.
• 이제 암호화된 데이터와 암호화된 DEK를 봉투 안에 안전하게 저장한다.

• 복호화 과정은 다음과 같다.
• 암호화된 DEK를 KMS에 Decryp API를 호출해서 전송한다.
• 권한을 확인하고, 권한이 있다면 평문 DEK를 반환한다.
• 클라이언트 측에서 평문 DEK를 통해 복호화를 실시한다.

봉투 암호화 기술의 목적은 KMS를 키 관리에만 사용하고, 암호화, 복호화를 클라이언트 측에서 실시한다는 것이다.

Encryption SDK

• SDK 또는 CLI를 통해 암호화를 사용할 수 있다.
• SDK 에서 자바, 파이썬, C, 자바스크립트 등의 언어를 사용할 수 있다.
• 암호화 SDK에 데이터 키 캐싱이라는 기능이 있다.
  • 데이터 키를 암호화 API가 호출될 때마다 새로 생성하는 것이 아닌, 재사용하는 방식을 의미한다.
  • 이를 통해, KMS 호출을 줄이고 비용을 절감할 수 있다.
  • 그러나 보안은 조금 떨어진다.
  • LocalCryptoMAterialsCache를 통해 최대 유지 시간, 최대 암호화 바이트, 최대 암호화 될 메시지 수(해당 수를 다 채우면 다음 키로 넘어간다.) 등을 정할 수 있다.

대칭 키 API 요약

• encrypt: KMS에 4 키로바이트 이하의 데이터를 암호화하는데 사용된다.
• GenerateDatakey: unique한 대칭 키를 생성해서 반환한다. (DEK)
  • 평문의 DEK와 암호화된 DEK를 반환한다.
• GenerateDataKeyWithoutPlaintext: 우선 암호화된 DEK를 먼저 받고 나중에 사용하기 위해 저장해둔다.
  • 나중에 사용할 때는 암호화를 한 번 거쳐서 사용한다.
• decrpyt: 4kb 이하의 데이터를 해독할 때 사용한다.
• GenerateRandom: 랜덤한 숫자의 바이트를 반환한다.

KMS Request Quotas

• KMS는 요청 할당량이 정해져 있다. 할당량을 초과하게 되면 ThrottlingExcdeption이 발생한다.
• 이럴 땐 첫 번째로, 지수 백오프 전략을 시도한다.
• 각 암호화 작업마다(암호화든 복호화든) 할당량이 공유된다.
• 요청을 보내는 모든 서비스들이 같은 할당량을 소모한다는 의미이다.
• 다른 계정간, 다른 리전간도 모두 할당량이 공유된다.
• 두 번째로, DEK에서 캐싱을 사용하면 API호출의 수를 줄일 수 있다.
• 마지막으로, 요청 할당량을 높이는 것이다.
  • API 호출이나 AWS support를 통해 증가시킬 수 있다.
• 할당량은 리전마다 다르다.

S3 버킷 암호화 with SSE-KMS

• SSE-KMS 신기능을 사용하면 S3에서 호출하는 KMS API 호출의 양을 99% 감소시킬 수 있다.
• 이 말은 비용 또한 99% 절감을 할 수 있다는 것이다.

• KMS 키를 사용해 S3 버킷 키를 생성한다.
• 이제 버킷 키를 통해 데이터 키를 생성하고, 해당 데이터 키(DEK)를 사용해 객체를 암호화 한다.
• 이를 통해 KMS 호출의 수를 줄이는 것이다.

Key Policy

• 키 정책은 KMS 키에 접근할 수 있는 사용자를 정의하는 데 사용된다.
  • 기본 값은 계정에 속한 모든 사용자가 접근이 가능한 것이다.
  • 명시적으로 특정 사용자에게만 권한을 부여할 수도 있다.
  • 어떤 작업을 허용할 것인지도 설정할 수 있다.

Principal OPtions in IAM Policies

• 이렇게 principal을 설정하는데 맨 뒤에 root를 붙이면 해당 계정 모든 사용자에게 보안 권한이 부여된다.

CloudHSM

• 암호화 전용 하드웨어다. Hardware Security Module의 줄임말이다.
• aws가 아닌 본인이 직접 암호화 키를 전부 관리한다.
• AWS 클라우드 내에 위치하며, FIPS 104-2 레벨 3규정을 준수하여 변조 방지 기능을 갖추고 있다.
  • 누구든지 HSM에 접근하려고 하면 장치는 중지되고 차단된다.
• 대칭 및 비대칭 키를 모두 지원한다.
• 프리티어는 없으며, 사용하기 위해선 클라이언트 소프트웨어를 사용해야 한다.
• RedShift는 HSM의 데이터 베이스 암호화를 도와준다.
• SSE-C 유형의 암호화를 사용하려는 경우 굉장히 유용한 옵션이다.

AWS가 하드웨어를 관리하고, 서비스는 자체적으로 사용할 수 있다.

IAM 에서는 CRUD에 대한 권한을 다루고, 소프트웨어에서는 키와 유저를 관리한다.

KMS는 IAM에서 모든 것을 관리하는 데, 여기서 차이점이 생긴다.

 

CloudHSM - High Availabiility

• 고가용성을 제공하며, 여러 AZ에 분산되어 있어 HA이다.
• 클라이언트는 둘 중 하나의 HSM에 연결된다.

CloudHSM - intergration with AWS Service

• AWS 서비스 암호화 내에서 CloudHSM을 투명하게 활용하려면 어떻게 해야할까?

• 우선 커스텀 키를 HSM에 저장하고 KMS와 연결을 맺는다.
• 이후 KMS를 활용해 각종 정보를 암호화 시킨다.
• 암호화와 복호화는 모두 HSM에 저장된 키를 활용해서 이뤄진다.
• 이 방식은 CloudTrail을 통한 API 호출을 모두 트래킹 할 수 있다는 것에 존재한다.

SSM Parameter Store

• configuration 및 보안 암호를 안전하게 보관하기 위한 저장소다.
• 구성 데이터를 안전하게 저장하고 싶다면, KMS를 사용해 암호화하면 된다.
• 서버리스 서비스이며, 확장성 및 내구성을 갖고 있고 SDK를 사용하기도 쉽다.
• 버전 관리도 가능하다.
• IAM을 통해 보안을 적용할 수 있으며,
• 이벤트 브릿지로 알림을 받을 수도 있다.
• CloudFormation을 완벽히 지원하기 때문에, 매개변수에 저장된 데이터를 CloudFormation 스택의 입력 매개변수로 사용할 수 있다.

• 플레인 텍스트 구성을 전송한다.
• IAM 권한을 확인하고 저장한다.
• 이번엔 암호화 저장 요청을 보낸다.
• 마찬가지로 IAM 권한을 확인하고 KMS를 활용해 암호화 하여 저장한다.

SSM Parameter Store Hierarchy

• 파라미터는 파라미터 저장소에 계층 구조로 저장된다.

• 이렇게 하면 IAM 정책에서 애플리케이션에 부여할 액세스 권한을 정의할 때
  • 구역 전체를 지정하거나 특정 경로를 지정할 수 있다.

만약 파라미터 저장소에서 AWS 시크릿 매니저(중요한 비밀 변수)를 가져오고 싶다면,

이런 식으로 가져올 수 있다.

 

• 다음과 같이 람다 함수에 접근 권한을 허용해주고, 파라미터 스토어에 접근해 주요 변수를 가져올 수 있다.

SSM Parameter Store Tier

Parameter Policies (for advanced parameters)

• 이 정책을 사용해 파라미터의 지속 시간, 즉 만료 날짜를 정할 수 있다.
• 사용자가 암호 등의 민감 데이터를 업데이트 하거나 삭제하도록 강제할 수 있다.
• 여러 정책을 동시에 할당할 수도 있다.

AWS Secrets Manager

• 이것도 비밀 정보를 저장하기 위한 서비스다.
• X일 마다 저장한 정보를 강제로 바꾸도록 할 수 있다는 차이점이 있다.
• 다른 AWS 서비스와 아주 잘 통합된다. (MySQL, PostgreSQL, Aurora)
• KMS를 사용해서 저장하는 비밀 정보를 암호화할 수 있다.
• 시험에서 secret과 RDS 통합 같은 것이 나오면 Secrets Manager를 떠올려야한다.

AWS Secrets Manager - Multi Region Secrets

• 여러 리전에 걸쳐 secret을 복제할 수 있다.
• 다른 리전은 기존 리전과 동기화 하여 정보를 읽을 수 있다.

• 이렇게 함으로서 얻을 수 있는 장점은,
  • 재해 복구
  • 다중 지역의 DB등과 원활한 통합 등등이 있다.

SSM Parameter Store VS Secrets Manager

• secrets Manager
  • 시크릿 매니저가 더 비싸다
  • 람다 함수를 사용해서 암호의 변경을 자동화할 수 있다.
  • 저장한 암호에 KMS 암호화는 필수이며
  • 클라우드 포메이션과 통합이 가능하다.
• parameter Store
  • 조금 더 다용도로 사용이 가능하며, 비용이 더 저렴하다.
  • 단순 API를 지니고 있고, 암호의 변경은 없다.
    • 그러나 CloudWatch 이벤트로 변경시킬 수 있다.
  • 파라미터 스토어에는 암호, 혹은 파라미터만도 저장이 가능하므로 KMS 암호화는 선택사항이다.
  • 클라우드 포메이션과 통합이 가능하다.
  • SSM 파라미터 스토어 API를 통해 암호 폴링이 가능하다.

• 이 예시를 보면, 내장된 람다함수 기능을 통해 자동으로 RDS암호 변경이 가능하다.
• 파라미터 스토어 같은 경우엔 직접 람다함수를 만들어 RDS 암호를 변경하고, 파라미터 스토어에 저장된 값도 변경해야 한다.

CloudWatch Logs - Encryption

• KMS 키를 사용해 CloudWatch 로그를 암호화할 수 있다.
• 암호화는 로그 그룹 레벨에서 일어난다.
• 기존 CMK를 기존 로그 그룹과 연결할 수도 있고, 새 로그 그룹과 연결할 수도 있다.
• 클라우드 워치 콘솔을 사용해서는 CMK와 로그 그룹을 연결할 수 없으며, 
  Cloud Watch 로그 API를 사용해야한다.
  • associate-kms-key: kms 키를 기존의 로그 그룹과 연결하는 명령이다.
  • create-log-group: 아직 존재하지 않는 로그 그룹을 생성해 KMS키와 연결하는 명령이다.

CodeBuild Security

• codeBuild는 VPC 외부에 있지만, VPC 내부 리소스로 액세스를 위해 VPC 내부에서 실행할 수도 있다.
• 코드 빌드 내에 암호를 저장하는 방법은 두 가지가 있다.
  • 파라미터 스토어에 저장한 값을 참조하는 방식과
  • 환경 변수가 secrets manager의 암호를 참조할 수도 있다.

Nitro Enclaves

• 클라우드에서 아주 민감한 데이터를 처리해야 할 때가 있다.
  • 민감 데이터랑 개인 식별 번호, 신용카드 데이터 등등,,
• 예전에는 민감 데이터를 처리하기 위해 완전히 독립된 VPC를 구성하고 그 내부에 처리를 했다.
• 그러나 이 서비스는 완전 독립형 가상 머신으로 외부와 완전히 차단되어 있기 때문에 별도의 VPC를 구축하고 할 필요가 없다.
  • 컨테이너도 없고 저장소도 없고, SSH 접근도 불가능하다.
  • 민감 데이터 처리에 최적화된 곳이다.
• 암호화 증명을 사용해 인증받은 코드만 엔클레이브에서 실행되도록 할 수도 있다.
• KMS를 사용해 엔클레이브만 민감 데이터에 접근할 수 있도록 설정할 수도 있다.

• 우선 나이트로 기반의 EC2 인스턴스를 EnlcaveOption: true로 해서 실행한다.
• nitro cli를 활용해서 인클레이브 이미지를 생성한다.
• 해당 이미지를 기반으로 EC2 인스턴스 내부에 인클레이브를 생성한다.
• 인클레이브는 가상 머신과 분리된 독립된 환경에 있다.
• EC2 호스트에서 니트로 하이퍼 바이저를 사용하면 인클레이브와 암호화된 통신을 할 수 있다.
• EC2 인스턴스가 엔클레이브로부터 분리되고 보안 로컬 채널로 통신만 한다.
• 다른 모든 EC2 인스턴스와 분리된다.