온프레미스 대 클라우드 TLS 검사: 배포 시 고려해야 할 장단점
- TLS 검사 과정에서는 트래픽을 복호화하고, 검사한 후 다시 암호화하므로, 이 과정이 이루어지는 곳이라면 어디에서든 잠시 동안 평문이 존재하게 됩니다.
- 로컬 검사를 통해 로컬 평문과 키를 제어할 수 있으며, 클라우드 기반 서비스와 해당 처리 과정을 별도로 평가할 수 있습니다.
- NSA 지침에 따르면, 체인형 프록시를 사용하지 않고 기업 네트워크 내에서 각 세션을 한 번씩 검사할 것을 권장하고 있습니다.
- 고정된 앱, 개인정보 보호가 중요한 카테고리, 그리고 검사 과정에서 오류가 발생하는 트래픽에 대해 검토를 거친 예외 목록을 관리합니다.
- RFC 9849로 발표된 ‘암호화된 Client Hello’는 수동적 가시성을 제한하므로 신중한 처리가 필요합니다.
TLS 검사(여전히 SSL 검사라고 불리는 경우가 많음)는 TLS 세션을 가로채어, 기업이 신뢰하는 인증서로 복호화한 뒤 내용을 검사하고, 다시 암호화한 후 목적지로 전달하는 과정입니다. 이 과정이 없으면 보안 웹 게이트웨이, DLP 엔진, 샌드박스는 목적지 메타데이터만 확인할 수 있습니다. 반면 이 과정을 거치면, 암호화된 세션 내에서 악성코드를 탐지하고, 데이터 유출을 차단하며, 허용 가능한 사용 정책을 적용할 수 있습니다.
핵심은 ‘검사를 할 것인가’가 아니라 ‘어디서 검사할 것인가’입니다. 이 가이드에서는 복호화 경로, 인증서 관리 책임, 예외 사항, 로깅 및 운영 측면에서 온프레미스 및 클라우드 TLS 검사를 비교합니다.
이 기사는 ‘하이브리드 클라우드 보안’ 가이드의 일부입니다.
TLS 검사 작동 원리
TLS 검사 방식은 신뢰할 수 있는 프록시가 클라이언트의 암호화된 세션을 종료하고, 내용을 검사한 뒤, 대상에 대한 새로운 암호화된 세션을 개설하는 방식으로 작동합니다.
프록시는 클라이언트에 대해서는 서버 역할을, 대상에 대해서는 클라이언트 역할을 수행합니다:
- 클라이언트는 웹사이트나 애플리케이션에 대해 TLS 세션을 시작합니다.
- 프록시는 연결을 가로채고, 클라이언트 기기가 신뢰하는 기업용 검사 인증 기관(CA)이 서명한 대상에 대한 인증서를 제시합니다.
- 프록시는 실제 목적지와 자체 TLS 세션을 열고 해당 서버의 인증서를 검증합니다.
- 두 세션 간의 트래픽은 복호화되어 검사된 후 다시 암호화됩니다.
이는 프록시가 매우 강력한 키를 보유하고 있으며, 검사 대상인 모든 세션의 평문을 처리한다는 것을 의미합니다. NSA의 권고문인 ‘전송 계층 보안(TLS) 검사로부터의 위험 관리(Managing Risk from Transport Layer Security Inspection) ’에서는 이러한 상황이 발생하는 경우를 최소화할 것을 권장합니다. 즉, 기업 네트워크 내에서 검사를 한 번만 수행하고, 여러 포워드 프록시에 의한 중복 검사를 피해야 한다는 것입니다. CISA가 이전에 발표한 HTTPS 가로채기 관련 경보에서는, 제대로 구현되지 않은 검사 제품이 예를 들어 업스트림 인증서를 적절히 검증하지 못하는 등의 이유로 TLS 보안을 약화시킬 수 있다고 경고한 바 있습니다.
온프레미스 대 클라우드 TLS 검사 비교 요약
온프레미스 검사 방식은 평문과 키를 사용자의 인프라에 보관하는 반면, 클라우드 검사 방식은 이를 서비스 제공업체의 접속 지점으로 이동시킵니다.
| 요인 | 로컬(온프레미스) TLS 검사 | 클라우드 TLS 검사 |
|---|---|---|
| 평문이 존재하는 곳 | 귀사의 데이터 센터 또는 지사용 어플라이언스 | 서비스 제공업체의 접속 지점 |
| 검사 CA의 개인 키를 누가 보유하고 있나요? | 사용자, 원하는 경우 본인의 HSM을 사용할 수 있습니다 | 제공자, 또는 제공자가 지원하는 키 옵션을 통해 귀하 |
| 다음에 가장 적합합니다 | 규제 대상 데이터, 내부 트래픽, 현장 사용자, OT | 원격 사용자, SaaS로 직접 연결되는 트래픽 |
| 현장 사용자의 지연 시간 | 현지 처리 능력과 트래픽 경로에 따라 다릅니다. | 접속 지점 간의 거리와 라우팅에 따라 다릅니다. |
| 용량 계획 | 참고: 암호 해독은 연산 집약적입니다. | 제공자의 |
| 외부 연결에 대한 의존성 | 로컬 웹 정책 적용에는 필요하지 않으나, 데이터 보호와 같은 클라우드 기반 서비스에는 필수입니다. | 필수 |
| 로그 및 증거의 위치 | 로컬 로그는 구성할 수 있으며, 클라우드 서비스의 증거 자료는 해당 서비스의 저장 정책을 따릅니다. | 구성 설정에 따라 달라지는 제공 지역 |
| 운영 활동 | 하드웨어 사양 결정, 패치 적용, 인증서 수명 주기 | 인증서 배포, 예외, 공급자 구성 |
대부분의 하이브리드 조직은 선별된 온프레미스 트래픽 및 규제 대상 트래픽에 대해서는 로컬 검사를, 원격 사용자에 대해서는 클라우드 검사를 모두 사용합니다. 각 경로에 TLS 종료를 매핑하고, 로컬 게이트웨이가 클라우드 기반 서비스용 트래픽을 전달하는 경우를 포함하여 중복된 암호 해독을 방지하십시오.
복호화 경로
모든 하이브리드 설계는 각 TLS 종단 및 재암호화 지점을 정확히 파악하고, 중복된 검사를 피해야 합니다.
일반적인 경로는 다음과 같습니다:
- 오피스 사용자가 인터넷에 접속할 때: 로컬 게이트웨이 또는 클라우드 접속 지점으로 터널링
- 원격 사용자의 인터넷 접속: 클라우드 접속 지점 또는 로컬 게이트웨이로 백홀 연결
- 사용자 → 비공개 앱: 선택한 ZTNA 경로가 TLS 검사 기능을 지원하는지, 그리고 지원하는 경우 어디에서 지원하는지 확인
- 브라우저 세션: 네트워크 암호 해독 없이 콘텐츠를 볼 수 있는 브라우저 수준의 제어 기능
- 종단점: 기기에서의 에이전트 기반 검사
하이브리드 환경에서 발생할 수 있는 위험 중 하나는 계획되지 않은 중복 복호화입니다. 지사에서는 트래픽을 로컬 프록시를 통해 전송한 후, TLS를 다시 종료하는 클라우드 서비스를 경유할 수 있습니다. 필요한 각 검사 단계를 문서화하고, 각 평문 경계를 보호하며, 보안 노출 위험을 높이거나 문제 해결을 복잡하게 만드는 중복 단계를 제거해야 합니다.
인증서 관련 책임
TLS 검사는 이를 뒷받침하는 인증서의 신뢰도에 따라 그 신뢰성이 결정되므로, 인증서 수명 주기의 각 단계에 대해 명확한 책임 소재를 지정해야 합니다:
- CA 생성 및 보호 점검. 개인 키의 저장 위치, 접근 권한이 있는 사용자, HSM이 필요한지 여부를 문서화하십시오. 각 로컬 게이트웨이 또는 클라우드 서비스와 해당 제품 버전에 대해 지원되는 HSM 통합 기능을 확인하십시오. 지원이 당연하다고 가정하지 마십시오.
- 배포. 관리 대상 기기의 운영 체제 및 브라우저 신뢰 저장소에 CA가 어떻게 설치되는지, 그리고 관리되지 않는 기기에서는 어떤 일이 발생하는지.
- 교대. 정전 없이 검사 CA를 교체하기 위한 일정 및 절차.
- 상류 검증. 프록시가 유효하지 않거나 만료되었거나 취소된 수신자 인증서를 사용자에게 숨기지 않고 거부하는지 확인합니다.
- 프로토콜 지원. TLS 1.3(RFC 8446)은 다운그레이드하지 말고 기본적으로 검사해야 합니다.
교통 예외 사항
어떤 조직도 모든 데이터를 복호화해서는 안 되므로, 문서화되어 있고 정기적으로 검토되는 예외 목록을 유지해야 합니다:
| 예외 유형 | 이유 | 일반적인 취급 방법 |
|---|---|---|
| 인증서가 고정된 애플리케이션 | 검사가 연결을 끊습니다 | 목적지별 우회; 평판 및 카테고리 기반 제어 적용 |
| 건강, 재정, 개인 관련 카테고리 | 직원의 사생활 보호, 법적 요건 및 노사협의회 요건 | 복호화 과정을 건너뛰되, 카테고리 정책은 여전히 적용 |
| 상호 TLS 및 클라이언트 인증서 인증 | 프록시가 클라이언트 인증서를 제시할 수 없습니다. | 우회하거나 지원되는 패스스루를 사용하십시오 |
| 업데이트 서비스 및 일부 OT 프로토콜 | 안정성 및 공급업체 지원 | 접근이 제한된 목적지에 따른 우회 |
| QUIC 및 HTTP/3 (RFC 9000) | 많은 프록시는 QUIC을 검사할 수 없습니다 | QUIC을 차단하여 브라우저가 TCP를 통한 TLS로 대체되도록 하거나, 네이티브 지원 여부를 확인하십시오. |
분기별로 예외 사항을 검토하십시오. 오래되어 더 이상 적용되지 않는 우회 조치는 흔히 간과되는 사각지대입니다.
암호화된 Client Hello와 그로 인해 달라지는 점
암호화된 Client Hello는 수동적인 관찰자로부터 대상 호스트명을 숨기므로, SNI 기반의 가시성 및 일부 우회 결정에 대해 재고할 필요가 있습니다.
‘암호화된 클라이언트 헬로(Encrypted Client Hello, ECH)’는 2026년에 RFC 9849로 발표되었습니다. ECH는 이전에는 대상 호스트 이름(서버 이름 표시, SNI) 및 기타 필드를 노출하던 TLS 핸드셰이크의 해당 부분을 암호화합니다. SNI를 읽어 트래픽을 분류하는 수동형 도구는 ECH가 활성화된 사이트의 경우 이러한 정보를 파악할 수 없게 됩니다.
TLS를 종료하는 명시적 프록시는 대상과 별도의 세션을 구축하기 때문에 상황이 다릅니다. 그렇다 하더라도 ECH는 운영상 다음과 같은 영향을 미칩니다:
- 브라우저는 ECH가 사용되지 않는 경우에도 ECH와 유사한 확장 정보를 전송할 수 있으므로, 검사 도구는 이를 올바르게 처리해야 합니다.
- 이 RFC는 관리형 기업 환경에서 그룹 정책을 통해 ECH를 비활성화하고, 클라이언트가 해당 설정을 준수하도록 하는 것이 한 가지 접근 방식이라고 언급하고 있습니다.
- 우회된 트래픽에 대해 SNI에 의존하던 카테고리 및 평판 결정에는 DNS 계층 제어나 명시적인 프록시 구성과 같은 대안이 필요합니다.
검사 업체의 ECH 로드맵을 확인하고, 최신 브라우저 버전에서 테스트 동작을 검증하십시오.
로그 기록
검사 로그에는 URL, 신원 정보 및 DLP 증거가 포함될 수 있으므로, 해당 로그의 내용, 저장 위치 및 접근 권한에 대해서는 명확한 결정이 필요합니다:
- 복호화된 트래픽과 우회된 트래픽에 대해 각각 어떤 필드가 기록되나요?
- 로그가 어디에 저장되는지, 그리고 해당 관할 구역을 벗어날 수 있는지 여부
- 보존 기간 및 전체 콘텐츠 증거에 접근할 수 있는 대상
- 어떤 이벤트가 SIEM으로 전달되나요?
현장 검사를 실시하면 해당 국가 내에서 로그 및 증거 자료를 보관하기가 더 쉬워집니다. 클라우드 검사의 경우, 서비스 제공업체의 로그 저장 지역 및 접근 제어 정책을 확인해야 합니다. ‘하이브리드 클라우드 보안에서의 데이터 주권’을 참조하십시오.
운영상의 상충 관계
로컬 검사 방식은 제어 기능을 위해 운영상의 노력을 치러야 하는 반면, 클라우드 검사 방식은 단순성을 위해 제어 기능을 희생하며, 하이브리드 검사 방식은 원활한 작동을 위해 하나의 정책 엔진이 필요합니다.
로컬 검사 기능을 구현하려면 피크 시간대의 데이터 처리량을 고려하여 장비를 적절히 구성하고, 검사 엔진에 패치를 꾸준히 적용하며, 하드웨어 또는 가상 용량 확장을 계획해야 합니다. 그 대가로 로컬에서 검사되는 트래픽에 대한 평문, 키 및 로그를 완전히 제어할 수 있으며, WAN 또는 클라우드 연결이 중단된 상황에서도 웹 및 사내 애플리케이션 정책에 대한 로컬 적용이 지속되는 반면, 벤더 클라우드에서 적용되는 서비스는 연결이 복구될 때까지 일시 중지됩니다.
클라우드 검사를 도입하면 용량 계획 수립과 엔진 업데이트 업무가 서비스 제공업체 측으로 이관됩니다. 여전히 인증서 배포, 예외 관리, 정책 조정이 필요하며, 서비스 제공업체의 가용성과 연결 상태에 대한 의존성이 발생합니다.
하이브리드 검사는 두 가지를 모두 결합하지만, 하나의 정책 엔진에서만 제대로 작동합니다. 로컬 게이트웨이와 클라우드 게이트웨이가 서로 다른 예외 목록과 DLP 규칙을 가지고 있다면, 사용자는 위치에 따라 다르게 처리될 것입니다.
Skyhigh의 온프레미스 및 클라우드 검사 접근 방식
Skyhigh는 규정 준수 요건에 따라 로컬 환경에서는 TLS를 검사하고, 원격 사용자의 경우 클라우드 환경에서 TLS를 검사하며, 이를 단일 정책 하에 수행합니다.
Skyhigh Hybrid SSE Mesh는 규정 준수가 필요한 경우 조직의 자체 어플라이언스에서, 원격 사용자의 경우 Skyhigh 클라우드 PoP(Point of Presence)에서 SSL/TLS 복호화 및 검사를 수행하며, 두 환경 모두에 단일 정책 엔진을 적용합니다. Secure Web Gateway 및 Zero Trust Access는 게이트웨이에서 기본적으로 적용되는 반면, 데이터 보호 정책은 게이트웨이가 전달하는 트래픽에 대해 Skyhigh 클라우드에서 적용됩니다. 온프레미스 게이트웨이에서 복호화된 웹 트래픽은 현지 웹 정책 적용을 위해 해당 게이트웨이에서 검사 및 재암호화됩니다. 데이터 보호와 같이 클라우드에서 적용되는 서비스를 사용하는 정책의 경우, 게이트웨이는 관련 트래픽을 Skyhigh 클라우드로 전달하며, 클라우드는 동일한 정책을 적용합니다. 에이전트 없는 보안 브라우저 제어(Agentless Secure Browser Controls) 기능은 브라우저 세션 내 AI 및 메시징 트래픽에 대해 WebSocket을 인식하는 검사 기능을 추가합니다.
출처
- NSA. 전송 계층 보안(TLS) 검사에서 발생하는 위험 관리 (2019년 11월). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. “HTTPS 가로채기가 TLS 보안을 약화시킨다” (경보 TA17-075A, 2017년 3월). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: 전송 계층 보안(TLS) 프로토콜 버전 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: TLS 암호화 클라이언트 헬로. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: UDP 기반의 다중화 및 보안 전송 프로토콜. https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. “Skyhigh SSE 플랫폼으로 하이브리드 도입이 한층 더 쉬워졌습니다” (2024년 10월 3일). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “Skyhigh Hybrid SSE Mesh를 활용한 시만텍 엣지 Secure Web Gateway 현대화” (2026년 7월 15일). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html