What is the shared responsibility model
In my final semester in school, I made a presentation about security threats faced by cloud technologies. In that session, my professor began his questioning with a simple question: "What is the shared responsibility model". I let my teammate answer that question that day because she was a Solutions Architect and I didn't want to step on her toes. Today, let's visit the question with what I know now.
What is it?
The Shared Responsibility Model is a framework that helps to define who is responsible for each vertical component within a managed service. This means there are components entirely within the responsibility of the service provider, some entirely within the responsibility of the customer, and some have nuance. Let's explore them.
S3 - a very managed example
For an extremely managed service like S3, the responsibilities are rather clear. AWS (the provider), takes care of the hardware within the data centre, the BIOS firmware, the operating system, the hypervisor and/or container abstractions within the system and ultimately the S3 application itself. The responsibility of the customer will be what they can configure. So the access policies from IAM or S3 bucket policies, the content they are storing (the files themselves), and other toggles the S3 service allows them to control like versioning, retention policies, etc.
EC2 - a less managed example
For a less managed service like EC2, the responsibilities are rather clear too. AWS takes care of the hardware, the hypervisor that abstracts the virtual machine away from the host (if it exists, idk the internal implementation of Ec2). Everything on and above the operating system layer is the responsibility of the customer. Again, their responsibility is what they have control over. If they use an insecure AMI, it's the customer's fault. If they accidentally exposed ports to the public (through security groups), customer's fault. If they run an outdated and insecure version of Nginx on their EC2 instance, customer's fault.
SQS - a very managed example, with nuance
Of course, there are nuances here. SQS is a simple messaging queue service that provides 2 types of server-side encryption for data at rest. Customers can use SQS-managed encryption, or they can use AWS KMS. But, what is stopping them from encrypting the content on the client side? Nothing. So now, if the client decides that AES-based encryption is not strong enough, they can choose to encrypt their payload externally before passing the message into an SQS queue. So, there is some nuance here, the shared responsibility for the same component, encryption, can be either the responsibility of the provider and/or the responsibility of the customer. It depends on the customer's implementation of their application and configuration of the service (of course, client-side encryption is not the same as server side and they can both be done on the same implementation, which is my point).
As consumers of the cloud, it is important that we consider our technology implementation along with the guidance provided by the cloud providers. So yea, that is the shared responsibility model.
