相比数量，我们更应关注数据质量。数据为王本身并没有错，问题是怎样的数据才能为王？
典型误区：只要数据多就能解决问题
当你说数据为王，通常会伴上大数据、Hadoop、Storm等一系列高大上的名词概念。我所在的团队每一天都在和数据打交道。我们建立了一套以数据为核心的风控运营体系。我们也注意到同行里很多企业都建立起了自身的风控系统，并且“数据为王“常常被大家挂在口边。
华丽风控系统背后是强大的数据技术支撑，然而一句“数据为王”却是风控建设过程中无数惨痛经验教训的总结。本篇不谈成功，我们只谈失败，谈谈那些决定风控系统能否真正取得成功的决定性因素。
在某款玫瑰金手机首发的秒杀活动中，黄牛动用了有史以来最强大的资源向我们发起了最凶残的抢购请求。此时选购线各个接口开始报错，后端压力骤然飙升，监控系统疯狂告警。
为快速问题，团队筛选并封禁了大量IP地址，但仍然不能彻底解决后端系统的压力。大概有上千个的黄牛账号在持续更换IP疯狂请求购物车前端接口，压力传递到了后端。此时除了封禁IP，业务风控团队还需要快速识别黄牛所使用的ID并予以踢下线和冻结。
问题来了：通过这些异常IP向服务器发起请求的账户到底有哪些？从了解到的情况看，现有系统的日志包括：Nginx日志和购物车数据库记录。
购物车接口请求日志（Nginx）：
http://example.com/cart/add.php?&product_id=1111&ip=1.1.1.1
购物车业务日志（MySQL）
| cart_id | user_id | product_id | time |
|---|---|---|---|
| 1 | 123 | 1111 | 2016-03-03 10:00:10 |
| 2 | 456 | 1111 | 2016-03-03 10:00:12 |
| 3 | 789 | 4444 | 2016-03-03 10:00:13 |
很显然Nginx日志中能够看到接口的参数，有商品，有IP，就缺少UserId。购物车数据库中存储了商品Id和UserId，但却没有IP。在这样的现实条件下，再强大的风控系统也无能为力，因为两组日志数据都不完整，任何一组都不能算是完整的信息。
试想，如果接口或MySQL两者中的任何一个能够完整记录一次购物请求的关键日志，业务安全监控绝不会如此被动，很显然我们需要的是这样的日志记录：
http://example.com/cart/add.php?&product_id=1111&ip=131.1.1.1&userid=123
或者：
| cart_id | user_id | product_id | client_ip | time |
|---|---|---|---|---|
| 1 | 123 | 1111 | 131.1.1.1 | 2016-03-03 10:00:10 |
| 2 | 456 | 1111 | 208.2.2.2 | 2016-03-03 10:00:12 |
| 3 | 789 | 4444 | 127.1.1.1 | 2016-03-03 10:00:13 |
经过上一次经验教训，购物车团队依照我们的要求在数据日志中同时增加了用户ID和IP两个信息。那么我们是不是可以轻松应对下一次抢购了呢？鼻青脸肿之后，我们明白——想得太简单了。由于公司网络架构的原因，购物车接口同时接受来自LVS、F5等不同设备的请求，这期间一个负载设备的错误配置导致购物车底层看到的用户IP地址为内网地址，而非用户真实IP！
| cart_id | user_id | product_id | client_ip | time |
|---|---|---|---|---|
| 1 | 123 | 1111 | 192.168.9.8 | 2016-03-03 10:00:10 |
| 2 | 456 | 1111 | 123.10.1.1 | 2016-03-03 10:00:12 |
| 3 | 789 | 4444 | 219.23.2.2 | 2016-03-03 10:00:13 |
好吧，如果你看到的IP已经不是真实攻击者的IP，那么如何才能执行封禁IP呢？
对异常订单进行二次筛选是风控运营人员每天在做也是最为头疼的工作。举个最简单的例子，下述订单一眼就能看出是异常。
| order_id | order_time | order_address |
|---|---|---|
| 1 | 2016-04-16 12:00:01 | 广州市.番禺区.氓气氕氖路1号 |
| 2 | 2016-04-16 12:00:02 | 广州市.番禺区.気氘氙洔路2号 |
| 3 | 2016-04-16 12:00:03 | 广州市.番禺区.洣津洦洧路3号 |
| 4 | 2016-04-16 12:00:03 | 广州市.番禺区.紣崔败䴧路4号 |
但是，如果如果面临特征不明显的订单时，单纯依靠订单自身的信息是很难判断这些是否为异常订单。很显然，在分析异常订单时，风控运营人员需要更多的辅助信息以增加识别精准度和降低误报率。针对上述情况，如果增加人机识别等多样性数据，系统或运营人员能够再次降低异常订单的误判
| order_id | order_time | order_address | 页面浏览次数 |
|---|---|---|---|
| 1 | 2016-04-16 12:00:01 | 广州市.番禺区.人民路102号 | 20 |
| 2 | 2016-04-16 12:00:02 | 广州市.番禺区.南朝大街105司库书城 | 0 |
| 3 | 2016-04-16 12:00:03 | 广州市.番禺区.胡杨小区2幢101 | 0 |
| 4 | 2016-04-16 12:00:03 | 广州市.番禺区.区政府大门口对面包子店 | 5 |
这里只增加了一项最近出的PV计算，就能为识别恶意订单提供有力的佐证。
无数血与泪的经验告诉我们，要做好业务风控，必须要让业务系统提供足够可用的日志记录，有时我们也称之为“埋点“。那么到底哪些信息是关键的，哪些又是必须记录下来的呢？我的团队对过往的日志记录和分析过程做了多次梳理和总结，最终形成如下结论。任何数据埋点必须包含以下几大要素：
时间
日期
时间戳
用户
用户ID
用户登录名
用户手机号
用户邮箱
第三方账户唯一识别号
用户付款账户
设备
IP地址
IP段
IP地理区域
客户端浏览器
客户端APP
微信
H5页面
资源
用户信息
商品信息
购物车信息
订单信息
访问方式
Web访问
APP访问
访问结果
成功
失败
举一个例子：
2016-04-19 12:00:01,1234567,[email protected],13888888888,113.65.254*,广东.广州,login,android,v2.11,failed
最终解决问题的是你值得信赖的基础数据和分析方法。
好了，我们已经解决了数据质量，接下来我们来解决数量的问题。嗯，我考虑好了，放在下一期：）
我将以业务风控为主题进行连载，关注VSRC微信公众号可以第一时间获取信息。变的是笔名，不变的是公众号，关注我吧。
原文：
http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=2652277114&idx=1&sn=82afefde2b29c494347c897d211e2ac9#rd
相关推荐
VSRC连载系列（2）：VPN真的安全吗？继上周机房排错后，A同学又接到公司需求：总部希望有一个更加灵活的上网环境，希望SOHO员工能便捷的接入公司资源，且出于安全考虑，所有数据必须经过严格的加密传输。于是A同学便想到了EzVPN，EzVPN采用中心站点管理模式，通过动态的分发策略，从...
VSRC连载系列（1）：谁动了我的500端口？作为一枚代码小白，周末当然一如往常的宅家学习Coding啦，不过突然接到A同学的求助说上周在机房配置好的VPN现在突然连不上了。而且监控发现流量很大，怀疑是被恶意攻击了。于是在简单了解之后发现是一个普通的站点到站点的IPSec VPN，两端...
VSRC连载系列（1）：谁动了我的500端口？作为一枚代码小白，周末当然一如往常的宅家学习Coding啦，不过突然接到A同学的求助说上周在机房配置好的VPN现在突然连不上了。而且监控发现流量很大，怀疑是被恶意攻击了。于是在简单了解之后发现是一个普通的站点到站点的IPSec VPN，两端...
听博士讲引力波与信息安全在爱因斯坦的描述中，有质量的物体会使它周围的时空发生扭曲；物体的质量越大，时空就扭曲得越厉害。时空告诉物质如何运动； 物质告诉时空如何弯曲；今天，博士告诉大家，引力波还与信息安全有关。点击以下链接，查看完整内容：http://mp.weixin.qq.com/s...
本站收录的网站若侵害到您的利益，请联系我删除处理.| 联系QQ：22333889 请注明来意！ Copyright © 2022 信安人·全栈导航网 All Rights Reserved. 粤ICP备15080684号 XML地图 信安人·全栈网 | aqer.cn
