When you spin up an EC2 instance in your AWS account, you are able to choose a region from all the available geographic regions AWS offers to have your instance come up in. There is no need to order a server or rack, stack it, secure it in the cage at the data center, and so on. Once that server spins up, it will have a base operating system and network connectivity based on the VPC settings that you have chosen or configured.
Once your instance is up and running, whether for minutes, hours, months, or even years, it is your responsibility as the customer to update (or remove) any packages that do not meet your security baseline. Suppose you add additional users; this falls under the Identity and Access Management category. In that case, it is up to you to ensure that these users conform to your organization’s password or secure key policy. Similarly, if you decide to install any additional applications, keeping them up to date when security patches become available (either through the vendor or from the developers) is again your responsibility.
As you connect to this EC2 instance, creating a secure connection via SSL or TLS is up to you. Securing the data in transit to and from the instance falls under the customer responsibilities of the shared model for infrastructure security.
In summary, when working with services that fall within the infrastructure shared responsibility model, AWS is responsible for the security of the cloud, which includes everything in the hypervisor stack and levels below it. The customer is then responsible for security in the cloud, which starts from the operating system stack and levels above it.
Having an understanding of each of these models will help you define a more robust security strategy and strengthen your security posture across your AWS account. Fully understanding what you are responsible for and what AWS is responsible for will help ensure that you are not left open to any unexpected vulnerabilities.
Although infrastructure services constitute a large part of cloud computing (especially when it comes to AWS), the way the security responsibilities are handled for the customer and the cloud provider is not the same as that of packaged services. In the next section, you will learn about some of those differences of the shared responsibility model for container services.
The second model this chapter will cover is the container model. The word container is frequently used to describe software packages containing code and all associated dependencies that can be run across various compute environments. Examples of standard container technologies are Docker, Podman, and Kubernetes. However, the word container refers to a slightly different concept when used in this context.
The container model focuses on services that reside on top of infrastructure services. This implies that the customer does not have access to some of the infrastructure-level components, such as the operating system. The following are some examples of services in the container model:
Figure 1.4 shows the responsibility model for container services:
Figure 1.4: Shared responsibility model for container services
As is evident from the preceding figure, AWS still maintains the same level of security responsibility as it is retained from the infrastructure model, along with additional responsibilities. Platform, application management, operating system, and network configuration are now the responsibility of AWS in this model.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
