OCI Cloud Guard and Security Zones: Hardening Guide

Oracle Cloud Guard and Security Zones are the two native guardrails in Oracle Cloud Infrastructure, and most tenancies that enable them still leave gaps: Cloud Guard watching the wrong scope, responders that nobody dares to switch on, and zones that were never applied to production. Cloud Guard is detective: detector recipes raise problems, and responder recipes can act on them. Security Zones are preventive: they deny create and update operations that break a recipe of deny policies, whoever makes the call. This guide goes deeper than the overview in the Oracle Cloud Infrastructure Security Guide: it covers the IAM policy model for both services, who should administer them, the service permissions responders need, the event and log flow into a SOC, a hardening baseline with rule names, and the misconfigurations that quietly disable the protection. It is for cloud security engineers and platform teams running OCI tenancies. Rule and policy names are taken from Oracle's documentation as checked in October 2026; Oracle adds detector rules over time, so confirm names in your console.

Key takeaways

Prevention and detection are separate jobs. Security Zones block non-compliant new changes; Cloud Guard finds resources that already violated policy before the zone existed, and flags risky activity that no zone policy covers.
Both services sit under one IAM resource family. Security Zones resource types are part of cloud-guard-family, so a group with manage cloud-guard-family in tenancy can change detectors, responders and zones alike. Keep that group small.
Responders change your estate with Cloud Guard's own service permissions. Remediation rules need statements such as allow service cloudguard to manage policies in compartment, which makes Cloud Guard a powerful non-human identity. Grant them per compartment, not tenancy-wide.
The reporting region is the control point for alerts. Events rules and notifications for Cloud Guard must be built in the reporting region, which is not necessarily the home region. Alerts built elsewhere never fire.
Creating a zone rewrites Cloud Guard targets. A new security zone deletes existing Cloud Guard targets on that compartment and its children and creates a security zone target with default Oracle-managed detector recipes, so tuned recipes must be reattached.

How identity and access work in OCI Cloud Guard and Security Zones

Cloud Guard and Security Zones are governed by ordinary OCI IAM policy statements written against the cloud-guard-family aggregate resource type and its members. OCI IAM is allow-only, so access to these services is whatever your policy statements grant. Security Zones then add a deny layer that applies to everyone, including tenancy administrators, for operations inside a zone. Cloud Guard is not available on free tenancies: Oracle requires a paid tenancy with account type default_dbaas, enterprise_dbaas or enterprise.

Resource type	What it controls	Typical grant
`cloud-guard-family`	All Cloud Guard and Security Zones resources: targets, recipes, problems, zones, zone recipes	`manage` for a named security engineering group only; `read` for the SOC
`cloud-guard-config`	Enabling or disabling Cloud Guard and the reporting region (tenancy scope only)	`inspect` for readers (otherwise they are redirected to the Enable page); `use` or `manage` for the few people who may switch the service on or off
`cloud-guard-targets`	Which compartments are monitored and with which recipes	Scope to a compartment so local teams can only act within it; only the root administrator should delete targets
`cloud-guard-detector-recipes`	Detector rules, risk levels and conditions	`read` for auditors; changes through the security engineering group
`cloud-guard-problems`	Problems raised by detectors, and their lifecycle (resolve, dismiss)	`read` for SOC analysts; `use` or `manage` for the team that triages
`cloud-guard-risk-scores`, `cloud-guard-security-scores`	Tenancy risk score and security score views	`inspect` for managers and reporting

Oracle's sample read-only policy for a SOC team that sees everything is two statements: allow group cgreadgroup to read cloud-guard-family in tenancy and allow group cgreadgroup to read compartments in tenancy. A compartment-scoped reader needs read cloud-guard-family in compartment <name>, read compartments in tenancy where target.compartment.name = '<name>' and inspect cloud-guard-config in tenancy. For groups outside the default identity domain, prefix the group name with the domain name and a forward slash, for example <domain>/CloudGuardUsers. If you federate from an external identity provider, map the IdP group to the OCI group rather than adding users directly. The wider OCI IAM model (identity domains, compartments, dynamic groups) is covered in the Oracle Cloud Infrastructure Security Guide.

Admin roles and privileged access

Cloud Guard holds a tenancy-wide view of security weaknesses, and Oracle advises that it should be available to a restricted audience. Whoever administers it can also weaken it: disable detector rules, lower risk levels, detach a target, or remove a security zone so that public buckets become possible again. Treat these as privileged operations.

Role (suggested group)	Policy scope	Can do	Should not do
Security platform administrators (CloudGuardUsers)	`manage cloud-guard-family in tenancy`	Enable Cloud Guard, set the reporting region, clone and tune recipes, create zones and zone recipes	Daily triage; use a separate analyst group for that
SOC analysts	`read cloud-guard-family` plus `use` on problems	View problems, resolve or dismiss with a reason, run queries	Edit recipes or targets
Compartment owners	Read problems in their compartment only	See and fix findings for their workloads	See other business units' problems
Auditors	`read` on detector recipes, problems, compartments; `inspect cloud-guard-config`	Evidence that detectors and zones exist and are enforced	Any change
Tenancy administrators	Administrators group	Break-glass recovery, target deletion	Routine Cloud Guard work under a tenancy admin account

Separate who can turn it off: use or manage on cloud-guard-config lets a user disable Cloud Guard. Restrict it to two or three named administrators and alert on it (see Logging and detection).
Watch for admin sprawl with Cloud Guard itself: the configuration detector rule "Tenancy admin privilege granted to group" flags groups other than Administrators holding tenancy admin rights, and "Policy gives too many privileges" flags admin-level statements outside approved groups. Add approved group OCIDs in the rule's input settings rather than disabling the rule.
Zone removal is a privileged change: removing a compartment from a zone restores normal create and update behaviour. Require a change ticket and a second approver, and keep the custom recipe definitions in source control.
Use break-glass accounts sparingly: keep tenancy administrator credentials for emergencies only. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Three non-human identities matter here: Cloud Guard's own service principal, the automation that manages Cloud Guard and zones as code, and the functions that receive Cloud Guard events.

Cloud Guard service principal: detectors read configuration, but responders of type REMEDIATION need write permissions. Oracle lists statements of the form allow service cloudguard to manage instance-family in compartment <name>, and the same for object-family, buckets, users, policies and keys. Grant only the families your enabled responders use, per compartment. A statement that lets Cloud Guard manage users and policies across the tenancy is a high-value permission if a responder is misconfigured.
Infrastructure as code: manage targets, cloned recipes and zone recipes through Terraform or the CLI, run by a pipeline identity. The CLI names follow the service, for example oci cloud-guard responder-recipe-responder-rule update, and the API operation UpdateResponderRecipeResponderRule. Give the pipeline manage cloud-guard-family only in the compartments it owns, and prefer instance or resource principals over user API signing keys. See the Cloud Landing Zone Security Guide.
Event-driven functions: Oracle's sample OCI Function receives Cloud Guard events and uses a resource principal signer (oci.auth.signers.get_resource_principals_signer()) to write problem details to Object Storage or call a ticketing or SIEM system. That function's dynamic group needs only the write access it uses; do not reuse a broad automation group.
Credential findings feed your NHI programme: configuration rules such as "User has API keys", "API key is too old" (90 days by default), "IAM Auth Token is too old", "User has Auth Token capability" and "User has Customer Secret Key capability" are effectively an inventory of user-bound machine credentials. Route them to whoever owns the Detection Engineering for Non-Human Identities Guide process rather than closing them as noise.

Logging and detection

Cloud Guard turns findings into problems, but a SOC needs them as events in its own pipeline. The supported path is the Cloud Event responder rule, which is enabled by default and needs no extra IAM policy, followed by an Events rule and a Notifications topic or a Function. Oracle states that Events and Notifications must be set up from the Cloud Guard reporting region, which aggregates problems from monitored regions. The reporting region is shown under Cloud Guard Settings.

Event type	Use it for	Example filter
`com.oraclecloud.cloudguard.problemdetected`	New problems to the SIEM or ticketing	`riskLevel` for critical problems
`com.oraclecloud.cloudguard.problemdismissed`	Review dismissals; a spike can mean someone is hiding findings	All, to a low-volume review queue
`com.oraclecloud.cloudguard.problemremediated`	Evidence of fixes, including automatic responder actions	`status` RESOLVED
`com.oraclecloud.cloudguard.sightingdetected`	Threat detector sightings for hunting	All
`com.oraclecloud.cloudguard.status`	Service tampering	`status` = `CLOUDGUARD_DISABLED` as a high-severity alert
`com.oraclecloud.cloudguard.announcements`	New detector rules added by Oracle	`announcement` = `DETECTOR_RULE_ADDED`

For the Cloud Event rule to emit events automatically, its rule trigger on the target must be set to execute automatically and confirmed; if it is left as "Ask me before executing rule", events wait for a human. Verify the flow by checking the Responder Activity page for the Cloud Event rule with status Succeeded. Security Zones API calls are served from Cloud Guard endpoints and recorded by the OCI Audit service, so zone creation, recipe edits and compartment removal appear in Audit logs. Forward Audit through Connector Hub to the same SIEM; see the Cloud Logging and Audit Trail Guide.

Detections worth building on top of Cloud Guard output:

Defence impairment: Cloud Guard disabled, detector rules disabled in a cloned recipe, a target deleted, or a compartment removed from a zone. These map to MITRE ATT&CK T1685 Disable or Modify Tools.
Credential abuse: the activity rule "Local user authenticated without MFA" (HIGH by default) and "Suspicious Ip Activity" (CRITICAL), correlated with Audit sign-ins. These map to T1078.004 Cloud Accounts.
Credential persistence: "IAM API keys Created", "IAM Auth Token Created" and "IAM OAuth 2.0 credentials created" are disabled by default. Enable them for tenancies with few human users, because a new key on an existing user is a classic persistence step (T1098.001 Additional Cloud Credentials).
Data exposure: "Bucket is public" (CRITICAL) and "PAR exists for a bucket" (HIGH) cover T1530 Data from Cloud Storage; pre-authenticated requests are bearer links and should be rare and short-lived.

Hardening baseline

Apply the baseline in this order, because each step depends on the one before. Security Zones require Cloud Guard to be enabled first.

Prepare IAM. Create the administrator, analyst and auditor groups with the statements above, map IdP groups, and add inspect cloud-guard-config for every reader.
Enable Cloud Guard with a root target. Choose the reporting region deliberately, attach Oracle-managed configuration and activity detector recipes, and attach the responder recipe with only the Cloud Event rule executing. Oracle's CIS compliance script (cis_report.py, certified for the CIS OCI Foundations Benchmark v3.0.0) checks that Cloud Guard is configured at the root compartment with detectors and responders, which gives you an independent test.
Wire events before tuning. Build the Events rules in the reporting region and confirm that a test problem reaches the SIEM. Run in this notify-only mode for two to four weeks.
Clone and tune. Oracle-managed recipes allow few changes; user-managed (cloned) recipes allow enabling and disabling rules and conditions while keeping ties to the Oracle recipe. Tune with conditions (approved groups, known public load balancers) rather than disabling rules.
Introduce remediation responders one at a time. Add the required service policy for that responder's resource family in one compartment, set it to ask before executing, review outcomes, then move to automatic only for low-risk actions such as making a bucket private in non-production.
Create security zones for new workloads first. A new compartment with the Maximum Security Recipe is the easiest win, because nothing exists to break. Then clear Cloud Guard problems in an existing production compartment and apply a custom zone recipe to it. Resources cannot be moved into a zone unless they already meet all its policies.
Reattach tuned recipes. Creating a zone replaces the compartment's Cloud Guard targets with a security zone target using default detector recipes. Reapply your cloned recipes afterwards.
Roll back safely. To reverse a zone, remove the compartment from it, which restores normal behaviour; to reverse a responder, disable the rule in the cloned recipe and remove its service policy statement.

Zone policy category	Example policy names	What breaks if you apply it carelessly
Deny public access	`deny public_buckets`, `deny public_subnets`, `deny internet_gateway`, `deny public_load_balancer`, `deny db_instance_public_access`, `deny cloud_shell_public_network`	Internet-facing workloads; keep them in a separate, non-zoned compartment behind a WAF
Require encryption	`deny block_volume_without_vault_key`, `deny boot_volume_without_vault_key`, `deny buckets_without_vault_key`, `deny file_system_without_vault_key`	Provisioning that relies on Oracle-managed keys; create Vault keys first
Data durability and security	`deny database_without_backup`, `deny database_in_security_zone_create_clone_not_in_security_zone`	Test databases without backups; clones into developer compartments
Restrict movement and association	`deny instance_in_security_zone_move_to_compartment_not_in_security_zone`, `deny block_volume_in_security_zone_attach_to_instance_not_in_security_zone`	Migration scripts that move resources between compartments
Approved configurations only	`deny instance_without_sanctioned_image`, `deny security_list_to_allow_traffic_to_restricted_port`, `deny load_balancer_with_weak_SSL_communication`, `deny update_route_table`	Network and image changes by pipelines; several of these are change freezes in effect, so use them only in tightly managed zones

Know the limits. Zone policies are checked on create and update only; database policies do not apply to Exadata Cloud@Customer; compute management policies apply only to instance configurations and instance pools; and a compartment can belong to only one zone. The restricted-port policy blocks rules allowing listed ports such as TCP 23 to 25, 3389 and 445, but not TCP 22, so SSH exposure still needs a Cloud Guard rule or a network control.

Framework mapping

Capability	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Security Zones deny policies	CM-2, CM-6, CM-7, SC-7	PR.PS-01, PR.IR-01	Control 4 Secure Configuration	A.8.9 Configuration management
Configuration detectors	CA-7, CM-6	ID.RA-01, DE.CM-09	Control 4, Control 7 Continuous Vulnerability Management	A.8.8 Management of technical vulnerabilities
Activity and threat detectors, events	SI-4, AU-6	DE.CM-03, DE.CM-09	Control 8 Audit Log Management, Control 13 Network Monitoring and Defense	A.8.15 Logging, A.8.16 Monitoring activities
Responders	IR-4	RS.MI-01	Control 17 Incident Response Management	A.5.26 Response to information security incidents
Credential age and MFA rules	IA-2, IA-5, AC-2	PR.AA-01	Control 5 Account Management, Control 6 Access Control Management	A.5.17 Authentication information

Common misconfigurations

No target on the root compartment: IAM policy changes and identity rules are not evaluated, so "Policy gives too many privileges" never fires. Target root, and add child targets only where a different recipe is needed (targets cannot overlap).
Alerts built in the home region: Events rules created outside the reporting region receive nothing. Test with a deliberate low-risk problem after every change.
Cloud Event left on "ask": the default rule exists, but if it waits for confirmation, problems stay in the console and the SOC sees nothing.
Tenancy-wide responder permissions: granting allow service cloudguard to manage users or policies across the tenancy means a mis-scoped responder can disable people or rewrite access at scale. Grant per compartment, enable one remediation rule at a time.
Zone created over a tuned target: creating a zone deletes the compartment's Cloud Guard targets and attaches default recipes, silently undoing months of tuning. Record recipe attachments in code and reapply.
Dismissing credential findings as noise: old API keys and auth tokens on users are exactly what attackers reuse. Long-lived cloud credentials on users were central to the Snowflake Breach, where accounts without MFA were accessed with infostealer credentials that had never been rotated; treat "User does not have MFA enabled" (CRITICAL by default) as a fix, not an exception.

Practitioner checklist

Confirm a paid tenancy, enable Cloud Guard with a root target, and record the reporting region.
Create separate administrator, analyst and auditor groups; restrict use and manage on cloud-guard-config to named administrators.
Build Events rules in the reporting region for problemdetected, problemdismissed, status (CLOUDGUARD_DISABLED) and sightingdetected, and prove delivery to the SIEM.
Clone Oracle-managed recipes, tune with conditions, and enable the disabled-by-default IAM credential activity rules where human users are few.
Grant Cloud Guard service policies per compartment and only for the responders you enable; move to automatic execution one rule at a time.
Put every new production compartment in a security zone; clear existing problems before zoning older compartments.
Reattach tuned detector recipes after creating any zone, and keep recipes and zone definitions in source control.
Run Oracle's CIS compliance script quarterly as an independent check of Cloud Guard coverage.
Track metrics: share of compartments under a target and in a zone, open CRITICAL and HIGH problems with median age, dismissals per month, responder success rate, and user API keys older than 90 days.

OCI Cloud Guard and Security Zones Guide: Detectors, Responders and Preventive Zone Recipes