乐趣区

关于安全:洞态在陌陌的最佳落地实践

对于陌陌

MOMO 是挚文团体推出的一款基于地理位置的挪动社交利用,是中国当先的开放式社交平台之一。

在 MOMO,你能够通过视频、文字、语音、图片来展现本人,基于地理位置发现左近的人,退出左近的群组,建设实在、无效、衰弱的社交关系。

挚文团体的使命愿景是“连贯人,连贯生存”。

和洞态的结缘

为什么在上线前做 IAST 平安检测?

陌陌是去年十月份开始接触 IAST 技术,因为陌陌现有的自动化平安测试体系,并不能满足咱们的需要。目前除了 IAST 技术之外,SAST、DAST 这两项技术在陌陌都曾经有了落地的实际,咱们在上线前有针对源码层面的白盒扫描器,也有对线上业务进行扫描的黑盒扫描器,这两项技术都有本人的用武之地,当然也有一些弊病。

白盒扫描器 最让人诟病的一点是高误报,在一个企业当中,可能平安人员的占比原本就不高,这种高误报让平安人员没有精力一条一条解决。

黑盒扫描器 的试验原理,是对同一个接口发送大量 Payload,依据响应来判断是否存在破绽,从实现原理能够看出,第一个弊病就是流量大;第二个弊病,有些接口会把测试用的 Payload 代入数据库中,这就导致可能会有脏数据的产生。正是因为这两个弊病,导致黑盒扫描器不能笼罩到比拟敏感的业务,就导致它的覆盖率会低一点。

所以咱们就在想有没有一个解决方案,既能够保障破绽的高检出率,而且覆盖面还不错,并且没有脏数据,所以咱们把锋芒瞄准在 IAST 这项技术。

陌陌为什么抉择洞态?

理解到洞态,最开始是通过朋友圈的口口相传,洞态的开源间接促成了陌陌对 IAST 技术的落地实际,因为陌陌外部大量应用了自研的 RPC 框架,这就导致无论咱们抉择哪一款 IAST 产品,都得本人入手革新来适配咱们的框架。

所以洞态的开源劣势一下就体现进去了,咱们能够间接拿到代码,间接能够开始革新,从而省去多余的沟通环节。

开始因为洞态的开源抉择了它,然而在咱们应用一段时间过后,咱们发现洞态的劣势不仅仅是代码开源。

开源社区很沉闷

洞态开源社区很沉闷,咱们有时候在群里反馈一个 bug 或者是一个新的个性,洞态团队在下一版本就能够立马修复这个问题,而后帮咱们实现新的性能,这一点我特地喜爱,点赞!

轻 Agent 重服务端设计

我还特地喜爱洞态轻 Agent 重服务端的设计,劣势是如果 Agent 运算量过大,会对业务有一个比拟显著的影响,所以轻 Agent 重服务端,让咱们在 Agent 的性能上更好一点。

对于平安人员来说,推动部署会不便一点,如果你的 Agent 有问题,影响业务的失常运行,业务不会违心进行部署。

洞态在陌陌落地实际

那么洞态是如何在陌陌落地实际的呢?

咱们听听 陌陌的平安工程师何纪新 是怎么说的。

点击观看视频

↓↓↓

https://www.bilibili.com/vide…

洞态在陌陌曾经利用到哪个阶段?

因为咱们后期花了一些工作在外部 RPC 框架的适配上,所以咱们的部署工作进展比拟迟缓,因为陌陌平安在整个陌陌公司的属性,咱们推动部署 Agent 的形式并不是找运维同学批量接入,而是由平安同学对业务团队对接,进行部署,所以咱们的部署工作是比拟麻烦迟缓的,目前部署了几十台。

您感觉洞态哪个性能实用性最高,与陌陌理论业务场景更匹配?

在一段时间的应用下来,我最喜爱的是 Agent 治理相干的性能,无论是主动降级还是 Agent 热更新,我都特地喜爱,我感觉这两个性能特地赞。

主动降级 性能解决了咱们之前在业务上遇到的,部署 Agent 导致业务接口超时的问题.

Agent 热更新 次要是不便了更新 Agent,因为咱们改变比拟多,更新频繁,所以我感觉热更新很赞。

对洞态社区的奉献 or 想法

基于公司业务实现须要,在开发过程中,对洞态做了哪些降级和革新?

陌陌外部应用自研的 RPC 框架,所以咱们对洞态做了适配,在这个过程中,咱们始终和洞态团队的成员放弃着亲密的沟通,咱们反馈了本人遇到的问题和一些想要的新个性,洞态也都很好的反对了咱们。

在部署洞态 IAST 这件事上,开发人员是否难以承受导致推动艰难,您是怎么克服的?

在部署的过程当中,可能常常会遇到来自业务方同学的敌对提问,比如说 Agent 对代码是有侵入性的,出了问题怎么办?

像这种时候,你就得急躁的给他论述,咱们为了 Agent 的稳定性都做哪些工作,以及如果真的出了问题,有哪些措施能够解决这个问题。

对洞态的期待

依据公司理论利用场景,你最期待洞态 IAST 将来会开发的新性能是什么?

我始终想要一个性能,就是是否在服务端提供一个开关,就是配置项【是否开机即注册引擎】。当初 Agent Jar 包只负责装载 Core 以及其余 Jar 包,有了这个开关之后,咱们就能够在 Agent 服务启动的时候,不立马注册 Core 的以及字节码的重写,而是由平安人员手动进行 Core 注册以及字节码的重写,这样平安人员对于 Agent 管制感更强一点。

还有一个比拟期待的性能,如果 Agent 部署对业务方造成了影响,是否能够间接卸载掉这个 Agent,卸载过后还能还原业务方的代码字节码,这就要求咱们 Agent 在启动的时候要保留原字节码。当然我起初想了一下,就放弃了这个想法,因为可能会带来肯定的性能影响。当然如果洞态的同学有比拟好的解决方案,我还是特地期待这个性能。

更多详情:https://mp.weixin.qq.com/s/eN…

退出移动版