Tenancy design for government agencies: Using a zone defense with multiple tenancies, compartments, and VCNs

In several design sessions with various customers, we discuss how to design their tenancies, compartments, and virtual cloud networks (VCN) to comply with government IT security requirements. If you’re new to Oracle Government Cloud, you might want to familiarize yourself with some key Oracle concepts around tenancies and compartments. In a typical government IT organization, you usually have environments or, in the case of the Department of Defense (DoD) world, zones, as defined by DoD Cloud Computing SRG. Each environment has strict requirements for security separation and what types of activities you can perform within each environment.

The design options described in this blog post are examples and guiding principles on how to design your Oracle Government Cloud tenancy. Your cyber security teams might have different interpretations of security requirements that require deviations from what we describe.

In an example on-premises environments, you have the following environments and zones designated:

With both environments or zones, the goal is to reduce the risk of security threats horizontally within the tenancy and compartmenting the production environment from test, development, and integration activities. The production environment is strictly for a pristine production operating environment maintaining the utmost uptime. We protect the resources by restricting network traffic to and from the VCN and applying policies to the compartment to restrict access rights. Combining those two capabilities of Oracle Cloud Infrastructure (OCI) provides a defensive in-depth approach.

The misconception about compartments that they provide a boundary that controls access to your resources is untrue. Compartments alone provide a grouping of resources and don’t restrict or control access. You need to apply policies. So, we create a VCN around a compartment of resources, apply security lists to the VCN, and create policies to restrict users or groups access to compartment resources.

Design example

You can design your tenancies, compartments, and VCNs in multiple ways. There’s no right or wrong way, but review how your organization manages its IT infrastructure, autonomy, and security requirements.

This scenario has the following requirements:

• A top-level organization acting as a cloud service provider

• The application owner is responsible for managing the infrastructure for four different applications for four different programs under the same organization.

• The application owner is responsible for application development of the four different applications.

• Each program has its own accreditation boundary.

• The applications require isolation from each other.

• Each environment must be isolated from each other.

Why not create a single tenancy and separate the environments with a VCN and apply policies by compartment? By design, each OCI tenancy has a single Identity and Access Management (IAM) plane. Federating the IAM plane provides more security. How you use IAM can introduce security risks. A malicious user with elevated access can move horizontally from VCN to VCN and potentially compromise all environments. But proper configuration of policies and application of security can prevent these situations. The interpretation and tolerance for risk is unique to each customer.

Now, the goal is to separate access of each environment or zone by a tenancy. Create a tenancy for each zone per application and program: Four environments in each of the four tenancies, for a total of 16 tenancies.

This configuration isn’t efficient from an administrative standpoint. Because a top-level organization manages the environments, we have a tenancy for each environment. Next we group the applications by compartments in each tenancy and use VCNs to provide the isolation in each environment.

The four tenancies accomplish the following results:

• Limit and restrict access to each environment: Only people who need to test can test and only people who need to push changes to the production zone can do so. Starting with development and moving to production, each environment is more restrictive and fewer administrators have access.

• Keeping a pristine production environment: Within each tenancy, a VCN with security lists and policies applied to the compartment controls network and administrative access. This organization allows for a pristine production environment.

• Most restrictive control: The production environment is controlled as tightly as possible without the rest of the environments being too restrictive to perform activities, such as development. For example, this organization only allows ingress and egress of SSL/443 traffic through of the VCN. Ideally, a customer or user can only access this environment through port 443.

What’s your risk tolerance?

Your level of risk tolerance is the most important factor. Some organizations are fine with a single tenancy; some require multiple tenancies. For larger organizations with more employees to perform, development, testing, integration, and production tasks, it makes sense to have more separation of powers and more separation and isolation between environments. For smaller organizations, you might not have enough staff to justify multiple tenancies. The same people testing might be performing integration and production tasks, so the separation of powers and isolation isn’t needed. Again, there’s no right or wrong way. You can interpret and meet security requirements in multiple ways.

Other considerations

If you require a management network, you have two options: Adding another VCN and compartment in each tenancy dedicated to management or by creating a separate management tenancy.

Unified billing is not yet available in the Oracle Government Cloud, but it’s available in our commercial cloud. For now, having multiple tenancies invokes multiple billing invoices. You need a third party to consolidate the invoices.

Depending on your security requirements, you might require communications between VCNs. So, you need to set up peering. Oracle Government Cloud offers two types of peering: Remote peering connections (RPC) and local peering gateway (LPG). RPCs are used for VCNs in different regions, and LPGs are used for networks in the same region.

What’s next?

Give it a try yourself. When you have your design laid out, you can select either the Oracle Cloud Free Tier for a 30-day free trial in our commercial regions, which includes US$300 in credits to get you started with a range of services, including compute, storage, and networking. The Oracle Cloud Infrastructure regions dedicated for the Government consist of FedRAMP high federal and civilian authorized regions and IL5 Department of Defense (DoD) authorized regions. If you prefer the Oracle Government Cloud, consult with your Oracle sales representative for a proof of concept in the appropriate region.