网络身份认证新规下平台不得索要明文信息：技术逻辑、合规边界与泄露风险分析

一、问题的提出：实名认证为何成为泄露重灾区

过去十余年，互联网服务的实名制要求逐步覆盖社交、电商、内容、金融等几乎所有需要用户登录的场景。其典型实现方式极为统一：用户在注册或首次使用某项功能时，手动填写姓名与身份证号码，部分平台还要求上传身份证正反面照片，甚至配合手持证件照进行人工审核。

这套流程在业务上简单直接，但在安全层面存在一个结构性缺陷：身份明文的采集、传输、存储、使用与销毁，全部由分散的平台自行完成。这意味着：

• 每一个接入实名制的平台，都会形成一份独立的身份证明文数据副本；
• 中小平台的安全防护能力参差不齐，日志、数据库、备份文件、客服系统都可能成为泄露入口；
• 内部人员倒卖、外部黑客拖库、第三方共享扩散，构成多条并行的泄露链路；
• 一旦明文身份信息流入黑产，可被用于注册虚假账号、申请网络贷款、实施电信诈骗等二次犯罪。

从数据安全视角看，这不是某一家平台的问题，而是“明文身份信息多点留存”这一模式本身的系统性风险。国家网络身份认证公共服务的加快推广，正是针对这一模式提出的替代方案。

二、核心变化：从“明文提交”到“脱敏核验”

结合《国家网络身份认证公共服务管理办法》的相关要求，可以将新规的核心逻辑概括为一句话：实名认证被拆分为两套并行的模式，平台原则上不再获取用户的明文身份信息。

2.1 传统模式与网号模式的对比

维度	传统实名模式	网号脱敏核验模式
用户提交内容	姓名、身份证号、证件照片	在认证应用中完成一次核验
平台获得内容	明文身份信息	核验结果（通过/不通过）
数据存储位置	各平台自建数据库	国家级安全服务器
平台可见性	完全可见	仅见加密网号，不可见明文
用户控制力	较弱，难以撤回	可要求删除历史留存数据

2.2 网号机制的工程含义

用户在完成一次实名与人脸核验后，系统会生成一串加密的网号（数字代号）。真实姓名与身份证号仅保存在国家级安全服务器中，普通互联网平台在调用核验能力时，只能得到“身份核验通过/不通过”这一结果。

用伪代码表示，传统模式与网号模式在平台侧的数据流差异大致如下：

// 传统模式：平台持有明文
user.register(name, idCardNumber, idCardPhoto)
platform.db.save({ name, idCardNumber, idCardPhoto })
platform.verify(name, idCardNumber) -> true / false
// 网号模式：平台仅持有核验结果与网号
user.completeAuthInNationalApp() -> networkId
platform.requestVerify(networkId) -> { result: true / false }
// 平台无法获得 name、idCardNumber、idCardPhoto

对开发者而言，这意味着实名认证的集成方式将从“收集并校验用户输入”转向“调用可信核验接口并接收布尔结果”。平台侧不再需要设计身份证字段的存储结构，也不再承担明文身份数据的保管责任。

三、平台侧的三条硬性约束

新规对平台提出了明确的合规边界，可归纳为三条：

3.1 日常场景：只收结果，不收明文

在账号注册、软件实名、普通线上核验等日常场景中，平台只能收到核验结果，不能获取身份证号码与姓名。这就是“实名不显名”的含义——业务上完成了实名要求，但技术上不暴露身份明文。

3.2 法定特殊场景：需单独同意方可获取明文

只有在法律强制要求的情形下，例如银行开户、办理营业执照等，并且经过用户单独同意，平台才可以获取明文身份信息。若用户不同意，平台不得强制索要身份证号或证件照片。

这一条对产品设计的影响在于：同意必须是单独、明确、可拒绝的，不能将其打包进笼统的用户协议中，也不能以“不提供就无法使用”的方式变相强制。

3.3 不得无差别留存，支持历史数据删除

平台不能再以“实名制”为由，无差别留存用户的身份证原件信息。接入国家网络身份认证后，用户有权要求平台删除此前留存的身份证数据。这意味着平台需要具备：

• 身份明文数据的分级分类管理能力；
• 按用户维度定位并删除历史身份数据的能力；
• 删除操作的可审计记录，以应对合规检查。

四、能降低信息泄露风险吗：风险模型分析

要回答“能否降低泄露风险”，需要从泄露面、泄露价值和泄露后果三个维度分析。

4.1 泄露面收缩

传统模式下，泄露面等于“所有采集过明文的平台数量”。网号模式下，明文身份信息集中保存在国家级安全服务器，平台侧不再形成明文副本。采集点从成百上千个收敛为单一受控节点，攻击面显著减小。

4.2 泄露价值下降

即使平台侧发生数据泄露，攻击者获取到的主要是网号与核验记录，而非可直接用于办贷、注册的姓名与身份证号。网号本身是加密代号，脱离核验体系后难以直接变现，黑产的利用成本随之上升。

4.3 泄露后果可控

明文身份信息一旦泄露，往往具有不可撤销性——身份证号无法像密码一样更改。网号机制下，用户可以通过认证应用管理授权关系，并对平台侧历史数据提出删除要求，这在某种程度上提供了“事后补救”的能力。

需要客观指出的是，网号模式并非消除所有风险。核验接口的可用性、网号与用户身份的绑定关系、认证应用自身的安全性，仍然是需要持续关注的技术课题。但从整体风险模型看，它将“多点明文留存”转变为“集中脱敏核验”，方向上是收敛而非扩张。

五、开发者与企业的适配建议

面对这一变化，开发团队可以从以下角度提前准备：

1. 梳理现有身份数据资产：盘点哪些系统采集、存储了身份证明文，评估删除与迁移成本。
2. 改造实名认证链路：将“收集明文+自行校验”逐步替换为“调用核验能力+接收结果”。
3. 重构同意与授权流程：为法定特殊场景设计单独同意机制，确保可拒绝、可撤回。
4. 建立数据删除能力：支持按用户维度删除历史身份数据，并保留审计日志。
5. 加强日志脱敏：确保核验过程中的日志、监控、告警不落入明文身份信息。

在云上环境中，可结合通用的密钥管理、访问控制、日志服务与数据分级分类能力，构建符合合规要求的身份数据处理体系。例如，将核验结果与业务账号绑定，而将网号作为不可逆的关联标识，避免在业务库中冗余存储任何明文身份字段。

六、结语

国家网络身份认证的加快推广，本质上是一次身份数据治理模式的切换：从“平台各自保管明文”转向“国家集中核验、平台脱敏使用”。它回应了长期以来个人信息泄露的主要源头问题，也为开发者提供了更清晰的合规边界。对用户而言，这意味着更少的明文暴露；对平台而言，这意味着更轻的数据保管责任与更明确的删除义务。能否真正降低泄露风险，取决于认证体系的安全运营、平台的合规落地，以及用户对自身授权关系的主动管理。三者协同，才是这套机制发挥效力的前提。