云栖号：https://www.aliyun.com/#module-yedOfott8
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！
在刚过去的2019双11中，天猫全天成交额再创新高，达2684亿。在全球人民买买买之际，阿里云安全一直为大家保驾护航：
云平台自动识别并拦截来自184个国家的60亿次攻击；为天猫、淘宝等多个平台应用拦截来自17种不同方式的473万次攻击、2.9万个恶意攻击IP；成功防御1917次DDoS攻击，峰值223Gbps。
在这背后，阿里云使用了哪些黑科技？在今年的双11，阿里所有的核心业务上云，这对云安全是个巨大的挑战，工程师们是如何准备这场硬战的？
带着这些问题，CSDN（ID：CSDNnews）专访阿里云云平台安全总监，云产品安全负责人牛纪雷（花名：东厂），揭秘阿里云安全的那些事儿。
始于兴趣，陷于安全，忠于内心
东厂入安全的“坑”可追溯到高中时期。
自2001年的中美黑客大战后，国内涌现许多像绿色兵团、安全焦点等的安全组织。高中生的东厂感觉“很酷很炫”，在心里埋下对安全技术的种子。
2002年，高考后的东厂想学计算机专业。可他没考上该专业，无奈只好去了个相关的专业——物理系电子信息专业。
与计算机失之交臂的东厂，在读大学期间仍念念不忘安全技术，自己“瞎捣鼓”攻防技术，并在网上认识志同道合的技术人。
2004年左右，新兴的Web安全出现，东厂和几个小伙伴共同成立了一个安全组织——Bug Center Team，专门来研究Web的攻击技术。
由于当时国内互联网公司的大环境，这项安全技术还未引起大家的重视，所以东厂在业余捣鼓捣鼓还好，等真正毕业时，还是和其他人一样，没有直接选这条路，而是选择热门的Java开发。
很快，东厂发现自己还是对安全很感兴趣，兜兜转转踏上安全工程师之路。
自2014年入职阿里，如今的东厂俨然成为安全领域的“老司机”。目前他负责阿里云网站上所有的云产品的安全。
谈到“东厂”这花名的来历，东厂说，老阿里人喜欢把位于杭州城西的西溪园区叫“西厂”；位于相对西溪的城东的支付宝，叫“东厂”；相对比较“内”的阿里起源地滨江园区，叫“大内”；北京分公司叫“北厂”。
比东厂入职早的好哥们，取名“西厂”，东厂一时兴起，便取了“东厂”做花名。“后来在别人的提醒下去查了下，原来东厂在明朝还是一个非常特殊的机构。”东厂笑谈往事。
在入职阿里之前，东厂接触的是Web安全，对于云计算技术，刚开始是“云里雾里”的。经过一段时间的摸索后，慢慢地摸到一些门路。
早在2014年，阿里云业务刚刚有了起色，安全技术产品化尚属于初级阶段。
经过五年时间，东厂从对云计算一窍不通的“小萌新”，成长为独当一面的阿里云云平台安全总监，肩负起今年双11阿里所有核心业务上云的安全工作；从较为初期阶段，发展为如今抗住60亿次攻击的云平台，这是一个技术人与技术共成长的故事。
在这期间，东厂与云平台安全发展可分为三个阶段：
1、初期成长——救火阶段；
2、破局突围——数字化转型阶段；
3、稳定向前——化被动为主动。
这期间又有什么技术人精（填）彩（坑）的故事？且听东厂娓娓道来——
救火阶段：外忧内患，倒逼技术提升
2014年的云计算技术涉及的虚拟化技术，主要分为两类，一是计算虚拟化，二是网络虚拟化。
说实在，刚起步的阿里云对这两项技术掌握得不是很好，因为在虚拟化有比较的指标，即虚拟化带来的延迟损耗大概有多少？
当时阿里云ECS使用的虚拟化技术是XEN，它在虚拟化上带来的损耗在今天看来相对较大的。而在网络上，采用的是大二层网络技术，这是基于传统网络来的，可能会存在一个问题：传统网络由于是一个网络平面下的，如果网络隔离做得有问题，可能会导致租户之间能看到其他租户的资源。
对于阿里云来说，资源隔离是非常重要，必须确保云上不同的租户之间不能有资源的抢占。并且如果隔离做得不好，还会导致数据泄露。
且在2015年，东厂他们发现虚拟化组件XEN一个非常严重的安全漏洞，通过漏洞，可通过一个租户去窃取到另一个租户的信息。所以从技术上来说，XEN的安全性存在一定问题。
除此之外，阿里自研的飞天操作系统也遇到一个棘手的问题，如何解决不同的租户通过脚本来执行自定义函数需求且不会互相影响，这中间均涉及到安全性。
初期的云拥有众多问题，尚“云里雾里”的东厂不免承受巨大的压力。
遇到问题他只能先冲过去，将当前的事情处理掉。所以他将这个阶段称为“救火”。
除了解决内部遇到的各种安全挑战，一些白帽子发现安全漏洞后还会上传至当年知名的漏洞平台乌云网。
“外忧内患”下，刚入职的东厂被授予重任——“救火队队长”。
如今他回忆当时危机的情况，说：“当时也没有很好的办法，只能先扑人上去，先把这个火给灭了，解决当前一个个严重的风险”。
后来，东厂带领着团队，说是团队，当时也就三四个人，做好 “心理建设”后，坚定的“开干”，慢慢地竟将云平台的安全体系建立起来，通过系统化的技术一一将上述问题化解，并研发出新的安全工具。
例如在传统的IT系统里，系统漏洞补丁生效需要操作系统重启生效，但在云上是不能这么做的，如果物理机系统重启，将导致用户业务全挂了，无法使用。于是东厂他们和研发团队一起研究出新的虚拟化热补丁技术，无需用户的虚拟机重启，采用此技术就可将虚拟化系统的漏洞修复掉。
平台安全的“数字化”转型
此处的“数字化”与现在大家说的数字化不太一样，在实际工作中，安全工程师的工作不太好去量化和说明其价值。安全工作其实是0和1的问题，如果工作做得好的话，大伙基本是感知不到的，但要是出问题了，都会发现其安全工作没做到位。
所以安全工程师需要寻找一个数字来证明自己今天的工作做的好还是不好。这便是云平台的“数字化”转型之路。这里面包含两个目标：
一是控制安全事件的“0”和“1”；二是量化安全工程师的工作。
对于第一目标，前期以乌云网为标准，对安全团队提出乌云网零漏洞上报的要求。后期成立阿里云的安全应急响应中心，通过这个平台来收集白帽子上报的漏洞，并通过平台收集到的漏洞数量降低，来量化安全工程师的工作成效。
这样便和第二个目标关联起来：应急响应中心外报的阿里云漏洞下降50%。
可随着业务的增长，假如只用百分比做为衡量值的话，假如原来100个业务外包，可能有50个漏洞，假如业务扩大10倍呢？是否分子也在增加？那么尽管最终保持50%这个值，对于安全工程师来说，50%也是无法接受的。
所以东厂他们重新制定新的量化目标：“双0”，第一个是零外部安全漏洞导致的安全事件，第二个是零外报高危安全漏洞。
如此一来，将应急中心的50%外报漏洞率作为过程指标，把双0作为终极的目标，这两个目标共同衡量安全工程师的工作。
当目标确定好后，便开始执行。
由于阿里云在SDL上已有非常多的实践经验，借助这些积累，最近已连续达成了第一个的外报漏洞下降50%的目标。
可后来乌云网维修官网，加上响应中心的漏洞越报越少，东厂他们又面临一个新问题：如何重新寻找新的目标来衡量工作呢？
于是先知·安全众测平台诞生，阿里云邀请白帽子来做安全测试，确认漏洞后24小时内发放奖金。
不仅这样，阿里云也会定期邀请国内外不同的专业安全团队，对阿里云平台进行真实的攻击测试，以帮我们发现问题。
另外在2019 Real World CTF国际网络安全大赛上，阿里云首次开放真实的线上运行环境，提供ECS、RDS for MySQL、MaxCompute三款云上核心产品，公开给选手挑战，并提供500万奖金池。
除了技术上的转型，“数字化”转型还涉及安全人员自身能力的“转型”。
在安全团队里，日常很多繁琐、重复的工作，于是制定“重复的事情只做一遍”的目标，逼着大家去想办法来提升工作的效率，于是自动化运营平台诞生。
原本当安全工程师发现一异常后，需对其做排查和分析，通过相关的信息去查IP、查日志、分析问题。
如今有了自动化平台，这些重复性的工作可以做成标准化，封装成一个函数方法，当异常来了，平台将自动执行这个方法，返回结果，再执行下一步的动作。这个过程的动作如何安排，是通过逻辑编排的。从日志到监控，最快仅需5分钟便可分析出结果。
据东厂介绍，自去年接入该自动化平台后，大约提升了他们团队50%的工作效率，也就是说原来可能两个人干的活，现在一个人就能搞定。
被动转为主动，“一票否决权”
度过兵荒马乱的“救火期”，在曲折中上升的“转型期”，如今来到稳定期的东厂安全团队，还想“搞事情”，这次安全团队要对开发、运维团队“下狠手”？！
平常安全工程师的工作基本上属于“事件驱动”，即事情发生后，安全同学处理下，然后基于此次事件，制定流程、控制风险，这样会导致研发、运维团队可能不了解实际情况，在执行流程时难免有质疑的地方：为什么要让我做这件事？
另外，在和研发团队协同的过程中可能会有这样的问题：研发人员设计的代码，如果安全工程师不了解的话，很容易会被质疑与挑战。所以在团队间沟通时，需要注意：
1、安全团队和技术团队之间的平等对话。
安全说到底的话是稳定性的问题，如果因为安全问题导致产品稳定性出现风险，此时研发人员是能接受的，但如果仅是说这里可能会有安全问题，导致数据安全泄露，这会被研发人员质疑的，毕竟很多安全的风险仅是潜在的风险。
2、在和研发人员聊技术时，安全人员先做好功课。
因为安全团队要和技术团队要合作，让他们帮你解决安全问题，需要获得这些技术团队的更深层次的信任。通过和研发人员聊技术，则是获得信任的好办法之一。
有一个事件让东厂印象深刻：研发团队某产品出故障后，开发工程师研究了一天还没找到故障的原因。东厂安排一安全工程师去帮忙看问题，通过与研发人员不同的安全思维和方法，一个小时内，安全人员定位到了原因，故障快速消除。
“随着类似的事情越来越多后，技术团队对我们的信任也越来越强，他们知道我们不单单是能解决安全的问题，还能解决稳定性上的问题。”东厂说。
另外，东厂也在不断地争取安全团队的“话事权”。
阿里云内部有个商业化小组，这小组里有各个领域的专家来控制产品是否能上线。例如法务认为一产品有法律上的风险，该产品不允许上线。
东厂在该产品小组里旁听了整整一年后，对阿里云官网上所有的产品了如指掌后，帮安全团队拿到“一票否决权”，这意味着“安全”对产品是否能上线，亦是关键的指标。
云平台三大技术架构
谈到云平台的安全技术架构，东厂表示可以分为三部分：
1、SPLC云产品安全生命周期。
当研发人员需要发布上线时，在此系统会自动执行，来检查其是否做研发的安全培训，经过SPLC的审核，确保每一个云产品的发布都“默认安全”。
还可以和DevOps相结合，共同形成流程来对研发做安全培训。在这里面，我们会强制要求所有的代码上线之前，要经过安全工程师的Review。
2、基于大数据技术，打造实时威胁检测平台。
随着客户数量增多，对安全的需求也增多，在线下，安全工程师在产品发布前会提前进行排查和处理。在线上，通过自动化扫描工具，来监控和发现产品的安全问题。比如检测服务器的安全情况，收日志做分析。
如今每天要处理的日志量大概是P级别，如果没有大数据的计算能力，光靠安全工程师是没有办法一一分析的。通过大数据、算法、AI等技术，可分析大量日志和处理。该平台上，有100多种相对安全的认知，几百个安全检测模型，如果遇到问题会即时通报。
3、数据安全体系。
由于阿里云服务数百万客户，为了保障客户数据安全，形成了从传输加密、存储加密到计算加密的全链路数据加密体系以及内部一套严格的数据安全审计机制。
九个月准备双11 鏖战
2014年入职的东厂，已经历了6个双11。而今年的双11“战役”，是东厂备战最长的。
在今年3月份，阿里决定将天猫双11核心业务100%跑在阿里云上之际，东厂就带领团队开始推进相关的安全工作了。
因为对于安全来说，压力挺大的。于是东厂从三月份跟进以来，将核心系统上云的安全方案做了非常详细的规划，将双11的核心业务可能会遇到的问题、风险预估全部梳理清楚。
11月10号，安全方案整体的验收全部通过。双11作战室有一个大屏幕，能实时展示当前阿里双11业务安全的运行情况，当东厂看到大屏上的数字，确定已经没问题后，才觉得今年双11才准备妥当。
从10号下午一直到11号晚上，安全团队全程严阵以待。当晚天猫交易额锁定到2684亿时，东厂一直悬着的心总算放下来了，“今年的双11终于挺过去了。”
在今年双11，阿里云扛住60亿次的攻击。这背后，离不开研发团队自研的IPS（入侵检测系统）。IPS像一把保护伞，将所有针对阿里的攻击检测出来，从而进行抵御。
未来
谈及未来，东厂表示，云安全的技术布局有：
1、云原生技术上会做一些研究，比如Docker；
2、零信任，随着网络越来越复杂，对于网络的零信任也会做投入；
3、数据安全领域，阿里在数据安全领域拥有好多年的实践，撰写出DSMM《数据安全能力成熟度模型》，并推动其成为国家标准。现在的话在云上也推出了数据安全保护的相关产品，大概会在这几个方向。
东厂一直负责阿里云安全团队的校招工作，每年面试不少同学，在这个过程中他发现一个有趣的地方，对安全感兴趣的同学和不感兴趣的人是不太一样的。如果对安全有兴趣的人，不妨沉下心来研究安全技术。
因面试时一是考核候选人的基础是否扎实，二是查看候选人的操作能力。所以东厂建议在校先将安全理论知识学好，多多参加相关技术比赛，进行一些技术实践来启发自己的能力，有助于往后找工作。
这一路，东厂从 Java 工程师更换轨道到内心热爱的安全工程师，从云计算技术的”小萌新“成长为云平台安全总监。我们看到，个人兴趣与职业愿景相融合后所迸发的能量，既忠于内心，又实现了自我价值，还和平台共成长，成就一段让人点赞的技术与技术人的成长故事。
未来，祝福东厂。
云栖号：https://www.aliyun.com/#module-yedOfott8
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！
原文发布时间：2019-12-30
本文作者：伍杏玲
本文来自阿里云云栖号合作伙伴“CSDN”，了解相关信息可以关注“CSDN”
