託管服務提供者 (MSP) 與多據點物業的 DNS 過濾

針對 MSP 與多據點企業的 DNS 過濾，能在裝置連線前，於雲端根據安全性策略檢查功能變數名稱要求。透過 Purple 進行集中化管理，與 SSIDs、Captive Portals 和分析功能整合在一起，現場完全不需要任何硬體。Purple 支援 Cisco Meraki 和 HPE Aruba 等整合，無須安裝 Agent 即可保護超過 80,000 個以上實體場域的網路環境。

什麼是針對 MSP 與多據點企業的 DNS 過濾？

裝置進行的每一次連線都是從 DNS (Domain Name System) 查詢開始。裝置會要求解析器將 example.com 等名稱轉換為 IP 地址。DNS 過濾（亦稱為防護型 DNS）會在回應前，根據策略檢查該名稱。若該網域存在惡意或不符合策略，解析器就不會提供真實的地址。裝置便永遠無法建立連線，因此不會下載任何內容，也不會載入任何頁面。

對於單一場域來說，這是個非常實用的控制手段。但對於託管服務提供者 (MSP) 或多據點 IT 團隊而言，需求就完全不同了。您需要為數十個或數百個不同客戶所擁有、採用不同硬體與不同規則的網路進行過濾。這帶來了單一場域過濾器通常無法滿足的三項需求：

• 跨租戶策略 (Per-tenant policy)。 租戶是指擁有獨立規則的單一客戶或業務單位。親子飯店集團、連鎖酒吧和一般診所絕不應該共用相同的策略。
• 集中化管理。 您需要從單一入口查看並變更每個租戶的策略，而無需登入各個場域。
• 無需單一場域硬體。 在每個據點運送、上架和修補實體設備，無法在廣大的跨場域架構中有效擴充。

Purple Shield 是 Purple 的防護型 DNS 加值功能，與 SecurePass 和 Verify 並列。過濾功能完全於雲端執行，並與您已為各個客戶管理的 SSIDs（網路名稱）、Captive Portals 和分析功能無縫綁定。Captive Portal 是訪客連線開網前看到的登入頁面。

MSP 過濾與單一場域部署有何不同

單一場域過濾器只有一套策略、一位管理員和一個網路。MSP 託管環境則具備層級架構。您可以為整個託管環境設定規則、依客戶個別覆寫，再依據單一場域內的特定網路進行調整。飯店的訪客網路需要與櫃檯後方的員工網路套用不同的規則。

獨立的 DNS 過濾器通常為每個租戶設定一個子組織來處理此需求，且設定必須與 WiFi 本身分開。這導致您最終必須為每個客戶維護兩套系統：一套處理網路與 Portal，另一套處理解析器。Purple Shield 則省去了第二套系統，因為過濾策略會直接跟隨您已在 Purple 中定義好的網路。

為什麼 DNS 過濾對管理廣大的客戶場域至關重要？

三大壓力促使 MSP 將過濾功能提升至優先議程：照顧責任、威脅暴露以及有限的頻寬。

共享網路上的照顧責任

公共與訪客 WiFi 承擔著明確的合規義務。在英格蘭，學校與學院遵循教育部的過濾與監控標準（參考《 Keeping children safe in education 》）。在美國，《兒童網路保護法》（CIPA）要求接受 E-rate 補助的學校與圖書館進行內容過濾。飯店、咖啡廳和休閒中心若歡迎家庭顧客，一旦兒童存取成人內容，就會面臨商譽風險。英國的 Friendly WiFi 計劃正是為此而生。

當您為 40 個客戶代管 WiFi 時，您就承擔了這些義務的一部分。只要有一個未經過濾的網站，就可能引發您最不希望發生的客戶爭議。

威脅如何入侵不受控的裝置

您無法在訪客的手機上安裝 Agent 軟體，也無法為其安裝修補程式。釣魚連結、惡意軟體下載與指令控制（C2）回連，全都是從 DNS 查詢開始。這使得 DNS 查詢成為您對網路上每台裝置唯一能掌控的切入點。

Shield 會在 DNS 查詢階段標記威脅，在連線完成前阻斷惡意請求。在多個據點的架構下，一項威脅阻斷會同步套用到所有客戶站點。若要了解更廣泛的市場概況，請參閱 Phishing Protection Software: 10 Options for Shared WiFi。

頻寬受限站點的流量管理

許多場所的訪客 WiFi 僅依靠有限的網路頻寬運作：加油站前廣場的 4G 路由器、酒吧的共享線路、車站繁忙的電路。廣告流量與不良網頁內容會排擠正常傳輸。在 DNS 層級過濾廣告與惡意網域，能減少網路資料消耗並提升載入速度。在壅塞的站點，省下的頻寬能直接釋放給訪客真正需要的流量。

防火牆無法涵蓋的盲點

防火牆依然重要，但它的運作層級不同。它是在 DNS 完成解析後才檢查連線。這會在多站點訪客環境中留下四個漏洞：

1. 加密隱藏了目的地。 TLS 1.3 (RFC 8446) 會加密伺服器憑證。Encrypted Client Hello (ECH) 這項 IETF TLS 擴充功能甚至能隱藏伺服器名稱。在沒有解密的情況下，防火牆只能看到 IP 位址，而您無法在訪客裝置上安裝解密憑證。

2. 共享 IP 位址模糊了規則判斷。 內容交付網路（CDN）會在相同的 IP 位址上託管許多網域。若阻斷該 IP，會影響到合規網站；若放行，惡意網域就會趁虛而入。

3. 跨站點規則設定容易產生偏差。 歷經多年建置的多站點環境常混用不同廠商的防火牆與韌體版本。維持 60 套規則設定的一致性是一項繁重的維護工作，只要遺漏一個站點就會形成漏洞。

4. 阻斷時機過晚。 當防火牆採取行動時，裝置已經解析了名稱並嘗試連線。DNS 過濾則可在建立任何連線之前就中止請求。

DNS 過濾無需解密、無需 Agent 軟體，也不需要針對個別站點設定規則即可填補這些漏洞。它不會取代防火牆在網路分段與通訊埠管制上的功能。

DNS 過濾如何在多租戶環境中運作？

每次查詢時會發生什麼情況

1. 訪客連線至客戶的 WiFi，通常是透過 Captive Portal。
2. 裝置請求一個網域，例如點擊社交工程釣魚郵件中的連結。
3. Shield 會根據指派給該網路的策略檢查該網域。
4. 如果網域被允許，裝置會接收到位址並正常連線。
5. 如果被封鎖，查詢就不會傳回真實位址，因此不會建立任何連線。

如何架構多租戶策略

多租戶內容過濾的最佳做法是採用一小套標準策略，而非為每個據點量身打造個別規則集。這種模式適用於旅宿業、零售業和公共部門：

• 安全基準。 在每個網路和每個租戶上封鎖惡意軟體、釣魚網站和其他威脅類別。無人例外。
• 家庭訪客。 安全基準加上成人和不適齡內容過濾。適合家庭飯店、圖書館、休閒中心、學校和醫療照護候診區。
• 成人訪客。 安全基準搭配較寬鬆的內容規則。適合酒吧、深夜場所和商務飯店。
• 員工。 安全基準加上反映各客戶可接受使用策略的規則。

為每個網路指派一個策略，僅在企業有需要時才新增客戶例外情況。飯店的行銷團隊可能需要使用學校會封鎖的社群平台。四個策略加上一份簡短的例外清單，遠比 60 個手動建立的規則集更容易進行稽核。

由於 Shield 是將策略附加至您在 Purple 中執行的網路，因此據點的訪客和員工 SSID 可以套用不同的策略。使用 802.1X（基於埠的網路存取控制標準）的員工網路可保留其身分驗證控制，Shield 則在其之上附加 DNS 層。

從單一儀表板管理所有設備

中央 DNS 策略管理只有在符合您既有的工作流程時才能發揮效益。Shield 與管理各客戶 SSID、Captive Portal 和分析資料的 Purple 平台位於同一個系統中。您不需要切換主控台即可變更過濾器，也不需要維護第二份據點清冊。

這對 MSP 帶來了實用的好處：

• 匯入上線。 在 Purple 中建立新的客戶據點不需要單獨的解析器帳號。
• 變更控制。 變更一次策略即可套用至已指派該策略的每個網路。
• 報表產生。 過濾活動與您已分享的連線分析資料並列，因此單一季度審查即可涵蓋 WiFi 與安全性。

為何不需要寄送任何硬體

Shield 在雲端進行過濾，因此無需為每個據點購買、設定、寄送或更換任何硬體設備。Purple 獨立於硬體之外，可作為雲端覆蓋層（cloud overlay）運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 上。即使客戶資產在收購後混合了多家廠商設備，仍可執行同一套策略。設定方式因廠商而異，請參考 Purple 的支援文件以取得您硬體的相應設定。

Purple 目前已在 80,000 多個實體場所運行，並在 2024 年記錄了 4.4 億次登入（Purple 資料）。

DNS 過濾在真實房產資產中看起來如何？

以下三個情境是根據常見的場域類型組合而成的綜合案例。據點數量和硬體設備皆為典型配置；最終成果則展現了各項變更帶來的營運效益。

情境 1：擁有 14 家餐旅業客戶的 MSP

現況。 一家 MSP 為 14 家餐旅業客戶（跨 60 個據點）營運訪客與員工 WiFi。客戶類型包含獨立飯店、擁有 20 個據點的酒吧集團以及渡假公園。WiFi 與 Captive Portal 已在 Purple 上運行。過濾功能原本採用獨立的 DNS 服務，每個客戶各有一套帳號與據點清單。

執行的變更。 該 MSP 將過濾功能轉移至 Shield，並以四種標準政策取代 14 套客製化規則集。親子飯店與渡假公園採用親子訪客政策；酒吧集團則採用成人訪客政策。有兩家客戶保留了簡短的例外清單。

成果。 跨 60 個據點實現零硬體出貨與零現場拜訪。該 MSP 停用了 14 個獨立的過濾帳號，現在直接透過現有的 Purple 控制台管理所有客戶。規則變更只需編輯四種政策之一，不再需要逐一修改多達 60 個據點的條目。

情境 2：地方議會的圖書館與休閒中心

現況。 一個郡議會為 22 間圖書館和 5 座休閒中心提供公共 WiFi。學童會在放學後使用圖書館網路。經歷兩輪採購後，圖書館採用 HPE Aruba，而休閒中心則使用 Ubiquiti UniFi。IT 團隊僅有三人。

執行的變更。 議會將親子訪客政策套用至所有公共 SSID，並將員工政策套用至員工網路。員工身分驗證維持使用 802.1X 與 WPA3 - Enterprise，這是目前的企業級 WiFi 加密標準。訪客仍透過議會的 Captive Portal 連線。

成果。 所有 27 個據點跨越兩個硬體品牌運行統一的公共政策，完全不需要在任何地方安裝硬體設備。單次編輯即可涵蓋所有 27 個據點。議會向稽核人員展示的是單一政策與單一日誌來源，而非 27 個在地端設定。

情境 3：頻寬有限的 120 家門市零售商

現況。 一家零售商在 120 家門市為顧客提供訪客 WiFi，其中三分之一的門市使用 4G 回傳網路。顧客的瀏覽行為會與門市系統爭奪頻寬。持卡人資料環境已與訪客流量進行網路隔離，使其免受 PCI DSS 規範約束。

執行的變更。 該零售商僅在訪客 SSID 上啟用了 Shield 的威脅防護與廣告攔截功能。首先在 4G 流量最高的 10 家門市進行試點。員工與門市系統網路則維持在各自的獨立區段。

成果。 試點計畫測量了四週內的前後使用量比較，證實了在受限的連線環境下整體資料消耗有所降低。該零售商隨後透過一次變更，將政策擴展至所有 120 家門市，完全無需造訪門市現場。

DNS 過濾如何與您現有的系統搭配運作？

防護型 DNS 只是其中一個層級。它與您可能已經擁有的安全控制措施搭配時效果最佳。

• 網路區隔。 VLAN（虛擬區域網路，將單一實體網路分割為獨立的邏輯網路）可將訪客流量與員工及支付系統隔離。請參閱 如何為訪客和員工設定網路區隔。
• 身份驗證。 搭配 RADIUS（根據中央伺服器驗證憑證的協定）的 802.1X，可決定誰能加入員工網路。SecurePass 搭配 Microsoft Entra ID、Okta 或 Google Workspace 也是如此。Shield 則能在裝置連線後，決定其可存取的目標。
• 防火牆。 您的防火牆仍負責控制網段之間的連接埠、協定與流量。Shield 則會在查詢階段就阻擋已知的惡意目標。
• 隱私法規。 DNS 記錄可能包含 IP 地址與裝置識別碼，GDPR 將其視為個人資料。Purple 完全符合 GDPR 並通過 ISO 27001 認證。

Shield 與 DNSFilter 及 Cisco Umbrella 的比較

DNSFilter 與 WebTitan 主要針對 MSP，而 Cisco Umbrella 則是許多 Cisco 環境的預設選擇。這些產品全都在雲端的 DNS 層進行過濾。差異在於由誰管理、管理內容為何，以及在何處管理。

評估標準	Purple Shield	DNSFilter	Cisco Umbrella
過濾發生的位置	在 Purple 雲端進行 DNS 查詢	在 DNSFilter 雲端進行 DNS 查詢	在 Cisco 雲端進行 DNS 查詢
各據點硬體需求	無	網路過濾無需硬體	DNS 層防護無需硬體
租戶管理	在運作客戶 WiFi 的 Purple 儀表板內	具備子組織的獨立 MSP 主控台	獨立的多組織或 MSP 主控台
與 SSID、Captive Portal 及 WiFi 分析繫結	是，原生整合於 WiFi 平台	否，需設定為獨立的技術堆疊	與 Cisco Meraki 整合，在自己的主控台管理
異地漫遊裝置	專為您運作之 WiFi 上的裝置打造	漫遊用戶端代理程式	Cisco Secure Client 漫遊模組
硬體支援範圍	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks, Fortinet	任何能將 DNS 轉發至其解析器的網路	任何能將 DNS 轉發至其解析器的網路，在 Cisco 環境發揮最深
最適合	客戶 WiFi 運作於 Purple 上的 MSP	保護內部與異地受控端點的 MSP	標準化採用 Cisco 安全性架構的企業

在 Shield 未涉足的領域，其他替代方案非常強大。DNSFilter 與 Cisco Umbrella 皆提供適用於異地受控筆記型電腦的漫遊代理程式。Umbrella 也包含在 Cisco 更廣泛的安全產品組合中。來自 TitanHQ 的 WebTitan 同樣為 MSP 提供多租戶雲端過濾器。如果您的合約涵蓋企業端點無論移動至何處的防護，上述產品之一可能非常適合。

Shield 的優勢更為明確，且對於以 WiFi 為主的 MSP 來說更具競爭力。如果您在 Purple 中管理每個客戶的 SSID、Captive Portal 與分析數據，那麼為每個租戶維護獨立的解析器架構會帶來額外的維護成本。如需詳細資訊，請閱讀 Shield vs DNSFilter: a protective DNS comparison for WiFi operators 與 Shield vs Cisco Umbrella: choosing protective DNS for guest WiFi。

您應該瞭解的 DNS 過濾限制有哪些？

DNS 過濾作用於連線的特定端點，這也決定了它的局限性。

• 加密 DNS 可能繞過過濾。 DNS over HTTPS (DoH, RFC 8484) 與 DNS over TLS (DoT, RFC 7858) 允許裝置選擇自己的解析器。網路控制措施可以減少非託管裝置上的此類情況，但無法完全消除。請參閱 DNS over HTTPS explained: privacy vs public WiFi filtering。
• VPN 會透過通道繞過過濾。 使用個人 VPN 的訪客會在通道內解析名稱。您可以封鎖已知的 VPN 網域，但無法封鎖所有網域。
• 直接 IP 連線會跳過 DNS。 存取硬編碼 IP 地址的惡意軟體絕不會進行 DNS 查詢。您的防火牆可以涵蓋此類情況。
• 它只能識別網域，無法識別內容。 DNS 過濾是允許或封鎖整個網域，而非個別頁面或檔案。
• 分類需要定期檢視。 任何分類清單偶爾都會出現過度封鎖或封鎖不足的情況。請為每個客戶提供指定的聯絡人與申請變更的管道。
• 日誌需要權限管理。 在部署前與每個客戶確認資料留存與存取權限，並記錄於您的資料處理協議中。

下一步您應該怎麼做？

1. 梳理您的租戶。 列出所有客戶、據點與網路，並標註產業類別與法規義務，例如學校、圖書館、醫療機構與特許場所。
2. 草擬標準策略。 從上述四項原則開始，並強制執行安全基準。
3. 在具代表性的據點進行試點。 每個產業類別選擇一個據點，包含一個頻寬受限的據點，並測量實施前後的資料使用量。
4. 按策略部署，而非按據點部署。 為每個客戶的網路指派策略，並在 30 天後檢視例外情況。
5. 提供回報報告。 將過濾活動新增至您現有的 WiFi 檢討報告中。

如果您客戶的 WiFi 尚未在 Purple 上運行，請先造訪 Guest WiFi，然後新增 Purple Shield。如需更多關於跨區域網路安全的資訊，請瀏覽 All guides。

常見問題

我需要在每個客戶據點安裝硬體才能使用 DNS 過濾嗎？

不需要。Shield 是在雲端的 DNS 層進行過濾，因此無需購買、設定或運送任何設備至任何地點。Purple 可以作為雲端覆蓋層，運行於您客戶現有的存取點上，包含 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 與 Fortinet。設定方式因廠商而異，請參考 Purple 針對您場域中各硬體類型的支援文件。

我可以為每個客戶與每個網路設定不同的過濾策略嗎？

是的。Shield 會將過濾策略與您已在 Purple 中執行的網路綁定，因此每個客戶以及站點內的每個 SSID 都可以載入各自的策略。飯店的訪客網路可以封鎖成人內容，而員工網路則能套用客戶的可接受使用規則。比起每個站點都設置訂製規則，採用少數一套標準策略搭配簡短的例外清單，在稽核上會更加容易。

我可以從單一儀表板管理多個站點的內容過濾嗎？

是的。Shield 與管理客戶 SSID、Captive Portal 和分析資料的 Purple 平台在同一個地方進行管理，因此您無需切換主控台即可變更過濾設定。策略變更會套用到指派給該策略的每個網路（跨所有站點）。過濾活動會與您現有的 WiFi 報表並列顯示，因此一次客戶審查就能同時涵蓋連線能力與安全性。

對於 MSP 而言，Shield 與 DNSFilter 相比如何？

Shield 適合客戶 WiFi 已在 Purple 上執行的 MSP；而 DNSFilter 則適合保護網內外託管筆記型電腦的 MSP。兩者都在雲端的 DNS 層進行過濾，無需在每個站點安裝硬體。DNSFilter 作為帶有漫遊代理程式的獨立多租戶主控台運行。Shield 則在 WiFi 平台內部運行，綁定至您已在管理的相同 SSID、Captive Portal 和分析資料。

訪客可以透過 DNS over HTTPS 或 VPN 繞過 DNS 過濾嗎？

是的，有心繞過的訪客確實可以。DNS over HTTPS、DNS over TLS 和個人 VPN 會將查詢傳送到您的解析器之外。網路控制措施可以減少這種情況，例如封鎖已知的 VPN 和公開 DoH 端點，但沒有任何 DNS 過濾器能完全控制未受託管的裝置。請將 DNS 過濾視為使用該網路 DNS 的每台裝置之預設防護，並搭配網路分段與您的防火牆一同使用。

DNS 過濾能否協助學校和圖書館符合過濾要求？

它涵蓋了過濾要素，但僅靠過濾無法滿足完整要求。在英格蘭，教育部 (Department for Education) 的過濾與監控標準要求同時進行過濾與監控，並需指定負責人與定期審查。在美國，CIPA 要求獲得 E-rate 資助的學校和圖書館必須在網際網路安全策略中使用技術保護措施。請將跨站點的一致過濾措施，與您的監控及安全防護流程相結合。

在 GDPR 規範下，DNS 查詢記錄如何處理？

Purple 符合 GDPR 規範，並擁有 ISO 27001 認證。DNS 記錄可能包含 IP 地址與裝置識別碼，GDPR 將其視為個人資料。在上線前請與每位客戶確認保留期、存取權限與用途，並將這些條款記錄在您的資料處理合約中。作為 MSP，您通常會擔任客戶的資料處理者，因此請記錄誰控制每個資產的記錄。

Shield 在多站點資產中如何計價？

Shield 是 Purple 平台的安全性附加功能，與 SecurePass 及 Verify 並列，因此您可以將其新增至已在 Purple 上運作的據點。無需在各據點安裝硬體，因此沒有需要評估的設備、運輸或更換成本。請向 Purple 諮詢基於您的客戶與據點數量的報價，並包含您計劃今年上線的所有據點。