搭建风控系统道路上踩过的坑合集

做者前言

从业近10年，大大小小参与了3家公司不一样领域的风控系统的设计，从前到后把风控系统全部环节都细细的琢磨过，然而至今仍然感受刚刚一只脚踏进门而已。

大多数人作的产品都是目的明确的，好比订单支付、帐户体系要作什么一开始就知道了，并且也有不少的竞品能够去参考；风控系统却彻底不同——将来要面对什么问题不可能彻底了解，作每一个功能都谨小慎微，由于一个不注意走错了方向，可能就会在将来的某个阶段要全盘推翻。

而对于研发资源紧缺的安全需求来看，每每会在某个时间把本身摆到一个很是尴尬的境地，问题解决不了，改造又面临大量的时间和沟通成本。

因此，把本人踩过的一些坑在这里分享出来，让准备搭建风控的人内心有个数。

业务安全风控设计101-信息采集

业务风控主要作四件事：

1. 拿到足够多的数据

2. 作足够灵活的分析平台去分析数据

3. 产出风险事件进行阻拦风险

4. 量化风险拦截的价值和不断分析案例进行策略优化

拿数据这件事几乎是决定风控系统成败的核心，因为篇幅问题咱们先主要说这点，主要有三件事要考虑：

1 拿到的数据越详细越好：

拿帐号安全这件事来举例子，若是能拿到基础的登录注册数据，就能够从频率、登录注册特征来进行分析；

若是能够进一步拿到登录注册行为的上下文，好比登录前访问了哪些页面，登录后去访问了什么，就能够从访问行为轨迹来增长更多的分析维度，例如页面停留时间，是否有访问到必访问的页面等；

若是还能够拿到用户的操做行为数据，好比鼠标移动的轨迹，键盘输入，那么能够进一步的从操做过程来增长分析维度，好比是否是输入密码的时候有过屡次输入删除？是否是直接复制粘贴的帐号密码？

2创建标准的日志格式：

确认好能拿到哪些数据之后，就要开始创建标准的日志格式。
常见的登录、注册、下单、密码修改、绑定凭证修改等等都要给出一个标准的日志格式，并且要充分考虑到字段命名的统一，好比密码、用户名字段的名称若是在不一样的日志中叫法不统一，在后续分析和指定策略的时候都会遇到不小的麻烦。

3拿到的数据质量：

必要的字段是否都能拿到？

每每风控关心的信息好比IP地址、UserAgent、referer这些信息业务都是不关心的，但这些信息的缺失可能形成不少策略无法作，因此在采集信息开始的时候就要有个明确的信息列表，一旦妥协了后面再去返工让研发加是会遭白眼的。

数据信息拿的是否准确？

比较常见的是须要用户的访问IP，结果拿到的IP地址是内网的服务器IP；或者是想要用户名，结果传递过来的是UID。这点须要大量的前期沟通确认工做，一旦上线了之后发现数据不对再改也一样要遭白眼。

拿数据有主动方式和被动方式两种：

1主动方式

主动方式是本身去数据库、日志里面去读。
这种方式实时性比较差，并且基本有什么拿什么，想加信息是比较难的，但不须要研发配合太多事情，适合喜欢本身动手丰衣足食的场景。
固然有些比较成熟的公司有本身的消息总线，风控能够去实时的订阅信息而后做为数据源进行分析，但这种一般为少数；

2被动方式

被动方式就是提供接口给研发，让业务把消息按格式标准喷过来。
这种配合周期很是长，但能够按照标准来拿到高质量的信息，因此是比较常见的风控系统搭建方式。

踩坑记

1号坑：

若是拿消息是多数据源的时候，必需要考虑到消息的时间序问题：
好比登录日志是公共服务发过来的，网页访问是拿的access_log，用户操做行为数据是页面JS或者SDK发过来的，那么这三者的时间是不一致的。
这就必需要在确认全部的消息到位以后再进行分析判断。不然，若是实时策略考虑了登录的时候必须有页面键盘点击，而两个数据到位的时间不一致，就可能出现大量的误封形成事故。

2号坑：

对采集回来的数据必须按期的对数据质量进行监控——
已经采集到的数据可能由于技术架构调整，代码更新等各种奇葩缘由形成采集回来的数据不许了，若是没法及时发现可能形成后面一系列分析过程都出现错误。

3号坑：

采集点尽可能选择稳定的业务点，好比采集登录日志，一次性在公共服务采集好，后面出现问题只要找一个点。
若是是去前端从WEB、移动端等各个调用登录服务的点去采集，出了问题要改动的工做就会成倍增长，还有可能出现新业务点的日志没法覆盖的状况。

4号坑：

关于技术选型：
消息队列是必须的，用restful只能处理业务日志好比登录这种1秒最多几回的类型，若是后期要去采集页面访问行为这种一秒上千的消息就必需要用到队列.
开源的能够考虑RabbitMQ或者Kafka,稳定性都还不错。

5号坑：

关于日志存储：
ELK是不错的选择，为后续的分析平台提供基本的查询功能。
信息采集每每是实施风控的最难的一个环节，但也是最重要的环节，覆盖、质量、时效都决定了项目的成败。

业务安全风控设计--信息分析

在获取足够多的数据以后，接下来的事情就是要建立一个机制去灵活的处理这些信息，为自动分析捕捉风险事件提供基础原料，进而借助规则引擎从中分析出风险事件。
接下来，一样的有三件事情须要考虑：

1让分析人员能够快速的查询原始日志

日志并非简单的存下来，从风控分析的需求来看，经过IP、用户名、设备等维度在一个较长的跨度中搜索信息是很是高频的行为，同时还存在在特定类型日志，好比在订单日志或者支付日志中按特定条件搜索的需求。

而这些主要是为了可以让分析人员能够快速的还原风险CASE，例如从客服那边获得了一个被盗的案例，那么如今须要从日志中查询被盗时间段内这个用户作了什么，这个过程若是有一个界面能够去作查询，显然比让分析人员用grep在一大堆文件中查询要快的多，而且学习门槛也要低得多。

若是在日志作过标准化的前提下，也能够进行后续的业务语言转译，将晦涩难懂的日志字段转化为普通员工都能看得懂的业务语言，也能极大的提高分析师在还原CASE时阅读日志的速度。

2实时或定时的计算加工消息成变量&档案

例如在分析某个账号被盗CASE的时候，每每须要把被盗期间登陆的IP地址和用户历史经常使用的IP地址进行比对，即便咱们如今能够快速的对原始日志进行查询，筛选一个用户的全部历史登陆IP并察看被盗IP在历史中出现的比例也是一个很是耗时的工做。
再好比咱们的风控引擎在自动判断用户当前登陆IP是否为经常使用IP时，若是每次都去原始日志里面查询聚合作计算也是一个很是“贵”的行为。

那么，若是能预约义这些变量并提早计算好，就能为规则引擎和人工节省大量的时间了，而根据这些变量性质的不一样，采起的计算方式也是不一样的。不过还好咱们有一个标准能够去辨别：频繁、对时效敏感的利用实时计算（好比访问频率、时间间隔）；而相对不频繁、对时效不敏感的利用定时计算（好比用户的经常使用IP、设备，即便少算短时间内的登陆记录，也不会受到太大影响）

3选择规则引擎将人工策略自动运行

一个设计优雅的规则引擎是把分析师的经验决策和数据最终转化为风险输出的核心模块，首先说为何须要规则引擎而不是选择硬编码逻辑——
笔者无数次遇到过这种场景，一个上午刚刚上线的策略，没过1个小时，攻击者或者欺诈者就已经试出绕过策略的方法了，若是你的风险控制逻辑是硬编码，那么恭喜你，再走一遍开发测试发布流程。

快速响应是安全的生命线，没法想象还有比被攻击者胖揍48小时而后才反应过来去挡脸更让人沮丧的事情了。

因此策略引擎必须能把策略逻辑从业务逻辑中解藕出来，让防护者能够灵活配置规则在静默模式下验证和实时上线生效，并能够去随时调整。

相似的开源框架有不少，各有优劣，但若是须要下降学习曲线，必须进行一层包装（这里又是一个比较大的话题，就先略过了）。

坑位标注：

一、Sharding会影响到你的策略

为了支持并发和性能，一般在利用集群计算变量的时候咱们会用到sharding。
sharding方式会按IP把数据分配到不一样的运算单元中去处理，在读取结果的时候按IP去集群中的某台机器中去拿数据，以大幅提高并发处理读取计算结果的能力。
那么，如今若是我想去按某个USER去拿数据的时候，就会发现一个用户在不一样IP下的信息被保存在不一样的服务器上了，因此单一的Sharding分配确定是不合理的，这点必需要注意。

二、策略中用到的变量，能不用现场算的就不用

有些简易的策略引擎设计中用到的变量都是到数据库里现场算的，虽然能够极大的提高灵活性（新的变量不须要考虑历史数据回补），但会极大的影响稳定性和响应时长，尤为在业务请求爆发的时候几乎都会出现宕机无响应的问题。
要知道业务研发对安全的结果并非那么敏感，但若是出现了问题致使应用不稳定给人添麻烦，被抛弃可能就是迟早的事情，因此变量必定要尽可能作到提早计算，而且设立缓存机制。

三、对风险分析要用到的计算资源有充分的认识

绝不夸张的说，合格的风险分析要作的实时、准实时计算量要大过应用内全部计算的总和甚至超过几倍。
其实这也很好理解，好比一个典型登陆场景，业务要作的逻辑最主要的就是检查密码和账号的身份是否吻合，而风控要把这登陆用户的历史档案所有拉出来看个遍，而后根据风控策略来决定是否放行。因此在规划风险分析要用到的资源时请不要吝啬，按业务5X甚至10X的标准来评估风险分析的资源需求。

若是说信息采集主要看的是安全产品经理的沟通协调能力，设计风险分析功能更多的就是考验安全产品经理的逻辑思惟能力。

到了这样一个阶段，外部冗杂的沟通协调已经结束，但如何最大化利用前期打下的基础，须要对风险问题的分析、决策过程有一个很是清晰的认识，这里也有一个比较好的标准来去检验：
分析平台设计的差，那么就只有设计者本身会用；设计的好，你会发现处理投诉的客服、分析师都会很乐意来用你的分析平台为他们解决问题。

可是分析出来的东西不能光本身看着High，还得去阻拦这些风险才能真正产生业务价值。

业务安全风控设计--阻拦风险

到了第三步咱们离整个系统核心框架的搭建就只剩一步之遥了，那么让咱们看看这个环节要考虑什么：

一、最终呈现给业务研发直白的断定结果

咱们最终从数据中发现的报警和问题最终是要在业务逻辑中去阻拦的，在接入这些结果的时候，每每分析师以为能够提供的信息有不少，好比命中了什么规则、这些规则是什么、何时命中的、何时过时，其中最让接入方心烦的当属风险分值当仁不让了，不少接入风控的研发看到这些分值就一脑壳包：你到底想让我作什么，拦仍是不拦？这时候若是你喏喏的再丢出个多少分值以上要拦，研发多半都会跟你说直接给我结果就行了。
是的，不少风控接口设计的都十分累赘，无用信息多到研发会以为你在故意浪费带宽，其实一个code list给他们说明对应但愿作的操做就好，必定把你以为那些很牛逼的中间结果等等包装成最终结果再给出去。

二、T＋0仍是T＋1

举个例子来解释实时(T+0)和异步（T＋1）风险判断的区别。

T+1
你在打拳击比赛，选手A只会打脸，上来就照着你脸来了一拳，你分析了一下打脸很疼并且不科学，在第二拳往脸挥过来时你忽然告知对方不可打脸，对方就成功的被你克制住了。这就是T+1的特色，至少要在第二次风险攻击才能够生效；

T＋0

拳击比赛第二场对阵选手B，一样被打脸后你说不可打脸，对方说好，结果冲着肚子就来了一拳。你说禁止打肚子，对方又一拳打腋下。这时你发现要在对方挥拳立刻打到你以前就要禁止。
这就是T＋0了。
由于T＋0在接入的时候要额外承担不少计算成本，结果要现场算出来而延时要求又很高，因此通常都只在攻击者得手关键步骤采起实时判断（好比订单支付或者提现请求）。而对于其余场景能够选择T＋1方式，好比登陆或者提交订单等。

三、阻断逻辑到阻断产品

这一点咱们岂安在对外演讲的时候介绍过不少，在阻断风险的时候事件发生的点是不一样的，但短时间又不可能让业务研发在全部的地方接入风险阻断怎么办？
因此咱们须要考虑几个基本的保底措施，好比统一的验证码验证页面在IP层全局防止任何爬虫脚本行为，在帐号层经过登陆态管理统一拦截单个帐号在登陆后任何风险行为（全局强制登出）。
可能这些措施在体验上不是最好的，可是在发生特殊问题的时候要等研发给你临时加阻断逻辑这个时间就无法控制了。

坑位

一、接入风控阻断的逻辑位置

登陆的时候帐号输入框鼠标失焦就要去走风控了，登陆结果出来以后再去判断就没意义，而资金相关的通常是在跳转去收银台以前，你会发现通常风险判断都是在结果出来以前（收集本次行为完整日志以前），因此若是你要作T+0判断，就要求研发在进行风险判断的时候要提供更完整的信息，而不是只给个IP或者帐号名就好了（每每T＋1就之要这些就够）。

二、对业务流量充分调研并关注

平时可能流量很小的业务，忽然由于某个活动（好比秒杀）流量大增，除了在接入之初要对风险判断请求有了解，对后续的活动也要提早准备，不然若是资源预估不足，忽然又遇上这个点接了T+0接口有不少要现场计算的逻辑，陡增的业务流量分分钟教你作人。

三、bypass ！ bypass ! bypass

风控风险判断的最基本原则就是要不影响业务逻辑，因此超时机制在一开始就要严格约定并执行，一旦发现风控接口超过预计响应时间立马放行业务请求。

四、让一线同事们知道你在作什么

任何风控准确率都不是100%的，因此在和研发沟通好接入后必定要告诉一线同事们风控阻断可能出现的表象，以及大体的缘由，以免一线客服们对风险拦截的投诉不知道如何解释，并给出具体的阻断回复措施（加白名单、删除黑名单等等，上帝们在某些日子好比315维权意识是很是强的）。

阻断是最终产生真实价值的环节，另外也是关联部门最敏感的环节（吓唬我半天逼着我把风控接了，结果一天到晚给我出毛病？生产环境是给大家玩的？！），请保护这相当重要的信任，你后面会越作越顺的。

业务安全风控设计--效果评估与优化

风控系统和大部分的产品项目同样，最终须要对领导层汇报这个项目为公司带来了什么价值，这是评估项目成功与否的要素；

另外是哪里作的不够好，若是改善了能带来更多的价值，给出了预期才有后续资源的补充，整个项目才能转起来造成一个良性循环。

如今开始说说这个系列的最后一话：如何对风控系统进行效果评估与优化。
咱们看一下这个环节要考虑的：

1.找到钱在哪里
风控项目的基本价值在于省钱，而省钱的思路基本有三种：直接拦截风险带来的止损（好比提早阻止了一笔欺诈交易所挽回的损失）；提高服务稳定性所带来的业务基本指标提高（好比因阻止风险事件所下降的服务响应延时而提高的业务转化）；下降服务不可用几率事件所带来的直接业务损失（好比下降了风险事件致使服务宕机所带来的营收损失）。

能够看出这三点是按风险事件的暴力程度作出的简单划分，其实也还有不少其余不一样的视角来分类，很大程度上和对应企业的互联网业务形态有关。

而咱们作这样划分的目的是为了：在一开始就明确风控项目从哪里能够挖掘效益。
不少状况下风险事件不是一个独立的问题，而是一个链条，由一些看起来影响不大的问题逐层深刻。好比，交易欺诈并非一个独立的问题，而是由于注册环节发生的垃圾注册问题攻击者手里有了大量的帐号所致使的，因此任何一个风险问题都是有价值的。
无利不起早，做为风险分析者应当有能力找到其中的关联转化关系，并预测对方的得手点进行效果评估会有更好的效果。

2.有效利用预期价值的力量

天下没有100%准确的风控策略，因此在接入拦截的过程当中业务方可能存在种种阻力，每每的一个误区是没有拦截就认为风控没有效果。
其实，效果评估不仅是在最后项目落地评估价值所用，在推行项目中间也有很好的效果，虽然没有拦截，但预期效果放在那里，这对决策者平衡业务影响有着重要的价值。

3.学会考虑企业财务目标

风控系统并非一个无关紧要的东西。其实大部分企业中安全已是业务的必要组成部分了，那么咱们知道在资源有限、而业务风险问题无限的状况下，全部的资源投入都必然有一个优先级，而这个优先级与整个企业发展的现状必须是紧紧捆绑在一块儿的。
讲简单些：风控系统解决什么问题，评估出的效果与企业目前业务关心的问题息息相关。
若是企业目前的业务重点在一次年度促销活动，那么风控的重点就应当在促销羊毛党；若是企业目前面临严重的帐户盗用投诉问题，那么重点就应在帐号安全。尤为在风控系统启动之初，配合系统的需求交付时间选择对应的重点问题，对于项目效果的评估是一个巨大的加分项，切记一开始就贪大贪全。

4.策略的生命周期和健康度

风控系统的规则有多少？哪些已经好久没有触发了？产生误判投诉的对应规则有哪些？一个新规则在创建起初的效果确定是最有效的（由于这时风险问题正在发生，而规则正好对应了风险），但随着时间其有效性是呈快速降低的趋势。
好比，攻击者都知道网站三次输入密码错误触发验证码，他们会傻傻的尝试第三次猜想密码的几率有多大？那么，是否有人在按期的去统计分析这些规则的效率？这就是风控产品的重要运营环节了。
而运营风控产品所要付出的代价，每每大于常规互联网业务产品，而且是保证项目可以持续产出价值并不断迭代进化的一个前提。

写在最后

业务风控是一个很是具备挑战性的项目，我一直把它比做一种竞技游戏，而这种攻防不一样于传统安全（在传统安全你并不能有足够的技术能力预测全部人的攻击方法），它更强调逻辑和预测——
攻守双方在一个双方充分了解的环境下（业务逻辑简单到任何人均可以理解，但又能够产生无数的变化和组合）不断的博弈。

而这正是业务风控系统的乐趣所在。

业务风险问题足够简单而又足够复杂，正是这样的缘由其参与攻击者并无过高的门槛限制。处于国内互联网的环境下，任何一家企业都不可能逃开业务风险问题的影响。
做一个比喻，这片土壤是有着本身的一些特质的，企业若是是生长在这片土壤中的一颗树，投入足够的营养才能快速生长，而业务风险则是寄生于树木窃取营养的角色，只有可以充分抵御这种风险的才能成长为参天大树。

做者介绍 刘明 岂安科技联合创始人，首席产品技术官 超过6年的风控和产品相关经验，曾就任网易，负责《魔兽世界》中国区帐户体系安全。现带领岂安互联网业务风控团队为客户提供包括了明星产品Warden和RED.Q的风控服务。