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

1.0時代

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

控制用戶嘗試登錄的頻率

控制單個緯度登錄帳號的數(shù)量

控制手機號發(fā)送短信的頻率

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

控制單個賬號的積分發(fā)送

控制特定緯度的登錄及領(lǐng)卷

架構(gòu)圖如圖：

這套風(fēng)險防御系統(tǒng)的特點有：

黑名單數(shù)據(jù)同時DB＆redis雙寫

數(shù)據(jù)預(yù)處理和數(shù)據(jù)引擎耦合，無法更改

長時間數(shù)據(jù)計算基于DB做sharding分片

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

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

在默認(rèn)的引擎范圍內(nèi)，可以自由添加規(guī)則，并實時發(fā)布

結(jié)果由黑白名單服務(wù)響應(yīng)，可以直接導(dǎo)入黑名單

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

使用下來，優(yōu)缺點都很明顯。

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

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

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

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

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

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

總結(jié)：隨著業(yè)務(wù)量的增長和業(yè)務(wù)場景的增加，這套系統(tǒng)已經(jīng)明顯顯現(xiàn)了性能和業(yè)務(wù)需求的瓶頸，需要改造。

1.5時代

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

基于這個情況，我們在去年上線了風(fēng)險庫系統(tǒng)，這個系統(tǒng)旨在用現(xiàn)有的時間跨度較大的業(yè)務(wù)數(shù)據(jù)，異步計算相關(guān)風(fēng)險，并輸出給黑白名單服務(wù)，由這個服務(wù)為各個業(yè)務(wù)方提供結(jié)果。

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

（1）計算規(guī)則相對復(fù)雜，所以沒有規(guī)則引擎的概念，直接使用sql統(tǒng)計，自由度高。
（2）由于直接使用sql統(tǒng)計，所以無法做規(guī)則實時調(diào)整，一定要進(jìn)行發(fā)布。
（3）離線計算數(shù)據(jù)是周/天級別，計算時間顆粒度是分鐘級別。
（4）統(tǒng)計結(jié)果支持下發(fā)黑白名單服務(wù)，無需讓業(yè)務(wù)方單獨接入。

在這個系統(tǒng)上線后，可以說我們才具備了一個風(fēng)險規(guī)則(rule)這樣一個概念，同樣的，這個系統(tǒng)的優(yōu)缺點也很明顯。

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

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

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

因為沒有了規(guī)則引擎概念，所有的都是通過配置rule來進(jìn)行數(shù)據(jù)抽取，自由度高的代價自然是每次調(diào)整規(guī)則或者新增規(guī)則都需要進(jìn)行發(fā)布，在某些需要應(yīng)急響應(yīng)的場景下，尤其是對比黑產(chǎn)團(tuán)隊調(diào)整自身策略的速度，往往捉襟見肘。

總結(jié)：風(fēng)險庫系統(tǒng)雖然填補了離線黑產(chǎn)數(shù)據(jù)統(tǒng)計的問題，但是離真正的防御黑產(chǎn)，依然是任重道遠(yuǎn)。

2.0時代

介紹完上面的準(zhǔn)實時風(fēng)險防御系統(tǒng)和離線風(fēng)險庫系統(tǒng)后，可以說有了一個實時+異步數(shù)據(jù)的雛形，在這個基礎(chǔ)上，攜程信息安全業(yè)務(wù)安全團(tuán)隊構(gòu)建了下面這樣一個平臺，我們命名為Ares平臺。

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

數(shù)據(jù)層：
數(shù)據(jù)層負(fù)責(zé)對各種結(jié)構(gòu)化以及非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行統(tǒng)一的數(shù)據(jù)收集，清洗，預(yù)處理操作。目前來說，這種清洗注重點一般在區(qū)分正常用戶和異常用戶的注冊，登錄到賬戶各種重要操作，瀏覽PV數(shù)據(jù)，到最后購買旅游產(chǎn)品的一個行為區(qū)別，以及用戶存在是否批量操作的相關(guān)數(shù)據(jù)抽取，這也被稱為用戶的社交網(wǎng)絡(luò)區(qū)分。

規(guī)則引擎層：
規(guī)則引擎層負(fù)責(zé)將清洗及預(yù)處理完成的數(shù)據(jù)，使用實時流或者迭代作業(yè)按照定義好的規(guī)則或者模型進(jìn)行數(shù)據(jù)計算，將計算完成的數(shù)據(jù)，存放在數(shù)據(jù)倉庫內(nèi)，以供分析層或者應(yīng)用層調(diào)用。

分析模型層：
分析模型層負(fù)責(zé)將目前已有的清洗完成以及計算完成的結(jié)果數(shù)據(jù)再清洗和歸類，進(jìn)行后續(xù)的規(guī)則分析，補充，調(diào)整，模型的建立，以及離線+實時評分卡的數(shù)據(jù)權(quán)重比例調(diào)整等。

應(yīng)用層：
應(yīng)用層主要負(fù)責(zé)將綜合得到的實時+離線的評分卡形式的得分結(jié)果通過SOA接口返回給業(yè)務(wù)方，告知業(yè)務(wù)方請求是否存在風(fēng)險，并提供操作建議，同時會將相關(guān)請求數(shù)據(jù)全部記錄，以供后續(xù)分析。
系統(tǒng)優(yōu)勢：

由于Ares系統(tǒng)使用實時+離線兩部分?jǐn)?shù)據(jù)通過評分卡形式實時給出結(jié)果，避免了之前準(zhǔn)實時數(shù)據(jù)和離線數(shù)據(jù)各自為戰(zhàn)，有效提高了返回結(jié)果的準(zhǔn)確性和有效性。

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

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

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

黑產(chǎn)團(tuán)隊一直在進(jìn)行著技術(shù)以及思路的變化，不斷的挑戰(zhàn)甲方的信息以及資金安全。在這種大背景下，我們唯有不斷的自我革新，才能應(yīng)對國內(nèi)復(fù)雜多變的黑產(chǎn)局勢。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。