携程风险防御体系的变革之路

随着OTA在线旅游市场规模越来越大，据统计，2016年第一季度中国在线旅游市场交易规模达到1301.2亿元，环比增长17.4%，同比增长41.4%。OTA市场营收规模为64.6亿元，同比增长51.3%，在这种高速增长的大环境下，国内的黑产行业自然不会放过这份饕餮盛宴。

不管是骗补贴，薅羊毛，信息欺诈，批量注册，爬虫或者是直接扫号后进行资金转移，已经从前几年的散兵游勇，发展为目前的集团化作战，对企业的各种防御策略，黑产团伙也进行了不断的变化，来进行适应及突破，从中获取巨大的利益。

为了应对黑产团伙的变化，自然企业的风险防御之道也需要随着黑产的变化而变化，并且在不久的将来，变化速度和深度都需要有一个质的飞跃，由被动防御变为主动感知。

本文接下来会分享携程信息安全业务安全团队在这几年来，风险防御体系演进变革的要点，遇到的一些坑，如何做技术选型，解决了哪些困境，走过的弯路，各位读者可以将本文作为自身建设风险防御系统的攻略参考，也可以作为一个回忆录，避免重复踩坑。

 

1.0时代

过去携程曾经使用一套基于.NET的风险防御系统作为控制注册，登录，支付以及其他相关场景的主要手段，这套系统主要由三个服务组成：数据收集服务，规则引擎服务，黑白名单服务。

主要实现的场景案例有：

 

架构图如图：

 

yewu1

 

这套风险防御系统的特点有：

使用下来，优缺点都很明显。

 

优点：

规则可以实时的配置，测试，上线，下线，虽然规则引擎和纬度存在一定限制，但是针对短时间内做登录&注册的流量控制，应该来说是可以接受的。

配合验证码，比如“同一个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时代

在介绍了上面的系统后，读者一定会发现，这个系统阻挡的场景由于规则引擎的不可变，导致了能拦截到的异常数据都是基本固化的，在黑产千变万化的当今，这个系统只能对付对付一些非常初级的黑产兴趣爱好者以及一些测试人员，想要依靠上面这个系统，去阻挡真正的扫号工作室，批量注册，薅羊毛等情况，无异于痴人说梦。

基于这个情况，我们在去年上线了风险库系统，这个系统旨在用现有的时间跨度较大的业务数据，异步计算相关风险，并输出给黑白名单服务，由这个服务为各个业务方提供结果。

yewu2

 

从这个简单的系统架构图可以看到，我们在保证原先风控系统架构不变的前提下，加入了这个风险库系统，对外仍然使用统一的黑白名单服务API接口提供结果，保证了业务方不需要再接入一个新的服务API，这个设定节约了我们大量的系统推广成本以及接入方的接入成本，只需要在内部确保系统的可用性和性能即可。

风险库系统的特点：

（1）计算规则相对复杂，所以没有规则引擎的概念，直接使用sql统计，自由度高。

（2）由于直接使用sql统计，所以无法做规则实时调整，一定要进行发布。

（3）离线计算数据是周/天级别，计算时间颗粒度是分钟级别。

（4）统计结果支持下发黑白名单服务，无需让业务方单独接入。

在这个系统上线后，可以说我们才具备了一个风险规则(rule)这样一个概念，同样的，这个系统的优缺点也很明显。

 

优点：

由于可以使用sql语句做各种复杂统计，相当于是一个没有任何限制的规则引擎，所以可以根据人工分析结果，设置各种复杂规则，分别应对扫号，爬虫，异常注册，活动/优惠卷领取等等各种场景，并且效果经过验证，相对于准实时风险防御系统计算的结果只能做一个短时间维持（比如密码错3次，只能让一个账户30分钟不能尝试登录），风险库系统计算应对的异常目标的维持时间可以长达几年（异常注册的薅羊毛账号，可以让他5年不能参与活动）。

相对于准实时风险防御系统计算的量大，精度低这么一个特点，风险库得到的结果是量小，精度高，都是99%以上可以确认有问题的纬度值，填补了无法长时间维持黑名单，做异常数据积累的问题。

 

缺点：

由于种种原因，当时上线这个系统的时候，任务紧时间急，架构选取的是sql+db+redis，导致了计算大体量数据，尤其是在目前业务量年年显著增长的情况下，DB明显在性能上存在明显瓶颈，分钟级计算基本是这套系统的极限。

因为没有了规则引擎概念，所有的都是通过配置rule来进行数据抽取，自由度高的代价自然是每次调整规则或者新增规则都需要进行发布，在某些需要应急响应的场景下，尤其是对比黑产团队调整自身策略的速度，往往捉襟见肘。

总结：

风险库系统虽然填补了离线黑产数据统计的问题，但是离真正的防御黑产，依然是任重道远。

 

2.0时代

介绍完上面的准实时风险防御系统和离线风险库系统后，可以说有了一个实时+异步数据的雏形，在这个基础上，携程信息安全业务安全团队构建了下面这样一个平台，我们命名为Ares平台。Ares

 

这个是Ares系统的架构图，读者可以看到，相对于之前两个系统的架构，这个系统除了顶层的API接口定义沿用了之前的老接口定义（避免接入方做无谓的开发调整），其他的架构基本上都做了重构。

数据层：

数据层负责对各种结构化以及非结构化数据进行统一的数据收集，清洗，预处理操作。目前来说，这种清洗注重点一般在区分正常用户和异常用户的注册，登录到账户各种重要操作，浏览PV数据，到最后购买旅游产品的一个行为区别，以及用户存在是否批量操作的相关数据抽取，这也被称为用户的社交网络区分。

规则引擎层：

规则引擎层负责将清洗及预处理完成的数据，使用实时流或者迭代作业按照定义好的规则或者模型进行数据计算，将计算完成的数据，存放在数据仓库内，以供分析层或者应用层调用。

分析模型层：

分析模型层负责将目前已有的清洗完成以及计算完成的结果数据再清洗和归类，进行后续的规则分析，补充，调整，模型的建立，以及离线+实时评分卡的数据权重比例调整等。

应用层：

应用层主要负责将综合得到的实时+离线的评分卡形式的得分结果通过SOA接口返回给业务方，告知业务方请求是否存在风险，并提供操作建议，同时会将相关请求数据全部记录，以供后续分析。

系统优势：由于Ares系统使用实时+离线两部分数据通过评分卡形式实时给出结果，避免了之前准实时数据和离线数据各自为战，有效提高了返回结果的准确性和有效性。

系统架构的更新，有效提高了数据的统计量和计算效率，带来的直接效果就是可以数据量放大，可以覆盖更多的低频次异常操作检测，比如低频扫号，低频爬虫，在新架构上线后，抓取率明显提高。

分析层同时引入规则和模型同时提供异常检测策略，在某些已存在黑样本的场景下，尤其是规则运行时间长，黑产团队不断变化策略的情况下，模型的异常检出率和覆盖率会优于规则。

目前这套系统已经开始陆续为携程多个部门提供黑产及异常行为检测，并且在年后，会基于这套系统打造携程的账户风险画像体系，为携程所有高危行为接口提供行为异常检测分析，比如无风险用户，可以直接修改某些账户信息，高风险用户，则需要验证多种信息，才能进行账户信息或者其他的交易相关操作等。

结语：

黑产团队一直在进行着技术以及思路的变化，不断的挑战甲方的信息以及资金安全。

在这种大背景下，我们唯有不断的自我革新，才能应对国内复杂多变的黑产局势。

安全，绝不仅仅只是靠说的，期待属于携程业务安全的3.0时代尽快到来！

 

【原文：携程风险防御体系的变革之路  作者：携程信息安全部小胖胖   安全脉搏整理发布】

源链接

Hacking more

...