<p>干货</p>    <p>观点</p>    <p>案例</p>    <p>资讯</p>    <p>我们</p>    <p>作者前言</p>    <p>从业近10年，大大小小参与了3家公司不同领域的风控系统的设计，从前到后把风控系统所有环节都细细的琢磨过，然而至今仍然感觉刚刚一只脚踏进门而已。</p>    <p>大多数人做的产品都是目的明确的，比如订单支付、账户体系要做什么一开始就知道了，而且也有很多的竞品可以去参考；风控系统却完全不一样——未来要面对什么问题不可能完全了解，做每个功能都谨小慎微，因为一个不注意走错了方向，可能就会在未来的某个阶段要全盘推翻。</p>    <p>而对于研发资源紧缺的安全需求来看，往往会在某个时间把自己摆到一个非常尴尬的境地，问题解决不了，改造又面临大量的时间和沟通成本。</p>    <p>所以，把本人踩过的一些坑在这里分享出来，让准备搭建风控的人心里有个数。</p>    <p>业务安全风控设计101-信息采集</p>    <p>业务风控主要做四件事：</p>    <p>拿到足够多的数据</p>    <p>做足够灵活的分析平台去分析数据</p>    <p>产出风险事件进行阻拦风险</p>    <p>量化风险拦截的价值和不断分析案例进行策略优化</p>    <p>拿数据这件事几乎是决定风控系统成败的核心，由于篇幅问题我们先主要说这点，主要有三件事要考虑：</p>    <h3><strong>1 拿到的数据越详细越好：</strong></h3>    <p>拿账号安全这件事来举例子，如果能拿到 <strong>基础的登陆注册数据</strong> ，就可以从频率、登陆注册特征来进行分析；</p>    <p>如果可以进一步拿到 <strong>登陆注册行为的上下文</strong> ，比如登陆前访问了哪些页面，登陆后去访问了什么，就可以从访问行为轨迹来增加更多的分析维度，例如页面停留时间，是否有访问到必访问的页面等；</p>    <p>如果还可以拿到 <strong>用户的操作行为数据</strong> ，比如鼠标移动的轨迹，键盘输入，那么可以进一步的从操作过程来增加分析维度，比如是不是输入密码的时候有过多次输入删除？是不是直接复制粘贴的账号密码？</p>    <h3><strong>2 建立标准的日志格式：</strong></h3>    <p>确认好能拿到哪些数据以后，就要开始建立 <strong>标准的日志格式</strong> 。</p>    <p>常见的登陆、注册、下单、密码修改、绑定凭证修改等等都要给出一个标准的日志格式，而且要充分考虑到字段命名的统一，比如密码、用户名字段的名称如果在不同的日志中叫法不统一，在后续分析和指定策略的时候都会遇到不小的麻烦。</p>    <p><strong>3 拿到的数据质量：</strong></p>    <ul>     <li> <p>必要的字段是否都能拿到？</p> </li>    </ul>    <p>往往风控关心的信息比如IP地址、UserAgent、referer这些信息业务都是不关心的，但这些信息的缺失可能造成很多策略没法做，所以在采集信息开始的时候就要有个明确的信息列表，一旦妥协了后面再去返工让研发加是会遭白眼的。</p>    <ul>     <li> <p>数据信息拿的是否准确？</p> </li>    </ul>    <p>比较常见的是需要用户的访问IP，结果拿到的IP地址是内网的服务器IP；或者是想要用户名，结果传递过来的是UID。这点需要大量的前期沟通确认工作，一旦上线了以后发现数据不对再改也同样要遭白眼。</p>    <p>拿数据有 <strong>主动方式</strong> 和 <strong>被动方式</strong> 两种：</p>    <p><strong>1 主动方式</strong></p>    <p>主动方式是自己去数据库、日志里面去读。</p>    <p>这种方式实时性比较差，而且基本有什么拿什么，想加信息是比较难的，但不需要研发配合太多事情，适合喜欢自己动手丰衣足食的场景。</p>    <p>当然有些比较成熟的公司有自己的消息总线，风控可以去实时的订阅信息然后作为数据源进行分析，但这种通常为少数；</p>    <p><strong>2 被动方式</strong></p>    <p>被动方式就是提供接口给研发，让业务把消息按格式标准喷过来。</p>    <p>这种配合周期非常长，但可以按照标准来拿到高质量的信息，所以是比较常见的风控系统搭建方式。</p>    <p>踩坑记</p>    <p><strong>1号坑：</strong></p>    <p>如果拿消息是多数据源的时候，必须要考虑到 <strong>消息的时间序</strong> 问题：</p>    <p>比如登陆日志是公共服务发过来的，网页访问是拿的access_log，用户操作行为数据是页面JS或者SDK发过来的，那么这三者的时间是不一致的。</p>    <p>这就必须要在确认所有的消息到位之后再进行分析判断。 否则，如果实时策略考虑了登陆的时候必须有页面键盘点击，而两个数据到位的时间不一致，就可能出现大量的 <strong>误封</strong> 造成事故。</p>    <p><strong>2号坑：</strong></p>    <p>对采集回来的数据必须定期的 <strong>对数据质量进行监控</strong> ——</p>    <p>已经采集到的数据可能因为技术架构调整，代码更新等各类奇葩原因造成采集回来的数据不准了，如果无法及时发现可能造成后面一系列分析过程都出现错误。</p>    <p><strong>3号坑：</strong></p>    <p>采集点尽量选择 <strong>稳定的业务点</strong> ，比如采集登陆日志，一次性在公共服务采集好，后面出现问题只要找一个点。</p>    <p>如果是去前端从WEB、移动端等各个调用登陆服务的点去采集，出了问题要改动的工作就会成倍增加，还有可能出现新业务点的日志无法覆盖的情况。</p>    <p><strong>4号坑：</strong></p>    <p>关于 <strong>技术选型</strong> ：</p>    <p>消息队列是必须的，用restful只能处理业务日志比如登陆这种1秒最多几次的类型，如果后期要去采集页面访问行为这种一秒上千的消息就必须要用到队列.</p>    <p>开源的可以考虑RabbitMQ或者Kafka,稳定性都还不错。</p>    <p><strong>5号坑：</strong></p>    <p>关于 <strong>日志存储</strong> ：</p>    <p>ELK是不错的选择，为后续的分析平台提供基本的查询功能。</p>    <p>结语</p>    <p>信息采集往往是实施风控的最难的一个环节，但也是最重要的环节，覆盖、质量、时效都决定了项目的成败。</p>    <p>因为出于沟通的压力，往往会有比较多的妥协，也就为后期风控系统的搭建埋下了隐患，其实也很难一篇文章把细节描述详尽。</p>    <p>如果你在这方面遇到了难点， <strong>欢迎留言和我们沟通交流</strong> ，如果对接下来的内容感兴趣，请分享鼓励一下小编，我们会尽快给出后续的章节。</p>    <p> </p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s?__biz=MzIxNDE4MzA4OQ==&mid=2651024906&idx=1&sn=bc6799a2121e29edd46ced66272ff0f7&chksm=8c5cb3d4bb2b3ac2b338abacfb9d7d3b05a093343aaca02ddc59eaae016ff6355a0c4576cb37&scene=0</p>    <p> </p>