Customer:

U.S. Department of Commerce
National Oceanic and Atmospheric Administration (NOAA)
National Marine Fisheries Service (NMFS)
Silver Springs, Maryland

Business Problem:

How to segregate and control access to OCI resources, allocate costs, and enforce Separation of Duties, and Privileged Access Control

Oracle Solution or Service associated with the Service Expertise,
Oracle Cloud Platform Security:

Oracle Infrastructure Cloud Security Compartments and Security Policies

Background

NOAA Fisheries, also known as the National Marine Fisheries Service (NMFS), is responsible for the management, conservation, and protection of living marine resources within about 200 miles of the U.S. coast.  They have 18 offices (science centers, permitting, and administrative) known as Financial Management Centers (FMC) located around the United States.  They have five regional offices, six science centers, and seven program offices.

NOAA Fisheries offices process data at their own respective locations with locally managed IT systems.  The NOAA Fisheries network backbone is the only component that is presently centrally managed.

NOAA, looking to better manage its IT resources, looked to use a cloud service provider and chose to use the Oracle Gov Cloud. “Oracle Government Cloud offerings have achieved FedRAMP high JAB accreditation, joined by the infrastructure and platform services generally available in those regions. Oracle Cloud US Government regions provide an excellent platform to host a service or organization seeking FISMA compliance by reducing effort by applying Oracle government cloud’s FedRAMP accreditations.”

During the initial phase of the initiative, there were several business requirements that drove the design of the architecture relating to the number of tenancies needed, cost allocation, separation of duties and privileged access control, and security.

OCI Compartments as a Solution for Cost allocation, Separation of Duty (SOD), and Privileged Access Management (PAM) 

We used multiple layers of compartments and security policies to meet NOAA’s requirements for simplicity, cost allocation, Separation of Duties (SOD), and Privileged Access Management (PAM). 

How many tenancies to allocate, specifically whether to allocate one tenancy or a tenancy for each NOAA Fisheries Financial Management Centers (FMC), eventually led to our use of Compartments as a solution for allocating costs and enforcing security policies. Our Impact Analysis findings listed below provided our reasoning for selecting a single tenancy.

  • Multiple tenancies would require achieving 18 separate Authority to Operate (ATO), one for each FMC. The ATO process requires significant documentation and exhaustive reviews. In this case, each FMC would need to make sure that they comply comprehensively with all set Federal Information Security Modernization Act (FISMA) standards as well as NIST RMF specifications. 
  • Multiple tenancies would require separate and redundant network connection, i.e., Trusted Internet Connection (TIC) between the NOAA Fisheries enterprise network and each tenancy.
  • Firewall and routing rules between each Oracle tenancy become opaque and complicated to manage and protect as the number of tenancies increase.  Routing between a set of tenancies would require a path in-and-out of the NOAA Enterprise network instead of routing within a tenancy.  The preference is to have a single set of network rules for all traffic that enters and leaves the tenancy through a hub and spoke network model.

What are OCI Compartments?

Compartments help you organize and control access to your resources. A compartment is a collection of related resources (such as cloud networks, computer instances, or block volumes) that can be accessed only by those groups that have been given permission by an administrator in your organization.

Compartments can be hierarchical and security policies applied to a parent compartment will be inherited by the child compartments.  This is important because tenancy-wide policies can be applied to top level compartments and automatically be applied as new compartments under them are created.  

Compartments are an essential concept that underpins our entire logical and technical approach to organizing the Cloud tenancy. The logical placement of resources, the segmentation of networking components and even security groups and associated policies are all built on top of a hierarchical compartmentalization scheme. 

Hierarchical Compartment Scheme

Our compartmentalization scheme is broken down into four levels, which may be nested, and are described in more detail below, refer to Figure 1.

“Resource” Compartments. Our resource compartments serve to group like types of computing resources together. In addition, the hierarchical nesting of these compartments communicates the breadth of control required to use and manage these resources. For example, a Compute Instance located within a particular application and within a particular FMC, is available for use only by actors specific to that single application, or to tenancy wide administrators. In contrast, a Compute Instance located in the root compartment, for NMFS wide use, is limited to only tenancy wide administrators. 

“Use” Compartments. Use compartments are provided to group resources by the way that they are used or by the overarching purpose that they serve. A common example of this would be grouping members along the lines of a Software Development Lifecycle, i.e., Development, Test and Production.

“Organizational” Compartments. Organizational compartments are used to align members along reporting or budgetary boundaries. That is, these are concerned with the alignment of computing resources to an organization within the agency. A common example of this type of compartmentalization would be grouping resources to facilitate billing and invoicing along FMC boundaries. 

“Project” or “Application” Compartments. Members within these compartments are grouped along the boundaries of a single project or application. This, in turn, facilitates our most granular form of charge back, Application-Level Charges. Because the Cloud Framework allows us to report resource consumption and, in turn, metered use charges, along compartmental boundaries, we can tie expenses directly to specific applications simply by taking the care to properly organize them into appropriate compartments.

Figure 1 Hierarchical Compartmentalization Scheme for NOAA Fisheries

Cost Allocation

NOAA Fisheries is required to identify cloud service costs incurred by each FMC. Oracle issues a single monthly invoice by tenancy, which does not contain cost details by organization level, application, or project. Using Compartments, CP developed an approach for determining cost allocation for almost any level of granularity resulting in the compartment structure as illustrated in Figure 2.

We have a series of compartments first at the root tenancy level for all common core services.  These are services as the name suggests common to the overall setup of the tenancy such as a compartment for security related access control, network configurations for connecting the NOAA Fisheries enterprise network to the tenancy, etc.  Our next tier of compartments is for each FMC specifically. Any further breakout of compartments for a given FMC is contained within it. Starting with this configuration NOAA Fisheries accounts for each office’s portion of the bill and levies a chargeback to the respective group and to monitor for any unusual activity associated with resources.

Each FMC makes their own decision on selecting a share everything model, an application specific model, or a mixture of the two depending on their specific cost tracking needs.  Some FMCs use application specific compartments to explicitly track the expenses associated with directly funded specific programs.

Enforcing Separation of Duties (SOD)

The next security requirement for our implementation was derived from the requirement that each office’s data and access be segregated unless explicitly authorized and under specific conditions in compliance with NIST 800-207, also referred to as the Zero Trust Architecture (ZTA). ZTA requires all users, systems, and programs, whether in or outside NOAA’s network, be authenticated, authorized, and continuously validated for security configuration and posture before being granted, or allowed access to NOAA Fisheries applications, systems, or data.

To comply with ZTA, we needed a much more robust compartment organization structure to enforce the required separation of duties between the FMC’s and within the FMC’s.  With the use of additional compartments, we were able to apply security policies at the compartment level to prevent a person who accessed a compartment from automatically obtaining access to other compartments, unless explicitly done so. Refer back to, Figure 1 Hierarchical Compartmentalization Scheme for NOAA Fisheries.

Privilege Access Management (PAM)

Although the ability to create and modify security policies can be granted to administrators of lower-level compartments (i.e. FMC, application), an administrator should not be given access/permissions to modify security policies for a compartment level that is above the level they are responsible for administering, i.e. Tenancy. An administrator may be allowed to create more restrictive policies, but not less.

In addition, an administrator should not be able to grant administrative access in a way that would allow a new administrator to remove the restrictions imposed on them.  For example, in Figure 1, if a person were granted the ability to manage an FMC NETWORK compartment through a security policy that is directly associated with that compartment, then that same administrator would have the ability to modify that same security policy and remove restrictions that were meant to limit that person’s access.  It is vital to have such policies tied to a compartment at least one level above the compartment the administrator is managing. 

Our approach is to assign all tenancy-wide policies to the root container. We enforce a base set of minimum policies at the tenancy level, while at the same time allowing local administrators to create security specific to their area of responsibility as long as they don’t conflict and are the same or more restrictive than those at a higher-level container/compartment. 

Restricting Access Using Compartments – Example

Figure 2 illustrates the compartmentalization by resource and then by use. Alternatively, we could have optionally added a compartment called OLE_APP_X (program/application) with resource sub-compartments followed by use sub-compartments.  In this way all resources associated with the OLE_APP_X program would be directly attributable.  This is an appropriate way to handle cases where access to special programs requires additional vetting or processes, and the need for a security policy that limits access exclusively to those persons who have met the necessary requirements for access.

Figure 2 OLE compartment, with sub-compartments by Resource (compute instance) and Use (Test, Prod)

It is important to note how different categories of resources have been given their own compartment.  For example, all databases are kept within a DBaaS compartment and further divided by USE compartments (dev, test, or prod) that can be restricted to specific administrators.  For example, someone with network privileges does not need access to a DBAAS resource, and someone with access to the development environment does not necessarily need access to the production environment.  This ensures that the creation of a new database or compute instance in an existing production styled compartment, would only be accessible to those previously granted production.

Takeaway

  • Use compartments to their fullest extent.
  • Compartmental security policies provide greater access granularity.
  • By default, sub-compartments inherit the security policies of higher-level Compartments.