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:
- Data: The data object or objects that need to be encrypted.
- Encryption engine: The engine that performs the encryption operation itself.
- 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.
