目錄
- 背景
- 風控業務架構元件層業務層決策層能力層計算層可視層
- 基礎安全元件落地難點接入場景多接入終端多接入元件多待解決問題架構特性安全性穩定性易用性
- 具體案例問題分析攻擊場景攻擊還原攻擊步驟防禦可行性分析系統設計系統架構元件層透傳層決策層能力層架構特性安全性穩定性易用性
- 最後
原創文章，轉載請标注。https://www.cnblogs.com/boycelee/p/17324600.html
背景
本篇文章會從系統架構設計的角度，分享在對業務安全風控相關基礎安全産品進行系統設計時遇到的問題難點及其解決方案。
内容包括三部分：（1）風控業務架構；（2）基礎安全産品的職責；（3）基礎安全産品相關系統架構的設計要點。
文章會以總-分的形式進行闡述。懂的不多，做的太少。歡迎批評、指正。
風控業務架構
我把風控業務架構的分層分為6層，分别是元件層、業務層、決策層、能力層、計算層、可視層。
以下基建為基礎安全産品的簡稱。
元件層
元件層的職責是：資料收集與行為反制。
從接口、裝置、行為三個次元進行資料收集，接收決策層的指令進行行為反制。為了保證資料的收集資料的可靠性，就衍生出了殼、混淆、反調試等加強政策。
更詳細的思考在我的《風控安全産品的探索之路》這篇文章中，感興趣可跳轉閱讀，這裡就不再贅述。https://www.cnblogs.com/boycelee/p/15948323.html
業務層
業務層的職責是：風控資料透傳與風控決策結果處理。
将風控所需要的資料透傳至決策層，業務層擷取到決策層資料後，根據決策層結果選擇執行風險反制或業務邏輯。
透傳資料一般包括：風控資料和業務補充資料。
決策層
決策層的職責是：風控能力應用。
決策層是整個風控業務的核心，将風控能力高效連接配接起來，有效、合理地應用能力層、計算層所具備的能力。這一層的難點在于工程而非安全領域，例如：如何設計調用鍊路（降低計算時長）、如何處理超高并發流量、如何保護下遊風控内部系統等。
其中包括：風控參數預處理、風控能力應用（元件/名單/模型等）、風險決策（規則引擎）、反制決策（觀測/登入/驗證碼/行為驗證/封禁）。
能力層
能力層的職責是：識别基礎安全風險。
該層包括：裝置指紋、環境檢測、接口防護、驗證碼、IP風險、手機号風險、鍊路風險等。
能力層是風控系統的基石，它的能力決定了一個風控系統識别風險能力的下限。會從資源、接口、裝置、鍊路、行為等次元進行系統性風險掃描。
計算層
能力層的職責是：補充風險識别能力。
該層包括：資料引擎、規則引擎、風險名單、識别模型、風險預警。
計算層是對基礎安全風險識别能力的補充，它的能力決定了一個風控系統識别風險能力的上限。從頻率統計、政策規則、風險名單、模型識别、風險預警等次元對能力層進行能力補充。
可視層
可視層的職責是：提升運維效率。
該層包括：運維報表、引擎配置、流量監控、事件追蹤。
可視層能夠在事前能夠分析風險潛在風險，事中有效執行并降低配置錯誤機率，事後觀察風控效果。滿足營運政策調整與風險管理的需求。
因為目前主要深入了解與實踐的是元件層和能力層的建設，是以文章後續會從基建（基礎安全産品）的視角進行系統性總結。
基礎安全元件
落地難點
- 接入場景多
- 拉新激活、賬号、反爬（多業務線）、交易（多業務線）、營銷（多業務線）。
- 接入終端多
- ADR（多技術棧）、IOS（多技術棧）、WX（原生、非原生）、WEB、TOUCH。
- 接入元件多
防護元件（指紋、環境檢測、接口防護等）、驗證碼元件、登入元件等。
待解決問題
架構特性
在進行架構設計時，我會重點關注架構的這三大特性，分别是：安全性、易用性、穩定性。
安全性
因為是安全元件，其識别能力群組件自身安全性是首先要保證的。
穩定性
元件會應用在各個場景，是以要盡可能降低由安全元件造成故障的機率。
易用性
盡可能降低業務接入的成本。
具體案例
以接口防護元件設計來舉例。
問題分析
攻擊場景
（以ip138查詢網舉例，不代表本人對該網站進行過攻擊）
攻擊還原
思路描述
請求離開容器後，通過抓包的方式，擷取并解析資料，然後進行資料篡改、僞造鑒權，最後重新構造資料并發送請求。
攻擊步驟
（1）抓包；（2）解析資料；（3）資料篡改；（4）僞造鑒權；（5）構造資料；（6）發送請求。
攻擊步驟防禦可行性分析
防止抓包
（1）抓包在應用外進行；
（2）除App，其他端防抓包基本不可防；
（3）防禦成本效益不高。
防止解析
解決方案是加密。
（1）入侵性較強、強依賴；
（2）加解密服務穩定性要求高；
（3）業務響應時長上升。
系統設計
系統架構
描述系統分層、職責、關系以及運作規則。
元件層
提供接口防護元件、驗證組碼件和登入元件。
透傳層
通過資料共享或業務系統透傳方式透傳風控參數。
決策層
進行入參校驗、版控、能力使用以及反制決策等。
能力層
提供接口檢測能力等。
架構特性
安全性
關于安全性另一篇文章《業務安全相關安全産品的反思》中已經詳細闡述，這篇文章就不過多贅述。https://www.cnblogs.com/boycelee/p/16223114.html
安全性的難點除了風險識别上的難點，還有就是面對多個終端（Android、iOS、小程式、PC、Touch），其底層邏輯完全不一樣。我們如何總結出統一的設計思想（方法論）這樣的類工程問題。
如防容器脫離，我總結的思想就是：上層與業務邏輯建立聯系，中層多個元件間建立聯系，下層與作業系統（WX容器、浏覽器）建立聯系。
穩定性
易用性
（1）元件化
關于前端元件的易用性，不能與業務過于耦合，需要根據業務特性進行适當地解耦。如果與業務系統過于耦合，首先是在對防護邏輯進行更新時勢必會影響業務，就需要投入測試人力進行業務邏輯回歸，其次是防護能力往其他場景遷移也會有代碼重複備援的問題。
（2）易用性提升
如何在元件化的前提下進行易用性提升？我堅持的原則是盡量在不入侵業務的前提下，降低接入成本。
我的解決方案是，結合項目前端技術棧特點進行如下選擇：
a）方式一：是否有統一的網絡架構？
如使用安卓原生技術開發、蘋果原生技術開發一般企業都有統一的網絡架構進行網絡出口管理，這時元件就可以從中找一個切面進行元件接入。
b）方式二：是否有統一元件？
如小程式（或Android Hybird等）沒有封裝統一的網絡庫，而是頁面直接使用HTTP協定發送請求，但有統一的工具庫，此時可以幫業務提前做好元件引入工 作，業務使用時 直接本地調用即可。這也可以一定程度地提升易用性。
c）方式三：是否可以引入三方元件？
如網頁端（WWW、TOUCH）提供好完整的風控.js檔案，業務方使用時直接調用即可，雖然不如以上a、b兩種方式更友好，但要強于代碼拷貝的方案。
最後
軟體工程沒有銀彈，逆向工程永遠勝利。
原文連結：https://www.cnblogs.com/boycelee/p/17324600.html