Before you dive into infrastructure protection, first recall a key principle of AWS—the shared responsibility model. Security, along with compliance, is considered a shared responsibility between AWS and the customer. Essentially, AWS is responsible for the security of the cloud and you, the customer, are responsible for the security in the cloud.
The AWS shared responsibility model is represented Figure 5.2:
Figure 5.2: AWS shared responsibility model
AWS secures the infrastructure for supporting the services they provide—that is, both the facilities (data centers) and the hardware equipment running in these facilities, whether it is compute, storage, or networking. The customer is in charge of securing their AWS resources on top of what AWS already does. This naturally varies from service to service.
If you are using an Infrastructure-as-a-Service (IaaS) layer service such as Amazon EC2, you must ensure that the virtual machines (VMs) you create on top of it are secure, that is, make sure the operating system (OS) is patched to the latest level of security. The same goes for any software package or library installed on it and for protecting access to these VMs both from a networking perspective and from an identity and access control perspective. If you use an AWS service where the infrastructure is abstracted away and managed by AWS—for instance, Amazon S3—you obviously don’t have to patch the OS or the software since AWS manages such tasks, but you still have to ensure the protection of the resources deployed with that service. For instance, in the case of Amazon S3, you must ensure that access to the objects you store in your S3 buckets matches your security guidelines and compliance requirements.
Essentially, you are fully responsible for the security of the resources you deploy on AWS. This may seem daunting at first to some but really, it is not—remember that you have sole and full control of your own resources.
Keep in mind that whichever resource you plan to deploy on AWS, you must make sure it operates in a safe environment. You need to take care of the management and operational aspects that support the life cycle of that resource, which can mean quite different things depending on the type of the resource and the AWS services used.
Therefore, for any new solution that you design on AWS, the first thing that you need to do is to have a clear understanding of the security and compliance requirements that apply. Why is this important? These requirements primarily dictate the security measures that you will put in place. You can, for instance, set up the most elaborate protection system against distributed denial-of-service (DDoS) attacks from the outside world, but it is going to be of little use if you are designing a solution for internal use only. The following are a few questions you might want to answer before taking any measures to protect your infrastructure:
This is by no means an exhaustive list of questions but only serves to illustrate some of the key aspects that will guide you to having a thorough understanding of your solution’s security and compliance requirements. Once you have a better view of your solution’s security scope, you can see how these requirements can be met on AWS.
The second aspect that you want to consider is the AWS corpus of best practices concerning security. For this, the starting point and essential guidebook for any solutions architect is the Well-Architected Framework security pillar. It contains a wealth of recommendations to help you set up a secure foundation on AWS. There are various additional sources out there, including blogs and whitepapers, so please check the Further reading section at the end of this chapter for the links to resources.
Your environment security is, overall, as strong as your weakest system. But where do you start?
Nowadays, the zero-trust security model has is becoming increasingly popular. In the traditional network security model, corporate perimeters were protected and every system inside the corporate perimeter was considered to be trusted, while every system outside that perimeter was considered untrusted. The zero-trust model takes the approach that no system should be trusted based solely on its network location.
The zero-trust model is not new, but its recent popularity is mostly due to the fact that it is particularly adapted to a cloud or hybrid IT environment. In such an environment, you naturally find IT systems that do not follow the traditional concept of a corporate perimeter as well as modern architectural models—such as microservices architecture or event-driven architecture—that involve numerous interactions between IT systems belonging to separate network perimeters.
The zero-trust model thus advocates a dynamic approach to security, whereby individual interactions between systems are authorized based on the context of the session in which they happen, leveraging fine-grained authentication and authorization mechanisms.
Therefore, your primary objective in a zero-trust architecture is to prevent any unauthorized access from happening. The following subsection dives deeper into what you can do to achieve this objective on AWS.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
