One of the fundamental security tools for protecting data in multitenant environments is encryption. When implemented...
properly, cloud encryption can allow you to protect data when you don't have full control of the environment. This is valuable both in private cloud and public cloud -- anytime you are sharing a repository with users and data of different sensitivity levels.
But encrypting for the cloud isn't the same as encrypting for a single-tenant environment you have full control over. Implemented improperly, encryption may not buy you the security you think you're getting. And, while we commonly see these mistakes in traditional infrastructures, they tend to be exacerbated when we move to the cloud.
There are three major components to any encryption system: the data, the encryption engine and the key management. With something like laptop encryption, all three components are running or stored in the same place -- on the laptop. In our application architectures, we tend to break things out more to reduce the chances that the compromise of any single component will result in compromise of the entire system. Let's look at how these three pieces are distributed in some common cloud security architectures:
1. When using the cloud for data storage, implement a virtual private storage architecture. Encrypt the data before it's sent to the cloud, and decrypt it when it comes back. For example, use a cloud backup service that encrypts the data locally in the backup software using a local key before it's stored in the cloud. Since you are managing the encryption and keys, it's critical you keep copies of the keys in a secure backup (which should be a function of the key management built into your backup solution).
2. For basic encryption of data stored in an IaaS application, you can build volume encryption into your instance, and store the data in a second encrypted volume. This isn't the most secure option, since you are storing the key with the encryption engine in your instance, but this does protect you from anyone without the right access to the running instance from seeing your data. For example, assuming you've created your instance properly so someone from the cloud provider can't authenticate to the operating system or application (which is the typical default), they have no way of getting the key and then accessing the encrypted volume. (The exception is if they pull the key from volatile memory, which is rare for most threat models).
3. For more advanced encryption, you can separate the key from the encryption engine in the instance. In this three-tier architecture, you have a volume with the encrypted data, an instance with the encryption engine, and a third key-management server that provides the encryption key on-demand. This is useful if you don't want the key embedded with the instance, since then an attacker who obtains a copy of the instance has a copy of the key. An attack might also spin up a new instance off the same image with the embedded key. The external key management server should only return the key when a set of policy-based criteria are met, such as manual approval of a new running instance, or based on integrity checks in the encryption client running in the instance. The key is then used by the instance in memory until it's shut down. This option is typically only available with special cloud encryption products.
These are only three of many use cases for cloud encryption, but they highlight three different ways to distribute the encryption engine, key management and data. For example, we also see virtual private storage for SaaS in commercial products that sit in an enterprise network and proxy traffic to the SaaS provider, encrypting sensitive pieces of data like Social Security numbers.
With so many different cloud service providers, internal cloud configurations, and SaaS, PaaS and IaaS models, it’s impossible to detail them all here. . But as long as you understand who you are trying to protect against, and where your data, encryption engine and keys are located, you can design extremely secure architectures, even for multitenant environments outside of your control.
About the author:
Rich Mogull has nearly 20 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, he spent seven years at Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies, including DLP, and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security.