本文不会特别干，毕竟风控可有太多的领域了，无论是内容、交易、营销等场景，都不可避免地要设计好风控才能上。本文主要是说说在业务安全中风控体系的构成，包括事前、事中、事后所需要的一些技术要素，权当为初入本行的人搭建一个理论框架体系。
在互联网企业中 toC 业务安全的环境下，做风控的核心在于利用可信数据进行全面的风险管理，包括预防、检测、响应和缓解潜在的欺诈和滥用行为。
这里一般都是分成两大板块（引擎部分由于要做得太多，有些人认为该拆成规则 + 算法模型接入 + 画像），拆开并行做：
终端部分
终端这里是广义的，包括手机、平板和电脑。目前大趋势是 PC 端功能限制越来越多，厂商"逼"用户使用手机移动端来使用产品。
因此做风控时，在移动终端上的对抗最为激烈，我们可以粗暴地说：终端部分要做的就是埋点收集数据，上报给引擎，引擎做出决策。终端部分的计算任务一般不多，主要在于终端采集到的数据都不一定可信，更何况是计算类任务呢...
具体需要采集哪些信息呢？
举个例子，做风控肯定是要给用户的每台设备生成一个"唯一"的设备 ID。不过，现在安卓版本越来越新，对获取系统某些状态的方法限制太多了，我们举例：
Android 10 之后的 WIFI MAC 地址都是随机的，以前不变的 MAC 每次都变，是不是这个信息就无效了？
一些重视用户隐私的 ROM，在获取 IMEI 时候会返回一串随机码，这个怎么办？
Android 8之后的 ID 是隔离的，也就是说每一个应用程序看到自己获取到的 Android ID 都是不同的，这又怎么做关联？
要解决的问题很多很多，但是我们知道核心思想即可：
通过稳定且唯一的标识符识别用户的设备。
稳定性表示设备经过改机或恢复出厂设置以后还能保证设备ID 不变。唯一性表示不同设备（尤其是同一型号的设备ID ）不一致。
系统级设备ID信息收集
有很多可以采集来用，OAID、SN、开机时长、硬件配置、设备是否 Root、是否被改机、系统属性对不对之类的，都属于系统级的信息可以采集上来用。
再例如各种传感器状态啊，可发挥的地方很多，但前提是需要先知道该收集到哪些基础数据。
应用级设备ID信息收集
Android ID、VAID、AAID、应用列表和局域网设备等等，这些都是应用级的设备ID收集项。
在实际的工程中，生成一个唯一的设备ID很容易，但难点在于稳定性。保证设备指纹不漂移，是一个非常浩瀚的工程...从众多变量中找相对稳定的不变量困难程度极高。现在通用的方法是用关联或找回的思路来做，就是基于收集到的设备特征反查特征库(图谱)，是这么个路径：
收集应用层到内核层的特征数据
上传到后台，使用私有算法生成一个唯一设备指纹，也就是设备ID
找回：利用多重ID，包括AndroidID、IMEI、IDFV、IDFA等尝试找回已经分配的设备ID，如果找不到，则认为是新设备，分配新的ID，在后台存储ID映射关系，并下发给终端存储。所有的生成和找回都是依赖于ID的映射关系查询，后台处理逻辑简单，可以快速查询。
稳定性这里真的很难，APP卸载重装、APP清空缓存、系统OTA升级等多种场景下保持不变还好说，iOS可能放keychain里、Android那就放在存储的隐藏目录之类保存。但抹机之后还保持设备ID稳定的话，没啥太好的参考，可以想办法通过获取某些硬件的唯一标识入手，或者根据行为特征综合UID来判断下
上面说的全都是设备指纹这一个部分，实际上终端做的事不只是这些，还有很多东西例如行为收集啊、反调试啊等等，都是终端该做的事儿。现在也有很多风控SDK能一键接入，效果先不谈，但可以避免一穷二白，先用起来总好过没有对吧。
引擎部分
光有终端的数据上来还不够，还需要有一个靠谱的风控决策引擎，这个引擎就是给运营使用的平台，一定要有规则编辑和规则执行、灰度、数据统计分析这几块。流程分支太多，总不能一个一个写if else吧？当然也不是不行，但写多了难免会破防😓。一个比较完善的风控引擎（或者说风控中台？都行）会对接终端风控系统、实时和离线指标计算平台、风控数据画像、机器学习和模型平台等各类风控子系统，集中进行风险计算和决策，避免产生"数据孤岛"。
当然，上来就实现这么大的宏伟目标不够现实，做一个勉强可用的引擎也行呀，甚至你直接写个简单的页面，页面上写能识别到黑产作恶的SQL特征并保存下来，也算是个规则引擎了...
实现一个简单的规则引擎要么用Drolls之类开源的，要么自己实现，只要保证能对每一个事件根据你写好的规则集判定就可以了。
再说说设备指纹
指纹最重要的两个特性：稳定性和唯一性。
这里其实有两种思路，第一个思路是管你什么特征不特征的，我直接放弃稳定性，每次都服务器下发一个随机的 UUID 就完了，收集到的特征都存起来，纯靠引擎里的规则和模型来做风控。
第二个就是，尽可能地用"稳定"的特征来生成一个设备ID，使用时候先去服务端的ID中查询看有没有能对应上的，没有的话就插入一条记录，有的话就直接下发服务端存储过的ID。
用户行为习惯特征
现在基本所有应用都会收集用户的使用习惯特征，例如你的浏览时长、停留时长、甚至输入速度、点击速度、验证码滑动曲线等等。这些特征对抗养号有点用，例如灰产批量养号，这些号的使用习惯大概率高度类似，做个简单的聚类就能发掘一大批账号有问题。灰产对抗的方式就是随机呗，那这时候风控就要加入另一层特征了，例如传感器状态，那灰产也会进步，你读传感器那我就改传感器，做风控是一个持续的行为，灰产为了赚钱会一直进步，也会倒逼业务和安全共同进步。
规则还是模型？
规则为主，做模型难度高、开发周期长、效果"可能"比直接的规则会好，但也有可能更烂...在我看来，模型更多是对规则照顾不到的角落或者规则暂时支持不好的场景做补充吧。
灵魂问题：你做的事，价值在哪里？
先要说到可感知，啥意思呢？举个例子：
假设某一天你的应用有一万次登录，但是成功了8000次，失败了2000次，你说这是为什么呢？是有黑产来撞库吗？还是有啥别的原因？
做风控的第一步不一定是打击，而是要先大概摸清楚用户中有哪些是"坏人"，哪些是"好人"。
摸清楚之后，你的leader问：
你做这件事有什么价值？
我相信大家没少听这句话（笑。
讲出风控，或者说安全这种成本部门的价值有两个很大的难点：
风控部门的产出是"消除"了可能的经济损失或商誉损失
但也正因为损失被消除了，让我评估一个不存在的事情（例如杨幂的演技）就变得很离谱
我的套路一般是讲定价，你别和我提什么价值了，我就给你看我做出的这套系统，在市场上一般卖多少钱。这个是很好的量化手段；再例如，这一波我阻断了多少人薅羊毛，这些羊毛在市场上多少钱，但这里的价格不会太好看，我一般不说。
最后回到文章开头：可信数据
在互联网企业中 toC 业务安全的环境下，做风控的核心在于利用可信数据进行全面的风险管理，包括预防、检测、响应和缓解潜在的欺诈和滥用行为。
之前遇到过这种情况，查数据发现终端收集到的很多特征根本就是错的，全是假数据，在一张破表上面查来查去，查到最后属于拉了一坨大的...
来源可靠、质量高、准确性和完整性经过验证的特征数据很重要，换句话说修改起来越困难、收集越难的特征才越重要，再举个小例子：你把收集特征的代码写在java层，相比写在so再做一层VMP肯定是更麻烦的，这对于逆向者来说是一个很大的挑战，因此从VMP加固后的so中收集到的特征数据就比在java层收集到的数据特征更可信。