MongoDB 3.2加密技术测试

一、简介

MongoDB3.2为静态数据加密引入了新的选择，本文将对这些内容进行深入探讨：加密需求增长的动力、MongoDB的数据加密功能以及新加密存储引擎(Encrypted Storage Engine)的性能特点。

由于近年来攻击事件有所增加，一系列的数据泄露事件导致一些知名度较高的品牌受到了负面影响，如今数据安全已成为重中之重。比如在2015年，在大规模的数据泄露事件中，一家知名医疗保险公司就成为了受害者：罪犯盗取了8000多万人的社会安全号码，造成的损失大约有1亿美元。最后发现，一个很关键的漏洞就是由于医疗保险公司没有对静态存储在数据库的病人敏感资料进行加密所致。

在保护敏感数据的整体性策略中，数据加密是很关键的部分。然而，对数据的加密与解密可能相当耗费资源，想要正确执行产能规划，了解加密技术的性能特点非常重要。

二、MongoDB 3.2带来了本地静态加密功能

MongoDB 3.2为数据保护提供了综合性的加密方案，包括动态加密与静态加密方案。针对动态加密，MongoDB使用了SSL/TLS协议，确保数据库与客户端之间，还有集群中节点间数据传输的安全性。

在最新的3.2版本中，MongoDB还支持完全集成式的静态加密方案，从而减少了成本与性能开销。静态加密功能只在MongoDB Enterprise Advanced版本中才有提供，不过这一功能是向开发者与评估者免费开放的。在本文后面的部分，我们会深入探讨这个新选择。

3.2版之前，静态加密主要是通过第三方应用来提供：在应用、文件系统或硬盘中对文件进行加密。这些方式在MongoDB中表现良好，但会增加成本、复杂性和开销。

此外，硬盘和文件系统加密在有些情况下可能无法生效。尽管硬盘级加密能防止由于物理硬盘被窃取而造成的泄密，却无法阻止有访问权限的人所造成的泄密并覆盖文件系统。

与此类似，文件系统加密能够防止他人覆盖文件系统，但无法防止他人通过应用或数据层面获得越权存取。

数据库加密通过增加额外的安全层，缓解了这些问题。即使管理员有文件系统的访问权限，也需要在解密数据文件前进行数据库身份验证。

MongoDB的加密存储引擎支持OpenSSL库提供的多种加密算法。默认是AES-256加密CBC模式，可选GCM模式，或者与FIPS-140-2兼容的FIPS模式。

加密是在页面级别中执行的，以便达到性能最优化。无需每次变更都对全部文件或数据库进行加密/解密，只需对修改的页面执行加密/解密即可。

此外，加密存储引擎为加密密钥提供了安全可靠的管理机制。每个加密节点都包含有用来加密/解密数据文件的内部数据库密匙。数据库密匙被封装在外部主密匙之内，想要执行初始化就必须向节点提供这个密匙。MongoDB通过VirtualLock和mlock之类的操作系统保护机制，将页面锁定在物理内存中，确保密匙不会被交换到未加密的硬盘中。

三、评估性能

数据的加密与解密都需要资源，因此管理者会想要了解加密和解密对性能的影响，以便根据情况调整产能规划。

我们在对加密存储引擎执行了基准测试，结果显示：平均的吞吐开销为10%到20%。进一步分析基准测试数据，得出在执行只插入、只读取以及各50%的工作负载时的测试结果。

基准测试使用的Intel Xeon X5675 CPU是支持AES-NI指令集的，而我们在测试时让CPU执行高负荷(100%)运转。我们评估了四种不同的配置：“工作集与内存相匹配”、“工作集超过内存”、“加密”以及“解密”。“工作集”指的是系统主动使用的一些数据和索引。