容器和微服務是如何改變了安全性

Wei Lien Dang發表於2017-11-13

雲原生程式和基礎架構需要完全不同的安全方式。牢記這些最佳實踐

如今,大大小小的組織正在探索雲原生技術的採用。“雲原生Cloud-native”是指將軟體打包到被稱為容器的標準化單元中的方法,這些單元組織成微服務,它們必須對接以形成程式,並確保正在執行的應用程式完全自動化以實現更高的速度、靈活性和可伸縮性。

由於這種方法從根本上改變了軟體的構建、部署和執行方式,它也從根本上改變了軟體需要保護的方式。雲原生程式和基礎架構為安全專業人員帶來了若干新的挑戰,他們需要建立新的安全計劃來支援其組織對雲原生技術的使用。

讓我們來看看這些挑戰,然後我們將討論安全團隊應該採取的哪些最佳實踐來解決這些挑戰。首先挑戰是:

  • 傳統的安全基礎設施缺乏容器可視性。 大多數現有的基於主機和網路的安全工具不具備監視或捕獲容器活動的能力。這些工具是為了保護單個作業系統或主機之間的流量,而不是其上執行的應用程式,從而導致容器事件、系統互動和容器間流量的可視性缺乏。
  • 攻擊面可以快速更改。雲原生應用程式由許多較小的元件組​​成,這些元件稱為微服務,它們是高度分散式的,每個都應該分別進行審計和保護。因為這些應用程式的設計是通過編排系統進行配置和調整的,所以其攻擊面也在不斷變化,而且比傳統的獨石應用程式要快得多。
  • 分散式資料流需要持續監控。容器和微服務被設計為輕量級的,並且以可程式設計方式與對方或外部雲服務進行互連。這會在整個環境中產生大量的快速移動資料,需要進行持續監控,以便應對攻擊和危害指標以及未經授權的資料訪問或滲透。
  • 檢測、預防和響應必須自動化。 容器生成的事件的速度和容量壓倒了當前的安全操作流程。容器的短暫壽命也成為難以捕獲、分析和確定事故的根本原因。有效的威脅保護意味著自動化資料收集、過濾、關聯和分析,以便能夠對新事件作出足夠快速的反應。

面對這些新的挑戰,安全專業人員將需要建立新的安全計劃以支援其組織對雲原生技術的使用。自然地,你的安全計劃應該解決雲原生程式的整個生命週期的問題,這些應用程式可以分為兩個不同的階段:構建和部署階段以及執行時階段。每個階段都有不同的安全考慮因素,必須全部加以解決才能形成一個全面的安全計劃。

確保容器的構建和部署

構建和部署階段的安全性側重於將控制應用於開發人員工作流程和持續整合和部署管道,以降低容器啟動後可能出現的安全問題的風險。這些控制可以包含以下準則和最佳實踐:

  • 保持映象儘可能小。容器映象是一個輕量級的可執行檔案,用於打包應用程式程式碼及其依賴項。將每個映象限制為軟體執行所必需的內容, 從而最小化從映象啟動的每個容器的攻擊面。從最小的作業系統基礎映象(如 Alpine Linux)開始,可以減少映象大小,並使映象更易於管理。
  • 掃描映象的已知問題。當映象構建後,應該檢查已知的漏洞披露。可以掃描構成映象的每個檔案系統層,並將結果與​​定期更新的常見漏洞披露資料庫(CVE)進行比較。然後開發和安全團隊可以在映象被用來啟動容器之前解決發現的漏洞。
  • 數字簽名的映象。一旦建立映象,應在部署之前驗證它們的完整性。某些映象格式使用被稱為摘要的唯一識別符號,可用於檢測映象內容何時發生變化。使用私鑰簽名映象提供了加密的保證,以確保每個用於啟動容器的映象都是由可信方建立的。
  • 強化並限制對主機作業系統的訪問。由於在主機上執行的容器共享相同的作業系統,因此必須確保它們以適當限制的功能集啟動。這可以通過使用核心安全功能和 Seccomp、AppArmor 和 SELinux 等模組來實現。
  • 指定應用程式級別的分割策略。微服務之間的網路流量可以被分割,以限制它們彼此之間的連線。但是,這需要根據應用級屬性(如標籤和選擇器)進行配置,從而消除了處理傳統網路詳細資訊(如 IP 地址)的複雜性。分割帶來的挑戰是,必須事先定義策略來限制通訊,而不會影響容器在環境內部和環境之間進行通訊的能力,這是正常活動的一部分。
  • 保護容器所使用的祕密資訊。微服務彼此相互之間頻繁交換敏感資料,如密碼、令牌和金鑰,這稱之為祕密資訊secret。如果將這些祕密資訊儲存在映象或環境變數中,則可能會意外暴露這些。因此,像 Docker 和 Kubernetes 這樣的多個編排平臺都整合了祕密資訊管理,確保只有在需要的時候才將祕密資訊分發給使用它們的容器。

來自諸如 Docker、Red Hat 和 CoreOS 等公司的幾個領先的容器平臺和工具提供了部分或全部這些功能。開始使用這些方法之一是在構建和部署階段確保強大安全性的最簡單方法。

但是,構建和部署階段控制仍然不足以確保全面的安全計劃。提前解決容器開始執行之前的所有安全事件是不可能的,原因如下:首先,漏洞永遠不會被完全消除,新的漏洞會一直出現。其次,宣告式的容器後設資料和網路分段策略不能完全預見高度分散式環境中的所有合法應用程式活動。第三,執行時控制使用起來很複雜,而且往往配置錯誤,就會使應用程式容易受到威脅。

在執行時保護容器

執行時階段的安全性包括所有功能(可見性、檢測、響應和預防),這些功能是發現和阻止容器執行後發生的攻擊和策略違規所必需的。安全團隊需要對安全事件的根源進行分類、調查和確定,以便對其進行全面補救。以下是成功的執行時階段安全性的關鍵方面:

  • 檢測整個​​環境以得到持續可見性。能夠檢測攻擊和違規行為始於能夠實時捕獲正在執行的容器中的所有活動,以提供可操作的“真相源”。捕獲不同型別的容器相關資料有各種檢測框架。選擇一個能夠處理容器的容量和速度的方案至關重要。
  • 關聯分散式威脅指標。 容器設計為基於資源可用性以跨計算基礎架構而分佈。由於應用程式可能由數百或數千個容器組成,因此危害指標可能分佈在大量主機上,使得難以確定那些與主動威脅相關的相關指標。需要大規模,快速的相關性來確定哪些指標構成特定攻擊的基礎。
  • 分析容器和微服務行為。微服務和容器使得應用程式可以分解為執行特定功能的最小元件,並被設計為不可變的。這使得比傳統的應用環境更容易理解預期行為的正常模式。偏離這些行為基準可能反映惡意行為,可用於更準確地檢測威脅。
  • 通過機器學習增強威脅檢測。容器環境中生成的資料量和速度超過了傳統的檢測技術。自動化和機器學習可以實現更有效的行為建模、模式識別和分類,從而以更高的保真度和更少的誤報來檢測威脅。注意使用機器學習的解決方案只是為了生成靜態白名單,用於警報異常,這可能會導致嚴重的警報噪音和疲勞。
  • 攔截並阻止未經授權的容器引擎命令。傳送到容器引擎(例如 Docker)的命令用於建立、啟動和終止容器以及在正在執行的容器中執行命令。這些命令可以反映危害容器的意圖,這意味著可以禁止任何未經授權的命令。
  • 自動響應和取證。容器的短暫壽命意味著它們往往只能提供很少的事件資訊,以用於事件響應和取證。此外,雲原生架構通常將基礎設施視為不可變的,自動將受影響的系統替換為新系統,這意味著在調查時的容器可能會消失。自動化可以確保足夠快地捕獲、分析和升級資訊,以減輕攻擊和違規的影響。

基於容器技術和微服務架構的雲原生軟體正在迅速實現應用程式和基礎架構的現代化。這種模式轉變迫使安全專業人員重新考慮有效保護其組織所需的計劃。隨著容器的構建、部署和執行,雲原生軟體的全面安全計劃將解決整個應用程式生命週期問題。通過使用上述指導方針實施計劃,組織可以為容器基礎設施以及執行在上面的應用程式和服務構建安全的基礎。


作者:WeLien Dang 是 StackRox 的產品副總裁,StackRox 是一家為容器提供自適應威脅保護的安全公司。此前,他曾擔任 CoreOS 產品負責人,並在亞馬遜、Splunk 和 Bracket Computing 擔任安全和雲基礎架構的高階產品管理職位。


via: https://www.infoworld.com/article/3233139/cloud-computing/how-cloud-native-applications-change-security.html

作者:Wei Lien Dang 譯者:geekpi 校對:wxy

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

相關文章