AWS preaches the “Shared Security Model” and emphasizes what it is responsible for and what you are responsible for.
You got hacked? You must have configured it wrong because we already told you it was unhackable; Good luck proving it was our fault not yours.
Seems like it would be incredibly easy to prove that an S3 bucket was misconfigured in such a way that the data was publicly accessible. In fact this has been the case in the recent high-profile cases that I can recall.
The hacker got ephemeral keys by remotely exploiting the WAF. The WAF had no reason to have privileges to read from S3, that was a mistake.
I’m unclear if data in bucket was encrypted at rest but I guess if you get keys to read it’s a moot point.
They make no promises about your side.
The customer agreement[4] states:
> 3.1 AWS Security. Without limiting Section 10 or your obligations under Section 4.2, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure.
> 10. Disclaimers. THE SERVICE OFFERINGS ARE PROVIDED “AS IS.”
It goes on with the usual shouty disclaimers.
The service terms[3] state (I'm specifically citing IAM here because it's how you handle a ton of authentication):
> 19.3 You are responsible for maintaining the secrecy and security of the User Credentials (other than any key that we expressly permit you to use publicly). You are solely responsible, and we have no liability, for any activities that occur under the User Credentials, regardless of whether such activities are undertaken by you, your employees, agents, subcontractors or customers, or any other third party.
My read on it:
AWS generally gives you tools to secure your data, and it's largely up to you how you want to do it.
The docs state that if you set IAM to allow or deny access to a service to an authenticated entity, then IAM will do that. If you set up a VPC and shut off a port through a security group, it's going to be locked down.
AWS has a slew of services, and these things can interact in surprising ways. So reading the permissions, you're often wondering[1], "what permissions do I need" and it's not always clear what a permission grants.
To summarize, then, the AWS documentation at a low level gives you some very technical instructions, and at a high level will generally recommend best practices[2].
I will say that IAM is good stuff and works, the issue is the sheer complexity of configuring it all, and a few footguns thrown in for good measure. But AWS should look at adding "security agreements" similar to their Service Level Agreements that guarantee availability.
[1]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_perm...
[2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi...