原創文章，轉載請標註。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兩種方式更友好，但要強於程式碼複製的方案。
最後
軟體工程沒有銀彈，逆向工程永遠勝利。
懂的不多，做的太少。歡迎批評、指正。