Beyond the Big Three: Mastering Oracle Cloud Security in a Multi-Cloud World

Beyond the Big Three: Mastering Oracle Cloud Security in a Multi-Cloud World

Speakers: Dani Kaganovitch

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=L-Y2UKnaLAM

Overview

Dani Kaganovitch, a product manager at Rock Steady, presented an introduction to Oracle Cloud Infrastructure (OCI) security for practitioners accustomed to AWS, Azure, and GCP. With Fortune 100 customers increasingly adopting OCI -- driven by legacy Oracle product usage and aggressive infrastructure pricing -- the talk covered OCI's unique cloud structure, key architectural differentiators from other providers, and walked through two practical use cases for preventive security controls: region management using governance rules and IAM policies, and blocking public internet access using OCI's Security Zones feature. The talk arrived with a same-day announcement that OCI now supports deny statements in IAM policies, addressing a long-standing limitation.

Background

▶ Watch: Why customers choose OCI: legacy Oracle products and cost (2:00)

OCI has been growing as a multi-cloud component for enterprise organizations, though it remains less understood by security practitioners than AWS, Azure, or GCP. Two primary drivers push organizations to OCI: legacy Oracle product usage (database, middleware, applications) and significantly lower infrastructure costs, particularly relevant as FinOps gains importance. Rock Steady, a cloud security startup focused on leveraging native cloud provider capabilities for preventive security, added OCI to their multi-cloud portfolio in response to increasing customer demand.

OCI's cloud structure is simpler than the other major providers, with only two primary organizational entities: the tenancy (analogous to an AWS organization or Azure tenant) and compartments. Compartments serve a dual role as both containers (like AWS accounts or Azure resource groups) and resource entities where resources can be directly created. The root compartment is always the top level and is the only place where certain security services can be configured. Compartment hierarchies support inheritance, meaning policies and controls applied to a parent compartment cascade to all child compartments.

Key Findings

▶ Watch: Four OCI differentiators: physical network isolation, default encryption, gra... (5:45)

OCI has four significant architectural differentiators from other cloud providers:

1. Physical network isolation: OCI built its own data centers with custom hardware implementing off-box virtualization. Each customer has physically separated networking at the NIC level -- not shared networking with logical isolation. This is unique among major cloud providers.

1. Encryption at rest by default: All data stores in OCI are encrypted at rest by default without any customer configuration required. This contrasts with other providers where encryption settings must be explicitly configured per service.

1. Granular IAM conditions: OCI's IAM policy language supports a highly flexible condition system with no apparent limitations on the number or complexity of conditions per statement.

1. Free or low-cost security services: Most OCI security services are provided free of charge or at significantly lower cost than comparable services from other providers.

OCI now supports deny statements in IAM policies (announced as limited availability the day of the talk). This is a transformational change -- previously, OCI's IAM only supported allow statements, which created a significant limitation: any new allow statement could inadvertently override existing restrictions. Deny statements bring OCI's IAM closer to parity with AWS SCPs and address the "implicit allow override" drift problem.

Security Zones is a powerful preventive control unique to OCI. Part of the CloudGuard CSPM service (free of charge), Security Zones provides 76 built-in policies that enforce configuration standards declaratively. Policies are simple prohibitions (e.g., "deny public subnets," "deny internet gateway," "deny public load balancer," "deny public buckets") that are attached to compartments via recipes and inherited downward. This is comparable to AWS declarative policies in simplicity but is enforced preventively rather than through monitoring.

Technical Deep Dive

▶ Watch: Region management use case with governance rules and IAM conditions (10:00)

Use Case 1: Region Management. The objective was ensuring all cloud workloads stay within approved regions -- serving data residency (GDPR), attack surface reduction (preventing crypto mining in unmonitored regions), and monitoring efficiency goals. Two implementation methods were demonstrated:

Governance Rules: Requires opting into an OCI Organization (a logical entity above tenancies). Using CLI commands, allowed regions are defined and governance rules are applied as a template. Behind the scenes, governance rules create quota policies that set resource family quotas to zero for non-approved regions. A limitation exists: some resources (like object storage) can still be provisioned in restricted regions but cannot be used (e.g., files cannot be uploaded). Governance rules add a lock mechanism that differentiates them from raw quota policies.

IAM Policy Conditions: A more flexible but less centrally managed approach. Conditions like request.region = 'us-ashburn-1' are added to each IAM policy statement. The limitation is drift management -- new statements created without the region condition override the restriction.

Use Case 2: Blocking Public Internet Access. The objective was restricting sensitive compartments to internal-only networking. Implementation used Security Zones from CloudGuard:

Virtual network controls: Built-in Security Zone policies deny public subnets, internet gateways, and public load balancers. A recipe is created from selected policy IDs and attached to the target compartment.

Managed service controls: Additional policies like "deny public buckets" are added to the same recipe. For services not covered by Security Zone policies (e.g., public DNS zones), quota policies set to zero can supplement the coverage.

Limitations of Security Zones: Only one security zone per compartment (they cannot be stacked), no native support for exclusions (workaround: detach zone, make changes, reattach), recommended for new environments rather than retrofitting existing ones, and the 76 built-in policies are not customizable.

Demo / Proof of Concept

▶ Watch: Security Zones: 76 built-in preventive policies via CloudGuard (13:30)

No live demo was performed. CLI commands and configuration examples were shown on slides to illustrate the implementation of both use cases.

Defensive Implications

▶ Watch: Security Zone limitations: one per compartment, no exclusions, fixed policies (17:30)

Organizations adopting OCI should immediately enable CloudGuard (free) to access Security Zones. For new sensitive environments, Security Zone recipes should be attached at creation time with policies blocking public subnets, internet gateways, public load balancers, and public storage. Region management should use governance rules for centralized enforcement, supplemented by IAM policy conditions for additional flexibility.

The arrival of deny statements in OCI IAM is a significant event. Organizations should begin planning their migration from allow-only policy architectures to include deny-based guardrails that prevent common misconfigurations and limit blast radius. The combination of Security Zones for configuration enforcement and IAM deny statements for identity-level controls gives OCI a comprehensive preventive security posture for the first time.

For multi-cloud organizations, the OCI-specific patterns (compartment inheritance, security zones, governance rules) should be mapped to equivalent controls in their AWS/Azure/GCP environments to maintain consistent security policy across providers.

Key Takeaways

• OCI adoption is growing among Fortune 100 companies driven by legacy Oracle usage and lower infrastructure costs
• OCI provides physical network isolation at the NIC level per customer -- unique among major cloud providers
• Security Zones offer 76 built-in preventive policies (free via CloudGuard) that can block public subnets, internet gateways, public load balancers, and more at the compartment level
• OCI now supports IAM deny statements (limited availability), closing a major gap with AWS SCPs
• Governance rules enforce region restrictions via quota policies but have limitations (some resources can still be provisioned but not used in restricted regions)
• Security Zones are limited to one per compartment, have no native exclusion support, and policies are not customizable

About the Speaker(s)

Dani Kaganovitch is a product manager at Rock Steady, a cloud security startup focused on creating secure-by-design cloud environments using native cloud provider capabilities. He previously worked at major cloud providers including Google Cloud and Oracle, giving him direct experience with OCI's security capabilities. This was his first time speaking in the United States and at fwd:cloudsec.