經銷商專區｜登入
〔最新消息〕2020-10-22
保護容器化應用程式的4種方法
隨著越來越多的企業開始採用運行微服務的容器，他們也在絞盡腦汁，試圖找出哪種方式才是保護這些生態系統的正確方法。Radware的Web應用安全報告表明，目前還沒有出現單一的做法，然而有不同的技術聲稱可以完成這項工作。在這裡，我們將對這些方法進行比較。
微服務的安全隱患
設計微服務環境需要關注更多的資訊安全方面。典型的應用基礎架構必須是可擴展的，通常會包括一個部署和分配資源的協調器（如Kubernetes、OpenShift或Mesos），以及一個反向代理入口控制器（最流行的是NGiNX、HA-Proxy和Envoy）。
這些工具都沒有內置應用安全功能。此外，這些環境通常是由DevOps設計的，他們的目標不是安全，而是自動化和同步，以提高敏捷性。因此，如果在設計時沒有考慮到安全問題，就必須由安全人員追溯解決。
東西方流量和API流量被認為是安全的，因此被信任，儘管這是微服務安全的最大盲點。
策略
企業正在採取不同的策略來克服這些挑戰。新的技術出現，以創建一個更安全的CI/CD管道。讓我們仔細看看它們。
外部WAF--無論是作為週邊的虛擬機器還是在入口控制器上運行（例如，在NGiNX上運行的WAF），外部WAF可以根據IP信譽或簽名阻止已知的攻擊。然而，根據定義，這樣的部署無法提供細細微性的學習和準確的安全性，使應用程式容易受到零日攻擊。試圖應用正向安全和自動學習將導致高假陽性率，因為學習的是所有微服務的所有流量，並不像需要的那樣精細。雲安全服務也是如此。 此外，將流量分流到生態系統外，再分流回來，會增加不必要的延遲，而且違背了CI/CD管道端到端整合的原理。
容器安全解決方案--這些是新興的解決方案--有些非常成功--為容器本身提供不同級別的安全。它們被設計為將容器作為主機或端點進行保護，著眼於容器映射和其中的已知漏洞，而不是資料交易和HTTP流量。因此，它們提供了最小的應用安全，不會保護訪問違規、注入、Bruteforce、XSS和其他漏洞。此外，大多數仍處於只報警的模式，並沒有對資料交易實施安全保護。儘管如此，它們可以與應用安全共存，形成相當強大的態勢。
運行時應用程式自我保護（RASP）--顧名思義，應用程式將在運行時自我保護。這是一個輕巧、經濟的概念，並且可以隨著微服務自動擴展。但它真的有用嗎？
首先，它沒有引入由於資料路徑中的安全控制而導致的延遲。相反，由於額外的庫/外掛程式與所有類似WAF的規則，會有性能上的懲罰。其次，RASP適應了端到端加密的要求，在應用端進行SSL/TLS終止。它還能即時提供主動保護--然而，有些攻擊人們根本無法在運行時阻斷，必須在應用本身之前減輕。比如，拒絕服務。由於需要開銷，無法承受，所以做學習的能力有限。
最後，RASP不會自動修復代碼漏洞，這可能會讓它的保護對某些應用來說是一塊瑞士乳酪。由於它重寫代碼，可能會在運行時停止一個函數，因此對應用的執行和最終的SLA有很高的風險。不管是否相關，RASP方法並沒有在商業上爆發，它也沒有享受到太大的商業成功。總結一下--RASP本身是無法實現的。
MicroWAF - 這是一個專門的應用安全執行工具，它集成到系統中，最好由Kubernetes等編排工具管理，並作為側車坐在每個容器前。這種方法有兩大優勢。
1. 它由Kubernetes控制，可以自動部署、調配、擴展。
2. 因為每個容器前面都有一個實例，所以可以自動學習微服務的流量作為正向安全的基線。
在這種方法中，管理、分析和規則引擎與執行者分開居住，執行者不斷分享必要的資訊以優化安全。
這種方法的另一個關鍵優勢是它對DevOps友好--沒有減速或中斷，完全可見，而且隨著它與K8s受控生態系統中更多的供應、分析和自動化工具的集成，越多越好。這裡是一個說明。
我們希望在辯論如何解決微服務中的應用和資料安全問題時，這是很好的思路。這份檢查表包括評估微服務安全解決方案的10個提示。
原文網址
設計微服務環境需要關注更多的資訊安全方面。典型的應用基礎架構必須是可擴展的，通常會包括一個部署和分配資源的協調器（如Kubernetes、OpenShift或Mesos），以及一個反向代理入口控制器（最流行的是NGiNX、HA-Proxy和Envoy）。
這些工具都沒有內置應用安全功能。此外，這些環境通常是由DevOps設計的，他們的目標不是安全，而是自動化和同步，以提高敏捷性。因此，如果在設計時沒有考慮到安全問題，就必須由安全人員追溯解決。
- 外部威脅--這不是第一個威脅，來自互聯網的外部使用者與應用程式進行交易的威脅。這種典型的用戶端到伺服器的流量也被稱為南北流量。
- 橫向威脅--在微服務中，重點轉移到資料中心或VPC內部的資料包從伺服器到伺服器，或者微服務到微服務的傳輸。這種內部通信也被稱為東西向流量。保護東西部流量的安全對於減少惡意活動的可用表面至關重要。
- API安全--API是微服務之間東西方資料交換的主要載體，使用不同的協定--REST、gRPC、GraphQL或其他。API面臨的威脅各不相同，包括未經授權的訪問、協定操作、拒絕服務和各種僵屍攻擊。
- 開源--現成的工具、模組和功能非常多，但不能保證它們經過安全測試或打補丁。
- 端到端加密--如今的企業對任何形式的明文通信都不太寬容，需要在主機級別上終止SSL/TLS。這樣，他們就可以避免維護分散在多個地點的多個證書。
東西方流量和API流量被認為是安全的，因此被信任，儘管這是微服務安全的最大盲點。
企業正在採取不同的策略來克服這些挑戰。新的技術出現，以創建一個更安全的CI/CD管道。讓我們仔細看看它們。
外部WAF--無論是作為週邊的虛擬機器還是在入口控制器上運行（例如，在NGiNX上運行的WAF），外部WAF可以根據IP信譽或簽名阻止已知的攻擊。然而，根據定義，這樣的部署無法提供細細微性的學習和準確的安全性，使應用程式容易受到零日攻擊。試圖應用正向安全和自動學習將導致高假陽性率，因為學習的是所有微服務的所有流量，並不像需要的那樣精細。雲安全服務也是如此。 此外，將流量分流到生態系統外，再分流回來，會增加不必要的延遲，而且違背了CI/CD管道端到端整合的原理。
容器安全解決方案--這些是新興的解決方案--有些非常成功--為容器本身提供不同級別的安全。它們被設計為將容器作為主機或端點進行保護，著眼於容器映射和其中的已知漏洞，而不是資料交易和HTTP流量。因此，它們提供了最小的應用安全，不會保護訪問違規、注入、Bruteforce、XSS和其他漏洞。此外，大多數仍處於只報警的模式，並沒有對資料交易實施安全保護。儘管如此，它們可以與應用安全共存，形成相當強大的態勢。
運行時應用程式自我保護（RASP）--顧名思義，應用程式將在運行時自我保護。這是一個輕巧、經濟的概念，並且可以隨著微服務自動擴展。但它真的有用嗎？
首先，它沒有引入由於資料路徑中的安全控制而導致的延遲。相反，由於額外的庫/外掛程式與所有類似WAF的規則，會有性能上的懲罰。其次，RASP適應了端到端加密的要求，在應用端進行SSL/TLS終止。它還能即時提供主動保護--然而，有些攻擊人們根本無法在運行時阻斷，必須在應用本身之前減輕。比如，拒絕服務。由於需要開銷，無法承受，所以做學習的能力有限。
最後，RASP不會自動修復代碼漏洞，這可能會讓它的保護對某些應用來說是一塊瑞士乳酪。由於它重寫代碼，可能會在運行時停止一個函數，因此對應用的執行和最終的SLA有很高的風險。不管是否相關，RASP方法並沒有在商業上爆發，它也沒有享受到太大的商業成功。總結一下--RASP本身是無法實現的。
MicroWAF - 這是一個專門的應用安全執行工具，它集成到系統中，最好由Kubernetes等編排工具管理，並作為側車坐在每個容器前。這種方法有兩大優勢。
1. 它由Kubernetes控制，可以自動部署、調配、擴展。
2. 因為每個容器前面都有一個實例，所以可以自動學習微服務的流量作為正向安全的基線。
在這種方法中，管理、分析和規則引擎與執行者分開居住，執行者不斷分享必要的資訊以優化安全。
這種方法的另一個關鍵優勢是它對DevOps友好--沒有減速或中斷，完全可見，而且隨著它與K8s受控生態系統中更多的供應、分析和自動化工具的集成，越多越好。這裡是一個說明。
我們希望在辯論如何解決微服務中的應用和資料安全問題時，這是很好的思路。這份檢查表包括評估微服務安全解決方案的10個提示。
原文網址
