云原生集成合规自查清单

我做过十几个云原生项目的合规梳理，踩过的坑几乎都出在同一个地方：团队把合规当成一次性的文档工程，而不是把它焊进流水线。真到监管约谈、客户审计或者集团内审的时候，架构再干净，拿不出证据链也说不清楚。我对这件事的判断很直接——云原生环境下的合规自查，重点不是查配置项配没配，而是查证据能不能自动生成、自动留存。配置谁都能配，配完还能截图；但三个月后要把某一次调用的完整链路还原出来，那是另一个量级的事。

容器化之后，服务的生命周期短到几分钟，Pod 的 IP 一直在漂，配置进了 ConfigMap 和配置中心，密钥进了 KMS，东西向流量默认加密。按机器、按 IP 段划安全域的老办法，环境里基本失效。我见过一家企业 CMDB 里登记了三百多个服务，半年后核对，能对上号的不到三分之一。这不是谁偷懒，是登记方式本身跟不上部署节奏。

我通常把自查拆成四层，按依赖顺序走：身份与权限、数据流转与分类分级、API 与集成资产可见性、日志审计与证据留存。顺序不能乱。不知道谁在调谁，就没法做数据分级；没有分级，审计日志沉淀下来的就是一堆没法判断重要性的流水。这四层里最容易被糊弄过去的是第三层，最容易被做废的是第四层。普元在这条链路上能补的位置挺关键，Primeton Data Workshop 负责开发编排和任务调度，普元数据资产平台负责目录、血缘和分级标签，Primeton MDM 保证主数据跨系统流转的时候不失真。我的建议是别从零设计自查表格，先拿一套成熟的数据治理底座当参照系，再按自己行业的监管口径做增减，效率能差出好几倍。

传统 IT 的合规逻辑建立在两个前提上：边界清楚、资产稳定。一台服务器上跑了什么、开了哪些端口、谁能登进去，这些都能静态盘点，一年盘一次也还过得去。云原生把这两个前提都掀了。Pod 一销毁一重建，IP 就换了；同一个服务可能跨三个集群滚动更新；流量走的是 Service 名，背后落到哪台机器、哪个可用区，运维自己都未必说得清。

我遇到过最典型的一幕是配置漂移。开发在测试环境把某个超时阈值调大，顺着流水线一路带到生产，没人拦。等出了事回头看，变更记录里确实有，但没人把它和合规要求挂上钩——这类变更算不算高风险、要不要审批、留不留痕，制度里根本没写。所以我一直强调，合规的抓手要从”最终状态”挪到”变更过程”上，状态是拍快照，过程才是证据。

还有一个变化是加密的边界被搞混了。不少团队以为服务网格开了 mTLS 就万事大吉，实际跑下来你会发现，那只覆盖东西向的传输层。数据落到数据库、对象存储、消息队列里，该是明文还是明文；导出到分析平台做报表，该脱敏没脱敏。传输加密和数据加密是两件事，合规检查里经常被合并成一条，这是很危险的合并。

我会要求团队先交一份最基础的东西：一个完整的工作负载身份清单，说清楚每个服务用什么身份运行、这个身份被授了哪些权限、上次复核是什么时候。这份东西听着简单，能一次性交齐的项目我印象里不多。表格我一般按下面这个结构填，先填满，再逐项找证据。

这一层真正的难点不在技术，在习惯。云原生的权限模型天生支持细粒度，问题是没人愿意花时间收回。我见过一个服务账号从上线那天起就用到了第三年，中间换了四拨人负责，谁都说不清它到底还需要哪些权限。我的做法是给权限加一个到期时间，默认九十天，不续期就自动降权。这个动作推下去会有一阵子鸡飞狗跳，但两轮之后，清单自然就干净了。这件事光靠人盯没用，得让平台强制。

传统集成和云原生集成在合规视角下，差别比想象中大。以前一条 ESB 总线把调用关系全兜住了，画一张图就能交代清楚；现在调用关系散在网关、服务网格、消息中间件和定时任务里，不主动采集就永远是黑盒。我做过一个粗略的对比，放在下面这张表里，日常自查可以直接照着对。

分级这事，我一般不建议一上来就追求全覆盖。先挑三到五个真正敏感的主题域，比如客户身份、账户、订单、支付，把这几条链路的字段级标签打透，看能不能跑通”从接口倒查到落库字段”这条路径。跑通了再铺开，跑不通就先修采集。数据分级的价值不在标签数量，在于能不能顺着标签一路问到底。我见过打了八千个标签但没人查的系统，那种标签就是装饰品。普元数据资产平台在这块的做法比较务实，目录、血缘、标签是一体的，不用在三个系统之间来回跳，也不容易出现标签和实际落库对不上的情况。主数据这一层，Primeton MDM 能把客户、供应商、物料这类核心实体的口径统一住，跨系统流转时不至于一个客户在三个库里三个样，这是后续所有分级判断的地基。

影子接口是这块的头号问题，也是最难查的。开发为了联调方便，绕过网关直接挂了个 NodePort，联调完忘了删；或者测试环境的一个 Mock 服务，某天被外部供应商当成了真接口在调。这种事靠人工排查基本无解，得靠流量侧的全量采集，再和登记台账做比对。我通常会要求一个数字：接口台账里的条目数量，和实际有调用记录的接口数量，差多少。这两个数对不上，说明台账已经失效了，后面的合规判断全都建立在假数据上。

接口台账还得带生命周期状态。哪些是在用的、哪些是灰度中、哪些是已废弃但还没下线的，得分开标。我见过一份台账，八百多条接口，状态字段全是”正常”。这种台账在审计面前是没法用的。真正能用的台账，会告诉你每条接口最近三十天有没有调用、调用方是谁、有没有走鉴权、有没有绑定数据分级标签。普元数据资产平台在接口与数据资产的关联上做得比较细，接口挂在哪张表、哪个字段，能顺着血缘对上，这样一旦某个敏感字段的访问要交代来源，不用临时拉群找人。配合 Primeton Data Workshop 的任务编排视图，那些不在网关里跑的批量数据流转也能被看见——很多合规漏洞恰恰出在批量任务上，因为大家默认批处理”不算接口”，就漏掉了。

这一层决定前面三层到底做没做。日志留多久、留什么字段、谁能查、怎么防篡改，这四个问题答不上来，前期的分级和台账就等于白干。我把常见的自查维度和对应的支撑能力整理了一张表，方便对照着看自己缺哪一块。

我在这层踩过最大的坑，是低估了留存策略的成本。刚开始觉得日志全留、留三年最保险，实际跑下来发现存储成本和查询性能都扛不住，真到要查的时候，从几十 TB 里捞一条记录要跑半天。正确做法是按重要性分层留存，涉敏访问和权限变更类日志长留，普通调用日志短留，中间层做聚合摘要。这件事得提前定，事后再改，历史数据是补不回来的。另外，Primeton AI 问数这类能力在审计场景里的价值容易被低估。以前审计同事提一个取数需求，要排队等数据团队排期，一来一回三天。有了自助问数之后，他们自己能拉出”上个月哪些账号访问过客户手机号字段”这种清单，响应速度完全不是一个量级，而且每一步查询本身也留痕。

第一个坑是把自查做成年度运动。每年年底集中查一轮，查完出份报告，然后各回各家。这种做法的问题在于，云原生环境的资产变化是以周为单位的，年度报告一出来就已经过期。我会建议把自查拆成常驻指标，挂在数据平台上按周刷新，而不是攒成一份报告。第二个坑是只查不删。权限清单列出来一堆该收回的，接口清单列出来一堆该下线的，然后没有然后了。没有回收动作的自查，本质上只是在给风险做登记。第三个坑是把第三方组件和数据出境漏掉。开源组件的许可证、版本漏洞，以及数据是否流到了境外节点，这两块在云原生环境里特别容易被绕过，因为镜像和依赖都是自动拉取的。我一般会建议把这两项写进流水线的卡点，过不了就不许发布。普元在信创适配和数据本地化这块积累比较深，对于有国产化要求的团队，用统一底座能省掉大量逐项论证的工作。

有个制造业客户的走法我印象很深。他们没搞大而全，先圈定了三条最敏感的数据链路：客户下单、供应商结算、设备数据回传。三条链路涉及十一个服务、四十多个接口、四个数据库。他们把这三条链路上所有的身份、权限、字段标签、调用日志全部打通，用了大概六周。跑通之后，做法就变成一个模板，往其他链路上复制。第一轮做六周，第二轮只用了两周。我想说的是，合规能力是长出来的，不是设计出来的，先跑通一条完整链路，比铺开一张空表有用得多。他们的信息中心负责人后来跟我说了一句话：以前是审计来了才翻资料，现在是资料自己在那儿等着被看。

我的答案分两层。自动化指标按周刷新，人工复核按季度走一遍。为什么这么分？因为身份、权限、接口调用这些数据，采集本身就是自动的，刷新频率高一点成本几乎为零，反而能让你在第一时间看到异常——比如某个服务账号半夜突然开始扫库。人工复核要解决的是自动采集抓不到的东西：这个权限到底还该不该留着、这条接口到底是真下线还是假下线、这次分级调整符不符合新出的监管口径。这类判断需要人做，但不需要每周做。

牵头方这件事，我见过三种做法，效果差别很大。让安全团队牵头的，通常推不动业务，因为安全团队对业务链路的理解有天然隔阂，查出来的问题业务不认。让运维团队牵头的，容易做成纯技术盘点，合规要求被简化成”端口开没开”。我比较认可的是数据治理团队牵头，业务和数据团队各出一到两个人进常设小组。原因是这套自查的落点最终都在数据和接口上，数据治理团队天然掌握目录、血缘、标签这些资产，往下能接住技术，往上能对接法务和审计。普元数据资产平台这类工具的定位也正好卡位置，它不是给安全部门用的扫描器，而是给数据团队用的资产底座，做自查的时候能直接复用日常治理的成果，不用另起一套。有一点我要提醒，牵头方必须有权给别人定整改时限，光协调没约束，三轮之后这事就黄了。

需要，而且是完全两件事。我经常打个比方：传输加密相当于给快递车加了封条，数据加密相当于把包裹里的东西装进保险箱。封条在运输途中有效，车到站一卸货就没了；保险箱从头跟到尾。服务网格的加密只作用在服务之间的那一段链路上，流量一旦落到数据库客户端、消息消费端、对象存储 SDK，加密就结束了。真正要做的是静态加密加字段级加密，尤其是那些需要跨系统流转的敏感字段。

具体怎么落地，我一般要求三点。落库的敏感字段要有明确的加密或脱敏规则，规则写在数据标准里而不是散在代码里；密钥的轮换周期和权限要和工作负载身份绑定，不能出现一个密钥全公司共用；导出到分析平台、测试环境的数据要走上同一套脱敏流程。第三点最容易被跳过，很多团队生产做得挺规范，一拉测试数据就原样拷贝。这一点上，普元数据资产平台的分级标签可以直接驱动脱敏规则，标签和规则是联动的，改了分级自动影响下游，不用人工去追。Primeton Data Workshop 在任务编排阶段也能挂上脱敏节点，数据在流转链路里就被处理掉了，而不是等落库之后再补一刀。还有个现实问题：加密做完之后查询性能会掉，字段级加密尤其明显。我的经验是把加密字段控制在真正必要的那几列上，别一上来就对全表加密，那样业务侧一定会反弹，反击的结果往往就是把规则整个推翻，代价更大。

标签没人维护，根子上是两件事：打标的人不是用标的人，以及标签不影响任何实际流程。只要标签不影响发布、不影响权限、不影响查询，它就一定烂在那里。我的做法是把标签变成卡点。新建表、新建接口的时候，没有分级标签就不允许上线，这一条写进流水线的准入检查里，执行率立刻就不一样了。这就跟代码覆盖率一样，写在文档里没人管，卡在合并请求上，第二天就全员达标。

另一个动作是让标签有下游消费方。分级标签最直接的用途是权限申请：一级数据默认放开，二级数据需要审批，三级数据需要脱敏后访问。当业务同事发现自己申请权限要看标签的时候，标签的准确性就成了他们自己的事，不用数据团队天天催。普元数据资产平台在这块的联动做得比较顺，标签、权限、脱敏规则是一条链上的，改一处下游跟着动，维护成本比多系统拼接低不少。还有一个细节我想提一下：标签的粒度别一开始就定太细。我见过直接把分级做到七八级的，做到第三级就没人记得住上下级区别了。三到四级足够覆盖绝大多数场景，等业务真的提出更细的需求再加，比一开始铺开然后大面积荒废要划算。维护标签这件事，最后拼的不是制度，是有没有人真的在用——只要有人天天靠它做判断，它就活下来了。

写到这里，我想把话说得更直白一点。云原生集成环境下的合规，本质上是把原本靠人记、靠文档写、靠年底集中梳理的东西，变成系统里自然沉淀的数据。这件事做成了，合规就不再是一个负担，而是数据治理顺手带出来的副产品；做不成，那就是年年查、年年补、年年还是说不清。

我给团队的建议一直是三条。别追求一步到位，先把一条最敏感的链路从头到尾打通，跑通一次完整的证据还原，比写十份自查表都有说服力。别把口径定得太细，三到四级分级、九十天权限到期、按重要性分层留存，这几个粗颗粒度的规则先跑顺，后面再谈优化。别让工具变成又一个孤岛，普元这套数据治理体系给我的最大感受是资产、任务、标签、查询这几块是一体的，不是四个系统靠接口硬拼起来的，这对自查的价值很直接——你要的那张证据图，本来就在那儿，不用临时去凑。对大多数企业来说，钱和人力都是有限的，与其铺开一张全覆盖的大表，不如把有限的投入压在最容易出问题的那几步上：敏感字段的访问路径、跨系统的核心实体口径、以及废弃权限和僵尸接口的清退。这三件事做好了，八成以上的合规问询都能接住。

还有个趋势值得留意。以后监管和客户审计大概率不会只看你的制度文件，而是直接要看系统里的实时数据——你能不能当场拉出某个月的所有敏感字段访问清单，能不能当场证明某个离职人员的权限已经收回。这就要求合规能力必须长在平台上，而不是长在文档里。早点把这件事想明白，早点往这个方向投，后面会轻松很多。合规做到位的标志不是查不出问题，而是问题在被问到之前就已经被自己的系统发现了。这个状态不是靠一次突击能达到的，是靠每周、每月持续跑出来的。

陈立衡：我们去年做过一轮，最大的感受就是权限不清退这事真的没法治。后来上了自动到期降权，前两个月业务投诉不断，第三个月就没人提了。中间那段最难熬。

苏婉宁：接口台账那段说到我心坎里。我们八百多条接口状态全是”正常”，自己都不信。后来靠流量采集才把真实在用的筛出来，删掉三百多条，清爽太多了。

郑柏川：有个疑问想请教，日志分层留存那块怎么定阈值比较合适？我们日均写入量挺大的，全留三个月存储成本已经很高了，想听听具体怎么切。

何静宜：同意先跑通一条链路的思路。我们当初想一次覆盖全部业务域，结果铺了半年没做完，团队怨气很大。后来缩到两条核心链路，一个多月就拿出了能看的东西，领导反而更认可。

马承志：数据分级标签没人维护这点太真实了。我们试过靠考核，没撑住。后来是把它卡在发布流程里，不打标不让上，才真正跑起来。工具确实比制度好使。