你關心的“云原生API安全”問題，答案在這里

一. 概述

云原生技術的迅猛發展已經在全球各行各業中得到積極的應用實踐。Gartner報告指出，到2025年，超過95%的新云工作負載將部署在云原生平臺上。然而，由于應用架構的變革，在遵循面向微服務化的設計方式的前提下，功能組件化、服務API數量的激增，以及配置的復雜性等問題也隨之而來。這些架構變化導致了傳統Web請求/響應的服務交互模式向API請求/響應的服務交互模式的轉變，如RESTful/HTTP、gRPC、GraphQL等。因此，在未來的云原生環境中，API將作為主要的服務交互載體被大規模企業用戶使用。

另一方面，從近年的安全事件來看，API安全問題呈現上升的態勢，嚴重威脅了用戶的隱私和數據安全。一些典型的安全事件包括：2019年11月，國外安全人員發現超過2.67億條Facebook ID、電話號碼和姓名等信息被存儲在某公開數據庫中。相關研究顯示，該數據庫通過某未知API接口抓取，而非來自公開信息。2020年4月，視頻會議服務廠商Zoom被爆出多項安全漏洞，其中包括Facebook Graph API濫用導致隱私數據泄露問題。2021年4月，Facebook 5億用戶數據泄露，據暗網上公布的數據截圖，涉及到用戶昵稱、郵箱、電話等信息。2021年6月，國外社交網絡服務網站LinkedIn爆發大規模數據泄露事件，近7億用戶信息在暗網上被售賣，據相關研究人員證實，攻擊者最終是利用LinkedIn的某一API獲取到用戶的敏感數據。2021年12月，國內某證券公司的客戶信息，包括用戶姓名、手機號等敏感數據以每日1萬條的量級在數據交易平臺被售賣，經驗證分析，證實為內部系統數據API管控疏忽導致。2022年4月，WordPress插件Rank Math爆出嚴重的API安全漏洞，借此漏洞可以直接修改用戶數據庫表信息。

根據云安全聯盟（CSA）發布的云原生技術標準模型[2]（如圖1所示），我們可以看出橫軸是開發運營安全的維度，涉及需求設計、開發、運營階段，細分為需求、設計、編碼、測試、集成、交付、防護、檢測和響應階段。縱軸則按照云原生系統和技術的層次進行劃分，包括容器基礎設施安全、容器編排平臺安全、微服務安全、服務網格安全、無服務器計算安全五個部分。安全機制（藍色標注部分）基本上覆蓋了全生命周期的云原生安全要求。

圖1. 云安全聯盟（CSA）發布的云原生技術標準模型

容器安全產品在國內市場中，容器基礎設施安全和容器編排平臺安全的方案成熟度比較高，也得到廣泛的應用和驗證，而微服務安全、服務網格安全以及無服務器安全領域的成熟度則相對較低。

未來，微服務間必然會使用大量API進行交互，這些API可能產生于FaaS函數、容器應用、Pod等載體中。相應地，云原生API安全風險將隨著云原生環境的進一步發展而不斷增加，因此API安全的需求也將逐漸增多。在這種背景下，API安全對于保護整個云原生環境的安全性至關重要，將成為云原生安全的下一個重要階段。

本文將圍繞云原生API所面臨的安全風險以及相應的防護思路進行探討，并介紹綠盟科技在云原生API安全防護上的一些思考與技術方案。希望這些內容能為各位讀者帶來一些啟發與思考。

二. 云原生API安全風險

云原生API安全風險應當從缺乏可見性、應用架構變化、東西向流量難以防護這幾個方面去考慮。

2.1 缺乏可見性導致的風險

云原生環境中，由于微服務數量增多，每個微服務包含多個API，因此微服務之間的API調用變得更加復雜。這種情況下，整個API系統的可見性變得缺乏，這可能導致以下幾個問題：

首先，API資產存在不可見性，當API資產受到黑客攻擊時，很難及時定位入侵位置，從而錯過最佳處理時間，增加安全風險。

其次，API異常行為也缺乏可見性，例如高頻訪問某API或利用API的未授權訪問漏洞進行大量數據下載等異常行為。這些行為可能導致接口不穩定或敏感數據泄露的風險。

最后，隨著微服務應用架構的普及，東西向流量交互增多導致API數量激增，API權限管理變得更為復雜，由API調用鏈組合導致的權限繞過問題成為API業務安全的防護難題。

2.2 應用架構變化導致的風險

我們知道，新應用架構遵循微服務化的設計模式，通過應用的微服務化，我們能夠構建容錯性好、易于管理的松耦合系統，與此同時，新應用架構的出現也會引入新的風險，本文將從數據泄露風險、未授權訪問風險、被拒絕服務風險三方面進行介紹[1]。

2.2.1數據泄露風險

當單體應用被拆分為若干個服務后，這些服務會根據業務情況進行相互訪問，API訪問范圍變為服務到服務（Service to Service），若某服務因API漏洞導致攻擊者有利可圖，那么攻擊者將會看到應用內部的流量，這無疑為攻擊者提供了更多的攻擊渠道，因而針對數據泄露的風險程度而言，微服務架構相比傳統單體應用架構帶來的風險更大。此外，隨著服務數量達到一定規模，API數量將不斷遞增，進而擴大了攻擊面，增大了數據泄露的風險。

傳統單體應用架構中，由于網絡拓撲相對簡單，且應用通信多基于HTTP/HTTPS，因而造成的數據泄露風險多是因為采用了HTTP協議。微服務應用架構中，網絡拓撲相對復雜，因遵循分布式的特點，應用間的通信不僅采用HTTP/HTTPS協議，還采用gRPC等協議，由于gRPC協議默認不加密，因而將會導致攻擊面的增多，為數據泄露帶來了更多的風險。

2.2.2未授權訪問風險

在單體應用架構下，應用作為一個整體對用戶進行認證授權，且應用的訪問來源相對單一，基本為瀏覽器，因而風險是相對可控的，微服務應用架構下，其包含的所有服務均需對各自的訪問進行授權，從而明確當前用戶的訪問控制權限，此外，服務的訪問來源除了用戶外還包含內部的其他服務，因而在微服務架構下，應用的認證授權機制更為復雜，為云原生應用帶來了更多的攻擊面。

微服務應用架構下，由于訪問權限還需涉及服務對服務這一層面，因此將會導致權限映射關系變得更加復雜，相應的權限配置難度也在同步增加，例如一個復雜應用被拆分為100個服務，運維人員需要嚴密地對每個服務賦予其應有的權限，如果因疏忽導致為某個服務配置了錯誤的權限，攻擊者就有可能利用此缺陷對服務展開攻擊，若該服務中包含漏洞，進而可能會導致單一漏洞擴展至整個應用的風險。所以如何對云原生應用的訪問權限進行高效率管理成為了一個較難的問題，這也是導致其風險的關鍵因素。

2.2.3被拒絕服務風險

在微服務應用架構下，由于API數量會隨著服務數量的遞增而遞增，因而可能將會導致單一請求生成數以萬計的復雜中間層和后端服務調用，進而更容易引起被拒絕服務的風險，例如若微服務應用的API設計未考慮太多因單個API調用引起的耗時問題，那么當外部訪問量突增時，將會導致訪問需求與資源能力不匹配的問題，使服務端無法對請求作出及時的響應，造成頁面卡死的現象，進而會引起系統崩潰的風險。

2.3 東西向流量難以防護的風險

圖2. 云原生環境下的東西向流量

云原生應用場景下的流量不僅包含傳統基于邊界的南北向流量，還包含集群節點間，微服務間訪問的東西向流量，如果攻擊者通過漏洞利用攻入集群內部，進而可能通過利用脆弱的認證機制橫向移動入侵至其他微服務導致集群整體的癱瘓。

2.4其他風險

在云原生環境中，由于API的類型種類繁多，包括影子API、僵尸API、東西向API、南北向API、公共API、內部API等，而且它們的迭代周期非常短，后端架構也更為復雜，因此管理起來更為困難。

此外，傳統的安全設備很難適配API使用的其他協議，例如gRPC、SOAP、GraphQL等。這些協議的出現使得云原生環境下的API安全風險進一步上升。

三. 云原生API安全防護思路

在討論云原生API安全防護具體思路前，綠盟君想先提出云原生API安全防護的必要性，以下幾個問題可能是讀者普遍比較擔憂的幾個問題：

問題一. 我的容器基礎設施已經有了安全保護，但業務部門運行的是微服務、服務網格和無服務，這些新的服務如何治理，安全性如何保證？

問題二. 我有硬件、虛擬化或其他南北向的WAF了，但東西向的微服務安全怎么辦？

問題三. WAF能解決所有的API問題嗎？

帶著以上問題，綠盟君梳理了一些防護思路，下文將做具體介紹。

API是微服務架構中通信的重要媒介，在云原生環境中，微服務通常以容器或Pod的形式出現，這些微服務在容器編排平臺，例如Kubernetes或OpenShift中運行，或者運行在服務網格（Service Mesh）中。因此，在云原生API安全防護方面，需要考慮容器編排平臺和服務網格兩種場景下的安全防護措施。

3.1 Kubernetes場景

圖3. Kubernetes場景防護方案

Kubernetes場景中，常有的防護方案是在Kubernetes Ingress Controller前串行部署API安全網關用于處理惡意流量， 此時，API安全網關核心能力為WAF的能力，開源的API網關如Ambassador、Gloo、Envoy Gateway等雖然也集成了一部分的安全能力，但缺陷是集成的防護規則相對較弱，許多傳統安全廠商選擇將其WAF產品容器化，并充分利用K8S的負載均衡和自動擴縮容能力提升高可用性。

然而，以上提出的方案實際也存在著一些問題，主要有以下幾方面：

首先，安全網關部署位置實際仍處于集群邊界處，與傳統安全網關部署位置相同，僅能對微服務的南北向流量進行防護，無法進行全向流量防護；

其次，采用WAF進行防護僅能處理7層惡意流量，并且無法覆蓋OWASP API Security Top 10中的所有風險。在云原生環境中，微服務間通信協議還包括各類RPC調用，如Google的gRPC、阿里的Dubbo、Facebook的Thrift RPC等，此外還存在GraphQL、SOAP等通信協議，這些都是WAF無法進行防護的；

最后，云原生環境下，如果微服務訪問采用加密流量，由于其數量可能會很多，傳統WAF的證書卸載功能因為缺乏證書統一管理模塊，因而并不一定適用于云原生場景，因此我們認為該方案在某種程度上無法處理微服務加密流量。

3.2 Service Mesh場景

3.2.1 安全能力容器化，通過引流將業務流量牽引至安全容器

圖4.Istio安全架構圖

圖4為Istio的安全架構圖，我們知道Istio的數據平面主要通過Envoy代理容器實現流量管理、安全能力以及可觀測性能力，安全方面主要提供以下機制：

1. 服務間及外部服務間多種認證授權機制；

2. 證書管理機制、加密流量卸載機制；

3. Envoy提供CSRF、外部授權服務器（ext_auth filter，連接如WAF設備）、限流等HTTP安全過濾器。

圖5.Envoy安全類Filter

由圖5我們可以看出Envoy自有的安全能力并不夠，可行的一種方案是通過Envoy的引流filter引流到外部的安全容器，那么這個時候將傳統的WAF容器化是一個較好的選擇，WAF也可以充分利用K8S的LB進行動態擴縮容。方案如圖6所示：

圖6. 通過Envoy引流Filter實現的方案

該方案通過Envoy容器進行流量牽引，使得所有集群服務的流量都經過了WAF的檢測，具備了對東西向流量的檢測優勢。然而，這種方案也存在一些缺陷，其中最明顯的就是Envoy引流插件的性能問題，即如何保證它能夠承受大規模并發流量，并且防止服務宕機等問題。因此，針對這方面進行深入研究是非常有必要的。

3.2.2安全能力集成至現有Sidecar容器

另一個思路是復用服務網格自身提供的擴展能力，如Envoy的擴展能力，實現將安全能力集成至現有的Sidecar容器，我們將可以復用的Envoy擴展梳理為以下三種：

圖7. Envoy擴展能力總結

3.2.3 安全能力Sidecar化

最后一種思路是將安全能力Sidecar化，我們知道Istio提供Sidecar自動注入能力，我們可以通過修改Istio注入模板，將安全能力作為Sidecar容器放置在現有Service數據平面中，如圖8所示：

圖8. 安全能力Sidecar化示意圖

上述思路，通過一定的策略管理，Service Mesh可接管微服務的流量治理、監控及追蹤甚至具備一定的基礎防護能力，安全容器以輕量級安全伴生容器的方式透明注入至微服務中，并隨著微服務資源的變化而變化，不僅可與現有服務網格治理框架高度兼容，也能進一步提升服務網格在流量側的全向安全防護能力。此外，也能帶來一些額外的優勢，如：

1. 爆炸半徑更小 — 爆炸半徑僅限于一個微服務，即使安全容器因各種因素停止運行，由于安全容器于微服務內部運行，因而不會影響其他業務的正常運行。

2. 代理維護成本低 — 利用容器編排工具現有的滾動升級更新、灰度發布等機制，無需額外進行開發維護。

3. 安全邊界更清晰 — 安全容器僅對位于同一微服務中的業務應用進行防護，與應用具有相同的IP地址。

4. 代理資源消耗依賴應用負載自身的變化 — 傳統安全網關如WAF可能會存在不同站點流量搶奪的問題，即若有站點占用了較高的流量，消耗了WAF的所有資源，則其他站點流經的惡意流量將不會被處理，導致WAF無法正常工作，安全容器Sidecar化這種方式可通過配置微服務資源消耗占比有效應對此場景。

5. 容器級別的隔離防護 — 安全容器的方式可以讓內核在容器級別執行所有的安全防護能力。

然而，該方案也存在一定的性能問題，比如高并發流量場景下，安全容器處理惡意流量會占用大量CPU和內存，導致超過節點承受最大閾值，即便安全網關容器不處理惡意流量也會占用一定內存和CPU，引起不必要的性能消耗；此外，針對Kubernetes集群容器數量有一定限制的場景下，會影響正常業務的運行（如100個容器中，單安全容器就占用50個），再如這種方式將會導致請求鏈路增加，最終導致吞吐量降低和延遲升高

四. 云原生API安全解決方案

技術實現上，我們提供了兩種解決方案，分別支持Kubernetes以及Service Mesh場景，如圖9所示：

圖左為適配于Service Mesh的微API安全網關方案，安全能力采用輕量級的方式，無感知地接入每個微服務應用中，根據集群具體業務不同，可采用不同的API安全模塊進行精準防護。此方案與Service Mesh配合使用，能夠快速將微API安全網關注入至每個微服務應用中，同時對集群中的每個微API安全網關運行數據進行管理面上統一分析，并通過安全編排層進行服務策略編排，實現基于微服務粒度的全向安全防護能力，圖右為適配于Kubernetes的節點API安全網關方案，該方案采用eBPF技術將集群微服務引流從用戶空間offload至內核層實現，降低系統CPU消耗的同時，提升了處理性能，也同時支持全向流量安全防護及靈活的策略編排。

圖9. 解決方案簡要示意圖

五. 總結

Gartner早在2020年1月就提出了CNAPP（Cloud Native Application Protection Platform 云原生應用防護平臺）的術語，其集合了CWPP和CSPM的功能，重點強調了云應用安全防護的重要性，綠盟君認為，云原生API安全可有效針對微服務進行應用層面防護，是企業構建CNAPP過程的必經階段，也是未來構建云原生應用安全（微服務安全、服務網格安全、FaaS安全）必不可少的一環。此外，云原生API安全不應僅具備基于網絡層面的威脅檢測能力，還應集成API業務安全能力，以應對通過微服務業務邏輯漏洞對微服務進行攻擊的風險，減少經濟損失。最后，我們常說可見才可防，API資產發現能力、分類分級能力和微服務可觀測性等技術為API安全提供了有利的土壤，這些也是實現云原生API安全重要組成部分。