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 会是我们很好的合作伙伴,期待后续的合作~

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


Eotalk 往期推荐 ⭐⭐⭐⭐⭐:

【Eotalk Vol.04】如何安全开放 API 数据?|奇安信 负责数据安全的子公司技术负责人—简川力

【Eotalk Vol.03】结合 API & DaaS,让使用数据更方便|Tapdata CEO TJ 唐建法

【Eotalk Vol.02】从极客到 CEO ,开发者如何提升技术领导力?|甘果科技的 CEO 老甘(路文杰)

【Eotalk Vol.01】Eoapi,我们希望以开源的方式构建 API 生态系统| Eoapi 的核心开发者秦圆圆

你可能感兴趣的:(api安全数据网关测试)