访客 WiFi RFP 需求：如何在入网、安全和分析方面提出具体要求

访客 WiFi RFP 应在五个方面设定可衡量的要求。接入入组：强制门户、同意收集和 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 还会确定您在合同期内的运营模式。强制门户是设备在获取互联网访问权限之前看到的网页。您可以在所有场所运行统一的强制门户和同意记录。另一种选择是为每个硬件厂商使用不同的设置。日后解耦零碎的设施所付出的成本，远高于现在指定统一方案的成本。

本指南为您提供需求表述、评分矩阵和试点测试。您可以将其用作访客 WiFi RFP 模板，并适用于 酒店、零售、医疗保健、列车、体育场馆和公共部门场所。

在撰写访客 WiFi RFP 之前需要准备什么？

在起草初稿之前，请收集以下五项输入信息。每一项都可以避免中标后常见的变更申请。

• 每个场所的硬件清单。 记录每个场所的无线接入点 (AP) 厂商、型号、管理平台和固件。注明每个场所使用的是云端仪表板还是本地控制器。我们的指南 什么是 WLC（无线局域网控制器）？您是否还需要它？ 解释了两者之间的区别。
• 按类型划分的场所列表。 按行业和规模对场所进行分组，因为体育场馆大厅和酒店大堂需要不同的接入入组方式。明确每个场所服务的人群：访客、购物者、乘客、球迷、患者或游客。
• 数据流转图。 确定谁担任数据控制者，哪些系统将接收 WiFi 数据，以及您将保留数据多久。您的数据保护官应在 RFP 发布前签署确认此项。
• 您的支付边界。 列出所有接受刷卡支付的站点。注明支付设备是否与访客流量共享交换机或线路。这决定了您的 PCI DSS 范围。
• 成功衡量标准。 确定您要汇报的指标数据，例如登录量、选择性同意率（opt-in rate）、回头客以及支持工单。竞标方随后可以展示其报表如何生成每一项指标。

从一开始就让 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 中定义。RFC 2866 中定义的 RADIUS 计费可记录会话的开始、停止和数据使用情况。对于包含多个场馆的地产园区，请指定以下要求。

• 带冗余的云端 RADIUS。 如果一个数据中心发生故障，身份验证必须保持正常工作。要求竞标方提供架构说明和过去 12 个月测得的高可用性数据。
• 加密的 RADIUS 传输。 在 RADIUS 跨越公共互联网的地方，要求使用 RadSec（基于 TLS 的 RADIUS，RFC 6614）或加密隧道。
• 动态授权。 平台应该发送 CoA 消息 (RFC 5176) 以终止或更改会话，而无需强制重新连接。
• 网络分段。 访客流量必须保留在单独的 VLAN 上，这是一种与员工和支付系统隔离的逻辑网络分段。客户端隔离必须防止访客设备彼此访问。
• 开放网络上的加密。 要求支持 WPA3，包括 Enhanced Open（ Opportunistic Wireless Encryption，RFC 8110）。它无需共享密码即可对每个连接进行加密。
• 根据需要提供独立密钥。 iPSK（身份预共享密钥）可在共享网络上为每位人员或每台设备提供专属的 WiFi 密码。它适用于长期停留的访客、展商和活动工作人员。Purple 通过 SecurePass 提供此功能。

Passpoint（也称为 Hotspot 2.0）基于 IEEE 802.11u 构建。它允许设备自动查找并加入网络，无需强制门户。身份验证通过 IEEE 802.1X（基于端口的网络访问控制标准）运行，因此凭据保持加密状态。由无线宽带联盟（Wireless Broadband Alliance）运营的 OpenRoaming 是基于 Passpoint 构建的联盟。它允许人们使用已有的身份加入参与联盟的网络。

在第一阶段将 Passpoint 和 OpenRoaming 指定为“应具备”的要求，并提供包含成本的路线图。Purple 支持 OpenRoaming，因此再次光临的访客可以在您的场所自动连接。

如果 RFP 还涵盖员工 WiFi，则要求与 Microsoft Entra ID、Okta 和 Google Workspace 集成。这样可以使入职、调岗和离职人员的网络访问保持同步，无需手动更改密码。

兼容硬件的 AP 兼容性

“与领先的企业硬件兼容”无法作为打分项。请列出您正在运行或可能在合同期内采用的每一个平台。然后要求在每个平台上都具备相同的五种能力。

1. 支持外部强制门户。
2. RADIUS 身份验证和计费。
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 云	集成指南、实时参考案例、基于您固件的试点
Ubiquiti UniFi	UniFi Network application	集成指南、实时参考案例、基于您固件的试点
Cambium	cnMaestro	集成指南、实时参考案例、基于您固件的试点
Extreme	ExtremeCloud IQ	集成指南、实时参考案例、基于您固件的试点
Fortinet	FortiGate 集成无线控制器	集成指南、实时参考案例、基于您固件的试点

要求每家投标方说明其支持的固件范围，然后针对您自己的固件进行测试。Purple 与硬件无关，可在所有八个平台上作为云叠加层运行。无需拆除和更换。为什么您的下一次 WiFi 升级不需要新硬件 介绍了商业案例。对于 Ruckus 资产，请参阅 Ruckus SmartZone 和 RUCKUS One 访客 WiFi 与外部强制门户平台对比。

需要包含的 GDPR 条款

访客 WiFi 会大规模收集个人数据，因此合同必须包含以下条款。

• 符合 GDPR 第 28 条要求的数据处理协议，涵盖目的、安全性、子处理者和删除。
• 同意记录，显示每次选择同意的时间戳、措辞版本和渠道，并可根据需要导出。
• 可配置的保留期和自动删除，符合第 5(1)(e) 条中的存储限制原则。
• 用于查找、导出和擦除个人数据的数据主体工具。根据第 12(3) 条，您必须在一个月内回复请求。
• 处理者不得无故拖延地发出数据泄露通知，正如第 33(2) 条所要求的。然后，您有 72 小时的时间根据第 33(1) 条通知监管机构。
• 跨境传输。 投标方必须说明数据的存放地点以及在英国或欧洲经济区以外进行任何处理的传输机制。
• 针对第 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 标准的支付提供商，并提供其合规性确认书 (AoC)。
• 根据要求 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 门槛。在试点阶段，一家入围竞标者的过滤策略被基于 HTTPS 的 DNS 绕过，因而取消了其竞标资格。

访客 WiFi 采购中常出现哪些问题，又该如何解决？

每家竞标者都回答“是”

原因： 需求仅描述了功能，而未说明标准。解决方法： 在每一项后列出 RFC、IEEE 标准或 GDPR 文章，并要求提供凭证。

强制门户未正常弹出

原因： 围墙花园配置不完整，或强制门户检测机制较弱。解决方法： 要求支持 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 平台是否可以在我们现有的接入点上运行？

可以。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) 条规定的一个月期限内响应访问和删除请求。

我们是否从第一天起就需要 Passpoint 或 OpenRoaming？

不需要，但您应该要求提供包含两项内容的明确成本路线图。强制门户仍然是首次访问时获取同意和一方数据的正确体验。随后，Passpoint 和 OpenRoaming 可以让再次光临的访客自动连接，使用加密的 802.1X 身份验证，无需登录页面。Purple 支持 OpenRoaming，因此您可以在同一个合同内稍后添加自动连接功能。

防护性 DNS 是否应该成为访客 WiFi 合同的一部分？

是的，对于公共部门和适合家庭的场所尤其如此。保护性 DNS 可防止设备访问与恶意软件、网络钓鱼和命令与控制服务器关联的域名。它还可以按场所应用分类过滤。将其作为议会、图书馆和医疗保健场所的“必备”功能。要求提供品牌化的拦截页面、加密的 DNS 策略、每月报告以及与您的 GDPR 计划保持一致的日志保留计划。

切换访客 WiFi 平台会造成多大干扰？

当新平台作为覆盖层运行时，切换只是每个场所的配置更改，而不是硬件项目。Purple 叠加在现有基础设施之上，因此您的 AP、线缆和线路均保持不变。在采用不同硬件的两个场所运行为期 30 天的试点，然后分批推广。首先从即将卸任的平台导出同意记录，这样就不会丢失任何合法的同意订阅。

为什么不使用我们的 AP 厂商平台中内置的强制门户？

因为内置门户会将接入、同意和数据绑定到单个硬件品牌。经过收购和更新周期后，多场所资产很少能保持在单一平台上。无论硬件如何，独立的平台都能在每个站点保持统一的门户、统一的同意记录和统一的分析视图。这可以在未来的每次硬件更新中保护您的数据和谈判地位。