云原生環境下的API業務安全思考 - 網安 - 專業的網絡安全產業、社區、知識平臺

一. 概述

針對單體架構的應用，安全防護往往在邊界網關設備處。隨著業務需求的不斷變化以及技術的持續更新，企業應用開始從單體架構向微服務架構轉變。不同應用模塊可以根據業務規模進行動態擴縮容，與此同時，微服務應用也為API安全防護帶來了新的挑戰。

筆者認為，微服務應用API安全防護相比傳統API安全防護主要增加了以下幾類挑戰：

1. 隨著服務更細顆粒度的劃分，API接口的數量激增及調用關系的復雜，API管理將變得更加困難；

2. 服務間調用的不斷增多使得利用API漏洞進行橫向攻擊的風險也不斷增加，從而增加了防御難度；

3. 傳統防御方式往往是在網絡邊界對南北向的流量進行檢測，微服務間產生的東西向流量無法通過傳統邊界防御的方式檢測；

如上所述，我們需要一種更細粒度的適用于微服務環境下的全流量的API防護方法。本文將首先介紹傳統應用API

安全防護方法，進而引出云原生環境下微服務應用API安全防護方法，最后通過實際案例對微服務應用API安全防護方法進行剖析解讀，希望可以引發大家更多的思考。

二. API安全防護

API（ApplicationProgramming Interface）作為程序之間交互的橋梁，承擔著數據傳輸的重大作用。越來越多的安全問題都來自于API泄露，API設計缺陷等問題。微服務環境下，API數量的激增為系統的安全風險帶來新的挑戰。OWASP組織總結的API

對于API防護也主要集中在以下幾個方面：

1. 身份認證：可靠的身份認證及權限控制機制

2. 訪問控制：對發起請求的對象，請求的速率進行準確的訪問控制

3. 安全防護：傳統Web安全風險的防護，SQL注入，XSS，CSRF等

4. 日志記錄：對請求的鏈路進行完善的日志記錄

5. 配置管理：對API 參數、調用鏈路、版本等進行有效管理

三. 傳統API防護方案

在傳統的網絡架構中，內外網一般有明確的網絡邊界。常見的安全防護設備，例如WAF，防火墻，API網關等，都會在網絡邊界搭建來實現安全防護。主要防護進出內網的南北向流量，對于集群內部的API調用行為無法做到有效的防護。因此，一旦網絡內部的一臺機器的淪陷，會導致整個邊界類型的API防護機制的失效。

圖1

四. 微服務應用API治理與安全防護

在微服務環境下，存在著大量的服務之間的調用。這時，內部服務的API調用的安全風險就不得不考慮進去。同時，在云原生環境中，內外網邊界逐漸模糊，更多的API會暴露在云上。隨著API暴露面的增加，API被攻擊的風險也大大增加，傳統的南北向的邊界流量的防護體系在云原生環境下的防護將會顯得力不從心。因此我們需要一種更細粒度的適用于微服務環境下的全流量的API防護的方案。

4.1 微服務治理

在微服務環境下，面對眾多數據的微服務API，我們首先要解決的就是服務發現以及負載均衡的問題。

即如何發現服務的提供者、如何轉發服務調用方發起的請求。目前業界主要有三種服務發現的模式。

1.集中代理

提供統一代理入口，一般通過域名解析的方式由集中代理實現服務的負載均衡轉發

2.客戶端代理

該模式通過獨立中心的服務注冊組件實現服務發現，負載均衡是在客戶端自己獨自實現

3.Service Mesh模式

該模式和客戶端代理模式有點相似，也是通過獨立中心的服務注冊組件實現服務發現，但是負載均衡是使用單獨的進程，通常被稱為Sidecar，統一實現。

集中代理模式，對業務變動較小，實現較為簡單，但是存在集中單點的風險，且對集中代理的要求較高。客戶端代理模式可以有效解決集中代理的單點的問題，同時直接調用服務提供者，可以降低網絡開銷，但是負載均衡需要自己實現，提升了實現復雜度，客戶端比較復雜，不易于管理。Service

Mesh彌補了兩者的不足，通過Sidecar的模式做到負載均衡的統一。

4.2 Service Mesh

ServiceMesh這個詞的創始人William Morgan對ServiceMesh定義是：

“服務網格是一個基礎設施層，用于處理服務間通信。云原生應用有著復雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭。在實際應用當中，服務網格通常是由一系列輕量級的網絡代理組成的，它們與應用程序部署在一起，但對應用程序透明。”

Service Mesh 在微服務的基礎上加上了一個網絡代理，所有的流量都在Sidecar上完成，Sidecar完成服務發現，負載均衡，智能路由，故障注入，熔斷等動能，從而微服務只需要注重業務實現。

Service Mesh的架構如下圖2所示：

圖2

從該架構可以看出，Service

Mesh架構的設計為安全防護提供了很好的入口

，在Sidecar中，我們可以完成上文提到的身份認證、訪問控制、訪問控制、日志記錄、配置管理等API防護功能。目前比較知名的項目有Linkerd，Envoy，Istio，HashiCorp

Consul等。

4.3 Istio

Istio[2]就是目前受Google/IBM

等大廠支持和推進的一個 ServiceMesh開源框架組合。Istio

提供一種簡單的方式來為已部署的服務建立網絡，該網絡具有負載均衡、服務間認證、監控等功能，而不需要對服務的代碼做任何改動。Istio官方[3]對Istio的架構描述如下圖3：

Istio在邏輯上分為數據平面和控制平面，控制平面主要實現微服務管理需要的服務發現的功能，數據平面的Envoy以Sidecar的模式提供負載均衡的功能。

圖3

4.4 Envoy

其中Envoy[3]是Istio的核心組件之一，以Sidecar的方式與服務運行在一起，對服務的流量進行攔截轉發。具有路由，流量控制等強大特性。Envoy主要面向SOA（面向服務的架構）的網絡代理，所以非常適用于微服務，其主要是用來調解ServiceMesh中所有服務的入站和出站流量。

圖4

Envoy流量走向，從上圖4可以看出，所有流經后端業務容器的流量都會被Envoy劫持，流經各種Envoy的過濾器（EnvoyFilter），最終流量再轉發到業務容器。Envoy的流量處理都是通過各種過濾器來實現。

過濾器分為兩個類別：

1. 網絡過濾器（L3/L4），是Envoy網絡連接處理的核心

2. HTTP過濾器（L7），由特殊的網絡過濾器HttpConnectionManager管理，專門處理HTTP1/HTTP2/gRPC請求

關于Envoy的詳細介紹可以參閱往期文章：【Istio系列二：Envoy組件分析】

4.5 安全防護

雖然Service

Mesh架構的出現，有效解決了微服務治理的問題，但是還是缺失API安全風險防護所需的訪問控制、安全防護等功能。得益于Envoy接管了進出微服務的所有的流量以及Envoy的過濾器的機制，只需要在Envoy的過濾器中實現API安全防護的能力，我們就得到了一個微服務環境下的全流量的安全防護體系。

圖5

數據平面數據流走向如圖5所示：

1. 請求發送至Pod,Envoy截獲此請求

2. 請求經過Envoy事先定義的 Filter，Envoyfilter官方提供了多種實現方式[4]，常用的有lua，wasm等

3. Filter對請求流量進行檢測，判斷是否是惡意流量，對非法行為直接阻攔，合法行為放行轉發到業務容器

4. 業務容器接受到正常請求處理完，返回響應報文

5. Filter對響應流量進行檢測，判斷是否是惡意流量，對非法行為直接阻攔，合法行為放行響應給請求方

五. 案例

號鏈接特性”與“Kubernetes自身代碼邏輯”兩部分結合的產物。符號鏈接引起的問題并不新鮮，這里它與虛擬化隔離技術碰撞出了逃逸問題，以前還曾有過在傳統主機安全領域與SUID概念碰撞出的權限提升問題等[11]。

5.1 內置過濾器

通過內置過濾器，我們可以在不編寫代碼的前提下，只需要通過配置項，就可以對流經Envoy的API請求進行防護。

假設為了解決數據安全風險，某請求接口需要添加token，利用Envoy的過濾器就可以對特定請求添加token。

具體EnvoyFilter配置如下：

```yamlapiVersion:networking.istio.io/v1alpha3kind:EnvoyFiltermetadata:  name: add-header  namespace: spec:  configPatches:  - applyTo: VIRTUAL_HOST    match:      context: SIDECAR_OUTBOUND      routeConfiguration:        vhost:          name: www.test.com:8080          route:            name: default    patch:      operation: MERGE      value:        request_headers_to_add:        - append: true          header:            key: "X-AUTH-TOKEN"            value: token
```

5.2 自定義過濾器

在更復雜的場景下，通過Envoy默認的Filter無法達到我們的需求，這時候我們希望能通過自定義的代碼來實現更定制化的業務邏輯。

通過Envoy提供的lua或者wasm的過濾器。我們可以直接編寫lua代碼，或者將C++、resty代碼編譯成WebAssembly代碼，實現自定義的過濾器。

假設發現特定接口有信息泄露的風險，在服務修復前，需要對調用該接口的所有請求進行攔截處理。利用Envoy的http_filter的 lua擴展，我們可以很容易的對包含特定特征的請求進行攔截。

具體EnvoyFilter配置如下：

```yamlapiVersion:networking.istio.io/v1alpha3kind:EnvoyFiltermetadata:  name: test-envoyfilter  namespace: test-filterspec:  configPatches:    # The first patch adds the lua filter tothe listener/http connection manager  - applyTo: HTTP_FILTER    match:      context: GATEWAY      listener:       filterChain:         filter:           name: envoy.filters.network.http_connection_manager           subFilter:              name: envoy.filters.http.router    patch:      operation: INSERT_BEFORE      value:        name: envoy.filters.http.lua        typed_config:          "@type":type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua          inline_code: |            functionenvoy_on_request(request_handle)              ifrequest_handle:headers():get(":path") == "/xss" then               request_handle:respond({[":status"] ="403"},"ok")              end            end            functionenvoy_on_response(response_handle)            end```

更為完整的采用lua過濾器完成API防護的可以參考開源項目curiefense[5]的實現。

六. 總結

在云原生環境下，利用Service Mesh的架構，在Sidecar提供負載均衡，路由的同時，同時提供API安全防護的能力，可以不僅防護南北向的流量，也可以提供東西向的全流量的安全防護，有效保證的云原生應用的安全性。

參考文獻

[1] https://owasp.org/www-project-api-security/

[2] https://istio.io

[3] https://www.envoyproxy.io/

[4] https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/filter/filter

[5] https://www.curiefense.io/