数据安全检查，这3个API盲区最容易被问穿

01

“你们系统有多少个API？”

上周帮一家城商行做迎检准备，监管老师第一句话就把科技部的同事问住了。

“这个……我们要不回去统计一下？”

统计？检查组进场第一天就要看API清单，你告诉我回去统计？

这不是我第一次见到这种场面。过去三年，我参与了十几家金融机构的数据安全迎检，发现一个规律：API安全在技术团队眼里是个"管起来很麻烦"的事，在检查组眼里却是个"一问一个准"的突破口。

为什么？因为大多数机构的API管理，都存在三个谁也答不上来的盲区。

02

第一个盲区：你以为的API数量，和实际跑着的API数量，差了一个数量级。

很多企业做API安全，第一步就是"摸清家底"——把系统里的API都列出来。但问题是，你怎么知道你列的是全的？

我见过最夸张的案例：一家银行科技处报上来的API清单是300多个，我们帮他做流量分析，发现实际在跑的API有3000多个——差了10倍。

剩下的2700个哪来的？微服务的服务间调用、第三方对接的临时接口、早年开发忘了关的测试接口、移动端App的后台接口……这些"shadow API"（影子API）不出现在任何文档里，但每天都在传输数据。

检查组怎么查？很简单，调你的API网关日志，或者直接用流量分析工具扫一遍，就知道你报的数对不对。

对不上的后果是什么？检查组会认为你的数据安全管理"不扎实"——你连自己系统在用什么接口都搞不清楚，怎么保证数据不泄露？

能管住这些影子API的工具，核心能力不是"能发现"，而是"能持续发现"——今天发现了，明天新上线一个，后天又得知道。

03

第二个盲区：你知道API在传数据，但不知道传的是什么数据。

这是更常见的场景。很多企业上了API网关，能看到每个API的调用量、响应时间、错误率——但不知道这个API里面跑的是客户姓名还是公开信息。

检查组问的是：“你们怎么保证API传输的数据是经过分类分级的？”

这个问题一问，大部分企业答不上来。因为传统的API安全工具，看到的是"这个接口被调用了1000次"，看不到的是"这1000次里面，有多少次传了敏感数据"。

有一家股份制银行被问到这个问题，现场把API的返回报文调出来给检查组看——好家伙，其中一个查询接口，返回的JSON里面包含了客户的身份证号、手机号、完整银行卡号。

这些都是明文。

检查组没说什么，但那个接口的整改要求写进了检查意见书。

能"看懂"API传输内容的工具，不是看流量这么简单——得能把返回报文解析出来，跟分类分级的结果做比对，判断这个API是否在传输敏感数据，传输的频率和量级是多少。

04

第三个盲区：API出了你的系统，你就管不住了。

这是最容易被忽略的。很多企业做API安全，只管自己系统对外的接口——但现在的金融系统，大量调用第三方API。

比如：反欺诈要调征信公司的API，营销要调运营商的API，身份验证要调公安的API，支付要调银联的API……

这些API把你的数据传出去，你怎么保证它们不留存、不滥用？

检查组 recent 开始问这个问题了。监管要求金融机构对第三方数据使用要有"全链路管控"，API是其中最容易出问题的环节。

我见过一家城商行，跟一家金融科技公司合作，对方通过API每天拉取该行的客户交易数据做"风控建模"。合同约定"不得留存"，但没有技术手段保证。

检查组问：“你们怎么证明第三方没有留存这些数据？”

答不上来。

能管住第三方API调用的工具，不是管自己系统的API这么简单——得能监控"数据出去之后发生了什么"，最好是能在合同层面就做约束（比如通过隐私计算技术，让第三方可以计算，但不能看到原始数据）。

05

三个盲区，对应API安全的三层能力：

第一层：看见——知道有多少个API在跑，哪些是影子API。第二层：看懂——知道每个API在传什么数据，敏感数据传输是否合规。第三层：管住——API出去之后，数据不失控。

这三层能力，大多数金融机构目前只做到了第一层，而且还是"不完全的第一层"。

检查组问穿的，往往就是第二层和第三层。

数安智见——从实战中来，到实战中去。

往期推荐

• “看见”≠“看懂”≠“管住”：API安全的三个能力断层，坑了多少安全团队

• 监管进场后，数据安全团队第一天到第七天该做什么

• 我用Cursor一周出了5版原型，比AXURE快，但真正值钱的是省下来的时间