DevOps與DevSecOps有何區(qū)別？

DevOps、DevSecOps、左移、安全態(tài)勢、云原生……說起現(xiàn)代應(yīng)用程序的開發(fā)生命周期，大家總會聽到上面這些詞。它們作為解釋復(fù)雜流程的框架時，作用積極，誤用或濫用則反而有害。無論是刻意為之還是無意間的誤用，用戶在面對這些流行詞時往往都無法準(zhǔn)確理解其背后代表的真正含義。

DevOps與DevSecOps就是濫用與誤用之下造成不少負(fù)面影響的典型案例。自2009年被首次提出以來，DevOps所涵蓋的內(nèi)容已經(jīng)發(fā)生過多次迭代，其中的負(fù)面含義往往源自交流背景中種種不切實際的烏托邦元素、以及難以真正落地的理想假設(shè)。盡管不少組織堅稱自己以DevOps為中心，但卻幾乎沒多少人能真正準(zhǔn)確地做出定義。沒有正確實踐作為前提，DevOps向團(tuán)隊及企業(yè)做出的承諾也將無從談起。

DEVOPS與DEVSECOPS之間有何區(qū)別?

DevOps的實現(xiàn)依賴于五大核心組件： 敏捷框架、 一次構(gòu)建/隨處運行的開發(fā)方法、一切即代碼、自動化、溝通與協(xié)作。

在全面普及之后，DevOps能夠加快部署速度、降低故障率并增強恢復(fù)能力。而這一切都將幫助團(tuán)隊乃至企業(yè)打造出周期更短、適應(yīng)性更強、質(zhì)量更好的產(chǎn)品。但這也給我們提出了新的問題——如何把安全考量融入進(jìn)去?DevSecOps的重點，正在于以符合安全要求的方式擴展DevOps核心原則。

理解DevSecOps的一種重要方法，在于拆分DevOps核心組件并審視適合在哪里插入安全要素。

(1) 敏捷框架——敏捷方法仍然是當(dāng)今軟件開發(fā)生命周期(SDLC)的主要內(nèi)容。與瀑布式開發(fā)方法相反，敏捷開發(fā)更強調(diào)短周期加小變化的組合，確保組織能夠針對客戶反饋做出快速反應(yīng)。

然而，敏捷框架面臨著安全隱患。運營反饋從何而來?是否符合安全要求?這類框架在加快開發(fā)周期方面確實表現(xiàn)不錯，但卻又常常受制于運營與安全要求。開發(fā)人員希望將運營與安全工作交給支持性工具負(fù)責(zé)，自己則快速行動、一路奮勇向前。

總而言之，敏捷專注于提升開發(fā)人員的行動速度，也取得了不錯的效果;但其中的重點只有開發(fā)本身，一切運營與安全元素都成為事后才考慮的元素。

(2) 一次構(gòu)建、隨處運行——容器技術(shù)讓SDLC更上一層樓。作為一項真正具有顛覆性的技術(shù)，容器使得開發(fā)人員能夠獨立于運營資源之外進(jìn)行編碼、構(gòu)建、運行以及測試。如今，由于開發(fā)人員不必分神設(shè)置運營環(huán)境，他們可以將更多精力集中在測試、安全與擴展方面。利用容器技術(shù)，一切都可由Dockerfile所容納并實現(xiàn)隨處運行。在提交最終鏡像之前，開發(fā)人員根本不需要接觸運營工作;但在整個過程中，運營仍然始終存在、在不知不覺中為開發(fā)者提供支持。

雖然存在這種開發(fā)與運營之間的隔絕，容器本身仍然是一項重大成就，而容器的起效又離不開編排工具的引導(dǎo)。

到這里，我們要請出下一位重量級嘉賓——Kubernetes。

Kubernetes使組織得以高效管理、擴展、觀察并接入容器。它將Dockerfile的需求抽象為可以管理及擴展的明確對象。這種聲明式抽象要求開發(fā)人員與運營人員開展溝通，進(jìn)而有效運用Kubernetes。隨著時間推移，雙方的交流將逐漸升級、最終將安全問題納入進(jìn)來。

(3) 自動化——那么，安全或者運營團(tuán)隊又該如何要求、或者說約束開發(fā)人員?

通過在不影響開發(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)該明白，他們越早提供自動化反饋機制，開發(fā)人員就能越早適應(yīng)這種新的協(xié)作模式。

這一點對安全團(tuán)隊來說極為重要。在組織當(dāng)中，安全團(tuán)隊往往被視為一種“令人心煩”的存在，因為這幫家伙總在強調(diào)根本不可能實現(xiàn)的所謂“100%安全系統(tǒng)”。但行之有效的DevSecOps可不是這么簡單粗暴。

借助新的工具與好實踐，安全團(tuán)隊可以為開發(fā)人員提供穩(wěn)定且安全的基礎(chǔ)鏡像，由此不斷提升代碼質(zhì)量。安全團(tuán)隊還可以在管道中引入自動檢查機制，監(jiān)控一切包含權(quán)限提升行為的YAML文件、未匹配網(wǎng)絡(luò)策略的命名空間或者存在漏洞及風(fēng)險的容器鏡像。

(4) 一切即代碼——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)隊間再難開展充分交流。

(5) 溝通與協(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)讓新功能順利上線。

組織必須努力彌合各團(tuán)隊之間的差距，專注于吸取教訓(xùn)，鼓勵合理的嘗試失敗，并設(shè)定出切合實際的后續(xù)目標(biāo)。從文化角度來看，這種變化通常由高層自上而下推動。在重視這種方法的組織當(dāng)中，開發(fā)、運營及安全團(tuán)隊會樂于討論哪些意圖較合理、哪些不合理，并愿意站在對方的立場上考慮問題。

DEVSECOPS將向何處去?

總而言之，DevSecOps向我們提出了以下幾項重點要求：

要求在快速迭代的軟件開發(fā)生命周期中建立嵌入式自動安全檢查機制

可重用的各開發(fā)環(huán)境間具有同類型的安全控制機制

版本控制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ā)展的浪潮終將成為我們手中的有力武器。

文章題目：DevOps與DevSecOps有何區(qū)別？
文章轉(zhuǎn)載：http://www.muchs.cn/news38/203338.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、App設(shè)計、響應(yīng)式網(wǎng)站、電子商務(wù)、靜態(tài)網(wǎng)站、建站公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)