原生云應用程序和基礎設施需要完全不同的安全方法。請牢記下面這些最佳實踐。

　　如今，大大小小的組織正在探索云原生軟件技術的應用。“原生云（cloud－native）”是指將軟件封裝在被稱為容器的標準化單元內的方法，將這些單元排列成彼此以接口連接的微服務器以形成應用程序，并確保運行的應用程序完全自動化，以實現更高的速度、靈活性和可擴展性。

　　因為這種方法從根本上改變了軟件的構建、部署和運行，所以它也從根本上改變了保護軟件的方式。原生云應用程序和基礎設施為安全專業人員帶來了幾個新的挑戰，他們將需要建立新的安全程序來支持組織使用原生云技術。

　　我們來看看這些挑戰，然后我們將討論安全小組應對這些挑戰應采取的一些最佳實踐。首先面臨的挑戰是：

　　· 傳統的安全基礎設施缺乏容器的可見性。大多數現有的基于主機和網絡安全的工具無法監視或采集容器活動。這些工具被構建為保護單個操作系統或主機之間的流量，而不是在其上運行的應用程序，這導致對容器事件、系統交互和容器間流量的可見性的損失。

　　· 攻擊面可能會迅速變化。原生云應用程序由很多被稱為微服務的較小的組件組成，這些組件高度分布，必須單獨審計和保護每個組件。由于這些應用程序被設計為由編排系統進行配置和擴展，因此它們的攻擊面會不斷變化，遠遠超過傳統的整體式應用程序（monolithic application）。

　　· 分布式數據流需要持續監控。把容器和微服務設計為輕量級，并通過編程方式與彼此或外部云服務進行互連。這將在整個環境中產生大量快速移動的數據，以便不斷監控攻擊指標以及未經授權的數據訪問或滲透。

　　· 檢測、預防和響應必須自動化。容器產生的事件的速度和容量使當前的安全操作流程無法招架。容器的短暫的生命也使捕獲、分析和確定事件的根本原因變得很困難。有效的威脅保護意味著將數據收集、過濾、關聯和分析自動化，以便能夠對新事件做出足夠快的響應。

　　面對這些新挑戰，安全專業人員需要建立新的安全計劃，以支持其組織使用原生云技術。當然，你的安全程序應該解決原生云應用程序的整個生命周期，這可以分為兩個不同的階段：構建和部署階段以及運行時階段。這些階段中的每一個階段都有一組不同的安全因素，必須解決這些安全因素以形成一個全面的安全程序。

　　保護容器的構建和部署

　　構建和部署階段的安全性把重點放在將控件應用于開發人員工作流程以及持續集成和部署管道（deployment pipeline），以減輕容器啟動后可能出現的安全問題的風險。這些控件可以包含以下準則和最佳實踐：

　　· 保持圖像盡可能小。容器鏡像是一個輕量級的可執行文件，它用于封裝應用程序代碼及其依賴項。將每個圖像的大小限制在剛好夠軟件運行，這樣就可以將從圖像啟動的每個容器的攻擊面最小化。從最小的操作系統基礎圖像開始，如Alpine Linux可以減小圖像尺寸，并使圖像更容易管理。

　　· 掃描圖像以了解已知問題。當構建圖像時，應檢查已知的漏洞和后門。可以掃描構成圖像的每個文件系統層，并將結果與常規更新的通用漏洞和后門（Common Vulnerabilities and Exposures，CVE）數據庫進行比較。然后，開發和安全團隊可以在圖像用于啟動容器之前處理發現的漏洞。

　　· 數字簽名圖像。一旦構建了圖像，就應該在部署前驗證它們的完整性。有些圖像格式使用被稱為摘要的唯一標識符，它們可以用來檢測圖像內容何時發生變化。用私鑰簽名圖像提供加密可以確保用于啟動容器的每個圖像都是由受信方創建的。

　　· 加強并限制對主機操作系統的訪問。由于在主機上運行的容器共享相同的操作系統，因此確保它們以適當限制的一系列功能開始是非常重要的。這可以用內核安全功能和模塊（如Seccomp，AppArmor和SELinux）來實現。

　　· 指定應用級分段策略。微服務之間的網絡流量可以分段，以限制它們之間的連接方式。然而，這需要根據標簽和選擇器之類的應用程序級屬性進行配置，從而抽象出處理IP地址之類的傳統網絡細節的復雜性。分段所提出的挑戰是必須先定義限制通信的策略，而不影響作為容器的正常活動的一部分在環境內和跨環境中進行通信的能力。

　　· 保護容器所使用的秘密。互相以接口連接的微服務經常交換被稱為秘密的密碼、令牌和密鑰等敏感數據。如果這些秘密存儲在圖像或環境變量中，可能會意外暴露。因此，Docker和Kubernetes等多個編排平臺已經集成了秘密管理，確保秘密只在需要時才將其分配給使用它們的容器。

　　Docker、Red Hat和CoreOS等公司的幾個領先的容器平臺和工具提供了部分或全部功能。從這些選項之一著手是構建和部署階段確保強健的安全性的最簡單的方法。

　　然而，構建和部署階段的控件仍然不足以確保全面的安全程序。在容器開始運行之前搶占所有安全事件是不可能的，原因如下。首先，不可能一勞永逸地消除所有漏洞，新的漏洞始終會被利用。其次，聲明式容器元數據和網絡分段策略不能完全預測高度分布式環境中的所有合法應用程序活動。最后，運行時控件使用起來很復雜，經常會配置錯誤，使應用程序容易受到威脅。

　　在運行時保護容器

　　運行時階段的安全性包括發現和停止容器運行時發生的攻擊和策略違規所需的所有功能，即可見性、檢測、響應和預防。安全小組需要對安全事件的根本原因進行鑒別分類、調查和確認，以便對其進行充分的補救。以下是成功運行時階段的安全性的關鍵方面：

　　· 為持續可見性測量整個環境。能夠檢測攻擊和違反策略的行為都始于能夠實時捕獲運行容器的所有活動，以提供可操作的“事實上的來源（source of truth）”。存在各種用于捕獲不同類型的容器的相關數據的儀器框架。選擇可以處理容器的容積和速度的關鍵。

　　· 關聯分布式威脅指標。把容器設計成按資源可用性分布在計算基礎設施。鑒于應用程序可能包含數百或數千個容器，攻擊的指標可能會擴散到大量的主機上，這使確定與作為主動威脅的一部分相關的那些主機變得更困難。需要大規模，快速的相關性來確定是哪些指標構成特定攻擊的基礎。

　　· 分析容器和微服務行為。微服務和容器可將應用程序分解為執行特定功能并被設計為不可變的最小組件。這種做法比傳統應用程序環境更容易讓人理解預期行為的正常模式。與這些行為基準的偏差可能反映了惡意活動，而這可以更準確地檢測威脅。

　　· 用機器學習增強威脅檢測。在容器環境中產生的數據量和速度使常規的檢測技術應接不暇。自動化和機器學習可以實現更有效的行為建模、模式識別和分類，以更高的保真度和更少的誤報檢測威脅。要警惕那些僅僅用機器學習來生成用于警告異常的靜態白名單的解決方案，這可能會導致嚴重的警報噪音和疲勞。

　　· 攔截和阻止未經授權的容器引擎命令。發給容器引擎的命令（例如Docker）用于創建、啟動和終止容器以及運行啟動中的容器內的命令。這些命令可以反映對容器的攻擊企圖，這意味著必須禁止任何未經授權的容器。

　　· 將響應和取證的動作自動化。容器的短暫生命意味著它們留給事件響應和取證的可用信息極少。此外，原生云架構往往將基礎設施視為不可變，自動將受影響的系統替換為新的系統，這意味著容器在調查時可能會消失。自動化可以確保快速捕獲、分析和升級信息，以減輕攻擊和破壞的影響。

　　基于容器技術和微服務架構的原生云軟件正在迅速地對應用程序和基礎設施進行現代化。這種范式轉移迫使安全專業人員重新考慮能有效保護其組織所需的計劃。當容器被構建、部署和運行時，一個全面的原生云軟件安全程序解決了整個應用程序生命周期。通過使用上述指南實施程序，組織可以為容器基礎設施及運行在它上面的應用程序和服務構建穩固的基礎。

　　Wei Lien Dang是StackRox的產品副總裁，StackRox是一家為容器提供適應性威脅防護的安全公司。此前，他曾擔任CoreOS的產品負責人，并擔任Amazon Web Services、Splunk和Bracket Computing的安全和云基礎架構的高級產品管理角色。