搭建風控系統道路上踩過的坑02-風險分析 | 一個CPO的心得分享

上一章《搭建風控系統道路上踩過的坑01--信息採集》咱們介紹了第一點，如何去獲取足夠多的數據，而接下來的事情就是要建立一個機制去靈活的處理這些信息，爲自動分析捕捉風險事件提供基礎原料，進而藉助規則引擎從中分析出風險事件。

在開始前，咱們仍是回顧下業務風控主要作四件事：

一、拿到足夠多的數據
二、作足夠靈活的分析平臺去分析數據
三、產出風險事件進行阻攔風險
四、量化風險攔截的價值和不斷分析案例進行策略優化

接下來，一樣的有三件事情須要考慮：

1、讓分析人員能夠快速的查詢原始日誌

日誌並非簡單的存下來，從風控分析的需求來看，經過IP、用戶名、設備等維度在一個較長的跨度中搜索信息是很是高頻的行爲，同時還存在在特定類型日誌，好比在訂單日誌或者支付日誌中按特定條件搜索的需求。

而這些主要是爲了可以讓分析人員能夠快速的還原風險CASE，例如從客服那邊獲得了一個被盜的案例，那麼如今須要從日誌中查詢被盜時間段內這個用戶作了什麼，這個過程若是有一個界面能夠去作查詢，顯然比讓分析人員用grep在一大堆文件中查詢要快的多，而且學習門檻也要低得多。

若是在日誌作過標準化的前提下，也能夠進行後續的業務語言轉譯，將晦澀難懂的日誌字段轉化爲普通員工都能看得懂的業務語言，也能極大的提高分析師在還原CASE時閱讀日誌的速度。

2、實時或定時的計算加工消息成變量&檔案

例如在分析某個賬號被盜CASE的時候，每每須要把被盜期間登陸的IP地址和用戶歷史經常使用的IP地址進行比對，即便咱們如今能夠快速的對原始日誌進行查詢，篩選一個用戶的全部歷史登陸IP並察看被盜IP在歷史中出現的比例也是一個很是耗時的工做。

再好比咱們的風控引擎在自動判斷用戶當前登陸IP是否爲經常使用IP時，若是每次都去原始日誌裏面查詢聚合作計算也是一個很是「貴」的行爲。

那麼，若是能預約義這些變量並提早計算好，就能爲規則引擎和人工節省大量的時間了，而根據這些變量性質的不一樣，採起的計算方式也是不一樣的。不過還好咱們有一個標準能夠去辨別：頻繁、對時效敏感的利用實時計算（好比訪問頻率、時間間隔）；而相對不頻繁、對時效不敏感的利用定時計算（好比用戶的經常使用IP、設備，即便少算短時間內的登陸記錄，也不會受到太大影響）。

3、選擇規則引擎將人工策略自動運行

一個設計優雅的規則引擎是把分析師的經驗決策和數據最終轉化爲風險輸出的核心模塊，首先說爲何須要規則引擎而不是選擇硬編碼邏輯——

筆者無數次遇到過這種場景，一個上午剛剛上線的策略，沒過1個小時，攻擊者或者欺詐者就已經試出繞過策略的方法了，若是你的風險控制邏輯是硬編碼，那麼恭喜你，再走一遍開發測試發佈流程。

快速響應是安全的生命線，沒法想象還有比被攻擊者胖揍48小時而後才反應過來去擋臉更讓人沮喪的事情了。

因此策略引擎必須能把策略邏輯從業務邏輯中解藕出來，讓防護者能夠靈活配置規則在靜默模式下驗證和實時上線生效，並能夠去隨時調整。

相似的開源框架有不少，各有優劣，但若是須要下降學習曲線，必須進行一層包裝（這裏又是一個比較大的話題，就先略過了）。

坑位標註：

一、Sharding會影響到你的策略

爲了支持併發和性能，一般在利用集羣計算變量的時候咱們會用到sharding。

sharding方式會按IP把數據分配到不一樣的運算單元中去處理，在讀取結果的時候按IP去集羣中的某臺機器中去拿數據，以大幅提高併發處理讀取計算結果的能力。

那麼，如今若是我想去按某個USER去拿數據的時候，就會發現一個用戶在不一樣IP下的信息被保存在不一樣的服務器上了，因此單一的Sharding分配確定是不合理的，這點必需要注意。

二、策略中用到的變量，能不用現場算的就不用

有些簡易的策略引擎設計中用到的變量都是到數據庫裏現場算的，雖然能夠極大的提高靈活性（新的變量不須要考慮歷史數據回補），但會極大的影響穩定性和響應時長，尤爲在業務請求爆發的時候幾乎都會出現宕機無響應的問題。

要知道業務研發對安全的結果並非那麼敏感，但若是出現了問題致使應用不穩定給人添麻煩，被拋棄可能就是遲早的事情，因此變量必定要儘可能作到提早計算，而且設立緩存機制。

三、對風險分析要用到的計算資源有充分的認識

絕不誇張的說，合格的風險分析要作的實時、準實時計算量要大過應用內全部計算的總和甚至超過幾倍。

其實這也很好理解，好比一個典型登陸場景，業務要作的邏輯最主要的就是檢查密碼和賬號的身份是否吻合，而風控要把這登陸用戶的歷史檔案所有拉出來看個遍，而後根據風控策略來決定是否放行。因此在規劃風險分析要用到的資源時請不要吝嗇，按業務5X甚至10X的標準來評估風險分析的資源需求。

若是說信息採集主要看的是安全產品經理的溝通協調能力，設計風險分析功能更多的就是考驗安全產品經理的邏輯思惟能力。

到了這樣一個階段，外部冗雜的溝通協調已經結束，但如何最大化利用前期打下的基礎，須要對風險問題的分析、決策過程有一個很是清晰的認識，這裏也有一個比較好的標準來去檢驗：

分析平臺設計的差，那麼就只有設計者本身會用；

設計的好，你會發現處理投訴的客服、分析師都會很樂意來用你的分析平臺爲他們解決問題。

反爬蟲
文章來源：http://bigsec.com/

做者介紹

劉明  豈安科技聯合創始人，首席產品技術官
超過6年的風控和產品相關經驗，曾就任網易，負責《魔獸世界》中國區帳戶體系安全。現帶領豈安互聯網業務風控團隊爲客戶提供包括了明星產品Warden和RED.Q的風控服務。