首页>会议文档 >

YY直播 韩方-YY直播安全运维从“0”到“1”的实践

page:
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践
YY直播 韩方-YY直播安全运维从“0”到“1”的实践

YY直播 韩方-YY直播安全运维从“0”到“1”的实践

所属会议:GOPS 2016全球运维大会 • 北京站会议地点:北京


下载

手机看
活动家APP客户端

扫二维码下载
或点击下载
Android iOS

8777次
浏览次数
GOPS 2016全球运维大会 • 北京站所有文档 韩晓光 - 传统运维VS互联网运维:从哪里来到哪里去? 高级架构师-刘源-大规模分布式存储的开发与实践 云集智造(灵犀) 熊亚军-混合 IT 时代需要什么样的监控系统 中交兴路车联网 许颖维- 中小企业如何优雅地管理多机房服务器账号 七牛云 陈爱珍-七牛百亿级请求量数据处理系统架构演进 腾讯 方锦亮-腾讯大规模集群跨城迁移之术 eBay 方伟-建立基于Kafka的企业级数据传输平台 平安证券 刘宏霞-券商大数据质量保障之道 运维自动化-张乐-持续交付:高效率和高质量可以兼得 蓝鲸 党受辉 - 【从零打造百人级别的DevOps团队】等 光载无限 欧曜伟-分布式监控系统的容器化变迁与 CICD 实践 Google, SRE孙宇聪-Google 运维技术平台与设计思想浅析 Qunar DevOPS叶璐-去哪儿私有云建设和自动化管理 云杉网络 张天鹏-云网络数据分析及应用 陈运维自动化-陈尔冬-第三种运维 迅达云成科技 陈震-云计算资源的全球部署经验 携程 胡俊雅-SaltStack在携程万台服务器上的运维实践 腾讯 洪楷-腾讯游戏运维服务体系 优维科技 王津银 - DevOps运维体系框架与其精益实践 —以运维为始,以运营为终,以交付为桥 乐视 邓良驹-乐视电商云高可用架构与实现 去哪儿网 吕晓旭-去哪儿实时流系统实践 广州尚航 尹璐-高可用性自适应安全网络 京东 赵明-手机京东统一与开放的监控体系构建 ThoughtWorks 金明-建设持续交付容器云平台 IBM马达-PaaS平台中的资源管理及调度 DOM-Toda-A Heart of EXIN DevOps Master 沙盘教练梁定安-凤凰项目沙盘精要 EXIN 国际信息科学考试学会 孙振鹏 - DevOpsDays 即将首次落户中国 优维科技CEO 王津银王津银-持续交付及互联网实践 阿里巴巴 范伦挺-阿里大数据计算平台运维实践 优云 刘东海-运维演进正确之道 - ITIL+DevOps双态运维 微信支付 莫晓东-微信支付数据库管理和优化实践 盛大游戏 胥峰-盛大游戏万台服务器自动化运维实战 微信支付 周汤-微信支付数据库管理和优化实践 金融保险-任明-传统企业运维演进及开源实践 金融保险-张晓诚-平安证券的自动化运维演进 中信银行 周海鹏-“十问”:银行私有云建设若干问题 博云 李亚琼-场景化运维——平台、引擎与自动化 点乐 赵舜东-中小企业 DevOps 实践之路 360 陈思雨&李福-从漏洞组合攻击看运维安全之殇 奇虎360 王珂&任言-XSS攻击与企业级的解决方案 金山孙召增-企业内网APM实战 凤凰网 王建新-大型互联网公司与创业公司的 IT 对比分析 首都在线周东波-运维背后的逻辑 HIM陈贻泰-大中型互联网企业 IT 基础架构概览 高效运维 发起人萧田国-DevOps 2.0:重塑运维价值 主会场-Toda-DevOps & TPS - For success your Business 蓝鲸 党受辉 - 遇见蓝鲸,也许是个机会- Google SRE孙宇聪-SRE:Google 运维解密 中国移动王晓征-浙江移动云运维实践 KSC视频云 魏代政-视频直播运维难点与解决方案 DevOps Master 白皮书,企业 DevOps 的成功之路

文档介绍

韩方,欢聚时代(YY直播)运维部安全中心总监,公司T4技术专家,10年以上安全领域的攻防研究和设计开发工作,对于平台安全、应用安全、业务安全等安全领域有非常深入的研究,申请过多项安全领域相关技术专利,以及发表过多篇安全领域学术文章,多次参加安全领域技术峰会分享;曾先后主导设计和开发云防DDOS系统、分布式web入侵防御系统、Linux入侵防御系统、移动安全加固系统、外挂对抗系统、机器人识别挑战云服务等安全领域对抗和防御系统;熟悉互联网安全技术体系,主导公司安全技术体系建设。

演讲实录

一、概要

本文分享分三部分:


介绍一下安全运维救火的经历,可能有很多搞安全或者搞运维的小伙伴都有同样的经历,看看是否有共鸣。

YY 安全运维发展历程,从0-1的实践,2012年开始建设到现在有4年的时间。

安全运维体系建设考虑的因素。

二、YY的安全运维视角

先看一下 YY 主营业务构成。因为所有安全对抗和安全运维的体系建设都跟业务有关系,50台服务器和500台服务器有着不同的思路和方案。YY目前主要的业务还是直播和游戏,主要有虎牙直播,YYlive、BIGO  LIVE,多玩游戏。


fcf250e58758b16c003a908f9734d6ad503a2ec9

直播的行业有一些个性化的安全问题,比如主播的IP被打劫,这对业务影响很大,因为主播不能播了。你的安全对抗和你运维体系建设,与业务形态有非常大的关系。安全运维使命:维护业务安全稳定地运行。涉及的方面比较多,我们比较常见的是服务器、网络、硬件、基础平台,有很多涉及到业务。


dbb31fe4092c5906b82776fc6f2c4ccecf6c9161

直播的业务会涉及到音频、视频,后面我们会有一些案例,一些特殊性的音频劫持,视频流的劫持。比如本来两个人在做音频联麦的时候,黑客不能进来,这是直播行业特殊的安全需求。还有通用的,各种行业都存在攻击。信息攻击和入侵等漏洞,这是安全运维比较常见的形态。


安全运维的团队,就是为了能够保障业务的连续性,稳定性和可靠性。在持续运维中有几个比较重要的职能:质量、成本、效率。对于我们安全运维团队来说,今天我们的关注领域就是安全,质量再怎么高,效率再怎么高,没有安全,稳定的可靠运行也没有意义。


安全运维团队在整个运维团队中是不可缺少的,但不同的公司,不同发展阶段,可能不一定需要专职的团队。创业公司初期需要系统网络和数据库,安全方面看到很多刚开始初期都是由系统运维来做,或者说由其它第三方服务,购买第三方安全服务或安全的产品和硬件,这也是可以的,但职责不能缺少。


今天就我就带大家站在 YY 的视角来看看安全运维团队需要面对的安全事件。


e2f698a70e0280edc70729f5304a81441e144af5

1.入侵


当你的服务器数量达到一定规模时,例如我们 YY 有超过几万台服务器,即便仅有万分之一的入侵概率,每天也可能有几起。安全团队要分析,为什么这个杀不掉?为什么这个流量这么大,但正常的流量没有跑?还在发流量,但看不到连接的流量,为什么?交换机可能由于这么多的流量被堵死,这些情况都有可能是入侵。某某公司泄露很多的数据,入侵会导致业务的巨大安全隐患。入侵你的交换机,改变你交换机的网络配置,直接导致网络瘫痪。


2.攻击


攻击YY 的 DDOS 攻击和 CC 攻击都比较常见的,一天有十几二十起。我给大家说一个数据,大家会知道这个攻击的成本很低。打一次15-20G的 DDOS 攻击需要120块钱,单价两万块钱的普通服务器可以被打挂掉20台。千兆网卡的服务器可以处理的极限也就是30万并发,也就是并发 PPS 30万,160块钱可以打到700万 PPS,这是一个非常惊人的数字我见过可以五千块钱包月随时随地打,就是这么便宜。安全团队和安全运维团队面临的对抗不容易,因为产业太大,赚钱比我们安全运维团队还多。


3.破解


移动端有很多像机器外挂,有好的外挂,也有恶意的外挂,音视频的劫持,都是研究你的业务流程,从而破解软件实现他的目的。


4.漏洞


大部分可能是你在使用的开源组件时候的漏洞。这两年比较出名的心脏流血,这些漏洞出现后需要安全运维团队评估,是否立即升级,影响是什么,对你公司有无影响。有可能有漏洞没有影响,因为需要有一定的利用条件。我们出现一次漏洞就忙通宵,老大要求24小时之内修复。前几天的某某泄露的数据官方回应,也是由于双十二的漏洞所导致。在远程执行命令,有很大的触发条件需要开很多的配置权限,所以这必定会对你产生影响,必定会需要升级,甚至升级非常急迫,这是安全团队面临的一些漏洞问题。


除了开源组件会有漏洞,业务系统也有漏洞,这也是非常多的。比如音频的劫持,视频的劫持,客户端发消息,消息处理的不严格,黑客把主播的 IP 调出来,要求主播每个月给三千块钱,如果不给钱就打你下线不让你赚钱,这是业务功能的漏洞导致了业务场景受到了巨大的影响。这是安全团队需要及时跟进的原因。


5.脱库


雅虎和某某东的数据泄露都是如此。有可能来自于内部员工的主动,但多数都是来自外部的入侵。数据库保存密码没有加密,直接变成了明文数据库。


6。劫持


劫持对业务的影响很大,很多的用户使用你的 App,他已经得不到正常的服务,而是被劫持方的一些服务。音视频的劫持都很多。


这就是我列举的主要一些安全运维在平时工作中所要面对的安全事件。我们建设安全运维体系,先搞清楚面对哪一些安全事件,哪一些是多发的,我们才能有针对性的建设。


三、那些年救火的场景

安全应急响应的案例,我称之为救火。确实是救火,因为整天各种情况各种事情发生,当你的体系建立不那么完善的时候,你只能是靠人肉救火。


场景一:业务服务器每隔5秒连接中断


这是一个非常大的案例,导致两个机房二千多台服务器都弄走,因为每隔几秒钟全部中断,无法新建连接。当时我们排查的时候有几个方面,有可能是被攻击了。但当时我们的体系不完善,没有看到大流量的数据。其实其它的小包的攻击没有看到,没有办法证明也没有办法排除。我们把业务全部切换,切了机房,三个机房只用一个机房,另外两个机房停掉,爆发了这个事件。


表面现象就是连接不稳定,你的业务断断续续,一会儿可以支付,一会儿不可以支付,一会儿可以登录,一会儿不可以登录。这是脉冲攻击导致的,这是一种攻击方式,而不是漏洞所导致的,所以我们才敢把业务切回来。每五秒打一千万报文,打到 IOS 集群前面,一打就瘫痪,这是后面分析出的原因。当你的体系不完善,问题分析对我们很困难,几乎分析不出来,而且又不能重现。包量攻击而不是流量攻击,一般的初始阶段都可以看到攻击阶段,包量攻击不容易看到,当你的体系不完善的时候。


场景二:Nginx fork 队列阻塞等待超时


当你看到大量 Nginx 状态码都是错误的时候,客户端等不了。还有就是 Fork 队列堵塞,还有回包超时,这是信息攻击导致资源耗尽。每逢重大活动攻击现象很多。当年我们还没有自动化的对抗体系,用手工写脚本,每台服务器下发IP限速,当请求200业务活不下去,然后就限速150。手工的方式可以保证业务活下去,我相信我们会误伤很多的有效用户,因为活下去是唯一的目的。


场景三:运营活动礼物瞬间被“羊毛党”秒杀


我们的年度盛典给每个人可以发一个免费的门票,很多黑场刷免费的门票给主播送,这样省钱。我们刚放出一秒钟黑抢秒杀,上千万的年票就没了。因为你的礼物或者运营没有给到有效的自然人,而是给了机器人,这不是业务运营期望看到的。我们现在的安全体系可以解决这个问题,我们有用户的画像,指纹设备的画像,保证我的礼物或免费门票能够99%以上发给有效的自然人。


场景四:Struts2/Bash破壳/心脏流血又来一波0day,升不升级?


开源组件对我们安全运维体系是非常困扰的,因为我们不知道需要多少小时内才能全网升级完毕。如果有几万台服务器全网升级,这个风险很大,所以跟你们公司的网络环境有关系。腾讯和阿里有明确的网络边界,数据中心有两三个,YY分散在全国有一百个,网络边界没有那么明确。一百个对外的攻击面都需要升级,这对我们的挑战很大,安全运维团队需要迅速地评估影响和判断条件是否可以升级。


场景五:服务器发大量IP报文导致交换机流量异常


这个场景很多业务部门也经常会碰导,很多人会说机器怎么这么诡异,交换机说发大量的报文,但机器上没有,其实很多已经是被控制的入侵,甚至已经改了系统。我们看到的实际是被入侵后串改的数据结果。


场景六:有台服务器负载异常可以发现但是杀不掉。


我们看到有改了系统的 PS 命令,只要一 PS 那个进程就会拉起。你可以发现异常进程,但杀不掉,这有各种守护机制,这是很顽固的木马。


场景七:操作系统大量的会话状态跟踪表full


我们经常会遇到的,操作系统大量的会话状态跟踪表 full,业务影响严重,调整超系统参数会有效的缓解一点,但只是把攻击的门槛提升了一点。150块钱几十G的流量肯定扛不住,只是把门槛提高了一点,但还是有攻击的。这些场景是我们在YY安全运维中有遇到过的,不管你们有没有遇到,反正我们是遇到了。


四、YY安全运维的发展历程

接下来给大家介绍YY安全运维团队这几年从0-1的体系建设过程。2012年12月份开始,大家可以看一下这张图。


8da32eaf17e1613a7948204da1a8230abe38cc11

2012年底开始2013年初建设安全运维体系,开始上线的 WAF,互联网公司的防御,为什么自己写模块而不买外部的设备呢。传统的安全硬件可能对我们而言有一点瓶颈,因为它是单设备的。WAF 在全国有8-10个机房,我们需要看到分布式的效果,拦截的情况和攻击统计数据。单设备对我们解决不了问题,这是互联网公司自己开发的原因,这是2013年上线的 WAF,还是主机的漏洞扫描。原来很多的传统开展漏洞扫描,也可以去利用的,我们也是用了端口状态和应用识别,借用开源组件。前期实现了基本的漏洞,匿名登录等。

2014年上线了木马的自动分析和识别,因为几万台服务器如果手工地分析扫描不可能实现,而且互联网公司的版本迭代太快。差不多一天的发布进程需要上百次,每一个团队都去发布,如果不自动化地实现这些扫描和检测,基本是很难完成一项任务。我们2014年上线的安全应急响应门户,某种原因目前暂时没有办法用,所以现在只能依靠自己的应急响应门户,我们也建立了这个机制。但可能与 BAT 相比,还有很大的差距。

2015年上线了业务防刷,黑客很难刷到这些礼物。云防 DDOS 上线,利用的 DBDK 跟核心交换机的动态。

2016年上线了应用画像技术,包括对用户的画像,包括保护行为模式,支付行为和登录行为以及业务行为,加的好友个数和频率等等。因为特别频繁有可能是发广告的,那些机器人发广告都是频繁加好友。

还有你的IP画像,这个IP是不是开了代理?这个IP是不是云主机代理?这个IP是不是协议站伪造的?这个IP是不是开了网关的服务?是否在国外?历史上有没有对我们发生过攻击?安卓的设备是不是虚拟机?是不是开了调试?你的设备指纹是否跟别的指纹重复?设备指纹是否捆绑了一万个账号?这是设备的画像能识别出来的问题,可以有效的支撑业务上对你设备IP和用户的可疑行为判断。


我们2016年上线了大数据平台,可以支撑其它的业务。登录业务和运营的分析与结算支付,可以调用数据平台分析的结果。对互联网公司来说,网络安全主要是对抗 DDOS 攻击的,我之前也在传统公司待过。我一直在华为,但我认为互联网公司注重可用性会比完整性更加多一些。当然了不是说不重视机密性和完整性,网络安全主要对抗还是 DDOS。入侵的时候,也可以被及时的发现。


五、YY安全运维团队成果

1. YSRC 门户


我们建立了一个 YSRC 门户,专门用于收集漏洞等问题,我们已经跟老板争取了一些资源,希望老板能在日后放出更多给力的大奖,让我们门户能够好好运营好。我们一直在努力,希望可以争取更多的资源来奖励热爱YY的朋友们。


57a0ca59b08b0a6dfb0db81706cc306e7c0c3df3

2. YSEC_WAF简介


先来看看 WAF 技术框架,这个模块对所有的请求做过滤分析,如果发现异常会有两种,一种是挑战,比如挑战你一段代码,让你永远自动运行,可以判断你的一种行为方式。另一种是拦截限速,直接返回到412状态码,我们想不要挑战黑客,412还是标准的,但用的不多见。


d1e1662d24d89b0be85cf183173b3d721a75598f

保证业务快速迭代上线的时候,至少基本的安全功能还是可以得到防护。即使业务上没有什么过滤和校验,还是有基本的防护协议。Nginx 有过滤的规则,最后生成规则,返回到运行中。


62cb80b68e8422de196288f250ab542ce4f028e6

WAF 拦截之后的返回,原来没有界面,业务返回说如果没有界面,我们业务同学调试问题被拦截,我也不知道是谁拦截。后面做了状态码的返回和拦截界面,就是模仿外部拦截公司的做法,方便业务开发调试问题。这是 WAF 的实时拦截数据。安全体系的可视化,其实效果很大,作用也很大。之前很多对抗都是拦截了就算了,配置下发就算了,没有数据记录。


27a9447d05678381ce4a2e26f3b779dc34a04290

安全运维团队不容易,你做很多事情,上线很多攻击与防御,很多的业务无感知。当年可能天天被业务打瘫痪,还知道把安全团队抓过来弄一通,现在上线了很多的防御,用户感知攻击被你默默的拦截,怎么知道安全运维团队存在的价值?其实做个 WAF 展示是最好的,否则的话无感知,有效的流量被返回,攻击流量被拦截对业务很正常,不知道是一年没有发生,还是安全体系建设的完善了,需要把拦截的数据展示出来。这是WAF的拦截数据,这是 WAF 的数据统计,也方便我们自己研究一些规则。其实我们的规则统计没有贴出来,我们有1101、1102,每种规则的拦截效果都有分析。


3. 漏洞扫描架构


404d4205978e54d336043d74a929a4e8dc809b83

这是漏洞扫描的架构,后边有扫描集群,是在公司里面比较特殊的扫描集群。我们单独做一个扫描集群,原来存在的时候发现公司很多业务同学设置IP规则的时候把这个屏蔽了,我不占公司的流量。通过外部的通信协议,在端口应用状态的时候判断你的应用。你开了端口,有可能是公司其它的协议。


4. 入侵检测系统


6584977c320c784cc80e98eb776363d3d98a86f7

我们做了网络层和应用层漏洞的扫描。入侵检测主要是在这里,及时地预警会发到我们的 SOC 的后台,同时保存到数据库。漏洞扫描和入侵检测,主机对抗体系是这样的结果。我们实现的开发工作量不太大,几万台服务器从1端口扫描到最后,我们需要执行六七个小时,每天可以扫描一遍。及时把漏洞预警出来,你的哪一个业务模块和哪一个负责人出现了什么样的漏洞,重要的等级和漏洞类型,给研发的同学及时地修复问题。


5. 漏洞预警邮件通知


dc0f8b2ece329b4c226ba93b040e058141fac653

入侵检测,在一个时间发现了可疑的木马,模块的信息需要及时处理。这是漏洞邮件,以前漏洞预警邮件是很难看的,我们看了外部觉得产品化的公司做的很好,我们改了UI觉得效果好了很多,我认为包装很重要。内部系统的包装也是很重要的,看起来高大上很多。


6. 云防DDOS技术简介


98953faaaf250a3d3ec6e684a2b3ba9c59ac1c78

这是我们2015年上线云防 DDOS 的技术架构,中间是核心交换机。这是一个单机房的架构,这边有一个看防御能力,如果是在40G的,防御能力不是集群的,如果是 80G 的,防御能力的地方就是集群。核心的交换机会镜像或分光流量到这边,这边会根据流量来做分析进行报文或者流量模型做分析。如果发现攻击的话,会通过清洗集群跟核心交换机做动态 BGP 宣告路由。然后会把C服务器的流量牵引到这边,这边会把攻击流量干掉之后,把有效的流量再回注到核心交换机,核心交换机继续转发。


正常请求业务流量不受影响,这是行业内 DDOS 防御的基本架构,这对有效的未被攻击的业务没有影响。我们做过测试,这个分析过程是毫秒级的,对业务没有影响,这比直接引入黑洞有效很多。因为你引入黑洞,正常请求也被引入黑洞,这跟攻击没有什么区别。还是需要把正常的流量回注回来,攻击的流量干掉。我们实现的方式用了因特尔的 DBDK 方案,这会有数据处理,数据接入等。当时有两种方案,但我们选择了主流的 DBDK。单台三万块钱的服务器可以处理的能力在接近40G流量,二千万的报文量。


f533a7892f8c0cf5020a670fbb8f86a58acd3d34

这是云防 DDOS 实时清洗的效果,最右边是攻击类型。在这张表中会把攻击的时间和清洗的时间,流量峰值,清洗比例,以及分析清洗算法的有关部分。并以排名的方式展现出来。

六、懂得报告才会有好果子吃

大数据对安全体系相当重要,前期没有大数据可以做到80分,如果再往上提高的话大数据绝对是关键核心,可以把有效数据整合和业务数据整合,可以使得你的防御能力上升一个台阶。如果没有这个的话,只能是70分或者80分。


37a55dca720e029fd79e6ddb4c92002919fc07f5

今年我们也通过大数据发了YY的安全大数据报告,这是我们的数据。我们发数据报告,也是想让公司的老板能够看到,安全运维团队做的事情,可以把做的事情量化出来。如果没有这些的话,老板不知道安全运维团队做哪些事情,这是很有效果的,可以帮助做安全的或者说安全运维的团队争取后续的资源,这是帮兄弟们争取利益。


052eec79f4ea70eb8552ff0b0215eac67cef596b

我们发了大数据报告,主要就是给老板看的。我们清洗 400TB,人机大战22亿次。我们可以看到未来技术体系的优化方向可以朝着哪一个方向改进。


七、YY安全运维体系考虑的因素

安全运维体系建设需要考虑的因素,这是YY建设过程中的思考。


b2d1a3f550a36899b6a69d05272b035c2f5e33de

投入产出比


你需要投入什么,可以产出什么。在前期建设的时候,可能很多公司安全运维体系都是从0-1的建设,这个时候投入产出比非常关键。云防 DDOS 非常重要,但投入产出比可能前期没有那么高。因为投入很大,需要很多的团队来搞,你的开发团队也不少,所以一定要选择投入产出比优的点切入安全体系从0-1的建设。


关键矛盾


业务现在面临的关键矛盾是什么,如果天天被攻击,你跟老板说今年解决被入侵的问题,可以把漏洞及时发现,老板说天天被攻击,业务活不下去了你还解决这个?一定关注业务面临当前最主要的矛盾是什么,先把这个矛盾解决了。不至于让安全运维团队或者说安全团队站在风口浪尖上。 我们有一段时间曾经半年公司开会都是要点名的,就是因为在风口浪尖,天天这件事摆不平,关键矛盾一定要在前期建设前处理好,哪一些是当前面临的主要矛盾,要先解决掉。如果不能完全解决,至少也要降低风险或者说发生概率。


不一定追求100分


我发现很多搞技术的同学,尤其是我们现在很多的兄弟们非常希望做深入的研究工作,比如说我们之前想做一个静态的分析系统,但有些同事一定想做个动态的分析系统。投入的人力和时间都会很大。前期我觉得不一定做一百分,你可能做80分已经解决了很大的问题。


分阶段实施


不要想一件事一下子做的很完美。做到七八十分很容易,越往后投入的产出比越低。原来投入四五个人搞两三个月在某一些领域有突破,后面投入二三十人一年不一定有太大的提升。所以要把精力配置到容易有效的方式上进行。


数据化、可视化、自动化


安全团队做的事情可以量化,之前老板经常问你全年云防 DDOS、WAF 和漏洞扫描、入侵检测,你们做了哪一些事情,有什么数据?你防刷提供多少数据。我们运维团队的很多兄弟之前去数据库里面拿,还不一定可以分析出来,很难直观量化团队的绩效。有了数据化分析,这为你争取后面的利益有很大的帮助。可视化也是如此。包括我们的人机对抗,现在都是可视化的配置,能让一些业务参与进来,可视化的配置。原来还有改数据库和脚本,这增加了很多错误的机会。自动化,当你的机器数量或者业。务规模达到一定程度的时候,手工很困难完成出来的,自动化可以帮助你提升扫描效率或者说拦截的效率。


“安全”VS“业务”平衡之道


我们经常遇到跟业务PK。比如说,我们希望账号注册的时候,可能有一些绑定手机的问题,这样可以有效地降低黑场暴利注册的门槛。 业务说你绑定手机,我的注册用户每天降了很多,在不同的阶段还是可以做一些平衡的,可以牺牲安全的利益给业务让路,这是可以。安全可以做到什么程度,取决于业务发展到什么程度,日活有5万和日活有五百万,安全防御规模是不一样的。 把业务卡死了,你的安全还有发展吗。跟业务在不同的时期有平衡之道。


安全对抗体系路很长,我们也是处于这个阶段,依然是 ON THE  ROAD,后续我们会继续努力。


×

打开微信扫一扫,分享到朋友圈