李 深余 建

（1.中國電信股份有限公司福建分公司，福建 福州 350000；2.三明學院網(wǎng)絡中心，福建 三明 365004）

0 引言

21世紀的技術(shù)革命就是互通互連的應用，它們讓人們的點滴生活變得更加便利。云計算讓工作生活效率倍增，幫助人們網(wǎng)上購物、網(wǎng)上訂餐、車票預訂等，分享照片給朋友和家人，尋找新家附近的美食，跟蹤健身計劃的進展，大眾越來越受益于這些應用。騰訊、淘寶、京東、Facebook和Google等服務的增長速度表明，無論是在手機屏幕上還是在瀏覽器中，每個應用都為用戶帶來了巨大的價值。

這場革命的成功一部分要歸功于創(chuàng)建和運營這些應用的工具的進步?；ヂ?lián)網(wǎng)上的競爭日益激烈，用戶對創(chuàng)意的新鮮感很快就會消退，組織必須快速行動來占領(lǐng)市場份額，并鎖定其產(chǎn)品的用戶。在初創(chuàng)企業(yè)的世界里，取得成功的關(guān)鍵因素是創(chuàng)意融入產(chǎn)品的速度和成本。DevOps帶來了一場革命，通過互聯(lián)網(wǎng)世界里工具和技術(shù)的工業(yè)化，它讓低成本運營在線服務成為可能，這場革命讓小型初創(chuàng)企業(yè)也能夠和科技巨頭相互競爭，一爭高下。

在這場創(chuàng)業(yè)熱潮之中，數(shù)據(jù)安全有時候會受到損害。客戶已經(jīng)展示出了對應用的信任，并且愿意用他們的數(shù)據(jù)來換取功能，這導致大量的組織存儲了海量的用戶個人信息，而當這種局面形成之時，組織往往還沒有準備好能處理這些數(shù)據(jù)的安全策略。一個讓組織心存僥幸的激烈競爭格局再加上海量的敏感信息，這簡直就是孕育災難的完美“溫床”。因此，隨著在線服務數(shù)量的不斷增加，數(shù)據(jù)泄露也隨之出現(xiàn)得越來越頻繁。

1 De v Op s安全現(xiàn)狀

隨著云服務和云生態(tài)環(huán)境的興起，傳統(tǒng)的網(wǎng)絡運營已經(jīng)從提供和運行云基礎設施，轉(zhuǎn)移到了提供服務支持型的應用程序?，F(xiàn)在，隨著容器化環(huán)境技術(shù)的發(fā)展，安全團隊也在進行著類似的轉(zhuǎn)變，這是因為應用程序的安全已經(jīng)逐步進入了DevOps的領(lǐng)域。考慮到DevOps在構(gòu)建、測試和部署應用程序方面的專業(yè)知識和核心作用，大量的運營成員必須負責去保護這些應用程序以及基礎設施。雖然安全團隊仍然需要去制定一些安全策略并設置防護邊界，但DevOps將越來越多地去操作更適用于容器化應用程序的安全工具。

2 De v Op s中的安全

DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運維技術(shù)人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構(gòu)變更”的流程，來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。

DevOps可以代表許多不同的含義，這取決于它應用于信息技術(shù)（IT，Information Technology）領(lǐng)域的那個部分。運營核電站的基礎設施和在網(wǎng)站上處理信用卡的支付有很大的不同，但同樣都可以從DevOps中獲益，對運營進行優(yōu)化和加強。本文不可能涵蓋DevOps和IT的全部領(lǐng)域，因此重點著眼于云服務，這是一個專注于Web應用開發(fā)和運維的領(lǐng)域。對于運維保護和維護一個托管在云中的Web應用，可以輕易地將它們轉(zhuǎn)換到任何DevOps環(huán)境之中。DevOps教會使用者，行之有效的策略要求運維方和開發(fā)方結(jié)合得更為緊密，要開發(fā)人員和運維人員之間的各種溝通壁壘。同樣地，保障DevOps必須從安全團隊和他們的工程師伙伴之間的緊密協(xié)作開始。安全需要作為服務的一項功能提供給客戶，同時安全團隊和DevOps團隊的內(nèi)部目標必須保持一致。

當安全變成DevOps不可分割的一部分之后，安全工程師可以將安全控制直接內(nèi)建到產(chǎn)品之中，而不是在事后強加于產(chǎn)品之上。每個人都有著讓組織獲得成功的共同目標。只有目標達成一致，溝通才得到改善，數(shù)據(jù)安全得到提升。將安全引入Devops的核心思想中，讓安全團隊采用DevOps技術(shù)，將他們的注意力從僅僅保護基礎設施轉(zhuǎn)移到通過持續(xù)改進來保護整個組織的目標上來。在本研究中，筆者將這種方法稱為持續(xù)安全。

3 De v Op s的持續(xù)安全模型

持續(xù)安全由三個領(lǐng)域組成，圖1中已由三個帶編號的方框標出。每一個領(lǐng)域都聚焦于DevOps流水線的一個特定方面?？蛻舻姆答伌碳ち私M織的擴張，從而驅(qū)動出新的特性，這一過程也適用于持續(xù)安全。本文分為三個部分，每一部分分別覆蓋了持續(xù)安全的一個領(lǐng)域：

圖1 “持續(xù)安全”模型

（1）驅(qū)動安全（TDS，Test-Driven Security）。程序安全的第一步就是定義、實現(xiàn)并測試安全控制。TDS覆蓋了簡單的安全控制，比如Linux服務器的標準配置，還有Web應用必須實現(xiàn)的安全標頭。通過持續(xù)地實現(xiàn)基本的安全控制，并不斷地測試這些安全控制的準確性，可以獲得極大的安全感。在實施得不錯的DevOps中，人工測試應該是例外而不是規(guī)則。安全測試的處理方式和所有應用測試的處理方式一模一樣，自始至終都要自動化。

（2）監(jiān)控與應對。在線服務命中注定會受到威脅。當事件發(fā)生時，組織會向安全團隊求助，團隊必須準備好應對之策。持續(xù)安全的第2個階段就是監(jiān)控和應對風險，保護組織賴以生存的服務和數(shù)據(jù)。

（3）消除風險并完善安全性。網(wǎng)絡安全不只是技術(shù)，安全策略如果只是關(guān)注技術(shù)問題，則不能稱之為成功。持續(xù)安全的第3個階段將跳出技術(shù)范疇，在更高的層面觀察組織的安全形勢。

成熟的組織信任它們的安全程序，而且會和它們的安全團隊緊密協(xié)作。要做到這一點，組織需要專注、經(jīng)驗及良好的意識，即知道什么時候承擔風險及什么時候規(guī)避風險。全面的安全策略要結(jié)合技術(shù)和人員，識別出可以改進的方方面面，并且合理地分配資源，所有這些都發(fā)生在快速完成的改進周期中。

3.1 測試驅(qū)動安全

只用手機就能突破層層防火墻或是破解密碼，這樣的黑客神話只是電影大片里的噱頭，真實世界里鮮有這樣的事情發(fā)生。在大多數(shù)情況下，攻擊者會找安全防御較弱：有安全漏洞的Web框架、過時的系統(tǒng)、密碼容易被猜到且可以公開訪問的管理頁面，以及不小心泄露在開源代碼里的安全憑證，這些都是攻擊者喜歡的目標。實現(xiàn)持續(xù)安全策略的第一個目標就是守住底線：在組織的應用和基礎設施上使用基本的安全控制集并持續(xù)地進行測試。

安全團隊、開發(fā)人員及運維人員之間應該建立安全最佳實踐清單，以確保每個人都認同其價值。通過收集這些最佳實踐并加入一些常識，基線需求的列表很快就可以建立起來。

3.1.1 應用安全性

現(xiàn)代Web應用暴露在大量的攻擊之下。開放Web應用安全項目（OWASP，Open Web Application Security Project）發(fā)布了排名在前十名的最常見的攻擊手段：跨站腳本攻擊、SQL注入攻擊、跨站請求偽造、暴力攻擊，等等，數(shù)不勝數(shù)。幸運的是，每一種攻擊向量都可以通過在正確的地方使用正確的安全控制來化解。

3.1.2 基礎設施安全性

依靠laaS（Infrastructure as a Service）運行軟件并不能讓DevOps團隊高枕無憂，從而不用去關(guān)心基礎設施的安全性。所有系統(tǒng)都有對外授予更高權(quán)限的入口，比如VPN、SSH網(wǎng)關(guān)，或者管理面板。隨著一個企業(yè)的不斷擴張，在開放新的入口和集成更多模塊時，必須一直小心翼翼地保護好系統(tǒng)和網(wǎng)絡。

3.1.3 流水線安全性

DevOps交付產(chǎn)品的自動化方式和大多數(shù)安全團隊熟悉的傳統(tǒng)運維方式完全不同。破壞CI/CD流水線只會把運行在生產(chǎn)環(huán)境中的軟件的控制權(quán)拱手讓給攻擊者。在從代碼提交到生產(chǎn)環(huán)境部署的這個過程中，采用的自動化步驟可以使用提交簽名和容器簽名這樣的完整性控制來保護。

3.1.4 持續(xù)測試

在剛剛定義的三個領(lǐng)域中，對于任意一個領(lǐng)域中的應用來說，安全控制單獨實現(xiàn)起來都相當簡單。困難來自隨時隨地測試和實現(xiàn)它們。這就是TDS該發(fā)揮作用的時候了。TDS是一種類似測試驅(qū)動開發(fā)（TDD，Test-Driven Development）的方法。TDD建議開發(fā)人員先編寫表達期望行為的測試，然后再來編寫滿足測試的代碼；TDS建議先編寫表達期望狀態(tài)的安全測試，然后再實現(xiàn)讓測試通過的安全控制。

3.2 攻擊監(jiān)控安全與應對

現(xiàn)代組織十分復雜，要想用合理的成本覆蓋每一個角落基本上是不可能實現(xiàn)的。安全團隊必須權(quán)衡優(yōu)先級。日常的攻擊監(jiān)控與應對方法集中在日志和欺詐檢測、入侵檢測和事件響應三個方面。如果組織能做好這三項，那么就是做好了應對安全事件的準備。

3.2.1 日志和欺詐檢測

日志的生成、保存和分析在組織的每一個部分都發(fā)揮著作用。開發(fā)人員和運維人員需要日志來跟蹤服務的健康度。產(chǎn)品經(jīng)理使用它們來度量特性受歡迎的程度或是用戶留存率。對安全性來說，要關(guān)注檢測安全異常和在調(diào)查事件時提供取證能力兩個特定的日志需求。日志收集和分析達到理想化的要求幾乎是不可能的。海量的數(shù)據(jù)使存儲變得不切實際。

日志流水線是處理并集中來自各種日志源的日志事件。日志流水線十分強大，因為它提供了一條可以執(zhí)行異常檢測的單一管道。與每個組件自己執(zhí)行檢測相比，它的模型更簡單，但是它在大型環(huán)境中的實現(xiàn)可能比較困難。圖2概括了日志流水線的核心組件。

圖2 日志流水線分析

日志和流水線包含了：用于記錄來自基礎設施各個組件的日志事件的收集層；用于捕捉和路由日志事件的流式處理層；用于檢查日志內(nèi)容、檢測欺詐并告警的分析層；用于歸檔日志的存儲層。允許運維人員和開發(fā)人員訪問日志的訪問層。強大的日志流水線為安全團隊提供了監(jiān)控基礎設施所需的核心功能。

3.2.2 入侵檢測

入侵檢測在入侵基礎設施時，攻擊者通常會按照以下四個步驟執(zhí)行：

（1）在目標服務器上留下惡意載荷。惡意載荷是一種非常小的后門腳本或惡意軟件，小到可以被下載和執(zhí)行而不會引起注意。

（2）一旦部署，后門便會與母船建立聯(lián)系，通過命令與控制(CC，Commandand-Control)信道接收進一步指令。CC信道可以采用很多種形式，包括：出站IC連接，在正文中隱藏特殊關(guān)鍵字的HTML頁面，或者在TXT記錄中嵌入命令的DNS請求。

（3）后門執(zhí)行指令并在網(wǎng)絡中擴散，掃描并入侵其他主機直到發(fā)現(xiàn)有價值的目標。

（4）找到目標后，攻擊者勢必要盜取其中的數(shù)據(jù)，很可能是通過另一條和CC信道平行的信道來盜取這些數(shù)據(jù)。

對于網(wǎng)絡流量和系統(tǒng)事件，可以采用以下工具進行觀察和分析：

（1）入侵檢測系統(tǒng)（IDS，Intrusion Detection System）：圖3展示了IDS如何通過持續(xù)不斷地分析網(wǎng)絡流量副本，以及如何通過持續(xù)不斷地在網(wǎng)絡連接上應用可檢測欺詐活動的復雜邏輯，來檢測CC信道。IDS擅長對千兆字節(jié)的網(wǎng)絡流量中的欺詐活動模式進行實時檢查。

圖3 IDS流量檢測拓撲圖

（2）連接審計：分析經(jīng)過基礎設施的全部網(wǎng)絡流量有時是不現(xiàn)實的。NetFlow提供了另一種審計網(wǎng)絡連接的方式，它通過將連接信息記錄在流水線中的方式來進行審計。當無法訪問底層時，NetFlow是審計IaaS基礎設施中的網(wǎng)絡層活動的好方法。

（3）系統(tǒng)審計：對線上系統(tǒng)的完整性進行審計是跟蹤整個基礎設施中發(fā)生一切事情的絕佳方法。在Linux中，內(nèi)核的審計子系統(tǒng)可以記錄在系統(tǒng)中執(zhí)行的所有系統(tǒng)調(diào)用。攻擊者在入侵系統(tǒng)時常常會在這種類型的日志中留下蛛絲馬跡，將這些審計事件發(fā)給日志流水線可以幫助檢測到入侵。

入侵檢測難度很大，常常需要安全團隊和運維團隊的密切合作。如果操作不當，這些系統(tǒng)就會占用本該用于運營生產(chǎn)服務的資源。3.2.3 事件響應

在任何組織中，遇到的最緊張的情況或許就是處理安全事故了。即使是最強大的公司，安全事件給公司帶來的混亂和不確定性也可能嚴重破壞其健康運轉(zhuǎn)。在安全團隊手忙腳亂地恢復系統(tǒng)和應用的完整性時，領(lǐng)導層也必須做好止損，并確保業(yè)務能盡快恢復正常運營。

在應對安全事件時應該遵循的一套六階操作手冊。它們是：

（1）準備：確保有一套處理安全事件的最精簡流程；

（2）識別：迅速判斷異常是否是安全事件；

（3）隔離：阻止破壞進一步擴散；

（4）殺滅：消除對組織的威脅；

（5）恢復：恢復組織正常運營；

（6）總結(jié)：事后進行回顧并總結(jié)經(jīng)驗教訓。

4 De v Op s安全保障

完整的安全策略遠遠不是只涵蓋實現(xiàn)安全控制和事件響應等技術(shù)方面的因素，持續(xù)安全中的“人”的因素才是實施風險管理的關(guān)鍵。

4.1 評估風險

對許多工程師和管理人員來說，風險管理就是制作花花綠綠的超大電子表格，任由它們在收件箱里堆積如山。不幸的是，這種現(xiàn)象屢見不鮮，這導致許多組織放棄了風險管理。管理風險就是識別出威脅到生存和增長的問題，以及排列出它們的優(yōu)先級。電子表格中的花哨的單元格的確有用，但那并不是重點。好的風險管理必須達到以下三個目標：

（1）頻繁快速地以小迭代的方式運作。軟件和基礎設施會持續(xù)不斷的變化，一個組織必須能夠頻繁地討論風險，而不是陷進數(shù)周漫長的流程中；

（2）DevOps自動化，手動操作只是例外，而不是規(guī)則；

（3）組織里的每個人都要求參加風險討論，構(gòu)建安全的產(chǎn)品和維護安全是整個團隊的工作。

4.2 安全測試

成熟的安全程序的另一個核心強項是能夠通過安全測試定期評估自身的表現(xiàn)。通過測試策略如何在以下三個重要方面來幫助完善組織的安全性：

（1）使用漏洞掃描、模糊測試、靜態(tài)代碼分析或者配置審計等安全技術(shù)手段對應用和基礎設施的安全性進行內(nèi)部評估。筆者將討論多種可以集成到CI/CD流水線中的技術(shù)，它們將變成DevOps策略中軟件開發(fā)生命周期（SDLC，Software Development Lifecycle）的一部分；

（2）利用外部公司來審計核心服務的安全性。如果目標正確，安全審計會給組織帶來很多價值，并且利于用新的思路和視角審視安全程序。通過有效地使用外部審計和“紅軍”，讓它們充分發(fā)揮作用；

（3）建立漏洞報告獎勵程序。DevOps組織通常會積極擁抱開源并公開發(fā)布大量源代碼。對于獨立安全研究人員來說，這是巨大的資源，他們會測試應用，并報告他們在安全性上的發(fā)現(xiàn)以換取幾千美元的報酬。

完善一個持續(xù)安全程序需要好幾年的時間，但這些時間投入會讓安全團隊變成一個組織產(chǎn)品策略中不可或缺的一部分。通過跨團隊的緊密合作及對安全事件的妥善處理和技術(shù)指導，安全團隊將從他們的伙伴那里收獲保障客戶安全的信任。成功的持續(xù)安全策略的核心就是：將安全人員及其工具和知識盡可能地與DevOps中其他人拉近距離。

5 結(jié)語

要想真正保護客戶，安全性必須內(nèi)建到產(chǎn)品之中，必須和開發(fā)人員還有運維人員緊密合作。測試驅(qū)動安全，監(jiān)控與應對攻擊，以及完善安全性是推動組織實現(xiàn)持續(xù)安全策略的三個階段。傳統(tǒng)的安全技術(shù)，例如漏洞掃描、入侵檢測及日志監(jiān)控，都應該被重復利用并進行調(diào)整，以適應DevOps流水線。