Authorization Boundary Diagram

An Authorization Boundary Diagram is a visual representation that maps out the structure and flow of your system’s software components, data connections, and security boundaries. It provides a clear, graphical depiction of how your system is organized and how different components interact.

To ensure seamless integration and secure deployment of your system within our environment, we require an Authorization Boundary Diagram. This diagram is crucial for us to understand your system design, validate that it meets security requirements, and ensure that it properly connects with our infrastructure.

Understanding Data Flow and External Connections

When establishing external data connections, it is imperative that you have a complete understanding of your data’s directional flow:

Egress – Data leaves or exits the boundary.

Ingress – Data enters the boundary.

Bidirectional – Data both leaves and enters the boundary.

For us to properly assess the security and integration of your system, our team needs a comprehensive understanding of the following:

Ports in Use: It is essential to know which ports are open and being used for these data flows (e.g., HTTP/HTTPS ports, API ports, etc.) to assess any potential security risks associated with network access.

Data Direction Management (Ingress/Egress): Understanding whether data is being ingested (ingress) into your environment or if it is being sent out (egress) helps us evaluate security policies related to data handling. Additionally, knowing if the data flow is bidirectional ensures we account for both directions of data transfer, which could have distinct security implications.

Preventing Data Spillage: To prevent data leakage or unintended data exposure, it is crucial to ensure that data flowing in and out of your system is properly controlled and monitored. We need to be certain that sensitive or regulated data does not spill into unauthorized areas or external systems.

For example, IL4+ data cannot exist at a lower Impact Level. For any applications accredited at IL4+, data transit across Game Warden boundary (to/from applications) must align with government requirements. Therefore, we must see these connections on your diagrams.

An Authorization Boundary Diagram not only provides visibility into the data flowing out of the boundary, but also offers a comprehensive view of all the physical components of your system, including servers, network devices, services, and third-party integrations. This holistic view is crucial for understanding how your system operates, where sensitive data resides, and how it interacts with external entities—enabling us to assess security, compliance, and connectivity more effectively.

The content below proactively provides guidance on the requirements for your Game Warden Authorization Boundary Diagram. Aligning your diagram with the specifications below ensures compliance with Authority to Operate (ATO) requirements.

Authorization Boundary Requirements

When creating your Authorization Boundary Diagram, you must clearly represent all data movement both within your application and outside its boundary. Specifically, you need to:

• Indicate the direction of data flow: ingress (data entering), egress (data leaving), or bidirectional (data flowing both ways).
• Specify the ports and protocols used for each connection.
• Include all application containers and any external or managed services that interact with your system.

This ensures that all components and data flows are visible, helping us assess security, compliance, and connectivity effectively.

Boundary Examples

In the images below, the right side of the diagram displays two end users accessing the Game Warden environment; one using the Department of Defense (DoD) Non-classified Internet Protocol Router Network (NIPRNet) IP, and the other using public Internet. The DoD uses NIPRNet to manage unclassified information.

The Cloud Native Access Point (CNAP) only exists at IL4 and IL5. In the diagrams below, the primary distinction between IL2 and IL4-IL5 is CNAP or an Internet Gateway. CNAP NIPR IP Whitelist screens the NIPR IP user, based on an allowable list of IP addresses. Both users proceed through an Internet Gateway to the Game Warden ATO Boundary, gaining access to AWS services and container instances. All customer environments are Keycloak-protected areas. For Platform One (P1)-hosted applications, you must provide P1 login credentials. CNAP functions as the P1 gatekeeper.

As evident in the diagrams, the data access methods include:

• NIPRNet
• Public Internet
• Platform One
• AWS GovCloud

IL2 Boundary Example

The diagram below displays the external data connections, customer containers, and the required platform services.

IL4/IL5 Boundary Example

The diagram below displays the external data connections, customer containers, and the required platform services.

Note

If your Virtual Desktop Infrastructure (VDI) is within NIPRNet, you can access IL4 and IL5 without using Appgate SDP which is a DoD-approved authentication service. The DoD's P1 team requires that you use Appgate SDP if you do not use NIPRNet or NIPRNet VPN (such as Air Force Desktop Anywhere), as you cannot access IL4 or IL5 without using one of these options. For additional information, read Appgate.

Download Templates

Below are the corresponding templates that you can use as a guide to create your Authorization Boundary Diagram. You can access an editable template in an MS Visio (VSDX) format, which will be made available to you on the Documents page of the Game Warden Web App.

If you need additional help with the diagram or would like to discuss your specific security requirements, don't hesitate to contact your Technical Implementation Manager (TIM) or Customer Success Manager (CSM).

Download Template for apps with external connections.

Download Template for apps without external connections.

Last Updated: 1/16/2025