클라우드형 대 온프레미스형 보안 웹 게이트웨이
- 클라우드 기반 및 온프레미스 보안 웹 게이트웨이는 주로 트래픽이 어디에서 복호화되고 검사되는지에 따라 차이가 있습니다.
- 클라우드 SWG는 원격 사용자와 SaaS에 적합하며, 온프레미스 SWG는 규제 대상 트래픽, 내부 트래픽 및 OT 트래픽에 적합합니다.
- 점점 더 비슷해지는 기능 목록보다, 지연 시간, 주권, 복원력, 그리고 대량 사용 시의 비용 문제가 더 중요합니다.
- 하이브리드형 secure web gateway 는 단일 정책 하에서 각 사용자와 사이트를 최적의 지점에서 검사합니다.
- 공통 정책 엔진 없이 두 모델을 모두 실행하면 사무실 사용자와 원격 사용자 간에 정책 편차가 발생합니다.
온프레미스형 secure web gateway 는 자체 데이터 센터나 지사에서 실행되며 웹 트래픽을 로컬에서 검사하는 물리적 또는 가상 프록시 어플라이언스입니다. 클라우드형 secure web gateway 는 공급업체의 PoP(Point of Presence)에서 동일한 기능을 수행합니다. 현재 많은 조직이 이 두 가지를 모두 필요로 하고 있으며, 이것이 바로 규제 대상 기업에서 하이브리드 SWG가 일반적인 아키텍처로 자리 잡은 이유입니다.
이 기사는 ‘하이브리드 클라우드 보안’ 가이드의 일부입니다.
secure web gateway 의 기능
secure web gateway 는 사용자들과 인터넷 사이에 위치하여, 어디서 실행되든 위협을 차단하고, 허용 가능한 사용 기준을 적용하며, 데이터 손실을 방지합니다.
일반적으로 다음을 제공합니다:
- URL 및 카테고리 필터링
- TLS 복호화 및 검사
- 악성코드 검사, 샌드박싱, 그리고 위험 사이트에 대한 remote browser isolation
- Data loss prevention 파일 업로드 및 양식 제출 시
- 클라우드 애플리케이션 가시성 및 제어
- 조사 및 규정 준수를 위한 기록 보관
NIST SP 800-215는 기존의 경계 보안 개념이 사라짐에 따라 현대 기업 네트워크가 ZTNA, CASB 및 기타 통제 수단과 결합하여 사용하는 점 보안 솔루션 중 하나로 SWG를 꼽고 있다.
클라우드형 대 온프레미스형 SWG: 나란히 비교
클라우드형 SWG와 온프레미스형 SWG의 주요 차이점은 검사가 이루어지는 위치와 이를 실행할 책임이 누구에게 있는지에 있습니다.
| 요인 | 클라우드 SWG | 온프레미스 SWG |
|---|---|---|
| 점검 장소 | 공급업체 접속 지점 | 귀사의 데이터 센터 및 지사 |
| 다음에 가장 적합합니다 | 원격 및 모바일 사용자, SaaS로 직접 유입되는 트래픽 | 사무실, 공장 및 데이터 센터 사용자; 내부 트래픽 |
| 지연 시간 | 가장 가까운 접속 지점까지의 거리에 따라 다릅니다. | 현장 사용자를 위한 최소한의 홉 추가 |
| 복호화된 데이터가 있는 곳 | 공급업체 인프라 | 귀사의 인프라 |
| 로그 위치 | 공급업체가 선정하거나 구성 가능한 지역 | 어디에 보관하든 |
| 외부 연결에 대한 의존성 | 필수 | 지원되는 온프레미스 검사의 경우 필요하지 않으나, 클라우드 기반 서비스의 경우 인터넷 연결이 필요합니다. |
| 용량 계획 | 공급업체의 책임 | 귀하의 책임 |
| 운영 노력 | 하드웨어 관련 작업 부담 감소; 정책 및 예외 처리 권한은 여전히 귀사에 있습니다 | 하드웨어 수명 주기, 패치 적용 및 확장 관리는 귀사가 직접 담당합니다 |
| 비용 모델 | 사용자당 또는 사용량 기준, 사용자 수에 따라 확장됨 | 하드웨어 및 라이선스, 처리량에 따라 확장 가능 |
| 에어갭 네트워크 | 적합하지 않음 | 명시적으로 지원되며 모든 종속성이 해결된 경우에만 |
점검 장소
검사가 이루어지는 위치에 따라 암호 해독된 콘텐츠를 누가 처리할지 결정됩니다.
많은 트래픽 유형의 경우, 적절한 제어 기능과 인증을 갖춘 클라우드 SWG만으로도 요구 사항을 충족할 수 있습니다. 규제 대상 페이로드의 경우, 로컬 검사를 통해 외부 처리를 줄일 수 있지만, 검사 위치를 결정하기 전에 전달되는 서비스, 로깅, 증거, 액세스 및 관련 요구 사항을 평가해야 합니다.
TLS 검사에서 발생하는 위험을 관리하기 위한 NSA 지침에 따르면, TLS 검사는 기업 네트워크 내에서 한 번만 수행하고, 동일한 트래픽을 각각 복호화하는 프록시 체인을 피할 것을 권장합니다. 하이브리드 설계의 경우, 특정 데이터 흐름이 로컬 게이트웨이와 클라우드 게이트웨이 중 한 곳에서만 복호화되도록 해야 하며, 두 곳 모두에서 복호화되어서는 안 됩니다. ‘로컬 대 클라우드 TLS 검사: 배포 시 고려 사항’을 참조하십시오.
지연 시간 및 사용자 경험
지연 시간은 실제 라우팅 경로, 접속 지점(PoP)과의 거리, 게이트웨이 용량 및 검사 부하에 따라 달라집니다.
원격 사용자의 경우, 클라우드 SWG를 활용하면 본사로 연결되는 VPN 백홀을 제거함으로써 사용자 경험을 개선할 수 있습니다. 현장 사용자의 경우, 로컬 검사를 통해 클라우드 경유 경로를 피할 수 있지만, 목적지 및 네트워크 설계에 따라 클라우드 검사가 여전히 적합할 수도 있습니다. 다음 항목에 대한 차이를 측정해 보십시오:
- 음성, 영상, 거래 플랫폼과 같은 실시간 애플리케이션
- 대용량 파일 전송 및 소프트웨어 업데이트
- 공급업체의 가장 가까운 접속 지점에서 멀리 떨어진 사이트
- 엄격한 타이밍 요구 사항이 있는 OT 및 산업용 시스템
정책 제어
두 모델 모두 세분화된 정책을 적용합니다. 진짜 문제는 클라우드 게이트웨이와 온프레미스 게이트웨이가 하나의 정책을 공유하는지 여부입니다.
기존 어플라이언스 시스템을 별도의 클라우드 서비스와 병행하여 운영하는 조직은 대개 두 가지 규칙 세트, 두 가지 예외 사항 세트, 그리고 두 가지 DLP 구성을 유지 관리합니다. 시간이 지남에 따라 사무실에 있는 사용자와 집에 있는 동일한 사용자가 서로 다르게 취급되지만, 감사나 사고가 발생하기 전까지는 아무도 이를 알아차리지 못합니다.
통합 정책 관리 기능을 갖춘 하이브리드 SWG를 사용하면 팀이 규칙을 한 번만 정의해도 모든 게이트웨이에 해당 규칙을 적용할 수 있습니다. 예를 들어, ‘Skyhigh SWG for Hybrid’는 클라우드 콘솔에서 정책을 한 번만 작성하면 온프레미스 및 클라우드 적용 지점 전반에 걸쳐 통합 정책 관리를 지원합니다.
운영 노력
클라우드 SWG는 하드웨어 관련 업무를 줄여주지만, 두 모델 모두에서 정책, 예외 처리 및 인증서 관리는 여전히 귀사 팀의 몫입니다.
클라우드 SWG는 하드웨어 조달, 용량 계획 수립, 어플라이언스 패치 적용 등의 작업을 없애줍니다. 하지만 정책 설계, 예외 처리, 인증서 관리, 사고 분류 등의 작업은 여전히 남아 있습니다. 이러한 작업들은 어떤 모델을 선택하든 귀사 팀의 몫입니다.
온프레미스 SWG는 하드웨어 교체, OS 업그레이드, 트래픽 증가에 따른 확장 등 라이프사이클 관리가 필요합니다. 가상 및 컨테이너형 어플라이언스는 이러한 작업 부담을 일부 줄여줍니다. 벤더 플랫폼 변경은 예상치 못한 운영 비용을 초래할 수 있습니다. 예를 들어, 시만텍 엣지 SWG(구 시만텍 Blue Coat ProxySG) 고객은 SGOS 7.3의 지원 종료와 SGOS 7.4에서 자바 기반 관리 콘솔이 제거되는 상황에 직면해 있습니다. 자세한 내용은Blue Coat 및 ‘ProxySG 지원 종료: 마이그레이션 계획’을 참조하십시오.
회복력
온프레미스 SWG는 외부 연결이 중단되더라도 계속 검사를 수행하는 반면, 클라우드 SWG는 공급업체와 해당 공급업체로의 네트워크 경로에 따라 달라집니다.
클라우드 SWG는 공급업체와의 연결 상태와 공급업체의 가용성에 의존합니다. 대부분의 조직은 원격 사용자의 경우 이를 용인합니다. 그러나 공장, 병원, 트레이딩 플로어 또는 정부 시설의 경우, 서비스 중단 시 웹 검사 기능이 중단되거나 ‘failing open’ 상태가 되는 것은 용납될 수 없습니다. 온프레미스 게이트웨이는 외부 연결이 중단되더라도 로컬에서 웹 트래픽 검사를 계속 수행합니다. 데이터 보호 및 remote browser isolation 와 같이 공급업체 클라우드에 의존하는 서비스는 경로가 복구될 때까지 사용할 수 없습니다. ‘하이브리드 SSE 복원력: 장애 조치 및 복구’를 참조하십시오.
이주 요건
모델 간이든 공급업체 간이든 모든 SWG 마이그레이션에는 다음과 같은 6가지 단계가 포함됩니다:
- 현재의 정책, 예외 사항, 인증 영역 및 ICAP, DLP와 같은 통합 기능을 파악합니다.
- 어떤 사용자와 사이트를 어떤 적용 지점으로 이동시킬지 결정하십시오.
- 트래픽 유도 재설정: 명시적 프록시 또는 PAC 파일, 에이전트, 터널, 브라우저 제어 기능.
- TLS 검사 인증 기관을 재발급하고 배포하십시오.
- 본 시스템으로 전환하기 전에 시범 그룹과 병행하여 운영하십시오.
- 검증된 롤백 계획을 수립한 후 단계적으로 전환하십시오.
“Secure Web Gateway 마이그레이션: 전환 및 롤백 체크리스트”를 참조하십시오.
어떤 모델이 여러분에게 적합할까요?
기능 목록이 아니라 사용자, 애플리케이션 및 규제 대상 데이터가 어디에 있는지를 기준으로 선택하십시오.
대부분의 사용자가 원격으로 근무하고, 대부분의 애플리케이션이 SaaS이며, 암호 해독된 트래픽을 로컬에서 처리해야 한다는 규정이나 계약이 없는 경우에는 주로 클라우드를 선택하십시오.
특정 트래픽에 대해 로컬 처리 또는 서비스 연속성이 필요한 경우, 주로 온프레미스 방식을 선택하십시오. 에어갭(air-gapped) 환경, 기밀 환경 또는 OT 환경의 경우, 제품에 대한 명시적인 지원 여부와 관리, 신원 확인, 업데이트, 라이선싱 및 검사 관련 모든 종속 사항을 확인하십시오.
사무실 근무자와 원격 근무자가 혼재되어 있거나, 규제 대상 데이터와 일반 트래픽이 공존하거나, 클라우드로의 강제 이전 없이 기존 온프레미스 게이트웨이 인프라를 현대화하고자 하는 경우 하이브리드 방식을 선택하십시오. 이는 규제 대상 산업에 속한 대부분의 대기업에 해당됩니다.
하이브리드 secure web gateway
하이브리드 SWG는 온프레미스 어플라이언스와 클라우드 PoP(접속 지점)를 하나의 정책 엔진, 하나의 콘솔, 하나의 로그 세트 아래 통합합니다.
사무실 내 트래픽은 현지에서, 원격 트래픽은 클라우드에서, 그리고 정책이 요구하는 곳에서는 트래픽이 규제됩니다.
Skyhigh Hybrid SSE Mesh는 이 모델의 적용 범위를 웹 게이트웨이를 넘어 확장하여, 동일한 정책 하에 로컬 ZTNA, 보안 브라우저 제어 기능, 클라우드 CASB, DSPM, DLP 및 RBI를 추가합니다.
출처
- NIST. SP 800-215: 안전한 기업 네트워크 환경 구축 지침 (2022년 11월). https://csrc.nist.gov/pubs/sp/800/215/final
- NSA. 전송 계층 보안(TLS) 검사에서 발생하는 위험 관리 (2019년 11월). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- Skyhigh Security. 하이브리드용 Secure Web Gateway . https://www.skyhighsecurity.com/products/secure-web-gateway-for-hybrid.html
- Skyhigh Security. “Skyhigh Security , 2026년 가트너 ‘ Critical Capabilities ’ 보고서에서 ‘ Security Service Edge’ 부문의 ‘고급 SSE 사용 사례’ 1위 선정” (2026년 8월 5일). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- 브로드컴. Edge SWG(ProxySG) 및 Advanced Secure Gateway의 단종 및 제품 수명 주기 (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html