기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에 대한 모범 사례 AWS CloudHSM

AWS CloudHSM을 효과적으로 사용하려면 이 주제의 모범 사례를 수행하십시오.

클러스터 관리

AWS CloudHSM 클러스터를 생성, 액세스 및 관리할 때는 이 섹션의 모범 사례를 따르십시오.

피크 트래픽을 처리할 수 있도록 클러스터 확장

클라이언트 인스턴스 크기, 클러스터 크기, 네트워크 지형, 사용 사례에 필요한 암호화 작업 등 여러 요인이 클러스터가 처리할 수 있는 최대 처리량에 영향을 미칠 수 있습니다.

시작점으로 일반적인 클러스터 크기 및 구성에 대한 성능 추정치는 주제 AWS CloudHSM 성능 섹션을 참조하십시오. 예상되는 최대 부하로 클러스터를 부하 테스트하여 현재 아키텍처가 복원력이 있고 적절한 규모인지 확인하는 것이 좋습니다.

고가용성을 위한 클러스터 설계

유지 관리를 위해 이중화 추가: 예정된 유지 관리 또는 문제가 감지된 경우 HSM을 교체할 AWS 수 있습니다. 일반적으로 클러스터 크기에는 +1 이상의 중복성이 있어야 합니다. 예를 들어, 피크 타임에 서비스를 운영하기 위해 2개의 HSM이 필요한 경우 이상적인 클러스터 크기는 3입니다. 가용성과 관련된 모범 사례를 따른다면 이러한 HSM 교체가 서비스에 영향을 미치지 않을 것입니다. 그러나 교체된 HSM에서 진행 중인 작업은 실패할 수 있으므로 다시 시도해야 합니다.

HSM을 여러 가용 영역으로 분산: 가용 영역 장애 발생 시 서비스를 어떻게 운영할 수 있을지 생각해 보십시오. AWS 에서는 가능한 한 많은 가용 영역에 HSM을 분산할 것을 권장합니다. HSM이 3개인 클러스터의 경우 HSM을 3개의 가용 영역에 분산해야 합니다. 시스템에 따라 추가 중복성이 필요할 수 있습니다.

새로 생성된 키의 내구성을 보장하려면 HSM이 3개 이상 있어야 합니다.

새로 생성된 키의 내구성을 필요로 하는 애플리케이션의 경우 한 리전에 있는 다양한 가용 영역에 3개 이상의 HSM을 분산시키는 것이 좋습니다.

클러스터에 대한 보안 액세스

프라이빗 서브넷을 사용하여 인스턴스에 대한 액세스 제한: VPC의 프라이빗 서브넷에서 HSM과 클라이언트 인스턴스를 시작하십시오. 이렇게 하면 외부에서 HSM에 액세스하는 것이 제한됩니다.

VPC 엔드포인트를 사용하여 API에 액세스: AWS CloudHSM 데이터 플레인은 인터넷 또는 AWS API에 액세스할 필요 없이 작동하도록 설계되었습니다. 클라이언트 인스턴스에서 AWS CloudHSM API에 액세스해야 하는 경우 클라이언트 인스턴스에서 인터넷에 액세스할 필요 없이 VPC 엔드포인트를 사용하여 API에 액세스할 수 있습니다. 자세한 정보는 AWS CloudHSM 및 엔드포인트 VPC을 참조하세요.

클라이언트-서버 통신을 보호하도록 SSL 재구성: TLS를 AWS CloudHSM 사용하여 HSM에 대한 연결을 설정합니다. 클러스터를 초기화한 후 외부 TLS 연결을 설정하는 데 사용되는 기본 TLS 인증서와 키를 교체할 수 있습니다. 자세한 내용은 SSL/TLS 오프로드를 통해 웹 서버 보안을 개선하세요. AWS CloudHSM 섹션을 참조하십시오.

필요에 맞게 확장하여 비용 절감

AWS CloudHSM사용에 따른 선결제 비용은 없습니다. HSM을 종료할 때까지 시작한 각 HSM에 대해 시간당 요금을 지불합니다. 서비스를 계속 사용할 필요가 없는 경우 필요하지 않을 때 HSM을 0으로 축소 (삭제) 하여 비용을 절감할 수 있습니다. AWS CloudHSM HSM이 다시 필요한 경우 백업에서 HSM을 복원할 수 있습니다. 예를 들어 한 달에 한 번, 특히 말일에 코드에 서명해야 하는 워크로드가 있는 경우 먼저 클러스터를 확장하고, 작업이 완료된 후 HSM을 삭제하여 축소하고, 다음 달 말에 서명 작업을 다시 수행하도록 클러스터를 복원할 수 있습니다.

AWS CloudHSM 클러스터에 있는 HSM을 정기적으로 자동으로 백업합니다. 나중에 새 HSM을 추가하면 최신 백업이 새 HSM에 복원되므로 이전 위치에서 다시 사용할 수 있습니다. AWS CloudHSM AWS CloudHSM 아키텍처 비용을 계산하려면 요금을 참조하십시오AWS CloudHSM .

관련 리소스:

HSM 사용자 관리

AWS CloudHSM 클러스터의 사용자를 효과적으로 관리하려면 이 섹션의 모범 사례를 따르십시오. HSM 사용자는 IAM 사용자와 다릅니다. 적절한 권한이 있는 ID 기반 정책을 보유한 IAM 사용자 및 엔터티는 API를 통해 리소스와 상호 작용하여 HSM을 생성할 수 있습니다. HSM을 생성한 후에는 HSM 사용자 보안 인증 정보를 사용하여 HSM에서의 작업을 인증해야 합니다. HSM 사용자에 대한 자세한 안내는 HSM 사용자 관리 AWS CloudHSM 섹션을 참조하십시오.

HSM 사용자의 보안 인증 정보 보호

HSM 사용자는 HSM에서 암호화 및 관리 작업을 수행하고 액세스할 수 있는 엔터티이므로 HSM 사용자의 보안 인증 정보를 안전하게 보호하는 것이 필수적입니다. AWS CloudHSM 는 HSM 사용자 보안 인증 정보에 액세스할 수 없으며 액세스 권한을 상실할 경우 지원해 드릴 수 없습니다.

관리자를 두 명 이상 두고 계정 잠금 방지

클러스터에서 잠기지 않도록 하려면 관리자 암호 하나를 분실할 경우에 대비하여 최소 두 명의 관리자를 두는 것이 좋습니다. 이 경우 다른 관리자를 통해 암호를 재설정할 수 있습니다.

모든 사용자 관리 작업에 쿼럼 활성화

쿼럼을 사용하면 작업을 수행하기 전에 사용자 관리 작업을 승인해야 하는 최소 관리자 수를 설정할 수 있습니다. 관리자가 가질 수 있는 권한 때문에 모든 사용자 관리 작업에 대해 쿼럼을 활성화하는 것이 좋습니다. 이렇게 하면 관리자 암호 중 하나가 손상될 경우 미칠 수 있는 영향을 제한할 수 있습니다. 자세한 내용은 쿼럼 관리를 참조하십시오.

각각 권한이 제한된 암호 사용자를 여러 명 생성

암호 사용자의 책임을 분리함으로써 어느 사용자도 전체 시스템을 완전히 통제할 수 없게 됩니다. 따라서 여러 암호 사용자를 만들고 각 사용자의 권한을 제한하는 것이 좋습니다. 일반적으로 이 작업은 암호 사용자마다 수행하는 책임과 작업이 확연히 다릅니다(예: 한 명의 암호 사용자가 키를 생성하고 다른 암호 사용자와 공유한 다음 이를 애플리케이션에서 사용하는 경우).

관련 리소스:

HSM 키 관리

AWS CloudHSM의 키를 관리할 때는 이 섹션의 모범 사례를 따르십시오.

적합한 키 유형 선택

세션 키를 사용할 경우 초당 트랜잭션(TPS)은 키가 있는 HSM 1개로 제한됩니다. 클러스터의 추가 HSM은 해당 키에 대한 요청 처리량을 증가시키지 않습니다. 동일한 애플리케이션에 토큰 키를 사용하는 경우 요청이 클러스터에서 사용 가능한 모든 HSM에 걸쳐 로드 밸런싱됩니다. 자세한 내용은 의 키 동기화 및 내구성 설정 AWS CloudHSM 섹션을 참조하십시오.

키 스토리지 한도 관리

HSM에는 한 번에 HSM에 저장할 수 있는 최대 토큰 및 세션 키 수에 제한이 있습니다. 키 스토리지 한도에 대한 자세한 내용은 AWS CloudHSM 할당량 섹션을 참조하십시오. 애플리케이션에 한도 이상이 필요한 경우 다음 전략 중 하나 이상을 사용하여 키를 효과적으로 관리할 수 있습니다.

신뢰할 수 있는 래핑을 사용하여 외부 데이터 스토리지에 키 저장: 신뢰할 수 있는 키 래핑을 사용하면 모든 키를 외부 데이터 스토리지에 래핑하여 저장함으로써 키 스토리지 한도를 극복할 수 있습니다. 이 키를 사용해야 하는 경우 키를 HSM에서 세션 키로 해제하고 필요한 작업에 키를 사용한 다음 세션 키를 폐기할 수 있습니다. 원본 키 데이터는 필요할 때 언제든지 사용할 수 있도록 데이터 스토어에 안전하게 보관됩니다. 신뢰할 수 있는 키를 사용하면 보호를 극대화할 수 있습니다.

클러스터 간 키 배포: 키 스토리지 한도를 극복하기 위한 또 다른 전략은 키를 여러 클러스터에 저장하는 것입니다. 이 접근 방식에서는 각 클러스터에 저장된 키의 매핑을 유지 관리합니다. 이 매핑을 사용하여 필요한 키를 사용하여 클라이언트 요청을 클러스터로 라우팅할 수 있습니다. 동일한 클라이언트 애플리케이션에서 여러 클러스터에 연결하는 방법에 대한 내용은 다음 주제를 참조하십시오.

키 래핑 관리 및 보안

키는 EXTRACTABLE 속성을 통해 추출 가능 또는 추출 불가능으로 표시될 수 있습니다. 기본적으로 HSM 키는 추출 가능으로 표시됩니다.

추출 가능한 키는 키 래핑을 통해 HSM에서 내보낼 수 있는 키입니다. 래핑된 키는 암호화되어 있으며 동일한 래핑 키를 사용하여 래핑을 해제해야 사용할 수 있습니다. 추출할 수 없는 키는 어떤 상황에서도 HSM에서 내보낼 수 없습니다. 추출할 수 없는 키를 추출 가능하게 만드는 방법은 없습니다. 따라서 키를 추출할 수 있어야 하는지 여부를 고려하고 그에 따라 해당 키 속성을 설정하는 것이 중요합니다.

애플리케이션에 키 래핑이 필요한 경우 신뢰할 수 있는 키 래핑을 활용하여 관리자가 신뢰할 수 있는 것으로 명시적으로 표시한 키만 HSM 사용자가 래핑/언래핑할 수 있도록 제한해야 합니다. 자세한 내용은 에서 키 관리 AWS CloudHSM의 신뢰할 수 있는 키 랩핑에 대한 항목을 참조하십시오.

관련 리소스

애플리케이션 통합

이 섹션의 모범 사례에 따라 애플리케이션이 AWS CloudHSM 클러스터와 통합되는 방식을 최적화하십시오.

클라이언트 SDK 부트스트랩

클라이언트 SDK를 클러스터에 연결하려면 먼저 부트스트랩해야 합니다. 클러스터에 IP 주소를 부트스트래핑할 때 가능한 경우 --cluster-id 파라미터를 사용하는 것이 좋습니다. 이 방법을 사용하면 개별 주소를 추적할 필요 없이 클러스터의 모든 HSM IP 주소로 구성을 채울 수 있습니다. 이렇게 하면 HSM이 유지 관리 중이거나 가용 영역이 중단되는 경우 애플리케이션 초기화의 복원력이 향상됩니다. 자세한 내용은 Client SDK 부트스트랩합니다. 섹션을 참조하십시오.

작업 수행을 위한 인증

AWS CloudHSM에서는 암호화 작업과 같은 대부분의 작업을 수행하려면 먼저 클러스터에 인증을 받아야 합니다.

CloudHSM CLI를 사용하여 인증: CloudHSM CLI를 사용하면 단일 명령 모드 또는 대화형 모드를 사용하여 인증할 수 있습니다. login 명령을 사용하여 대화형 모드에서 인증할 수 있습니다. 단일 명령 모드에서 인증하려면 환경 변수(CLOUDHSM_ROLE 및 CLOUDHSM_PIN)를 설정해야 합니다. 이 작업에 대한 자세한 내용은 단일 명령 모드 섹션을 참조하십시오. AWS CloudHSM 는 애플리케이션에서 사용하지 않을 때는 HSM 보안 인증 정보를 안전하게 저장하는 것을 권장합니다.

PKCS #11 인증: PKCS #11 에서는 C_를 사용하여 세션을 연 후 C_Login API를 사용하여 로그인합니다. OpenSession 슬롯(클러스터)당 하나의 C_Login만 수행하면 됩니다. 로그인에 성공하면 추가 로그인 작업을 수행할 필요 없이 OpenSession C_를 사용하여 추가 세션을 열 수 있습니다. PKCS #11 인증에 대한 예는 PKCS #11 라이브러리의 코드 샘플 섹션을 참조하십시오.

JCE 인증: AWS CloudHSM JCE 제공자는 암시적 로그인과 명시적 로그인을 모두 지원합니다. 사용 사례에 따라 효과가 있는 방법이 다릅니다. 애플리케이션이 클러스터에서 연결이 끊어져 재인증이 필요한 경우 SDK가 자동으로 인증을 처리하므로 가능하면 암시적 로그인을 사용하는 것이 좋습니다. 애플리케이션 코드를 제어할 수 없는 통합을 사용하는 경우에도 암시적 로그인을 사용하면 애플리케이션에 보안 인증 정보를 제공할 수 있습니다. 로그인 방법에 대한 자세한 내용은 JCE 공급자에게 자격 증명을 제공하십시오. 섹션을 참조하십시오.

OpenSSL로 인증: OpenSSL 동적 엔진을 사용하면 환경 변수를 통해 보안 인증 정보를 제공합니다. AWS CloudHSM 는 애플리케이션에서 사용하지 않을 때 HSM 보안 인증 정보를 안전하게 저장할 것을 권장합니다. 가능하면 수동 입력 없이 이러한 환경 변수를 체계적으로 검색하고 설정하도록 환경을 구성해야 합니다. OpenSSL 인증에 대한 자세한 내용은 OpenSSL Dynamic Engine 설치 섹션을 참조하십시오.

애플리케이션의 키를 효과적으로 관리

키 속성을 사용하여 키가 수행할 수 있는 작업 제어: 키를 생성할 때 키 속성을 사용하여 해당 키에 대한 특정 유형의 작업을 허용하거나 거부하는 권한 집합을 정의하십시오. 작업을 완료하는 데 필요한 속성을 최소화하여 키를 생성하는 것이 좋습니다. 예를 들어, 암호화에 사용되는 AES 키는 HSM에서 키를 래핑하는 것도 허용해서는 안 됩니다. 자세한 내용은 다음 클라이언트 SDK의 속성 페이지를 참조하십시오.

가능하면 키 객체를 캐시하여 지연 시간 최소화: 키 찾기 작업은 클러스터의 모든 HSM을 쿼리합니다. 이 작업은 비용이 많이 들고 클러스터의 HSM 수에 따라 확장되지 않습니다.

최적의 성능을 위해 응용 프로그램 시작 중에 키 찾기 명령 (예: findKey 및키 목록) 을 한 번만 사용하고 반환된 키 객체를 응용 프로그램 메모리에 캐시하는 것이 좋습니다. AWS 나중에 이 키 객체가 필요한 경우 각 작업마다 이 객체를 쿼리하여 상당한 성능 오버헤드를 추가하는 대신 캐시에서 객체를 검색해야 합니다.

멀티스레딩 사용

AWS CloudHSM 다중 스레드 응용 프로그램을 지원하지만 다중 스레드 응용 프로그램에서는 몇 가지 유의해야 할 사항이 있습니다.

PKCS #11에서는 PKCS #11 라이브러리(C_Initialize 호출)를 한 번만 초기화해야 합니다. 각 스레드에는 자체 세션(C_OpenSession)을 할당해야 합니다. 다중 스레드에서 동일한 세션을 사용하는 것은 권장되지 않습니다.

JCE에서는 제공자를 한 번만 초기화해야 합니다. AWS CloudHSM 스레드 간에 SPI 객체 인스턴스를 공유하지 마십시오. 예를 들어 암호, 서명, 다이제스트, Mac KeyFactory 또는 KeyGenerator 객체는 해당 스레드의 컨텍스트에서만 사용해야 합니다.

제한 오류 처리

다음과 같은 상황에서 HSM 제한 오류가 발생할 수 있습니다.

이 시나리오를 가장 잘 처리하는 방법에 대한 내용은 HSM 스로틀링 섹션을 참조하십시오.

클러스터 크기가 적절하고 병목 현상이 발생하지 않도록 하려면 최대 트래픽이 예상되는 환경에서 AWS 부하 테스트를 수행하는 것이 좋습니다.

클러스터 작업에 재시도 통합

AWS 운영 또는 유지 관리상의 이유로 HSM을 교체할 수 있습니다. 이러한 상황에서 애플리케이션을 복원할 수 있도록 하려면 클러스터로 라우팅되는 모든 작업에 대해 클라이언트측 재시도 로직을 구현할 AWS 것을 권장합니다. 교체로 인해 실패한 작업에 대한 후속 재시도는 성공할 것으로 예상됩니다.

재해 복구 전략 구현

이벤트에 대응하여 전체 클러스터 또는 리전에서 트래픽을 이동해야 할 수도 있습니다. 다음 섹션에서는 이를 수행하기 위한 여러 전략에 대해 설명합니다.

VPC 피어링을 사용하여 다른 계정이나 지역에서 클러스터에 액세스: VPC 피어링을 사용하여 다른 계정이나 지역에서 AWS CloudHSM 클러스터에 액세스할 수 있습니다. 이를 설정하는 방법에 대한 자세한 내용은 VPC 피어링 가이드의 VPC 피어링이란?을 참조하십시오. 피어링 연결을 설정하고 보안 그룹을 적절하게 구성한 후에는 평소와 같은 방식으로 HSM IP 주소와 통신할 수 있습니다.

동일한 애플리케이션에서 여러 클러스터에 연결: 클라이언트 SDK 5의 JCE 공급자, PKCS #11 라이브러리 및 CloudHSM CLI는 동일한 애플리케이션에서 여러 클러스터에 연결할 수 있도록 지원합니다. 예를 들어, 각각 다른 리전에 두 개의 활성 클러스터를 둘 수 있으며, 애플리케이션은 두 가지 모두에 동시에 연결하여 일반 작업의 일부로 둘 사이의 로드 밸런싱을 수행할 수 있습니다. 애플리케이션에서 Client SDK 5(최신 SDK)를 사용하지 않는 경우 동일한 애플리케이션에서 여러 클러스터에 연결할 수 없습니다. 또는 다른 클러스터를 계속 실행하고, 리전 중단이 발생하는 경우 트래픽을 다른 클러스터로 이동하여 가동 중지를 최소화할 수 있습니다. 자세한 내용은 각 페이지를 참조하십시오.

백업에서 클러스터 복원: 기존 클러스터의 백업에서 새 클러스터를 생성할 수 있습니다. 자세한 내용은 AWS CloudHSM 백업 관리 섹션을 참조하십시오.

모니터링

이 섹션에서는 클러스터와 애플리케이션을 모니터링하는 데 사용할 수 있는 여러 메커니즘에 대해 설명합니다. 모니터링에 대한 자세한 내용은 모니터링 AWS CloudHSM 섹션을 참조하십시오.

클라이언트 로그 모니터링

모든 클라이언트 SDK는 모니터링할 수 있는 로그를 작성합니다. 클라이언트 로깅에 대한 자세한 내용은 클라이언트 SDK 로그로 작업 섹션을 참조하십시오.

Amazon ECS와 AWS Lambda같이 일시용으로 설계된 플랫폼에서는 파일에서 클라이언트 로그를 수집하기가 어려울 수 있습니다. 이러한 상황에서는 콘솔에 로그를 기록하도록 클라이언트 SDK 로깅을 구성하는 것이 좋습니다. 대부분의 서비스는 이 출력을 자동으로 수집하여 Amazon CloudWatch 로그에 게시하여 사용자가 보관하고 볼 수 있도록 합니다.

AWS CloudHSM 클라이언트 SDK에서 타사 통합을 사용하는 경우 출력을 콘솔에도 기록하도록 해당 소프트웨어 패키지를 구성해야 합니다. AWS CloudHSM 클라이언트 SDK의 출력은 이 패키지에서 캡처되고 그렇지 않으면 자체 로그 파일에 기록될 수 있습니다.

애플리케이션에서 로깅 옵션을 구성하는 방법에 대한 자세한 내용은 클라이언트 SDK 5 구성 도구 섹션을 참조하십시오.

감사 로그 모니터링

AWS CloudHSM Amazon CloudWatch 계정에 감사 로그를 게시합니다. 감사 로그는 HSM에서 가져오며 감사 목적으로 특정 작업을 추적합니다.

감사 로그를 사용하여 HSM에서 호출되는 모든 관리 명령을 추적할 수 있습니다. 예를 들어, 예상치 못한 관리 작업이 수행되고 있는 것을 발견하면 경보를 트리거할 수 있습니다.

자세한 내용은 HSM 감사 로깅 작동 방식 섹션을 참조하십시오.

모니터 AWS CloudTrail

AWS CloudHSM 에서 사용자 AWS CloudTrail, 역할 또는 서비스가 수행한 작업의 기록을 제공하는 AWS 서비스와 통합됩니다 AWS CloudHSM. AWS CloudTrail 모든 API 호출을 AWS CloudHSM 이벤트로 캡처합니다. 캡처된 호출에는 AWS CloudHSM 콘솔에서의 호출 및 AWS CloudHSM API 작업에 대한 코드 호출이 포함됩니다.

AWS CloudTrail 를 사용하면 AWS CloudHSM 컨트롤 플레인에 대한 모든 API 호출을 감사하여 계정에서 원치 않는 활동이 발생하지 않도록 할 수 있습니다.

세부 정보는 AWS CloudTrail 와 함께 일하기 AWS CloudHSM를 참조하세요.

아마존 CloudWatch 지표 모니터링

Amazon CloudWatch 메트릭을 사용하여 AWS CloudHSM 클러스터를 실시간으로 모니터링할 수 있습니다. 지표는 리전, 클러스터 ID 또는 HSM ID 및 클러스터 ID별로 그룹화할 수 있습니다.

Amazon CloudWatch 지표를 사용하면 서비스에 영향을 미칠 수 있는 잠재적 문제를 경고하도록 Amazon CloudWatch 경보를 구성할 수 있습니다. 다음을 모니터링하도록 경보를 구성하는 것이 좋습니다.

자세한 내용은 Amazon CloudWatch 로그 및 AWS CloudHSM 감사 로그 사용 섹션을 참조하십시오.