SEC05-BP02 Control traffic flow within your network layers
Within the layers of your network, use further segmentation to restrict traffic only to the flows necessary for each workload. First, focus on controlling traffic between the internet or other external systems to a workload and your environment (north-south traffic). Afterwards, look at flows between different components and systems (east-west traffic).
Desired outcome: You permit only the network flows necessary for the components of your workloads to communicate with each other and their clients and any other services they depend on. Your design factors in considerations such as public compared to private ingress and egress, data classification, regional regulations, and protocol requirements. Wherever possible, you favor point-to-point flows over network peering as part of a principle of least privilege design.
Common anti-patterns:
-
You take a perimeter-based approach to network security and only control traffic flow at the boundary of your network layers.
-
You assume all traffic within a network layer is authenticated and authorized.
-
You apply controls for either your ingress traffic or your egress traffic, but not both.
-
You rely solely on your workload components and network controls to authenticate and authorize traffic.
Benefits of establishing this best practice: This practice helps reduce the risk of unauthorized movement within your network and adds an extra layer of authorization to your workloads. By performing traffic flow control, you can restrict the scope of impact of a security incident and speed up detection and response.
Level of risk exposed if this best practice is not established: High
Implementation guidance
While network layers help establish the boundaries around
components of your workload that serve a similar function, data
sensitivity level, and behavior, you can create a much
finer-grained level of traffic control by using techniques to
further segment components within these layers that follows the
principle of least privilege. Within AWS, network layers are
primarily defined using subnets according to IP address ranges
within an Amazon VPC. Layers can also be defined using different
VPCs, such as for grouping microservice environments by business
domain. When using multiple VPCs, mediate routing using an AWS Transit Gateway
Understand and inventory the data flow and communication requirements of your workloads in terms of connection-initiating parties, ports, protocols, and network layers. Evaluate the protocols available for establishing connections and transmitting data to select ones that achieve your protection requirements (for example, HTTPS rather than HTTP). Capture these requirements at both the boundaries of your networks and within each layer. Once these requirements are identified, explore options to only allow the required traffic to flow at each connection point. A good starting point is to use security groups within your VPC, as they can be attached to resources that uses an Elastic Network Interface (ENI), such Amazon EC2 instances, Amazon ECS tasks, Amazon EKS pods, or Amazon RDS databases. Unlike a Layer 4 firewall, a security group can have a rule that allows traffic from another security group by its identifier, minimizing updates as resources within the group change over time. You can also filter traffic using both inbound and outbound rules using security groups.
When traffic moves between VPCs, it's common to use VPC peering
for simple routing or the AWS Transit Gateway for complex routing.
With these approaches, you facilitate traffic flows between the
range of IP addresses of both the source and destination networks.
However, if your workload only requires traffic flows between
specific components in different VPCs, consider using a
point-to-point connection using
AWS PrivateLink
While security groups and PrivateLink help control the flow between the components of your workloads, another major consideration is how to control which DNS domains your resources are allowed to access (if any). Depending on the DHCP configuration of your VPCs, you can consider two different AWS services for this purpose. Most customers use the default Route 53 Resolver DNS service (also called Amazon DNS server or AmazonProvidedDNS) available to VPCs at the +2 address of its CIDR range. With this approach, you can create DNS Firewall rules and associate them to your VPC that determine what actions to take for the domain lists you supply.
If you are not using the Route 53 Resolver, or if you want to complement the Resolver with deeper inspection and flow control capabilities beyond domain filtering, consider deploying an AWS Network Firewall. This service inspects individual packets using either stateless or stateful rules to determine whether to deny or allow the traffic. You can take a similar approach for filtering inbound web traffic to your public endpoints using AWS WAF. For further guidance on these services, see SEC05-BP03 Implement inspection-based protection.
Implementation steps
-
Identify the required data flows between the components of your workloads.
-
Apply multiple controls with a defense-in-depth approach for both inbound and outbound traffic, including the use of security groups, and route tables.
-
Use firewalls to define fine-grained control over network traffic in, out, and across your VPCs, such as the Route 53 Resolver DNS Firewall, AWS Network Firewall, and AWS WAF. Consider using the AWS Firewall Manager
for centrally configuring and managing your firewall rules across your organization.
Resources
Related best practices:
Related documents:
Related tools:
Related videos:
Related examples:
