安全即代碼：保護云應用程序和系統的最佳（也許唯一）途徑

正文

    管理安全即代碼，使公司能夠在云中安全地創造價值。

    隨著公司采用公有云平臺，現有的網絡安全架構和運營模式已經崩潰。為什么？因為云里面幾乎所有的泄露都來自于錯誤配置，而不是來自攻擊、入侵底層的云基礎設施。

    因此，云要求應用程序和系統的安全配置。但傳統的網絡安全機制，沒有設計成保證安全配置、或像商業領袖期望的那樣，利用敏捷和速度的優點來運營。如果公司想要得到云的價值，他們必須采用新的安全架構和流程，來保護他們的云負載。相比傳統的本地模式，云遷移不僅能增加業務價值的交付，而且能提高系統和應用的安全。

    安全即代碼（Security as code，SaC）是保護云負載最有效的方法，實現速度和敏捷。在這一點上，大多數云領先者認可基礎設施即代碼（infrastructure as code，IaC）允許他們在云中自動化構建系統，消除手動配置容易引起的故障。SaC走得更遠，以編程的方式定義網絡策略和標準，在提供云系統的配置腳本中被自動引用，在云中運行的系統可以和安全策略對比，防止“漂移”（見圖1）。例如，如果業務設置了一個策略，所有個人身份信息（personally identifiable information，PII）在存儲時必須加密，這個策略被轉換成一個過程，當開發人員提交代碼時會自動啟動，違反PII策略的代碼自動被拒絕。

    為了獲取云里面的價值，要求大多數公司打造一個轉換引擎（圖2）把云集成到業務和技術中，推動在重要業務領域內優先采用，建立能夠安全和經濟地擴展云使用的基礎能力。SaC是在云安全和風險管理中發展基礎能力的機制。

    理論上SaC能在公司自己的數據中心內實施，但云服務商（CSP）提供的自動化能力，使它在云中更具有實際意義。

SaC三個最大的好處

    第一個好處是速度。為了充分認識到云的業務收益，安全團隊必須以他們在本地環境中不習慣的速度移動。人工干預會引入摩擦、拖慢開發、損害了云對業務的整體價值主張。

    第二個好處是減少風險。本地的安全控制無法考慮云的細微差別。云安全要求在整個生命周期內，控制隨著工作負載移動。實現這種級別的嵌入式安全的唯一方法是通過SaC。

    最后，SaC是業務的推動者。安全和合規要求日益變成業務產品和服務的核心。在這方面，SaC不僅僅加快上市時間，還在不降低安全的情況下，擴展創新和產品創意的機會。

實現SaC的方法

    實施SaC對所有公司都要求策略、架構和文化的明顯改變。出于這個原因，許多人發現根據敏感性和重要性，使用SaC框架去分類工作負載非常有幫助，然后基于工作負載風險和部署類型，應用特定的安全控制。而且提供未來狀態架構的藍圖，總結所指定的關鍵決策。通過各種自動化使用案例來有效和有效率地實例化SaC。最后，這個框架定義了公司的運營模型必須如何改變，才能獲取采用云的全部好處（圖3）。

風險分類，部署模型，和標準/策略

    在對工作負載及數據的敏感性和重要性分類后，下一步是應用策略，最后能通過代碼來實例化。為了達到這個水平，在每個控制區域，組織常常會遇到三種選擇。

    首先，發現和編寫新策略，解釋本地沒有的技術，例如考慮容器安全。一直在本地運營的公司可能不會強制掃描靜止、部署、運行時的容器漏洞。同樣，應該有使用可信鏡像和安全注冊表的現成策略。標準中常見差異的另一個例子是API安全，需要認證流量和使用網關控制API。

    其次，除了編寫新的策略，公司要修改當前本地環境策略，解決云的獨特安全環境，例如要考慮網絡分段。因此大多數本地組織，僅限于在網絡邊界使用粗粒度的防火墻規則，強制網絡分段策略。在云中，他們可以配置成安全組，提供主機水平的網絡保護，甚至在單獨子網內，有效提供微隔離。此外他們在子網或虛擬網絡邊界上使用更粗粒度的控制，這些可以通過代碼來配置和維護，而不是人工流程和使用手冊。

     最后，為了完整實現SaC的承諾，所有當前策略和新策略，必須編寫地足夠詳細，保證他們能夠轉換成代碼。在生成有效的安全策略方面，我們觀察到最大的差距之一是缺少了解如何設計有效策略和策略實施的人才。設計槽糕的策略和策略實施同他們想解決的風險一樣問題多多和成本很高，也許是和應用安全有關最常見的例子。策略必須要細粒度，足以自動化阻止應用進入生產，直到他們沒有明顯的、超出預計修復時間幀的漏洞。同樣，為了身份和訪問管理的目標，策略應該要求集成SaaS應用和聯合身份系統，根據應用的風險分類，自動強制使用多因素認證（MFA）。

架構和自動化

    一旦組織建立了健壯的風險分類框架，定義了云策略，成功實施SaC取決于做出關鍵架構設計決策和執行正確的自動化能力。與策略一樣，我們推薦把這些決策映射到組織的優先控制區域。

     但在公司能回答云安全架構的關鍵問題之前，必須首先對于整體云架構做出設計決策。這看起來顯而易見，但常常是一個被忽略的關鍵步驟。只有當組織能回答它的多云架構的關鍵問題，包括（但不限于）選擇主要的云服務商，以及如何設計戰略邊界之后，組織才能開始設計安全架構。

     也許實現SaC最重要的決策是，策略目標是否通過聯合、原生CSP工具或集中的第三方工具來實例化。這沒有標準答案；而是這個問題必須根據組織的風險偏好、工作負載分類、策略目標和整體云戰略的關聯關系來考慮。集中的、第三方工具的原理是通過單一界面，跨本地和云，實現集成的可視化。

     自動化是加強系統開發生命周期（SDLC）不同階段策略的基礎。因此，組織對于他們的多云環境，開發一個安全自動化使用實例的全面清單非常重要。不像映射到控制區域的策略目標和架構功能，這些使用實例應該映射到SDLC的各個階段：編碼、構建、打包、部署和運維。一些使用實例，如系統正式停止和容錯測試，是基礎設施即服務（IaaS）部署獨有的。而其他的如日志傳輸、導入、代碼掃描，在多種部署模型中很常見。一個云治理引擎合規服務（Cloud Governance Engine Compliance Service）用來管理這個流程。這是一個集中的服務，提供云資源之前，負責接受提出的請求，驗證基礎設施即代碼（IaC）是否符合組織合規要求。

運營模型和更廣泛的云戰略的連接

    當采用合適的安全開始云的旅程時，大多數公司采用技術優先的方法。和技術改變同樣重要的是，公司需要改進他們的運維模式，實現“左移”，最大化自我服務能力，實現全生命周期的安全自動化。

    SaC要求高度自動化服務、開發人員可以通過API來使用。反過來這同樣也要求在安全、基礎設施、應用開發團隊上的行為改變。安全組織必須從響應式的、基于請求的模式，轉變到使用高度自動化的安全產品-例如，在身份和訪問管理或漏洞管理中。在云里面，許多控制僅僅是核心計算或存儲服務的配置選項。因此，基礎設施產品工程團隊必須和對應安全部門團結得更緊密，解決產品中積壓的安全需求。開發團隊要求現場可靠工程師（site-reliable engineers，SRE）有足夠的經驗來有效地提供安全服務和管理應用。

    為實現這個目標，公司需要和常見的開發工具鏈及持續集成/交付管道結合起來。除非這些能力被標準化，否則SaC和云中的安全，都變得不可能。他們必須升級整個組織的技能，現場可靠工程師（SRE）需要成為有經驗的安全使用者。基礎設施產品管理者和工程師需要理解他們產品的安全影響。相比合規，安全組織需要更多產品管理和工程能力。

公司如何實現SaC

    一個大規模金融機構準備將80%的工作負載轉移到云上。然而人們很快就發現，解決合規問題的傳統響應方法，在部署到產品環境之后，無法跟上云負載。因此公司決定使用SaC主動推動管道中的合規。

    為了實現這個目標，對關鍵任務應用分成了400個控制，保證彈性的云基礎設施。然后開發和實現了90多個規則支持這些控制，并把他們轉換成小段代碼，在任何時候，任何基礎設施請求都可以引用。這些代碼塊確保在提供之前滿足所有的合規要求。這個方法為當前一半的安全需求提供自動化覆蓋。

     安全常常被看作是采用云的障礙。本來應該是無摩擦的部署過程，從一開始就嵌入安全。但當他們試圖把云部署硬塞入傳統的安全機制中，變成在開發人員、基礎設施和安全之間幾周和幾個月時間來回扯皮。從第三方評估到防火墻變更的冗長審批，不僅降低了云的整體價值主張，而且為適應業務要求，增加了風險策略例外情況的需求。

    SaC努力扭轉這種趨勢，把CISO定位為業務的推動者，而不是妨礙者。消除基于ticket的工作流、手動變更流程的需求，相比本地系統，SaC框架把最關鍵的安全控制實現自動化，提高整體安全，不會降低業務或犧牲合規要求。

CISO 對SaC的看法

    來自亞馬遜、谷歌和微軟的CISO們看到了安全即代碼的多種好處。

減少人力錯誤：

    通過代碼實現安全關鍵在于可重復性。為了安全目的，我們實施自動化和使用代碼，因為它在整個組織內應用普遍的嚴謹。解決人工錯誤問題，這是云泄露中常見的共同點。

—Stephen Schmidt, AWS CISO

    隨著時間，規模經濟會推動高水平的缺省控制。我們越提高控制基線(例如，加密虛擬機、高保證容器工作負載，身份和訪問管理，客戶管理加密秘鑰),更多的客戶就能打開所有工作負載分類。很快，當這樣的增強安全控制部署到所有客戶的所有服務，我們會到達一個頂點Schmidt, AWS CISO

—Phil Venables, Google Cloud CISO

平衡速度和風險：

    安全即代碼就是給與我們員工工作自由，同時保證我們能看見他們的所作所為，沒有隱藏的行為或影子IT。安全團隊必須扮演一個審計員角色，詳細了解進行的工作，當變更發生時得到提示。

—Stephen Schmidt, AWS CISO

    你從清單、服務、配置中獲得的自動化能力和洞察，以及大規模修復能力在本地都是不可能的。我們在兩年半時間內，通過使用集成的整體云方案，減少48%的供應商。

—Bret Arsenault, Microsoft CISO

    安全提高的步伐和我們產品安全特性（我們安全產品的主題，而不僅僅是安全產品）增加的程度正在加快，許多其他云提供商也取得類似成績，這個大規模、全球范圍內的競爭，在保持敏捷和生產力同時持續提高安全，對所有人都有好處。

—Phil Venables, Google Cloud CISO

提升和轉移安全：

    我們能看見的最大的問題是組織努力把安全從本地轉移到云，這樣做錯失了很多在云里而不是數據中心的機會。

—Stephen Schmidt, AWS CISO

    對一些沒有熟練安全團隊的客戶，他們所做的是保證開啟云提供的每項新安全功能。最先進的客戶要求給所有人帶來好處的新功能，而這一點再加上我們作為大規模的云提供商擁有的對威脅的可視化和響應，事實上，對整個客戶生成一個數字免疫系統。

—Phil Venables, Google Cloud CISO

    我們能和企業客戶建立聯系，我們的安全基礎設施和工具不是天生為云而生。然而，組織不能只采用傳統的、本地安全過程和工具，把他們應用到云環境中，他們無法以必要的規模或速度起到作用。他們必須根據他們操作的環境進行過渡。這個投資實現整體成本節省，好處非常明顯。

—Bret Arsenault, Microsoft CISO

自動化遏制：

    一些組織能自動化修復到已知的良好狀態，但大多數組織沒有，他們應該專注自動化遏制。應用的所有組件需要有特定的、最新的、測試過的運行手冊，遏制事件中不期望的行為。盡早帶給業務和應用的所有者。你不會想爭論何時拉開在激烈斗爭中隔開每件事的那根線。

—Stephen Schmidt, AWS CISO