You may now be wondering why protecting the network is important even though it was just mentioned that zero-trust concepts recommend not to trust systems based on their location. Now while zero trust advocates not to solely use the location of a system to decide whether it can be trusted or not, it certainly does go against leveraging network security best practices to protect your environments.
Thus, protecting your virtual networks (virtual private clouds (VPCs) or subnets) on AWS is still good practice and a must-do. It is recommended to apply multiple levels of control for both inbound and outbound traffic. This typically includes using subnets, route tables, NFW, web application firewalls (WAFs), security groups (stateful firewalls), and network access control lists (ACLs) (stateless firewalls).
First, you want to layer your virtual networks in such a manner that resources are placed according to their connectivity requirements. A VPC can be split into multiple subnets. Remember that a VPC is a regional construct, while subnets are attached to a single Availability Zone (AZ). Each subnet can have an associated route table that specifies how traffic flows within the subnet. Resources that do not require internet access should be placed in a network without access to or from the internet. So, resources such as a backend system or a database should be placed in a private subnet, such as a subnet without access to or from the internet. As a corollary, resources that need access to or from the internet—for instance, a load balancer—should be placed in a virtual network that can provide connectivity to the internet, in this case, a public subnet.
Further, VPCs and subnets on AWS provide natural means of isolating your AWS resources depending on their business function, your organizational structure, and other factors. Complex organizations will end up with hundreds or even thousands of VPCs and interconnect them by means of an AWS transit gateway (TGW). If they have resources deployed across multiple AWS Regions and require connectivity between VPCs across regions, they will then typically have one TGW per region acting as a regional hub, each peered with one or more other TGWs sitting in other regions. If you are unsure about hub-and-spoke network architectures on AWS, please refer to Chapter 2, Designing Networks for Complex Organizations, for more details.
Similarly, these organizations may require connectivity from AWS back to their on-premises environment and vice versa. Again, the TGW can act as a central hub where you would terminate your VPN or Direct Connect connections.
You can see a diagram outlining this concept in Figure 5.3:
Figure 5.3: Illustration of a centralized setup with TGW and inspection via Network Firewall (NFW)
As per the preceding diagram, you may end up with the TGW acting as a central hub both for East–West communication (inter-VPC) and for North–South connectivity (to/from the internet and to/from on-premises). In a zero-trust security approach, you want to manage and control the traffic flowing through all these connections. First, you may want to place some network firewalls (through AWS NFW or using your own self-managed appliances) on some or all these paths, to control and/or inspect traffic. Second, you want to control routing to decide how traffic flows. With a central hub (TGW) in place, you have routing tables at the level of the hub to control how traffic is routed in and out of the hub, into the VPCs, and toward the internet and/or your on-premises environment.
You also have routing tables in your VPCs and subnets where you can also decide to put additional control depending on your overall network topology. For instance, consider a situation where the central hub (TGW) handles East–West communication, sending inter-VPC traffic for inspection through a set of network firewalls. In this case, you may also want to put specific routing in place at the VPC level for internet-connected VPCs in order to force all ingress and/or egress traffic from and/or to the internet through the same or another set of network firewalls for inspection.
When dealing with layer 7 communication (such as HTTP/S; WebSocket) from the Open Systems Interconnection (OSI) model, you may also want to leverage a specific type of firewall to protect your web application against malicious attacks such as cross-site scripting (XSS), Structured Query Language (SQL) injections, and many more. For that, you can use AWS WAF or your own self-managed WAF if you prefer to. When using AWS WAF, you benefit from its out-of-the-box integration with other AWS services, such as Amazon CloudFront, Application Load Balancer (ALB), Amazon API Gateway, and AWS AppSync, which are all services commonly used for designing web applications on AWS.
However, ideally, you also want to block any malicious attack upfront before it even enters your VPCs to protect your internet-facing applications. For that, AWS provides AWS Shield, which comes in two flavors: Standard and Advanced. AWS Shield Standard is available at no extra cost to all AWS customers. It protects your AWS environment against the most common types of DDoS attacks at International Organization for Standardization (ISO) layers 3 and 4, such as synchronize (SYN)/User Datagram Protocol (UDP) floods and reflection attacks. For enhanced protection, AWS Shield Advanced brings extra features to counter larger and more sophisticated attacks as described below:
Additionally, if you are looking to apply a variety of protections across multiple AWS accounts belonging to your AWS Organizations organization, AWS Firewall Manager can help simplify administration and maintenance tasks. This is particularly welcome for large organizations where managing these resources on an individual account basis could become a daunting task. AWS Firewall Manager helps you pilot protections with AWS WAF, AWS Shield Advanced, AWS NWF, Amazon Route 53 Resolver DNS Firewall, and Amazon VPC security groups. The idea is that you can apply a protection baseline to your entire organization or whenever you deploy a new application in your AWS environment, to make sure it is compliant with your security rules.
Now that you are aware of the critical aspects of network protection, you are ready to dive into the protection of compute resources that you deploy in your AWS environment.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
