Meeting TIC requirements
It is your responsibility to identify and comply with relevant Trusted Internet Connetions (TIC) requirements as guided by your agency. To help you with compliance, here’s guidance for interpreting the TIC reference architecture v2.0 as it concerns cloud.gov.
Formal statement of customer responsibility
The cloud.gov System Security Plan has a formal description of customer responsibility under CA-3 (3).
Use-cases for accessing cloud.gov
The TIC reference architecture includes two use case examples on pages 63 and 64 that are relevant for federal agencies using cloud.gov. Here we describe how to interpret those use cases in the cloud.gov-specific context.
Restricting developer and operator access to cloud.gov services
You can ensure that developer and operator access to cloud.gov services traverses your agency’s TIC so that you can monitor all changes to your organizations, spaces, applications and services. The diagram below shows how the traffic flows.
Figure 1. restricting changes to agency origin
Any traffic from an agency-authorized boundary (eg physical network of an agency building, or collective virtual boundary for all networked agency buildings) to one that it is not under your agency’s control (e.g. the open internet, or cloud.gov) is likely already routed over a TIC connection.
For requests originating from your agency’s TIC egress bound for cloud.gov, our TLS implementation plays the role of the orange “encrypted tunnel” in Figure 14 of the TIC reference architecture. You will access both api.fr.cloud.gov and yourapp.app.cloud.gov exclusively over TLS because the cloud.gov domain is included in the HSTS preload list for your browser. (If you try to directly access those domains via HTTP, your request will be 301 redirected over to HTTPS; it’s not possible to get any other response without TLS.)
cloud.gov’s TLS endpoint is not restricted, but rather accessible over the open internet. When an administrator wants to interact with the deployed application through the cloud.gov API, it’s your agency’s responsibility to make sure that traffic goes over a TIC connection before it reaches its destination on cloud.gov. For example, you may not want users to be able to manipulate applications on cloud.gov from their home connection or via a wifi access point in the local coffee shop.
Your agency can accomplish this by establishing an operational requirement that all administrative access to cloud.gov services happens via the agency network. You can further enforce this requirement with a technical control: Prevent users in your domain from using the cloud.gov API except from your agency’s TIC egress range. Requests from an IP origin that does not match the range we have on record for your TIC (the dotted/dashed line in the diagram) will be rejected.
Restricting usage of your application
You may also need to restrict access through the “front door” of your deployed applications, such as administrator access to a Wordpress site, or public access to an internal-only service. The diagram below shows where you can implement this restriction.
Figure 2. restricting client access to your application
For remote workers or partners outside the normal agency network boundary, you can require use of a VPN to ensure that cloud.gov-bound traffic is routed over the agency network and TIC (shown in Figure 15 of the TIC Reference architecture).
You can then reject requests to your app unless they come from your agency’s TIC egress range. You can do this by modifying your application logic or deploying a user-provided route-service to act as a proxy.