“安全即代碼”：整合安全團隊和DevOps團隊

随着雲計算開發和部署變得越來越快且越來越靈活，安全團隊意識到，保護雲應用和系統部署的唯一有效方法是開發可整合到部署管道的安全控制，以及盡可能自動化。安全社群很多人将這種方法稱為安全即代碼，這是采用基礎設施即代碼的概念，即将所有虛拟和基于雲的堆棧元件定義為可配置元素，這些元素隻是被視為一種軟體定義，并在在配置檔案和模闆中進行管理。

然而，很多安全團隊在采用這種方法時并不順利。大多數安全專業人士并沒有軟體開發背景，并且，他們通常與devops團隊脫節，devops團隊使用高度自動化和靈活的工具及流程來內建、測試和部署代碼到雲端。

重要的是要記住，大多數devops工程師和開發人員希望他們的部署盡可能安全，但他們需要安全性整合其環境，而不是部署障礙以及使用緩慢而笨重的工具和流程削弱可擴充性和速度。

為此，安全團隊應該開始學習devops環境中使用的devops工具，這通常包括jenkins、chef、puppet、salt、ansible、github等。安全團隊不需要精通所有這些devops工具，但需要注意以下幾點：

用于存儲和管理代碼的devops工具。例如，如果jenkins用于整合github。安全團隊将需要知道如何管理權限、當代碼簽入和推出時jenkins中可使用哪些日志。此外，源代碼掃描和審查應在這個級别進行內建，以確定代碼中不包含密碼或加密密鑰。

用于建立和管理伺服器配置及部署編排的工具。chef、puppet和ansible是很多環境中的常見選擇，它們都有自己的定義語音和不同的配置檔案。安全團隊需要整合配置設定和安全政策到這些平台内的定義檔案。

幸運的是，所有這些主要配置和自動化工具都有可用的配置模闆和政策評估模闆，并符合網際網路安全中心基準、美國國防資訊系統局技術部署指南和其他行業最佳做法和要求。

用于存儲和通路登入憑證和密鑰的devops工具。全面的devops做法會規定使用單獨的平台用于控制登入憑證和密鑰，例如hashicorp vault或ansible tower。監控和控制對這些平台的控制至關重要，安全團隊應該能夠獨立審查通路并發送日志到遠端日志記錄庫。

在建構系統進行部署時，安全團隊需要定義配置設定和政策，并将其內建到正在使用的工具中。通常情況下，這些定義将使用javascript object notation或者yaml格式進行編碼，這兩者都易于學習。

當伺服器和應用堆棧元素版本得到準許後，安全團隊應該部署無法變更的基礎設施，在下一個準許的修訂版本确定之前，任何更改嘗試都将被忽略。上述很多devops工具支援這種設定。例如，如果ansible手冊用于生成伺服器配置，再次運作該手冊将不會導緻任何其他更改或問題。

為了成功整合到開發和部署過程，安全團隊需要確定團隊成員大部分時間都在與devops團隊協同工具。這種方法(又是被稱為devsecops)可確定在代碼推送到生産或者任何系統在雲環境建構之前，所有變更和更新都将得到妥善保護。

然而，這個部署管道整合隻是整個流程的一半。安全團隊還需要為雲端運作的系統和應用提供自動回報，這将在之後的文章中進行讨論。

本文轉自d1net（轉載）