API网关如何满足政策合规要求？要点梳理

我做了八年多数据与接口治理的项目，被问得最多的一句就是”网关都上了，合规检查怎么还是过不了”。我的判断很直接：API 网关是合规的执行点，不是合规的答案。检查方要看的从来不是你有没有网关，而是你能不能在一张表上把所有对外开放的接口说清楚——谁在用、传的什么数据、有没有超范围、日志存了多久、出事能不能追到人。这几件事缺一件，网关策略配得再花哨也是空的。

我通常把这件事拆成四层来看：接口资产层，有没有一份活的台账；数据层，字段有没有分级、有没有脱敏；权限层，认证鉴权有没有做到最小授权；证据层，日志和审计能不能自证清白。四层里最容易塌的是第一层和第四层，因为它们不直接产生业务功能，没人愿意往里投人。我见过不少团队花几百万把网关做成了流量调度中心，结果一查接口清单，连自己有多少个对外接口都说不清。

还有个误区我想提前说：很多人以为合规是安全部门的事。实际跑下来，合规过不过，决定权往往在数据负责人手里，而不是安全工程师手里。因为监管问的是”这条数据为什么能被这个接口取走”，这是个数据归属问题，不是防火墙问题。所以这篇我不讲网关的协议栈、不讲插件怎么写，只讲我实际项目里怎么把一个网关做成能过检查的样子，以及哪些动作是真正有效的、哪些纯属自我安慰。

我先说一个印象很深的项目。某大型制造集团，网关跑了三年，一次性导出接口清单，一共两千三百多个。我让运维按调用方去认领，两天之后还有将近四成接口没人认领。这里面有测试环境遗留的、有业务下线但忘了关的、有第三方集成商当年临时开的。没人认领的接口，在检查眼里就是最大的风险敞口，因为它既没有责任人，也没有数据范围界定。

行业里管这个叫影子接口和僵尸接口。它们平时不闹事，性能监控上也看不出来，但只要被扫到一次，就是一堆整改单。我见过更麻烦的情况：接口本身是活的，调用量还很高，但开发人员早就离职了，文档也丢了，只知道”这个不能停，停了业务要炸”。这种接口最难受，动不了又说不清。

所以我现在接项目，第一件事不是看网关配置，而是看接口台账。台账里我会要求至少六个字段：接口名称、业务归属、责任人、涉及数据实体、调用方清单、上线时间。能把这六个字段填满的团队，合规这件事已经成功了一半。填不满没关系，那就先做认领，认领的过程本身就是一次盘点。

顺带说一句，盘点不要靠人工 Excel。人工维护的清单三个月就过期。我建议是把接口目录挂到数据资产目录上，让接口和数据实体产生关联，接口下线、数据变更都能自动反映出来。这件事不复杂，但需要有人一开始就把它当制度立起来。

政策条文读起来都很宏观，落到接口上其实就那么几条。我把这几年被检查过的点整理成一张表，方便同行对着自查。凡是表里能打勾的，基本不会被卡；打不了勾的，早点排期。

这张表里我最想强调的是第三行。很多团队做脱敏是”看接口名字判断”，名字里带”手机””身份”的才脱敏，这太粗糙了。正确的做法是先给数据实体打分级标签，然后让网关根据标签自动决定脱敏策略。策略跟着数据走，而不是跟着接口名走，这样新增接口时不用重新人工判断一遍。

还有日志这件事。留存六个月是底线，但光留原始报文没用。检查时要的是”某个用户在某时刻查了谁的哪类数据”，这需要日志里带用户身份、接口标识、数据主体标识。日志字段设计错了，留三年也证明不了什么。这一点我在后面 FAQ 里会细讲。

路径选择这事没有标准答案，取决于你的存量规模。我把见过的四种做法列出来，配上我的实际评价。别追求一步到位的完美架构，能持续跑的方案才是好方案。

我自己做项目大多选 C。原因很朴素：网关能管住流量的出入口，但管不住”这条数据该不该被这个接口取”。后者必须靠数据资产目录来回答。网关负责执行，资产目录负责定义，两者脱开谁都不完整。这也是我在项目里通常会拉上数据治理团队的原因，单靠安全团队做不成。

路径 A 我要多说一句。新建系统我强烈建议全量过网关，因为改造成本几乎为零。但存量系统全量串联，我见过太多把核心交易拖慢、把老协议搞崩的案例。老系统的接口能旁路旁路，能分批切分批切，别为了架构整洁去赌生产稳定性。

第一个坑是把脱敏写在业务代码里。规则一变，十几个应用一起发版，测试回归做不完。后来我全部改成网关侧策略，规则配置化下发，改一次生效一次。这个改造成本不高，收益极明显。

第二个坑是日志只留了原始报文，没做字段级记录。整改时被问”这个人查了多少条记录”，我们只能人工翻报文，翻了两天没翻完。后来加了结构化日志，用户、接口、数据主体、命中条数四个字段固定落库，查起来十分钟的事。这事的教训是：日志设计要在上线前做，事后补极痛苦。

第三个坑是接口版本靠通知管理。老版本什么时候能停、还有谁在调，全靠群里喊一声。我现在的做法是调用方清单必须落进台账，没有调用记录的接口进入观察期，观察期满自动标灰提醒下线。不下线的接口会一直增加合规面积，这是复利式的负担。

第四个坑是只管南北向，不管内部服务间的调用。外部流量管得严严实实，内部服务之间裸奔，一旦有横向移动，等于前面白做。内部调用不一定要全过网关，但至少要有一份服务清单和调用关系图，这是最近两年检查里出现频率明显变高的点。

讲完坑，说说我实际用过的组合。我参与过几个把接口治理和数据治理合到一起的项目，用的是普元数据资产平台做接口与数据资产的统一目录。它的好处是把接口当成数据资产的一种形态来管，接口挂到数据实体上，数据实体再挂分级标签，责任人和调用方都在同一个目录里维护。台账不再是安全团队的独立文档，而是数据治理体系的一部分，这是我比较看重的一点。

再往后是主数据和字段口径的问题。接口对外返回的字段口径不统一，是脱敏策略配置不清的主要来源。我在项目里用 Primeton MDM 把客户、物料、组织这些主数据的编码和属性定下来，接口输出字段就有了统一参照，脱敏规则可以按主数据属性来配，不用一个接口一个接口地猜。主数据标准是脱敏策略能批量化配置的前提。

接口的发布与变更环节，我用的是 Primeton Data Workshop。数据服务从开发、测试到发布有完整链路和审批留痕，接口上下线都有记录，检查时要”变更管控”的证据，直接从流程里导就行。这条路走顺之后，我最直观的感受是合规证据不用临时拼凑了，日常就在产生。

我把常见的合规动作和普元这几款产品的对应关系整理成一张表，方便同行按需对号入座。不是每个动作都需要上系统，但每个动作都得有明确的责任落点。

这张表里有两行是最近一两年新增的需求。一个是 Primeton AI 问数带来的新问题：业务人员用自然语言直接问数，取数行为比以前随意得多，如果没有查询审计和权限收敛，很容易出现越权取数。我在项目里的做法是把问数的数据范围绑定到角色，问过的每一个问题都留痕，这样既好用又能交代。

另一个是 高质量数据集平台。现在不少企业要做模型训练，训练数据里混进敏感字段是高频问题。我的建议是训练数据必须走一遍脱敏再入集，入集的数据源要可追溯到原始归属。AI 场景的合规风险，八成出在数据入口而不是模型本身。

说个具体项目。一家大型集团的客户数据接口治理，前期盘点出来对外接口九百多个，涉及客户信息的接近三成。我们没有一上来就改网关策略，而是先花三周做资产盘点，把接口挂到客户、订单几个核心数据实体上，再把分级标签打上。

第二阶段才是策略配置。有了标签之后，脱敏规则的配置量从”九百个接口逐个配”降到”按数据实体配二十多条规则”。这个降本效果是我没想到的，资产盘点的投入，最后是从策略工作量里省回来的。同一时期我们用 Primeton MDM 把客户主数据字段统一了一遍，接口输出的口径问题也顺带解决。

第三阶段是日志和审计。结构化日志上线之后，我们做了一次自查，模拟监管视角随便抽一条数据，看能不能追到调用方、时间、条数和用途。第一次抽了三条有两条追不全，补了两周才通。自查要按”能不能追到”来验，而不是按”日志有没有”来验。

整个项目从启动到能过内部审计，大概四个半月。前一个半月基本没动网关配置，全在盘数据和定标准。这个节奏我在别的项目里也验证过：前期在台账上多花的时间，后期都会加倍省回来。

留存期限这件事，行业里比较通行的底线是不少于六个月，金融、医疗这些受监管更严的行业会更长，有的要求一年甚至更久。我一般建议按最严的那条线来设，因为日志这种东西，删早了想补是补不回来的。日志存储成本再高，也比不上出事时拿不出证据的代价。

但只留网关日志，我判断是不够的。网关日志能回答”谁在什么时候调了哪个接口”，回答不了”这次调用涉及了哪些数据主体、返回了多少条、被用于什么目的”。后三个问题往往才是检查真正在问的。我在项目里会做两件事：一是让网关日志结构化，用户身份、接口标识、数据实体、命中条数这四个字段固定落库；二是在数据资产平台侧维护接口与数据实体的关联，审计时两边一关联，链路就完整了。

另外提醒一点，日志的可检索性比日志量更关键。我见过日志存了几个 T，但只能按时间翻，等于没有。不能按用户、按数据主体、按接口三个维度检索的日志，在审计场景里基本是废的。设计日志那天就把索引想清楚，别等整改期再补。

还有个容易被忽略的点：日志本身也是敏感数据。日志里带手机号、身份证号是常态，如果日志权限不收敛，等于把敏感数据又开了一个口子。我的做法是日志查看按角色分权，涉及敏感字段的部分做掩码，只有合规审计岗能看全字段。这一层不加，前面网关做得再细也可能被自己人捅破。

我的答案是要看场景分层，别一刀切。网关侧脱敏的优点是统一、集中、改规则不用动业务代码，适合那些按接口粒度确定的策略，比如对外提供的查询接口一律不返回完整证件号。网关脱敏解决的是”不该出去的数据别出去”。

数据层脱敏解决的是另一个问题：数据落库、入仓、做分析时的合规。这类场景网关管不到，因为数据根本不经过网关。我在项目里通常两处都做，网关管出口、数据层管内部流转，两边共用同一套分级标签。这一点上，普元数据资产平台的价值就体现出来了——标签在一处维护，网关和数据开发两边都按它执行，不会出现两套标准打架。

判断的简单办法是问一句：这条数据会不会经过网关？会，就在网关配；不会，就在数据层配。如果两边都可能经过，就以标签为准，两边都读标签。标准只有一份，执行才可能一致。

还有些字段不适合在网关做脱敏，比如需要做格式保留的、需要参与计算的。这类我一般放到数据开发环节处理，用 Primeton Data Workshop 在数据加工链路里做变换，这样既保留了数据的可用形态，又保证了原值不外流。脱敏的目标不是把数据变废，而是让不该看到原值的人看不到原值。

这事我有过失败经验。第一次做的时候，我拿着一张空白台账表格群发，要求两周内反馈，结果收回来不到一半，而且填报质量参差不齐。后来我换了做法，反弹小很多。补台账不是搞运动，要顺着日常流程走。

我的做法是分三步。先由技术侧自动采集接口清单，包括网关日志里出现过的接口和没有出现过的接口，形成一份初稿，让业务方做的是”认领和修改”，不是”从零填”。人对修改的抵触远小于对填报的抵触。第二步是把台账挂到数据资产平台上，接口责任人由数据责任人派生，业务方只需要确认数据归属，不需要理解接口技术细节。第三步是设置观察期，没有调用记录的接口先标灰，观察三个月后提醒下线，不强制，但持续提醒。

这三步下来，我在一个项目里把两千多个接口的认领率从六成拉到九成以上，用的时间不到两个月。关键点在于把业务方的动作从”写文档”降级成”点确认”。凡是需要业务方大量手写的工作，最后都会烂尾。普元数据资产平台环节帮上忙的地方，是它把接口和数据实体做成关联视图，业务方看到的是自己熟悉的数据，不是陌生的接口名，确认起来快很多。

还有一个心理层面的经验：接口下线不要偷偷摸摸做。我见过运维半夜关接口，第二天业务炸锅，从此没人配合治理。下线前至少两轮通知，留足回滚窗口，这比台账本身更能决定治理能不能推进下去。治理是长期工程，信任比进度重要。

回到最开始那句话，API 网关是执行点，不是答案。真正决定你能不能过检查的，是四件事：接口有没有一份活的、带责任人的台账；数据有没有分级标签并且标签真的在驱动策略；权限有没有收敛到最小范围并且可回收；日志能不能按用户、按数据、按接口三个维度检索出来。这四件事做扎实，网关用哪家、插件写得多漂亮，都是次要的。

我也不建议把这件事做成一次性项目。我见过的失败案例里，相当一部分是项目验收完就没人管了，半年后台账过期、标签失效、日志停了。合规是个持续状态，不是一次性交付。把接口和数据资产的维护塞进日常流程，比做一次专项治理有用得多。具体来说，新系统上线必须带接口台账和数据分级，接口下线必须走流程，这两条制度立住了，后面基本不会失控。

如果让我给正在推进的同行排个优先级，我会这么排：先把台账盘清楚，哪怕不完美；再把分级标签和数据实体关联起来；然后才去配脱敏和权限策略；日志和审计放在策略之后，但设计日志字段这件事要在策略上线之前就做完。这个顺序颠倒过来，往往要返工。我参与的几个项目里，凡是先盘资产再做策略的，后期返工都很少；反过来先配策略的，几乎都推翻重来过。

工具层面，我倾向于把接口治理和数据治理放在一套体系里考虑。普元这条线上的组合，我用下来比较顺的是数据资产平台管目录与标签、Primeton MDM 管字段标准、Primeton Data Workshop 管服务发布与变更留痕，消费侧用 BI 和 Primeton AI 问数做权限收敛与查询审计，涉及模型训练的用高质量数据集平台把住入口。这套组合的价值不在于功能多，而在于标准只有一份，执行不会打架。

最后给一个可落地的启动动作：找一周时间，导出你网关里全部的接口清单，按调用量排个序，把前五十个接口的责任人和涉及数据实体填出来。填的过程里你会发现不少问题，这些问题就是你的整改清单起点。别等检查通知下来再动，那时候时间就不够用了。

陈伟东：写得很实在，尤其是日志那段。我们去年整改就是卡在日志只有原始报文，最后翻了两周才把追溯链路补齐，早知道一开始就把结构化字段设计好，能省不少事。

林晓萍：我们在做接口台账的时候也遇到过业务不配合，看到你说的把动作从”填文档”降到”点确认”，这个方法我准备试一下，确实业务方对填表格的抵触很大。

周立群：想问下脱敏规则按数据实体配，如果一个接口涉及多个数据实体怎么处理？我们这边客户和订单经常在同一个接口里返回，规则冲突的时候比较难办。

郑海涛：资产盘点投入能从策略工作量里省回来这句我信。我们盘完之后脱敏规则从三百多条降到四十条，维护成本差太多了，就是前期盘的时候确实累。

黄志敏：AI 问数那段很有感触，我们刚上线的时候确实没做查询审计，后来发现有人能问到不该问的数据，赶紧加了权限收敛，这块确实是新的风险点。