简介《C0131国家政务服务平台统一身份认证隐私保护要求》面向政务服务平台建设方、统一身份认证系统开发者及隐私合规人员梳理身份认证场景下个人信息保护的标准依据与落地要点。资源包仅含1个PDF文件大小约188KB便于直接查阅与归档。内容围绕隐私数据定级、判定、使用与责任展开明确一级至三级数据的保护差异并覆盖收集、保存、加工、共享披露、导出输出、归档销毁等环节的基本原则和操作边界同时列出网络安全法、个人信息安全规范等引用依据以及组织管理与检查检测要求附录A还给出自然人身份信息隐私判定说明。已有820人学习可用于政务身份认证项目的合规自查、制度编写和隐私影响评估参考。1. 统一身份认证的隐私边界27 项字段定级表能挡掉多少返工政务服务平台统一身份认证隐私保护这件事多数人是被整改单推着入场的系统跑了大半年一纸检查意见下来说身份认证节点字段分级不清、日志存得不够、脱敏比例不达标。翻遍手里的开发文档找不到一条能直接抄的规则全是“应按相关要求执行”。C 0131-2018 补的就是这个缺口——它把统一身份认证里哪些字段算隐私、算几级、怎么存、怎么显示、谁能碰写成了可对照的条款还附了一张 27 项自然人身份信息的判定表。它不教你写代码但给了你一把能贴在工位上的尺子。正在做政务身份认证对接、被合规改造追着跑或者要给团队定字段分级基线的人值得把它当底稿读一遍。2. 三级定级落地把附录 A 的 27 项字段拆成数据字典2.1 定级不看“感觉敏感”先看能不能落到自然人身上标准给的三级划分有一条主线能不能对应到自然人实体。一级数据是“不能对应到自然人实体身份信息的数据”证件类型、实名等级、性别、民族、国籍这些都归一级二级是“可用于标识自然人实体的身份信息且较公开”登录账号、姓名、手机号是典型三级是“可用于标识自然人实体且具有较高隐私性”证件编号、户籍地址、居住地址在列。这条主线的好处是它可判定。团队评审时最常吵的是“这个字段敏不敏感”这种争论没有收敛点。换成“这个字段单独出现时能不能定位到某一个人”讨论立刻落地。证件类型不能证件编号能所以一个一级一个三级。性别不能姓名加手机号能所以姓名和手机号都是二级。我一般要求评审时把每个字段填进一句话模板“持有该字段值的人能否在系统内唯一定位一个自然人”答能就至少二级答不能才考虑一级。真正容易翻车的是“单字段级别低、组合起来级别高”的情况。标准本身按字段定级但 6.5 条另外禁止了以两个或两个以上用户的个人信息做关联分析也禁止跨用户以散列值做关联。也就是说字段级定级是底线不是全部字段组合后的可识别性要在数据加工环节另行受约束。把定级表当唯一答案会漏掉组合场景。2.2 附录 A 的 27 项字段按级别拆成三张落地表附录 A 是规范性附录它才是实施时的准绳。我习惯把它直接翻成三张表每张表带一列“实施动作”让开发和运维看到级别就知道该干什么而不是回头再查一遍正文。一级数据8 项存储无特殊要求但仍受通用安全要求约束字段级别实施动作自然人证件类型一级可明文导出仍需登记证件散列码一级可明文禁止用于跨用户关联分析自然人实名等级一级可明文自然人实名核验日期一级可明文用户性别一级可明文用户类型一级可明文用户民族一级可明文用户国籍一级可明文三级数据4 项互联网区必须不可逆处理外网必须加密字段级别实施动作自然人证件编号三级互联网区散列存储禁止明文与可逆加密社保卡号三级同上用户户籍地址三级同上显示按地址规则脱敏用户居住地址三级同上二级数据15 项加密存储默认脱敏显示字段级别实施动作自然人姓名二级加密存储显示最后 1-2 个汉字自然人登录账号二级加密存储按账号规则脱敏自然人手机号二级加密存储前 3 后 4 显示证件有效日期二级加密存储显示后 4 位证件失效日期二级加密存储显示后 4 位发卡地二级加密存储按地址规则脱敏用户邮箱二级加密存储保留 及域名注册时间二级加密存储按日期规则脱敏用户生日二级加密存储按日期规则脱敏用户学历二级加密存储用户支付宝号二级加密存储显示后 4 位用户微信号二级加密存储显示后 4 位用户工作单位二级加密存储按单位名规则脱敏用户第二手机号二级加密存储前 3 后 4 显示用户第三手机号二级加密存储前 3 后 4 显示把这三张表变成一个可被代码引用的常量是让定级真正生效的第一步。字典化之后序列化层、脱敏层、日志层都能统一引用同一个来源避免三处各写一份、改一处漏两处# privacy_level.py —— 按附录 A 落地的字段定级基线值 1/2/3 对应一/二/三级 LEVEL { # 三级可标识自然人且隐私性高互联网区必须散列存储 id_no: 3, # 证件编号 social_card_no: 3, # 社保卡号 residence_addr: 3, # 户籍地址 live_addr: 3, # 居住地址 # 二级可标识且较公开加密存储 默认脱敏 real_name: 2, login_account: 2, mobile: 2, mobile2: 2, mobile3: 2, email: 2, birthday: 2, reg_time: 2, id_valid_from: 2, id_valid_to: 2, issue_place: 2, alipay_no: 2, wechat_no: 2, education: 2, work_unit: 2, # 一级不能对应到自然人实体 id_type: 1, id_hash: 1, real_level: 1, verify_time: 1, gender: 1, user_type: 1, nation: 1, nationality: 1, } def level_of(field: str) - int: # 未登记字段一律按三级处理宁可多加密不可漏判 return LEVEL.get(field, 3)这段代码有两个刻意设计。一是level_of的默认值取 3新增字段忘记登记时走最严路径出错方向是“多做一步”而不是“漏保护一个”。二是字典键必须是英文标识而不是中文名中文名在不同系统里叫法不统一用它做键迟早对不上。参数上唯一需要团队约定的是字段命名规范我把mobile2、mobile3对应第二、第三手机号就是为了和正文措辞保持可追溯。2.3 表外还有三类数据儿童、生物特征、访问记录附录 A 只是“身份模型里”的字段标准在判定一章另外点了三类表外数据它们不进主表但必须进字典。未满 14 周岁的儿童标准明确“可提升数据隐私级别”。注意措辞是可提升不是必须提升工程上我建议直接提升一级理由很简单儿童数据一旦泄露的处置成本远高于多加密一次的存储成本而且判定年龄依赖生日字段生日本身是二级判定链路短实现起来不复杂。生物特征分两档人脸、声纹这类较公开的属二级指纹这类可作为认定个人信息的属三级。这个区分不是按采集难度是按可替换性——人脸和声纹在政务场景里常作为核验辅助指纹往往直接绑定身份认定。落地时最容易漏的是把指纹特征值当普通字符串存进业务库正确做法是走三级口径。访问记录属二级登录记录、政务门户访问记录都算。但它还有一条额外限制——只允许用于异常登录分析和异常处置不得用于其他用途。这条限制很多人只记住了级别、忘了用途结果把访问记录接进了用户画像或者推荐位。3. 存储与密钥二级加密、三级散列密钥不进代码库3.1 三个级别对应三套存储口径区域不同口径也不同存储要求分层很清晰但有一个容易被忽略的细节标准对三级数据明确区分了互联网区和电子政务外网对二级数据没有区分区域。三级在互联网区要求不可逆加密不得明文或可逆加密且必须用国家节点统一提供的散列函数对明文做散列运算三级在电子政务外网则以加密方式存储。二级统称“应以加密方式存储”。级别互联网区电子政务外网可逆性算法口径一级按通用安全要求按通用安全要求可逆不作特殊要求二级加密存储加密存储可逆加密密钥使用 SM2、SM4三级散列存储禁止明文/可逆加密存储互联网区不可逆统一散列函数 SM2/SM4二级数据没有区分区域实施时按更严的那一侧做就对了——两边都加密不留讨论空间。三级数据的可逆性必须在设计阶段定死因为一旦业务侧提出“证件编号要能回显完整值”就意味着互联网区不能存明文只能在用户二次认证后从加密侧取值或者走国家节点查询架构上前置条件完全不同。还有一条常被漏掉的保存原则各节点应按用户信息模型范围收集节点自己收的数据自己负责安全。这条看着像废话实际影响的是责任边界——地方和部门节点不能因为“数据最终要上报国家节点”就放松本地存储要求。3.2 密钥托管与人员边界密钥管理员为什么不能碰数据密钥这部分是整份标准里最容易在检查中失分的地方因为它考的不是技术是岗位设置。密钥必须存放在符合 GM/T 0051-2016 的系统或设备中不能落在配置文件、环境变量、代码仓库里。密钥由专人管理。密钥管理人员不得从事数据操作、加工、使用等工作。密钥管理人员应是本节点正式工作人员不得来自软件开发商、服务商等第三方机构。加密密钥使用 SM2、SM4 算法。四句话四条硬约束。第三条和第四条在项目制交付里几乎必然产生冲突外包运维团队熟悉密钥设备、熟悉轮换流程但他们不能当密钥管理员。常见的合规做法是把密钥管理员岗设在甲方正式人员编制里第三方只承担设备运维和流程支持不持有密钥操作权限。落到配置上策略文件里只写“引用哪个密钥标识、用哪种算法”不写密钥本身。我给团队的模板大致长这样# storage_policy.yaml —— 存储与密钥策略只写引用不写密钥材料 fields: id_no: # 证件编号三级 zone: internet storage: hash # 互联网区不可逆 hash_provider: national-node-unified # 统一散列函数禁止自研 display_mask: tail4 social_card_no: zone: internet storage: hash hash_provider: national-node-unified mobile: zone: both storage: encrypt # 二级两侧都加密 key_ref: kms://identity/mobile/v1 # 只引用标识 algorithm: SM4 display_mask: mobile_3_4 key_management: device: gm-t-0051-compliant # 符合密钥管理规范的设备 custodian_role: key-admin # 正式人员专岗 forbidden_roles: [data-ops,>MASK * def mask_name(name: str) - str: # 姓名两字留最后 1 个汉字三字及以上留最后 2 个 if not name: return keep 1 if len(name) 2 else 2 return MASK * (len(name) - keep) name[-keep:] def mask_mobile(mobile: str) - str: # 手机号前 3 后 4标准明确不受 50% 下限约束 if len(mobile) ! 11: return MASK * len(mobile) return mobile[:3] MASK * 4 mobile[-4:] def mask_tail(value: str, keep: int 4) - str: # 证件编号、社保卡号、证件有效期、支付宝号、微信号只留后 4 位 if len(value) keep: return MASK * len(value) return MASK * (len(value) - keep) value[-keep:] def mask_email(email: str) - str: # 邮箱保留 及域名本地部分全部掩码 local, sep, domain email.partition() if not sep: return MASK * len(email) return MASK * len(local) domain def mask_address(addr: str) - str: # 地址/单位/发卡地12 字符显示前 6 位12 字符隐藏不少于一半 n len(addr) if n 0: return if n 12: return addr[:6] MASK * (n - 6) hidden (n 1) // 2 # 向上取整保证隐藏比例 50% return addr[: n - hidden] MASK * hidden逻辑说明mask_name用len()计数而不是按姓氏语义切分是为了兼容复姓和带间隔符的姓名mask_tail的keep参数默认 4覆盖证件编号、社保卡号、证件有效期、支付宝号、微信号五类字段字段不同但规则相同共用一个函数减少分支mask_address的hidden (n 1) // 2是向上取整n 为奇数时多隐藏一位确保任何长度都满足“显示不超过 50%”mask_email用partition而不是split是为了处理本地部分含点号、加号的邮箱地址。参数说明与改法keep只在极少数场景需要调整标准写的都是后 4 位不建议动mask_address里的 12 和 6 是标准给的固定阈值属于硬编码规则而不是可调参数别做成配置项让运维随手改改了就偏离标准mask_mobile里的长度 11 是国标手机号长度遇到非 11 位的历史脏数据直接整串掩码比截断更安全。验收时我会做三件事拿线上真实样本跑一遍所有函数逐条比对标准示例构造边界样本1 个字符的姓名、10 个字符的地址、12 个字符的地址、13 个字符的地址、含 但无域名的脏邮箱把脱敏函数的输出和页面实际显示做一次比对确认页面没有绕开函数直接取原值。5. 踩坑排查五条血泪经验每条都能让你暂停接入5.1 工作单位到底是二级还是三级现象字段分级评审会上一份材料说工作单位是三级另一份说是二级两边都能在标准里找到依据开发按三级做了不可逆散列业务侧要按单位统计时发现原值取不回来功能直接废掉。原因标准正文的定级举例里把工作单位和证件编号、户籍地址并列提到了“较高隐私性”而规范性附录的判定表里用户工作单位明确列为二级。正文是举例说明附录是逐字段判定表两者粒度不同。解决以附录 A 为准工作单位按二级处理——加密存储、可逆、默认脱敏显示脱敏按地址类规则执行。团队内部要立一条规矩字段级别有歧义时先查附录 A 的判定表判定表没列的字段才回到正文看举例最后按“未登记默认三级”兜底。5.2 把“不可逆加密”做成了自研散列加盐现象三级字段上线半年跨节点查询全部失败同一个证件编号在两个节点算出来的散列值对不上用户信息查询接口返回空结果。原因开发团队按“不可逆加密”的字面理解自己选了散列算法并加了项目自定义盐值。标准的要求是采用国家节点统一提供的散列函数对明文进行散列运算散列口径必须全网一致自研等于自断链路。解决三级数据的散列必须调用统一提供的散列实现盐值和参数由统一侧管理业务侧不参与。改造时同步做两件事把存量数据按统一函数重算一遍并做双写过渡在配置里把hash_provider固化为统一标识禁止业务代码直接引入第三方散列库。5.3 查询接口写成批量一条请求带走一页用户现象性能压测时有人把用户信息查询接口改成了支持主键列表一次最多传 50 个用户标识接口返回列表。功能上线两周后检查中被判定不合规。原因标准对查询接口的限制是只允许接收和输出一个用户的个人信息不得存在一次查询多个用户的服务。这个限制不是性能约束是防止一次请求批量拉取个人信息。解决接口签名回退成单用户主键批量需求在调用方拆成多次单用户调用并在网关层加参数校验检测到数组入参直接拒绝。同时在审计日志里记录每次查询的用户标识和被查用户标识两者不一致时告警。5.4 日志留存配了 90 天自动清理现象检查要求提供近一年的隐私数据操作日志翻出来只有最近三个月其余已被定时任务清理。原因日志组件沿用了通用系统的保留策略没人把它和隐私数据各环节都要记日志、日志保存时间不少于 1 年这条要求对上。解决把日志留存周期从通用默认值改为不少于 1 年超出时效后归档而不是删除。同时补齐日志覆盖面——收集、使用、加工、输出各个环节都要有记录不能只记登录。日志本身也可能含敏感字段写日志前先过一遍脱敏函数别让日志库成了明文泄露点。5.5 密钥管理员由外包运维兼任现象密钥轮换流程走得挺顺但岗位表一查密钥管理员是第三方驻场运维同时还有生产库的数据操作权限。原因项目交付期人手紧谁熟悉密钥设备就谁来管没人对照“密钥管理人员不得从事数据操作、加工、使用等工作且应是本节点正式工作人员”这两条硬约束。解决密钥管理员岗改由正式人员担任第三方只做设备运维支持、不持有密钥操作权限在权限系统里把密钥管理角色和数据操作角色做成互斥同一账号不能同时授予轮换、启停、销毁都留双人操作记录。5.6 排查顺序从字段表开始别从代码开始遇到合规问题我的排查顺序是固定的先拉字段分级表核对附录 A确认每个字段的级别和存储口径没跑偏再看脱敏函数和页面回显用边界样本跑一遍然后查密钥托管位置和管理员岗位接着查日志留存周期和覆盖面最后查数据导出记录和销毁流程。这个顺序是按“改一处影响面”排的越靠前的问题改动成本越低、影响面越大。反过来从代码查起往往在细枝末节上耗掉两天回头发现字段级别一开始就定错了。6. 一张自查表把验收前的一次性冲刺变成常态标准落地最常见的失败模式是“检查前突击、检查后回退”。想把这件事做稳得把检查项变成一张能每周跑一遍的自查表而不是一份锁在共享盘里的整改报告。我的做法是把标准条款压成六行每行带一个可验证的证据物谁负责、证据在哪、多久看一次都写清楚检查项判定依据证据物频率字段定级附录 A 逐字段比对字段分级字典与代码引用每次模型变更存储口径三级互联网区不可逆、二级加密存储策略配置 抽样数据每月密钥托管设备合规、管理员岗位互斥密钥台账 权限矩阵每季度默认脱敏除手机号外隐藏 ≥ 50%边界样本跑测报告每次发布临时明文配额1000 条 / 24h、8h、2h接口限流配置 销毁日志每月日志与导出日志 ≥ 1 年、导出记录 ≥ 1 年日志保留策略 导出台账每季度表格只是骨架真正管用的是配套的抽样手法。我一般从生产环境抽一条完整链路——一个真实用户的注册、核验、查询、导出四步然后把这条链路上出现的所有数据副本列出来业务库、缓存、临时表、日志文件、导出文件、备份。逐份核对它是否落在允许的级别口径内尤其是缓存和临时文件这两个地方标准在数据销毁一章专门点了内存残留、缓存、临时文件、临时库表实际出问题也大多在这几处。归档后形成离线文档、不可在线查询获取这条同样要落在这份清单里别让归档库还挂在线上。差异比对也要做。字段分级字典更新后跑一遍脚本比对“字典里的级别”和“线上实际存储方式”任何不一致都当成缺陷单处理。这个脚本很简单遍历字典按级别去核对存储表的列类型、是否加密、是否有散列标记输出差异列表。它的价值不在技术含量在于把“应该”变成“已经”。血泪经验是这么来的早些年我接手一个身份认证节点的整改前期所有精力都扑在脱敏函数上验收前一天才发现导出记录只记了操作人和时间用途、地点、授权信息、导出文件大小、数据数量、个人信息散列值全缺只能连夜补流程、补字段、补历史台账。从那以后我每次做这类合规落地都强制先跑一遍“字段—存储—显示—日志—导出—销毁”六段自查一段不通过就不往下推。这份标准的价值也在这里它把每一段该长什么样都写死了剩下的是你愿不愿意把它变成每周的固定动作。希望帮到你。本文还有配套的精品资源点击获取
