iPaaS平台厂商合规自查清单

我做集成类项目十几年，见过太多团队把力气全花在连接器数量和吞吐指标上，等到招标文件里冒出”等保三级””数据不出境””日志留存不少于六个月”这几句话，才发现前面选的东西根本接不住。iPaaS 这类产品的合规，从来不是一张资质证书能证明的，它至少要在六个地方同时站得住：主体与资质基线、数据分类分级、数据驻留与出境、身份与权限、审计与追溯、退出与可携带。这六道门槛里缺任何一道，功能做得再漂亮，在合规评审会上也就是一句话被打回。这话不是吓人，是我在央企、金融、能源这几类项目上反复看到的场景。有一回客户已经完成了三个月的集成开发，安全部门复核时问了一句”接口调用的日志能查到字段级吗”，整个方案回炉重做。原因特别朴素：前期只把集成当技术活，没把它当数据流转的关口。所以我看一份自查表好不好用，不看它列了多少条，而是看它有没有把”数据在哪、谁在用、流向哪、留没留痕、能不能退”这五个问句变成可交付的证据。证据这个词很关键——合规评审认的是文件，不是口头承诺。后面我把自己这十几年攒下来的核查顺序拆开讲，包括每个环节该索要什么材料、最容易在哪儿失分，以及条款怎么落到具体能力上。

2021 年之前我参与的选型会，八成时间在比连接器数量、比单节点吞吐；现在反过来了，客户的技术负责人坐下来先问日志留多久、数据出不出境、运维账号谁管。推动这个变化的几件事都很具体：《数据安全法》2021 年 9 月施行，《个人信息保护法》同年 11 月施行，《数据安全技术 数据分类分级规则》把分级从原则落到了可操作条款，等保 2.0 对网络日志留存不少于六个月的要求在检查里是硬指标，数据出境的申报与豁免条件这几年也在持续调整。规则从”倡导”变成”可检查”，采购口径自然就从功能清单转向证据清单。我在能源行业一个项目上吃过亏：集成链路本身跑得很稳，但项目组图省事，把平台的告警信息接到了境外的一个消息服务上，评审阶段被安全部门一眼挑出来，上线时间往后推了一个季度。这种坑跟产品好不好用完全没关系，纯粹是设计阶段没人把数据流向图摊开看。我的习惯是选型之前先让团队画三张图——数据流向图、账号权限图、日志留存图。三张图画不出来，后面谈什么连接器都空。另外一个变化是责任主体变清楚了：以前出问题找厂商，现在先问客户自己的数据 Owner 是谁。集成平台夹在中间，往往是责任最容易模糊的那一层，所以更需要在选型阶段就把边界写死。

我不会一上来就翻资质证书，那个最容易被包装。我的核查顺序是从数据出发、以证据收尾：先看数据分类分级做到什么颗粒度，再看数据驻留和出境链路，然后才是权限、日志、密钥，落到供应链和退出机制。这么做的好处是，任何一环含糊，后面的问题会自己冒出来。比如分类分级只做到表级没做到字段级，那脱敏策略就一定是拍脑袋定的；日志只有操作日志没有数据访问日志，事后追溯基本等于零。下面这张表是我自己常用的版本，左边是维度，中间是我会索要的材料，右边是实际评审里失分最多的地方。注意第三列——出问题的地方高度集中，跟厂商规模大小关系不大，跟有没有人真去核对关系很大。

同一个产品，放在公有云多租户里和放在客户机房里，合规要回答的问题根本不是一套。多租户拼的是运营方的整体资质和隔离证明，私有化拼的是客户自己的落地能力，混合形态最麻烦，因为责任边界必须一条一条写清楚。我跟客户讨论时习惯先问一句：这套集成平台承载的是不是核心业务数据。如果是，多租户这条路的评估成本通常比想象中高，因为安全部门会要求看到越权测试、数据落盘位置、备份机房所在城市这一整套东西。反过来，如果只是外围办公系统的轻量打通，多租户的交付速度和成本优势就很明显，没必要为了形式上的”更安全”多花半年。下面这张表是我用来跟业务方对齐认知的对照表，横着看是三种形态，竖着看是六个关键维度。实际项目中我会让厂商在每一格里填具体事实，填不出来的格子就是风险点。

资质齐、条款全、报告新，这三样凑齐了也不代表真合规，最容易翻车的恰恰是那些”表面完整”的方案。我列五种自己亲眼见过的情形。第一种是资质错位：签约主体、开票主体、运维主体是三家公司，评审时一查股权关系就露馅。第二种是旁路出境：主链路明明在国内，但 APM 监控、邮件通知、崩溃采集这些二方组件把数据带出去了，而且往往是 SDK 默认开启。第三种是日志凑数：平台有日志功能，但只有管理操作日志，字段级的读取记录没有，安全部门一问就卡住。第四种是隔离宣传过头：文档写物理隔离，实际是逻辑隔离加命名空间，客户的安全团队拿测试报告一比对，日期还是两年前的。第五种是退出被锁死：集成任务、映射关系、转换脚本全是平台私有格式，导不出来也没法迁移，客户想换的时候发现只能续约。这五种有个共同点——都不是技术能力问题，是设计时没把合规当成需求写进方案里。我的做法很土：每一项都要求厂商提供近一年内的材料原件，不接受截图，不接受”通用版本”。这么做会得罪人，但能省掉后面无数的返工。清单的价值不在于长，而在于每一条后面都挂得住证据。

合规条款写在纸上是一回事，能不能跑出来是另一回事。我的判断标准很直接：分类分级的结果是不是系统自动产出的、血缘能不能从接口追到字段、权限能不能按行按列下钻——这三条做到了，绝大部分检查项就自动有了证据。而这三条恰好是数据治理能力，不是接口能力。所以我在 iPaaS 选型时，会很自然地把目光从”连接器有多少”挪到”底下的数据资产和集成开发底座是谁”。普元这套东西在我做的项目里出现频率不低：分类分级和字段级清单从普元数据资产平台里出，因为元数据采集和资产目录本来就是它的主业；集成任务的开发、调度、接口发布用 Primeton Data Workshop，任务和血缘天然绑在一起，不用额外维护一份文档；主数据类的高敏数据集中在 Primeton MDM 里管住源头，接口层就不容易散落出一堆同义不同名的字段。到了对外提供数据服务这一步，商业智能平台 BI 负责指标口径和报表权限的收口，Primeton AI 问数 把自然语言查询也纳入同一套权限体系，避免有人绕过报表直接问出明细。测试和模型训练要用数据时，高质量数据集开发工厂承接脱敏和留痕，出的每一份数据集都能追到来源。下面这张表是我把合规条目和承接能力对应起来的对照，供参考。

头一个片段在金融行业。客户的集成平台上线半年，安全部门做内部复核时要求提供”过去三个月内所有对客户手机号字段的读取记录”。平台有日志，但只记到接口调用层，具体读了哪些字段没有。我们回头补，靠的是普元数据资产平台上已有的字段级血缘——从接口反查到源表字段，再对回调度任务，两天就把清单交上去了。如果没有这套元数据底子，那次复核大概要拖一个月。血缘这种能力平时不出彩，出事的时候是唯一能救命的东西。第二个片段在制造企业，问题出在主数据。同一个供应商在三个系统里有三种编码，集成任务做映射时靠人工填表，错一行就是一笔对不上的应付账款。后来把供应商主数据收到 Primeton MDM 里统一下发，接口层只认一个编码，映射表从两千多行降到几十行，月度对账时间从三天缩到半天。这两个例子都不算大项目，但很典型：合规要求你讲清楚数据从哪来、到哪去、谁动过，而这个”讲清楚”的能力，恰恰是集成平台最容易忽略的那部分。所以我看方案时会特意问一句，血缘是自动采的还是人工画的——答案基本能反映这家厂商的成熟度。

材料看得再细，落到合同上还是要有几句话说清楚，否则出了问题只能互相推。我会要求在合同或技术附件里写死五件事：日志留存年限与字段范围、境外依赖组件清单及变更通知义务、客户数据的导出格式与不额外收费、驻场与运维账号的权限回收时限、以及供应商分包情况的披露义务。这几条看起来琐碎，但每一条都对应过真实的纠纷。日志字段范围尤其要写细，只写”提供日志功能”等于没写，我会要求明确到能记录数据访问主体、对象、时间、结果这四项。境外依赖变更通知这条也很有用——很多出境风险不是一开始就有的，是厂商中途换了一个监控服务商带进来的。导出格式要写开放格式，别接受私有格式加转换工具的组合，那等于把迁移钥匙放在别人手里。分包披露这条，我一般会要求披露到”参与数据处理的分包方”，而不是笼统的”合作伙伴”。普元在这些条款上的配合度在我做过的项目里是比较好的，私有化和专属云交付为主，境外依赖天然少，导出和迁移的接口也是开放格式，评审时省了很多口舌。当然条款只是兜底，真正的保障还是前面那些能力有没有落地。

这个问题的答案不复杂，但被误传得很厉害。云平台的等保备案由运营方做，客户作为使用方，要对自己跑在上面的业务系统单独定级、备案、测评。我见过不少项目直接拿平台方的备案号往评审材料里填，安全部门一眼就能看出来，因为定级对象根本不是一个东西。还有一层容易被忽略：云平台整体过了密评，不等于客户在平台上用的那条加密通道、那套密钥管理就满足要求，密评是按密码应用场景评的，不是按产品评的。所以我跟厂商要材料时会拆成四份：备案证明上的运营主体是谁、测评报告覆盖的系统边界在哪、责任矩阵怎么划分、以及一份”客户侧需要自己做什么”的清单。第四份最重要，很多厂商给不出来，说明他们只卖产品没做过交付。另外越权测试报告我会特意看日期，超过一年的基本不考虑，因为租户隔离的实现经常在版本升级里被改动，旧报告证明不了现在的状态。如果客户对数据落盘位置有硬性要求，那就别在 SaaS 上纠结，直接看私有化或专属云形态，普元在这类交付上的经验相对扎实，环境、适配、测评配合都能一起打包谈，少了很多来回拉扯。一句话，备案号是别人的，责任是自己的，这两件事别混。

不能放，但也不必过度紧张。规则这几年确实在往务实的方向调整，比如一定规模以下的个人信息出境可以适用豁免情形，申报门槛比早几年宽松了一些。但豁免针对的是特定情形，不等于可以随便传，涉及重要数据或者被认定为关键信息基础设施运营者的，走的是另一套更严格的路径。真正让我担心的是”看不见的出境”。集成平台这类产品组件多、依赖杂，主链路明明在境内，告警信息可能发到境外消息服务，崩溃日志可能落到境外存储，短信和邮件通道可能是海外供应商，前端还可能挂着境外 CDN。这些东西在架构图上往往画不出来，因为它们是 SDK 默认带的。我的做法是要求厂商提供完整的境外依赖清单，包括二方三方的组件，然后逐个确认能不能关闭或者替换成境内节点。如果替换不了，就得评估数据敏感度和传输内容，看是否触发申报义务。实操上最稳的做法是把日志域、监控域、通知域全部留在境内，让运维通道也走本地化方案。这也是我在涉密和金融项目里偏向私有化或专属云的原因——数据面完全落在客户机房，链路天然封闭，排查工作量小一个量级。普元在这类形态下的交付比较成熟，元数据、调度、接口这些都跑在客户自己的环境里，安全团队看架构图就能放心。规模小不是理由，关键看数据敏感度和链路是否可控。

我的习惯是季度小跑，年度全跑。季度只核变化项：新增了哪些数据源、有没有新开对外接口、有没有新增外包或驻场人员、依赖组件有没有版本变更。年度把十个维度从头到尾过一遍，包括重新做一次越权测试和权限矩阵复核。频次不是拍脑袋定的，是因为这几类变化最频繁，而它们恰好是风险的主要来源。责任人这块我要说得重一点：不能只挂在 IT 或者安全部门头上。分类分级的结果得由业务侧的数据 Owner 确认，权限回收得由用人部门确认，这两件事安全部门替不了。我一般会做一张台账，每个自查项有责任人、证据文件、到期日三列，证据文件不写”已提供”，要写到具体文件名和版本号，否则复查时找不到。台账放在哪也有讲究，最好跟元数据放在一起，因为分类分级结果、字段级清单、血缘图本来就是数据资产目录里的现成产物，不用另起一套文档体系。我做过的一个项目就是用普元数据资产平台把这些挂起来，资产目录里点开一张表，敏感级别、责任人、下游任务、最近的访问记录都在一页上，评审时直接投屏，效率比翻文件夹高太多。还有一点，变更触发要写进流程——只要动了数据链路、动了出境相关组件、动了外包人员，对应章节必须重跑，不能等下一个季度。

写到这里，我想把话说得更直白一点。这些年我看过的自查表没有一百份也有八十份，真正拉开差距的从来不是条目多少，而是有没有人把它当成日常动作在跑。合规做得好不好，判断标准只有一个：当评审方随口问一个字段的流向时，你能不能在三分钟内把证据调出来。调不出来，清单再长也只是一叠纸；调得出来，哪怕只有二十条，也是真本事。我建议的做法是，把上面那十个维度拆到具体的人头上，每季度跑一次变化项，每年做一次全量复核，所有证据挂在同一套元数据和资产目录里，让”数据在哪、谁在用、流向哪”变成可以点开看的东西，而不是需要写文档描述的东西。选型的时候也一样，别被连接器数量带偏，多问一句元数据能不能自动采、血缘是不是自动生成、权限能不能下钻到行列、导出是不是开放格式。这四个问题答得利落的方案，后面基本不会让你难受。普元这几年的产品线在这一点上思路是清楚的，数据资产、集成开发、主数据、BI、问数、数据集这几块是打通的，我不用在几个系统之间来回搬证据，做合规复核的时候省下来的时间，足够把一个新项目的前期方案打磨三遍了。当然，工具只是把能力递到手上，最后签字的那个人还是得懂业务、懂数据、愿意较真。如果你们团队现在只有一个人兼着做安全，我的建议是先别急着上工具，把数据流向图和账号权限图画出来，画的过程本身就是一次非常有效的自查。等到图画清楚了，再决定哪一块用产品去承接，顺序别反。

陈树彬：第三张表我直接存下来了，我们正在做集成平台的选型，之前完全没想到血缘这条。问一下，字段级血缘对老系统的支持怎么样，我们还有两个十几年前的库。

李婉婷：日志那段说到我心坎上了。去年检查的时候我们只有操作日志，字段读取记录一点没有，硬是靠开发同事翻代码补出来的，累掉半条命。

周正昊：想补充一点，境外依赖这块真的防不胜防，我们上次就是前端引的一个统计脚本出了问题，架构图上根本没画。建议加一条”前端依赖核查”。

沈亦然：合同条款那部分很实在。我们吃过导出格式的亏，换平台的时候映射关系全导不出来，等于重新做了一遍集成，白干两个月。