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

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

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

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

之前是在某个大厂里面工作，负责云安全相关的产品线。有非常丰富的漏洞攻防和大数据安全经验。今天我们一起聊聊怎么通过 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 本身已经存在非常久了。像一些头部的、数字化程度非常高的企业，比如说 BAT 类型的厂商，其实深耕 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 资产的威胁程度，为安全团队的运营工作，提出优先级建议。

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

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

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

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

刘昊臻：功能做得非常深度。我有些更具体的问题，比如说一开始讲到的资产梳理，可能观众也比较好奇，通过流量我们到底能够梳理出多少或者说能够梳理出多少精确的 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 会是我们很好的合作伙伴，期待后续的合作

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