随着金融业务全面线上化、开放化，API已成为金融行业数据流转、业务交互和开放生态的核心通道，也是监管关注的重点领域。近年来，人行3号令《业务领域数据安全管理办法》、金办发〔2025〕93号文专项行动、JR/T 0185《商业银行应用程序接口安全管理规范》等文件相继出台，对API安全提出了明确要求。与此同时，API安全威胁持续升级：影子API、僵尸API难以发现，传统WAF和API网关防护不足，AI时代攻击面进一步扩大，敏感数据通过API泄露的场景层出不穷。
近日，合规社举办金融行业API安全对谈直播活动，本期聚焦金融行业API安全，邀请上海翰纬信息科技有限公司数据安全咨询服务负责人张兵与瑞数信息技术（上海）有限公司技术总监吴剑刚展开深度对谈。本次直播吸引近200位行业同仁在线参与，在一个多小时的交流中，两位嘉宾围绕金融行业最关心的18个实战问题，逐一拆解，为在线观众带来了一场兼具深度与可操作性的实战分享。
Q1
API的基本工作原理是什么？
：谈到API，即应用程序接口，它的基本工作原理是什么？请吴老师介绍一下。
：API是应用程序接口的英文缩写。互联网交互中，各方遵循同一套规则和标准。请求方发出请求，服务方返回结果，双方基于约定的协议、参数和报文格式交互。业界常说“万物皆可API”，出行、外卖、下单等基本都调用API，由客户端发起。目前应用最广的是基于HTTP协议的Open API。
金融行业对API安全要求更严，除HTTPS网络层保护外，很多API还会对报文做应用层加密，返回格式以JSON为主。
可以理解为“契约先行”：服务对外开放前，先定义接口、请求格式和内容；请求方按格式和参数发起请求；服务方按请求内容返回结果。AI时代，智能体、移动办公App、小程序等访问，基本都调用API。
：吴总讲的技术性比较强。很多人并非专业研究API，能否更简洁地说明？比如A系统指定一个端口，比如200号端口，通过该端口发送数据；B系统连接200端口，按约定协议传输数据，是这样吗？
：更准确地说，不是端口号，而是接口地址，通常是一串URL加参数。API接口对外开放时，首先要鉴权，访问端需要权限。公开API可能不需要鉴权，金融行业一般都需要。B要访问A，先拿到A的授权和权限，再按A提供的接口地址、参数和报文格式发起请求。例如提交用户名、口令、查询或转账金额等。请求匹配，A返回结果；参数或格式不对，请求失败。
从架构上看，API简化了交互。过去交互多通过网页URL连接，API更简洁，不必从网页首页入口进入，只要有接口和权限，就可以直接访问，因此也会绕过很多限制。
Q2
金融行业API安全威胁有哪些主要特点和发展趋势？
：在金融行业，API安全威胁有哪些主要特点和发展趋势？
：从数据看，目前整个互联网攻击中，API攻击已占超过七成。针对Web应用或互联网的攻击，大量都指向API接口。
金融行业API的特点主要体现在两方面：一是大量数据交互通过API完成，核心风险是数据泄露；二是很多API承载交易，如转账，因此同时涉及数据和业务风险。数据和业务，是金融API最核心的两个点。
在这一背景下，金融行业API威胁主要有以下特点：
第一，攻击面大。外部应用攻击中，API接口已占七成。尤其2024年、2025年金融行业发布相关规范，要求金融企业排查API接口，防止未鉴权访问或越权访问。未鉴权可导致参数遍历或用户信息遍历，造成大量数据泄露，风险很高。
第二，攻击智能化和自动化。AI应用、大模型、智能体在各行业普及，攻击者大量利用AI辅助工具，包括自动化渗透、路径猜测、编码猜测等。通过AI进行接口猜测、路径探测、攻击报文重构，攻击变得更加严峻。
第三，业务逻辑攻击增多。OWASP API Security Top 10 2023中，几乎没有传统安全攻击，传统认知中的SQL注入并不在其中，主要都是业务攻击。金融机构开放API通常有明确业务目的，要么提供数据查询，要么提供交易，因此针对API的攻击多为业务攻击，如越权访问、调用顺序绕过等。金融行业有核心交易和核心业务，影响更大。
第四，影子API风险凸显。整个API攻击中，约30%的影响来自影子API。影子API是指在API流量中看不到的接口。例如老版本接口未下线，长期无人调用，逐渐变成影子接口。这类接口往往鉴权机制薄弱，容易被攻击。
第五，数据定向窃取。很多API攻击潜伏超过一个月，批量窃取数据。当前互联网上大量数据泄露行为由API接口导致，API已成为数据泄露主要途径。金融行业有核心业务和数据，数据安全尤为重要。
最后，攻击链隐蔽化。有了智能体之后，攻击者可模仿真实用户行为，降低访问速率，调整IP地址，隐藏身份特征和客户端特征，模拟真人操作。此时，传统特征匹配和特征识别在识别AI驱动攻击时变得非常困难。相关测试表明，当身份全部隐藏后，传统特征识别技术是否仍然有效，面临很大挑战。
从趋势看，API安全威胁正逐步走向智能化和自动化。AI技术会简化攻击流程，大幅降低攻击成本，同时提升攻击隐蔽性。
Q3
“看不见的API”为什么是最大的安全风险？
：我们在帮助金融机构做API管理时，用工具扫描，通常会发现大量API，可能几万个，甚至10万个以上。直觉上，其中很多API已经下线，不再支持业务。这里提到“看不见的API是最大的安全风险”，请吴总解释一下，这里说的“看不见的API”指什么？
：“看不见的API”主要指未知API接口，也包括影子API。影子API在老版本中可能还能看到，但这里更多指未知和影子两种。
未知API，是指大家根本不知道其存在。例如使用了某个开源组件，组件自身带有一个API接口，但大家根本不知道。这是最可怕的，因为压根不知道这个接口存在。另一种情况，是API接口一直没有流量，通过流量监测根本看不到。
为什么说看不见的API风险最大？因为安全管理和资产管理最基础的前提是摸清家底。金融机构到底有1万个还是10万个API，资产必须清楚。所以资产管理的前提，是先摸清家底。
为什么会产生这么多看不见的API？很多金融机构排查API资产时，通常采取发文、制表、要求各部门填报的方式。但信息化环境动态变化，业务持续演进。表格下发到填报完成期间，接口可能已经发生变化。API数量呈爆炸式增长，业务变化过程中不断产生新接口。以支付接口为例，早期可能只有银联，后来出现微信、支付宝，以及字节、抖音等渠道，接口随业务变化不断演进。业务爆发直接导致API接口爆发。
为什么影子API或未知API很难识别？由于其在流量中没有请求记录，通过流量镜像方式识别非常困难。传统安全技术如WAF，依靠规则和特征匹配防护API威胁，但API威胁主要是业务层面安全风险，如未鉴权、越权，并非WAF的主要防护目标。WAF主要防护的仍是SQL注入、跨站脚本等安全攻击。
固定安全扫描器或扫描工具也难以扫描API。API是开放接口、约定参数和报文格式，供请求方调用。通用扫描器不知道API的报文格式和请求参数，无法构造请求报文，也就无法扫出未知接口。API不同于网页，无法通过爬虫方式爬取。只要请求报文参数格式或授权信息不正确，就无法访问，请求必然失败。这就导致未知API和影子API非常难被识别。
开展风险评估和风险识别时，如果根本不知道资产存在，就无法判断其风险。未知API接口是最大的安全风险。从整体安全风险看，其占整个API风险超过30%。
Q4
传统WAF、API网关为什么不足以应对API安全挑战？
：根据总局《银行保险机构数据安全管理办法》要求，要把API统一管理起来，很多金融机构选择用API网关实现统一管理。作为安全防护，API网关和WAF为什么不足以应对API安全挑战？
：每个产品、每个安全设备都有自己的定位。WAF和API网关的定位，并不是用于API安全防护。
WAF基于规则和特征匹配识别Web攻击，主要防外部应用攻击，如SQL注入、跨站脚本。对业务逻辑风险，并不是它要解决的核心问题。因此，WAF无法应对OWASP API Security Top 10里的安全风险。
API网关更多是鉴权认证和API资产管理，并不以安全为核心。业务中台、数据中台里通常都有API网关功能。它关注的是接口鉴权模式、请求方式，不关注安全情况。API网关是业务组件，不是安全组件，对业务逻辑和数据侧防护能力不足。
API网关有资产管理能力，但只覆盖已注册的已知API。未在网关注册的未知API，网关无法发现。OWASP Top 10里的未鉴权访问、参数遍历、调用顺序篡改，以及敏感数据识别管控、全量审计、异常行为分析，都不是WAF和API网关的定位。《网络安全法》要求互联网访问至少保存6个月，API暴露在互联网时也属于互联网访问，全程全量审计同样不是WAF和API网关能承担的。
因此，每个产品有独立定位，应该用适合的产品解决适合的问题，不能靠一个产品解决全部安全问题。
：总局办法里专门提到，对数据外联通过统一管理的外联平台或应用程序接口来管理。API网关在安全方面没有特别强的作用，但作为统一管理，如果金融机构的API都在API网关上注册，它是不是能够实现统一管理职能？
：可以。如果能把整个金融机构的互联网出口或API接口收敛得很好，在网关上统一做策略管理和权限管理，是很好的办法。
：从满足总局监管要求看，API网关仍能起到明显作用。
Q5
AI时代，API安全面临哪些新挑战？
：在AI时代，API安全面临哪些新挑战？
：从AI时代来看，API安全主要面临以下几方面新挑战：
第一，新型接口涌现。大模型火起来之后，API接口访问量暴增300%。所有大模型、AI相关组件都以接口模式开放。例如智能体调用大模型算力，大模型会开放接口；智能体也开放接口做MCP，MCP同样通过接口实现。以前接口更多集中在业务层面，现在除业务接口外，大模型、智能体、MCP组件都产生大量接口资产，API资产管理范围明显扩大。
第二，攻击者更加AI化。过去编写攻击脚本需要人工写代码，门槛较高。现在通过AI coding模式，与智能体、AI交互平台或代码平台互动，只需用自然语言提出需求，就能快速生成攻击工具和脚本。攻击者使用AI技术后，攻击门槛大幅下降。以前需要一定代码基础才能发起攻击，现在只要能跟大模型用自然语言交互，就可以编写攻击脚本。攻击速率和效率倍增。今年刚结束的国家级护网中，我们公司亲身经历的最快AI攻击，是23分钟打穿靶标系统。攻击者通过AI自动化程序，23分钟完成整个攻击。
第三，提示词注入攻击风险更受关注。提示词注入攻击是大模型安全Top 10中排名第一的风险。
第四，API Key泄露风险更加严峻。智能体、大模型交互中会分配API Key，给相关智能体或人员使用。这个Key一旦被盗用或窃取，就会造成严重问题。之前OPC特别火时，就有一家公司、一个人，一晚上被刷了50万出去，因为API Key暴露，别人调用他的接口刷算力，一晚上50万就没有了。
第五，智能体调用链风险。金融行业智能体调用仍然非常谨慎。AI时代，API接口和智能体在使用过程中，需要更好地管理和控制，尤其权限问题、访问问题、未知风险，是各方非常关注的点。
从防守方来看，AI赋能也是一个机会。此前资产梳理、资产排查主要靠流量镜像，现在可以引入AI技术。异常行为、攻击研判方面，API一旦上线后报警特别多，处理非常困难，可以通过AI技术做降噪、行为分析、研判，包括路径推理和还原。
AI时代对API安全有正面和反面两方面。反面是攻击严峻性上升、接口暴露和资产暴露面更广；正面是很多API安全运营和运维工作可以通过AI赋能，提升效率，降低成本。
Q6
人行3号令《中国人民银行业务领域数据安全管理办法》对API安全提出了哪些核心要求？
：2025年，人行发布了《中国人民银行业务领域数据安全管理办法》，对API安全提出了哪些核心要求？
：人行3号令针对业务领域数据，核心要求主要有以下几方面：
数据分类分级。数据分为一般、重要、核心三个维度。金融行业做数据安全，首先要完成数据分类分级。
全流程安全管控。覆盖采集、传输、存储、提供、公开、销毁全生命周期。API接口同样如此，从产生、开放到传输、存储、提供、公开、销毁，全过程都要纳入管理。
数据资源目录。API应纳入数据资产目录。办法要求至少每年更新一次。这个频度偏低。API变化很快，实际需要在线系统支撑，至少每周或更短周期更新，否则台账很快失效。
责任划分。谁管业务，谁管数据。API属于哪个业务，就由哪个业务部门负责，承担主体责任。
风险监督处置和安全审计。API访问日志必须全量记录，作为核心溯源依据。
：这些要求落到API上，具体怎么落地？
：API纳入数据资产目录，并做分类分级标识。核心数据API加密传输、访问控制、脱敏展示。这是基本要求。很多金融机构在HTTPS之外，还会对报文做应用层加密。但加密是一把双刃剑：满足合规的同时，传统流量镜像分析可能失效，加密后数据不可见，本身也带来新的风险。另外，建立API数据安全审计机制，敏感访问可溯源。所有访问要有全链路记录，能够回答谁访问了敏感数据、什么时间、做了什么，即5W1H。
：API纳入数据资源目录时，目录里记什么？只记API链接，还是也记API传输的数据？
：不能只记URL。要记录接口及全部请求参数、报文格式和样例。这是数据资源目录最起码的要求，否则无法形成完整的数据资源目录。
Q7
金办发〔2025〕93号文专项行动，API安全对应哪些检查重点？
：金办发〔2025〕93号文与总局数据安全管理办法内容趋同。在93号文专项行动中，API安全对应哪些检查重点？
：金办发〔2025〕93号文要求金融机构先自查、再整改。自查路径是：建台账、定基线、做监测、做整改、做修复，形成闭环。目前阶段，监管现场排查重点是整改情况和资产管理情况。对金融行业而言，93号文是专项行动的行动指南，需要在规定时间内按规范完成。
93号文从六大维度切入，包括数据安全治理、数据分类分级、数据安全管理、数据安全技术保护、个人信息保护、出境数据保护、数据安全风险监测处置。
第一，接口资产识别。要明确API数量、用途、类型和数据级别。台账不能只记接口路径，还要有请求报文样例。例如转账接口可能涉及用户名、口令、转账金额、交易账号、对方账号等敏感数据，其定级必须与数据分类分级一致。
第二，访问控制与鉴权。遵循最小权限原则。用户A登录后，只能访问用户A自己的数据和被授权功能，不能访问用户B的数据。例如，账号只有查询权限，就只能查询，不能发起交易。重点关注未鉴权、弱鉴权和越权访问。越权访问最危险：如果用户A能访问用户B的数据，对金融行业是致命问题。未鉴权是指系统没有有效验证访问者身份，或登录凭证过期、失效后仍允许访问。弱鉴权是指认证机制过于简单，容易被绕过或破解。例如用户登录后，过一段时间无需再次登录，凭Cookie即可访问，如果此时凭证已经失效但仍能访问，就属于未鉴权或鉴权失效。
第三，敏感数据保护。敏感数据要加密传输、脱敏展示、防数据泄露，并防批量泄露。相关安全防护技术要配套。
第四，日志审计与监测。访问日志要完整留存，并在此基础上发现异常行为。可引入UEBA用户行为分析。比如某金融客户账号在凌晨期间被越南、老挝、香港等境外IP不断登录，操控上百个账号交易，这就是典型异常行为。
第五，第三方接口管理。第三方接口要审批、监测，并有退出机制。既包括机构调用第三方接口，也包括第三方调用机构接口。
Q8
JR/T 0185《商业银行应用程序接口安全管理规范》核心要求是什么？
：金融标准方面有两个文件：一个是《商业银行应用程序接口安全管理规范》，另一个是《商业银行应用程序接口安全管理检测规范》。第一个是管理规范，专门针对API接口管理。请吴总介绍其核心要求。
：该规范由人行发布，配套管理规范和检查规范，专门针对商业银行应用程序接口。核心要求主要有以下几方面：
一、接口分级管理。商业银行API按公开、授权、凭证进行分级管理，覆盖设计、开发、测试、部署、运维五个阶段。规范所指接口不限于互联网开放接口，也包括金融机构之间的调用接口和内部数据交互接口。
二、双向身份认证。A和B要互相认证，不能只做单向认证。
三、报文安全。使用国密算法加密，并具备完整性校验、时间戳和防篡改校验。规范出台后，很多银行做接口应用改造，需要支持国密算法。
四、流量控制。按接口分类差异化限流。核心接口、敏感数据接口、非公开非敏感接口，要区别控制。
五、日志留存。规范要求至少6个月。金融交易、保险交易等留存时间可能更长，需按行业要求执行。
六、统一标识码。每个API接口必须有唯一标识，不能用一个接口承载大量不同业务。
七、全生命周期管理。从设计、开发、测试、部署到运维，全过程纳入管理。
规范真正落地，也有几方面难点：存量接口梳理分类工作量大。银行早期接口不一定是Open API模式，也包括C/S架构接口，存量复杂。历史接口改造难，优先级难排序。所有接口支持国密算法，需要应用改造。180天留存要求带来存储成本。
Q9
《商业银行应用程序接口安全管理检测规范》要检测什么、怎么检测？
：怎么根据检测规范来进行检测？
：管理规范和检测规范是配套的，一个管理，一个检查。检测覆盖接口全生命周期四个维度：
部署安全检测。检查部署环境、身份认证、加密传输、访问控制是否落实。
安全集成检测。检查集成过程中的风险，第三方接口上线前是否做过安全评估。
安全运维。检查日志留存、漏洞管理、变更管理、应急响应是否有记录。
检查和审计有区别，检查偏上线前合规性审计，审计偏运行中的实践要求。基本要求是不通过检测不投产，API上线前必须做安全检测。可引入自动化工具，实现问题分级闭环，提高检测效率。
Q10
国标GB/T 46796《数据安全技术 数据接口安全风险监测方法》核心要求是什么？
：国标《数据安全技术 数据接口安全风险监测方法》是2025年发布的，它与金融行业接口安全管理如何结合？核心要求有哪些？
：该标准是首个数据接口安全国家标准，发布时间晚于商业银行接口安全管理规范，但为API接口方案设计和选型提供了对标基准。它提出八大监测要素：资产、身份、调用、数据、行为、异常、风险、处置。API接口设计时，就要考虑这些要素。
标准里提出了三种监测方式，分别是流量解析、日志解析和主动探测。这几种方式各有侧重，最好结合起来用。目前流量解析用得比较多，日志解析也有客户在用，主动探测相对少一些。三种方式结合，有助于发现未知接口。
监测流程覆盖监测准备、数据采集、分析研判、处置，形成从准备到响应的闭环。
标准列出了脆弱性、未授权访问或披露、异常调用、异常提供四类风险源，并给出了建设框架，可用于自建或选型对标。
Q11
如何识别影子API/僵尸API？
：前面提到，影子API和僵尸API识别出来非常难。从吴总的经验来看，如何准确识别这些影子API和僵尸API？
：识别影子API和僵尸API，建议采用三管齐下：以流量为主，文档为基础，主动扫描为辅，并引入AI技术。
流量为主。通过流量镜像做基础识别。国标也提出三种方式结合，流量镜像必不可少。
文档为基础。通过Swagger文件或开发规范获取API资产，进行核对。
主动扫描为辅。盲扫基本不可行，必须先将流量学习或文档提供的API导入扫描器，由扫描器构造请求和响应报文、参数，并可利用AI技术发现未知接口。通过报文重构，扫描器可以穷举V1、V2、V3，发现流量中看不到的老版本接口。这是扫描器与审计的重要区别。
AI智能推理。通过AI推理接口名称和功能，让未知接口显形。
大模型接口覆盖。除传统业务接口外，还要将大模型相关接口纳入资产管理范围。
定期盘点。API资产管理是循环过程，不是一次性工程。业务变化、接口增长、开发人员绕过流程私自开放接口，都会产生新接口。只有持续盘点，才能发现未知接口和影子接口。
：按这些方法，能够比较准确、完整地盘点API资产吗？
：是的。实践中，这种思路比传统单一维度更准确。
Q12
API监控告警的处理和降噪？
：我们之前了解一些网络安全产品，包括DLP，都会有很多误报，通过一些方法做降噪。API监控是不是也有同样的情况？
：确实存在。金融机构拥有数万甚至十万级API接口并不罕见，接口数量一多，告警量就会很大。一个人一天能处理的告警数量有限，告警过多就无人处理，系统最终沦为摆设。告警量过大，安全团队也难以判断。
API降噪很重要。我们更推荐API闭环运营：从发现风险、产生告警，到验证、治理，形成闭环。只有各环节都运转起来，API运营才能真正落地。
降噪首先面对几个问题。一是告警量过大，处理人力不足，很多告警被搁置。二是误报率高。安全团队反复告知业务存在未鉴权漏洞，业务验证后却发现漏洞并不存在。业务配合一次、两次、三次，不会持续配合。误报率过高，业务部门就不再配合。三是告警缺乏上下文和语义理解，仅基于单请求报文产生告警。传统时代受语义和环境限制，现在AI时代可以改变。没有语义理解直接报警，效果有限。四是告警与处置环节脱节，缺乏处置流程。API运营需要发现、验证、处置形成治理闭环，只有循环处置，降噪才能真正做好。
降噪可从几个方面入手。
第一，AI研判。将API告警送入内部智能体，不对外公网暴露。内部调用算力和智能体，例如日志分析智能体，判断告警是否真实存在。第二，建立行为基线。很多客户设置固定阈值，例如一分钟50次算高频告警，这是非AI时代的做法。AI时代可以采用动态基线，基于流量学习自动生成基线或阈值，不必依赖固定阈值。第三，风险分类分级与聚合去重。对风险分级，人力不足时优先处理高风险事件，低风险暂缓。同一告警重复100次没有意义，应聚合为一条并说明发生次数。第四，尝试本体模型降噪。本体模型类似知识图谱，建立业务语义与接口的关联要素，构建领域本体模型。接口与元数据做语义映射，再通过推理识别降噪。实践中，部分金融客户通过本体模型降噪70%—80%。AI也可用于降噪，通过大量智能体和Skill实现，但对人员要求较高，业务变化也会产生影响，可以考虑用大模型尝试。
最后，告警要能到管控。告警应能触发拦截、限速、定向处置。不能只发现风险，然后完全依赖人为处置，需要自动化手段做拦截或限制。例如，突然发现API接口敏感数据泄露事件，如果还要走流程、靠人判断后再拦截，数据已经泄露，为时已晚。实时拦截或固定拦截机制仍然必要。
运营需要闭环。建议从发现到验证再到治理形成闭环，发现、分析验证、处置各环节都要有验证。
Q13
API接口开发是否满足开发规范？
：如何判断API接口开发是否满足开发规范？这里说的开发规范就是前面介绍的金标。满足开发规范要求，正是安全左移的体现，也就是在开发设计阶段就把安全要求纳入进来。请吴总谈谈。
：金融机构普遍都有API接口开发规范，甚至可能有多份，但规范有没有落地、开发人员是否按规范开发，实际上缺乏检测手段。今天讨论的是，如何建立API接口开发规范的检查机制，判断接口开发是否满足规范。
AI技术之后，这件事相对容易。为什么要做？
第一，开发人员水平不一致，对规范、对安全规范的理解也不一致，理解不一致，开发结果自然不一致。
第二，规范文档不断更新，或者更新不及时，开发安全存在信息差。
第三，人工代码审计非常困难，尤其API接口人工代码审计效率低、复杂度高。
第四，参数命名不规范、错误状态码不一致等问题普遍存在。
解决思路是AI赋能。
通过AI技术对接口参数进行自学习。一个有10万个API接口的机构，很难提供每个接口的请求参数和报文格式，让开发人员提供也不现实，因为每个业务由不同人员开发。所以通过AI技术实现API接口参数自学习，把接口请求参数全部学习出来，建立参数类型、范围、必填基线。基线建立后，再将开发规范通过AI映射为检查内容，两边比对，判断接口开发是否按照开发文档执行。
参数合规检测用于判断开发参数与学习到的参数是否一致。这一环节可以嵌入CI/CD自动化流程。退回报文检测可检查是否包含大量敏感数据、是否存在过度数据暴露。鉴权和加密检测也可纳入其中。
我们建议，API开发合规应将开发规范映射为技术可落地的检查内容，再通过AI技术对API参数或内容进行自学习，学习完成后两边比对，判断是否按规范开发。靠人执行非常复杂，10万个接口、10万个参数一一比对不现实。
：这个方法比较科学。我也确实看到很多金融机构在开发环节并不那么规范，远不像你说的这样用这种方法规范起来。从你的经验来看，金融机构在开发环节的实际状态如何？
：我接触的一些大型金融机构，两年前特意立了API接口开发规范梳理和检查的项目，说明他们已经非常重视API接口开发规范。
不可能要求每个项目团队开发能力一致、对规范理解一致。所以规范由合规部门或安全部门解读，解读后给到开发，提供一个开发人员能读懂、可直接执行的规范。不能让开发人员独立理解接口安全管理规范或检查规范，10个项目组可能理解出10种不同做法。安全部门、合规部门解读后形成统一结果，全行按此执行。这个结果可以引入专业咨询机构做咨询认证。
把可解读的开发规范给到开发人员，是第一个维度，很重要。接下来，开发人员按文档开发后，是否真正落实，仍需检测。检测手段非常关键。我接触的很多客户以代码审计为核心来做，这种方式可行，但效率低、对人要求高。两三年前AI能力有限，到现在，通过AI技术落地会更加有效。
Q14
如何识别“看起来合法、实则违反业务逻辑”的API操作？
：如何识别“请求本身合法、但实际违反业务逻辑”的API操作？请吴总讲讲。
：金融行业交易有交易顺序，业务操作也有业务逻辑和操作顺序。所谓看起来合法，比如业务交易分为A、B、C三个步骤，攻击者只做了A和C，绕过中间步骤，这就违反了业务逻辑。
以银行开卡为例，一类卡、二类卡互联网开卡模式可能有1、2、3三个步骤，需要登录、身份识别、人脸识别、证件识别等。攻击者绕过中间两个步骤，直接到最后一步。它不是人工绕过，而是通过工具直接对接口发送相应参数，绕过接口校验。这就是绕过业务逻辑的操作。
这类操作带来的问题主要有四类：
第一，合法身份。攻击者身份合法，但不按正常顺序访问，绕过了安全检测。
第二，跳过中间步骤。直接调用结果接口，修改参数绕过金额校验，或者反复重试绕过次数限制。
第三，单个请求合法。每一步请求看起来都正常，规则检测很难识别。
第四，金融场景下，可能直接导致资金损失或数据泄露。
解决思路与AI相关。让金融机构梳理API接口调用顺序，问10个，基本10个都回答不了。安全部门梳理不可行，因为不了解业务；业务部门梳理也很难，因为A业务、B业务、C业务涉及多人，协调难度大。
因此，需要引入AI手段理解接口调用顺序，实现调用顺序自学习。学习完成后做业务逻辑建模，自动建立金融交易等业务的调用顺序。在此基础上做参数关联和检测，校验金额、数量等一致性；同时设置频率和数据限制，识别异常行为，最终实现全链路溯源和实时处置。
实践中，很多客户对业务逻辑梳理非常困惑，尤其调用顺序。这类似前面谈的本体模型，需要理解业务语义，再识别调用顺序。通过AI技术会好很多。相当于先把核心业务，至少核心业务的接口调用顺序全部理解清楚，只要违反调用顺序，就视为异常业务操作。这是我们的核心思路。
Q15
敏感数据通过API泄露的常见场景有哪些？
：回到敏感数据。通过API泄露，都有哪些常见场景？
：敏感数据通过API泄露，常见的有几种情况。
一种是接口返回字段过度暴露。一个查询接口本来只想查询家庭住址，但除了住址之外，身份证、手机号、银行卡等信息也一并返回。开发人员为了方便，往往只要请求接口，就把全部信息返回，由调用方自己查看，这就造成过度数据暴露。
另一种是明文传输、中间劫持。在金融行业核心交易中已经很少，明文传输基本不多见。未鉴权访问和越权访问也很常见，金融行业未鉴权问题尤其多。未鉴权漏洞属于开发代码层面的业务逻辑漏洞，不是业务安全问题，但造成的问题非常多。
日志完整记录请求响应也会导致数据泄露。很多用户端展示要求脱敏，相关人员不能看到完整日志和响应报文，管理员也要经过权限控制才能查看。一旦发生二次泄露，安全管理人员能看到所有人的交易记录或完整报文，本身就成为另一个泄露源，因此对管理人员也要做控制。
第三方接口缺乏管控同样会造成泄露。比如开源组件接口，未知接口根本不知道，也就无法管控。它可能通过未知接口漏洞，把整个系统核心数据全部拿到。
防护上，首先要做敏感数据识别。通过数据分类分级方法识别敏感数据，建立行业的数据识别规范。
其次，核心数据加密传输。除HTTPS网络层协议外，还用国密算法做应用层加密。这样再做越权、未鉴权就很困难。
另外要限制批量调用。敏感数据、敏感接口的高频访问必须限制。曾有金融客户一天通过接口泄露50万用户数据。攻击者访问这么多敏感数据，必须控制。动态基线很重要，因为每个接口一天访问多少次算正常，并不容易判断。接口开放给大电商调用，和开放给小商户，访问量完全不一样，一刀切限制并不合理，需要引入动态基线。
最后还要做数据出境监测。境外数据访问、数据外传，要识别违规外发和异常流量。
Q16
API安全运营的整体治理方案是什么？
：API安全运营的整体治理方案是什么？
：从实践看，客户比较认可这一方案。整体上从事前、事中、事后三个维度展开。
事中实时防护很关键。前面举例，一个金融客户一天泄露50万用户数据。发现问题时，如果早点防护，就不会泄露50万用户数据。为什么让它一直泄露之后，再通过审计才发现？事后审计只有审计是不够的。事后发现泄露50万用户数据时，数据泄露已经造成，还能做什么？这是最大的问题，因此事中实时防护非常关键。
事后是API审计。我们认为API整个安全管理、安全治理的闭环，必须从事前、事中、事后三个维度入手，只做事后不够。事前安全左移肯定要做，事中防护非常重要，要通过事中实时阻断未知风险和数据泄露行为。
Q17
如何做好API安全资产盘点？
：API安全资产盘点是最基础的工作。对资产盘点，吴老师有什么好的建议？
：资产盘点建议采用主被动结合的方式：通过被动流量识别，再通过主动扫描发现资产，先覆盖核心业务，再向边缘扩展。每个API资产要责任到人。
同时要建立数据资产目录。国标提到数据资产，API资产也应纳入其中。这是API资产管理的方法论，可以理解为全生命周期闭环。
开发阶段，要建立Swagger文件、开发手册和开发规范。很多客户开发时，Swagger文件或开发文件建立得不够好，会影响后续资产台账梳理。开发阶段必须建立资产台账，内容包括路径、名称、业务类型、分类、协议、方法、数据类型、依赖关系、鉴权信息等。资产台账不能只记录一个接口路径，那不够。只给一张静态表格，表格不会变化，也没有意义。
测试阶段，上线前通过扫描方式做被动资产导入。资产台账建立后，导入扫描器。扫描需要输入，有输入才能做资产扫描。扫描可以发现所有已导入的已知接口，再基于已知接口构造请求参数和报文格式，发现未知接口和僵尸接口，并梳理和完善资产暴露面路径。
扫描完成后做缺陷扫描，也就是漏洞扫描。构造攻击报文，比如参数篡改，把参数V1改成V2，做越权、未鉴权等测试。现在可以通过AI技术构造请求参数，效率更高。之后做敏感信息探测，根据敏感路径、敏感文件返回内容判断是否敏感，作为数据分类分级的依据。
上线后进入运营监测阶段。做流量镜像，基于流量做资产被动识别，识别路径关键字、参数关键字、响应类型等，然后做风险监测，覆盖OWASP API Security Top 10、Web攻击、API攻击和业务攻击，做业务风险建模。之后进入迭代或发布，再走整个流程。
责任非常重要。很多客户做API资产梳理时没有责任到人。这个接口归属哪个部门、哪个人负责？《数据安全法》明确，业务是谁的，数据管理就是谁的，数据责任就是谁的。API接口也一样，哪个部门开放接口，哪个部门就要承担接口责任。必须责任到人。
最后建立闭环，从风险发现、分析确认、整改处置到进度跟踪，形成闭环，这才是真正的生命周期管理闭环。通过不断循环，资产盘点才能做得更精细、更有效。
：这个图说得比较清楚。实际在机构里做盘点时，要把业务部门拉过来做责任人，通常都没那么容易。
：是的。接口安全管理办法、商业银行接口管理办法或国标里都提到，一定要责任到人。不责任到人，没办法落地，整个管理就变得很困难。必须责任到人，这是非常重要的一点。
：理论上我是完全支持的。
：落地情况跟安全部门、数安部门或监管部门、合规部门的执行力度有关。有些部门比较弱势，就非常难落地；有些部门比较强势，甚至采取“接口不认领就下线”的做法，最后促使各业务部门完成认领。
：这也是一种可行的推动方式。
Q18
AI时代，API安全的方向在哪里？
：在AI时代，API安全的方向在哪里？请吴总分析一下。
：AI时代，整体上仍然是事前、事中、事后：事前安全扫描，事中一体化防护，事后API审计。
具体来看，API安全方向可以分为两个维度：一是通过AI技术做业务赋能，二是通过AI技术做安全分析。同时，防护上要更加重视实时防护。
一体化安全防护方面，很多客户建设安全体系时往往分散采购：外部应用买Web应用防火墙，App、小程序买加固产品，智能体应用买智能体防护设备，API再买API安全网关或API安全防护设备。但这些接入渠道只是入口。Web、小程序、App、智能体、API，最终调用的都是API接口，交易和数据访问最后也落在API上。
AI时代，除传统Web应用防火墙外，还需要大模型应用防火墙。很多金融机构已经在使用大模型应用，大模型应用被攻击，需要相应防护。同时还需要AI攻击防护。客户经常问，AI攻击跟传统自动化攻击有什么区别？传统自动化攻击，比如爬虫软件，写好后会一直爬数据，不管有没有获取成功。AI不一样。AI爬取数据失败后，会想办法绕过，换一条路走。这是AI最大的区别：可以独立思考，自主完成任务，自主决策。这是AI攻击非常大的本质区别。
为什么讲AI攻击防护？今年刚结束的护网演练中，大量AI自动化渗透工具和智能体攻击出现。这个时代，必须同步提升安全防护技术，提升到AI攻击防护和对抗维度。
AI赋能业务方面，首先是API接口参数识别与开发合规。如何保证所有开发人员按照API开发规范做接口开发？如果不通过AI技术做参数自学习，就难以识别这些内容是否按照开发规范执行。所以AI赋能业务层面，API接口参数开发合规可以做一些事情。
其次是业务合规，API接口调用顺序识别。金融机构有1万个、10万个API接口，这些接口调用顺序是什么？业务逻辑是什么？问任何人都很难回答。现在通过AI技术学习接口调用顺序和业务顺序，判断是否违规，是很好的思路。
还有API路径名猜测。通过API请求报文、路径参数、路径名字，或英文缩写、拼音全拼等，推理接口是做什么的。比如是转账接口、查询接口、交易接口或注册接口，把接口名字自动识别出来。很多时候，10万个API接口梳理出来了，但没人能回答这些接口是做什么的。靠AI推理、猜测，可以辅助管理，因为资产很重要。
AI赋能安全方面，一是API告警降噪，通过本体模型、Skill方式实现。
二是AI深度分析。AI算法可以做深度分析。动态基线、未知行为、异常行为识别，可以通过AI分析技术、深度分析技术实现。包括孤立森林、图算法、LSTM时间序列等算法。也可以通过大模型技术、小模型技术，集成Skill识别模式。
AI时代还可以尝试引入智能体，比如日志分析智能体，做智能运维。智能运维可以只做分析。金融机构比较谨慎，直接做自动化防护或通过智能体做防护，大家不太敢做。做日志分析和识别，还是可以做的。
所以AI时代，API安全方向主要是两大部分：通过AI技术做业务赋能，通过AI技术做安全分析。
还有一点，防护维度上要更多考虑实时防护，而不是只做事后分析。AI攻击速度远比想象得快，金融机构版本迭代、补丁评估周期又较长，如果不具备实时防护能力，风险会越来越大。
📖 推荐阅读：直播回顾精华合集
