企业官网建设流程全解析

简介：《C0131国家政务服务平台统一身份认证隐私保护要求》面向政务服务平台建设方、统一身份认证系统开发与合规人员，以及关注个人信息保护的技术研究者，给出统一身份认证场景下隐私数据定级、判定、使用和责任划分的规范依据。资源为1个PDF文件，约188KB，正文围绕一级至三级隐私数据分级展开，细化了隐私数据收集、保存、使用、加工、共享披露、导出输出及归档销毁等环节的操作边界，并列出合法性、最小必要、知情同意、安全保护等基本原则，附录还提供自然人身份信息隐私判定说明。现有818人学习下载，可用于政务系统隐私保护方案设计、制度编写、接口与数据流梳理以及合规自查时对照参考。

1. 一份 2018 年的隐私标准，为什么现在被重新翻出来

统一身份认证的隐私保护要求，核心就一句话：把「谁在什么情况下能看到你的什么信息」写成了可执行的分级规则。这份编号 C 0131-2018 的国家政务服务平台标准，2018 年 12 月 28 日发布并同日实施，全文把自然人身份信息切成一级、二级、三级，逐条规定收集、存储、显示、加工、导出、销毁的动作边界。它不像新产品发布那样抓眼球，但对做政务系统对接、做身份中台、做数据合规的团队来说，这是一份会被反复引用的底稿。值得关注的原因很直接：当身份认证从「一个系统一个账号」走向跨节点互通，隐私风险不再来自单点泄露，而来自数据在节点之间流动时没人说得清哪一级该加密、哪一级该脱敏、哪一级根本不该被二次收集。这份标准给出的正是那套判定依据。

2. 三级定级：把身份信息拆成可操作的颗粒度

2.1 一级、二级、三级到底怎么分

标准把隐私数据分成三层，分类逻辑不是「敏感程度从高到低」这么模糊，而是按「能不能对应到自然人实体」这个硬标准来切。

一级数据是不能对应到自然人实体身份信息的数据。附录 A 的判定表里，证件类型、证件散列码、实名等级、实名核验日期、性别、民族、国籍、用户类型都归在這一层。这类数据单独拿出来无法指向具体某个人，泄露后的直接伤害有限。

二级数据是可用于标识自然人实体、且较公开的身份信息。姓名、登录账号、手机号、证件有效日期和失效日期、社保卡发卡地、邮箱、注册时间、生日、学历、支付宝号、微信号、工作单位、第二和第三手机号，都在这一级。这些信息能指向人，但在日常场景里本身就处于半公开状态。

三级数据同样能标识自然人实体，但隐私性明显更高。证件编号、社保卡号、户籍地址、居住地址属于这一级。这几项的共同点是：一旦泄露，可被用于精准冒用或定位，伤害不可逆。

提示：注意附录 A 里一个容易被忽略的设计——证件编号是三级，但证件散列码是一级。同一份信息的不同形态被定了不同级别，这是整份标准最关键的思路之一。

2.2 生物特征和访问记录被单独拎出来

第 5 章在附录 A 的定级表之外，又补了两类数据的判定规则，这块在实际对接中最容易扯皮。

生物特征数据按可识别性分层：人脸数据、声纹数据这类相对公开的生物特征属于二级；指纹数据这类可作为认定个人信息的生物特征属于三级。也就是说，刷脸和按指纹在合规处理上不是一个量级，指纹的存储、传输要求要按三级数据走。

访问记录被明确划为二级数据，范围包括个人用户在统一身份认证体系中的登录记录、政务门户访问记录。这一条的价值在于堵住一个常见操作：把访问日志当成「非个人信息」随便分析。标准的态度很明确，登录时间和访问路径组合起来就能勾勒一个人的行为轨迹，它属于隐私数据。

另外还有一条兜底条款：未满 14 岁的儿童，可提升数据隐私级别。这条没有给出固定升几级，但方向清楚——未成年人相关数据在判定时要从紧。

2.3 定级不是标签，直接决定后面每一个动作

很多人读这类标准只记住分类表，忽略了定级是后续所有条款的开关。举几个直接的联动：存储环节，二级数据必须加密存储；三级数据在互联网区必须用不可逆加密存储，不得明文也不得可逆加密，且不可逆加密必须用国家节点统一提供的散列函数。显示环节，二级以上数据默认脱敏，脱敏范围不少于 50%（手机号除外）。导出环节，导出管理制度要分别定义少量、批量、大批量导出的流程，而划分依据就是数据级别。

从行业角度看，这种「定级驱动全流程」的写法比笼统的「加强保护」有用得多。它意味着开发团队在写代码时可以直接把级别当成字段属性，用一张配置表驱动加密、脱敏、审计三条链路，而不是每个接口靠人肉判断。

3. 采集与显示：最小化和脱敏被写成了硬约束

3.1 禁止重复收集，这条改变了系统对接的顺序

第 6.2 条关于收集的规定，含金量最高的是这一句：地方和部门节点应优先查询并使用国家节点已经存在的个人信息，禁止重复收集用户个人信息，仅当国家节点无此用户信息时才可进行收集。

这条把系统对接的默认顺序定死了——先查、查不到再采。以前不少地方节点的做法是本地先建一套用户表，注册时自己收一遍，需要时再跟国家节点比对。按这份要求，这个顺序是反的，本地重复收集本身就是违规动作。

收集方式也被限定了。国家节点只有两条收集路径：用户注册与修改、地方和部门节点上传。各节点在注册时必须向用户提供隐私保障协议，明示收集哪些信息，并由用户明确确认，协议模板参照 GB/T 35273-2017 和国办函〔2016〕108 号所列模板。知情不是弹一行字，是要有确认动作。

还有一句责任划分值得留意：各节点所收集的数据，由各节点自行负责安全。谁收的谁负责，不存在把数据交给上级节点就转移了责任。

3.2 全文显示的例外只有两种，其余一律脱敏

第 6.4 条 a 款把「什么时候可以不脱敏」收得很紧，只有两种情况允许二级以上隐私数据全文显示：

一是用户注册时填写的内容，允许全文显示；二是用户查看和修改个人信息时，应在二次认证后允许全文显示。二次认证的级别不低于包含手机短信验证码的双因子认证，修改信息宜使用实名等级四级（实人认证）。

除此之外，系统默认必须脱敏显示二级以上数据，脱敏范围不少于 50%，手机号除外。标准直接给了示例，这在实际开发中几乎可以直接当测试用例用：

这张表里有个细节值得单独说：地址类字段的规则是「长度大于 12 时只显示前 6 位，不足 12 位显示不超过 50%」。这是一个按长度分支的规则，实现时不能只写一个固定截断，否则短地址会脱敏过度或不足。

3.3 互联网区明文只能是临时的，且带数量和时间上限

标准没有一刀切禁止互联网区出现明文，而是给了四个带明确上限的临时场景，每个都有销毁要求：

实名核验场景，可临时获取用于提交核验的未加密数据，禁止使用超出核验需要的其他数据，一次核验只允许获取一条个人信息，核验完成后销毁。

注册信息上报场景，地方和部门节点可将本地注册用户信息临时保存到互联网区，总数不得超过 1000 条，时间不超过 24 小时，上报时以明文上报全量数据，上报完成后销毁；国家节点收到后可在互联网区临时保存不超过 8 小时，处理完销毁。

用户信息查询场景，地方和部门节点通过用户标识向国家节点查询指定用户信息，结果以明文下发，查询发起节点应在收到信息 2 小时内完成处理并销毁互联网内明文；查询接口只允许接收和输出一个用户的信息，不得存在一次查询多个用户的服务。

通讯安全场景，所有涉及未加密个人信息的传输，按 C 0111-2018 的 8.3 和 C 0113-2018 第 7 章的安全通讯规定执行，互联网和电子政务外网都按此处理。

这些数字——1000 条、24 小时、8 小时、2 小时、一条——是可以直接写进监控告警阈值的。从工程角度看，这比「及时销毁」有用得多。下面这段伪代码示意如何把这类时限约束落成可检查的逻辑：

# 互联网区明文临时缓存的合规检查示意（参数取自标准第 6.4 条 b 款） LIMITS = { "register_upload": {"max_rows": 1000, "max_hours": 24}, # 地方节点上报 "national_receive": {"max_rows": None, "max_hours": 8}, # 国家节点接收后处理 "user_query": {"max_rows": 1, "max_hours": 2}, # 单用户查询结果 } def check_temp_cache(scene, rows, created_at, now): rule = LIMITS[scene] # 条数上限：None 表示标准未对此场景设条数限制 if rule["max_rows"] is not None and rows > rule["max_rows"]: return "reject: rows exceed limit" # 时限上限：超时即触发强制销毁，并记录审计日志 if (now - created_at).total_seconds() > rule["max_hours"] * 3600: return "destroy: ttl exceeded" return "ok"

这段逻辑的关键不在于代码本身，而在于它体现了标准的一个隐含要求：临时明文必须带 TTL 和条数上限，且销毁动作要能被审计。真实系统里还要补一条——销毁要覆盖内存残留、缓存和临时库表，这一点第 6.8 条有明确要求。

4. 加工、共享与导出：三处最容易被踩空的边界

4.1 关联分析被全面禁止，例外只有三类

第 6.5 条写得非常硬：统一身份认证系统内所有节点禁止以两个或两个以上用户的个人信息进行关联分析，包括以散列值进行分析。

这条限制的范围比很多人想象的大。不只是「把两个人的身份证号放一起比对」不行，用散列值做关联也不行——这就堵死了「我用散列后的标识做用户画像关联，反正看不到明文」这条路。

例外只有三类：一是对个人信息通过脱敏、散列化处理等方式进行安全加强；二是用户对政务服务门户、业务系统的访问记录，只用于异常登录等安全分析和异常处置，禁止用于其他用途；三是允许对个人信息的散列值进行加工。

第二条例外特别值得注意，它给访问记录的用途上了一把锁：只能用于安全分析和异常处置。拿访问记录做活跃度统计、做推荐、做运营分析，都在禁止范围内。这和前面把访问记录定为二级数据是配套的。

4.2 禁止共享披露，导出却要留痕一年

第 6.6 条一句话封死：禁止各级节点对用户数据进行公开披露、转让和共享用户个人数据。没有例外条款。

但第 6.7 条承认导出是现实需求，所以转向管控流程：各节点应制定数据导出管理制度，明确二级和三级隐私数据对少量导出、批量导出、大批量导出的定级定义及相应管理流程，明确责任人，数据导出记录至少保存一年。

导出记录要包含的信息也列了：数据导出用途、时间、操作地点、人员、授权信息，以及导出文件大小、数据数量、所有个人信息的标识（散列值）。注意最后一项——连导出文件里包含哪些人的信息都要以散列值形式记下来，这等于给每次导出建立了可追溯清单。

这套设计的逻辑是：不让数据流动不可能，那就让每一次流动都留痕到能追责的程度。从行业角度看，这与近年数据安全领域强调的「可审计」思路一致，只是这份标准在 2018 年就落到了字段级。

4.3 销毁要不可恢复，日志也要留一年

第 6.8 条对销毁的要求是：超出使用时限或完成生命周期后归档或销毁；归档后形成离线文档，不可在线查询、获取；销毁采用不可恢复方式，保证不可从存储介质中恢复；销毁后不存在内存残留、缓存、临时文件、临时库表等剩余信息。

「内存残留、缓存、临时文件、临时库表」这四项被点名，是很多团队翻车的地方。删了数据库记录，但 Redis 里还有一份缓存，临时表没清，日志文件里留着明文——这些都算没销毁干净。

配套的是第 6.9 条：隐私数据的收集、使用、加工、输出等各个环节均应记录日志，日志保存时间不少于 1 年，超出时效后及时归档。日志本身也可能含隐私数据，所以它既是审计依据，也是需要被管理的对象。

5. 常见误读：这份标准最容易被读错的五个地方

5.1 误读一：以为级别越高、加密越强就完事

误区是把定级理解成「打个标签，然后统一上加密」。实际条款里，不同级别在存储、显示、导出三个环节的动作完全不同：三级数据在互联网区必须不可逆加密，在电子政务外网是加密存储——同一份数据在两个网络区域的处理方式不一样。如果只按级别配一套策略，跨网场景就会出错。

怎么看：把「数据级别 × 所在网络区域 × 操作类型」当成三维坐标去查要求，而不是一维的级别表。

5.2 误读二：把「脱敏不少于 50%」理解成字符数砍一半

标准的 50% 是下限原则，具体字段有具体规则，而且规则之间不统一。姓名显示最后 1-2 个汉字，身份证显示后四位，邮箱显示 @ 及之后部分，地址按长度分支。如果实现时统一按「隐藏一半字符」处理，姓名和邮箱这类字段的显示效果会不符合要求，甚至暴露过多。

怎么看：以第 6.4 条给出的字段级示例为准，把它当验收清单逐条比对，而不是自己推导一套通用算法。

5.3 误读三：认为禁止共享就等于数据不能出本节点

第 6.6 条禁止的是公开披露、转让和共享用户个人数据，但第 6.4 条 b 款明确允许查询、上报等流转，第 6.7 条允许在制度约束下导出。所以准确理解是：数据可以在授权和留痕的前提下按既定通道流动，禁止的是任意的对外提供。

怎么看：区分「通道内流转」和「对外共享」。前者有接口规范、有时限、有销毁要求；后者一律禁止。把这两件事混为一谈，要么过度保守导致业务做不了，要么借「流转」之名行「共享」之实。

5.4 误读四：忽略密钥管理里的人员约束

第 6.3 条 d 款关于密钥的规定，最容易只读到「用 SM2、SM4 算法」就跳过。完整要求是：密钥必须存放于符合 GM/T 0051-2016 的系统或设备中；密钥由专人管理；密钥管理人员不得从事数据操作、加工、使用等工作；密钥管理人员应是本节点正式工作人员，不得来自软件开发商、服务商等第三方机构。

最后这一条在实操中冲击不小——意味着密钥托管不能默认交给外包团队或云服务商的人员来管。

怎么看：把密钥管理当成岗位设计问题，而不只是技术选型问题。系统上线前先确认这个岗位由谁担任、是否满足身份约束。

5.5 误读五：把这份标准当成一次性合规检查

第 8.2 条写的是：国家节点按本要求对各节点组织定期或不定期检查，不符合本要求的节点将暂停接入服务并限期整改。这是一条带后果的条款，不是建议。

怎么看：把这份标准当持续运行的约束，而不是上线前过一遍的文档。特别是日志保存一年、导出记录保存一年这类有时间跨度的要求，只有在日常运行中持续满足才算数，临检前补是补不出来的。

6. 趋势判断：身份认证的隐私要求正在从「原则」走向「参数」

把这份 2018 年的标准放到今天的语境里看，它最超前的地方不是提出了隐私保护原则——那在同期文件里并不稀缺——而是把原则翻译成了可测量、可检查、可追责的参数。1000 条、24 小时、8 小时、2 小时、50%、1 年、一条查询，这些数字构成了一个可以直接写进代码和监控的约束集。

从行业角度看，这条演进线还会继续。身份认证体系越互通，单点自律就越不够用，规则必须细到能自动化执行。对做政务系统对接的团队，短期影响集中在三件事：一是把用户信息的获取顺序改成先查后采，消除本地重复收集；二是给每个字段打上级别属性，用配置驱动加密和脱敏，而不是散落在各接口里；三是把临时明文的 TTL 和条数上限做成基础设施能力，而不是每个模块各写一遍。

对管理层来说，值得关注的信号是责任条款的落点。第 7 章明确各节点对本系统内收集、存储、使用的用户信息负责，数据被篡改或丢失由系统所在节点通过权威机构技术鉴定或查实确定责任；一旦发生泄露，视泄露数据的隐私级别进行上报处置。这意味着隐私级别不只是内部管理标签，它会直接影响事件上报的定性和处置路径。定级定错，出事时的上报口径就是错的。

还有一条容易被低估的趋势：这份标准对「关联分析」和「访问记录用途」的限制，实际上是在身份认证这个基础设施层面预先排除了一些后来很常见的数据利用方式。对产品侧的含义是，基于身份数据的增值分析空间被压得很窄，做这类设计前先对照第 6.5 条，能省掉很多返工。

我自己的习惯是，每接一个涉及身份信息的系统，先把附录 A 那张判定表抄成一份字段清单，逐字段标注级别、所在网络区域、允许的显示形式、存储加密方式和保留期限，五个维度列成一张表再开工。有次图省事跳过这步，直接在代码里按「敏感/不敏感」两档处理，结果地址字段在短地址场景下脱敏不足，联调时被打回来重做，那次的教训让我后来每次都用这张表强制走一遍。这份标准的原文加上附录 A 的完整判定表，值得放在手边随时对照，需要的话可以下载下来留着。希望帮到你。

本文还有配套的精品资源，点击获取