Kloudvil

Cloudflare 제품과 활용 사례, Zero Trust를 정리하는 기술 블로그

Cloudflare One 이해하기: TLS Decryption과 HTTP 정책

✍ Myungsup Kwak |
Cloudflare One 이해하기 시리즈 (8편 중 6편)
  1. 전체 구조와 연결 방식
  2. Cloudflare One Client와 Device Posture
  3. Tunnel, Mesh, Cloudflare WAN 비교와 적용 시나리오
  4. Access 인증·인가와 접근 정책
  5. Gateway DNS·Network·HTTP 정책
  6. TLS Decryption과 HTTP 정책 (현재 글)
  7. Browser Isolation 구조와 적용 시나리오
  8. DLP, Data Classification, CASB

이전 글에서 HTTP 정책은 URL, 헤더, 파일까지 검사할 수 있다고 설명했습니다. 하지만 오늘날 웹 트래픽의 대부분은 HTTPS로 암호화되어 있어, 복호화하지 않으면 HTTP 정책이 볼 수 있는 정보는 매우 제한적입니다. 이 글에서는 Gateway의 TLS Decryption이 왜 필요하고 어떻게 동작하는지, 그리고 HTTP 정책과 어떻게 연계되는지 정리합니다.

TLS Decryption이 필요한 이유

HTTPS 연결에서 Gateway가 복호화 없이 확인할 수 있는 정보는 TLS 핸드셰이크에 평문으로 포함된 SNI (Server Name Indication), 즉 접속하려는 호스트네임 정도입니다. 전체 URL, 헤더, 요청·응답 본문은 암호화되어 있어 보이지 않습니다.

검사 항목복호화 없음복호화 있음
호스트네임 (SNI) 기반 허용·차단OO
목적지 IP, 포트 기반 제어 (Network 정책)OO
전체 URL 경로 기반 차단 (예: example.com/admin)XO
HTTP 메서드, 헤더 기반 제어XO
파일 업로드·다운로드 유형 제어XO
안티바이러스 (AV) 검사, 파일 샌드박싱XO
DLP (민감 데이터 탐지)XO
SaaS 세부 동작 제어 (예: 개인 계정 로그인 차단, 업로드 금지)XO
Browser Isolation (In-line 방식)XO
Shadow IT의 상세 가시성제한적O

즉, TLS Decryption은 그 자체가 보안 기능이라기보다 HTTP 정책, DLP, AV 검사, Browser Isolation이 제대로 동작하기 위한 전제 조건입니다.

동작 구조

TLS Decryption을 켜면 Gateway는 사용자와 목적지 서버 사이에서 TLS 연결을 두 구간으로 나누어 처리합니다.

 User device                      Cloudflare Gateway                      Origin server
 (trusts Cloudflare root CA)      (decrypt -> inspect -> re-encrypt)
      |                                   |                                     |
      |==== TLS #1 (user-side cert) ======|==== TLS #2 (origin's cert) =========|
      |                                   |                                     |
                              HTTP policies, DLP, AV
  1. 사용자 디바이스가 HTTPS 요청을 보내면, Gateway가 사용자 쪽 TLS 연결 (TLS #1)을 종료하고 트래픽을 복호화합니다.
  2. Gateway가 HTTP 정책, DLP, AV 검사를 적용합니다.
  3. 허용된 요청은 Gateway가 목적지 서버와 새로운 TLS 연결 (TLS #2)을 맺어 전달합니다.
  4. 응답은 반대 방향으로 검사된 뒤, Gateway가 사용자 측 인증서 (user-side certificate)로 다시 암호화해 사용자에게 전달합니다.

사용자 브라우저 입장에서는 Gateway가 발급한 인증서로 서명된 응답을 받게 되므로, 디바이스가 이 인증서의 루트 CA를 신뢰하고 있어야 경고 없이 동작합니다.

데이터 처리 측면에서 Cloudflare는 복호화, 검사, 재암호화를 데이터센터의 메모리에서만 수행하며, 캐시 대상 콘텐츠만 암호화된 디스크에 저장합니다. 데이터 현지화 요구가 있다면 Data Localization Suite의 Regional Services로 복호화가 수행되는 지역을 제한할 수 있습니다.

적용 조건

1. HTTP 트래픽이 Gateway로 들어와야 함

5편에서 정리했듯이 HTTP 정책은 On-ramp에 따라 적용 여부가 다릅니다.

  • Cloudflare One Client: Traffic and DNS 또는 Traffic only 모드, 또는 Local proxy 모드로 지정한 애플리케이션 트래픽 (DNS only, Posture only 모드는 HTTP 트래픽을 보내지 않음)
  • Proxy endpoint (PAC 파일): 브라우저 트래픽만
  • Cloudflare WAN 네트워크 터널: 사이트 전체 트래픽

기본적으로 Gateway는 포트 80의 HTTP와, TLS Decryption을 켠 경우 포트 443의 HTTPS만 검사합니다. 다른 포트의 HTTP·HTTPS까지 검사하려면 프로토콜 탐지 (protocol detection)를 켜고 모든 포트 검사를 설정해야 합니다. HTTP/3 (QUIC) 트래픽에 HTTP 정책을 적용하려면 UDP용 Gateway 프록시도 켜야 합니다.

2. 사용자 디바이스에 루트 인증서 설치

TLS Decryption, DLP, AV 검사, Access for Infrastructure, Browser Isolation을 사용하려면 사용자 디바이스가 루트 인증서를 신뢰해야 합니다.

방식설명
Cloudflare 생성 인증서 (기본값)Zero Trust 계정마다 고유한 루트 CA를 생성해 Cloudflare 네트워크에 배포. 만료 기간은 5년이 권장됨
사용자 정의 인증서 (Custom certificate)조직이 보유한 루트 CA를 업로드해 사용 (Enterprise)

인증서는 생성 → 활성화 (Cloudflare 네트워크에 배포되어 Available 상태) → 디바이스 설치 → 검사용으로 켜기 (In-Use) 순서로 적용합니다. Available 상태가 되면 Cloudflare One Client가 사용자 디바이스에 인증서를 자동으로 설치할 수 있고, MDM으로 수동 배포할 수도 있습니다. Available 인증서는 여러 개 둘 수 있지만, 검사에 사용되는 In-Use 인증서는 한 번에 하나뿐입니다.

일부 애플리케이션과 개발 도구는 OS 인증서 저장소가 아닌 자체 인증서 저장소를 사용하므로, 해당 애플리케이션에 Cloudflare 인증서를 별도로 추가해야 할 수 있습니다.

3. TLS Decryption 활성화

루트 인증서가 설치된 것을 확인한 뒤, Traffic settings의 Proxy and inspection에서 Inspect HTTPS requests with TLS decryption을 켭니다. 사용자와 Gateway 간 연결은 TLS 1.1, 1.2, 1.3을 지원하며, TLS 1.3에서는 X25519와 ML-KEM768을 결합한 양자 내성 (post-quantum) 하이브리드 키 교환을 지원합니다. FedRAMP처럼 FIPS 140-3 준수가 필요한 환경에서는 FIPS 호환 암호 스위트만 사용하도록 설정할 수 있습니다 (이 경우 TLS 1.2 필요).

복호화할 수 없는 트래픽

다음과 같은 애플리케이션은 Gateway의 TLS Decryption과 호환되지 않습니다.

유형이유
인증서 고정 (Certificate pinning)앱이 특정 인증서만 신뢰하므로 Cloudflare 인증서를 거부. 대부분의 모바일 앱이 해당
자체 서명 인증서 (Self-signed)공인 CA가 서명하지 않은 인증서는 Cloudflare가 신뢰하지 않음
mTLS (상호 TLS)Gateway가 연결을 종료하고 새로 맺으므로 클라이언트 인증서를 오리진에 전달할 수 없어 핸드셰이크 실패
ESNI, ECH (Encrypted Client Hello)SNI가 암호화되어 어떤 HTTP 정책을 적용할지 판단할 수 없음
Chrome 자동 HTTPS 업그레이드HTTP 링크를 HTTPS로 자동 전환하면서 Gateway와의 연결이 끊길 수 있음

호환되지 않는 애플리케이션을 복호화하면 SSL·신뢰 오류가 발생하거나 앱이 로드되지 않습니다. 해결 방법은 다음과 같습니다.

  • Do Not Inspect 정책으로 해당 애플리케이션을 검사 대상에서 제외합니다. Application 선택자에는 인증서를 내장한 것으로 알려진 애플리케이션 목록이 제공됩니다.
  • 지원하는 애플리케이션이라면 해당 앱에 Cloudflare 인증서를 추가합니다.
  • 개인 디바이스처럼 개인 앱 사용이 예상되는 환경에서는 Split Tunnels를 Include 모드로 설정해 회사 대상 트래픽만 검사합니다.
  • ECH 트래픽은 SNI 기반 선택자를 제외한 Network 정책을 적용하거나, 브라우저에서 ECH를 비활성화합니다.

HTTP 정책과의 연계: Do Not Inspect가 먼저

5편에서 본 것처럼 HTTP 정책은 Action 유형에 따라 단계적으로 평가되며, 복호화 여부를 결정하는 Do Not Inspect 정책이 가장 먼저 평가됩니다.

  1. Do Not Inspect: SNI를 기준으로 일치하면 복호화하지 않고 허용하며, 나머지 HTTP 정책을 모두 건너뜁니다.
  2. Isolate: 복호화된 트래픽 중 격리 대상을 원격 브라우저로 보냅니다.
  3. Allow, Block, Do Not Scan 등: URL, 파일, 애플리케이션 조건으로 허용·차단합니다.
  4. 본문 검사: DLP, AV 검사, 파일 샌드박싱을 수행합니다.

이 순서 때문에 다음 사항을 주의해야 합니다.

  • Do Not Inspect로 제외한 트래픽은 로그, 차단, DLP, AV 검사를 모두 할 수 없습니다. 이후에 더 구체적인 Block 정책을 만들어도 적용되지 않습니다. 대신 해당 트래픽에도 Network 정책은 적용할 수 있습니다.
  • Do Not Inspect는 SNI를 기준으로 판단하므로, URL 경로 단위로는 예외를 만들 수 없습니다. 호스트네임이나 애플리케이션 단위로 설계해야 합니다.
  • Do Not Inspect 정책은 꼭 필요한 대상만 좁게 만듭니다. 넓은 범위로 제외하면 해당 트래픽에 대한 가시성이 사라집니다.
  • 예외적으로 Clientless Web Isolation을 통한 트래픽은 Do Not Inspect에 일치하더라도 모두 격리됩니다.

신뢰할 수 없는 인증서 처리

HTTP 정책에서는 오리진이 신뢰할 수 없는 인증서를 사용할 때의 동작 (Untrusted certificate action)도 지정할 수 있습니다.

옵션동작
Error (기본값)Gateway 오류 페이지 표시
Block설정된 차단 페이지 표시
Pass through보안 경고를 건너뛰고 오리진에 연결

Pass through는 사내 테스트 서버처럼 인증서 문제가 알려진 대상에만 제한적으로 사용해야 합니다.

복호화 기반 HTTP 정책 예시

목적정책 예시
인증서 고정 앱 예외 처리Do Not Inspect: Application in Do Not Inspect 대상 애플리케이션
개인 이메일 계정 차단Block: Application = Gmail AND 회사 도메인 계정이 아닌 경우 (테넌트 제어)
관리자 경로만 차단Block: URL matches intranet.company.com/admin AND 사용자 그룹이 admins가 아님
실행 파일 다운로드 제한Block: Download File Types in exe, msi AND 사용자 그룹이 IT가 아님
파일 공유 서비스 업로드 통제Block: Application in 미승인 파일 공유 AND HTTP Method = POST/PUT
민감 데이터 유출 차단Block: DLP Profile in 개인정보, 신용카드 번호 (8편)

단계적 도입 방법

TLS Decryption은 사용자 경험에 직접적인 영향을 주므로 단계적으로 도입하는 것이 안전합니다.

  1. 루트 인증서 배포: MDM이나 Client로 모든 관리 디바이스에 인증서를 먼저 배포하고 신뢰 상태를 확인합니다.
  2. 예외 정책 준비: 인증서 고정 앱, mTLS를 사용하는 사내 시스템에 대한 Do Not Inspect 정책을 미리 만듭니다.
  3. 파일럿 적용: 파일럿 그룹에만 검사를 적용하고, Gateway 로그와 사용자 피드백으로 깨지는 애플리케이션을 찾아 예외를 보완합니다.
  4. 규제·개인정보 검토: 금융, 의료처럼 개인 민감 정보가 오가는 카테고리는 조직의 개인정보 정책과 규제 요구에 따라 검사 제외 여부를 결정합니다.
  5. 전체 확대: 예외 목록이 안정되면 적용 범위를 넓히고, DLP·AV·Browser Isolation 같은 복호화 기반 기능을 차례로 활성화합니다.

마치며

TLS Decryption은 Gateway가 HTTPS 트래픽의 URL, 헤더, 본문을 보고 HTTP 정책, DLP, AV 검사, Browser Isolation을 적용하기 위한 전제 조건입니다. 루트 인증서 배포와 호환되지 않는 애플리케이션에 대한 Do Not Inspect 예외를 먼저 준비하고, Do Not Inspect가 모든 HTTP 정책보다 먼저 평가된다는 점을 고려해 예외를 최소한으로 설계해야 합니다.

다음 글에서는 복호화된 웹 트래픽을 원격 브라우저에서 실행해 디바이스를 격리하는 Browser Isolation의 구조와 적용 시나리오를 살펴봅니다.

태그:
CloudflareCloudflare One가이드

← 블로그 목록으로