Much has been discussed about the latest feature Amazon added to their S3 product. The server-side encryption ensures all data at rest is encrypted. What does this mean? It means, that your data, within the Amazon hard disk emporium, finally hits a spindle they will encrypt it using a AES 256 encryption algorithm.
You can read about the technicalities here on Jeff's blog at Amazon. In summary, there is no need for you to manage public/private keys, simply add a
x-amz-server-side-encryption header to each PUT request to S3 and boom you are now in the security business. Collect that bonus from your boss for your forward thinking.
No changes to your existing apps when it comes to collecting the data again. Amazon will kindly decrypt data, on the fly, and deliver it back the requester. No need to hassle with public/private keys.
Sounds great eh? Ticks another box in the security table and makes all those paranoid management types feel all safe that should someone go waltzing off with a hard disk from Amazon your data is secure.
Wait a minute? What are we protecting against? Someone gaining access to Amazon's data centers and stealing hard disks? Or worse, a disgruntled Amazon employee (do such people exist?) plugging in a USB stick and sucking out your precious data.
Pretty darn rare occurrences if you ask me. If such a breach where to happen, Amazon's business would be crippled as soon as the news hit the media. They take physical security very seriously and take a whole manner of precautions to prevent this.
The problem with this feature is that we, the customer, are not in control. Amazon is the gatekeeper for not only the core data, but the management of the keys. The keys are different for each customer, but so what? The customer has no control, insight or verification into this process.
This feature, at best, is a security placebo. A security blanket if you will! It protects you against nothing that is probable. If someone gains access to your Amazon access credentials, they can also gain access to your stored S3 data. The biggest omission from this potentially excellent feature is putting the key management into the hands of the customers. Let us pass in the necessary part of the key to encrypt/decrypt on the fly through another HTTP header. Not dissimilar to how they manage the core access credentials now.
If you are genuinely concerned about your data at rest, then you encrypt and decrypt before you send the object to Amazon. They will store the encrypted stream and deliver that encrypted stream back to you, which you will then decrypt.
This way you control the complete eco-system, managing your keys. Architect your system properly and you can even use this system to protect against the loss/compromise of your Amazon access credentials.
Any sensitive data you are storing within the Amazon S3 system should be protected as best you can. Assume nothing from Amazon. The data responsibility is yours. Not Amazon's. Yours.
Don't be lazy with security and hope they will solve it for you. It will only end in tears.