
Upstream 서버에 대한 TCP 트래픽 보호
NGINX Plus 의 SSL/TLS 암호화를 사용하여 NGINX 또는 NGINX Plus와 Upstream 서버 간의 TCP 트래픽을 보호합니다.
이 문서에서는 NGINX와 TCP Upstream 서버 또는 TCP 서버의 Upstream 그룹 간의 TCP 트래픽을 보호하는 방법을 설명합니다.
목차
1. 전제 조건
2. SSL 서버 인증서 가져오기
3. SSL 클라이언트 인증서 가져오기
4. NGINX 구성
5. 전체 예제
1. 전제 조건
with-stream
및with-stream_ssl_module
구성 매개변수를 사용하여 컴파일된 NGINX Plus R6 이상 또는 최신 NGINX Open Source- Proxy된 TCP 서버 또는 TCP 서버의 Upstream 그룹
- SSL 인증서 및 Private Key
2. SSL 서버 인증서 가져오기
먼저 서버 인증서와 Private Key를 받아서 Upstream 서버 또는 Upstream 그룹의 각 서버에 넣어야 합니다. 인증서는 신뢰할 수 있는 Certificate Authority(CA)에서 받거나 OpenSSL과 같은 SSL 라이브러리를 사용하여 생성할 수 있습니다.
자체 서명된 서버 인증서는 NGINX와 Upstream 서버 간의 연결을 암호화해야 할 때 사용됩니다. 그러나 이러한 연결은 중간자 공격에 취약합니다. 즉, 공격자가 Upstream 서버를 사칭할 수 있으며 NGINX는 가짜 서버와 통신하고 있다는 사실을 알지 못합니다. 신뢰할 수 있는 CA에서 서명한 서버 인증서를 받으면(OpenSSL을 사용하여 자체 내부 CA를 만들 수 있음), 해당 CA에서 서명한 인증서만 신뢰하도록 NGINX를 구성할 수 있습니다. 이렇게 하면 공격자가 Upstream 서버를 사칭하기가 훨씬 더 어려워집니다.
3. SSL 클라이언트 인증서 가져오기
NGINX는 SSL 클라이언트 인증서를 사용하여 Upstream 서버에 자신을 식별할 수 있습니다. 이 클라이언트 인증서는 신뢰할 수 있는 CA가 서명하고 해당 Private Key와 함께 NGINX에 저장해야 합니다.
들어오는 모든 SSL 연결에 대해 클라이언트 인증서를 요구하고 클라이언트 인증서를 발급한 CA를 NGINX에 신뢰하도록 Upstream 서버를 구성해야 합니다. 그러면 NGINX가 Upstream에 연결할 때 클라이언트 인증서를 제공하고 Upstream 서버가 이를 수락합니다.
4. NGINX 구성
NGINX 구성 파일에서 stream
Level의 server
블록에 proxy_ssl
지시문을 포함시킵니다.
stream {
server {
...
proxy_pass backend;
proxy_ssl on;
}
}
그런 다음 Upstream 서버에 필요한 SSL 클라이언트 인증서의 경로와 인증서의 Private Key를 지정합니다.
server {
...
proxy_ssl_certificate /etc/ssl/certs/backend.crt;
proxy_ssl_certificate_key /etc/ssl/certs/backend.key;
}
선택 사항으로 어떤 SSL 프로토콜과 암호를 사용할지 지정할 수 있습니다.
server {
...
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
}
CA에서 발급한 인증서를 사용하는 경우, Upstream의 보안 인증서를 확인하는 데 사용되는 신뢰할 수 있는 CA 인증서가 포함된 파일 이름을 지정하는 proxy_ssl_trusted_certificate
지시문도 포함하세요. 파일은 PEM 형식이어야 합니다. 선택 사항으로 proxy_ssl_verify
및 proxy_ssl_verfiy_depth
지시문을 포함하면 NGINX가 보안 인증서의 유효성을 확인하도록 합니다.
server {
...
proxy_ssl_trusted_certificate /etc/ssl/certs/trusted_ca_cert.crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;
}
새로운 SSL 연결마다 클라이언트와 서버 간에 전체 SSL Handshake가 필요하므로 CPU 사용량이 상당히 높습니다. 이전에 협의한 connection 매개변수를 NGINX Proxy가 사용하도록 하고 소위 축약된 Handshake를 사용하려면 proxy_ssl_session_reuse
지시문을 추가하세요.
proxy_ssl_session_reuse on;
5. 전체 예제
stream {
upstream backend {
server backend1.example.com:12345;
server backend2.example.com:12345;
server backend3.example.com:12345;
}
server {
listen 12345;
proxy_pass backend;
proxy_ssl on;
proxy_ssl_certificate /etc/ssl/certs/backend.crt;
proxy_ssl_certificate_key /etc/ssl/certs/backend.key;
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/ssl/certs/trusted_ca_cert.crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;
proxy_ssl_session_reuse on;
}
}
이 예제에서 proxy_ssl
지시문은 NGINX가 Upstream 서버로 전달하는 TCP 트래픽을 보호하도록 지정합니다.
보안 TCP 연결이 NGINX에서 Upstream 서버로 처음 전달되면 전체 Handshake 프로세스가 수행됩니다. Upstream 서버는 proxy_ssl_certificate
지시문에 지정된 보안 인증서를 제시하도록 NGINX에 요청합니다. proxy_ssl_protocols
및 proxy_ssl_ciphers
지시문은 어떤 프로토콜과 암호를 사용할지 제어합니다.
다음에 NGINX가 Upstream에 연결을 전달할 때 proxy_ssl_session_reuse
지시문으로 인해 session 매개변수가 재사용되며 보안 TCP 연결이 더 빠르게 설정됩니다.
proxy_ssl_trusted_certificate
지시문으로 지정된 파일에 있는 신뢰할 수 있는 CA 인증서는 Upstream 서버에서 인증서를 확인하는 데 사용됩니다. proxy_ssl_verify_depth
지시문은 인증서 체인에 있는 두 개의 인증서를 확인하도록 지정하고, proxy_ssl_verify
지시문은 인증서의 유효성을 확인하도록 지정합니다.