알림
뒤로
NGINX OpenSource/Plus 에서 구현가능한 기술 / 사용사례

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

관리자
조회수 373


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

NGINX에서 HTTPS 트래픽을 복호화하면 많은 이점이 있습니다.

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 트래픽을 처리 하고 이를 업스트림 그룹으로 프록시합니다.


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를 통해 백엔드 서버와 통신할 수 있도록 합니다. 

또는 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를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

  

전문가에게 상담받기

NGINX Plus를 사용한 역방향 프록시 WebSocket 프록시로서의 NGINX
목록