How Oracle Manages Exadata Cloud@Customer Without Accessing Your Data

One of the first questions security teams ask when evaluating Oracle Exadata Cloud@Customer is surprisingly simple: "If Oracle manages the infrastructure, does Oracle have access to our data?"

It's a fair question. Your Oracle databases are physically running inside your own data center, but Oracle Cloud is provisioning infrastructure, monitoring hardware, and performing lifecycle operations. To many people, that sounds like Oracle must somehow have access to everything.

The reality is very different. Oracle Exadata Cloud@Customer was designed from the ground up with data isolation as a non-negotiable architectural requirement — not a marketing add-on bolted on after the fact.

Because managing hardware and reading database rows are completely different jobs — and ExaCC keeps them in separate operational planes.

Think of it like a building manager who maintains the HVAC, electrical panels, and elevator systems. They have keys to the mechanical room. They do not have keys to your office filing cabinets. ExaCC applies the same principle at datacenter scale.

Oracle's management agents operate in the Control Plane (Dom0). Your databases run in the Customer Plane (DomU). The hypervisor enforces a hard boundary between them. Oracle receives hardware health metrics, firmware status, and provisioning instructions — not SQL query results, table contents, or backup plaintext.

Figure 1 · Control Plane vs Customer Plane — infrastructure mechanics vs data custody

When Oracle performs a scaling operation or dispatches a field engineer for a failed disk, those actions touch the infrastructure layer. They never require — and architecturally cannot require — access to your database data dictionary, tablespaces, or application schemas.

When your team uses the OCI Console, CLI, Terraform, or REST APIs against ExaCC resources, you interact with the Control Plane. Commands travel over an encrypted management connection to local agents on the rack. Those agents broker infrastructure work — they do not broker database queries.

The distinction is deliberate. Oracle automates the parts of the stack that are repetitive, hardware-bound, and identical across every ExaCC customer. You retain custody of everything that makes your data uniquely yours.

Several independent mechanisms work together. No single layer is the whole story — and that redundancy is the point.

Hypervisor Isolation (Dom0 / DomU)

When you look under the hood at the hypervisor layer, the split is explicit. Dom0 runs Oracle's management stack. DomU runs your Guest VMs with their own kernel, file systems, and memory space. Oracle's agents cannot attach to DomU memory or mount DomU file systems without crossing a boundary the architecture does not permit.

Figure 2 · Dom0/DomU hypervisor isolation on an ExaCC compute node

Encryption at Rest (TDE)

Transparent Data Encryption encrypts data blocks before they are written to ASM disk groups on Exadata storage cells. Even if someone could read raw storage blocks — which the Control Plane cannot do with usable plaintext — they would see encrypted ciphertext without your TDE master keys.

Network Segregation

ExaCC separates Client Network (application traffic), Backup Network (backup streams), and Management Network (OCI control plane telemetry). Production database sessions stay on your corporate LAN. They do not ride the same path as Oracle's infrastructure management packets.

Customer-Owned Credentials

You set database administrator passwords, OS root credentials, and SSH keys inside Guest VMs. Oracle does not receive, store, or escrow these credentials as part of the ExaCC service model.

Security on ExaCC is not one firewall rule. It is three stacked enforcement layers — each independently auditable.

Figure 3 · IAM, Network, and Storage security boundary layers

Layer 1 — IAM & Identity

OCI Identity and Access Management controls who in your organization can create VM Clusters, scale OCPUs, or trigger patch operations. Oracle's internal cloud operations staff use a completely separate Oracle-internal identity system for hardware maintenance — they do not inherit your database credentials or Guest VM logins.

Layer 2 — Network

Physical and logical network separation ensures management telemetry, backup traffic, and production database connections use distinct paths. Security teams can enforce VLAN isolation at the datacenter switch layer and validate that Client Network subnets never route through the OCI management tunnel.

Layer 3 — Storage & Encryption

ASM manages disk groups with high redundancy across storage cells. TDE ensures data at rest is encrypted with keys you control — locally via Oracle Wallet or remotely via OCI Vault integration. Backup pieces leaving the database memory layer are encrypted before transit over the Backup Network.

Security reviews often focus on edge cases: what happens when Oracle is actively doing something on the rack? Here are four common scenarios and how data stays protected in each.

This is the same conceptual model as public cloud — adapted for hardware sitting in your building. Understanding where the line falls prevents both over-trusting Oracle with data tasks and under-maintaining security tasks that remain yours.

Figure 4 · ExaCC shared responsibility model

Oracle's SLA covers platform availability up to the hypervisor. Your SLA to the business covers database performance, data integrity, access controls, and compliance attestations. Both sides have clear, non-overlapping jobs.

Banks, healthcare systems, government agencies, and payment processors choose ExaCC because it satisfies two requirements that usually conflict: cloud-grade automation and strict data residency.

ExaCC gives regulated enterprises the operational relief of managed infrastructure without surrendering data sovereignty — the combination that pure public cloud or pure on-premises models struggle to deliver alone.

Before your security review committee signs off, let's address those head-on.

1. "Oracle support can log into my database and read production data."Oracle maintains the hypervisor and hardware layers outside your Guest VMs. They do not have SYSDBA credentials, OS root access to your DomU environments, or visibility into encrypted tablespaces unless you explicitly grant it for a specific support session you initiate and monitor.
2. "Because Oracle owns the hardware, they own my data too."Hardware ownership and data custody are legally and architecturally separate on ExaCC. Oracle owns the rack asset; you own the data inside your databases. Encryption and hypervisor isolation make your data structurally unreadable to Oracle even during hardware maintenance.
3. "ExaCC sends my database contents to OCI for monitoring."The management connection carries infrastructure telemetry and lifecycle metadata — CPU utilization at the hypervisor level, disk health alerts, provisioning status. It does not stream SQL results, table exports, or backup plaintext to Oracle Cloud.
4. "If OCI connectivity drops, Oracle loses access but so do I — and my data is at risk."Your databases continue running locally without interruption. You lose the ability to perform cloud-level lifecycle operations until connectivity returns. Your data remains on the rack, under your control, fully available to local applications.

Before production go-live, confirm your security team can check off each item:

• TDE enabled on all production databases with customer-controlled master encryption keys
• Network segmentation validated — Client, Backup, and Management networks isolated at the physical switch layer
• IAM policies mapped from corporate IdP groups to OCI compartments with least-privilege access
• Guest VM audit logging enabled — auditd, OS logs, and SIEM integration configured
• Backup encryption verified — RMAN backups encrypted before leaving the database memory layer
• Management connection documented — firewall rules, proxy settings, and outbound HTTPS requirements approved by security
• Shared responsibility matrix signed off — Oracle vs customer tasks documented in operational runbooks
• Incident response plan updated for ExaCC-specific scenarios (control plane outage, hardware failure, credential compromise)

1. Oracle manages the rack, not your dataExaCC separates infrastructure mechanics (Control Plane) from data custody (Customer Plane) with a hard architectural boundary.
2. Dom0/DomU isolation is the core mechanismOracle's hypervisor layer cannot read Guest VM memory, database files, or encryption keys.
3. Three security layers stack independentlyIAM controls who can operate the platform; network segmentation isolates traffic paths; TDE protects data at rest.
4. Management operations don't require data accessHardware replacement, patching, scaling, and backup orchestration touch infrastructure — not table contents.
5. Shared responsibility is explicitOracle owns the platform up to the hypervisor; you own Guest VMs, databases, credentials, and compliance.
6. Regulated industries adopt ExaCC for a reasonData residency, encryption control, and auditability satisfy financial, healthcare, PCI, and government requirements.
7. Common fears are usually misconceptionsOracle cannot read your tables, train AI on your data, or comply with a subpoena for data it does not custody.
8. Your security team still has work to doTDE, IAM, network segmentation, and Guest VM audit logging remain customer responsibilities — and ExaCC is designed that way on purpose.

Oracle Exadata Cloud@Customer was built for organizations that need cloud automation without giving up data custody. The Control Plane handles the repetitive infrastructure work. The Customer Plane keeps your databases, keys, and application data under your exclusive control.

The question is not whether Oracle manages your Exadata rack — it does. The question is whether that management requires access to your data — and on ExaCC, the architecture ensures it never does.

At ExaGuru, our Exadata Expert course covers ExaCC security architecture, Control Plane vs Customer Plane operations, and production deployment patterns — because understanding this isolation model is the foundation for every security review and architecture sign-off.