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

PAGE 1 PAGE 1 携程风险防御体系的变革之路  携程信息安全业务安全团队在这几年来，风险防备体系演进变革的要点，遇到的一些坑，如何做技术选型，解决了哪些逆境，走过的弯路，各位读者可以将本文作为自身建设风险防备系统的攻略参考，也可以作为一个回忆录，避免重复踩坑。  1.0时代  过去携程曾经使用一套基于.NET的风险防备系统作为掌握注册，登录，支付以及其他相关场景的主要手段，这套系统主要由三个服务组成：数据收集服务，规则引擎服务，黑白名单服务。主要实现的场景案例有：  1.掌握用户尝试登录的频率  2.掌握单个纬度登录帐号的数量  3.掌握手机号发送短信的频率  4.掌握单个纬度注册帐号的频次和数量  5.掌握单个账号的积分发送  6.掌握特定纬度的登录及领卷  架构图如图：  这套风险防备系统的特点有：  1.黑名单数据同时DB＆redis双写  2.数据预处理和数据引擎耦合，无法更改  3.长时间数据计算基于DB做sharding分片  4.支持的纬度由于预处理流量表写死，无法添加  5.结果纬度由流量表掌握，无法自由添加，且无法组合  6.在默认的引擎范围内，可以自由添加规则，并实时发布  7.结果由黑白名单服务响应，可以直接导入黑名单  8.支持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时代  在介绍了上面的系统后，读者一定会发觉，这个系统阻挡的场景由于规则引擎的不可变，导致了能拦截到的异常数据都是基本固化的，在黑产千变万化的当今，这个系统只能应付应付一些特别初级的黑产兴趣爱好者以及一些测试人员，想要依靠上面这个系统，去阻挡真正的扫号工作室，批量注册，薅羊毛等状况，无异于痴人说梦。  基于这个状况，我们在去年上线了风险库系统，这个系统旨在用现有的时间跨度较大的业务数据，异步计算相关风险，并输出给黑白名单服务，由这个服务为各个业务方供应结果。  从这个简洁的系统架构图可以看到，我们在保证原先风控系统架