关于nosql的安全分析,NoSql

几种nosql的浅谈

1、性能

成都创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于成都网站设计、做网站、庄河网络推广、微信小程序开发、庄河网络营销、庄河企业策划、庄河品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；成都创新互联公司为所有大学生创业者提供庄河建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com

都比较高，性能对我们来说应该都不是瓶颈。

总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。

2、操作的便利性

memcache 数据结构单一。（key-value）

redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，

hash 等数据结构的存储。

mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。

3、内存空间的大小和数据量的大小

redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过

期时间（类似 memcache）

memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立

10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b

10.1.2.3:14000 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务

不要和别的服务在一起。

4、可用性（单点问题）

对于单点问题，

redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整

个快照,无增量复制，因性能和效率问题，

所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。

一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成

增量复制的方式（需要自己实现），一致性问题和性能的权衡

Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环

状的算法，解决单点故障引起的抖动问题。

mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。

5、可靠性（持久化）

对于数据持久化和数据恢复，

redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影

响

memcache 不支持，通常用在做缓存,提升性能；

MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性

6、数据一致性（事务支持）

Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行

mongoDB 不支持事务

7、数据分析

mongoDB 内置了数据分析的功能(mapreduce),其他不支持

8、应用场景

redis：数据量较小的更性能操作和运算上

memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写

少，对于数据量比较大，可以采用 sharding）

MongoDB:主要解决海量数据的访问效率问题。

表格比较：

memcache redis 类型 内存数据库 内存数据库

数据类型 在定义 value 时就要固定数据类型 不需要

有字符串，链表，集 合和有序集合

虚拟内存 不支持 支持

过期策略 支持 支持

分布式 magent master-slave，一主一从或一主多从

存储数据安全 不支持 使用 save 存储到 dump.rdb 中

灾难恢复 不支持 append only file(aof)用于数据恢复

性能

1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。当然，memcache 也可用于缓存其他东西，例如图片等等。

2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。

3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。

4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通

过例如 expire 设定，例如 expire name 10。

5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。都可

以一主一从。

6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。

7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。

Memecache 端口 11211

yum -y install memcached

yum -y install php-pecl-memcache

/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid

-d 启动一个守护进程

-p 端口

-m 分配的内存是 M

-c 最大运行并发数-P memcache 的 pid

//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间

//delete 5 是 timeout

简答大数据安全的特征?

大数据安全面临着许多挑战，需要通过研究关键技术、制定安全管理策略来应对这些挑战。当前，大数据的应用和发展面临着许多安全问题，具体来说有以下几个方面。（1）大数据成为网络攻击的显著目标在网络空间中，大数据是更容易被“发现”的大目标，承载着越来越多的关注度。一方面，大数据不仅意味着海量的数据，也意味着更复杂、更敏感的数据，这些数据会吸引更多的潜在攻击者，成为更具吸引力的目标；另一方面，数据的大量聚集，使黑客一次成功的攻击能够获得更多的数据，无形中降低了黑客的进攻成本，增加了“收益率”。（2）大数据加大隐私泄露风险从基础技术角度看，Hadoop对数据的聚合增加了数据泄露的风险。作为一个分布式系统架构，Hadoop可以用来应对PB甚至ZB级的海量数据存储；作为一个云化的平台，Hadoop自身存在云计算面临的安全风险，企业需要实施安全访问机制和数据保护机制。同样，大数据依托的基础技术——NoSQL（非关系型数据库）与当前广泛应用的SQL（关系型数据库）技术不同，没有经过长期改进和完善，在维护数据安全方面也未设置严格的访问控制和隐私管理机制。NoSQL技术还因大数据中数据来源和承载方式的多样性，使企业很难定位和保护其中的机密信息，这是NoSQL内在安全机制的不完善，即缺乏机密性和完整性。另外，NoSQL对来自不同系统、不同应用程序及不同活动的数据进行关联，也加大了隐私泄露的风险。此外，NoSQL还允许不断对数据记录添加属性，这也对数据库管理员的安全性预见能力提出了更高的要求。从核心价值角度看，大数据的技术关键在于数据分析和利用，但数据分析技术的发展，势必对用户隐私产生极大威胁。

NoSQL数据库是否意味着缺乏安全性？

NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。