기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AWS CloudHSM OpenSSL 공급자와 함께 NGINX 또는 HAProxy를 사용하여 Linux에서 SSL/TLS 오프로드
이 주제에서는 OpenSSL 공급자와 함께 NGINX 또는 HAProxy AWS CloudHSM 를 사용하여 Linux 웹 서버에서를 사용하여 SSL/TLS 서버 자격 증명 오프로드를 설정하는 step-by-step 지침을 제공합니다.
개요
Linux에서는 NGINX
이 자습서를 완료하려면 AWS CloudHSM OpenSSL 공급자를 사용하도록 NGINX 또는 HAProxy를 구성합니다. 이 자습서에서는 다음을 수행하는 방법을 보여줍니다.
-
Amazon EC2 인스턴스에 웹 서버 소프트웨어를 설치합니다.
-
AWS CloudHSM 클러스터에 프라이빗 키가 저장되는 HTTPS를 지원하도록 웹 서버 소프트웨어를 구성합니다.
-
(선택 사항) Amazon EC2를 사용하여 두 번째 웹 서버 인스턴스를 만들고 Elastic Load Balancing을 사용하여 로드 밸런서를 만듭니다. 로드 밸런서를 사용하면 여러 서버에 부하를 분산하여 성능을 향상할 수 있습니다. 또한 하나 이상의 서버에 장애가 발생할 경우 중복성과 더 높은 가용성을 제공할 수 있습니다.
시작할 준비가 되면 1단계: 사전 조건 설정로 이동합니다.
1단계: 사전 조건 설정
플랫폼마다 필요한 필수 조건이 다릅니다. 플랫폼에 맞는 아래의 사전 조건 섹션을 사용하세요.
AWS CloudHSM OpenSSL 공급자의 사전 조건
클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 사용하여 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 설정하려면 다음이 필요합니다.
-
하드웨어 보안 모듈(HSM)이 2개 이상 있는 활성 AWS CloudHSM 클러스터
참고
단일 HSM 클러스터를 사용할 수 있지만 먼저 클라이언트 키 내구성을 비활성화해야 합니다. 자세한 내용은 클라이언트 키 내구성 설정 관리 및 클라이언트 SDK 5 구성 도구를 참조하세요.
-
다음 소프트웨어가 설치된 Linux 운영 체제를 실행하는 Amazon EC2 인스턴스.
-
웹 서버(NGINX 또는 HAProxy)
-
클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자
-
-
HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 CU(Crypto User)입니다.
HSM에서 Linux 웹 서버 인스턴스를 설정하고 CU를 생성하려면
참고
이 절차의 많은 명령에는 승격된 권한이 필요합니다. 시스템 구성에 따라 루트 사용자로 sudo 또는를 사용하여 명령을 실행해야 할 수 있습니다.
-
클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 설치하고 구성합니다. OpenSSL 공급자 설치에 대한 자세한 내용은 AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자를 참조하세요.
-
클러스터에 액세스할 수 있는 EC2 Linux 인스턴스에 NGINX 또는 HAProxy 웹 서버를 설치합니다.
-
CloudHSM CLI를 사용하여 Crypto User를 생성합니다. HSM 사용자 관리에 대한 자세한 내용은 CloudHSM CLI를 사용한 HSM 사용자 관리를 참조하십시오.
작은 정보
CU의 사용자 이름과 암호를 기록합니다. 나중에 웹 서버용 HTTPS 프라이빗 키와 인증서를 생성하거나 가져올 때 이 정보가 필요합니다.
이 단계들을 완료한 후 2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기로 이동합니다.
참고
-
보안이 강화된 리눅스(SELinux) 및 웹 서버를 사용하려면 클라이언트 SDK 5가 HSM과 통신하는 데 사용하는 포트인 포트 2223에서 아웃바운드 TCP 연결을 허용해야 합니다.
-
클러스터를 생성 및 활성화하고 EC2 인스턴스에 클러스터 액세스 권한을 부여하려면 AWS CloudHSM시작하기의 단계를 완료하십시오. 시작하기에서는 HSM 1개와 Amazon EC2 클라이언트 인스턴스 1개로 활성 클러스터를 생성하는 방법에 대한 단계별 지침을 제공합니다. 이 클라이언트 인스턴스를 웹 서버로 사용할 수 있습니다.
-
클라이언트 키 내구성을 비활성화하지 않으려면 클러스터에 HSM을 두 개 이상 추가하십시오. 자세한 내용은 AWS CloudHSM 클러스터에 HSM 추가 섹션을 참조하십시오.
-
SSH 또는 PuTTY를 사용하여 클라이언트 인스턴스에 연결할 수 있습니다. 자세한 정보는 Amazon EC2 설명서의 SSH를 사용하여 Linux 인스턴스에 연결과 PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결 단원을 참조하세요.
2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기
HTTPS를 활성화하려면 웹 서버 애플리케이션(NGINX 또는 HAProxy)에 프라이빗 키와 해당 SSL/TLS 인증서가 필요합니다. 에서 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 사용하려면 AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장 AWS CloudHSM해야 합니다. 먼저 프라이빗 키를 생성한 후 해당 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. 그런 다음 HSM에서 가짜 PEM 프라이빗 키를 내보냅니다. 즉 HSM에 저장된 프라이빗 키에 대한 참조를 포함하는 PEM 형식의 프라이빗 키 파일입니다(실제 프라이빗 키가 아님). 웹 서버는 가짜 PEM 프라이빗 키 파일을 사용하여 SSL/TLS 서버 자격 증명 오프로드 중에 HSM의 프라이빗 키를 식별합니다.
프라이빗 키 생성
이 섹션에서는 CloudHSM CLI를 사용하여 키 페어를 생성하는 방법을 보여줍니다. HSM 내부에 키 페어가 생성되면 이를 가짜 PEM 파일로 내보내고 해당 인증서를 생성할 수 있습니다.
CloudHSM CLI 설치 및 구성
-
CloudHSM CLI를 설치 및 구성합니다.
-
다음 명령을 사용하여 CloudHSM CLI를 시작합니다.
$/opt/cloudhsm/bin/cloudhsm-cli interactive -
다음 명령을 실행하여 HSM에 로그인합니다.
<user name>을 Crypto User의 사용자 이름으로 변경aws-cloudhsm>login --username<user name>--role crypto-user
프라이빗 키 생성
사용 사례에 따라 RSA 또는 EC 키 페어를 생성할 수 있습니다. 다음 중 하나를 수행하십시오.
-
HSM에서 RSA 프라이빗 키를 생성하려면
key generate-asymmetric-pair rsa 명령을 사용하여 RSA 키 페어를 생성합니다. 이 예제에서는 모듈러스가 2048, 퍼블릭 지수가 65537, 퍼블릭 키 레이블이
tls_rsa_pub, 프라이빗 키 레이블이tls_rsa_private인 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 명령을 사용하여 EC 키 페어를 생성합니다. 이 예제에서는
prime256v1곡선(NID_X9_62_prime256v1곡선에 해당)에 기반하여 퍼블릭 키 레이블이tls_ec_pub, 프라이빗 키 레이블이tls_ec_private인 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 명령을 실행하여 가짜 PEM 형식의 프라이빗 키를 내보내고 파일에 저장합니다. 다음 값을 사용자의 값으로 대체합니다.
-
<private_key_label>- 이전 단계에서 생성한 프라이빗 키의 레이블입니다. -
<web_server_fake_pem.key>- 가짜 PEM 키가 기록될 파일의 이름입니다.
aws-cloudhsm >key generate-file --encoding reference-pem --path<web_server_fake_pem.key>--filter attr.label=<private_key_label>{ "error_code": 0, "data": { "message": "Successfully generated key file" } }
CloudHSM CLI 종료
다음 명령을 실행하여 CloudHSM CLI를 종료합니다.
aws-cloudhsm >quit
이제 이전 명령에서 <web_server_fake_pem.key>로 지정된 경로에, 시스템에 새 파일이 있어야 합니다. 이 파일은 가짜 PEM 프라이빗 키 파일입니다.
자체 사인된 인증서를 생성합니다.
가짜 PEM 프라이빗 키를 생성한 후에는 이 파일을 사용하여 인증서 사인 요청(CSR) 및 인증서를 생성할 수 있습니다.
프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우 CA에 CSR 파일을 보내고 CA가 웹 서버에서 HTTPS용으로 제공하는 서명된 SSL/TLS 인증서를 사용하세요.
CA를 사용하는 대신 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 자체 서명된 인증서를 생성할 수 있습니다. 자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다.
주의
자체 사인된 인증서는 테스트 환경에서만 사용해야 합니다. 프로덕션 환경의 경우 인증 기관과 같은 추가 보안 방법을 사용하여 인증서를 생성하십시오.
OpenSSL Dynamic Engine 설치 및 구성
-
클라이언트 인스턴스에 연결합니다.
인증서 생성
-
이전 단계에서 생성한 가짜 PEM 파일의 사본을 확보하세요.
-
CSR 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 인증서 서명 요청(CSR)을 생성합니다.
<web_server_fake_pem.key>를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.<web_server.csr>을 CSR이 포함된 파일의 이름으로 바꿉니다.req명령은 대화식입니다. 각 필드에 응답합니다. 필드 정보가 SSL/TLS 인증서에 복사됩니다.참고
CSR 생성은 현재 OpenSSL 공급자에서 지원되지 않습니다. 이 단계에서는 OpenSSL 엔진을 사용해야 하지만 TLS 암호 작업은 공급자와 함께 작동합니다.
$openssl req -engine cloudhsm -new -key<web_server_fake_pem.key>-out<web_server.csr> -
자체 서명된 인증서 생성
다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 HSM의 프라이빗 키로 CSR에 서명합니다. 이렇게 하면 자체 사인된 인증서가 생성됩니다. 명령의 다음 값을 사용자의 값으로 바꿉니다.
-
<web_server.csr>– CSR이 포함된 파일 이름 -
<web_server_fake_pem.key>– 가짜 PEM 프라이빗 키가 포함된 파일 이름 -
<web_server.crt>– 웹 서버 인증서가 포함될 파일 이름
$openssl x509 -engine cloudhsm -req -days 365 -in<web_server.csr>-signkey<web_server_fake_pem.key>-out<web_server.crt> -
프라이빗 키와 인증서가 있으면 로 이동합니다3단계: 웹 서버 구성하기.
3단계: 웹 서버 구성하기
이전 단계에서 생성한 HTTPS 인증서와 이에 해당되는 가짜 PEM 프라이빗 키를 사용하려면 웹 서버 소프트웨어의 구성을 업데이트하십시오. 시작하기 전에 기존 인증서와 키를 백업해야 한다는 점을 잊지 마십시오. 그러면 SSL/TLS 서버 자격 증명 오프로드를 위한 Linux 웹 서버 소프트웨어 설정이 완료됩니다 AWS CloudHSM.
다음 섹션 중 하나에 있는 단계를 완료합니다.
NGINX 웹 서버를 구성합니다
이 섹션을 사용하여 OpenSSL 공급자로 NGINX를 구성합니다.
OpenSSL 공급자용 NGINX를 구성하려면
-
클라이언트 인스턴스에 연결합니다.
-
다음 명령을 실행하여 웹 서버 인증서 및 가짜 PEM 프라이빗 키에 필요한 디렉터리를 생성합니다.
$mkdir -p /etc/pki/nginx/private -
다음 명령을 실행하여 웹 서버 인증서를 필요한 위치에 복사합니다.
<web_server.crt>를 웹 서버 인증서 이름으로 바꿉니다.$cp<web_server.crt>/etc/pki/nginx/server.crt -
다음 명령을 실행하여 가짜 PEM 프라이빗 키를 필요한 위치에 복사합니다.
<web_server_fake_pem.key>를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다.$cp<web_server_fake_pem.key>/etc/pki/nginx/private/server.key -
다음 명령을 실행하여 nginx라는 이름의 사용자가 파일을 읽을 수 있도록 파일 소유권을 변경합니다.
$chown nginx /etc/pki/nginx/server.crt /etc/pki/nginx/private/server.key -
AWS CloudHSM 공급자를 사용하도록 OpenSSL을 구성합니다. OpenSSL 공급자 구성에 대한 자세한 내용은 AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자를 참조하세요.
-
OpenSSL 구성 파일을 찾습니다.
$openssl version -d다음과 비슷한 출력이 표시되어야 합니다.
OPENSSLDIR: "/etc/pki/tls"구성 파일은이 디렉터리
openssl.cnf에 있습니다. -
참고
시스템의 기본 openssl.cnf 파일을 직접 수정하지 마십시오. 이렇게 하면 시스템 전체의 OpenSSL 작업(SSH, TLS 연결 및 기타 서비스)이 의도치 않게 CloudHSM 공급자를 통해 라우팅되지 않습니다.
별도의 구성 파일을 사용하면 HSM 지원 암호화 작업이 필요한 특정 애플리케이션으로만 CloudHSM 공급자 사용량의 범위를 지정할 수 있습니다.
다음 내용이 포함된 새 OpenSSL 구성 파일을 생성합니다.
$cat >## NOTE: This should point to the system default openssl config file. # Replace /etc/pki/tls with the path to your OpenSSL configuration directory .include<example-cloudhsm-openssl.cnf><< 'EOF'</etc/pki/tls>/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 = 1EOF -
CLOUDHSM_PIN환경 변수가 CU(Crypto User) 자격 증명으로 설정되어 있는지 확인합니다.$export CLOUDHSM_PIN=<username>:<password> -
업데이트된 구성 파일을 가리키도록
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
-
-
다음 명령을 실행하여
/etc/nginx/nginx.conf파일을 백업합니다.$cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup -
NGINX 구성을 업데이트합니다.
참고
각 클러스터는 모든 NGINX 웹 서버에서 최대 1000개의 NGINX 작업자 프로세스를 지원할 수 있습니다.
파일을 저장합니다.
-
systemd구성 파일을 백업한 후,EnvironmentFile경로를 설정합니다. -
/etc/sysconfig/nginx파일이 있는지 여부를 확인한 후, 다음 중 하나를 수행합니다.-
파일이 있는 경우 다음 명령을 실행하여 파일을 백업합니다.
$cp /etc/sysconfig/nginx /etc/sysconfig/nginx.backup -
파일이 없는 경우 텍스트 편집기를 연 후
/etc/sysconfig/폴더에nginx라는 파일을 생성합니다.
-
-
NGINX 환경을 구성합니다.
-
NGINX 웹 서버를 시작합니다.
NGINX를 구성한 후 로 이동합니다HTTPS가 사용자가 구성한 인증서를 사용하는지 확인.
HAProxy 웹 서버 구성
이 섹션을 사용하여 OpenSSL 공급자로 HAProxy를 구성합니다. 다음 예제에서는 CloudHSM 인증서 및 키를 사용하여 HAProxy를 설정하는 방법을 보여줍니다.
OpenSSL 공급자용 HAProxy를 구성하려면
-
기존 통합 인증서 파일이 있는 경우 백업합니다.
$cp server-combined.pem server-combined.pem.backup -
인증서와 CloudHSM 가짜 PEM 키를 사용하여 HAProxy용 통합 인증서 파일을 생성합니다.
$cat server.crt server.key > server-combined.pem -
기존 HAProxy 구성을 백업합니다.
$cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup -
에서 새 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파일 위치와 일치하도록 인증서 경로를 업데이트합니다.
-
HAProxy용 환경 파일을 사용하도록 systemd를 구성합니다. 위치는 Linux 배포판에 따라 다릅니다.
-
시스템에 적합한 위치에 환경 파일을 생성합니다.
<CU 사용자 이름>및<암호>를 CU 자격 증명으로 바꿉니다. -
시스템 구성 다시 로드:
$systemctl daemon-reload -
CloudHSM TLS 오프로드 구성으로 HAProxy를 시작합니다.
$systemctl start haproxy사용자 지정 구성 파일을 사용하여 HAProxy를 직접 실행할 수도 있습니다.
$haproxy -f /path/to/haproxy-cloudhsm.cfg
HAProxy를 구성한 후 로 이동합니다HTTPS가 사용자가 구성한 인증서를 사용하는지 확인.
4단계: HTTPS 트래픽 활성화 및 인증서 확인하기
를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM.
인바운드 HTTPS 연결 활성화
클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다.
HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면
-
https://console.aws.amazon.com/ec2/
에서 Amazon EC2 콘솔을 엽니다. -
탐색 창에서 보안 그룹을 선택합니다.
-
보안 그룹 생성을 선택합니다.
-
보안 그룹 생성에서 다음을 수행합니다.
-
보안 그룹 이름에 생성하려는 보안 그룹의 이름을 입력합니다.
-
(선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다.
-
웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 VPC로 선택합니다.
-
규칙 추가를 선택합니다.
-
드롭다운 창에서 HTTPS를 유형으로 선택합니다.
-
소스에 소스 위치를 입력합니다.
-
보안 그룹 생성을 선택합니다.
-
-
탐색 창에서 인스턴스(Instances)를 선택합니다.
-
웹 서버 인스턴스 옆에 있는 확인란을 선택합니다.
-
페이지 상단의 작업 드롭다운 메뉴를 선택합니다. 보안을 선택한 다음 보안 그룹 변경을 선택합니다.
-
연결된 보안 그룹에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 보안 그룹 추가를 선택합니다.
-
저장을 선택합니다.
HTTPS가 사용자가 구성한 인증서를 사용하는지 확인
웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 OpenSSL s_client
웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면
-
웹 브라우저를 사용하여 서버의 퍼블릭 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 인스턴스로 트래픽 라우팅을 참조하십시오.
-
웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오.
-
Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 View a Certificate(인증서 보기)
를 참조하십시오. -
Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 보안 문제 이해
를 참조하십시오.
다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다.
-
-
SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
OpenSSL s_client를 사용하여 SSL/TLS 오프로드를 확인하려면
-
다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다.
<server name>을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다.openssl s_client -connect<server name>:443작은 정보
Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 Amazon Route 53 개발자 안내서 또는 DNS 서비스 설명서에서 Amazon EC2 인스턴스로의 라우팅 트래픽을 참조하십시오.
-
SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다.
이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다.
로드 밸런서를 추가하려면 Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항) 섹션을 참조하십시오.