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

NGINX 및 NGINX Plus에서 SSL/TLS를 사용하는 주요 사례는 세 가지입니다.
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는 복호화와 암호화를 모두 수행할 수 있으므로, 계층 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 서버 최적화 – 작업자 프로세스 수를 구성하고, 연결 유지를 사용하며, SSL/TLS 세션 캐시를 활용하여 NGINX의 SSL/TLS 성능을 극대화하도록 조정할 수 있습니다.
자세한 내용은 다음 자료를 참조하세요:
- NGINX SSL 종료(NGINX Plus 관리자 가이드)
- HTTPS 서버 구성(nginx.org)
- ngx_http_ssl_module 참조 문서 - nginx.org
예시
다음은 NGINX의 보안 기능을 보여 주는 몇 가지 예입니다. 이 예제를 이해하려면 NGINX 구성에 대한 기본 지식이 필요합니다.
다음 구성은 www.example.com의 HTTP 트래픽을 처리하고 이를 업스트림 그룹으로 프록시합니다:
upstream backends {
server 192.168.100.100:80;
server 192.168.100.101:80;
}
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass http://backends;
}
}이제 HTTPS 지원을 추가하여 NGINX가 인증서와 개인 키를 사용해 트래픽을 복호화하고 백엔드 서버와는 HTTP로 통신하도록 합니다:
upstream backends {
server 192.168.100.100:80;
server 192.168.100.101:80;
}
server {
listen 80;
listen 443 ssl; # 'ssl' parameter tells NGINX to decrypt the traffic
server_name www.example.com;
ssl_certificate www.example.com.crt; # The certificate file
ssl_certificate_key www.example.com.key; # The private key file
location / {
proxy_pass http://backends;
}
}또는 HTTP를 통해 트래픽을 수신한 후 HTTPS를 통해 백엔드 서버로 전송하는 경우:
upstream backends {
server 192.168.100.100:443;
server 192.168.100.101:443;
}
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass https://backends; # 'https' prefix tells NGINX to encrypt the traffic
}
}NGINX Plus를 사용해 보려면 지금 30일 무료 체험을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.
작성자 소개

관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.