简介《国家政务服务平台统一身份认证隐私保护要求》C 0131-2018是一份面向政务服务平台建设方、身份认证系统运维者与隐私合规人员的规范性文件重点解决统一身份认证场景下个人信息如何定级、判定、使用与追责的问题。包内仅含1个PDF文件体积约188KB篇幅紧凑便于检索查阅与内部培训引用。文件系统梳理隐私数据一级至三级定级规则、判定准则及收集、保存、使用、加工、共享披露、导出输出、归档销毁等全流程要求并明确平台、服务提供者与个人信息处理者的责任边界附录A还给出自然人身份信息隐私判定说明可辅助落地执行。已有818人学习适合作为政务服务身份认证项目合规自查、制度编写与风险排查的参考底稿。1. 政务服务平台统一身份认证隐私保护的真正难点政务服务平台统一身份认证隐私保护最容易被误当成一个“加密算法选型”问题——好像把存储换成国密、链路加上 TLS 就完事了。但真在系统里跑过一轮就会知道用户的一张证件信息会同时出现在国家节点、部门节点、地方节点、日志、导出报表和缓存里任何一处以明文落地都是一个敞口。这份标准要解决的不是“怎么加密”而是“明文最多能存在多久、以什么形态存在、谁有资格看见、谁能把两条数据拼起来”。它用三级定级、默认脱敏、临时明文时限、密钥三权分立和关联分析禁令把数据从“静态加密”推向“全路径管控”。搞懂这套设计等于搞懂政务级身份系统里数据流的约束条件。2. 隐私数据定级为什么证件编号必须散列存储而姓名只需可逆加密定级是整套标准的起点。定错了后面的存储、脱敏、密钥、审计全部跟着错。而这份标准最有意思的地方在于它判定一个字段的隐私级别看的不是字段名而是“这个值在系统里以什么形态存在”。2.1 判定锚点是“可识别性”不是字段类型标准把隐私数据分成三级定义非常克制一级是“不能对应到自然人实体身份信息的数据”二级是“可用于标识自然人实体身份且较公开的数据”三级是“可用于标识自然人实体身份且具有较高隐私性的数据”。三句话的共同锚点只有一个——能不能把这个字段和一个具体自然人挂上钩。按这个锚点看附录 A 的表 A.1会发现几个反直觉的判定自然人证件类型是一级数据。因为“身份证”这个值对所有人都一样单独拿出来识别不了任何个体。自然人证件编号是三级数据。它是唯一识别码泄露即可被用于撞库、冒名注册、伪造材料。证件散列码是一级数据。散列后不可逆无法直接还原成某个人但它是系统内部稳定的比对标识。同一张证件明文是三级散列后是一级。这说明定级针对的是“值”而不是“字段”——同一个业务字段在不同存储形态下可以有不同级别。这条如果理解反了后面所有加密策略都会错位。提示一级数据不是“最敏感”恰恰是敏感度最低的一档。很多团队第一次读这份标准时会望文生义把一级当最高密级结果把证件类型、性别、民族这些字段做了过度加密查询性能掉下来真正的三级证件编号反而按普通字段处理。2.2 用户标识的设计散列值作为系统内部主键标准第 3.2 条给“用户标识”下了一个很关键的定义用户个人信息中的证件号码等唯一识别码形成的散列值在统一身份认证系统中唯一。这句话背后的机制是系统内部所有跨节点流转、日志记录、导出清单、关联比对全部只用散列值明文证件编号不参与流转。地方节点向国家节点查询某个用户的信息时传的是散列值而不是证件号日志里落的是散列值导出记录里列的也是散列值。即使某一份日志被拖走攻击者拿到的是一串不可逆的散列无法直接还原成证件号。但这里有个容易被忽略的闭环散列值虽然是不可逆的它本身却是一个稳定标识符——同一个人在不同系统里的散列值如果用了同一个散列函数就可以碰撞比对。所以标准第 6.5 条紧接着禁止“以两个或两个以上用户的个人信息进行关联分析包括以散列值进行分析”。先用散列值替代明文降低单点泄露危害再限制散列值的聚合能力两步是一套组合拳。2.3 存储形态随级别变化而不是一刀切定级之后存储要求按级别分层而且同一级别在互联网区和电子政务外网的要求还不一样。表 A.1 加上第 6.3 条可以整理成下面这张对照隐私级别互联网区存储要求电子政务外网存储要求判定理由一级无特殊要求无特殊要求不能对应到自然人二级加密存储可逆加密存储可逆需要展示、检索、核验三级不可逆散列不得明文或可逆加密加密存储可逆互联网区暴露面大外网相对受控三级数据在互联网区必须用不可逆方式且散列函数由“国家节点统一提供”。这个“统一提供”不是随便定的——如果各节点各用各的散列函数跨节点就无法比对同一个人统一散列函数保证了散列值在全体系内可比对同时又把明文挡在散列之外。为什么电子政务外网允许可逆加密因为外网是受控网络且部分业务比如证件打印、材料核验确实需要还原明文。但“可逆”不等于“裸奔”仍然是加密存储、密钥受控。这是一种按网络位置分配防护强度的思路暴露面越大数据形态越不可逆暴露面越小才允许保留可逆能力。加密算法上标准引用的是 SM4 对称加密和 SM2 非对称加密。对称加密用于数据本身的存储加密非对称加密用于密钥协商和签名。国密体系在政务系统里是硬性要求不能拿 AES 替代。2.4 附录 A 的读法与 14 岁以下提级附录 A 是规范性附录逐字段列出了定级。它和正文第 4 章的关系是正文给判定原则附录给逐字段结果。落地时应该以附录 A 为准因为它更具体、更可执行。标准第 5 章还有两条补充判定一是未满 14 岁的儿童可提升数据隐私级别二是生物特征数据单独定级——人脸、声纹等较公开的生物特征属于二级指纹等可认定个人信息的生物特征属于三级。这里“可提升”用的是“可”而不是“应”给了实现弹性。实务上我一般建议对儿童数据一律提一级处理因为儿童信息的泄露后果和追责压力都更大。人脸定为二级、指纹定为三级这个划分本身有讨论空间人脸走在路上就能被拍到公开程度确实高于指纹但人脸一旦泄露无法更换长期风险其实不低。这是标准在“公开程度”和“不可撤销性”之间做的一个取舍落地时如果业务涉及人脸建议按更严的口径做加密和访问控制。3. 默认脱敏与临时明文一条个人信息的“可见窗口”是怎么被压到最小的定级解决“存成什么样”脱敏解决“给人看什么样”。这两件事经常被混为一谈其实前者是存储形态后者是展示策略对应的是两类完全不同的攻击面存储泄露和内部滥用。3.1 默认脱敏是基线全文显示是白名单标准第 6.4 条的逻辑是“默认拒绝”系统中默认应脱敏显示二级以上隐私数据只有两种情况允许全文显示——用户注册时自己填写的内容用户查看和修改个人信息时且必须经过二次认证。这是典型的白名单设计。不是“哪些字段该脱敏”而是“默认全脱敏只有列出来的场景才放开”。这种写法在工程上更好落地新增字段时默认走脱敏不会因为忘记配置而漏掉。脱敏规则本身也给了可计算的示例整理如下字段脱敏示例规则姓名**明显示最后 1-2 个汉字公民身份号码、社保卡号***********4432显示最后 4 位手机号码133****4387显示前 3 位和后 4 位证件有效日期、失效日期****0421显示后 4 位用户邮箱*********163.com显示 及之后部分支付宝号、微信号****0403显示后 4 位户籍地址、居住地址、工作单位、发卡地某市某区********长度大于 12 时显示前 6 位不足 12 位显示不超过 50%标准还规定“除手机号码外二级以上隐私数据脱敏范围应不少于 50%”。这个 50% 是下限工程含义是不能只遮一两位。比如姓名如果只遮姓剩下一个字的信息量仍然很大所以规则定成显示最后 1-2 个字。手机号之所以例外是因为它是验证码通道用户需要确认验证码发到了哪个号而且前 3 后 4 的规则本身已经遮住了中间 4 位。3.2 二次认证与实人认证修改为什么比查看更严查看和修改都要二次认证级别不低于包含手机短信验证码的双因子认证。但修改信息“宜”使用实名等级四级实人认证——注意这里是“宜”是推荐不是强制。二次认证防的是会话劫持。攻击者拿到了登录态 token还得再过一道短信验证码成本立刻抬高。而修改比查看更危险改绑手机号等于接管账号改证件号等于冒用身份。实人认证人脸核验能确认操作者就是本人把“拿到账号”和“证明是本人”分开。“宜”字留出的弹性空间落地时可以按风险分级改普通字段用短信双因子改手机号、证件号这类关键字段上实人认证。这样既不违背标准也不会让所有修改操作都背上人脸核验的成本。3.3 临时明文窗口三个场景的时限设计标准没有一刀切禁止明文而是开了三个有严格边界的临时窗口。这三个窗口的数量和时限是整份标准里最值得细看的量化设计场景数量限制时间限制销毁要求实名核验一次 1 条用完即销毁禁止使用超出核验需要的数据注册信息上报地方、部门节点到国家节点不超过 1000 条不超过 24 小时上报后销毁国家节点收到后不超过 8 小时用户信息查询单用户收到信息 2 小时内处理并销毁查询接口只允许接收和输出一个用户这三个数字不是拍脑袋来的它们对应的是“暴露窗口 数量 × 时间”的量化思路。实名核验只需要比对一条所以限制一次一条地方节点批量上报有业务波峰所以给 1000 条、24 小时的缓冲国家节点处理能力更强窗口压到 8 小时查询是实时业务2 小时足够完成处理。还有一个容易被忽略的约束查询接口只允许接收和输出一个用户的个人信息不得存在一次查询多个用户的服务。这条必须在接口层面硬限制不能靠调用方自觉——否则一个批量查询接口就能把前面所有数量限制架空。所有涉及未加密个人信息的传输按 C 0111-2018 和 C 0113-2018 中的安全通讯规定处理互联网区和电子政务外网一视同仁。3.4 数据加工与访问记录的红线第 6.5 条是一条很硬的禁令禁止以两个或两个以上用户的个人信息进行关联分析包括以散列值进行分析。例外只有三条——脱敏、散列化等安全加强处理访问记录只用于异常登录等安全分析和处置对散列值本身进行加工。为什么连散列值都禁因为散列值是稳定标识符两个系统的散列值一碰撞就能把同一个人在不同系统里的行为拼起来。单个人的数据泄露危害有限聚合才是灾难——把一批用户的访问记录、办事记录、身份信息关联起来就能做画像、做群发、做精准推送。标准直接在源头掐掉聚合能力而不是等到聚合之后再追责。访问记录被单独限定为“只用于异常登录等安全分析和异常处置”也是同一个逻辑访问记录一旦被用于画像就变成了行为数据性质完全变了。4. 密钥托管与关联分析禁令把“能解密的人”和“能拼图的人”同时关进笼子存储加密解决“拖库后看不懂”但如果能解密的人不受约束加密就只是纸面功夫。这份标准在密钥管理上的设计核心不是算法而是岗位分离。4.1 密钥三权分立知密与用数必须分开第 6.3 条 d 款对密钥管理提了四条要求密钥必须存放于符合 GM/T 0051-2016 的系统或设备中密钥由专人管理密钥管理人员不得从事数据操作、加工、使用等工作密钥管理人员应是本节点正式工作人员不得来自软件开发商、服务商等第三方机构。这四条合起来是一个“知密”与“用数”分离的结构。一个人如果同时掌握密钥和数据操作权限就等于可以任意解密任何数据加密形同虚设。把密钥管理岗和数据操作岗分开任何单点都无法独立完成“解密并导出”这个动作。“必须是正式工作人员、不得来自第三方”这条尤其值得注意。第三方人员流动性大、权限边界模糊、出事后的责任追溯链条长。把密钥责任人锁定在正式员工本质上是把无限责任落到一个可追溯的主体上。这是制度性隔离不是技术隔离但效果比很多技术手段都直接。4.2 禁止共享、转让和披露为什么是“一律禁止”而不是“审批后可以”第 6.6 条的措辞非常绝对禁止各级节点对用户数据进行公开披露、转让和共享用户个人数据。没有“经批准可以”的例外。这种写法在标准里不常见但放在政务身份数据的语境下是合理的数据一旦共享出去就失控接收方怎么用、存多久、再共享给谁原节点都无法控制。与其设计一套复杂的审批流程不如直接禁止把跨部门的数据需求引导到“查询接口”这条受控通道上。这也解释了第 6.4 条为什么要开一个 2 小时的查询窗口——跨部门办事确实需要核验信息但核验不等于同步。查询接口只返回单用户、限时销毁数据不出域控制权还在原节点手里。4.3 导出、归档与销毁留下可追溯的痕迹导出是最容易出事的环节所以标准要求各节点制定数据导出管理制度明确少量导出、批量导出、大批量导出的定级定义和流程明确责任人导出记录至少保存一年。记录内容清单很具体用途、时间、操作地点、人员、授权信息、导出文件大小、数据数量以及所有个人信息的标识散列值。为什么要记散列值清单因为一旦发生泄露需要能回答“泄露的是哪一批人”。散列值清单可以和系统内的用户标识比对快速圈定受影响范围而不需要把明文再翻出来。归档要求形成离线文档不可在线查询、获取。销毁要求采用不可恢复方式并保证销毁后不存在内存残留、缓存、临时文件、临时库表等剩余信息。日志则要求覆盖收集、使用、加工、输出各个环节保存不少于一年超期及时归档。“内存残留”这一条在工程上经常被低估。比如 Java 里 String 不可变敏感数据以 String 形式存在时GC 之前会一直驻留堆内存临时文件如果只是删了目录项而没覆写磁盘上仍可恢复。标准把“临时库表”也列进来说明起草时考虑过实际系统里的各种中间态。4.4 责任与检查标准要有牙齿第 7 条明确各节点对本系统内收集、存储、使用的用户信息负责。数据被篡改或丢失由系统所在节点通过权威机构技术鉴定或查实确定责任。发生泄露按泄露数据的隐私级别上报处置。第 8.2 条给了检查机制国家节点按本要求对各节点组织定期或不定期检查不符合要求的节点将暂停接入服务并限期整改。“暂停接入”是有实际约束力的——统一身份认证是政务服务的前置入口接不进来业务就停了。没有这条前面所有条款都只是建议。5. 落地排查标准条款在系统里最容易翻车的五个地方标准读起来条理清晰真落到代码和运维里翻车点往往出在对条款的误读和横切关注点的遗漏。下面五条是踩过的坑里最有代表性的。5.1 把“一级数据”当成最敏感数据现象开发时望文生义把一级当最高密级证件类型、性别、民族这些字段被做了字段级加密查询和索引性能明显下降真正的三级证件编号反而按普通字符串存储。原因一级的定义是“不能对应到自然人实体身份信息的数据”是敏感度最低的一档。级别数字小不代表敏感度高。解决以附录 A 的逐字段判定为准先给每个字段打上级别标签再倒推存储策略。一级不做特殊要求把加密和脱敏资源集中在二级和三级上。5.2 正文举例与附录判定表冲突时按哪个来现象第 4.3 条正文举例时说工作单位属于三级数据但附录 A 表 A.1 判定“用户工作单位”为二级数据。同一个字段两处定级不一致。原因正文是举例说明不构成逐字段判定附录 A 是规范性附录逐字段列明权威性更高。解决以附录 A 为准工作单位按二级加密存储。同时在设计文档里记录这个差异和取舍理由避免后续审计时被问住。遇到类似冲突统一原则是“规范性附录优先于正文举例”。5.3 脱敏规则散落在各业务代码里现象新增一个字段时忘了脱敏同一个手机号在不同接口里脱敏格式不一致导出报表里是明文页面上是脱敏。原因脱敏是横切关注点靠每个开发在每处出参手动处理必然漏。解决建统一的脱敏服务按字段级别驱动接口出参统一走序列化脱敏导出走同一套规则。给每个字段加单元测试覆盖页面、接口、导出三条路径。脱敏规则集中配置改一处全生效。5.4 临时明文忘了销毁现象实名核验的明文缓存在 Redis 里没设 TTL上报文件落在临时目录没人清理查询结果在服务内存里留了副本服务不重启就一直驻留。原因销毁是“事后动作”容易被当成可选项加上很多框架对临时文件、连接池、缓存都有默认保留行为。解决所有临时明文强制设 TTL并在业务完成后主动删除临时文件用可覆写的字节流处理用完即清敏感数据尽量用可清零的字节数组而不是不可变字符串接口层限制单条查询销毁动作本身写审计日志方便事后核对。5.5 导出和日志记录字段不全现象导出只记了操作人和时间没记文件大小、数据量、散列值清单日志只记了接口调用没记数据流向和授权信息。原因标准列出的记录字段多手写埋点容易漏。解决导出统一走导出网关由网关自动采集用途、时间、地点、人员、授权信息、文件大小、数据数量、散列值清单日志字段按标准清单做成模板接入时逐项核对。导出记录和日志都保留至少一年超期归档而不是直接删除。6. 设计取舍为什么宁可牺牲一点便利也要让数据“出不去、拼不起来”这套标准通篇在做同一件事把隐私风险从“依赖人自觉”转移到“依赖机制约束”。而每一个机制背后都有代价值得单独拿出来看。维度标准的选择付出的代价换来的收益存储形态三级数据在互联网区不可逆散列无法反查明文部分业务要另设通道拖库后无法还原证件号展示策略默认脱敏白名单才全文显示运营和客服效率下降内部滥用和肩窥的成本抬高数据流转用散列值替代明文做主键需要额外的映射和兼容改造日志、导出泄露的危害大幅降低共享披露一律禁止只留查询接口跨部门要改造成接口调用数据不出域控制权留在原节点密钥管理知密与用数分离密钥岗不用数流程变重人员配置要求提高单点无法独立完成解密导出关联分析禁止跨用户关联含散列值部分分析类需求被直接砍掉从源头消除聚合画像风险这张表里最值得琢磨的是“关联分析禁令”。它砍掉的不只是违规操作还包括一些看起来正当的分析需求。但换个角度想一旦允许“经过审批的关联分析”审批本身就成了新的攻击面而且关联一旦发生就无法撤回。标准选择在源头禁止是把不可逆的风险挡在门外。要验证一套系统是否真的落地了这些要求我一般按这个顺序走一遍先拿字段清单对照附录 A 打级别标签再核对每个级别的存储形态尤其是三级数据在互联网区是不是真的走了不可逆散列然后抽样检查页面、接口、导出三条路径的脱敏是否一致接着查临时明文的 TTL 和销毁日志再确认密钥管理岗和数据操作岗是不是分开的最后审计有没有跨用户关联的查询或分析任务在跑。这六步走完基本的合规面就覆盖住了。从那以后我每次做身份相关的系统都会先把字段清单按附录 A 打标再倒推存储、脱敏和密钥策略而不是先写代码再回头补隐私。顺序反过来改造成本会高出一个量级。希望帮到你。本文还有配套的精品资源点击获取