39. 关于数据库加密的讨论

数据库加密是指将存储于数据库中的数据，尤其是敏感数据，以加密的方式进行存储。

39.1 为什么要做数据库加密

数据库是所有信息系统的核心，是信息系统中最核心的资产，数据的丢失、破坏或泄漏，很可能会给企业带来难以估量的损失。数据库的安全通常是指其中所存数据的安全，是网络安全、信息安全的重要组成部分。而对数据库中数据的加密保护，是数据库安全的重要内容。但是数据库加密具有相对较高的技术门槛。本章希望通过几个相关问题的分析，来对此进行概念层面的讨论。

数据类型分两种，一种是非结构化数据（如文档和图片），另一种是结构化数据（如数据库中的数据）。这两种形态的数据都非常重要，都需要进行加密保护。尤其结构化数据，通常所承载的是非常集中且极有价值的信息，因而对其进行加密保护尤为重要。面对敏感数据频繁泄漏的严峻现实，虽然加解密过程将损害数据库的使用效率，但对数据库进行加密仍是不得不为的必要防护措施。数据库加密能够显著提升数据库的安全性。加密后，数据以密文的方式存储，防止了数据直接暴露，同时增强对加密数据的访问控制，大大降低了数据被泄漏和恶意破坏的风险。

有人说，数据库加密是“数据安全技术皇冠上的一颗明珠”，以此表明其技术难度之大；也有人说，数据库加密是“数据安全防线的最后一公里”，道出了其所处的重要位置与底线责任。然而，数据库加密受自身技术复杂度高、实施部署难度大，且一旦出现异常状况对使用方业务影响烈度大等因素影响，使其更像是一个无法被真正采纳和应用的数据安全技术，只存在于合规、应检及相关法律法规的条文中。

• 网络安全法对数据库加密的要求：

【第二十一条】…采取数据分类、重要数据备份和加密等措施…

• 密评密改中对数据库加密的要求：

密码协议、密钥管理系统、密码应用子系统和密码安全防护机制不仅设计合理，而且在系统运行过程中能够发挥密码效用，保障信息的机密性、完整性、真实性、不可否认性…

• 等级保护中对数据库加密的要求：

保护数据在存储、传输、处理过程中不被泄漏、破坏和免受未授权的修改的信息安全类要求…

39.2 数据库加密的能与不能

39.3.1 能解决哪些问题

数据库加密能够通过有效的解决如下问题，来提升数据库的安全性：

1. 防止数据库文件被下载或者复制、以及直接分析数据文件导致的数据泄漏和破坏。由于敏感数据被加密，任何直接对数据库文件进行分析的攻击方式，都只能看到密文。
2. 防止DBA或高权限帐号密码泄露导致的数据泄漏和破坏。DBA或者高权限账号被攻击者获取后，虽然攻击者能够得到数据库中的全部数据，但是由于敏感数据是被加密的，所以仍然不能获得明文。或者攻击者试图修改授权用户的访问密码进行身份伪造攻击，但是加密系统额外的身份认证机制能够对这种伪造身份进行识别，致使攻击者仍然无法获取真实数据。
3. 部分的防止SQL注入方式拖库泄漏全库数据和数据破坏。SQL注入攻击者通过拖库获取全部数据库内容，但是只能获取到攻击时所使用的用户所对应的明文权限，对于该用户不具有权限的敏感数据，攻击者仍然不能访问。

4. 实现多因子身份认证和授权，弥补仅由口令验证方式安全性不足的缺陷。可以增加对应用系统、时间、IP地址、用户名等多种因子的身份认证和授权管理。

   39.3.2 不能解决什么问题

   虽然数据库透明加密能够显著的提升数据库的安全性，但是并不能解决所有的数据库安全问题：

5. 不能完全阻止SQL注入攻击。SQL注入攻击者如果使用应用系统访问数据库的授权用户对数据库发起攻击，则能够获得加密系统对该用户的相应授权，能够访问到该授权项下的敏感数据。

6. 不能完全阻止攻击者伪造身份对数据库的攻击。当攻击者通过社交工程，完全窃取并伪造了具有对敏感数据合法访问权限的用户的帐号、密码、以及应用系统、IP信息时，数据库加密将不能对其访问进行限制。

7. 不能完全阻止授权应用系统后门程序对数据库的违规访问。当应用系统被授权访问敏感数据，但是被开发者留有后门时，数据库加密系统并不能识别这种后门并加以阻止。

   39.3 理想的数据库加密方案

   对于数据库加密，通常我们认为理想的方案具有如下的特点

8. 透明性足够好。不影响 SQL 语句执行，不需要应用改造已上线系统。

9. 兼容性足够好。既能满足多节点，数据分区等特性，又满足该数据库常用的运维工具和手段。
10. 性能足够好。即使对密文字段进行统计分析，或批量模糊查询，也能保证其可用。
11. 安全性足够好。密钥独立，权控独立，算法独立（国密），均纳入刚需。

数据库透明加密是指对库内数据的加密和解密，对数据库的访问程序是完全无感知的。特别是应用系统，不需要做任何修改和编译，就能够直接应用到加密库上。

与透明加密相对应的，是在应用系统中对数据进行加密，然后再存储到数据库中。需要真实数据的时候，从数据库中读取密文，再解密出明文。

39.4 常见数据库加密方案

“xxx拖库”、“xxxx数据泄露”等等层出不穷的安全事件表明，要想根本上解决这种越过网络防护，绕开权控体系，直接复制文件块并异地还原解析的“内鬼”式攻击方式，必须采用存储层的加密技术，确保敏感信息一旦落盘，必须密文存储。随着数据库加密技术在国内市场的兴起，更多数据安全企业的涌入，市面上出现了几种具有代表性的数据库加密技术。

39.4.1 前置代理及加密网关

该方案的总体思路是在数据库之前增加一道安全代理服务，对数据库访问的用户都必须经过该安全代理服务，在此服务中实现如数据加解密、存取控制等安全策略。然后安全代理服务通过数据库的访问接口实现数据存储。安全代理服务存在于客户端应用与数据库存储引擎之间，负责完成数据的加解密工作，加密数据存储在安全代理服务中。

这个方案有如下的优缺点：

• 由于在安全增强代理中需要存储加密数据，因此要解决与数据库存储数据的一致性问题，这基本不可实现。
• 数据的联合检索问题：由于在数据库内外都存在数据，这些数据的联合检索将变得很困难；SQL语法的完全兼容也非常困难。
• 开发无法透明问题：数据库协议虽然存在标准，但事实上每个不同的数据库版本都会进行若干变更、扩展和增强，使用了这些特性的用户必须进行改造。同时在安全代理中对数据库通讯协议的模拟非常困难。
• 数据库的优化处理、事务处理、并发处理等特性都无法使用：查询分析、优化处理、事务处理、并发处理工作都需要在安全增强器中完成，无法使用数据库在并发处理和查询优化上的优势，系统的性能和稳定性更多地依赖于安全代理；
• 对于对存储过程、触发器、函数等存储程序的实现支持也非常困难。

另外此种方案需要在安全代理服务层提供非常复杂的数据库管理功能，如SQL命令解析，通讯服务，加密数据索引存储管理、事务管理等等，因此存在巨大的开发工作量及很高的技术复杂度，此外还有类似于存储过程、触发器等无法解决的技术问题。

39.4.2 在应用层做加密解密

这个方案的主要原理是在应用系统中对敏感数据做加密处理，然后再将加密数据存储到数据库中。在进行数据检索时，将密文数据取回到再进行解密，应用系统自行管理密钥体系。

这种方案最主要不足在于应用程序必须对数据进行加解密，增加应用服务器的负担，已有系统必须进行改造，不能透明实施。这种技术无法利用数据库的索引机制，加密后数据的检索性能大幅下降。更关键的，使用这个方案的时候无法执行针对内容的查询。

39.4.3 对数据库文件加解密

这个方案处理加密解密的对象是数据库系统的文件。这个方案不与数据库自身原理融合，只是对数据存储的载体从操作系统或文件系统层面进行加解密的技术手段。

这种技术通过在操作系统中植入具有一定入侵性的“钩子”进程，在数据存储文件被打开的时候进行解密动作，在数据落地的时候执行加密动作，具备基础加解密能力的同时，能够根据操作系统用户或者访问文件的进程ID进行基本的访问权限控制。

这个方案绕过了让其他方案头疼的问题。对数据库高端特性兼容、查询检索性能保障、统计分析效率等关键技术指标均有较好的适应情况。然而在这种机制下，存在的问题也会比较明显，包含以下几类:

• 操作系统或文件系统级加解密，对不同平台适应性较差，而且与内核绑定过重，一旦出现程序故障，会对操作系统造成较大影响，容易导致业务中断。
• 操作系统或文件级加解密的权控在系统层，因此无法单独完成对不同数据库账号的访问权限的设置，需要和其他产品与技术进行组合。
• 操作系统或文件级的加解密针对落地文件进行操作，加解密粒度比较粗糙，无法针对列级进行加密。

  39.4.4 视图及触发器的后置代理

  这个方案是使用“视图”+“触发器”+“扩展索引”+“外部调用”的方式实现数据加密，同时保证应用完全透明。核心思想是充分利用数据库自身提供的应用定制扩展能力，分别使用其触发器扩展能力、索引扩展能力、自定义函数扩展能力以及视图等技术来满足数据存储加密，加密后数据检索，对应用无缝透明等核心需求。

以传统的列加密为代表的后置代理加密技术，经过几年演进逐步被大家接受，这种技术拥有前置代理和应用改造所不具备的透明性，灵活性以及数据库高端技术的兼容性，可谓率先走过了数据库加密这一风险与挑战都巨大的“独木桥”。然而向前看，“独木桥”还在。

“应用环境下，单表亿级数据规模，加密后查询检索性能会不会受到明显影响？”“对密文数据的统计分析操作，如何保证速度基本不下降？”“实施加密后，对密文数据的运维、迁移、备份等操作，如何将改动降至最低”“大量的数据加密，会否带来更大量的空间膨胀”……这些自数据库加密技术问世以来就相伴而生的问题，不仅变成了用户心头的疑云，也成为了后置代理加密技术提供商亟待解决的当务之急。

39.4.5 数据库表和表空间加密

自 My SQL 5.7.11 和 MariaDB 10.1.3 起，他们加入了支持表加密和表空间加密的特性，能够避免数据文件、binlog等文件被窃取后破解出关键数据。

MariaDB 有如下的加密特性

• innodb表空间加密
• innodb日志加密
• binlog加密
• aria表加密
• 临时文件加密

MariaDB的加密特性有一些限制

• 元数据文件(.frm)目前尚未加密
• 目前只有MariaDB server才能解密，mysqlbinlog工具还不支持解析加密后的binlog文件
• xtrabackup工具目前无法备份/恢复使用了加密特性的MariaDB实例
• 慢查询日志和错误日志尚未加密，里面可能会包含原始数据

开启加密后，主从结构的主机和备机之间的binlog传输是不加密的，由备机在写relaylog/binlog/数据文件时进行加密。所以主备之间的密钥可以不同，但ID信息必须一致，否则建表语句在备机上无法执行成功，将会导致slave SQL线程中止。

数据加密和数据压缩可以同时使用，MariaDB先做数据压缩再做数据加密，可以节约很大的存储空间。

这种加密方案能防止磁盘丢失和文件被复制导致的敏感数据泄漏。但是，对于控制了数据库系统的攻击者来说却是开放的，并没有防护能力。而且其密钥管理通常不会对数据库用户开放，安全性得不到保证，也得不到国内相关评测机构的认可。

39.4.6 小结

显然，数据被加密的位置离用户越近，安全性越高，同时实现的难度也越大

39.5 关于加密算法面临的监管

在数据库加解密技术体系里，另一个需要给予足够关注的议题是“算法的选择”。而从合规角度来看，也只有符合国密规范的算法，才有可能被最终使用。通常有如下的建议：

1. 选择符合国密规范的算法，尤其是SM4这种对称算法用于数据库加解密。对于SM2这种非对称算法（性能相对较低）或SM3这种哈希算法（不可逆），通常用于密钥管理或身份认证，不能用于对数据本身的加解密；

2. 当面对较强的合规监管或密评密改时，不要选择AES、DES这种商业算法，因为在合规性上无法提供保障；

3. FPE、SSE等保格式加密算法通常无法满足合规需求，并且对被加密的数据本身限制较多，还可能会为了保留格式而大幅度牺牲算法强度；

4. 加解密算法的密钥管理要相对独立并遵循国密规范，对密钥的生成、使用、销毁等应由加解密系统实现，而不是由数据库本身进行管理。

   39.6 国内数据库加密市场状况

   因为只能为政务类系统选择“国产”涉及密码（加密解密）的产品，因此我们重点关注国内的市场状况。

国内数据库加密产品的发展可以分为三个阶段：

• 第一个阶段是摸索阶段。在2003年之前，国内的数据库加密手段是通过反编译国外安全数据库系统完成的。国外安全版本的数据库系统具有加密功能，有国内技术人员对其进行逆向工程，加入国产加密算法，即完成了“国产化”。该加密手段在国内某些敏感部门曾进行了小范围的应用，达到了一定的效果。但随着数据库安全技术的进一步发展，目前已退出市场。

• 第二阶段是国外产品导入国内市场以及国产数据库加密产品萌芽阶段。从2003年开始，几家国外的数据库加密产品厂商，为了进入中国市场，将产品界面进行“中国化”，经由香港进入国内市场。但由于国家保密政策的限制，这些被伪装成国产的数据库加密产品并没有在国内数据库安全市场大行其道，逐渐销声匿迹。但在这一阶段，逐渐有国内科研人员开始进行数据库加密技术的研究。2009年已有数据库加密技术的专利发明出现。虽说与国外顶级技术有不小差距，但毕竟是迈出了非常重要的第一步。

• 第三个阶段是国产数据库加密技术逐步产品化并走向市场的阶段。从2010年开始，随着科研成果的产业化，国内市场开始出现纯国产的数据库加密产品。经过市场的磨练，产品越来越成熟，越来越为数据库安全运维人员所接受。不难预见，假以时日，数据库加密产品将成为数据库安全市场的重要力量，甚至能取代数据库审计产品和数据库防火墙产品的市场地位，成为数据库安全市场的宠儿。

目前国内数据库安全市场主流的数据库加密方式是库内扩展加密（即后置代理），通过使用视图、触发器、扩展索引等机制，实现透明加密。由于引入了独立于数据库的第三方程序，通过控制加密解密的权限，增加了额外的访问控制。对于数据库内不同的用户，也可以控制其对加密数据的访问。但是这种加密方式不能越过应用系统，实现应用系统用户对敏感数据的访问控制。而且这种加密方式依赖于数据库系统的扩展索引机制，并不能在所有数据库上实现。

39.7 在应用层加解密的简单方法

如果项目在短期内无法购置专门的数据库加密产品，但又要尽快解决数据库加密“有没有”的问题。可以考虑针对特定的数据进行字段级别的应用层加密。具体的思路是定义实现 javax.persistence.AttributeConverter 接口的方法，然后把它作为自定义的注解标注在数据库实体类的属性定义上。

下面是该接口的定义

package javax.persistence;
public interface AttributeConverter<X, Y> {
    Y convertToDatabaseColumn(X attribute)
    X convertToEntityAttribute(Y attribute);
}

在具体实现加密解密的过程中，应该使用 SM4 对称密码算法。

版权说明：本文由北京朗思云网科技股份有限公司原创，向互联网开放全部内容但保留所有权力。