摘要：所以，把本人踩過的一些坑在這里分享出來，讓準(zhǔn)備搭建風(fēng)控的人心里有個(gè)數(shù)。結(jié)語信息采集往往是實(shí)施風(fēng)控的最難的一個(gè)環(huán)節(jié)，但也是最重要的環(huán)節(jié)，覆蓋質(zhì)量時(shí)效都決定了項(xiàng)目的成敗。

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)信息拿的是否準(zhǔn)確？

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

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

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

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

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

被動(dòng)方式就是提供接口給研發(fā)，讓業(yè)務(wù)把消息按格式標(biāo)準(zhǔn)噴過來。

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

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

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

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

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

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

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

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

關(guān)于技術(shù)選型：

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

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

關(guān)于日志存儲：

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

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

因?yàn)槌鲇跍贤ǖ膲毫Γ鶗斜容^多的妥協(xié)，也就為后期風(fēng)控系統(tǒng)的搭建埋下了隱患，其實(shí)也很難一篇文章把細(xì)節(jié)描述詳盡。

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

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

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

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