受訪人 | 牛紀雷
采訪人 | 伍杏玲
出品 | CSDN（ID:CSDNnews）
在剛過去的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 工程師更換軌道到內心熱愛的安全工程師，從云計算技術的”小萌新“成長為云平臺安全總監。我們看到，個人興趣與職業愿景相融合后所迸發的能量，既忠于內心，又實現了自我價值，還和平臺共成長，成就一段讓人點贊的技術與技術人的成長故事。
未來，祝福東廠。
