Oracle Cloud Infrastructure Documentation

Securing IAM

Security Recommendations

Oracle Cloud Infrastructure Identity and Access Management (IAM) provides authentication of users, and authorization to access The cloud objects that your company's employees create and use when interacting with Oracle Cloud Infrastructure.. Security-relevant IAM concepts include:

IAM concepts and descriptions
Concept Description
Compartment A compartment is a fundamental mechanism to aggregate resources into logical groups. They also provide isolation.
Tenancy Oracle Cloud Infrastructure automatically creates a tenancy for an account created by an organization. It is the root compartment that contains all the organization's resources.
Users and groups A group is an aggregation of users who need similar access to a group of resources.
Resource A resource is an object created in Oracle Cloud Infrastructure services.
Security policy A security policy specifies the type of access IAM groups have to resources in a specified aggregation level. An aggregation level can be the tenancy, a compartment, or a service.
Dynamic groups A dynamic group allows aggregating Compute instances as principal actors (similar to user groups), in order to authorize instances to make calls to Oracle Cloud Infrastructure APIs.
Tags Tags allow you to organize resources across multiple compartments for reporting purposes or for taking bulk actions.
Federation Mechanism to federate IAM with other identity providers (IdP) used by an organization to authenticate their users.

Oracle recommends that you periodically monitor Audit logs to review changes to IAM users, groups, and security policies.

IAM Tenancy and Compartments

  • Compartments are unique to IAM, and offer a mechanism that allows an enterprise customer to meet its central needs by having a single account or tenancy. This single account or tenancy provides full central control and visibility while also allowing the account or tenancy to be subdivided to meet the needs of constituent teams, projects, and initiatives.
  • For security and governance reasons, users should only have access to resources they need. For example, enterprise users working on a project or belonging to a business unit should have access only to resources belonging to the project or business unit. Compartments provide an effective mechanism to group tenancy resources based on their access privileges and authorize groups of users to access the compartments on as needed basis. In the example above, a compartment can be created to include all resources belonging to a business unit, and authorize only members of the business unit to access the compartment. Similarly, a groups' access to a compartment can be revoked when they do not need it anymore.
  • Keep the following in mind when you create a compartment and assign resources:
    • Every resource should belong to a compartment.
    • A resource can be reassigned to a different compartment after creation. See Managing Compartments.
    • A compartment can be deleted after creation. See Managing Compartments.
  • Resource tags provide a way to logically aggregate resources distributed across multiple compartments. For example, tenancy resources can be tagged as test or production depending on their use. For more information about resource tags (free-form and defined tags), see Resource Tags.
  • Every tenancy comes with a default administrators group. This group can perform any action on all resources in a tenancy (that is, they have root access to the tenancy). Oracle recommends that you keep the group of tenancy administrators as small as possible. Some security recommendations on managing tenancy administrators:
    • Have security policies granting membership of tenancy administrator group strictly on a as-needed basis.
    • Tenancy administrators should use high-complexity passwords, along with MFA, and periodically rotate their passwords.
    • After account set up and configuration, Oracle recommends that you don't use the tenancy administrator account for day-to-day operations. Instead, create less privileged users and groups.
    • Though administrator accounts are not used for daily operations, they are still needed to address emergency scenarios impacting customer tenancy and operations. Specify secure and auditable "break-glass" procedures for using administrator accounts in such emergencies.
    • Disable tenancy administration access immediately when an employee leaves the organization.
    • Because the tenancy administrator group membership is restricted, Oracle recommends that you create security policies which prevent administrator account lock-out (for example, if the tenancy administrator leaves the company and no current employees have administrator privileges).

IAM Users and Groups

  • Create an IAM user for everyone in the customer organization who needs access to resources. Do not share IAM user accounts across multiple users, especially those with administrative accounts. Using distinct IAM users enables enforcing least privilege access for each user, and captures their actions in audit logs.
  • The recommended unit of administration is IAM groups, which makes it easier to manage and keep track of security permissions (as opposed to individual users). Create IAM groups with permissions to do commonly needed tasks (for example, network administration, volume administration), and assign users to these groups on an as-needed basis. IAM permissions can be used to give a group access to resources across multiple compartments in a tenancy.
  • Periodically review membership of IAM users in IAM groups, and remove IAM users from groups they do not need access to anymore. Using group membership to manage user access scales well with increasing number of users.
  • Deactivate IAM users who do not need access to tenancy resources. Deleting an IAM user removes the user permanently. You can temporarily deactivate an IAM user by doing the following:
    • Rotate the user password and throw it away.
    • Remove all tenancy permissions of the user by removing membership from all groups.

IAM Credentials

IAM user credentials (Console password, API signing key, auth tokens, and customer secret keys) grant access to resources. It is important to secure these credentials to prevent unauthorized access to Oracle Cloud Infrastructure resources. General guidelines for handling credentials include:

  • Create a strong console password for each IAM user, with sufficient complexity. Oracle recommends the following for a complex password:

    • Password has a minimum length of 12 characters
    • Password contains at least one uppercase letter
    • Password contains at least one lowercase letter
    • Password contains at least one symbol
    • Password contains at least one number
  • Rotate IAM passwords and API keys regularly, every 90 days or less. In addition to a security engineering best practice, this is also a compliance requirement. For example, PCI-DSS Section 3.6.4 states, "Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined crypto period(s)."
  • Do not hard code sensitive IAM credentials directly in software or documents accessible to a wide audience. Examples include code uploaded to GitHub, presentations, or documents available on the internet. There have been known, highly publicized cases of hackers breaching customer cloud accounts, using credentials inadvertently disclosed on public sites. When software applications need to access Oracle Cloud Infrastructure resources, Oracle recommends that you use instance principals. If it is not feasible to use instance principals, other recommendations include using user environment variables to store credentials, and using locally stored credential files with API keys to be used by the Oracle Cloud Infrastructure SDK or CLI.
  • Do not share IAM credentials between multiple users.
  • By federating the Console login through Oracle Identity Cloud Service, customers can use multifactor authentication (MFA) for IAM users, especially administrators.

When rotating API keys, verify that the rotated keys work as expected before disabling older keys. For information about generating and uploading IAM API keys, see Required Keys and OCIDs. The high-level steps in rotating an API key are:

  1. Generate and upload a new API key.
  2. Update the SDK and CLI configuration files with the new API key.
  3. Verify that the SDK and CLI calls are working correctly with the new key.
  4. Disable the old API key. Use ListApiKeys to list all active API keys.

IAM Security Policies

IAM policies are used to govern access of IAM groups to resources in compartments and in the tenancy. Oracle recommends that you assign least privilege access to IAM groups for accessing resources. The common format for IAM policies is shown in the following example.

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>
Allow group <group_name> to <verb> <resource-type> in tenancy

IAM policies allow four predefined verbs: inspect, read, use and manage. Inspect allows least privilege and manage allows the maximum. The four verbs are shown in increasing order of privilege in the following table.

IAM policy verbs
Verb Access Type Example User
inspect Should only show metadata. This usually results in ability to list resources only third-party auditor
read inspect plus ability to read resource and user metadata. This is the permission most users need to get work done. internal auditors
use read plus ability to work with resources (the actions vary by resource type). Excludes ability to create or delete resource regular users (software developers, system engineers, dev managers, etc) setting up and configuring tenancy resources, and applications running on them
manage All the permissions for all the resources administrators, executives (for break-glass scenarios)

The resource types of Oracle Cloud Infrastructure resources are shown in the following table.

IAM resource families, descriptions, and resource types
Resource Type FamilyDescriptionResource Types
all-resourcesAll resource types 
No name by designResource types in IAM servicecompartments, users, groups, dynamic-groups, policies, identity-providers, tenancy tag-namespaces, tag-definitions
instance-familyResource types in compute serviceconsole-histories, instance-console-connection, instance-images, instances, volume-attachments
volume-familyResource types in block storage servicevolumes, volume-attachments, volume-backups
virtual-network-familyResource types in virtual networking servicevcns, subnets, route-tables, security-lists, dhcp-options, private-ips, public-ips, internet-gateways, local-peering-gatewaysdrgs, deg-attachments, cpes, ipsec-connections, cross-connects, cross-connect-groups, virtual-circuits, vnics, vnic-attachments
object-familyResource types in object storage servicebuckets, objects
database-familyResource types in DbaaS servicedb-systems, db-nodes, db-homes, databases, backups
load-balancersResources in Load Balancer serviceload-balancers
file-familyResources in file storage servicefile-systems, mount-targets, export-sets
dnsResources in DNS servicedns-zones, dns-records, dns-traffic
email-familyResources in email delivery serviceapproved-senders, suppressions

For more information about IAM verbs and resource type permission mappings, see Details for the Core Services.

IAM security policies can be made fine-grained through conditions. Access specified in the policy is allowed only if the condition statements evaluate to true. Conditions are specified using predefined variables. The variables use the key words request or target, depending on whether the variable is relevant to the request or the resource being acted on, respectively. For information about supported predefined variables, see Policy Reference.

IAM dynamic groups are used to authorize Compute instances to access Oracle Cloud Infrastructure APIs. The instance principals feature can be used by applications, running on the instances, to programmatically access Oracle Cloud Infrastructure services. Customers create dynamic groups, which include instances as members, and authorize access to their tenancy resources using IAM security policies. All access by instances is captured in the audit logs available to customers.

IAM Federation

  • Oracle recommends that you use federation to manage logins into the Console. Identity federation supports SAML 2.0 compliant identity providers, and can be used to federate on-premises users and groups to IAM users and groups. The enterprise administrator needs to set up a federation trust between the on-premises identity provider (IdP) and IAM, in addition to creating mapping between on-premises groups and IAM groups. Then, on-premises users can single sign-on (SSO) into the Console, and access resources based on authorization of IAM groups they belong to. For more information about federating to the Console, see Federating with Identity Providers. Federation is especially important for enterprises using custom policies for user authentication (for example, multifactor authentication) . For more information about managing users and groups under federation, see Federating with Identity Providers.
  • When using federation, Oracle recommends that you create a federation administrators group that maps to the federated IdP administrator group. The federation administrators group will have administrative privileges to manage customer tenancy, while being governed by the same security policies as the federated IdP administrator group. In this scenario, it is a good idea to have access to the local tenancy administrator user (that is, member of the default tenancy administrator IAM group), to handle any break-glass type scenarios (for example, inability to access resources through federation). However, you must prevent any unauthorized use of this highly privileged local tenancy administrator user. Oracle recommends the following approach to securely managing the tenancy administrator user:
    1. Create a local user belonging to the default tenancy administrator group.
    2. Create a highly complex Console password or passphrase (18 characters or more, with at least one lowercase letter, one uppercase letter, one number, and one special character) for the local tenancy administrator user.
    3. Securely escrow the local tenancy administrator user password in an on-premises location (for example, place the password in a sealed envelope in an on-premises physical safe).
    4. Create security policies for accessing the escrowed password only under specific "break-glass" scenarios.
    5. Have IAM security policy to prevent the federated administrators IAM group from adding or modifying membership of the default tenancy administrator group to prevent security by-passes.
    6. Monitor audit logs for accesses by default tenancy administrator and changes to the administrator group, to alert on any unauthorized actions. For additional security, the local tenancy administrator user password can be rotated after every login, or periodically, based on a password policy.

For an example that shows the way various IAM components fit together, see Example Scenario. Periodically monitor Audit logs to review changes to IAM users, groups, policies, compartments, and tags.

Security Policy Examples

Common IAM security policy examples are available at Common Policies. In all the examples that follow, the policies are scoped to a tenancy. However, by specifying a compartment name, you can scope down the policies to specific compartments in a tenancy.

Create Service-level Admins for Least Privilege

To implement security principle of least privilege, you can create service-level admins in the tenancy to further scope down administrative access. This means that service-level administrators can only manage resources of a specific service. For instance, network administrators need administrative (manage) access only to VCN resources, and not to other resources. The following example shows how to create administrator groups for block storage (VolumeAdmins), VCN (NetworkAdmins), databases (DBAdmins), and object storage (StorageAdmins).

Allow group TenancyAdmins to manage all-resources in tenancy
Allow group VolumeAdmins to manage volume-family in tenancy
Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group StorageAdmins to manage object-family in tenancy
Allow group DBAdmins to manage database-family in tenancy

You can further constrain the security policies to a specific compartment. For example, the HR department in an enterprise can create group HRAdmins to manage resources within its compartment, HR-compartment. The HRNetworkAdmins group has administrative access to VCN resources only within the HR-compartment compartment.

Allow group HRAdmins to manage all-resources in compartment HR-compartment
Allow group HRNetworkAdmins to manage virtual-network-family in compartment HR-compartment

Compliance auditors are tasked with examining cloud resources and verifying for policy violations. The following policy allows group InternalAuditors to inspect (list) all resources in a tenancy.

Allow group InternalAuditors to inspect all-resources in tenancy

If you want to limit auditors to only inspect users and groups in a tenancy, you can create a group UserAuditors with the following policy:

Allow group UserAuditors to inspect users in tenancy
Allow group UserAuditors to inspect groups in tenancy

If you want to create an auditor group that can only inspect VCN firewalls in the tenancy, use the following policy:

Allow group FirewallAuditors to inspect security-lists in tenancy

In all the policy examples, you can constrain the policies to a compartment by specifying Compartment <name> (where <name> is the compartment name) in the policy.

Restrict Ability to Change Tenancy Administrators Group Membership

Members in the group Administrators can manage all resources in a tenancy. Membership of the Administrators group is controlled by users in the group. Usually, it's convenient to have a group to create and add users in the tenancy, but restrict them from making changes to the Administrators group membership. The following example creates a group UserAdmins to do this.

Allow group UserAdmins to inspect users in tenancy
Allow group UserAdmins to inspect groups in tenancy
Allow group UserAdmins to use users in tenancy
 where target.group.name!='Administrators'
Allow group UserAdmins to use groups in tenancy
 where target.group.name!='Administrators'

Use verb with conditions (third and fourth policy statements) allows UserAdmins to add users and groups using APIs (UpdateUser, UpdateGroup) to all groups in the tenancy except the Administrators group. However, because target.group.name!='Administrators' is not related to the list and get APIs (ListUsers, GetUser, ListGroups, and GetGroup), these APIs will fail. So you must explicitly add the inspect verb (first and second policy statements) to allow UserAdmins to get user and group membership information.

Prevent Delete or Update of Security Policies

The following example creates a group PolicyAdmins to be able to create and list security policies created by tenancy administrators, but not delete or update them.

Allow group PolicyAdmins to use policies in tenancy
Allow group PolicyAdmins to manage policies in tenancy
 where request.permission='POLICY_CREATE'

This security policy statement explicitly only allows POLICY_CREATE permission, and not to POLICY_DELETE and POLICY_UPDATE.

Prevent Admins from Accessing or Altering User Credentials

Some compliance requirements need separation of duties, especially where user credential management functionality is separated from tenancy management. In this case, you can create two administration groups, TenancyAdmins and CredentialAdmins where TenancyAdmins can perform all tenancy management functions except user credential management, and CredentialAdmins can manage user credentials. TenancyAdmins can access all APIs except those that list, update, or delete user credentials. CredentialAdmins can only manage the user credentials.

Allow group TenancyAdmins to manage all resources in tenancy
 where all {request.operation!='ListApiKeys',
            request.operation!='ListAuthTokens',
            request.operation!='ListCustomerSecretKeys',
            request.operation!='UploadApiKey',
            request.operation!='DeleteApiKey',
            request.operation!='UpdateAuthToken',
            request.operation!='CreateAuthToken',
            request.operation!='DeleteAuthToken',
            request.operation!='CreateSecretKey',
            request.operation!='UpdateCustomerSecretKey',
            request.operation!='DeleteCustomerSecretKey'}
Allow group CredentialAdmins to manage users in tenancy
 where any {request.operation='ListApiKeys',
            request.operation='ListAuthTokens',
            request.operation='ListCustomerSecretKeys',
            request.operation='UploadApiKey',
            request.operation='DeleteApiKey',
            request.operation='UpdateAuthToken',
            request.operation='CreateAuthToken',
            request.operation='DeleteAuthToken',
            request.operation='CreateSecretKey',
            request.operation='UpdateCustomerSecretKey',
            request.operation='DeleteCustomerSecretKey'}

Useful CLI Commands

In all the following examples, environment variables $T and $Care set to tenancy OCID and compartment OCID, respectively.

List Compartments in a Tenancy

# list all compartments (OCID, display name, description) in tenancy $T
oci iam compartment list -c $T
# grep above command for important fields
oci iam compartment list -c $T | grep -E "name|description|\"id\""

List IAM Users

# lists all users (OCID, display name, description) in tenancy $T
oci iam user list -c $T
# grep above command for important fields
oci iam user list -c $T | grep -E "name|description|\"id\"" 

List IAM groups

# lists all groups (OCID, display name, description) in tenancy $T.
oci iam group list -c $T
# grep above command for important fields
oci iam group list -c $T | grep -E "name|description|\"id\"" 

List Users in a Group

The following command is helpful for listing users in groups, especially users with administrative privileges. This command requires the OCID of the group whose users are listed.

# list users in group with OCID <GROUP_OCID>
oci iam group list-users -c $T --group-id <GROUP_OCID>

List Security Policies

# lists all policies (OCID, name, statements) in tenancy $T. Remove pipe to grep to get entire information
oci iam policy list -c $T
# grep above command for important fields
oci iam policy list -c $T | grep -E "name|Allow|\"id\""