随着互联网的迅速发展，以数据库为基础的信息系统在各行各业基础设施建设中得到了广泛的应用，越来越多的数据信息被搜集、存储以及发布，其中大量信息被用于行业合作和数据共享。但是由于信息的易获取，这些包含在数据库系统中的关于商业或技术机密、个人隐私等涉密信息将面临更多的安全威胁。数据泄漏无处不在，且愈演愈烈。因此，数据加密尤为重要。数据库透明加密技术是针对关系型数据库保密需求应运而生的一种数据库加密技术。透明数据加密（Transparent Data Encryption，简称TDE），通过证书加密数据文件和备份文件，可进行实时的io加密/解密，能有效保护数据库及数据文件的安全。RDS for SQL server提供透明数据库加密功能，为您的数据保驾护航。开启实例级别的TDE加密功能1.登录管理控制台。2.单击管理控制台左上角的，选择区域和项目。3.选择“数据库 > 云数据库 RDS”。进入云数据库 RDS信息页面。4.在“实例管理”页面，单击目标实例名称，进入实例的“基本信息”页面。5.在“数据库信息”模块，单击“TDE状态”后的。  图1 开启实例级别的TDE加密功能6.在弹出框中，单击“确定”进行二次确认后，开启TDE加密功能。   说明：实例级别的TDE加密功能一旦开启，将不允许关闭，请您谨慎操作。设置数据库级别的TDE加密功能   在开启数据库级别的TDE加密功能之前，请确保已成功开启实例级别的TDE加密功能。 1.连接目标实例。 请参考通过公网连接SQL Server实例、通过内网连接SQL Server实例及通过DAS连接SQL Server实例。 2.通过rds_tde存储过程开启、关闭或查询TDE加密功能。 exec master.dbo.rds_tde DatabaseName,TDE_ActionDatabaseName：目标数据库名，取值可为null。TDE_Action：取值为“-1”，表示查询目标库加密信息。      如果“DatabaseName”取值为null，则返回所有库的加密状态。取值为“0”，表示关闭目标库TDE加密功能。取值为“1”，表示开启目标库TDE加密功能。 3.开启数据库db1的TDE加密功能：  exec master.dbo.rds_tde db1, 1 4.关闭数据库db1的TDE加密功能：  exec master.dbo.rds_tde db1, 0 5.查询数据库db1的TDE加密状态：  exec master.dbo.rds_tde db1, -1 6.查询所有数据库的TDE加密状态：  exec master.dbo.rds_tde null, -1更多相关介绍，欢迎查看https://support.huaweicloud.com/usermanual-rds/rds_11_0004.html

1 、密钥分层管理结构密钥的安全管理通常采用层次化的保护方式。密钥的分层管理机制通常把密钥分为三层，即：根密钥、密钥加密密钥和工作密钥，下层的密钥为上层密钥提供加密保护。采用分层的密钥结构有助于使密钥的管理满足本规范的要求 Ÿ 工作密钥：工作密钥对本地保存的敏感数据和需要在不安全信道上传输的数据提供机密性、完整性保护，还可提供认证和签名等密码学服务。工作密钥直接被上层应用程序所使用，包括存储加密使用的密钥、预共享密钥、MAC密钥、签名私钥等。Ÿ 密钥加密密钥：对工作密钥提供机密性保护的密钥，其自身受到根密钥的保护。对于较为简单、安全等级要求不高的密码应用系统，密钥加密密钥的职能可以直接由根密钥兼任。Ÿ 根密钥：位于密钥管理分层结构的最底端，用于对上层密钥（如密钥加密密钥）的机密性进行保护。 规则：密钥分层管理至少选择两层结构进行管理说明: 密钥的分层管理机制最少把密钥分为两层，即：根密钥和工作密钥，根密钥为工作密钥提供加密保护。根密钥、工作密钥的生成必须满足本规范中4.1节对密钥生成的相关要求。密钥分层管理结构的选择与其应用场景有密切的关系。选择三层结构还是两层结构取决于产品所涉及的加密应用场景的复杂度。应用场景复杂的情况推荐使用三层管理结构。适合三层密钥管理结构的场景有：Ÿ 根密钥更新过程产生大量的加解密运算开销在应用系统中，如果使用根密钥直接保护工作密钥，根密钥的更新会导致所有受其加密保护的工作密钥需要全部使用更新前的根密钥解密，再重新使用更新后的根密钥加密。当工作密钥数量比较庞大时，对工作密钥的解密和加密操作将耗费大量的资源并影响系统的性能。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），密钥加密密钥对工作密钥进行加密保护，根密钥则对KEK进行加密保护。当根密钥更新时，只需要解密和重新加密KEK即可，由于KEK的数量远远小于工作密钥数量，对KEK的解密和加密操作不会消耗大量资源，对系统的性能影响很小。当KEK更新时，将需要被更新的KEK和被其保护的工作密钥都保存成历史密钥信息。应用系统需要解密被历史密钥信息加密的数据时，直接使用历史密钥解密即可。Ÿ 系统要求频繁的进行工作密钥更新在应用系统中，如果工作密钥的更新频率很高，典型的应用场景是工作密钥作为通信密钥（可能要求每次会话都被要求使用不同的密钥）。该场景下的工作密钥更新过程通常在线进行，需要使用工作密钥的下层密钥加密保护工作密钥的传输过程。如果使用根密钥直接保护工作密钥，根密钥加密的密文会频繁的在不安全的信道上传输，并易于被攻击者截获。攻击者可以通过分析大量密文破解根密钥。虽然通过更新根密钥的方法可以有效避免上述对根密钥的攻击，但根密钥更新周期一般较长，且一般使用手动方式更新，无论采用白盒密码还是基于密钥组件的根密钥保护方案，根密钥的更新操作都较为繁琐，难以广泛的适应该应用场景的要求。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），工作密钥的更新过程使用KEK保护，由于KEK的更新频率远远小于工作密钥的更新频率，KEK的更新可以使用根密钥保护。由于KEK更新周期相对较长，即使攻击者可以截获使用根密钥加密的KEK密文，获取的密文数量也非常有限，所以攻击者很难通过分析密文破解出根密钥。Ÿ 应用系统结构复杂如果应用系统中包含两个或者两个以上的子系统，各子系统之间的业务相互独立，每个子系统都为用户提供不同的服务。在这样的场景下，各子系统使用的密钥应该各不相同。如果不同的应用系统之间使用的工作密钥都被根密钥保护，根密钥的泄露（根密钥的泄露风险可参考“系统要求频繁的进行密钥更新”场景）将导致各子系统由密码机制保障的安全性完全失效。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），为每个子系统分配各自的KEK，这样即使某一个子系统的KEK泄露，密码安全机制失效的威胁仅也限于该子系统内，不会影响其他子系统的安全性，而且由于KEK更新较为方便，当发生KEK泄露的事故后，可以通过立即更新KEK的方法将信息泄露的损失最小化。2、密钥生命周期一个密钥在其生命周期中会经历多种不同的状态。密钥在其生命周期的各个阶段，都应满足一些基本的安全要求，以保障自身的安全性。密钥生命周期由于不良设计可能导致的安全问题生成生成算法随机性差，导致密钥可被预测，或攻击者可以自己生成密钥。分发密钥明文分发，导致密钥存在被攻击者截获的风险。更新密钥从不更新，导致攻击者更容易获取密钥，从而能够轻易获取敏感数据的明文。存储密钥明文存储在数据库中，导致攻击者容易读取出密钥，从而能够轻易获取敏感数据的明文。备份如果重要密钥从不备份，一旦密钥丢失，将导致原有加密的数据不能解密，大大降低了系统可靠性。销毁密钥仅被普通删除，导致攻击者有可能恢复出密钥。3 、密钥生命周期的安全管理] 密钥的生成密钥通常被划分成对称密钥和非对称密钥。常用的密钥生成方式包括：基于安全的随机数发生器、基于密钥导出函数、基于标准的密钥协商机制、基于安全的密钥生成工具等。利用随机数发生器、密钥导出函数、密钥协商等方式来生成密钥，均应遵循一些规则，以使产生的密钥足够安全。1 iPSI、OpenSSL数字信封加解密接口接口iPSIOpenSSL加密CRYPT_sealInit()EVP_SealInit()CRYPT_sealUpdate()EVP_SealUpdate()CRYPT_sealFinal()EVP_SealFinal()解密CRYPT_openInit()EVP_OpenInit()CRYPT_openUpdate()EVP_OpenUpdate()CRYPT_openFinal()EVP_OpenFinal()4、密钥须支持可更新，并明确更新周期，在一次性可编程的芯片中保存的密钥除外工作密钥及密钥加密密钥在使用过程中，都应保证其可以更新。对于根密钥暂不要求必须支持可更新。密钥可更新才能保证密钥使用的安全，原因如下：Ÿ 密钥使用时间越长，攻击者花费精力去破解它的诱惑也越大，这使得密钥被破解的风险也越大；Ÿ 密钥加密的数据量越多，攻击者能够获取到密文的数据机会也越大，而对被同一个密钥加密的多个密文进行密码学分析相对比较容易，导致密钥越容易被破解；Ÿ 如果密钥已经泄露，那么密钥被使用的时间越久，损失越大。密钥生命周期的结构因素较多，包括：密文被攻击者进行密码分析的可能性、密钥泄露产生的连锁危害的严重程度、密钥本身的保护机制（如：访问控制）的强度、被密钥保护的敏感数据的重要程度、密钥因为某些管理原因造成泄露的可能性等。应用系统设计人员可以参考以上因素确定适当的密钥更新周期。密钥的更新一般包括如下两种方式：1、系统定期自动更新密钥。执行密钥更新时，系统根据密钥生成的规则，重新生成新密钥，同时使用旧密钥解密已加密的数据，并使用新生成的密钥重新加密，同时销毁旧密钥；对于加密数据量很大的场景，可以考虑保留旧密钥，用于解密旧密钥加密的数据，同时使用更新后的密钥加密新数据。此方式适用于系统可自主生成密钥的场景。 2、管理员手动更新密钥。管理员根据实际需要，触发密钥更新指令，系统接收到更新指令后，根据密钥生成规则，重新生成密钥；或者管理员利用安全的密钥生成工具，重新生成新密钥。生成新密钥后，系统利用旧密钥解密已加密的数据，并使用新密钥重新加密数据，同时销毁旧密钥；对于加密数据量很大的场景，可以考虑保留旧密钥，用于对旧数据的解密，同时使用更新后的密钥加密新数据。