The AWS Shared Responsibility Model and Compliance Validation with AWS Artifact
There are a number of different ways to achieve a level of compliance on AWS (and ever more for the elusive continuous compliance)!
In this post, I’ll take a bit of a dive into the AWS Shared Responsibility Model, to show where you (the customers)responsibility lies, and where AWS' responsibility lies. This is important.
The AWS Shared Responsibility Model - A Deep Dive
AWS are responsible for maintaining the physical security of the global AWS data centres, the AWS global network, servers, switches, hardware, and anything from the host operating system and virtualization layer down.
The customer (you) are then responsible for the guest operating system (e.g to patch and keep your EC2 instances updates in the IaaS model), and configuration of the AWS managed services (e.g AWS firewall). Think of it like, AWS gives you all you need to get going, but if you spin up an EC2 instance and open the security groups to the world, you’ve got no firewalling in place, so anything bad that happens is put squarely in your court.
AWS services are split into three:
Abstraction Amazon S3, Amazon Glacier, Amazon DynamoDB, Amazon Simple Queuing Service (Amazon SQS), and Amazon Simple Email Service (Amazon SES)
Container Amazon Relational Database Services (Amazon RDS), Amazon Elastic Map Reduce (Amazon EMR) and AWS Elastic Beanstalk
Infrastructure Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Virtual Private Cloud (Amazon VPC)
Each category has a different ownership model based on user interaction and functionality of the service.
The customers responsibility is defined by the AWS services selected, and this depicts the outcome of responsibility.
E.g as an AWS managed service, you the customer aren’t responsible for patching database host servers, but if you hosted say a MySQL database on an EC2 instance you would be responsible. This is an example showing the difference between using a container service (Amazon RDS) vs an Infrastructure Service (Amazon EC2).
AWS Artifact
But, I hear you ask - how can we deliver solutions to our clients using AWS Managed Services and prove compliance!? They are black-box. We have no control of what goes under the hood, of something like an RDS instance, or the configuration behind Cognito for user authentication.
There is a slightly less known about service called AWS Artifact that can greatly aid you in this approach. And it is a gold mine, when it comes to completing tasks such as Security Risk Assessments, or C&A processes.
(It’s important to note that AWS Artifact covers a wider remit of scope than just AWS managed services and the example above is a common use-case I’ve provided.)
In a nutshell, AWS Artefact is the way to find all of the various AWS services, and view in detail independent reports performed by 3rd parties to prove compliance and security on AWS services. This is the way AWS can not only talk the talk with compliance, but they can walk the walk too.
You can also download reports from 3rd parties via AWS Marketplace for ISV vendors who have completed reports for you.
It’s a free AWS service too! So take a look.
Sounds, great, how do I use it? Let me show you now!
Login to the AWS Management Console
Login to the AWS Management Console and search for AWS Artifact
Now click on the view reports button. For the purposes of this demonstration we’ll be using the Accessibility Conformance Report (VPAT) - Amazon Cognito User Pool
Now you’ve downloaded the report, it will download as a PDF document to your local disk, and you can simply open and review it.
The PDF will have a T&C’s attached PDF, so you might need to navigate around your PDF reader to find the actual report, and use the links throughout for links to external references as well.
That’s it for AWS Artifact! A really useful tool, and you can share the reports easily using the URL’s and/or via the AWS Management Console (e.g if you want to share a copy with an external auditor).
That’s me! I hope you enjoyed this blog.