从本地 RADIUS (NPS) 迁移到 RADIUS as a Service

播客脚本：从本地 RADIUS (NPS) 迁移到 RADIUS as a Service 时长：约 10 分钟 | 配音：英国英语，男声，资深顾问语气 --- 第 1 部分：引言与背景 欢迎来到 Purple WiFi 技术简报系列。今天，我们将探讨一项目前正处于许多企业 IT 团队规划路线图上的迁移任务：从本地 RADIUS（特别是 Microsoft 的 Network Policy Server）迁移到云托管的 RADIUS as a Service 模型。 如果您正在管理酒店集团、零售物业、体育场或公共部门园区的 WiFi 身份验证，这与您直接相关。本地 NPS 模型已经为我们服务了近二十年，但运营开销、单点故障风险以及扩展限制正变得越来越难以接受——特别是当云原生替代方案现在能以总拥有成本的一小部分提供企业级可靠性时。 在接下来的十分钟里，我们将介绍这两种方法的技术架构，逐步讲解结构化的迁移方法，分析两个真实的实施场景，并以您自信做出决策所需的关键决策框架结束。 让我们开始吧。 --- 第 2 部分：技术深挖 首先，让我们确保我们在 RADIUS 在您的网络栈中的实际作用上达成一致。RADIUS（Remote Authentication Dial-In User Service）是 RFC 2865 中定义的协议，用于处理网络访问的身份验证、授权和计费。在 WiFi 环境中，它是 IEEE 802.1X 基于端口的访问控制的骨干。当设备连接到 WPA2-Enterprise 或 WPA3-Enterprise SSID 时，接入点充当 RADIUS 客户端（我们称之为网络访问服务器，即 NAS），并将身份验证请求转发给 RADIUS 服务器。服务器通常会针对 Active Directory 或 LDAP 目录验证凭据，并返回 Access-Accept 或 Access-Reject 响应。这就是基本流程。 现在，在本地 NPS 模型中（Network Policy Server 是 Microsoft 随 Windows Server 捆绑的 RADIUS 实现），您是在自己拥有、维护的数据中心或服务器机房的硬件上运行该身份验证逻辑。NPS 服务器保存着您的网络策略、用于 EAP-TLS 或 PEAP-MSCHAPv2 的证书基础设施以及连接请求策略。它确实有效，也很成熟。但它带来了一系列随着时间推移而累积的运营现实问题。 首先是硬件依赖。您的 NPS 服务器是一台物理机或虚拟机，需要打补丁、容量规划以及最终的硬件更新。在多站点部署中（例如，在英国各地拥有物业的酒店集团），您要么运行具有 WAN 依赖关系的集中式 NPS，要么在每个站点部署 NPS 实例并分别进行管理。这两种方式都不够优雅。 其次是可用性。单个 NPS 实例是您整个身份验证基础设施的单点故障。是的，您可以部署 NPS 故障转移对，但这会使您的硬件和许可开销翻倍，并且仍然无法提供云服务原生提供的地理冗余。 第三是可扩展性。NPS 是为企业 LAN 环境设计的。当您在体育场活动或会议中心高峰期间处理数千个并发身份验证请求时，单个 NPS 实例的吞吐量限制就会变得非常明显。身份验证延迟激增，用户在您最无法承受的时刻遇到连接失败。 RADIUS as a Service 从架构上解决了所有这三个限制。云 RADIUS 提供商运行一个分布式的、地理冗余的 RADIUS 服务器集群。您的接入点指向云托管的 RADIUS 端点，而不是本地服务器。身份验证请求在集群中进行负载均衡，故障转移是自动且透明的。提供商负责处理补丁、容量扩展和证书管理。从您作为网络运营商的角度来看，RADIUS 变成了一种消费服务，而不是一个托管组件。 身份验证协议本身并没有改变。您仍然根据客户端设备组合运行带有 EAP-TLS、PEAP-MSCHAPv2 或 EAP-TTLS 的 IEEE 802.1X。不同之处在于 RADIUS 服务器所在的位置以及谁负责其运营连续性。 这里有一个重要的安全考虑，我想直接说明，因为在几乎每一次与客户的对话中都会提到它。将 RADIUS 移至云端意味着您的身份验证流量正在穿越公共互联网以到达云 RADIUS 端点。这可以通过两种机制来缓解。首先，Network Access Server 和 RADIUS 服务器之间的 RADIUS 流量使用共享密钥和基于 MD5 的消息认证进行保护。其次，对于现代部署而言更重要的一点是，您应该运行 RadSec（即 RFC 6614 中定义的 RADIUS over TLS），它将整个 RADIUS 对话封装在 TLS 隧道中。这为您提供了等同于 HTTPS 的传输层加密，消除了 MD5 漏洞，并在 NAS 和 RADIUS 服务器之间提供了双向身份验证。任何值得考虑的云 RADIUS 提供商都应将支持 RadSec 作为标准配置。 在身份集成方面，云 RADIUS 服务通常支持通过 LDAPS 连接回您的本地 Active Directory，或者通过 SAML 或 SCIM 与 Azure Active Directory 和 Entra ID 进行原生集成。这意味着您不需要迁移用户目录——云 RADIUS 服务会查询您现有的身份库，从而维持您现有的用户生命周期管理流程。 对于注重合规性的组织（包括根据 PCI DSS 处理支付卡数据或根据 GDPR 处理个人数据的任何组织），获得 SOC 2 Type II 认证和 ISO 27001 认证的云 RADIUS 提供商提供了比大多数组织通过自主管理 NPS 基础设施所能达到的更强的合规性水平。 --- 第 3 部分：实施建议与常见陷阱 好的，让我们来谈谈如何在不让身份验证基础设施下线的情况下实际执行此迁移。 我推荐的方法是五阶段法。第一阶段是审计和盘点。记录每个 RADIUS 客户端（每个接入点、每个交换机、每个 VPN 集中器）以及它当前使用的共享密钥、它正在使用的 EAP 方法以及您的 NPS 策略中的任何厂商特定属性。这是枯燥的工作，但跳过它通常是迁移失败的第一大原因。 第二阶段是试点部署。启动您的云 RADIUS 实例，并将非生产 SSID 或单个测试站点指向它。验证您的 EAP 方法是否端到端工作，您的身份集成是否正常运行，以及您的计费数据是否正确传输。 第三阶段是并行运行。这是关键的风险缓解步骤。将您的接入点配置为同时将本地 NPS 服务器和云 RADIUS 服务器作为身份验证目标，并将云服务设为主服务器，NPS 设为备用服务器。在整个业务周期中，以此配置运行至少两周。监控身份验证成功率、延迟以及任何策略差异。 第四阶段是切换。移除 NPS 备用配置，并承诺将云 RADIUS 作为您唯一的身份验证基础设施。在计划的维护窗口期间执行此操作，并准备好经过测试的记录在案的回滚程序。 第五阶段是停用。在验证切换后稳定运行三十天后，停用 NPS 服务器并回收硬件或虚拟机资源。 我最常看到的陷阱是：证书信任链问题——具体来说，客户端设备不信任云 RADIUS 服务器的证书，因为 CA 不在它们的受信任存储中。在切换之前，通过您的 MDM 或组策略解决此问题。第二个常见陷阱是防火墙规则。云 RADIUS 要求从您的接入点到云端点开放出站 UDP 1812 和 1813，或者为 RadSec 开放 TCP 2083。确保您的网络边界允许这些流量。第三：共享密钥复杂性。如果您现有的 NPS 共享密钥较弱，请利用迁移的机会轮换为加密强度高的密钥，或者更好的是，迁移到 RadSec 并完全消除共享密钥。 --- 第 4 部分：快速问答 让我快速解答一下我最常收到的关于这个主题的问题。 我们能把 Active Directory 保留在本地吗？是的，完全可以。云 RADIUS 通过 LDAPS 连接到您的本地 AD。您的目录仍保留在原处。 如果我们的互联网连接中断会怎样？这是关键的依赖关系转移。使用云 RADIUS，互联网连接成为身份验证的依赖项。通过冗余 WAN 链路或在中断期间为已知设备缓存身份验证的本地 RADIUS 代理来缓解此问题。 这会影响我们的 PCI DSS 合规性吗？迁移到经过认证的云 RADIUS 提供商通常会改善您的合规性水平。确保您的提供商能够提供 SOC 2 Type II 报告，并将其纳入您的年度 QSA 评估范围。 完整迁移需要多长时间？对于单个站点，需要两到四周。对于拥有五十个或更多地点的多站点资产，请计划通过分阶段推广进行三到六个月。 --- 第 5 部分：总结与后续步骤 总结一下：从本地 NPS 迁移到 RADIUS as a Service 的理由在运营、财务和合规性方面都非常充分。当通过结构化的并行运行阶段执行时，迁移本身是低风险的。关键的技术决策是您的 EAP 方法选择、您的身份集成方法，以及是否为传输安全实施 RadSec（我强烈建议在任何新部署中实施 RadSec）。 您眼前的后续步骤：对您当前的 RADIUS 客户端和策略进行审计，联系您的云 RADIUS 提供商以获取试点环境，并在开始之前检查您的防火墙规则和证书信任链。 对于运行 Purple WiFi 访客接入平台的组织，RADIUS as a Service 功能可直接与访客 WiFi 身份验证流程集成，为您提供一个同时适用于企业 802.1X 身份验证和访客网络访问管理的单一控制平面，并内置分析和合规性报告。 感谢收听。完整的技术参考指南可在 Purple 网站上获取，如果您准备好向前推进，我们的解决方案团队可为您提供范围界定交流。 --- 脚本结束