DevSecOps 提升安全性的五種方式

對於我們是否需要擴展 DevOps 以確實提升安全性，我們一直都有爭議。畢竟，我們認為，DevOps 一直是一系列的新實踐的簡寫，使用新工具（通常是開源的）並且在這之上構建更多的協作文化。為什麼 DevBizOps 不能更好地滿足商業的需求？或者說 DevChatOps 強調的是更快更好的溝通？

然而，如 John Willis 在今年（LCTT 譯註：此處是 2018 年）的早些時候寫的關於他對 DevSecOps 術語的理解，「我希望，有一天我們能在任何地方都不再使用 DevSecOps 這個詞，安全會是所有關於服務交付的討論中理所應當的部分。在那一天到來前，在這一點上，我的一般性結論是，這個詞只是三個新的特性而已。更重要的是，我們作為一個產業，在信息安全方面並沒有做的很好，而這個名稱切實地區分出了問題的狀況。」

所以，為什麼我們在信息安全方面做的不好，在 DevSecOps 的語境下安全做的好又是什麼意思呢？

儘管（也可能是因為）龐大的複雜行業的單點產品解決了特定方面的問題，但我們可以說是從未做好過信息安全。我們仍然可以在這個時代把工作做得足夠好，以此來防範威脅，這些威脅主要集中在一個範圍內，網路的連接是受限的，而且大多數的用戶都是公司的員工，使用的是公司提供的設備。

這些年來，這些情況並沒有能準確地描述出大多數組織的真實現狀。但在現在這個時代，不止引入了 DevSecOps，也同時引入了新的應用架構模型、開發實踐，和越來越多的安全威脅，這些一起定義了一個需要更快迭代的新常態。與其說 DevSecOps 孤立地改變了安全，不如說信息安全公司在 2018 年需要新的方法。

請仔細思考下面這五個領域。

自動化

大量的自動化通常是 DevOps 的標誌，這部分是關於速度的，如果你要快速變化（並且不會造成破壞），你需要有可重複的過程，而且這個過程不需要太多的人工干預。實際上，自動化是 DevOps 最好的切入點之一，甚至是在仍然主要使用老式的 獨石應用 monolithic app 的組織里也是如此。使用像 Ansible 這樣易於使用的工具來自動化地處理相關的配置或者是測試，這是快速開始 DevOps 之路的常用方法。

DevSecOps 也不例外，在今天，安全已經變成了一個持續性的過程，而不是在應用的生命周期里進行不定期的檢查，甚至是每周、每月的檢查。當漏洞被廠商發現並修復的時候，這些修復能被快速地應用是很重要的，這樣對這些漏洞的利用程序很快就會被淘汰。

「左移」

在開發流程結束時，傳統的安全通常被視作一個守門人。檢查所有的部分確保沒有問題，然後這個應用程序就可以投入生產了。否則，就要再來一次。安全小組以說「不」而聞名。

因此，我們想的是，為什麼不把安全這個部分提到前面呢（在一個典型的從左到右的開發流程圖的「左邊」）？安全團隊仍然可以說「不」，但在開發的早期進行重構的影響要遠遠小於開發已經完成並且準備上線時進行重構的影響。

不過，我不喜歡「左移」這個詞，這意味著安全仍然是一個只不過提前進行的一次性工作。在應用程序的整個生命周期里，從供應鏈到開發，再到測試，直到上線部署，安全都需要進行大量的自動化處理。

管理依賴

我們在現代應用程序開發過程中看到的一個最大的改變，就是你通常不需要去編寫這個程序的大部分代碼。使用開源的函數庫和框架就是一個明顯的例子。而且你也可以從公共的雲服務商或其他來源那裡獲得額外的服務。在許多情況下，這些額外的代碼和服務比你給自己寫的要好得多。

因此，DevSecOps 需要你把重點放在你的軟體供應鏈上，你是從可信的來源那裡獲取你的軟體的嗎？這些軟體是最新的嗎？它們已經集成到了你為自己的代碼所使用的安全流程中了嗎？對於這些你能使用的代碼和 API 你有哪些策略？你為自己的產品代碼使用的組件是否有可用的商業支持？

沒有一套標準答案可以應對所有的情況。對於概念驗證和大規模的生產，它們可能會有所不同。但是，正如製造業長期存在的情況（DevSecOps 和製造業的發展方面有許多相似之處），供應鏈的可信是至關重要的。

可見性

關於貫穿應用程序整個生命周期里所有階段的自動化的需求，我已經談過很多了。這裡假設我們能看見每個階段里發生的情況。

有效的 DevSecOps 需要有效的檢測，以便於自動化程序知道要做什麼。這個檢測分了很多類別。一些長期的和高級別的指標能幫助我們了解整個 DevSecOps 流程是否工作良好。嚴重威脅級別的警報需要立刻有人進行處理（安全掃描系統已經關閉！）。有一些警報，比如掃描失敗，需要進行修復。我們記錄了許多參數的志以便事後進行分析（隨著時間的推移，哪些發生了改變？導致失敗的原因是什麼？）。

分散服務 vs 一體化解決方案

雖然 DevSecOps 實踐可以應用於多種類型的應用架構，但它們對小型且鬆散耦合的組件最有效，這些組件可以進行更新和復用，而且不會在應用程序的其他地方進行強制更改。在純凈版的形式里，這些組件可以是微服務或者函數，但是這個一般性原則適用於通過網路進行通信的鬆散耦合服務的任何地方。

這種方法確實帶來了一些新的安全挑戰，組件之間的交互可能會很複雜，總的攻擊面會更大，因為現在應用程序通過網路有了更多的切入點。

另一方面，這種類型的架構還意味著自動化的安全和監視可以更加精細地查看應用程序的組件，因為它們不再深埋在一個獨石應用程序之中。

不要過多地關注 DevSecOps 這個術語，但要提醒一下，安全正在不斷地演變，因為我們編寫和部署程序的方式也在不斷地演變。

via: https://opensource.com/article/18/9/devsecops-changes-security

作者：Gordon Haff 選題：lujun9972 譯者：hopefully2333 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive