本文為CSDN投稿文章，分享了攜程信息安全業務安全團隊在這幾年來，風險防御體系演進變革的要點，遇到的一些坑，如何做技術選型，解決了哪些困境，走過的彎路，各位讀者可以將本文作為自身建設風險防御系統的攻略參考，也可以作為一個回憶錄，避免重復踩坑。

1.0時代

過去攜程曾經使用一套基于.NET的風險防御系統作為控制注冊，登錄，支付以及其他相關場景的主要手段，這套系統主要由三個服務組成：數據收集服務，規則引擎服務，黑白名單服務。主要實現的場景案例有：

控制用戶嘗試登錄的頻率

控制單個緯度登錄帳號的數量

控制手機號發送短信的頻率

控制單個緯度注冊帳號的頻次和數量

控制單個賬號的積分發送

控制特定緯度的登錄及領卷

架構圖如圖：

這套風險防御系統的特點有：

黑名單數據同時DB＆redis雙寫

數據預處理和數據引擎耦合，無法更改

長時間數據計算基于DB做sharding分片

支持的緯度由于預處理流量表寫死，無法添加

結果緯度由流量表控制，無法自由添加，且無法組合

在默認的引擎范圍內，可以自由添加規則，并實時發布

結果由黑白名單服務響應，可以直接導入黑名單

支持A/B，可以灰度觀察規則命中情況

使用下來，優缺點都很明顯。

優點：
規則可以實時的配置，測試，上線，下線，雖然規則引擎和緯度存在一定限制，但是針對短時間內做登錄&注冊的流量控制，應該來說是可以接受的。配合驗證碼，比如“同一個IP，X分鐘內登錄Y個不同的攜程賬號，給這個IP出現Z分鐘的@@類型驗證碼”,這種看似大路貨的規則，實際上能攔截掉很大一部分的異常嘗試。

因為存在黑白名單服務，由DB和redis維持，所以可以直接導入大批量的黑產名單，這個在業務初期，大量依賴人工事后分析異常以及存在外部黑產數據的場景下，顯得格外有用。

缺點：
由于用DB和redis是雙寫的，一旦數據量過大，db寫入性能即出現影響，同時影響redis寫入，從而整個系統受到影響。真實案例，明明一個ip應該在半小時前就從黑名單自動消失，可以正常訪問攜程，但是這個ip現在依然還是被攜程彈出高級別驗證碼，導致用戶體驗受損，排查下來，就是由于DB單位時間數據量過大，出現IO瓶頸，這個數據失效請求一直在排隊狀態，影響到生產。

因為數據預處理和引擎耦合，并且是通過流量表進行計算，導致了現在想增加一些復雜引擎和結果緯度，難度基本接近于重構，后期的維護和使用成本過高。并且由于流量表的結果緯度單一化，想做成組合緯度結果或者評分卡也成為了空談，只能單一化的輸出。類似“某攜程賬號在福建被盜，需要禁止這個賬號在福建IP的登錄，在上海IP允許其登錄”這種實際意義很大的場景無法實現。

由于大量數據的計算依賴DB，這套系統日均千萬級別的計算量，讓DB多次達到了負荷極限，即使做了索引，因為大量冗余和重復的規則計算，導致了整體服務的性能下降嚴重。實際案例是，隨著有段時間的業務量增長，DB表每分鐘產生的數據就是上萬級別，而刪除的數據只是上千級別，導致DB表內的數據超過數億條，直接無法操作。

因為這套系統的計算結果并不直接返回給請求方，而是異步計算并將結果寫入黑白名單服務，只有等待請求方第二次來請求黑白名單服務的時候，才會給出返回結果。類似”滿足xx條件的ip,30分鐘內不允許該IP再次訪問”的規則，只有在這個ip第二次來請求的時候，才會禁止其請求，無法在第一次就直接回復無法訪問，導致了掃號，只要有足夠多的IP，對方可以隨意嘗試，每個IP都有一條命的無敵嘗試機會。

總結：隨著業務量的增長和業務場景的增加，這套系統已經明顯顯現了性能和業務需求的瓶頸，需要改造。

1.5時代

在介紹了上面的系統后，讀者一定會發現，這個系統阻擋的場景由于規則引擎的不可變，導致了能攔截到的異常數據都是基本固化的，在黑產千變萬化的當今，這個系統只能對付對付一些非常初級的黑產興趣愛好者以及一些測試人員，想要依靠上面這個系統，去阻擋真正的掃號工作室，批量注冊，薅羊毛等情況，無異于癡人說夢。

基于這個情況，我們在去年上線了風險庫系統，這個系統旨在用現有的時間跨度較大的業務數據，異步計算相關風險，并輸出給黑白名單服務，由這個服務為各個業務方提供結果。

從這個簡單的系統架構圖可以看到，我們在保證原先風控系統架構不變的前提下，加入了這個風險庫系統，對外仍然使用統一的黑白名單服務API接口提供結果，保證了業務方不需要再接入一個新的服務API，這個設定節約了我們大量的系統推廣成本以及接入方的接入成本，只需要在內部確保系統的可用性和性能即可。
風險庫系統的特點：

（1）計算規則相對復雜，所以沒有規則引擎的概念，直接使用sql統計，自由度高。
（2）由于直接使用sql統計，所以無法做規則實時調整，一定要進行發布。
（3）離線計算數據是周/天級別，計算時間顆粒度是分鐘級別。
（4）統計結果支持下發黑白名單服務，無需讓業務方單獨接入。

在這個系統上線后，可以說我們才具備了一個風險規則(rule)這樣一個概念，同樣的，這個系統的優缺點也很明顯。

優點：
由于可以使用sql語句做各種復雜統計，相當于是一個沒有任何限制的規則引擎，所以可以根據人工分析結果，設置各種復雜規則，分別應對掃號，爬蟲，異常注冊，活動/優惠卷領取等等各種場景，并且效果經過驗證，相對于準實時風險防御系統計算的結果只能做一個短時間維持（比如密碼錯3次，只能讓一個賬戶30分鐘不能嘗試登錄），風險庫系統計算應對的異常目標的維持時間可以長達幾年（異常注冊的薅羊毛賬號，可以讓他5年不能參與活動）。

相對于準實時風險防御系統計算的量大，精度低這么一個特點，風險庫得到的結果是量小，精度高，都是99%以上可以確認有問題的緯度值，填補了無法長時間維持黑名單，做異常數據積累的問題。

缺點：
由于種種原因，當時上線這個系統的時候，任務緊時間急，架構選取的是sql+db+redis，導致了計算大體量數據，尤其是在目前業務量年年顯著增長的情況下，DB明顯在性能上存在明顯瓶頸，分鐘級計算基本是這套系統的極限。

因為沒有了規則引擎概念，所有的都是通過配置rule來進行數據抽取，自由度高的代價自然是每次調整規則或者新增規則都需要進行發布，在某些需要應急響應的場景下，尤其是對比黑產團隊調整自身策略的速度，往往捉襟見肘。

總結：風險庫系統雖然填補了離線黑產數據統計的問題，但是離真正的防御黑產，依然是任重道遠。

2.0時代

介紹完上面的準實時風險防御系統和離線風險庫系統后，可以說有了一個實時+異步數據的雛形，在這個基礎上，攜程信息安全業務安全團隊構建了下面這樣一個平臺，我們命名為Ares平臺。

這個是Ares系統的架構圖，讀者可以看到，相對于之前兩個系統的架構，這個系統除了頂層的API接口定義沿用了之前的老接口定義（避免接入方做無謂的開發調整），其他的架構基本上都做了重構。

數據層：
數據層負責對各種結構化以及非結構化數據進行統一的數據收集，清洗，預處理操作。目前來說，這種清洗注重點一般在區分正常用戶和異常用戶的注冊，登錄到賬戶各種重要操作，瀏覽PV數據，到最后購買旅游產品的一個行為區別，以及用戶存在是否批量操作的相關數據抽取，這也被稱為用戶的社交網絡區分。

規則引擎層：
規則引擎層負責將清洗及預處理完成的數據，使用實時流或者迭代作業按照定義好的規則或者模型進行數據計算，將計算完成的數據，存放在數據倉庫內，以供分析層或者應用層調用。

分析模型層：
分析模型層負責將目前已有的清洗完成以及計算完成的結果數據再清洗和歸類，進行后續的規則分析，補充，調整，模型的建立，以及離線+實時評分卡的數據權重比例調整等。

應用層：
應用層主要負責將綜合得到的實時+離線的評分卡形式的得分結果通過SOA接口返回給業務方，告知業務方請求是否存在風險，并提供操作建議，同時會將相關請求數據全部記錄，以供后續分析。
系統優勢：

由于Ares系統使用實時+離線兩部分數據通過評分卡形式實時給出結果，避免了之前準實時數據和離線數據各自為戰，有效提高了返回結果的準確性和有效性。

系統架構的更新，有效提高了數據的統計量和計算效率，帶來的直接效果就是可以數據量放大，可以覆蓋更多的低頻次異常操作檢測，比如低頻掃號，低頻爬蟲，在新架構上線后，抓取率明顯提高。

分析層同時引入規則和模型同時提供異常檢測策略，在某些已存在黑樣本的場景下，尤其是規則運行時間長，黑產團隊不斷變化策略的情況下，模型的異常檢出率和覆蓋率會優于規則。

目前這套系統已經開始陸續為攜程多個部門提供黑產及異常行為檢測，并且在年后，會基于這套系統打造攜程的賬戶風險畫像體系，為攜程所有高危行為接口提供行為異常檢測分析，比如無風險用戶，可以直接修改某些賬戶信息，高風險用戶，則需要驗證多種信息，才能進行賬戶信息或者其他的交易相關操作等。

黑產團隊一直在進行著技術以及思路的變化，不斷的挑戰甲方的信息以及資金安全。在這種大背景下，我們唯有不斷的自我革新，才能應對國內復雜多變的黑產局勢。

總結

以上是生活随笔為你收集整理的携程风险防御体系的变革之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。