【访谈】Eotalk Vol.05: API 全生命周期管理，如何解决企业 API 安全问题

Eotalk 是由 Eolink 和各合作方一起发起的泛技术聊天活动，每期我们会邀请一些技术圈内的大牛聊聊天，聊一下关于技术、创业工作、投融资等热点话题。

本期 Eotalk 我们邀请到的嘉宾是来自星阑科技的 CTO 徐越~ 👏👏

徐越是一位 90 后，他在学生时代就已经非常沉迷于编程、黑客技术相关的东西。当时就通过找一些软件漏洞、甚至找到大厂系统的漏洞获得了不少赏金，后来去参与国际的黑客大赛，并且开源了自己的安全项目。他经历了整个 Web 安全、主机安全、容器安全方面的产品建设。

之前是在某个大厂里面工作，负责云安全相关的产品线。有非常丰富的漏洞攻防和大数据安全经验。今天我们一起聊聊怎么通过 API 的全生命周期管理来解决 API 安全问题。

API 的全生命周期安全，如何更好地为企业解决 API 安全相关的痛点？

徐越： 今天非常开心参加 Eotalk 和大家一起交流，我是星阑科技的 CTO 徐越。

星阑科技在做的事情和 API 高度相关，我们相当于 API 安全的供应商，属于网络安全赛道，帮助企业在 API 的应用或业务上防止一些攻击活动，降低他们的入侵风险和损失。今天我们就聊聊安全。

刘昊臻： 星阑在过去的几年发展得非常快速，在国内安全领域，是非常有竞争力的。今天我们聊到 API 的安全，在企业方面大家会面临什么样的 API 安全的问题？有什么样的挑战？有些什么案例可以跟大家分享一下？

徐越： 企业安全关注的事情很多，API 安全目前来讲是一个非常新兴的，但是非常重要的一个热点。软件世界数据通信万物互联的背景下，从我的视角来看，API 是一种新的能够更低成本去让数据打通，让软件集成融为一体，以及在某种程度上甚至能够以一种更好的生产方式，快速完成企业软件交付的一种新模式。大家也已经看到，各行各业的企业都已经在做一些做业务或者做 API 化的战略转型，其实就在 API 里面。

基础设施增长的背后，一定也会带来安全问题。我们讲的黑客攻击，以利益为主导的黑客攻击它无非就是想控制你的资产，或者想偷你的数据，而 API 这两点它是都具备。

一方面，API 本身是暴露在网络上的，相当于软件构建的系统，对网站攻击的手法完全可以应用到 API 的场景里。API 的后端，比如一些 Java 的代码，也是各种各样的系统，这些系统它存在的漏洞，也可以通过 API 打进去，最终导致自己的资产实现。这是传统攻防领域的情况。

最近我们看到一个更严峻的趋势，越来越多的 API 导致了非常严重的数据泄露。数据泄露对企业来讲，尤其是大型企业，以及关系到民生或基础设施的企业，他们一次大范围的数据泄露是非常致命的，可能不仅仅是业务上损失，还会涉及到监管层面。

以前的数据泄露事件，要层层攻击，从外网到内网到数据库打进去，打进去很费劲，最终才能把数据库的数据拖出来。现在不一样了，我们只需要找到一个没有认证授权的 API 数据，随便一个脚本就可以把数据拖出来，这是一个非常简单快速的入侵链路，但是它的杀伤力巨大。现在越来越多企业除了要面对漏洞攻击，还要面对 API 导致的数据泄露。

刘昊臻： 现在都在讨论万物互联、微服架构、API，这些确实让整个攻击成本变得非常的低。现在你想要找一个企业、一个产品到底有什么 API ，都不用像以前那样去扫描。直接打开它的官网，按下 F12 你就可以看到有什么请求，所以它有两面性。

一方面，现在系统对接会简单得多，但同时，攻击的成本也会比以前低得多。的确在最近的两年，我们会发现从用户的角度，从客户侧大家在意识上面会更加关注所谓的安全问题。而且我们看到业内的一些报告，比如说过去的网络安全，有半数以上的数据泄露事件都是由于 API 安全而导致的，像之前我们说国内的某个地方有信息的泄露，它的泄露的方式其实也通过 API。

这方面挑战的确是很严峻，有什么样的思路能够让我们去参考或借鉴？

 

如何更好的保障企业的 API 安全？

徐越： API 本身已经存在非常久了。像一些头部的、数字化程度非常高的企业，比如说 BAT 类型的厂商，其实深耕 API 领域也有很久了。包括国外的 API 的生态，可能在安全这个领域会比国内走得更前沿一点。他们为客户也做了很多尝试，现在我们看到的 API 安全的终局，还有软件全生命周期的理念，为了保证最终交付物是安全的，我们一定要在它的生产环节里，从设计到开发到运行，再到它销毁生命周期结束的整个流程，不同的点位都需要植入安全能力。

一方面是企业侧，目前国内很多企业会说我的 API 以前被打过，我要怎么办？可能他是在一些攻防演练中被打过，或者说有过一些数据泄露，虽然咱们从公开的信息里面看不到，但是实际上是有非常多的，这些方面会推动着企业真正去反思这件事情。

另一方面就是监管侧，监管侧也逐渐延展到 API 这一领域。通过这两个驱动力，我们看到最多的情况是：我确实要做这件事情，但是还没想好怎么样启动，怎么样去规划。我们首要要做的，是帮助企业走出第一步。

第一步我们会帮助企业建设三个基础能力：资产的梳理能力、威胁的可视能力、以及数据的梳理能力。通过前期的流量分析方案帮助企业去打地基。有了地基之后，就已经能摸清自己的家底，即可以针对性的基于自己业务的需求去思考下一步要怎么走。

刘昊臻： 明白，我们频繁提起国家去年颁布的数据安全法，的确是会让大家对个人隐私，、企业数据泄露的问题更加重视。

 

企业 API 安全的三板斧

徐越： 帮助企业打一个 API 安全的地基，我们分为三个步骤。

第一：模清家底。很多的大型企业的安全团队和业务团队就是做 API 生产流程的团队和守护 API 安全的团队，它们往往是有一定的部门沟通成本。在企业逐渐壮大之后，无论是从人员配合机制、采购的流程等等都有一定的割裂，负责安全的同学第一个想的是保护 API。那到底这项业务到底有多少个 API ？这些 API 是哪些部门在管？怎么管？大部分的安全团队是摸不清的。我们要帮助企业在不知道哪些服务器上写的哪些程序，有多少 API 在通信的情况下，从网络流量做快速的梳理。那么，我们只需要在网络侧核心汇聚层的一些节点上监控 API 的通信流量，即什么样的 API 在存活，就可以在没有频繁的部门间沟通的情况下，直接帮助安全部门摸清：这一项业务到底多少个 API？它的通信模式是什么？所以，安全建设的第一步就是先要摸清家底。

第二：我要能看见别人打我。这是作为安全守护者最基础的职责。可能以前企业的业务团队会从运维的角度，对 API 通信的过程有日志记录，但是这个记录很难满足安全的诉求。比如我想判定一次攻击是否成功，需要记录 API 的完整的原始流量，无论是四层还是七层，都是不能经过数据加工的，而是需要最原始的流量。所以第二项能力就是我们帮助安全团队，从流量的视角，比如说别人在攻击我，流量上会有一定的痕迹，我们可以看见攻击。

第三：API 数据流动的绘制。API 本身的价值就是传输数据，无论是从企业内部的安全，还是从效果角度，或者业务角度来讲，都会有关注数据的场景。比如举办活动，有一些活动的减免，刷单薅羊毛等等，这是异常的访问流量。再比如一些接口是否有越权未授权的访问，没有认证就开出去了，导致大批量的数据泄露，这样的例子已经见过太多了。还有就是一些 SAAS 或 PAAS 的服务，我们不知道哪些开发者可能买了你的服务，突然有一天就把 API 的 AK 和 Token 直接传到了 github 上，我们需要监控这一类行为。监测 API 的数据流动，一方面是符合安全部门的监管合规审计要求，另外一方面是真正避免业务侧的损失。

刘昊臻： 理解，首先如果要对安全有一个比较好的防护，得知道到底有什么 API，所以第一件事情是做一个类似于 API 资产的整理或者是梳理。我们以前也遇到过类似的情况，某个银行客户内部系统有 200 多个，他们自己能够统计到的 API 有接近 1 万个，还有些是他们不知道的，有的系统很老旧，开发人员可能也离职了或者他们自己也不记得，我们就必须要做 API 整个资产的梳理。

第二步，整理好了 API 资产之后，就要去监控它上面的一些流量，到底有没有异常，有些风险，比如会不会有人攻击你，或者它的请求频率、次数可能不那么正常，这个地方可能会对流量建模，其行为可能跟平时不太一样。

第三步就是对于 API 的数据还要做更多的识别，比如是不是有一些敏感信息？有些不应该出现在外网的数据，它居然经过了网关，或者经过接口被暴露了出去，甚至还涉及到人员的违规操。

 

萤火 API 安全分析平台

刘昊臻： 能否给大家介绍一下你们在做的萤火 API 安全平台？

徐越： 我们产品能力就是围绕刚才提到的三个主要的场景。比如在资产梳理里面，用户的第一个角度是要尽可能完整的梳理出已有的 API 资产。我们通过流量侧，跟 API 网关进行数据打通，把已经注册进来的资产用不同类型的标签标注出来，它是属于哪些业务，它的资产注册量，还有一些我们叫做影子 API 没有注册进来的，把 API 统一管控，这是资产角度的问题。从资产视角来看，光知道它有哪些 API 资产是不够的，安全团队不管是人数还是预算都是有限的，肯定要把精力排高优先级，哪些资产它是最危险的，就要优先去做。

怎么定义资产的威胁程度？从它历史有没有不安全通信的检查项，有没有已经被攻破的入侵事件，以及它传递的数据否是非常涉敏的，从这几个维度去描绘 API 资产的威胁程度，为安全团队的运营工作，提出优先级建议。

接下来风险监测，我们在摸清资产之后要把这批资产的行为监控起来，以免出现安全事件又意识不到导致严重损失。风险监测方面我们能做的事就比较多了，目前我们已经集成了大概有 100 多种的检测项，不同类型的威胁，基本上也都能够覆盖。就像刚才提到的漏洞攻击类，我们背后有安全工程师持续维护，针对行业内部出现的各种中间件、各种组件，只要跟 API 攻击相关的，都会第一时间进行分析维护，让产品时刻带有最新的检测能力。

再就是通过行为分析，鉴别 API 的异常行为。针对数据我们内建了一些通用的隐私数据识别模型，目前大概有 100 多种，比如常见的卡号、手机号、邮箱、人名、地名、出版物、公司内部重要文件的敏感信息等等，这些是最底层最基础的识别能力，只要你的 API 里面包含了这个数据，就可以自动地从文本里识别出来。

识别出来之后还要去判断数据到底敏感不敏感。比如一个手机号，他是 SAAS 用户的手机号、企业级客户的手机号、员工的手机号，还是老板的手机号，单从一条数据来讲，仅仅识别出隐私数据还是不够的，还要对它进行更深入的研判。比如他在我们内部是属于哪些业务跟业务层的管理，或者说针对我们内部的数据分类分级的管理标准，再去进行上层的抽象，这样才能把数据管好。

总体来讲就是资产入侵、风险监测和数据这三个点。

刘昊臻： 功能做得非常深度。我有些更具体的问题，比如说一开始讲到的资产梳理，可能观众也比较好奇，通过流量我们到底能够梳理出多少或者说能够梳理出多少精确的 API？

 

通过流量分析我们能够梳理出多少精确的 API？

徐越： 流量识别 API ，流量分析的产品非常多，抓到流量这件事并不难，只需要解析好所有主流 API 的协议就可以了。难的是两个点是，第一你能不能适配所有主流企业的不同技术架构，比如给到我们一个复杂的技术架构，你要监控哪几个点？从哪几个点通过什么样的技术手段去提取流量？以及在每一个节点里，流量的探针协议解析的速度和它的吞吐量的限制，是有一定技术壁垒的。像流量解析，我们有专门自研的一块引擎，专门从四层流量还原到七层，再从七层去分析 API。可能我识别到了 1 亿次请求，到底背后它是一亿个 API 还是一个 API ？我们目前是用聚合的算法去做，把所有的 API 无论是 URL 的部分还是 Body 的部分，把所有的参数全部抽象成一个数据结构，再通过统计的方法去判别。比如我 path 里的第一块，前一个字段它可能是一个固定值，后一个字段是一个可变的参数，通过一定的算法把通用的模式识别出来，再用这些通用的模式去打标签，这种增量的流量逐渐的能够收敛掉，接近到真实 API 的资产数量程度。

刘昊臻： 第二个问题，刚刚讲到敏感的数据识别，我们怎么知道这个手机号它到底是有多敏感，或者说我怎么知道它里边的哪个字段可能是敏感，是需要我们在开始的时候先配置吗？还是说它其实有体验比较好的、比较自动一点的方式？

徐越： 我们有专门的能力建设的同学去维护，针对主流的 100 来种的数据实体，基本上都是可以自动识别的。识别方案分为不同的几种，可能类似于规则匹配类型的、类似于校验算法类型的，比如识别身份证号的时候，如果只匹配一个数字的一个字符串的话，那它肯定是不准的。我们其实可以考虑，比如它前面的省份是固定的，后面的一位其实是整个前面的一个校验位，这种我们就会针对不同的实体类型。如果它自带校验的话，当然是最准的。

还有就是类似于中文类的，最简单的人名、企业地址，没法用模式匹配的方式去做。我们也是训练了一些简单高效的小模型，比如真正从客户端获取到的一些场景化数据，以及其他的数据集积累下来的标注样本，去训练一些数据识别的模型出来。像这样话，其实在机器学习领域也是一个比较成熟的方向，我们借用了过来解决一些安全的场景，自动识别基本就是这几种方式。

同时我们观察到很多用户，有一些差异化的需求，比如可能涉及到一个订单接口，那它第一个参数你也不知道叫什么，它后面就是一个数字，这个数字就是它商品的价格，他要监控这个商品价格是否有零元异常，也是很多黑客或者白帽子，经常挖的漏洞。这种情况下，我们就给客户提出一些比较友好的，可以让他自定义的方式，直接在报文里面指定一项监控。

刘昊臻： 刚讲了 API 资产梳理，我们有很多用户其实希望不单纯是能够把文档给识别出来，他还希望知道我到底有哪一些服务器或者哪一些用户，他调用了接口，这个接口背后对应的是我的哪一些服务，或者是哪一些 IP 地址。这个地方它应该会有个拓扑图，这个时候去做 API 资产整理下其实会更好一些，目前这块你们是不是也有这个能力呢？

 

调用链路可视化

徐越：是 的，本身我们的底层技术架构是基于一个数据分析数仓的结构去做的，我们基本上是用一些数据采集加工处理的能力，最终通过一个图的方式把 API 的调用链路可视出来。比如链路在集群里面可能就是每一个 service 之间的调用，可能在普通的虚拟机里以一个 IP 或者一个域名指代一个服务，中间两个 IP 之间它有多少个 API，这些 API 它存在哪些的通信模式，哪些的风险，我们都可以用可视化的方式表达出来。

对安全团队来讲，第一我可以通过拓扑图一眼看出来这个 API 到底是干嘛用的。第二个，比如我的 API 被入侵了，接下来需要做止损和救火，这是安全团队的责任之一。但是救火可能会影响到业务，这个时候就要研判它的上下游到底是干什么用的。采取的手段也不一样，是直接拔网线还是直接封 IP，或者只能加一些规则过滤掉，还是服务器可以关停等等。调用链路可视化可以帮助安全团队去研判，做救火的运营工作。

刘昊臻： 所以它其实跟很多其他产品是能够互相结合的。比如和 Eolink 的 API 管理和网关。像网关可能直接就有流量的流通，只要打通了，你们这边的一些安全规则就可以直接同步到网关上面去。比如说你们从网关那边得到流量实时分析完之后，发现流量异常。就给网关那边同步一个临时的处理规则，及时把流量异常的流量给阻断掉，或者是把某个 IP 给封掉，这个场景应该在你们客户里面挺多的。

徐越： 是的，因为安全也是需要联动的，它是比较复杂的工作流。我们也经常会遇到，最多的可能是跟 API 的网关做一些数据层的打通，包括跟一些安全设备，有些企业会希望把几十款安全设备统一来管理，统一去运营它的告警，就相当于是给其他的下游设备，去收集数据，会有相应的对接或者集成。包括像防御，我们可以监测到一些威胁，别人正在拖我的数据，我要给他阻断掉，可能就会调用一些防火墙、或者一些堡垒机、或者一些网关类能阻断流量的产品，然后去打通，实现能力的联动，这是比较丰富的场景。

刘昊臻： 我由此衍生出一个疑问，我们有很多客户希望能够有类似于安全测试，比如我线上可能记录到了一些有风险的流量或异常流量，可能在下个版本迭代或者要做复盘的时候，我拿这些异常流量去做一次回放，去检测我的产品，这块不知道你们有没有遇到过类似的诉求？

徐越： 有的，本质上来讲安全的问题就像我们治病一样，大家都希望在还没有发病的时候就把病给治了，安全也是一样，企业如果真正能够做到在开发的过程中，甚至在开发的设计阶段就规避掉很多安全风险，那么它的成本是非常小的。等到别人打你了，你再去救，成本就很大了。安全测试在安全领域发展是最早的一项，也是历史比较久的。

刘昊臻： 这些跟 Eolink 的 API 全生命周期管理产品有很多可以结合的点，因为Eolink不仅有API的文档、自动化测试，还有网关、监控等产品。很多用户也是希望在我们这边能够做安全测试，如果你们安全测试那块弄好的话，和我们的产品可以很好的结合。

徐越： 是的，Eolink 会是我们很好的合作伙伴，期待后续的合作～

刘昊臻： 今天非常感谢徐越来给我们做分享！