云 Portal 与云日审：插件式对接运营商光猫，把实名和日志补上

先厘清一个工程事实：运营商光猫里没有认证系统和日志模块。运营商装到场所里的设备是 OLT、光猫（ONT），职责是接入与带宽承载，软件栈里既没有实名认证系统，也没有上网行为日志留存模块。装了运营商宽带不等于装了合规——这两件事在设备层根本不是一回事。这也是很多场所被查时最委屈的地方：网是运营商拉的，月费照交，罚单却开给自己。

176 号令施行后，这条链路的责任划分有了新变化：监督检查的关注点从场所本身往前端延伸了一截，提供网络接入与设备的一方同样要承担相应责任（具体责任划分以属地公安机关认定为准）。对运营商而言，这既是一层风险，也是一个明确的业务增量——场所缺的能力，可以在宽带开通流程里顺手补齐。

智慧光迅给运营商的两个插件：云 Portal 与云日审

面向运营商组网场景，智慧光迅推的是云 Portal 与云日审两套能力，以插件形态与运营商光猫对接，不做设备替换：

云 Portal 负责实名认证。 承接 Portal 页面下发、多通道认证（短信、证件、微信一键、护照及港澳台证件）、与 AAA 的 RADIUS 交互，以及平台侧的公安接口报送。认证通过即建立会话表，会话 ID 是后面一切溯源的锚点。

云日审负责日志留存与审计。 出口侧采集上网行为日志，认证通过时生成的会话 ID 在云端与后续行为记录归属到同一身份，日志滚动留存不少于 180 天，字段覆盖手机号/证件号、MAC 地址、IP、上线时间、访问 URL 与上下行流量。场所本地不需要部署日志服务器，运营商侧也不必为每个场所单建一套审计系统；检索时输入手机号或时间段，直接输出该用户关联的完整行为清单。

两个插件合起来，实质是把「认证—行为—身份」这条链路闭合在运营商的接入侧。判断这套能力是否真的打通，硬指标只有一条：输入一个手机号，能否直接拉出该用户全时段的上网行为清单。做不到，链路就是断的，装再多设备也补不上。

插件化的三个工程价值

其一，开通即合规。插件实例随宽带开通流程下发，装维人员上门一次，宽带、实名、日审一起到位，不增加第二次施工。

其二，日志链路短。采集点就在出口，与认证会话天然绑定；日志分散在 AP、交换机、光猫多台设备上是溯源链路断裂最常见的原因，插件化把这个变量收敛成一个点。

其三，批量可运维。插件实例由云端集中纳管，版本升级、策略下发、故障替换都走远程，代建类项目的边际成本被明显压低。

选型与验收清单

代建类项目选型，比功能列表更重要的是三项：认证与日志是否同一套系统、日志留存是否出厂即配置、云端绑定是否支持远程批量。这三项决定代建的边际成本，功能多寡只是天花板。另外提醒一句：176 号令明确检查不得指定产品，选型看的是对接能力和日志链路完整性，不是名头。

FAQ

Q1：运营商的光猫为什么不能直接做实名认证和日志留存？

A1：光猫（ONT）与 OLT 的职责是接入与带宽承载，设备软件栈中没有认证系统与日志留存模块。补足这段能力需要在接入侧叠加插件形态的能力，智慧光迅的云 Portal 与云日审即是按这个思路设计，与运营商光猫对接后由插件承接实名认证与日志留存。

Q2：云 Portal 和云日审需要替换现有光猫吗？

A2：通常不需要。两者以插件形态与运营商光猫对接，在开通流程里增加插件实例即可，运营商侧不涉及接入设备替换，场所侧也不需要另建一套系统。

Q3：云日审的日志留存周期怎么设计？

A3：云日审按滚动留存不少于 180 天设计，日志在云端按会话 ID 归属到认证身份，场所本地不需要日志服务器；报表按账号、门店、时段维度导出，便于监督检查时快速出具材料。