NGINX 및 NGINX Plus를 사용한 SSL/TLS 오프로딩, 암호화 및 인증서

NGINX와 NGINX Plus는 대부분의 SSL/TLS 요구 사항을 처리할 수 있는 다양한 기능을 제공합니다. 그들은 OpenSSL과 표준 프로세서 칩의 성능을 사용하여 비용 효율적인 SSL/TLS 성능을 제공합니다. 표준 프로세서 칩의 성능이 계속 증가하고 칩 공급업체가 암호화 가속 지원을 추가함에 따라 특수 SSL/TLS 칩보다 표준 프로세서 칩을 사용하는 데 따른 비용적 이점도 점점 커지고 있습니다.

SSL/TLS를 지원하는 NGINX 및 NGINX Plus 에는 세 가지 주요 사용 사례가 있습니다.

SSL/TLS 오프로딩

NGINX를 프록시로 사용하면 백엔드 서버에서 SSL 복호화 처리를 오프로드할 수 있습니다. 프록시에서 암호 해독을 수행하는 데는 여러 가지 장점이 있습니다.

• 성능 향상 – SSL 복호화를 수행할 때 성능에 가장 큰 영향을 미치는 부분은 초기 핸드셰이크입니다. 성능을 개선하기 위해 복호화를 수행하는 서버는 SSL 세션 ID를 캐시하고 TLS 세션 티켓을 관리합니다. 이 작업이 프록시에서 수행되면 동일한 클라이언트의 모든 요청이 캐시된 값을 사용할 수 있습니다. 백엔드 서버에서 수행되는 경우 클라이언트의 요청이 다른 서버로 이동할 때마다 클라이언트는 다시 인증해야 합니다. TLS 티켓을 사용하면 이 문제를 완화하는 데 도움이 되지만, 모든 클라이언트에서 지원되는 것은 아니며 구성 및 관리가 어려울 수 있습니다.
• 백엔드 서버 활용도 향상 – SSL/TLS 처리에는 CPU 사용량이 매우 많으며 키 크기가 커질수록 사용량도 점점 더 많아지고 있습니다. 백엔드 서버에서 이 작업을 제거하면 가장 효율적인 작업, 즉 콘텐츠 제공에 집중할 수 있습니다.
• 지능형 라우팅 - 트래픽을 해독하면 프록시는 헤더, URI 등과 같은 요청 콘텐츠에 액세스하고 이 데이터를 사용하여 요청을 라우팅할 수 있습니다.
• 인증서 관리 – 인증서는 프록시 서버에서만 구매하여 설치하면 되며 모든 백엔드 서버에서는 구매할 필요가 없습니다. 이렇게 하면 시간과 비용을 모두 절약할 수 있습니다.
• 보안 패치 - SSL/TLS 스택에 취약점이 발생하는 경우, 해당 패치를 프록시 서버에만 적용하면 됩니다.

자세한 내용은 NGINX Plus 관리자 가이드의 NGINX SSL 종료를 참조하세요.

원본 서버에 대한 SSL/TLS 암호화

백엔드 서버로 전송하는 트래픽을 암호화하기 위해 NGINX가 필요할 때가 있습니다. 이러한 요청은 일반 텍스트로 NGINX 서버에 도착하거나 NGINX가 라우팅 결정을 내리기 위해 해독해야 하는 암호화된 트래픽으로 도착할 수 있습니다.  백엔드 서버에 대한 Keepalive 연결 풀을 사용하면 SSL/TLS 핸드셰이크 수가 최소화되고 결과적으로 SSL/TLS 성능이 극대화됩니다. NGINX를 "https"로 프록시하여 아직 암호화되지 않은 트래픽을 자동으로 암호화하도록 구성하면 매우 간단하게 달성됩니다.

종단간 암호화

NGINX는 복호화와 암호화를 모두 수행할 수 있으므로 NGINX가 여전히 레이어 7 라우팅 결정을 내리는 동안 모든 요청의 종단 간 암호화를 달성할 수 있습니다. 이 경우 클라이언트는 HTTPS를 통해 NGINX와 통신하고, NGINX는 요청을 복호화한 다음 백엔드 서버로 전송하기 전에 다시 암호화합니다. 프록시 서버가 백엔드 서버와 함께 데이터 센터에 배치되지 않은 경우 이것이 바람직할 수 있습니다. 점점 더 많은 서버가 클라우드로 이동함에 따라 프록시와 백엔드 서버 간에 HTTPS를 사용하는 것이 더욱 필요해지고 있습니다.

클라이언트 인증서

NGINX는 SSL/TLS 클라이언트 인증서를 처리할 수 있으며 이를 선택 사항 또는 필수 사항 으로 구성할 수 있습니다. 클라이언트 인증서는 비밀번호가 필요 없이 사전 승인된 클라이언트만 시스템에 액세스할 수 있도록 제한하는 방법이며, 해지된 인증서를 인증서 해지 목록 (CRL)에 추가하여 인증서를 제어할 수 있습니다. NGINX에서 이 목록을 확인하여 클라이언트 인증서가 여전히 유효한지 확인할 수 있습니다.

추가 보안 기능

이러한 사용 사례를 지원하는 데 도움이 되는 다른 기능은 다음과 같습니다(이에 국한되지 않음).

• 여러 인증서 - 단일 NGINX 인스턴스는 다양한 도메인에 대한 여러 인증서를 지원할 수 있으며 수십만 개의 인증서를 지원하도록 확장할 수 있습니다. 각 도메인에 별도의 인증서가 필요하고 여러 IP 주소와 도메인을 제공하는 NGINX 인스턴스가 있는 것은 일반적인 사용 사례입니다.
• OCSP 스테이플링 – 이 기능을 활성화하면 NGINX는 인증 기관에서 서명한 타임스탬프가 포함된 OCSP 응답을 포함하며, 클라이언트는 이를 사용하여 서버의 인증서를 확인하여 OCSP 서버에 직접 연결하여 발생하는 성능 저하를 방지할 수 있습니다.
• SSL/TLS 암호 – 어떤 암호를 사용할지 지정할 수 있습니다.
• SSL/TLS 프로토콜 – SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2를 포함하여 어떤 프로토콜을 활성화할지 지정할 수 있습니다.
• 체인된 인증서 – NGINX는 웹사이트의 인증서가 CA(인증 기관)의 루트 인증서에 의해 직접 서명되지 않고 일련의 중간 인증서를 통해 서명된 경우 사용되는 인증서 체인을 지원합니다. 웹 서버는 중간 인증서가 포함된 '인증서 체인'을 제공하므로, 웹 클라이언트는 웹사이트 인증서와 신뢰할 수 있는 루트 인증서를 연결하는 신뢰 체인을 확인할 수 있습니다.
• HTTPS 서버 최적화 – NGINX는 작업자 프로세스 수 구성, Keepalive 연결 사용 및 SSL/TLS 세션 캐시를 사용하여 SSL/TLS 성능을 최대화하도록 조정할 수 있습니다.

자세한 내용은 다음 리소스를 확인하세요.

• NGINX Plus 관리자 가이드의 NGINX SSL 종료
• nginx.org에서 HTTPS 서버 구성
• nginx.org의 ngx_http_ssl_module 참조 문서

예시

다음은 NGINX의 보안 기능에 대한 몇 가지 예입니다. 이러한 예제에서는 NGINX 구성에 대한 기본적인 이해가 있다고 가정합니다.

다음 구성은 www.example.com 에 대한 HTTP 트래픽을 처리하고 이를 업스트림 그룹으로 프록시합니다.

업스트림 백엔드 {
서버 192.168.100.100:80;
서버 192.168.100.101:80;
}

서버 {
수신 80;
서버 이름 www.example.com;

위치 / {
프록시 패스 http://백엔드;
}
}

이제 HTTPS 지원을 추가하여 NGINX가 인증서와 개인 키를 사용하여 트래픽을 해독하고 HTTP를 통해 백엔드 서버와 통신할 수 있도록 합니다.

업스트림 백엔드 { 서버 192.168.100.100:80; 서버 192.168.100.101:80; } 서버 { 수신 80; 수신 443 ssl ; # 'ssl' 매개변수는 NGINX에 트래픽을 해독하라고 지시합니다 server_name www.example.com; ssl_certificate www.example.com.crt ; # 인증서 파일 ssl_certificate_key www.example.com.key ; # 개인 키 파일 위치 / { proxy_pass http://backends; } }

또는 HTTP를 통해 트래픽을 수신하고 HTTPS를 통해 백엔드 서버로 전송하는 경우:

업스트림 백엔드 { 서버 192.168.100.100:443; 서버 192.168.100.101:443; } 서버 { 수신 80; 서버 이름 www.example.com; 위치 / { 프록시 패스 https ://백엔드; # 'https' 접두사는 NGINX에 트래픽을 암호화하라고 지시합니다. } }

NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요.