现在大多数WiFi认证系统在宣传的时候都会把"支持云管"作为一个卖点。确实，WiFi认证平台的云化管理带来了部署方便、运维集中、功能迭代快这些好处。但云端化管理也引入了一些传统本地部署里不太需要考虑的安全问题——这些问题不一定会在项目初期暴露，但运行一段时间之后可能变成安全事件。

管理通道和数据通道是否分离

WiFi认证系统在云管模式下，管理通道和数据通道的分离程度直接决定了安全基线。所谓管理通道，就是AP和云平台之间的控制面通信，包括配置下发、状态上报、固件升级等。所谓数据通道，就是用户的认证请求和上网流量。

理想的设计是管理通道和数据通道完全物理分离——AP用单独的管理IP和云平台通信，用户流量不经过云平台。但在一些低价位的云管方案里，为了简化部署，用户的认证请求实际上是先到云平台、再回到本地AC的。这在安全上有两个风险：一是用户的认证数据经过了公网，增加了中间人攻击和流量窃听的可能性；二是云平台一旦被打或者出现故障，认证服务就停了。

评估一个云管WiFi认证方案的时候，必须搞清楚它的流量模型到底是怎样的。如果管理面和数据面混在一起走，那它的适用场景就局限在安全要求不高的场景里，有合规要求的场景不能这么用。

云平台自身的访问控制和账号安全

WiFi认证系统的云管平台，本质上是一个集中管理入口。如果这个入口被人拿到了控制权，攻击者可以做的事情包括：修改所有AP的认证策略、批量踢掉在线用户、甚至下发恶意Portal页面来实施钓鱼攻击。这比攻击一台本地AC的后果严重得多。

云管平台的安全措施至少应该包括这几点：强密码策略加多因素认证、基于角色的访问控制（运维人员和只读查看人员看到的界面不一样）、操作审计日志（谁在什么时间做了哪个配置变更）、API调用的频率限制和IP白名单。这些安全措施看起来是常识，但在实际购买和使用过程中，很多用户并没有逐项确认厂商是否真的做到了。

还有一个容易被忽视的点：厂商的云平台运维人员有没有访问客户数据的权限？如果客户的数据和配置是存在公有云上的，厂商的后台运维人员理论上可以接触到这些数据。需要在合同中明确约定数据访问权限的控制范围和审计方式。

用户隐私数据在云端存储和传输中的保护

WiFi认证系统必然会处理一些用户的隐私数据——手机号、MAC地址、上网时间、位置信息。这些数据如果上传到云端，就涉及数据出境和隐私保护的问题。特别是对于外资企业或者有海外业务的公司，数据存储在哪个云区域、数据流转经过了哪些国家和地区，是在合规上需要非常仔细评估的事项。

一个实际的操作建议是：凡是涉及用户个人信息的数据，尽量留在本地——手机号哈希之后再做云端查询、MAC地址脱敏处理之后再上传、上网行为日志只上传统计结果不上传明细。不一定每一类数据都做本地化处理，但至少在方案设计阶段要有一个明确的数据分类分级策略，哪些数据可以上云、哪些必须留本地，不能用一个"全部上云"来解决所有问题。

API接口的安全暴露面

云管WiFi认证系统通常提供API接口，供客户自己的业务系统做集成——比如酒店可以把自己的PMS系统和WiFi认证系统对接，住客办理入住后自动生成WiFi账号。API接口的安全如果不做好，就可能成为一个攻击入口。

API安全的基本要求包括：所有API必须走HTTPS、必须做客户端身份认证（API Key或者OAuth Token）、接口必须有频率限制、敏感操作（比如批量导出用户数据）需要有二次确认机制。另外就是API的鉴权粒度要做细——调用方应该只能操作被授权范围内的数据，酒店A的API Key不能用来查询酒店B的用户信息。

WiFi认证系统的云管化是一种趋势，带来的便利性是实实在在的。但便利不应该以牺牲安全为代价。在选型和部署的时候，花一些时间把上面这些安全问题逐项确认，比上线之后遇到安全事件再补救要划算得多。 另外还有一个容易被忽视的现实：WiFi认证系统的云管平台如果部署在公有云上，它的可用性就取决于公有云服务商的SLA。云厂商承诺99.9%的可用性听起来很高，但换算下来一年有将近9小时的不可用时间。如果这9小时恰好发生在酒店入住高峰期或者学校上课时间，影响是实实在在的。对于SLA要求更高的场景，可以考虑混合部署方案——认证的核心功能跑在本地、管理和统计功能放在云端，即使云平台暂时不可达，本地认证服务不受影响。这个架构在方案设计阶段就要确定下来，因为涉及到设备选型和部署架构，不是上线之后能临时改的事情。