如何使用 Cloud RADIUS 实现 802.1X 认证

如何使用 Cloud RADIUS 实现 802.1X 认证 Purple WiFi 智能简报 --- 引入与背景（约 1 分钟） --- 欢迎收看 Purple WiFi 智能简报。我是您的主持人，今天我们将深入探讨使用 Cloud RADIUS 实现 802.1X 认证的细节——它是什么、为什么现在很重要，以及如何在多站点资产中实际部署它。 如果您正在为酒店集团、零售连锁店、体育场或公共部门组织管理 WiFi 基础设施，这是一个经常被提及的话题——而且理由充分。威胁形势已经发生变化。共享 PSK 网络越来越被视为一种合规责任，而不仅仅是安全上的不便。监管机构、审计人员和网络保险公司都在对网络访问控制提出更严苛的问题。好消息是，云端交付的 RADIUS 使 802.1X 真正实现了大规模部署，而无需本地基础设施开销，这在以前曾让分布式资产望而却步。 那么，让我们开始吧。 --- 技术深挖（约 5 分钟） --- 首先，让我们确保大家对定义达成共识。IEEE 802.1X 是一种基于端口的网络访问控制标准。它定义了一个位于 OSI 模型第 2 层的认证框架——因此它在设备被授予任何 IP 连接之前运行。这是与应用层认证的关键区别。通过 802.1X，设备在通过确切认证之前无法进入网络。 该协议有三个组成部分。客户端（supplicant）——即终端设备，无论是笔记本电脑、智能手机还是 POS 终端。认证器（authenticator）——通常是您的 WiFi 接入点或托管交换机。以及认证服务器——在现代部署中，这就是您的 Cloud RADIUS 服务。 流程是这样的。设备尝试与接入点关联。接入点不会立即授予完整的网络访问权限。相反，它会打开一个受控端口，并与设备发起 EAP 交换（即扩展认证协议）。设备出示其凭据，可以是用户名和密码、数字证书或基于 SIM 的身份。接入点使用 UDP 上的 RADIUS 协议将该交换转发给 RADIUS 服务器，通常在端口 1812 用于认证，1813 用于计费。RADIUS 服务器根据身份存储（Active Directory、Azure AD 或 LDAP 目录）验证凭据，并返回 Access-Accept 或 Access-Reject 消息。如果接受，接入点将打开端口，设备获得网络访问权限。如果拒绝，它将保持受阻状态。原理很简单，但实现细节极其重要。 现在，EAP 方法的选择是许多部署出错的地方。有几种常用的 EAP 方法，它们具有非常不同的安全属性和运营要求。 EAP-TLS 是黄金标准。它需要双向证书认证——服务器和客户端都出示证书。这完全消除了凭据被盗的风险，因为没有密码可偷。但它需要 PKI 基础设施和向设备推送客户端证书的机制，这通常意味着需要 MDM 解决方案。对于企业 BYOD 环境和高安全部署，这是正确的答案。 带有 MSCHAPv2 的 PEAP 是企业环境中部署最广泛的方法。它只需要服务器端证书，并将凭据交换封装在 TLS 中。它原生兼容 Active Directory，这使得运营非常简单。风险在于，如果用户连接到带有自签名证书的流氓接入点，它很容易受到凭据收集的攻击——因此客户端的证书验证是不可妥协的。 EAP-TTLS 与 PEAP 类似，但在内部认证方法上更具灵活性。在混合设备环境中，当您拥有具有不同客户端能力的 Windows、macOS、iOS 和 Android 设备组合时，它特别有用。 对于传统设备支持——想想旧的 POS 硬件或物联网传感器——EAP-FAST 可以是一个务实的选择，因为它不需要证书，而是使用受保护的访问凭据。 现在，谈谈 Cloud RADIUS 部分。传统上，RADIUS 是一项本地服务——Linux 服务器上的 FreeRADIUS，或 Windows Server 上的 Microsoft NPS。这种模式可行，但它有实际的运营成本：硬件维护、高可用性配置、打补丁，以及在每个需要低延迟认证的站点部署本地基础设施的需求。Cloud RADIUS 显著改变了这一计算方式。 Cloud RADIUS 服务由提供商托管和管理。您的接入点通过互联网将 RADIUS 请求发送到云服务，云服务负责针对您的身份提供商进行认证。对延迟的担忧是现实存在的，但也是可控的——现代 Cloud RADIUS 服务是全球分布的，认证往返通常在 100 毫秒内完成，这对于终端用户来说是察觉不到的。 与身份提供商的集成是关键的依赖关系。大多数 Cloud RADIUS 平台支持 LDAP、LDAPS、SAML 2.0 以及直接的 Azure AD 或 Okta 集成。对于已经运行 Microsoft 365 的组织，Azure AD 集成是自然的选择——您可以获得单点登录、条件访问策略和 MFA 执行，所有这些都融入到您的网络访问控制层中。 对于在员工网络之外还部署了访客 WiFi 的场所，该架构通常将它们划分为具有不同认证策略的不同 SSID。员工网络使用带有企业凭据的 802.1X。访客网络使用 Captive Portal 或社交登录流程。Purple 的平台支持这两种模式，且 WiFi 分析层横跨两者，让您在不损害安全分段的情况下，洞察设备行为、停留时间和网络利用率。 --- 部署建议与常见陷阱（约 2 分钟） --- 让我为您提供实际的部署顺序，并指出我最常看到的失败模式。 首先从您的身份提供商集成开始。在您接触任何单个接入点之前，确认您的 Cloud RADIUS 服务可以针对您的目录进行认证。使用服务帐户进行测试，验证 LDAP 绑定，并确认组群成员身份属性是否正确返回——因为您将需要这些属性用于 VLAN 分配策略。 第二，规划您的证书策略。如果您选择 EAP-TLS，您需要一个 CA，您需要决定是使用公共 CA 还是内部 CA，并且您需要一个用于客户端证书的 MDM 推广计划。如果您选择 PEAP，您需要一个来自受信任 CA（而非自签名）的服务器证书，并且您需要将 CA 证书推送到所有客户端设备，以便证书验证正常工作。这是最容易被跳过并导致安全事件的步骤。 第三，使用正确的共享密钥和服务器 IP 或主机名配置您的 RADIUS 客户端（即您的接入点和控制器）。使用强随机生成的共享密钥，而不是字典词汇。如果您的 Cloud RADIUS 提供商支持 TLS 上的 RADIUS（即 RadSec），请使用它。它会加密传输中的 RADIUS 流量，当该流量穿过公共互联网时，这一点尤为重要。 第四，在全面推广之前先在试点小组中进行测试。大规模的认证失败具有破坏性，且在压力下难以诊断。在 10 到 20 台设备上进行试点，验证认证日志，确认 VLAN 分配正常工作，并检查计费记录是否正确写入。 我最常看到的失败模式包括：客户端上禁用了证书验证，导致中间人漏洞；共享密钥太短或在多个站点间重复使用；未配置 RADIUS 服务器 IP 允许列表，导致来自新站点的认证请求被默默丢弃；以及在证书过期时未更新 MDM 配置文件，导致在更新日发生大规模认证失败。 --- 快速问答（约 1 分钟） --- 以下是我经常被问到的几个问题。 我是否可以在同样拥有不支持 EAP 的物联网设备的网络上运行 802.1X？可以——对于无法运行客户端的设备，使用 MAC 认证绕过作为备用方案，但要将这些设备放在具有严格防火墙规则的受限 VLAN 中。 802.1X 是否取代了 WPA2 或 WPA3 加密？不——802.1X 处理认证。WPA2-Enterprise 或 WPA3-Enterprise 处理加密。您两者都需要。带有 802.1X 的 WPA3-Enterprise 是目前新部署的最佳实践。 对认证的延迟影响是什么？通过配置良好的 Cloud RADIUS 服务，预计每次认证需要 50 到 150 毫秒。对于漫游场景，802.11r 快速 BSS 过渡可以显著减少重新认证的开销。 这符合 PCI DSS 要求吗？在合理分段的网络上，结合 EAP-TLS 或 PEAP 的 802.1X 满足了 PCI DSS 对网络访问控制的要求 1 和要求 8。尽早让您的 QSA 参与进来。 --- 总结与后续步骤（约 1 分钟） --- 总结一下：对于任何需要向审计人员展示网络访问控制、减少凭据泄露的影响范围或在分布式资产中集中管理认证的组织来说，结合 Cloud RADIUS 的 802.1X 都是正确的答案。 部署并非微不足道，但只要准备充分，完全是可控的。首先做好您的身份提供商集成。根据您的设备资产和管理证书的运营能力选择您的 EAP 方法。如果您的基础设施支持，请使用 RadSec。并在大规模推广之前进行测试。 如果您运行的是混合访客和员工网络（大多数酒店和零售运营商都是如此），像 Purple 这样的平台可以让您从单一窗口管理这两种认证模式，且分析层横跨整个资产。 对于您的后续步骤：审计您当前的网络访问控制状况，确定哪些站点仍在运行共享 PSK，并制定分阶段迁移计划。从风险最高的站点开始（那些在 PCI DSS 范围内或处理敏感数据的站点），然后向外推进。 感谢收听。更多技术简报请访问 purple.ai。