Encryption basically has two use cases:
1. Moving information from point A to point B and not letting anyone else be able to see it during transit.
2. Making sure that when the information is at rest (data, email, etc.) that unauthorized people cannot use it or read it.
You often hear claims like "AES 256 bit encryption" or "We use military grade encryption". Doesn't mean much. All encryption uses keys. These keys are mathematical constructs, when used properly,
provide the amount of security necessary. Who ever has access to the keys, can see your information.
Key management is a very big deal. Your first consideration is who generates the keys and how do they do it. For instance, if you are storing data off site, and the service provider generates and stores the key, you have to ask yourself "Do I trust them"?
This is the model of Google Drive for instance. In that case you are at the mercy of rogue Google employees, stolen equipment, or unknown subpoenas from government agencies.
Amazon Web Services also will generate the key for you, but not store it. That's a little better, but you are vulnerable if a copy is being made surreptitiously.
The best case scenario is you generate your own keys using a proven key generation mechanism (a topic for discussion in itself).
Now comes the hard part. Whoever has the key can read the information. How are you protecting and distributing those keys? What is your access control and audit? What happens if an employee leaves and has a key?
The best scenario is to assess the balance of risk and usability. If it is too difficult it won't be used. One of the slickest methods I've seen for protecting a user / application communicating to a server works like this:
1) The user / application starts a secure session using a public key (PKI uses a lot of overhead)
2) After the connection is made, a single use symetrical key is created (very fast)
3) The session switches to using the same symmetrical key
This gets more interesting when you're talking about backups and disaster recovery. To fail over to a cloud warm site, that site needs your key to restore the data. One way to get around this is to have the service provider hold the key and have that key encrypted. To release the key, you would simply log into the recovery site, enter your credentials and now the key would be released. They don't need to store your password, just an encrypted hash of the password to verify (and maybe 2 factor authentication to your cell phone).
This is all doable and well worth the time to think through the process from beginning to end.
