The principle of “shared responsibility†that governs how we conduct ourselves in a society, also applies to how organizations run and secure their IT estates. With most organizations using cloud services to store, secure, and structure their data, we take a look at how the responsibility of securing stored data and applications on Amazon EC2 is shared between AWS and customers, be it in the case of IaaS or PaaS services or containers or abstracted services.
When you think about it, much of life incorporates the principle of “shared responsibility.†If you live in a subdivision, you are responsible for maintaining your home and property. In contrast, the homeowners association is responsible for maintaining the community’s front entrance and the community pool if one exists. If you live in a condominium, you are responsible for repairs involving your kitchen appliances or internal plumbing, while the building association takes on repairs to the roof and building structure. If you live in an apartment, the landlord is responsible for nearly all repairs and maintenance.Â
Other examples of shared responsibility are present in healthcare and security. While the surgeon is responsible for the operation, you are responsible for attending your regular physical therapy sessions during the recovery period. If you subscribe to a home security service, you are still responsible for locking your doors and enabling the alarm when you leave.
Multi-tenancy and the Cloud
We can apply the same analogy when it comes to securing your IT estate. Hosting and maintaining your own exclusive data center is much like being a homeowner. You are pretty much responsible for everything. When it comes to the cloud, however, that’s where things become a little more complicated. Cloud computing involves tenancy. Cloud service customers are tenants in the same manner as the tenants who rent a multi-unit apartment. In multi-tenant cloud computing architectures, cloud computing customers share a pool of computing resources. While they may share the same infrastructure, they still operate in isolation, ensuring that the data of each customer is secure.
Amazon Web Services (AWS) is the largest cloud computing vendor in the world. The building block of its cloud computing service is the Amazon Elastic Compute Cloud service (Amazon EC2) that provides scalable computing capacity to its customers. EC2 provides three tenancy offerings:
- Shared instances in which multiple AWS accounts share the same physical hardware
- Dedicated Instance in which your instance runs on a physical server with EC2 instance capacity
- Dedicated Host in which an instance runs on a physical server that is fully dedicated to the customer’s use
There are several advantages of hosting your assets in the cloud. One of them is the low-cost access to advanced enterprise security equipment and services that would be impossible for many SMBs if they were to purchase such solutions themselves. However, just as the home security monitoring company cannot take on the responsibility of ensuring that you locked your doors at night, a cloud provider can’t take on the burden of securing every layer of the OSI model for their customers. This is where shared responsibility comes into play. The only point of contention is the exact demarcation point that separates accountability for each party. In the case of AWS, that depends on which EC2 tenant option you choose.
Learn More: Top 10 Cloud Security Challenges to Overcome in 2021
The Level of Abstraction
The AWS shared responsibility model defines the security responsibilities for both AWS and end-users. In some cases, the lines of responsibility are well defined. For instance, customers are responsible for the encryption and integrity of their data and must manage their own client-side data encryption. They can do this either by using their encryption key system or utilizing an AWS-managed encryption key. Customers are also responsible for implementing identity and access management and using file system encryption systems to protect customer data at rest.
For example, an ecommerce company has to secure its customers’ identities and accounts to protect their personal information. It is the customer’s responsibility to assign access privileges for trusted users to the company’s digital assets and to assign access control lists to restrict public access to designated areas of the IT estate.
On the other hand, AWS is responsible for securing the hardware that provides the regional and global infrastructure of AWS. It is the responsibility of AWS to update the firmware of all physical servers, switches, routers, firewalls, storage arrays, etc. The demarcation point is apparent when it comes to cybersecurity hygiene and training. While AWS must enforce cloud security best practices when it comes to its support staff, AWS customers must embrace the responsibility of training their employees on matters of security.
Despite these well-established practices in place, people still wonder who is responsible for patching server operating systems and applications? At what point in the network pipeline does the responsibility of security network traffic pass on from AWS to its customers? Well, it depends on the services that the customer is utilizing. A given service type is associated with an assigned level of architectural abstraction. As a general rule, the responsibility of AWS increases as the level of abstraction increases. In other words, the customer’s security responsibility is determined by the services the customer uses.
The Abstract Levels of IaaS vs PaaS
For customers who take up an Infrastructure as a Service (IaaS) subscription, AWS is only abstracting the server. This may be a dedicated bare metal server or a virtual host server. For a bare metal server, AWS abstracts and maintains the server hardware, while the customer is in charge of protecting the system’s operating system. In the case of a virtual machine, AWS takes on the task of performing all security configurations regarding the virtual host server and its internal operating system, while customers are responsible for patching the virtual machine’s guest operating system as well as all hosted applications. As a simplistic rule, AWS takes on the task of securing the physical or host infrastructure so that customers can focus on securing software or virtual environments.
The abstraction level moves up the ladder for those customers that acquire a Platform as a Service (PaaS) plan. That’s because AWS abstracts the operating system for PaaS subscriptions. This means that AWS is responsible for patching the server operating system and the virtual machine itself. The customer is only responsible for patching its installed applications.Â
Learn More: Maximizing Cloud Security With a Shared Responsibility Model
Containers and Abstracted Services
AWS abstracts even more in the case of containers and abstracted services. For container customers, AWS abstracts the server operating system and thus assumes the responsibility of securing it. The customer is only responsible for the application hosted within the container. For abstracted services, AWS takes on an even more significant security role as nearly everything gets abstracted.
Conclusion
In the end, the AWS shared responsibility model is beneficial to both the company and its customers. It provides assurances to AWS and its customers that neither one is solely responsible for securing every aspect of the multi-tenant IT stack, but both have well-defined roles.Â
Did you enjoy reading this article? Comment below or let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d love to hear from you!