本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
將所有微服務視為易受攻擊的 —— 並監控其行為
這篇文章提醒開發運維人員（Devops）警惕一種虛假的安全感。在開發和配置微服務時遵循安全最佳實踐，並不能保證微服務無懈可擊。文章指出，儘管所有已部署的微服務都存在漏洞，但仍有很多措施可以確保微服務不被利用。文章解釋瞭如何從安全形度分析客戶端和服務的行為，即本文所稱的**“安全行為分析”**，從而保護已部署的存在漏洞的微服務。文章還介紹了一個開源專案 Guard，該專案為假定存在漏洞的 Kubernetes 微服務提供安全行為監控和控制。
隨著網路攻擊的複雜程度不斷加劇，部署雲服務的組織持續增加其網路安全投資，旨在打造安全無漏洞的服務。然而，網路安全投資的逐年增長並未帶來網路安全事件的相應減少。相反，網路安全事件的數量仍在逐年增加。顯然，組織在這場鬥爭中註定會失敗——無論付出多少努力來檢測和消除已部署服務中的網路弱點，攻擊者似乎總是佔上風。
考慮到當前攻擊工具的泛濫、攻擊者的複雜性以及攻擊者不斷增長的網路犯罪經濟收益，任何依賴於在 2023 年構建一個無漏洞、無弱點服務的網路策略都顯得過於天真。似乎唯一可行的策略是：
➥ 承認你的服務存在漏洞！
換句話說，要清醒地認識到你永遠無法創造出完全無懈可擊的服務。如果你的對手找到哪怕一個弱點作為入口，你就輸了！承認儘管你盡了最大努力，所有服務仍然存在漏洞，這是重要的第一步。接下來，這篇文章將討論你可以為此做些什麼……
如何保護微服務免遭利用
存在漏洞並不一定意味著你的服務會被利用。雖然你的服務在某些你未知的地方存在漏洞，但攻擊者仍需要識別這些漏洞然後加以利用。如果攻擊者未能利用你服務的漏洞，你就贏了！換句話說，一個無法被利用的漏洞，代表著一個無法成為現實的風險。
圖 1. 攻擊者在易受攻擊的服務中獲得立足點
上圖顯示了一個示例，其中攻擊者尚未在服務中獲得立足點；也就是說，假定你的服務在第一天沒有執行受攻擊者控制的程式碼。在我們的示例中，服務向客戶端暴露的 API 存在漏洞。為了獲得初步立足點，攻擊者使用惡意客戶端嘗試利用服務 API 的某個漏洞。惡意客戶端傳送一個利用程式（exploit），觸發服務的某些非預期行為。
更具體地說，我們假設服務存在 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 整合在運行於 Kubernetes 之上的完整 Knative 自動化套件中。或者，你可以將 Guard 部署為一個獨立的工具，以保護 Kubernetes 上任何基於 HTTP 的工作負載。
請參閱
- GitHub 上的 Guard，瞭解如何將 Guard 作為獨立工具使用。
- Knative 自動化套件 - 在博文 Opinionated Kubernetes 中瞭解 Knative，該文章描述了 Knative 如何簡化和統一在 Kubernetes 上部署 Web 服務的方式。
- 你可以透過 SIG Security Slack 頻道或 Knative 社群的 security Slack 頻道與 Guard 的維護者聯絡。Knative 社群頻道將很快遷移到 CNCF Slack，頻道名稱為
#knative-security。
這篇文章的目標是邀請 Kubernetes 社群採取行動，引入安全行為監控和控制，以幫助保護基於 Kubernetes 的部署。希望社群作為後續行動能夠：
- 分析不同 Kubernetes 用例中出現的網路挑戰
- 為使用者新增關於如何引入安全行為監控和控制的適當安全文件。
- 考慮如何與能夠幫助使用者監控和控制其易受攻擊服務的工具整合。
參與進來
歡迎你參與進來，加入為 Kubernetes 開發安全行為監控和控制的努力；分享反饋併為程式碼或文件做出貢獻；以及提出或建議任何形式的改進。