ComparisonDNS filtering limits
DNS 过滤与安全 Web 网关：何时需要更重型的工具
使用从部署位置到隐私足迹等八项标准，决定您的网络需要 DNS 过滤、安全 Web 网关还是两者兼备。您可以在包括访客 WiFi WiFi 在内的每个网络上部署防护型 DNS，并将网关的作用域限制在必须检查 URL、文件或上传内容的受控设备上。
在无需安装硬件的情况下保护 90 个国家/地区 80,000 多个场所中的非托管 WiFi 设备时，请选择基于 RFC 1035 标准解析阶段的 DNS 过滤。而在使用 Microsoft Entra ID 等平台对托管设备上的完整 URL、下载或上传内容进行检查时，请选择安全 Web 网关。DNS 过滤可在建立连接前阻止恶意目标，而网关则通过代理并解密流量来进行处理。
DNS 过滤与安全 Web 网关：简要回答
答案取决于一个问题：您是需要查看连接内部的内容，还是仅需了解其去向？
DNS 过滤在域名阶段作出决策。它会拒绝解析恶意或违规目标，从而使设备根本无法建立连接。安全 Web 网关 (SWG) 则是位于流量路径中的代理。它可以读取完整的 URL、文件和页面，但前提是必须先解密 TLS。
在访客 WiFi 上，这个问题不言自明。您无法在访客的手机上安装根证书。如果没有该证书，网关在解密流量时就会触发证书错误。DNS 过滤无需安装任何内容即可保护网络上的每台设备。这就是为什么它成为酒店、零售、交通枢纽和活动场所的首选方案。
在处理受监管数据的托管员工笔记本电脑上，网关则物有所值。您需要通过它来检查上传内容、强制执行 URL 路径规则或应用数据防泄漏 (DLP)。DLP 可防止敏感数据泄漏出您的网络。
大多数场所都需要在所有网络上配备防御性 DNS，并且仅在少数托管设备上配备网关（如果确实需要的话）。Purple Shield 可以提供第一部分的功能。它可以独立运行在任何 WiFi 上，也可以与 Purple Access 配合运行，为每个网络和 VLAN 提供相应的策略。有关 DNS 方法的更广泛局限，请参阅我们的 DNS 过滤局限 概述。
我们对比的内容，以及为什么这些标准能够决定选择
我们根据八项标准对这两种方法进行了评分。每项标准都对应 IT 安全经理或场所运营经理在确定过滤范围时所作出的决策。我们结合各方案的公开资料以及实际部署两者的经验得出了相应的功能评价。
部署位置排在首位，因为它决定了其他七项标准。DNS 过滤位于域名解析阶段，即 RFC 1035 中定义的查询过程。每台设备在连接前都会向解析器询问地址。防御性 DNS 解析器会根据威胁情报和类别策略检查域名，然后提供解析结果或予以拒绝。
由于该检查发生在建立任何连接之前，因此它可以捕获防火墙遗漏的威胁。防火墙规则基于 IP 地址和端口。而恶意域名往往在共享云地址之间变动，防火墙无法安全地对其进行拦截。
安全 Web 网关位于连接建立后的内部。流量通过终端代理、代理自动配置 (PAC) 文件或内联设备到达网关。为了读取 HTTPS 流量，网关会终止 TLS，检查内容并重新加密。这种深度检查需要在其检查的每台设备上安装受信任的根证书。
八项标准：
- 位置： 过滤器在连接的哪个位置做出决策。
- 可见性： 过滤器可以看到的内容，从域名到页面内容。
- 未管理设备： 是否覆盖访客和 BYOD（自带设备）流量。
- 部署占用空间： 所需的硬件、代理和证书。
- 性能： 过滤器增加的延迟和带宽消耗。
- 故障应对机制： 服务无法连接时会发生什么。
- 防绕过能力： 设备绕过过滤器的难易程度，例如通过基于 TLS 的 DNS (DoT) 或基于 HTTPS 的 DNS (DoH)。
- 隐私占用空间： 过滤器处理多少个人数据。
在市场上，这两者的界限并不总是绝对清晰。DNSFilter 是一项保护性 DNS 服务，与 Purple Shield 属于同一类别。Cisco Umbrella 销售 DNS 层安全服务，并在其高级套餐中提供完整的安全 Web 网关，因此它跨越了本次对比的两端。在评估任何供应商时，请检查每个套餐所提供的具体层级，而不是仅仅依赖产品名称。
两条泳道对比了在查找时进行拦截的 DNS 过滤路径与解密并检查流量的网关路径。
Connections
- 设备查找域名 to Shield 检查策略
- Shield 检查策略 to 已拦截：未建立连接 (威胁或受拦截类别)
- Shield 检查策略 to 已允许：设备直接连接 (已允许)
- 设备发送流量至代理 to 代理解密 TLS
- 代理解密 TLS to 检查 URL、文件和内容
- 检查 URL、文件和内容 to 重新加密、转发或拦截
DNS 过滤与安全 Web 网关对比如何？
| 评价标准 | Purple Shield（DNS 过滤） | 安全 Web 网关 |
|---|---|---|
| 部署位置 | 在 DNS 解析阶段，任何连接建立之前 | 在流量路径中，连接建立之后 |
| 可见性 | 域名，根据威胁和分类策略进行检查 | TLS 解密后的完整 URL、文件和页面内容 |
| 非托管设备与访客设备 | 无需安装任何软件即可覆盖 | 设备上没有可信证书则无法进行 TLS 检查 |
| 部署占用空间 | 无需新硬件：仅需更改每个网络的 DNS 服务器 | 代理软件、PAC 文件或硬件设备，加上每台设备需要的根证书 |
| 性能 | 每个新域名仅查询一次；广告拦截可降低整体带宽消耗 | 每个 Web 请求都会通过代理 |
| 故障处理机制 | 故障时关闭，确保没有网络在未经过滤的情况下运行 | 故障开路或故障闭路，根据每次部署进行设置和测试 |
| 防绕过能力 | 在防火墙处拦截端口 853 上的 DoT 以及已知的 DoH 解析器 | 拦截绕过代理的直接出站 Web 流量 |
| 隐私记录 | 仅处理域名，不处理具体内容 | 解密内容，因此对员工进行检查需要符合 GDPR DPIA 要求 |
有两行值得仔细研读。在可见性方面，网关优势明显。DNS 过滤器能看到 example.com，但永远看不到该站点上的文件路径。我们在 为什么 DNS 过滤无法看到完整 URL 中解释了原因。在非托管设备方面，DNS 过滤完全胜出，因为访客覆盖不需要证书也不需要代理软件。
其余各行是您可以管理的权衡方案。您可以通过防火墙规则阻止加密 DNS 的绕过行为。在配置合理的云服务上，网关延迟是可以接受的。故障处理机制取决于产品本身，这就是我们明确阐述 Shield 机制的原因：它采用故障闭路模式。
DNS 过滤在哪些场景胜出
访客 WiFi 与非托管设备
WiFi 网络上的每台设备都会使用 DHCP 分配给它的 DNS 服务器。将该服务器指向保护性解析器，每部手机、笔记本电脑、游戏机和智能电视都会受到保护。无需任何人安装任何内容。Captive Portal（网络接入前显示登录页面）保持原样。在规模化场景下，这是过滤访客、居民、乘客和粉丝流量唯一切实可行的方法。
分支机构众多且无需新增硬件
切换到 DNS 过滤是一项配置更改，而不是一个复杂项目。Shield 可以在您现有的 WiFi 网络上运行，包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。
您可以针对每个网络和每个 VLAN 分别设置策略。因此，同一场所的亲子友好的访客网络和员工网络可以运行不同的规则。如果您的员工网络通过基于端口的网络身份验证标准 IEEE 802.1X 按角色分配 VLAN，那么无需代理即可直接应用特定于角色的 DNS 策略。
早期威胁拦截
DNS 会在任何流量产生之前识别访问意图。遭受钓鱼攻击的设备在连接前必须先查找域名，受感染的设备向命令与控制服务器发起呼叫时也是如此。Shield 能在威胁生命周期的更早阶段进行标记，即在建立 Web 连接之前。这段提前量可以决定钓鱼域名是在首次点击之前被拦截，还是在点击之后被拦截。
降低网络负载
广告拦截发生在同一层级。启用广告拦截后，可以减少带宽占用并降低 DNS 查询量。在回传带宽有限的繁忙场所网络中，无需额外投资即可回收这部分流量容量。
保持安全的故障处理
Shield 采用“故障关闭”（fail-closed）机制，因此网络中断绝不会导致过滤功能失效。这一点对访客网络至关重要，因为无论加载什么内容，您都需要承担相应的声誉风险。我们在 DNS 过滤故障开放与故障关闭的对比 中阐述了相关权衡。
更小的隐私保护影响
DNS 过滤器只处理域名，而不处理页面内容。在 GDPR 的规定下，与解密后的浏览会话相比，这属于范围更窄的个人数据集。因此，您的数据处理记录将保持更加简明。
- 241,000每周拦截威胁数St George's Healthcare NHS Trust
- 500M每年用户及登录次数Purple 数据
- 99.999%服务正常运行时间 SLAPurple 数据
- 80,000+遍布 90 个国家的活跃场所Purple 数据
安全 Web 网关的优势领域
请务必明确网关的优势所在。如果您假设 DNS 过滤能够覆盖这些优势，您的安全计划将会出现真正的漏洞。
完整的 URL 和路径控制
某些策略需要应用于域名之下的细分层级。您可能希望允许某个云存储服务，但拦截其中一个共享文件夹；或者允许访问新闻网站，但拦截其评论页面。只有能够查看完整 URL 的代理才能执行此类规则。共享平台是最棘手的情况，因为 DNS 过滤器必须对整个域名进行允许或拦截。
文件与内容检测
安全网关可以扫描下载文件中的恶意软件、拦截特定文件类型并对未知可执行文件进行沙盒化处理。而 DNS 过滤仅能阻止与已知恶意域名的连接。如果是托管在受信任域名上的恶意文件，依然会通过 DNS 过滤。
数据防泄漏
您的员工可能会处理 PCI DSS 范围内的数据或患者记录。如果是这样，您可能需要检查上传的内容是否存在敏感信息。这就需要对流量进行解密，并使用网关或专用 DLP 工具。
离网后的按人策略
网关 Agent 根据从 Microsoft Entra ID、Okta 或 Google Workspace 同步的命名身份来应用策略。该策略会跟随托管笔记本电脑延伸至家庭宽带或酒店 WiFi。Shield 的策略是按网络和 VLAN 设置的，这非常适合场所和固定站点。使用托管设备的远程办公人员可能需要在他们连接的任何地方实施按人策略控制。
应用控制
许多网关可以对指定应用的流量进行解码。例如，它们可以允许员工读取文件共享服务，但阻止上传文件。DNS 过滤可以允许或阻止某个应用的域名，但无法控制应用内部的单个操作。
如果您正在结合风险登记簿评估这些差距，请阅读 DNS 过滤是否足够？，了解与防护性 DNS 协同工作的控制措施。
各自的运行成本是多少？
这两种方法的计费方式不同，因此请比较它们的成本结构，而不是只看表面数字。我们不提供竞争对手的报价。请向各供应商确认最新条款。
| 成本要素 | Purple Shield (DNS 过滤) | 安全 Web 网关 |
|---|---|---|
| 许可依据 | 该类别通常按网络、站点或席位计费 | 该类别通常按席位、设备或吞吐量计费 |
| 硬件 | 无：直接运行在您现有的 WiFi 上 | 云服务无硬件需求；本地代理需要硬件设备 |
| 端点 Agent | 网络内无需安装 | 离网设备和完全检查时需要 |
| 证书 | 无 | 需在每台托管设备上部署和更新根证书 |
| 策略维护 | 按网络和 VLAN 划分的类别、允许及阻止列表 | URL、文件、应用和例外规则 |
| 带宽 | 启用广告拦截后数据使用量更低 | 所有受检流量均通过代理路由 |
| 支持工作量 | 允许请求和类别审查 | 证书错误、固定应用失效和例外申请 |
| 合规工作 | GDPR 规定下的域名日志留存 | 解密内容的 DPIA 以及员工告知通知 |
安全网关的隐形成本在于证书与例外项的管理。采用证书固定（Certificate Pinning）的应用在 TLS 检查下会中断运行，因此每个此类应用都需要配置例外项。出于隐私原因，大多数部署都会对银行和医疗网站予以豁免。每一项豁免都会变成需要有人维护的规则。客户端代理也需要在所有设备集群中保持更新。这些都不是缺陷，而是审视内部流量所付出的代价。
DNS 过滤的运行成本在于策略维护和绕过控制。您需要复核分类决定并处理允许请求。同时，随着新的公共解析器不断出现，您还需要保持防火墙针对加密 DNS 的规则处于最新状态。
从 DNS 过滤与安全网关之间迁移涉及哪些内容？
从代理迁移到访客网络上的 DNS 过滤
这是最常见的迁移方式。团队经常发现访客 WiFi 上的代理除了主机名之外几乎过滤不了其他内容，因为它无法解密访客流量。具体步骤如下：
- 导出您当前的代理分类以及允许和阻止列表。
- 将它们映射到 DNS 分类。URL 路径规则没有对应的 DNS 替代方案，因此需要针对每条规则决定是允许还是阻止整个域名。
- 将每个网络 DHCP 作用域中的 DNS 服务器指向防护性解析器。
- 阻止向其他解析器发送的出站 DNS、端口 853 上的 DoT 以及已知的 DoH 端点。
- 使用真实的访客设备进行测试，然后停用该网络的代理规则集。
Purple Shield 的设置步骤见 Purple Shield 工作原理。加密 DNS 标准包含适用于 DoT 的 RFC 7858 和适用于 DoH 的 RFC 8484。
为托管设备添加网关
这种迁移更为繁重，应当仅针对有此需求的设备限定范围。通过您的移动设备管理（MDM）平台部署根证书。分发客户端代理或 PAC 文件，然后针对固定证书的应用和隐私敏感分类创建例外项。在开始流量检查之前，请完成数据保护影响评估（DPIA）。在底层继续保持 Purple Shield 的运行，因为它仍然覆盖了网关未覆盖的每一台设备。
两者并行运行
在混合场所中，分层结合使用两者是最稳健的设计方案。Purple Shield 能在解析阶段阻止已知的恶意域名，覆盖访客和员工网络。随后网关对托管流量进行深度检查。由于 DNS 预先排除了恶意目的地，到达代理的敌意流量大幅减少。建议保持这两个层的分类策略一致，以便在其中一层被阻止的域名不会在另一层被允许。
如何在 DNS 过滤与安全 Web 网关之间做出抉择
请使用此决策规则：如果您不拥有这些设备，请使用 DNS 过滤。如果您拥有这些设备且必须审查流量内部细节，请仅在这些设备上添加网关。在其他所有场景中，保护性 DNS 都是大小最合适、最得心应手的工具。
哪款工具适合您的网络？
Purple Shield (DNS 过滤)
Fits when
- 访客、居民或乘客自带设备
- 您需要在无需新硬件的情况下保护多个站点
- 您需要针对每个网络和 VLAN 制定策略
- 网络绝对不能因故障而处于未经过滤的状态
Not when
- 您必须对 URL 路径或文件类型强制执行规则
安全 Web 网关
Fits when
- 您管理这些设备并且可以部署根证书
- 您必须检查上传内容以防 DLP 数据泄露或扫描下载内容
- 策略必须随指定员工跟随至任何网络
Not when
- 绝大多数流量来自不受管理的访客设备
两者分层结合
Fits when
- 某个站点既接待访客，又在受管理的员工设备上处理受监管的数据
- 您希望利用 DNS 来减少网关需要检查的流量体积
Not when
- 没有受管理的设备需要内容检查
Our recommendation: 首先在每个网络上部署 Shield，然后仅在必须审查流量内部细节的受管理设备上添加网关。
您的下一步是列出您的网络和 VLAN，并标记哪些网络承载不受管理的设备。这些网络现在就需要使用保护性 DNS。然后参阅 Shield 的工作原理 以进行部署。了解围绕身份、加密和网络切片的分段更广泛控制，请阅读我们的 企业级 WiFi 安全指南。
常见问题解答
运行 DNS 过滤比安全 Web 网关更便宜吗？
通常是的，因为 DNS 过滤不需要硬件、不需要终端 Agent 代理，也不需要证书管理。网关会按席位或设备增加许可证费用、代理维护、根证书更新以及因解密检查而崩溃的应用程序例外规则。请对比总运行成本而非仅对比许可证条目，并与各供应商确认最新的条款。
Purple Shield 是否支持我现有的 WiFi 硬件？
支持。Shield 在 DNS 层运行，因此适用于任何 WiFi，包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。您只需将每个网络的 DNS 指向 Shield，并为每个网络和 VLAN 设置策略即可。它可以独立运行或与 Purple Access 并行运行，现场无需添加任何新硬件。
DNS 过滤可以替代安全 Web 网关吗？
在访客和场馆网络上可以，但在您必须审查流量内部细节的场景下不行。DNS 过滤在任何连接建立之前阻止恶意和不受欢迎的域名，这涵盖了访客的大部分威胁防护和内容过滤需求。但它无法对 URL 路径强制执行规则、无法扫描受信任域名上的文件，也无法为了防止数据泄露而检查上传内容。请为需要这些控制功能的受管理设备保留网关。
我能否同时运行 DNS 过滤和安全 Web 网关？
可以，在混合场所中，这是最稳健的设计方案。Shield 会在 DNS 解析层面过滤每台设备，包括网关无法检查的访客设备。然后，网关会对受管的工作人员设备进行深度检查。由于 DNS 会首先拦截已知恶意域名，到达代理的恶意流量也会随之减少。请保持这两个层级的类别策略一致，确保在一个层级被拦截的域名不会在另一个层级获准通过。
安全 Web 网关是否适用于访客 WiFi？
仅部分适用。如果设备上没有可信根证书，网关在解密 HTTPS 时就会导致证书错误。您无法在访客的手机上安装证书。网关仍可以根据 TLS 握手发送的主机名进行过滤，这与 DNS 过滤的效果接近，但占用的基础架构更少。对于访客 WiFi，防护性 DNS 是切实可行的选择。
如果 DNS 服务中断，过滤会受到什么影响？
使用 Shield 时，过滤功能将保持开启。Shield 采用故障关闭（fail-closed）机制，因此服务中断绝不会导致网络处于无过滤状态。采用故障开启（fail-open）机制的服务会将设备发送至未经过滤的解析器以保持流量通畅，这会导致网络在整个服务中断期间暴露于风险之中。请要求每位供应商书面说明其故障处理行为，并在上线前进行测试。
TLS 检查是否兼容 GDPR？
可以兼容，但相比 DNS 过滤，它需要更严格的管理。解密工作人员流量会处理其通信的具体内容。因此，您需要合法的依据、数据保护影响评估以及向工作人员提供明确通知。大多数部署还会将银行和医疗网站列入豁免。DNS 过滤仅处理域名，涉及的范围更窄，更容易解释合理性并记录备案。
从代理迁移到 DNS 过滤需要付出多少精力？
比大多数团队预期的要少，因为切脑操作只是针对每个网络更改一次 DNS 设置。具体工作集中在三个方面：将代理类别映射到 DNS 类别、决定如何处理没有 DNS 对应项的 URL 路径规则，以及在防火墙端拦截加密 DNS。在废除旧规则集之前，请务必从真实设备上测试每个网络。
Key terms
- DNS 过滤（防护型 DNS）
- 一种解析程序，它利用 RFC 1035 中定义的名称解析，在响应前根据威胁情报和类别策略检查每个查询的域名。它拒绝解析被拦截的域名，因此不会建立任何连接。 当您更改每个网络上由 DHCP 分发的 DNS 服务器时，就会接触到它。它无需安装任何软件即可覆盖访客和 BYOD 设备，这使其成为场所 WiFi WiFi 的默认选择。
- 安全 Web 网关 (SWG)
- 流量路径中的正向代理，负责终止 TLS、检查完整 URL、文件和页面内容，然后重新加密或拦截。流量通过端点 Agent、PAC 文件或串行（inline）硬件设备到达该网关。 在为受控的员工设备划定过滤范围时，您会遇到它。只有在必须查看内部流量的地方，它的成本才物有所值，且它需要在每台被检查的设备上安装根证书。
- TLS 检查
- 解密 HTTPS 会话（由传输层安全性协议指定，TLS 1.3 为 RFC 8446），方法是出示由设备信任的根证书签发的代理证书，并在检查后重新加密。 它是网关无法检查访客手机的原因，也是导致固定应用故障、例外规则以及员工设备上 DPIA GDPR 治理的根源。
- TLS 上 DNS (DoT)
- RFC 7858，在 TCP 端口 853 上的 TLS 会话中传输 DNS 查询，对设备和解析程序之间的查找进行加密。 使用 DoT 连接到其他解析程序的设备会绕过您的 DNS 过滤器。在停用代理之前，请在防火墙上拦截端口 853。
- HTTPS 上 DNS (DoH)
- RFC 8484，将 DNS 查询作为 HTTPS 请求发送到解析程序端点，使其难以与普通 Web 流量区分开来。 硬编码的 DoH 解析程序是常见的绕过手段。随着新的公共解析程序出现，您需要保持已知 DoH 端点的防火墙规则为最新状态。
- 代理自动配置 (PAC) 文件
- 一个 JavaScript 文件，用于告知浏览器每个 URL 应使用哪个代理，与 Agent 和串行硬件设备并列为将流量引导至安全 Web 网关的三种方式之一。 在将网关分发到受控设备时部署它。它对您无法控制的访客设备没有任何作用。
- 数据防泄漏 (DLP)
- 用于检查出站内容（例如上传的文件）中是否包含敏感数据（例如 PCI DSS 适用范围内的支付卡数据或患者记录）并阻止其离开网络的控制措施。 DLP 需要解密流量，因此需要网关或专用 DLP 工具。DNS 过滤无法提供此功能。
- 数据保护影响评估 (DPIA)
- 根据 GDPR（欧盟第 2016/679 号法规）第 35 条要求进行的评估，须在可能导致个人权利和自由面临高风险的处理活动之前完成。 解密员工流量会处理其通信内容，因此在启动 TLS 检查之前，需完成 DPIA 并通知员工。
- IEEE 802.1X
- 基于端口的 IEEE 网络访问控制标准。该标准在授予访问权限之前通过 EAP 针对 RADIUS（远程身份验证拨入用户服务）服务器验证设备，并可以按用户或角色分配 VLAN。 如果您的员工网络通过 802.1X 按角色分配 VLAN，则基于每个 VLAN 的 DNS 策略可在无需代理的情况下为您提供特定于角色的过滤。
- VLAN
- IEEE 802.1Q 定义的虚拟局域网，通过标记以太网帧将一个物理网络分割为独立的逻辑网络。 Shield 支持按网络和按 VLAN 设置策略，因此同一星期的家庭友好型访客网络和员工网络可以运行不同的规则。
- 故障闭合
- 一种故障模式。当过滤服务无法访问时，它会阻止解析，而不是故障开放至未过滤的解析器以维持流量流动。 在访客网络上，您需要承担任何加载内容的声誉风险。Shield 采用故障闭合机制，因此在发生中断期间没有网络会在未经过滤的情况下运行。
- 强制门户
- 在授予网络访问权限之前向设备显示的登录页面，通常用于访客 WiFi，以进行条款接受和身份验证。 将访客过滤迁移到保护性 DNS 可以保留现有的强制门户，因此访客登录体验不会改变。
Worked examples
某场所在其访客 WiFi WiFi 上运行代理，但由于无法解密访客流量，除了主机名之外几乎无法过滤其他内容。如何将该网络迁移到 DNS 过滤？
导出代理类别以及允许和拦截列表，然后将其映射到 DNS 类别。URL 路径规则没有对应的 DNS 等效项，因此需要针对每条规则决定是允许还是拦截整个域名。将每个网络的 DHCP 作用域中的 DNS 服务器指向防护型解析程序。在防火墙处拦截发送至其他解析程序的出站 DNS、端口 853 上的 DNS over TLS 以及已知的 DNS over HTTPS 端点。从真实的访客设备进行测试，然后停用该网络的代理规则集。之所以行之有效，是因为此切换只需按网络变更 DNS，且防护型 DNS 无需安装任何软件即可覆盖所有访客设备。
某场所通过 WiFi WiFi 为访客提供服务，其员工在受控笔记本电脑上处理受监管的数据（例如 PCI DSS 范围内的支付卡数据）。哪种设计最合适？
采用分层架构。首先在每个网络上部署 Shield，以便在 DNS 解析阶段对访客和员工设备进行过滤。然后仅在受控笔记本电脑上添加网关：通过 MDM 平台部署根证书，分发 Agent 或 PAC 文件，并为固定应用（pinned apps）和隐私敏感类别创建例外情况。在开始检查之前完成 DPIA。Shield 会首先过滤已知的恶意域名，从而减少到达代理的有害流量。对齐这两个类别的策略，确保在一个层级被拦截的域名不会在另一个层级被允许。
Frequently asked questions
DNS 过滤的运行成本比安全 Web 网关更低吗？
通常是的，因为 DNS 过滤不需要硬件、终端 Agent 和证书管理。网关会增加按席位或设备计算的许可费用、Agent 维护、根证书更新以及因检查中断的应用的例外规则。DNS 过滤的运行成本在于策略维护和针对加密 DNS 的防火墙规则。请对比总运行成本而非许可明细，并向各供应商确认当前的条款。
Purple Shield 是否兼容我现有的 WiFi 硬件？
是的。Shield 运行在 DNS 层，因此适用于任何 WiFi，包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。您只需将每个网络的 DNS 指向 Shield，并按网络和 VLAN 设置策略。它可以独立运行，也可以与 Purple Access 配合运行，现场无需新增任何硬件。
DNS 过滤可以替代安全 Web 网关吗？
在访客和场所网络中可以替代，但无法满足需要深入查看内部流量的场景。DNS 过滤在建立任何连接之前拦截恶意和不受欢迎的域名，这涵盖了访客的大部分威胁和内容过滤需求。它无法针对 URL 路径实施规则、无法扫描信任域名上的文件，也无法检查上传内容以防数据泄露。对于需要这些控制措施的受管设备，请保留安全网关。
我可以同时运行 DNS 过滤和安全 Web 网关吗？
是的，在混合站点中，这是最稳健的设计。Shield 会在 DNS 解析层过滤每台设备，包括网关无法检查的访客设备。网关则对受管的员工设备进行深度检查。由于 DNS 会优先拦截已知的高危域名，到达代理的恶意流量会有所减少。请确保这两个层级的分类策略保持一致，避免在一个层级被拦截的域名在另一个层级被允许。
安全 Web 网关适用于访客 WiFi 吗？
只能部分实现。如果设备上没有安装可信的根证书，网关在解密 HTTPS 时会导致证书错误。您无法在访客手机上安装证书。网关仍可根据 TLS 握手中发送的主机名进行过滤，这与 DNS 过滤的作用类似，但所需的架构成本更低。对于访客 WiFi，防护性 DNS 是切实可行的选择。
如果 DNS 服务中断，过滤功能会怎样？
使用 Shield，过滤功能将保持开启。Shield 采用故障闭合（fail-closed）机制，因此服务中断绝不会导致网络处于无过滤状态。采用故障开放（fail-open）机制的服务会将设备转向无过滤的解析器以维持流量通畅，这会让网络在整个中断期间暴露于风险之中。请要求每位供应商书面说明其故障处理行为，并在上线前进行测试。
TLS 检查是否兼容 GDPR？
可以兼容，但相比 DNS 过滤需要更严格的管理。解密员工流量会处理其通信的具体内容。因此，您需要合法的依据、数据保护影响评估以及向员工提供明确告知。大多数部署还会豁免银行和医疗类网站。DNS 过滤仅处理域名，涉及的数据范围更小，更容易做出合理解释和记录。
从代理迁移到 DNS 过滤需要多少工作量？
工作量比大多数团队预期的要少，因为切换过程只需对每个网络进行 DNS 变更。工作主要集中在三个方面：将代理分类映射到 DNS 分类、确定如何处理没有 DNS 对应项的 URL 路径规则，以及在防火墙处拦截加密 DNS。在停用旧规则集之前，请在真实设备上测试每个网络。