實現容器安全的辦法：設計應用程序標識

【IT168 編譯】多年來，我們一直在採用新技術來尋找系統構建過程中的改進辦法，因此如今的IT基礎設施可謂是經歷了重大的演變。為了迎接新技術的到來，遺留技術常常需要與新技術結合在一起，但這種結合併不是水到渠成的。在整體解決方案中，超現代與傳統之間相互融合的阻力使過去和未來之間的關係劍拔弩張。

雲的多租戶共享基礎架構、Docker和Kubernetes等容器技術，以及像微服務和無伺服器這樣的新架構，在技術層面上可以說是引人注目的，但同時也增加了複雜性。複雜性是安全的頭號敵人。因此，我們需要一種並不依賴於將基礎設施作為控制點的新的安全方法。而像思科和VMware這樣的公司，都在擴展他們的解決方案，以覆蓋容器網路和安全。

IT環境的挑戰

管理員對雲的控制力很有限。啟用雲服務可以控制現有的靜態環境——這些靜態環境以前由本地管理員控制，具有良好的邊界和傳統的安全構造。而原生雲技術對傳統的安全邊界是不可見的，傳統的安全控制(如IP地址過濾和防火牆上的ACL)已不再有效。

經典的三層架構現在經常被分解成許多不同的應用程序編程介面(API)，它們都在共享環境中運行。微服務架構消除了顯式的入口和逸出點。現在，服務之間的通信是通過許多不同的內部和第三方API以公開的網路調用和服務進行的。API是新資源，所有服務現在都響應API調用。

IP地址的挑戰

在這個快速發展的環境中，IT組織在維護傳統IP地址和ACL入口的嘗試中面臨挑戰。現代的動態基礎設施通過假定一個相對靜態的配置，使現有的網路安全方法失效。ACL表變得越來越大，最終變得非常複雜，以至於幾乎不可能有效地進行管理，而且它們的處理進程會影響主機性能。層4與網路拓撲結構耦合，缺乏支持敏捷型應用程序的靈活性。此外，將網路地址轉換(NAT)引入到數據路徑中，消除了端到端可見性，這增加了連接的第二個問題。使用IP地址有效地識別和保護應用程序端點是一項挑戰。因此，也可以說IP識別「蒙上了管理員的眼睛」。這時你有兩個選擇：你可以信任網路來完成它的工作，不需要對它進行任何控制，也可以引入一種新的方法來進行資源識別和控制，從而減少對IP地址的依賴。

應用程序標識和政策

IP地址就像家庭住址，為你的房子創建了一個物理標識。我們使用IP地址作為網路計算資源身份的代理，但是直到此時我們還沒有一個可靠的方法來有效地標識實際的端點。你對一個人了解得越多，那個人的身份就越豐富。並不僅僅是了解一個人的名字、身高、體重或年齡，而且，你肯定不能只通過他們的家庭住址來了解他們。身份的概念對於在現實世界和網路中發生的每一種授權和身份驗證通信都是必不可少的。每當有交互時，你需要建立標識並安全地授權和驗證連接。交互可以是用戶、應用程序或API之間的任何通信組合。

在零信任的雲環境中，你必須假設任何東西對於任何人在任何時刻都是可以訪問的，在網路交互過程中，應用程序組件需要額外的安全性。僅僅免受外部威脅是不夠的，還需要加強防範內部漏洞和配置錯誤。如果一個工作負載產生一個特定的標識，應該是安全簽名，這樣就沒有機會篡改它的標識。作為流程的一部分，當端點呈現給另一個端點時，它應該使用用於建立信任的證書來顯示已簽名的標識。雲原生應用程序是有彈性的，並且根據需求動態增長。應用程序的動態特性需要一種新的持久特性。傳統上，應用程序配置了IP地址，但是在沒有對基礎設施進行控制的動態環境中，IP地址不再是識別應用程序的可靠或持久的方式。但是，如果你給應用程序、服務或API一個持久的標識，你就可以識別它是誰。

為什麼這個很重要?策略創建需要授權和對試圖溝通者的身份驗證。傳統的編寫策略的模型基於IP地址，但是由於IP地址不再是持久性的，所以如果在規模上構建策略並非不可能，那麼它就會變得非常費力。具有穩定的身份範式和可靠的身份應用程序組件(如容器、微服務或API)的能力，安全策略可以與應用程序一起分發，以實現規模和獨立於網路的實時執行。持久的和經過驗證的身份可以減輕跨動態工作負載的策略執行，並在多個環境中實現統一的安全性。

可見性

當你檢查網路時，會有一個同時具有源和目標的流。源是基於子網的，它被分配給一個工作負載，例如前端或後端層。在檢查雲中信息的流時，你無法找到發送者和端點試圖進行通信的原因。雲應用程序的採用放棄了對正在實例化應用程序的基礎設施的控制。從可見性的角度來看，你沒有持久的標識或有意義的方式去跟蹤服務到服務之間的通信。但是，如果你給一個應用程序一個持久的身份，就可以快速地找出誰是前端或後端層，以及他們為什麼試圖通信。持久性標識提高了網路中的可見性和一致性。

應用程序標識

工作負載可以用幾種方式封裝，比如虛擬機(VM)、裸金屬或容器。容器安全解決方案必須以一種獨特的方式評估工作負載。如何保護工作負載是一個次要的概念。然而，封裝的方法是微不足道的。

容器安全解決方案應用程序標識應該將安全性與網路和基礎結構分離開來，以使其能夠伸縮。這種方法使策略與實際的工作負載標識綁定在一起。使用細粒度的、統一的安全策略來保護工作負載簡化了安全模型，而不需要對業務邏輯或網路配置進行任何更改。現在，應用程序和組件之間的所有通信都可以通過身份驗證、授權和透明加密。因此，這些解決方案完全保護了應用程序，並消除了網路內的任何未經授權的橫向移動。

由於安全策略的執行不再依賴於IP，因此關於以網路和以邊界為中心的安全性的挑戰不再是一種不利因素。例如，如果資料庫工作負載離線並返回一個不同的IP地址，這不再是什麼大事，因為工作負載現在已具有從元數據或其他環境變數中提取的持久標識。

如何搭建?

當一個受保護的工作負載通過Docker、Kubernetes或作為一個程序在主機或VM上完成實例化時，安全解決方案必須檢查工作負載的所有相關屬性，以建立資源的唯一應用程序標識。

有各種各樣的元數據和安全信息來源用於建立應用程序標識的上下文，可以來自操作系統本身，例如systemd和與操作系統環境變數相關的元數據。如果是一個主機上的進程，它們可以檢查通過CLI命令或systemd進程發出的環境變數。除此之外，數據還可以從其他可用的數據源中提取，比如來自雲服務提供商的身份證明文件(ID)文檔、關於應用程序的CI/CD管道元數據、來自內部或第三方漏洞掃描器的漏洞信息以及運行時觀察到的威脅行為信息。

在應用程序通信中嵌入多屬性標識是可行的，這可以通過截取用於在組件之間建立網路連接的三次握手來實現。一個模塊可以位於應用程序TCP/IP棧的前面。然後，身份組件被注入到SYN和SYN-ACK數據包的TCP選項中，使它們能夠獨立於基礎設施。作為三次握手的一部分，可以嵌入一個JSON Web Token來交換用於建立和執行策略的多屬性標識。當傳入的連接請求出現時，前端模塊檢查傳入請求的標識，檢查策略以查看是否允許通信，並簡單地刪除連接，而接收方永遠不會看到預期的連接。接收方被隱藏在所有類型的惡意探索中，如無根據的連接、攻擊探針或攻擊者的掃描。

到現在為止，我們已經討論了控制網路層的訪問，即TCP層，但是超文本傳輸協議(HTTP)層又如何呢?在微服務環境中，典型的資源是API。在這種情況下，可以部署在堆棧中運行更高的HTTP代理。例如，一個服務公開了一組具有特定範圍的統一資源標識符(URI)。在這種保護API的場景中，這個用例擴展到了那些試圖使用API或服務的用戶。現在，它是一種服務對服務、用戶對服務和服務對用戶的連接，根據策略允許的用戶和服務標識的組合進行了身份驗證和授權。

HTTP代理擴展能力超出了網路訪問控制，達到了其中身份可以是用戶或服務的API訪問控制。

為了充分接受應用程序分解和雲原生應用程序帶來的好處，為資源建立一個獨特的應用程序標識，以確定如何識別和保護應用程序端點。這需要技術和心態的改變。

使用網路作為安全控制點的舊方法不僅在操作上具有挑戰性，而且還具有安全隱患。應用程序身份與分散式策略實施模型的結合，創建了一個安全範例，可以有效地在任何基礎設施上實現統一的安全性。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！