0×01 风控产品场景与工作原理

风控概念针对不同的行业(如金融)，不同的业务场景(如贷款)都有不同的解决方案。本文基于上一篇文章《互联网业务安全之通用安全风险模型 》提到的互联网行业的业务安全通用漏洞模型为背景，以目前风控产品从该模型角度出发，技术层面讲解其中可以用技术来解决的风控防护方案中的人机识别方案。

个人认为判断一套风控产品的好坏应该具有的特点：有效性、高可用性、高可移植性、实时性。有效性直观反应的是技术上对数据风险的分析能力，使用的分析方法，采取的分析手段等;高可用性是对风控底层架构设计，存储、传输及高并发等各种情况系统稳定的考量;高可移植性也是决定风控成败最关键的指标之一，高可移植性决定风控系统对业务系统的耦合度要相应的低，包括接入部署、决策可控、自身扩展性强等;实时性是在交互系统的各个环节都非常重要，尤其对于支付/交易等重要环节的尤为突出，如何尽可能的保障延迟的架构设计就留给读者朋友自己思考了。

目前国内做风控的厂商也越来越多，针对不同业务也相应推出了不同的产品。技术上的风控体系分解出来主要有几个部份：信息采集系统、风险分析系统、风险决策系统。高可移植性风控产品目前采用的架构架构如下图:

0×02风控产品构建

信息采集系统的建设，主要指对PC端及移动端H5的可用信息进行布点采集。采集的信息有设备软硬件信息、用户交互行为数据、用户环境信息、用户历史信息、用户业务数据。采集的软硬件信息加密作为对用户的唯一标识符，即设备指纹。关于设备指纹原理请参考:《设备指纹简析》，具体的设备指纹代码实现请参考fingerprintjs2，设备指纹设计的重要性对整个风控系统至关重要，做好设备指纹可更好的标识每个用户的所有行为的可;

用户交互行为数据的采集主要针对的是人在应用的交互数据，人的正常行为是不可预料且具有相对随机性的，机器要模拟正常人非常困难。交互为先数据的采集主要采集正常人的动作，如鼠标移动、鼠标点击、鼠标释放、触摸板动作、键盘操作。具体比如采集鼠标在某个区域内的连续坐标变化及时间点、键盘操作的时间点及键值等;

用户环境信息的采集包括用户操作系统版本、cpu集、浏览器版本、屏幕分辨率、屏幕大小、屏幕色彩、浏览器安装的插件、浏览器语言、浏览器支持的字体、用户的ip信息、cookie tracking、每个浏览器针对不同方法的处理特性信息、来源、location等尽可能收集的信息;

用户历史信息包括历史行为信息，例如交易、支付、登录等;用户业务数据的采集可视情况而定，比如针对用户身份的cardid、手机号、邮箱等。

风险分析系统的建设，主要是对采集回来的大量信息进行数据分析的阶段，通过对数据的分析，对用户的整体操作行为风险进行评估分值加权。比如设备指纹与账户一一对应的前提下，设备的变动的情况，环境的变化情况，包括IP变动等。行为的分析比如分析鼠标移动的频繁、坐标在某个区域或某个操作下的动作速度、是否为直线或者不可能存在的曲线。或者用户操作的环境及行为不匹配等各种差异情况。历史行为的估值、用户信誉的估值。最终将所有风险加权估值判断。风险分析系统也可在无法确定风险时作出风控二次处理的决策，最终得出用户风险值等。对于风险分析系统的建设，本文只是初略讲解，具体分析风险方法很多，待读者自己挖掘。

风险决策系统的建设，风险决策系统与风险分析系统及业务系统也独立存在，主要针对风险分析的分值，在一定阈值内实现业务打标或者业务清洗的功能。比如对于低于某个分值高于风险分析的用户进行业务打标，然后对用户的操作进行业务层上的限制以积累信用积分等操作。风险决策可根据自身的业务数据进行相应的策略上的调整可控。

0×03策略、破解、防护

风控产品的整体架构大体上如上所述，基于该架构下的风控衍生出各自独立的工作模块(子系统)，例如独立的行为系统、设备系统、分析系统、决策系统等等，对于用户感知的无外乎前端行为采集系统或者设备指纹系统。目前国内产品的展现形式有两种，风险识别产品，基于设备指纹、业务数据等进行风险判断服务;风险拦截产品，如阿里的滑动验证和Google的recaptcha对检测出的风险进行风险阻断。如风险拦截产品大致的架构也如最上图所示，前端采集->风险判断->反馈->后台决策的模式。对于互联网企业或者金融公司而言，采集的方式可以有js、客户端、控件等等，采集的内容可以是任何潜在有价值抑或未来有价值的数据，这些数据都直接作为分析决策系统的依据。

防护与对抗是安全永恒的话题，对于风控的技术性对抗，直观体现在于信息的采集的破解，伪造数据。比如采用JS前端采集，最容易面对的就是js对于客户端是处于明文状态，最常见的手法也就是混淆、压缩等。对黑客而言，无外乎时间成本和技巧。

系统再完美也无法规避被破解的可能，所以信息对抗的目标就是进一步提升攻击成本。如何让风控的前端破解伪造风险降至更低，以下以JS采集为例提供若干的一些思考。从JS采集最终提交到服务器分析的数据的可靠性考虑，可以在密文中打入前端特定字符验证;前端密文的高混淆的灵活性，针对AST分析的处理;明文与密文、模块与模块之间的高耦合性等，避免数据传输及算法变化的有规律性;另外对于单设备或者单IP在时间段内的限制等

后端分析及策略可通过对采集回的信息做样本学习，比如同一个为行为动作在某个点会不会发生，世界上不可能有同样一片树叶，所以正常行为人的动作也不可能完全一样，可通过分析用户移动速度规律等进一步提高分析能力。对前端的采集的特殊行为及特殊字段，比如浏览器响应的样本及传送回的浏览器类型一致性等作为数据检校的关键指标;对同一设备指纹的设备不同业务场景的操作的限制;对信誉值较低的用户递进式验证等。