What is the difference between Security Zones and Cloud Guard?

Security Zones are preventive — they block non-compliant actions before they occur. Cloud Guard is detective — it identifies security issues after resources are created and can trigger automated remediation. They are complementary: use Security Zones to enforce guardrails in production compartments so non-compliant resources can never be created, and use Cloud Guard to monitor all compartments for drift, misconfigurations, and security threats that emerge over time.

Can I override Security Zone policies for specific operations?

No. Security Zone policies are strictly enforced and cannot be bypassed, even by administrators. This is by design to provide strong security guardrails. If you need to perform an operation blocked by a Security Zone, you must either move the resource to a compartment outside the Security Zone, modify the recipe to remove that specific policy, or detach the Security Zone from the compartment temporarily. This strict enforcement is what makes Security Zones valuable for compliance.

OCI Security Zone Recipe Builder

IAM & SecurityOCI

Build Security Zone recipe policies to enforce security posture in compartments.

Last verified: May 2026

OCI Security Zones Configuration

Build Security Zone recipe policies to enforce security posture in OCI compartments.

Required Fields

compartmentIddisplayNamesecurityPolicies

{
  "compartmentId": "ocid1.compartment.oc1..aaaaaaaexample",
  "displayName": "cis-security-zone-recipe",
  "description": "Security Zone recipe enforcing CIS benchmark policies for production workloads",
  "securityPolicies": [
    {
      "policyId": "ocid1.securityzonessecuritypolicy.oc1..aaaaaaaexample1",
      "friendlyName": "deny-public-buckets",
      "description": "Deny creation of public Object Storage buckets",
      "category": "restrict-public-access"
    },
    {
      "policyId": "ocid1.securityzonessecuritypolicy.oc1..aaaaaaaexample2",
      "friendlyName": "require-vault-encryption",
      "description": "Require all block volumes and boot volumes to use Vault-managed encryption keys",
      "category": "restrict-encryption"
    },
    {
      "policyId": "ocid1.securityzonessecuritypolicy.oc1..aaaaaaaexample3",
      "friendlyName": "deny-public-ip-launch",
      "description": "Deny launching compute instances with public IP addresses",
      "category": "restrict-public-access"
    },
    {
      "policyId": "ocid1.securityzonessecuritypolicy.oc1..aaaaaaaexample4",
      "friendlyName": "require-nsg",
      "description": "Require compute instances to be associated with at least one NSG",
      "category": "restrict-network-access"
    }
  ],
  "targetCompartments": [
    "ocid1.compartment.oc1..aaaaaaaproduction",
    "ocid1.compartment.oc1..aaaaaaafinance"
  ],
  "freeformTags": {
    "compliance": "cis-1.2",
    "environment": "production"
  }
}

Generated Output

Output will appear here...

About This Tool

OCI Security Zones enforce security posture policies on compartments by preventing actions that violate predefined or custom security recipes. When a Security Zone is active, operations like creating public buckets, disabling encryption, or launching instances without approved images are automatically blocked. This builder helps you configure Security Zone recipes by selecting from Oracle's predefined policies and adding custom policy statements, then associating recipes with target compartments.

Real-World Scenario

Your security team is hardening production after an audit found public Object Storage buckets that shouldn't have been public. The builder generates a Security Zone recipe combining Oracle's 'Maximum Security Recipe' (denies public buckets, requires encryption, blocks unencrypted volumes) plus custom statements requiring all instances use approved images from the security-approved-images compartment. Apply to all production compartments. From that point forward, no one — even admins — can create non-compliant resources. The audit finding is closed structurally, not just remediated.

When to Use This Tool

•Creating a Security Zone recipe for production compartments that prevents public Object Storage buckets, unencrypted block volumes, and instances on public subnets
•Building a custom recipe that enforces specific approved Compute image OCIDs and blocks instance launches with images not in the approved list
•Configuring a Security Zone for a regulated compartment that requires encryption with customer-managed keys on all storage resources
•Defining a recipe that enforces network security policies like mandatory Network Security Groups and blocked internet gateways in sensitive compartments

Pro Tips

TIP

Security Zones are STRICT — they CANNOT be bypassed even by admins. This is intentional and the security strength of the feature, but means a poorly-designed recipe can block legitimate operations. Test recipes in a sandbox compartment first; promote to production only after validating that legitimate workflows still work.

TIP

Combine predefined Oracle recipes with custom statements. Oracle's recipes cover ~80% of common security requirements (no public buckets, encryption at rest, etc.). Add custom statements for org-specific rules (approved-image-only, mandatory tags, region restrictions). The combination gives you well-tested baselines + your specific overlays.

TIP

Plan compartment hierarchy with Security Zones in mind from day 1. Production compartments get a strict zone; dev/test compartments can have looser zones or none. Trying to retrofit Security Zones onto an existing compartment with non-compliant resources is painful — you have to relocate or remediate every offender.

How It Works Under the Hood

The builder constructs OCI Security Zone recipes: recipe resource (display name, description, list of policy statements that combine predefined Oracle policies and custom statements), recipe compartment association (which compartments enforce this recipe), and security zone activation. Output is generated as oci cloud-guard security-recipe + oci cloud-guard security-zone commands and Terraform oci_cloud_guard_security_recipe + oci_cloud_guard_security_zone resources.

Frequently Asked Questions

What is the difference between Security Zones and Cloud Guard?: Security Zones are preventive — they block non-compliant actions before they occur. Cloud Guard is detective — it identifies security issues after resources are created and can trigger automated remediation. They are complementary: use Security Zones to enforce guardrails in production compartments so non-compliant resources can never be created, and use Cloud Guard to monitor all compartments for drift, misconfigurations, and security threats that emerge over time.
Can I override Security Zone policies for specific operations?: No. Security Zone policies are strictly enforced and cannot be bypassed, even by administrators. This is by design to provide strong security guardrails. If you need to perform an operation blocked by a Security Zone, you must either move the resource to a compartment outside the Security Zone, modify the recipe to remove that specific policy, or detach the Security Zone from the compartment temporarily. This strict enforcement is what makes Security Zones valuable for compliance.

Related Learning Guides

OCI Security Best Practices24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.