Linux中國

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

如今,大大小小的組織正在探索雲原生技術的採用。「 雲原生 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中國 榮譽推出


本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive

對這篇文章感覺如何?

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據

    More in:Linux中國