将 RADIUS 服务器迁移至云端本身并不能算作一项完整的 WiFi 安全策略。将 FreeRADIUS 或 Windows NPS 替换为托管端点的流行建议忽略了更棘手的问题：由谁的身份来控制访问、离职员工如何失去访问权限，以及当场馆无法连接到该服务时会发生什么。
RADIUS 即服务作为身份治理控制手段最为有用，而不仅仅是替换一台服务器。对于英国的场馆和企业而言，合适的设计通常是将与目录绑定的员工身份验证，与针对无法使用现代企业级身份验证设备的唯一密钥相结合。仅采用证书的切换方式并不必然是最强劲的选择。
RADIUS 即服务为 WiFi 带来的改变
RADIUS 即服务是一个托管的身份验证、授权和计费（AAA）控制平面。您的无线接入点 (AP) 或 WLAN 控制器仍然是策略执行点。托管服务负责决定是否准入用户或设备，并返回要应用的网络策略。
本地、云端与联邦 RADIUS 对比
| 模式 | 谁来运营 AAA | 身份源 | 故障转移与扩展 | 最佳适用场景 |
|---|---|---|---|---|
| 本地 FreeRADIUS 或 Windows NPS | 由您的团队打补丁并监控服务 | 本地目录或通过服务器访问的身份提供程序 | 由您为每个实例打补丁、构建集群和监控，然后配置更多站点 | 具备内部 RADIUS 技术能力的单站点 |
| 云端 RADIUS 即服务 | 由服务提供商打补丁并监控托管服务 | Entra ID、Okta、Google Workspace 或其他支持的身份提供程序 | 提供商端点和 SLA，无需新增身份验证服务器即可添加新站点 | 无专门 RADIUS 团队的多站点场馆 |
| 联邦 RADIUS 代理 | 共享代理运营商加上归属身份提供程序 | 归属组织的凭据 | 国家级或共享代理基础架构连接各参与站点 | 跨独立运营站点的漫游用户 |
仅迁移服务器并不能实现零信任。安全性依然取决于唯一的身份、及时的权限撤销，以及关于当身份验证不可用时访问是“故障开”（fail-open）还是“故障关”（fail-closed）的书面规则。
共享的 WiFi 密码无法可靠地识别具体个人。您也无法在不为其他所有人更改密码的情况下单单撤销某位离职员工的权限。要让访客隔离于员工系统之外，还需要网络策略，而不仅是一个不同的密码。
将运营模式与访问策略相分离
云端托管改变了身份验证基础架构的维护者。在 Purple，我们运营替代 FreeRADIUS 或 Windows NPS 的云端 RADIUS，无需您的团队对本地身份验证服务器打补丁或处理故障转移。您的团队仍完全掌握访问规则、目录组和本地网络设计。
联邦（Federation）解决的是另一个问题：允许人员在独立管理的地点进行身份验证。根据 Jisc 的 eduroam 管理简报，英国的该项服务于 2006 年 5 月 2 日 推出，它将访客的身份验证重定向至其归属机构，而不是要求受访站点管理本地访客帐户。这是委派身份管理，而不仅仅是远程服务器托管。
实用规则：圈出与当前身份所有者匹配的模式，然后决定该所有权是否需要更改。
身份验证也不是射频覆盖差、网络拥堵或互联网连接弱的万能药。Madeira Remote 关于 改善 WiFi 以实现更顺畅视频通话 的指南是区分连接质量工作与访问控制工作的重要背景参考。修复网络准入并不能解决过载的无线信道问题。
因此，这项决策既是技术性的，也是运营性的。您可以在外包服务器维护的同时，保留对“究竟谁可以进入哪个网络”的控制职责。
云端 RADIUS 如何决定访问权限
受管笔记本电脑连接到配置为 WPA2-Enterprise 或 WPA3-Enterprise 的 SSID。它不需要证明自己知道覆盖整栋大楼的共享密码，而是通过接入点开始进行可扩展身份验证协议（EAP）交互。
接入点或控制器将该交互封装为 RADIUS Access-Request 并发送给托管服务。在服务拥有足够的信息做出决断之前，EAP 可能需要进行多次交互。
分别测试各项 AAA 功能
英国政府的 FreeRADIUS 架构文档 从身份验证（Authentication）、授权（Authorisation）和计费（Accounting）三个维度描述了该服务。请将它们视为单独的验收测试，而非成功登录的互换称谓。
- 身份验证确立身份。服务使用配置的方法评估凭据或证书。Access-Challenge 继续交互，Access-Reject 拒绝准入，而 Access-Accept 则允许准入。
- 授权分配权限。响应可以包含 VLAN、角色、访问控制列表（ACL）或会话限制。控制器必须能够识别并强制执行这些属性。
- 计费记录会话。收集会话开始、中间更新和停止信息，并附带稳定的身份与设备标识符、时间戳和会话标识符。
收到 Access-Accept 并不代表网络隔离生效了。假设承包商身份验证成功，但由于控制器忽略了角色属性而落入员工 VLAN。此时身份验证成功了，但访问设计却失败了。
同样，提供商控制面板中的身份验证结果不能替代会话计费。排查人员需要将身份与设备、场馆及会话联系起来，包括访问开始和结束的时间。
针对端点不可达的情况进行设计
请配置冗余服务端点、健康状况监控和有界重试定时器。无休止的重试会导致客户端挂起，同时增加排查难度。我们的云端 RADIUS 具备跨区域故障转移能力，并提供 99.9% 正常运行时间 SLA，但场馆连接性和控制器行为仍需单独测试。
在投产前制定好断网规则。“故障开”（Fail-open）行为可能会在未经预期检查的情况下准入设备，从而引发无限制访问风险。“故障关”（Fail-closed）行为会拒绝新的准入，这能保护边界，但可能会中断支付终端或其他运营设备。
不要假设现有会话和新连接在网络中断期间的表现完全相同。请分别测试初始身份验证、重新身份验证和端点恢复，并获取书面的可用性承诺和故障转移设计方案。
凭借可观察的证据完成试点：
- 已接受的会话：客户端进入预期的 VLAN，且仅能访问允许的服务。
- 已禁用的身份：新的身份验证尝试收到拒绝（Reject）。
- 可检索的计费日志：管理员事后能够查找到相应的会话记录。
托管服务必须证明的安全控制措施
根据 Consultancy.uk 关于零信任的探讨，2024 年有 50% 的英国企业 在过去 12 个月中遭遇过网络入侵或攻击，而在中大型企业中，这一比例更是超过了 70%。仅凭托管登录服务本身并不能消除这种风险暴露。
零信任意味着对访问进行身份验证和授权，而不是仅仅因为设备连接到了企业 SSID 就信任它。如果通过共享凭据、缺失设备检查或过宽的权限来实现，云服务依然可能应用弱安全策略。
要求在每个边界提供凭证与证据
从凭据开始，然后依次检查传输、管理和执行。每一个环节都有不同的失效模式。
- 具名身份：使用个人帐户或设备身份，并采用由目录驱动的删除机制，而非手动维护的访问列表。
- 强客户端身份验证：对于受管端点，优先采用基于证书的设备身份验证。在支持的情况下使用防钓鱼方法，并在管理和适宜的入职/入网流程中要求多因素身份验证 (MFA)。
- 受保护的传输：使用恰当的加密传输（如 RadSec 或安全隧道）保护控制器到服务之间的路径。仅靠 RADIUS 共享密钥（shared secret）并不能加密整个交互过程。
- 独立管理：将特权管理员身份与日常帐户分开，并保留策略变更的审计日志。
- 最小权限角色：仅向员工、承包商、临床设备和楼宇管理系统授予其所需的访问权限。
不要假设云目录基于浏览器的 MFA 提示能够出现在每一次 EAP 交互中。所选的 EAP 方法、客户端软件和身份集成必须支持预期的身份验证流程。
同时检查无线与运营控制
配置企业级无线安全，包含服务器证书验证、双向身份验证和加密数据帧。在支持且适合所选 WPA 模式的情况下要求使用受保护的管理帧 (PMF)，而不是将“企业级”标签误以为所有保护措施都已启用。
对于更广泛的策略设计，我们的 企业 WiFi 安全指南 提供了有价值的参考。我们的员工 WiFi 提供企业级安全性，且无需复杂的 NAC，但管理员仍必须定义访问边界并监控其运行。
即使身份验证已托管在云端，物理基础架构依然至关重要。ABCO Security Services Australia 关于 加强数据中心安全性 的指南为保护支持网络服务的设施提供了补充背景。
有效的凭据不应赋予设备访问大楼内所有内容的权限。
为重复拒绝警报、意外的权限变更和可疑的管理活动指定负责人。只有当有人能够解读日志并采取行动时，日志才有价值。
连接目录且无需第二个用户存储库
权威目录应当始终是管理雇佣状态和组成员身份的地方。无论是 Entra ID、Okta 还是 Google Workspace，托管 RADIUS 集成都应该将身份转换为网络权限，而不是创建一个脱节的密码数据库。
集成方式非常关键。连接器可以同步组、通过支持的机制验证凭据，或将证书与目录身份关联。不要假设每个云目录都提供相同的密码验证接口。
追踪入职、调岗与离职全流程（JML）
以一名新员工加入设施管理团队为例。一旦其目录成员身份无误且设备已注册，服务就应该分配设施网络角色，而无需管理员另行创建独立的 WiFi 帐户。
当该员工调动至财务部门时，目录中的变更应在下一次适用的策略评估中自动生成对应的 VLAN 或 ACL。成功的设计免去了手动修改各个控制器的麻烦，但它必须明确缓存的成员身份和现有会话何时进行刷新。
对于离职人员，禁用其目录帐户应能在约定的时间窗口内阻止随后的身份验证。当控制器支持且集成触发时，授权变更 (CoA) 可以断开或更改实时会话。基于证书的部署还需要明确的证书撤销或身份状态检查流程。
验收条件：就目录变更同步至新身份验证和活动会话的速度达成一致。对这两者都要进行测试，而不是把“自动”直接当作时间承诺。
英国国家网络安全中心 (NCSC) 的身份与访问控制原则 支持在授予访问权限之前对用户、设备和系统进行验证和授权。应用于 WiFi 时，这使得生命周期管理成为一项安全要求，而不仅仅是入网时的便捷措施。
确认集成边界
CoA、动态角色和围墙花园（walled-garden）行为均依赖于场馆控制器。在 Meraki、Aruba、Ruckus、Mist 和 UniFi 设备群中，应确认具体的型号、固件和功能支持，而不是仅仅依赖厂商名称。
受管笔记本电脑可以使用 EAP-TLS 或其他支持的无密码企业级方法。访客不应需要经历相同的受管设备证书流程。SSO 适用于管理控制台和合适的员工入职流程，但它并不能取代无线链路上的 802.1X。
对于以 Entra 为主的部署，请使用我们的 Entra ID 集成概述 来构建身份需求框架。然后运行一个小型生命周期测试：
- 入职者：配置正确的入职新人必须能够正常连接。
- 调岗者：组变更必须生成预期的网络角色。
- 离职者：在记录的测试时间禁用的帐户必须在约定的撤销窗口期内身份验证失败。
访客、员工与多租户访问模式
一栋大楼内包含具有不同信任边界的不同人群。酒店访客、员工笔记本电脑和租户的电视不应该仅仅因为使用相同的接入点就继承相同的访问策略。
在选择入网/注册页面前，请先确定该人群对应的模式行。所选方法必须能在设备上工作，同时网络必须防止访问无关的用户和系统。
人群访问模式
| 人群分类 | 身份验证方法 | 隔离机制 | 访问如何终止 |
|---|---|---|---|
| 临时访客 | 电子邮件或一次性身份验证，在使用企业级或 Passpoint 时带有加密 | 访客角色或 VLAN，无通往员工网络的路由 | 会话到期或门户（portal）策略 |
| 员工及受管设备 | 通过 EAP 验证的目录身份，通常为证书或无密码企业级身份验证 | 来自目录组的角色、VLAN 或 ACL | 目录禁用，若控制器支持则加上 CoA |
| 承包商/外包人员 | 有时间限制的目录组 | 窄权限角色，而非完整的员工 VLAN | 组到期或工单结束 |
| 传统设备与 IoT 设备 | 唯一 PSK 或其他严格限制范围的凭据 | 独立的网络段，除显式允许的服务外无横向移动路径 | 密钥轮换或与所有者解绑 |
| 多租户住户 | 每人或每户独立的唯一 PSK | 与其他租户隔离的专用网络 | 退租时撤销密钥 |
将便捷入网与宽泛访问权限分离开来
访客需要低门槛的入网体验，通常通过电子邮件身份认证。然而，引导页面（splash page）本身并不会加密无线连接。请在支持的情况下选择加密访问方式，不要将成功完成 Portal 页面验证当作访问内部系统的许可。
员工需要与目录绑定的企业级身份验证。承包商则需要设置有效期和更窄的角色权限，即使他们与员工一起工作也是如此。应让运营负责人承担延长承包商访问权限的责任，而不是让帐户无限期保持激活状态。
住户和商业租户还有另一个需求：他们自己的设备必须能够相互协作，同时又不会暴露给邻居。我们的 多租户 WiFi 指南 对这种专用网络模式进行了探讨。
为受限设备使用唯一密钥
打印机、电视、游戏机和扫描仪可能不支持所需的 EAP 方法。唯一预共享密钥（通常称为 iPSK 或 xPSK）允许您将它们的访问权限与具体个人、住户或设备绑定，而无需恢复覆盖整栋大楼的全局密码。
单凭密钥本身并不能创造隔离。控制器和网络必须将其映射到预期的私有网段并强制执行允许的路径。请将凭据视为可转让的，记录其所有者，并在所有权终止时予以撤销。
我们在单一云平台上提供访客 WiFi、员工 802.1X 安全防护以及 xPSK 专有区域网络（Private Area Network）。我们的 xPSK 和多租户 WiFi 为每个住户、租户或设备提供带有租户隔离功能的唯一密钥，包括为无浏览器的游戏机和电视提供私密连接。
对于住宅运营商而言，应将数字退租与物理门禁权限的撤销进行协调。Nimbio 关于 多户住宅大门门禁控制 的方案是思考住户凭据所有权的一个很好的类比。前住户的大门门禁权限和网络密钥都不应该在搬离后继续有效。
如何在不依赖共享备用密码的情况下进行迁移
迁移应当在旧方案彻底废除前，证明每种设备人群都能安全连接。运营上的误区在于将每一个例外情况都当作保留整栋大楼紧急密码的理由。
周密规划的需求不仅限于 WiFi：《Cyber Magazine》关于 Hiscox 调查的报道 指出，三分之二受访的企业计划在 2030 年之前部署零信任架构。这是对未来的规划声明，并非表明其现有网络已经符合该模式。
按受控顺序执行切换
- 对客户端进行分类。区分支持 802.1X 的员工端点、无浏览器或传统设备以及访客。记录设备所有权和运营关键程度。
- 验证控制器能力。确认企业级身份验证、动态 VLAN 或角色、CoA 以及任何所需的围墙花园。检查已安装的固件，而不仅仅是产品系列。
- 在选定站点试点限定范围的 SSID。将其连接到目录并记录“故障关”（fail-closed）行为。试点应包含有代表性的运营设备，而不只是 IT 部门的笔记本电脑。
- 配置受管员工设备。使用证书或支持的无密码企业级方法。我们的员工 WiFi 运行在现有的接入点上，客户无需自行构建 PKI。
- 为受限设备提供限定范围的凭据。在适当时向打印机、医疗设备和 IoT 发放唯一 PSK。仅允许访问其必需的目标地址。
- 让访客保持独立的策略。即使入网和身份验证共享同一个管理平台，也要测试确保访客设备无法访问员工资源。
- 演练断网路径。分别中断身份提供程序访问和场馆互联网连接。验证无需分发通用密码即可恢复的能力。
- 逐步完成切换。审查每个站点的计费、隔离和客户端行为。在约定的验收检查成功后，彻底清除旧密码。
明确何时不应迁移
物理隔离（Air-gapped）的站点无法依赖云端控制平面。无法处理所需 RADIUS 属性的控制器也可能会阻碍预期设计的落实，即使基础身份验证可以工作。
关于将身份验证元数据保留在英国境内的内部要求，必须通过已归档的处理地点和分包商安排来解决。仅仅依靠服务提供商在英国设有办事处是远远不够的。记录保留、管理访问和恢复安排也属于采购审批的一部分。
我们的服务作为云端叠加层（overlay）运行在现有接入点上，因此不需要全面替换（rip-and-replace）现有的部署。我们的 xPSK 和多租户 WiFi 支持 Meraki、Aruba、Ruckus 和 UniFi 硬件，具体取决于设计所需的控制器能力。
企业级身份验证与唯一密钥的混合方案解决的是客户端兼容性问题，而不一定能解决云端断网的依赖问题。在本地自主性至关重要的场景下，请保留合适的本地身份验证设计或继续留在本地。不要将未解决的弹性韧性需求伪装成例外密码。
评估云端 RADIUS 是否适合您的资产/设施
当多个站点需要一致的由身份主导的访问权限，且您的团队不想维护身份验证服务器时，请选择云端 RADIUS。最强有力的理由在于运营维度：目录变更应该直接管辖网络访问，而无需创造额外的帐户管理工作量。
当您的团队已经能够很好地运营具备高弹性的本地 RADIUS、托管服务与数据处理要求相冲突、或者控制器无法强制执行拟议的策略时，请保持本地部署（on-premises）。如果一次迁移去掉了服务器却削弱了本地可用性，这并不是进步。
根据资产清册做出决策
当受管员工端点支持 802.1X，但大楼内同时还包含需要限定范围密钥的电视、打印机、扫描仪或临床设备时，请选择混合访问模式。其目标是为每类人群提供适当的保障，而非为每台设备提供完全相同的凭据。
建立一份包含以下内容的资产清册：
- 无线资产：SSID、控制器厂商、型号和固件版本。
- 身份归属：权威目录、组所有者和离职流程。
- 客户端能力：哪些设备可以使用证书，哪些不能。
- 运营依赖项：连接中断期间必须保持可用的系统。
对比书面承诺，而非演示效果
向每家入围的服务提供商提出相同的问题：在多站点故障期间可用性承诺包含哪些内容、日志保留多久、身份验证元数据在哪里处理、哪些分包商可以访问这些数据，以及恢复机制如何避免退回到共享密码的方案？
当您的资产符合访客、员工和多租户模式时，请将 Purple 与其他提供商一起列入候选名单。自 2012 年以来，我们一直为零售商、医疗机构、体育场馆、交通枢纽和市中心等环境提供支持。我们的员工 WiFi 价格未公开公开，因此请联系我们，获取基于您要迁移的资产规模的报价。
您的下一步是制定一份以资产清册为支撑的验收计划。精彩的演示绝不应替代您的控制器、您的目录以及您那些棘手设备真正通过测试。
Purple 提供用于员工身份验证的托管 RADIUS，以及访客 WiFi 和隔离的多租户访问。请准备好您的控制器清单、身份提供程序需求和传统设备列表，访问 Purple，与我们讨论立足于您实际资产情况的部署方案和价格。
