作者前言：
在过去的10年里，我参与了三家公司不同领域的风险控制系统的设计。我仔细考虑了风险控制系统的所有环节，但我仍然觉得我只是一只脚进门。
大多数人生产的产品都有明确的目的，比如订单支付、账户系统一开始就知道该做什么，有很多竞争产品可供参考；风险控制系统完全不同——不可能完全理解未来要面对什么问题。每个功能都要谨慎，因为如果你不注意错误的方向，你可能不得不在未来的某个阶段完全推翻它。
对于研发资源短缺的安全需求，我们往往会在某个时候把自己置于非常尴尬的境地，问题无法解决，转型面临着大量的时间和沟通成本。
所以，在这里分享一些我踩过的坑，让准备搭建风险控制的人心里有个数。
业务安全风险控制设计101-信息采集
业务风险控制主要做四件事：
拿数据几乎是决定风险控制系统成败的核心。由于空间问题，我们首先要考虑三件事：
1、数据越详细越好：
以账户安全为例。如果您能获得基本的登录注册数据，您可以分析频率和登录注册特征；
如果您可以进一步获得登录注册行为的上下文，如登录前访问的页面和登录后访问的页面，您可以从访问行为轨迹中增加更多的分析维度，如页面停留时间、是否访问必要的页面等；
如果您还可以获得用户的操作行为数据，如鼠标移动轨迹和键盘输入，您可以从操作过程中进一步增加分析维度。例如，您在输入密码时是否多次输入和删除？直接复制粘贴的帐户密码吗？
2、建立标准日志格式：
在确认可以获得的数据后，开始建立标准的日志格式。
常见的登陆、注册、下单、密码修改、绑定凭证修改等等都要给出一个标准的日志格式，而且要充分考虑到字段命名的统一，比如密码、用户名字段的名称如果在不同的日志中叫法不统一，在后续分析和指定策略的时候都会遇到不小的麻烦。
3、拿到的数据质量：
能得到所有必要的字段吗？
风险控制往往关心信息，如风险控制IP地址、UserAgent、referer这些信息业务并不关心，但这些信息的缺乏可能会导致许多策略无法完成，所以在信息收集开始时应该有一个明确的信息列表。一旦妥协，然后返工，研发将是白眼睛。
数据信息准确吗？
用户访问更为常见IP，结果拿到的IP地址是内网服务器IP;或者想要用户名，结果是传递的UID。这需要大量的前期沟通和确认工作。一旦发现数据不对，一旦上线就会变白。
有两种主动和被动的方式来获取数据：
1、主动方式
主动去数据库和日志读。
这种 *** 实时性差，基本上很难添加信息，但不需要研发太多的东西，适合喜欢自己丰衣足食的场景。
当然，一些成熟的公司有自己的消息总线。风险控制可以实时订阅信息，然后作为数据源进行分析，但这通常是少数；
2、被动方式
被动方式是为研发提供界面，让业务按照格式标准喷消息。
这种合作周期很长，但是可以按照标准获得高质量的信息，所以是建立风险控制系统的常用 *** 。
踩坑记
1、号坑：
如果消息是多数据源，则必须考虑消息的时间顺序：
比如登录日志是公共服务发的，网页访问是拿的access_log，用户操作行为数据页面 *** 或者SDK这三者的时间是不一致的。
这需要在确认所有信息到位后进行分析和判断。否则，如果实时策略考虑登录时必须单击页面键盘，两个数据到位时间不一致，可能会发生大量误封事故。
2、号坑：
收集到的数据必须定期监控数据质量——
由于技术架构调整、代码更新等各种奇怪原因，收集到的数据可能不准确。如果不能及时发现，可能会导致以下一系列分析过程出现错误。
3、号坑：
尽量选择稳定的业务点，如收集登录日志，一次性收集公共服务，只要找到一个问题。
假如是去前端WEB、移动终端和其他调用登录服务点进行收集。如果出现问题，需要更改的工作将成倍增加，新业务点的日志可能无法覆盖。
4、号坑：
关于技术选型：
必须使用消息队列restful只能处理业务日志，比如登录这种1秒最多几次的类型。如果你想在后期收集页面访问行为，你必须使用队列.
可以考虑开源RabbitMQ或者Kafka,稳定性好。
5、号坑：
关于日志存储：
ELK为后续的分析平台提供基本的查询功能是一个不错的选择。
结语
信息收集往往是实施风险控制最困难的环节，但也是最重要的环节。覆盖、质量和及时性决定了项目的成败。
由于沟通的压力，往往会有更多的妥协，这为后期风险控制系统的建设埋下了隐患。事实上，一篇文章很难详细描述细节。
如果您在这方面遇到困难，请留言与我们沟通。如果您对下一个内容感兴趣，请分享并鼓励小边，我们将尽快给出后续章节。
作者介绍：
科技联合创始人刘明 ，***产品技术官
超过6年的风险控制和产品相关经验，曾在网易工作，负责魔兽世界中国账户系统的安全。现带领互联网业务风险控制团队为客户提供明星产品Warden和RED.Q风险控制服务。
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。