Up front, I worked at AWS on the CloudHSM team, don't work at AWS any more. I am not a lawyer. This is all my opinion from a very brief analysis.
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.
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...
[3]: https://aws.amazon.com/service-terms/
[4]: https://aws.amazon.com/agreement/