摘要

在基於微服務的雲原生架構中，客戶端的一次服務呼叫，會產生包括服務和中介軟體在內的眾多呼叫關係。對這些大量複雜的呼叫過程進行追蹤，對於微服務的安全性分析、故障定位、以及效能提升等，有著重要的作用。

1.   概述

當前的網際網路服務，大多數都是透過複雜的、大規模的分散式叢集來實現，而隨著雲原生、微服務等架構的逐步成熟，傳統的單體架構設計，向著更加松耦合的微服務架構進行演進。同時，考慮到微服務架構下的負載均衡以及高可用等設計，服務間通訊以及呼叫關係的複雜度，將變得異常龐大。

我們看這樣一個搜尋查詢的例子[[1]]，比如前端發起的一個Web查詢請求，其目標將可能是後端的上百個查詢服務，每一個查詢都有自己的index。這個查詢可能會被髮送到多個後端的子系統，這些子系統分別用來進行廣告的處理、拼寫檢查或是查詢一些圖片、影片或新聞這樣的特殊結果。根據每個子系統的查詢結果進行篩選，進而得到最終結果，彙總到返回頁面上。

總的來說，這一次全域性搜尋有可能呼叫上千臺伺服器，涉及多種服務。而且，使用者對搜尋的耗時是很敏感的，而任何一個子系統的低效都將可能影響最終的搜尋耗時，如何在微服務架構下有效的發現並且解決系統的效能瓶頸問題。

同時，一旦前端暴露的服務被攻擊者攻陷，或者是內部某個服務已被攻擊者攻陷，那麼，面對系統內部服務之間龐大複雜的呼叫關係，這些呼叫是否全部是完成這次搜尋所必須發生的業務聯絡？是否存在API探測？API濫用？是否存在針對某個服務的拒絕服務攻擊（DoS）？客戶端服務傳送的請求是否包含注入攻擊？如何在海量的正常業務呼叫邏輯中，發現非法的異常呼叫請求？這些問題將嚴重關係到服務甚至整個系統的安全。

另外，一旦這次請求，最終以失敗的結果返回，那麼如何在這樣錯綜複雜的服務之中，準確的進行故障定位，並且快速的實現故障的修復。

2.   雲原生架構下的可觀察性

為了應對這些問題，可觀察性（Observability）的概念被引入軟體領域。提到可觀察性，通常會引用如下這張經典的圖，日誌（Logging）、監控指標（Metrics）和追蹤（Tracing）構成了可觀察性的三大組成部分。關於日誌和監控，作為傳統的技術方法，本文將不再過多進行介紹，感興趣的讀者可以自行搜尋[[2]]。

圖1 可觀察性組成

對於可觀察性，它和傳統的監控、日誌有什麼區別呢？從可觀察性的三大組成可以看出，一方面，傳統的日誌系統和監控系統，將作為可觀察性的重要組成部分，另一方面，可觀察性還引入了一個很重要的因素，就是對整個系統進行追蹤（Tracing）。一個經典的解釋就是，“監控告訴我們系統的哪些部分不工作了，可觀察性則告訴我們那裡為什麼不工作了”。

在CNCF給出的雲原生參考體系（Cloud Native Landscape）[[3]]中，將可觀察性（Observability）和分析（Analysis）放在了同一個維度。一方面透過實現可觀察性的工具，獲取系統中各個維度的執行資料，從而對整個雲原生架構下的應用執行情況有全面深入的瞭解。另一方面，在擁有了這些資料之後，可以進行安全性分析、運維故障分析、效能分析等。

圖2 Cloud Native Landscape（Observability）

3.   分散式追蹤

分散式追蹤是實現應用鏈路追蹤的一種重要技術手段，同時也是實現雲原生可觀察性的重要組成部分，其主要應用於應用的效能分析（APM，Application Performance Management）和故障定位等。Google在2010年公開其生產環境下的分散式跟蹤系統Dapper[[4]]，奠定了整個分散式追蹤以及APM模型的基礎。

3.1 OpenTracing

隨著微服務、雲原生等應用新架構的發展，分散式追蹤系統的需求以及優勢越來越明顯。為了推進Tracing協議和工具的標準化，統一Trace資料結構和格式，雲原生基金會（CNCF）推出了OpenTracing標準[[5]]。

OpenTracing是一個輕量級的標準化層，位於應用程式/類庫或者追蹤/日誌分析程式之間[[6]]，透過提供平臺無關、廠商無關的API，使得開發人員能夠方便的新增或更換追蹤系統的實現，比如從Zipkin替換成Jaeger或Skywalking等後端。同時，OpenTracing還提供了用於運營支撐系統和針對特定平臺的輔助程式庫。當前OpenTracing得到了來自Uber、Apple等商業公司，以及Zipkin、Jaeger等開源社群的積極響應和推動。

圖3 OpenTracing分層架構圖

從上述架構圖可以看出，基於OpenTracing的分散式追蹤系統，上層的應用程式、類庫、運營支撐服務、遠端呼叫框架等，都可以直接使用OpenTracing定義的標準介面來描述和傳遞分散式追蹤資料，而不必關心具體的OpenTracing以及下層多種Tracers的具體實現。

其後端的追蹤器（Tracers），則可以是任何支援OpenTracing標準的追蹤系統，包括應用鏈路的追蹤、日誌系統、監控系統等。當前支援的典型實現包括CNCF Jaeger、Apache SkyWalking、Instana、LightStep、Datadog等[[7]]。

基於OpenTracing的分散式追蹤系統，有兩個重要的概念：Trace和Span[[8]]。一個Span代表了系統中具有開始時間和執行時長的邏輯執行單元，表示追蹤中的一次操作，Span之間透過巢狀或者順序排列建立邏輯上的因果關係。Span中包含操作名（operationName）、Span ID、當前Span的前一個Span（root span除外）、操作起始與終止時間戳、屬性鍵值對等資訊。在廣義上，一個Trace代表了一個事務或者流程在（分散式）系統中的一次執行過程，每個Trace是由多個Span組成的一個有向無環圖（DAG）。

下面的示意圖簡單直觀的展現了一個典型的Trace過程，同時清晰的描述了Trace和Span的關係。它很好的顯示了元件的呼叫時間，是序列呼叫還是並行呼叫，呼叫間的時間間隔等。

圖4 Trace示例

這種展現方式增加顯示了執行時間的上下文，相關服務間的層次關係，程式或者任務的序列或並行呼叫關係。這樣的檢視有助於發現系統呼叫的關鍵路徑。透過關注關鍵路徑的執行過程，專案團隊可能專注於最佳化路徑中的關鍵位置，最大幅度的提升系統效能。例如：可以透過追蹤一個資源定位的呼叫情況，明確底層的呼叫情況，發現哪些操作有阻塞的情況。

3.2 追蹤器Tracers

自Google Dapper首先提出分散式鏈路追蹤的設計理念以來，許多分散式追蹤工具不斷湧現。當前，常見的分散式追蹤工具包括Dapper，Zipkin，Jaeger，SkyWalking，Canopy，鷹眼，Hydra，Pinpoint等，其中常用的開源分散式追蹤工具為Zipkin，Jaeger，SkyWalking和Pinpoint。這些分散式追蹤工具大致可分為：基於SDK的和基於探針的。

基於SDK的分散式追蹤工具。以Jaeger為例，Jaeger提供了大量可供追蹤使用的API，透過侵入微服務業務的軟體系統，在系統原始碼中新增追蹤模組實現分散式追蹤。此類工具可以最大限度地抓取業務系統中的有效資料，提供了足夠的可參考指標；但其通用性較差，需要針對每個服務進行重新實現，部署成本較高，工作量較大。

基於探針的分散式追蹤工具。以SkyWalking Java探針為例，在使用SkyWalking Java探針時，需將探針檔案打包到容器映象中，並在映象啟動程式中新增-javaagent agent.jar命令實現探針的啟動，以完成SkyWalking在微服務業務上的部署。SkyWalking的Java探針實現原理為位元組碼注入，將需要注入的類檔案轉換成byte陣列，透過設定好的攔截器注入到正在執行的程式中。這種探針透過控制JVM中類載入器的行為，侵入執行時環境實現分散式追蹤。此類工具無需修改業務系統的原始碼，相對SDK有更好的通用性，但其可獲取的有效資料相對SDK類工具較少。

3.3 Jaeger

下面我們以CNCF Jaeger[[9]]為例，簡單看一下追蹤器（Tracer）的一般實現原理。Jaeger是Uber開源的分散式追蹤系統，現在是CNCF的開源專案，併成為CNCF繼Kubernetes、Prometheus、Envoy等之後的第七個畢業專案。

Jaeger專案由Uber公司於2015年建立，目前被整合至眾多的微服務架構當中，每秒負責記錄成千上萬條業務記錄。Uber、Weaveworks、Symantec等20多家組織機構將其引入生產環境。此外，Jaeger還被Red Hat整合至OpenShift Service Mesh等產品當中。

Jaeger於2017年9月被CNCF接納為孵化專案，當前最新版本為1.21。背後有大廠和強大的組織支援，專案目前開發活躍；Jaeger原生支援OpenTracing標準，可以認為是OpenTracing協議的參考實現，支援多種主流語言，可以複用大量的OpenTracing元件。支援雲原生的部署方式，非常容易部署在 Kubernetes 叢集中。

下圖展示的是Jaeger的簡單架構，其主要由Client、Agent、Collector、Data Store、Query等幾個部分組成。其中Jaeger Client為不同語言實現了符合OpenTracing標準的SDK，應用程式透過API寫入資料，Client Library把trace資訊按照應用程式指定的取樣策略傳遞給Jaeger Agent；Jaeger Agent是一個監聽在UDP埠上接收Span資料的守護程式，它會將資料批次傳送給Collector；Collector接收Jaeger Agent傳送來的資料，然後將資料寫入後端儲存。Collector 被設計成無狀態的元件，因此可以同時執行任意數量的Collector。後端的儲存被設計成可插拔的元件，支援Cassandra、Elastic Search。

圖5 Jaeger架構

考慮到分散式追蹤系統本身的效能損耗，一般需要進行取樣設定。Jaeger當前支援四種取樣頻率的設定：包括固定取樣（全取樣或不取樣）、百分比取樣（隨機採百分比數量的樣本）、限制速度取樣（設定每秒取樣幾個traces）、動態設定取樣（可以透過配置從Agent中獲取取樣率的動態設定）。

4. 雲原生應用安全

前文介紹了在雲原生架構下，可以透過分散式追蹤系統，實現對雲原生應用的可觀察性追蹤。根據追蹤資料，進而實現對應用的效能分析、故障定位等。接下來本章將介紹，基於分散式追蹤系統獲取的可觀察性資料，如何實現雲原生應用的安全檢測與防護。

4.1 什麼是雲原生應用安全

應用安全是指應用級別的安全措施，旨在保護應用內的資料或程式碼免遭竊取和劫持。它涵蓋了在應用設計和開發期間發生的安全注意事項，還涉及在應用部署後對其加以保護的系統和方法。

雲原生應用在安全防護上，同樣遵循上述應用安全的建設思路。區別在於，雲原生架構下，應用在自身架構以及開發、運維等管理模式上，發生了一定的變化。因此，安全防護手段也較傳統的應用安全有著一定的區別。

4.2 安全左移

敏捷開發、DevOps等軟體開發方法，加速了應用程式生命週期的迭代，應用的安全開發管理流程也從傳統的SDL邁向了DevSecOps，尤其強調要在更早的軟體開發生命週期，投入更多的安全資源，嵌入安全動作，這樣能更容易的收斂安全漏洞問題，儘可能更早的確定其安全性，這也就是近幾年提及較多的“安全前置”或“安全左移”。

4.3 雲原生工作負載的防護

“安全左移”可以有效的解決應用設計和開發期間發生的安全注意事項，接下來重要的一點，就是在應用部署後，對其加以安全防護。

基於微服務架構的雲原生應用，通常採用Docker、Kubernetes、Service Mesh、Serverless等雲原生計算支撐技術，實現對應用程式的執行支撐。針對這些執行時的安全防護問題，我們可以將其歸類於對雲工作負載的防護範疇中，也就是Gartner所提到的CWPP[[10]]（Cloud Workload Protection Platforms），感興趣的讀者可以針對CWPP做更深入的瞭解，本文將不再過多的展開。

4.4 雲原生應用的API安全

回到雲原生應用的本身，基於微服務的架構設計，使得應用之間的互動模式從Web請求/響應為主轉向各類API的請求/響應，API通訊在雲原生應用互動中佔據了重要的地。因此，API安全也成為了雲原生應用安全中尤為重要的一個部分。

對於雲原生架構下應用的API安全，我們可以採用對API進行全生命週期監測防護的思路，這就包括API的識別、API的脆弱性檢測、API的呼叫追蹤以及API異常呼叫的檢測等。

4.4.1 API的識別和發現

在複雜龐大的微服務之間的API呼叫中，要實現應用的API安全，首先要解決的是API的識別和發現，要能夠知道整個系統中所有的服務都暴露了什麼樣的API，API本身的設計是什麼樣，比如API的URL、引數是什麼，API的認證情況如何。然後把API作為安全防護的一種“資產”，根據發現識別到的API，實現其對應的Pod、Service、應用以及租戶等屬性的關聯，完成API“資產”的梳理。

這個步驟中，分散式追蹤所獲取的鏈路追蹤資訊，則可以天然的解決這個問題，比如在Span的訊息中，可以獲取到相應API呼叫的URL、HTTP Header、HTTP Body等資訊。

圖6 Jaeger追蹤資料示例

4.4.2  API的分析和評估

獲取到了所有的API資訊之後，接下來我們需要對其進行安全性的分析評估。這裡的安全分析既包括API在設計實現上的脆弱性評估，也包括在業務邏輯上安全性、合規性的分析評估。

在脆弱性評估方面，可以參考傳統的API安全方案或者一些API安全檢測工具，例如42Crunch[[11]]，或者一些商業性的API安全掃描產品[[12]]，實現加密連線的檢測、認證授權的檢測、引數校驗的檢測、響應內容檢測等。

圖7 API脆弱性分析示例

在業務邏輯合規性檢測方面，主要包括該服務所暴露的API範圍是否合理，是否暴露了服務必要的API以外的API服務，是否增加了這個層面的攻擊面範圍；在網路側是否實現了相應的訪問控制邏輯，比如原則上某個服務只能訪問另一個服務的某個GET API，可是實際上能夠訪問諸如POST、PUT等其他API，這一點通常會在網路層透過L7防火牆來實現，在應用安全側，我們需要能夠對這種合規性進行檢測分析。

圖8 API訪問控制示例

4.4.3    API的呼叫監控

前面介紹的對API“資產”的識別，API脆弱性、合規性的檢測，我們可以認為是針對單個API的靜態安全性分析，有了這些基礎之後，接下來需要對整個系統中所有服務間的API呼叫行為進行收集。

參考API的識別發現，這裡可以持續的對API呼叫行為進行監控收集。區別在於，在API識別發現的環節，我們通常會以服務為單位，確定某個服務有哪些API，API會有哪些脆弱性等。在這一步的監控，我們關注的重點基本和分散式追蹤是一致的，我們也將以一次完整的請求執行過程，也就是一個Trace為單位，監控這一次Trace請求的API呼叫鏈，以及某一個呼叫會屬於哪個請求Trace等。

4.4.4    API的行為模型學習

透過分散式追蹤系統收集到API呼叫資料後，首先對其進行預處理，篩選出相關有用的資料欄位後，根據歷史資料利用機器學習或統計學的方法，訓練出業務系統中API的呼叫行為，比如基於API呼叫鏈、呼叫時間、響應時間、呼叫引數等屬性，形成正常情況下的API呼叫行為畫像，並生成與業務系統正常行為匹配的特徵資料。

這裡進行訓練的先驗知識為，我們認為業務系統中大量存在的行為是正常行為，而數量很少的行為是異常行為。在訓練過程中，需要根據專家知識對訓練結果的檢驗不斷調整訓練模型的引數。

4.4.5    API的異常檢測

至此，我們就已經有了業務系統中正常的API呼叫行為資料了，將業務系統當前資料與特徵資料庫中資料進行檢索匹配，並利用序列相似性計算等方法找出特徵資料庫中與當前行為最為匹配的特徵資料。

檢測引擎需要將特徵資料與當前資料的相似性與基線進行比較，若比較結果顯示當前行為與正常行為的差異在基線限制範圍內，則為正常行為，若超出基線限制範圍，則判定為異常行為。

對於基線，首先需要根據專家知識設定合理的初始基線，並根據不同場景，或利用無監督模型自行調整基線，或由運維人員手動維護基線。

4.5  基於Jaeger的API異常檢測示例

下面我們以Jaeger為例，簡單看一下如何基於分散式追蹤系統，實現雲原生應用的API安全檢測。

如下圖所示，透過Jaeger對應用程式的追蹤，我們可以獲取相關的API呼叫資料（圖中綠色部分），結合這些資料，就可以生成對應的特徵資料以及進行諸如序列邏輯異常、API引數異常、API呼叫頻率異常等異常檢測。

比如，對於呼叫邏輯異常，當攻擊者採用某些方法使API呼叫的邏輯順序出現異常，包括關鍵呼叫步驟缺失，顛倒等。這樣在API呼叫序列中就會出現缺失關鍵步驟的情況，具體細節介紹可參考[[13]]。

圖9 基於Jaeger的API異常檢測示例

5.   總結

基於微服務的雲原生架構，使得服務間的通訊變的異常複雜，給雲原生應用的安全檢測和防護帶來了巨大的挑戰。

分散式追蹤是實現應用鏈路追蹤的一種重要技術手段，同時也是實現雲原生可觀察性的重要組成部分，實現了微服務間鏈路的可見可觀測。

基於追蹤資料，結合經典的安全檢測方法以及機器學習等大資料分析技術，可以有效的解決雲原生應用安全問題。

參考文獻

[1] https://bigbully.github.io/Dapper-translation

[2] https://mp.weixin.qq.com/s/WOWYaUeToTvzOUPEYASaug

[3] https://landscape.cncf.io

[4] https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/36356.pdf

[5] https://opentracing.io

[6] https://opentracing.io/docs/best-practices

[7] https://opentracing.io/docs/supported-tracers

[8] https://wu-sheng.gitbooks.io/opentracing-io/content/pages/spec.html

[9] https://www.jaegertracing.io

[10] https://www.gartner.com/en/documents/3983483

[11] https://42crunch.com

[12] https://www.nsfocus.com.cn/html/2019/209_1009/66.html

[13] https://mp.weixin.qq.com/s/6ZQvWRn4Fti-szOvffaasg