WiFi网络计费系统最值钱的东西不是代码本身，不是服务器配置，甚至不是商业授权，而是用户数据和个人信息。今年帮一个做公共WiFi运营的公司做安全评估的时候，发现他们的计费系统后台能看到所有用户的明文手机号、上网记录、支付记录，而且管理后台的登录密码是出厂默认的admin/admin123。我让他们IT经理赶紧改密码，他回了一句让我至今记忆深刻的话："反正就我们自己人用，应该没事吧。"

WiFi网络计费系统在数据传输层面有多个环节需要加密保护。首先是Portal认证页面——用户在连接WiFi以后看到的那个认证页面，如果走的是HTTP而不是HTTPS，那么用户在上面输入的手机号和验证码在传输过程中就是明文，任何在同一个局域网内的设备都有可能截获。

很多人觉得Portal页面走HTTPS的实现难度太大，因为要做SSL证书部署、要做HTTPS重定向、要处理各种浏览器的证书验证。但实际上这些都不是技术障碍，市面上成熟的WiFi网络计费系统基本都支持Portal页面的HTTPS部署了。如果一个方案告诉你"HTTP就够了，没什么安全问题"，你应该立刻警觉。

其次是支付回调接口——前面说过必须走HTTPS加签名验证。还有管理后台——只要管理后台走的是HTTP，登录凭证就在网络上明文传输，在同一个网段内的任何设备用Wireshark一抓就是一个用户名和密码。

WiFi网络计费系统的数据库中存储了大量敏感信息：用户的手机号、身份证号（如果涉及实名认证）、设备MAC地址、上网记录、支付信息。这些数据的存储至少要满足几个基本的安全要求。

手机号和身份证号这类个人身份信息，数据库里不应该明文存储。行业内的常见做法是对手机号做AES加密存储，身份证号做哈希加盐后存储（除非涉及公安审计等明确要求保留明文的场景）。上网记录这类行为数据，至少要按最小必要原则来存储——该留的留，不该留的不留，不能为了"以后说不定用得上"而无限期地把所有日志都保存着。

支付信息是另一个需要特别注意的领域。如果系统存储了完整的银行卡号或者第三方支付账号，PCI-DSS或者等保2.0的合规要求就会介入，对系统的安全防护能力有一整套明确的评估标准。一般来说，WiFi网络计费系统只应该存储支付平台的交易流水号，而不存储任何支付敏感信息。

WiFi网络计费系统的管理后台是安全防护最薄弱的一环。很多系统的管理后台就一个登录页面，进去以后所有功能敞开用，没有操作日志、没有权限分级、没有异常行为告警。这意味着任何一个有后台登录权限的人，都可以悄无声息地导出所有用户数据，而系统不会有任何记录。

一个合格的安全设计应该包括：管理后台强制走HTTPS、登录启用双因素认证或多IP限制、所有涉及用户数据的导出操作都必须留下审计日志（谁在什么时间导出了哪些数据）、后台登录IP异常时触发告警。这些要求放在今天已经不是高配了，而是基础的安全基线。数据安全在WiFi网络计费系统里不是一个附加的可选功能，而是从系统设计的第一天起就应该纳入考量的基础能力。用户的数据交到你手里，你就有了保护它们的义务。这不是说大话，而是实实在在的法律责任和商业信誉问题。一次数据泄露事件，可能让一个运营了几年的项目瞬间失去所有用户的信任。安全投入是保险，不是在已经出事以后才想起来补的东西。在实际操作层面，建议在系统上线之前至少请第三方做一次渗透测试和安全评估，重点检查Portal页面的传输加密、数据库的敏感信息存储、管理后台的认证机制和API接口的鉴权逻辑。这些检查花不了太多费用，但能帮你发现自检时看不到的安全漏洞。还有一点很多人忽略——WiFi网络计费系统的日志本身也包含大量敏感信息。Radius日志里可能含有用户的MAC地址和IP地址，Web服务器日志里可能含有认证页面的完整URL参数。这些日志文件的安全保护同样是合规要求的一部分，不能因为是"日志"就觉得不需要保护。日志的保存周期、访问权限、加密存储、是否允许外传，每一项都应该是安全设计文档里明确写清楚的条目，而不是运维的时候临时想起来再处理。除了技术层面的安全措施以外，管理层面的安全制度同样重要。谁有权限导出用户数据、导出数据需要经过什么审批流程、离职员工的管理后台账号什么时候注销、第三方厂商远程排查问题时候的临时账号怎么管控——这些看起来是行政流程的事情，但每一项疏漏都可能带来严重的数据安全事件。