How to implement CNAP for federal and defense customers in AWS

Federal and U.S. Department of Defense (DoD) organizations often have requirements to establish a secure, scalable, multi-account environment that implements the security baseline compliant with US federal government standards. Amazon Web Services (AWS) customers can comply with these requirements by deploying AWS solutions like the Landing Zone Accelerator in AWS GovCloud (US). AWS GovCloud (US) helps meet compliance mandates, safeguard sensitive data, and protect accounts and workloads. AWS solutions built in AWS GovCloud (US) inherit AWS GovCloud (US) compliance accreditations, which fulfill the Defense Information Systems Agency (DISA) Cloud Computing Security Requirements Guide (CC SRG) for impact Level (IL) 4 and IL 5 workload requirements.

In July 2021, the DoD released a cloud native access point (CNAP) reference design that follows zero trust architecture (ZTA) principles and provides a new approach to access mission owner (MO) applications. The DoD’s reference design discusses four core capabilities of CNAP: authenticated and authorized entities (C1), authorized ingress (C2), authorized egress (C3), and security monitoring and compliance enforcement (C4). These capabilities provide guidelines for organizations and agencies to securely publish their applications to the Defense Information System Network (DISN) and internet end users.

In this blog post, we walk through how to establish the C2 component via a virtual internet access point (vIAP) with AWS for federal and defense customers. This walkthrough assumes the customer has already implemented the C1 component. We present two reference architectures using AWS Cloud native services, which can help you achieve the C2 component of the CNAP reference design in a multi-account AWS environment. The proposed architectures can reduce operational cost and management overhead, while improving the accessibility, resiliency, and security of the MO applications.

Solution overview

To implement CNAP on AWS, you need the following:

Multi-account AWS environment.
Connection to on-premises with a boundary cloud access point (BCAP) for DISN or AWS Direct Connect in a dedicated transit account.
Dedicated account that can host an application, and labeled as the mission owner account.

The proposed solution uses the following AWS services in your multi-account AWS environment:

Amazon Virtual Private Cloud (Amazon VPC)
AWS Network Firewall
Application Load Balancer (ALB)
AWS PrivateLink
Network Load Balancer (NLB)
Internet Gateway (IGW)

Deployment models

The following two proposed models can help you achieve a true cloud native environment. The right model for you depends on your specific rules and regulations.

1. Centralized internet and on-premise ingress model

This solution design focuses on allowing both on-premise and internet inbound traffic from the one centralized transit account. To separate on-premise and internet traffic, we create an additional Amazon VPC in the transit account. The central BCAP ingress VPC is used for on-premise ingress traffic while the central internet ingress VPC is used for internet ingress traffic. This model provides a centralized point of control for all ingress traffic.

Figure 1. Overview of centralized internet and on-premise ingress model.

Figure 1 illustrates a centralized ingress for internet and on-premise traffic using IGW and a virtual private gateway (VPG) respectively for all MO applications. You can read more about designing your firewall deployment for internet ingress traffic flows here. The authorized internet and on-premise ingress traffic is separated by creating two Amazon VPCs in the transit account. Individual Amazon VPCs can reduce blast radius through isolation. Ingress traffic is inspected by Network Firewall or by a next generation firewall. The ALB hosts the MO application which integrates with AWS WAF. The MO account runs NLB to power PrivateLink. Using PrivateLink, connections can only be initiated in one direction, from end user to the application. MO applications cannot initiate traffic to the internet.

Figure 2. Detailed view of one Availability Zone (AZ) and the Amazon VPC, route tables, and services. The diagram indicates internet ingress and DISN ingress traffic with a legend.

Figure 2 provides a detailed view of the architecture and shows the traffic flow for authorized internet ingress traffic:

A new connection towards the application is initiated from the internet and directed towards the IGW of the transit account.
Amazon VPC ingress routing directs all traffic from the IGW to the Network Firewall using Edge Association.
The Network Firewall inspects the traffic based on the pre-defined firewall policies and either allows or denies the traffic.
The ALB hosts the MO application. The ALB target groups are endpoints of PrivateLink. The endpoints are powered by NLB which is hosted in the MO Account.
PrivateLink forwards the traffic to the MO account using the AWS network backbone. The traffic does not leave the AWS boundary.
The NLB forwards traffic to the instances that host the application.

The on-premise traffic follows almost the same path with a slight difference in the entry into the AWS boundary.

A new connection towards the application is initiated from on-premises and directed towards Direct Connect.
The Direct Connect gateway forwards the traffic to the VPG through Direct Connect. The routing is managed on premise.
The VPG forwards traffic to the next generation firewall through an internal Elastic Load Balancer.
The next generation firewall inspects the traffic based on the pre-defined firewall policies and either allows or denies the traffic.
PrivateLink forwards the traffic to the MO account using the AWS network backbone. The traffic does not leave the AWS boundary.
The NLB forwards traffic to the instances which host the application.

2. Distributed internet ingress and centralized BCAP

This solution design focuses on allowing on-premise inbound traffic from the transit account and distributes inbound internet traffic to all MO accounts. To separate on-premise and internet traffic, create an additional Amazon VPC in the MO account. The MO distributed internet ingress Amazon VPC is used for internet ingress traffic. This model distributes point-of-control for all internet ingress traffic to individual mission owners.

Figure 3. Overview of distributed internet and centralized on-premise ingress model.

Figure 3 illustrates the distributed model. In this model, the MO operates an IGW for the internet ingress traffic towards the application. The on-premise traffic is centralized in the transit account using Direct Connect. The distributed internet ingress Amazon VPC has Network Firewall and ALB. The remaining architecture is similar to the centralized model.

Figure 4. Detailed view of one AZ and the Amazon VPC, route tables, and services. The diagram indicates internet ingress and DISN ingress traffic with a legend.

Figure 4 provides a detailed view of the architecture and shows the traffic flow for authorized internet ingress traffic:

A new connection towards the application is initiated from the internet and directed towards the IGW of the MO account.
Amazon VPC ingress routing directs all traffic from the IGW to the Network Firewall using Edge Association.
The Network Firewall inspects the traffic based on the pre-defined firewall policies and either allows or denies the traffic.
The ALB hosts the application. The ALB target groups are endpoints of PrivateLink. The endpoints are powered by NLB which is hosted in the MO application VPC.
PrivateLink forwards the traffic between the two VPCs of the MO account using AWS network backbone. The traffic does not leave the AWS boundary.
The NLB forwards traffic to the instances which host the application.

The on-premise traffic follows the similar path as that of the central BCAP ingress Amazon VPC described previously.

Considerations

Key considerations with the two proposed CNAP models are:

The vIAP (C2) component of CNAP includes multiple sub-components. Customers can use AWS services with third party tools to satisfy the sub-component requirements.
The assumption in both the traffic flows is that the user who initiates the connection from the internet or on-premises is authenticated and authorized before it reaches the AWS boundary.
All services are shown in one Availability Zone (AZ) to reduce complexity, but are scalable and highly available.
Network Firewall endpoints require a dedicated subnet per AZ for each endpoint.
Traffic between NLB and backends of instance target type do not follow Amazon VPC route tables routes. If you want to inspect traffic between NLB and backends, use an IP target type.
Billing considerations are required for the distributed model for the Network Firewall.
You can use Firewall Manager to centrally manage security policies for the Network Firewall within AWS Organizations.
Network Firewall does not currently support deep packet inspection for encrypted traffic. Third party firewall appliances with Gateway Load Balancer can be used for deep packet inspection for encrypted traffic. For using alternative solutions, please refer to the Network Firewall FAQs.
Services used in the architecture should be checked for their current compliance status on the AWS compliance website for Federal Risk and Authorization Management Program (FedRAMP) and DoD Cloud Computing Security Requirements Guide (CC SRG).

Conclusion

The models discussed in this blog post allow you to adapt the newer CNAP guidelines and modernize your AWS environment. These models extend the access of federal and DoD applications for end users to increase availability and accessibility. These proposed AWS Cloud-native architectures can help you improve business agility, scalability, availability, utilization, and cost savings by not needing long-term contracts or up-front commitments.

We recommend you review the CNAP reference architecture document for further guidance. This blog post is not designed to ensure compliance with a CNAP standard. You are responsible for making your own assessment of whether the use of best practices meets the legal and regulatory compliance requirements.

Learn more about how AWS supports federal government customers and how AWS supports defense customers, or contact us directly for more information.

AWS Public Sector Blog