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