IaaS Encryption: Understanding Encryption Systems
Now that we have covered the basics of how IaaS platforms store data, we need to spend a moment reviewing the parts of an encryption system that are relevant for protecting cloud data. Encryption isn’t our only security tool, as we mentioned in our last post, but it is one of the only practical data-specific tools at our disposal in cloud computing. The three components of a data encryption system Cryptographic algorithms and implementation specifics are important at the micro level, but when designing encryption for cloud computing or anything else, the overall structure of the cryptographic system is just as important. There are many resources on which algorithm to select and how to use it, but far less on how to piece together an overall system. When encrypting data in the cloud, knowing how and where to place these pieces is incredibly important, and one of the most common causes of failure. In a multi-tenant environment – even in a private cloud – with almost zero barriers to portability, we need to pay particular attention to where we manage keys. Three major components define the overall structure of an encryption system are: The data: The object or objects to encrypt. It might seem silly to break this out, but the security and complexity of the system are influenced by the nature of the payload, as well as where it is located or collected. The encryption engine: The component that handles the actual encryption (and decryption) operations. The key manager: The component that handles key and passes them to the encryption engine. In a basic encryption system all three components are likely to be located on the same system. As an example take personal full disk encryption (the built-in tools you might use on your home Windows PC or Mac): the encryption key, data, and engine are all stored and used on the same hardware. Lose that hardware and you lose the key and data – and the engine, but that is’t normally relevant. (Neither is the key, usually, because it is protected with another key that is not stored on the system – but if the system is lost while running, with the key is in memory, that becomes a problem). In a traditional application we would more likely break out the components – with the encryption engine in an application server, the data in a database, and key management in an external service or appliance. In cloud computing some interesting limitations force certain architectural models: As of this writing, we cannot typically encrypt boot instances the way we can encrypt the full disk of a server or workstation. So we have fewer options for where to put and how to secure our data. One risk to protect against is a rogue cloud administrator, or anyone with administrative access to the infrastructure, seeing your data. So we have fewer options for where to securely manage keys. Data is much more portable than in traditional infrastructure, thanks to native storage redundancy and data management tools such as snapshots. Encryption engines may run on shared resources with other tenants. So your engine may need special techniques to protect keys in live memory, or you may need to alter your architecture to reduce risk. Automation dramatically impacts your architecture, because you might have 20 instances of a server spin up at the same time, then go away. Provisioning of storage and keys must be as dynamic and elastic as the underlying cloud application itself. Automation also means you may manage many more keys than in a more static, traditional application environment. As you will see in the next sections when we get into details, we will leverage the separation of these components in a few different ways to compensate for many of the different security risks in the cloud. Honestly, the end result is likely to be more secure than what you use in your traditional infrastructure and application architectures. Share:
