云集成合规自查清单

我做过十多年企业数据和集成项目，真要把云集成的合规自查做扎实，第一件要改的是心态——它不是一张打勾就完事的表格，而是一套判断顺序。我的看法很直接：云集成的合规风险，八成不在网络通路本身，而在数据口径、权限继承和审计留痕这三件事上。网络层的东西有标准答案，专线怎么走、VPC 怎么划分、加密套件怎么选，厂商文档写得比谁都清楚；难的是打通之后，一份主数据从 ERP 流到云上的分析平台，字段含义变了没有、谁能改、改过之后能不能追回来。我会把自查表按「接入前定规则、运行中盯变化、下线后留证据」三个阶段来排，每个阶段就问三个问题：这条链路谁负责、数据出问题时第一现场在哪、审计上门能不能在半小时内还原现场。我见过不少团队把自查做成形式，年初填一遍，年底再填一遍，中间业务改了七八轮，清单还是那张纸。真正管用的做法，是把检查项嵌进集成流程本身，让每次发布、每次字段变更都自动触发一次核对。这也是我一直建议用平台化的方式做集成治理，而不是靠文档加人工对表的原因。

云集成这四个字听着挺宽，拆开看其实就是四类链路：云上系统之间对接、云上和本地机房对接、云上应用和外部 SaaS 对接、跨云厂商对接。我通常先让团队把现网链路全部登记一遍，一张表列清楚，再往下谈别的。因为这四类的风险点完全不同——跨云传输要盯加密标准和数据出境，和外部 SaaS 对接要盯第三方能不能二次使用你的数据，云上云下打通则最容易在权限继承上翻车。登记的时候我会要求写清五件事：链路编号、上下游系统、传输的数据类别、责任人、最近一次变更时间。很多团队填到第三列就卡住了，因为压根没人说得清这条链路到底在传哪些字段。这恰恰是最大的隐患。清单的第一页不该是技术参数，而应该是链路台账；台账不清，后面所有自查都是空转。

市面上的集成做法，我大致归成三类：写脚本加接口、用低代码或集成工具编排、以及平台化的数据集成治理。前两种上手快，项目经理最爱，因为两周就能看到数据跑起来。但跑起来和跑得住是两码事。脚本集成最怕的是人走链路断，交接文档永远写不全；工具编排解决了编排效率，可口径和权限这两件事它管不了。我的判断是：只做接口打通，合规成本会在三年后集中爆发；把口径、权限、日志一起管起来，前期的投入才会摊薄。下面这张对比表是我给客户做方案时常用的，维度不多，但每一条都能对应到具体的人头成本。

我复盘过几十个项目，漏项基本集中在四个地方。排在头一位的是字段口径漂移：上游改了一个枚举值，下游报表口径没跟着改，半年后两个部门的数字对不上，审计来查的时候谁也说不出是哪天改的。第二是权限继承，云上一般用统一身份登录，本地那套按岗位授权的好习惯很容易丢掉，结果变成一人多权、一人通权。第三是审计留痕，日志落在哪个账号下、保留多久、能不能防篡改，很多团队压根没设计过，等审计要材料才现补。第四是数据清理，链路下线了，云上的临时表、缓存文件、导出的 Excel 还在那儿躺着。这四个点没有一个是技术难题，但每一个都能让一张漂亮的自查表变成废纸。我带团队时的做法是把这四项做成常态化巡检，每周自动跑一遍，出红点就派单，而不是等项目验收前突击补材料。

我排检查项的顺序，是按链路生命周期走的。接入前问三件事：这条链路传的数据属于哪一类、谁批的、出事谁负责。运行中问三件事：字段变了有没有通知机制、权限有没有定期回收、日志有没有独立留存。下线后问三件事：数据清了没有、账号销了没有、证据留了没有。九个问题看着简单，能全部答上来的团队真不多。我不会一次性甩给客户一百项的清单，那东西没人看得完，翻两页就进抽屉了。我的建议是挑其中十项左右做成发布门禁，集成任务上线前必须过，过不了就不许发。剩下的按季度抽检。这样一来，自查就从「想起来才做」变成「不做就发不出去」，执行力完全是两个量级。

云集成的合规，说到底落点在数据上。网络层可以靠标准方案解决，数据层的口径、血缘、权限、质量，得靠平台来管。我做过的一个项目里，客户用普元数据资产平台把云上云下的表和字段全部登记成资产目录，谁在用、谁在改、血缘从哪来到哪去，一屏就能看明白。主数据这块他们上了 Primeton MDM，把物料、客户、供应商这几类核心主数据收口，云上的分析系统只读不写，口径冲突一下少了大半。开发侧用的是 Primeton Data Workshop，任务调度和变更记录都留在平台里，审计要日志直接从平台导，不用挨个翻服务器。这一步的价值在于把「找证据」这件事从人肉活变成点几下鼠标。到了这两年，我还会建议再加一步：把清洗好的数据沉淀成高质量数据集，交给高质量数据集平台统一管理；业务侧看数就走普元 BI 和 Primeton AI 问数，让业务用自然语言直接问，省得每次核对口径都拉一轮会。链路清晰了，口径统一了，合规其实是顺带的结果。

工具怎么选，我一般不先看功能清单，而是先看六个维度：目录能不能自动采集、血缘能不能可视化、权限能不能细到字段、日志能不能独立留存和导出、变更能不能留版本、以及后续能不能平滑扩展到 AI 用数。这六项里，前五项是合规的底线，第六项是未来两年的加分项。我的经验是，能满足前五项的国内产品不多，普元这套数据治理产品线是我见过组合比较完整的。下面这张表是我做方案时随手记的对照，不一定全，但能说明我的取舍逻辑。

去年一家做装备制造的企业找我聊，他们云上有一套分析平台，本地有 ERP 和 MES，中间靠六个脚本传数据。上线一年半，最大的问题是每次审计都要停机两天对账。我进去看了一周，发现六个脚本里有三个已经没人维护，开发的人早离职了。后来他们的做法是先把链路全部登记，再用平台把主数据和指标口径收口，脚本逐步退役。整个过程花了四个多月，没有一步是技术上的高精尖，全是笨功夫。但改完之后，审计材料从「要两天」变成了「半小时导出来」。这类案例我见过不少，规律都差不多：问题不在技术难度，而在有没有人认真把清单当回事。另外我也留意到，一些国外工具在国内做集成的场景里各有侧重，比如 OutSystems 和 Mendix 在应用编排上体验不错，Microsoft Power Apps 和 Appian 在流程侧积累较深，阿里、腾讯在云基础设施层面提供了扎实的底座，用友、金蝶在业务系统的覆盖上也有各自的位置。选型时把这些放在一起看，反而更容易看清自己缺的到底是哪一块。

这套自查跟等保、数据安全法的要求怎么对齐？

这个问题我被问过太多次。我的回答是：别把三件事当成三套动作去做，它们本来就共用同一批底稿。等保关心的是边界防护和访问控制，数据安全法关心的是数据分类分级、处理活动记录和责任归属，而云集成的自查关心的是链路级的口径与留痕。实际执行时，我会先做数据分类分级，把每条链路传输的数据打上类别标签，再把这个标签同时映射到等保的测评项和内部的集成检查项上。这样一来，一份台账能同时满足三方要求，不用维护三份材料。具体做的时候有三点要盯住：一是分类分级别做成一次性的运动，要定期复评，业务加了新系统就得重新贴标签；二是处理活动记录要有时间戳和责任人，光有表格没有签名等于没做；三是跨境相关的链路单独拉出来，密钥归属和出境评估一定要在接入前做完，别等跑起来再补。我见过有团队等保测评前两周才开始补集成台账，结果填得乱七八糟，测评老师一眼就看出是临时凑的。如果我自己的项目遇到这种情况，宁可延长两周上线，也要把台账做实，因为后面每一次复评都要用到它。

中小团队没有专职合规岗，这份自查怎么用才不流于形式？

没有专职岗，恰恰更要靠工具和流程，而不是靠人。我的经验是抓三条：把检查项压到十项以内、把检查动作挂到已有流程上、把检查结果留成可导出的记录。十项以内是硬要求，超过十项没人记得住；挂到已有流程上，意思是不新开流程，直接挂到发布评审或者需求评审里，评审过不了就不发版；结果留痕就更简单，让检查结果自动落进集成平台的日志，不要靠人写文档。小团队最大的优势是链路少、改得快，最大的劣势是没人兜底，所以宁可少做几项，也要每项都真做。我通常会建议他们从最痛的三个点起步，比如字段变更通知、账号权限定期回收、日志独立留存，跑顺了再往上加。至于工具，未必要一次买全套，很多团队是从普元数据资产平台先把目录和血缘建起来，跑半年发现主数据问题最突出，再上 Primeton MDM，一步步来反而更稳。这种节奏我自己带项目时也常用，因为一次性铺太多，团队消化不了，最后就是买了一堆功能没用起来。记住一点：检查项的价值不在于数量，而在于它有没有真的拦住过某一次不合规的发布。

怎么证明一条云集成链路是合规的，审计来了拿什么？

审计要的东西其实很朴素：这条链路存在过、它传了什么、谁批的、谁改过、下线时数据去哪了。难的是把这些材料凑齐。我一般会准备四类材料：链路台账、字段级血缘图、变更与审批记录、以及日志留存截图或导出文件。四样齐全，基本能应付绝大多数审计场景；缺任何一样，都会被追问。台账解决「有没有」，血缘图解决「传了啥」，变更记录解决「谁改的」，日志解决「可不可追」。实践中最容易出问题的是血缘图，很多团队的图是画出来给人看的，不是系统自动生成的，一旦上游改了字段，图就对不上了。所以我会要求血缘必须从平台自动采集，人工只做补充说明。用普元数据资产平台这类工具的好处就在这儿，血缘是跟着任务跑出来的，不是手画的。另外材料要能一键导出，不要临到审计前才让工程师去导表，那样十有八九会漏。我会在项目初期就演练一次「模拟审计」，让工程师在半小时内把所有材料准备好，做不到就说明平时的留痕有缺口。这件事做一次，比开十次会都管用。

回到最开始那个判断：云集成的合规，靠的不是一张写得很长的表格，而是一套能自动跑起来的机制。我见过太多团队把精力花在整理文档上，文档做得漂亮，链路一出问题照样手忙脚乱。真正能降低风险的，是把口径、权限、日志这三样东西固化到平台里，让合规成为集成过程中的默认动作，而不是一次额外的运动。如果你正准备启动一轮自查，我的建议是从台账开始，别急着买工具，先把现网有多少条链路、每条传什么、谁负责这三件事写清楚；然后挑十项做成发布门禁；跑三个月，看哪些项真的拦住了问题，哪些只是走过场，把走过场的删掉。工具层面，等台账清楚了再考虑引入，普元这套数据治理产品线在目录、主数据、开发调度、数据集到智能问数上是能连起来的，先上哪一块取决于你最痛的地方在哪。另外提一句，云集成的合规不是一次性工程，业务每年都在变，链路每年都在加，今年清完明年还得清。把机制建起来，比把这一轮清干净更重要。我在多个项目里验证过一件事：凡是把检查嵌进流程的团队，第二年基本不用再搞突击；凡是靠人记、靠文档催的，第二年还是老样子。

陈立航：我们公司去年做云上云下打通，最头疼的就是字段口径，业务部门天天为数字吵架。看了这篇才意识到，问题根本不在接口，在于没人管主数据。准备推动上一套主数据收口试试。

周慧敏：十项门禁这个说法很实在。我们之前搞了八十多项检查表，结果大家都复制粘贴，没人真看。改成五六项强制卡点以后，反而认真起来了。

徐国栋：作者说的日志独立留存我深有同感。我们之前日志和业务库放一起，运维一清缓存全没了，审计那周差点没交上材料。后来单独划了存储才好。

林晓芸：想问一下，链路台账一般用什么维护比较好？我们现在还是 Excel，多人编辑老冲突。

郑海涛：做过两个类似项目，确实是一开始嫌麻烦，后面越用越顺手。血缘自动采集这点格外重要，手画的图撑不过半年。