Cloud RADIUS 与本地 RADIUS：IT 团队决策指南
本指南为 IT 主管、网络架构师和场馆运营团队提供了一个明确的框架，用于在云托管 RADIUS 服务和传统本地 RADIUS 服务器之间进行选择。它涵盖了多站点酒店、零售和公共部门部署的技术架构、延迟和可靠性权衡、总拥有成本以及合规性考虑。最后，读者将拥有一个与其特定基础设施约束和组织风险偏好相一致的决策模型。
Listen to this guide
View podcast transcript
执行摘要
RADIUS 身份验证是每个企业 WiFi 部署的核心。无论您是通过 IEEE 802.1X 保护员工访问，还是在多个场馆管理访客接入，决定 RADIUS 基础设施的托管位置都会直接影响正常运行时间、运营开销和总拥有成本。
云 RADIUS 服务提供受管、全球分布的身份验证基础设施，内置高可用性、自动证书轮换和弹性扩展能力——消除了困扰分布式本地部署的逐站点维护负担。本地 RADIUS（无论是运行 FreeRADIUS 还是 Microsoft NPS）能提供亚毫秒级的本地身份验证、完全的数据主权以及独立于 WAN 连接的运行模式——在特定高密度或受监管环境中，这些优势仍然至关重要。
对于大多数多站点运营商——酒店集团、零售连锁店、会议中心——云 RADIUS 以更低的五年总拥有成本提供更优的运营成果。但也有明确定义的例外：气隙隔离环境、严格的数据驻留要求，以及本地 LAN 性能至关重要的大型单站点部署。本指南为您提供框架，以确定您的部署属于哪一类别，以及如何根据这一决策采取行动。
技术深度解析
RADIUS 协议及其在 802.1X 基础设施中的角色
RADIUS（远程认证拨入用户服务，RFC 2865）作为网络接入层和身份目录之间的身份验证代理运行。在 802.1X 部署中，接入点或交换机充当网络接入服务器（NAS），通过 UDP（端口 1812 用于身份验证，端口 1813 用于计费）将 EAP 身份验证帧转发到 RADIUS 服务器。RADIUS 服务器根据后端目录（Active Directory、LDAP 或云身份提供程序）验证请求者的凭据，并返回 Access-Accept 或 Access-Reject 响应，可选包含 VLAN 分配属性。
无论您的 RADIUS 服务器是服务器机架中的机架式设备还是全球分布的云服务，此架构从根本上来说是相同的。差异在于该服务器所在的位置、谁负责维护以及如何扩展。
本地 RADIUS：架构与权衡
两个主导的本地 RADIUS 平台是 FreeRADIUS 和 Microsoft 网络策略服务器（NPS）。FreeRADIUS 是全球部署最广的 RADIUS 服务器，支持广泛的 EAP 方法，包括 EAP-TLS、PEAP-MSCHAPv2、EAP-TTLS 和 EAP-PWD。它通过 LDAP、SQL 或 REST 与几乎所有后端目录集成，并且无需许可费用。然而，它需要熟练的管理：配置基于文件，调试需要日志分析经验，跨数十个站点的扩展需要仔细的复制和故障切换规划。
Microsoft NPS 与 Active Directory 原生集成，是以 Windows 为中心的环境的默认选择。它开箱即用地支持 PEAP-MSCHAPv2 和 EAP-TLS，并通过熟悉的 Windows Server 界面进行管理。其代价是与 Windows Server 许可的紧密耦合，以及与 FreeRADIUS 相比更有限的 EAP 方法集。
对于高可用性的本地部署，组织通常会部署主动-主动或主动-被动 RADIUS 集群。接入点配置有主和辅助 RADIUS 服务器地址；如果主服务器在配置的超时时间（通常为 3-5 秒）内未能响应，NAS 会故障切换到辅助服务器。这种架构要么需要地理上分散的服务器——这会引入额外的复杂性——要么需要同一设施中的一对服务器，而这并不能抵御站点级别的中断。
延迟概况：本地 RADIUS 通过本地 LAN 可提供低于 1 毫秒的身份验证往返延迟。对于处理数千个同时身份验证的高密度环境（例如，一个 68,000 座体育场在售罄活动期间），这种本地处理能力是真正的运营优势。
云 RADIUS：架构与权衡
云 RADIUS 平台在多个地理分布的可用区上托管 RADIUS 基础设施。当接入点发送身份验证请求时，它会被路由到最近的云边缘节点，根据提供商到站点的接入点（PoP）距离，通常会增加 5-50 毫秒的往返延迟。对于绝大多数身份验证用例，这种延迟对最终用户而言是不可感知的。
高可用性模型与本地部署有根本不同。云平台的负载均衡器会自动将请求路由到未发生故障的节点，而不是配置主/辅助对。企业云 RADIUS 提供商通常发布 99.99% 正常运行时间的 SLA，并以多区域冗余作为后盾。在本地实现同等的冗余需要在多个地理分散的数据中心部署主动-主动集群——这是一项巨大的工程和资本投资。
云 RADIUS 平台与云身份提供程序原生集成。如果您的组织使用 Okta、Azure Active Directory 或 Google Workspace，云 RADIUS 服务可通过 SAML、基于 TLS 的 LDAP 或专有 API 连接器进行连接。有关 Okta 集成的详细演练，请参阅我们的指南： Okta 与 RADIUS：将身份提供程序扩展到 WiFi 身份验证 。
证书管理是云 RADIUS 最具说服力的运营论据之一。EAP-TLS 和 PEAP 都依赖服务器端数字证书。在本地，证书过期是身份验证中断的主要原因——FreeRADIUS 服务器上的证书过期会导致每个连接的客户端拒绝服务器的身份，从而造成全面的 WiFi 中断，直到证书得以更新和部署。云 RADIUS 提供商完全自动化证书轮换，消除了这一故障模式。
WPA3-企业版和协议注意事项
WiFi 联盟的 WPA3-企业版规范引入了 192 位安全模式，强制要求使用采用 Suite B 加密套件（ECDHE、ECDSA、AES-256-GCM）的 EAP-TLS。这对于医疗、金融和政府部署日益重要。大多数现代云 RADIUS 平台原生支持 WPA3-企业版。运行较旧 FreeRADIUS 版本（3.0.x 之前）或旧式 NPS 配置的本地部署可能需要升级才能部署 WPA3-企业版。如果 WPA3-企业版在您的路线图上，请在承诺采用某一基础设施路径之前验证您的 RADIUS 平台的支持情况。
对于考虑支撑多站点云 RADIUS 部署的 SD-WAN 层的组织，我们的指南 面向现代企业的核心 SD-WAN 优势 提供了关于广域网弹性架构的补充背景信息。
实施指南
步骤 1：审核您当前的身份验证依赖关系
在选择部署模型之前，请记录当前身份验证基础设施接触的每一个 SSID、VLAN、EAP 方法和后端目录。包括无头设备（打印机、物联网传感器、销售点终端）的 MAC 认证旁路（MAB）策略——这些在迁移过程中经常被忽视，并可能导致严重的切换后事故。
步骤 2：评估身份提供程序就绪状态
如果您的用户目录是本地 Active Directory 并且无法同步到云 IdP，那么您的云 RADIUS 选项仅限于支持 LDAP 代理到本地目录的平台。如果您可以部署 Azure AD Connect 或类似的同步工具，则可用的云 RADIUS 平台范围将扩大。这一单一决策——云 IdP 还是本地目录——通常是云与本地 RADIUS 选择中的决定性因素。
步骤 3：评估每个站点的广域网弹性
云 RADIUS 的可靠性取决于每个站点的互联网连接。在迁移之前，审核每个位置的广域网连接。只有单个 ISP 连接且无故障切换的站点面临重大风险。在部署云 RADIUS 作为主要身份验证基础设施之前，应实施双 ISP 连接或 SD-WAN 故障切换。对于销售点系统依赖网络身份验证的 零售 环境，广域网弹性是不可协商的。
步骤 4：规划证书迁移（本地部署）
如果使用 EAP-TLS 部署或维护本地 RADIUS，请建立证书生命周期管理流程。在证书到期前 90、60 和 30 天实施监控警报。考虑部署内部 PKI（例如 Microsoft ADCS 或 HashiCorp Vault）以自动化证书颁发和续订。在生产环境中，切勿仅依赖日历提醒进行证书管理。
步骤 5：配置存活策略
对于云 RADIUS 部署，请在无线控制器或接入点上配置本地存活策略。选项包括：在可配置的时间段内缓存最近已知的身份验证状态，回退到预批准设备列表的 MAC 认证旁路，或通过辅助身份验证路径路由关键员工 SSID。对于 酒店业 运营商，确保通过 Purple 的 Guest WiFi 等平台进行的访客 WiFi 接入在 RADIUS 不可用期间具有定义的回退行为。
步骤 6：运行并行部署
将新的 RADIUS 平台与现有基础设施并行部署。创建一个映射到新 RADIUS 服务器的专用测试 SSID，并在迁移生产 SSID 之前验证所有 EAP 方法、VLAN 分配和策略执行。对于单站点部署，此并行运行期限应至少为两周，对于多站点迁移，应为四到六周。
步骤 7：执行分阶段、逐站点的迁移
对于多站点部署，应按顺序而非同时迁移站点。从风险较低的站点开始——流量较小且用户容忍度较高的小型地点——然后再迁移旗舰店或会议密集型酒店等优先级较高的站点。在开始切换之前，为每个站点制定回滚程序。
最佳实践
共享机密卫生：接入点与 RADIUS 服务器之间的 RADIUS 共享机密必须至少包含 32 个字符，随机生成，并且每个 NAS 设备唯一。在所有接入点之间重复使用共享机密意味着只要攻陷一台设备就会暴露整个身份验证基础设施。每年或在怀疑发生任何攻击后轮换共享机密。
VLAN 分段：使用 RADIUS 分配的 VLAN（通过 Tunnel-Type、Tunnel-Medium-Type 和 Tunnel-Private-Group-ID 属性）根据用户角色动态分段流量。访客设备应落在仅限互联网访问的隔离 VLAN 上；公司设备落在生产 VLAN 上；物联网设备落在专用的受限 VLAN 上。这种分段是任何处理持卡人数据的网络的 PCI DSS 要求。
计费和审计日志记录：启用 RADIUS 计费（端口 1813），并将计费日志至少保留 12 个月。这些日志记录会话开始/停止时间、数据量以及分配的 IP 地址——这对于安全事件调查和 GDPR 合规性至关重要。云 RADIUS 平台通常通过 syslog 或 API 将计费数据导出到 SIEM 系统；本地部署应将计费数据路由到集中式日志管理平台。
EAP 方法选择：对于公司员工网络，EAP-TLS（基于证书）提供最强的安全态势，并推荐用于 PCI DSS 和医疗环境。PEAP-MSCHAPv2 可接受用于风险较低的环境，但如果请求者未正确验证服务器证书，则容易受到凭据窃取攻击。完全避免 EAP-MD5——它已被弃用，并且不提供双向认证。
RadSec（基于 TLS 的 RADIUS）：传统的 RADIUS 协议通过 UDP 传输数据，仅加密 User-Password 属性。RadSec（RFC 6614）将 RADIUS 封装在 TLS 中，提供全传输加密以及 NAS 与 RADIUS 服务器之间的双向认证。大多数现代云 RADIUS 平台支持 RadSec。对于新部署，RadSec 应作为默认的传输选择。
对于 医疗 和 交通 行业的部署，由于 GDPR 和行业特定法规下的数据处理义务尤为严格，应确保您的 RADIUS 平台提供数据处理协议并支持区域数据驻留。
故障排除与风险缓解
常见故障模式 1：证书过期（本地）
症状：所有客户端突然无法身份验证；RADIUS 日志显示 TLS 握手失败。
根本原因：RADIUS 服务器上的服务器端证书已过期。客户端请求者拒绝服务器的身份。
缓解措施：实施自动化证书监控，在 90/60/30 天前发出警报。使用具有自动续订功能的内部 CA。云 RADIUS 通过自动证书轮换完全消除了此故障模式。
常见故障模式 2：广域网中断阻断云 RADIUS
症状：特定站点的身份验证失败；其他站点不受影响。本地网络正常运行。
根本原因：站点的互联网连接已中断，导致接入点无法访问云 RADIUS 服务。
缓解措施：部署双 ISP 连接或具有自动故障切换功能的 SD-WAN。在接入点上配置存活策略，以缓存凭据或对关键设备回退到 MAB。
常见故障模式 3：共享机密不匹配
症状：身份验证请求被静默丢弃；RADIUS 日志显示“invalid authenticator”或“message authenticator”错误。
根本原因：接入点上配置的共享机密与 RADIUS 服务器上配置的机密不匹配。
缓解措施：使用集中式机密管理系统（HashiCorp Vault、AWS Secrets Manager）来确保一致性。在 NAS 或 RADIUS 服务器配置更改后验证共享机密。
常见故障模式 4：请求者配置错误
症状：个别设备无法身份验证，而同一 SSID 上的其他设备成功。
根本原因：故障设备上的 802.1X 请求者未配置为信任 RADIUS 服务器的证书，或配置了不兼容的 EAP 方法。
缓解措施：通过 MDM 或组策略部署请求者配置以确保一致性。对于 BYOD 环境，提供清晰的接入指南。Purple 的 WiFi Analytics 平台可以帮助识别整个设备资产中的身份验证失败模式。
常见故障模式 5：负载下的 RADIUS 超时
症状：高峰时段（活动开始、换班）身份验证延迟或失败。
根本原因：RADIUS 服务器被并发身份验证请求淹没；在收到响应之前，NAS 超时已过。
缓解措施：本地部署：在已知高峰事件之前扩展 RADIUS 服务器容量；在接入点上实施连接速率限制。云 RADIUS：验证您的订阅层支持高峰身份验证吞吐量；大多数企业云平台会自动扩展。
投资回报与业务影响
总拥有成本：五年对比
以下分析基于一个具有代表性的 20 站点零售连锁店，每个站点大约 50 个接入点，高峰时每个站点 200 个并发认证设备。
| 成本构成 | 本地 RADIUS（20 个站点） | 云 RADIUS（20 个站点） |
|---|---|---|
| 硬件（服务器、高可用对） | £80,000–£120,000 | £0 |
| 操作系统和软件许可 | £10,000–£30,000 | £0 |
| 年度订阅 | £0 | £18,000–£40,000/年 |
| 电力与冷却（5 年） | £15,000–£25,000 | £0 |
| 工程时间（5 年） | £60,000–£100,000 | £10,000–£20,000 |
| 5 年总成本 | £165,000–£275,000 | £100,000–£220,000 |
工程时间差异是最重要的因素。20 个站点的本地 RADIUS 需要持续的补丁管理、证书管理、监控和事件响应。云 RADIUS 将其减少为策略管理和集成维护——仅为此所花费精力的一小部分。
衡量成功
RADIUS 部署的关键绩效指标应包括：身份验证成功率（目标：生产环境 >99.5%），平均身份验证延迟（目标：云 <100ms，本地 LAN <5ms），身份验证中断平均恢复时间（目标：<15 分钟），以及证书过期事件（目标：通过适当自动化实现零事件）。
对于使用 Purple 的 Guest WiFi 平台的 酒店业 运营商，身份验证基础设施的可靠性直接影响住客满意度分数。高峰入住登记期间的 2 秒身份验证延迟会反映在住客反馈中。在适当配置存活策略的情况下，云 RADIUS 在此指标上持续优于临时的本地部署。
从分布式本地 FreeRADIUS 部署迁移到云 RADIUS 的组织一致报告，与身份验证相关的 IT 事件减少了 30-50%，并且分配给 RADIUS 维护的工程小时数显著减少——这些时间被重新分配给战略性网络改进项目。Purple 的平台与两种部署模型集成，提供 WiFi Analytics 和 Sensors 数据，以量化这些改进，与迁移前捕获的基线指标进行对比。
对于考虑更广泛网络现代化背景的场馆运营商，Purple 的 Wayfinding 功能以及将身份验证数据与人流分析相集成，代表了架构良好的 RADIUS 基础设施所能实现的下一层价值。身份验证事件本质上是存在数据——当通过 Purple 的分析层呈现时，它们成为了解整个场所的访客行为、停留时间和回访率的强大工具。
Key Definitions
RADIUS（远程认证拨入用户服务）
一种网络协议（RFC 2865），为连接到网络的用户提供集中式身份验证、授权和计费（AAA）。RADIUS 基于 UDP 运行，充当网络接入设备（接入点、交换机）与身份目录（Active Directory、LDAP、云 IdP）之间的代理。
IT 团队在为 WiFi 或有线网络部署 802.1X 身份验证时就会接触到 RADIUS。它是企业网络访问控制的基础协议，也是 WPA2-企业版和 WPA3-企业版部署所必需的。
802.1X
一种 IEEE 标准，用于定义基于端口的网络访问控制框架，该框架定义了基于 EAP 的身份验证。在 WiFi 环境中，802.1X 需要三个组件：请求者（客户端设备）、认证者（接入点）和认证服务器（RADIUS）。在 RADIUS 返回 Access-Accept 之前，接入点会阻止客户端的所有流量。
802.1X 是 WPA2-企业版和 WPA3-企业版网络的身份验证机制。IT 团队使用它来确保只有授权的设备和用户才能连接到公司 WiFi，并根据用户身份动态分配 VLAN。
EAP（可扩展身份验证协议）
在 802.1X 中使用的一种灵活身份验证框架，支持多种身份验证方法。常见的 EAP 方法包括 EAP-TLS（基于证书，安全性最强）、PEAP-MSCHAPv2（基于密码，需验证服务器证书）和 EAP-TTLS（隧道密码身份验证）。
EAP 方法的选择直接影响安全态势和部署复杂性。EAP-TLS 要求每台设备上都有客户端证书，这使得部署更复杂，但对凭据盗窃攻击的抵抗力显著增强。受监管行业（医疗、金融）的 IT 团队应默认使用 EAP-TLS。
FreeRADIUS
全球部署最广的开源 RADIUS 服务器，为全球数亿用户提供身份验证服务。FreeRADIUS 支持广泛的 EAP 方法和后端集成，无需许可费用，在 Linux 上运行。它需要熟练的管理和基于文件的配置。
FreeRADIUS 是非微软环境下本地 RADIUS 部署的默认选择。评估云与本地决策的 IT 团队应评估其是否具备有效运营 FreeRADIUS 的内部专业知识，因为配置错误是导致身份验证事件的主要原因。
NPS（网络策略服务器）
微软内置的 RADIUS 服务器，包含在 Windows Server 中。NPS 与 Active Directory 原生集成，支持 PEAP-MSCHAPv2 和 EAP-TLS。它通过 Windows Server GUI 进行管理，是以 Microsoft 为中心的环境的默认 RADIUS 选择。
运行 Windows Server 基础设施的 IT 团队通常将 NPS 作为其本地 RADIUS 服务器部署。NPS 与 Windows Server 许可和 Active Directory 紧密耦合，这在 Microsoft 环境中简化了部署，但在异构或云原生环境中限制了灵活性。
MAC 认证旁路（MAB）
一种身份验证方法，使用设备的 MAC 地址作为其凭据，允许无法运行 802.1X 请求者的无头设备（打印机、物联网传感器、销售点终端）向网络进行身份验证。RADIUS 服务器根据允许列表检查 MAC 地址。
MAB 对于任何拥有物联网设备或旧式设备的网络都是必不可少的。IT 团队必须维护准确的 MAC 地址清单，并实施添加新设备的流程。云 RADIUS 平台通常提供集中式仪表板用于管理所有站点的 MAB 列表，这比在 FreeRADIUS 上逐站点管理配置文件效率高得多。
RadSec（基于 TLS 的 RADIUS）
RADIUS 协议的一种扩展（RFC 6614），通过 TLS 而非 UDP 传输 RADIUS 数据包。RadSec 提供全传输加密以及 NAS 与 RADIUS 服务器之间的双向认证，解决了传统基于 UDP 的 RADIUS 协议中多个已知的安全漏洞。
传统的 RADIUS 只加密 User-Password 属性；所有其他属性，包括用户名和会话数据，都以明文传输。RadSec 是现代、安全的 RADIUS 传输机制，大多数企业云 RADIUS 平台和现代接入点供应商都支持。部署新 RADIUS 基础设施的 IT 团队应将 RadSec 作为默认传输方式进行评估。
VLAN 分配（RADIUS 分配的 VLAN）
一种 RADIUS 功能，根据身份验证结果动态将连接的设备分配到特定的 VLAN。RADIUS 服务器在 Access-Accept 响应中返回 Tunnel-Type（13=VLAN）、Tunnel-Medium-Type（6=802）和 Tunnel-Private-Group-ID（VLAN ID）属性，接入点将设备置于指定的 VLAN。
动态 VLAN 分配是 IT 团队根据用户身份实施网络分段的机制。一个 SSID 可以为多种用户类型服务——访客、员工、承包商、物联网设备——每种类型根据他们的 RADIUS 认证结果自动放入适当的 VLAN。这是处理持卡人数据的网络的 PCI DSS 要求。
高可用性（HA）RADIUS
一种 RADIUS 部署架构，确保在个别服务器故障时身份验证服务仍然可用。常见的高可用性模式包括主动-主动集群（两台服务器同时处理流量，并进行负载均衡）、主动-被动故障切换（主服务器发生故障时由辅助服务器接管）以及地理分布式冗余（服务器位于不同的物理位置）。
高可用性是任何生产型 RADIUS 部署的关键设计考虑因素。IT 团队必须定义其恢复时间目标（RTO）——身份验证在发生故障后必须恢复多快——并据此设计高可用性架构。云 RADIUS 提供商将高可用性作为内置服务提供；本地高可用性需要明确架构设计和持续维护。
Worked Examples
一家欧洲酒店集团在六个国家经营着 45 家酒店。每家酒店拥有 150-400 间客房，外加会议设施。中央 IT 团队由三名网络工程师组成。他们目前在每家酒店运行虚拟机上的 FreeRADIUS——共 45 个独立实例。一家酒店的证书过期导致在一次大型会议期间出现完全的访客 WiFi 中断。首席技术官希望消除此类事件并减少维护开销。推荐的架构是什么？
推荐架构：集成 Purple Guest WiFi 的云 RADIUS
选择云 RADIUS 提供商，要求具有欧洲数据驻留（以满足 GDPR 义务），并与您现有的 IdP 原生集成。如果酒店集团使用 Azure AD 进行员工身份管理，请选择支持 Azure AD LDAP 连接器的平台。
首先迁移访客 WiFi SSID。访客身份验证是最高量、最低风险的迁移目标。配置 Purple 的 Captive Portal 来处理访客接入（数据捕捉、同意、品牌化展示页），并将已认证会话传递给云 RADIUS 后端。这立即消除了针对访客网络的逐酒店 FreeRADIUS 维护。
逐酒店迁移员工 SSID，从较小的酒店开始。对于每家酒店，在切换生产流量之前，使用测试 SSID 运行两周的并行部署。
在每个酒店配置广域网存活机制。实施 SD-WAN 或双 ISP 连接。配置无线控制器本地缓存员工凭据长达 8 小时，确保酒店运营员工即使在短暂互联网中断期间也能进行身份验证。
迁移后停用每家酒店的 FreeRADIUS 虚拟机。保留虚拟机快照 30 天作为回滚安全网。
通过云 RADIUS 仪表板集中策略管理。一次性定义 VLAN 分配策略，并将其应用于所有 45 家酒店——这项任务以前需要逐酒店编辑配置文件。
预期成果：消除证书过期事件（自动轮换），RADIUS 相关工程时间减少约 40%，并在云提供商拥有本地边缘节点的国家的酒店改善身份验证延迟。
一座拥有 68,000 座位的国家体育场每年举办 30 场大型活动。在售罄比赛期间，峰值并发 WiFi 用户超过 25,000 人。体育场有一条专用的 10Gbps 互联网连接，但 IT 安全团队有一项硬性要求：所有身份验证日志必须保留在英国境内，且不得经过公共互联网。体育场还为特许经营点运行一个符合 PCI DSS 标准的销售点网络。合适的 RADIUS 架构是什么？
推荐架构：采用主动-主动集群和托管灾备的本地 RADIUS
在体育场内部数据机房部署主主动-主动 RADIUS 集群。使用两台物理服务器运行 FreeRADIUS，配置为主动-主动模式，通过无线控制器的 RADIUS 服务器列表进行负载均衡。每个服务器应能独立处理全部身份验证负载——在高峰活动入场时，容量应达到每分钟 3,000 次以上的身份验证请求。
在英国境内距离体育场 30 英里的托管设施中部署辅助集群，通过专用私有广域网链路（非公共互联网）连接。这提供了站点级灾难恢复，同时不违反数据主权要求。
为 PCI DSS 环境实施分段，为销售点 SSID 设置专用 RADIUS 策略。通过 RADIUS 属性将 POS 设备分配到专用 VLAN。确保 POS 身份验证的 RADIUS 计费日志至少保留 12 个月，并存储在本地以符合 PCI DSS 要求 10。
为所有员工和 POS 设备身份验证实施 EAP-TLS。部署内部证书颁发机构（Microsoft ADCS 或同等产品）来颁发和管理客户端证书。配置自动证书续订，并设置提前 90 天的警报。
在接入点和本地 RADIUS 集群之间部署 RadSec（基于 TLS 的 RADIUS），以加密内部网络上的身份验证流量——考虑到高密度公共环境，这一点尤为重要。
在大型活动前预先配置容量。与体育场活动运营团队合作，提前 72 小时获取确认的出席人数，并根据预期的峰值身份验证速率验证 RADIUS 服务器容量。
预期成果：高峰活动入场时亚毫秒级身份验证延迟，完全符合数据主权要求，PCI DSS 合规的身份验证日志记录，以及通过主动-主动集群架构实现 99.99% 以上的可用性。
Practice Questions
Q1. 一家全国性药房连锁店在英国经营着 320 家门店。每家门店只有一家主要 ISP 提供的单一互联网连接，没有故障切换。该连锁店使用 Microsoft 365 和 Azure Active Directory 进行所有员工身份管理。8 名工程师组成的 IT 团队目前管理着每家门店虚拟机上运行的 FreeRADIUS 实例。首席信息安全官已指出，23% 的门店的 RADIUS 证书将在 90 天内到期。首席技术官希望解决这一问题并减少持续的维护开销。您推荐哪种 RADIUS 架构，迁移前需要的最关键的基础设施变更是什么？
Hint: 请仔细考虑广域网弹性要求——如果部署云 RADIUS 后互联网连接中断，店内运营会发生什么？
View model answer
推荐架构：与 Azure Active Directory 集成的云 RADIUS，取代 320 个 FreeRADIUS 实例。鉴于现有的 Microsoft 365 部署，Azure AD 集成很直接，而且云 RADIUS 通过自动轮换能立即解决证书管理危机。
迁移前最关键的的基础设施变更：广域网弹性。目前每家门店只有单一 ISP 连接，没有故障切换。云 RADIUS 完全依赖互联网连接。在迁移任何门店之前，应实施具有双 ISP 故障切换的 SD-WAN，或至少配置无线控制器本地缓存员工凭据 8-12 小时。否则，失去互联网连接的门店无法对员工进行公司网络的身份验证——可能阻断对销售点系统、库存管理和其他网络相关运营的访问。
迁移顺序：(1) 在所有 320 家门店部署 SD-WAN 或凭据缓存。(2) 首先迁移证书即将到期的 23% 的门店——这解决了即时风险。(3) 以每周 20-30 家的批量迁移剩余门店。(4) 迁移后停用 FreeRADIUS 虚拟机。预期成果：证书过期事件为零，RADIUS 相关工程时间减少 60-70%，所有 320 家门店实现集中策略管理。
Q2. 一个会议中心运营商经营着一个可容纳 5,000 名代表的旗舰场馆。该场馆每年举办 200 场活动，从小型董事会到大型国际会议。在大型活动期间，高峰并发 WiFi 用户可达 4,500 人。该场馆有一条 1Gbps 专用互联网连接，SLA 为 99.9%。IT 团队由两名网络工程师组成。没有特定的数据主权要求。当前的本地 FreeRADIUS 服务器已接近使用寿命。他们应该用新的本地部署替换它，还是迁移到云 RADIUS？
Hint: 既要考虑峰值负载情况，也要考虑团队规模。单个站点 4,500 名并发用户是否强有力地支持本地部署，还是团队规模和管理开销会打破平衡？
View model answer
推荐架构：云 RADIUS。尽管是单站点、高密度场景，但 IT 团队规模小（2 名工程师）、没有数据主权要求以及可靠的专用互联网连接的组合使得云 RADIUS 成为更强的选择。
推理：4,500 名并发用户的峰值负载完全在企业云 RADIUS 平台的吞吐量容量之内，这些平台的设计目标就是处理更高的量。云路由带来的额外 5-20 毫秒延迟在会议环境中是感觉不到的。具有 99.9% SLA 的 1Gbps 专用互联网连接为依赖云 RADIUS 提供了足够的广域网可靠性。
决定性因素是团队规模。两名工程师管理本地 FreeRADIUS 替换——包括硬件采购、操作系统加固、证书管理、EAP 配置和持续维护——对于一个规模较小的团队来说意味着巨大的持续开销。云 RADIUS 将其简化为策略管理，使两位工程师能腾出时间专注于场馆更广泛的网络基础设施需求。
实施说明：在无线控制器上为场馆运营员工 SSID 配置凭据缓存，以便在任何短暂的互联网中断期间提供生存能力。确保云 RADIUS 提供商拥有英国或欧洲边缘节点，以最小化高密度活动场景下的身份验证延迟。
Q3. 一个地区性的 NHS 信托基金在一个县内运营着 12 家医院。身份验证要求包括：(1) 通过 802.1X 和 EAP-TLS 的员工访问临床网络，(2) 通过 Captive Portal 的访客/患者 WiFi，以及 (3) 通过 MAC 认证旁路的医疗设备认证。该信托基金的信息治理团队要求所有患者相关数据，包括身份验证日志，必须保留在英格兰的 NHS 批准的数据中心内。该信托基金使用本地 Active Directory，目前没有迁移到 Azure AD 的计划。您推荐哪种架构？
Hint: 这个场景有多个硬性限制。逐一识别它们，并判断是会完全排除云 RADIUS 还是只是部分排除。
View model answer
推荐架构：混合模式——临床员工和医疗设备身份验证使用本地 RADIUS；访客/患者 WiFi 使用云 RADIUS（符合 NHS 标准）或本地方案。
约束分析：
- 数据主权（英格兰 NHS 批准的数据中心）：这排除了大多数商业云 RADIUS 提供商，除非它们提供符合 NHS 要求的数据驻留方案。一些提供商提供 NHS 特定部署；这些应予以评估。如果没有合规的云选项，所有身份验证都需要本地部署。
- 本地 Active Directory 无云同步：这是云 RADIUS 集成的一个硬性限制。没有 Azure AD Connect 或同等工具，云 RADIUS 无法查询该信托基金的员工目录。员工身份验证需要本地 RADIUS。
- 临床员工 EAP-TLS：本地 FreeRADIUS 和 NPS 均支持。需要内部 PKI（对于 AD 集成环境，推荐 Microsoft ADCS）。
推荐部署：在 12 家医院各部署一对主动-被动模式的本地 RADIUS（NPS 或 FreeRADIUS），与本地 Active Directory 集成。使用 RADIUS 分配的 VLAN 将临床、行政和医疗设备流量进行分段。对于访客/患者 WiFi，部署 Purple 的 Captive Portal 进行符合 GDPR 的数据捕获和同意管理——这不需要 RADIUS 进行访客身份验证，从而完全规避了访客网络的数据主权限制。医疗设备 MAB 策略在本地 RADIUS 服务器上管理，MAC 地址列表通过配置管理工具集中维护。
需要缓解的关键风险：12 个站点的 EAP-TLS 证书管理。部署 Microsoft ADCS，并通过组策略自动进行证书注册，以确保所有临床设备自动获取和更新证书。