AWS Key Management Service FAQ

AWS KMS는 관리자가 정의한 사용 및 관리 정책을 시행합니다. 관리자 계정 또는 다른 계정의 IAM 사용자 및 역할이 키를 사용하고 관리하도록 선택할 수 있습니다.

AWS KMS는 AWS 직원을 비롯하여 누구도 서비스에서 일반 텍스트 KMS 키를 검색하지 못하도록 설계되었습니다. AWS KMS는 FIPS 140-2에 따라 검증되었거나 검증 과정에 있는 하드웨어 보안 모듈(HSM)을 사용하여 키의 기밀성과 무결성을 보호합니다. 일반 텍스트 KMS 키는 HSM을 절대로 벗어나지 않으며, 디스크에 작성되는 일도 없습니다. 또한, 요청한 암호화 작업을 수행하는 데 필요할 때만 HSM 휘발성 메모리에서 사용됩니다. 서비스 호스트에 있는 소프트웨어 및 AWS KMS HSM 펌웨어에 대한 업데이트는 Amazon 내 독립적인 그룹 및 FIPS 140-2를 준수하는 NIST 공인 실습에서 감사하고 검토하는 다자간 액세스 제어를 통해 제어됩니다.

이러한 보안 제어에 대한 자세한 내용은 AWS KMS 암호화 세부 정보 기술 문서에서 확인할 수 있습니다. 또한 AWS KMS HSM이 FIPS 140-2 보안 요구 사항을 어떻게 충족하는지에 대한 자세한 내용은 AWS KMS HSM에 대한 FIPS 140-2 인증서 및 관련 보안 정책을 검토하세요. 또한 KMS 키를 보호하기 위해 서비스에서 사용하는 보안 제어에 대해 자세히 알아보려면 AWS Artifact에서 System and Organization Controls(SOC) 보고서 사본을 다운로드하면 됩니다.

아무것도 하지 않으셔도 됩니다. 모든 AWS KMS 키는 생성 날짜 또는 오리진과 관계없이 FIPS 140-2 보안 수준 3에 따라 인증된 HSM을 사용하여 자동으로 보호됩니다.

FIPS 140-2 보안 수준 3 인증 HSM은 AWS KMS가 제공되는 모든 AWS 리전에 배포됩니다.
참고: 규정에 따라 중국 리전의 AWS KMS는 NIST FIPS HSM을 사용할 수 없으며 대신 중국 국무상업암호관리국(OSCCA) 인증 HSM을 사용합니다.

AWS KMS은 2계층 서비스입니다. API 엔드포인트는 완전 순방향 비밀성(PFS)을 지원하는 TLS ciphersuite만 사용하여 HTTPS 연결을 통해 클라이언트 요청을 수신합니다. 이러한 API 엔드포인트에서는 암호화 작업에 대한 요청을 AWS KMS HSM으로, 혹은 KMS 사용자 지정 키 스토어 기능을 사용하는 경우에는 AWS CloudHSM 클러스터로 전달하기 전에 요청을 인증하고 권한을 부여합니다.

고유한 리전별 FIPS 140-2 인증 HTTPS 엔드포인트에 연결하도록 애플리케이션을 구성합니다. AWS KMS FIPS 140-2 인증 HTTPS 엔드포인트는 OpenSSL FIPS Object Module에서 제공합니다. 여기에서 OpenSSL 모듈의 보안 정책을 검토할 수 있습니다. FIPS 140-2 인증 API 엔드포인트는 AWS KMS가 제공되는 모든 상용 리전에서 사용할 수 있습니다.

예. AWS KMS는 암호화 및 키 관리 요구 사항(주로 PCI DSS 3.2.1 섹션 3.5 및 3.6에서 참조됨)을 충족하는 기능 및 보안 제어를 제공하는 것으로 검증되었습니다.

AWS 내 PCI DSS 준수 서비스에 대한 자세한 내용은 PCI DSS FAQ에서 확인할 수 있습니다.

AWS KMS가 데이터 키를 생성한 후 자체 애플리케이션에서 사용할 목적으로 반환하도록 요청할 수 있습니다. 데이터 키는 AWS KMS에 정의한 루트 키를 사용하여 암호화되므로 암호화된 데이터 키를 암호화된 데이터와 함께 안전하게 저장할 수 있습니다. 암호화된 데이터 키(및 소스 데이터)는 원래 루트 키를 사용해 암호화된 데이터 키를 복호화할 권한이 있는 사용자만 복호화할 수 있습니다.

아니요. AWS KMS 키는 서비스 내에서만 생성 및 사용되어 보안을 보장하고, 정책이 일관되게 시행되도록 하며, 키 사용에 대한 중앙 집중식 로그를 제공합니다.

AWS KMS에서 생성한 단일 리전 KMS 키는 생성된 리전에서만 저장 및 사용됩니다. AWS KMS 다중 리전 키를 사용하면 다중 리전 프라이머리 키를 동일한 AWS 파티션 내의 여러 리전으로 복제하도록 선택할 수 있습니다.

AWS CloudTrail의 로그에는 관리 요청(예: 생성, 교체, 비활성화, 정책 편집)과 암호화 요청(예: 암호화/복호화)을 비롯하여 모든 AWS KMS API 요청이 표시됩니다. 이러한 로그를 보려면 계정에서 CloudTrail을 활성화하세요.

CloudHSM은 키를 저장 및 사용할 수 있는 Amazon Virtual Private Cloud(VPC)에서 검증된 단일 테넌트 HSM 클러스터를 제공합니다. AWS와 별개인 인증 메커니즘을 사용하여 키가 사용되는 방식을 배타적으로 제어할 수 있습니다. Amazon EC2에서 실행되는 애플리케이션과 상호 작용하는 것과 비슷한 방식으로 CloudHSM 클러스터의 키와 상호 작용합니다. CloudHSM을 사용하여 디지털 권한 관리(DRM), 퍼블릭 키 인프라(PKI), 문서 서명, 그리고 PKCS#11, Java JCE 또는 Microsoft CNG 인터페이스를 사용한 암호화 기능 등 다양한 사용 사례를 지원할 수 있습니다.
 

AWS KMS는 단일 콘솔에서 전 세계 여러 리전의 애플리케이션 및 지원되는 AWS 서비스에서 사용하는 암호화 키를 생성하고 제어하는 데 도움이 됩니다. 이 서비스는 키의 보안을 보호하기 위해 FIPS 140-2에 따라 인증되었거나 인증 중인 FIPS HSM을 사용합니다. AWS KMS의 모든 키를 중앙에서 관리하면 키를 사용할 수 있는 사용자 및 조건, 키 교체 시기, 키 관리자를 지정하는 데 도움이 됩니다. AWS KMS와 CloudTrail을 통합하면 키 사용에 대한 감사를 수행하여 규제 및 규정 준수 활동을 지원할 수 있습니다. AWS KMS에 통합된 다른 AWS 서비스를 통해 서비스 API를 직접 호출하려는 경우에는 AWS SDK를 사용하여 애플리케이션에서 AWS KMS와 상호작용하거나 클라이언트 측 암호화를 수행하려는 경우에는 AWS Encryption SDK를 사용하여 애플리케이션에서 AWS KMS와 상호작용합니다.

AWS KMS는 사용한 양에 대해서만 결제하며 최소 요금이 없습니다. 서비스를 시작하는 데 드는 설치 수수료나 약정이 없습니다. 월말에 사용자의 신용 카드에서 월 사용액이 자동으로 결제됩니다.

생성하는 모든 KMS 키에 대한 요금과 매달 프리 티어를 초과하여 서비스에 전송되는 API 요청에 대한 요금이 부과됩니다.
 

현재 요금 정보는 AWS KMS 요금 페이지를 참조하세요.

예. AWS 프리 티어를 사용하여 모든 리전에서 무료*로 AWS KMS를 시작할 수 있습니다. AWS 서비스에서 사용자를 대신하여 생성되는 AWS 관리형 AWS KMS 키는 계정에 무료로 저장할 수 있습니다. 매월 서비스에서 무료로 사용할 수 있는 요청 수를 제공하는 프리 티어 사용량이 있습니다. 프리 티어를 비롯한 현재 요금 정보에 대한 자세한 내용은 AWS KMS 요금 페이지를 참조하세요.

*비대칭 KMS 키와 관련된 API 요청과 GenerateDataKeyPair 및 GenerateDataKeyPairWithoutPlaintext API에 대한 API 요청은 프리 티어에 포함되지 않습니다.

달리 명시하지 않는 한 가격에는 VAT 및 해당 판매세를 포함한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세한 내용은 여기를 참조하세요.

예. 자체 키 관리 인프라의 키 사본을 AWS KMS로 가져와서 통합된 다른 AWS 서비스에서 사용하거나 자체 애플리케이션 내에서만 사용할 수 있습니다.

가져온 키를 사용하여 AWS KMS에 있는 키의 생성, 수명 주기 관리 및 내구성에 대한 제어를 강화할 수 있습니다. 가져온 키는 규정 준수 요구 사항을 충족하는 데 도움이 되도록 설계되었습니다. 이 요구 사항에는 인프라에서 안전한 키 사본을 생성 또는 유지 관리하는 기능과 AWS 인프라에서 가져온 키 사본을 즉시 삭제하는 기능이 포함될 수 있습니다.

대칭 키, 비대칭 키(RSA 및 타원 곡선) 및 HMAC 키를 가져올 수 있습니다.

가져오기 프로세스에서 키는 지원되는 래핑 알고리즘을 사용하여 AWS KMS 제공 퍼블릭 키로 래핑되어야 합니다. 이렇게 하면 암호화된 키를 AWS KMS에서만 복호화할 수 있습니다.

2가지 큰 차이점이 있습니다.
 

1. 가져온 키 사본을 언제든지 다시 가져올 수 있도록 키 관리 인프라에서 유지 관리하는 것은 사용자의 책임입니다. 하지만 AWS KMS에서 사용자를 대신해 생성된 키는 사용자가 키 삭제 일정을 예약할 때까지 AWS가 가용성, 보안 및 내구성을 보장합니다.
2. 가져온 키에 대해서는 유효 기간을 설정할 수 있습니다. AWS KMS는 이 유효 기간이 지나면 키 구성 요소를 자동으로 삭제합니다. 그 밖에 가져온 키 구성 요소를 온디맨드 방식으로 삭제하는 것도 가능합니다. 하지만 두 경우 모두 키 구성 요소만 삭제될 뿐 AWS KMS의 KMS 키 참조를 비롯해 연결된 메타데이터는 유지되기 때문에 향후 키 구성 요소를 다시 가져올 수도 있습니다. AWS KMS에서 생성된 키는 만료 기간이 없고 바로 삭제할 수 없습니다. 의무적으로 7~30일을 기다려야 합니다. 고객 관리형 KMS 키에서는 키 구성 요소를 가져왔든 가져오지 않았든 상관없이 모두 수동으로 사용 중지하거나 삭제 일정을 예약할 수 있습니다. 이때 KMS 키 자체만 삭제될 뿐 기본적인 키 구성 요소는 삭제되지 않습니다.

유효한 만료 기간이 적용된 키 구성 요소의 사본을 AWS KMS의 원래 AWS KMS 키로 다시 가져와서 사용할 수 있습니다.

예. 키를 AWS KMS 키로 가져오면, 가져온 키의 만료 시간을 알려주는 CloudWatch 지표를 몇 분 간격으로 받게 됩니다. 또한 AWS KMS 키 아래 가져온 키가 만료될 때에도 CloudWatch 이벤트가 수신됩니다. 가용성 위험을 방지할 수 있도록 이러한 지표 또는 이벤트에 따라 조치를 취하는 로직을 구축하고 새로운 만료 기간이 적용된 키를 자동으로 다시 가져올 수 있습니다.

AWS KMS는 암호화 및 복호화를 위한 KMS 키를 생성할 때 256비트 키를 지원합니다. 호출자에게 반환되는 생성된 데이터 키는 256비트, 128비트 또는 최대 1,024바이트의 임의 값이 될 수 있습니다. AWS KMS가 사용자 대신 256비트 KMS 키를 사용하여 암호화 또는 복호화하는 경우 Galois Counter Mode의 AES 알고리즘(AES-GCM)이 사용됩니다.

AWS KMS는 RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 및 ECC SECG P-256k1과 같은 비대칭 키 유형을 지원합니다. AWS KMS은 RSA 2048, RSA 3072, RSA 4096 키 유형을 사용하는 RSAES_OAEP_SHA_1 및 RSAES_OAEP_SHA_256 암호화 알고리즘을 지원합니다. 암호화 알고리즘은 타원 곡선 키 유형(ECC NIST P-256, ECC NIST P-384, ECC NIST-521, ECC SECG P-256k1)에는 사용할 수 없습니다.

타원 곡선 키 유형을 사용하는 경우 AWS KMS는 ECDH 키 계약 알고리즘을 지원합니다.

RSA 키 유형을 사용하는 경우 AWS KMS는 RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384, RSASSA_PKCS1_V1_5_SHA_512 서명 알고리즘을 지원합니다. 타원 곡선 키 유형을 사용하는 경우 AWS KMS는 ECDSA_SHA_256, ECDSA_SHA_384, ECDSA_SHA_512 서명 알고리즘을 지원합니다.

비대칭 키 구성 요소의 퍼블릭 부분은 AWS KMS에서 생성되며 ‘Verify’ API를 직접적으로 호출하여 디지털 서명 확인에 사용하거나 ‘Encrypt’ API를 직접적으로 호출하여 퍼블릭 키 암호화에 사용할 수 있습니다. 퍼블릭 키는 확인 또는 암호화를 위해 AWS KMS 외부에서 사용할 수도 있습니다. GetPublicKey API를 직접적으로 호출하여 비대칭 KMS 키의 퍼블릭 부분을 검색할 수 있습니다.

크기 제한은 4KB입니다. 4KB보다 큰 데이터에 디지털 서명을 하려면 데이터의 메시지 다이제스트를 생성하여 AWS KMS에 보내면 됩니다. 디지털 서명은 데이터 다이제스트에 대해 생성되어 반환됩니다. 전체 메시지를 전송할지 또는 메시지 다이제스트를 전송할지는 Sign API 요청에서 파라미터로 지정합니다. 비대칭 작업을 사용해야 하는 Encrypt, Decrypt 또는 Re-Encrypt API에 제출된 모든 데이터도 4KB 미만이어야 합니다.

콘솔에서 각 키에는 키 유형이라는 새로운 필드가 있습니다. 이 필드에는 키 유형을 나타내는 Asymmetric Key(비대칭 키) 또는 Symmetric Key(대칭 키) 값이 있습니다. DescribeKey API는 키를 사용하여 서명, HMAC 생성 또는 암호화할 수 있는지 여부를 지정하는 KeyUsage 필드를 반환합니다.

아니요. 비대칭 또는 HMAC KMS 키에는 자동 키 교체가 지원되지 않습니다. 일반적으로 비대칭 키 또는 HMAC 키를 교체하면 과거에 다른 사람과 공유했던 키의 모든 인스턴스를 폐기하고 교체해야 하기 때문에 기존 워크로드에 큰 지장을 줄 수 있습니다. 필요하면, 새 KMS 키를 생성하고 이전 KMS 키의 기존 키 별칭을 새 KMS 키로 매핑하여 수동으로 교체할 수 있습니다.

아니요. KMS 키를 생성할 때 키를 복호화에 사용할지, 서명 작업에 사용할지 지정해야 합니다. RSA 키 유형은 서명 또는 암호화 작업에 사용할 수 있지만 둘 다에 사용할 수는 없습니다. 타원 곡선 키 유형은 서명 작업에만 사용할 수 있습니다.

예. 초당 요청 수 제한은 키 유형과 알고리즘에 따라 다릅니다. 자세한 내용은 AWS KMS 제한 페이지를 참조하세요.

아니요. 비대칭 키로는 사용자 지정 키 스토어 기능을 사용할 수 없습니다.

직접적으로 사용할 수는 않습니다. AWS KMS는 디지털 인증서를 저장하거나, 서비스에서 생성하는 비대칭 KMS 키와 디지털 인증서를 연결하지 않습니다. AWS Private Certificate Authority와 같은 인증 기관에서 비대칭 KMS 키의 퍼블릭 부분에 대한 인증서를 발급하도록 선택할 수 있습니다. 이렇게 하면 퍼블릭 키를 사용하는 엔터티가 해당 퍼블릭 키가 사용자 소유인지 확인할 수 있습니다.

AWS KMS 사용자 지정 키 저장소 기능은 CloudHSM에서 제공하는 제어 기능과 AWS KMS의 통합 및 사용 편의성을 결합한 것입니다. 자체 CloudHSM 클러스터를 구성한 후 기본 AWS KMS 키 스토어가 아닌 이 클러스터를 전용 키 스토어로 사용하도록 AWS KMS에 권한을 부여할 수 있습니다. AWS KMS에서 키를 생성할 때 CloudHSM 클러스터에서 키 구성 요소를 생성하도록 선택할 수 있습니다. 사용자 지정 키 스토어에서 생성된 KMS 키는 절대 일반 텍스트 상태에서 CloudHSM 클러스터의 HSM을 벗어나지 않으며, 이러한 키를 사용하는 모든 AWS KMS 작업은 HSM에서만 수행됩니다. 그 밖에 모든 측면에서는 사용자 지정 키 스토어에 저장된 KMS 키가 다른 AWS KMS 키와 동일하게 작동합니다.

사용자 지정 키 저장소의 사용 적합성 여부를 결정할 수 있는 추가 지침은 이 블로그에서 확인할 수 있습니다.

CloudHSM 클러스터는 사용자가 제어하기 때문에 원하는 경우 AWS KMS와 별도로 KMS 키의 수명 주기를 관리할 수 있습니다. 다음은 사용자 지정 키 스토어가 유용한 3가지 이유입니다. 첫째, 단일 테넌트 HSM에서, 혹은 직접 제어하는 HSM에서 키를 명시적으로 보호해야 하는 경우가 발생할 수 있기 때문입니다. 둘째, AWS KMS에서 키 구성 요소를 즉시 제거한 후 독립적인 방법으로 제거 여부를 증명하는 기능이 필요할 수 있기 때문입니다. 셋째, AWS KMS 또는 CloudTrail과 상관없이 모든 키 사용을 감사할 수 있는 요건이 필요할 수도 있기 때문입니다.

CloudHSM으로 지원되는 사용자 지정 키 스토어에서 키를 관리할 경우 기본 AWS KMS 키 스토어와 비교해 2가지 차이점이 있습니다. 사용자 지정 키 스토어로는 키 구성 요소를 가져올 수 없으며, AWS KMS가 키를 자동으로 교체하도록 할 수 없습니다. 생성 가능한 키의 유형, 키의 별칭 사용 방식 및 정책 정의 방법을 비롯하여 그 밖에 모든 측면에서는 사용자 지정 키 스토어에 저장되는 키가 다른 AWS KMS 고객 관리형 KMS 키와 동일하게 관리됩니다.

아니요. 고객 관리형 KMS 키만 CloudHSM으로 지원되는 AWS KMS 사용자 지정 키 스토어에 저장하여 관리할 수 있습니다. 다른 AWS 서비스에서 데이터를 암호화할 목적으로 사용자를 대신해 생성하는 AWS 관리형 KMS 키는 항상 AWS KMS 기본 키 스토어에서 생성되고 저장됩니다.

아니요. AWS KMS에게 KMS 키를 사용해 데이터를 암호화 및 복호화하도록 하는 API 요청은 동일하게 처리됩니다. 인증 및 승인 프로세스는 키의 저장 위치와 상관이 없습니다. CloudHSM으로 지원되는 사용자 지정 키 스토어에 저장된 키를 사용하는 모든 작업 역시 CloudTrail에 동일한 방식으로 로깅됩니다. 하지만 실제 암호화 작업은 사용자 지정 키 스토어 또는 기본 AWS KMS 키 스토어에서만 발생합니다.

사용자 지정 키 스토어를 사용할 때는 AWS KMS에서 CloudTrail에 로깅하는 작업 외에도 세 가지 감사 메커니즘이 추가로 제공됩니다. 첫째, CloudHSM은 클러스터 생성 및 HSM 추가 또는 제거와 같은 모든 API 활동도 CloudTrail에 로깅합니다. 둘째, 각 클러스터 역시 자체 로컬 로그를 수집하여 사용자 및 키 관리 작업을 기록합니다. 셋째, 각 CloudHSM 인스턴스는 로컬 사용자 및 키 관리 작업 로그를 AWS CloudWatch에 복사합니다.

AWS KMS 사용자 지정 키 스토어를 사용하는 경우 AWS KMS에서 사용할 수 있는 키를 확인할 책임은 사용자에게 있습니다. CloudHSM의 구성 오류, 혹은 CloudHSM 클러스터에서 키 구성 요소의 우발적 삭제 등은 가용성에 영향을 미칠 수 있습니다. 사용하는 HSM 수와 선택하는 가용 영역(AZ) 역시 클러스터의 복원력에 영향을 미칩니다. 모든 키 관리 시스템에서 그렇듯이 키의 가용성이 암호화된 데이터의 복구에 어떤 영향을 미칠 수 있는지 정확하게 이해하고 있어야 합니다.

AWS KMS API 직접 호출을 통해 CloudHSM으로 지원되는 AWS KMS 사용자 지정 키 스토어에 저장되는 키를 사용할 수 있는 비율은 기본 AWS KMS 키 스토어에 저장되는 키와 비교하여 낮습니다. 현재 성능 제한은 AWS KMS 개발자 가이드를 참조하세요.

사용자 지정 키 스토어를 사용하더라도 AWS KMS 요금은 바뀌지 않습니다. 단, 사용자 지정 키 스토어를 사용하려면 AWS CloudHSM 클러스터에 HSM이 2개 이상 있어야 합니다. 이러한 HSM에는 표준 AWS CloudHSM 요금이 부과됩니다. 따라서 사용자 지정 키 스토어를 사용하는 데 따른 추가 비용은 없습니다.

사용자 지정 키 스토어를 사용하려는 AWS KMS 사용자는 AWS CloudHSM 클러스터를 설정하고, HSM을 추가하며, HSM 사용자를 관리하고, 잠재적으로 HSM을 백업에서 복원할 줄 알아야 합니다. 모두 보안에 민감한 태스크이므로 적절한 리소스와 조직적 제어 기능이 있는지 확인할 수 있습니다.

아니요. 자체 키 구성 요소를 AWS KMS 사용자 지정 키 스토어로 가져오는 기능은 지원되지 않습니다. 사용자 지정 키 스토어에 저장되는 키는 CloudHSM 클러스터에 속하는 HSM에서만 생성할 수 있습니다.

아니요. 서로 다른 유형의 AWS KMS 키 스토어 사이에서 키를 마이그레이션하는 기능은 현재 지원되지 않습니다. 모든 키는 사용할 키 스토어에서 생성해야 합니다. 단, 자체 키 구성 요소를 기본 AWS KMS 키 스토어로 가져오는 경우는 예외입니다.

AWS KMS 사용자 지정 키 스토어에 저장된 키 구성 요소를 자동으로 교체하는 기능은 지원되지 않습니다. 따라서 먼저 새로운 키를 생성한 다음 이후 암호화 작업에서 새로운 키를 사용할 수 있도록 애플리케이션 코드에서 사용하는 AWS KMS 키 별칭을 다시 매핑하여 키를 수동으로 교체해야 합니다.

예. AWS KMS는 AWS CloudHSM 클러스터에 대한 배타적 액세스를 요구하지 않습니다. 이미 클러스터가 있다면 이를 사용자 지정 키 스토어로 사용할 수 있으며 다른 애플리케이션에도 계속해서 사용할 수 있습니다. 하지만 클러스터가 AWS KMS가 아닌, 높은 워크로드를 지원하고 있다면 사용자 지정 키 스토어에 저장된 KMS 키를 사용하는 작업의 처리량이 줄어들 수도 있습니다. 마찬가지로 사용자 지정 키 스토어에 대한 AWS KMS 요청 비율이 높다면 다른 애플리케이션에 영향을 미칠 수 있습니다.

서비스 개요는 AWS CloudHSM 웹사이트를 참조하고, 서비스 구성 및 사용에 대한 자세한 내용은 AWS CloudHSM 사용 설명서를 참조하세요.

외부 키 스토어는 외부 키 관리 인프라로 지원되는 사용자 지정 키 스토어이며 AWS 외부에서 사용자가 소유하고 관리합니다. 외부 키 스토어의 KMS 키를 사용하는 모든 암호화 및 복호화 작업은 사용자가 제어하고 AWS에서 물리적으로 액세스할 수 없는 암호화 키 및 작업을 통해 키 관리자 내에서 수행됩니다.

XKS는 사용자가 제어하는 AWS 외부에서 암호화 키를 저장하고 사용할 것을 요구하는 규칙 또는 규제를 준수하는 데 도움이 될 수 있습니다.

통합된 AWS 서비스에서 자동으로 실행되거나 자체 애플리케이션에서 실행되는 요청은 XKS 프록시라고 하는 네트워크의 구성 요소로 전달됩니다. XKS 프록시는 오픈 소스 API 사양으로, 사용자 및 사용자의 키 관리 공급업체에서 이러한 요청을 수락하고 키 관리 인프라로 전달하여 암호화 및 복호화에 해당 키를 사용할 수 있도록 하는 서비스를 구축하는 데 도움이 됩니다.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems, HashiCorp는 XKS 프록시 사양과 통합되는 솔루션을 보유하고 있습니다. 이러한 공급업체 솔루션의 가용성, 요금 및 사용 방법에 대한 자세한 내용은 해당하는 설명서를 참조하세요. 사용자와 사용자의 키 관리 인프라 파트너는 오픈 소스 XKS 프록시 사양을 활용하여 요구 사항을 충족하는 솔루션을 구축하는 것이 좋습니다. XKS 프록시의 API 사양은 여기에 게시되어 있습니다.

외부 키는 Encrypt, ReEncrypt, Decrypt 및 GenerateDataKey와 같은 대칭형 암호화 작업을 지원합니다.

XKS 키를 사용할 때는 AWS KMS와 통합되는 모든 AWS 서비스의 데이터를 고객 관리형 키를 사용하여 암호화할 수 있습니다. 여기에서 지원되는 서비스 목록을 참조하세요. AWS 서비스는 AWS KMS GenerateDataKey API를 호출하여 데이터 암호화에 사용할 고유한 일반 텍스트 데이터 키를 요청합니다. 이 일반 텍스트 데이터 키는 데이터 키의 암호화된 복사본과 함께 서비스로 반환되고 암호화된 데이터와 함께 저장됩니다. 데이터 키의 암호화된 복사본을 생성하기 위해 먼저 일반 텍스트 데이터 키가 사용자의 AWS 계정에 고유한 AWS KMS에 저장된 키로 암호화됩니다. 이 암호화된 데이터 키는 외부 키 관리자에 연결된 XKS 프록시 구현으로 전달되고 외부 키 관리자에 정의된 키를 사용하여 두 번째로 암호화됩니다. 이중으로 암호화된 결과 데이터 키는 GenerateDataKey API 요청에 대한 응답으로 반환됩니다.

AWS KMS, XKS 프록시 구현 및 외부 키 관리자 간의 네트워크 연결은 TLS와 같은 지점 간 암호화 프로토콜로 보호되어야 합니다. 그러나 데이터가 AWS KMS를 떠나 외부 키 관리자에 도착할 때까지 데이터를 보호하기 위해 AWS KMS는 외부 키 스토어에 정의된 각 KMS 키에 고유한 계정의 내부 관리형 KMS 키를 사용하여 데이터를 먼저 암호화합니다. 결과 사이퍼텍스트는 외부 키 관리자로 전달되고 외부 키 관리자는 이 사이퍼텍스트를 사용하여 외부 키 관리자의 키를 암호화합니다. 이중 암호화는 외부 키 관리자의 키 구성 요소를 사용하지 않고는 어떤 사이퍼텍스트도 복호화할 수 없는 보안 제어를 제공합니다. 또한 이 보안 제어에서 AWS 네트워크를 떠난 사이퍼텍스트는 FIPS 140 인증 AWS KMS HSM을 사용하여 암호화됩니다. 데이터를 복호화할 때는 외부 키 관리자를 사용해야 하기 때문에 AWS KMS에 대한 액세스 권한을 취소하면 암호화된 기초 데이터에 액세스할 수 없게 됩니다.

예. AWS KMS를 키 제공업체로 사용하는 클라이언트측 대칭 암호화 솔루션을 사용하는 경우 자체 애플리케이션 안에서도 XKS 키를 사용할 수 있습니다. AWS Encryption SDK, S3 암호화 클라이언트 및 DynamoDB 암호화 클라이언트와 같은 AWS 오픈 소스 클라이언트측 암호화 솔루션은 XKS 키를 지원합니다.

KMS에서 모든 XKS 키를 새 키로 생성해야 합니다. 기존 KMS 키를 외부 키 관리자에서 호스팅되는 XKS 키로 마이그레이션할 수는 없습니다.

AWS 서비스 또는 자체 애플리케이션에서 작업을 지원하는 경우 새로 생성된 XKS 키로 기존 데이터를 다시 암호화할 수 있습니다. 많은 AWS 서비스가 암호화된 리소스를 복사하고 복사본을 암호화할 때 사용할 KMS 키를 지정하는 작업을 지원합니다. AWS 서비스가 제공하는 COPY 명령에서 XKS 키를 구성할 수 있습니다. 자체 애플리케이션에서 클라이언트측 암호화 데이터를 다시 암호화하려면 KMS ReEncrypt API를 직접적으로 호출하고 XKS 키를 구성하면 됩니다.

모든 고객 관리형 키와 마찬가지로 XKS 키도 삭제되기 전까지 매월 1 USD의 요금이 부과됩니다. XKS 키를 사용한 요청에는 다른 모든 AWS KMS 대칭 키와 동일한 요금이 부과됩니다. AWS KMS 요금 페이지에서 요금에 대해 자세히 알아보세요.

예. 자동 키 교체는 XKS 사양으로 지원되며 XKS를 지원하는 대부분의 공급업체에서 제공하는 기능입니다. XKS 키의 자동 교체는 전적으로 외부 키 관리자에서 발생하며 KMS 내에서 생성 및 관리되는 AWS KMS 키의 자동 키 교체와 비슷한 방식으로 작동합니다. 교체된 KMS XKS 키를 사용하여 데이터를 암호화하는 경우 외부 키 관리자는 현재 키 구성 요소를 사용합니다. 교체된 XKS 키를 사용하여 사이퍼텍스트를 복호화하는 경우 외부 키 관리자는 암호화에 사용된 키 구성 요소의 버전을 사용합니다. 이전 사이퍼텍스트를 생성할 때 사용된 XKS 키를 외부 키 관리자에서 여전히 사용할 수 있는 동안에는 이러한 버전의 XKS 키로 Decrypt API 요청을 성공적으로 수행할 수 있습니다.

키를 캐시하지 않는 서비스의 경우 이 XKS KMS 키를 사용한 이후 API 직접 호출이 실패합니다. 일부 서비스는 성능, 지연 시간 또는 KMS 비용 관리를 위해 데이터 키 캐싱 또는 기타 키 파생 체계를 구현합니다. 이러한 키의 캐싱은 5분~24시간까지 다를 수 있습니다. 현재 사용 중인 보호되는 모든 리소스(예: RDS 데이터베이스 또는 EC2 인스턴스)는 키 액세스를 거부한 후 다르게 응답합니다. 자세한 내용은 관련된 AWS 서비스 설명서를 참조하세요.

외부 키 스토어 프록시에 대한 인증을 위해 AWS KMS는 사용자가 프록시에서 구성하고 KMS에 제공한 AWS SigV4 보안 인증 정보를 사용하여 프록시에 대한 모든 요청을 서명합니다. AWS KMS는 서버 측 TLS 인증서를 사용하여 외부 키 스토어 프록시를 인증합니다. 필요한 경우 프록시에서 추가 보증을 위해 상호 TLS를 사용할 수 있습니다. 그러면 AWS KMS의 요청만 수신됩니다.

다른 KMS 키에 사용하는 모든 일반적인 AWS KMS 권한 부여 메커니즘(IAM 정책, AWS KMS 키 정책, 부여)이 외부 키 스토어의 KMS 키에도 동일한 방식으로 작동합니다.

또한 사용자 또는 사용자의 키 관리자 파트너는 AWS KMS에서 XKS 프록시로 전송되는 각 요청에 포함된 요청 메타데이터에 따라 보조 계층의 권한 부여 제어를 구현할 수 있습니다. 이 메타데이터에는 호출을 수행한 AWS 사용자/역할, KMS 키 ARN 및 요청된 특정 KMS API가 포함됩니다. 이렇게 하면 단순히 AWS KMS의 모든 요청을 신뢰하는 것을 넘어 외부 키 관리자의 키 사용에 세분화된 권한 부여 정책을 적용할 수 있습니다. 이러한 요청 속성을 사용하여 정책을 적용하는 것은 개별 XKS 프록시 구현에 따라 선택할 수 있습니다.

XKS 키와 관련하여 AWS KMS로 오는 모든 요청에 대해 생성된 고유 ID는 XKS 프록시로도 전달됩니다. XKS 프록시 또는 외부 키 관리자의 로그 데이터(사용할 수 있는 경우)를 사용하여 AWS KMS에 대한 요청과 외부 키 관리자에 대한 요청을 조정할 수 있습니다. 이 기능을 사용하면 모든 요청에 외부 키 관리자의 키(AWS KMS로 직접 또는 통합된 AWS 서비스를 통해 시작한 직접 호출에서 비롯된 키)가 사용되는지 확인할 수 있습니다.

가용성 위험: XKS 프록시 및 외부 키 구성 요소의 가용성에 대한 책임은 사용자에게 있습니다. 이 시스템은 고가용성이어야 합니다. 즉, 암호화된 리소스를 복호화하거나 새 데이터를 암호화하기 위해 XKS 키가 필요할 때 AWS KMS에서 XKS 프록시에 연결하고 프록시 자체에서 외부 키 관리자에 연결한 후 키를 사용하여 필요한 암호화 작업을 완료할 수 있어야 합니다. 예를 들어 XKS 키를 사용하여 EBS 볼륨을 암호화했습니다. 이제 EC2 인스턴스를 시작하고 이 암호화된 볼륨을 연결하려고 합니다. EC2 서비스는 해당 볼륨의 암호화된 고유 데이터 키를 AWS KMS로 전달하여 볼륨을 복호화합니다. Nitro Card의 휘발성 메모리에 볼륨을 프로비저닝하여 볼륨에 대한 읽기/쓰기 작업을 복호화하고 암호화하기 위해서입니다. XKS 프록시 또는 외부 키 관리자를 사용하여 볼륨 키를 복호화하지 못하면 EC2 인스턴스가 시작되지 않습니다. 이러한 유형의 장애에서 AWS KMS는 XKS 프록시를 사용할 수 없음을 알리는 KMSInvalidStateException을 반환합니다. 이제 사용자는 KMS가 제공한 오류 메시지를 기반으로 XKS 프록시 및 키 관리자를 사용할 수 없는 이유를 결정해야 합니다.

내구성 위험: AWS 외부 시스템에서 사용자가 키를 제어하기 때문에 사용자가 생성한 모든 외부 키의 내구성에 대한 책임은 전적으로 사용자에게 있습니다. XKS 키의 외부 키가 영구적으로 손실되거나 삭제된 경우 XKS 키로 암호화된 모든 사이퍼텍스트를 복구할 수 없습니다.

성능 위험: 사용자는 XKS 프록시 및 외부 키 저장소 인프라가 요구 사항을 충족하는 충분한 성능 특성을 갖도록 설계되었는지 확인할 책임이 있습니다. XKS 키를 사용하는 모든 요청에는 외부 키 스토어에 대한 연결이 필요하기 때문에 AWS KMS의 요청 속도가 XKS 프록시 또는 외부 키 관리자로 지원할 수 있는 요청 속도를 초과할 경우 XKS 프록시에서 병목 현상이 발생할 수 있습니다. 또한 AWS KMS에서 XKS 프록시로의 단일 요청(재시도 1회 포함)의 경과 시간이 500ms*를 초과할 경우 AWS KMS는 호출 클라이언트에 400 오류를 반환하여 XKS 키를 사용할 수 없으니 호출 클라이언트에서 재시도를 수행하지 말 것을 실질적으로 알립니다. 이 동작은 업스트림 AWS 서비스 또는 자체 애플리케이션에서 인프라 연결 문제로 인해 간헐적으로 초과되는 지연 시간에 대응할 필요를 최소화하도록 설계되었습니다.

*AWS KMS는 250ms가 소요되는 모든 요청에서 재시도를 1회 시도합니다. 재시도 요청도 250ms를 초과하면 400 오류가 직접 호출 클라이언트로 반환됩니다.

AWS KMS와 외부 키 저장소 인프라 간의 연결에 대한 엔드 투 엔드 가용성을 AWS에서 제어할 수 없기 때문에 AWS의 퍼블릭 KMS 가용성 SLA에서 XKS의 사용을 명시적으로 제외합니다. 또한 XKS 키는 서비스 내의 데이터를 암호화할 용도로 사용자가 XKS 키를 구성한 모든 AWS 서비스의 가용성 SLA에서도 제외됩니다.