数据质量与安全管理的解决方案及动向

2023-11-16 理论教育版权反馈

【摘要】：但是，这样的独立访问方法可能会表现出将所有焦点对准Hadoop的安全解决方案的缺乏。在组织中，移动信息的必要性和大数据的流入被黑客及其他网络罪犯制作成大规模的新目标。由于这种安全配置的困难，Hadoop用户在采纳最基本的安全功能方面也受到限制。到目前为止，开源社区没有解决这样的安全差距，而是关注创造像MapReduce 2.0这样的已改善的Hadoop技术。大数据环境中，追加安全功能的功能应当与数据一同扩张。

虽然开源框架Hadoop可以支持大容量数据的管理逻辑扩张，但企业组织仍面临着大数据分布及管理的课题。Hadoop的核心规格仍然由Apache社区进行开发，到现在为止，并没有应对企业关于足够强有力的安全、政策的适用及规定遵循的要求。虽然不知道Hadoop是否有难题，但是在计算机集群中使大规模数据的分散处理成为可能的方法，展现了企业计算技术的未来。

与Hadoop类似的NoSQL数据存储位置与大小无关，使某个组织收集、管理及进行巨大的数据组分析成为可能，但是这些技术初期设计时并没有考虑到全面的安全。提供现有的结构化数据库解决方案的数据安全厂家们（vendors）为了确保集群环境，不断修改现有的产品。但是，这样的独立访问方法可能会表现出将所有焦点对准Hadoop的安全解决方案的缺乏。因此，只有构建应对分散计算的独特体系结构的新访问方式，才能够使企业数据中心的安全要求事项和Hadoop集群环境相符合。应当观察Hadoop发布版本和数据安全厂家所采取的不同的开源Hadoop发布版本中存在的安全差距，并且应该考虑针对待保护企业的分布式计算环境的安全强化方法。

大数据来自传感器等各种来源，这些传感器用于收集气象信息、社交媒体网站留言、数码照片及录像、购买交易记录、手机GPS信号。得益于云计算和网络的社会化，海量字节（petabytes）的非标准格式数据每天在线生成，如果能够收集和分析这些字节，那么大部分信息会具有商务固有的价值。

例如，移动通信厂家在手机基站中收集数据，石油及燃气公司在炼油传感器和地震勘探中收集数据，电力公用事业在发电厂及配电系统中收集数据。企业收集关于信用卡代码、社保代码、使用模式和消费习惯的数据。

在组织中，移动信息的必要性和大数据的流入被黑客及其他网络罪犯制作成大规模的新目标。企业之前未曾使用的这种数据现在是非常有价值的信息，应当作为遵守个人信息保护法及规定的对象并加以保护。

如同UNIX和TCP/IP等各种开源技术，开发Hadoop时也没有考虑到安全。Hadoop是从旨在构筑开源网络搜索引擎的其他开源Apache项目中进化而来的。Hadoop是从使用内置安全的MapReduce设施和没有内置安全（built-in security）的分布式文件系统的Apache Lucene和Nutch项目的子项目中派生出来的。Hadoop是谷歌MapReduce框架的开源版本，保存的数据（公用URL）不是个人信息保护限制对象，所以，未被设计成安全软件。Hadoop结构和安全关系如图8-8所示。

开源Hadoop社区使用Kerberos的目前表现形式——防火墙和基本HDFS权限，从而支持几种安全功能。Kerberos不对所有可能的安全进行分配，而是执行整个集群，这不是Hadoop集群的必要事项。安装Kerberos和设置集群很难，AD（active directory）和轻量目录访问协议（LDAP）服务的整合更加困难。由于这种安全配置的困难，Hadoop用户在采纳最基本的安全功能方面也受到限制。

pagenumber_ebook=120,pagenumber_book=108

图8-8　Hadoop结构和安全关系

（出处：Blogs.Perficient.com）

企业组织数十年一直暴露于数据安全侵害相关的危险中，所以，正期待在IT中被采用的、安装在数据中心的新技术是能够满足所有安全要求事项的最小集合。企业希望在非大数据（non-big data）信息系统中使用的解决用户认证及访问控制、政策执行及管理、数据遮蔽及加密的解决方案等安全功能，在大数据中也能使用。HIPAA、 HITECH、 SOX、 PCI/DSS等众多团体，由于保持遵守规定（将其他安全及个人信息保护义务化的规定）的计策，需要这样的大数据安全对策。

到目前为止，开源社区没有解决这样的安全差距，而是关注创造像MapReduce 2.0这样的已改善的Hadoop技术。企业组织（尤其是应当遵守数据限制遵守义务的企业和企业组织）应当为此担忧。

Hadoop的分散计算体系结构特征使数据中心管理者和安全专家必须再次铭记以下事项并进行系统设计。

（1）分布式计算。数据在可以使用资源的任何地方都能被处理，并可进行大规模并行计算。这与整齐划一且容易保护的中央存储库不同，形成非常容易受到攻击的脆弱复杂环境。

（2）分段的数据。为了确保大数据集群内的数据重复和复原力，几个复制本移动相异的节点的流体。数据可以被分离成在几个服务器中共享的碎片，这些数据碎片使安全问题更加复杂。

（3）数据访问。基于角色的访问控制（role-based access control， RBAC）是大部分数据库安全框架的核心，但是，大部分大数据环境没有被细化，以便通过与角色相关的访问对用户进行处理。所以，在概要（schema）中提供访问控制。

（4）节点间通信。Hadoop及分布大多数无法安全地进行通信，通过TCP/IP使用RPC。

（5）实际上无安全性。大数据堆栈（stacks）几乎是毫无安全性地构建而成。即使排除服务标准权限赋予和YARN的网络代理功能，也没有保护数据存储位置、应用程序和核心Hadoop功能的设施。所有的大数据设置都以网络服务模型为基础构筑而成，在应对一般的网络威胁方面有少数设施或没有设施。(www.chuimin.cn)

大体积、速度、各种数据没有考虑到大数据，而压过了设计、构筑成的现有安全解决方案。Hadoop不是一种技术，它是Hive、HBase、Zookeeper、Oozie、job tracker等应用程序的整体生态系统（eco-system）。这样的应用程序需要各个硬化。大数据环境中，追加安全功能的功能应当与数据一同扩张。轻而易举编凑的现有IT安全技术不能扩张，所以无法持续。安全厂家将现有产品适用于他们能做的线中，用普通方法，适用数据和命令输入集群的控制点（网关/周长）。但是，他们在最有效的地方——集群内并不适用安全。

现有数据安全厂家认为Hadoop和分散集群的安全可以通过现有的边界安全解决方案——防火墙及入侵检测/屏蔽技术等解决。但是，无论怎样进步，依靠边界安全的现有访问方式都无法充分保护Hadoop集群和分散文件系统。

一部分防火墙虽然试图在实际AD资格证明中检测IP，但是，这在Hadoop环境中可能成为问题。为了确保正确的功能，需要特定的网络设计，作为特殊的网络构成，防火墙也只是按照不同的IP/端口限制访问，所以，无法得知Hadoop的文件系统或Hadoop本身。结果，数据管理者为了控制访问，需要将重要的数据分离到另外的服务器上。这种方法与Hadoop这样的分散文件系统根本不兼容。防火墙的问题是表现出脆弱的室内单一层，防火墙被破坏的话，集群等于对攻击敞开。防火墙对集群内不活动的数据或转换中的数据不进行任何保护。

为形成有效的防御线，必须最大限度地将控制器配置在靠近数据存储位置及数据本身的位置。数据安全如果是首要事项的话，应当确实保护集群免受攻击。

像Hadoop这样的大数据平台被广泛应用，与现有的关系型数据库的使用一起，易于进行数据扩张的基于NoSQL的所谓的大数据数据库开始被广泛普及，Cassandra和MongoDB是代表性的事例。除此之外，基于NoSQL的数据库虽然被用于不同目的，但是，由于自身安全功能的缺乏，不适合管理数据安全，但是，由于最近Cassandra和MongoDB使用的激增，下面来观察这两种NoSQL的安全层面。

1） Cassandra的安全问题

Cassandra不提供数据加密功能，所以，为了在Cassandra中保管敏感数据，在保存数据之前，存在先加密再保存的麻烦，此外，为了防御来自任意用户的数据访问，应当具备另外的访问控制。

尽管提供像SSL这样的加密通信功能，但是与大部分用户应用软件的通信中并未加密。所以，通过收集Cassandra和用户应用软件之间的通信，不仅能收集所有数据的流动，而且在Cassandra中认证的ID和密码以文本的形态被原封不动地暴露出来。对于大数据平台集群中存在的Cassandra节点间的通信，相互之间存在认证程序或加密功能。但是在所有节点之间，这种设置必须同步进行。最近，Cassandra提供与SQL类似的CQL（Cassandra Query Language），它可以用于JDBC API和界面。问题是CQL暴露于像SQL这样的Injection攻击中。Cassandra以针对所有客户应用软件的Thread结构运行，面对恶意用户的随机访问企图，Cassandra会最大限度地使用资源（为了生成该Thread的资源），这引起其他正常服务相连的资源配额不均衡，还会发生引起服务障碍的现象。除此之外，Cassandra通过IAuthentication或SimpleAuthneticator两种方式，提供认证方法，但仍有在数据包中将ID和密码原封不动地泄露的危险。通过称为IAuthority的机制，使用以列为单位的Read/Write权限的方法正被应用。Cassandra的安全功能如表8-1所示。

表8-1　Cassandra的安全功能

pagenumber_ebook=122,pagenumber_book=110

（出处：2011 IEEE Joint Conference）

2） MongoDB的安全问题

MongoDB和Cassandra一样，未对数据文件进行加密。所以，无法屏蔽任意用户访问数据的违法行为。因此对于敏感数据，在保存数据之前，应当加密后再保存，并应当在OS level中事前实现对用户的访问控制。用于内部通信的协议被用于各种应用软件或节点间的通信，甚至还会与HTTP这样的服务端口相联系。问题是通过它，MongoDB的状态确认或构成设置甚至会发生变更。由于不提供关于它的加密通信，所以处于非常危险的状态。因此，当激活MongoDB的HTTP服务器时，为对其进行安全保护，建议应用Apache的HTTPD的增强认证功能。对于MongoDB，常被用于激活各种内部指令，这些内部指令在内部应用基于对象的脚本语言，可知，它容易受到注入攻击。虽然在内部提供认证功能，但只有数据在非碎片状态的节点中才可能被认证，这也将MongoDB的安全强化置于非常艰难的状况中。MongoDB的安全功能如表8-2所示。

表8-2　MongoDB的安全功能

pagenumber_ebook=123,pagenumber_book=111

（出处：2011 IEEE Joint Conference）

数据质量与安全管理的解决方案及动向

相关推荐