1. Well-architected framework for Oracle Cloud Infrastructure
  2. Manage Identities and Authorization Policies

Manage Identities and Authorization Policies

Oracle Cloud Infrastructure Identity and Access Management enables you to control who has access to your cloud resources. Credentials for access and authorization include API keys, sign-in password, federated sign-in, and authentication tokens. Use appropriate credentials to protect your cloud account and resources. Oracle encourages you to adopt the following recommendations when implementing identity management in the cloud.

Use Multi-Factor Authentication (MFA)

Enterprise Architect, Security Architect, Application Architect

Restrict access to resources to only users that have been authenticated through your enterprise's single sign-on solution, and a time-limited one-time password, or other suitable factor such as a biometric scan function.

With OCI Identity and Access Management (IAM) identity domains, MFA is configured and enforced in a predefined sign-on policy for OCI Console. This policy should not be deactivated.

You should require this at the user level and enforce it at the resources level through IAM. You can enforce MFA for a resource in the access policy that allows access to the resource.

MFA can also be configured for break-glass use cases when you need to give a user temporary elevated access to bypass regular access control to gain immediate access to critical systems.

Don't Use the Tenancy Administrator Account for Day-to-Day Operations

Enterprise Architect, Security Architect, Application Architect

Service-level administrators in the tenancy should be created to further limit administrative access. Service-level administrators should only manage resources of a specific service or domain.
For example, the following policy allows users in the VolumeAdmins group to manage only the resources in the block volumes family.
Allow group VolumeAdmins to manage volume-family in tenancy

Create Security Policies to Prevent Administrator Account Lock-out

Enterprise Architect, Security Architect

Create and protect an admin account specifically for use in case the tenancy administrator leaves your organization, or for some other emergency when no tenancy admins are available.

For example, create an Emergency User persona, with membership in the Administrators OCI group, not federated, and with local password only. This is sometimes referred to as a "Break glass" account.

Break glass refers to the processes and mechanisms used to obtain highly privileged access in the event of an IT emergency. The term is derived from the practice of placing an alarm trigger behind a protective glass pane, which serves as a physical barrier to prevent unauthorized, or non-emergency activation. In IT, break glass is used metaphorically to describe the need for full access privileges during a critical emergency that cannot be addressed within the established segregation of duties (SOD) and least-privileged access controls. The key features of an effective break-glass process are high availability, restricted access, risk assessment, expedited approval, short-lived entitlements, auditing, and regular testing. Even a well-designed access model may not account for all possible emergencies. In such cases, break glass provides a way to concentrate the highest level of access privileges into one or more break-glass accounts, transcending the established access model. The OCI Administrators Group can be used to grant break-glass access, along with an alternative entitlement option.

Restrict IAM Administrator Groups from Managing Default Administrators and Credential Administrators Groups

Enterprise Architect, Security Architect

Administrator permissions should follow the rule of least privilege, so membership to an Admin group or attachment to an Admin policy should be limited to an as-needed basis.

The following policy allows the users in the UserAdmins group to only inspect the groups in the tenancy. 

Allow group UserAdmins to inspect groups in tenancy

The out-of-the-box Tenancy Admin Policy should also not be altered.

Prevent Accidental or Malicious Deletion of (and Changes to) Access Policies

Enterprise Architect, Security Architect, Application Architect

For example, the following policy only allows users in the PolicyAdmins group to create policies, but not to edit or delete them. 
Allow group PolicyAdmins to manage policies in tenancy where
      request.permission='POLICY_CREATE'

Restrict credential administrators to managing only user capabilities and user credentials such as API keys, authentication tokens, and secret keys.

Use Multiple Identity Domains

Enterprise Architect, Security Architect

Use the default OCI Identity and Access Management identity domain for OCI Admins only.
  • For application workloads, use separate identity domains for each environment, such as development, test, and production.
  • Each domain can have different identity and security requirements to protect your applications and OCI services.
  • Using multiple identity domains can help you maintain the isolation of administrative control over each identity domain. Multiple identity domains are required, for example, when your security standards prevent user IDs for development from existing in the production environment. Multiple domains are also used when you require different administrators to have control over various environments.

Federate Oracle Cloud Infrastructure Identity and Access Management

Enterprise Architect, Security Architect, Application Architect

Where possible and relevant, federate Oracle Cloud Infrastructure Identity and Access Management with your organization's centralized identity provider (IdP).
  • Create a federation administrators group that maps to the federated IdP's administrator group and is governed by the same security policies as the federated IdP's administrator group.
  • Create local users and assign the users to the default Administrators, IAM Administrators, and Credential Administrators IAM groups. Use these users for break-glass type scenarios (for example, inability to access resources through federation).
  • Define a policy to prevent the federated administrators IAM group from modifying the membership of the default tenancy Administrators groups.
  • Detect unauthorized access and operations by monitoring the audit logs for operations by tenancy administrators and changes to the Administrators groups.

Monitor and Manage the Activities and Status of All Users

Enterprise Architect, Security Architect, Application Architect

Monitor and manage the activities and status of all users.
  • When an employee leaves the organization, disable access to the tenancy by deleting the user immediately.
  • Enforce rotation of the user password, API keys, and and all authentication-related user capabilities, every 90 days or less.
  • Ensure that Identity and Access Management (IAM) credentials are not hard-coded in any of your software or operations documentation.
  • Create an IAM user for everyone in the organization who needs access to resources in the tenancy. Don't share an IAM user across multiple human users.
  • Implement federated single sign-on to streamline access to multiple applications and centralize authentication.
  • Review the users in IAM groups periodically, and remove users that no longer need access.

Learn More