二十一世纪，互联网已经充斥在我们生活中的方方面面，人们在获得便利的同时也面对着大量的风险产生，或黑产、或漏洞、或泄露导致的风险问题层出不穷，到如今，我们每一个人不再是这场安全攻防战中的看客，每一次问题的发生，风险都可能直接影响到我们，轻则个人基础信息泄露，重则账号、账户资金被盗，更有甚者可能直接失去了即将到手的总统之位。至此，越来越多的企业开始关注安全，尤其是业务安全，其中大部分选择自建业务风控体系，今天我们聊聊在自建过程中的一些“坑”。

业务风控离不开数据，数据是否多而全将直接影响到风控精准度和范围，但要收集多而全的数据并不简单：

1） 数据字段不统一

企业内部各产品线由于业务逻辑的不同，开发人员开发习惯的不同，设备渠道的不同，相同含义的数据字段会被定义得五花八门，如代表账号唯一标识的，可能会有account、account_id、account_uuid、id、aid等，又比如手机端和网页端的HTTP头的一些自定义属性命名的不同，这是都是无法避免的，但风控系统需要将这些格式化为标准规范，因为在进行规则配置和事后分析中，我们需要将相同的信息进行关联，此时相同含义的字段被标准化为同一字段就尤为重要，所以风控系统需要有适应的能力，常见的做法有两种，风控系统使用标准的字段表提供业务方来映射后接入，或由风控系统来拥提供字段映射的能力，将五花八门的字段映射成标准规范字段，两种方法没有好坏之分，主要看推行力度。

2） 层出不穷的衍生字段

接入的数据日志是为了后续的规则、模型服务的，在安全攻防的过程中，规则和模型几乎是天天在变，无论是规则策略本身，还是规则阈值，都会在应对层出不穷的恶意用户的对抗中不断调整，此时原生的接入日志就会显得不够看了，试想下以下场景：

接入了IP地址，业务方发送过来的IP地址为1.2.3.4，原先规则只需要对是1.2.3.4的进行黑名单的命中，很好，我们直接将这原生的IP进行配置，实现了恶意IP的封堵。但是过几天（理想太丰满，一般也就最多1小时了），恶意用户来了一堆1.2.3.5，1.2.3.6的IP进入了，此时原生的就不够看了，我们取巧可以通过配置一些IP前缀（startWith）等于1.2.3的规则来代替（机智脸）。可又过了没多久，恶意用户变成了更分散的IP进行频繁尝试，我们发现唯一的特征是这群IP归属地都是上海，这时候已经很难通过后面的规则进行配置了，就算可以跟着hard code出归属地，最终你会发现，恶意用户又改变了，这次使用的是一堆代理IP。（奔溃中。。。）

通过上述这个“栗子”，我们发现攻防中变是必然的，并且是极高频率的，诚然，我们可以将这部分逻辑做到规则中去，但是个人觉得规则引擎分担的是规则类型，规则逻辑，而这种转换的工作，字段属性的衍射，应该放在字段预处理中，使风控系统在字段配置表里加入新增预处理字段的能力，来扩展出这些更多维度的衍生变量。

3） IP取值逻辑

在企业内部，当你辛辛苦苦和业务方沟通完风控系统的接入方案，开发环境、测试环境都联调妥当后，上生产了，激动人心的时刻到了，一验收，IP和当时开发、测试环境一样，依旧是内网IP，此处省去内心奔溃一万字。。。这种坑极其常见，主要由两类情况导致的：

a)IP获取方式错误，现今手机端比重已经是主流，大部分的核心业务都是主推APP，这时候有的业务方会直接在APP前端去获取IP地址，然后将数据抛给风控系统，此时获取的IP就极容易变成该终端设备wifi环境下的内网地址，完全没有参考意义。而正确的做法应该是从业务方的服务器去获取真实的客户端地址。

b)第二个主要是由于前端路由配置问题导致的，如Big F5、nginx，配置不同直接可能导致在内网跳跃过程中，将真实的IP丢弃，从而导致取到了路由的内网地址。一般情况，如用的是nginx代理，X-Real-IP和X-Forwarded-For都是可以的，但是如果web拓扑是多层nginx代理，则需要取X-Forwarded-For的第一个IP，这是由nginx内部代理一路带过来的，才是真实的客户端IP(这里其实真实的场景会更为复杂，也要根据HAProxy和nginx的具体位置来确认配置参数)。这边也提一下环境中软件版本的一致性也是尤为需要重视的，本人之前就遇到测试环境和生产环境由于jar版本的不一致性，导致相同配置无论如何在生产上都获取不到外网IP的情况发生，尤其需要注意。

4） SDK相关的一些“坑”

环境设备信息、设备指纹已然成为了业务风控的标配，业务方上报事件的时候，单纯的业务属性字段，公共服务的访问日志，设备信息已经成为了业务风控的三叉戟，在业务风控中扮演着不可或缺的角色。而设备信息与指纹并非只是简单的在web中植入webjs，在app中植入SDK就好的，会遇到很多坑。

a)渠道与数据收集

业务风控系统在收集设备相关信息的时候需要了解本次用户的访问渠道到底是web、wap、android、IOS等，对于这些渠道可能之后会有不同的风控权重。而现在一些比较流行的H5页面，大部分是通过手机端去访问的，这时候可能会面对的冲突是H5也植入了web设备指纹，而手机端也植入了sdk的设备指纹，此时以哪个为准，一般我们更建议以手机端的SDK收集作为主要参考依据，因为从实现逻辑来看更成熟，也更精准。但这不能一概而论，因为此时app与其访问的H5页面很有可能是两条业务线，这时候单一的顶替就会出现问题，因为不同业务线基于的设备信息并不一定一致，渠道风险度也不尽相同，这时候需要具体情况具体分析，一味着一条路走到底是行不通的，之后会遇到死胡同。

b)采集信息真伪与运用之坑

设备信息和业务数据不一样，业务数据是由业务方发送，几乎不存在数据真实性问题，但在采集设备信息的时候一定要确保数据的真实性，因为后续的风控规则很多会基于设备信息和设备指纹来做，举个例子，很多时候我们会根据类似imei，serialno，idfa，imsi等的信息来作为设备指纹和信息的一些重要参考依据，但由于有些手机运营商的策略，一些恶意用户存心篡改，自身SDK的取值兼容性问题可能直接导致我们取来的数据是假的，空的，或者并非我们想要的。而很多风控规则会需要使用到设备唯一指纹这样的属性，这时候就需要考虑很多了。首先技术对抗是不可避免的，不然任何方案都是徒劳。其次设备指纹的生成逻辑，不能随机生成，也不能简单的放在content provider/storage/key chain里，这样极其容易被修改和清空，导致后续无法关联。还有就是需要关注各类篡改软件、模拟器设备等恶意软件的一些更新，也从他们的patch中来重新审视自身的SDK是否过硬，否则这些都将成为日后规则运营挥之不去的拦路虎。