OCI Security Checklist: Score Your Oracle Cloud

Workloads live in compartments organized by project or business unit, not in the root compartment (the tenancy).

A security model was defined up front: number of compartments, number of administrators, and administrative roles and permissions.

Shared services (network, security, logging, keys) sit in their own compartments separate from workloads.

Compartments and resources carry an owner and environment label so findings reach someone.

Membership of the Administrators group is limited to the few people who need tenancy-wide control.

Policies grant specific verbs on specific resource types in a compartment, and tenancy-wide or all-resources statements are rare and reviewed.

People sign in through a federated corporate identity provider, so joiners and leavers are managed in one place.

Multifactor authentication is enforced through an identity domain sign-on policy that is activated, not just created.

Compute instances and other resources that call OCI APIs use dynamic groups and policies rather than long-lived API keys stored on them.

Users, groups and policies are reviewed on a schedule and access is removed when it is no longer needed.

Cloud Guard is enabled for the tenancy, using detector recipes, and problems have owners and a triage routine.

Responders are enabled deliberately, with the policies they need, rather than all at once.

Compartments with sensitive data are in a security zone with a recipe that fits (Maximum Security Recipe or a custom one).

Resources that existed before a zone was created were checked for violations through Cloud Guard.

Application access rules use network security groups, with an NSG as the source where tiers talk to each other.

You know that rules from security lists and NSGs combine as a union, and review both when checking exposure.

Databases and internal services are in private subnets; public subnets hold only what must be reachable.

Outbound access for private resources uses a NAT gateway, and traffic to OCI services such as Object Storage uses a service gateway.

Administrative access to private targets goes through OCI Bastion or an equivalent time-limited path, not public SSH.

No bucket is public without a documented business reason, and sharing uses pre-authenticated requests with expiry.

Existing pre-authenticated requests are inventoried and reviewed, including those created before a bucket was made private.

Object versioning and retention rules protect records that must not be lost or overwritten.

Sensitive data is encrypted with keys you manage in Vault, in the same region as the service that uses them.

Key protection mode (HSM or software) was chosen on purpose, knowing it cannot be changed after creation.

Keys are rotated on a schedule, and old key versions are kept until data they protect is re-encrypted.

Credentials live as secrets in Vault, not in files or scripts.

Audit logs are reviewed periodically by someone who can act on what they see.

Service logs are on where they matter, including Object Storage read and write events and VCN flow logs.

Logs are organized in log groups and archived or forwarded with Connector Hub.

Only a small group can change Audit retention and view logs, and that access is itself reviewed.