教育数字化知识图谱

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 时代

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

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

从这个简单的系统架构图可以看到，我们在保证原先风控系统架构不变的前提下，加入了这个风险库系统，对外仍然使用统一的黑白名单服务 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 系统使用实时 + 离线两部分数据通过评分卡形式实时给出结果，避免了之前准实时数据和离线数据各自为战，有效提高了返回结果的准确性和有效性。

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

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

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

黑产团队一直在进行着技术以及思路的变化，不断的挑战甲方的信息以及资金安全。在这种大背景下，我们唯有不断的自我革新，才能应对国内复杂多变的黑产局势。