您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
浅析金融大数据安全
 
作者:mcvoodoo 来源:freebuf 发布于:2016-9-2
486 次浏览     评价:      

随着大数据的发展,从银行到P2P再到保险、证券等,越来越多的金融企业开始建设自己的大数据平台。传统上对于数据的管理,金融界是有经验的。但在当前以Hadoop为基础的大数据平台,接触数据的人更多,数据使用的更频繁,数据的内外交互实时,数据种类更复杂,对安全带来了更严峻的挑战。

从金融业态上来说,包括征信、消费金融、P2P、众筹、互联网银行、互联网保险等金融企业,都会需要大数据平台来支撑业务需要。金融大数据的安全有三个很重要的工作内容,分别是安全管理及监管合规、数据安全、业务安全。具体到实际的安全映射上,分为以下四类。

一、安全管理

金融机构是属于被强监管的机构,很多业务都需要牌照才能开展。在安全领域保持监管层的汇报和日常沟通,是工作量不大,但需持续进行的工作。监管机构一般会有现场监管和非现场监管,注意及时、准确的填写内容,利用现场监管的机会,充分展示安全保障能力。金融监管由于行业特点,普遍比较保守,对于新技术的应用较为谨慎,例如人脸识别、二维码付款、大数据风控等新型技术,不建议在汇报沟通中过多渲染。这里点到为止不再多谈。

主管机构在监管层面,目前主要还是看安全制度、信息安全等级保护评测。等级保护测评无需多说。安全制度层面,由于不同金融业态对应不同的安全管理要求,需要结合专业条线的安全管理制度来开展。有些机构为了取得更多安全证书,会去拿一些国外的安全体系认证,这在监管层面不是很认可,我自己的建议是,除非有国外机构的业务,或者真正需要借证书来完善自己的安全管理体系,否则这个证书不用过于强调。

除监管之外,安全管理还有一个重要内容是传递安全的信任感。一个平台是否安全是投资者非常关心的一个角度,平台安全可以分为资金安全和信息安全,而信息安全则需要传递这种信心。如果一个平台被黑客攻击,或者羊毛党大量聚集,或者出现批量的受害者,这对平台的打击是致命的。在安全信心的传递上,一是用人民群众喜闻乐见的形式在平台上宣传,二是要处理好应急事件,尤其在公关层面。

二、生产安全

金融的安全运维和研发安全上,与其他类型机构相比,安全要求相对较高一些。但本质上并无较大差异,本文也不在这里介绍。主要探讨大数据平台安全。

一个简单大数据平台示意图如下:

整个大数据平台可分为三大块。

1、 数据源

一个大数据平台,必然面临这种形式的数据接入,数据有结构化的非结构化的、爬虫数据、上报数据、图片数据等各类格式。数据又有个人身份信息、支付、移动数据、法院信息等各种类。数据还根据来源有组织内和组织外。根据接入方式有互联网、专网等。这里需要考虑存网络边界风险。

在一个大型集团的大数据平台,每天都会有各种各样的数据接入需求。安全部门在这里要有统一、强制的介入方式,包括连接类型是API、FTP还是其他类型。包括数据流量预测。包括接入的鉴权方式和证书管理。包括使用期限和下线管理。建议是形成统一的数据接入平台进行管理,按照不同的数据保密性级别分类处理,约定统一的安全强度。这件事要早做,越晚做越痛苦,等到业务发展起来,无数的接口需要梳理的时候就积重难返了。

2、大数据平台安全

2.1基础设施安全

大数据平台首先要考虑自身基础设施安全。由于金融属性,大数据平台不太会考虑使用云的形式。另外,取决于搭建大数据平台的技术及数据库,还需要进行针对Hadoop、mogodb、nosql等的安全管理。需要指出的是,大数据设计的初衷并不是为了安全考虑,整个安全管理机制并不成熟,比如Hadoop早期版本缺少身份认证机制、节点之间的传输无法加密,后续的版本提供了此类的机制之后,升级又可能导致Hadoop不可用。NoSQL数据库则缺乏一些传统数据库提供的安全功能,比如基于角色的访问控制功能。

具体而言,应用层面的安全要考虑一些比较新的版本来搭建大数据平台,如果是已有平台,可以使用Cloudera Sentry、DataStax Enterpris、Accumulo这一类应用安全的加强。日志的统一监控可以使用Apache Oozie。由于大数据平台具有较多的集群服务器,物理位置可能分布式,所以需要在运维安全上考虑加固,使用统一的、最小化权限的版本进行自动化配置。

大数据平台的账户管理也是重要的一部分。密码强壮度的控制、离职休假员工的账户回收、登录失败限制,对账户的监控等等日常工作需要定期审计。但最核心的内容,是做好安全域管理,做好边界防控,把大数据平台在内部盒子里运转。

2.2敏感数据保护

大型金融集团里,大数据会包括来自各种内外部机构的数据。可能会包括保险、银行、证券、支付等多种机构,而这其中每个机构都面临着不同的行业监管要求,同时又需要有各种的机构访问。种种数据的行业要求,加上产品经理、开发等各业务单元的访问,每个数据表甚至字段的访问,都需要建立在个案分析的基础上进行安全控制。

因此首先要对数据进行分类分级管理,如下图。一般的分类分级可以参照传统安全做法,并无太大区别。但要注意由于大数据的来源非常丰富,不能仅靠人工去判定数据级别,需要有自动发现敏感数据的工具,市面上有一些通用工具可以用,但从长远来看,数据发现还需要有自己可定义的工具为佳。

对数据的分级,不仅要考虑到表,还要到字段级别的授权。除此之外还有数据融合的问题,基于业务的需要,例如在风控领域需要对用户画像,就需要综合多个类别级别的数据进行开发,多个数据融合的时候,对数据的控制要按照最高级来进行。

2.3数据脱敏

大数据平台最终是为业务服务的,在产品的生产过程中,多个团队都需要使用大数据平台进行分析、开发、测试工作。大数据平台中包含了大量敏感数据,如何能够既不影响业务开发,又能保障安全性,这就需要进行数据脱敏。

脱敏有几件事情要做,首先关键表关键字段的脱敏。这部分比较容易理解,例如用户的password,这就是无论何时都不能展示的。在有些行业,银行卡号、身份证等信息都需要脱敏。所谓脱敏是指隐去这些信息。

但是,脱敏不能简单的将关键信息用星号脱敏,如果一张表的name字段全是*,业务分析就无法进行了,这就需要有一个替换和映射。替换和映射的意思是:

真实的:张三,手机13900000000,身份证9999999999999

替换后:李四,手机13999999999,身份证1111111111111

而在系统内部则要建立两者之间的映射关系。这方面市场上也有产品提供,但对于大型机构来说,通用型产品远远不能满足需要,大型机构建议自行开发。

其次但某些业务的需要,例如风控案件调查,一定是需要欺诈分子的真实信息,脱敏后案件就无法跟踪下去了,这就需要有控制的对部分人员开放敏感数据,又要保证这些数据不会出去。这种控制方法,一般是建立一个分析集群虚拟机,办公网通过堡垒机跳转,在虚机上进行操作,虚机集群则无法与外界建立联系。当然也可以选择在办公终端上进行严格终端控制,但终端层面风险敞口较大,很难做到完全控制。

同时,分析结果在很多情况下,需要对外输出。例如夺宝活动获奖用户清单,需要LIST清单进行奖励寄送,这就需要在封闭的集群中有统一出口。出口需要经过业务主管、安全团队审批,并经过加密输出,确保即使该文件被泄露,别人也无法打开内容。

2.4 数据产品输出

大多数数据会加工成产品对内外输出。有用在内部经营数据分析的产品,有向外部组织提供的数据接口,有应用产品。所有类型的输出,都需要安全团队参与评审。而绝大多数情况下,都不需要输出明细数据,在理解对方业务需求的基础上进行标签化可以满足多数场景的需求。

例如,某基金业务的资金变化展示,这种只是汇总型的数据,可以在大数据平台计算完毕后输出。再比如资金对账数据,可以通过接口性质输出,禁止人工对账,通过在鉴权、加密上的控制来保证安全。

还有一种情况例如,客服团队需要了解CASE详情,而这些详情需要通过数据来了解。这就需要控制好信息的输出,例如CASE是由用户触发,而不是客服触发。对客户的敏感个人信息要进行界面脱敏,外呼电话可通过隐匿后的软电话按钮呼出。这需要对客服系统进行敏感信息保护的改造。

三、办公网安全

传统金融机构对办公终端的管理都比较完善,甚至双网双机。一些互联网公司在这方面反倒有所欠缺。我自己的看法,终端层面的监控和防护已经是最后一道防线,也是重要的信息泄露点,因此对终端电脑的安全管控必须向金融机构的强度对标,但手段上可以不同。这里涉及到DLP、终端杀毒防木马、BYOD、邮件、上网行为管理、准入、透明加密等多方面内容,不再一一解释。

四、业务安全

在业务安全上,根据不同的业务特点会有不同的风险。刷库和倒卖是征信业务特有的风险,而账户安全则是所有业务都关心的风险,信贷风控又属于信贷类风险。我想表达的是,安全一直以来受重视程度不足,究其原因相对业务来说是个成本中心,而如果安全切入业务安全领域,则对整个业务带来价值,甚至可能会成为利润中心,是提高安全队伍话语权的重要法宝。

防刷库。征信公司本身的业务特点是接入各方数据,加工成产品后对外输出,典型产品如信贷黑名单,其中汇集了逾期老赖用户。这就会有下游机构进行刷库,简单可以理解为使用所有公民的身份证号进行查询。对这种情况,需要有业务监控,根据机构大小进行分类,异常查询的,可根据人行相关要求,调阅用户授权。另外为防止意外,可进行阈值设定,超出阈值的自动BLOCK并报警。

防盗卖。下游机构在接入接口后,将数据对外转售以此牟利,并留存数据。对于这种盗卖在技术上很难防范。但可以通过下钩子的方法,放置一些特定数据。一旦这些数据在未授权机构出现,则意味有人盗卖,可以根据不同的钩子数据找到盗卖方。

 

   
487 次浏览  评价: 差  订阅 捐助
 
相关文章

iOS应用安全开发,你不知道的那些事术
Web安全之SQL注入攻击
移动APP安全在渗透测试中的应用
从Google备份互联网看“数据安全”
 
相关文档

web安全设计与防护
互联网海量内容安全处理技术
黑客攻击与防范技术
WEB黑盒安全检测
 
相关课程

WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
信息安全问题与防范
 

iOS应用安全开发
Web安全之SQL注入攻击
APP安全在渗透测试中的应用
初探PHP的SQL注入攻击的技术
从Google备份看“数据安全”
更多...   

WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
注册信息安全专业人员(CISP)
信息安全管理
信息安全问题与防范

相关咨询服务
应用架构设计与构建

中国银行 信息安全技术及深度防御
Web应用安全架构、入侵检测与防护
某财税领域知名IT服务商 Web安全测试
普瑞克斯 web安全设计、测试与优化
北京和利时 性能和安全性测试
SUN中国工程研究院 JSF框架、安全
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号