Cloud Guard and Security Zones: OCI's prevention layer is better than its detection layer

Oracle Cloud ships two security services that look similar and do opposite things. Cloud Guard detects: it evaluates your tenancy against recipes of detector rules and produces problems. Security Zones prevent: a compartment designated as a security zone refuses the creation of a resource that violates its policy.

The second one is the more interesting of the two, and it is underused because it arrives with a constraint that feels restrictive until you realise that is the point.

Security Zones: prevention as a compartment property

Designate a compartment as a security zone with a recipe, and OCI enforces the recipe at the API. Try to create a public bucket in it, and the call fails. Try to launch an instance with a public IP where the recipe forbids it, and the call fails. There is no finding to triage because the resource does not exist.

The Maximum Security Recipe covers the things that matter most:

• No public buckets, no public subnets for database resources.
• Resources must use customer-managed keys from OCI Vault.
• Databases and instances must be created from approved sources.
• Resources in the zone cannot be moved to a compartment outside it — which is the rule people forget and which is precisely what stops a quiet exfiltration by relocation.
• Block volumes and boot volumes must be encrypted with your keys and have backup policies.

The usual objection is that this is too rigid for a general-purpose compartment, and that is correct. The right use is targeted: designate the compartment holding regulated data as a security zone, and leave the rest under Cloud Guard detection. A small strictly-enforced zone is worth more than a large audited one.

Start with a less strict custom recipe if the maximum one blocks legitimate work, but do not start with nothing. The equivalent capability on other clouds — organisation policy constraints in GCP, Azure Policy in Deny mode — is the single control type that makes a posture improvement permanent rather than a remediation project that repeats next year.

Cloud Guard: enable it properly, then triage by exposure

Cloud Guard is free and should be enabled at the tenancy root with the reporting region set and all compartments in scope. Enable the OCI CIS benchmark recipe alongside the default one — it maps directly to what an auditor will ask about.

Then triage the problems the same way as on every other cloud: reachable from the internet and grants or exposes credentials first. Concretely, in a fresh OCI tenancy the list that matters is usually:

• Buckets with public access or long-lived pre-authenticated requests.
• Security lists or NSGs allowing 0.0.0.0/0 on SSH, RDP or database ports.
• Users with API keys and broad policies, and users without MFA.
• manage all-resources policies outside the Administrators group — the findings from OCI policies and dynamic groups.
• Instances with public IPs in compartments that should not have them.

Responder rules can act automatically on some problem types — disabling a public bucket, stopping an instance. Enable the ones whose action is unambiguously safe and leave the rest as notifications. An automatic responder that stops a production instance during a false positive teaches the team to turn responders off entirely.

Route the problems somewhere

Cloud Guard problems can publish to the OCI Events service and from there to Notifications, a Function or a Streaming topic. Wire high-risk problems to your on-call channel and everything else to tickets, and stop expecting anyone to open the console. This is the same lesson as turning GuardDuty into a rota someone answers, and it is the step that most often gets skipped.

The rest of the baseline

Cloud Guard and Security Zones do not cover everything. Alongside them:

• Audit logs are on by default with a retention period — extend it and export to a bucket in a compartment the workload teams cannot write to, with retention rules and object versioning.
• OCI Vault for keys and secrets, with a customer-managed master key for anything regulated.
• VCN flow logs and service logs to OCI Logging, and a saved search that someone can actually run during an incident.
• Vulnerability Scanning Service for instances and container images in OCI Registry, which is free and which nobody enables.
• Bastion service instead of jump hosts with public IPs, so SSH access is a time-limited session rather than an open port.

We work through this whole set in a security assessment, and the open-source scanners in our tooling piece cover OCI too if you want a second opinion before acting.

What to do this week

Enable Cloud Guard at the tenancy root with the CIS recipe, if it is not already. Then pick the one compartment holding your most sensitive data and read the Maximum Security Recipe against it — not to enable it yet, but to see how many of its rules you already satisfy. That gap list is your actual security backlog.