기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 타사 애플리케이션을와 통합 AWS CloudHSM
의 일부 [사용 사례에](use-cases.md) AWS CloudHSM 는 타사 소프트웨어 애플리케이션을 AWS CloudHSM 클러스터의 HSM과 통합하는 것이 포함됩니다. 타사 소프트웨어를와 통합하면 다양한 보안 관련 목표를 달성할 AWS CloudHSM수 있습니다. 다음 주제에서는 이러한 목표 일부를 달성하는 방법에 대해 설명합니다.
**Topics**
+ [SSL/TLS 오프로드](ssl-offload.md)
+ [Windows Server CA](third-ca-toplevel.md)
+ [Oracle Database 암호화](oracle-tde.md)
+ [Microsoft SignTool](third-signtool-toplevel.md)
+ [Java Keytool 및 Jarsigner](third_java-sdk_integration.md)
+ [Microsoft 매니페스트 생성 및 편집 도구](third-magetool.md)
+ [기타 타사 벤더 통합](other-integrations.md)
# 에서 SSL/TLS 오프로드로 웹 서버 보안 개선 AWS CloudHSM
웹 서버와 해당 클라이언트(웹 브라우저)는 SSL(Secure Sockets Layer) 또는 TLS(전송 계층 보안) 프로토콜을 사용하여 웹 서버의 ID를 확인하고 인터넷을 통해 웹 페이지 또는 기타 데이터를 송수신하는 보안 연결을 설정할 수 있습니다. 이를 일반적으로 HTTPS라고 합니다. 웹 서버는 퍼블릭-프라이빗 키 페어 및 SSL/TLS 퍼블릭 키 인증서를 사용하여 각 클라이언트에 HTTPS 세션을 설정합니다. 이 프로세스에는 웹 서버에 대한 많은 계산이 포함되지만 SSL 가속화라고 하는 AWS CloudHSM 클러스터로이 중 일부를 오프로드할 수 있습니다. 오프로드를 사용하면 웹 서버의 컴퓨팅 부담을 줄일 수 있으며 서버의 프라이빗 키를 HSM에 저장하여 보안을 강화할 수 있습니다.
다음 주제에서는의 SSL/TLS 오프로드 AWS CloudHSM 작동 방식에 대한 개요와 AWS CloudHSM 다음 플랫폼에서의 SSL/TLS 오프로드를 설정하기 위한 자습서를 제공합니다.
**Linux**의 경우 [NGINX](https://nginx.org/en/) 또는 [Apache HTTP Server](https://httpd.apache.org/) 웹 서버 소프트웨어에서 OpenSSL Dynamic Engine 사용
**Windows**의 경우 [Windows Server용 IIS(인터넷 정보 서비스)](https://www.iis.net/) 웹 서버 소프트웨어 사용
**Topics**
+ [에서 SSL/TLS 오프로드 AWS CloudHSM 작동 방식](ssl-offload-overview.md)
+ [AWS CloudHSM NGINX 또는 Apache with OpenSSL을 사용하는 Linux의 SSL/TLS 오프로드](third-offload-linux-openssl.md)
+ [AWS CloudHSM OpenSSL 공급자와 함께 NGINX 또는 HAProxy를 사용하여 Linux에서 SSL/TLS 오프로드](third-offload-linux-openssl-provider.md)
+ [AWS CloudHSM JSSE와 함께 Tomcat을 사용하는 Linux에서의 SSL/TLS 오프로드](third-offload-linux-jsse.md)
+ [AWS CloudHSM KSP와 함께 IIS를 사용하여 Windows에서 SSL/TLS 오프로드](ssl-offload-windows.md)
+ [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md)
# 에서 SSL/TLS 오프로드 AWS CloudHSM 작동 방식
HTTPS 연결을 설정하기 위해 웹 서버는 클라이언트와의 핸드섀이크 프로세스를 수행합니다. 이 프로세스의 일환으로 서버는 다음 그림과 같이 일부 암호화 처리를 AWS CloudHSM 클러스터의 HSMs으로 오프로드합니다. 프로세스의 각 단계는 그림 아래 설명되어 있습니다.
**참고**
다음 이미지와 프로세스는 서버 확인 및 키 교환에 RSA가 사용된다고 가정합니다. RSA 대신 Diffie-Hellman을 사용하는 경우 프로세스가 약간 다릅니다.
![\[HSM으로 암호화 오프로드를 포함하여 클라이언트와 서버 간 TLS 핸드섀이크 프로세스를 보여 주는 그림\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/ssl-offload-handshake-process.png)
1. 클라이언트가 서버에 hello 메시지를 전송합니다.
1. 서버는 hello 메시지로 응답하고 서버의 인증서를 전송합니다.
1. 클라이언트는 다음 작업을 수행합니다.
1. 클라이언트가 신뢰하는 루트 인증서로 SSL/TLS 서버의 인증서가 서명되어 있는지 확인합니다.
1. 서버 인증서에서 퍼블릭 키를 추출합니다.
1. pre-master 시크릿을 생성하여 서버의 퍼블릭 키로 암호화합니다.
1. 암호화된 pre-master 시크릿을 서버로 전송합니다.
1. 클라이언트의 pre-master 시크릿을 복호화하기 위해 서버가 이를 HSM에 전송합니다. HSM은 HSM에 있는 프라이빗 키를 사용하여 pre-master 시크릿을 암호화 해제한 다음 pre-master 시크릿을 서버로 전송합니다. 클라이언트와 서버는 각각 독립적으로 pre-master 시크릿과 hello 메시지의 일부 정보를 사용하여 마스터 시크릿을 계산합니다.
1. 핸드섀이크 프로세스가 종료됩니다. 세션의 나머지에서는 클라이언트와 서버 사이에서 전송되는 모든 메시지가 master secret의 파생문으로 암호화됩니다.
를 사용하여 SSL/TLS 오프로드를 구성하는 방법을 알아보려면 다음 주제 중 하나를 AWS CloudHSM참조하세요.
+ [AWS CloudHSM NGINX 또는 Apache with OpenSSL을 사용하는 Linux의 SSL/TLS 오프로드](third-offload-linux-openssl.md)
+ [AWS CloudHSM JSSE와 함께 Tomcat을 사용하는 Linux에서의 SSL/TLS 오프로드](third-offload-linux-jsse.md)
+ [AWS CloudHSM KSP와 함께 IIS를 사용하여 Windows에서 SSL/TLS 오프로드](ssl-offload-windows.md)
# AWS CloudHSM NGINX 또는 Apache with OpenSSL을 사용하는 Linux의 SSL/TLS 오프로드
이 주제는 Linux 웹 서버에서 AWS CloudHSM 을 사용하여 SSL/TLS 오프로드를 설정하기 위한 단계별 지침을 제공합니다.
**Topics**
+ [개요](#ssl-offload-linux-openssl-overview)
+ [1단계: 사전 조건 설정](#ssl-offload-prerequisites)
+ [2단계: 프라이빗 키 및 SSL/TLS 인증서 생성](#ssl-offload-import-or-generate-private-key-and-certificate)
+ [3단계: 웹 서버 구성하기](#ssl-offload-configure-web-server)
+ [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate)
## 개요
Linux에서는 HTTPS를 지원하기 위해 [NGINX](https://nginx.org/en/) 및 [Apache HTTP Server](https://httpd.apache.org/) 웹 서버 소프트웨어가 [OpenSSL](https://www.openssl.org/)에 통합되어 있습니다. [OpenSSL용AWS CloudHSM Dynamic Engine](openssl-library.md)은 웹 서버 소프트웨어가 암호화 오프로딩 및 키 스토리지를 위해 클러스터에서 HSM을 사용할 수 있도록 인터페이스를 제공합니다. OpenSSL 엔진은 웹 서버를 AWS CloudHSM 클러스터에 연결하는 브리지입니다.
이 자습서를 완료하려면 Linux에서 NGINX 웹 서버 소프트웨어를 사용할지, Apache 웹 서버 소프트웨어를 사용할지 먼저 선택해야 합니다. 그런 다음 이 자습서에서는 다음을 수행하는 방법을 보여줍니다.
+ Amazon EC2 인스턴스에 웹 서버 소프트웨어를 설치합니다.
+ AWS CloudHSM 클러스터에 프라이빗 키가 저장되는 HTTPS를 지원하도록 웹 서버 소프트웨어를 구성합니다.
+ (선택 사항) Amazon EC2를 사용하여 두 번째 웹 서버 인스턴스를 만들고 Elastic Load Balancing을 사용하여 로드 밸런서를 만듭니다. 로드 밸런서를 사용하면 여러 서버에 부하를 분산하여 성능을 향상할 수 있습니다. 또한 하나 이상의 서버에 장애가 발생할 경우 중복성과 더 높은 가용성을 제공할 수 있습니다.
시작할 준비가 되면 [1단계: 사전 조건 설정](#ssl-offload-prerequisites)로 이동합니다.
## 1단계: 사전 조건 설정
플랫폼마다 필요한 필수 조건이 다릅니다. 플랫폼에 맞는 아래의 사전 조건 섹션을 사용하세요.
### 클라이언트 SDK 사전 조건 5
클라이언트 SDK 5으로 웹 서버 SSL/TLS 오프로드를 설정하려면 다음이 필요합니다.
+ 하드웨어 보안 모듈(HSM)이 2개 이상 있는 활성 AWS CloudHSM 클러스터
**참고**
단일 HSM 클러스터를 사용할 수 있지만 먼저 클라이언트 키 내구성을 비활성화해야 합니다. 자세한 내용은 [클라이언트 키 내구성 설정 관리](working-client-sync.md#client-sync-sdk8) 및 [클라이언트 SDK 5 구성](configure-sdk-5.md) 도구를 참조하세요.
+ 다음 소프트웨어가 설치된 Linux 운영 체제를 실행하는 Amazon EC2 인스턴스.
+ 웹 서버(NGINX 또는 아파치)
+ 클라이언트 SDK 5용 OpenSSL Dynamic Engine
+ HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다.
**HSM에서 Linux 웹 서버 인스턴스를 설정하고 CU를 생성하려면**
1. 용 OpenSSL Dynamic Engine을 설치하고 구성합니다 AWS CloudHSM. OpenSSL 동적 엔진 설치에 대한 자세한 내용은 [클라이언트용 OpenSSL 동적 엔진 SDK 5](openssl5-install.md)를 참조하세요.
1. 클러스터에 액세스할 수 있는 EC2 Linux 인스턴스에서 NGINX 또는 Apache 웹 서버를 설치하세요.
------
#### [ Amazon Linux 2 ]
+ Amazon Linux 2에서 최신 버전의 NGINX를 다운로드하는 방법에 대한 자세한 내용은 [NGINX 웹 사이트](https://nginx.org/en/linux_packages.html)를 참조하세요.
Amazon Linux 2에서 사용할 수 있는 NGINX의 최신 버전은 OpenSSL의 시스템 버전보다 최신 버전의 OpenSSL을 사용합니다. NGINX를 설치한 후 AWS CloudHSM OpenSSL Dynamic Engine 라이브러리에서이 버전의 OpenSSL에 필요한 위치로의 심볼 링크를 생성해야 합니다.
```
$ sudo ln -sf /opt/cloudhsm/lib/libcloudhsm_openssl_engine.so /usr/lib64/engines-1.1/cloudhsm.so
```
+ Apache
```
$ sudo yum install httpd mod_ssl
```
------
#### [ Amazon Linux 2023 ]
+ NGINX
```
$ sudo yum install nginx
```
+ Apache
```
$ sudo yum install httpd mod_ssl
```
------
#### [ Red Hat 8 ]
+ NGINX
```
$ sudo yum install nginx
```
+ Apache
```
$ sudo yum install httpd mod_ssl
```
------
#### [ Red Hat 9 ]
+ NGINX
```
$ sudo yum install nginx
```
+ Apache
```
$ sudo yum install httpd mod_ssl
```
------
#### [ Ubuntu 22.04 ]
+ NGINX
```
$ sudo apt install nginx
```
+ Apache
```
$ sudo apt install apache2
```
------
#### [ Ubuntu 24.04 ]
+ NGINX
```
$ sudo apt install nginx
```
+ Apache
```
$ sudo apt install apache2
```
------
1. CloudHSM CLI를 사용하여 [Crypto User](understanding-users.md#crypto-user-chsm-cli)를 생성합니다. HSM 사용자 관리에 대한 자세한 내용은 [CloudHSM CLI를 사용한 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오.
**작은 정보**
CU의 사용자 이름과 암호를 기록합니다. 나중에 웹 서버용 HTTPS 프라이빗 키와 인증서를 생성하거나 가져올 때 이 정보가 필요합니다.
이 단계들을 완료한 후 [2단계: 프라이빗 키 및 SSL/TLS 인증서 생성](#ssl-offload-import-or-generate-private-key-and-certificate)로 이동합니다.
#### 참고
+ 보안이 강화된 리눅스(SELinux) 및 웹 서버를 사용하려면 클라이언트 SDK 5가 HSM과 통신하는 데 사용하는 포트인 포트 2223에서 아웃바운드 TCP 연결을 허용해야 합니다.
+ 클러스터를 생성 및 활성화하고 EC2 인스턴스에 클러스터 액세스 권한을 부여하려면 [AWS CloudHSM시작하기](getting-started.md)의 단계를 완료하십시오. 시작하기에서는 HSM 1개와 Amazon EC2 클라이언트 인스턴스 1개로 활성 클러스터를 생성하는 방법에 대한 단계별 지침을 제공합니다. 이 클라이언트 인스턴스를 웹 서버로 사용할 수 있습니다.
+ 클라이언트 키 내구성을 비활성화하지 않으려면 클러스터에 HSM을 두 개 이상 추가하십시오. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오.
+ SSH 또는 PuTTY를 사용하여 클라이언트 인스턴스에 연결할 수 있습니다. 자세한 정보는 Amazon EC2 설명서의 [SSH를 사용하여 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)과 [PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) 단원을 참조하세요.
## 2단계: 프라이빗 키 및 SSL/TLS 인증서 생성
HTTPS를 활성화하려면 웹 서버 애플리케이션(NGINX 또는 Apache)에 프라이빗 키와 해당 SSL/TLS 인증서가 필요합니다. 에서 웹 서버 SSL/TLS 오프로드를 사용하려면 AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장 AWS CloudHSM해야 합니다. 먼저 프라이빗 키를 생성한 후 해당 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. 그런 다음 HSM에서 *가짜 PEM 프라이빗 키*를 내보냅니다. 즉 HSM에 저장된 프라이빗 키에 대한 참조를 포함하는 PEM 형식의 프라이빗 키 파일입니다(실제 프라이빗 키가 아님). 웹 서버는 SSL/TLS 오프로드 중에 가짜 PEM 프라이빗 키 파일을 사용하여 HSM의 프라이빗 키를 식별합니다.
### 프라이빗 키 및 인증서 생성
#### 프라이빗 키 생성
이 섹션에서는 [CloudHSM CLI](cloudhsm_cli.md)를 사용하여 키 페어를 생성하는 방법을 보여줍니다. HSM 내부에 키 페어가 생성되면 이를 가짜 PEM 파일로 내보내고 해당 인증서를 생성할 수 있습니다.
**CloudHSM CLI 설치 및 구성**
1. CloudHSM CLI를 [설치 및 구성](cloudhsm_cli-getting-started.md)합니다.
1. 다음 명령을 사용하여 CloudHSM CLI를 시작합니다.
```
$ /opt/cloudhsm/bin/cloudhsm-cli interactive
```
1. 다음 명령을 실행하여 HSM에 로그인합니다. **을 Crypto User의 사용자 이름으로 변경
```
Command: login --username --role crypto-user
```
**프라이빗 키 생성**
사용 사례에 따라 RSA 또는 EC 키 페어를 생성할 수 있습니다. 다음 중 하나를 수행하십시오.
+ HSM에서 RSA 프라이빗 키를 생성하려면
[`key generate-asymmetric-pair rsa`](cloudhsm_cli-key-generate-asymmetric-pair-rsa.md) 명령을 사용하여 RSA 키 페어를 생성합니다. 이 예제에서는 모듈러스가 2048, 퍼블릭 지수가 65537, 퍼블릭 키 레이블이 *tls\$1rsa\$1pub*, 프라이빗 키 레이블이 *tls\$1rsa\$1private*인 RSA 키 페어를 생성합니다.
```
aws-cloudhsm > key generate-asymmetric-pair rsa \
--public-exponent 65537 \
--modulus-size-bits 2048 \
--public-label tls_rsa_pub \
--private-label tls_rsa_private \
--private-attributes sign=true
{
"error_code": 0,
"data": {
"public_key": {
"key-reference": "0x0000000000280cc8",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "full"
},
"attributes": {
"key-type": "rsa",
"label": "tls_rsa_pub",
"id": "",
"check-value": "0x01fe6e",
"class": "public-key",
"encrypt": true,
"decrypt": false,
"token": true,
"always-sensitive": false,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": false,
"sign": false,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 512,
"public-exponent": "0x010001",
"modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c
73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634d
f6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc
133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0ac
ac3160f0ca9725d38318b7",
"modulus-size-bits": 2048
}
},
"private_key": {
"key-reference": "0x0000000000280cc7",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "full"
},
"attributes": {
"key-type": "rsa",
"label": "tls_rsa_private",
"id": "",
"check-value": "0x01fe6e",
"class": "private-key",
"encrypt": false,
"decrypt": true,
"token": true,
"always-sensitive": true,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": true,
"sign": true,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 1217,
"public-exponent": "0x010001",
"modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634df6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0acac3160f0ca9725d38318b7",
"modulus-size-bits": 2048
}
}
}
}
```
+ HSM에서 EC 프라이빗 키를 생성하려면
[`key generate-asymmetric-pair ec`](cloudhsm_cli-key-generate-asymmetric-pair-ec.md) 명령을 사용하여 EC 키 페어를 생성합니다. 이 예제에서는 `prime256v1` 곡선(`NID_X9_62_prime256v1` 곡선에 해당)에 기반하여 퍼블릭 키 레이블이 *tls\$1ec\$1pub*, 프라이빗 키 레이블이 *tls\$1ec\$1private*인 EC 키 페어를 생성합니다.
```
aws-cloudhsm > key generate-asymmetric-pair ec \
--curve prime256v1 \
--public-label tls_ec_pub \
--private-label tls_ec_private \
--private-attributes sign=true
{
"error_code": 0,
"data": {
"public_key": {
"key-reference": "0x000000000012000b",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "session"
},
"attributes": {
"key-type": "ec",
"label": "tls_ec_pub",
"id": "",
"check-value": "0xd7c1a7",
"class": "public-key",
"encrypt": false,
"decrypt": false,
"token": false,
"always-sensitive": false,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": false,
"sign": false,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 57,
"ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c",
"curve": "secp224r1"
}
},
"private_key": {
"key-reference": "0x000000000012000c",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "session"
},
"attributes": {
"key-type": "ec",
"label": "tls_ec_private",
"id": "",
"check-value": "0xd7c1a7",
"class": "private-key",
"encrypt": false,
"decrypt": false,
"token": false,
"always-sensitive": true,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": true,
"sign": true,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 122,
"ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c",
"curve": "secp224r1"
}
}
}
}
```
**가짜 PEM 프라이빗 키 파일 내보내기**
HSM에 프라이빗 키가 있으면 가짜 PEM 프라이빗 키 파일을 내보내야 합니다. 이 파일에은 실제 키 데이터가 포함하지 않지만 OpenSSL 동적 엔진이 HSM의 프라이빗 키를 식별할 수 있도록 해줍니다. 그런 다음 프라이빗 키를 사용하여 CSR(인증서 서명 요청)을 생성하고 CSR에 서명하여 인증서를 생성할 수 있습니다.
[`key generate-file`](cloudhsm_cli-key-generate-file.md) 명령을 실행하여 가짜 PEM 형식의 프라이빗 키를 내보내고 파일에 저장합니다. 다음 값을 사용자의 값으로 대체합니다.
+ ** - 이전 단계에서 생성한 프라이빗 키의 레이블입니다.
+ ** - 가짜 PEM 키가 기록될 파일의 이름입니다.
```
aws-cloudhsm > key generate-file --encoding reference-pem --path --filter attr.label=
{
"error_code": 0,
"data": {
"message": "Successfully generated key file"
}
}
```
**CloudHSM CLI 종료**
다음 명령을 실행하여 CloudHSM CLI를 종료합니다.
```
aws-cloudhsm > quit
```
이제 이전 명령에서 **로 지정된 경로에, 시스템에 새 파일이 있어야 합니다. 이 파일은 가짜 PEM 프라이빗 키 파일입니다.
#### 자체 사인된 인증서를 생성합니다.
가짜 PEM 프라이빗 키를 생성한 후에는 이 파일을 사용하여 인증서 사인 요청(CSR) 및 인증서를 생성할 수 있습니다.
프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우 CA에 CSR 파일을 보내고 CA가 웹 서버에서 HTTPS용으로 제공하는 서명된 SSL/TLS 인증서를 사용하세요.
CA를 사용하는 대신 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 자체 서명된 인증서를 생성할 수 있습니다. 자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다.
**주의**
자체 사인된 인증서는 테스트 환경에서만 사용해야 합니다. 프로덕션 환경의 경우 인증 기관과 같은 추가 보안 방법을 사용하여 인증서를 생성하십시오.
**OpenSSL Dynamic Engine 설치 및 구성**
1. 클라이언트 인스턴스에 연결합니다.
1. [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL Dynamic Engine 설치](openssl5-install.md)
**인증서 생성**
1. 이전 단계에서 생성한 가짜 PEM 파일의 사본을 확보하세요.
1. CSR 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 인증서 서명 요청(CSR)을 생성합니다. **를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다. **을 CSR이 포함된 파일의 이름으로 바꿉니다.
`req` 명령은 대화식입니다. 각 필드에 응답합니다. 필드 정보가 SSL/TLS 인증서에 복사됩니다.
```
$ openssl req -engine cloudhsm -new -key -out
```
1. 자체 서명된 인증서 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 HSM의 프라이빗 키로 CSR에 서명합니다. 이렇게 하면 자체 사인된 인증서가 생성됩니다. 명령의 다음 값을 사용자의 값으로 바꿉니다.
+ ** – CSR이 포함된 파일 이름
+ ** – 가짜 PEM 프라이빗 키가 포함된 파일 이름
+ ** – 웹 서버 인증서가 포함될 파일 이름
```
$ openssl x509 -engine cloudhsm -req -days 365 -in -signkey -out
```
이 단계들을 완료한 후 [3단계: 웹 서버 구성하기](#ssl-offload-configure-web-server)로 이동합니다.
## 3단계: 웹 서버 구성하기
[이전 단계](#ssl-offload-import-or-generate-private-key-and-certificate)에서 생성한 HTTPS 인증서와 이에 해당되는 가짜 PEM 프라이빗 키를 사용하려면 웹 서버 소프트웨어의 구성을 업데이트하십시오. 시작하기 전에 기존 인증서와 키를 백업해야 한다는 점을 잊지 마십시오. 그러면 AWS CloudHSM이 지원되는 SSL/TLS 오프로드의 Linux 웹 서버 소프트웨어 설정이 완료됩니다.
다음 섹션 중 하나에 있는 단계를 완료합니다.
**Topics**
+ [NGINX 웹 서버를 구성합니다](#ssl-offload-nginx)
+ [Apache 웹 서버 구성하기](#ssl-offload-apache)
### NGINX 웹 서버를 구성합니다
이 섹션을 사용하여 지원되는 플랫폼에서 NGINX를 구성합니다.
**NGINX용 웹 서버 구성을 업데이트하려면**
1. 클라이언트 인스턴스에 연결합니다.
1. 다음 명령을 실행하여 웹 서버 인증서 및 가짜 PEM 프라이빗 키에 필요한 디렉터리를 생성합니다.
```
$ sudo mkdir -p /etc/pki/nginx/private
```
1. 다음 명령을 실행하여 웹 서버 인증서를 필요한 위치에 복사합니다. **를 웹 서버 인증서 이름으로 바꿉니다.
```
$ sudo cp /etc/pki/nginx/server.crt
```
1. 다음 명령을 실행하여 가짜 PEM 프라이빗 키를 필요한 위치에 복사합니다. **를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
```
$ sudo cp /etc/pki/nginx/private/server.key
```
1. 다음 명령을 실행하여 *nginx*라는 이름의 사용자가 파일을 읽을 수 있도록 파일 소유권을 변경합니다.
```
$ sudo chown nginx /etc/pki/nginx/server.crt /etc/pki/nginx/private/server.key
```
1. 다음 명령을 실행하여 `/etc/nginx/nginx.conf` 파일을 백업합니다.
```
$ sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
```
1. NGINX 구성을 업데이트합니다.
**참고**
각 클러스터는 모든 NGINX 웹 서버에서 최대 1000개의 NGINX 작업자 프로세스를 지원할 수 있습니다.
------
#### [ Amazon Linux 2 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Amazon Linux 2023 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Red Hat 8 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Red Hat 9 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Ubuntu 22.04 LTS ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Ubuntu 24.04 LTS ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다. 파일의 맨 위에 다음 행을 추가합니다.
```
ssl_engine cloudhsm;
env CLOUDHSM_PIN;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
#ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA";
ssl_prefer_server_ciphers on;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
파일을 저장합니다.
1. `systemd` 구성 파일을 백업한 후, `EnvironmentFile` 경로를 설정합니다.
------
#### [ Amazon Linux 2 ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 후, [서비스] 섹션 아래에 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Amazon Linux 2023 ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 다음 [서비스] 섹션에서 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Red Hat 8 ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 후, [서비스] 섹션 아래에 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Red Hat 9 ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 후, [서비스] 섹션 아래에 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Ubuntu 22.04 LTS ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 후, [서비스] 섹션 아래에 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Ubuntu 24.04 LTS ]
1. `nginx.service` 파일을 백업합니다.
```
$ sudo cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service` 파일을 연 후, [서비스] 섹션 아래에 다음 경로를 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
1. `/etc/sysconfig/nginx` 파일이 있는지 여부를 확인한 후, 다음 중 하나를 수행합니다.
+ 파일이 있는 경우 다음 명령을 실행하여 파일을 백업합니다.
```
$ sudo cp /etc/sysconfig/nginx /etc/sysconfig/nginx.backup
```
+ 파일이 없는 경우 텍스트 편집기를 연 후 `/etc/sysconfig/` 폴더에 `nginx`라는 파일을 생성합니다.
1. NGINX 환경을 구성합니다.
**참고**
클라이언트 SDK 5는 CU의 자격 증명을 저장하기 위한 `CLOUDHSM_PIN` 환경 변수를 도입합니다.
------
#### [ Amazon Linux 2 ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
#### [ Amazon Linux 2023 ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
#### [ Red Hat 8 ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
#### [ Red Hat 9 ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
#### [ Ubuntu 22.04 LTS ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
#### [ Ubuntu 24.04 LTS ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 이때 Linux 루트 권한이 필요합니다. 암호화 사용자(Cryptography User) 자격 증명 추가하기:
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
파일을 저장합니다.
------
1. NGINX 웹 서버를 시작합니다.
------
#### [ Amazon Linux 2 ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ sudo systemctl start nginx
```
------
#### [ Amazon Linux 2023 ]
모든 NGINX 프로세스 중지
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 시작
```
$ sudo systemctl start nginx
```
------
#### [ Red Hat 8 ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ sudo systemctl start nginx
```
------
#### [ Red Hat 9 ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ sudo systemctl start nginx
```
------
#### [ Ubuntu 22.04 LTS ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ sudo systemctl start nginx
```
------
#### [ Ubuntu 24.04 LTS ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ sudo systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ sudo systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ sudo systemctl start nginx
```
------
1. (선택 사항) 시작 시 NGINX를 시작하도록 플랫폼을 구성합니다.
------
#### [ Amazon Linux 2 ]
```
$ sudo systemctl enable nginx
```
------
#### [ Amazon Linux 2023 ]
```
$ sudo systemctl enable nginx
```
------
#### [ Red Hat 8 ]
```
$ sudo systemctl enable nginx
```
------
#### [ Red Hat 9 ]
```
$ sudo systemctl enable nginx
```
------
#### [ Ubuntu 22.04 LTS ]
```
$ sudo systemctl enable nginx
```
------
#### [ Ubuntu 24.04 LTS ]
```
$ sudo systemctl enable nginx
```
------
웹 서버 구성을 업데이트한 후에 [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate) 단원으로 이동합니다.
### Apache 웹 서버 구성하기
이 섹션을 사용하여 지원되는 플랫폼에서 Apache를 구성합니다.
**Apache용 웹 서버 구성을 업데이트하려면**
1. Amazon EC2 클라이언트 인스턴스에 연결합니다.
1. 플랫폼의 인증서 및 프라이빗 키의 기본 위치를 정의하십시오.
------
#### [ Amazon Linux 2 ]
`/etc/httpd/conf.d/ssl.conf` 파일에 다음 값이 존재하는지 확인하십시오.
```
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
------
#### [ Amazon Linux 2023 ]
`/etc/httpd/conf.d/ssl.conf` 파일에 다음 값이 있는지 확인합니다.
```
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
------
#### [ Red Hat 8 ]
`/etc/httpd/conf.d/ssl.conf` 파일에 다음 값이 존재하는지 확인하십시오.
```
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
------
#### [ Red Hat 9 ]
`/etc/httpd/conf.d/ssl.conf` 파일에 다음 값이 존재하는지 확인하십시오.
```
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
------
#### [ Ubuntu 22.04 LTS ]
`/etc/apache2/sites-available/default-ssl.conf` 파일에 다음 값이 존재하는지 확인하십시오.
```
SSLCertificateFile /etc/ssl/certs/localhost.crt
SSLCertificateKeyFile /etc/ssl/private/localhost.key
```
------
#### [ Ubuntu 24.04 LTS ]
`/etc/apache2/sites-available/default-ssl.conf` 파일에 다음 값이 존재하는지 확인하십시오.
```
SSLCertificateFile /etc/ssl/certs/localhost.crt
SSLCertificateKeyFile /etc/ssl/private/localhost.key
```
------
1. 웹 서버 인증서를 플랫폼의 필수 위치에 복사하십시오.
------
#### [ Amazon Linux 2 ]
```
$ sudo cp /etc/pki/tls/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
#### [ Amazon Linux 2023 ]
```
$ sudo cp /etc/pki/tls/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
#### [ Red Hat 8 ]
```
$ sudo cp /etc/pki/tls/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
#### [ Red Hat 9 ]
```
$ sudo cp /etc/pki/tls/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
#### [ Ubuntu 22.04 LTS ]
```
$ sudo cp /etc/ssl/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
#### [ Ubuntu 24.04 LTS ]
```
$ sudo cp /etc/ssl/certs/localhost.crt
```
**를 웹 서버 인증서 이름으로 바꿉니다.
------
1. 가짜 PEM 프라이빗 키를 플랫폼에 필요한 위치로 복사합니다.
------
#### [ Amazon Linux 2 ]
```
$ sudo cp /etc/pki/tls/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
#### [ Amazon Linux 2023 ]
```
$ sudo cp /etc/pki/tls/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
#### [ Red Hat 8 ]
```
$ sudo cp /etc/pki/tls/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
#### [ Red Hat 9 ]
```
$ sudo cp /etc/pki/tls/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
#### [ Ubuntu 22.04 LTS ]
```
$ sudo cp /etc/ssl/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
#### [ Ubuntu 24.04 LTS ]
```
$ sudo cp /etc/ssl/private/localhost.key
```
**를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
------
1. 플랫폼에서 필요한 경우 이러한 파일의 소유권을 변경하십시오.
------
#### [ Amazon Linux 2 ]
```
$ sudo chown apache /etc/pki/tls/certs/localhost.crt /etc/pki/tls/private/localhost.key
```
*apache*라는 이름의 사용자에게 읽기 권한을 제공합니다.
------
#### [ Amazon Linux 2023 ]
```
$ sudo chown apache /etc/pki/tls/certs/localhost.crt /etc/pki/tls/private/localhost.key
```
*apache*라는 이름의 사용자에게 읽기 권한을 제공합니다.
------
#### [ Red Hat 8 ]
```
$ sudo chown apache /etc/pki/tls/certs/localhost.crt /etc/pki/tls/private/localhost.key
```
*apache*라는 이름의 사용자에게 읽기 권한을 제공합니다.
------
#### [ Red Hat 9 ]
```
$ sudo chown apache /etc/pki/tls/certs/localhost.crt /etc/pki/tls/private/localhost.key
```
*apache*라는 이름의 사용자에게 읽기 권한을 제공합니다.
------
#### [ Ubuntu 22.04 LTS ]
작업이 필요하지 않습니다.
------
#### [ Ubuntu 24.04 LTS ]
작업이 필요하지 않습니다.
------
1. 플랫폼의 Apache 지시어를 구성합니다.
------
#### [ Amazon Linux 2 ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/httpd/conf.d/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
```
파일을 저장합니다.
------
#### [ Amazon Linux 2023 ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/httpd/conf.d/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
```
파일을 저장합니다.
------
#### [ Red Hat 8 ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/httpd/conf.d/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
SSLProxyCipherSuite HIGH:!aNULL
```
파일을 저장합니다.
------
#### [ Red Hat 9 ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/httpd/conf.d/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
SSLProxyCipherSuite HIGH:!aNULL
```
파일을 저장합니다.
------
#### [ Ubuntu 22.04 LTS ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/apache2/mods-available/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
SSLProtocol TLSv1.2 TLSv1.3
```
파일을 저장합니다.
SSL 모듈 및 기본 SSL 사이트 구성을 활성화합니다.
```
$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
```
------
#### [ Ubuntu 24.04 LTS ]
이 플랫폼의 SSL 파일을 찾으십시오.
```
/etc/apache2/mods-available/ssl.conf
```
이 파일에는 서버 실행 방법을 정의하는 Apache 지시어가 들어 있습니다. 왼쪽에 지시어가 표시되고 그 뒤에 값이 표시됩니다. 텍스트 편집기를 사용하여 이 파일을 편집합니다. 이때 Linux 루트 권한이 필요합니다.
다음 지시어를 다음 값으로 업데이트하거나 입력하십시오.
```
SSLCryptoDevice cloudhsm
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA
SSLProtocol TLSv1.2 TLSv1.3
```
파일을 저장합니다.
SSL 모듈 및 기본 SSL 사이트 구성을 활성화합니다.
```
$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
```
------
1. 플랫폼의 환경 값 파일을 구성합니다.
------
#### [ Amazon Linux 2 ]
httpd 서비스 파일을 엽니다.
```
/lib/systemd/system/httpd.service
```
`[Service]` 섹션 아래에 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/httpd
```
------
#### [ Amazon Linux 2023 ]
httpd 서비스 파일을 엽니다.
```
/lib/systemd/system/httpd.service
```
`[Service]` 섹션 아래에 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/httpd
```
------
#### [ Red Hat 8 ]
httpd 서비스 파일을 엽니다.
```
/lib/systemd/system/httpd.service
```
`[Service]` 섹션 아래에 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/httpd
```
------
#### [ Red Hat 9 ]
httpd 서비스 파일을 엽니다.
```
/lib/systemd/system/httpd.service
```
`[Service]` 섹션 아래에 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/httpd
```
------
#### [ Ubuntu 22.04 LTS ]
작업이 필요하지 않습니다. `/etc/sysconfig/httpd`에 환경 값이 입력됩니다.
------
#### [ Ubuntu 24.04 LTS ]
작업이 필요하지 않습니다. `/etc/sysconfig/httpd`에 환경 값이 입력됩니다.
------
1. 플랫폼의 환경 변수를 저장하는 파일에서 암호화 사용자(cryptographic user)의 자격 증명이 포함된 환경 변수를 설정합니다.
------
#### [ Amazon Linux 2 ]
텍스트 편집기를 사용하여 `/etc/sysconfig/httpd`을 편집합니다.
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
------
#### [ Amazon Linux 2023 ]
텍스트 편집기를 사용하여 `/etc/sysconfig/httpd`을 편집합니다.
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
------
#### [ Red Hat 8 ]
텍스트 편집기를 사용하여 `/etc/sysconfig/httpd`을 편집합니다.
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
**참고**
클라이언트 SDK 5는 CU의 자격 증명을 저장하기 위한 `CLOUDHSM_PIN` 환경 변수를 도입합니다.
------
#### [ Red Hat 9 ]
텍스트 편집기를 사용하여 `/etc/sysconfig/httpd`을 편집합니다.
```
CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
**참고**
클라이언트 SDK 5는 CU의 자격 증명을 저장하기 위한 `CLOUDHSM_PIN` 환경 변수를 도입합니다.
------
#### [ Ubuntu 22.04 LTS ]
텍스트 편집기를 사용하여 `/etc/apache2/envvars`을 편집합니다.
```
export CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
**참고**
클라이언트 SDK 5는 CU의 자격 증명을 저장하기 위한 `CLOUDHSM_PIN` 환경 변수를 도입합니다. 클라이언트 SDK 3에서 CU 자격 증명을 `n3fips_password` 환경 변수에 저장했습니다. 클라이언트 SDK 5는 두 환경 변수를 모두 지원하지만 `CLOUDHSM_PIN`을 사용하는 것이 좋습니다.
------
#### [ Ubuntu 24.04 LTS ]
텍스트 편집기를 사용하여 `/etc/apache2/envvars`을 편집합니다.
```
export CLOUDHSM_PIN=:
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다.
**참고**
클라이언트 SDK 5는 CU의 자격 증명을 저장하기 위한 `CLOUDHSM_PIN` 환경 변수를 도입합니다. 클라이언트 SDK 3에서 CU 자격 증명을 `n3fips_password` 환경 변수에 저장했습니다. 클라이언트 SDK 5는 두 환경 변수를 모두 지원하지만 `CLOUDHSM_PIN`을 사용하는 것이 좋습니다.
------
1. Apache 웹 서버를 시작합니다.
------
#### [ Amazon Linux 2 ]
```
$ sudo systemctl daemon-reload
$ sudo service httpd start
```
------
#### [ Amazon Linux 2023 ]
```
$ sudo systemctl daemon-reload
$ sudo service httpd start
```
------
#### [ Red Hat 8 ]
```
$ sudo systemctl daemon-reload
$ sudo service httpd start
```
------
#### [ Red Hat 9 ]
```
$ sudo systemctl daemon-reload
$ sudo service httpd start
```
------
#### [ Ubuntu 22.04 LTS ]
```
$ sudo service apache2 start
```
------
#### [ Ubuntu 24.04 LTS ]
```
$ sudo service apache2 start
```
------
1. (선택 사항) 시작 시 Apache를 시작하도록 플랫폼을 구성합니다.
------
#### [ Amazon Linux 2 ]
```
$ sudo chkconfig httpd on
```
------
#### [ Amazon Linux 2023 ]
```
$ sudo chkconfig httpd on
```
------
#### [ Red Hat 8 ]
```
$ systemctl enable httpd
```
------
#### [ Red Hat 9 ]
```
$ systemctl enable httpd
```
------
#### [ Ubuntu 22.04 LTS ]
```
$ sudo systemctl enable apache2
```
------
#### [ Ubuntu 24.04 LTS ]
```
$ sudo systemctl enable apache2
```
------
웹 서버 구성을 업데이트한 후에 [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate) 단원으로 이동합니다.
## 4단계: HTTPS 트래픽 활성화 및 인증서 확인하기
를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM.
**Topics**
+ [인바운드 HTTPS 연결 활성화](#ssl-offload-add-security-group-linux)
+ [HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux-enable)
### 인바운드 HTTPS 연결 활성화
클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다.
**HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. **보안 그룹 생성**에서 다음을 수행합니다.
1. **보안 그룹 이름**에 생성하려는 보안 그룹의 이름을 입력합니다.
1. (선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다.
1. 웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 **VPC**로 선택합니다.
1. **규칙 추가**를 선택합니다.
1. 드롭다운 창에서 **HTTPS**를 **유형**으로 선택합니다.
1. **소스**에 소스 위치를 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 탐색 창에서 **인스턴스(Instances)**를 선택합니다.
1. 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
1. 페이지 상단의 **작업** 드롭다운 메뉴를 선택합니다. **보안**을 선택한 다음 **보안 그룹 변경**을 선택합니다.
1. **연결된 보안 그룹**에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 **보안 그룹 추가**를 선택합니다.
1. **저장**을 선택합니다.
### HTTPS가 사용자가 구성한 인증서를 사용하는지 확인
웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\$1client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.
**웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 웹 브라우저를 사용하여 서버의 퍼블릭 DNS 이름 또는 IP 주소를 사용해 웹 서버에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다. 예를 들어 **https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/**입니다.
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
+ Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오.
+ Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
**OpenSSL s\$1client를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다. **을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다.
```
openssl s_client -connect :443
```
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서에서 [Amazon EC2 인스턴스로의 라우팅 트래픽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다.
로드 밸런서를 추가하려면 [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md) 섹션을 참조하십시오.
# AWS CloudHSM OpenSSL 공급자와 함께 NGINX 또는 HAProxy를 사용하여 Linux에서 SSL/TLS 오프로드
이 주제에서는 OpenSSL 공급자와 함께 NGINX 또는 HAProxy AWS CloudHSM 를 사용하여 Linux 웹 서버에서를 사용하여 SSL/TLS 서버 자격 증명 오프로드를 설정하는 step-by-step 지침을 제공합니다.
**Topics**
+ [개요](#ssl-offload-linux-openssl-provider-overview)
+ [1단계: 사전 조건 설정](#ssl-offload-provider-prerequisites)
+ [2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기](#ssl-offload-provider-generate-key-and-certificate)
+ [3단계: 웹 서버 구성하기](#ssl-offload-provider-configure-web-server)
+ [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate-provider)
## 개요
Linux에서는 [NGINX](https://nginx.org/en/) 및 [HAProxy](https://www.haproxy.org/) 웹 서버 소프트웨어가 [OpenSSL](https://www.openssl.org/)과 통합되어 HTTPS를 지원합니다. [AWS CloudHSM OpenSSL 공급자는](openssl-provider-library.md) 웹 서버 소프트웨어가 암호화 오프로드 및 키 스토리지를 위해 클러스터의 HSMs을 사용할 수 있는 인터페이스를 제공합니다. OpenSSL 공급자는 웹 서버를 AWS CloudHSM 클러스터에 연결하는 브리지입니다.
이 자습서를 완료하려면 AWS CloudHSM OpenSSL 공급자를 사용하도록 NGINX 또는 HAProxy를 구성합니다. 이 자습서에서는 다음을 수행하는 방법을 보여줍니다.
+ Amazon EC2 인스턴스에 웹 서버 소프트웨어를 설치합니다.
+ AWS CloudHSM 클러스터에 프라이빗 키가 저장되는 HTTPS를 지원하도록 웹 서버 소프트웨어를 구성합니다.
+ (선택 사항) Amazon EC2를 사용하여 두 번째 웹 서버 인스턴스를 만들고 Elastic Load Balancing을 사용하여 로드 밸런서를 만듭니다. 로드 밸런서를 사용하면 여러 서버에 부하를 분산하여 성능을 향상할 수 있습니다. 또한 하나 이상의 서버에 장애가 발생할 경우 중복성과 더 높은 가용성을 제공할 수 있습니다.
시작할 준비가 되면 [1단계: 사전 조건 설정](#ssl-offload-provider-prerequisites)로 이동합니다.
## 1단계: 사전 조건 설정
플랫폼마다 필요한 필수 조건이 다릅니다. 플랫폼에 맞는 아래의 사전 조건 섹션을 사용하세요.
### AWS CloudHSM OpenSSL 공급자의 사전 조건
클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 사용하여 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 설정하려면 다음이 필요합니다.
+ 하드웨어 보안 모듈(HSM)이 2개 이상 있는 활성 AWS CloudHSM 클러스터
**참고**
단일 HSM 클러스터를 사용할 수 있지만 먼저 클라이언트 키 내구성을 비활성화해야 합니다. 자세한 내용은 [클라이언트 키 내구성 설정 관리](working-client-sync.md#client-sync-sdk8) 및 [클라이언트 SDK 5 구성](configure-sdk-5.md) 도구를 참조하세요.
+ 다음 소프트웨어가 설치된 Linux 운영 체제를 실행하는 Amazon EC2 인스턴스.
+ 웹 서버(NGINX 또는 HAProxy)
+ 클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자
+ HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다.
**HSM에서 Linux 웹 서버 인스턴스를 설정하고 CU를 생성하려면**
**참고**
이 절차의 많은 명령에는 승격된 권한이 필요합니다. 시스템 구성에 따라 루트 사용자로 `sudo` 또는를 사용하여 명령을 실행해야 할 수 있습니다.
1. 클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 설치하고 구성합니다. OpenSSL 공급자 설치에 대한 자세한 내용은 [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자](openssl-provider-install.md)를 참조하세요.
1. 클러스터에 액세스할 수 있는 EC2 Linux 인스턴스에 NGINX 또는 HAProxy 웹 서버를 설치합니다.
------
#### [ Amazon Linux 2023 ]
+ NGINX
```
$ yum install nginx
```
+ HAProxy
```
$ yum install haproxy
```
------
#### [ RHEL 9 (9.2\$1) ]
+ NGINX
```
$ yum install nginx
```
+ HAProxy
```
$ yum install haproxy
```
------
#### [ RHEL 10 (10.0\$1) ]
+ NGINX
```
$ yum install nginx
```
+ HAProxy
```
$ yum install haproxy
```
------
#### [ Ubuntu 24.04 ]
+ NGINX
```
$ apt install nginx
```
+ HAProxy
```
$ apt install haproxy
```
------
1. CloudHSM CLI를 사용하여 [Crypto User](understanding-users.md#crypto-user-chsm-cli)를 생성합니다. HSM 사용자 관리에 대한 자세한 내용은 [CloudHSM CLI를 사용한 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오.
**작은 정보**
CU의 사용자 이름과 암호를 기록합니다. 나중에 웹 서버용 HTTPS 프라이빗 키와 인증서를 생성하거나 가져올 때 이 정보가 필요합니다.
이 단계들을 완료한 후 [2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기](#ssl-offload-provider-generate-key-and-certificate)로 이동합니다.
#### 참고
+ 보안이 강화된 리눅스(SELinux) 및 웹 서버를 사용하려면 클라이언트 SDK 5가 HSM과 통신하는 데 사용하는 포트인 포트 2223에서 아웃바운드 TCP 연결을 허용해야 합니다.
+ 클러스터를 생성 및 활성화하고 EC2 인스턴스에 클러스터 액세스 권한을 부여하려면 [AWS CloudHSM시작하기](getting-started.md)의 단계를 완료하십시오. 시작하기에서는 HSM 1개와 Amazon EC2 클라이언트 인스턴스 1개로 활성 클러스터를 생성하는 방법에 대한 단계별 지침을 제공합니다. 이 클라이언트 인스턴스를 웹 서버로 사용할 수 있습니다.
+ 클라이언트 키 내구성을 비활성화하지 않으려면 클러스터에 HSM을 두 개 이상 추가하십시오. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오.
+ SSH 또는 PuTTY를 사용하여 클라이언트 인스턴스에 연결할 수 있습니다. 자세한 정보는 Amazon EC2 설명서의 [SSH를 사용하여 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)과 [PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) 단원을 참조하세요.
## 2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기
HTTPS를 활성화하려면 웹 서버 애플리케이션(NGINX 또는 HAProxy)에 프라이빗 키와 해당 SSL/TLS 인증서가 필요합니다. 에서 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 사용하려면 AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장 AWS CloudHSM해야 합니다. 먼저 프라이빗 키를 생성한 후 해당 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. 그런 다음 HSM에서 *가짜 PEM 프라이빗 키*를 내보냅니다. 즉 HSM에 저장된 프라이빗 키에 대한 참조를 포함하는 PEM 형식의 프라이빗 키 파일입니다(실제 프라이빗 키가 아님). 웹 서버는 가짜 PEM 프라이빗 키 파일을 사용하여 SSL/TLS 서버 자격 증명 오프로드 중에 HSM의 프라이빗 키를 식별합니다.
### 프라이빗 키 생성
이 섹션에서는 [CloudHSM CLI](cloudhsm_cli.md)를 사용하여 키 페어를 생성하는 방법을 보여줍니다. HSM 내부에 키 페어가 생성되면 이를 가짜 PEM 파일로 내보내고 해당 인증서를 생성할 수 있습니다.
**CloudHSM CLI 설치 및 구성**
1. CloudHSM CLI를 [설치 및 구성](cloudhsm_cli-getting-started.md)합니다.
1. 다음 명령을 사용하여 CloudHSM CLI를 시작합니다.
```
$ /opt/cloudhsm/bin/cloudhsm-cli interactive
```
1. 다음 명령을 실행하여 HSM에 로그인합니다. **을 Crypto User의 사용자 이름으로 변경
```
aws-cloudhsm>login --username --role crypto-user
```
**프라이빗 키 생성**
사용 사례에 따라 RSA 또는 EC 키 페어를 생성할 수 있습니다. 다음 중 하나를 수행하십시오.
+ HSM에서 RSA 프라이빗 키를 생성하려면
[`key generate-asymmetric-pair rsa`](cloudhsm_cli-key-generate-asymmetric-pair-rsa.md) 명령을 사용하여 RSA 키 페어를 생성합니다. 이 예제에서는 모듈러스가 2048, 퍼블릭 지수가 65537, 퍼블릭 키 레이블이 *tls\$1rsa\$1pub*, 프라이빗 키 레이블이 *tls\$1rsa\$1private*인 RSA 키 페어를 생성합니다.
```
aws-cloudhsm > key generate-asymmetric-pair rsa \
--public-exponent 65537 \
--modulus-size-bits 2048 \
--public-label tls_rsa_pub \
--private-label tls_rsa_private \
--private-attributes sign=true
{
"error_code": 0,
"data": {
"public_key": {
"key-reference": "0x0000000000280cc8",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "full"
},
"attributes": {
"key-type": "rsa",
"label": "tls_rsa_pub",
"id": "",
"check-value": "0x01fe6e",
"class": "public-key",
"encrypt": true,
"decrypt": false,
"token": true,
"always-sensitive": false,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": false,
"sign": false,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 512,
"public-exponent": "0x010001",
"modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634df6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0acac3160f0ca9725d38318b7",
"modulus-size-bits": 2048
}
},
"private_key": {
"key-reference": "0x0000000000280cc7",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "full"
},
"attributes": {
"key-type": "rsa",
"label": "tls_rsa_private",
"id": "",
"check-value": "0x01fe6e",
"class": "private-key",
"encrypt": false,
"decrypt": true,
"token": true,
"always-sensitive": true,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": true,
"sign": true,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 1217,
"public-exponent": "0x010001",
"modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634df6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0acac3160f0ca9725d38318b7",
"modulus-size-bits": 2048
}
}
}
}
```
+ HSM에서 EC 프라이빗 키를 생성하려면
[`key generate-asymmetric-pair ec`](cloudhsm_cli-key-generate-asymmetric-pair-ec.md) 명령을 사용하여 EC 키 페어를 생성합니다. 이 예제에서는 `prime256v1` 곡선(`NID_X9_62_prime256v1` 곡선에 해당)에 기반하여 퍼블릭 키 레이블이 *tls\$1ec\$1pub*, 프라이빗 키 레이블이 *tls\$1ec\$1private*인 EC 키 페어를 생성합니다.
```
aws-cloudhsm > key generate-asymmetric-pair ec \
--curve prime256v1 \
--public-label tls_ec_pub \
--private-label tls_ec_private \
--private-attributes sign=true
{
"error_code": 0,
"data": {
"public_key": {
"key-reference": "0x000000000012000b",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "session"
},
"attributes": {
"key-type": "ec",
"label": "tls_ec_pub",
"id": "",
"check-value": "0xd7c1a7",
"class": "public-key",
"encrypt": false,
"decrypt": false,
"token": false,
"always-sensitive": false,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": false,
"sign": false,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 57,
"ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c",
"curve": "secp224r1"
}
},
"private_key": {
"key-reference": "0x000000000012000c",
"key-info": {
"key-owners": [
{
"username": "cu1",
"key-coverage": "full"
}
],
"shared-users": [],
"cluster-coverage": "session"
},
"attributes": {
"key-type": "ec",
"label": "tls_ec_private",
"id": "",
"check-value": "0xd7c1a7",
"class": "private-key",
"encrypt": false,
"decrypt": false,
"token": false,
"always-sensitive": true,
"derive": false,
"destroyable": true,
"extractable": true,
"local": true,
"modifiable": true,
"never-extractable": false,
"private": true,
"sensitive": true,
"sign": true,
"trusted": false,
"unwrap": false,
"verify": false,
"wrap": false,
"wrap-with-trusted": false,
"key-length-bytes": 122,
"ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c",
"curve": "secp224r1"
}
}
}
}
```
**가짜 PEM 프라이빗 키 파일 내보내기**
HSM에 프라이빗 키가 있으면 가짜 PEM 프라이빗 키 파일을 내보내야 합니다. 이 파일에은 실제 키 데이터가 포함하지 않지만 OpenSSL 동적 엔진이 HSM의 프라이빗 키를 식별할 수 있도록 해줍니다. 그런 다음 프라이빗 키를 사용하여 CSR(인증서 서명 요청)을 생성하고 CSR에 서명하여 인증서를 생성할 수 있습니다.
[`key generate-file`](cloudhsm_cli-key-generate-file.md) 명령을 실행하여 가짜 PEM 형식의 프라이빗 키를 내보내고 파일에 저장합니다. 다음 값을 사용자의 값으로 대체합니다.
+ ** - 이전 단계에서 생성한 프라이빗 키의 레이블입니다.
+ ** - 가짜 PEM 키가 기록될 파일의 이름입니다.
```
aws-cloudhsm > key generate-file --encoding reference-pem --path --filter attr.label=
{
"error_code": 0,
"data": {
"message": "Successfully generated key file"
}
}
```
**CloudHSM CLI 종료**
다음 명령을 실행하여 CloudHSM CLI를 종료합니다.
```
aws-cloudhsm > quit
```
이제 이전 명령에서 **로 지정된 경로에, 시스템에 새 파일이 있어야 합니다. 이 파일은 가짜 PEM 프라이빗 키 파일입니다.
### 자체 사인된 인증서를 생성합니다.
가짜 PEM 프라이빗 키를 생성한 후에는 이 파일을 사용하여 인증서 사인 요청(CSR) 및 인증서를 생성할 수 있습니다.
프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우 CA에 CSR 파일을 보내고 CA가 웹 서버에서 HTTPS용으로 제공하는 서명된 SSL/TLS 인증서를 사용하세요.
CA를 사용하는 대신 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 자체 서명된 인증서를 생성할 수 있습니다. 자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다.
**주의**
자체 사인된 인증서는 테스트 환경에서만 사용해야 합니다. 프로덕션 환경의 경우 인증 기관과 같은 추가 보안 방법을 사용하여 인증서를 생성하십시오.
**OpenSSL Dynamic Engine 설치 및 구성**
1. 클라이언트 인스턴스에 연결합니다.
1. [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL Dynamic Engine 설치](openssl5-install.md)
**인증서 생성**
1. 이전 단계에서 생성한 가짜 PEM 파일의 사본을 확보하세요.
1. CSR 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 인증서 서명 요청(CSR)을 생성합니다. **를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다. **을 CSR이 포함된 파일의 이름으로 바꿉니다.
`req` 명령은 대화식입니다. 각 필드에 응답합니다. 필드 정보가 SSL/TLS 인증서에 복사됩니다.
**참고**
CSR 생성은 현재 OpenSSL 공급자에서 지원되지 않습니다. 이 단계에서는 OpenSSL 엔진을 사용해야 하지만 TLS 암호 작업은 공급자와 함께 작동합니다.
```
$ openssl req -engine cloudhsm -new -key -out
```
1. 자체 서명된 인증서 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 HSM의 프라이빗 키로 CSR에 서명합니다. 이렇게 하면 자체 사인된 인증서가 생성됩니다. 명령의 다음 값을 사용자의 값으로 바꿉니다.
+ ** – CSR이 포함된 파일 이름
+ ** – 가짜 PEM 프라이빗 키가 포함된 파일 이름
+ ** – 웹 서버 인증서가 포함될 파일 이름
```
$ openssl x509 -engine cloudhsm -req -days 365 -in -signkey -out
```
프라이빗 키와 인증서가 있으면 로 이동합니다[3단계: 웹 서버 구성하기](#ssl-offload-provider-configure-web-server).
## 3단계: 웹 서버 구성하기
[이전 단계](#ssl-offload-provider-generate-key-and-certificate)에서 생성한 HTTPS 인증서와 이에 해당되는 가짜 PEM 프라이빗 키를 사용하려면 웹 서버 소프트웨어의 구성을 업데이트하십시오. 시작하기 전에 기존 인증서와 키를 백업해야 한다는 점을 잊지 마십시오. 그러면 SSL/TLS 서버 자격 증명 오프로드를 위한 Linux 웹 서버 소프트웨어 설정이 완료됩니다 AWS CloudHSM.
다음 섹션 중 하나에 있는 단계를 완료합니다.
**Topics**
+ [NGINX 웹 서버를 구성합니다](#ssl-offload-provider-configure-nginx)
+ [HAProxy 웹 서버 구성](#ssl-offload-provider-configure-haproxy)
### NGINX 웹 서버를 구성합니다
이 섹션을 사용하여 OpenSSL 공급자로 NGINX를 구성합니다.
**OpenSSL Provider용 NGINX를 구성하려면**
1. 클라이언트 인스턴스에 연결합니다.
1. 다음 명령을 실행하여 웹 서버 인증서 및 가짜 PEM 프라이빗 키에 필요한 디렉터리를 생성합니다.
```
$ mkdir -p /etc/pki/nginx/private
```
1. 다음 명령을 실행하여 웹 서버 인증서를 필요한 위치에 복사합니다. **를 웹 서버 인증서 이름으로 바꿉니다.
```
$ cp /etc/pki/nginx/server.crt
```
1. 다음 명령을 실행하여 가짜 PEM 프라이빗 키를 필요한 위치에 복사합니다. **를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.
```
$ cp /etc/pki/nginx/private/server.key
```
1. 다음 명령을 실행하여 *nginx*라는 이름의 사용자가 파일을 읽을 수 있도록 파일 소유권을 변경합니다.
```
$ chown nginx /etc/pki/nginx/server.crt /etc/pki/nginx/private/server.key
```
1. AWS CloudHSM 공급자를 사용하도록 OpenSSL을 구성합니다. OpenSSL 공급자 구성에 대한 자세한 내용은 [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자](openssl-provider-install.md)를 참조하세요.
1. OpenSSL 구성 파일을 찾습니다.
```
$ openssl version -d
```
다음과 비슷한 출력이 표시되어야 합니다.
```
OPENSSLDIR: "/etc/pki/tls"
```
구성 파일은이 디렉터리`openssl.cnf`에 있습니다.
1.
**참고**
시스템의 기본 openssl.cnf 파일을 직접 수정하지 마십시오. 이렇게 하면 시스템 전체의 OpenSSL 작업(SSH, TLS 연결 및 기타 서비스)이 의도치 않게 CloudHSM 공급자를 통해 라우팅되는 것을 방지할 수 있습니다.
별도의 구성 파일을 사용하면 HSM 지원 암호화 작업이 필요한 특정 애플리케이션으로만 CloudHSM 공급자 사용량의 범위를 지정할 수 있습니다.
다음 내용이 포함된 새 OpenSSL 구성 파일을 생성합니다.
```
$ cat > << 'EOF'
## NOTE: This should point to the system default openssl config file.
# Replace /etc/pki/tls with the path to your OpenSSL configuration directory
.include /openssl.cnf
# Override the existing provider_section to include AWS CloudHSM OpenSSL Provider as a 3rd party OpenSSL provider
[provider_sect]
default = default_sect
# Include AWS CloudHSM CloudHSM OpenSSL provider
cloudhsm = cloudhsm_sect
[default_sect]
activate = 1
[cloudhsm_sect]
activate = 1
EOF
```
1. `CLOUDHSM_PIN` 환경 변수가 CU(Crypto User) 자격 증명으로 설정되어 있는지 확인합니다.
```
$ export CLOUDHSM_PIN=:
```
1. 업데이트된 구성 파일을 가리키도록 `OPENSSL_CONF` 환경 변수를 설정하고 공급자가 로드되었는지 확인합니다.
```
$ OPENSSL_CONF=/path/to/example-cloudhsm-openssl.cnf openssl list -providers
```
기본 공급자와 CloudHSM 공급자가 모두 나열되어야 합니다.
```
OPENSSL_CONF=/path/to/example-cloudhsm-openssl.cnf openssl list -providers
Providers:
default
name: OpenSSL Default Provider
version: 3.2.2
status: active
cloudhsm
name: AWS CloudHSM OpenSSL Provider
version: 5.17.0
status: active
```
1. 다음 명령을 실행하여 `/etc/nginx/nginx.conf` 파일을 백업합니다.
```
$ cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
```
1. NGINX 구성을 업데이트합니다.
**참고**
각 클러스터는 모든 NGINX 웹 서버에서 최대 1000개의 NGINX 작업자 프로세스를 지원할 수 있습니다.
------
#### [ Amazon Linux 2023 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다.
```
env CLOUDHSM_PIN;
env OPENSSL_CONF;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters for DHE ciphers
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
# ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ RHEL 9 (9.2\$1) ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다.
```
env CLOUDHSM_PIN;
env OPENSSL_CONF;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters for DHE ciphers
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
# ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ RHEL 10 (10.0\$1) ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다.
```
env CLOUDHSM_PIN;
env OPENSSL_CONF;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /usr/share/nginx/html;
ssl_certificate "/etc/pki/nginx/server.crt";
ssl_certificate_key "/etc/pki/nginx/private/server.key";
# It is *strongly* recommended to generate unique DH parameters for DHE ciphers
# Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048
# ssl_dhparam "/etc/pki/nginx/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
#### [ Ubuntu 24.04 ]
텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다.
```
env CLOUDHSM_PIN;
env OPENSSL_CONF;
```
그런 다음 파일의 TLS 섹션에 다음을 추가합니다.
```
# Settings for a TLS enabled server.
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
root /var/www/html;
ssl_certificate "/etc/ssl/certs/server.crt";
ssl_certificate_key "/etc/ssl/private/server.key";
# It is *strongly* recommended to generate unique DH parameters for DHE ciphers
# Generate them with: openssl dhparam -out /etc/ssl/certs/dhparams.pem 2048
# ssl_dhparam "/etc/ssl/certs/dhparams.pem";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256";
ssl_prefer_server_ciphers off;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
```
------
파일을 저장합니다.
1. `systemd` 구성 파일을 백업한 후, `EnvironmentFile` 경로를 설정합니다.
------
#### [ Amazon Linux 2023 ]
1. `nginx.service` 파일을 백업합니다.
```
$ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ RHEL 9 (9.2\$1) ]
1. `nginx.service` 파일을 백업합니다.
```
$ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ RHEL 10 (10.0\$1) ]
1. `nginx.service` 파일을 백업합니다.
```
$ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
#### [ Ubuntu 24.04 ]
1. `nginx.service` 파일을 백업합니다.
```
$ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup
```
1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다.
```
EnvironmentFile=/etc/sysconfig/nginx
```
------
1. `/etc/sysconfig/nginx` 파일이 있는지 여부를 확인한 후, 다음 중 하나를 수행합니다.
+ 파일이 있는 경우 다음 명령을 실행하여 파일을 백업합니다.
```
$ cp /etc/sysconfig/nginx /etc/sysconfig/nginx.backup
```
+ 파일이 없는 경우 텍스트 편집기를 연 후 `/etc/sysconfig/` 폴더에 `nginx`라는 파일을 생성합니다.
1. NGINX 환경을 구성합니다.
------
#### [ Amazon Linux 2023 ]
Linux 루트 사용자는 텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 예:
```
vi /etc/sysconfig/nginx
```
CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다.
```
CLOUDHSM_PIN=:
OPENSSL_CONF=
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. **를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider).
파일을 저장합니다.
------
#### [ RHEL 9 (9.2\$1) ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다.
```
CLOUDHSM_PIN=:
OPENSSL_CONF=
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. **를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider).
파일을 저장합니다.
------
#### [ RHEL 10 (10.0\$1) ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다.
```
CLOUDHSM_PIN=:
OPENSSL_CONF=
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. **를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider).
파일을 저장합니다.
------
#### [ Ubuntu 24.04 ]
텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다.
```
CLOUDHSM_PIN=:
OPENSSL_CONF=
```
** 및 *<암호>*를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. **를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider).
파일을 저장합니다.
------
1. NGINX 웹 서버를 시작합니다.
------
#### [ Amazon Linux 2023 ]
모든 NGINX 프로세스 중지
```
$ systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ systemctl daemon-reload
```
NGINX 시작
```
$ systemctl start nginx
```
------
#### [ RHEL 9 (9.2\$1) ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ systemctl start nginx
```
------
#### [ RHEL 10 (10.0\$1) ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ systemctl start nginx
```
------
#### [ Ubuntu 24.04 ]
실행 중인 NGINX 프로세스를 모두 중지하기
```
$ systemctl stop nginx
```
`systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기
```
$ systemctl daemon-reload
```
NGINX 프로세스 시작하기
```
$ systemctl start nginx
```
------
NGINX를 구성한 후 로 이동합니다[HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux).
### HAProxy 웹 서버 구성
이 섹션을 사용하여 OpenSSL 공급자로 HAProxy를 구성합니다. 다음 예제에서는 CloudHSM 인증서 및 키를 사용하여 HAProxy를 설정하는 방법을 보여줍니다.
**OpenSSL 공급자용 HAProxy를 구성하려면**
1. 기존 통합 인증서 파일이 있는 경우 백업합니다.
```
$ cp server-combined.pem server-combined.pem.backup
```
1. 인증서와 CloudHSM 가짜 PEM 키를 사용하여 HAProxy에 대한 결합된 인증서 파일을 생성합니다.
```
$ cat server.crt server.key > server-combined.pem
```
1. 기존 HAProxy 구성을 백업합니다.
```
$ cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup
```
1. 에서 새 CloudHSM TLS 오프로드 구성을 생성합니다`/etc/haproxy/haproxy.cfg`.
```
global
daemon
ssl-provider cloudhsm
# It is *strongly* recommended to generate unique DH parameters
# Generate them with: openssl dhparam -out /etc/haproxy/dhparams.pem 2048
# ssl-dh-param-file /etc/haproxy/dhparams.pem
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend haproxy_frontend
bind *:443 ssl crt /path/to/server-combined.pem
default_backend web_servers
backend web_servers
server web1 127.0.0.1:8080 check
```
파일 위치와 일치하도록 인증서 경로를 업데이트합니다.
1. HAProxy용 환경 파일을 사용하도록 systemd를 구성합니다. 위치는 Linux 배포판에 따라 다릅니다.
------
#### [ Amazon Linux and RHEL ]
HAProxy 서비스 파일을 백업하고 수정합니다.
```
$ cp /lib/systemd/system/haproxy.service /lib/systemd/system/haproxy.service.backup
```
[서비스] 섹션 아래에 다음 줄을 편집`/lib/systemd/system/haproxy.service`하고 추가합니다.
```
EnvironmentFile=/etc/sysconfig/haproxy
```
------
#### [ Ubuntu ]
HAProxy 서비스 파일을 백업하고 수정합니다.
```
$ cp /lib/systemd/system/haproxy.service /lib/systemd/system/haproxy.service.backup
```
[서비스] 섹션 아래에 다음 줄을 편집`/lib/systemd/system/haproxy.service`하고 추가합니다.
```
EnvironmentFile=/etc/default/haproxy
```
------
1. 시스템에 적합한 위치에 환경 파일을 생성합니다.
------
#### [ Amazon Linux and RHEL ]
HAProxy 환경 파일이 있는 경우 백업합니다.
```
$ cp /etc/sysconfig/haproxy /etc/sysconfig/haproxy.backup
```
다음 내용을 `/etc/sysconfig/haproxy` 사용하여 HAProxy 환경 파일을 생성합니다.
```
CLOUDHSM_PIN=:
```
------
#### [ Ubuntu ]
HAProxy 환경 파일이 있는 경우 백업합니다.
```
$ cp /etc/default/haproxy /etc/default/haproxy.backup
```
다음 내용을 `/etc/default/haproxy` 사용하여 HAProxy 환경 파일을 생성합니다.
```
CLOUDHSM_PIN=:
```
------
** 및 *<암호>*를 CU 자격 증명으로 바꿉니다.
1. 시스템 구성 다시 로드:
```
$ systemctl daemon-reload
```
1. CloudHSM TLS 오프로드 구성으로 HAProxy를 시작합니다.
```
$ systemctl start haproxy
```
사용자 지정 구성 파일을 사용하여 HAProxy를 직접 실행할 수도 있습니다.
```
$ haproxy -f /path/to/haproxy-cloudhsm.cfg
```
HAProxy를 구성한 후 로 이동합니다[HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux).
## 4단계: HTTPS 트래픽 활성화 및 인증서 확인하기
를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM.
**Topics**
+ [인바운드 HTTPS 연결 활성화](#ssl-offload-add-security-group-linux)
+ [HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux)
### 인바운드 HTTPS 연결 활성화
클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다.
**HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. **보안 그룹 생성**에서 다음을 수행합니다.
1. **보안 그룹 이름**에 생성하려는 보안 그룹의 이름을 입력합니다.
1. (선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다.
1. 웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 **VPC**로 선택합니다.
1. **규칙 추가**를 선택합니다.
1. 드롭다운 창에서 **HTTPS**를 **유형**으로 선택합니다.
1. **소스**에 소스 위치를 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 탐색 창에서 **인스턴스(Instances)**를 선택합니다.
1. 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
1. 페이지 상단의 **작업** 드롭다운 메뉴를 선택합니다. **보안**을 선택한 다음 **보안 그룹 변경**을 선택합니다.
1. **연결된 보안 그룹**에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 **보안 그룹 추가**를 선택합니다.
1. **저장**을 선택합니다.
### HTTPS가 사용자가 구성한 인증서를 사용하는지 확인
웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\$1client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.
**웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 웹 브라우저를 사용하여 서버의 퍼블릭 DNS 이름 또는 IP 주소를 사용해 웹 서버에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다. 예를 들어 **https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/**입니다.
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
+ Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오.
+ Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
**OpenSSL s\$1client를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다. **을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다.
```
openssl s_client -connect :443
```
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서에서 [Amazon EC2 인스턴스로의 라우팅 트래픽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다.
로드 밸런서를 추가하려면 [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md) 섹션을 참조하십시오.
# AWS CloudHSM JSSE와 함께 Tomcat을 사용하는 Linux에서의 SSL/TLS 오프로드
이 주제에서는 AWS CloudHSM JCE SDK와 함께 Java Secure Socket Extension(JSSE)을 사용하여 SSL/TLS 오프로드를 설정하는 step-by-step 지침을 제공합니다.
**Topics**
+ [개요](#third-offload-linux-jsse-overview)
+ [1단계: 사전 조건 설정](#third-offload-linux-jsse-prereqs)
+ [단계 2: 프라이빗 키 및 SSL/TLS 인증서 생성 또는 가져오기](#third-offload-linux-jsse-gen)
+ [3단계: Tomcat 웹 서버 구성](#third-offload-linux-jsse-config)
+ [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#third-offload-linux-jsse-verify)
## 개요
에서 AWS CloudHSM Tomcat 웹 서버는 Linux에서 작동하여 HTTPS를 지원합니다. AWS CloudHSM JCE SDK는 JSSE(Java Secure Socket Extension)와 함께 사용하여 이러한 웹 서버에 HSMs을 사용할 수 있는 인터페이스를 제공합니다. AWS CloudHSM JCE는 JSSE를 AWS CloudHSM 클러스터에 연결하는 브리지입니다. JSSE는 보안 소켓 계층(SSL) 및 전송 계층 보안(TLS) 프로토콜을 위한 Java API입니다.
## 1단계: 사전 조건 설정
Linux에서 SSL/TLS 오프로드를 AWS CloudHSM 위해와 함께 Tomcat 웹 서버를 사용하려면 다음 사전 조건을 따르세요. 클라이언트 SDK 5 및 Tomcat 웹 서버를 사용하여 웹 서버 SSL/TLS 오프로드를 설정하려면 이러한 필수 조건을 충족해야 합니다.
**참고**
플랫폼마다 필요한 필수 조건이 다릅니다. 항상 플랫폼에 맞는 올바른 설치 단계를 따릅니다.
### 사전 조건
+ Tomcat 웹 서버가 설치된 Linux 운영 체제를 실행하는 Amazon EC2 인스턴스입니다.
+ HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다.
+ [클라이언트 SDK 5용 JCE가](java-library-install_5.md) 설치 및 구성된 하드웨어 보안 모듈(HSMs)이 2개 이상 있는 활성 AWS CloudHSM 클러스터입니다.
**참고**
단일 HSM 클러스터를 사용할 수 있지만 먼저 클라이언트 키 내구성을 비활성화해야 합니다. 자세한 내용은 [클라이언트 키 내구성 설정 관리](working-client-sync.md#client-sync-sdk8) 및 [클라이언트 SDK 5 구성 도구](configure-sdk-5.md)를 참조하십시오.
#### 필수 조건 충족 방법
1. 최소 2개의 하드웨어 보안 모듈(HSMs)이 있는 활성 AWS CloudHSM 클러스터 AWS CloudHSM 에 용 JCE를 설치하고 구성합니다. 설치에 대한 자세한 내용은 [클라이언트 SDK 5용 JCE](java-library-install_5.md)를 참조하십시오.
1. AWS CloudHSM 클러스터에 액세스할 수 있는 EC2 Linux 인스턴스에서 [Apache Tomcat 지침에](https://tomcat.apache.org/download-90.cgi ) 따라 Tomcat 웹 서버를 다운로드하고 설치합니다.
1. [CloudHSM CLI](cloudhsm_cli.md)를 사용하여 CU(Crypto User)를 생성합니다. HSM 사용자 관리에 대한 자세한 내용은 [CloudHSM CLI를 사용한 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오.
**작은 정보**
CU의 사용자 이름과 암호를 기록합니다. 나중에 웹 서버용 HTTPS 프라이빗 키와 인증서를 생성하거나 가져올 때 이 정보가 필요합니다.
1. Java Keytool을 사용하여 JCE를 설정하려면 [클라이언트 SDK 5를 사용하여 Java Keytool 및 Jarsigner AWS CloudHSM 와 통합](keystore-third-party-tools_5.md)의 지침을 따릅니다.
이 단계들을 완료한 후 [단계 2: 프라이빗 키 및 SSL/TLS 인증서 생성 또는 가져오기](#third-offload-linux-jsse-gen)로 이동합니다.
#### 참고
+ 보안이 강화된 리눅스(SELinux) 및 웹 서버를 사용하려면 클라이언트 SDK 5가 HSM과 통신하는 데 사용하는 포트인 포트 2223에서 아웃바운드 TCP 연결을 허용해야 합니다.
+ 클러스터를 생성 및 활성화하고 EC2 인스턴스에 클러스터 액세스 권한을 부여하려면 [AWS CloudHSM시작하기](getting-started.md)의 단계를 완료하십시오. 이 섹션에서는 하나의 HSM과 Amazon EC2 클라이언트 인스턴스로 활성 클러스터를 생성하기 위한 단계별 지침을 제공합니다. 이 클라이언트 인스턴스를 웹 서버로 사용할 수 있습니다.
+ 클라이언트 키 내구성을 비활성화하지 않으려면 클러스터에 HSM을 두 개 이상 추가하십시오. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오.
+ SSH 또는 PuTTY를 사용하여 클라이언트 인스턴스에 연결할 수 있습니다. 자세한 정보는 Amazon EC2 설명서의 [SSH를 사용하여 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)과 [PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) 단원을 참조하세요.
## 단계 2: 프라이빗 키 및 SSL/TLS 인증서 생성 또는 가져오기
HTTPS를 활성화하려면 Tomcat 웹 서버 애플리케이션에서 프라이빗 키와 해당되는 SSL/TLS 인증서가 필요합니다. 에서 웹 서버 SSL/TLS 오프로드를 사용하려면 AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장 AWS CloudHSM해야 합니다.
**참고**
아직 프라이빗 키와 해당 인증서가 없다면 HSM에서 프라이빗 키를 생성하세요. 프라이빗 키를 사용하여 SSL/TLS 인증서를 생성하는 데 사용하는 인증서 사인 요청(CSR)을 생성합니다.
HSM의 프라이빗 키 및 관련 인증서에 대한 참조가 포함된 local AWS CloudHSM KeyStore 파일을 생성합니다. 웹 서버는 AWS CloudHSM KeyStore 파일을 사용하여 SSL/TLS 오프로드 중에 HSM의 프라이빗 키를 식별합니다.
**Topics**
+ [프라이빗 키 생성](#jsse-ssl-offload-generate-private-key)
+ [자체 사인된 인증서를 생성합니다.](#jsse-ssl-offload-generate-certificate)
### 프라이빗 키 생성
이 섹션에서는 JDK의 KeyTool을 사용하여 키 페어를 생성하는 방법을 보여줍니다. HSM 내에서 키 쌍을 생성한 후에는 이를 키스토어 파일로 내보내고 해당 인증서를 생성할 수 있습니다.
사용 사례에 따라 RSA 또는 EC 키 페어를 생성할 수 있습니다. 다음 단계에서는 RSA 키 쌍을 생성하는 방법을 보여 줍니다.
**KeyTool의 `genkeypair` 명령을 사용하여 RSA 키 페어를 생성합니다.**
1. 아래의 **을 특정 데이터로 바꾼 후 다음 명령을 사용하여 HSM의 프라이빗 키를 참조하는 `jsse_keystore.keystore`라는 이름의 키스토어 파일을 생성합니다.
```
$ keytool -genkeypair -alias -keyalg -keysize -sigalg \
-keystore /.keystore -storetype CLOUDHSM \
-dname CERT_DOMAIN_NAME \
-J-classpath '-J'$JAVA_LIB'/*:/opt/cloudhsm/java/*:./*' \
-provider "com.amazonaws.cloudhsm.jce.provider.CloudHsmProvider" \
-providerpath "$CLOUDHSM_JCE_LOCATION" \
-keypass -storepass
```
+ ******: 키스토어 파일을 생성하려는 경로입니다.
+ ******: HSM에서 키를 고유하게 식별하는 데 사용됩니다. 이 별칭은 키의 LABEL 속성으로 설정됩니다.
+ ******: 키에 대한 참조를 로컬 Keystore 파일에 저장하며, 이 암호는 해당 로컬 참조를 보호합니다.
+ ******: 로컬 키스토어 파일의 암호입니다.
+ ******: 키스토어 파일의 이름입니다.
+ ******: X.500 고유 이름.
+ ******: 키 페어를 생성하는 키 알고리즘(예: RSA 및 EC).
+ ******: 키 페어를 생성하기 위한 키 크기(예: 2048, 3072, 4096).
+ ******: 키 쌍을 생성하기 위한 키 크기(예: RSA를 사용하는 SHA1, RSA를 사용하는 SHA224, RSA를 사용하는 SHA256, RSA를 사용하는 SHA384, RSA를 사용하는 SHA512).
1. 명령이 성공했는지 확인하려면 다음 명령을 입력하고 RSA 키 쌍이 성공적으로 생성되었는지 확인합니다.
```
$ ls /.keystore
```
### 자체 사인된 인증서를 생성합니다.
키스토어 파일과 함께 개인 키를 생성한 후에는 이 파일을 사용하여 인증서 서명 요청(CSR) 및 인증서를 생성할 수 있습니다.
프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우 CA에 CSR 파일을 보내고 CA가 웹 서버에서 HTTPS용으로 제공하는 서명된 SSL/TLS 인증서를 사용하세요.
CA 사용의 대안으로 KeyTool을 사용하여 자체 서명 인증서를 생성할 수 있습니다. 자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다.
**주의**
자체 사인된 인증서는 테스트 환경에서만 사용해야 합니다. 프로덕션 환경의 경우 인증 기관과 같은 추가 보안 방법을 사용하여 인증서를 생성하세요.
**Topics**
**인증서 생성**
1. 이전 단계에서 생성한 키스토어 파일의 사본을 확보하세요.
1. 다음 명령을 실행하여 OpenSSL용 KeyTool을 사용해 인증서 서명 요청(CSR)을 생성하십시오.
```
$ keytool -certreq -keyalg RSA -alias unique_alias_for_key -file certreq.csr \
-keystore .keystore -storetype CLOUDHSM \
-J-classpath '-J$JAVA_LIB/*:/opt/cloudhsm/java/*:./*' \
-keypass -storepass
```
**참고**
인증서 서명 요청의 출력 파일은 `certreq.csr`입니다.
**인증서에 서명**
+ 아래 **를 특정 데이터로 대체한 후 다음 명령을 실행하여 HSM의 프라이빗 키로 CSR에 서명합니다. 이렇게 하면 자체 사인된 인증서가 생성됩니다.
```
$ keytool -gencert -infile certreq.csr -outfile certificate.crt \
-alias -keypass -storepass -sigalg SIG_ALG \
-storetype CLOUDHSM -J-classpath '-J$JAVA_LIB/*:/opt/cloudhsm/java/*:./*' \
-keystore jsse_keystore.keystore
```
**참고**
`certificate.crt`는 별칭의 프라이빗 키를 사용하는 서명된 인증서입니다.
**키스토어에서 인증서 가져오기**
+ 아래 **를 특정 데이터로 바꾼 후 다음 명령을 실행하여 서명된 인증서를 신뢰할 수 있는 인증서로 가져옵니다. 이 단계에서는 별칭으로 식별되는 키 저장소 항목에 인증서를 저장합니다.
```
$ keytool -import -alias -keystore jsse_keystore.keystore \
-file certificate.crt -storetype CLOUDHSM \
-v -J-classpath '-J$JAVA_LIB/*:/opt/cloudhsm/java/*:./*' \
-keypass -storepass
```
**인증서를 PEM으로 변환합니다.**
+ 다음 명령을 실행하여 서명된 인증서 파일(`.crt`)을 PEM으로 변환합니다. PEM 파일은 http 클라이언트에서 요청을 보내는 데 사용됩니다.
```
$ openssl x509 -inform der -in certificate.crt -out certificate.pem
```
이 단계를 완료한 후 [3단계: 웹 서버 구성](#third-offload-linux-jsse-config)으로 이동합니다.
## 3단계: Tomcat 웹 서버 구성
이전 단계에서 생성한 HTTPS 인증서와 해당 PEM 파일을 사용하려면 웹 서버 소프트웨어의 구성을 업데이트합니다. 시작하기 전에 기존 인증서와 키를 백업해야 한다는 점을 잊지 마십시오. 그러면 AWS CloudHSM이 지원되는 SSL/TLS 오프로드의 Linux 웹 서버 소프트웨어 설정이 완료됩니다. 자세한 내용은 [Apache Tomcat 9 구성 참조](https://tomcat.apache.org/tomcat-9.0-doc/config/http.html)를 참조하십시오.
**서버 중지**
+ 아래의 **를 특정 데이터로 바꾼 후 구성을 업데이트하기 전에 다음 명령을 실행하여 Tomcat 서버를 중지하십시오.
```
$ //bin/shutdown.sh
```
+ ******: Tomcat 설치 디렉터리입니다.
**Tomcat 클래스 경로 업데이트**
1. 클라이언트 인스턴스에 연결합니다.
1. Tomcat 설치 폴더를 찾습니다.
1. 아래 **를 특정 데이터로 바꾼 후 다음 명령을 사용하여 Tomcat/bin/catalina.sh 파일에 **classpath**있는 Tomcat에 Java 라이브러리와 AWS CloudHSM Java 경로를 추가합니다. Tomcat/bin/catalina
```
$ sed -i 's@CLASSPATH="$CLASSPATH""$CATALINA_HOME"\/bin\/bootstrap.jar@CLASSPATH="$CLASSPATH""$CATALINA_HOME"\/bin\/bootstrap.jar:'"
"'\/*:\/opt\/cloudhsm\/java\/*:.\/*@' /bin/catalina.sh
```
+ ******: Java JRE 라이브러리 위치입니다.
+ ******: Tomcat 설치 폴더입니다.
**서버 구성에 HTTPS 커넥터를 추가합니다.**
1. Tomcat 설치 폴더로 이동합니다.
1. 아래의 **를 특정 데이터로 바꾼 후 다음 명령을 사용하여 필수 구성 요소에서 생성된 인증서를 사용하도록 HTTPS 커넥터를 추가합니다.
```
$ sed -i '//.keystore\" keystorePass=\"\" keyPass=\"
\" keyAlias=\"" clientAuth=\"false\" sslProtocol=\"TLS\"/>' /conf/server.xml
```
+ ******: 키스토어 파일이 위치한 디렉터리입니다.
+ ******: 키스토어 파일의 이름입니다.
+ ******: 로컬 키스토어 파일의 암호입니다.
+ ******: 키에 대한 참조를 로컬 Keystore 파일에 저장하며, 이 암호는 해당 로컬 참조를 보호합니다.
+ ******: HSM에서 키를 고유하게 식별하는 데 사용됩니다. 이 별칭은 키의 LABEL 속성으로 설정됩니다.
+ ******: Tomcat 폴더의 경로입니다.
**서버 시작**
+ 아래 **를 특정 데이터로 바꾼 후 다음 명령을 사용하여 Tomcat 서버를 시작합니다.
```
$ //bin/startup.sh
```
**참고**
******는 Tomcat 설치 디렉터리의 이름입니다.
웹 서버 구성을 업데이트한 후에 [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#third-offload-linux-jsse-verify) 단원으로 이동합니다.
## 4단계: HTTPS 트래픽 활성화 및 인증서 확인하기
를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM.
**Topics**
+ [인바운드 HTTPS 연결 활성화](#jsse-linux-add-security-group)
+ [HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#jsse-linux-verify-https-connection)
### 인바운드 HTTPS 연결 활성화
클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다.
**HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. **보안 그룹 생성**에서 다음을 수행합니다.
1. **보안 그룹 이름**에 생성하려는 보안 그룹의 이름을 입력합니다.
1. (선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다.
1. 웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 **VPC**로 선택합니다.
1. **규칙 추가**를 선택합니다.
1. 드롭다운 창에서 **HTTPS**를 **유형**으로 선택합니다.
1. **소스**에 소스 위치를 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 탐색 창에서 **인스턴스(Instances)**를 선택합니다.
1. 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
1. 페이지 상단의 **작업** 드롭다운 메뉴를 선택합니다. **보안**을 선택한 다음 **보안 그룹 변경**을 선택합니다.
1. **연결된 보안 그룹**에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 **보안 그룹 추가**를 선택합니다.
1. **저장**을 선택합니다.
### HTTPS가 사용자가 구성한 인증서를 사용하는지 확인
웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\$1client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.
**웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 웹 브라우저를 사용하여 서버의 퍼블릭 DNS 이름 또는 IP 주소를 사용해 웹 서버에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다. 예를 들어 **https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/**입니다.
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
+ Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오.
+ Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
**OpenSSL s\$1client를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다. **을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다.
```
openssl s_client -connect :443
```
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서에서 [Amazon EC2 인스턴스로의 라우팅 트래픽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다.
로드 밸런서를 추가하려면 [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md) 섹션을 참조하십시오.
# AWS CloudHSM KSP와 함께 IIS를 사용하여 Windows에서 SSL/TLS 오프로드
이 자습서는 Windows 웹 서버에서 AWS CloudHSM 을 사용하여 SSL/TLS 오프로드를 설정하기 위한 단계별 지침을 제공합니다.
**Topics**
+ [개요](#ssl-offload-windows-overview)
+ [1단계: 사전 조건 설정](#ssl-offload-prerequisites-windows)
+ [단계 2: 인증서 서명 요청(CSR) 및 인증서 생성](#ssl-offload-windows-create-csr-and-certificate)
+ [3단계: 웹 서버 구성하기](#ssl-offload-configure-web-server-windows)
+ [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate-windows)
## 개요
Windows에서 [Windows Server용 IIS(인터넷 정보 서비스)](https://www.iis.net/) 웹 서버 애플리케이션은 기본적으로 HTTPS를 지원합니다. [Microsoft의 CNG(Cryptography API: Next Generation)용AWS CloudHSM KSP(Key Storage Provider)](ksp-library.md)는 IIS가 암호화 오프로딩 및 키 스토리지를 위해 클러스터에서 HSM을 사용할 수 있도록 인터페이스를 제공합니다. AWS CloudHSM KSP는 IIS를 AWS CloudHSM 클러스터에 연결하는 브리지입니다.
이 자습서에서는 다음을 수행하는 방법을 보여줍니다.
+ Amazon EC2 인스턴스에 웹 서버 소프트웨어를 설치합니다.
+ AWS CloudHSM 클러스터에 프라이빗 키가 저장되는 HTTPS를 지원하도록 웹 서버 소프트웨어를 구성합니다.
+ (선택 사항) Amazon EC2를 사용하여 두 번째 웹 서버 인스턴스를 만들고 Elastic Load Balancing을 사용하여 로드 밸런서를 만듭니다. 로드 밸런서를 사용하면 여러 서버에 부하를 분산하여 성능을 향상할 수 있습니다. 또한 하나 이상의 서버에 장애가 발생할 경우 중복성과 더 높은 가용성을 제공할 수 있습니다.
시작할 준비가 되면 [1단계: 사전 조건 설정](#ssl-offload-prerequisites-windows)로 이동합니다.
## 1단계: 사전 조건 설정
플랫폼마다 필요한 필수 조건이 다릅니다. 플랫폼에 맞는 아래의 사전 조건 섹션을 사용하세요.
**Topics**
+ [클라이언트 SDK 사전 조건 5](#ssl-offload-prerequisites-windows-sdk5)
+ [Client SDK 3의 필요 조건](#ssl-offload-prerequisites-windows-sdk3)
### 클라이언트 SDK 사전 조건 5
를 사용하여 웹 서버 SSL/TLS 오프로드를 설정하려면 다음이 AWS CloudHSM필요합니다.
+ 하나 이상의 HSM이 있는 활성 AWS CloudHSM 클러스터입니다.
+ 다음 소프트웨어가 설치된 Window 운영 체제를 실행하는 Amazon EC2 인스턴스
+ Windows용 AWS CloudHSM 클라이언트 소프트웨어입니다.
+ Windows Server용 IIS(인터넷 정보 서비스).
+ HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다.
**참고**
이 자습서에서는 Microsoft Windows Server 2019를 사용합니다. Microsoft Windows Server 2016 및 2022는 지원되지 않습니다.
**HSM에서 Windows Server 인스턴스를 설정하고 CU를 생성하려면**
1. [시작하기](getting-started.md)의 단계를 수행하세요. Amazon EC2 클라이언트를 시작할 때 Windows Server 2019 AMI를 선택합니다. 해당 단계를 수행하면 한 개의 HSM이 있는 활성 클러스터가 생깁니다. Windows용 클라이언트 소프트웨어가 설치된 상태에서 Windows Server를 실행하는 Amazon EC2 AWS CloudHSM 클라이언트 인스턴스도 있습니다.
1. (선택 사항) 클러스터에 HSM을 더 추가합니다. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오.
1. Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. CloudHSM CLI를 사용하여 CU(Crypto User)를 생성합니다. CU의 사용자 이름과 암호를 기록합니다. 다음 단계에서 해당 정보가 필요합니다.
**참고**
사용자 생성에 대한 자세한 내용은 [CloudHSM CLI를 사용하여 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오.
1. 이전 단계에서 생성한 CU 사용자 이름과 암호를 사용하여 [HSM의 로그인 자격 증명을 설정](ksp-library-authentication.md)합니다.
1. 5단계에서 Windows 자격 증명 관리자를 사용하여 HSM 자격 증명을 설정한 경우 SysInternals에서 [https://live.sysinternals.com/psexec.exe](https://live.sysinternals.com/psexec.exe)를 다운로드하여 다음 명령을 *NT Authority\$1SYSTEM*으로 실행합니다.
```
psexec.exe -s "C:\Program Files\Amazon\CloudHsm\tools\set_cloudhsm_credentials.exe" --username --password
```
**과 **를 HSM 자격 증명으로 바꿉니다.
**Windows Server에 IIS를 설치하려면**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. **서버 관리자** 대시보드에서 **역할 및 기능 추가**를 선택합니다.
1. **시작하기 전에** 정보를 읽은 후 **다음**을 선택합니다.
1. **Installation Type(설치 유형)**에서 **Role-based or feature-based installation(역할 기반 또는 기능 기반 설치)**을 선택합니다. 이후 **다음**을 선택합니다.
1. **서버 선택**에서 **서버 풀에서 서버 선택**을 선택합니다. 그런 다음 **다음**을 선택합니다.
1. **서버 역할**의 경우 다음을 수행합니다.
1. **Web Server(IIS)(웹 서버(IIS))**를 선택합니다.
1. **Add features that are required for Web Server (IIS)(웹 서버(IIS)에 필요한 기능 추가)**에서 **Add Features(기능 추가)**를 선택합니다.
1. **다음**을 선택하여 서버 역할 선택을 마칩니다.
1. **Features(기능)**에 기본값을 적용합니다. 그리고 **다음**을 선택합니다.
1. **Web Server Role (IIS)(웹 서버 역할(IIS))** 정보를 읽습니다. 그리고 **다음**을 선택합니다.
1. **Select role services(역할 서비스 선택)**에서 기본 설정을 그대로 수락하거나 필요에 따라 설정을 변경합니다. 그리고 **다음**을 선택합니다.
1. **Confirmation(확인)**에서 확인 정보를 읽은 후 **Install(설치)**을 선택합니다.
1. 설치가 완료되면 **Close(닫기)**를 클릭합니다.
이 단계들을 완료한 후 [단계 2: 인증서 서명 요청(CSR) 및 인증서 생성](#ssl-offload-windows-create-csr-and-certificate)로 이동합니다.
### Client SDK 3의 필요 조건
를 사용하여 웹 서버 SSL/TLS 오프로드를 설정하려면 다음이 AWS CloudHSM필요합니다.
+ 하나 이상의 HSM이 있는 활성 AWS CloudHSM 클러스터입니다.
+ 다음 소프트웨어가 설치된 Window 운영 체제를 실행하는 Amazon EC2 인스턴스
+ Windows용 AWS CloudHSM 클라이언트 소프트웨어입니다.
+ Windows Server용 IIS(인터넷 정보 서비스).
+ HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다.
**참고**
이 자습서에서는 Microsoft Windows Server 2016을 사용합니다. Microsoft Windows Server 2012 역시 지원되지만, Microsoft Windows Server 2012 R2는 지원되지 않습니다.
**HSM에서 Windows Server 인스턴스를 설정하고 CU를 생성하려면**
1. [시작하기](getting-started.md)의 단계를 수행하세요. Amazon EC2 클라이언트를 시작할 때 Windows Server 2016 또는 Windows Server 2012 AMI를 선택합니다. 해당 단계를 수행하면 한 개의 HSM이 있는 활성 클러스터가 생깁니다. Windows용 클라이언트 소프트웨어가 설치된 상태에서 Windows Server를 실행하는 Amazon EC2 AWS CloudHSM 클라이언트 인스턴스도 있습니다.
1. (선택 사항) 클러스터에 HSM을 더 추가합니다. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오.
1. Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. CloudHSM CLI를 사용하여 CU(Crypto User)를 생성합니다. CU의 사용자 이름과 암호를 기록합니다. 다음 단계에서 해당 정보가 필요합니다.
**참고**
사용자 생성에 대한 자세한 내용은 [CloudHSM CLI를 사용하여 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오.
1. 이전 단계에서 생성한 CU 사용자 이름과 암호를 사용하여 [HSM의 로그인 자격 증명을 설정](ksp-library-prereq.md)합니다.
1. 5단계에서 Windows 자격 증명 관리자를 사용하여 HSM 자격 증명을 설정한 경우 SysInternals에서 [https://live.sysinternals.com/psexec.exe](https://live.sysinternals.com/psexec.exe)를 다운로드하여 다음 명령을 *NT Authority\$1SYSTEM*으로 실행합니다.
```
psexec.exe -s "C:\Program Files\Amazon\CloudHsm\tools\set_cloudhsm_credentials.exe" --username --password
```
**과 **를 HSM 자격 증명으로 바꿉니다.
**Windows Server에 IIS를 설치하려면**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. **서버 관리자** 대시보드에서 **역할 및 기능 추가**를 선택합니다.
1. **시작하기 전에** 정보를 읽은 후 **다음**을 선택합니다.
1. **Installation Type(설치 유형)**에서 **Role-based or feature-based installation(역할 기반 또는 기능 기반 설치)**을 선택합니다. 이후 **다음**을 선택합니다.
1. **서버 선택**에서 **서버 풀에서 서버 선택**을 선택합니다. 그런 다음 **다음**을 선택합니다.
1. **서버 역할**의 경우 다음을 수행합니다.
1. **Web Server(IIS)(웹 서버(IIS))**를 선택합니다.
1. **Add features that are required for Web Server (IIS)(웹 서버(IIS)에 필요한 기능 추가)**에서 **Add Features(기능 추가)**를 선택합니다.
1. **다음**을 선택하여 서버 역할 선택을 마칩니다.
1. **Features(기능)**에 기본값을 적용합니다. 그리고 **다음**을 선택합니다.
1. **Web Server Role (IIS)(웹 서버 역할(IIS))** 정보를 읽습니다. 그리고 **다음**을 선택합니다.
1. **Select role services(역할 서비스 선택)**에서 기본 설정을 그대로 수락하거나 필요에 따라 설정을 변경합니다. 그리고 **다음**을 선택합니다.
1. **Confirmation(확인)**에서 확인 정보를 읽은 후 **Install(설치)**을 선택합니다.
1. 설치가 완료되면 **Close(닫기)**를 클릭합니다.
이 단계들을 완료한 후 [단계 2: 인증서 서명 요청(CSR) 및 인증서 생성](#ssl-offload-windows-create-csr-and-certificate)로 이동합니다.
## 단계 2: 인증서 서명 요청(CSR) 및 인증서 생성
HTTPS를 활성화하려면 웹 서버에서 SSL/TLS 인증서와 해당되는 프라이빗 키가 필요합니다. 에서 SSL/TLS 오프로드를 사용하려면 클러스터의 HSM에 AWS CloudHSM 프라이빗 키를 AWS CloudHSM저장합니다. 이렇게 하려면 [Microsoft의 CNG(Cryptography API: Next Generation)용AWS CloudHSM KSP(Key Storage Provider)](ksp-v3-library.md)를 사용하여 인증서 서명 요청(CSR)을 생성합니다. 그런 다음, 인증서 생성을 위해 CSR에 서명하는 인증 기관(CA)에 CSR을 제공합니다.
**Topics**
+ [클라이언트 SDK 5를 사용하여 CSR 생성](#ssl-offload-windows-create-csr-new-version)
+ [클라이언트 SDK 3를 사용하여 CSR 생성](#ssl-offload-windows-create-csr-old-version)
+ [서명된 인증서를 받아 가져옵니다.](#ssl-offload-windows-create-certificate)
### 클라이언트 SDK 5를 사용하여 CSR 생성
1. Windows Server에서 텍스트 편집기를 사용하여 `IISCertRequest.inf`라는 인증서 요청을 생성합니다. 다음 예제에서는 `IISCertRequest.inf` 파일의 내용을 보여 줍니다. 이 파일에서 지정할 수 있는 섹션, 키 및 값에 대한 자세한 내용은 [Microsoft 설명서](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#BKMK_New)를 참조하십시오. `ProviderName` 값은 변경하지 마십시오.
```
[Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "CN=example.com,C=US,ST=Washington,L=Seattle,O=ExampleOrg,OU=WebServer"
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "CloudHSM Key Storage Provider"
KeyUsage = 0xf0
MachineKeySet = True
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
```
1. [Windows **certreq** 명령](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1)을 사용하여 이전 단계에서 생성한 `IISCertRequest.inf` 파일에서 CSR을 생성합니다. 다음 예제에서는 CSR을 `IISCertRequest.csr`이라는 파일에 저장합니다. 인증서 요청 파일에서 다른 파일 이름을 사용한 경우에는 *IISCertRequest.inf*를 해당되는 파일 이름으로 바꿉니다. 선택에 따라 CSR 파일에서 *IISCertRequest.csr*을 다른 파일 이름으로 바꿀 수 있습니다.
```
C:\>certreq -new IISCertRequest.inf IISCertRequest.csr
CertReq: Request Created
```
`IISCertRequest.csr` 파일에는 CSR이 포함되어 있습니다. 서명된 인증서를 얻기 위해서는 이 CSR이 필요합니다.
### 클라이언트 SDK 3를 사용하여 CSR 생성
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. 다음 명령을 사용하여 AWS CloudHSM 클라이언트 데몬을 시작합니다.
------
#### [ Amazon Linux ]
```
$ sudo start cloudhsm-client
```
------
#### [ Amazon Linux 2 ]
```
$ sudo service cloudhsm-client start
```
------
#### [ CentOS 7 ]
```
$ sudo service cloudhsm-client start
```
------
#### [ CentOS 8 ]
```
$ sudo service cloudhsm-client start
```
------
#### [ RHEL 7 ]
```
$ sudo service cloudhsm-client start
```
------
#### [ RHEL 8 ]
```
$ sudo service cloudhsm-client start
```
------
#### [ Ubuntu 16.04 LTS ]
```
$ sudo service cloudhsm-client start
```
------
#### [ Ubuntu 18.04 LTS ]
```
$ sudo service cloudhsm-client start
```
------
#### [ Windows ]
+ Windows 클라이언트 1.1.2\$1의 경우:
```
C:\Program Files\Amazon\CloudHSM>net.exe start AWSCloudHSMClient
```
+ Windows 클라이언트 1.1.1 이상의 경우:
```
C:\Program Files\Amazon\CloudHSM>start "cloudhsm_client" cloudhsm_client.exe C:\ProgramData\Amazon\CloudHSM\data\cloudhsm_client.cfg
```
------
1. Windows Server에서 텍스트 편집기를 사용하여 `IISCertRequest.inf`라는 인증서 요청을 생성합니다. 다음 예제에서는 `IISCertRequest.inf` 파일의 내용을 보여 줍니다. 이 파일에서 지정할 수 있는 섹션, 키 및 값에 대한 자세한 내용은 [Microsoft 설명서](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#BKMK_New)를 참조하십시오. `ProviderName` 값은 변경하지 마십시오.
```
[Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "CN=example.com,C=US,ST=Washington,L=Seattle,O=ExampleOrg,OU=WebServer"
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "Cavium Key Storage Provider"
KeyUsage = 0xf0
MachineKeySet = True
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
```
1. [Windows **certreq** 명령](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1)을 사용하여 이전 단계에서 생성한 `IISCertRequest.inf` 파일에서 CSR을 생성합니다. 다음 예제에서는 CSR을 `IISCertRequest.csr`이라는 파일에 저장합니다. 인증서 요청 파일에서 다른 파일 이름을 사용한 경우에는 *IISCertRequest.inf*를 해당되는 파일 이름으로 바꿉니다. 선택에 따라 CSR 파일에서 *IISCertRequest.csr*을 다른 파일 이름으로 바꿀 수 있습니다.
```
C:\>certreq -new IISCertRequest.inf IISCertRequest.csr
SDK Version: 2.03
CertReq: Request Created
```
`IISCertRequest.csr` 파일에는 CSR이 포함되어 있습니다. 서명된 인증서를 얻기 위해서는 이 CSR이 필요합니다.
### 서명된 인증서를 받아 가져옵니다.
프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우에는 CSR 파일(`IISCertRequest.csr`)을 CA에 전송하고 CA를 사용하여 서명된 SSL/TLS 인증서를 생성합니다.
CA 사용의 대안으로 [OpenSSL](https://www.openssl.org/) 같은 도구를 사용하여 자체 서명 인증서를 생성할 수 있습니다.
**주의**
자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다.
다음 절차에서는 자체 서명 인증서를 생성하고 이를 사용해 웹 서버의 CSR을 서명하는 방법을 보여줍니다.
**자체 서명된 인증서를 생성하려면**
1. OpenSSL 명령을 사용하여 프라이빗 키를 생성합니다. 선택에 따라 *SelfSignedCA.key*를 프라이빗 키가 포함된 파일 이름으로 바꿀 수 있습니다.
```
openssl genrsa -aes256 -out SelfSignedCA.key 2048
Generating RSA private key, 2048 bit long modulus
......................................................................+++
.........................................+++
e is 65537 (0x10001)
Enter pass phrase for SelfSignedCA.key:
Verifying - Enter pass phrase for SelfSignedCA.key:
```
1. OpenSSL 명령을 사용하여 이전 단계에서 생성한 프라이빗 키를 통해 자체 서명 인증서를 생성합니다. 이것은 대화식 명령입니다. 화면의 지침을 읽고 프롬프트의 메시지를 따릅니다. *SelfSignedCA.key*를 프라이빗 키(다를 경우)가 포함된 파일 이름으로 바꿉니다. 선택에 따라 *SelfSignedCA.crt*를 자체 서명 인증서가 포함된 파일 이름으로 바꿀 수 있습니다.
```
openssl req -new -x509 -days 365 -key SelfSignedCA.key -out SelfSignedCA.crt
Enter pass phrase for SelfSignedCA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
```
**자체 서명 인증서를 사용하여 웹 서버의 CSR을 서명하려면**
+ 다음 OpenSSL 명령을 사용해 프라이빗 키와 자체 서명 인증서를 통해 CSR을 서명합니다. 다음을 해당 데이터(다를 경우)가 포함된 파일 이름으로 바꿉니다.
+ *IISCertRequest.csr* – 웹 서버의 CSR이 포함된 파일 이름
+ *SelfSignedCA.crt* – 자체 서명된 인증서가 포함된 파일의 이름
+ *SelfSignedCA.key* – 개인 키가 포함된 파일 이름
+ *IISCert.crt* – 웹 서버의 서명된 인증서를 포함하는 파일의 이름
```
openssl x509 -req -days 365 -in IISCertRequest.csr \
-CA SelfSignedCA.crt \
-CAkey SelfSignedCA.key \
-CAcreateserial \
-out IISCert.crt
Signature ok
subject=/ST=IIS-HSM/L=IIS-HSM/OU=IIS-HSM/O=IIS-HSM/CN=IIS-HSM/C=IIS-HSM
Getting CA Private Key
Enter pass phrase for SelfSignedCA.key:
```
이전 단계를 완료하고 나면 웹 서버에 대한 서명 인증서(`IISCert.crt`)와 자체 서명 인증서(`SelfSignedCA.crt`)를 얻게 됩니다. 이러한 파일을 얻었으면 [3단계: 웹 서버 구성하기](#ssl-offload-configure-web-server-windows)로 이동합니다.
## 3단계: 웹 서버 구성하기
[이전 단계](#ssl-offload-windows-create-csr-and-certificate)가 끝날 때 생성한 HTTPS 인증서를 사용하려면 IIS 웹사이트의 구성을 업데이트하십시오. 그러면 AWS CloudHSM이 지원되는 SSL/TLS 오프로드의 Windows 웹 서버 소프트웨어(IIS) 설정이 완료됩니다.
CSR 서명을 위해 자체 서명 인증서를 사용한 경우에는 먼저 신뢰할 수 있는 Windows 루트 인증 기관에 자체 서명 인증서를 가져와야 합니다.
**자체 서명 인증서를 신뢰할 수 있는 Windows 루트 인증 기관에 가져오려면**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에 자체 서명 인증서를 복사합니다.
1. Windows Server에서 **제어판**을 엽니다.
1. **제어판 검색**에 **certificates**를 입력합니다. 그런 다음 **컴퓨터 인증서 관리**를 선택합니다.
1. **인증서 - 로컬 컴퓨터** 창에서 **신뢰할 수 있는 루트 인증 기관**을 두 번 클릭합니다.
1. **인증서**를 마우스 오른쪽 버튼으로 클릭하고 **모든 작업**, **가져오기**를 선택합니다.
1. **인증서 가져오기 마법사**에서 **다음**을 선택합니다.
1. **찾아보기**에서 자체 서명 인증서를 찾아서 선택합니다. [이 자습서의 이전 단계](#ssl-offload-windows-create-csr-and-certificate)에 나와 있는 지침에 따라 생성한 자체 서명 인증서는 이름이 `SelfSignedCA.crt`으로 지정됩니다. **열기**를 선택합니다.
1. **다음**을 선택합니다.
1. **Certificate Store**에서 **다음 스토어에 모든 인증서 배치**를 선택합니다. 그런 다음 **인증서 저장소**에 **신뢰할 수 있는 루트 인증 기관이** 선택되었는지 확인하십시오.
1. **다음**을 선택한 다음 **마침**을 선택합니다.
**IIS 웹사이트의 구성 업데이트**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. AWS CloudHSM 클라이언트 데몬을 시작합니다.
1. 웹 서버의 서명된 인증서 복사 - [이 자습서의 이전 단계](#ssl-offload-windows-create-csr-and-certificate)가 끝날 때 생성한 인증서를 Windows 서버에 복사합니다.
1. Windows Server에서 다음 예제에서와 같이 [Windows **certreq** 명령](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1)을 사용하여 서명 인증서를 수락합니다. *IISCert.crt*를 웹 서버의 서명 인증서가 포함된 파일 이름으로 바꿉니다.
```
C:\>certreq -accept IISCert.crt
SDK Version: 2.03
```
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. **서버 관리자** 대시보드의 오른쪽 상단 모서리에서 **도구**, **인터넷 정보 서비스(IIS) 관리자**를 선택합니다.
1. **인터넷 정보 서비스(IIS) 관리자** 창에서 서버 이름을 두 번 클릭합니다. 그런 다음 **사이트**를 두 번 클릭합니다. 웹사이트를 선택합니다.
1. **SSL 설정**을 선택합니다. 그런 다음 창의 오른쪽에서 **바인딩**을 선택합니다.
1. **사이트 바인딩** 창에서 **추가**를 선택합니다.
1. **유형**에서 **https**를 선택합니다. **SSL 인증서**에서 [이 자습서의 이전 단계](#ssl-offload-windows-create-csr-and-certificate)가 끝날 때 생성한 HTTPS 인증서를 선택합니다.
**참고**
이 인증서 바인딩 중에 오류가 발생하면, 서버를 다시 시작하고 이 단계를 다시 시도하십시오.
1. **확인**를 선택합니다.
웹사이트의 구성을 업데이트한 후에 [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate-windows)로 이동합니다.
## 4단계: HTTPS 트래픽 활성화 및 인증서 확인하기
를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM.
**Topics**
+ [인바운드 HTTPS 연결 활성화](#ssl-offload-add-security-group-windows)
+ [HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-windows)
### 인바운드 HTTPS 연결 활성화
클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다.
**HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **보안 그룹**을 선택합니다.
1. **보안 그룹 생성**을 선택합니다.
1. **보안 그룹 생성**에서 다음을 수행합니다.
1. **보안 그룹 이름**에 생성하려는 보안 그룹의 이름을 입력합니다.
1. (선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다.
1. 웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 **VPC**로 선택합니다.
1. **규칙 추가**를 선택합니다.
1. 드롭다운 창에서 **HTTPS**를 **유형**으로 선택합니다.
1. **소스**에 소스 위치를 입력합니다.
1. **보안 그룹 생성**을 선택합니다.
1. 탐색 창에서 **인스턴스(Instances)**를 선택합니다.
1. 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
1. 페이지 상단의 **작업** 드롭다운 메뉴를 선택합니다. **보안**을 선택한 다음 **보안 그룹 변경**을 선택합니다.
1. **연결된 보안 그룹**에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 **보안 그룹 추가**를 선택합니다.
1. **저장**을 선택합니다.
### HTTPS가 사용자가 구성한 인증서를 사용하는지 확인
웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\$1client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.
**웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 웹 브라우저를 사용하여 서버의 퍼블릭 DNS 이름 또는 IP 주소를 사용해 웹 서버에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다. 예를 들어 **https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/**입니다.
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
+ Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오.
+ Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
**OpenSSL s\$1client를 사용하여 SSL/TLS 오프로드를 확인하려면**
1. 다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다. **을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다.
```
openssl s_client -connect :443
```
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서에서 [Amazon EC2 인스턴스로의 라우팅 트래픽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다.
로드 밸런서를 추가하려면 [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md) 섹션을 참조하십시오.
# Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)
웹 서버 하나를 사용하여 SSL/TLS 오프로드를 설정한 후 추가 웹 서버와 HTTPS 트래픽을 웹 서버로 라우팅하는 Elastic Load Balancing 로드 밸런서를 생성할 수 있습니다. 로드 밸런서는 둘 이상의 서버에 걸쳐 트래픽의 균형을 조정하여 개별 웹 서버의 부하를 줄일 수 있습니다. 또한 로드 밸런서는 웹 서버의 상태를 모니터링하여 정상적 서버로만 트래픽을 라우팅하므로 웹사이트의 가용성을 높일 수 있습니다. 웹 서버에 장애가 발생하면 로드 밸런서는 해당 웹 서버로의 트래픽 라우팅을 자동으로 중지합니다.
**Topics**
+ [1단계. 두 번째 웹 서버의 서브넷 생성](#ssl-offload-load-balancer-create-new-subnet)
+ [2단계. 두 번째 웹 서버 생성](#ssl-offload-load-balancer-create-web-server)
+ [3단계. 로드 밸런서 생성](#ssl-offload-load-balancer-create-load-balancer)
## 1단계. 두 번째 웹 서버의 서브넷 생성
다른 웹 서버를 생성하려면 먼저 기존 웹 서버와 AWS CloudHSM 클러스터가 포함된 동일한 VPC에 새 서브넷을 생성해야 합니다.
**새 서브넷을 생성하려면**
1. [Amazon VPC 콘솔의 **서브넷** 섹션을](https://console.aws.amazon.com/vpc/home#subnets:) 엽니다.
1. **서브넷 생성**을 선택합니다.
1. [**Create Subnet**] 대화 상자에서 다음 작업을 수행합니다.
1. **Name 태그**에 서브넷의 이름을 입력합니다.
1. **VPC**에서 기존 웹 서버 및 AWS CloudHSM 클러스터가 포함된 AWS CloudHSM VPC를 선택합니다.
1. **가용 영역**에서 기존 웹 서버가 포함된 가용 영역과는 다른 가용 영역을 선택합니다.
1. **IPv4 CIDR 블록**에 서브넷에 사용할 CIDR 블록을 입력합니다. 예를 들어 **10.0.10.0/24**를 입력합니다.
1. **예, 생성**을 선택합니다.
1. 기존 웹 서버가 포함된 퍼블릭 서브넷 옆에 있는 확인란을 선택합니다. 이것은 이전 단계에서 생성한 퍼블릭 서브넷과 다릅니다.
1. 콘텐츠 창에서 **라우팅 테이블** 탭을 선택합니다. 그런 다음 라우팅 테이블의 링크를 선택합니다.
![\[Amazon VPC 콘솔에서 라우팅 테이블 링크를 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/console-vpc-choose-route-table.png)
1. 라우팅 테이블 옆의 확인란을 선택합니다.
1. **서브넷 연결** 탭을 선택합니다. 그런 다음 **편집**을 선택합니다.
1. 이 절차의 앞부분에서 생성한 퍼블릭 서브넷 옆에 있는 확인란을 선택합니다. 그런 다음 **저장**을 선택합니다.
## 2단계. 두 번째 웹 서버 생성
다음 단계를 완료하여 기존 웹 서버와 동일한 구성으로 두 번째 웹 서버를 생성합니다.
**두 번째 웹 서버를 생성하려면**
1. Amazon EC2 콘솔의 [https://console.aws.amazon.com/ec2/v2/home#Instances:](https://console.aws.amazon.com/ec2/v2/home#Instances:) 섹션을 엽니다.
1. 기존 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
1. **작업**, **이미지**, **이미지 생성**을 차례로 선택합니다.
1. **이미지 생성** 대화 상자에서 다음 작업을 수행합니다.
1. **이미지 이름**에 이미지의 이름을 입력합니다.
1. **이미지 설명**에 이미지에 대한 설명을 입력합니다.
1. **이미지 생성**을 선택합니다. 이 작업은 기존 웹 서버를 재부팅합니다.
1. **보류 중인 이미지 ami-** 보기** 링크를 선택합니다.
![\[Amazon EC2 콘솔에서 보류 중인 이미지 보기 링크를 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/console-ec2-choose-view-pending-image.png)
**상태** 열에서 이미지 상태에 유의하십시오. 이미지 상태가 **사용 가능**이면(몇 분 정도 걸릴 수 있음) 다음 단계로 이동합니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 기존 웹 서버 옆에 있는 확인란을 선택합니다.
1. **작업**을 선택하고 **기존 인스턴스를 기반으로 시작**을 선택합니다.
1. **AMI 편집**을 선택합니다.
![\[Amazon EC2 콘솔에서 AMI 편집 링크를 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/console-ec2-choose-edit-ami.png)
1. 왼쪽 탐색 창에서 **나의 AMI**를 선택합니다. 그 다음 검색 상자에서 텍스트를 삭제합니다.
1. 웹 서버 이미지 옆에 있는 **선택**을 선택합니다.
1. **Yes, I want to continue with this AMI(예, 이 AMI를 계속 사용)(** - ami-**)**를 선택합니다.
1. **다음**을 선택합니다.
1. 인스턴스 유형을 선택하고 **Next: Configure Instance Details(다음: 인스턴스 정보 구성)**를 선택합니다.
1. **3단계: 인스턴스 세부 정보 구성**에서 다음을 수행합니다.
1. **네트워크**에서 기존의 웹 서버가 포함된 VPC를 선택합니다.
1. **서브넷**에서 두 번째 웹 서버를 위해 생성한 퍼블릭 서브넷을 선택합니다.
1. **퍼블릭 IP 자동 할당**에서 **활성화**를 선택합니다.
1. 나머지 인스턴스 세부 정보를 원하는 대로 변경합니다. 그런 다음 **Next: Add Storage(다음: 스토리지 추가)**를 선택합니다.
1. 스토리지 설정을 원하는 대로 변경합니다. **다음: 태그 추가**를 선택합니다.
1. 필요에 따라 태그를 추가하거나 편집합니다. 그러고 나서 **다음: 보안 그룹 구성**을 선택합니다.
1. **6단계: 보안 그룹 구성**에서 다음을 수행합니다.
1. **보안 그룹 할당**에서 **Select an existing security group(기존 보안 그룹 선택)**을 선택합니다.
1. **cloudhsm-**-sg**라는 보안 그룹 옆에 있는 확인란을 선택합니다. AWS CloudHSM 은 [클러스터를 생성](create-cluster.md)할 때 사용자를 대신하여 이 보안 그룹을 생성했습니다. 웹 서버 인스턴스가 클러스터의 HSM에 연결되도록 허용하려면 이 보안 그룹을 선택해야 합니다.
1. 인바운드 HTTPS 트래픽을 허용하는 보안 그룹 옆에 있는 확인란을 선택합니다. [이 보안 그룹은 이전에 생성했습니다](ssl-offload-windows.md#ssl-offload-add-security-group-windows).
1. (선택 사항) 네트워크에서 인바운드 SSH(Linux용) 또는 RDP(Windows용) 트래픽을 허용하는 보안 그룹 옆의 확인란을 선택합니다. 즉, 보안 그룹은 포트 22(Linux의 SSH용) 또는 포트 3389(Windows의 RDP용)에서 인바운드 TCP 트래픽을 허용해야 합니다. 그렇지 않으면 클라이언트 인스턴스에 연결할 수 있습니다. 이와 같은 보안 그룹이 없는 경우, 보안 그룹을 생성한 다음 이후 클라이언트 인스턴스에 할당해야 합니다.
**검토 및 시작**을 선택합니다.
1. 인스턴스 세부 정보를 검토한 후 **시작**을 선택합니다.
1. 기존 키 페어를 사용하여 인스턴스를 시작할지, 새 키 페어를 생성할지 또는 키 페어 없이 인스턴스를 시작할지 선택합니다.
+ 기존 키 페어를 사용하려면 다음 작업을 수행하십시오.
1. [**Choose an existing key pair**]를 선택합니다.
1. [**Select a key pair**]의 경우 사용할 키 페어를 선택합니다.
1. **선택한 프라이빗 키 파일(**.pem)에 액세스할 수 있음을 확인합니다. 이 파일이 없으면 내 인스턴스에 로그인할 수 없습니다.** 옆에 있는 확인란을 선택합니다.
+ 새 키 페어를 생성하려면 다음 작업을 수행하십시오.
1. **새 키 페어 생성**을 선택합니다.
1. **키 페어 이름**에 키 페어 이름을 입력합니다.
1. [**Download Key Pair**]를 선택하고 안전하고 액세스 가능한 위치에 프라이빗 키 파일을 저장합니다.
**주의**
이 시점 이후에는 프라이빗 키 파일을 다시 다운로드할 수 없습니다. 지금 프라이빗 키 파일을 다운로드하지 않으면 클라이언트 인스턴스에 액세스할 수 없습니다.
+ 키 페어 없이 인스턴스를 시작하려면 다음을 수행합니다.
1. **키 페어 없이 계속**을 선택합니다.
1. **이 AMI에 기본 제공된 암호를 이미 알고 있는 경우가 아니면 이 인스턴스에 연결할 수 없는 것으로 알고 있습니다** 옆에 있는 확인란을 선택합니다.
**인스턴스 시작(Launch Instances)**을 선택합니다.
## 3단계. 로드 밸런서 생성
다음 단계를 완료하여 HTTPS 트래픽을 웹 서버로 라우팅하는 Elastic Load Balancing 로드 밸런서를 생성합니다.
**로드 밸런서 생성**
1. Amazon EC2 콘솔의 [ https://console.aws.amazon.com/ec2/v2/home#LoadBalancers:]( https://console.aws.amazon.com/ec2/v2/home#LoadBalancers:) 섹션을 엽니다.
1. **로드 밸런서 생성**을 선택합니다.
1. **Network Load Balancer** 섹션에서 **생성**을 선택합니다.
1. **1단계: 로드 밸런서 구성**에서 다음을 수행합니다.
1. **이름**에 생성할 로드 밸런서 이름을 입력합니다.
1. **리스너** 섹션의 **로드 밸런서 포트**에서 값을 **443**으로 변경합니다.
1. **가용 영역** 섹션의 **VPC**에서 웹 서버가 포함된 VPC를 선택합니다.
1. **가용 영역** 섹션에서 웹 서버가 포함된 서브넷을 선택합니다.
1. **다음: 라우팅 구성(Next: Configure Routing)**을 선택합니다.
1. **2단계: 라우팅 구성**에서 다음을 수행합니다.
1. **이름**에 생성하려는 대상 그룹의 이름을 입력합니다.
1. **포트**에서 값을 **443**으로 변경합니다.
1. **다음: 대상 등록(Next: Register Targets)**을 선택합니다.
1. **3단계: 대상 등록**에서 다음을 수행합니다.
1. **인스턴스** 섹션에서 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다. 그런 다음 **등록된 항목에 추가**를 선택합니다.
1. **다음: 검토**를 선택합니다.
1. 로드 밸런서 세부 정보를 검토한 후 **생성**을 선택합니다.
1. 로드 밸런서가 성공적으로 생성되면 **닫기**를 선택합니다.
위의 단계를 완료하면 Amazon EC2 콘솔에 Elastic Load Balancing 로드 밸런서가 표시됩니다.
로드 밸런서의 상태가 활성이면 로드 밸런서가 작동 중임을 확인할 수 있습니다. 즉, 로드 밸런서가 AWS CloudHSM을 사용한 SSL/TLS 오프로드로 HTTPS 트래픽을 웹 서버에 전송하고 있음을 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\$1client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다.
**로드 밸런서가 웹 브라우저에서 작동하고 있음을 확인하려면**
1. Amazon EC2 콘솔에서 방금 생성한 로드 밸런서의 **DNS 이름**을 찾습니다. 그런 다음 DNS 이름을 선택하고 복사합니다.
1. Mozilla Firefox 또는 Google Chrome 같은 웹 브라우저로 로드 밸런서의 DNS 이름을 사용하여 로드 밸런서에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다.
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
+ Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오.
+ Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
1. 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
**로드 밸런서가 OpenSSL s\$1client에서 작동하는지 확인하려면**
1. 다음 OpenSSL 명령으로 HTTPS를 사용하여 로드 밸런서에 연결합니다. **을 로드 밸런서의 DNS 이름으로 바꿉니다.
```
openssl s_client -connect :443
```
**작은 정보**
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오.
1. 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 서버의 프라이빗 키가 AWS CloudHSM 클러스터의 HSM에 저장된 HTTPS로 보호되는 웹 사이트가 생겼습니다. 웹사이트에 2개의 웹 서버와 효율 및 가용성 개선을 돕는 로드 밸런서가 하나 있습니다.
# 를 사용하여 Windows Server를 인증 기관(CA)으로 구성 AWS CloudHSM
AWS CloudHSM 는 클라이언트 SDK 3 및 클라이언트 SDK 5를 통해 Windows Server를 인증 기관(CA)으로 구성할 수 있는 지원을 제공합니다. 이러한 도구를 사용하는 단계는 현재 다운로드한 클라이언트 SDK의 버전에 따라 달라집니다. 다음 섹션에서는 각 SDK에 정보를 제공합니다.
**Topics**
+ [Windows Server CA를 사용하는 클라이언트 SDK 5](win-ca-overview-sdk5.md)
+ [Windows Server CA를 사용하는 클라이언트 SDK 3](win-ca-overview-sdk3.md)
# 클라이언트 SDK 5를 사용하여 Windows Server를 인증 기관(CA)으로 구성
퍼블릭 키 인프라(PKI)에서 인증 기관(CA)은 디지털 인증서를 발행하는 믿을 수 있는 단체입니다. 이러한 디지털 인증서는 퍼블릭 키 암호화 및 디지털 서명을 사용하여 퍼블릭 키를 ID(개인 또는 조직)에 바인딩합니다. CA를 운영하려면 CA에서 발급한 인증서에 서명하는 프라이빗 키를 보호하여 신뢰성을 유지해야 합니다. AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장하고 HSM을 사용하여 암호화 서명 작업을 수행할 수 있습니다.
이 자습서에서는 Windows Server 및 AWS CloudHSM 를 사용하여 CA를 구성합니다. Windows 서버에 Windows용 AWS CloudHSM 클라이언트 소프트웨어를 설치한 후 Windows Server에 AD CS(Active Directory Certificate Services) 역할을 추가합니다. 이 역할을 구성할 때 AWS CloudHSM 키 스토리지 공급자(KSP)를 사용하여 CA의 프라이빗 키를 생성하고 AWS CloudHSM 클러스터에 저장합니다. KSP는 Windows 서버를 AWS CloudHSM 클러스터에 연결하는 브리지입니다. 마지막 단계에서는 Windows Server CA와 함께 인증서 서명 요청(CSR)을 서명합니다.
자세한 내용은 다음 항목을 참조하세요.
**Topics**
+ [1단계: 사전 조건 설정](#win-ca-prerequisites-sdk5)
+ [2단계:를 사용하여 Windows Server CA 생성 AWS CloudHSM](#win-ca-setup-sdk5)
+ [3단계:를 사용하여 Windows Server CA로 인증서 서명 요청(CSR)에 서명 AWS CloudHSM](#win-ca-sign-csr-sdk5)
## 1단계: 사전 조건 설정
Windows Server를 CA(인증 기관)로 설정하려면 다음이 AWS CloudHSM필요합니다.
+ 하나 이상의 HSM이 있는 활성 AWS CloudHSM 클러스터입니다.
+ Windows용 AWS CloudHSM 클라이언트 소프트웨어가 설치된 Windows Server 운영 체제를 실행하는 Amazon EC2 인스턴스입니다. 이 자습서에서는 Microsoft Windows Server 2016을 사용합니다.
+ HSM에서 CA 프라이빗 키를 소유하고 관리할 CU(Cryptographic User)입니다.
**를 사용하여 Windows Server CA에 대한 사전 조건을 설정하려면 AWS CloudHSM**
1. [시작하기](getting-started.md)의 단계를 수행하세요. Amazon EC2 클라이언트를 시작할 때 Windows Server AMI를 선택합니다. 이 자습서에서는 Microsoft Windows Server 2016을 사용합니다. 해당 단계를 수행하면 한 개의 HSM이 있는 활성 클러스터가 생깁니다. Windows용 클라이언트 소프트웨어가 설치된 상태에서 Windows Server를 실행하는 Amazon EC2 AWS CloudHSM 클라이언트 인스턴스도 있습니다.
1. (선택 사항) 클러스터에 HSM을 더 추가합니다. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 단원을 참조하십시오.
1. 클라이언트 인스턴스에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. [CloudHSM CLI로 HSM 사용자 관리](manage-hsm-users-chsm-cli.md) 또는 [CloudHSM 관리 유틸리티(CMU)로 HSM 사용자 관리](manage-hsm-users-cmu.md)를 사용하여 Crypto User(CU)를 생성합니다. CU의 사용자 이름과 암호를 기록합니다. 다음 단계에서 해당 정보가 필요합니다.
1. 이전 단계에서 생성한 CU 사용자 이름과 암호를 사용하여 [HSM의 로그인 자격 증명을 설정](ksp-library-authentication.md)합니다.
1. 5단계에서 Windows 자격 증명 관리자를 사용하여 HSM 자격 증명을 설정한 경우 SysInternals에서 [https://live.sysinternals.com/psexec.exe](https://live.sysinternals.com/psexec.exe)를 다운로드하여 다음 명령을 *NT Authority\$1SYSTEM*으로 실행합니다.
```
psexec.exe -s "C:\Program Files\Amazon\CloudHsm\tools\set_cloudhsm_credentials.exe" --username --password
```
**과 **를 HSM 자격 증명으로 바꿉니다.
를 사용하여 Windows Server CA를 생성하려면 로 AWS CloudHSM이동합니다[Windows Server CA 생성](#win-ca-setup-sdk5).
## 2단계:를 사용하여 Windows Server CA 생성 AWS CloudHSM
Windows Server CA를 만들려면 Windows Server에 AD CS(Active Directory 인증서 서비스) 역할을 추가합니다. 이 역할을 추가할 때 AWS CloudHSM 키 스토리지 공급자(KSP)를 사용하여 CA의 프라이빗 키를 생성하고 AWS CloudHSM 클러스터에 저장합니다.
**참고**
Windows Server CA를 만들 때 루트 CA 또는 종속 CA를 만들도록 선택할 수 있습니다. 일반적으로 퍼블릭 키 인프라 설계 및 조직의 보안 정책을 기준으로 결정합니다. 이 자습서에서는 단순 루트 CA를 만드는 방법을 설명합니다.
**Windows Server에 AD CS 역할을 추가하고 CA의 프라이빗 키를 생성하려면**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. **서버 관리자** 대시보드에서 **역할 및 기능 추가**를 선택합니다.
1. **시작하기 전에** 정보를 읽은 후 **다음**을 선택합니다.
1. **Installation Type(설치 유형)**에서 **Role-based or feature-based installation(역할 기반 또는 기능 기반 설치)**을 선택합니다. 이후 **다음**을 선택합니다.
1. **서버 선택**에서 **서버 풀에서 서버 선택**을 선택합니다. 그런 다음 **다음**을 선택합니다.
1. **서버 역할**의 경우 다음을 수행합니다.
1. **Active Directory 인증서 서비스**를 선택합니다.
1. **Active Directory 인증서 서비스에 필요한 기능을 추가하시겠습니까?**라는 메시지가 표시되면 **기능 추가**를 선택합니다.
1. **다음**을 선택하여 서버 역할 선택을 마칩니다.
1. **기능**에서 기본 설정을 그대로 수락하고 **다음**을 선택합니다.
1. **AD CS**의 경우 다음을 수행합니다.
1. **다음**을 선택합니다.
1. **Certification Authority**를 선택한 다음 **다음**을 선택합니다.
1. **확인**에서 확인 정보를 읽은 다음 **설치**를 선택합니다. 창을 닫습니다.
1. 강조 표시된 **대상 서버에서 Active Directory 인증서 서비스 구성** 링크를 선택합니다.
1. **자격 증명**에서 표시된 자격 증명을 확인하거나 변경합니다. 그리고 **다음**을 선택합니다.
1. **역할 서비스**에서 **인증 기관**을 선택합니다. 그리고 **다음**을 선택합니다.
1. **설치 유형**에서 **독립 CA**를 선택합니다. 그리고 **다음**을 선택합니다.
1. **CA 유형**에서 **루트 CA**를 선택합니다. 그리고 **다음**을 선택합니다.
**참고**
퍼블릭 키 인프라 설계 및 조직의 보안 정책을 기반으로 루트 CA 또는 하위 CA를 만들도록 선택할 수 있습니다. 이 자습서에서는 단순 루트 CA를 만드는 방법을 설명합니다.
1. **프라이빗 키**에서 **프라이빗 키 새로 만들기**를 선택합니다. 그리고 **다음**을 선택합니다.
1. **암호화**에서 다음을 수행합니다.
1. **암호화 공급자 선택**에서 메뉴의 **CloudHSM 키 저장소 공급자** 옵션 중 하나를 선택합니다. 이 옵션은 AWS CloudHSM KSP입니다. 예를 들어 **RSA\$1CloudHSM Key Storage Provider**를 선택할 수 있습니다.
1. **키 길이**에서 키 길이 옵션 중 하나를 선택합니다.
1. **인증 기관에서 발급한 인증서에 서명하기 위한 해시 알고리즘을 선택합니다.**에서 해시 알고리즘 옵션 중 하나를 선택합니다.
**다음**을 선택합니다.
1. **CA 이름**에서 다음을 수행합니다.
1. (옵션) 일반 이름을 수정합니다.
1. (옵션) 고유 이름 접미사를 입력합니다.
**다음**을 선택합니다.
1. **유효 기간**에 년, 월, 주 또는 일 단위로 기간을 지정합니다. 그리고 **다음**을 선택합니다.
1. **인증서 데이터베이스**에서 기본값을 사용하거나 선택적으로 데이터베이스와 데이터베이스 로그의 위치를 변경할 수 있습니다. 그리고 **다음**을 선택합니다.
1. **확인**에서 CA에 대한 정보를 검토하고 **구성**을 선택합니다.
1. **닫기**를 선택한 다음 **닫기**를 차례로 선택합니다.
이제가 포함된 Windows Server CA가 생겼습니다 AWS CloudHSM. CA로 인증서 서명 요청(CSR)에 서명하는 방법을 배우려면 [CSR 서명하기](#win-ca-sign-csr-sdk5) 섹션으로 이동합니다.
## 3단계:를 사용하여 Windows Server CA로 인증서 서명 요청(CSR)에 서명 AWS CloudHSM
와 함께 Windows Server CA를 사용하여 인증서 서명 요청(CSR)에 서명 AWS CloudHSM 할 수 있습니다. 이러한 단계들을 완료하려면 유효한 CSR이 필요합니다. CSR은 다음을 포함한 다양한 방법으로 만들 수 있습니다.
+ OpenSSL 사용
+ Windows Server IIS(인터넷 정보 서비스) 관리자 사용
+ Microsoft Management Console(MMC)에서 스냅인 인증서 사용
+ Windows의 명령줄 유틸리티에서 **certreq** 사용
CSR 생성 단계는 본 자습서에서 다루지 않습니다. CSR이 있으면 Windows Server CA로 서명할 수 있습니다.
**CSR로 Windows Server CA 서명**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. 오르쪽 상단 모서리에 **서버 관리자** 대시보드에서 **도구**, **인증 기관**을 선택합니다.
1. **인증 기관** 창에서 컴퓨터 이름을 선택합니다.
1. **작업** 메뉴에서 **모든 작업**을 선택한 후 **새 요청 제출**을 선택합니다.
1. CSR 파일을 선택한 다음 **열기를** 선택합니다.
1. **인증 기관** 창에서 **대기 중인 요청**을 두번 클릭합니다.
1. 대기 중인 요청을 선택합니다. 그런 다음 **작업** 메뉴에서 **모든 작업**을 선택하고 **문제**를 선택합니다.
1. 서명 인증서를 보려면 **인증 기관** 창에서 **발급된 요청**을 두번 클릭합니다.
1. (옵션) 서명 인증서를 파일에 내보내려면 다음 단계를 완료해야 합니다.
1. **인증 기관** 창에 보이는 인증서를 두번 클릭합니다.
1. **세부 정보** 탭을 선택한 다음 **파일로 복사**를 선택합니다.
1. **인증서 내보내기 마법사**에서 지침을 따릅니다.
이제를 사용하는 Windows Server CA AWS CloudHSM와 Windows Server CA에서 서명한 유효한 인증서가 있습니다.
# 클라이언트 SDK 3를 사용하여 Windows Server를 인증 기관(CA)으로 구성
퍼블릭 키 인프라(PKI)에서 인증 기관(CA)은 디지털 인증서를 발행하는 믿을 수 있는 단체입니다. 이러한 디지털 인증서는 퍼블릭 키 암호화 및 디지털 서명을 사용하여 퍼블릭 키를 ID(개인 또는 조직)에 바인딩합니다. CA를 운영하려면 CA에서 발급한 인증서에 서명하는 프라이빗 키를 보호하여 신뢰성을 유지해야 합니다. AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장하고 HSM을 사용하여 암호화 서명 작업을 수행할 수 있습니다.
이 자습서에서는 Windows Server 및 AWS CloudHSM 를 사용하여 CA를 구성합니다. Windows 서버에 Windows용 AWS CloudHSM 클라이언트 소프트웨어를 설치한 후 Windows Server에 AD CS(Active Directory Certificate Services) 역할을 추가합니다. 이 역할을 구성할 때 AWS CloudHSM 키 스토리지 공급자(KSP)를 사용하여 CA의 프라이빗 키를 생성하고 AWS CloudHSM 클러스터에 저장합니다. KSP는 Windows 서버를 AWS CloudHSM 클러스터에 연결하는 브리지입니다. 마지막 단계에서는 Windows Server CA와 함께 인증서 서명 요청(CSR)을 서명합니다.
자세한 내용은 다음 항목을 참조하세요.
**Topics**
+ [1단계: 사전 조건 설정](#win-ca-prerequisites-sdk3)
+ [2단계:를 사용하여 Windows Server CA 생성 AWS CloudHSM](#win-ca-setup-sdk3)
+ [3단계:를 사용하여 Windows Server CA로 인증서 서명 요청(CSR)에 서명 AWS CloudHSM](#win-ca-sign-csr-sdk3)
## 1단계: 사전 조건 설정
Windows Server를 CA(인증 기관)로 설정하려면 다음이 AWS CloudHSM필요합니다.
+ 하나 이상의 HSM이 있는 활성 AWS CloudHSM 클러스터입니다.
+ Windows용 AWS CloudHSM 클라이언트 소프트웨어가 설치된 Windows Server 운영 체제를 실행하는 Amazon EC2 인스턴스입니다. 이 자습서에서는 Microsoft Windows Server 2016을 사용합니다.
+ HSM에서 CA 프라이빗 키를 소유하고 관리할 CU(Cryptographic User)입니다.
**를 사용하여 Windows Server CA에 대한 사전 조건을 설정하려면 AWS CloudHSM**
1. [시작하기](getting-started.md)의 단계를 수행하세요. Amazon EC2 클라이언트를 시작할 때 Windows Server AMI를 선택합니다. 이 자습서에서는 Microsoft Windows Server 2016을 사용합니다. 해당 단계를 수행하면 한 개의 HSM이 있는 활성 클러스터가 생깁니다. Windows용 클라이언트 소프트웨어가 설치된 상태에서 Windows Server를 실행하는 Amazon EC2 AWS CloudHSM 클라이언트 인스턴스도 있습니다.
1. (선택 사항) 클러스터에 HSM을 더 추가합니다. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 단원을 참조하십시오.
1. 클라이언트 인스턴스에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. [CloudHSM CLI로 HSM 사용자 관리](manage-hsm-users-chsm-cli.md) 또는 [CloudHSM 관리 유틸리티(CMU)로 HSM 사용자 관리](manage-hsm-users-cmu.md)를 사용하여 Crypto User(CU)를 생성합니다. CU의 사용자 이름과 암호를 기록합니다. 다음 단계에서 해당 정보가 필요합니다.
1. 이전 단계에서 생성한 CU 사용자 이름과 암호를 사용하여 [HSM의 로그인 자격 증명을 설정](ksp-library-prereq.md)합니다.
1. 5단계에서 Windows 자격 증명 관리자를 사용하여 HSM 자격 증명을 설정한 경우 SysInternals에서 [https://live.sysinternals.com/psexec.exe](https://live.sysinternals.com/psexec.exe)를 다운로드하여 다음 명령을 *NT Authority\$1SYSTEM*으로 실행합니다.
```
psexec.exe -s "C:\Program Files\Amazon\CloudHsm\tools\set_cloudhsm_credentials.exe" --username --password
```
**과 **를 HSM 자격 증명으로 바꿉니다.
를 사용하여 Windows Server CA를 생성하려면 로 AWS CloudHSM이동합니다[Windows Server CA 생성](#win-ca-setup-sdk3).
## 2단계:를 사용하여 Windows Server CA 생성 AWS CloudHSM
Windows Server CA를 만들려면 Windows Server에 AD CS(Active Directory 인증서 서비스) 역할을 추가합니다. 이 역할을 추가할 때 AWS CloudHSM 키 스토리지 공급자(KSP)를 사용하여 CA의 프라이빗 키를 생성하고 AWS CloudHSM 클러스터에 저장합니다.
**참고**
Windows Server CA를 만들 때 루트 CA 또는 종속 CA를 만들도록 선택할 수 있습니다. 일반적으로 퍼블릭 키 인프라 설계 및 조직의 보안 정책을 기준으로 결정합니다. 이 자습서에서는 단순 루트 CA를 만드는 방법을 설명합니다.
**Windows Server에 AD CS 역할을 추가하고 CA의 프라이빗 키를 생성하려면**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. **서버 관리자** 대시보드에서 **역할 및 기능 추가**를 선택합니다.
1. **시작하기 전에** 정보를 읽은 후 **다음**을 선택합니다.
1. **Installation Type(설치 유형)**에서 **Role-based or feature-based installation(역할 기반 또는 기능 기반 설치)**을 선택합니다. 이후 **다음**을 선택합니다.
1. **서버 선택**에서 **서버 풀에서 서버 선택**을 선택합니다. 그런 다음 **다음**을 선택합니다.
1. **서버 역할**의 경우 다음을 수행합니다.
1. **Active Directory 인증서 서비스**를 선택합니다.
1. **Active Directory 인증서 서비스에 필요한 기능을 추가하시겠습니까?**라는 메시지가 표시되면 **기능 추가**를 선택합니다.
1. **다음**을 선택하여 서버 역할 선택을 마칩니다.
1. **기능**에서 기본 설정을 그대로 수락하고 **다음**을 선택합니다.
1. **AD CS**의 경우 다음을 수행합니다.
1. **다음**을 선택합니다.
1. **Certification Authority**를 선택한 다음 **다음**을 선택합니다.
1. **확인**에서 확인 정보를 읽은 다음 **설치**를 선택합니다. 창을 닫습니다.
1. 강조 표시된 **대상 서버에서 Active Directory 인증서 서비스 구성** 링크를 선택합니다.
1. **자격 증명**에서 표시된 자격 증명을 확인하거나 변경합니다. 그리고 **다음**을 선택합니다.
1. **역할 서비스**에서 **인증 기관**을 선택합니다. 그리고 **다음**을 선택합니다.
1. **설치 유형**에서 **독립 CA**를 선택합니다. 그리고 **다음**을 선택합니다.
1. **CA 유형**에서 **루트 CA**를 선택합니다. 그리고 **다음**을 선택합니다.
**참고**
퍼블릭 키 인프라 설계 및 조직의 보안 정책을 기반으로 루트 CA 또는 하위 CA를 만들도록 선택할 수 있습니다. 이 자습서에서는 단순 루트 CA를 만드는 방법을 설명합니다.
1. **프라이빗 키**에서 **프라이빗 키 새로 만들기**를 선택합니다. 그리고 **다음**을 선택합니다.
1. **암호화**에서 다음을 수행합니다.
1. **암호화 공급자 선택**에서 메뉴의 **Cavium 키 저장소 공급자** 옵션 중 하나를 선택합니다. 이 옵션은 AWS CloudHSM KSP입니다. 예를 들어 **RSA\$1Cavium Key Storage Provider**를 선택할 수 있습니다.
1. **키 길이**에서 키 길이 옵션 중 하나를 선택합니다.
1. **인증 기관에서 발급한 인증서에 서명하기 위한 해시 알고리즘을 선택합니다.**에서 해시 알고리즘 옵션 중 하나를 선택합니다.
**다음**을 선택합니다.
1. **CA 이름**에서 다음을 수행합니다.
1. (옵션) 일반 이름을 수정합니다.
1. (옵션) 고유 이름 접미사를 입력합니다.
**다음**을 선택합니다.
1. **유효 기간**에 년, 월, 주 또는 일 단위로 기간을 지정합니다. 그리고 **다음**을 선택합니다.
1. **인증서 데이터베이스**에서 기본값을 사용하거나 선택적으로 데이터베이스와 데이터베이스 로그의 위치를 변경할 수 있습니다. 그리고 **다음**을 선택합니다.
1. **확인**에서 CA에 대한 정보를 검토하고 **구성**을 선택합니다.
1. **닫기**를 선택한 다음 **닫기**를 차례로 선택합니다.
이제가 포함된 Windows Server CA가 생겼습니다 AWS CloudHSM. CA로 인증서 서명 요청(CSR)에 서명하는 방법을 배우려면 [CSR 서명하기](#win-ca-sign-csr-sdk3) 섹션으로 이동합니다.
## 3단계:를 사용하여 Windows Server CA로 인증서 서명 요청(CSR)에 서명 AWS CloudHSM
와 함께 Windows Server CA를 사용하여 인증서 서명 요청(CSR)에 서명 AWS CloudHSM 할 수 있습니다. 이러한 단계들을 완료하려면 유효한 CSR이 필요합니다. CSR은 다음을 포함한 다양한 방법으로 만들 수 있습니다.
+ OpenSSL 사용
+ Windows Server IIS(인터넷 정보 서비스) 관리자 사용
+ Microsoft Management Console(MMC)에서 스냅인 인증서 사용
+ Windows의 명령줄 유틸리티에서 **certreq** 사용
CSR 생성 단계는 본 자습서에서 다루지 않습니다. CSR이 있으면 Windows Server CA로 서명할 수 있습니다.
**CSR로 Windows Server CA 서명**
1. 아직 역할 추가 및 키를 생성하지 않은 경우 Windows Server에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. Windows Server에서 **서버 관리자**를 시작합니다.
1. 오르쪽 상단 모서리에 **서버 관리자** 대시보드에서 **도구**, **인증 기관**을 선택합니다.
1. **인증 기관** 창에서 컴퓨터 이름을 선택합니다.
1. **작업** 메뉴에서 **모든 작업**을 선택한 후 **새 요청 제출**을 선택합니다.
1. CSR 파일을 선택한 다음 **열기를** 선택합니다.
1. **인증 기관** 창에서 **대기 중인 요청**을 두번 클릭합니다.
1. 대기 중인 요청을 선택합니다. 그런 다음 **작업** 메뉴에서 **모든 작업**을 선택하고 **문제**를 선택합니다.
1. 서명 인증서를 보려면 **인증 기관** 창에서 **발급된 요청**을 두번 클릭합니다.
1. (옵션) 서명 인증서를 파일에 내보내려면 다음 단계를 완료해야 합니다.
1. **인증 기관** 창에 보이는 인증서를 두번 클릭합니다.
1. **세부 정보** 탭을 선택한 다음 **파일로 복사**를 선택합니다.
1. **인증서 내보내기 마법사**에서 지침을 따릅니다.
이제를 사용하는 Windows Server CA AWS CloudHSM와 Windows Server CA에서 서명한 유효한 인증서가 있습니다.
# 를 사용한 Oracle 데이터베이스 투명 데이터 암호화(TDE) AWS CloudHSM
TDE(Transparent Data Encryption)는 데이터베이스 파일을 암호화하는 데 사용됩니다. TDE를 사용하면 데이터베이스 소프트웨어는 데이터를 디스크에 저장하기 전에 암호화합니다. 데이터베이스의 테이블 열 또는 테이블스페이스의 데이터는 테이블 키 또는 테이블스페이스 키로 암호화됩니다. Oracle Database 소프트웨어의 일부 버전은 TDE를 제공합니다. Oracle TDE에서, 이 키는 TDE 마스터 암호화 키로 암호화됩니다. AWS CloudHSM 클러스터의 HSMs에 TDE 마스터 암호화 키를 저장하여 보안을 강화할 수 있습니다.
![\[AWS CloudHSM에 Oracle TDE 마스터 암호화 키를 저장합니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/tde-master-key-in-hsm.png)
이 솔루션에서는 Amazon EC2 인스턴스에 설치된 Oracle Database를 사용합니다. Oracle Database는 [PKCS \$111용AWS CloudHSM 소프트웨어 라이브러리](pkcs11-library.md)와 통합되어 클러스터의 HSM에 TDE 마스터 키를 저장합니다.
**중요**
Amazon EC2 인스턴스에 Oracle Database를 설치하는 것이 좋습니다.
Oracle TDE를 AWS CloudHSM과 통합하려면 다음 단계를 완료하십시오.
**Topics**
+ [1단계. 사전 조건 설정](#oracle-tde-prerequisites)
+ [2단계: Oracle 데이터베이스 구성 업데이트](#oracle-tde-configure-database-and-generate-master-key)
+ [3단계: Oracle TDE 마스터 암호화 키 생성](#oracle-tde-generate-master-key)
## 1단계. 사전 조건 설정
Oracle TDE와의 통합을 수행하려면 다음이 AWS CloudHSM필요합니다.
+ 하나 이상의 HSM이 있는 활성 AWS CloudHSM 클러스터입니다.
+ 다음 소프트웨어가 설치된 Amazon Linux 운영 체제를 실행하는 Amazon EC2 인스턴스:
+ AWS CloudHSM 클라이언트 및 명령줄 도구입니다.
+ PKCS \$111용 AWS CloudHSM 소프트웨어 라이브러리입니다.
+ Oracle Database.는 Oracle TDE 통합을 AWS CloudHSM 지원합니다. Client SDK 5.6 이상은 Oracle Database 19c용 Oracle TDE를 지원합니다. Client SDK 3은 Oracle Database 버전 11g 및 12c용 Oracle TDE를 지원합니다.
+ 클러스터의 HSM에서 TDE 마스터 암호화 키를 소유하고 관리할 CU(Cryptographic User)입니다.
다음 단계를 완료하여 사전 조건을 모두 설정합니다.
**와의 Oracle TDE 통합을 위한 사전 조건을 설정하려면 AWS CloudHSM**
1. [시작하기](getting-started.md)의 단계를 수행하세요. 이렇게 하면 HSM이 하나 있는 활성 클러스터가 생깁니다. 또한 Amazon Linux 운영 체제를 실행하는 Amazon EC2 인스턴스도 있습니다. AWS CloudHSM 클라이언트 및 명령줄 도구도 설치 및 구성됩니다.
1. (선택 사항) 클러스터에 HSM을 더 추가합니다. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 단원을 참조하십시오.
1. Amazon EC2 클라이언트 인스턴스에 연결하고 다음을 수행합니다.
1. [PKCS \$111용 AWS CloudHSM 소프트웨어 라이브러리를 설치합니다](pkcs11-library-install.md).
1. Oracle Database를 설치합니다. 자세한 내용은 [Oracle Database 설명서](https://docs.oracle.com/en/database/)를 참조하십시오. Client SDK 5.6 이상은 Oracle Database 19c용 Oracle TDE를 지원합니다. Client SDK 3은 Oracle Database 버전 11g 및 12c용 Oracle TDE를 지원합니다.
1. cloudhsm\$1mgmt\$1util 명령줄 도구를 사용하여 클러스터에서 CU(Cryptographic User)를 생성합니다. CU 생성에 대한 자세한 내용은 [CMU를 사용하여 HSM 사용자를 관리 방법](create-users-cmu.md) 및 [HSM 사용자](manage-hsm-users.md) 항목을 참조하십시오.
## 2단계: Oracle 데이터베이스 구성 업데이트
클러스터의 HSM을 *외부 보안 모듈*로 사용하도록 Oracle 데이터베이스 구성을 업데이트하려면 다음 단계를 수행합니다. 외부 보안 모듈에 대한 자세한 내용은 *오라클 데이터베이스 고급 보안 가이드*의 [투명한 데이터 암호화 소개](https://docs.oracle.com/database/122/ASOAG/introduction-to-transparent-data-encryption.htm)를 참조하십시오.
**Oracle 구성을 업데이트하려면**
1. Amazon EC2 클라이언트 인스턴스에 연결합니다. 이 인스턴스는 Oracle 데이터베이스를 설치한 인스턴스입니다.
1. `sqlnet.ora` 파일의 백업 사본을 생성합니다. 이 파일의 위치는 Oracle 문서를 참조하십시오.
1. 텍스트 편집기를 사용하여 `sqlnet.ora` 파일을 편집합니다. 다음 행을 추가합니다. 파일에서 기존 행이 `encryption_wallet_location`으로 시작할 경우 기존 행을 다음과 같이 바꿉니다.
```
encryption_wallet_location=(source=(method=hsm))
```
파일을 저장합니다.
1. 다음 명령을 실행하여 Oracle Database가 AWS CloudHSM PKCS \$111 소프트웨어 라이브러리의 라이브러리 파일을 찾을 것으로 예상되는 디렉터리를 생성합니다.
```
sudo mkdir -p /opt/oracle/extapi/64/hsm
```
1. 다음 명령을 실행하여 PKCS \$111 파일용 AWS CloudHSM 소프트웨어 라이브러리를 이전 단계에서 생성한 디렉터리에 복사합니다.
```
sudo cp /opt/cloudhsm/lib/libcloudhsm_pkcs11.so /opt/oracle/extapi/64/hsm/
```
**참고**
`/opt/oracle/extapi/64/hsm` 디렉터리는 라이브러리 파일을 하나만 포함해야 합니다. 해당 디렉터리에 있는 다른 파일을 제거합니다.
1. 다음 명령을 실행하여 `/opt/oracle` 디렉터리와 그 안에 포함된 모든 항목의 소유권을 변경합니다.
```
sudo chown -R oracle:dba /opt/oracle
```
1. Oracle 데이터베이스를 시작합니다.
## 3단계: Oracle TDE 마스터 암호화 키 생성
클러스터의 HSM에서 Oracle TDE 마스터 키를 생성하려면 다음 절차의 단계를 수행합니다.
**마스터 키를 생성하려면**
1. 명령을 사용하여 Oracle SQL\$1Plus를 엽니다. 메시지가 표시되면 Oracle 데이터베이스를 설치할 때 설정한 시스템 암호를 입력합니다.
```
sqlplus / as sysdba
```
**참고**
Client SDK 3의 경우 마스터 키를 생성할 때마다 `CLOUDHSM_IGNORE_CKA_MODIFIABLE_FALSE` 환경 변수를 설정해야 합니다. 이 변수는 마스터 키 생성에만 필요합니다. 자세한 내용은 [타사 애플리케이션 통합에 대해 알려진 문제](ki-third-party.md)에서 "문제: Oracle은 마스터 키 생성 중에 PCKS \$111 속성 `CKA_MODIFIABLE`을 설정하지만 HSM은 이를 지원하지 않습니다"를 참조하십시오.
1. 다음 예제와 같이 마스터 암호화 키를 생성하는 SQL 문을 실행합니다. Oracle 데이터베이스의 버전에 해당하는 문을 사용하십시오. **을 CU(Cryptographic User)의 사용자 이름으로 바꿉니다. **를 CU 암호로 바꿉니다.
**중요**
다음 명령은 한 번만 실행하십시오. 명령이 실행될 때마다 새 마스터 암호화 키가 생성됩니다.
+ Oracle 데이터베이스 버전 11의 경우, 다음 SQL 문을 실행합니다.
```
SQL> alter system set encryption key identified by ":";
```
+ Oracle 데이터베이스 12버전 및 19c버전의 경우 다음 SQL문을 실행합니다.
```
SQL> administer key management set key identified by ":";
```
응답이 `System altered` 또는 `keystore altered`일 경우 Oracle TDE의 마스터 키가 성공적으로 생성 및 설정된 것입니다.
1. (선택 사항) 다음 명령을 실행하여 *Oracle wallet*의 상태를 확인합니다.
```
SQL> select * from v$encryption_wallet;
```
Oracle wallet이 열리지 않은 경우 다음 명령 중 하나를 실행하여 엽니다. **을 CU(Cryptographic User)의 이름으로 바꿉니다. **를 CU 암호로 바꿉니다.
+ Oracle 11의 경우, 다음 명령을 실행하여 Oracle Wallet을 엽니다.
```
SQL> alter system set encryption wallet open identified by ":";
```
수동으로 Oracle wallet을 닫으려면 다음 명령을 실행합니다.
```
SQL> alter system set encryption wallet close identified by ":";
```
+ Oracle 12 및 Oracle 19c의 경우 지갑을 열기 위해 다음 명령을 실행합니다.
```
SQL> administer key management set keystore open identified by ":";
```
수동으로 Oracle wallet을 닫으려면 다음 명령을 실행합니다.
```
SQL> administer key management set keystore close identified by ":";
```
# 에서 Microsoft SignTool AWS CloudHSM 을 사용하여 파일 서명
AWS CloudHSM 는 Microsoft Signtool을 사용하여 클라이언트 SDK 3 및 클라이언트 SDK 5를 통해 파일에 서명할 수 있는 지원을 제공합니다. 이러한 도구를 사용하는 단계는 현재 다운로드한 클라이언트 SDK의 버전에 따라 달라집니다. 다음 섹션에서는 각 SDK에 정보를 제공합니다.
**Topics**
+ [클라이언트 SDK 5 및 Microsoft SignTool](signtool-sdk5.md)
+ [클라이언트 SDK 3 및 Microsoft SignTool](signtool-sdk3.md)
# Microsoft SignTool과 클라이언트 SDK 5를 사용하여 파일에 서명
암호화 및 PKI(퍼블릭 키 인프라)에서는 신뢰할 수 있는 기관이 전송한 데이터임을 확인하기 위해 디지털 서명이 사용됩니다. 서명은 데이터가 전송 중에 변조되지 않았음을 나타내기도 합니다. 서명은 발신자의 프라이빗 키로 생성된 암호화된 해시입니다. 수신자는 발신자의 퍼블릭 키로 해시 서명 암호를 해독하여 데이터 무결성을 확인할 수 있습니다. 디지털 인증서를 유지 관리하는 것은 발신자의 책임입니다. 디지털 인증서는 발신자의 프라이빗 키 소유권을 나타내며 암호 해독에 필요한 퍼블릭 키를 수신자에게 제공합니다. 발신자가 프라이빗 키를 소유하는 한 서명을 신뢰할 수 있습니다.는 보안 FIPS 140-2 레벨 3 검증 하드웨어를 AWS CloudHSM 제공하여 독점적인 단일 테넌트 액세스로 이러한 키를 보호합니다.
많은 조직이 Microsoft SignTool을 사용합니다. Microsoft SignTool은 명령줄 도구이며, 코드 서명 절차를 간소화하기 위해 파일에 서명하고 확인하며 타임스탬프를 찍습니다. SignTool에 필요할 때까지 AWS CloudHSM 를 사용하여 키 페어를 안전하게 저장할 수 있으므로 데이터 서명을 위한 워크플로를 쉽게 자동화할 수 있습니다.
다음 주제에서는 SignTool을와 함께 사용하는 방법에 대한 개요를 제공합니다 AWS CloudHSM.
**Topics**
+ [1단계: 사전 조건 설정](#signtool-sdk5-prereqs)
+ [2단계: 서명 인증서 생성](#signtool-sdk5-csr)
+ [3단계: 파일 서명](#signtool-sdk5-sign)
## 1단계: 사전 조건 설정
Microsoft SignTool을와 함께 사용하려면 다음이 AWS CloudHSM필요합니다.
+ Windows 운영 체제를 실행하는 Amazon EC2 클라이언트 인스턴스.
+ 자체 관리하거나 타사 공급자가 설정한 CA(인증 기관)
+ EC2 인스턴스와 동일한 Virtual Public Cloud(VPC)의 활성 AWS CloudHSM 클러스터입니다. 클러스터에 HSM이 하나 이상 있어야 합니다.
+ AWS CloudHSM 클러스터에서 키를 소유하고 관리할 CU(Crypto User)입니다.
+ 서명되지 않은 파일 또는 실행 파일
+ Microsoft Windows 소프트웨어 개발 키트(SDK)
**Windows SignTool AWS CloudHSM 에서를 사용하기 위한 사전 조건을 설정하려면**
1. 본 설명서의 [시작하기](getting-started.md) 단원에 있는 지침에 따라 Windows EC2 인스턴스와 AWS CloudHSM 클러스터를 시작합니다.
1. 자체 Windows Server CA를 호스팅하려면를 [사용하여 Windows Server를 인증 기관으로 구성 AWS CloudHSM](win-ca-overview-sdk5.md)의 1단계와 2단계를 따릅니다. 그렇지 않으면 계속해서 공신력 있는 타사 CA를 사용합니다.
1. 다음 Microsoft Windows SDK 버전 중 하나를 다운로드하여 Windows EC2 인스턴스에 설치합니다.
+ [Microsoft Windows SDK 10](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk)
+ [Microsoft Windows SDK 8.1](https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk)
+ [Microsoft Windows SDK 7](https://www.microsoft.com/en-us/download/details.aspx?id=8279)
`SignTool` 실행 파일은 데스크톱 앱을 위한 Windows SDK 서명 도구 설치 기능의 일부분입니다. 필요 없을 경우 다른 기능은 생략하고 설치해도 됩니다. 기본 설치 위치는 다음과 같습니다.
```
C:\Program Files (x86)\Windows Kits\\bin\\\signtool.exe
```
이제 Microsoft Windows SDK, AWS CloudHSM 클러스터 및 CA를 사용하여 [서명 인증서를 생성할](#signtool-sdk5-csr) 수 있습니다.
## 2단계: 서명 인증서 생성
이제 Windows SDK를 EC2 인스턴스에 다운로드했습니다. SDK를 사용하여 CSR(인증서 서명 요청)을 생성할 수 있습니다. CSR은 최종적으로 서명을 위해 CA에 전달되는 서명되지 않은 인증서입니다. 이 예제에서는 Windows SDK에 포함된 `certreq` 실행 파일을 사용하여 CSR을 생성합니다.
**`certreq` 실행 파일을 사용하여 CSR 생성**
1. 아직 연결하지 않았다면 Windows EC2 인스턴스에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. 아래의 행이 포함된 `request.inf` 파일을 생성합니다. `Subject` 정보를 조직에 맞게 바꿉니다. 각 파라미터에 대한 설명은 [Microsoft 설명서](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#BKMK_New)를 참조하십시오.
```
[Version]
Signature= $Windows NT$
[NewRequest]
Subject = "C=,CN=,O=,OU=,L=,S="
RequestType=PKCS10
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "CloudHSM Key Storage Provider"
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE"
MachineKeySet = True
Exportable = False
```
1. `certreq.exe`를 실행합니다. 이 예제에서는 CSR을 `request.csr`로 저장합니다.
```
certreq.exe -new request.inf request.csr
```
내부적으로 AWS CloudHSM 는 클러스터에 새 키 페어가 생성되고 페어의 프라이빗 키가 CSR을 생성하는 데 사용됩니다.
1. CA에 CSR을 제출합니다. Windows Server CA를 사용하는 경우 다음 단계를 따릅니다.
1. 다음 명령을 입력하여 CA 도구를 엽니다.
```
certsrv.msc
```
1. 새 창에서 CA 서버 이름을 마우스 오른쪽 버튼으로 클릭합니다. **모든 작업**을 선택한 후 **새 요청 제출**을 선택합니다.
1. `request.csr`의 위치로 이동하여 **열기**를 선택합니다.
1. **서버 CA** 메뉴를 확장하여 **대기 중인 요청** 폴더로 이동합니다. 방금 만든 요청을 마우스 오른쪽 버튼으로 클릭하고 **모든 작업**에서 **발행**을 선택합니다.
1. 이제 **발행된 인증서** 폴더(**대기 중인 요청** 폴더 위쪽)로 이동합니다.
1. **열기**를 선택하여 인증서를 보고 **세부 정보** 탭을 선택합니다.
1. **파일에 복사**를 선택하여 인증서 내보내기 마법사를 시작합니다. DER 인코딩 X.509 파일을 안전한 곳에 `signedCertificate.cer`로 저장합니다.
1. CA 도구를 끝내고 다음 명령을 사용하여 인증서 파일을 Windows의 개인 인증서 저장소로 이동합니다. 그러면 다른 애플리케이션에서 사용할 수 있습니다.
```
certreq.exe -accept signedCertificate.cer
```
이제 가져온 인증서를 사용하여 [파일에 서명](#signtool-sdk5-sign)할 수 있습니다.
## 3단계: 파일 서명
이제 SignTool과 가져온 인증서를 사용하여 예제 파일에 서명할 수 있습니다. 그러려면 인증서의 SHA-1 해시 또는 *지문*을 알아야 합니다. 지문이 있으면 SignTool이 AWS CloudHSM에서 확인한 인증서만 사용합니다. 이 예제에서는 PowerShell을 사용하여 인증서 해시를 가져옵니다. CA의 GUI나 Windows SDK의 `certutil` 실행 파일을 사용할 수도 있습니다.
**인증서 지문을 얻어 파일 서명에 사용하려면**
1. 관리자로 PowerShell을 열어 다음 명령을 실행합니다.
```
Get-ChildItem -path cert:\LocalMachine\My
```
반환된 `Thumbprint`를 복사합니다.
![\[인증서의 해시가 지문으로 반환됩니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/signtool-hash.png)
1. `SignTool.exe`가 있는 PowerShell 내의 디렉터리로 이동합니다. 기본 위치는 `C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64`입니다.
1. 마지막으로 다음 명령을 실행하여 파일에 서명합니다. 명령이 성공하면 PowerShell이 성공 메시지를 반환합니다.
```
signtool.exe sign /v /fd sha256 /sha1 /sm C:\Users\Administrator\Desktop\.ps1
```
![\[.ps1 파일에 성공적으로 서명했습니다.\]](http://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/images/signtool-last-command.png)
1. (선택 사항) 파일의 서명을 확인하려면 다음 명령을 사용합니다.
```
signtool.exe verify /v /pa C:\Users\Administrator\Desktop\.ps1
```
# Microsoft SignTool과 클라이언트 SDK 3를 사용하여 파일에 서명
암호화 및 PKI(퍼블릭 키 인프라)에서는 신뢰할 수 있는 기관이 전송한 데이터임을 확인하기 위해 디지털 서명이 사용됩니다. 서명은 데이터가 전송 중에 변조되지 않았음을 나타내기도 합니다. 서명은 발신자의 프라이빗 키로 생성된 암호화된 해시입니다. 수신자는 발신자의 퍼블릭 키로 해시 서명 암호를 해독하여 데이터 무결성을 확인할 수 있습니다. 디지털 인증서를 유지 관리하는 것은 발신자의 책임입니다. 디지털 인증서는 발신자의 프라이빗 키 소유권을 나타내며 암호 해독에 필요한 퍼블릭 키를 수신자에게 제공합니다. 발신자가 프라이빗 키를 소유하는 한 서명을 신뢰할 수 있습니다.는 보안 FIPS 140-2 레벨 3 검증 하드웨어를 AWS CloudHSM 제공하여 독점적인 단일 테넌트 액세스로 이러한 키를 보호합니다.
많은 조직이 Microsoft SignTool을 사용합니다. Microsoft SignTool은 명령줄 도구이며, 코드 서명 절차를 간소화하기 위해 파일에 서명하고 확인하며 타임스탬프를 찍습니다. SignTool에 필요할 때까지 AWS CloudHSM 를 사용하여 키 페어를 안전하게 저장할 수 있으므로 데이터 서명을 위한 워크플로를 쉽게 자동화할 수 있습니다.
다음 주제에서는 SignTool을와 함께 사용하는 방법에 대한 개요를 제공합니다 AWS CloudHSM.
**Topics**
+ [1단계: 사전 조건 설정](#signtool-sdk3-prereqs)
+ [2단계: 서명 인증서 생성](#signtool-sdk3-csr)
+ [3단계: 파일 서명](#signtool-sdk3-sign)
## 1단계: 사전 조건 설정
Microsoft SignTool을와 함께 사용하려면 다음이 AWS CloudHSM필요합니다.
+ Windows 운영 체제를 실행하는 Amazon EC2 클라이언트 인스턴스.
+ 자체 관리하거나 타사 공급자가 설정한 CA(인증 기관)
+ EC2 인스턴스와 동일한 Virtual Public Cloud(VPC)의 활성 AWS CloudHSM 클러스터입니다. 클러스터에 HSM이 하나 이상 있어야 합니다.
+ AWS CloudHSM 클러스터에서 키를 소유하고 관리할 CU(Crypto User)입니다.
+ 서명되지 않은 파일 또는 실행 파일
+ Microsoft Windows 소프트웨어 개발 키트(SDK)
**Windows SignTool AWS CloudHSM 에서를 사용하기 위한 사전 조건을 설정하려면**
1. 본 설명서의 [시작하기](getting-started.md) 단원에 있는 지침에 따라 Windows EC2 인스턴스와 AWS CloudHSM 클러스터를 시작합니다.
1. 자체 Windows Server CA를 호스팅하려면를 [사용하여 Windows Server를 인증 기관으로 구성 AWS CloudHSM](win-ca-overview-sdk3.md)의 1단계와 2단계를 따릅니다. 그렇지 않으면 계속해서 공신력 있는 타사 CA를 사용합니다.
1. 다음 Microsoft Windows SDK 버전 중 하나를 다운로드하여 Windows EC2 인스턴스에 설치합니다.
+ [Microsoft Windows SDK 10](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk)
+ [Microsoft Windows SDK 8.1](https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk)
+ [Microsoft Windows SDK 7](https://www.microsoft.com/en-us/download/details.aspx?id=8279)
`SignTool` 실행 파일은 데스크톱 앱을 위한 Windows SDK 서명 도구 설치 기능의 일부분입니다. 필요 없을 경우 다른 기능은 생략하고 설치해도 됩니다. 기본 설치 위치는 다음과 같습니다.
```
C:\Program Files (x86)\Windows Kits\\bin\\\signtool.exe
```
이제 Microsoft Windows SDK, AWS CloudHSM 클러스터 및 CA를 사용하여 [서명 인증서를 생성할](#signtool-sdk3-csr) 수 있습니다.
## 2단계: 서명 인증서 생성
이제 Windows SDK를 EC2 인스턴스에 다운로드했습니다. SDK를 사용하여 CSR(인증서 서명 요청)을 생성할 수 있습니다. CSR은 최종적으로 서명을 위해 CA에 전달되는 서명되지 않은 인증서입니다. 이 예제에서는 Windows SDK에 포함된 `certreq` 실행 파일을 사용하여 CSR을 생성합니다.
**`certreq` 실행 파일을 사용하여 CSR 생성**
1. 아직 연결하지 않았다면 Windows EC2 인스턴스에 연결합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html#ec2-connect-to-instance-windows)을 참조하세요.
1. 아래의 행이 포함된 `request.inf` 파일을 생성합니다. `Subject` 정보를 조직에 맞게 바꿉니다. 각 파라미터에 대한 설명은 [Microsoft 설명서](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1#BKMK_New)를 참조하십시오.
```
[Version]
Signature= $Windows NT$
[NewRequest]
Subject = "C=,CN=,O=,OU=,L=,S="
RequestType=PKCS10
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "Cavium Key Storage Provider"
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE"
MachineKeySet = True
Exportable = False
```
1. `certreq.exe`를 실행합니다. 이 예제에서는 CSR을 `request.csr`로 저장합니다.
```
certreq.exe -new request.inf request.csr
```
내부적으로 AWS CloudHSM 클러스터에 새 키 페어가 생성되고 페어의 프라이빗 키가 CSR을 생성하는 데 사용됩니다.
1. CA에 CSR을 제출합니다. Windows Server CA를 사용하는 경우 다음 단계를 따릅니다.
1. 다음 명령을 입력하여 CA 도구를 엽니다.
```
certsrv.msc
```
1. 새 창에서 CA 서버 이름을 마우스 오른쪽 버튼으로 클릭합니다. **모든 작업**을 선택한 후 **새 요청 제출**을 선택합니다.
1. `request.csr`의 위치로 이동하여 **열기**를 선택합니다.
1. **서버 CA** 메뉴를 확장하여 **대기 중인 요청** 폴더로 이동합니다. 방금 만든 요청을 마우스 오른쪽 버튼으로 클릭하고 **모든 작업**에서 **발행**을 선택합니다.
1. 이제 **발행된 인증서** 폴더(**대기 중인 요청** 폴더 위쪽)로 이동합니다.
1. **열기**를 선택하여 인증서를 보고 **세부 정보** 탭을 선택합니다.
1. **파일에 복사**를 선택하여 인증서 내보내기 마법사를 시작합니다. DER 인코딩 X.509 파일을 안전한 곳에 `signedCertificate.cer`로 저장합니다.
1. CA 도구를 끝내고 다음 명령을 사용하여 인증서 파일을 Windows의 개인 인증서 저장소로 이동합니다. 그러면 다른 애플리케이션에서 사용할 수 있습니다.
```
certreq.exe -accept signedCertificate.cer
```
이제 가져온 인증서를 사용하여 [파일에 서명](#signtool-sdk3-sign)할 수 있습니다.
## 3단계: 파일 서명