如何把安全融入到DevOps當(dāng)中？
自2009年被首次提出以來(lái)，DevOps所涵蓋的內(nèi)容已經(jīng)發(fā)生過(guò)多次迭代，盡管不少企業(yè)堅(jiān)稱自己以DevOps為中心，但卻幾乎沒(méi)多少人能真正準(zhǔn)確理解其含義。沒(méi)有正確實(shí)踐作為前提，DevOps給團(tuán)隊(duì)及企業(yè)做帶來(lái)的價(jià)值也將無(wú)從談起。
在全面普及之后，DevOps能夠加快部署速度、降低故障率并增強(qiáng)恢復(fù)能力。而這一切都將幫助團(tuán)隊(duì)乃至企業(yè)打造出周期更短、適應(yīng)性更強(qiáng)、質(zhì)量更好的產(chǎn)品。但這也給我們提出了新的問(wèn)題——如何把安全考量融入進(jìn)去？
DevOps與DevSecOps有什么區(qū)別？
敏捷框架、一次構(gòu)建/隨處運(yùn)行的開發(fā)方法、一切即代碼、自動(dòng)化、溝通與協(xié)作，是DevOps的五大核心組件。而DevSecOps的重點(diǎn)，在于以符合安全要求的方式擴(kuò)展DevOps核心組件。通過(guò)拆分，我們能夠?qū)徱曉谀睦镞m合插入安全要素，從而實(shí)現(xiàn)軟件的安全性。
敏捷框架——敏捷方法是當(dāng)今軟件開發(fā)生命周期（SDLC）的主要內(nèi)容。與瀑布式開發(fā)方法相反，敏捷開發(fā)更強(qiáng)調(diào)短周期加小變化的組合，確保企業(yè)能夠針對(duì)客戶反饋?zhàn)龀隹焖俜磻?yīng)。敏捷框架在加快開發(fā)周期方面確實(shí)表現(xiàn)不錯(cuò)，但卻又常常受制于運(yùn)營(yíng)與安全要求。開發(fā)人員希望將運(yùn)營(yíng)與安全工作交給支持性工具負(fù)責(zé)，自己則專注于提升開發(fā)人員的行動(dòng)速度。
總而言之，敏捷框架在提升運(yùn)營(yíng)效率方面，取得了不錯(cuò)的效果；但其中的重點(diǎn)只有開發(fā)本身，一切運(yùn)營(yíng)與安全元素都成為事后才考慮的元素。
一次構(gòu)建、隨處運(yùn)行——容器技術(shù)讓SDLC更上一層樓。作為一項(xiàng)真正具有顛覆性的技術(shù)，容器使得開發(fā)人員能夠獨(dú)立于運(yùn)營(yíng)資源之外進(jìn)行編碼、構(gòu)建、運(yùn)行以及測(cè)試。如今，由于開發(fā)人員不必分神設(shè)置運(yùn)營(yíng)環(huán)境，他們可以將更多精力集中在測(cè)試、安全與擴(kuò)展方面。利用容器技術(shù)，一切都可由Dockerfile所容納并實(shí)現(xiàn)隨處運(yùn)行。在提交最終鏡像之前，開發(fā)人員根本不需要接觸運(yùn)營(yíng)工作；但在整個(gè)過(guò)程中，運(yùn)營(yíng)仍然始終存在、在不知不覺(jué)中為開發(fā)者提供支持。
雖然存在這種開發(fā)與運(yùn)營(yíng)之間的隔絕，容器本身仍然是一項(xiàng)重大成就，而容器的起效又離不開編排工具的引導(dǎo)，例如Kubernetes。Kubernetes使企業(yè)得以高效管理、擴(kuò)展、觀察并接入容器。它將Dockerfile的需求抽象為可以管理及擴(kuò)展的明確對(duì)象。這種聲明式抽象要求開發(fā)人員與運(yùn)營(yíng)人員開展溝通，進(jìn)而有效運(yùn)用Kubernetes。隨著時(shí)間推移，雙方的交流將逐漸升級(jí)、最終將安全問(wèn)題納入進(jìn)來(lái)。
自動(dòng)化——通過(guò)在不影響開發(fā)速度的情況下，向開發(fā)人員提供直接反饋，自動(dòng)化成為實(shí)現(xiàn)DevSecOps的關(guān)鍵所在。單元測(cè)試、代碼分析與鏡像掃描已經(jīng)成為可輕松被添加至持續(xù)集成（CI）管道的常見(jiàn)工具，即時(shí)向開發(fā)人員通報(bào)必要修改。在開發(fā)團(tuán)隊(duì)的協(xié)作下，這些變更可以快速被集成至現(xiàn)有管道當(dāng)中。運(yùn)營(yíng)與安全團(tuán)隊(duì)?wèi)?yīng)該明白，他們?cè)皆缣峁┳詣?dòng)化反饋機(jī)制，開發(fā)人員就能越早適應(yīng)這種新的協(xié)作模式。
借助新的工具與最佳實(shí)踐，安全團(tuán)隊(duì)可以為開發(fā)人員提供穩(wěn)定且安全的基礎(chǔ)鏡像，由此不斷提升代碼質(zhì)量。安全團(tuán)隊(duì)還可以在管道中引入自動(dòng)檢查機(jī)制，監(jiān)控一切包含權(quán)限提升行為的YAML文件、未匹配網(wǎng)絡(luò)策略的命名空間或者存在漏洞及風(fēng)險(xiǎn)的容器鏡像。
一切即代碼——Kubernetes及其他編程語(yǔ)言的聲明性質(zhì)，極大提高了基礎(chǔ)設(shè)施與應(yīng)用程序的可重用性與可理解性。YAML文件將幫助各團(tuán)隊(duì)準(zhǔn)確理解容器如何才能發(fā)揮預(yù)期作用。時(shí)鐘時(shí)間、卷掛載以及secret注入等一切行為都可通過(guò)這個(gè)文件及注釋進(jìn)行觀察。這種方法還讓代碼成功呈現(xiàn)為文檔的形式，以供隨時(shí)進(jìn)行版本控制并實(shí)現(xiàn)迭代變更。
但即使有了最新、最好的工具，如果無(wú)法正確記錄和編目具體問(wèn)題，一切努力仍然可能是徒勞的。沒(méi)有清晰的文檔，將很難跨團(tuán)隊(duì)分享經(jīng)驗(yàn)教訓(xùn)。而在嘗試新的管道配置時(shí)，各團(tuán)隊(duì)掌握的經(jīng)驗(yàn)教訓(xùn)很可能對(duì)其他團(tuán)隊(duì)有著決定性的指導(dǎo)作用。因此，請(qǐng)使用代碼與版本控制系統(tǒng)充分展示變更內(nèi)容，并允許各方據(jù)此開展討論。否則隨著單一團(tuán)隊(duì)的快速推進(jìn)，知識(shí)共享體系將土崩瓦解，各團(tuán)隊(duì)間再難開展充分交流。
溝通與協(xié)作——如果團(tuán)隊(duì)和個(gè)人間不進(jìn)行充分溝通，那么一切代碼、應(yīng)用程序與安全變更都將毫無(wú)意義。而IT部門中最常忽視的一大溝通要點(diǎn)，在于對(duì)意圖的明確解釋。
DevOps與DevSecOps之所以難以發(fā)揮其全部潛力，一大核心原因就是相關(guān)行動(dòng)的意圖往往未被各方正確理解。安全團(tuán)隊(duì)并不是要阻礙開發(fā)工作，他們只是在完成自己的本職工作并保證應(yīng)用程序安全。而開發(fā)團(tuán)隊(duì)雖然也關(guān)心安全性，但他們面前的頭號(hào)難題永遠(yuǎn)是如何在限期之內(nèi)讓新功能順利上線。
企業(yè)必須努力彌合各團(tuán)隊(duì)之間的差距，專注于吸取教訓(xùn)，鼓勵(lì)合理的嘗試失敗，并設(shè)定出切合實(shí)際的后續(xù)目標(biāo)。從文化角度來(lái)看，這種變化通常由高層自上而下推動(dòng)。在重視這種方法的企業(yè)當(dāng)中，開發(fā)、運(yùn)營(yíng)及安全團(tuán)隊(duì)會(huì)樂(lè)于討論哪些意圖較合理、哪些不合理，并愿意站在對(duì)方的立場(chǎng)上考慮問(wèn)題。
DevSecOps將向何處去？
總而言之，DevSecOps向我們提出了以下幾項(xiàng)重點(diǎn)要求：
• 要求在快速迭代的軟件開發(fā)生命周期中建立嵌入式自動(dòng)安全檢查機(jī)制
• 可重用的各開發(fā)環(huán)境間具有同類型的安全控制機(jī)制
• 版本控制CI管道
• 以組織或團(tuán)隊(duì)職能范圍為邊界進(jìn)行管道變更，借此改善事件后的安全調(diào)查流程
• 完善的說(shuō)明文檔，最好以聲明式方法實(shí)現(xiàn)安全即代碼
• 鼓勵(lì)創(chuàng)新，并接納由此帶來(lái)的失敗文化
DevSecOps代表的是一種文化變革，其背后代表的思維方式轉(zhuǎn)變不限于任何特定工具。當(dāng)然，大家也應(yīng)盡可能采用支持協(xié)作解決問(wèn)題的工具，包括保證其具有良好的可移植性、可觀察性并提供簡(jiǎn)單易懂的說(shuō)明文檔。最重要的，還有獲得團(tuán)隊(duì)的支配以建立起可跨團(tuán)隊(duì)共享的上下文素材。
結(jié)合種種成功案例與理論層面的巨大潛能，相信DevSecOps這波不斷發(fā)展的浪潮終將成為我們手中的有力武器。
