本篇文章會從系統架構設計的角度，分享在對業務安全風控相關基礎安全產品進行系統設計時遇到的問題難點及其解決方案。 內容包括三部分：（1）風控業務架構；（2）基礎安全產品的職責；（3）基礎安全產品相關系統架構的設計要點。 文章會以總-分的形式進行闡述。懂的不多，做的太少。歡迎批評、指正。

原創文章，轉載請標注。http://www.rzrgm.cn/boycelee/p/17324600.html

背景

本篇文章會從系統架構設計的角度，分享在對業務安全風控相關基礎安全產品進行系統設計時遇到的問題難點及其解決方案。

內容包括三部分：（1）風控業務架構；（2）基礎安全產品的職責；（3）基礎安全產品相關系統架構的設計要點。

文章會以總-分的形式進行闡述。懂的不多，做的太少。歡迎批評、指正。

風控業務架構

我把風控業務架構的分層分為6層，分別是組件層、業務層、決策層、能力層、計算層、可視層。

以下基建為基礎安全產品的簡稱。

組件層

組件層的職責是：數據收集與行為反制。

從接口、設備、行為三個維度進行數據收集，接收決策層的指令進行行為反制。為了保證數據的收集數據的可靠性，就衍生出了殼、混淆、反調試等加固策略。

更詳細的思考在我的《風控安全產品的探索之路》這篇文章中，感興趣可跳轉閱讀，這里就不再贅述。http://www.rzrgm.cn/boycelee/p/15948323.html

業務層

業務層的職責是：風控數據透傳與風控決策結果處理。

將風控所需要的數據透傳至決策層，業務層獲取到決策層數據后，根據決策層結果選擇執行風險反制或業務邏輯。

透傳數據一般包括：風控數據和業務補充數據。

決策層

決策層的職責是：風控能力應用。

決策層是整個風控業務的核心，將風控能力高效連接起來，有效、合理地應用能力層、計算層所具備的能力。這一層的難點在于工程而非安全領域，例如：如何設計調用鏈路（降低計算時長）、如何處理超高并發流量、如何保護下游風控內部系統等。

其中包括：風控參數預處理、風控能力應用（組件/名單/模型等）、風險決策（規則引擎）、反制決策（觀測/登錄/驗證碼/行為驗證/封禁）。

能力層

能力層的職責是：識別基礎安全風險。

該層包括：設備指紋、環境檢測、接口防護、驗證碼、IP風險、手機號風險、鏈路風險等。

能力層是風控系統的基石，它的能力決定了一個風控系統識別風險能力的下限。會從資源、接口、設備、鏈路、行為等維度進行系統性風險掃描。

計算層

能力層的職責是：補充風險識別能力。

該層包括：數據引擎、規則引擎、風險名單、識別模型、風險預警。

計算層是對基礎安全風險識別能力的補充，它的能力決定了一個風控系統識別風險能力的上限。從頻率統計、策略規則、風險名單、模型識別、風險預警等維度對能力層進行能力補充。

可視層

可視層的職責是：提升運維效率。

該層包括：運維報表、引擎配置、流量監控、事件追蹤。

可視層能夠在事前能夠分析風險潛在風險，事中有效執行并降低配置錯誤概率，事后觀察風控效果。滿足運營策略調整與風險管理的需求。

因為目前主要深入了解與實踐的是組件層和能力層的建設，所以文章后續會從基建（基礎安全產品）的視角進行系統性總結。

基礎安全組件

落地難點

1. 接入場景多

   拉新激活、賬號、反爬（多業務線）、交易（多業務線）、營銷（多業務線）。

2. 接入終端多

   ADR（多技術棧）、IOS（多技術棧）、WX（原生、非原生）、WEB、TOUCH。

3. 接入組件多

? 防護組件（指紋、環境檢測、接口防護等）、驗證碼組件、登錄組件等。

待解決問題

架構特性

在進行架構設計時，我會重點關注架構的這三大特性，分別是：安全性、易用性、穩定性。

安全性

因為是安全組件，其識別能力和組件自身安全性是首先要保證的。

穩定性

組件會應用在各個場景，所以要盡可能降低由安全組件造成故障的概率。

易用性

盡可能降低業務接入的成本。

具體案例

以接口防護組件設計來舉例。

問題分析

攻擊場景

（以ip138查詢網舉例，不代表本人對該網站進行過攻擊）

攻擊還原

思路描述

請求離開容器后，通過抓包的方式，獲取并解析數據，然后進行數據篡改、偽造鑒權，最后重新構造數據并發送請求。

攻擊步驟

（1）抓包；（2）解析數據；（3）數據篡改；（4）偽造鑒權；（5）構造數據；（6）發送請求。

攻擊步驟防御可行性分析

防止抓包

（1）抓包在應用外進行；

（2）除App，其他端防抓包基本不可防；

（3）防御性價比不高。

防止解析

解決方案是加密。

（1）入侵性較強、強依賴；

（2）加解密服務穩定性要求高；

（3）業務響應時長上升。

系統設計

系統架構

描述系統分層、職責、關系以及運行規則。

組件層

提供接口防護組件、驗證組碼件和登錄組件。

透傳層

通過數據共享或業務系統透傳方式透傳風控參數。

決策層

進行入參校驗、版控、能力使用以及反制決策等。

能力層

提供接口檢測能力等。

架構特性

安全性

關于安全性另一篇文章《業務安全相關安全產品的反思》中已經詳細闡述，這篇文章就不過多贅述。http://www.rzrgm.cn/boycelee/p/16223114.html

安全性的難點除了風險識別上的難點，還有就是面對多個終端（Android、iOS、小程序、PC、Touch），其底層邏輯完全不一樣。我們如何總結出統一的設計思想（方法論）這樣的類工程問題。

如防容器脫離，我總結的思想就是：上層與業務邏輯建立聯系，中層多個組件間建立聯系，下層與操作系統（WX容器、瀏覽器）建立聯系。

穩定性

易用性

（1）組件化

關于前端組件的易用性，不能與業務過于耦合，需要根據業務特性進行適當地解耦。如果與業務系統過于耦合，首先是在對防護邏輯進行升級時勢必會影響業務，就需要投入測試人力進行業務邏輯回歸，其次是防護能力往其他場景遷移也會有代碼重復冗余的問題。

（2）易用性提升

如何在組件化的前提下進行易用性提升？我堅持的原則是盡量在不入侵業務的前提下，降低接入成本。

我的解決方案是，結合項目前端技術棧特點進行如下選擇：

a）方式一：是否有統一的網絡框架？

? 如使用安卓原生技術開發、蘋果原生技術開發一般企業都有統一的網絡框架進行網絡出口管理，這時組件就可以從中找一個切面進行組件接入。

b）方式二：是否有統一組件？

? 如小程序（或Android Hybird等）沒有封裝統一的網絡庫，而是頁面直接使用HTTP協議發送請求，但有統一的工具庫，此時可以幫業務提前做好組件引入工 作，業務使用時 直接本地調用即可。這也可以一定程度地提升易用性。

c）方式三：是否可以引入三方組件？

? 如網頁端（WWW、TOUCH）提供好完整的風控.js文件，業務方使用時直接調用即可，雖然不如以上a、b兩種方式更友好，但要強于代碼拷貝的方案。

最后

軟件工程沒有銀彈，逆向工程永遠勝利。

懂的不多，做的太少。歡迎批評、指正。