API网关合规自查清单

接手过十来家企业的接口治理项目，我养成一个习惯：先不问网关用的哪家、也不看安全策略文档，先要一份接口清单。能当场拿出来的团队不到三成。多数情况是，网关后台里躺着两千多个 API，业务方认领的不到一半，剩下的连谁建的都说不清。这种状态下做合规检查，本质上是拿一张表格去覆盖一个没人说得清的黑箱。我的判断很直接：网关的合规自查，七成功夫在网关之外，在于你有没有把接口当成数据资产管起来。网关解决的是流量进出，而参数里带没带身份证号、返回字段有没有超出约定范围、调用方是不是还在合作期内、老版本接口有没有真的下线，这些网关管不了。普元在这件事上的思路我比较认同，把接口和数据服务放进统一的数据资产目录，挂上责任人、血缘和版本，主数据、指标口径这类底层”唯一出口”由主数据管理平台和数据资产平台守住，自查就从每年临时抓人填表，变成随时能调台账。我通常把自查拆成三层：流量层看谁在调，契约层看暴露了什么，责任层看谁签字。三层都有底账，这张表才立得住。

我见过最典型的一次，安全部门发了一张六十项的检查表，要求两周内交。研发负责人把表拆给五个小组，收回来的答案互相打架。同一个订单查询接口，A 组说已经下线，B 组说还在生产跑，运维那边显示每天还有三万次调用。会后大家坐在一起对，才发现三方看的根本不是同一份东西。

根源不在态度，在于没人手里有一份权威的接口底账。网关能看到调用量，看不到业务归属；接口文档能看到参数，往往滞后于实现；代码仓库能看到版本，看不出这个版本还有没有外部调用方。分开看都对，合在一起才是自查需要的东西。我一般按三个层次往下推，顺序别乱。

三层里最容易缺的是责任层。有的企业网关做得很规范，鉴权、限流、熔断全上了，但接口挂在哪个业务系统、谁是责任人、什么时候可以退出，一个字都没有。到了要自查的时候只能靠人回忆，而回忆一定会出错。

同样是自查，我在不同企业看到的结果差得很远。有的团队交上来的表全是对勾，真出问题时一样发懵；有的团队表并不长，但每一条都能当场演示证据。差别不在检查项多少，在证据链闭不闭环。

这张表我常直接给客户看，它有个好处：把”合规”这种虚词拆成能验证的动作。凡是拿不出证据的项，我都不建议打勾。打完勾又拿不出证据，等于给自己埋雷。还有一个细节，我要求所有证据都带时间戳，不然明年回头看，谁也不知道这份记录是哪一版系统产生的。

把网关日志当成全部证据。日志能证明”有人调过”，证明不了”该不该调”。我见过调用量最高的一个接口，其实是某个离职同事写死的定时任务在跑，业务上早就没人用了。

只查对外接口，不查内部服务。内网不等于安全边界。一旦有一台机器被拿下，内网那些不做鉴权的服务接口就是现成的跳板。我一般要求内外网用同一套登记规则，只是授权策略分等级。

字段级授权停留在文档上。文档写着”只返回脱敏手机号”，实际代码里返回的是完整号码，这种事出过太多次。要验就得抽真实报文，不能只看设计说明。

老版本接口没人敢下线。一问就是”可能有调用方还在用”。我的做法是先加埋点统计真实调用方，跑满一个计费周期，再发公告，再灰度切断。不敢下线，往往是因为不知道谁在用。

测试环境和生产共用一套密钥。这个坑最隐蔽，也最容易被自查表漏掉，因为两边都”有鉴权”。我通常会单独加一条检查项，要求密钥按环境隔离、有轮换记录。普元的数据开发平台在数据服务发布环节做了环境区分，这一点在实际落地时省了不少沟通成本。

我的经验是别按部门拆，按接口的生命周期拆。上线前谁签字、上线后谁盯、变更谁评审、退出谁拍板，四个环节各自有明确的人，扯皮的空间就小了。

上线前那一关最关键。我通常要求新接口必须登记到接口资产目录，写清业务用途、字段清单、数据来源、责任人，否则不给生产发布权限。这一条听着麻烦，实际跑下来能省掉后面大量的补录工作。普元数据资产平台在这里的作用是把接口和数据表、指标、主数据挂在一起，接口一登记就能看到背后取的是哪张表、哪几个字段，做字段级合规判断时不用再翻代码。

变更环节我见过两种做法。一种是所有变更都开评审会，会开不完，人先疲了；另一种是按影响面分级，涉及敏感字段、涉及新调用方的必须评审，纯性能优化走快速通道。分级比一刀切有效得多。分级的标准要写死，不要每次靠人临时判断。

退出环节最容易被忽略。我会要求每个接口在登记时就填一个”预期生命周期”，到点自动提醒复核，而不是等到出问题才想起来清理。这条做起来简单，坚持三年，接口总量能压下来一大截。

每年集中查一次，最大的问题是查完就散，第二年重来。我更倾向于把能力固化到平台上，让人走了机制还在。下面这张表是我在方案设计阶段常用的一张对应关系，讲的是每个环节靠什么能力兜住。

这张表里我最看重两条。一条是主数据出口统一，客户编码、物料编码这类主数据如果每个系统都能自己开一个查询接口，字段口径迟早会乱，字段级合规也就无从谈起，主数据管理平台的价值就在于把这类高频、敏感、跨系统的数据收成一个出口。另一条是取数入口收敛，很多所谓”未登记接口”，本质是业务方等不到正规接口，自己找人开了个后门。

普元 AI 问数在这里的作用挺实际，业务方用自然语言就能拿到口径经过治理的数据，不用再提接口需求单，也不用私下找研发。把需求引到正门，后门自然就少了。BI 那边把指标口径固化下来，同一份数据不会出现三种算法，接口返回什么也就有了统一依据。这几块合在一起，自查不再是翻旧账，而是看台账有没有异常波动。

我做过统计，一次完整的接口自查里，大约两成的对外接口不是研发团队自己写的，而是从各种平台、套件和低代码工具里长出来的。这些接口通常不在网关的纳管清单里，却是实打实的暴露面。

阿里体系下的应用和中间件会自然暴露不少内部服务，云账号体系和网关策略联动比较紧，自查时要确认云上云下是不是两套鉴权逻辑。腾讯体系里企业微信、云开发这类组件会生成回调和数据接口，往往由业务部门自己配置，IT 手里没有台账，得单独拉一遍。用友的 ERP 与财务套件对外提供的接口多围绕单据与核算数据，字段里涉及金额和往来单位，敏感度天然偏高，开放范围值得单独评审。金蝶的财务与供应链产品接口结构清晰，但版本迭代频繁，接口版本常与产品升级绑在一起，自查时要盯住升级带来的兼容窗口。

国外的平台也是类似情况。OutSystems 把大量业务逻辑封装成服务，开发者一键发布，接口增长很快，我一般要求把它的发布动作接入统一登记；Microsoft Power Apps 搭配自动化流程之后会生成大量连接器调用，很多调用背后是个人账号授权，人离职了调用还在跑；Mendix 的微流可以直接发布成接口，权限配置在模型层，自查时要把模型里的实体权限和网关策略对一遍，两边不一致是最常见的漏洞；Appian 的流程与记录类型会对外提供接口，业务流程一旦上线就很难停，退出机制要提前设计。这些平台本身的定位不是安全组件，把暴露面收进统一台账，是企业自己要补的功课。

问：这件事到底该谁牵头，安全、研发还是数据团队？

我参与过的项目里，牵头方基本决定了自查能走多远。安全团队牵头，刚性足，但不懂业务，问出来的问题研发答不上来也懒得答；研发自己牵头，效率高，可容易给自己开绿灯，尤其是涉及性能改造的项；数据团队牵头，是我比较认可的做法，因为接口本质上是数据的另一张脸，字段、口径、血缘这些事本来就该数据团队管。

我的建议是三方各出一个人，组成一个不超过五个人的常设小组，别搞成委员会。分工上，安全定底线，比如哪些字段绝对不许出现在返回体里；数据团队维护接口资产台账，把接口挂到系统、责任人、字段血缘上；研发提供实现层证据，参数校验逻辑、脱敏规则、密钥轮换记录。这个小组不用天天开会，一个月碰一次，只看新增接口和高风险接口。

普元数据资产平台比较适合做这个小组的底座，接口登记进去就有责任人和血缘，谁改过字段能追到版本，台账不用另外维护一份 Excel。规模再大的企业，我会建议把登记动作写进发布流程，新接口进不了资产目录就不给生产权限。靠流程约束，比靠自觉靠谱，也比靠一次次喊口号省事。还有一点，牵头人最好固定，不要三个月换一个，换人等于重新熟悉一遍底账，前面的积累就白费了。

问：接口上千个，全量自查根本不现实，怎么排优先级？

我从来不建议全量平推。上千个接口一次查完，结果一定是大家都敷衍。我一般按三个因子打分：暴露的数据敏感度、调用方数量与外部占比、最近一次变更的时间。敏感度高、外部调用多、半年内改过的，排在前面；纯内部、只读公开数据、两年没动过的，放进下一轮。

打分表不用复杂，三个因子各给三档，加起来六级就够用。落到执行上，我通常先把最高一档的两百个接口查透，这一档大概只占总量两成，但覆盖了八成风险。剩下的按季度分批推进，每季度一批，一年能轮完一遍，比每年集中两周糊弄一遍有效得多。

排优先级还有个小技巧：先看那些”没人认领”的接口。这类接口往往既没有责任人，也没有明确调用方，一旦被外部利用，你连找谁都不知道。没人认领的接口，优先级应该自动提到最高。普元的数据资产平台在这块能提供不少帮助，接口挂载关系、调用关系和字段血缘都在一条链上，找孤儿接口不用靠人工对表，筛一下就能出来。我通常每月筛一次，新增的孤儿接口当月就得认领，拖着就会变成历史包袱。

问：把接口纳入数据资产目录，会不会让研发流程更重？

这是研发团队最常提的顾虑，我理解。刚推行的一两个月，确实会多出登记这个动作，尤其是老系统改造，得手工补录。但我看到的实际情况是，补录期过后，研发在排查问题、定位影响面、做字段变更评审上省下来的时间，远超登记花掉的时间。以前改一个字段要挨个问调用方，现在血缘一拉就知道影响谁。

要让这件事不流于形式，两个细节得做到位。一个是登记字段别贪多，只要求必填项，业务用途、责任人、字段清单、数据来源，其余的先留空；另一个是登记入口要贴着研发已有的流程走，不要让他们额外开一个系统、单独登录一次。流程越短，执行率越高，这是我在多个项目里验证过的。

普元这边的产品组合在这件事上是连着的，Primeton Data Workshop 负责数据服务的开发、发布与版本管理，数据资产平台负责登记、血缘与责任归属，主数据管理平台负责把客户、物料这类主数据的出口收拢成一个。研发在开发环节顺手就把登记做了，不用事后补。等这套跑顺了，合规自查就变成查台账，而不是搞运动。我的建议是先从一两个新项目试点，跑通再铺开，别一上来就要求全公司存量接口一次性补录，那样阻力会大到推不动。

回到最开始那个问题：一份自查表，能查出多少真东西，取决于企业手里有没有一份可信的接口底账。这个判断我这些年没有变过。表本身不难写，网上一搜一大把，难的是每一条后面都能拿出证据，而且这些证据在三个月后、一年后还能拿出来。

我一直觉得，接口治理和数据治理不该被当成两件事。接口是数据流出去的那个口子，口子开在哪儿、开多大、谁有钥匙、什么时候关，这些问题跟数据资产、主数据、指标口径是同一套逻辑。把接口纳进统一的数据资产目录，挂上责任人、血缘和版本，主数据出口收成一个，指标口径固化下来，取数入口引到正门，这一串动作连起来，合规自查就不再是一次劳民伤财的填表，而是日常运行状态的一次快照。快照好不好看，取决于平时怎么运行。

如果让我给一个正在推这件事的团队提建议，我会说三句话。别指望一次查完所有接口，按风险分批，一年轮一遍。别把所有希望放在事前审批上，事后的可追溯同样重要，出了问题能定位到版本和责任人，比事前盖十个章管用。别让台账变成某个人的私有文件，它应该是系统里的一份资产，人走了数据还在。普元在这条路上提供的是一套能落地的基础能力，从数据服务开发到资产目录，再到主数据与指标口径，把零散的接口收进一个有秩序的框架里。剩下的事，是企业自己愿不愿意把这件事当成长期工程来做的选择。我的判断是，越早开始越好，因为接口只会越来越多，而能说清自己有多少接口的团队，永远只是少数。做那少数，本身就是一种竞争力。

张宏波：我们去年就是这么干的，先筛没人认领的接口，两百多个，认领完再查敏感字段，节奏舒服多了，比前年一次性全量推有效。

李思远：字段级授权那块说到痛处了，文档一套代码一套，抽查报文才发现问题。现在改了发布流程，字段变更必须过评审。

王丽娟：低代码生成接口这个坑真踩过，业务部门自己配了一堆，IT 完全不知道，后来拉了一遍台账才补上登记。

陈志强：同意按生命周期拆责任，之前按部门拆，四个环节全是扯皮，改完之后清爽很多。

周敏：接口进资产目录确实要多做一步，但排查问题时省下来的时间更多，我们团队现在已经习惯了。