从阿里工程师谈业务安全通用方案 看安全运维的角色转换

没有绝对安全的系统,同时为系统提高安全性也并非零成本。 所以客户需要的“安全”是安全成本和安全资损的平衡。 安全运维者需要转变自己的角色,从业务阻碍者变成业务促进者。

“你们安全不要阻碍业务发展”、“这个安全策略降低用户体验,影响转化率”--这是甲方企业安全部门经常听到合作团队抱怨。但安全从业者加入公司的初衷绝对不是“阻碍业务发展”,那么安全解决方案能否成为“业务促进者”,而非“业务阻碍者”呢?答案是肯定。

在安全产品中,和业务解耦、对客户透明的安全产品,如防火墙、IDS、WAF等就很少遭受到类似的吐槽。

但回归到互联网业务安全场景,业务安全防控常见场景往往如下:

场景一:

安全:”这个安全策略需要你们把用户登录的IP发给我。”

业务开发改造N天上线。

安全:“这里有一部分IP不对啊,是不是取的网关的内网IP。”

业务开发:。。。

场景二:

业务开发:”安全让我们纪录user-agent、浏览记录,现在服务的性能都消耗在打日志上。做这些有业务价值吗?”

安全:。。。

这些场景核心问题都在于业务安全解决方案通常嵌入业务逻辑中。那互联网业务安全有没有如同防火墙一样通用的解决方案呢?要解答这个问题我们先探究业务安全的“通用安全风险”。

业务安全通用安全风险

要找到业务安全的通用风险,首先得定义什么状态才算业务“安全”。当安全工程师被客户问到“这个产品是否安全?”,他往往会考虑各种安全细节问题,业务类的是否会被撞库、是否存在信息泄漏,系统类的是否有注入、水平权限控制等问题。但这些安全细节问题,往往并非问题“是否安全”的答案。

客户所需要的“安全”是一个平衡状态。没有绝对安全的系统,再健壮的系统也有可能因为安全问题而遭受资损,同时为系统提高安全性也并非零成本。 所以客户需要的“安全”是安全成本和安全资损的平衡。 为一个DMZ区的博客服务器配备一个专属安全工程师保障不被入侵不是客户需要的“安全”。节约安全成本却导致大规模的撞库事件也不是客户希望的“安全”。

回归到业务安全场景,会发现一个共同特征。只有达到 一定规模,批量利用,业务安全漏洞 才会造成业务影响,产生用户无法承受的资损。一次Web攻击可能就写入webshell导致机器沦陷,但有限次的撞库、垃圾注册、垃圾消息、刷单造成的资损是企业可以承受的。而攻击者要达到大规模,批量性的目的,都要通过机器来自动化实现。所以可以得出结论—— 大规模、批量性的机器风险是业务安全领域面临的通用风险 

通用解决方案需求分析

上节已经得出大规模、批量性的机器风险是业务安全领域面临的最大痛点,那么要实现通用的“解决机器风险方案”有哪些需求。针对机器风险业界防御手段已经很成熟--针对人类知识(验证码)、针对人类固有特征(行为识别)、消耗机器成本(POW)等。但业界仍无整合这些防御手段提供通用普适的业务安全 解决方案 ,问题主要有两点——无法做到业务透明和快速部署。

业务透明

现有的人机识别方案,客户需要前端、后端的改造进行接入,甚至于业务需要配合安全方案进行业务逻辑的调整。安全侵入业务主逻辑,有时候安全甚至成为业务的负担。

快速部署

机器风险防御手段过于复杂,无法快速部署,进而导致业务系统无法通过配置简单的实现全站部署防控。而业务系统往往有无数的小流量入口,这些未进行部署的入口往往成为漏洞。

通用解决方案具体实现

如何实现“业务透明”、“快速部署”的通用机器风险解决方案呢?核心是能够以 中间人的方式介入浏览器和业务服务器 之间,实现如下需求:

1、在页面注入相应的Javascript脚本;

2、 Javascript脚本采集数据并hook用户所有触发提交操作的事件,将数据在用户发起请求时注入请求中;

3、能够代理转发浏览器与业务服务器的请求,并解析请求内容;

现在中间人攻击工具(MITMf)已经相当成熟,而逆向应用中间人攻击工具的思路似乎可以达成这些需求。在业务服务器与浏览器之间部署反向代理服务(通常为WAF),用户在浏览网站时由WAF注入前端需要数据采集的JS,同时JS在前端hook用户的请求事件,用户发起请求时将采集的风险识别数据注入,请求再次到达反向代理时,由反向代理提取相应风险识别数据提交风控大脑进行综合决策判断是阻断用户请求还是发起二次校验挑战。

业务风险防火墙在业务服务器与浏览器之间的交互流程如下图:

关键的业务风险防控采用三层漏斗模型进行层层过滤,达到透明阻断业务风险的目标。这三层漏斗模型分别是:阻断机器从而杜绝攻击者批量攻击的风险,异常流量分析识别部分漏网的机器行为及行为轨迹异常的不良用户,征信模型基于对于用户的信誉评分拒绝不良用户,最终达到将服务推送给目标用户的目的。

阻断机器:

1. 针对人类固有特征进行机器识别,基于JS实现的可信前端采集用户行为数据,通过线上实时模型来发现机器行为进行阻断;

2. 消耗机器攻击成本从而让攻击得不偿失,基于POW(proof of work)原理,通过服务端下发问题消耗前端的计算量。对于有足够空余CPU资源的普通用户少量的计算并不消耗成本,而攻击者需要达到批量攻击的效果则会占用极大的计算资源,让攻击得不偿失。

流量分析:

通过机器学习对网络流量中的异常流量进行识别,从而拦截上一层漏过的行为轨迹异常的不良用户,常见思路如下:

1. 浏览轨迹,比如在互联网金融场景,正常用户会在注册后对比多款理财产品最后进行下单,而“羊毛党”往往在群里得到活动信息就会直奔活动页面薅羊毛;

2. URL聚类,在网络购物场景,正常用户购买某款商品之前一般会在同类目商品中进行选择;

3. 浏览频率,在UGC网站上,用户浏览和评论的一般是有一定时间间隔,频繁秒回的用户极有可能是在发垃圾消息。

征信模型:

伴随互联网诞生有一句经典的论断”在互联网上,没人知道你是一条狗”。然而业务安全场景,识别用户身份、评估用户信誉是业务风控的重要依据。

借鉴现实社会成熟的征信系统,且现在互联网已经是一个成熟的生态闭环。通过设备指纹标示用户,基于用户在互联网的活动记录进行信誉评分,并辅以失信用户名单,从而对bypass前两层的高风险用户进行拦截。

业务风险防火墙的价值

回归到文章开始的问题,业务安全防控如何成为“业务促进者”,业务风险防火墙能否达成这个目标?答案是肯定的。

业务风险防火墙有两大优势,而这两大优势在保障企业业务安全同时也达到了促进业务发展提速的目标。

  • 第一,业务透明,业务开发资源可以专注的投入在业务代码上,降低企业达成安全需求的成本。
  • 第二,快速部署,业务风险防火墙可以快速进行全站部署,快速实现对网站业务风险的保障。如同安全带的发明保障驾驶员的安全性同时进而让汽车能够更安全的以更高的速度行驶,对全站进行业务风险防控后也可以让企业真正把业务推送给目标用户,从而让企业的业务发展提速。

原文发布时间:2017年3月24日

本文由:freebuf 发布,版权归属于原作者

原文链接:http://toutiao.secjia.com/business-safety-general-solutions

本文来自合作伙伴安全加,了解相关信息可以关注安全加网站

时间: 2024-10-06 12:48:06

从阿里工程师谈业务安全通用方案 看安全运维的角色转换的相关文章

阿里云大数据计算平台的自动化、精细化运维之路

免费开通大数据服务:https://www.aliyun.com/product/odps 作者简介:   范伦挺 阿里巴巴 基础架构事业群-技术专家 花名萧一,2010年加入阿里巴巴,现任阿里巴巴集团大数据计算平台运维负责人.团队主要负责阿里巴巴各类离在线大数据计算平台(如MaxCompute.AnalyticDB.StreamCompute等)的运维.架构优化及容量管理等 1.前言 本文主要会从以下四个方面来写,分别是: 阿里大规模计算平台运维面临的一些挑战: 阿里自动化平台建设: 数据精细

阿里云容器服务 - 提速云端应用部署与运维

阿里云容器服务 - 提速云端应用部署与运维 阿里云容器服务简介 什么是容器服务 什么是容器 容器服务解决了什么问题 容器服务架构 容器服务使用流程及场景 容器服务 阿里云容器服务(Container Service)是一种高性能可伸缩的容器管理服务.支持一键部署Docker集群,提供便利的基于容器的服务与应用的编排.部署及完整的生命周期管理.提供阿里云Docker镜像加速管理服务,支持基于Git等代码仓库集成.http://www.aliyun.com/product/containerserv

#运维侠客行·杭州站#关于业务、开发、架构、运维的思考

运维侠客行特邀作者 黄河,平安壹钱包高级架构师,应用运维负责人.前支付宝.大众点评资深运维工程师. 纵观整个互联网,整个技术部门,或多或少存在以下的情况:开发(业务开发):永远被业务驱使或者强奸,越来越忙,支持业务越来越疲于奔命.产品.业务上线快,bug也很多.架构:一般中大型的互联网公司,都会有架构部门或者小组.他们一般认为主要解决业务开发人员的需求,如提供RPC框架,消息中间件,缓存方案等,顺便也显示出其技术的水平就更好了.往往会出现,方案设计很漂亮,最终落地时却问题百出.运维:绝大多数互联

云监控推出应用分组,帮你在阿云上跨地域、跨产品从业务角度管理资源,提高运维效率!

云监控 应用分组功能上线啦 宝宝家大业大,业务遍布大江南北,又是阿里云的铁杆粉丝,购买了一大堆各式各样的云产品,可是却不能按照业务管理资源,实例经常找不到,改个报警规则更是只能一条条改,好烦啊! (╯‵□′)╯︵┻━┻ 功能速览 应用分组可以跨产品.跨地域,真正从业务角度管理您的云上资源 一条报警管全组,迅速提升运维效率,告别单个实例设置报警规则的旧时代 新增故障列表,快速定位故障实例 自定义监控图表,你的页面你做主 所以宝宝不哭!云监控推出的应用分组功能,就是帮你解决这些让你抓狂的管理问题的!

业务服务管理:大中企业IT运维的撒手锏

最近的媒体再次 提起用友当年的"洗衣机理论",并将该理论与IT运维管理联系起来,不由得让人思索起来. 所谓的"洗衣机理论"是讲如果想要洗衣服,不必要考虑洗衣机的原理,洗衣机怎么洗的?而是先把洗衣机先买回来,用上我们自然就会洗衣服了.这个说法被用于企业,先考虑ERP时,还是先做BPR(业务流程再造)?引用这个说法是告诉企业不要把时间浪费在"现在管理好不好"上,正因为企业的管理做的不好, 所以才更需要ERP,只有先用上了ERP,才知道哪些地方的管理不

《Puppet权威指南》——1.1 浅谈运维工程师

1.1 浅谈运维工程师 想必大家都看过<好的程序员是普通程序员效率的数十倍>这篇文章,这句话是比尔·盖茨说的,被很多文章引用和转载.笔者读后感同身受,觉得这篇文章讲的并不夸张.程序员如此,运维工程师也是如此,一个优秀运维工程师的效率确实是普通运维工程师的数十倍.本节笔者将带领大家了解一下优秀运维工程师和普通运维工程师之间的不同之处.我们从运维工程师的定位和职责开始介绍,继而详细分析普通运维工程师和优秀运维工程师的差别,最后落脚到自动化运维工具.1.1.1 运维工程师定位和职责 要想了解普通运维

某金融公司实践 | 从SRE&amp;DevOps&amp;PE谈如何颠覆应用运维认知

导读:[GO SRE!] 为数人云SRE系列活动专题,本文是北京站线下活动"当西方的SRE遇上东方的互联网"中某金融王超老师的分享. 他将从SRE,Devops, PE间的关系开始,介绍企业该如何构建适合自己的运维组织架构并管理团队,讲解持续交付.监控.容量规划等具体运维场景实操,从工程实践的角度解读大规模复杂化的业务场景下运维指导思想的落地. 王超 / 某金融企业高级PE 目前在某金融平台负责一个20人左右的应用运维团队(PE团队),也曾负责人人网PE团队.现阶段主要关注运维与业务的

阿里大数据SRE专家池枫:做Tesla,是因为传统运维方式已不能满足业务发展需求

4月20日20:00-21:30,一场别开生面的技术大会-- "运维/Devops在线技术峰会"将在线举办.从网络基础架构实践和演进,到同城容灾架构剖析:从如何稳定.安全的使用云数据库,到企业如何在云上安全加固最佳实践:从阿里云专家理解的DevOps,到如何构建一个通用化的智能运维平台--不仅一一告诉你云上的运维重点在哪.运维人应该如何思考,也手把手教你如何做.同时,对于处于转型中的企业,我们也邀请了有代表性的互联网公司来分享他们的亲身体验. 阿里云运维/Devops在线技术峰会官网:

如何设计并实现一个通用的应用运维管控平台

一.问题背景 大部分的应用运维工作随着服务器数量和产品数量的增长而增加,而运维人数的不足导致单个运维人员所承担的工作任务较为繁重,同时运维工作的不标准.无自动化使得应用运维任务十分复杂,耗费的大量的人员成本.时间成本和沟通成本. 应用运维工作说白了大体可以分为两种情况: 1. 在某个或某些服务器上执行某个脚本或命令; 2. 将某个或某些文件传输到某个或某些特定的服务器的特定位置上.在服务器数量较少的情况下,可以通过ssh或scp命令实现上面两个操作;服务器数量较多的情况下,我们可以通过包装ssh