웹 보안이 더 이상 “회사 네트워크 안/밖”의 문제로만 설명되지 않는 시대입니다. 재택·출장·협력사 환경이 일상화되면서, 사용자는 어디서든 인터넷(Web)에 접속하고 데이터는 SaaS로 흐릅니다. 이때 전통적인 경계형 보안(방화벽·온프렘 프록시)은 한 가지 질문에 자주 막힙니다. “지금 이 트래픽의 주체가 누구이며, 어떤 상황(컨텍스트)에서 발생했는가?”
바로 이 지점에서 Microsoft Entra Internet Access(= Global Secure Access의 Internet Access)가 제시하는 해법이 선명해집니다. ID와 컨텍스트 인지가 결합된 Secure Web Gateway(SWG)로 웹 접근 통제를 재정의하기 때문입니다.
Web 보안을 ‘네트워크’가 아니라 ‘ID’로 푸는 방식
Microsoft Entra Internet Access의 핵심은 한 문장으로 정리됩니다.
- 사용자의 인터넷 트래픽을 클라우드로 우회(포워딩)시키고,
- 그 트래픽에 대해 도메인(FQDN) 및 웹 카테고리 기반 필터링을 적용하되,
- 정책 판단의 중심을 Microsoft Entra ID + Conditional Access에 두어
사용자·그룹·디바이스·세션 조건(컨텍스트)에 따라 웹 접근을 제어합니다.
즉, 단순히 “이 URL은 위험하니 막는다”가 아니라,
“이 사용자가, 이 조건에서, 이 Web 카테고리/도메인에 접근하는 것을 허용/차단/모니터링한다”로 정책의 문법이 바뀝니다.
Web Secure Web Gateway(SWG)로서 무엇을 제공하나: FQDN/카테고리 중심의 1차 기능
현재 문서 기준으로 Entra Internet Access의 SWG 기능은 Web Content Filtering을 중심으로 합니다.
- 웹 카테고리 기반 제어: Adult, Ads 같은 카테고리를 기준으로 허용/차단/모니터링 정책 적용
- FQDN 기반 제어:
*.example.com같은 와일드카드 도메인 규칙 지원 - 그리고 이 모든 규칙이 Conditional Access와 연결되어 user-aware, context-aware하게 동작
중요한 포인트는 범위입니다. 이 단계는 “풀 기능 SWG”라기보다, 도메인/카테고리 축의 통제와 ID 결합을 먼저 완성한 모델에 가깝습니다. 다시 말해, URL 경로 단위의 극단적 세분화나 콘텐츠 심층 검사보다 ID 기반 통제의 골격을 클라우드에서 선제적으로 구현한 접근입니다.
Web 트래픽이 실제로 어떻게 제어되는가: Global Secure Access 동작 구조
Entra Internet Access가 효과를 발휘하려면, 사용자의 Web 트래픽이 먼저 Global Secure Access로 포워딩되어야 합니다. 일반적인 흐름은 다음과 같습니다.
- 사용자가 브라우저로 웹 사이트 접속 시도
- Global Secure Access 클라이언트(주로 Windows)가 트래픽을 포착해 클라우드 서비스로 터널링
- 서비스가 DNS 기반 가시성을 통해 요청 대상 FQDN 및 카테고리를 식별
- Security profile + Web content filtering policy를 평가
- 결과에 따라 허용(인터넷으로 포워딩) 또는 차단(차단 응답/페이지)
여기서 운영상 매우 현실적인 제약도 함께 등장합니다. 문서에서 명시하듯, 이 모델은 DNS 질의를 기반으로 FQDN을 파악하는 구조이므로 DNS over HTTPS(DoH) 비활성화가 요구됩니다. 조직은 “DNS 암호화(프라이버시) 강화”와 “Web 필터링 가시성” 사이에서 정책적 선택과 통제가 필요해집니다.
Web 관점에서 ‘기존 한계’를 넘어서는 지점: Conditional Access와의 결합
기존 웹 필터링은 대개 네트워크 장비(프록시/방화벽)의 규칙으로 완성됩니다. 사용자 구분이 되더라도 별도 에이전트나 디렉터리 연동을 덧대는 방식이 많았습니다. Entra Internet Access는 반대로 ID 플랫폼을 중심으로 SWG를 엮습니다.
- “특정 그룹만 Web 카테고리 A는 허용, B는 차단”
- “보안 위험도가 높은 로그인 세션이면 더 강한 필터링 적용”
- “회사 관리 디바이스에서만 특정 도메인 접근 허용”
같은 정책이 Conditional Access의 문법으로 자연스럽게 연결됩니다. 결과적으로 Web 보안이 네트워크 위치 중심에서 ‘누구(Identity) + 어떤 상태(Context)’ 중심으로 이동합니다. 이 변화가 바로, Microsoft Entra Internet Access가 말하는 ID 중심 보안 혁신의 본질입니다.
Web 기술의 심장부: FQDN 기반 Web Content Filtering의 작동 원리
도메인 이름을 기준으로 웹 접근을 제어한다? 말은 간단하지만, 실제로는 클라이언트가 트래픽을 “어디로” 보내고, 서비스가 그 트래픽을 어떤 힌트로 “무슨 사이트인지” 판별하느냐가 성패를 가릅니다. Microsoft Entra Internet Access의 Global Secure Access(Web Content Filtering 기반 SWG)는 바로 이 지점에서 DNS 질의 + 트래픽 포워딩 구조를 중심으로 설계되어 있습니다.
Web 트래픽이 보안 서비스로 들어가는 길: 클라이언트 포워딩 구조
FQDN 기반 필터링이 제대로 동작하려면, 사용자의 Web 트래픽이 먼저 Global Secure Access 클라우드로 “보이게” 들어와야 합니다. 이를 위해 핵심 전제는 두 가지입니다.
- Internet traffic forwarding(트래픽 포워딩 프로필) 활성화
사용자의 인터넷 트래픽을 Global Secure Access로 우회시키는 규칙 세트입니다. 이 프로필이 적용된 사용자/그룹의 트래픽만 SWG 정책 평가 대상이 됩니다. - Global Secure Access 클라이언트 설치(Windows) + 프로필 할당
클라이언트가 로컬에서 트래픽을 획득(acquisition)해 터널링하고, 관리자는 클라이언트 진단 화면에서 실제로 어떤 포워딩 규칙이 적용되는지 확인할 수 있습니다.
정리하면, 이 SWG는 “네트워크 경계 장비에서 막는” 방식이 아니라, 엔드포인트에서 클라우드 보안 서비스로 트래픽을 먼저 태워 보내는 구조로 Web 접근 제어를 구현합니다.
Web 사이트 판별의 핵심: 왜 ‘FQDN’이고, 왜 ‘DNS’인가
이 제품의 1차 기능 범위는 URL 경로(/path) 단위가 아니라, FQDN(예: news.example.com, *.example.com) 단위입니다. 즉 정책도 “특정 도메인/카테고리로 분류되는 사이트에 접속하려는가?”에 초점이 맞춰져 있습니다.
여기서 중요한 포인트는 서비스가 FQDN을 알아내는 방식입니다. 문서 흐름상 이 Web Content Filtering은 DNS 질의를 기반으로 FQDN을 식별하는 전제를 깔고 있으며, 그래서 아래 요구사항이 따라옵니다.
- DNS over HTTPS(DoH) 비활성화 요구
DoH가 켜지면 DNS 질의가 브라우저 내부에서 암호화되어 별도 채널로 나가고, 보안 서비스가 “이 연결이 어떤 FQDN으로 향하는지”를 안정적으로 파악하기 어려워질 수 있습니다.
결국 이 SWG의 FQDN 가시성은 “DNS를 통해 이름을 본다”는 설계와 강하게 연결되어 있고, DoH는 그 가시성을 약화시키는 변수가 됩니다.
즉, 이 구조는 콘텐츠를 깊게 뜯어보는 검사보다 먼저, “연결 대상의 이름(FQDN)을 정확히 아는 것”에 설계의 중심을 둡니다.
Web 정책이 실제로 적용되는 내부 흐름(개념도 수준으로 이해하기)
현장에서 가장 헷갈리는 지점은 “정책이 어디서 평가되고, 어떤 정보로 결정되느냐”입니다. 개념적으로는 다음 순서로 이해하면 깔끔합니다.
- 사용자가 브라우저에서 Web 사이트 접속을 시도합니다.
- 클라이언트가 트래픽 포워딩 프로필에 따라 인터넷 트래픽을 Global Secure Access 서비스로 터널링합니다.
- 서비스는 요청 대상의 FQDN을 식별하고, 해당 FQDN을 웹 카테고리(Adult, Ads 등)와 매핑하거나 관리자가 지정한 FQDN 규칙(와일드카드 포함)과 대조합니다.
- 그리고 “허용/차단”은 단순 네트워크 정책이 아니라, 사용자·그룹·세션 컨텍스트를 포함하는 방식으로 결정됩니다.
이유는 이 SWG 정책이 Security profile로 묶이고, 최종적으로 Entra Conditional Access 세션 제어에서 “이 사용자에게 이 보안 프로필을 적용”하는 형태로 연결되기 때문입니다. - 허용이면 인터넷으로 포워딩되고, 차단이면 브라우저는 차단 응답(일반적인 SWG 차단 경험)을 받습니다.
핵심은 하나입니다. 이 Web 필터링은 “도메인 차단”을 하되, 그 도메인 차단이 ID(누가) + 컨텍스트(어떤 조건에서)라는 조건부 접근의 문법 안으로 들어가 있다는 점입니다.
Web 관점에서의 한계도 구조에서 나온다: URL ‘전체’가 아니라 도메인 ‘이름’ 중심
FQDN 기반이라는 건 장점이자 한계입니다.
- 장점: 빠르고 단순하게 “이 도메인/카테고리는 업무상 불필요” 같은 정책을 강제하기 좋습니다.
- 한계:
example.com/safe는 허용하고example.com/risky는 차단처럼 경로 단위의 정교한 제어는 현재 모델만으로는 어렵습니다(기능 범위가 FQDN/카테고리 중심이기 때문).
결국 이 SWG의 ‘심장부’는 클라이언트 포워딩으로 트래픽을 한곳에 모으고, DNS 기반으로 FQDN을 식별해, ID/컨텍스트 기반 정책으로 Web 접근을 결정하는 흐름입니다. 이 구조를 이해하면, 도입 시 DoH 정책·클라이언트 배포·Conditional Access 설계를 왜 함께 고민해야 하는지도 자연스럽게 연결됩니다.
Web 정책을 단숨에 완성하는 구성 흐름: 포털 설정부터 Conditional Access까지
사용자별 맞춤형 웹 필터링 정책은 어떻게 실제로 구성되어 적용될까요? 핵심은 “필터링 정책(Web content filtering) → 보안 프로필(Security profile) → Conditional Access 세션 제어”를 한 줄로 연결하는 것입니다. 이 연결만 이해하면, 복잡해 보이던 Web 접근 제어가 의외로 간단해집니다.
Web 트래픽 우회(포워딩)부터 시작: 정책이 적용될 ‘경로’를 먼저 만든다
아무리 정교한 필터링 정책을 만들어도, 사용자 트래픽이 그 정책 엔진(Global Secure Access)으로 들어오지 않으면 작동하지 않습니다. 그래서 첫 단계는 늘 Internet Access 트래픽 포워딩 프로필 활성화입니다.
- 관리 포털에서 Global Secure Access → Secure → Internet Access 트래픽 포워딩 프로필로 이동
- 인터넷 트래픽 포워딩을 활성화하고, 대상 사용자/그룹을 할당
- Windows 환경이라면 Global Secure Access 클라이언트를 배포하고, 사용자가 해당 포워딩 프로필에 포함되어 있어야 합니다.
- 클라이언트의 Advanced Diagnostics → Forwarding profile에서 규칙 적용 여부를 확인할 수 있습니다.
기술적으로는 이 단계가 “사용자의 Web 트래픽이 로컬에서 바로 인터넷으로 나가지 않고, 터널링되어 클라우드 SWG로 우회”되도록 만드는 작업입니다. 이후의 모든 정책은 이 경로 위에서 평가됩니다.
Web Content Filtering Policy 만들기: 카테고리/도메인(FQDN)로 룰을 정의한다
다음은 실제 차단/허용 기준을 만드는 단계입니다.
- 경로: Global Secure Access → Secure → Web content filtering policy
Create policy로 정책을 생성한 뒤Add rule에서 룰을 추가- Web category 기반(예: Adult, Ads 등)으로 제어하거나
- FQDN 기반(예:
*.example.com)으로 지정 차단/허용을 구성할 수 있습니다.
여기서 중요한 포인트는 현재 기능 초점이 URL 경로 단위가 아니라 FQDN(도메인)과 카테고리 중심이라는 점입니다. 즉, “특정 사이트의 일부 페이지만 차단” 같은 정교한 URL 패턴보다는, “이 도메인은 허용/차단”, “이 카테고리는 차단”처럼 1차 관문을 빠르게 세우는 모델에 가깝습니다.
Web 정책을 ‘묶어서’ 재사용하는 Security Profile: 운영이 쉬워지는 이유
정책을 만든 다음 바로 Conditional Access에 붙이지 않고, 중간에 Security profile이라는 레이어가 한 번 더 등장합니다. 이게 운영 난이도를 크게 낮춥니다.
- 경로: Global Secure Access → Secure → Security profiles
Create profile에서 프로필을 만든 뒤Link a policy→Existing policy로 앞서 만든 Web content filtering policy를 연결
Security profile은 “이 사용자는 어떤 Web 필터링 세트를 적용받는다”를 정의하는 묶음(패키지) 단위로 이해하면 쉽습니다. 조직이 커질수록 정책은 늘어나는데, 이 구조 덕분에 Conditional Access에서는 “세부 룰”이 아니라 “프로필”만 선택하면 됩니다.
Conditional Access로 Web 세션에 ‘강제 적용’: 사용자·컨텍스트 인지의 핵심 연결고리
마지막 단계에서 비로소, 이 Web 필터링이 ID 기반으로 강제됩니다.
- 경로: Entra ID → Conditional Access
- 새 정책 생성 후
- 대상: 특정 사용자/그룹
Target resources: All internet resources with Global Secure AccessSession설정에서 Use Global Secure Access security profile 선택- 앞에서 만든 Security profile을 지정
- 정책을
On으로 활성화
이 구성이 “연동의 비밀”인 이유는 간단합니다. Web 필터링이 단지 네트워크 장비 룰이 아니라, Conditional Access의 세션 제어로 들어가면서 다음이 가능해지기 때문입니다.
- 사용자/그룹별로 다른 Web 정책 적용(예: 임원/개발/인턴 분리)
- 로그인 상태와 조건에 따라 정책을 다르게 적용(컨텍스트 인지)
- 결과적으로 “누가(사용자) 어떤 조건에서(세션/컨텍스트) 어떤 Web에 접근할 수 있는지”를 한 곳에서 통제
Web 필터링이 FQDN에 의존하는 구조라면: DoH 비활성화가 왜 필요할까?
운영 단계에서 자주 마주치는 함정이 DNS over HTTPS(DoH)입니다. 이 SWG의 필터링이 FQDN 식별(도메인 기준 판단)에 기대는 만큼, 문서에서도 DoH를 비활성화해야 트래픽을 정상적으로 터널링하고 정책을 적용할 수 있다고 안내합니다.
정리하면:
- Web 접근 제어는 “어떤 도메인으로 가는지”를 알아야 평가할 수 있고
- DoH가 이를 가리면(가시성이 줄면) 도메인 기반 정책의 정확도가 떨어질 수 있어
- 조직은 브라우저/OS 정책으로 DoH 통제를 함께 설계해야 합니다.
이 4단계(포워딩 → Web 정책 → Security profile → Conditional Access)만 잡으면, 사용자별 맞춤 Web 필터링이 정책 설계부터 실제 적용까지 끊기지 않고 이어집니다. 복잡한 룰을 많이 만드는 것보다, “정책이 적용되는 경로와 연결 구조”를 먼저 단단히 만드는 것이 성공의 지름길입니다.
Web 기반 기존 솔루션과 무엇이 다를까? Microsoft Entra만의 강력한 차별점
Fortinet이나 Cisco 같은 전통적인 Web 필터링 솔루션은 오랫동안 강력한 카테고리 분류, URL 규칙, 프록시/방화벽 중심의 정책 집행으로 표준처럼 자리 잡아왔습니다. 그런데 Microsoft Entra Internet Access(Global Secure Access)는 같은 “차단/허용”을 하더라도 출발점이 다릅니다. 핵심은 네트워크 경계가 아니라 ‘ID(사용자)와 세션 컨텍스트’에서 정책이 시작되는 클라우드 네이티브 SWG라는 점입니다.
Web 관점의 차이 1: “장비/경계”가 아니라 “ID·세션”에서 시작되는 정책
기존 방식은 대체로 다음 흐름에 가깝습니다.
- 사내/지사 경계(방화벽, 프록시)에서 Web 트래픽을 모아 검사
- IP, 서브넷, 장비 정책(혹은 제한적인 사용자 매핑)을 기준으로 룰 적용
- 원격 사용자는 VPN으로 경계 안으로 “들여보낸 뒤” 같은 정책을 적용
반면 Entra Internet Access는 Entra ID + Conditional Access를 통해 정책이 사용자/그룹/리스크/세션 조건에 직접 연결됩니다.
- “누가(사용자/그룹)”
- “어떤 상태로(디바이스/세션 컨텍스트)”
- “어떤 인터넷 리소스에 접근할 때(Internet resources with Global Secure Access)”
- “어떤 Web 콘텐츠 정책(Security profile)을 적용할지”
가 하나의 흐름으로 묶입니다. 결과적으로, 정책의 중심축이 네트워크 토폴로지에서 ID로 이동합니다. 하이브리드/원격이 기본이 된 환경에서 운영 모델 자체가 달라집니다.
Web 관점의 차이 2: 클라우드 네이티브 “트래픽 우회(포워딩)”로 어디서든 동일한 집행
Fortinet/Cisco 계열은 매우 성숙한 기능을 제공하지만, 일관된 Web 통제를 위해서는 보통 다음 중 하나가 필요합니다.
- 지사/사내로 트래픽 백홀(backhaul)
- VPN 상시 연결
- 지점별 장비/정책 동기화
- 원격 사용자를 위한 별도 프록시/클라이언트 전략
Entra Internet Access는 Global Secure Access 클라이언트 + Internet traffic forwarding 프로필로 사용자 트래픽을 클라우드 서비스로 직접 포워딩해 정책을 집행합니다. 즉, 사용자가 집이든 공용 Wi‑Fi든 “정책 집행 지점”이 조직 경계가 아니라 Microsoft의 보안 서비스 레이어로 고정됩니다.
이 구조의 실무적 이점은 분명합니다.
- 정책 적용 범위가 네트워크 위치 변화에 덜 흔들림
- 원격 사용자도 동일한 Web 카테고리/도메인 정책을 동일한 방식으로 적용
- 중앙에서 정책을 관리하고, Conditional Access로 대상(사용자/그룹)을 정교하게 조정
Web 관점의 차이 3: “정교한 URL 검사”보다 “FQDN·카테고리 + 컨텍스트”에 집중한 설계
전통 솔루션은 URL 경로 단위 제어, 다양한 콘텐츠 검사, 세밀한 예외 처리 등 기능 깊이가 강점인 경우가 많습니다. Entra Internet Access의 현재 Web 필터링은 문서 기준으로 FQDN(도메인) 및 Web 카테고리 기반에 초점이 맞춰져 있습니다.
- Web 카테고리 기반 허용/차단
*.example.com같은 FQDN 와일드카드 기반 필터링- 사용자·그룹·디바이스 컨텍스트와 결합되는 정책 모델
이 차이는 “기능이 부족하다”로만 보기 어렵습니다. Microsoft가 우선 완성하려는 것은 ID와 보안 정책을 인터넷 트래픽 집행에 직결시키는 구조입니다. 즉, 기존 SWG가 “더 깊은 검사”에 무게 중심이 있었다면, Entra는 “누가/언제/어떤 조건에서”라는 정책의 맥락(Context)을 먼저 강하게 가져가는 방향입니다.
Web 관점의 차이 4: DNS 가시성을 전제로 한 정책—DoH 요구사항이 의미하는 것
Entra Internet Access의 Web 필터링이 FQDN 식별에 기반하는 만큼, 문서에서는 DNS over HTTPS(DoH) 비활성화를 요구합니다. 이는 운영 관점에서 중요한 차별점이자 고려사항입니다.
- 장점: DNS 기반으로 FQDN을 안정적으로 파악해 카테고리/FQDN 정책을 일관되게 집행
- 과제: 브라우저/OS가 기본으로 DoH를 강화하는 흐름과 충돌할 수 있어, 조직 차원의 DNS 정책/통제가 필요
즉, Entra의 방식은 “Web 제어를 ID 기반으로 단순화”하는 대신, DNS 가시성 확보를 전제 조건으로 두는 아키텍처적 선택이 드러납니다.
정리하면, Fortinet·Cisco가 네트워크 경계 중심의 강력하고 깊은 Web 통제를 발전시켜 왔다면, Microsoft Entra Internet Access는 ID·Conditional Access와 결합된 클라우드 네이티브 SWG 경험을 전면에 내세웁니다. 같은 Web 필터링이라도, “어디에 장비를 두고 어떻게 우회시키는가”가 아니라 “누구의 세션에 어떤 정책을 걸 것인가”로 대화의 중심이 바뀌는 것이 가장 큰 변화입니다.
Web 한계와 미래: 지금의 제약을 넘어 진화할 Entra Internet Access
DNS over HTTPS(DoH)를 꺼야 하고, URL을 “도메인(FQDN)” 수준에서만 다룬다는 점은 분명 현재 버전의 제약입니다. 하지만 이 한계는 곧 “어디까지가 지금 가능한 통제이고, 어디부터가 다음 단계의 혁신인가”를 보여주는 로드맵이기도 합니다. 지금의 경계선을 정확히 이해하면, Entra Internet Access가 앞으로 어떤 방향으로 Web 보안 아키텍처를 확장할지 더 선명해집니다.
Web 현재 한계: FQDN 중심 SWG가 갖는 구조적 제약
Web 1) DoH 비활성화 요구: 가시성(보안) vs 프라이버시(암호화)의 충돌
Entra Internet Access의 Web Content Filtering은 DNS 질의를 바탕으로 FQDN(도메인)을 식별해 정책을 적용하는 설계입니다. 따라서 브라우저/OS에서 DoH가 활성화되면, DNS가 HTTPS로 암호화되어 서비스가 도메인 가시성을 확보하기 어려워지고 필터링 정확도가 떨어질 수 있어 DoH 비활성화가 요구됩니다.
기술적으로 보면 이는 다음 의미를 갖습니다.
- 정책 판정의 전제가 DNS 가시성에 있음
즉, “어떤 Web 목적지로 가는지”를 DNS에서 알아내는 방식이 핵심 축입니다. - 운영 측면의 파편화 위험
사용자가 브라우저별로 DoH 설정을 바꾸거나, OS 업데이트로 기본값이 바뀌면 정책 우회/오탐 가능성이 생깁니다. - 보안 철학의 트레이드오프
조직은 “DNS 암호화로 얻는 프라이버시/무결성”과 “보안 게이트웨이 가시성” 사이에서 기준을 정해야 합니다.
Web 2) 제한적인 URL 세부 검사: ‘도메인’은 막아도 ‘경로’는 구분이 어려움
현재 범위는 카테고리 및 FQDN 기반 필터링에 집중되어 있습니다. 이는 다음과 같은 실무적 한계를 만듭니다.
- 같은 도메인 내 서비스 경로를 구분하기 어렵다
예:example.com/login은 허용하지만example.com/upload는 차단 같은 세밀한 통제가 제한적입니다. - 콘텐츠 기반 판정(파일/본문/위험 징후)까지는 도달하지 못함
전통적인 “풀 SWG”가 제공하는 심층 검사(예: HTTPS 트래픽 분석, 콘텐츠 정책)와는 거리가 있습니다. - 예외 처리(화이트리스트)가 늘어날 수 있음
도메인 단위로만 다루면 업무에 필요한 일부 기능만 열고 싶을 때, 결과적으로 도메인을 통째로 허용하는 선택을 하게 되어 보안 강도가 낮아질 수 있습니다.
Web 3) 클라이언트/포워딩 의존성: ‘정책’은 있어도 ‘경로’가 확보돼야 적용됨
이 모델은 사용자의 Web 트래픽이 Global Secure Access로 포워딩되어야만 정책이 동작합니다. 따라서 다음이 관건입니다.
- 클라이언트 배포/상태 관리(특히 Windows 중심 운영)
- 사용자가 포워딩 프로필에 정확히 할당되는지 검증
- 진단(Forwarding profile) 기반의 운영 프로세스 정착
Web 미래 확장: “ID 중심 SWG”가 다음 단계로 진화할 가능성
현재의 제약은 “첫 번째 SWG 기능으로 무엇을 먼저 완성했는가”를 보여줍니다. 즉, Microsoft는 우선 Entra ID + Conditional Access와 결합된 ID/컨텍스트 기반 Web 제어라는 뼈대를 만든 뒤, 기능을 확장해 나갈 가능성이 큽니다.
Web 1) 더 깊은 URL·애플리케이션 단위 제어로의 확장
향후에는 다음과 같은 고도화가 기대됩니다.
- URL 경로/쿼리 기반의 세분화 정책(예: 특정 업로드 엔드포인트 차단)
- 애플리케이션/행위 기반 통제(예: “웹메일 카테고리”가 아니라 “첨부 업로드” 행위 제한)
- 카테고리와 FQDN의 장점은 유지하면서도, “정밀도”를 끌어올리는 방향
Web 2) TLS(HTTPS) 가시성 강화 옵션과 ‘검사 수준 선택’ 모델
기업 환경에서 Web 트래픽 대부분은 HTTPS입니다. 따라서 실질적인 보안 강화를 위해서는 다음 선택지가 중요해질 수 있습니다.
- 조직이 선택 가능한 검사 수준(inspection levels)
예: 기본은 도메인 기반, 필요 시 특정 그룹/고위험 세션에만 더 강한 검사 적용 - 리스크 기반 적응형 정책
Conditional Access의 신호(사용자 위험/디바이스 상태/위치 등)를 활용해 “평소엔 완화, 위험 시 강화” 같은 정책 모델이 자연스러워집니다.
Web 3) DoH/가시성 문제의 완화: ‘암호화 유지’와 ‘정책 집행’의 공존
DoH 비활성화 요구는 장기적으로 완화될 여지가 큽니다. 가능한 방향은 다음과 같습니다.
- 엔드포인트/브라우저 수준 제어와의 더 정교한 결합
“무조건 DoH OFF”가 아니라, 관리형 디바이스에서 정책 준수 방식으로 DNS 경로를 통제하는 형태 - 가시성 확보 메커니즘의 다변화
DNS만이 아니라 다른 신호(세션/연결 메타데이터 등)와 결합해 Web 목적지 식별 정확도를 높이는 방향
Web 4) 플랫폼 확대와 SSE 생태계 통합
실무에서는 OS/디바이스가 다양합니다. 따라서 다음 확장은 보안 운영의 현실성과 직결됩니다.
- macOS/모바일 등 클라이언트 범위 확대
- Defender, Purview 등과의 연계 강화(데이터 보호, 위협 탐지, 정책 일원화)
- 결과적으로 “Web 접속 제어”가 단독 기능이 아니라 ID·엔드포인트·데이터 거버넌스와 결합된 통합 정책으로 진화
Web 정리: ‘지금의 한계’는 ‘다음의 확장’을 예고한다
현재 Entra Internet Access의 Web Content Filtering은 FQDN/카테고리 중심이고, DoH 비활성화 같은 현실적인 제약도 있습니다. 하지만 그 대신, Conditional Access와 결합된 ID 중심 제어라는 강력한 기반을 이미 확보했습니다. 앞으로 URL 세분화, HTTPS 가시성 옵션, 플랫폼 확대가 더해진다면, “인터넷은 네트워크가 아니라 ID로 통제한다”는 방향이 Web 보안의 표준으로 자리 잡을 가능성이 큽니다.
