This is an 'enterprise-friendly' feature - the appearance of thorough security ("all our data is stored with AES-256 encryption") with only a nominal increase in actual security.
Just think: there will be AWS accounts using this while their master AWS console account continues to have a single-dictionary-word password and no MFA. Truly the Cloud is the silver bullet to save us all from shoddy CIOs!
Agreed, this is more of an item to check off on a list than an actual, meaningful feature. It's the kind of thing that some exec who doesn't understand the details will take comfort in, even though at the end of the day the benefit is minimal.
The only way to do this safely is to do the encryption yourself prior to uploading to S3 and manage the keys yourself.
Yes, this. It's awesome that AWS is providing server-side encryption at no additional cost and with no additional client-side implementation effort, but ultimately your data is still at risk.
When Dropbox's authentication layer failed, their encryption was meaningless. Same thing here: data is still vulnerable to errors, misappropriation, subpoena, etc.
Absolutely. This feature is really bad. I would even argue that, giving people who have no idea about security an additional false sense of it, actually decreases security overall. Now people will more likely give their money for this feature instead of paying a proper security analyst to implement security client side.
As I understand it the encryption adds both latency and more points of failure to S3 (keys stored on separate servers). How is adding both of that negligent?
From a security point of view the encryption adds no value at all: Either I trust Amazon to not look at my data, or I don't trust them. If I don't trust them with my data, surely I also can't trust them with my encryption keys.
The reason why this is a big deal is that it appears to satisfy PCI DSS requirements for key management (though I'm curious about their key rotation strategy). E-commerce hosts just got a lot more interested in S3.
From the business perspective I believe that we are talking about a whole new market, not just a feature.
I compare this business initiative with the past "e-mail managed service" market, where companies moved their own e-mail infrastructure to third parties (postini, messagelabs, mxlogic), something unthinkable (from a security or control point of view). Now security is moving to a managed service, seems strange but it can follow a similar route (new companies in this space + acquisitions by leaders).
A big advantage to this is for applications that require HIPAA compliance. One of the rules for HIPAA is to encrypt data at rest. There may be better ways to encrypt your information, but this will tick a box for compliance purposes (the advantage of this shouldn't be underestimated).
It basically allows HIPAA abiding applications to use S3 for data storage without the complexity of dealing with the encryption themselves, or using a 3rd party provider that offers this by proxy.
The only remaining step is to trial and error your way through using it due to the "light" documentation.
I don't see how this can work at all if Amazon has access to your keys but doesn't sign a Business Associate Agreement under HIPAA. They've refused to do this for us.
It might be viable to encrypt yourself and keep the keys, because then you're not giving them PHI---just goblety gook.
Could someone duplicate this server side encryption by inputting a key to hold in RAM that handles encryption? Or possibly a second server that accepts encrypted data and sends back decrypted data?
Which means that every time a system needs to reboot, losing key in RAM, someone needs to put in the key.
My naive view means someone with a tank can't run off with unencrypted data.
These are virtual machines right? You can easily read the contents of a virtual machines RAM from the host machine whilst it's running if you want the encryption key.
Ah, but you essentially have the 'evil maid' problem Schnier described. So I somehow gain physical access (or otherwise gain root) I then shut the server you are on down and replace the program that accepts your encryption key with my own program that saves the key for my own use. You'd see a reboot, you'd login and input your key, and I could run off with your data.
There are several other ways to do this; but really, countering the 'evil maid' attack is quite difficult.
Hence my second suggestion, a separate server akin to what AWS's post offered. Essentially the encryption server will get encrypted data, de-crypt it and then sends it back to production server (vice versa). It's not public facing, etc. Which means the attacker has to try to compromise the second server that's more locked down.
Or are you saying evil maid attacks can breach the VM they're on?
Pretty sure there is no VM involved... there'd be no reason to virtualize your storage nodes.
But yeah, you are right that if you kept the keys and did the encryption on the second server, you'd have to do the attack on the second server; but that's really just moving the problem around.
Configuring duplicity/rsync to use encryption, for example with database backups, was simple. There are a few guides around and in the end you retain control of your own encryption.
This can provide protection for example against a scenario where some of the hard disks used in S3 happen to end up in wrong place - for a reason or another. One should keep in mind that all data that is once put to the cloud can stay there forever - even if you try to delete it.
You can set custom headers as long as they are prefaced with x-amz-meta...Other than that, you're limited to just a handful of headers. See my reply to thamer for more info.
Sure, you can set custom headers as long as they are prefaced with x-amz-meta...Other than that, you're limited to just a handful of headers. This is a big deal for fonts because the Access-Control-Allow-Origin must be set appropriately to be able to use custom fonts from a different origin (i.e. host&port) and S3 will pretty much always be on a different origin than the rest of your website.
This is slightly off topic, but does anyone else find the AWS dashboard impenetrable? You have to hunt for each of the services you need to add, configuration is very well hidden and I can never find my S3 keys. I had to bookmark the link from the email because otherwise I kept going around in circles. I haven't used EC2 yet just because I'm intimidated by the complexity of that management interface...
No you're definitely not the only one. My company uses EC2 for our production environment and I loathe the management interface with a passion. Amazon should definitely hire a UI expert to give that damn thing a face lift.
It's a mix really, some of it works beautifully, some of it leaves me thinking "I like this but... why haven't they tweaked x" and some really is just horrible.
This is excellent for backups to reduce server load on the client side (no more need to encrypt locally).
I assume there is no extra charge for this from Amazon? (ah I see the footnote, no charge for SSE)
I guess this also means you can upload very large objects without having the hassle of local pre-encryption too - this assumes you have a secure https link to aws though.
Of course this also means aws has your keys stored somewhere which is less secure.
How exactly will this protect my data?