搭建風控系統道路上踩過的坑合集

做者前言

從業近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是不錯的選擇，爲後續的分析平臺提供基本的查詢功能。
信息採集每每是實施風控的最難的一個環節，但也是最重要的環節，覆蓋、質量、時效都決定了項目的成敗。

業務安全風控設計--信息分析

在獲取足夠多的數據以後，接下來的事情就是要建立一個機制去靈活的處理這些信息，爲自動分析捕捉風險事件提供基礎原料，進而藉助規則引擎從中分析出風險事件。
接下來，一樣的有三件事情須要考慮：

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的標準來評估風險分析的資源需求。

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

到了這樣一個階段，外部冗雜的溝通協調已經結束，但如何最大化利用前期打下的基礎，須要對風險問題的分析、決策過程有一個很是清晰的認識，這裏也有一個比較好的標準來去檢驗：
分析平臺設計的差，那麼就只有設計者本身會用；設計的好，你會發現處理投訴的客服、分析師都會很樂意來用你的分析平臺爲他們解決問題。

可是分析出來的東西不能光本身看着High，還得去阻攔這些風險才能真正產生業務價值。

業務安全風控設計--阻攔風險

到了第三步咱們離整個系統核心框架的搭建就只剩一步之遙了，那麼讓咱們看看這個環節要考慮什麼：

一、最終呈現給業務研發直白的斷定結果

咱們最終從數據中發現的報警和問題最終是要在業務邏輯中去阻攔的，在接入這些結果的時候，每每分析師以爲能夠提供的信息有不少，好比命中了什麼規則、這些規則是什麼、何時命中的、何時過時，其中最讓接入方心煩的當屬風險分值當仁不讓了，不少接入風控的研發看到這些分值就一腦殼包：你到底想讓我作什麼，攔仍是不攔？這時候若是你喏喏的再丟出個多少分值以上要攔，研發多半都會跟你說直接給我結果就行了。
是的，不少風控接口設計的都十分累贅，無用信息多到研發會以爲你在故意浪費帶寬，其實一個code list給他們說明對應但願作的操做就好，必定把你以爲那些很牛逼的中間結果等等包裝成最終結果再給出去。

二、T＋0仍是T＋1

舉個例子來解釋實時(T+0)和異步（T＋1）風險判斷的區別。

T+1
你在打拳擊比賽，選手A只會打臉，上來就照着你臉來了一拳，你分析了一下打臉很疼並且不科學，在第二拳往臉揮過來時你忽然告知對方不可打臉，對方就成功的被你剋制住了。這就是T+1的特色，至少要在第二次風險攻擊才能夠生效；

T＋0

拳擊比賽第二場對陣選手B，一樣被打臉後你說不可打臉，對方說好，結果衝着肚子就來了一拳。你說禁止打肚子，對方又一拳打腋下。這時你發現要在對方揮拳立刻打到你以前就要禁止。
這就是T＋0了。
由於T＋0在接入的時候要額外承擔不少計算成本，結果要現場算出來而延時要求又很高，因此通常都只在攻擊者得手關鍵步驟採起實時判斷（好比訂單支付或者提現請求）。而對於其餘場景能夠選擇T＋1方式，好比登陸或者提交訂單等。

三、阻斷邏輯到阻斷產品

這一點咱們豈安在對外演講的時候介紹過不少，在阻斷風險的時候事件發生的點是不一樣的，但短時間又不可能讓業務研發在全部的地方接入風險阻斷怎麼辦？
因此咱們須要考慮幾個基本的保底措施，好比統一的驗證碼驗證頁面在IP層全局防止任何爬蟲腳本行爲，在帳號層經過登陸態管理統一攔截單個帳號在登陸後任何風險行爲（全局強制登出）。
可能這些措施在體驗上不是最好的，可是在發生特殊問題的時候要等研發給你臨時加阻斷邏輯這個時間就無法控制了。

坑位

一、接入風控阻斷的邏輯位置

登陸的時候帳號輸入框鼠標失焦就要去走風控了，登陸結果出來以後再去判斷就沒意義，而資金相關的通常是在跳轉去收銀臺以前，你會發現通常風險判斷都是在結果出來以前（收集本次行爲完整日誌以前），因此若是你要作T+0判斷，就要求研發在進行風險判斷的時候要提供更完整的信息，而不是隻給個IP或者帳號名就好了（每每T＋1就之要這些就夠）。

二、對業務流量充分調研並關注

平時可能流量很小的業務，忽然由於某個活動（好比秒殺）流量大增，除了在接入之初要對風險判斷請求有了解，對後續的活動也要提早準備，不然若是資源預估不足，忽然又遇上這個點接了T+0接口有不少要現場計算的邏輯，陡增的業務流量分分鐘教你作人。

三、bypass ！ bypass ! bypass

風控風險判斷的最基本原則就是要不影響業務邏輯，因此超時機制在一開始就要嚴格約定並執行，一旦發現風控接口超過預計響應時間立馬放行業務請求。

四、讓一線同事們知道你在作什麼

任何風控準確率都不是100%的，因此在和研發溝通好接入後必定要告訴一線同事們風控阻斷可能出現的表象，以及大體的緣由，以免一線客服們對風險攔截的投訴不知道如何解釋，並給出具體的阻斷回覆措施（加白名單、刪除黑名單等等，上帝們在某些日子好比315維權意識是很是強的）。

阻斷是最終產生真實價值的環節，另外也是關聯部門最敏感的環節（嚇唬我半天逼着我把風控接了，結果一天到晚給我出毛病？生產環境是給大家玩的？！），請保護這相當重要的信任，你後面會越作越順的。

業務安全風控設計--效果評估與優化

風控系統和大部分的產品項目同樣，最終須要對領導層彙報這個項目爲公司帶來了什麼價值，這是評估項目成功與否的要素；

另外是哪裏作的不夠好，若是改善了能帶來更多的價值，給出了預期纔有後續資源的補充，整個項目才能轉起來造成一個良性循環。

如今開始說說這個系列的最後一話：如何對風控系統進行效果評估與優化。
咱們看一下這個環節要考慮的：

1.找到錢在哪裏
風控項目的基本價值在於省錢，而省錢的思路基本有三種：直接攔截風險帶來的止損（好比提早阻止了一筆欺詐交易所挽回的損失）；提高服務穩定性所帶來的業務基本指標提高（好比因阻止風險事件所下降的服務響應延時而提高的業務轉化）；下降服務不可用機率事件所帶來的直接業務損失（好比下降了風險事件致使服務宕機所帶來的營收損失）。

能夠看出這三點是按風險事件的暴力程度作出的簡單劃分，其實也還有不少其餘不一樣的視角來分類，很大程度上和對應企業的互聯網業務形態有關。

而咱們作這樣劃分的目的是爲了：在一開始就明確風控項目從哪裏能夠挖掘效益。
不少狀況下風險事件不是一個獨立的問題，而是一個鏈條，由一些看起來影響不大的問題逐層深刻。好比，交易欺詐並非一個獨立的問題，而是由於註冊環節發生的垃圾註冊問題攻擊者手裏有了大量的帳號所致使的，因此任何一個風險問題都是有價值的。
無利不起早，做爲風險分析者應當有能力找到其中的關聯轉化關係，並預測對方的得手點進行效果評估會有更好的效果。

2.有效利用預期價值的力量

天下沒有100%準確的風控策略，因此在接入攔截的過程當中業務方可能存在種種阻力，每每的一個誤區是沒有攔截就認爲風控沒有效果。
其實，效果評估不僅是在最後項目落地評估價值所用，在推行項目中間也有很好的效果，雖然沒有攔截，但預期效果放在那裏，這對決策者平衡業務影響有着重要的價值。

3.學會考慮企業財務目標

風控系統並非一個無關緊要的東西。其實大部分企業中安全已是業務的必要組成部分了，那麼咱們知道在資源有限、而業務風險問題無限的狀況下，全部的資源投入都必然有一個優先級，而這個優先級與整個企業發展的現狀必須是緊緊捆綁在一塊兒的。
講簡單些：風控系統解決什麼問題，評估出的效果與企業目前業務關心的問題息息相關。
若是企業目前的業務重點在一次年度促銷活動，那麼風控的重點就應當在促銷羊毛黨；若是企業目前面臨嚴重的帳戶盜用投訴問題，那麼重點就應在帳號安全。尤爲在風控系統啓動之初，配合系統的需求交付時間選擇對應的重點問題，對於項目效果的評估是一個巨大的加分項，切記一開始就貪大貪全。

4.策略的生命週期和健康度

風控系統的規則有多少？哪些已經好久沒有觸發了？產生誤判投訴的對應規則有哪些？一個新規則在創建起初的效果確定是最有效的（由於這時風險問題正在發生，而規則正好對應了風險），但隨着時間其有效性是呈快速降低的趨勢。
好比，攻擊者都知道網站三次輸入密碼錯誤觸發驗證碼，他們會傻傻的嘗試第三次猜想密碼的機率有多大？那麼，是否有人在按期的去統計分析這些規則的效率？這就是風控產品的重要運營環節了。
而運營風控產品所要付出的代價，每每大於常規互聯網業務產品，而且是保證項目可以持續產出價值並不斷迭代進化的一個前提。

寫在最後

業務風控是一個很是具備挑戰性的項目，我一直把它比做一種競技遊戲，而這種攻防不一樣於傳統安全（在傳統安全你並不能有足夠的技術能力預測全部人的攻擊方法），它更強調邏輯和預測——
攻守雙方在一個雙方充分了解的環境下（業務邏輯簡單到任何人均可以理解，但又能夠產生無數的變化和組合）不斷的博弈。

而這正是業務風控系統的樂趣所在。

業務風險問題足夠簡單而又足夠複雜，正是這樣的緣由其參與攻擊者並無過高的門檻限制。處於國內互聯網的環境下，任何一家企業都不可能逃開業務風險問題的影響。
做一個比喻，這片土壤是有着本身的一些特質的，企業若是是生長在這片土壤中的一顆樹，投入足夠的營養才能快速生長，而業務風險則是寄生於樹木竊取營養的角色，只有可以充分抵禦這種風險的才能成長爲參天大樹。

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