本文編譯自:Google Blog

資訊安全通常被視為“快速行動”或“保持安全”之間的零和遊戲。Google想挑戰這種思想流派，並引入一個框架，轉變為“雙贏遊戲”，使客戶可以同時做到“快速行動”與“保持安全”。

從歷史上看，應用程序安全工具的實施就像停車場的大門，停車場在入口和出口設有閘門，一次只允許一輛車通過，但是，一旦進入之後，幾乎沒有控制。可以訪問任何級別的任何空間，並輕鬆地在級別之間移動。

當將此應用在程序開發的應用上面時，AppSec 通常作為瀑布式原生工作流中的“收費站”。開發人員需要排隊，提交安全掃描，然後等待查看結果，當結果產生時，開發人員會花費大量時間和精力來調查安全引發的危險信號，這個過程很慢，而且在開發人員中不太受歡迎。這就是為什麼他們經常將傳統的安全程序視為創新的阻礙。

Google建議的工作流程不像停車場大門，更像是具有常識性安全措施的高速公路，高速公路對所有用戶都有指令規則，比如速度限制、單向行駛和退出時的強制減速區都有助於高速公路的安全性。一些高速公路根據這些規則實施預防措施，例如分隔相反交通流量的物理牆和保護性護欄，以減少碰撞並防止車輛偏離道路。雖然在高速公路上行駛有其自身的複雜性，但沒有吊桿式大門擋住去路。

遵循相同的指令規則，有檢測和響應控制，例如速度檢測器、攝影鏡頭、提醒駕駛員前進方向和行駛速度的標誌。將高速公路的經驗應用於雲端中的應用開發和合規性是更安全地建構軟體的最佳機會。

現代應用程序安全工具應該是完全自動化的，對開發人員來說基本上是不可見的，並最大限度地減少 DevOps 管道中的摩擦，為此，這些安全工具應該按照開發人員想要的方式工作。安全控制應儘早並無處不在地串連到開發生命週期中，這些控制軟體應該存在於開發人員的首選工具中，並創建快速反饋循環，以便可以盡快糾正錯誤。

典型的合規性週期如下所示：

在這裡，強調了期望狀態與實際狀態之間的差距，在審計時間到來時會出現問題，會增加審計的總體成本和生成控制證據所花費的時間。

相反，這正是我們所需要的。

我們需要實際狀態來持續追蹤期望的狀態。需要持續預防控制來阻止不安全的資源被引入。需要檢測來控制並及時、持續地發現不合規的資源，並透過響應控制來自動修復不合規的資源，換言之，我們需要持續符合安全的合規性。

我們如何開始維持安全的合規性？以下是開發此功能的參考架構。

該架構的中心是建立一個指令、預防、檢測和響應控制的閉環。同時也具有開放性與可擴展性。儘管本文中引用了 Google Cloud 架構，但你可以將它們應用於其他雲服務平台，甚至是地端的部署。

美國國家標準與技術研究院的開放式安全控制評估語言(OSCAL) 是一種有用的資源，可用於以機器可讀的格式表達控制庫。OSCAL 允許企業定義一組安全和隱私要求，這些要求表示為控制，然後組合在一起作為控制目錄。企業可以使用這些目錄，通過可以聚合和定制來自多個目錄的控制過程來建立安全和隱私控制基線。使用 OSCAL 配置文件模型來表達基線使得控制目錄和配置文件之間的映射顯示且機器可讀性。

閉環的起點是指令和協調控制。應該根據你所需遵守的合規性要求將控制映射合理化為技術控制。這些要求可能來自各種來源，例如所在行業的威脅形勢、內部安全策略和標準、外部法規遵從性以及行業最佳實踐框架。

控制映射將形成一個技術控制庫，此為一個資料庫，將協調控制映射到不同合規性框架中編寫的要求。控制映射證明了安全控制的合理性，它在安全性和合規性之間建立聯繫，並幫助企業降低合規性審計成本，這個資料庫應該是一個可不斷更新的文件。

建構資料庫的第一步是從CIS Google Cloud Platform Foundation Benchmark開始。該基準是輕量級的，它構成了任何實體都應該在 Google Cloud 上獲得正確的基礎安全性。此外，Security Command Center Premium的  Security Health Analytics可以幫助企業內所有項目的基準持續監控您的 Google Cloud 環境。

技術控制庫將指導閉環的其餘部分。對於每一個指令控制，你都應該有相應的預防控制來阻止不符合合規性的資源被部署。企業應該具有檢測控制來查看整個環境以尋找不合規的資源，並且應該有響應控制自動修復不合規資源或使用安全操作功能啟動響應工作流，最後，每個策略評估點都應該有一個反饋給工程師的循環。迅速而有意義的反饋循環可提供更好的工程體驗並在短期內提高開發速度，從長遠來看，這些反饋循環將孕育出良好的行為來編寫更好、更安全的代碼。

幾乎 Google Cloud 上的每個操作都是 API 調用，例如在創建、配置或刪除資源時，因此預防性控制都是關於 API 調用約束的。這些 API 調用有不同的包裝器，包括基礎架構即代碼 (IaC) 解決方案，例如Terraform或Google Cloud Deployment Manager、 Cloud Console、Cloud Shell SDK、Python 或 GO SDK。

與其他應用程序代碼部署一樣，IaC 解決方案應使用持續串接 (CI) 解決方案。在 CI 上，可以編排 IaC 約束，類似於為應用程序代碼編寫單元測試，由於所有 IaC 解決方案都可以轉換為 JSON 格式，因此可以使用開放策略代理(OPA) 作為 IaC 約束解決方案。OPA 的Rego策略語言具有聲明性和靈活性，允許企業在 Rego 中建構任何策略。

對於不是 IaC 的輸入源，可以退回到企業政策和 IAM，這兩個控件最接近 Google Cloud。也就是說，將非 IaC 輸入限制在更高的環境（例如生產環境或生產環境）被認為是最佳實踐，可以對基礎架構進行編碼，在源儲存庫中應用控制和工作流。

即使已經確定了預防控制，並且雲端環境是安全的，我們仍然需要檢測和響應控制。因為並非所有的控制措施都可以在現實世界中作為預防性控制措施安全地實施，例如，如果這些虛擬機具有外部 IP 地址，我們可能不會在 CI 上的所有 Google Compute Engine 部署都失敗，因為特定軟體或案例可能需要外部 IP 地址。另一個原因是我們希望為審計目的生成帶有時間軸的安全合規狀態。以 CIS 合規性為例，我們可以對 CI 強制執行所有 CIS 檢查，並將 IaC 設置為雲端基礎架構的唯一部署源。

但是，我們仍然需要使用 Security Command Center 演示 CIS 合規性報告。安全響應控制不限於補救措施，還可以通過電子郵件、消息傳遞工具或與 ITSM 系統集成的形式採取通知的形式。如果使用 Terraform 部署基礎設施並使用 Cloud Function 進行自動修復，則需要注意 Terraform 狀態。由於 Cloud Function 執行的自動修復操作未記錄在 Terraform 狀態文件中，因此您需要通知工程師更新源 Terraform 代碼。

圍繞安全性和合規性的手動流程無法擴展這一事實表明自動化是下一個推動因素。自動化的經濟學需要系統性的紀律和整體的企業範圍方法來進行法規遵從和雲端風險管理。

通過定義合規性流程的數據模型，上述 OSCAL 代表了風險管理和監管合規自動化的遊戲規則改變者。雖然我們意識到採用“代碼化”實踐，對大多數客戶來說是一項長期投資，但風險與合規性代碼化 (RCaC) 有許多建構模組可以幫助您入門。通過採用 RCaC 原則，可以轉向編碼策略和基礎架構，以實現安全的雲端轉型。