近年来, 数据安全形势越发严峻, 各种数据安全事件层出不穷. 在当前形势下, 互联网公司也基本达成了一个共识: 虽然无法完全阻止攻击, 但底线是敏感数据不能泄漏. 也即是说, 服务器可以被挂马, 但敏感数据不能被拖走. 服务器对于互联网公司来说, 是可以接受的损失, 但敏感数据泄漏, 则会对公司产生重大声誉, 经济影响.
在互联网公司的数据安全领域, 无论是传统理论提出的数据安全生命周期, 还是安全厂商提供的解决方案, 都面临着落地困难的问题. 其核心点在于对海量数据, 复杂应用环境下的可操作性不佳.
例如数据安全生命周期提出, 首先要对数据进行分类分级, 然后才是保护. 但互联网公司基本上都是野蛮生长, 发展壮大以后才发现数据安全的问题. 但存量数据已经形成, 日以万计的数据表在增长, 这种情况下如何实现数据分类分级? 人工梳理显然不现实, 梳理的速度赶不上数据增长速度.
再例如安全厂商提供的数据审计解决方案, 也都是基于传统关系型数据库的硬件盒子. Hadoop 环境下的数据审计方案是什么? 面对海量数据, 很多厂商也买不起这么多硬件盒子啊.
因此, 互联网公司迫切需要一些符合自身特点的手段, 来进行数据安全保障. 为此, 美团点评信息安全中心进行了一些具体层面的探索. 这些探索映射到 IT 的层面, 主要包括应用系统和数据仓库, 接下来我们分别阐述.
一, 应用系统
应用系统分为两块, 一是对抗外部攻击, 是多数公司都有的安全意识, 但意识不等于能力, 这是一个负责任企业的基本功. 传统问题包括越权, 遍历, SQL 注入, 安全配置, 低版本漏洞等, 这一类在 OWASP 的 Top10 风险都有提到, 在实践中主要考虑 SDL, 安全运维, 红蓝对抗等手段, 且以产品化的形式来解决主要问题. 这里不做重点介绍.
1.1 扫号及爬虫
新的形势下, 还面临扫号, 爬虫问题. 扫号是指撞库或弱口令: 撞库是用已经泄漏的账号密码来试探, 成功后轻则窃取用户数据, 重则盗取用户资金; 弱口令则是简单密码问题. 对于这类问题, 业界不断的探索新方法, 包括设备指纹技术, 复杂验证码, 人机识别, IP 信誉度, 试图多管齐下来缓解, 但黑产也在不断升级对抗技术, 包括一键新机, 模拟器, IP 代理, 人类行为模仿, 因此这是个不断的对抗过程.
举个例子, 有公司在用户登录时, 判断加速等传感器的变化, 因为用户在手机屏幕点击时, 必然会带来角度, 重力的变化. 如果用户点击过程中这些传感器没有任何变化, 则有使用脚本的嫌疑. 再加上一个维度去判断用户近期电量变化, 就可以确认这是一台人类在用的手机, 还是黑产工作室的手机. 黑产在对抗中发现公司用了这一类的策略, 则很轻易的进行了化解, 一切数据都可以伪造出来, 在某宝上可以看到大量的此类技术工具在出售.
爬虫对抗则是另一个新问题, 之前有文章说, 某些公司的数据访问流量 75% 以上都是爬虫. 爬虫不带来任何业务价值, 而且还要为此付出大量资源, 同时还面临数据泄漏的问题.
在互联网金融兴起后, 爬虫又产生了新的变化, 从原来的未授权爬取数据, 变成了用户授权爬取数据. 举例来说, 小张缺钱, 在互联网金融公司网站申请小额贷款, 而互联网金融公司并不知道小张能不能贷, 还款能力如何, 因此要求小张提供在购物网站, 邮箱或其他应用的账号密码, 爬取小张的日常消费数据, 作为信用评分参考. 小张为了获取贷款, 提供了账号密码, 则构成了授权爬取. 这和以往的未授权爬取产生了很大的变化, 互联网金融公司可以进来获取更多敏感信息, 不但加重了资源负担, 还存在用户密码泄漏的可能.
image
对爬虫的对抗, 也是一个综合课题, 不存在一个技术解决所有问题的方案. 解决思路上除了之前的设备指纹, IP 信誉等手段之外, 还包括了各种机器学习的算法模型, 以区分出正常行为和异常行为, 也可以从关联模型等方向入手. 但这也是个对抗过程, 黑产也在逐渐摸索试探, 从而模拟出人类行为. 未来会形成机器与机器的对抗, 而决定输赢的, 则是成本.
1.2 水印
近年来业界也出现了一些将内部敏感文件, 截图外发的事件. 有些事件引起了媒体的炒作, 对公司造成了舆论影响, 这就需要能够对这种外发行为进行溯源. 而水印在技术上要解决的抗鲁棒性问题, 针对图片的水印技术包括空间滤波, 傅立叶变换, 几何变形等, 简单的说是将信息经过变换, 在恶劣条件下还原的技术.
1.3 数据蜜罐
是指制作一个假的数据集合, 来捕获访问者, 从而发现攻击行为. 国外已经有公司做出了对应的产品, 其实现可以粗暴地理解为, 在一个数据文件上加入了一个 "木马", 所有的访问者再打开后, 会把对应记录发回服务器. 通过这个 "木马", 可以追踪到攻击者细节信息. 我们也曾做过类似的事情, 遗憾的是, 这个数据文件放在那里很久, 都无人访问. 无人访问和我我们对蜜罐的定位有关, 现阶段我们更愿意把它作为一个实验性的小玩意, 而不是大规模采用, 因为 "木马" 本身, 可能带有一定的风险.
1.4 大数据行为审计
大数据的出现, 为关联审计提供了更多的可能性, 可以通过各种数据关联起来分析异常行为. 这方面, 传统安全审计厂商做了一些尝试, 但从客观的角度来看, 还比较基础, 无法应对大型互联网公司复杂情况下的行为审计, 当然这不能苛求传统安全审计厂商, 这与生意有关, 生意是要追求利润的. 这种情况下, 互联网公司就要自己做更多的事情.
例如防范内鬼, 可以通过多种数据关联分析, 通过 "与坏人共用过一个设备" 规则, 来发现内鬼. 举一反三, 则可以通过信息流, 物流, 资金流等几个大的方向衍生出更多符合自身数据特点的抓内鬼规则.
除此之外, 还可以通过 UEBA(用户与实体行为分析) 来发现异常, 这需要在各个环节去埋点采集数据, 后端则需要对应的规则引擎系统, 数据平台, 算法平台来支撑.
例如常见的聚类算法: 某些人与大多数人行为不一致, 则这些人可能有异常. 具体场景可以是: 正常用户行为首先是打开页面, 选择产品, 然后才是登录, 下单. 而异常行为可以是: 先登录, 然后修改密码, 最后下单选了一个新开的店, 使用了一个大额优惠券. 这里每一个数据字段, 都可以衍生出各种变量, 通过这些变量, 最后可以有一个异常判断.
再例如关联模型, 一个坏人团伙, 通常是有联系的. 这些维度可以包括 IP, 设备, WiFi MAC 地址, GPS 位置, 物流地址, 资金流等若干维度, 再结合自己的其他数据, 可以关联出一个团伙. 而团伙中如果有一个人标记为黑, 则关系圈则会根据关系强弱进行信誉打分降级.
image
UEBA 的基础是有足够的数据支撑, 数据可以是外部的数据供应商. 例如腾讯, 阿里都提供一些对外数据服务, 包括对 IP 信誉的判断等, 使用这些数据, 可以起到联防联控的效果. 也可以是内部的, 互联网公司总会有若干条业务线服务一个客户, 这就要看安全人员的数据敏感度了, 哪些数据能为自己所用.
1.5 数据脱敏
在应用系统中, 总会有很多用户敏感数据. 应用系统分为对内和对外, 对外的系统脱敏, 主要是防止撞号和爬虫. 对内的系统脱敏, 主要是防止内部人员泄漏信息.
对外系统的脱敏保护, 可以分层来对待. 默认情况下, 对于银行卡号, 身份证, 手机号, 地址等关键信息, 强制脱敏, 以 ** 替换关键位置, 这样即使被撞库或者爬虫, 也获取不到相关信息, 从而保护用户数据安全. 但总有客户需要看到自己或修改自己的完整信息, 这时就需要分层保护, 主要是根据常用设备来判断, 如果是常用设备, 则可以无障碍的点击后显示. 如果非常用设备, 则推送一个强验证.
在日常业务中, 美团点评还有一个特点. 外卖骑手与买家的联系, 骑手可能找不到具体位置, 需要和买家进行沟通, 这时至少包括了地址, 手机号两条信息暴露. 而对于买家信息的保护, 我们也进行了摸索试探. 手机号码信息, 我们通过一个 "小号" 的机制来解决, 骑手得到的是一个临时中转号码, 用这个号码与买家联系, 而真实号码则是不可见的. 地址信息, 我们在系统中使用了图片显示, 在订单完成之后, 地址信息则不可见.
对内系统的脱敏保护, 实践中可以分为几个步骤走. 首先是检测内部系统中的敏感信息, 这里可以选择从 Log 中获取, 或者从 JS 前端获取, 两个方案各有优劣. 从 Log 中获取, 要看公司整体上对日志的规范, 不然每个系统一种日志, 对接周期长工作量大. 从前端 JS 获取, 方案比较轻量化, 但要考虑性能对业务的影响.
检测的目的是持续发现敏感信息变化, 因为在内部复杂环境中, 系统会不断的改造升级, 如果缺少持续监控的手段, 会变成运动式工程, 无法保证持续性.
检测之后要做的事情, 则是进行脱敏处理. 脱敏过程需要与业务方沟通明确好, 哪些字段必须强制完全脱敏, 哪些是半脱敏. 应用系统权限建设比较规范的情况下, 可以考虑基于角色进行脱敏, 例如风控案件人员, 是一定需要用户的银行卡完整信息的, 这时候可以根据角色赋予免疫权限. 但客服人员则不需要查看完整信息, 则进行强制脱敏. 在免疫和脱敏之间, 还有一层叫做半脱敏, 是指在需要的时候, 可以点击查看完整号码, 点击动作则会被记录.
就脱敏整体而言, 应该有一个全局视图. 每天有多少用户敏感信息被访问到, 有多少信息脱敏, 未脱敏的原因是什么. 这样可以整体追踪变化, 目标是不断降低敏感信息访问率, 当视图出现异常波动, 则代表业务产生了变化, 需要追踪事件原因.
二, 数据仓库
数据仓库是公司数据的核心, 这里出了问题则面临巨大风险. 而数据仓库的治理, 是一个长期渐进的建设过程, 其中安全环节只是其中一小部分, 更多的则是数据治理层面. 本文主要谈及安全环节中的一些工具性建设, 包括数据脱敏, 隐私保护, 大数据行为审计, 资产地图, 数据扫描器.
2.1 数据脱敏
数据仓库的脱敏是指对敏感数据进行变形, 从而起到保护敏感数据的目的, 主要用于数据分析人员和开发人员对未知数据进行探索. 脱敏在实践过程中有若干种形式, 包括对数据的混淆, 替换, 在不改变数据本身表述的情况下进行数据使用. 但数据混淆也好, 替换也好, 实际上都是有成本的, 在大型互联网公司的海量数据情况下, 这种数据混淆替换代价非常高昂, 实践中常用的方式, 则是较为简单的部分遮盖, 例如对手机号的遮盖, 139**0011 来展示, 这种方法规则简单, 能起到一定程度上的保护效果.
但有些场景下, 简单的遮盖是不能满足业务要求的, 这时就需要考虑其他手段, 例如针对信用卡号码的的 Tokenization, 针对范围数据的分段, 针对病例的多样性, 甚至针对图片的 base64 遮盖. 因此需要根据不同场景提供不同服务, 是成本, 效率和使用的考量结果, 数据遮盖要考虑原始表和脱敏后的表. 原始数据一定要有一份, 在这个基础上是另外复制出一张脱敏表还是在原始数据上做视觉脱敏, 是两种不同成本的方案. 另外复制一张表脱敏, 是比较彻底的方式, 但等于每张敏感数据表都要复制出来一份, 对存储是个成本问题. 而视觉脱敏, 则是通过规则, 动态的对数据展现进行脱敏, 可以较低成本的实现脱敏效果, 但存在被绕过的可能性.
2.2 隐私保护
隐私保护上学术界也提出了一些方法, 包括 K 匿名, 边匿名, 差分隐私等方法, 其目的是解决数据聚合情况下的隐私保护. 例如有的公司, 拿出来一部分去除敏感信息后的数据公开, 进行算法比赛. 这个时候就要考虑不同的数据聚合后, 可以关联出某个人的个人标志. 目前看到业界在生产上应用的是 Google 的 DLP API, 但其使用也较为复杂, 针对场景比较单一. 隐私保护的方法, 关键是要能够进行大规模工程化, 在大数据时代的背景下, 这些还都是新课题, 目前并不存在一个完整的方法来解决隐私保护所有对抗问题.
2.3 大数据资产地图
是指对大数据平台的数据资产进行分析, 数据可视化展现的平台. 最常见的诉求是, A 部门申请 B 部门的数据, B 作为数据的 Owner, 当然想知道数据给到 A 以后, 他是怎么用的, 有没有再传给其他人使用. 这时候则需要有一个资产地图, 能够跟踪数据资产的流向, 使用情况. 换个角度, 对于安全部门来说, 需要知道当前数据平台上有哪些高敏感数据资产, 资产的使用情况, 以及平台上哪些人拥有什么权限. 因此, 通过元数据, 血缘关系, 操作日志, 形成了一个可视化的资产地图. 形成地图并不够, 延伸下来, 还需要能够及时预警, 回收权限等干预措施.
2.4 数据库扫描器
是指对大数据平台的数据扫描, 其意义在于发现大数据平台上的敏感数据, 从而进行对应的保护机制. 一个大型互联网公司的数据表, 每天可能直接产生多达几万张, 通过这些表衍生出来更多的表. 按照传统数据安全的定义, 数据安全第一步是要分类分级, 但这一步就很难进行下去. 在海量存量表的情况下, 该怎样进行分类分级? 人工梳理显然是不现实的, 梳理的速度还赶不上新增的速度. 这时候就需要一些自动化的工具来对数据进行打标定级. 因此, 数据库扫描器可以通过正则表达式, 发现一些基础的高敏感数据, 例如手机号, 银行卡等这些规整字段. 对于非规整字段, 则需要通过机器学习 + 人工标签的方法来确认.
综上, 数据安全在业务发展到一定程度后, 其重要性越发突出. 微观层面的工具建设是一个支撑, 在尽量减少对业务的打扰同时提高效率. 宏观层面, 除了自身体系内的数据安全, 合作方, 投资后的公司, 物流, 骑手, 商家, 外包等各类组织的数据安全情况, 也会影响到自身安全, 可谓 "唇亡齿寒". 而在当前各类组织安全水平参差不齐的情况下, 就要求已经发展起来的互联网公司承担更多的责任, 帮助合作方提高安全水平, 联防共建.
来源: http://zhuanlan.51cto.com/art/201805/574244.htm