本篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
將所有微服務視為易受攻擊 — 並監控其行為
這篇文章警惕 DevOps 不要抱持錯誤的安全感。在開發和配置微服務時，即使遵循最佳安全實務，也不代表能產生沒有漏洞的微服務。本文指出，儘管所有已部署的微服務都存在漏洞，但仍有很多方法可以確保微服務不被利用。文章解釋了如何從安全角度分析客戶端和服務端的行為，在此稱為 「安全行為分析 (Security-Behavior Analytics)」，可以保護已部署的易受攻擊微服務。文章並介紹了 Guard，這是一個開源專案，提供對推定為易受攻擊的 Kubernetes 微服務進行安全行為監控和控制。
隨著網路攻擊的複雜性持續提升，部署雲端服務的組織不斷增加其網路安全投資，目標是產生安全且無漏洞的服務。然而，逐年增長的網路安全投資並未帶來網路事件的同步減少。相反地，網路事件的數量持續逐年增加。顯然，組織註定在這場鬥爭中失敗 - 無論付出多少努力來偵測和移除已部署服務中的網路弱點，攻擊者似乎總是佔上風。
考量到當前攻擊工具的普及、攻擊者的複雜性，以及攻擊者不斷增長的網路財務收益，任何在 2023 年仍依賴建構無漏洞、無弱點服務的網路安全策略顯然太過天真。看來唯一可行的策略是：
➥ 承認您的服務存在漏洞！
換句話說，有意識地接受您永遠無法創建完全無懈可擊的服務。如果您的對手找到哪怕一個弱點作為入口點，您就輸了！承認儘管您已盡最大努力，但所有服務仍然存在漏洞，這是重要的第一步。接下來，這篇文章將討論您可以如何應對...
如何保護微服務免受攻擊
存在漏洞並不一定表示您的服務會被利用。儘管您的服務在您未知的某些方面存在漏洞，但攻擊者仍然需要識別這些漏洞，然後加以利用。如果攻擊者未能利用您的服務漏洞，您就贏了！換句話說，擁有無法被利用的漏洞，代表著無法實現的風險。
圖 1. 攻擊者在易受攻擊的服務中取得立足點
上圖顯示了一個範例，其中攻擊者尚未在服務中取得立足點；也就是說，假設您的服務在第一天並未運行由攻擊者控制的程式碼。在我們的範例中，服務在暴露給客戶端的 API 中存在漏洞。為了取得初步立足點，攻擊者使用惡意客戶端嘗試利用其中一個服務 API 漏洞。惡意客戶端發送一個漏洞利用程式，觸發服務的某些非預期行為。
更具體地說，假設服務容易受到 SQL 注入攻擊。開發人員未能正確清理使用者輸入，因此允許客戶端發送會更改預期行為的值。在我們的範例中，如果客戶端發送一個查詢字串，其鍵為 “username”，值為 “tom or 1=1”，則客戶端將收到所有使用者的資料。利用此漏洞需要客戶端發送不規則的字串作為值。請注意，良性使用者不會發送包含空格或等號字元的字串作為使用者名稱，相反地，他們通常會發送合法的使用者名稱，例如，可以定義為 a-z 字元的短序列。沒有合法的用戶名可以觸發服務的非預期行為。
在這個簡單的範例中，人們已經可以識別出幾個機會來偵測和阻止利用開發人員（無）意間留下的漏洞的嘗試，從而使該漏洞無法被利用。首先，惡意客戶端的行為與良性客戶端的行為不同，因為它發送不規則的請求。如果偵測到並阻止此類行為變更，則漏洞利用程式永遠不會到達服務。其次，服務對漏洞利用程式的反應與服務對常規請求的反應不同。此類行為可能包括後續對其他服務（例如資料儲存庫）進行不規則呼叫、花費不規則的時間來回應，以及/或以不規則的回應（例如，包含比良性客戶端發出常規請求時通常發送的資料多得多的資料）回應惡意客戶端。服務行為變更（如果被偵測到）也將允許在漏洞利用嘗試的不同階段阻止漏洞利用程式。
更廣泛地來說
監控客戶端的行為可以幫助偵測和阻止針對服務 API 漏洞的攻擊。實際上，部署高效的客戶端行為監控使許多漏洞無法被利用，而另一些漏洞則非常難以實現。為了成功，攻擊者需要創建一個無法從常規請求中偵測到的漏洞利用程式。
監控服務的行為可以幫助偵測正在被利用的服務，無論使用何種攻擊媒介。高效的服務行為監控限制了攻擊者可能達成的目標，因為攻擊者需要確保服務行為無法從常規服務行為中偵測到。
結合這兩種方法可能會為已部署的易受攻擊服務增加一層保護，大幅降低任何人成功利用任何已部署的易受攻擊服務的可能性。接下來，讓我們識別四個需要使用安全行為監控的用例。
用例
從安全的角度來看，可以識別任何服務生命週期的以下四個不同階段。在每個階段，都需要安全行為監控來應對不同的挑戰。
| 服務狀態 | 用例 | 您需要什麼才能應對此用例？ |
|---|---|---|
| 正常 | 沒有已知漏洞： 服務所有者通常不知道服務映像或配置中存在任何已知漏洞。然而，合理假設服務存在弱點。 | 針對任何未知的零日服務漏洞提供通用保護 - 偵測/阻止作為傳入客戶端請求一部分發送的可能被用作漏洞利用程式的不規則模式。 |
| 易受攻擊 | 已發布適用的 CVE： 服務所有者需要發布服務的新非漏洞版本。研究表明，實際上，移除已知漏洞的過程可能需要數週才能完成（平均 2 個月）。 | 根據 CVE 分析新增保護 - 偵測/阻止包含可用於利用已發現漏洞的特定模式的傳入請求。即使服務存在已知漏洞，仍繼續提供服務。 |
| 可被利用 | 已發布已知漏洞利用程式： 服務所有者需要一種方法來過濾包含已知漏洞利用程式的傳入請求。 | 根據已知的漏洞利用簽章新增保護 - 偵測/阻止攜帶識別漏洞利用程式的簽章的傳入客戶端請求。即使存在漏洞利用程式，仍繼續提供服務。 |
| 遭濫用 | 攻擊者濫用支援服務的 Pod： 攻擊者可以遵循攻擊模式，使其能夠濫用 Pod。服務所有者需要重新啟動任何受損的 Pod，同時使用未受損的 Pod 繼續提供服務。請注意，一旦 Pod 重新啟動，攻擊者需要重複攻擊模式才能再次濫用它。 | 識別並重新啟動正在被濫用的組件實例 - 在任何給定時間，某些支援 Pod 可能會受損並被濫用，而其他 Pod 則按設計運行。偵測/移除被濫用的 Pod，同時允許其他 Pod 繼續為客戶端請求提供服務。 |
幸運的是，微服務架構非常適合安全行為監控，接下來將討論這一點。
微服務與巨型應用程式的安全行為
Kubernetes 通常用於支援以微服務架構設計的工作負載。依據設計，微服務旨在遵循 UNIX 「做好一件事並做到最好」的哲學。每個微服務都有一個有界限的上下文和清晰的介面。換句話說，您可以預期微服務客戶端發送相對常規的請求，並且微服務作為對這些請求的回應，呈現相對常規的行為。因此，微服務架構是安全行為監控的絕佳候選者。
圖 2. 微服務非常適合安全行為監控
上圖闡明了將巨型應用程式服務劃分為一組微服務如何提高我們執行安全行為監控和控制的能力。在巨型應用程式服務方法中，不同的客戶端請求相互交織，導致識別不規則客戶端行為的能力降低。在沒有先驗知識的情況下，交織客戶端請求的觀察者將難以區分請求類型及其相關特徵。此外，內部客戶端請求不會暴露給觀察者。最後，巨型應用程式服務的聚合行為是其組件許多不同內部行為的複合，這使得難以識別不規則的服務行為。
在微服務環境中，依據設計，每個微服務都應提供更明確定義的服務並服務於更好定義的請求類型。這使得觀察者更容易識別不規則的客戶端行為和不規則的服務行為。此外，微服務設計公開了內部請求和內部服務，這些請求和服務提供更多安全行為資料，供觀察者識別異常情況。總體而言，這使得微服務設計模式更適合安全行為監控和控制。
Kubernetes 上的安全行為監控
尋求新增安全行為的 Kubernetes 部署可以使用 Guard，它是在 CNCF 專案 Knative 下開發的。Guard 已整合到 Knative 自動化套件中，該套件在 Kubernetes 之上運行。或者，您可以將 Guard 作為獨立工具部署，以保護 Kubernetes 上任何基於 HTTP 的工作負載。
請參閱
- Github 上的 Guard，了解如何將 Guard 作為獨立工具使用。
- Knative 自動化套件 - 在部落格文章 Opinionated Kubernetes 中閱讀有關 Knative 的資訊，該文章描述了 Knative 如何簡化和統一在 Kubernetes 上部署網路服務的方式。
- 您可以在 SIG Security Slack 頻道或 Knative 社群 security Slack 頻道上聯繫 Guard 維護者。Knative 社群頻道很快將移至 CNCF Slack，名稱為
#knative-security。
本文的目的是邀請 Kubernetes 社群採取行動，並引入安全行為監控和控制，以幫助保護基於 Kubernetes 的部署。希望社群後續將會：
- 分析針對不同 Kubernetes 用例提出的網路安全挑戰。
- 為使用者新增關於如何引入安全行為監控和控制的適當安全文件。
- 考慮如何與可以幫助使用者監控和控制其易受攻擊服務的工具整合。
參與其中
歡迎您參與並加入為 Kubernetes 開發安全行為監控和控制的行列；分享回饋並貢獻程式碼或文件；以及提出或建議任何形式的改進。