In this digital era, you know how cyber threats are emerging day by day. Therefore, it is very important to protect you or your enterprise against these risks.
To protect, you must first understand how things are being deployed into a cloud environment. What are the boundaries between your cloud provider and customer(You or your organization).
In AWS, security is a shared responsibility between AWS(the cloud provider) and you(the customer). Let’s see how AWS Shared Responsibility Model affects Security & Compliance in the AWS cloud.
Don’t want to miss any posts from us? join us on our Facebook group, and follow us on Facebook, Twitter, LinkedIn, and Instagram. You can also subscribe to our newsletter below to not miss any updates from us.
Today’s focus here-
- What exactly is AWS shared responsibility model?
- AWS Shared responsibility model – Infrastructure services, Container Services, Abstract Services
- Examples of few controls including Inherit, Shared or customer-specific responsibility
- Key benefits of the shared responsibility model, that can be leveraged for better governance
What exactly is AWS shared responsibility Model?
Shared responsibility means responsibility is distributed between the cloud provider(i.e. AWS here) and the customer (i.e., AWS user here). It is part of cloud security framework, where the provider is responsible for securing some portion and the customer some other portion in shared mode to achieve the goal of security & compliance.
In the picture below, you can see two different colour combinations to represent the responsibilities of AWS as security ‘OF’ the cloud, where security ‘IN’ the cloud lies on the customer’s shoulder or AWS user.
Amazon Web Services (AWS) provides lots of security services/offerings to safeguard or protect your cloud environment against cyber threats. Security is the top priority for AWS, as well as the customer, These service offerings from AWS, enable you to maintain the CIA (Confidentiality, Integrity, Availability), also achieving overall security & compliance goals for your enterprise.
Let’s understand here, what it means ?? when we say ‘Security of the Cloud‘ and ‘Security in the Cloud‘ in this shared responsibility model
AWS responsibility – ‘Security of the cloud’
This means AWS is maintaining necessary controls protecting all the physical infrastructure including data centre facility, hardware, software or network components. The customer won’t have to worry about the physical infrastructures on which all AWS services/offering actually operates and AWS ensures security on these including Physical, Network and Hypervisor level etc.
Customer responsibility – ‘Security in the cloud’
The customer owns the responsibility for the security of user data and applications including Guest OS (if applicable). Your cloud provider, i.e., AWS here, might not have context on what type of application you are hosting and what kind of data you are keeping in the cloud. Securing these completely lies on the customer’s shoulder.
In other words, If I say, AWS makes sure that its service offering is secured by taking care of underlying infra. Whereas you are responsible for the security of any application you deploy on these services using various controls.
AWS Shared responsibility model
Let’s see security responsibility around three different categories on a high level. You may notice the responsibility line varies here in the below-shown diagram (self-explanatory with colour difference you notice in this picture here)
Infrastructure Services
When you choose Infrastructure services or Infrastructure as a service(IaaS), more degree of control lies on the customer’s shoulder. Also, It can be considered as more customizable due to more degree of control with the customer.
AWS owns the responsibility to safeguard AWS Global Infrastructure including Physical, Network, and Virtualization levels whereas the customer owns the responsibility to secure Guest OS, Customer Data or systems/applications hosted in the AWS cloud.
Customer will not have to worry about the undisrupted power supply, HVAC or Security of Physical DC etc., as a cloud provider, own these to safeguard and ensures reliable access to the AWS cloud or ecosystem.
When you think about the Infrastructure services of AWS, Elastic Compute Cloud(EC2) very commonly comes into your mind. The customer who deploys any application into the AWS cloud is responsible for safeguarding all necessary configuration and management of that application hosted within that EC2 instance. The customer will be solely responsible for any security patches or any third-party application patches hosted in the cloud environment.
Container Services
It can also be referred to as a Platform as Service (PaaS). It is the next level of abstraction on which customers can build and execute their applications. AWS owns more responsibility in this deployment model in comparison with IaaS.
Amazon RDS can be referred to as an example, where a customer doesn’t need to install or maintain any operating system. AWS is responsible to maintain hardware, and operating system also along with maintaining necessary security patching or system upgrades etc.
On the other hand, the customer is responsible for data encryption, and necessary security setting including VPC or other configurations set. Above diagram, you can refer to the magic lines & different colors to understand who owns what in container services or platform as services (PaaS).
Abstracted Services
This is another category to focus on here, where AWS or a cloud provider owns most of the security responsibilities. In this category, the customer has less responsibility and the provider has more control, hence the less customizable option you may see.
Customers still need to ensure maintain the necessary controls to safeguard customer data. The customer’s responsibility is to maintain client-side encryption to protect the data. It can also be referred to as Software as Services (SaaS)
Amazon s3 (Simple Storage Service), Dynamo DB etc can be considered as good examples here falling under these abstract services. Please refer above diagram to understand the mapping for the responsibility distributed among cloud providers and customers.
Example of Controls in a shared model
Let’s take a look together at a few controls including inherited, Shared and Solely customer specific control, which will give us a more clear understanding of this shared model of security & compliance responsibility for AWS cloud
Inherit Control – AWS maintains these and customers might not have any control over these, few examples here of Physical and Environmental controls that can be considered for the understanding purpose here
- Physical Data Center security including campus or parking lots etc
- Environmental control like HVAC etc.
Shared Control – Responsibility distributed among cloud provider and customer, let’s see a few examples to understand these.
- Patch management – AWS is responsible for patch infrastructure, where a customer patches guest OS or applications deployed into the AWS cloud.
- Configuration management – AWS is responsible to maintain the necessary configuration for AWS Global infrastructure, where securing DB, Applications or Guest Operating System responsibility lies on customer’s shoulders
- Awareness Session & Skill build training – AWS to ensure their own employees or contractors, Where customers provide the same thing for their employees or any third-party vendors (If applicable). User awareness is a must to fight against phishing or social engineering tricks.
Solely customer-specific control – Customers own this piece solely and need to ensure necessary controls are in place to strengthen the security posture
- Service or communication protection
- Zone data security within a specific environment
Key benefits of the Shared Responsibility Model
Let’s summarize here a few key points as the benefits or learnings from the shared responsibility model for security.
You may find this relevant or might already experience these key benefits if associated with such cloud services offering for your organization/enterprise
- Leveraging provider expertise for enhanced security posture from their managed security services offering and innovation from their research & development outcome
- Your provider takes most of the costly compliance and regulatory burden off your plate
- Overall, there are fewer security incidents in the public cloud compared to the traditional data centre (on-perm) model due to shared security responsibility.
- Advanced threat monitoring/managed security services in a reliable & cost-effective way.
Conclusion –
Finally, it’s time to conclude. A clear understanding of this shared responsibility enables you to define your roadmap for securing your AWS ecosystem.
I hope this article gives you a complete overview of AWS shared responsibility model for maintaining security & compliance. It gives a clear picture of which things AWS needs to focus on or which customers need to focus on from a security standpoint.
Security & compliance responsibility is shared among the cloud provider (i.e. AWS) and consumer (i.e., You or your organization). Both of them are liable/responsible on it to ensure CIA (Confidentiality, Integrity, Availability) for your AWS cloud environment.
Wrapping up today’s article here will soon come up with another interesting topic, that you may find relevant in terms of AWS Security or cloud security.
Enjoyed the content?
Subscribe to our newsletter below to get awesome AWS learning materials delivered straight to your inbox.
If you liked reading my post, you can motivate me by-
- Adding a comment below on what you liked and what can be improved.
- Follow us on Facebook, Twitter, LinkedIn, and Instagram
- Share this post with your friends and colleagues.
