Configure networks for FedRAMP and DoD in Google Cloud

Last reviewed 2024-02-28 UTC

This document provides configuration guidance to help you to securely deploy Google Cloud networking policies in the United States (US) that comply with the design requirements for FedRAMP High and Department of Defense (DoD) Impact Level 2 (IL2), Impact Level 4 (IL4), and Impact Level 5 (IL5). This document is intended for solution architects, network engineers, and security engineers who design and deploy networking solutions on Google Cloud. The following diagram shows a landing zone network design for highly regulated workloads.

Landing zone network design for highly regulated workloads.

Architecture

The network design shown in the preceding diagram is aligned with the US compliance framework requirements for FedRAMP High, and DoD IL2, IL4, and IL5. This architecture includes the following components, which are described in greater detail later in this document:

  • Virtual Private Cloud (VPC): These VPCs are global, however, you must only create subnets in US regions.
  • Regional load balancers: These load balancers are regional, not global. They only support US deployments. Note that the use of external load balancers than can be directly accessed by the internet might need extra validation with DISA to assure DoD authorization for IL4 and IL5.
  • Google Cloud Armor security policies: These policies can be used with supported regional load balancer security policies.
  • Private Service Connect, Private Google Access (PGA), and Private service access (PSA): These options enable private connectivity to Google managed services within the region. You must enable private access to Google managed services and APIs within the region through the relevant option for your use case.
  • Third-party services: For third-party producer-consumer services, you must ensure that both the producer service and the data that is in transit meet your compliance requirements.
  • Non-prod: Provision other environments such as non-prod, testing, and quality assurance (QA) in accordance with your organization's VPC strategy.

Use case

Assured Workloads is a compliance framework that can help to provide the security controls that you need to support regulatory requirements for FedRAMP High, and DoD IL2, IL4, and IL5. After you deploy with Assured Workloads, you are responsible for setting up compliant and secure networking policies. For other compliance use cases, see Hosting FedRAMP Moderate and High Workloads on Google Cloud in the FedRAMP documentation.

The scope of this guidance is limited to networking components. You must configure workloads in accordance with the shared responsibility model, FedRAMP Customer Responsibility Matrix, in-scope Google Cloud services, FedRAMP, and Assured Workloads guidelines. For more information about how to meet compliance requirements for other Google Cloud services, see the Compliance resource center.

The services referenced in this document are for example purposes only. You must review the services that are in scope for compliance programs to assure the correct compliance level requirements for your workload.

Out of scope products

The following services don't meet FedRAMP High, or DoD IL2, IL4, and IL5 jurisdictional boundary compliance requirements:

  • Global External Application Load Balancer
  • Global Google Cloud Armor
  • Global External Proxy Load Balancer

We recommend that you discuss the risk of using these services in your network with your Google support team before you begin to make your network design.

Design Considerations

This section describes design considerations for which the configurations that are described in this document are an appropriate choice.

Use Assured Workloads

You must use Assured Workloads to meet compliance-based requirements on Google Cloud for regulations that have data sovereignty and residency requirements, such as FedRAMP High, and DoD IL4 and IL5. To understand if these principles apply to your compliance program on Google Cloud, we recommend that you review Overview of Assured Workloads in the early stages of your design phase. You are responsible for configuring your own network and IAM policies.

You must configure an Assured Workloads folder and set the appropriate compliance program. In this case, either set the appropriate compliance program to FedRAMP High or IL2, IL4, IL5. This folder provides a regulatory boundary within an organization to identify regulated data types. By default, any project under this folder will inherit the security and compliance guardrails set at the Assured Workloads folder level. Assured Workloads restricts the regions that you can select for those resources based on the compliance program that you chose using the resource restriction Organization Policy Service.

Regional alignment

You must use one or more of the US Google regions to support the compliance programs in scope for this guidance. Note that FedRAMP High and DoD IL4 and IL5 have a general requirement that data be kept within a US geographical boundary. To learn which regions you can add, see Assured Workloads locations.

Product-level compliance

It's your responsibility to confirm that a product or service supports the appropriate data sovereignty and residency requirements for your use case. When you purchase or use your target compliance program, you must also follow these guidelines for each product that you use to meet applicable compliance requirements. Assured Workloads sets up a modifiable Organization Policy with a point in time resource usage restriction policy that reflects the services that are in compliance with the chosen compliance framework.

Deployment

To help you to meet your compliance requirements, we recommend that you follow the guidelines in this section for individual networking services.

Virtual Private Cloud network configurations

You must make the following Virtual Private Cloud configurations:

Private Service Connect configurations

Private Service Connect is a capability of Google Cloud networking that lets consumers access managed services privately from inside their VPC network.

Both Private Service Connect types (Private Service Connect endpoints and Private Service Connect backends) support the controls that are described in this document when configured with regional load balancers. We recommend that you apply the configuration details described in the following table:

Private Service Connect Type Supported load balancers Compliance status
Private Service Connect endpoints for Google APIs Not applicable Not supported
Private Service Connect backends for Google APIs
  • Global External Application Load Balancer
  • Regional External proxy Network Load Balancer or Internal Application Load Balancer
  • Regional External proxy Network Load Balancer
Compliant when used with either of the following regional load balancers:
  • Regional external or Internal Application Load Balancer
  • Regional External proxy Network Load Balancer
Private Service Connect endpoints for published services
  • Regional Internal Application Load Balancer
  • Regional Internal passthrough Network Load Balancer
  • Regional External proxy Network Load Balancer
Compliant
Private Service Connect backends for published services
  • Global External Application Load Balancer
  • Regional external or Internal Application Load Balancer
  • Regional External proxy Network Load Balancer
  • Regional Internal passthrough Network Load Balancer
Compliant when used with the following regional load balancer:
  • Regional external or Internal Application Load Balancer
  • Regional External proxy Network Load Balancer
  • Regional Internal passthrough Network Load Balancer

Packet Mirroring

Packet Mirroring is a VPC feature that you can use to help you to maintain compliance. Packet Mirroring captures all your traffic and packet data, including payloads and headers, and forwards it to target collectors for analysis. Packet Mirroring inherits VPC compliance status.

Cloud Load Balancing

Google Cloud offers different types of load balancers, as described in Application Load Balancer overview. For this architecture, you must use regional load balancers.

Cloud DNS

You can use Cloud DNS to help you to meet your compliance requirements. Cloud DNS is a managed DNS service in Google Cloud which supports private forwarding zones, peering zones, reverse lookup zones, and DNS server policies. Cloud DNS public zones don't comply with FedRAMP High, and DoD IL2, IL4, or IL5 controls.

Cloud Router

Cloud Router is a regional product that you can configure for Cloud VPN, Cloud Interconnect, and Cloud NAT. You must only configure Cloud Router in US regions. When you create or edit a VPC network, you can set the dynamic routing mode to be regional or global. If you enable global routing mode, you must configure custom advertised mode to only include US networks.

Cloud NAT

Cloud NAT is a regional managed NAT product that you can use to enable outbound access to the internet for private resources with no external IP addresses. You must only configure Cloud NAT gateway in US regions that have the associated Cloud Router component.

Cloud VPN

You must use Cloud VPN endpoints located within the US. Ensure that your VPN gateway is configured only for use in the correct US region, as described in Regional alignment. We recommend that you use HA VPN type for Cloud VPN. For encryption, you must only use FIPS 140-2 compliant ciphers to create certificates and to configure your IP address security. To learn more about supported ciphers in Cloud VPN, see Supported IKE ciphers. For guidance about how to select a cipher that conforms to FIPS 140-2 standards, see FIPS 140-2 Validated. After you make a configuration, there is no way to change an existing cipher in Google Cloud. Ensure that you configure the same cipher on your third-party appliance that you use with Cloud VPN.

Google Cloud Armor

Google Cloud Armor is a DDoS mitigation and application protection service. It helps to protect against DDoS attacks on Google Cloud customer deployments with workloads that are exposed to the internet. Google Cloud Armor for Regional external Application Load Balancer is designed to provide the same protection and capabilities for regional load balanced workloads. Because Google Cloud Armor web-application firewalls (WAF) use a regional scope, your configurations and traffic reside in the region where the resources are created. You must create regional backend security policies and attach them to backend services which are regionally scoped. The new regional security policies can only be applied to regionally scoped backend services in the same region, and are stored, evaluated, and enforced in-region. Google Cloud Armor for Network Load Balancers and VMs extends Google Cloud Armor DDoS protection for workloads exposed to the internet through a Network Load Balancer (or protocol forwarding) forwarding rule, or through a VM that's directly exposed through a public IP. To enable this protection, you must configure advanced network DDoS protection.

Dedicated Interconnect

To use Dedicated Interconnect, your network must physically connect to Google's network in a supported colocation facility. The facility provider supplies a 10G or 100G circuit between your network and a Google Edge point-of-presence. You must only use Cloud Interconnect in colocation facilities within the US that serve Google Cloud US regions.

When you use Partner Cloud Interconnect, you must consult with the service provider to confirm that their locations are within the US and connected to one of the Google Cloud US locations listed later in this section.

By default, the traffic sent over Cloud Interconnect is unencrypted. If you want to encrypt traffic sent over Cloud Interconnect then you can configure VPN over Cloud Interconnect or MACsec.

For the full list of supported regions and co-locations, see the following table:

Region Location Facility name Facility
us-east4 (Virginia) Ashburn iad-zone1-1 Equinix Ashburn (DC1-DC11)
Ashburn iad-zone2-1 Equinix Ashburn (DC1-DC11)
Ashburn iad-zone1-5467 CoreSite - Reston (VA3)
Ashburn iad-zone2-5467 CoreSite - Reston (VA3)
us-east5 (Columbus) Columbus cmh-zone1-2377 Cologix COL1
Columbus cmh-zone2-2377 Cologix COL1
us-central1 (Iowa) Council Bluffs cbf-zone1-575 Nebraska data centers (1623 Farnam)
Council Bluffs cbf-zone2-575 Nebraska data centers (1623 Farnam)
us-south1 (Dallas) Dallas dfw-zone1-4 Equinix Dallas (DA1)
Dallas dfw-zone2-4 Equinix Dallas (DA1)
us-west1 (Oregon) Portland pdx-zone1-1922 EdgeConneX Portland (EDCPOR01)
Portland pdx-zone2-1922 EdgeConneX Portland (EDCPOR01)
us-west2 (Los Angeles) Los Angeles lax-zone1-8 Equinix Los Angeles (LA1)
Los Angeles lax-zone2-8 Equinix Los Angeles (LA1)
Los Angeles lax-zone1-19 CoreSite - LA1 - One Wilshire
Los Angeles lax-zone2-19 CoreSite - LA1 - One Wilshire
Los Angeles lax-zone1-403 Digital Realty LAX (600 West 7th)
Los Angeles lax-zone2-403 Digital Realty LAX (600 West 7th)
Los Angeles lax-zone1-333 Equinix LA3/LA4 - Los Angeles, El Segundo
Los Angeles lax-zone2-333 Equinix LA3/LA4 - Los Angeles, El Segundo
us-west3 (Salt Lake City) Salt Lake City slc-zone1-99001 Aligned Salt Lake (SLC-01)
Salt Lake City slc-zone2-99001 Aligned Salt Lake (SLC-01)
us-west4 (Las Vegas) Las Vegas las-zone1-770 Switch Las Vegas
Las Vegas las-zone2-770 Switch Las Vegas

What's next

Contributors

Authors:

Other contributors: