Oracle Cloud Infrastructure US Federal Cloud with DISA Impact Level 5 Authorization
This topic contains information specific to Oracle Cloud Infrastructure US Federal Cloud with DISA Impact Level 5 authorization.
DISA Impact Level 5 authorization is in process for the following services:
Data Transfer service
Email Delivery service
Oracle Cloud VMware Solution
FedRAMP High Joint Authorization Board accreditation for these services is complete.
Compliance with Defense Cloud Security Requirements
US Federal Cloud with DISA Impact Level 5 authorization supports applications that require Impact Level 5 (IL5) data, as defined in the Department of Defense Cloud Computing Security Requirements Guide (SRG).
US Federal Cloud with DISA Impact Level 5 Authorization Regions
The region names and identifiers for the US Federal Cloud with DISA Impact Level 5 authorization regions are shown in the following table:
|Region Name||Region Identifier||Region Key||Realm Key||Availability Domains|
|US DoD East (Ashburn)||us-gov-ashburn-1||ric||OC3||1|
|US DoD North (Chicago)||us-gov-chicago-1||pia||OC3||1|
|US DoD West (Phoenix)||us-gov-phoenix-1||tus||OC3||1|
After your tenancy is created in one of the US Federal Cloud with DISA Impact Level 5 authorization regions, you can subscribe to the other regions in the US Federal Cloud with DISA Impact Level 5 authorization. These tenancies cannot subscribe to any Oracle Cloud Infrastructure regions not belonging to the OC3 realm . For information about subscribing to a region, see Managing Regions.
US Federal Cloud with DISA Impact Level 5 Authorization Console Sign-in URLs
To sign in to the US Federal Cloud with DISA Impact Level 5 authorization, enter one of the following URLs in a supported browser:
When you're logged in to the Console for one of the US Federal Government Cloud regions, the browser times out after 15 minutes of inactivity, and you need to sign in again to use the Console.
US Federal Cloud with DISA Impact Level 5 Authorization API Reference and Endpoints
This section includes the APIs and corresponding regional endpoints with US Federal Cloud DISA Impact Level 5 authorization.
Use the Endpoint of Your Home Region for All IAM API Calls
When you sign up for Oracle Cloud Infrastructure, Oracle creates a tenancy for you in one region. This is your home region. Your home region is where your IAM resources are defined. When you subscribe to a new region, your IAM resources are replicated in the new region, however, the master definitions reside in your home region and can only be changed there. Make all IAM API calls against your home region endpoint. The changes automatically replicate to all regions. If you try to make an IAM API call against a region that is not your home region, you will receive an error. See How do I find my tenancy home region?
In addition to these endpoints, each vault has a unique endpoint for create, update, and list operations for keys. This endpoint is referred to as the control plane URL or management endpoint. Each vault also has a unique endpoint for cryptographic operations. This endpoint is known as the data plane URL or the cryptographic endpoint.
The source service must be available in US Government Cloud regions for messages to be successfully sent through the Notifications service. If the source service is not available in these regions, then the message is not sent. For a list of unavailable services, see Services Not Supported in US Federal Cloud with DISA Impact Level 5 Authorization.
Both Object Storage and Archive Storage are accessible with the following APIs:
See Understanding Object Storage Namespaces for information regarding how to find your Object Storage namespace.
Oracle YUM Repo Endpoints
The Oracle YUM repo regional endpoints for US Federal Cloud with DISA Impact Level 5 authorization are shown in the following table
|Region||YUM Server Endpoint|
|US DoD East (Ashburn)||
|US DoD North (Chicago)||
|US DoD West (Phoenix)||
SMTP Authentication and Connection Endpoints
Email Delivery only supports the AUTH PLAIN command when using SMTP authentication. If the sending application is not flexible with the AUTH command, an SMTP proxy/relay can be used. For more information about the AUTH command, see AUTH Command and its Mechanisms.
|Region||SMTP Connection Endpoint|
|US DoD East (Ashburn)||smtp.email.us-gov-ashburn-1.oci.oraclegovcloud.com|
|US DoD North (Chicago)||smtp.email.us-gov-chicago-1.oci.oraclegovcloud.com|
|US DoD West (Phoenix)||smtp.email.us-gov-phoenix-1.oci.oraclegovcloud.com|
SPF Record Syntax
An SPF record is a TXT record on your sending domain that authorizes Email Delivery IP addresses to send on your behalf. SPF
is required for subdomains of
oraclegovcloud.com and recommended in
other cases. The SPF record syntax for each sending region is shown in the following
|Realm Key||SPF Record|
Services Not Supported in US Federal Cloud with DISA Impact Level 5 Authorization
Currently, the following services are not available or not supported for tenancies in the US Federal Cloud with DISA Impact Level 5 authorization.
Core Infrastructure services and features not available:
- FastConnect with a provider (FastConnect in a colocation model is supported)
- Data Transfer service
Database services not available:
- Autonomous Data Warehouse
- Autonomous Transaction Processing
- Data Safe
Solutions and Platform services not available:
- Analytics Cloud
- Fusion Analytics Warehouse
- Application Migration
- Compliance Documents
- Content and Experience
- DNS Zone Management
- Email Delivery
- Health Checks
- Traffic Management Steering Policies
Governance and Administration features not supported:
- Auto-federation with Oracle Identity Cloud Service
- WAF service
Integration with Oracle SaaS and PaaS services, including those listed here: Getting Started with Oracle Platform Services.
Access to Multiple US Federal Cloud with DISA Impact Level 5 Authorization Regions
This section shows how to give the on-premises resources that are part of NIPRNet access to multiple US Federal Cloud regions over a single FastConnect connection. This is important if one of the regions does not have a direct connection to the NIPRNet's border cloud access point (BCAP). The BCAP is also referred to as the meet me point.
Some US Federal Cloud regions have a direct connection to a NIPRNet BCAP, but others do not. You can use the Networking service to give on-premises resources that are part of NIPRNet access to a US Federal Cloud region that is not directly connected to the NIPRNet's BCAP. You might do this to extend your on-premises workloads into a particular US Federal Cloud region that you're interested in, or to use that region for disaster recovery (DR).
This scenario is illustrated in the following diagram.
In the diagram, US Federal Government Cloud region 1 has a direct connection to the NIPRNet's BCAP, but US Federal Government Cloud region 2 does not. Imagine that on-premises resources in NIPRNet (in subnet 172.16.1.0/24) need access to your virtual cloud network (VCN) in region 2 (with CIDR 10.0.3.0/24).
Optionally, there could also be a VCN with cloud resources in region 1 (with CIDR 10.0.1.0/24), but a VCN in region 1 is not required for this scenario. The intent of this scenario is for the on-premises resources to get access to resources in region 2.
In general, you set up two types of connections:
- FastConnect between the NIPRNet BCAP and region 1.
- Remote peering connection between region 1 and region 2.
Here are some details about the connections:
- That FastConnect has at least one physical connection, or cross-connect . You set up a private virtual circuit that runs on the FastConnect. The private virtual circuit enables communication that uses private IP addresses between the on-premises resources and the cloud resources.
- The remote peering connection is between a dynamic routing gateway (DRG) in region 1, and a DRG in region 2. A DRG is a virtual router that you typically attach to a VCN to give that VCN access to resources outside its Oracle region.
- You can control which on-premises subnets are advertised to the VCNs by configuring your BCAP edge router accordingly.
- The subnets in both VCN-1 and VCN-2 are advertised to your BCAP edge router over the FastConnect connection.
- You can optionally configure VCN security rules and other firewalls that you maintain to allow only certain types of traffic (such as SSH or SQL*NET) between the on-premises resources and VCNs.
Here are some basic requirements:
- The VCNs and DRGs in region 1 and region 2 must belong to the same tenancy, but they can be in different compartments within the tenancy.
- For accurate routing, the CIDR blocks of the on-premises subnets of interest and the VCNs must not overlap.
- To enable traffic to flow from a VCN to the on-premises subnets of interest, you must add a route rule to the VCN subnet route tables for each of the on-premises subnets. The preceding diagram shows the route rule for 172.16.1.0/24 in each VCN's route table.
General Setup Process
Summary: In this task, you set up the FastConnect between the NIPRNet BCAP and region 1. FastConnect has three connectivity models, and you generally follow the colocate with Oracle model. In this case, colocation occurs in the BCAP (the meet me point). The connection consists of both a physical connection (at least one cross-connect) and logical connection (private virtual circuit).
For instructions, follow the flow chart and tasks listed in Getting Started with FastConnect, and notice these specific variations:
- In task 2, the instructions assume that you have a VCN (in region 1), but it is optional.
- In task 8, create a private virtual circuit (not a public one).
Summary: If you don't yet have a VCN in region 2 (VCN-2 in the preceding diagram), you set it up in this task. You also create a DRG in region 2 and attach it to the VCN. Then, for each VCN-2 subnet that needs to communicate with the on-premises network, you update that subnet's route table to include a route rule for the on-premises subnet of interest. If there are multiple on-premises subnets that you want to route to, set up a route rule for each one.
For instructions, see these procedures:
- To create a VCN
- To create a DRG
- To attach a DRG to a VCN
To route a subnet's traffic to a DRG
In step 4 in the preceding list, add a route rule with the following settings:
- Destination CIDR = the on-premises subnet of interest
- Target = the VCN's DRG
In the preceding diagram, it's the rule with 172.16.1.0/24 as the destination CIDR, and target as DRG-2. The second rule in the diagram (for 10.0.1.0/24 and DRG-2) is necessary only if resources in VCN-2 need to communicate with resources in VCN-1.
Summary: In this task, you set up a remote peering to enable private traffic between DRG-1 and DRG-2. The term remote peering typically means that resources in one VCN can communicate privately with resources in a VCN in a different region. In this case, the remote peering also enables private communication between the on-premises network and VCN-2.
For instructions, see Setting Up a Remote Peering, and notice these important details:
- Optional region 1 VCN: The instructions assume that each region has a VCN, but in this situation, it is optional for region 1.
- Single VCN administrator: The instructions assume that there are two different VCN administrators: one for the VCN in region 1 and another for the VCN in region 2. In this situation, there might be only a single VCN administrator (you) who handles both regions and configures the remote peering connection.
- Unnecessary IAM policies: The instructions include a task for each VCN administrator to set up particular IAM policies to enable the remote peering connection. One policy is for the VCN administrator who is designated as the requestor, and one is for the VCN administrator who is designated as the acceptor. Those terms are further defined in Important Remote Peering Concepts. However, if there's only a single VCN administrator with comprehensive networking permissions across the tenancy, those IAM policies are not necessary. For more information, read the tip that appears at the end of the task.
- RPC anchor points and connection: The remote peering actually consists of multiple components that you must set up. There's an anchor point on each DRG (shown as RPC-1 and RPC-2 in the preceding diagram), plus a connection between those two RPC anchor points. The instructions include steps for creating those RPCs and the connection between them. Ensure that you create all the components.
Additional Information for US Federal Cloud with DISA Impact Level 5 Authorization Customers
- Shared Responsibilities
- Setting Up an Identity Provider for Your Tenancy
- Using a Common Access Card/Personal Identity Verification Card to Sign in to the Console
- IPv6 Support for Virtual Cloud Networks
- Setting Up Secure Access for Compute Hosts
- Setting Up an Identity Provider for Your Tenancy
- Required VPN Connect Parameters for Government Cloud
- Oracle's BGP ASN
- Requesting a Service Limit Increase for Government Cloud Tenancies