[NCP] (심화) 네이버 클라우드에서 TLSv1.2 이상으로만 제한하려면 어떻게 해야할까?

안녕하세요.

 

이번 시간에는 네이버 클라우드에서 TLSv1.2 이상으로만 제한하려면 어떻게 해야 하는지 알아보도록 하겠습니다.

 

1. 개요

요즘 정부·감사기관·고객사 보안점검에서 TLS 1.2 미만 차단(즉 TLSv1.2 이상만 허용) 요구가 빈번합니다. 인프라 구성(콘텐츠 전송, 경계장비, 로드밸런서, 웹서버)에 따라 설정 위치와 우선순위가 달라집니다.

이 글은 CDN → WAF → LB → WEB(애플리케이션 서버) 관점으로 TLS 정책을 정리하고, NCP(네이버 클라우드) 환경에서 실제로 어떤 점을 확인·조치해야 하는지 단계별로 초안 형식으로 정리한 것입니다.

 

2. 왜 TLS 버전 제한이 필요할까요?

1. 취약성 제거

TLS 1.0/1.1은 이미 오래된 암호화 방식으로 여러 취약성이 보고되어 실무에서 퇴출 권고됨. 규정/가이드(국가/금융기관 등)는 보통 TLS1.2 이상을 요구.

 

2. 규정 준수

보안점검 체크리스트·컴플라이언스(예: 금융·공공)에서 기술적 요구사항으로 명시됨.

 

3. 신뢰성 확보

안전한 프로토콜 유지로 사용자 데이터 보호, 서비스 신뢰도 향상.

 

3. 전체 아키텍처에서 고려할 점 (우선 순위)

TLS 버전 제한은 서비스의 가장 끝단에 우선 적용해야 합니다. 중간에만 TLS를 제한한다고 해도 끝단에서 TLS를 제한하지 않으면 요청 시 1.0, 1.1 버전도 통과됩니다.

 

 

1. CDN (Global Edge) — CDN(또는 외부 프록시)
→ 사용자와 가장 먼저 접촉하므로 여기서 TLS를 강제하면 약한 클라이언트 차단을 가장 빨리 수행.

 

2. 웹 방화벽(WAF) — TLS 종단/중단 여부에 따라 정책 적용 위치 결정.

 

3. 로드밸런서(LB) — 내부 트래픽과 외부 트래픽을 중재, TLS 오프로드 시 설정 필요.

 

4. 웹/애플리케이션 서버 — 최종적으로 서버 자체에서도 TLS 1.2 이상만 허용해 방어층 강화.

 

 

현재 점검 중인 시스템의 가장 끝단이 어디인지 확인한 후 TLS 제한은 끝단을 기준으로 우선 적용하도록 합니다.

핵심: 말단(Edge)에서 먼저 제한 + 내부(서버)에서 재확인
이 가장 안전한 패턴입니다. 한 지점만 변경하면 겉보기는 통과되지만 내부 서버가 취약한 상태일 수 있으므로 다층 방어(Defense in depth)를 권장합니다.

 

4. 실제 서비스별 조치 방법 (NCP)

1) CDN (Global Edge)

목적: 사용자 - 서비스 구간에서 TLSv1.2 미만 연결 차단

조치 방법: (1) Certificate Provisioning 사용

Global Edge에는 최근 Certificate Provisioning 기능을 통해 편리하게 인증서와 관련된 기능을 손쉽게 배포할 수 있게 되었습니다.

이 중에서도 TLS 제한에 가장 중요한 설정은 TLS 프로토콜 지원 버전과 Cipher Profile입니다.

 

CDN이 끝단이라면 앞에서도 설명드렸듯 WAF LB, LB, WEB에서 TLS 버전을 제한하더라도 TLS1.0, 1.1로도 요청이 됩니다.

우측에 ...을 눌러 [TLS 프로토콜 버전 설정]을 눌러줍니다. 저도 처음에는 업데이트 위치를 몰랐는데 업데이트는 해당 기능을 통해 가능합니다.

 

여기서 네이버 클라우드 플랫폼 권고 (TLS 1.2 이상 지원)로 변경하시고 프로필은 [GE-STRICT-v1]으로 변경합니다.

여기서 TLS 프로토콜 설정만 변경하시고 Cipher Profile은 변경하지 않는 경우 1.0과 1.1이 허용됩니다.

 

중요

Profile	Description	Cipher Suites
GE-STRICT-v1	이 프로필은 TLSv1.2 및 TLSv1.3만 지원하며 모든 인증서에 권장됨 Qualy SSL Labs 서버 테스트에서 "A"등급을 받는데 도움이 되도록 선택 가능	TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 TLS-AES-128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305
GE-GENERAL-v1	이 프로필은 TLSv1.3을 포함한 모든 TLS 버전에서 사용 가능함 더 이상 권장하지는 않지만 이전 클라이언트를 지원하는데 필요할 수 있는 CBC 암호가 포함되어 있음	TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 TLS-AES-128-GCM-SHA256 TLS-AES-128-CCM-8-SHA256 TLS-AES-128-CCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA
GE-DEFAULT-v1	이 프로필은 TLSv1.3을 포함한 모든 TLS 버전에서 사용 가능함 이 프로필은 순방향 비밀성(Forward Secrecy)을 지원하지 않거나 TLSv1.0 또는 TLSv1.1 지원이 필요한 레거시 클라이언트를 지원하기 위해 설계되었음	TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 TLS-AES-128-GCM-SHA256 TLS-AES-128-CCM-8-SHA256 TLS-AES-128-CCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES256-SHA AES128-SHA

https://guide.ncloud-docs.com/docs/certificateprovisioning-management

 

2) WAF (NCP Security Monitoring)
목적: 차단 정책 적용 전에 TLS 종료가 어디서 이루어지는지 확인

중요 포인트:
(1) WAF에서 TLS를 종료하는 경우: WAF에서 허용할 TLS 버전을 제한하면 끝. WAF가 리버스 프록시 역할로 TLS를 종료하므로 실제 클라이언트-서버 구간의 TLS 검증은 WAF가 담당
(2) WAF가 패스스루(pass-through)인 경우: WAF는 암호화된 트래픽을 그대로 백엔드로 전달하므로, WAF 설정만 변경해도 클라이언트 쪽 제어가 안될 가능성이 높음

조치 방법: [NCP 문의하기]를 통해 WAF LB TLSv1.2 이상으로만 제한하도록 설정 요청

 

3) LoadBalancer (NCP LoadBalancer)

목적: 외부로부터 오는 TLS 연결을 중앙에서 오프로드하거나 패스스루 할 때 정책 적용

조치 방법:

 

(1) LB에서 SSL/TLS 정책(Protocol policy)을 TLS1.2 이상으로 설정
(2) TLS 오프로드(terminate) 시 백엔드와의 통신은 내부망이더라도 가능하면 내부도 TLS1.2 이상으로 유지
(3) Session persistence 등 기능과 연동 시 문제가 없는지 테스트

 

4) WEB Server (NCP Server)
목적: 서버 자체에서 TLS1.2 미만 허용 여부를 차단

조치 방법: Nginx: ssl_protocols TLSv1.2 TLSv1.3;
예시:

server {
  listen 443 ssl;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers on;
  ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:...'; # 권장 목록 사용
  ...
}

 

5. 실제 운영에서의 체크리스트 & 테스팅 절차

배포 전 체크리스트

1. 서비스 맵 작성: 사용자→CDN→WAF→LB→WEB 흐름을 명확히 문서화. TLS가 어디서 종료되는지 표시
2. 설정 우선순위 결정: Edge 우선 정책 적용(권장) + Backend 재확인
3. 암호화 스위트 목록 검토: 취약한 ciphers(예: RC4, 3DES) 제거
4. 레거시 클라이언트 영향 분석: TLS1.2 미만을 사용하는 고객/장비가 있는지 파악
5. 콘솔 스크린샷/설정 백업: 변경 전후 스냅샷 보관(감사용)
6. 테스트 계획: 다양한 TLS 버전으로의 접속 시나리오(성공/차단) 작성

 

배포 후 검증

1. 외부에서 openssl s_client로 TLS 버전별 테스트.
2. SSL Labs 또는 유사 도구로 전체 도메인 스캔(Protocols, Cipher, KeyExchange 등).
3. 모니터링/로그: 차단된 접속 시도 및 사용자 불만 발생 모니터링.
4. 필요시 점진적 롤아웃(시간대/오리진 그룹별) — 레거시 영향 최소화.

 

6. 요약 (한 문장)

가장 안전한 패턴은 ‘Edge(CDN)에서 TLS 1.2 이상을 먼저 강제하고, WAF/LB/WEB에서도 재확인하여 다중 방어층을 구축’하는 것입니다. 변경 전 서비스 맵을 작성하고 레거시 영향평가와 테스트 계획을 반드시 수립하는 것이 좋습니다.

 

이번 시간에는 NCP에서 TLS 버전을 제한하는 자세한 가이드를 작성해 봤습니다.

 

감사합니다.