《云原生安全： 攻防實踐與體系構建》解讀：業務安全篇
《云原生安全： 攻防實踐與體系構建》解讀：業務安全篇
隨著云原生技術的發展，業務系統從原有的單體架構逐步轉換為微服務架構。微服務架構使應用的開發和業務的擴展變得更加便利，同時也帶來了許多新的安全問題。那么，生長在云原生環境下的業務系統面臨著哪些安全隱患？攻擊者如何利用這些隱患對業務系統進行攻擊？針對所存在的隱患和可能面臨的攻擊如何進行異常檢測和安全防護？各位讀者將在《云原生安全：攻防實踐與體系構建》書籍中找到答案。
微服務架構為業務系統帶來了新的安全隱患
01
由于微服務架構剛好符合開發者所期盼的業務抽象能力，面向微服務的開發已經被眾多開發者所選擇，業務系統微服務化已經成為不可避免的趨勢。在享受微服務為開發帶來便捷的同時，安全性也成為了不可忽視的問題。若是業務系統出現安全問題，由于微服務架構整個應用被分成多個服務，定位故障點將會非常困難。而且，微服務架構中一個服務出現故障可能會產生雪崩效應，導致整個業務癱瘓。
盡管上述情況是我們需要極力避免的，但其在實際微服務業務系統中卻極有可能會發生。從攻擊者的角度來看，微服務業務系統所包含的服務數量眾多，服務間通過API進行通信使得暴露端口數量多，攻擊面更大，與單體架構應用相比可滲透的機會更多。從防守方角度說，微服務的組織結構更加復雜，導致防守策略的設計和防守方案的部署也變得更加困難。
部署在云原生環境下的業務系統面臨的風險
02
筆者看來，云原生應用風險主要是Web應用風險，即網絡層面的風險，而云原生應用業務風險無明顯的網絡攻擊特征，多是利用業務系統的漏洞或規則對業務系統進行攻擊來牟利，從而造成一定的損失。
此外，與傳統應用架構中的業務風險不同，微服務應用架構中，若服務間的安全措施不完善，例如用戶授權不恰當、請求來源校驗不嚴格等，將會導致針對微服務業務層面的攻擊變得更加容易，例如針對一個電商應用，攻擊者可以對特定的服務進行攻擊，例如通過API傳入非法數據，或者直接修改服務的數據庫系統等。攻擊者可以繞過驗證碼服務，直接調用訂單管理服務來進行薅羊毛等惡意操作。攻擊者甚至可以通過直接修改訂單管理和支付所對應的服務系統，繞過支付的步驟，直接成功購買商品等。
綜上，筆者認為，應用微服務化的設計模式帶來的業務風險可包含兩方面，一方面是未授權訪問風險，典型場景為攻擊者通過權限繞過對業務系統的關鍵參數進行修改從而造成業務損失，另一方面則是API濫用的風險，典型的是對業務系統的薅羊毛操作。
未授權訪問的風險
云原生業務環境中，筆者針對造成未授權訪問風險的原因進行了分析，可以大致分為業務參數異常和業務邏輯異常兩方面，為了更為清晰的說明上述異常如何導致未授權訪問的風險，筆者以一個微服務架構的電商系統舉例說明。如圖1所示：
圖1 電商系統業務流程圖
業務參數異常。API調用過程中往往會傳遞相關的參數。參數的取值根據業務場景的不同會有不同的取值范圍。例如商品數量必須為非負整數，價格必須大于0等。如果API對相應參數的監測機制不完善，那么攻擊者往往可以通過輸入異常參數導致業務系統受到損失。例如在電商系統中，如果商品價格只在商品介紹服務中進行校驗，而在訂單管理和支付服務中沒有進行校驗，那么攻擊者就可以通過直接調用訂單管理和支付服務的API來將訂單價格修改為0元或者負值，給業務系統造成損失。
業務邏輯異常。相比于前兩類異常，這類異常一般較為隱蔽。攻擊者采用某些方法使API調用的邏輯順序出現異常，包括關鍵調用步驟缺失、顛倒等。例如在電商系統中，攻擊者可以利用漏洞繞過交費的步驟直接提交訂單。這樣就會出現業務邏輯出現關鍵步驟缺失的情況。對于前述業務頻率異常中的驗證碼繞過異常，也屬于業務邏輯異常。
API濫用的風險
針對此類風險，通常指的是攻擊者對業務系統的薅羊毛操作，風險成因則是由于業務頻率異常所致，這里筆者依然以電商系統舉例說明。
針對一個或者一組API的頻繁調用。業務系統往往通過圖形驗證碼的方式來避免機器人刷單的操作。攻擊者可以繞過驗證碼所對應的微服務，直接對訂單進行操作，進而實現機器刷單，對電商進行薅羊毛。
基于基線對業務系統進行異常檢測
03
為了應對微服務業務系統所面臨的安全風險，基于基線的異常檢測是一類比較有效的方法：首先建立正常業務行為與參數的基線，進而找出偏移基線的異常業務操作，其中，基線的建立需要結合業務系統的特性和專家知識共同來完成。
為此，我們設計了基于基線的異常檢測方案。
圖2 業務異常檢測引擎設計圖
此方案中各個模塊的功能為：
分布式追蹤工具。采集微服務業務系統運行時生成的數據。目前常用的開源分布式追蹤工具有Jaeger和Skywalking，它們對異常檢測上的幫助各有所長。Jaeger在部署上對軟件系統有較強的侵入性，需要在代碼中進行插樁，但可以獲取完整的數據信息。Skywalking與Jaeger相比，可以獲取的數據信息更少，比如無法獲取HTTP請求體信息，但其采用了字節碼注入技術，通過控制虛擬機的類加載器完成追蹤與數據采集，無需修改業務系統的源代碼。此外，也可以選擇sidecar截取業務容器上下游的流量信息進行數據采集，但目前sidecar無法獨立實現追蹤功能，獲取的數據集中沒有API調用樹（TraceID）信息，需要利用算法對追蹤序列進行還原。由于業務系統自身采用的分布式追蹤工具是不同的，而且其中有些業務系統沒有部署追蹤工具，檢測引擎需要適配不同的追蹤工具，在所能獲取到的數據字段下最大程度的覆蓋多種場景的異常檢測。
數據篩選與整合模塊。過濾數據集中的臟數據，并提取出可以表示業務系統行為的數據字段。
數據訓練模塊。利用機器學習或統計學的方法，訓練出業務系統中的正常行為，并生成與業務系統正常行為匹配的特征數據。在訓練過程中，需要根據專家知識對訓練結果進行檢驗并不斷調整訓練模型的參數。
檢測引擎。將業務系統當前數據與特征數據庫中數據進行檢索匹配，并將檢索出的特征數據與當前數據的相似度同基線進行比較，進而檢測出偏移基線的異常業務操作。初始基線需要由安全專家設置，基線的維護則需要根據業務的特性采用不同的方法，常用的維護方法包括利用無監督的機器學習模型自動維護以及由運維人員手動維護。
總結
04
業務在明，黑產在暗，本身在對抗層面防守方就處于劣勢，黑產有充足的時間通過小規模的試探摸清線上的業務規則，從而進行后續大規模的出擊。在這種劣勢條件下，怎樣走在黑產的前面將防護工作做好，保障微服務業務的安全，仍舊是一項巨大挑戰。《云原生安全：攻防實踐與體系構建》書籍中融合了筆者以及其他作者在業務安全上的研究經驗，盼望此書籍可為廣大讀者在微服務業務安全上的研究提供幫助。
本文旨在對《云原生安全：攻防實踐與體系構建》書籍中的業務安全部分進行精華解讀。若需要詳細了解云原生業務安全或希望對云原生安全有更加宏觀的了解，請參照具體書中章節，若有任何問題可隨時聯系作者。
本文選自《云原生安全：攻防實踐與體系構建》，經出版方授權發布。
