步骤1：分析并确定要保护的关键数据

要对数据进行保护之前，首先要确定哪些数据需要保护和为什么要保护这些数据。这其本质是一个数据分级的问题。数据分级从概念上讲是根据数据的敏感程度和数据遭到篡改、破坏、泄露或非法利用后对受害者的影响程度，按照一定的原则和方法进行定义。另一方面也需要关注的就是法规遵从性需求。例如《数据安全法》第二十一条就规定，”国家建立数据分类分级保护制度，根据数据在经济社会发展中的重要程度，以及一旦遭到篡改、破坏、泄露或者非法获取、非法利用，对国家安全、公共利益或者个人、组织合法权益造成的危害程度，对数据实行分类分级保护”。下图就是就是按数据敏感程度做的一个划分示例

步骤2：选择适合技术方案和加密算法

作为数据防护是否能够成功实施的关键，企业需要在关键数据的安全性、保持应用系统的功能可用性，和系统可维护性方面综合考虑，来确定适合企业需要的加密保护的技术方案。下表罗列常用加密技术及应对的安全风险。

磁盘采用的块级别加密技术，例如AWS的EBS，阿里云的ECS等都支持磁盘加密。这种加密大的好处在于，它对操作系统是透明的。性能在加密后较加密前有所降低，根据上层应用的不同性能下降幅度各异。

通过堆叠在其它文件系统之上（如 Ext2, Ext3, ReiserFS, JFS 等），为应用程序提供透明、动态、高效和安全的加密功能。典型的是用于加密指定的目录。需要关注的是这种加密方式可能会产生较大的性能损失。

透明数据加密TDE，是数据库提供的一种加密技术，即对数据文件执行实时I/O加密和解密。数据在写入磁盘之前进行加密，从磁盘读入内存时进行解密。TDE不会增加数据文件的大小，开发人员无需更改任何应用程序。其对应密钥管理也是由数据库提供的API或组件实现，应用透明。在某些场景下磁盘或系统无法对用户开放（如云环境）的条件下，这种方式就比较适合。

数据库加密还有种方式是采用对数据库进行三方加固的方式，即将第三方专业数据库加密厂商的产品内置在数据库之中，提供透明数据加密能力。所谓透明是指，用户应用系统不需要做改造即可使用，且具有权限的用户看到的是明文数据，完全无感。此外，还可以增强原有数据库的安全能力，如提供三权分立、脱敏展示等。

应用层加密，可以说是一种终极方案，其可保证在数据到达数据库之前，就已经做了数据加密，可实时保护用户敏感数据。这里关键需要提供应用透明性，保证应用无需改造或仅需少量改造。这种方式完全由用户自己控制，无需信任任何三方厂商提供的数据安全保障，得到充分的自由度和灵活性。例如可以跨多数据库提供统一安全加密策略等。

 对比几种方式 

步骤3：保护好数据的加密密钥

为了保护好加密数据，不会被非法窃取，需要保护好数据的加密密钥。避免第三方厂商或个人接触到明文数据，好做法就是将密文数据的密钥控制在用户自己手中。密钥管理包含了密钥的创建、存储、生命期管理、保护。密钥的安全性直接决定了加密数据的安全性。建议密钥独立存储，并采用根密钥保护，根密钥受硬件加密卡保护，或者被KMS服务的密码保护。所谓KMS密钥管理，是通过用户的口令保护主密钥，口令正确主密钥解密；主密钥对密钥文件进行保护，只有主密钥成功解密后，密钥文件才能使用，后通过密钥文件生成可用的密钥。

步骤4：实施必要的防数据泄漏措施

虽然采取了必要的数据加密措施，但并不能彻底解决来自应用系统环境和运维环境的安全威胁，典型的如来自应用系统的SQL注入攻击、后门程序、利用数据库漏洞的攻击行为、第三方运维人员的误操作等。因此需要采用数据库防火墙这样的数据边界防护技术，利用其细粒度的访问控制、防攻击、防批量数据下载等特性，实现有效的防数据泄漏。

步骤5：监控并审计数据的访问行为

一方面，黑客攻击行为千变万化，另一方面，系统的复杂性带来的数据正常维护和管理行为往往也是不可预期的。因此，需要对重要数据的访问行为采取持续、及时的监控和审计，形成有效的风险报告提供给用户发现新的风险，帮助用户更好地进行数据保护。

步骤6：利用自动脱敏防止测试环境数据泄漏

除了生产环境的数据防护外，企业内部测试环境也是一个重要信息泄漏源，特别是需要“抽取”源端生产数据用于测试系统时；利用数据自动脱敏技术可以在有效地保护生产数据的同时，为测试环境提供可用的符合用户预期的测试数据。

在数据存储安全的同时，如何提供如未加密前的使用体验非常重要。这里可总结为对应用的透明性。使用者或应用系统不需要关心系统进行了哪些保护，可完全无感地使用数据。这样的透明性主要体现在以下方面：

如上面提到的几种加密方式中，存储层加密、文件层加密会存在完全依赖于底层基础设施厂商（或云厂商）的问题，数据库加密也要部分依赖于数据库厂商或三方安全厂商；上述几种方式都会存在厂商绑定风险。对比而言，应用层加密相对灵活度大，可完全从用户角度考虑加密问题，但这一方式必然存在较大投入，如何能做到应用无感是比较头疼的问题。目前主流有通过数据中间层的方式解决，即在应用与数据库之间构建访问层，将数据加密、解密、脱敏等功能实现其中。对上面的应用提供标准化、透明的数据访问接口，对下数据库提供标准规范的安全策略，可不绑定具体产品。

如前面谈到的应用层加密，也许是个不错的选择。对应用来讲，好的透明使用方式是提供出标准的数据库接口服务。当前主流是采用Proxy模式，可以让应用完全无感地使用。但想做到无感，是需要从数据库协议层面仿真模拟，但受限于商业数据库协议的封闭，是存在一定局限的。虽然可以通过如JDBC/Client的方式去做，但这种方式一是无法完全无感，二是会存在更新客户端困难等问题。

性能效率问题

数据存储安全所涉及的数据加密、解密、脱敏等，势必会影响到应用使用效率。虽然很多产品都号称效率很高，但这个性能瓶颈是客观存在的。这里首先需要的是正视效率问题，能客观评估效率差异；此外如何能通过某些方式去扩展计算能力，部分解决效率低下问题也是一种思路。相对而言，采用存储层、文件层方式，可在一定程度上解决此问题。

针对数据加密，存在一个存量的问题。如果是新建项目，完全可以采用全新的数据安全策略，但对于已有项目且存在数据，是需要解决数据清洗及迁移问题。针对前者，难点在于如何实现动态清洗，在系统在线的同时，应用可同步处理新旧数据，逐步完成清洗动作。清洗后的解决还需解决数据校验等，确保清洗是准确的。针对后者，在清洗完毕后，需要做应用层面迁移，完全切换回去；这里需解决平滑过度问题及可能出现的回退问题。针对上述难点，应用层方案，无疑是比较好可以解决此问题的。

数据终是要参与到计算中的，不能因安全需求而影响到计算。对于数据安全计算，取决于其所处的位置在何处。对于存储层、文件层，其位于数据库之下，作为数据计算主体的数据库是可不感知的，但对于数据库层和应用层是要解决这一问题。数据经过加密后，会失去其数据特征，这会影响到优化器、执行器的工作。应用层加密也是同样的。目前存在一些密态计算技术，能在一定程度上解决这一问题。

国密算法，即国家商用密码算法。是由国家密码管理局认定和公布的密码算法标准及其应用规范，其中部分密码算法已经成为国际标准。如SM系列密码，SM代表商密，即商业密码，是指用于商业的、不涉及国家秘密的密码技术。之前很多的安全产品（特别是国外产品）是不支持国密算法的，这点是企业在做安全策略时需考虑的问题，特别是重监管的企业。

数据散落在企业各处，提供统一、全局、细粒度的安全管控，包括复杂条件授权等是很有意义的。对于企业可采用统一的数据视角解决安全问题。目前通常的做法是基于不同数据库自己来实现各自安全策略，对客户不甚友好，如能统⼀处理，非常具有商业意义。针对这点，是需要站在单一产品之上，从数据使用生态标准角度去考虑。

数据加密是存在风险的，可能存在加密后无法还原的风险。通常的做法是使用明文与密文并存方式解决。但由于明文的存在，必然会导致安全风险。目前针对这一问题没有很好的解法，常规的做法就是并存+隔离、小步快跑的策略。

这是一个终极问题，由于数据存储安全需求带来的各种问题，势必会影响用户对数据的使用且会存在较大的成本投入及面临风险。因而导致用户整体意愿不高，更多是政策层面的驱动。针对这一问题，一方面要看到数据安全已受到国家层面的关注，是必须要解决的问题；一方面通过技术上的不断完善成熟，加速稳定落地。