NoSQL，泛指非关系型的数据库。随着近年数据规模的爆发式增长，数据库的发展也经历了快速演变。为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，NoSQL数据库应运而生。
从2009年登上历史舞台，NoSQL数据库只用了8年时间，已经在主流数据库中占据3个席位。相较传统的非关系型数据库，NoSQL凭借其读取数据的高效性、易扩展性等优势，在众多细分领域应用中取得主导地位。例如电商行业：其业务属于标准的多读少写、事物简单，数据关系不复杂，这部分业务应用NoSQL会事半功倍。
NoSQL数据库不像标准关系形数据库有明确的定义，权威的规范，每种不同NoSQL适合的细分领域也多有不同，NoSQL从大类可以分成四类：
键值数据库
文档数据库
列族数据库
图数据库
仍以电商为例，该行业某些业务中使用的是键值数据库和文档数据库，本文对NoSQL安全问题展开分析也将主要从这两大类数据库类型入手。
一、NoSQL安全问题综述
NoSQL数据库在设计之初，就是为大大提升用户使用效率，所以并未做安全考虑。因此，NoSQL数据库普遍存在大量安全问题。安全问题主要可以分为七大类，分别为：
身份认证
权限控制
审计
通讯加密
数据加密
NoSQL注入
自身安全漏洞
大约在2013年前后，一些开源项目被企业化，企业化后企业版在一定范围内解决了一部分NoSQL数据库的安全问题。但大部分解决方案是以牺牲性能为代价，并不具备优良的推广性。大部分用户使用最多的还是社区版，该版本存在诸多安全问题，列举如下：
1）身份认证安全问题
无密码的身份认证安全问题
由于NoSQL中默认没有用开启户身份认证机制，所以任何用户都可以伪装成合法用户来访问数据库，并对数据库中的数据进行各种操作。如2016年底至2017年初兴起的一股针对NoSQL数据库的勒索行动，就是利用无身份认证登陆上NoSQL数据库实施敲诈勒索，这只是此安全隐患最简单的利用方式。很多时候黑客会以NoSQL数据库为跳板入侵NoSQL数据库所在的服务器，甚至整个网络环境。目前，最直接的解决方法就是给NoSQL加用户名和密码。
有密码的身份认证安全问题
NoSQL出于性能考量，默认不设置用户名和密码。要解决身份认证安全问题，一般采取两种方法。一种是使用NoSQL数据库自身支持的简单身份验证。通过客户端获取用户名和密码，然后和数据库中对应的记录进行比对，吻合则批准登录。该方法在抗暴力破解和网络窃取上非常差，一旦用户数量过多会引起性能的严重下降，所以部分NoSQL数据库不支持多用户登录。
另一种解决方案是以Hbase为代表，引入成熟的身份认证机制Kerberos来完成身份认证工作。该方式较适合以计算为主业的NoSQL数据库，对于要求执行效率和以大量查询为主要的业务并不适合。随着用户数量增长，并发量不断提高，KCD（密钥奋发中心）很快会成为整个业务流程的瓶颈。
2）权限控制
NoSQL数据库不仅缺乏身份验证，更缺乏对每个数据库用户的权限控制。很多NoSQL数据库，把自己当作“应用数据库”去设计，完全不关心数据库用户之间的权限区别，导致任意用户都相当于ORACLE数据库的sys用户。这种权限的混乱可能导致应用侧、运维侧两个层面的三种安全风险：1、缺乏命令权限控制；2、缺乏集合访问权限控制；3、缺乏集合内部数据访问控制。
NoSQL中有两类权限，一类是调用脚本的权限；另一类是对数据库系统的权限。Redis在这部分做得较差，任意用户都可以调用这两类权限，导致数据库面临安全威胁。一些重视安全的NoSQL数据库具备一定的访问控制能力，但仍缺乏细粒度的访问控制能力。
3）通讯加密
NoSQL数据库不仅身份验证是明文传输，后面的请求和结果集同样也是明文传输。这会导致户隐私数据、系统敏感信息在传输过程被窃取。解决通讯加密一般会提供一个附加的SSL安全层，但ssl安全层会拖慢整个业务的执行速度。后文会给出相应解决方案。
4）审计
NoSQL数据库缺乏审计能力，部分NoSQL数据库可以通过配置添加日志监控来完成一部分审计功能。通过日志的记录来判断整个流程中是否存在问题。这种日志的记录缺乏特征的判断和自动提示的功能。后面我们会用NoSQL审计产品完善审计功能的缺失。
5）数据加密
NoSQL数据库缺乏对数据的存储保护，所有数据均是明文形式存储，超管可以不经过用户允许直接查看、修改用户在云端保存的文件，很容易造成数据泄露。因此，需要常态保持加密，只允许具有固定身份的用户拿到明文，这样既保护了数据安全又强化了数据库权限控制。
6）NoSQL注入
虽然NoSQL数据库不再支持sql语句，也就没有了sql注入的威胁，但存在另外一种威胁——NoSQL注入威胁。NoSQL注入和其他注入类攻击类似，能获得数据库中整个集合（表）的信息，甚至通过改变语义，获得其他集合（表）中的敏感信息。目前已发现的SQL注入有重言式、联合查询、JavaScript注入、背负式查询四种。
7）自身安全漏洞
除了上述由于设计理念和web导致的安全风险外，NoSQL数据库本身也存在一些安全漏洞。主要集中在三方面：1、泄露敏感数据；2、越权操作；3、录调用的函数存在缓冲区溢出漏洞，会导致服务宕机。解决方法有二：1、及时打补丁；通过漏洞防护技术进行防护。
二、NoSQL安全解决方案
NoSQL数据库的设计目标是追求极致的效率和简易扩展性，设计者假设NoSQL数据库在一个绝对安全的环境下运行。现实中并没有绝对安全的运行环境，因此不可避免的出现了很多安全问题。
安华金和基于在数据库安全领域的深厚积累和业务前瞻性眼光，密切关注大数据安全的体系搭建，从专业角度提出针对NoSQL数据库全方位的安全解决方案，该解决方案主要由三部分构成。
第一部分如上图黄线所示，采用NoSQL漏扫产品，对NoSQL数据库进行弱口令、CVE漏洞、未使用安全配置进行检测，并生成报告提醒管理人员对NoSQL数据库进行安全加固。通过配置可以解决一部分安全问题，但很多细节问题难以解决。
于是需要引入上文红线所示的一套NoSQL防火墙+加解密代理。作为整套实时防护技术的核心，NoSQL防火墙通过截获web端到数据的数据，对数据进行分析，获取登录信息后进行一系列身份验证。在确定访问用户后，经过判断权限来决定放行与否。此外，NoSQL防火墙还是应对暴力破解的好手。如果单位时间内同一用户错误登录10次，则会对该用户的登录进行限时禁止行为，防止数据库被暴力破解。基于NoSQL防火墙对NoSQL数据库的语法解析能力，提炼出特定特征可以有效阻止NoSQL注入和CVE漏洞攻击，防止低权限用户越权操作。尽管NoSQL防火墙可以解决身份认证、细粒度访问控制、暴力破解、NoSQL注入、CVE漏洞攻击等问题，但欠缺对明文数据的保护。作为必要补充，部署加解密代理可以有效应对这个问题。数据通过加解密代理存入数据库后成为密文形态。加解密代理和NoSQL防火墙联动，保证只有具备访问目标value值的用户拿到的返回值才是明文，其他用户即使获取数据也是密文形态。
第三条绿线则是通过部署NoSQL审计产品对数据库的行为、动态进行更深入细致的追查。在事后为客户追查问题，提供有力保障。
至此，安华金和所提供的完整的NoSQL数据库安全环境搭建完毕。这个环境从事前、事中和事后三个层面，以纵向包裹整个NoSQL数据库， 从而保障数据库的安全。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
