IAM Security Structure

• The tenancy is the highest container hosting your OCI resources, and is also referred to as the root compartment.
• All access control of OCI resources is dictated by IAM policies, where tenancy is the highest level that IAM polices can be assigned. OCI Organization Management Governance Rules can control allowed regions, service quota, and tags for child tenancies, but have no control over the IAM policies. It's possible to grant access across tenancies by creating Cross-Tenancy IAM Policies. In this case, the administrators of granting and accepting tenancies must create special policy statements that explicitly state the resources that can be accessed and shared.

Note: The root compartment is the top level of the IAM policy hierarchy, and IAM policies can't inherit across tenancies. For more information, see How Policies Work and Cross-Tenancy Policies.

• Each OCI tenancy is created with a set of service limits configured by Oracle. Although users can request a service limit increase, they don't have direct control over the limits.
• To avoid service interruption, users can control the usage distribution by assigning service quotas to compartments as needed.
• Users can scale beyond hard service limits by leveraging a new tenancy, which has its own set of limits assigned during creation.

You can add tenancies to your organization using Organization Management, and have the tenancies consume credits from your primary funded subscription. You can then create an isolated tenancy to build your workloads without booking a new order.

The types of tenancy include the following:

• Parent tenancy: Associated with the primary funded subscription, which can analyze and report across each of your tenancies. Each organization can have only one parent tenancy. It's typical to use the parent tenancy for management purposes where developer, finance, and IT operations might need access to it. In this case, we recommend that you don’t host any applications or services within this tenancy.
• Child tenancies: Tenancies consuming from a subscription that is not their own. Child tenancies can be created as entirely new tenancies, or existing tenancies can be invited to join the parent tenancy and become part of the same organization.

Note: We recommend that you don’t host any applications or services within the parent tenancy, especially if it's used for management purposes. For more information, see OCI Blog-Use Organizations to centrally manage costs.

Consider the following information for your tenancies:

• Billing and cost management: Sharing a single commitment helps reduce cost overages and allows for consolidated billing.
• Environment isolation: When you require high operational autonomy with strict resource isolation, you can use a tenancy as the top-level boundary to isolate your environments. Because each tenancy comes with a distinct set of IAM resources and rules, the security and governance settings are administered separately. Separate administration supports the highest degree of operational autonomy.
• Management overhead: Multiple tenancies allow for operational autonomy with a strong isolation level, but incur management overhead costs. If you don't need a high level of isolation, such as for regulatory compliancy, consider using identity domains and compartments.
• IAM resources residency: Each tenancy has its own home region, which contains your Oracle Cloud account information and identity resources in the default IAM identity domain.
  • The default domain always replicates to all regions to which the tenant is subscribed. When an administrator subscribes to another region, only the default domain replicates to that region. The default domain's home region is the tenancy's home region, which can't be changed.
  • Secondary (non-default) identity domains can have their own home region, but only within the set of regions the tenancy is subscribed to. Secondary identity domains can also be replicated to regions within the set of regions the tenancy is subscribed to.

Consider the following limitations for tenancies:

• The home region contains your account information and identity resources, and can't be changed after the tenancy is provisioned. For more information, see The Home Region.
• When a child tenancy is created, the tenancy is not automatically federated to Oracle Identity Cloud Service/OCI Identity Domains. For more information, see Creating a New Child Tenancy.
• Tenancies using Pay As You Go or Free Tier subscriptions can't add new child tenancies. For more information, see Creating a New Child Tenancy.
• Parent-child tenancy is a single level structure and doesn't support a multi-level hierarchy.

Consider the following sample use cases for having separate tenancies:

• SaaS service provider to host dedicated tenancies for regulated customers
• IAM resource residency requirements from privacy and data security laws.
• For mergers and acquisitions (M&A), companies that need to maintain operational autonomy with separate identity management and hiring processes.
• For hackathons and proofs of concept (PoC), the ability to start innovative projects in a Free Tier and project-based tenancy, and then apply to the broader organization for negotiated price tables and better cost visibility.
• Regulatory requirements such as separation of production and non-production environments.

Make key design decisions based on the following information:

• Accepted use cases to scale OCI adoption with separate tenancies and organizations
• Tenancy operational models, such as the process for requesting a new tenancy, tenancy ownership, cost, and budget management

For more information, see Organization Management and Managing the Tenancy.

To enforce strong governance, some enterprises might need to have centralized control of new cloud account creation across a business group.

You can register your public domain name with OCI by way of Domain Management, which blocks others from claiming that domain in the future for using new cloud accounts. You can redirect new user sign-up attempts that use a corporate email address from that verified domain.

For example, if someone using OCI tries to create a tenancy with "companyA.com" in the email domain, the attempt is prevented and they are directed instead to OCI.

As a result, with Domain Management, large enterprises can more easily control their environments by knowing who is creating tenancies, and applying corporate policy onto the tenancies. You can securely verify ownership of your domains, and more easily control spending and management of resources.

Typically, this is covered in the parent tenancy as part of the central management capability. You need help from your public domain administrator to add the OCI provided TXT record to verify your ownership of the domain. This domain verification process can take up to 72 hours to complete.

Note: You can prevent others from creating an Oracle Cloud account with your verified domain by way of Domain Management. We use Oracle Notification to notify you if someone tries to create an account with your domain.

Note: You might block other lines of business to create their own accounts by enabling this feature if you share a domain. We recommended that you enable this feature by using your central administration team and proper communication with related stakeholders, such as the affected lines of business.

For more information, see Organization Management and Managing the Tenancy.

Consider the following information when designing IAM structure:

• The needs for separating user IDs and administrators across environments and workloads. For example:
  • Production compared with development environments
  • Staff-facing workloads compared with customer-facing workloads
  • Employees compared with contractors
• Administrators can create as many secondary identity domains as their service limits allow.
• You can upgrade the default or secondary identity domain to a different domain type. Each identity domain type is associated with different features and object limits.

The following information summarizes key differences between the default identity domain and secondary identity domains.

Consider the following sample use cases for having separate identity domains:

• Using environment separation since some security standards and industry regulations require that you separate users between production and development environments, preventing access from development to production.
• Separating external users, such as customers and contractors, from employee identities.

Follow these recommendations when setting up your domains:

• Use different identity domains for each user population.
• Use the default identity domain for tenancy level administration. Use secondary identity domains for environment-specific administration and platform as a service (PaaS) services to have more control over domain behavior, such as lifecycle, home region, and replication.
• Start with Free/Oracle Apps Identity Domain for cloud-only scenarios and upgrade to Premium/Oracle Apps Premium for higher limits or to support advanced use cases. For example:
  • Authenticate to on-premises or cloud-hosted Oracle applications.
  • Use bidirectional synchronization with Active Directory or other IAM systems.
  • Use modern AuthN/AuthZ features such as passwordless authentication, FIDO2 hardware tokens, and adaptive security solutions.
• Create a secondary external identity domain for consumer-facing and non-employee use cases that require the following resources:
  • Social login, user self-service password, profile management, and terms of use consent.
  • Full-featured identity as a service (IDaaS) to scale for millions of users.
  • No access to OCI entitlement management. Examples include managing access to OCI resources, and staff-facing IAM features for provisioning to third-party apps that use App Catalog and Active Directory sync.

• Endorse the acceptable use cases for having additional secondary identity domains for IAM isolations.
• Decide the home region of the IAM domain, which can't be changed after creation.
• Decide if any premier IAM feature is mandatory, such as bidirectional sync with LDAP/AD by bridge, EBS Asserter and RADIUS proxy.
• Decide the ownership and administration of external user IAM domain if features such as social login, user self-service password, and profile management are needed.

For more information, see IAM Identity Domain Types.

• IAM policy is a statement that specifies who can access which OCI resources that your company has, and how.

• Because OCI doesn't grant access by default, your organization needs at least one policy to start governing control of your resources. Each policy consists of one or more policy statements that follow this basic syntax:

  Allow <subject> to <verb> <resource-type> in <location> where <conditions>

• The following information describes the three main groups of IAM policies.

• Because the change of access for OCI Services and Dynamic Group can cause services outages if they aren't handled properly, we recommended that you release these types of changes by way of a canary tenancy/environment to avoid introducing breaking changes to production.
• You can fine grant access controls by organizing resources with compartments and tags.

Consider the following information when you set up compartments and tags:

• Compartments:

  • Compartments are tenancy-wide and span across regions. When you create a compartment, the compartment is available in every region that your tenancy is subscribed to.
  • You can create subcompartments inside other compartments to create hierarchies that are up to six levels deep. A subcompartment inherits access permissions from compartments above it in the hierarchy.
  
  • Compartment is one of the mandatory units of granting access control. You can further refine compartment by the conditional clauses.

• Tags: You can use tag-based access control to define access policies that span across compartments, groups, and resources. Using tag-based access control can help you avoid duplicating IAM policies, ensure consistency, and minimize management overhead.

  Caution: Defined tag keys are case-insensitive, whereas defined tag values are case-sensitive. For example, "Env" and "ENV" are the same tag key. "Dev" and "DEV" are distinct tag values.

• Conditional IAM policy:

  • Condition matching is case-insensitive, tag value is case-sensitive, and some resource types allow case-sensitive naming. For example, consider the following statement:

    A user in Group A can access resources in compartments with the tag Operations.Project= 'sample'. The user can also access resources in compartments with the tag Operations.Project= 'Sample'. >allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'sample'

  • Consider using predefined values in defined tags if tag-based access control is adopted. See Working with Predefined Values.

  • All OCI services support request.principal.compartment, request.principal.group, and target.resource.compartment.tag policy variables. However, not all services support the target.resource.tag policy variable. See Supported Services.

    For advanced conditional IAM Policy features, see Tag-Based Access Control and Time-based Access Control.

Use the following recommendations when setting up compartments and tags:

• Create and designate compartments for specific categories of resources. Also, write IAM policies to allow access to the resources for only the groups of users that need access.
• Divide production workloads and non-production workloads into separate compartments.
• Create and use child compartments to isolate resources for more organizational layers. Write separate policies for each compartment level.
• Allow only authorized users to move compartments to different parent compartments, and to move resources from one compartment to another. Write suitable policies to enforce this restriction.
• Limit the number of resources of each type that can be created in a compartment by setting compartment-level quotas.
• Limit the resources that an instance principal can manage by specifying a compartment in the IAM policy.
• Assign tags to resources to organize and identify them based on your business needs.
  • Use compartments and tagging to simplify access management. Align your OCI compartment design with your department or project structures. For more information, see Managing Compartments.
  • If tag-based access control is adopted, ensure that you have appropriate controls in place to govern who can apply tags.
  • After policies are in place, remember that applying tags to a group, user, or resource has the potential to confer access to resources.
• Keep as few compartments as possible. This makes browsing in the OCI Console less complicated.
• Don't combine with Network security. Compartments have limited impact on the actual workload.