Skip to content
Security guide

Secure OCI Architecture: Reference Design and Checklist

A secure OCI architecture puts structure and guardrails in before the workloads. Oracle's tenancy roadmap describes the order: define a security model, then identities, compartments and policies, then optional security zones and Cloud Guard, then keys and secrets in Vault, then networks and storage, and finally periodic review of Audit logs.

This guide draws that design, explains each area in plain words, and ends with a decision checklist. Every claim comes from Oracle Cloud Infrastructure documentation read on 4 November 2026. We did not find a single Oracle page that prescribes a full landing zone layout, so the compartment names in the diagram are ours.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

5 points
  • Oracle's "Securing Your Tenancy" page gives a ten-step order: security model, identities, compartments and policies, security zones, Cloud Guard, Vault, networks, storage, other services, then Audit review.
  • Structure: compartments by project or business unit; keep resources out of the root; keep Administrators small.
  • Identity: federate, enforce MFA with an activated sign-on policy, scope policies to compartments, use dynamic groups for resources.
  • Guardrails: Cloud Guard detects, security zones prevent. Network: NSGs, private subnets, NAT and service gateways, Bastion.
  • Data: private buckets with expiring pre-authenticated requests, Vault keys in the same region. Logging: Audit reviewed, service logs on, Connector Hub for routing.

The reference architecture

Read the figure from the top: identity, policy, Cloud Guard and Audit belong to the tenancy, shared services sit in their own compartment, and the production compartment that holds sensitive data sits inside a security zone.

Reference architecture for a secure Oracle Cloud Infrastructure tenancyA tenancy root compartment holds IAM, an identity domain federated to an identity provider with MFA, Cloud Guard and Audit. Under it are compartments for shared network, security and logging services, a production compartment inside a security zone, and a non-production compartment. The production compartment contains private subnets with network security groups, an Object Storage bucket and a database using keys from a Vault. A bastion, NAT gateway and service gateway connect the private subnets. Audit and service logs flow through Connector Hub to a logging compartment.Tenancy (root compartment): IAM, policies, Cloud Guard, AuditIdentity providerSSO, MFAIdentity domainfederation, sign-on policyIAM policiesgroups to compartmentsCloud Guarddetector recipesCompartment: shared servicesNetworkVCN hubBastiongatewaysSecurityVault, keyssecretsSecurity zone: production compartmentPrivate subnetsapp + data tiersNSGs name NSGsas rule sourcesObject Storageprivate bucketsexpiring pre-authrequests onlyDatabaseencrypted withcustomer-managedVault keykeys used by services in the same regionCompartment: non-productionNo production data, same policypatterns, its own networkCompartment: loggingAudit and service logs in log groups, Connector Hub archives toObject Storage or forwards to analysis toolsPlayCISO illustration. Compartment names are illustrative; Oracle does not prescribe them on the pages we read.
Figure 1. Reference architecture. The pieces (compartments, identity domain federation, Cloud Guard, a security zone, NSGs, private subnets with gateways and Bastion, Vault keys, Audit and Logging) come from the Oracle pages cited below; the layout and names are our illustration.

Design areas and where Oracle documents them

The table maps each design area to the Oracle pages behind it. Oracle's Well-Architected Framework overview lists security and compliance focus areas such as authentication and authorization, resource isolation and access control, network security and environment monitoring and auditing; the mapping of our areas to them is loose and ours.

AreaWhat to doSource
Tenancy structureCreate compartments by project or business unit and keep resources out of the root.IAM overview, Managing compartments
IdentityFederate with your identity provider, enforce MFA with an activated sign-on policy, keep Administrators small.Identity domains, IAM overview
AuthorizationWrite policies for specific verbs and resource types in a compartment; use dynamic groups for resources.Policy basics, Dynamic groups
DetectionEnable Cloud Guard with detector recipes and triage problems.Cloud Guard
PreventionPut sensitive compartments in a security zone; let it deny non-compliant operations.Security Zones
NetworkUse NSGs, private subnets, NAT and service gateways, and Bastion for admin access.Security rules (NSGs, security lists), Networking overview, Bastion
Data and keysPrivate buckets, expiring pre-authenticated requests, versioning, Vault keys in the same region.Object Storage buckets, Vault / Key Management
LoggingReview Audit periodically; enable service logs; route with Connector Hub.Audit, Logging

Tenancy structure and compartments

Oracle describes the tenancy as the root compartment that contains all your resources, with IAM entities directly inside it and other resources placed in compartments you create. Compartments separate resources for usage and billing, access through policies and isolation (IAM overview). Access is granted at the group and compartment level, and a group given access to the tenancy gets the same access to every compartment inside it, so tenancy-wide grants deserve care. The first step of the tenancy roadmap is a security model that decides how many compartments, how many administrators and which roles (Securing your tenancy).

Identity and authorization

An identity domain is a container for a user population with security settings such as MFA. When you federate with an identity provider, you manage users and groups there and authorization in OCI IAM. A sign-on policy sets whether users may sign in and must be activated to be enforced (Identity domains).

The Administrators group has a built-in policy, “Allow group Administrators to manage all-resources in tenancy”, that you cannot change or delete, so control its membership (IAM overview). For everyone else, a policy statement names a verb, a resource type and a location, and a compartment-scoped statement applies only there (Policy basics). For machines, dynamic groups use matching rules to group resources such as instances so that policies can permit their API calls, which avoids keys stored on disk.

Cloud Guard and Security Zones

Cloud Guard examines resources for configuration weaknesses and operators and users for risky activity. Oracle-managed detector recipes cover activity, configuration, instance security, container security and threats, user-managed recipes are clones you can tune, and problems are fixed, resolved or dismissed. Some responders need specific policy statements.

Security Zones associate a compartment with a recipe of policies; any create or update that violates one is denied, whoever performs it. Oracle describes principles such as no public internet reach, customer-managed keys and regular backups. The Maximum Security Recipe cannot be modified, and custom recipes are possible. Enable Cloud Guard first. A zone blocks new and changed operations only, and Cloud Guard, through the zone target, detects violations in existing resources.

Network

Oracle recommends network security groups over security lists, and a rule in an NSG can name another NSG in the same VCN as its source. Rules from both are combined as a union for a VNIC. A new subnet is public by default, and a private subnet cannot give VNICs public IPv4 addresses; an internet gateway alone does not expose instances unless several other conditions are met, including a public subnet, a route rule, a public IP and allowing security rules (Networking overview). Use a NAT gateway for outbound-only access and a service gateway for private traffic to services like Object Storage. OCI Bastion provides restricted, time-limited access to targets without public endpoints.

Data protection and keys

Buckets are private by default. Oracle says anonymous access lets any user get object metadata and download objects, recommends pre-authenticated requests instead, and notes that buckets in a security zone cannot be public. Versioning protects against overwrite or deletion and retention rules give immutable storage (Object Storage buckets).

In Vault, master encryption keys are HSM or software protected, a choice that cannot change after creation. Rotation creates a new key version while older versions still decrypt old data; automatic rotation is available only for private vaults, with an interval of 60 to 365 days. Integrated services can use a key only when the service and vault are in the same region.

Logging and audit

Audit automatically records calls to supported public API endpoints; for Object Storage it covers bucket-related events but not object-related ones. The tenancy roadmap asks you to review Audit logs periodically (Securing your tenancy). The Logging service adds service logs, such as Object Storage read and write events and VCN flow logs, organizes them in log groups and integrates with Connector Hub for archiving to Object Storage or forwarding elsewhere.

Decision checklist

Answer each with yes, partly or no. Every “no” is a design decision to make. For a scored version with per-domain gaps and export, use the OCI Security Checklist.

  1. Do workloads live in compartments that follow projects or business units, with nothing important in the root compartment?
  2. Is the Administrators group limited to the people who need tenancy-wide control?
  3. Do people sign in through your identity provider, with an activated sign-on policy that requires MFA?
  4. Are policies scoped to a compartment and to specific resource types, with all-resources grants rare and reviewed?
  5. Do resources that call OCI APIs use dynamic groups instead of long-lived keys on disk?
  6. Is Cloud Guard enabled, and does a named person triage its problems?
  7. Are sensitive compartments in a security zone, and have older resources been checked for violations?
  8. Do application tiers use NSGs with an NSG as the source, and have you reviewed security lists as well, since the rules are a union?
  9. Are databases and internal services in private subnets, with NAT, service gateway and Bastion in place of public access?
  10. Is every public bucket documented with an owner, and do shares use expiring pre-authenticated requests?
  11. Are keys in Vault, in the same region as the services that use them, with a rotation plan and a deliberate protection mode?
  12. Is Audit reviewed on a schedule, and are Object Storage read and write logs and VCN flow logs enabled where needed?
  13. Have you rehearsed the response to a leaked API key or a public bucket?

What this guide does not claim

  • The compartment layout in the diagram is illustrative. Oracle's pages we read do not prescribe one, and the maximum depth of nested compartments was not stated on the pages we read, so we give none.
  • The pages do not state a last-updated date in the text we read, so none is claimed. Last reviewed 4 November 2026.
  • The Audit and Logging pages we read did not state retention periods, so we give none. We did not read OCI's landing zone repository or per-service security pages in the best-practices index, which the index links to.
  • This is not the CIS benchmark (CIS Oracle Cloud benchmark (pointer) is a pointer only; we did not read it) and not a compliance opinion.

Frequently asked questions

What is a secure OCI architecture?

It is an Oracle Cloud Infrastructure tenancy where structure and guardrails come before workloads: compartments that follow the business, a small Administrators group, federated sign-in with MFA, policies scoped to compartments, Cloud Guard for detection, Security Zones as a hard boundary for sensitive compartments, private networks, Vault-managed keys and Audit and Logging reviewed on a schedule.

What do Oracle's own docs say to do first?

Oracle's "Securing Your Tenancy" page gives a ten-step roadmap: define a security model, optionally provision identity domains, provision users, groups, compartments and policies, optionally provision security zones, optionally enable Cloud Guard, provision keys and secrets in Vault, secure the networks, secure storage, secure other services, and review Audit logs periodically.

What is the difference between Cloud Guard and Security Zones?

Cloud Guard detects: it examines resources for configuration weaknesses and operators and users for risky activity and reports problems. A security zone prevents: it denies any operation that violates the policies of its recipe. Oracle requires Cloud Guard to be enabled before you create a zone, and Cloud Guard finds violations in resources that existed before the zone.

Should I use network security groups or security lists?

Oracle recommends NSGs because they separate the subnet architecture from application security requirements, and says it prioritizes them for future enhancements. If you use both, a VNIC gets the union of the rules from its subnet security lists and its NSGs.

Is a public bucket ever acceptable?

Oracle says to assess the business need carefully, because anonymous access lets any user obtain object metadata and download objects, and recommends pre-authenticated requests instead. Buckets in a security zone cannot be public. Treat a public bucket as an exception with an owner and an end date.

Is this the same as CIS compliance?

No. The CIS Oracle Cloud Infrastructure Foundations Benchmark is a separate, versioned checklist; we point to its CIS page and did not read its contents. This guide is design guidance. Use the OCI Security Checklist for a quick gap review.

Sources

🖤 Black Friday: new customers get 3 months of Pro for $5, then $5/month. Ends 30 Nov. Claim 3 months for $5 →