云数据库加密架构的几种解决方案

加密架构在很大程度上取决于加密解决方案的目标以及云交付的形式。保护静态数据以免本地泄露、未经授权的访问与保护传输到云中的数据会有很大不同。增加额外的控制来保护数据的完整性和可用性可能会使过程更加复杂。

通常，以下因素与大多数加密实施相关联：

1.数据：需要加密的一个或多个数据对象。

2.加密引擎：本身执行加密操作的引擎。

3.加密密钥：所有加密都基于密钥。保护密钥是一项至关重要的活动，对于确保加密实施及其算法的持续完整性是必要的。

注意：在密码学中，盐是随机数，用作单向函数的额外输入，该函数对密码或短语进行“哈希”。当使用任何随机数生成过程时，应将其作为可信过程进行。关注这些最佳实践对于安全使用基于云的加密服务至关重要。

一、IaaS中的数据加密：

(一) 基本存储层加密

在使用存储层加密的情况下，加密引擎位于存储管理层，密钥通常由云服务提供商持有。引擎将对写入存储的数据进行加密，并在退出存储时对其进行解密（例如：在使用数据时）。

这种类型的加密与对象和卷存储都有关，但它只能防止硬件被盗或丢失。它不会保护云服务提供商管理员或来自存储上层的任何未经授权的访问（例如：应用和数据库，译者注释）。

(二) 卷存储加密

卷存储加密要求加密数据驻留在卷存储上。这通常是通过加密容器完成的，该容器被映射为文件夹或卷。

卷存储加密不会提供对通过如下情况进行的任何访问的保护，即在卷上运行的应用程序内操纵或操作的攻击。

有两种方法可用于实现卷存储加密：

基于实例的加密：在使用基于实例加密的情况下，加密引擎位于实例本身。密钥可以在本地进行保护，但应在实例外部进行管理。

基于实例的加密仅允许通过卷操作访问数据，因此这种方式可提供以下保护：

•卷或者文件物理损失或失窃

•访问存储的外部人员

•快照或者存储级别的备份被删除或者盗窃

基于代理的加密：使用基于代理加密时，加密引擎在代理实例或设备上运行。代理实例是一台安全的设备，这台设备处理所有加密操作，包括密钥管理和存储。代理将映射卷存储上的数据，同时提供对实例的访问。密钥可以存储在代理上或通过外部密钥存储（推荐）（译者注释：与国内密钥管理机制要求不同），代理提供密钥交换和所需的内存密钥保护。

(三) 对象存储加密

如上所述，大多数对象存储服务将提供服务器端存储级加密。这种加密的有效性有限（译者注释：重点是这句话），建议外部加密机制在数据到达云环境之前对其进行加密。

二、PaaS和SaaS中的数据加密

潜在的外部实现方式包括：

•文件层加密：当与通常依赖于对象存储的文件托管和共享服务结合使用时，文件级加密，如数字版权管理（DRM）解决方案，可以非常有效。加密引擎通常在客户端（译者注释： 这意味着服务器端，除非是服务器端纯粹的文件存储，文件加密作用不大）实现，并将保留原始文件的格式。

•应用程序层加密：加密引擎驻留在使用对象存储的应用程序中（译者注释：我们的TrustZ应用数据加密属于这里产品）。它可以集成到应用程序组件中，也可以由负责在进入云端之前加密数据的代理集成。代理可以在客户网关上实现，也可以作为驻留在外部云服务提供商处的服务来实现。

三、数据库加密

对于数据库加密，需了解以下几种实现选项：

•文件级加密：数据库服务器通常存储在卷存储上。这种方式，使用加密引擎和密钥对数据库存放的卷或文件夹进行加密（译者注释：卷指文件系统管理系统）。外部文件系统加密将防止媒介被盗、备份丢失和外部攻击（译者注释：外部供给窃取文件，其他窃取方式没法防），但无法防止访问应用层、数据库实例操作或数据库本身的攻击。

•数据库透明加密（TDE）：许多数据库管理系统都包含加密整个数据库或特定部分（如：表）的能力。加密引擎位于数据库中，对应用程序是透明的。密钥通常驻留在实例中，尽管它们的处理和管理也可能被卸载到外部密钥管理系统（KMS）。这种加密可以提供有效的保护，防止存储媒介被盗、备份系统入侵以及某些数据库和应用程序级攻击（译者注释：数据库和应用程序攻击是防止不了的，是作者理解错误，参考Oracle TDE，即Oracle透明加密）。

•应用层加密：在应用层加密中，加密引擎驻留在使用数据库的应用程序上（译者注释：我们的TrustZ应用数据加密属于这里产品）。应用程序加密可以作为一种强大的机制来防御各种威胁，例如受损的管理帐户以及其他数据库和应用程序级攻击。由于数据在到达数据库之前是加密的，因此执行索引、搜索和元数据收集具有挑战性（译者注释：搜索确实具有挑战性，索引和元数据收集作者应该是具有知识局限性）。基于加密开发和集成的专业知识要求，在应用层加密可能具有挑战性（译者注释： 应用层开发有两种实现方式：1. 在应用层开发定制开发，因为加密技术特殊性，对一般开发人员了解确实有挑战；2. 自动改造方式，我们的TrustZ应用数据加密即采用这种方式，避免需要一般开发人员学习密钥管理规范，加密专业知识。）。

•代理层加密：这涉及使用与应用程序或数据库分离的加密引擎。这也可以描述用于加密和/或解密数据以供应用程序使用的第三方加密服务。

典型的几种加密实现路径

Cloud Data Encryption Architecture and Options（原文）

July 14, 2021

Encryption architecture is very much dependent on the goals of the encryption solutions, along with the cloud delivery mechanism. Protecting data at rest from local compromise or unauthorized access differs significantly from protecting data in motion into the cloud. Adding additional controls to protect the integrity and availability of data can further complicate the process.

Typically, the following components are associated with most encryption deployments:

1. Data: The data object or objects that need to be encrypted.

3. Encryption engine: The engine that performs the encryption operation itself.

5. Encryption keys: All encryption is based on keys. Safeguarding the keys is a crucial activity, necessary for ensuring the ongoing integrity of the encryption implementation and its algorithms.

NOTE: In cryptography, a salt is random data that is used as an additional input to a one-way function that “hashes” a password or passphrase. When any random number generation process is used, it should be conducted as a trusted process. Attention to these best practices is critical to the secure employment of cloud-based encryption services.

Data Encryption in IaaS

Basic storage-level encryption

Where storage-level encryption is utilized, the encryption engine is located on the storage-management level, with the keys usually held by the cloud service provider. The engine will encrypt data written to the storage and decrypt it when exiting the storage (i.e., for use).

This type of encryption is relevant to both object and volume storage, but it will only protect from hardware theft or loss. It will not protect from cloud service provider administrator access or any unauthorized access coming from the layers above the storage.

Volume-storage encryption

Volume-storage encryption requires the encrypted data to reside on volume storage. This is typically done through an encrypted container, which is mapped as a folder or volume.

Volume-storage encryption will not provide protection against any access made through the instance, that is, an attack that is manipulating or operating within the application running on the instance.

There are two methods that can be used to implement volume-storage encryption:

Instance-based encryption: Where instance-based encryption is used, the encryption engine is located on the instance itself. Keys can be guarded locally, but should be managed externally to the instance.

Instance-based encryption allows access to data only through the volume operating system, and therefore provides protection from:

· Physical loss or theft

· External administrator(s) accessing the storage

· Snapshots and storage-level backups being taken and removed from the system

Proxy-based encryption: Where proxy-based encryption is used, the encryption engine is running on a proxy instance or appliance. The proxy instance is a secure machine that will handle all cryptographic actions, including key management and storage. The proxy will map the data on the volume storage while providing access to the instances. Keys can be stored on the proxy or via external key storage (recommended), with the proxy providing the key exchanges and required safeguarding of keys in memory.

Object-storage encryption

The majority of object-storage services will offer server-side storage-level encryption as described above. This kind of encryption offers limited effectiveness, with the recommendation for external encryption mechanisms to have encrypted the data prior to its arrival within the cloud environments.

Data Encryption in PaaS and SaaS

Potential external mechanisms include:

· File-level encryption: File-level encryption, such as digital rights management (DRM) solutions, can be very effective when used in conjunction with file hosting and sharing services that typically rely on object storage. The encryption engine is commonly implemented at the client side and will preserve the format of the original file.

· Application-level encryption: The encryption engine resides in the application that is utilizing the object storage. It can be integrated into the application component or by a proxy that is responsible for encrypting the data before going to the cloud. The proxy can be implemented on the customer gateway or as a service residing at the external cloud service provider.

Database Encryption

For database encryption, the following options should be understood:

· File-level encryption: Database servers typically reside on volume storage. This deployment encrypts the volume or folder of the database, with the encryption engine and keys residing on the instances attached to the volume. External file system encryption will protect from media theft, lost backups, and external attack, but will not protect against attacks with access to the application layer, the instances’ OS, or the database itself.

· Transparent encryption: Many database management systems contain the ability to encrypt the entire database or specific portions, such as tables. The encryption engine resides within the database, and it is transparent to the application. Keys usually reside within the instance, although processing and management of them may also be offloaded to an external key management system (KMS). This encryption can provide effective protection from media theft, backup system intrusions, and certain database- and application-level attacks.

· Application-level encryption: In application-level encryption, the encryption engine resides at the application that is utilizing the database. Application encryption can act as a robust mechanism to protect against a wide range of threats, such as compromised administrative accounts along with other database- and application-level attacks. Since the data is encrypted before reaching the database, it is challenging to perform indexing, searches, and metadata collection. Encrypting at the application layer can be challenging, based on the expertise requirements for cryptographic development and integration.

· Proxy-level encryption: This involves the use of an encryption engine that is separate from the application or database. This could also describe a third-party encryption service used to encrypt and/or decrypt data for application use.