I for one think that S3's server side encryption is amazing for most if not all data. We backup hundreds of gigabytes of data every day to S3 and enabling server side encryption enables us to not worry about generating, rotating, and managing keys and encryption strategies. It also saves us time since we don't have to compute the encryption or the decryption. The best part is that the AWS AES-256 server side Encryption at Rest suffices for compliance.
Of course, the data that we store, while confidential, isn't super-mission-critical-sensitive data. We trust AWS to not peek into it, but nothing will be lost if they do.
I suppose it's OK for some use cases but realistically it doesn't provide a whole lot of security.
Doing this only really protects you if someone steals the physical disks from inside AWS, whilst this is a legitimate risk it seems incredibly unlikely and i'm not aware of any such instance.
HOWEVER, it does not protect you from the far more likely scenario of someone gaining access to your AWS account. If someone is able to get your credentials (or otherwise hack your account) then all your data is vulnerable.
In a lot of cases your AWS account being compromised is going to open you up to having any encryption keys you use for GPG encryption stolen too anyway. So it seems that there's a decent chance that even GPG encryption is just protecting you from the "disks stolen from the datacenter" risk.
At the end of the day your AWS account is often the "master key", so make sure you use a good password, rotate it, and 2-factor auth.
How's that? Say you set up duplicity on your AWS instances. They only need access to the public encryption key and private signing key -- the session (actual encryption) keys will be destroyed after a backup is made. Now, to restore you'll need to provide access to the public signing key (this is public, so no problem), and private encryption key. This should only ever be on-line and decrypted in case of a restore.
Of course, if you set things up differently, then, yes. Compromised by design.
Well clearly you wouldn't keep your keys in s3, if you were to keep them on an ec2 instance, for example, as long as you had proper SSH access configured even with AWS account access the servers would still be secure.
That then makes your local SSH key the last link in the chain (and OpenSSL of course, and that you trust AWS is actually encrypting the data).
What kind of "encryption-at-rest" compliance industry or standard are you dealing with?
I'm curious to where what AWS supplies suffices. As the encryption and decryption is, AFAICT, automatic and transparent, aren't you merely protecting your data from someone at AWS running off with it?
I.e. if your system that does the API calls is somehow exploited, the attacker has your AWS keys and so can get to the encrypted data. Or if there's a programming error in your data access routines that check whether user X can access data Y.
Perhaps I'm reading too much into what "encrypted data at rest" really is supposed to provide though (i.e. just data encrypted, key stored on a different system)
Just interested in what compliance you are referring to? We are looking at options for storing medical data in the cloud and I understand that Amazon can be used so as to conform with HIPPA [http://en.wikipedia.org/wiki/Health_Insurance_Portability_an...].
Yes, it can be used, but it needs some work up front. Like all compliance schemes it is not entirely devoid of effort. There used to be a whitepaper outlining the basics somewhere in the AWS site, IIRC.
There's also a number of companies providing HIPPA-compliant cloud services at various tiers and some of the offerings are backed by AWS. So it's possible and it's been done already.
Yes I appreciate that a service like AWS can't give you HIPPA of 21CFR Part11 compliance, only supply tools that can be used that way. What I'm looking for are examples (e.g. white papers) that describe how people have done it, preferably having been audited too.
Of course, the data that we store, while confidential, isn't super-mission-critical-sensitive data. We trust AWS to not peek into it, but nothing will be lost if they do.