本文来自微信公众号ITPUB，作者/韩锋频道。
随着云计算、大数据的快速发展，政府越来越意识到网络、数据安全的重要性。相应的法律法规不断完善，这其中包括《网络安全法》、《网络安全等级保护》、《重要数据出境安全评估指南》、《个人信息安全规范、大数据安全标准白皮书》、《大数据服务安全能力要求》等等。作为数据安全的重要组成部分，数据存储安全是安全的基础之一。本文，将描述数据存储加密的主流方案并进行对比，同时针对痛点难点问题进行说明。
1.数据存储加密的场景方案
要对数据进行有效的存储安全管理，可遵循如下步骤：
步骤1：分析并确定要保护的关键数据
要对数据进行保护之前，首先要确定哪些数据需要保护和为什么要保护这些数据。这其本质是一个数据分级的问题。数据分级从概念上讲是根据数据的敏感程度和数据遭到篡改、破坏、泄露或非法利用后对受害者的影响程度，按照一定的原则和方法进行定义。另一方面也需要关注的就是法规遵从性需求。例如《数据安全法》第二十一条就规定，”国家建立数据分类分级保护制度，根据数据在经济社会发展中的重要程度，以及一旦遭到篡改、破坏、泄露或者非法获取、非法利用，对国家安全、公共利益或者个人、组织合法权益造成的危害程度，对数据实行分类分级保护”。下图就是就是按数据敏感程度做的一个划分示例
步骤2：选择适合技术方案和加密算法
作为数据防护是否能够成功实施的关键，企业需要在关键数据的安全性、保持应用系统的功能可用性，和系统可维护性方面综合考虑，来确定适合企业需要的加密保护的技术方案。下表罗列常用加密技术及应对的安全风险。
●磁盘加密
磁盘采用的块级别加密技术，例如AWS的EBS，阿里云的ECS等都支持磁盘加密。这种加密最大的好处在于，它对操作系统是透明的。性能在加密后较加密前有所降低，根据上层应用的不同性能下降幅度各异。
●文件加密
通过堆叠在其它文件系统之上（如Ext2,Ext3,ReiserFS,JFS等），为应用程序提供透明、动态、高效和安全的加密功能。典型的是用于加密指定的目录。需要关注的是这种加密方式可能会产生较大的性能损失。
●数据库加密-TDE
透明数据加密TDE，是数据库提供的一种加密技术，即对数据文件执行实时I/O加密和解密。数据在写入磁盘之前进行加密，从磁盘读入内存时进行解密。TDE不会增加数据文件的大小，开发人员无需更改任何应用程序。其对应密钥管理也是由数据库提供的API或组件实现，应用透明。在某些场景下磁盘或系统无法对用户开放（如云环境）的条件下，这种方式就比较适合。
●数据库加密-三方加固
数据库加密还有种方式是采用对数据库进行三方加固的方式，即将第三方专业数据库加密厂商的产品内置在数据库之中，提供透明数据加密能力。所谓透明是指，用户应用系统不需要做改造即可使用，且具有权限的用户看到的是明文数据，完全无感。此外，还可以增强原有数据库的安全能力，如提供三权分立、脱敏展示等。
●应用层加密
应用层加密，可以说是一种终极方案，其可保证在数据到达数据库之前，就已经做了数据加密，可实时保护用户敏感数据。这里关键需要提供应用透明性，保证应用无需改造或仅需少量改造。这种方式完全由用户自己控制，无需信任任何三方厂商提供的数据安全保障，得到充分的自由度和灵活性。例如可以跨多数据库提供统一安全加密策略等。
步骤3：保护好数据的加密密钥
为了保护好加密数据，不会被非法窃取，需要保护好数据的加密密钥。避免第三方厂商或个人接触到明文数据，最好做法就是将密文数据的密钥控制在用户自己手中。密钥管理包含了密钥的创建、存储、生命期管理、保护。密钥的安全性直接决定了加密数据的安全性。建议密钥独立存储，并采用根密钥保护，根密钥受硬件加密卡保护，或者被KMS服务的密码保护。所谓KMS密钥管理，是通过用户的口令保护主密钥，口令正确主密钥解密；主密钥对密钥文件进行保护，只有主密钥成功解密后，密钥文件才能使用，最后通过密钥文件生成可用的密钥。
步骤4：实施必要的防数据泄漏措施
步骤5：监控并审计数据的访问行为
一方面，黑客攻击行为千变万化，另一方面，系统的复杂性带来的数据正常维护和管理行为往往也是不可预期的。因此，需要对重要数据的访问行为采取持续、及时的监控和审计，形成有效的风险报告提供给用户发现新的风险，帮助用户更好地进行数据保护。
步骤6：利用自动脱敏防止测试环境数据泄漏
除了生产环境的数据防护外，企业内部测试环境也是一个重要信息泄漏源，特别是需要“抽取”源端生产数据用于测试系统时；利用数据自动脱敏技术可以在有效地保护生产数据的同时，为测试环境提供可用的符合用户预期的测试数据。
2.数据存储加密的若干难点
应用透明问题
在数据存储安全的同时，如何提供如未加密前的使用体验非常重要。这里可总结为对应用的透明性。使用者或应用系统不需要关心系统进行了哪些保护，可完全无感地使用数据。这样的透明性主要体现在以下方面：
SQL语句透明：如常规的SELECT、UPDATE、INSERT、DELETE等语句可进行操作，应用程序不用作修改即可拥有安全特性。
库内计算透明：对于应用透明支持的含义还包括库内的计算（如存储过程和函数透明的支持等）。
开发接口透明：提供对应用开发接口的全面透明支持，包括：JDBC、ODBC等。
生态工具透明：数据库自身及周边生态工具仍然可以正常使用。
厂商绑定问题
如上面提到的几种加密方式中，存储层加密、文件层加密会存在完全依赖于底层基础设施厂商（或云厂商）的问题，数据库加密也要部分依赖于数据库厂商或三方安全厂商；上述几种方式都会存在厂商绑定风险。对比而言，应用层加密相对灵活度最大，可完全从用户角度考虑加密问题，但这一方式必然存在较大投入，如何能做到应用无感是比较头疼的问题。目前主流有通过数据中间层的方式解决，即在应用与数据库之间构建访问层，将数据加密、解密、脱敏等功能实现其中。对上面的应用提供标准化、透明的数据访问接口，对下数据库提供标准规范的安全策略，可不绑定具体产品。
接入方式问题
如前面谈到的应用层加密，也许是个不错的选择。对应用来讲，最好的透明使用方式是提供出标准的数据库接口服务。当前主流是采用Proxy模式，可以让应用完全无感地使用。但想做到无感，是需要从数据库协议层面仿真模拟，但受限于商业数据库协议的封闭，是存在一定局限的。虽然可以通过如JDBC/Client的方式去做，但这种方式一是无法完全无感，二是会存在更新客户端困难等问题。
性能效率问题
数据存储安全所涉及的数据加密、解密、脱敏等，势必会影响到应用使用效率。虽然很多产品都号称效率很高，但这个性能瓶颈是客观存在的。这里首先需要的是正视效率问题，能客观评估效率差异；此外如何能通过某些方式去扩展计算能力，部分解决效率低下问题也是一种思路。相对而言，采用存储层、文件层方式，可在一定程度上解决此问题。
清洗迁移问题
针对数据加密，存在一个存量的问题。如果是新建项目，完全可以采用全新的数据安全策略，但对于已有项目且存在数据，是需要解决数据清洗及迁移问题。针对前者，难点在于如何实现动态清洗，在系统在线的同时，应用可同步处理新旧数据，逐步完成清洗动作。清洗后的解决还需解决数据校验等，确保清洗是准确的。针对后者，在清洗完毕后，需要做应用层面迁移，完全切换回去；这里需解决平滑过度问题及可能出现的回退问题。针对上述难点，应用层方案，无疑是比较好可以解决此问题的。
安全计算问题
数据最终是要参与到计算中的，不能因安全需求而影响到计算。对于数据安全计算，取决于其所处的位置在何处。对于存储层、文件层，其位于数据库之下，作为数据计算主体的数据库是可不感知的，但对于数据库层和应用层是要解决这一问题。数据经过加密后，会失去其数据特征，这会影响到优化器、执行器的工作。应用层加密也是同样的。目前存在一些密态计算技术，能在一定程度上解决这一问题。
国密算法问题
国密算法，即国家商用密码算法。是由国家密码管理局认定和公布的密码算法标准及其应用规范，其中部分密码算法已经成为国际标准。如SM系列密码，SM代表商密，即商业密码，是指用于商业的、不涉及国家秘密的密码技术。之前很多的安全产品（特别是国外产品）是不支持国密算法的，这点是企业在做安全策略时需考虑的问题，特别是重监管的企业。
统一管控问题
数据散落在企业各处，提供统一、全局、细粒度的安全管控，包括复杂条件授权等是很有意义的。对于企业可采用统一的数据视角解决安全问题。目前通常的做法是基于不同数据库自己来实现各自安全策略，对客户不甚友好，如能统⼀处理，非常具有商业意义。针对这点，是需要站在单一产品之上，从数据使用生态标准角度去考虑。
数据加密风险
数据加密是存在风险的，可能存在加密后无法还原的风险。通常的做法是使用明文与密文并存方式解决。但由于明文的存在，必然会导致安全风险。目前针对这一问题没有很好的解法，常规的做法就是并存+隔离、小步快跑的策略。
用户意愿问题
这是一个终极问题，由于数据存储安全需求带来的各种问题，势必会影响用户对数据的使用且会存在较大的成本投入及面临风险。因而导致用户整体意愿不高，更多是政策层面的驱动。针对这一问题，一方面要看到数据安全已受到国家层面的关注，是必须要解决的问题；一方面通过技术上的不断完善成熟，加速稳定落地。
