[[173429]]

作者前言：

從業(yè)近10年，大大小小參與了3家公司不同領域的風控系統(tǒng)的設計，從前到后把風控系統(tǒng)所有環(huán)節(jié)都細細的琢磨過，然而至今仍然感覺剛剛一只腳踏進門而已。

大多數(shù)人做的產(chǎn)品都是目的明確的，比如訂單支付、賬戶體系要做什么一開始就知道了，而且也有很多的競品可以去參考;風控系統(tǒng)卻完全不一樣——未來要面對什么問題不可能完全了解，做每個功能都謹小慎微，因為一個不注意走錯了方向，可能就會在未來的某個階段要全盤推翻。

而對于研發(fā)資源緊缺的安全需求來看，往往會在某個時間把自己擺到一個非常尷尬的境地，問題解決不了，改造又面臨大量的時間和溝通成本。

所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數(shù)。

業(yè)務安全風控設計101-信息采集

業(yè)務風控主要做四件事：

1. 拿到足夠多的數(shù)據(jù)
2. 做足夠靈活的分析平臺去分析數(shù)據(jù)
3. 產(chǎn)出風險事件進行阻攔風險
4. 量化風險攔截的價值和不斷分析案例進行策略優(yōu)化

拿數(shù)據(jù)這件事幾乎是決定風控系統(tǒng)成敗的核心，由于篇幅問題我們先主要說這點，主要有三件事要考慮：

1、拿到的數(shù)據(jù)越詳細越好：

拿賬號安全這件事來舉例子，如果能拿到基礎的登陸注冊數(shù)據(jù)，就可以從頻率、登陸注冊特征來進行分析;

如果可以進一步拿到登陸注冊行為的上下文，比如登陸前訪問了哪些頁面，登陸后去訪問了什么，就可以從訪問行為軌跡來增加更多的分析維度，例如頁面停留時間，是否有訪問到必訪問的頁面等;

如果還可以拿到用戶的操作行為數(shù)據(jù)，比如鼠標移動的軌跡，鍵盤輸入，那么可以進一步的從操作過程來增加分析維度，比如是不是輸入密碼的時候有過多次輸入刪除?是不是直接復制粘貼的賬號密碼?

2、建立標準的日志格式：

確認好能拿到哪些數(shù)據(jù)以后，就要開始建立標準的日志格式。

常見的登陸、注冊、下單、密碼修改、綁定憑證修改等等都要給出一個標準的日志格式，而且要充分考慮到字段命名的統(tǒng)一，比如密碼、用戶名字段的名稱如果在不同的日志中叫法不統(tǒng)一，在后續(xù)分析和指定策略的時候都會遇到不小的麻煩。

3、拿到的數(shù)據(jù)質(zhì)量：

必要的字段是否都能拿到?

往往風控關心的信息比如IP地址、UserAgent、referer這些信息業(yè)務都是不關心的，但這些信息的缺失可能造成很多策略沒法做，所以在采集信息開始的時候就要有個明確的信息列表，一旦妥協(xié)了后面再去返工讓研發(fā)加是會遭白眼的。

數(shù)據(jù)信息拿的是否準確?

比較常見的是需要用戶的訪問IP，結(jié)果拿到的IP地址是內(nèi)網(wǎng)的服務器IP;或者是想要用戶名，結(jié)果傳遞過來的是UID。這點需要大量的前期溝通確認工作，一旦上線了以后發(fā)現(xiàn)數(shù)據(jù)不對再改也同樣要遭白眼。

拿數(shù)據(jù)有主動方式和被動方式兩種：

1、主動方式

主動方式是自己去數(shù)據(jù)庫、日志里面去讀。

這種方式實時性比較差，而且基本有什么拿什么，想加信息是比較難的，但不需要研發(fā)配合太多事情，適合喜歡自己動手豐衣足食的場景。

當然有些比較成熟的公司有自己的消息總線，風控可以去實時的訂閱信息然后作為數(shù)據(jù)源進行分析，但這種通常為少數(shù);

2、被動方式

被動方式就是提供接口給研發(fā)，讓業(yè)務把消息按格式標準噴過來。

這種配合周期非常長，但可以按照標準來拿到高質(zhì)量的信息，所以是比較常見的風控系統(tǒng)搭建方式。

踩坑記

1、號坑：

如果拿消息是多數(shù)據(jù)源的時候，必須要考慮到消息的時間序問題：

比如登陸日志是公共服務發(fā)過來的，網(wǎng)頁訪問是拿的access_log，用戶操作行為數(shù)據(jù)是頁面JS或者SDK發(fā)過來的，那么這三者的時間是不一致的。

這就必須要在確認所有的消息到位之后再進行分析判斷。否則，如果實時策略考慮了登陸的時候必須有頁面鍵盤點擊，而兩個數(shù)據(jù)到位的時間不一致，就可能出現(xiàn)大量的誤封造成事故。

2、號坑：

對采集回來的數(shù)據(jù)必須定期的對數(shù)據(jù)質(zhì)量進行監(jiān)控——

已經(jīng)采集到的數(shù)據(jù)可能因為技術(shù)架構(gòu)調(diào)整，代碼更新等各類奇葩原因造成采集回來的數(shù)據(jù)不準了，如果無法及時發(fā)現(xiàn)可能造成后面一系列分析過程都出現(xiàn)錯誤。

3、號坑：

采集點盡量選擇穩(wěn)定的業(yè)務點，比如采集登陸日志，一次性在公共服務采集好，后面出現(xiàn)問題只要找一個點。

如果是去前端從WEB、移動端等各個調(diào)用登陸服務的點去采集，出了問題要改動的工作就會成倍增加，還有可能出現(xiàn)新業(yè)務點的日志無法覆蓋的情況。

4、號坑：

關于技術(shù)選型：

消息隊列是必須的，用restful只能處理業(yè)務日志比如登陸這種1秒最多幾次的類型，如果后期要去采集頁面訪問行為這種一秒上千的消息就必須要用到隊列.

開源的可以考慮RabbitMQ或者Kafka,穩(wěn)定性都還不錯。

5、號坑：

關于日志存儲：

ELK是不錯的選擇，為后續(xù)的分析平臺提供基本的查詢功能。

結(jié)語

信息采集往往是實施風控的最難的一個環(huán)節(jié)，但也是最重要的環(huán)節(jié)，覆蓋、質(zhì)量、時效都決定了項目的成敗。

因為出于溝通的壓力，往往會有比較多的妥協(xié)，也就為后期風控系統(tǒng)的搭建埋下了隱患，其實也很難一篇文章把細節(jié)描述詳盡。

如果你在這方面遇到了難點，歡迎留言和我們溝通交流，如果對接下來的內(nèi)容感興趣，請分享鼓勵一下小編，我們會盡快給出后續(xù)的章節(jié)。

作者介紹：

劉明 豈安科技聯(lián)合創(chuàng)始人，***產(chǎn)品技術(shù)官

超過6年的風控和產(chǎn)品相關經(jīng)驗，曾就職網(wǎng)易，負責《魔獸世界》中國區(qū)賬戶體系安全?，F(xiàn)帶領豈安互聯(lián)網(wǎng)業(yè)務風控團隊為客戶提供包括了明星產(chǎn)品Warden和RED.Q的風控服務。