Example parsing cloud computing encryption

Encryption is one of the basic security tools for protecting data in a multi-tenant environment. For private cloud computing and public cloud computing, especially when you share a repository with different sensitive levels of data with other users. When you do not have full control over the cloud computing environment, it is invaluable that cloud computing encryption allows you to protect your data if implemented properly.

But cloud computing encryption is not the same encryption technology used in a single tenant environment where you have full control. If implemented improperly, cryptographic techniques may not achieve the functions and effects you expect to achieve. Also, errors that are common in traditional infrastructures have a greater negative impact as the cloud migrates.

Any cryptographic system has three main components: data, encryption engine, and key management. As with a laptop, all three components are run or stored in the same location. In our application architecture, any single part of the damage can cause the entire system to crash, so we tend to detach the three parts as much as possible to reduce this possibility. Now let's look at how these three parts are distributed in some common cloud computing security architectures:

1. When using cloud computing for data storage, a virtual private storage architecture is typically used. Encrypt data before it is sent to the cloud and decrypt it when it is sent back. For example, with a cloud computing backup service, the service encrypts data locally using a local key in the backup software before storing it in the cloud. Because you are managing cryptographic operations and keys yourself, keeping a copy of the key in a secure backup is a tool (this should be a feature of the Key Management section of your backup solution).

2. For basic cryptographic operations stored in the IaaS application, you can use the volume label encryption in your instance and save the data in the second volume label. Since your key and encryption engine are stored in your instance, this is not the safest method, but it does protect your data from unauthorized access. For example, assuming that you have created your instance correctly, someone from the cloud computing provider will not be authorized to run the system or application (which is the typical default setting), and they will not be able to obtain the key and then access the volume label. (The only exception is that they found the key from memory, which is extremely rare for most threat patterns.)

3. For more advanced encryption techniques, you can separate the key from the encryption engine in the instance. In this three-tier architecture, you have a volume label that holds encrypted data, one instance to run the cryptographic engine, and the third Key Management Server to provide encryption keys on demand. If you want the key not to be in the instance, this method will meet your requirements, because if the key is in the instance, the attacker who can get a copy of the instance will naturally get a copy of the key. Using the key in the instance can attack the same new instance. An external Key Management Server returns a key only if it satisfies a set of rule-based criteria, such as manually approving a new run instance or checking for consistency in an encrypted client running in an instance. This allows an instance in memory to use the key until the instance is closed. Usually this method is only suitable for special cloud computing encryption products.

The use cases described here are just three of many cloud computing cryptography, but they represent three different ways to distribute cryptographic engines, key management, and data. For example, encrypt sensitive data such as social Security numbers in virtual private storage for SaaS vendor Enterprise networks and agent traffic commercial products.

With so many different cloud computing service providers, internal cloud computing configurations, and SaaS, PaaS, IaaS patterns, we can't enumerate them here. But as long as you know who you're defending against, where your data, encryption engine, and key are, you can design a very secure architecture, even in a multi-tenant environment beyond your control.