Amazon Web Services 한국 블로그

AWS KMS 외부 키 스토어(XKS) 기능 출시

AWS Key Management Service(AWS KMS) 외부 키 스토어의 출시를 발표하게 되어 매우 기쁩니다. 규제 요구 사항이 있는 고객은 이제 온프레미스 또는 AWS 클라우드 외부에서 암호화 키를 저장하고 사용할 수 있습니다. 이 새로운 기능을 사용하면 AWS KMS 고객 관리형 키를 온프레미스나 원하는 위치에서 운영하는 하드웨어 보안 모듈(HSM)에 저장할 수 있습니다.

상위 수준에서 AWS KMS는 API 호출을 전달하여 HSM과 안전하게 통신합니다. 여러분의 키 요소는 HSM을 떠나지 않습니다. 이 솔루션을 사용하면 Amazon EBS, AWS Lambda, Amazon S3, Amazon DynamoDB 및 100개 이상의 서비스 등 AWS KMS 고객 관리 키를 지원하는 대다수의 AWS 서비스에 대한 외부 키로 데이터를 암호화할 수 있습니다. 기존 AWS 서비스의 구성 파라미터 또는 코드를 변경할 필요가 없습니다.

이를 통해 암호화 키를 AWS 데이터 센터 외부에 저장하고 사용해야 하는 규제 대상 워크로드의 일부에 대한 사용 사례를 차단 해제할 수 있습니다. 하지만 이는 클라우드 기반 인프라를 운영하는 방식의 주요 변화이자 공동 책임 모델의 중요한 변화입니다. 당사는 소수의 고객만이 이 기능을 사용할 것으로 예상합니다. 보호 데이터에 대한 가용성, 성능 및 지연 시간이 짧은 작업에 대한 추가적인 운영 부담과 더 큰 위험은 대부분의 경우 AWS KMS External Key Store가 제공하는 보안 이점을 넘어설 것입니다.

자세히 설명해 드리겠습니다.

키 관리 및 암호화에 대한 간략한 요약
AWS 서비스가 저장 데이터를 암호화하도록 구성된 경우 서비스는 AWS KMS에 고유한 암호화 키를 요청합니다. 이를 데이터 암호화 키라고 합니다. 또한 해당 서비스는 데이터 암호화 키를 보호하기 위해 루트 키라고도 하는 특정 KMS 고객 관리 키로 해당 키를 암호화하도록 AWS KMS에 요청합니다. 암호화된 데이터 키는 보호하는 데이터와 함께 안전하게 저장될 수 있습니다. 이 패턴을 봉투 암호화라고 합니다. 암호화한 데이터와 이러한 데이터를 암호화하는 데 사용한 암호화한 키가 모두 들어 있는 봉투를 상상해 보십시오.

하지만 루트 키는 어떻게 보호할까요? 루트 키로는 암호화된 모든 데이터 키를 해독할 수 있으므로 이를 반드시 보호해야 합니다.

루트 키 요소는 비밀키을 저장하도록 설계한 하드웨어인 하드웨어 보안 모듈에 안전하게 생성 및 저장됩니다. 변조 방지 기능을 갖추고 있으며 키 요소가 보안 하드웨어에 일반 텍스트로 남지 않도록 설계하였습니다. AWS KMS는 NIST 140-2 암호화 모듈 인증 프로그램에 따라 인증된 HSM을 사용합니다.

데이터 분류에 연결된 루트 키를 생성하거나, 고유한 루트 키를 생성하여 다양한 AWS 서비스를 보호하거나, 프로젝트 태그별로, 또는 각 데이터 소유자와 연결되도록 선택할 수 있고, 각 루트 키는 각 AWS 리전마다 고유합니다.

AWS KMS는 사용자가 키를 직접 생성 및 관리할 때 루트 키를 고객 관리형 키라고 부릅니다. Amazon Elastic Block Store(Amazon EBS), Amazon Simple Storage Service(S3), Amazon 관계형 데이터베이스(RDS) 또는 Amazon DynamoDB 등과 같이 데이터를 암호화하는 AWS 서비스를 대신해서 생성된는 키를 AWS 관리형 키라고 부릅니다. 간단하게 KMS 키라고 부르겠습니다. 이러한 루트 키는 보안 HSM 환경을 절대 벗어나지 않습니다. 모든 KMS 암호화 및 암호 해독 작업은 HSM의 보안 환경에서 이루어집니다.

XKS 프록시 솔루션
AWS KMS 외부 키 스토어(XKS)를 구성할 때에는 KMS 키 계층 구조를 새로운 외부 신뢰 루트로 대체합니다. 이제 루트 키는 모두 사용자가 제공 및 운영하는 HSM 내에서 생성 및 저장됩니다. AWS KMS는 데이터 키를 암호화 또는 해독해야 하는 경우 해당 요청을 공급업체별 HSM으로 전달합니다.

외부 HSM과의 모든 AWS KMS 상호 작용은 사용자가 제공 및 관리하는 프록시인 외부 키 스토어 프록시(XKS 프록시)가 조정합니다. 프록시는 일반 AWS KMS 요청을 공급업체별 HSM이 이해할 수 있는 형식으로 변환합니다.

XKS가 통신하는 HSM은 AWS 데이터 센터에 위치하지 않습니다.

XKS 아키텍처

고객에게 광범위한 외부 키 관리자 옵션을 제공하기 위해 AWS KMS는 Atos, Entrust, Fortanix, HashiCorp, Salesforce, ThalesT-Systems를 비롯한 여러 HSM, 키 관리 및 통합 서비스 공급자의 피드백을 받아 XKS 사양을 개발했습니다. 가용성, 가격 및 이러한 공급업체의 솔루션을 포함하는 XKS 사용 방법에 대한 자세한 내용은 해당 공급업체에 직접 문의하십시오.

또한 SoftHSM 또는 PKCS #11 인터페이스를 지원하는 모든 HSM과 함께 사용할 수 있는 XKS 프록시의 레퍼런스 구현도 제공할 예정입니다. 이 레퍼런스 구현 XKS 프록시는 컨테이너로 실행할 수 있고 Rust로 빌드되며 앞으로 몇 주 안에 GitHub를 통해 사용할 수 있습니다.

XKS 프록시 및 HSM 설정을 완료했으면 KMS에서 해당 외부 키 스토어 리소스를 생성할 수 있습니다. HSM에서 키를 생성하고 이러한 키를 KMS의 외부 키 스토어 리소스에 매핑합니다. 그런 다음 이러한 키를 사용하여 고객 키를 지원하는 AWS 서비스나 자체 애플리케이션에서 데이터를 암호화할 수 있습니다.

AWS KMS에서 XKS 프록시로 보내는 각 요청에는 KMS API를 호출한 AWS 보안 주체 및 KMS 키 ARN 등의 메타데이터가 포함됩니다. 이를 통해 AWS 계정의 IAM 정책에서 이미 제공한 항목 외에도 XKS 프록시 수준에서 추가 권한 부여 제어 계층을 생성할 수 있습니다.

XKS 프록시는 사실상 사용자가 제어하는 킬 스위치입니다. XKS 프록시를 끄면 XKS 키를 사용하는 모든 새로운 암호화 및 암호 해독 작업이 더 이상 작동하지 않습니다. 리소스 중 하나에 대한 데이터 키를 메모리에 이미 프로비저닝한 AWS 서비스는 리소스를 비활성화하거나 서비스 키 캐시가 만료될 때까지 계속 작동합니다. 예를 들어 Amazon S3는 버킷 키가 활성화된 경우 몇 분 동안 데이터 키를 캐싱합니다.

공동 책임의 변화
표준 클라우드 운영 절차에 따라 AWS는 클라우드 인프라를 운영 상태로 유지할 책임이 있습니다. 여기에는 시스템 패치 적용, 네트워크 모니터링, 고가용성을 위한 시스템 설계 등을 포함하며 이에 국한되지 않습니다.

XKS를 사용하기로 결정하면 공동 책임 모델에 근본적인 변화가 일어납니다. 이 모델에서 사용자는 XKS 프록시와 HSM을 작동 상태로 유지할 책임이 있습니다. 안전하고 가용성이 높아야 할 뿐만 아니라 예상되는 AWS KMS 요청 수를 수용할 수 있는 크기여야 합니다. 이는 물리적 시설, 전원 공급 장치, 냉각 시스템, 네트워크, 서버, 운영 체제 등 관련된 모든 구성 요소에 적용됩니다.

워크로드에 따라 클라우드의 저장 데이터를 암호화해야 하는 서비스를 운영하려면 AWS KMS 운영이 중요할 수 있습니다. 정상 운영을 위해 AWS KMS를 사용하는 일반적인 서비스로는 Amazon Elastic Block Store(Amazon EBS), Lambda, Amazon S3, Amazon RDS, DynamoDB 등이 있습니다. 즉, 사용자가 담당하는 인프라 일부를 사용할 수 없거나 지연 시간이 길면(일반적으로 250ms 이상) AWS KMS가 작동하지 않아 다른 AWS 서비스에 대한 요청이 연쇄적으로 실패하게 됩니다. EC2 인스턴스 시작, Lambda 함수 호출, S3에서 객체 저장 또는 검색, RDS 또는 DynamoDB 데이터베이스 또는 관리하는 인프라에 저장된 AWS KMS XKS 키를 사용하는 기타 서비스에 연결할 수 없습니다.

XKS와 관련된 제품 관리자 중 한 명이 이 블로그 게시물을 준비하면서 저에게 말했듯이, “여러분은 매우 연약한 길을 통해 산소로 향하는 터널을 달리고 있습니다.”

AWS 데이터 센터 외부에서 암호화 키를 유지해야 하는 규제 또는 규정 준수가 필요한 경우에만 이 기능을 사용하기를 권장합니다. 가장 중요한 워크로드를 지원하는 루트 키에 대해서만 XKS를 활성화하십시오. 모든 데이터 분류 범주가 루트 키의 외부 저장소를 필요로 하지는 않습니다. 규제 요구 사항을 충족할 수 있도록 XKS로 보호하는 데이터 세트를 최소한으로 유지하고, 나머지는 완전히 제어할 수 있는 AWS KMS 고객 관리 키를 계속 사용하십시오.

외부 키 스토리지가 규정 준수 요구 사항이 아닌 일부 고객도 과거에 이 기능을 요청했지만, XKS와 같은 솔루션의 보안 이점이 운영 비용보다 크지 않다는 것을 깨닫고 난 이후 클라우드 기반 키 스토리지 및 사용에 대한 기존 AWS KMS 옵션 중 하나를 수락하게 되었습니다.

어떤 변화가 있고 무엇이 그대로 유지되나요?
변경 사항을 요약해 보았습니다.

무엇이 표준 AWS KMS 키와 동일
한가요
무엇이 변화하나요

지원하는 AWS KMS API와 키 식별자(ARN) 는 동일합니다. 고객 관리형 키를 지원하는 AWS 서비스는 XKS와 함께 작동합니다.

AWS 측에서 액세스를 보호하고 액세스를 모니터링하는 방법은 변하지 않았습니다. XKS는 동일한 IAM 정책과 동일한 키 정책을 사용합니다. API 호출은 AWS CloudTrail에 기록되며, AWS CloudWatch는 사용량 지표를 가지고 있습니다.

요금은 다른 AWS KMS 키 및 API 작업과 동일합니다.

XKS는 제공하는 HSM에서 관리하는 비대칭 키 또는 HMAC 키를 지원하지 않습니다.

이제 사용자가 암호화 키 작업의 가용성, 내구성, 성능 및 지연 시간 한계를 관리해야 합니다.

XKS 프록시 수준에서 또 다른 인증, 감사 및 모니터링 계층을 구현할 수 있습니다. XKS는 사용자의 네트워크 안에 있습니다.

KMS 가격은 동일하게 유지되지만 HSM을 구매하고 XKS 관련 인프라를 운영 상태로 유지하려면 비용이 크게 증가할 수 있습니다.

공개 사양
엄격하게 규제되는 워크로드의 경우 개방형 상호 운용성 사양으로 XKS를 개발하고 있습니다. 앞서 언급한 주요 공급업체와 협력했을 뿐만 아니라 다음 자료를 포함하는 GitHub 저장소도 개설했습니다.

  • XKS 프록시 API 사양입니다. 여기서는 KMS가 XKS 프록시에 전송하는 일반 요청의 형식과 예상 응답을 설명합니다. 모든 HSM 공급업체는 이 사양을 사용하여 해당 HSM용 XKS 프록시를 생성할 수 있습니다.
  • 사양을 구현하는 XKS 프록시의 참조 구현입니다. HSM 공급업체는 이 코드를 조정하여 해당 HSM용 프록시를 생성할 수 있습니다.
  • XKS 프록시가 XKS 프록시 API 사양의 요구 사항을 준수하는지 여부를 확인하기 위해 사용할 수 있는 XKS 프록시 테스트 클라이언트입니다.

SalesForce와 같은 다른 공급업체는 고객이 자신의 키 관리 솔루션을 선택하고 이를 SalesForce를 포함하여 선택한 솔루션에 연결할 수 있는 자체 XKS 솔루션을 발표했습니다.

요금 및 가용성
외부 키 스토어는 AWS KMS에 추가 비용 없이 제공됩니다. AWS KMS는 키 구성 요소가 KMS, CloudHSM 또는 자체 온프레미스 HSM에 저장된 위치와 관계없이 매월 루트 키당 1USD를 청구합니다.

현재 AWS KMS XKS를 사용할 수 있는 지역의 전체 목록을 보려면 기술 설명서를 참조하십시오.

XKS가 규제 요구 사항을 충족하는 데 도움이 될 것이라고 생각하신다면 기술 문서와 XKS FAQ를 참조하십시오.

— seb