訪客 WiFi RFP 需求：報到登入、安全性與分析的明確規範項目

訪客 WiFi RFP 應在五個領域設定可衡量的需求。入網流程：Captive Portal、同意聲明收集與 WCAG 2.2 無障礙規範。安全性：IEEE 802.1X、RADIUS、Passpoint 與 WPA3。硬體：明確指定支援 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 與 Ubiquiti UniFi。合規性：GDPR、PCI DSS v4.0 與防護型 DNS。分析：可匯出的第一方資料。請根據佐證資料對投標商進行評分。

訪客 WiFi RFP 實際上需要指定哪些內容？

訪客 WiFi RFP 能將鬆散的需求說明（例如「為訪客提供免費 WiFi」）轉化為投標商可以通過或不通過的具體需求。它定義了使用者如何加入、流量如何保護以及平台必須在哪些硬體上運行。它還確定了如何處理個人資料以及您能獲得哪些報表。

內容不完善的 RFP 往往會以相同的方式失敗。它們列出功能而非標準，導致每個投標商都回答「是」，使得所有回覆看起來如出一轍。解決方法是在每一行需求中都附上具體的標準、您期望的佐證資料以及試點測試。

對於擁有多個場域的企業而言，RFP 還能確定合約期內的營運模式。Captive Portal 是裝置在存取網際網路之前看到的網頁。您可以在所有據點運行單一 Captive Portal 和單一同意記錄。另一種選擇是為每個硬體廠商採用不同的設定。日後要解開碎片化的場域架構，其代價遠高於現在直接指定單一架構。

本指南為您提供需求措辭、評分矩陣與試點測試。您可以將其視為可套用於 飯店、零售、醫療照護、鐵路、體育場館與公共部門場域的訪客 WiFi RFP 範本。

在撰寫訪客 WiFi RFP 之前您需要準備什麼？

在擬定第一版草案之前，請先收集以下五項輸入資料。每一項資料都能避免得標後常見的變更需求。

• 各場域的硬體盤點清單。 記錄每個據點的無線基地台（AP）廠商、型號、管理平台與韌體版本。註明每個據點使用的是雲端儀表板還是地端控制器。我們的指南 什麼是 WLC（無線區域網路控制器）？您是否仍然需要它？ 解釋了兩者的差異。
• 按類型劃分的場域清單。 按垂直產業與規模對據點進行分組，因為體育場館大廳與飯店大廳需要不同的入網流程。明確列出每個場域服務的人群：訪客、顧客、乘客、球迷、病患或來賓。
• 資料流向地圖（Data Map）。 確定由誰擔任資料控制者、哪些系統將接收 WiFi 資料以及資料將保留多久。您的資料保護官應在發布 RFP 前核准此內容。
• 您的付款界限。 列出所有接受卡片付款的站點。請注意付款裝置是否與訪客流量共用交換器或電路。這會定義您的 PCI DSS 範圍。
• 成功衡量標準。 對您要報告的數據達成共識，例如登入次數、選擇同意率、回訪者和支援工單。如此投標商就能展示其報告如何產生每項數據。

從一開始就讓 IT、資安、資料保護、行銷和場館營運團隊參與其中。訪客 WiFi 牽涉到這五個團隊。由一個團隊撰寫的要求往往會阻礙另一個團隊。

您該如何逐段撰寫訪客 WiFi RFP 要求？

遵循 RFC 2119 中的慣例，使用「必須 (must)」或「應該 (should)」撰寫各項要求。「必須」是合格與否的門檻。「應該」則會計分。要求投標商提供具體證明來回答每一行：文件、證書、參考站點或實機示範。

報到與強制入口要求

報到是訪客評估您網路的地方，也是建立同意紀錄的地方。這份強制入口 RFP 檢查清單涵蓋了核心要素。

• 登入方式。 平台必須支援電子郵件、社群登入、簡訊和存取碼，並可針對每個場館進行設定。
• 自主選擇同意。 行銷同意必須是單獨且未勾選的選項，絕不能與條款接受捆綁在一起。GDPR 第 7 條要求同意必須是可證明的，且撤回必須與給予一樣容易。
• 無障礙功能。 強制入口必須符合 WCAG 2.2 AA 等級。
• 可靠的入口偵測。 平台應該支援強制入口 API (RFC 8908) 以及 DHCP 強制入口選項 (RFC 8910)。兩者都有助於現代裝置尋找登入頁面而不會陷入重新導向迴圈。
• 回訪者辨識。 iOS 14 及 Android 10 以後版本預設使用隨機 MAC 地址。請詢問投標商如何在不依賴裝置硬體地址的情況下辨識回訪訪客。
• 中央控制。 總部必須集中管理品牌形象、條款和同意字樣，並為每個場館提供在地覆寫功能。

Purple 訪客 WiFi 將自主選擇同意整合至強制入口中，並跨整個物業資產進行集中管理。

驗證、RADIUS 與 Passpoint 要求

RADIUS 是 AP 用來詢問中央伺服器是否允許裝置進入的通訊協定。它定義於 RFC 2865 中。RADIUS 計費定義於 RFC 2866 中，負責記錄會話啟動、停止和資料使用量。針對多場館物業資產，請指定以下內容。

• 具備備援機制的雲端 RADIUS。 如果一個資料中心發生故障，驗證必須保持正常運作。請要求提供架構和 12 個月的量測可用性。
• 加密的 RADIUS 傳輸。 在 RADIUS 跨越公眾網際網路的地方，要求使用 RadSec (RADIUS over TLS，RFC 6614) 或加密通道。
• 動態授權。 平台應該傳送 CoA 訊息 (RFC 5176) 以結束或變更會話，而無需強制重新連線。
• 網路區隔。 訪客流量必須部位於獨立的 VLAN 上，這是一個與員工和支付系統隔離的邏輯網路區段。使用者隔離功能必須防止訪客裝置彼此互連。
• 開放式網路加密。 需要 WPA3，包括 Enhanced Open (機會性無線加密，RFC 8110)。它可以在沒有共享密碼的情況下加密每個連線。
• 視需要使用個別金鑰。 iPSK (身分預共享金鑰) 在共享網路上為每個人或裝置提供專屬的 WiFi 密碼。這適用於長期停留的訪客、參展商和活動工作人員。Purple 可透過 SecurePass 提供此功能。

Passpoint 也稱為 Hotspot 2.0，以 IEEE 802.11u 為基礎。它讓裝置能夠自動尋找並加入網路，無需透過強制入口。身分驗證透過以連接埠為基礎的網路存取控制標準 IEEE 802.1X 運行，因此憑證會保持加密狀態。OpenRoaming 由 Wireless Broadband Alliance 運營，是一個建立在 Passpoint 之上的聯盟。它讓使用者能夠使用現有的身分加入參與計畫的網路。

在第一階段中，將 Passpoint 與 OpenRoaming 指定為「應具備」的需求，並提供估算成本的路線圖。Purple 支援 OpenRoaming，因此再次造訪的訪客可以在您的場地自動連線。

如果 RFP 還包含員工 WiFi，請要求與 Microsoft Entra ID、Okta 及 Google Workspace 整合。這能讓新進、異動與離職人員的權限與網路存取保持同步，無需手動變更密碼。

獨立於硬體廠商的 AP 相容性

「相容於領先的企業級硬體」無法進行評分。請列出您正在運行或可能在合約期間採用的每個平台。然後要求每個平台都必須具備相同的五項能力。

1. 支援外部強制入口。
2. RADIUS 身分驗證與記帳 (Accounting)。
3. 圍牆花園 (Walled garden)：入口網站與社群登入所需的前登入允許功能變數名稱清單。
4. 支援 CoA，或用於終止工作階段且有完整文件紀錄的替代方案。
5. 已發布的整合指南，以及該平台上至少一個上線運行的參考案例。

廠商	RFP 中應具名列出的管理平台	應要求的最低證明文件
Cisco Meraki	Meraki Dashboard	整合指南、上線參考案例、基於您韌體版本的試行驗證
HPE Aruba	HPE Aruba Networking Central 或 Mobility Controller	整合指南、上線參考案例、基於您韌體版本的試行驗證
Ruckus	RUCKUS SmartZone 或 RUCKUS One	整合指南、上線參考案例、基於您韌體版本的試行驗證
Juniper Mist	Juniper Mist cloud	整合指南、上線參考案例、基於您韌體版本的試行驗證
Ubiquiti UniFi	UniFi Network application	整合指南、上線參考案例、基於您韌體版本的試行驗證
Cambium	cnMaestro	整合指南、上線參考案例、基於您韌體版本的試行驗證
Extreme	ExtremeCloud IQ	整合指南、上線參考案例、基於您韌體版本的試行驗證
Fortinet	FortiGate integrated wireless controller	整合指南、上線參考案例、基於您韌體版本的試行驗證
要求每家投標廠商說明其支援的韌體範圍，然後針對您自己的硬體進行測試。Purple 與硬體無關，可在所有 8 個平台上作為雲端重疊層執行，無需拆除並更換設備。為什麼您下次升級 WiFi 不需要新硬體 一文探討了商業案例。關於 Ruckus 物業，請參閱 Ruckus SmartZone 與 RUCKUS One 訪客 WiFi 對比外部強制入口平台。

需要求的 GDPR 條款

訪客 WiFi 會大規模收集個人資料，因此合約必須包含以下條款。

• 符合 GDPR 第 28 條的資料處理協議，涵蓋目的、安全性、次處理者和刪除機制。
• 同意紀錄，顯示每個選擇同意（opt-in）的時間戳記、文字版本與管道，且可依需求匯出。
• 可設定的保留期與自動刪除功能，符合第 5 條第 1 款 (e) 項的儲存限制原則。
• 當事人權利工具，用於尋找、匯出和擦除個人的資料。依據第 12 條第 3 款，您必須在一個月內回覆請求。
• 資料外洩通知，處理者必須在無不當延遲的情況下通報，如第 33 條第 2 款所要求。接著您有 72 小時的時間依據第 33 條第 1 款通報監管機關。
• 國際傳輸。 投標廠商必須說明資料儲存位置，以及在英國或歐洲經濟區（EEA）境外進行任何處理時的傳輸機制。
• 資安證明，符合第 32 條規定，最好具備 ISO 27001 認證。

Purple 已獲得 ISO 27001 認證，並符合 GDPR、CCPA 與 Cyber Essentials 的規範。

需要求的 PCI DSS 條款

訪客 WiFi 絕不應置於您的持卡人資料環境（CDE）內。CDE 涵蓋儲存、處理或傳輸卡片資料的系統。PCI DSS v4.0 允許您透過網路分割來縮減範疇，但您必須證明其有效性。

• 投標廠商必須以書面確認訪客流量絕不會行經 CDE，並提供設計文件。
• 該設計必須支援您的分割滲透測試（依據要求 11.4.5，至少每 12 個月需執行一次）。
• 強制入口上不得輸入任何卡片資料。任何付費存取都必須使用符合 PCI DSS 規範的支付提供商，並提供其合規證明（Attestation of Compliance）。
• 依據要求 11.2.1，您每季針對未授權無線存取點進行的測試，仍須涵蓋訪客區域。

需要求的保護性 DNS 條款

保護性 DNS 可以防止裝置解析已知代管惡意軟體、釣魚網站或命令與控制伺服器的網域。英國國家網路安全中心（NCSC）為公務機關提供保護性 DNS 服務。請指定以下內容。

• 威脅情報來源。 投標廠商必須說明其威脅情報來源以及更新頻率。
• 類別過濾（按場地設定），例如在圖書館和家庭區域封鎖成人內容。
• 品牌化封鎖頁面，告知訪客該網站被封鎖的原因。
• **加密 DNS 策略。**說明服務如何處理可能繞過篩選的 DNS over HTTPS (RFC 8484) 和 DNS over TLS (RFC 7858)。
• 與您的 GDPR 時程一致的日誌保留。與已登入身分連結的 DNS 日誌屬於個人資料。
• 每個場域已攔截威脅的每月報告。

Purple 的安全性增益集包含 SecurePass、Verify 和 Shield。請要求針對上述條款對每一項產品進行示範展示。

分析與整合需求

企業級訪客 WiFi 採購往往低估了分析的價值，但這正是您看到投資回報之處。請指定以下內容。

• **每個場域與整體資產的指標：**不重複訪客、初訪與回訪訪客、停留時間、造訪頻率和尖峰時段。
• 儀表板與排程報告，具備基於角色的存取控制，讓場域經理僅能查看自己的站點。
• 透過 API 或原生連接器與您的 CRM 及行銷平台進行整合。同意狀態必須隨每筆記錄一同傳輸。
• **資料所有權。**您擁有第一方資料。必須隨時提供 CSV 或 JSON 的完整匯出功能，且在合約結束時不得收取額外費用。

Purple WiFi Analytics 可報告每個場域的這些指標，並能與 CRM 及行銷平台整合。

服務水準與認證

• **可用性。**要求具備服務點數抵扣的每月上線時間 SLA。Purple 平台的運作上線時間達 99.999%。
• **支援。**指定服務時間、依嚴重程度區分的回應時間，以及指定的層報聯絡人。
• **認證。**要求 ISO 27001。根據採購政策通知 09/14，處理個人資料的英國中央政府合約需要 Cyber Essentials。
• **規模參考案例。**要求提供符合您規模的參考案例。Purple 在 90 多個國家/地區營運超過 80,000 個即時場域，並於 2024 年處理了 4.4 億次登入（Purple 自有資料）。

需求評分矩陣

領域	需求	優先順序	需要求的證明文件
入置引導	獨立且未預先勾選的行銷同意選項	必須	入口網站螢幕截圖與同意匯出範例
入置引導	WCAG 2.2 AA 強制入口	必須	獨立無障礙功能稽核報告
驗證	具備備援轉移功能的雲端 RADIUS	必須	架構圖與 12 個月的可用性資料
驗證	RadSec 或加密的 RADIUS 通道	必須	設計文件
驗證	Passpoint 與 OpenRoaming	建議	即時參考站點
加密	WPA3 與 Enhanced Open	建議	在您的 AP 上進行先期測試
硬體	針對您運作的每個平台提供指定支援	必須	整合指南與先期測試結果
GDPR	第 28 條 DPA 與保留控制	必須	已簽署的 DPA 與保留設定示範展示
PCI DSS	CDE 之外的訪客流量	聲明	分隔設計與測試支援聲明
保護性 DNS	具備攔截頁面的威脅與類別篩選	公共部門必須，其他領域建議	即時攔截測試與每月報告範例
分析	退出時完整資料匯出	必須	合約條款與範例匯出檔案
服務	包含服務點數的正常執行時間 SLA	必須	SLA 附表

如何確認投標方具備交付能力？

分兩個階段評估：書面審查，然後是試運行。任何未通過的「必須」項目都會在書面階段淘汰該投標方。對其餘的「應當」項目進行加權，以符合您的優先事項。典型的權重分配為：安全性與合規性 30%、上線啟用 20%、硬體 15%、分析 15%、服務 10% 以及商務條件 10%。

在兩個或更多採用不同硬體平台的場域進行為期 30 天的試運行。測試以下各項目並記錄合格或不合格。

• 強制入口在 iOS、Android、Windows 和 macOS 上首次成功顯示。
• 再次造訪的訪客在第二次造訪時獲得識別。
• 同意聲明匯出資料顯示時間戳記與文案版本。
• 刪除請求會將該人員從平台以及您已連線的 CRM 中移除。
• 在模擬的 RADIUS 故障轉移期間，身分驗證仍持續進行。
• CoA 訊息結束工作階段且未重新連線。
• 已知的測試網域被封鎖，並顯示您的品牌頁面。
• 從訪客 VLAN 到支付網路的連線嘗試失敗。

請將輸送量與涵蓋範圍的測試與平台分開處理。WiFi 網際網路須知：運作方式與檢查項目 涵蓋了基本要點。

實務上的應用情境為何？

以下三個情境是根據常見採購模式建置的說明性綜合案例。這些並非客戶案例研究。

擁有兩個硬體平台的 45 家飯店集團

情況。 該集團在 30 家飯店採用 Cisco Meraki，並在 15 家新收購的據點採用 HPE Aruba。每個資產都有自己的強制入口。在 15 家新收購的據點中，行銷同意條款與條款接受捆綁在一起。

做法。 RFP 將這兩個平台列為「必須」要求。它要求統一的入口、單一同意記錄和分開的選擇性同意（opt-ins）。試運行涵蓋每個平台各一家飯店。

結果。 五家投標方中有兩家未通過硬體門檻，因為他們僅支援單一平台。最終獲勝的覆蓋層讓所有 15 個 Aruba 據點保留現有的 AP。上線前，所有 15 個據點均已移除捆綁的同意條款。

納入 PCI DSS 範圍的 120 家零售連鎖門市

情況。 在較舊的門市中，支付終端機與訪客 AP 共用交換器。因此，訪客 WiFi 屬於該連鎖店 PCI DSS 評估範圍的一部分。

做法。 RFP 要求提供文件化的區隔設計，以及對 11.4.5 滲透測試的書面支援。此外也禁止在強制入口上輸入卡號。

結果。 所有 120 家門市均通過了年度區隔測試。訪客 WiFi 移出了 PCI DSS 範圍，從而縮小了評估員必須審查的系統範圍。

擁有 25 間圖書館與休閒中心的市議會

情況。 市議會需要為家庭提供安全的公共 WiFi、Cyber Essentials 以及無障礙登入頁面。

執行的內容。 保護型 DNS 是「必要」項目，配備兒童區域的類別篩選功能與加密 DNS 策略。DNS 記錄保留 90 天，符合地方議會的保存時程表。

結果。 七家競標者中有三家未能通過 WCAG 2.2 審查門檻。在試行階段，有一家入圍競標者的篩選機制被 DNS over HTTPS 繞過，因而失去競標資格。

訪客 WiFi 採購中會出現哪些問題？您該如何解決？

每家競標者都回答「是」

原因： 需求描述的是功能而非標準。解法： 為每一項需求列出 RFC、IEEE 標準或 GDPR 條款，並要求提供證明。

強制入口未出現

原因： 圍牆花園（walled garden）設定不完整，或強制入口偵測能力薄弱。解法： 要求支援 RFC 8908 與 RFC 8910，並在試行期間測試四種作業系統。

訪客人數看起來過高

原因： 隨機 MAC 位址使單一裝置看起來像是多台裝置。解法： 要求基於登入身分進行識別，並要求競標者說明他們如何計算回訪訪客。

同意聲明經不起檢驗

原因： 選擇同意選項與條款捆綁在一起，或沒有顯示文案的記錄。解法： 要求提供獨立且預設未勾選的同意選項，以及具備版本控制的同意記錄。

您無法離開

原因： 沒有資料匯出條款。解法： 要求在退場時可以免費完整匯出 CSV 或 JSON 格式的資料。

合約強制更換新硬體

原因： 廠商與特定 AP 品牌綁定。解法： 訂立硬體中立條款，載明您所運作的每個平台。

費用是多少？您能獲得什麼回饋？

請預算六項成本支出：軟體授權、任何硬體、安裝、網際網路線路、支援以及您自家團隊的時間。您選擇的架構決定了大部分的差異。

作法	硬體成本	多廠商環境	同意與資料	每個場地的變更
現有 AP 上的雲端重疊架構（Purple）	無：在現有 AP 上運作	單一入口涵蓋 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 與 Fortinet	中央同意記錄與您擁有的第一方資料	現有 AP 上的 SSID 與 RADIUS 設定
AP 廠商的內建強制入口	當前平台無成本	每個硬體平台各有獨立的入口	同意與訪客資料分別儲存於各個平台上	每個平台上重複進行設定
全面汰換的託管網路	每個場地皆需新 AP 與授權	整個環境強制使用單一硬體廠商	由提供者的合約條款決定	每個據點皆需安裝新 AP

要求競標者以單一基準報價：在整個合約期間內，每個場地每年固定價格。要求將匯入上線、支援、更新與退場成本分項列出。Purple 針對 Connect、Capture 與 Engage 三種方案提供報價，並提供 SecurePass、Verify 和 Shield 作為安全性加值功能。

效益來自四個方面：您能獲得受法律同意保障的第一方資料；您能查看離峰與尖峰時間及停留時間以規劃人力；您能透過雲端重疊架構節省硬體支出；您只需維護單一平台而非多個系統。Purple 自 2012 年以來已在 80,000 多個實體場域提供此服務。

常見問題

訪客 WiFi 平台可以在我們現有的基地台 (AP) 上運行嗎？

可以。Purple 獨立於硬體，可作為雲端重疊架構運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 及 Fortinet 上。您的 AP 會繼續處理無線電和流量。Purple 則提供強制入口、雲端 RADIUS、同意紀錄和分析。在您的 RFP 中，請列出您運行的每個平台，並要求在定案前於您自己的韌體上進行試行。

我們應該如何在 RFP 中要求廠商對訪客 WiFi 進行報價？

要求在整個合約期內，按每個場域提供固定年度價格，加購項目則單獨列出。要求投標方包含開通導入、支援、軟體更新和離線時的資料匯出，並說明任何硬體成本。Purple 針對 Connect、Capture 與 Engage 三種方案進行報價，並提供 SecurePass、Verify 與 Shield 作為安全性加購項目。這能讓您逐行比較競標方案。

我們的訪客 WiFi 網路是否屬於 PCI DSS 的適用範圍？

只要它與您的持卡人資料環境進行區隔，就不應該屬於適用範圍。PCI DSS v4.0 允許您透過網路區隔來縮小適用範圍，但您必須證明其有效性。需求 11.4.5 要求至少每 12 個月對區隔控制措施進行一次滲透測試。請明確規範訪客流量絕不跨越支付系統，且不得在強制入口上輸入任何卡片資料。

根據 GDPR，誰是訪客 WiFi 資料的資料控制者？

您通常是控制者，而 WiFi 廠商是您的處理者。因此，合約需要一份涵蓋目的、安全性、複處理者、刪除和資料外洩通知的第 28 條資料處理協議。您的 RFP 還應要求提供可匯出的同意紀錄和可設定的保存期限。請新增相關工具，以便在第 12(3) 條規定的 1 個月期限內回覆存取和刪除請求。

我們從第一天起就需要 Passpoint 或 OpenRoaming 嗎？

不需要，但您應該要求提供這兩者的估價藍圖。強制入口仍是首次存取的最佳體驗，可用於擷取同意和第一方資料。隨後，Passpoint 與 OpenRoaming 可讓再次光臨的訪客自動連線，使用加密的 802.1X 驗證，無需登入頁面。Purple 支援 OpenRoaming，因此您可以在日後於同一合約內新增自動連線功能。

防護性 DNS 是否應成為訪客 WiFi 合約的一部分？

是的，對公營部門和家庭場所而言尤為重要。保護性 DNS 可防止裝置連線至與惡意軟體、網路釣魚及命令與控制伺服器相關的網域。它還能針對每個場所套用類別篩選。請將其列為地方議會、圖書館和醫療保健場所的「必備」項目。要求提供品牌專屬的攔截頁面、加密 DNS 原則、每月報告，以及符合您的 GDPR 時程表的記錄保留原則。

更換訪客 WiFi 平台會造成多大的影響？

當新平台以覆蓋層（overlay）型式執行時，更換平台只是每個場所的組態變更，而不是硬體專案。Purple 疊加在現有基礎架構之上，因此您的 AP、線路和電路皆可保留在原位。可在使用不同硬體的兩個場所進行 30 天的試點運行，然後分批推廣。請先從舊平台匯出同意記錄，確保不會遺失任何合法的同意資料。

為什麼不直接使用 AP 廠商平台內建的強制入口？

因為內建的入口網站會將註冊、同意和資料綁定在單一硬體品牌上。在經歷收購和更新週期後，擁有多個場所的企業很少能維持使用單一平台。無論硬體為何，獨立平台能在所有據點保持統一的入口網站、同意記錄和分析檢視。這能保護您的資料，並確保您在未來的每一次硬體更新中都握有談判籌碼。