The ambiguous assignment of security responsibilities—who does what—is one of a company’s top concerns regarding cloud security. A company’s cloud security posture may easily develop blind spots in a dynamic, distributed cloud environment if it doesn’t know who is accountable for the tasks that must be completed to maintain security and compliance. According to a survey, 82% of organizations experienced a cloud security issue because they were unaware of the shared security responsibilities in cloud computing.
Amazon Web Services (AWS) has created the AWS Shared Responsibility Model to delineate roles and lessen the cost of cloud security. The AWS Shared Responsibility Model essentially outlines what the user is accountable for safeguarding in the cloud and what AWS is liable for protecting.
Responsibilities of AWS cloud vendor and user
AWS cloud vendor: AWS is in charge of safeguarding the infrastructure that powers all of the services provided by AWS Cloud. This framework comprises the components of hardware, software, networking, and amenities that drive AWS Cloud services.
AWS Cloud user: The level of customer accounts will depend on their choice of AWS cloud service. To put this in perspective, let’s take the example of Amazon Elastic Compute Cloud (EC2). EC2 falls under the Infrastructure as a service (IaaS) which necessitates the client to handle security setup as and when required, along with administrative chores. Upon deploying an Amazon EC2, the customers will oversee the guest OS (such as updates and security fixes), a situation-specific configuration of application software or utilities and setting up the firewall provided by AWS on each instance.
Under services like Amazon S3 and Amazon DynamoDB, the management and handling of systems, OS and infrastructure layer come under AWS’s purview, and users must use endpoints to store and retrieve information. Users are in charge of asset identification, data management (encryption settings included) along with the utilization of IAM tools to request proper rights.
Implementing AWS Shared Responsibility Model
It will be easier for you to comprehend your obligations and those of AWS if you know the type of services you utilize.
Infrastructure Services
Infrastructure services, or IaaS as referred to in the cloud, essentially give users complete control over computing services, similar to having your own data center. This is because they give you full control over your computing services, including the ability to set up your own operating systems and maintain their security while your app code is running on the AWS platform.
This architecture essentially allows total control of your computing services with no significant differences from your own data center because you have installed and maintained your operating systems to date. This category of services includes EC2 and its ancillary services, such as Elastic Book Store (EBS), Virtual Private Networks (VPNs), and auto-scaling.
As previously stated, AWS is in charge of what is referred to as “the security” of the cloud. This includes the fundamental components of their network, compute, storage, and database offerings and their regions, availability zones, and edge locations.
You are in charge of what gets into the cloud since AWS is responsible for securing and maintaining the fundamental cloud infrastructure. This includes operating system security, network security, firewall setup, client and server-side encryption, network traffic protection, application security, and identity and access management.
In short, adopting infrastructure services puts far more responsibility on you. View Amazon’s graphic comparing the responsibilities of the client and AWS.
Container Services
The container concept is the model we will discuss next. The term “container” is widely used to refer to software packages that include code and all necessary dependencies and may be executed in various computing environments. Docker and Kubernetes are two examples of popular container technologies. However, the word “container” in this context alludes to a slightly different idea.
This paradigm concentrates on services that effectively sit atop infrastructure services. Therefore customers are restricted from certain infrastructure-level elements, such as the operating system.
Even though container services leverage the same infrastructure (like EC2), users are not responsible for managing the platform or OS, for that matter. The container services manage any EC2 instances or other services to handle the workload. Examples of these are Relational Database Service (RDS) and Elastic Beanstalk. Amazon’s PaaS or platform-as-a-service are known as container services.
The security strategy of container services places additional responsibilities on AWS besides the customers’ responsibility for firewall settings and data encryption. As an illustration, if Oracle in RDS is chosen, AWS will be in charge of upgrading Oracle database software, security upkeep of the underlying operating system, and maintenance of the EC2 instance the databases are running on.
Abstract Services
We will now talk about abstract services. The consumer receives a comprehensive service through abstract services, and no effort is required on their end to obtain them. S3 and DynamoDB are two of these services. These solutions belong to software as a service (SaaS). Although customer responsibility is generally much reduced, misconfiguration can still leave you vulnerable to attack.
While infrastructure, operating system, and network and platform security are directly within AWS’s control, businesses must use encryption services and IAM tools properly to protect their data.
Conclusion
Maximizing the overall security of Amazon’s cloud infrastructure is the goal of the AWS shared responsibility concept. Customers and Amazon can both feel more secure if they are informed on how to manage or maintain robust operational measures.
Users feel more confident in Amazon’s ability to meet their security demands because of the joint obligations of shared security, which assures Amazon that they don’t have to manage every security component individually.
When security duties are shared, customers must have a thorough grasp of the dangers involved in placing their faith in a third party. This independence has the potential to impact service prices and quality altogether dramatically.
