Oracle Cloud Infrastructure Security Guide: IAM, Network and Tenancy Controls

Oracle Cloud Infrastructure (OCI) denies everything by default, so every exposure in an OCI tenancy traces back to a policy statement, a group membership or a credential that someone created. That makes OCI security largely an identity exercise: who sits in the tenancy Administrators group, how compartments divide the estate, which dynamic groups let instances and functions call OCI APIs, and how many API signing keys and auth tokens exist for users that are really automation. This guide explains how OCI IAM, identity domains, compartments and policies fit together, how to treat dynamic groups and user credentials as non-human identities, and how Cloud Guard, Security Zones, Vault and the Audit service form a hardening and detection baseline. It is written for cloud security engineers and architects running OCI alongside other clouds, and draws on Oracle's own documentation.

Key takeaways

• Policies only allow. OCI has no deny statement in IAM policy: access that no statement grants is refused, so least privilege means writing fewer and narrower Allow statements, and Security Zones provide the deny-style guardrails.
• The Administrators group is the crown jewel. Its tenancy policy grants everything and cannot be changed or deleted, so membership must be minimal, MFA protected and monitored.
• Dynamic groups are NHIs. Matching rules decide which instances, functions and other resources can call OCI APIs; a broad rule or a tag-based rule can quietly grant a whole compartment's workloads the same rights.
• User credentials are often automation in disguise. API signing keys, auth tokens, customer secret keys, SMTP credentials and OAuth 2.0 client credentials attached to users need the same inventory and rotation as service accounts elsewhere.
• Cloud Guard and the Audit service are the detection backbone. Cloud Guard needs a target on the root compartment to monitor IAM policies, and its notifications only flow from the reporting region.

How identity and access work in OCI

• Tenancy: the root compartment that contains all OCI resources. Its IAM entities include users, groups, compartments and policies.
• Compartments: the unit for organising resources and scoping policy. A policy can be written at the tenancy level or inside a compartment. To see what affects a compartment, read every statement in the tenancy's policies and in the compartment's own policy path; sibling compartments' policies cannot refer to it.
• Identity domains: a container for users and roles, federation and provisioning, Oracle Single Sign-On configuration for applications, and OAuth administration. MFA and sign-on policies are security settings of the domain. A sign-on policy is not enforced until it is activated.
• Policies: statements in the form Allow group <group-name> to <verb> <resource-type> in compartment <name> (or in tenancy), with optional where conditions. The verbs inspect, read, use and manage grant increasing privilege.
• Administrator roles: IAM evaluates policies and identity domain administrator roles together. Oracle recommends administrator roles for identity domain administration; a domain administrator role in a non-default domain gives full control of that domain only, not the tenancy.

The equivalence column is an approximation for orientation, not a feature match. For cross-cloud identity design see the Multi-Cloud Identity Guide.

Admin roles and privileged access

• Administrators group: membership lets a user do anything with any resource, and the Tenant Admin Policy that grants it comes with the tenancy and cannot be changed. Keep it to named break-glass and platform owners, all federated or MFA protected.
• Service-level administrators: Oracle's IAM security guidance recommends creating service-level administrators for least privilege, for example a network admin group with manage virtual-network-family in a network compartment, rather than adding people to Administrators.
• Protect the protectors: Oracle documents policy patterns that stop service administrators from changing Administrators group membership or deleting and updating security policies. Write these with where conditions and test them in a sandbox tenancy before production.
• Identity domain administrators: at least one administrator of a non-default domain must hold the identity domain administrator role directly, not only through a group. Track these assignments as privileged access.
• Federation: Oracle advises federating Console logins. Federated users cannot have an OCI Console password, which removes one credential to manage.

Treat all of these as privileged access in your PAM and CIEM process. See the Cloud PAM and CIEM Guide.

Integrations, API tokens and service accounts

Dynamic groups: workload identity in OCI

Dynamic groups let compute instances and other resources act as principals. Members are defined by matching rules and change automatically as resources are launched and terminated; policies then grant the group rights to call OCI services. This removes stored API keys from instances and functions, but the rule is now the access boundary.

• Rule syntax: a single condition (instance.compartment.id = '<compartment_ocid>') or Any {...} / All {...} lists of conditions.
• Variables: instance.id, instance.compartment.id, resource.id, resource.compartment.id, resource.type (for example fnfunc or apigateway) and defined tags tag.<namespace>.<key>.value. Free-form tags are not supported.
• Prefer narrow rules: All {resource.type = 'fnfunc', resource.compartment.id = '<ocid>'} is narrower than every instance in a compartment, and a specific resource.id is narrower still.
• Treat tag rules as delegated access: anyone who can set the matched defined tag on a resource can bring it into the group. Restrict use of that tag namespace.
• Grant the group little: for example Allow dynamic-group app-fn to read secret-family in compartment prod-app rather than manage all-resources.

User credentials used by automation

For non-human systems Oracle describes creating a user with an uploaded public key and no Console password. Those users are service accounts: give each one an owner, a purpose and a single narrow group. See the Cloud Workload Identity Guide and the Top 10 NHI Risks.

Vault and secrets

• Vault types: a virtual private vault is an isolated HSM partition with backup; a default vault shares partitions. The type cannot be changed later.
• Key protection: HSM-protected keys never leave the HSM (FIPS 140-2 Security Level 3); software-protected keys can be exported. Protection mode is fixed at creation.
• Key rotation: automatic key rotation, in private vaults only, runs every 60 to 365 days; older versions can still decrypt.
• External keys: External KMS (hold your own key) keeps key material outside OCI for residency or sovereignty requirements.
• Secrets: Oracle has moved secrets functionality to its Secret Management Service; secret versions are encrypted by a master encryption key and not stored in the HSM. For cross-cloud comparison see the Cloud Secrets Managers Guide.

Logging and detection

• Audit service: records calls to supported OCI public API endpoints, from the Console, CLI, SDKs and other services, with target resource, timestamp, request and response parameters. Object Storage logs bucket events but not object events, so enable service logs for object access where it matters. Oracle's retention page states audit logs are kept for 365 days; confirm the value on your tenancy details page.
• Watch IAM changes: Oracle advises periodically monitoring Audit logs for changes to IAM users, groups and security policies. Prioritise Administrators group membership, new policies with manage all-resources, new API keys, auth tokens and customer secret keys, and dynamic group rule changes.
• Cloud Guard: detector recipes (Configuration, Activity, Threat, Container Security Config and Instance Security) raise problems; responder recipes act on them. A target covers a compartment and its children until another target is met, targets cannot overlap, and the root compartment must be a target to monitor IAM policies.
• Reporting region: the first region set when Cloud Guard was enabled. Notifications and Events integration only work there, and configuration must be done there, not in the home region.
• Recipes: Oracle-managed recipes can change at any time and their rule settings cannot be edited; clone them into user-managed recipes to tune risk levels and disable noisy rules, accepting that you then own the tuning.

Forward Audit and Cloud Guard output to your SIEM. See the Cloud Logging and Audit Trail Guide.

Metrics:

• Number of Administrators group members (target: a handful, all named and MFA or federated).
• Percentage of human users signing in through federation or with MFA.
• Count of API signing keys, auth tokens and customer secret keys older than your rotation period.
• Percentage of workloads using dynamic groups instead of stored user API keys.
• Open Cloud Guard problems by risk level and median time to resolve.
• Percentage of production compartments inside a Security Zone.

Hardening baseline

Security Zones

A Security Zone binds one or more compartments to a recipe and denies create and update operations that violate it, regardless of who performs them. The Oracle-managed Maximum Security Recipe cannot be modified; custom recipes can. Policies include no public Object Storage buckets, encryption with customer-managed keys, no public internet access to resources, no moving resources or copying data out of the zone, and regular automatic backups. Zones do not fix resources that already violate policy; Cloud Guard scans and reports those. Creating a zone replaces any existing Cloud Guard target on that compartment, so enable Cloud Guard first.

Phased rollout

1. Baseline identity: list Administrators members, identity domain administrators, every policy with manage all-resources or in tenancy, every dynamic group rule, and every user credential. Assign an owner to each.
2. Federate and enforce MFA: configure federation and activate the sign-on policy in a pilot group, keep one tested break-glass account outside federation, then extend to all users.
3. Design compartments: separate network, security, production and non-production workloads into compartments, with service-level admin groups per compartment.
4. Enable Cloud Guard: target the root compartment, choose the reporting region deliberately (it carries the legal jurisdiction of where it is hosted), start with Oracle-managed recipes and responders in notify-only mode.
5. Introduce Security Zones: start with a new compartment for a new workload, then move existing production compartments once Cloud Guard shows no violations. Roll back by removing the zone, which restores normal create and update behaviour.
6. Replace user keys with dynamic groups: migrate one workload at a time, confirm it works with the dynamic group policy, then delete the old API key.
7. Turn on automatic responders only for problems with a clear, reversible fix, and review them monthly.

Decision guidance

• Small tenancy: a few compartments, Oracle-managed recipes, Maximum Security Recipe on production, and federation from day one.
• Large or regulated tenancy: a compartment hierarchy per business unit and environment, cloned recipes tuned per target, custom Security Zone recipes, private vaults with HSM keys, and External KMS where keys must stay outside OCI.
• Policies or domain roles: use administrator roles for identity domain administration, as Oracle recommends; use policies for OCI resources.

Common misconfigurations

• Daily work in Administrators: platform engineers in the Administrators group because it is easiest; one phished session controls the tenancy.
• Policies at tenancy scope: Allow group devs to manage all-resources in tenancy written for a proof of concept and never narrowed.
• Broad dynamic groups: every instance in a large compartment, or a tag-based rule on a tag anyone can set, given manage rights.
• Service accounts as users with keys: long-lived API signing keys and customer secret keys on users that represent pipelines, with no owner or rotation. Leaked keys of this kind drive campaigns such as the 230 Million AWS Cloud Environments Campaign 2024 in other clouds.
• Cloud Guard not on root, or watched from the wrong region: IAM policy changes go unmonitored, or alerts never reach the SOC.
• Ignoring legacy identity estates: the Oracle Cloud Breach Claim 2025 centred on login servers that Oracle reportedly told customers were obsolete Oracle Cloud Classic (Gen 1) systems, not OCI; Oracle publicly said there had been no breach of Oracle Cloud. Whatever the final facts, the claimed data (keystores, key files and encrypted SSO and LDAP passwords) is exactly the material to rotate when a provider's identity tier is in question. Rotate federation certificates and service credentials and review sign-in logs when such a claim surfaces. See the Leaked Credential Response Playbook.

Framework mapping

Practitioner checklist

• Reduce Administrators group membership to named break-glass and platform owners, all federated or MFA protected.
• Activate sign-on policies with MFA in every identity domain and federate Console access.
• Replace tenancy-wide manage policies with service-level admin groups scoped to compartments.
• Review every dynamic group matching rule; narrow by resource type, compartment or OCID and restrict tag namespaces used in rules.
• Inventory API signing keys, auth tokens, customer secret keys and OAuth clients; assign owners, rotate, delete unused.
• Enable Cloud Guard with a root target, confirm the reporting region feeds your SIEM, and tune cloned recipes.
• Place production compartments in Security Zones after clearing existing violations.
• Use private vaults and HSM keys for regulated data, with automatic key rotation configured.
• Alert on Administrators membership changes, new credentials on users and policy edits from the Audit service.

Standards and references

• Oracle: Getting Started with Policies
• Oracle: Writing Matching Rules to Define Dynamic Groups
• Oracle: Managing User Credentials
• Oracle: Cloud Guard Concepts
• Oracle: Security Zones Overview
• Oracle: Key Management Overview
• Oracle: Audit Overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Cloud Security Guide · Cloud PAM and CIEM Guide · Multi-Cloud Identity Guide · Container Image Security Guide · Top 10 NHI Risks