随着大数据的发展，从银行到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并报警。
防盗卖。下游机构在接入接口后，将数据对外转售以此牟利，并留存数据。对于这种盗卖在技术上很难防范。但可以通过下钩子的方法，放置一些特定数据。一旦这些数据在未授权机构出现，则意味有人盗卖，可以根据不同的钩子数据找到盗卖方。
|
