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.

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:

Note

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

The US Federal Cloud with DISA Impact Level 5 authorization has these APIs and corresponding regional endpoints:

Core Services (covering Networking, Compute, and Block Volume)

The Networking, Compute, and Block Volume services are accessible with the following API:

Core Services API

API reference

  • https://iaas.us-gov-ashburn-1.oraclegovcloud.com
  • https://iaas.us-gov-chicago-1.oraclegovcloud.com
  • https://iaas.us-gov-phoenix-1.oraclegovcloud.com
Database API

API reference

  • https://database.us-gov-ashburn-1.oraclegovcloud.com
  • https://database.us-gov-chicago-1.oraclegovcloud.com
  • https://database.us-gov-phoenix-1.oraclegovcloud.com

You can track the progress of long-running Database operations with the Work Requests API.

IAM API

API reference

  • https://identity.us-gov-ashburn-1.oraclegovcloud.com
  • https://identity.us-gov-chicago-1.oraclegovcloud.com
  • https://identity.us-gov-phoenix-1.oraclegovcloud.com
Note

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?

Key Management API (for the Vault service)

API reference

  • https://kms.us-gov-ashburn-1.oraclegovcloud.com
  • https://kms.us-gov-chicago-1.oraclegovcloud.com
  • https://kms.us-gov-phoenix-1.oraclegovcloud.com

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.

Monitoring API

API reference

  • https://telemetry-ingestion.us-gov-ashburn-1.oraclegovcloud.com
  • https://telemetry-ingestion.us-gov-chicago-1.oraclegovcloud.com
  • https://telemetry-ingestion.us-gov-phoenix-1.oraclegovcloud.com
  • https://telemetry.us-gov-ashburn-1.oraclegovcloud.com
  • https://telemetry.us-gov-chicago-1.oraclegovcloud.com
  • https://telemetry.us-gov-phoenix-1.oraclegovcloud.com
Object Storage and Archive Storage APIs

Both Object Storage and Archive Storage are accessible with the following APIs:

Object Storage API

API reference

  • https://objectstorage.us-gov-ashburn-1.oraclegovcloud.com
  • https://objectstorage.us-gov-chicago-1.oraclegovcloud.com
  • https://objectstorage.us-gov-phoenix-1.oraclegovcloud.com
Amazon S3 Compatibility API

API reference

  • https://<object_storage_namespace>.compat.objectstorage.us-gov-ashburn-1.oraclegovcloud.com
  • https://<object_storage_namespace>.compat.objectstorage.us-gov-chicago-1.oraclegovcloud.com
  • https://<object_storage_namespace>.compat.objectstorage.us-gov-phoenix-1.oraclegovcloud.com
Tip

See Understanding Object Storage Namespaces for information regarding how to find your Object Storage namespace.
Swift API (for use with Oracle RMAN)
  • https://swiftobjectstorage.us-gov-ashburn-1.oraclegovcloud.com
  • https://swiftobjectstorage.us-gov-chicago-1.oraclegovcloud.com
  • https://swiftobjectstorage.us-gov-phoenix-1.oraclegovcloud.com
Work Requests API (for Compute and Database work requests)

API reference

  • https://iaas.us-gov-ashburn-1.oraclegovcloud.com
  • https://iaas.us-gov-chicago-1.oraclegovcloud.com
  • https://iaas.us-gov-phoenix-1.oraclegovcloud.com

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:

  • Compute service features:
    • Autoscaling
  • FastConnect with a provider (FastConnect in a colocation model is supported)
  • Data Transfer service
  • File Storage service

Database services not available:

  • Autonomous Data Warehouse
  • Autonomous Transaction Processing
  • Data Safe

Data and AI services not available:

  • Digital Assistant

Solutions and Platform services not available:

  • Announcements
  • Analytics Cloud
  • Fusion Analytics Warehouse
  • Application Migration
  • Compliance Documents
  • Container Engine for Kubernetes
  • Content and Experience
  • DNS Zone Management
  • Email Delivery
  • Events
  • Functions
  • Health Checks
  • Integration
  • Marketplace
  • Notifications
  • Registry
  • Resource Manager
  • Streaming
  • Traffic Management Steering Policies

Governance and Administration features not supported:

  • Auto-federation with Oracle Identity Cloud Service
  • WAF service

Special considerations for Infrastructure Tools:

  • The Oracle Cloud Infrastructure Terraform provider does not support FIPS-certified encryption.

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.

Overview

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.

This image shows the layout of the NIPRNet connected to two different Oracle regions by way of FastConnect and remote peering.

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:

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

Task 1: Set up FastConnect to region 1

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).
Task 2: Set up a VCN and DRG in region 2

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:

  1. To create a VCN
  2. To create a DRG
  3. To attach a DRG to a VCN
  4. To route a subnet's traffic to a DRG
    Important

    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.

Task 3: Set up remote peering between region 1 and region 2

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