資訊專欄INFORMATION COLUMN
摘要：所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數。結語信息采集往往是實施風控的最難的一個環節，但也是最重要的環節，覆蓋質量時效都決定了項目的成敗。
作者前言
從業近10年，大大小小參與了3家公司不同領域的風控系統的設計，從前到后把風控系統所有環節都細細的琢磨過，然而至今仍然感覺剛剛一只腳踏進門而已。
大多數人做的產品都是目的明確的，比如訂單支付、賬戶體系要做什么一開始就知道了，而且也有很多的競品可以去參考；風控系統卻完全不一樣——未來要面對什么問題不可能完全了解，做每個功能都謹小慎微，因為一個不注意走錯了方向，可能就會在未來的某個階段要全盤推翻。
而對于研發資源緊缺的安全需求來看，往往會在某個時間把自己擺到一個非常尷尬的境地，問題解決不了，改造又面臨大量的時間和溝通成本。
所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數。
業務安全風控設計101-信息采集 業務風控主要做四件事：1.拿到足夠多的數據
2.做足夠靈活的分析平臺去分析數據
3.產出風險事件進行阻攔風險
4.量化風險攔截的價值和不斷分析案例進行策略優化
拿數據這件事幾乎是決定風控系統成敗的核心，由于篇幅問題我們先主要說這點，主要有三件事要考慮
1 拿到的數據越詳細越好拿賬號安全這件事來舉例子，如果能拿到基礎的登陸注冊數據，就可以從頻率、登陸注冊特征來進行分析；
如果可以進一步拿到登陸注冊行為的上下文，比如登陸前訪問了哪些頁面，登陸后去訪問了什么，就可以從訪問行為軌跡來增加更多的分析維度，例如頁面停留時間，是否有訪問到必訪問的頁面等；
如果還可以拿到用戶的操作行為數據，比如鼠標移動的軌跡，鍵盤輸入，那么可以進一步的從操作過程來增加分析維度，比如是不是輸入密碼的時候有過多次輸入刪除？是不是直接復制粘貼的賬號密碼？
2建立標準的日志格式確認好能拿到哪些數據以后，就要開始建立標準的日志格式。
常見的登陸、注冊、下單、密碼修改、綁定憑證修改等等都要給出一個標準的日志格式，而且要充分考慮到字段命名的統一，比如密碼、用戶名字段的名稱如果在不同的日志中叫法不統一，在后續分析和指定策略的時候都會遇到不小的麻煩。
3拿到的數據質量必要的字段是否都能拿到？
往往風控關心的信息比如IP地址、UserAgent、referer這些信息業務都是不關心的，但這些信息的缺失可能造成很多策略沒法做，所以在采集信息開始的時候就要有個明確的信息列表，一旦妥協了后面再去返工讓研發加是會遭白眼的。
數據信息拿的是否準確？
比較常見的是需要用戶的訪問IP，結果拿到的IP地址是內網的服務器IP；或者是想要用戶名，結果傳遞過來的是UID。這點需要大量的前期溝通確認工作，一旦上線了以后發現數據不對再改也同樣要遭白眼。
拿數據有主動方式和被動方式兩種：
1主動方式方式主動方式是自己去數據庫、日志里面去讀。
這種方式實時性比較差，而且基本有什么拿什么，想加信息是比較難的，但不需要研發配合太多事情，適合喜歡自己動手豐衣足食的場景。
當然有些比較成熟的公司有自己的消息總線，風控可以去實時的訂閱信息然后作為數據源進行分析，但這種通常為少數；
2 被動方式方式被動方式就是提供接口給研發，讓業務把消息按格式標準噴過來。
這種配合周期非常長，但可以按照標準來拿到高質量的信息，所以是比較常見的風控系統搭建方式。
踩坑記 1號坑：如果拿消息是多數據源的時候，必須要考慮到消息的時間序問題：
比如登陸日志是公共服務發過來的，網頁訪問是拿的access_log，用戶操作行為數據是頁面JS或者SDK發過來的，那么這三者的時間是不一致的。
這就必須要在確認所有的消息到位之后再進行分析判斷。否則，如果實時策略考慮了登陸的時候必須有頁面鍵盤點擊，而兩個數據到位的時間不一致，就可能出現大量的誤封造成事故。
2號坑：對采集回來的數據必須定期的對數據質量進行監控——
已經采集到的數據可能因為技術架構調整，代碼更新等各類奇葩原因造成采集回來的數據不準了，如果無法及時發現可能造成后面一系列分析過程都出現錯誤。
3號坑：采集點盡量選擇穩定的業務點，比如采集登陸日志，一次性在公共服務采集好，后面出現問題只要找一個點。
如果是去前端從WEB、移動端等各個調用登陸服務的點去采集，出了問題要改動的工作就會成倍增加，還有可能出現新業務點的日志無法覆蓋的情況。
4號坑：關于技術選型：
消息隊列是必須的，用restful只能處理業務日志比如登陸這種1秒最多幾次的類型，如果后期要去采集頁面訪問行為這種一秒上千的消息就必須要用到隊列.
開源的可以考慮RabbitMQ或者Kafka,穩定性都還不錯。
5號坑：關于日志存儲：
ELK是不錯的選擇，為后續的分析平臺提供基本的查詢功能。
結語信息采集往往是實施風控的最難的一個環節，但也是最重要的環節，覆蓋、質量、時效都決定了項目的成敗。
因為出于溝通的壓力，往往會有比較多的妥協，也就為后期風控系統的搭建埋下了隱患，其實也很難一篇文章把細節描述詳盡。
如果你在這方面遇到了難點，歡迎留言和我們溝通交流，如果對接下來的內容感興趣，請鼓勵一下小編，我們會盡快給出后續的章節。
反爬蟲
文章來源：http://bigsec.com/
劉明 豈安科技聯合創始人，首席產品技術官
超過6年的風控和產品相關經驗，曾就職網易，負責《魔獸世界》中國區賬戶體系安全。現帶領豈安科技互聯網業務風控團隊為客戶提供包括了明星產品Warden和RED.Q的風控服務。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/65179.html
摘要：所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數。結語信息采集往往是實施風控的最難的一個環節，但也是最重要的環節，覆蓋質量時效都決定了項目的成敗。 showImg(https://segmentfault.com/img/bVEcg5?w=900&h=658); 作者前言 從業近10年，大大小小參與了3家公司不同領域的風控系統的設計，從前到后把風控系統所有環節都細細...
摘要：所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數。結語信息采集往往是實施風控的最難的一個環節，但也是最重要的環節，覆蓋質量時效都決定了項目的成敗。 showImg(https://segmentfault.com/img/bVEcg5?w=900&h=658); 作者前言 從業近10年，大大小小參與了3家公司不同領域的風控系統的設計，從前到后把風控系統所有環節都細細...
摘要：上一章搭建風控系統道路上踩過的坑信息采集我們介紹了第一點，如何去獲取足夠多的數據，而接下來的事情就是要創建一個機制去靈活的處理這些信息，為自動分析捕捉風險事件提供基礎原料，進而借助規則引擎從中分析出風險事件。 上一章《搭建風控系統道路上踩過的坑01--信息采集》我們介紹了第一點，如何去獲取足夠多的數據，而接下來的事情就是要創建一個機制去靈活的處理這些信息，為自動分析捕捉風險事件提供基礎...
閱讀 2312·2021-09-26 10:21
閱讀 2785·2021-09-08 09:36
閱讀 3065·2019-08-30 15:56
閱讀 954·2019-08-30 12:57
閱讀 916·2019-08-26 10:39
閱讀 3554·2019-08-23 18:11
閱讀 3077·2019-08-23 17:12
閱讀 1070·2019-08-23 12:18
