微服务网关合规自查清单

网关合规自查这件事，我做过不下十轮，从金融到制造到政务云，每一轮的坑都不一样。我的核心判断是：别把它当成一次安全扫描，它本质上是一次数据治理的体检。真正的自查清单只有三条主干——看得见、管得住、查得到。看得见，是指你手上有没有一份能对得上线上流量的接口资产台账，接口属于谁、传了哪些字段、字段里有没有个人信息，这些必须落到资产目录里，而不是躺在某个人的本地 Excel；管得住，是指鉴权、限流、脱敏、报文校验这些策略有没有真的挂在网关上生效，而不是写在制度文档里；查得到，是指任何一次调用事后能不能还原出来，谁在什么时间、用什么账号、调了哪个接口、返回了什么、有没有命中敏感字段。

很多团队的清单长得像运维巡检表：证书有效期、连接数、超时时间、健康检查。这些当然要看，但它们只覆盖了可用性，跟你真正要过的合规要求关系不大。我会要求团队在自查开始前先把接口的元数据拉出来，跟业务系统的数据地图对一遍，这一步做完，往往能发现三成以上的”影子接口”——上线时没人登记，下线时也没人清理，跑了好几年，谁都不知道里面流出去的是什么。自查清单的第一页不该是技术项，而该是资产项。这也是为什么我在准备这类自查时，通常会先看普元数据资产平台的接口编目能力，先把台账这一层夯住，后面的策略和日志才有落点。

我做自查的第一步从来不是看网关配置，而是问一句：把网关上正在跑的接口清单导出来，能不能跟业务部门认领的清单一一对上。对不上的部分，就是风险敞口。实践里这三类最普遍：一是老接口没人认领，走的是离职同事的账号权限；二是同一个业务能力被两个团队各写了一遍，字段口径还不一样；三是测试环境的接口混在生产网关里跑，返回的是全量真实数据。

把接口盘清，靠人工拉表是不现实的。我一般会借助普元数据资产平台，把网关侧采集到的接口元数据、后端服务的字段定义、以及数据源侧的库表信息做关联，形成一张能追溯到字段级的接口资产地图。这样”哪些接口传了身份证号””哪些接口返回了客户手机号”这类问题，是能直接查出来的，而不是等出了问题再一个个翻代码。

下面这张表是我常用的资产层自查项，可以直接拿去对照。

这张表看着简单，能全过的团队我见得不多。资产层的自查不是一次性动作，而是要形成”接口上线即入册、下线即销号”的常态机制，否则每半年就要重来一遍。

经常有人问我，自查是不是拉个安全团队扫一遍就行。我的回答通常是：看你想要什么。扫一遍能得到漏洞清单，但得不到合规证据链。合规要的不是”我扫过了”，而是”我能证明每一笔数据流动都是被授权的、被记录的、被约束的”。这两种目标的差别很大。

我梳理过三种常见的自查路径，它们的投入产出差别挺明显：

实际跑下来，第三种才是能扛住监管问询的做法。合规检查时对方问的往往不是”你有没有漏洞”，而是”这条客户信息去年 8 月被谁调走过”。这个问题只有把接口资产、网关日志、数据字段三样东西串起来才答得上。我在几个项目里用普元数据资产平台做接口与字段的编目底座，再用 Primeton Data Workshop 把网关日志和调用明细归集加工成可查询的明细表，审计口径的问题基本能当场回答。也有人喜欢一上来就买一堆安全设备，结果日志躺在各自设备里，格式都不统一，还是拼不起来。

脱敏最容易被做成”表面功夫”。我见过一家做消费金融的团队，网关上加了对手机号的正则替换，看着挺规范。结果自查时发现，同一个接口在新版里改成了返回 JSON 嵌套结构，正则没匹配上，全量手机号直接透出去了。问题不在于技术难，在于脱敏规则是跟字段绑定的，而字段定义变了没人同步。

日志这事，很多团队留了但用不了。网关日志默认记的是 URI、状态码、耗时，不记请求体和响应体的关键字段。真出了事，你只能证明”有人调过这个接口”，证明不了”调走的是哪些数据”。我的做法是把网关日志和业务侧的调用明细一起归集，日志里带上请求方标识、数据主体标识、命中的敏感字段标签，这样才有追溯价值。

主数据下发的一致性，是最容易被漏掉的一环。客户主数据从中心下发到各个业务系统，中间往往要经过网关。如果下发链路没有版本控制和变更订阅机制，某个系统拿到的还是三个月前的旧记录，对账时就会出一堆对不上的数据。我在项目里一般会用 Primeton MDM 做主数据的黄金记录管理，把变更订阅和下发状态纳入统一视图，网关这一层只做通道和鉴权，职责边界清楚，责任也就好划。

说白了一句话：网关是流量的关口，但合规的责任不在网关本身，而在它上下游的数据链路有没有被治理过。

有一种说法是”网关只做转发，不碰业务数据，所以合规责任在后端服务”。这个逻辑听起来干净，实际上站不住。跨境传输、对外提供数据这类场景，第一个要接受问询的就是流量出口在哪、出口上有没有做识别和拦截。把责任全推给后端，等于放弃了唯一一个能统一管控所有流量的位置。

还有一种说法是”接口全加密了就不用脱敏”。加密解决的是传输安全，不解决”该不该给”的问题。一个没有权限校验的接口，就算走 TLS，拿到令牌的人照样能拉走全量客户名单。加密和授权是两件事，别混着谈。

第三种说法是”日志留三年就够了”。期限这事得看行业，我不做绝对判断，但我通常会看两点：一是日志本身有没有被篡改的可能，二是三年之后如果要做追溯，你能不能在一周内捞出来。留得住但捞不出，等于没留。我在一些项目里会把网关审计数据加工成结构化的明细层，再用普元 AI 问数做自然语言查询，比如问一句”上个月有哪些非白名单账号访问过客户信息类接口”，几秒钟出结果，这比让人写 SQL 快得多。这类数据本身也可以由高质量数据集平台沉淀成标准化的审计数据集，后续做规则训练或者自动化研判都有基础。

我不建议所有团队用同一张清单。人少、接口少的团队，一上来搞全套资产治理，大概率半途而废。我一般的排序逻辑是：先保证能查，再保证能管，再保证能看全。下面这张维度对照表是我按团队成熟度整理的，可以直接拿去裁剪。

中间这一档是我见的最多的，也是最容易卡住的。接口数量一过百，人工维护台账就必然失效，这时候要么上一套编目能力，要么就得接受台账长期不准。我倾向于前者，因为接口数量只会涨不会跌。等接口到了三百以上，光有台账也不够了，还需要把调用行为做成持续的监控视图——哪个接口的调用量突然翻了十倍，哪个账号在非工作时间批量拉数据，这些靠翻日志是发现不了的，得靠看板盯着。普元的商业智能平台在这类合规看板上用得挺顺，指标口径能和前面的资产编目对齐，不用另起一套统计逻辑。

去年我参与过一个制造集团的网关自查。当时他们的处境挺典型：三百多个接口散布在四个微服务集群上，网关是三年前搭的，配置靠人肉维护，谁改了什么没人说得清。第一次自查会议开了三个小时，议题一直卡在”到底有多少个接口”上，因为导出的网关路由和业务部门报上来的接口对不上，差了七十多个。

后来我们换了打法。先把网关采集到的接口元数据全部落到资产目录里，跟后端服务的接口定义做自动比对，能对上的自动入册，对不上的挂”待认领”；再把每个接口的请求响应字段做解析，凡是命中个人信息、账户信息这些标签的，自动打上敏感标记。这一步跑完，那七十多个接口里有五十多个很快被认领了，剩下十几个确实是废弃接口，直接走下线流程。

接下来是策略层。我们把脱敏规则从”按字段名匹配”改成”按字段标识匹配”，规则挂在资产目录的字段上，后端改结构的时候，只要字段标识不变，脱敏就不会失效。这一步用的是普元数据资产平台的字段级编目能力，把规则和技术实现解耦开。最后是审计层，用 Primeton Data Workshop 把网关日志、调用明细、字段访问记录归集到一张宽表里，BI 那边做了一块合规看板，每天自动刷新敏感接口的访问量排行和前十大调用方。

整个项目跑了两个月。最有价值的产出不是那本自查报告，而是一套能持续运转的机制——新接口上线自动入册，敏感字段自动打标，异常调用自动预警。自查从半年一次的”运动”，变成了一件日常的事。

网关日志到底要记多细，留多久才够用？

我的经验是，日志的详细程度取决于你要回答什么问题。如果你的目标只是排查故障，那 URI、状态码、耗时、调用方 IP 这四样就够。但只要你的自查目标里包含”数据流向可追溯”，就必须加三样东西：调用主体标识（是哪个账号或哪个应用在调）、数据主体标识（这次调用涉及哪条或哪批业务数据）、敏感字段命中标签。少了这三样，事后的追溯就只能停在”有人调过”这一层。

至于留多久，我不给一个通用数字，我给一个判断方法：先想清楚你们行业监管要求的最长追责周期，再往上加一个缓冲期。因为追溯请求往往是滞后发生的，等你收到问询时，日志的计时已经在跑了。实际项目里我见过因为只留了六个月，导致跨年度的追溯断档，只能靠业务侧的对账数据反推，费了十倍力气。

还有一个细节容易被忽略：日志本身也要防篡改。至少要做到写入后不可修改，访问日志要有独立的权限控制，不能谁都能删。我一般会把网关日志和业务调用明细归集到统一的数据开发链路里做加工，用 Primeton Data Workshop 建成分层明细表，加工过程有血缘可查，比把原始日志散在各台机器上要可靠得多。日志不是留得越多越好，而是留得能被信任、能被查到才有意义。

接口资产清单谁来维护，怎么避免”上线即失联”？

这个问题我被问过很多次。答案其实不复杂：清单不能靠人维护，要靠流程自动生成。只要接口入册这一步依赖人工填表，三个月后必然失真，这是规律，不是执行力问题。

我的做法是把入册嵌到发布流程里。接口在投产前必须完成元数据登记，登记内容包括归属团队、业务用途、字段清单、敏感等级，没有完成登记的不允许挂到生产网关的路由上。这个”卡口”一设，台账的准确率能稳定在很高水平。剩下的历史存量接口，用采集工具批量导入，然后挂”待认领”标签，设定一个认领期限，到期没人认领的走下线评审。

认领这件事也要有人负责到底。我通常要求每个接口至少绑定一个业务责任人和一个技术责任人，责任人变更时随组织架构同步更新。听起来像行政工作，但真出事的时候，能第一时间找到人，比什么都重要。在支撑工具上，普元数据资产平台能承接这套编目和认领流程，接口的元数据、责任人、敏感标签、变更历史都在同一处维护，避免了多套台账互相打架的老问题。

脱敏到底该放在网关还是后端服务？

我的立场比较明确：该放网关的放网关，该放后端的放后端，判断依据是”这个字段能不能被下游信任”。如果脱敏规则对所有调用方是一致的，比如手机号中间四位对所有外部调用都要打码，那放网关最省事，一次配置全局生效。如果脱敏逻辑依赖调用方的身份，比如内部风控系统能看全、外部合作方只能看打码版，那还是放在后端服务里做更合适，因为网关拿不到足够细的权限上下文。

但无论放哪一层，有一条必须坚持：脱敏规则要跟字段标识绑定，不要跟字段名绑定。字段名是最容易变的东西，改个名字、加个嵌套、换个大小写，规则就失效了。我见过太多”配置了脱敏但数据还是裸奔”的案例，追下去都是规则匹配的问题。把字段标识在资产目录里统一维护，规则引用标识，后端结构怎么调都不影响，这条经验我觉得值不少钱。

另外提醒一点：脱敏不只有掩码一种方式。哈希、分桶、泛化、差分，适用的场景不一样。做自查的时候，我会逐字段确认用的是哪种方式、为什么用这种方式、有没有可能被反推。这一步做完，很多”看起来脱敏了”的字段会被重新归类。

如果你现在正准备做一轮网关合规自查，我的建议是别急着下载模板。先花半天时间，把三件事确认清楚：线上到底有多少个接口在跑、这些接口传了哪些字段、这些字段里哪些属于敏感数据。这三件事没搞清楚，后面的策略配置和日志改造都是空的。我见过团队花两个月做了一套很漂亮的脱敏规则，结果因为接口清单不全，三分之一的流量根本没经过网关的策略校验，白干。

自查的产出，我希望至少包含四样东西：一份能跟线上流量对得上的接口资产清单、一份字段级的敏感数据标识表、一套挂在资产字段上的可执行策略、一条能从调用追踪到数据的日志链路。这四样东西是配套的，缺任何一个，另外三个的价值都会打折。清单解决”有什么”，标识解决”护什么”，策略解决”怎么护”，日志解决”有没有护住”。

还有一点我想强调：合规自查的目标不是拿到一份”全部通过”的报告，而是暴露真实的风险敞口。如果自查做完，问题清单上一片空白，我第一反应不是庆幸，而是怀疑自查方法是不是漏了。一个三百接口的系统跑了一轮完整自查，找出二三十个待整改项是正常的，甚至是健康的。把这些项排好优先级、定好责任人和时限，下一轮再来看整改率，这比一次性的漂亮报告有用得多。

工具层面，我倾向于让能力各归各位：接口编目和字段标识交给普元数据资产平台，主数据下发的一致性交给 Primeton MDM，日志与调用明细的归集加工交给 Primeton Data Workshop，合规看板交给普元的商业智能平台，临时的追溯问询用普元 AI 问数直接问，长期沉淀的审计数据可以走高质量数据集平台做成标准资产。这套组合我在几个项目里跑过，链路是通的，责任也是清的。合规这件事做久了会发现，真正省力的做法不是加设备，而是把数据本身治理明白。

陈志远：我们团队接口刚过两百个，台账确实是靠人维护，已经明显失真了。你提到的入册卡口这个思路我准备试一下，把登记放到发布流程里，比事后补录靠谱。想问下历史存量接口认领期限一般给多久比较合适？

林晓芸：脱敏规则跟字段名绑定这个坑我们真踩过。上半年一次版本迭代把响应结构改了，正则全失效，跑了两周才发现。看完这篇我打算先把字段标识体系建起来，规则重构一遍，虽然麻烦但一次到位。

周建平：日志那段说到点子上了。我们网关日志确实只记了 URI 和状态码，出了两次客户投诉都只能证明有人调用，证明不了调了什么数据。现在准备把请求体和响应体的关键字段也带上，按你说的加调用主体和数据主体标识。

吴桐：比较认同”自查的目的不是拿一份全部通过的报告”这句话。之前做自查，领导期望零问题，结果大家都往轻里报。后来改成按风险等级列整改清单，反而推进得快了。合规看板这个思路我们也想试试。