왜 전통적인 네트워크 필터링은 더 이상 충분하지 않을까요? 과거에는 사내 방화벽과 프록시, URL 차단 목록만 잘 운영해도 인터넷 사용을 어느 정도 통제할 수 있었습니다. 하지만 지금의 업무 환경은 클라우드 앱 중심, 원격·하이브리드 근무, 개인 소유/모바일 디바이스 확산으로 빠르게 바뀌었고, “사내 네트워크 경계” 자체가 흐릿해졌습니다. 그 결과, 네트워크 위치(IP/대역) 기반 통제는 다음 같은 구조적 한계를 드러냅니다.
- 사용자가 사무실 밖으로 나가면(재택·출장) 동일한 정책을 강제하기 어렵습니다.
- SaaS와 Web 트래픽이 뒤섞이며, 기존 장비 중심 설계는 우회·예외가 늘어나 운영 복잡도가 커집니다.
- “누가 접근했는지”보다 “어느 네트워크에서 나갔는지”를 기준으로 삼으면, 계정 탈취·내부자 위험에 취약해집니다.
이 변화의 맥락에서 주목받는 해법이 Microsoft Entra Global Secure Access의 클라우드 기반 Secure Web Gateway(SWG) + web content filtering입니다. 핵심은 간단합니다. 인터넷 트래픽을 클라우드로 올려 검사하고, 정책의 중심을 네트워크가 아니라 ‘ID와 컨텍스트’로 옮기는 것입니다.
Web 보안의 중심 이동: 네트워크 경계에서 ID·컨텍스트로
Entra의 접근은 “모든 사용자를 사내망으로 끌어들이는” 방식이 아니라, 사용자가 어디에 있든 일관된 Web 보안 정책을 클라우드에서 적용하는 모델에 가깝습니다. 특히 web content filtering은 다음을 가능하게 합니다.
- 사용자/그룹 기반 정책: 같은 사이트라도 “임직원”과 “학생”에게 다른 허용/차단 정책을 적용
- 조건(컨텍스트) 기반 제어: 접속 위치, 디바이스 상태(관리 디바이스/비관리 디바이스) 등 조건에 따라 정책을 차등 적용
- 카테고리 기반 통제: 개별 URL을 쫓기보다 “Social Networking”, “Gambling”, “Adult” 같은 웹 카테고리 단위로 정책을 설계
즉, Web 접근 제어가 “IP·방화벽 규칙의 연장”이 아니라, Conditional Access와 결합된 제로 트러스트 정책의 일부로 들어옵니다.
Web Secure Web Gateway(SWG)는 어떻게 동작하나: 터널링 + FQDN/카테고리 매칭
Global Secure Access 기반 SWG의 동작을 기술적으로 요약하면 다음 흐름입니다.
클라이언트 터널링으로 인터넷 트래픽을 클라우드로 전달
사용자 디바이스에 Global Secure Access 클라이언트를 설치하고, Internet Access 트래픽 포워딩 프로필을 적용합니다. 그러면 사용자의 Web 트래픽이 Microsoft 클라우드로 터널링되어 보안 검사를 받습니다.FQDN(도메인) 기반으로 트래픽을 식별
필터링의 주요 기준은 FQDN(예:news.example.com) 입니다. 관리자는 특정 도메인 또는 와일드카드(*.example.com)로 허용/차단을 정의할 수 있습니다.Web 카테고리 기반 정책 적용
도메인을 일일이 등록하지 않아도, “소셜 미디어”, “성인”, “도박” 같은 카테고리를 기준으로 한 번에 통제할 수 있습니다. 운영 관점에서 가장 큰 장점은 “룰이 줄고, 정책 의도가 명확해진다”는 점입니다.Conditional Access로 ‘누가/어떤 조건에서’ 접속했는지까지 반영
동일한 Web 요청이라도 사용자, 그룹, 위치, 디바이스 상태에 따라 서로 다른 보안 프로필(=필터 정책)을 적용할 수 있습니다. 네트워크 경계가 아닌 ID와 세션 조건이 정책 스위치가 됩니다.
참고로, 문서 기준 차단 시 사용자 화면은 커스텀 차단 페이지가 아니라 HTTP는 일반 오류, HTTPS는 연결 재설정(Connection Reset)처럼 보일 수 있어 헬프데스크 안내가 필요합니다.
Web 기술 진화가 의미하는 것: “어디서 접속했나”보다 “누가, 무엇에 접속했나”
정리하면, 클라우드 시대의 Web 보안은 더 이상 “사내망에서 나가는 트래픽을 막는 문제”가 아닙니다. 사용자의 업무 방식이 분산된 만큼, 보안도 클라우드에서 일관되게 제공되어야 합니다. Entra Global Secure Access의 SWG와 web content filtering은 이 전환을 상징합니다.
- 네트워크 중심 → ID 중심(Conditional Access)
- URL 목록 중심 → FQDN/카테고리 중심 정책
- 온프레미스 장비 중심 → 클라우드 네이티브 보안 적용
이제 기업이 묻는 질문은 “이 IP 대역에서 나갔나?”가 아니라, “이 사용자가 이 조건에서 이 Web 카테고리에 접근해도 되는가?”로 바뀌고 있습니다.
Web Global Secure Access의 동작 원리: 웹 콘텐츠 필터링의 비밀
사용자의 위치, 디바이스 상태까지 인지하는 ID·컨텍스트 기반 Web 필터링은 어떻게 구현될까요? 핵심은 “트래픽을 클라우드로 모아 검사한다”는 단순한 아이디어를 클라이언트 터널링, FQDN(도메인) 인지, Conditional Access(조건부 액세스)로 정교하게 완성하는 데 있습니다. 아래 흐름만 이해하면, Global Secure Access의 웹 콘텐츠 필터링이 왜 ‘제로 트러스트’ 방식인지 한눈에 정리됩니다.
Web 트래픽이 클라우드로 이동하는 방식: 클라이언트 터널링
Global Secure Access는 사용자 디바이스에 설치된 전용 클라이언트를 통해 Web 트래픽을 Microsoft 클라우드로 터널링(포워딩) 합니다.
- 클라이언트 설치 및 할당: 디바이스에 클라이언트를 배포하고, 조직의 Internet Access 트래픽 포워딩 프로필에 사용자/그룹을 할당합니다.
- 효과: 사용자가 사무실 밖(재택, 출장, 카페)에서 접속해도, Web 요청은 로컬 네트워크가 아니라 클라우드 보안 계층(SWG)을 먼저 통과합니다.
즉, 위치에 상관없이 “정책 집행 지점”을 클라우드로 고정해 일관된 보안을 만들 수 있습니다.
Web 필터링의 핵심 단서: FQDN(도메인) 기반 판별
이 Web 콘텐츠 필터링은 현재 구조상 FQDN(예: news.example.com) 단위로 제어하는 것이 핵심입니다. 클라우드 SWG가 트래픽의 목적지를 식별한 뒤 정책을 적용합니다.
- 도메인(FQDN) 규칙:
*.socialmedia.com처럼 와일드카드로 광범위한 도메인을 한 번에 허용/차단 - 웹 카테고리 규칙: “Social Networking”, “Gambling”, “Adult” 같은 분류 체계로 도메인을 묶어 정책화
정리하면, “URL을 하나씩 막는 방식”이 아니라 도메인과 카테고리 매칭으로 대상을 분류해 통제합니다.
Web 필터링이 깨지는 대표 원인: DoH(HTTPS DNS)와의 충돌
FQDN 기반 제어가 성립하려면, 보안 게이트웨이가 “이 트래픽이 어느 도메인으로 가는지”를 안정적으로 알아야 합니다. 그래서 브라우저의 DNS over HTTPS(DoH, Secure DNS)가 켜져 있으면 문제가 생길 수 있습니다.
- 브라우저가 자체 DoH로 DNS 질의를 암호화해 외부로 보내면,
- SWG가 기대한 방식으로 도메인(FQDN) 정보를 인지하지 못해
- Web 카테고리/도메인 기반 필터링이 정상 동작하지 않을 가능성이 커집니다.
따라서 운영 환경에서는 Chrome/Edge의 DoH 설정을 정책(GPO/MDM)으로 일괄 제어하는 준비가 필요합니다.
Web 정책이 “사람과 상황”을 인지하는 구조: Conditional Access 연동
Global Secure Access가 기존 SWG와 차별화되는 지점은, 필터링을 네트워크(IP/대역) 중심이 아니라 ID 중심으로 강제한다는 점입니다. 이를 가능하게 하는 연결고리가 Entra ID Conditional Access입니다.
- 누가: 사용자/그룹(예: 임직원, 외주, 학생)
- 어디서: 위치(국가, 네트워크 신뢰도 등)
- 어떤 상태로: 디바이스 컴플라이언스, 관리형 여부, 위험도 신호
이 컨텍스트에 따라 “같은 Web 사이트”라도 접근 결과가 달라질 수 있습니다. 예를 들어, 관리형 디바이스에서는 허용하지만 비관리 디바이스에서는 차단 같은 설계가 가능합니다.
Web 차단이 사용자에게 보이는 방식: ‘차단 페이지’가 아니라 오류처럼 보이는 UX
현재 문서 기준으로 차단 UX는 전통적인 “접근이 정책으로 차단되었습니다” 같은 커스텀 페이지가 아니라, 브라우저 오류 형태로 나타날 수 있습니다.
- HTTP 차단: 일반 텍스트 기반 브라우저 에러
- HTTPS 차단:
Connection Reset형태의 오류
이 방식은 보안 관점에서는 단순하지만, 사용자가 원인을 네트워크 장애로 오해해 문의가 늘어날 수 있으므로 사전 안내와 헬프데스크 대응 시나리오가 중요합니다.
Web 콘텐츠 필터링 전체 흐름 한 줄 요약
Global Secure Access는 클라이언트가 Web 트래픽을 클라우드로 터널링하고, 클라우드는 FQDN/카테고리로 대상을 분류한 뒤, Entra ID Conditional Access로 사용자·컨텍스트별 정책을 강제하는 구조로 동작합니다. 이렇게 “경계”가 아니라 “정체성과 조건”을 중심으로 웹 사용을 통제하는 것이 이 기술의 핵심입니다.
Web 정책 설계와 구축: 보안 엔지니어의 완벽 가이드
실제 업무 환경에서 “누가 어떤 Web 사이트에 접근할 수 있는가”를 정책으로 만들고, 이를 Conditional Access로 강제하는 과정이 가장 헷갈립니다. 여기서는 세 단계(트래픽 포워딩 → 필터 정책 → CA 연동)로 나눠, 그대로 따라 하면 구축이 끝나도록 정리합니다.
Web 1단계: Internet Access 트래픽 포워딩(클라이언트 터널링) 구성
Web content filtering은 기본적으로 사용자 트래픽이 Microsoft 클라우드(SWG)로 터널링되어야 동작합니다. 즉, “정책부터 만드는” 것이 아니라 먼저 트래픽 경로를 잡는 것이 우선입니다.
Internet Access 트래픽 포워딩 프로필 활성화
- Global Secure Access 포털에서 Internet Access 트래픽 포워딩 프로필을 켭니다.
- 이 프로필이 사용자의 Web 트래픽을 클라우드로 올립니다(사용자 관점에서는 “인터넷이 느려지거나 막히는 정책 효과”가 여기서부터 나타남).
프로필 할당(사용자/그룹 단위)
- 전사 일괄 적용보다, 보통은 PoC 그룹(예: IT부서/보안팀)부터 시작합니다.
- 이유: 초기에는 오탐/업무 영향도가 발생하기 쉬워, 영향 범위를 통제하는 편이 운영적으로 안전합니다.
Global Secure Access 클라이언트 배포
- Windows 등 지원 디바이스에 클라이언트를 설치합니다.
- 배포 후에는 “정책이 먹는 사용자”가 정확히 클라이언트 적용 대상과 일치하는지(누락/중복)부터 확인하세요.
중요: 브라우저 DNS over HTTPS(DoH) 비활성화
- 이 SWG 필터링은 FQDN(도메인) 인지가 핵심입니다.
- Chrome/Edge의 Secure DNS(DoH)가 켜져 있으면 DNS가 암호화 채널로 빠져나가 도메인 매칭 기반 필터링이 흔들릴 수 있어, 조직 차원에서 정책으로 끄는 구성이 필요합니다(MDM/그룹 정책 등으로 표준화 권장).
