Exadata Cloud Service Security

Exadata Cloud Service gives you the performance of engineered Oracle Database hardware on a cloud consumption model, but it does not give you security for free. The platform ships with strong controls. Whether those controls are switched on, scoped correctly and audited is your responsibility, and that is where most estates carry hidden risk. This guide walks the full security surface of an ExaCS deployment and gives you a model for hardening it.

The single most useful idea to hold onto is the shared responsibility line. Oracle operates and secures the physical infrastructure, the hypervisor and the Exadata software stack. You own everything inside the virtual machine cluster: the database configuration, the network exposure, the identity model, the encryption keys and the audit trail. A clean ExaCS security posture is the result of deliberate choices on each of those layers, not a default you inherit.

The shared responsibility model on ExaCS

On Exadata Cloud Service the boundary sits higher than on plain compute. Oracle patches the Exadata storage servers, the hypervisor and the firmware, and isolates tenants at the hardware level. You patch and configure the guest virtual machines, the Grid Infrastructure, the database homes and the databases themselves. Misreading this line is the root cause of most audit findings, because teams assume Oracle is hardening a layer that is in fact theirs to manage.

Network isolation comes first

An Exadata VM cluster lives inside a virtual cloud network and a private subnet that you define. Treat the client subnet as a sensitive zone. The database listeners should never be reachable from the public internet, and in almost every well run estate the cluster has no public IP at all. Access arrives through a bastion, a private endpoint, FastConnect or a site to site VPN.

Security lists and network security groups are your scalpel here. Scope ingress to the exact source ranges and ports your application tier needs, usually the SCAN listener port and the local listener range, and nothing else. The backup subnet, if you separate it, should only talk to the object storage service endpoint. We cover the full layout in Exadata Cloud Service Networking.

Encryption at rest and in transit

Exadata Cloud Service encrypts all database data at rest using Transparent Data Encryption by default. The question is who holds the master keys. You can let Oracle manage them, or you can hold them yourself in OCI Vault using a customer managed key. For regulated estates the customer managed key model is usually the right call, because it lets you rotate keys on your own schedule and revoke access independently of the database.

In transit, enable native network encryption or TLS between the application tier and the database. Backups written to object storage are encrypted, and you should confirm the bucket policy and the encryption setting rather than assume it. Treat key rotation as a scheduled operational task, not a one time setup.

Identity, access and least privilege

There are two identity planes to govern. The OCI control plane decides who can create, scale, patch or delete the Exadata infrastructure and VM clusters, and that is governed by OCI IAM policies, compartments and groups. The database plane decides who can connect and what they can do once inside, and that is governed by database accounts, roles and profiles.

On the control plane, scope policies to the compartment that holds the ExaCS resources, separate the team that operates infrastructure from the team that administers databases, and require multi factor authentication for any human with write access. On the database plane, retire shared administrative logins, give every administrator a named account, and use Oracle Database Vault to stop even privileged accounts from reading application data they have no business seeing.

A hardening framework for ExaCS

Auditing and continuous monitoring

Turn on unified auditing and ship the records off the cluster to a tamper resistant store, because an audit trail that lives only on the database being audited is worth little after an incident. Use OCI Logging and the Audit service for control plane events, and Data Safe to discover sensitive data, assess configuration drift and report on user activity across your databases. Set alarms on the events that actually matter: new grants of powerful roles, changes to audit policy, failed privileged logins and unexpected network rule changes.

Patching is part of security, not a separate discipline. An estate that is two or three quarters behind on database patches is carrying known, published vulnerabilities. Tie your patch cadence to your patching process and your Data Guard topology so you can patch the standby first and validate before touching the primary.

Common gaps we find

When we review an ExaCS estate the same handful of issues recur: a database with a public IP that nobody remembers provisioning, master keys still under Oracle management when policy requires customer managed keys, shared administrative accounts with passwords in a spreadsheet, unified auditing switched on but never reviewed, and a patch level that has quietly fallen a year behind. None of these are platform flaws. They are governance gaps, and they are exactly what an independent review is for.

If you want a structured read on where your estate sits, the Exadata Cloud Service practice runs a security and configuration assessment that maps every layer above against your actual deployment and gives you a prioritised remediation plan.