Amazon S3 Will Now Encrypt All New Data With AES-256 By Default 27
Amazon Simple Storage Service (S3) will now automatically encrypt all new objects added on buckets on the server side, using AES-256 by default. BleepingComputer reports: While the server-side encryption system has been available on AWS for over a decade, the tech giant has enabled it by default to bolster security. Administrators will not have to take any actions for the new encryption system to affect their buckets, and Amazon promises it won't have any negative performance impact. Administrators may leave the system to encrypt at the default 256-bit AES or choose one of the alternative methods, namely SSE-C or SSE-KMS.
The first option (SSE-C) gives bucket owners control of the keys, while the second (SSE-KMS) lets Amazon do the key management. However, bucket owners can set different permissions for each KMS key to maintain more granular control over the asset access system. To confirm that the changes have been applied to your buckets, admins can configure CloudTrail to log data events at no extra cost. Then perform a test object upload, and look in the event logs for the "SSEApplied": "Default_SSE_S3." field in the log for the uploaded file. To retroactively encrypt objects already in S3 buckets, follow this official guide. "This change puts another security best practice into effect automatically -- with no impact on performance and no action required on your side," reads Amazon's announcement.
"S3 buckets that do not use default encryption will now automatically apply SSE-S3 as the default setting. Existing buckets currently using S3 default encryption will not change."
The first option (SSE-C) gives bucket owners control of the keys, while the second (SSE-KMS) lets Amazon do the key management. However, bucket owners can set different permissions for each KMS key to maintain more granular control over the asset access system. To confirm that the changes have been applied to your buckets, admins can configure CloudTrail to log data events at no extra cost. Then perform a test object upload, and look in the event logs for the "SSEApplied": "Default_SSE_S3." field in the log for the uploaded file. To retroactively encrypt objects already in S3 buckets, follow this official guide. "This change puts another security best practice into effect automatically -- with no impact on performance and no action required on your side," reads Amazon's announcement.
"S3 buckets that do not use default encryption will now automatically apply SSE-S3 as the default setting. Existing buckets currently using S3 default encryption will not change."
Fine! (Score:2)
Re:Fine! (Score:5, Informative)
Amazon keeps the keys, because it's server-side encryption, as the summary said.
This is data-at-rest encryption, essentially. This doesn't protect you against unauthorized access to the S3 bucket through the AWS API or a misconfigured public bucket. This protects you against someone dumpster diving for old hard drives and recovering files from them.
Now you do have an option to do per-file encryption that requires you to have the key in order to decrypt and read the file - that's what the Key Management Service (KMS) is for. If you use that, then I don't think you can even access the file through the S3 API unless you have access to the key, and that access can be very granular using IAM.
If you're looking for "I don't want anyone to have the encryption key except me, and people I authorize" then cloud storage may not be for you, and that's ok. Or, encrypt it before uploading and perform your key exchange out-of-band, just like you would have with any other encryption over the last 10+ years.
Re: (Score:1, Troll)
This protects you against someone dumpster diving for old hard drives and recovering files from them.
Unless, of course, the hard drive containing the keys was thown out too, or (most likely) the keys are stored on the self-same drive as the encrypted file.
Now you do have an option to do per-file encryption that requires you to have the key in order to decrypt and read the file - that's what the Key Management Service (KMS) is for. If you use that, then I don't think you can even access the file through the S3 API unless you have access to the key, and that access can be very granular using IAM.
Which, of coruse, adds absolutely nothing of value. You could always encrypt the file before storing it on S3. That also has the advantage that Amazon does not have the key. All this does is ensure that Amazon has the key so they can "give away your data, decrypted" to whomever they please (including themselves) at any time, with no let or hindrance of
Re:Fine! (Score:4, Interesting)
Unless, of course, the hard drive containing the keys was thrown out too, or (most likely) the keys are stored on the self-same drive as the encrypted file.
Well, in the case of Amazon let's not speculate wildly. This is pretty clear and is a well documented well known service called KMS [amazon.com]. They do the "right" thing and instead of storing the keys on a disk they store them (or more specifically, the keys which decrypt the keys) in a proper hardware security module [wikipedia.org]. These are traceable back as Marvell HSMs [marvell.com] so you can do your own vulnerability research if you need to.
Specifically that means that whilst "Amazon" has the key, at least in the important sense that it's them that could lose it, Amazon's employees should* not have any possible way of personally accessing the keys.
The simple fact is that's much better than most organizations will do themselves.
* do not, assuming that Amazon is not lying about their operations procedures.
Re: (Score:2)
This protects you against someone dumpster diving for old hard drives and recovering files from them.
Unless, of course, the hard drive containing the keys was thrown out too, or (most likely) the keys are stored on the self-same drive as the encrypted file.
Highly unlikely for Amazon. It does not make any sense for their storage architecture. And it would make them fail a number of audit criteria, for example PCI-DSS.
Which, of course, adds absolutely nothing of value. You could always encrypt the file before storing it on S3. That also has the advantage that Amazon does not have the key. All this does is ensure that Amazon has the key so they can "give away your data, decrypted" to whomever they please (including themselves) at any time, with no let or hindrance of any type.
The whole thing is a big nothing for the four-colour brochure with appeal only to the particular idiots who are wowed by the four-colour brochure. In fact, is is designed to reduce or eliminate security, not improve it.
Indeed. This does absolutely nothing for the customer. Of course, marketing knows the customer is all too often stupid, so they praise this as a great new feature. I do not think this _reduces_ security though. More likely Amazon just wants to save some cost and do away with physical destruction of disks and SSDs, which would otherwise be required
Re: (Score:2)
_You_ are the asshole posturing here. I am an actual expert in the field, but I am sure you cannot even remotely grasp what that means. As to the facts of the matter, most can be looked up, but most also require some actual expertise to understand them, so _you_ cannot look them up. You can still fling crap bit that makes you a crap-flinger, nothing more.
Re: (Score:2)
Yup. The very fact that they're using AES-256, i.e. pointlessly taking their keys to eleven which does nothing apart from make the crypto slower is a huge sign that this is driven by marketing rather than security concerns. When someone accesses your bucket using stolen or leaked keys or because you've configured it incorrectly it doesn't matter whether Amazon is using rot13, AES-1024, or [algorithm name removed by NSA bot that doesn't exist].
As you point out, it helps Amazon's cleanup, and nothing else.
Re: (Score:2)
This doesn't protect you against unauthorized access to the S3 bucket through the AWS API or a misconfigured public bucket. This protects you against someone dumpster diving for old hard drives and recovering files from them.
Yeah. But realistically how likely is _Amazon_ (or any other serious cloud provider) to mess up disk decommissioning? They will likely do 1. overwrite 2. secure erase 3. degaussing 4. physical shredding. All not a lot of effort in a large cloud set-up. The first two are just a script-run, the 3rd requires some equipment which is not that expensive for somebody like Amazon and same for step 4. Incidentally, step 4 is the only reliable thing for SSDs, so they will have to do that anyways.
Of course, this could
Re:And the point is? (Score:5, Insightful)
What is the point? Seems a massive waste of resources for no gain whatsoever.
There are endless stories in security circles of peoplpe buying cheap used hard disks of ebay and it turing out that these disks had been diverted from destruction to grey market sale. If the guy you pay to destroy your disks does this to you having the disks encrypted can be the difference between a GDPR jail sentence and never finding out about it because the data never leaks.
Re: (Score:1)
If the guy you pay to destroy your disks does this to you having the disks encrypted can be the difference between a GDPR jail sentence and never finding out about it because the data never leaks.
If you are so stupid as to remain liable after having contracted with a third-party to perform a service and they breach the contract, then you deserve far worse than going to jail. You should be flogged with a cat-o-nine until you are dead for your utter incompetence.
Re: (Score:2)
You cannot pass along criminal liability by contract. Your own employees may lie to you. You may misread an email warning you of problems and nobody believes you when you say you didn't understand. Most of all you might be a decent person who doesn't want the risk of the data leaking in the first place.
Re: (Score:2)
What is the point? Seems a massive waste of resources for no gain whatsoever.
Probably looks good to the idiots reading the four-bolour brochures, however. Those idiots are not known for being particularly intelligent.
"AES-256" is marketing, too. It's no more secure than AES-128.
Re: (Score:2)
How so?
Re: (Score:2)
How not so?
AES256 isn't more secure than AES128 in any meaningful way.
The only reason AES256 was created was to satisfy the requirements for the original NIST competition for key lengths of 128, 192 and 256 bits.
Bottom line: AES128 is currently considered secure today and for all future attacks. Even against quantum attacks.
There's no reason to use AES256, it just complicates things on the software and key management side.
Re: (Score:2)
Grover's algorithm allows brute forcing AES in square root time, relative to classical algorithms. So one day, if someone manages to build a sufficient quantum computer, AES128 becomes equivalent to AES64. AES256 becomes AES128.
AES256 is considered quantum resistant, which is why it's recommended. That is the way in which it is more secure over 128, against foreseeable technology developments.
What's the point? (Score:2)
Re: (Score:2)
And that accomplishes what exactly? (Score:2)
Basically the only use-case is if somebody makes off with disks from the Amazon data center. Yeah, very likely.
For anything else, Amazon can get at the keys, people compromising your machine can get at the keys or do not need to. Hence this has absolutely no use-case. Well, besides selling you something.
I am aware that some regulators require disk encryption even on cloud servers, but that comes from a lack of understanding what disk encryption can and cannot do.
I never considered writing unencrypted to S3 (Score:2)
I for one certainly do not care whether Amazon claims they will apply additional encryption on top of what my software still has to do.
I watched Amazon Flounder Doing Compute HAHA! (Score:2)
Case File JR-116970/S (Score:2)
All this tells me is that AES-256 has probably been broken by whatever quantum connection machines have been developed in the black labs under the surface of Amish County, Indiana.
No biggie.
Simple. . . (Score:2)