Two Invoices, One Control Plane, and 38% Over Budget

The core insight is that no single control plane sees everything, so the design goal is a join key, not a single tool.

Collect:

• OCI: Audit is the authoritative record of actions taken through OCI IAM, which is how Database@Azure resources are administered. Route it through OCI Logging and a Service Connector Hub to two destinations - an Object Storage bucket for immutable retention and a stream or connector into the SIEM. Add VCN flow logs for the Frankfurt tenancy.
• Azure: subscription-level diagnostic settings and activity logs into Log Analytics for hot querying, with a continuous export to immutable storage for the long tail. The Azure plane is authoritative for control-plane changes to the Azure substrate - networking, the delegated subnet, RBAC - and those are invisible to OCI Audit.
• Enable OCI Cloud Guard with a reporting region and turn on Security Zones for new compartments. Cloud Guard findings should land in the same SIEM, not a separate console nobody reads.

Normalise and join:

• Use the principal as the join key. Because Entra ID federates into OCI, the OCI Audit entry carries the same user identity the Azure logs do. Standardise on the UPN, store timestamps in UTC, and retain both the OCI OCID and the Azure resource ID on each normalised event.
• Retention: extend to at least 13 months on both sides. Fix the Object Storage bucket lifecycle immediately - a bucket with no lifecycle policy accumulates cost without adding evidence quality. Move to archive tier after 90 days rather than deleting.

Validate with a tabletop exercise: pick a real key deletion and see whether one analyst can reconstruct who, from where, and what happened next.

First, be honest about the threat model. A database administrator with full CDB privileges can read data whether or not they can see the key. Separation of duties for TDE protects against media theft, backup exfiltration, and rogue key operations - deletion, export, or disabling - not against a determined DBA with live access. Say so in the design document; auditors respect a precise claim and distrust an overbroad one.

Design:

• Put TDE keys in a dedicated OCI Vault compartment that only the security function can administer. Grant the database team use keys on the specific keys, not manage keys, and never manage vaults. Use dynamic groups or service principals so the grant is attached to the database resource, not to a person.
• Keep the Azure Key Vault estate separate: it holds application secrets, not TDE keys. For Database@Azure the TDE root of trust is OCI Vault. Do not blur the two in documentation, because that ambiguity is what lets a team quietly accumulate both privileges.
• Rotate key versions on a defined schedule and require the key custodian, not the DBA, to initiate rotation. OCI does not provide a native dual-approval workflow for key operations, so implement it through change management plus detection: alert on every key deletion, disable, and export event, and route the alert to the security team.
• Kill the password spreadsheet. Move those credentials into Azure Key Vault with rotation and managed identity retrieval, then record the migration so the access review can attest to it.

Evidence for the auditor: a policy document showing which group holds manage keys and which holds use keys, an identity-domain report proving no user is in both, and the last four quarterly review sign-offs.

Both teams are describing the same arrangement from different angles, and neither is wrong. Oracle Database@Azure is procured through Azure Marketplace, appears on the Azure invoice, and consumes Azure commitment - so finance legitimately sees it as Azure spend. It is nonetheless an OCI service, administered through OCI IAM and the OCI Console, and the legacy Frankfurt tenancy is billed by Oracle separately. The answer to finance is that there is one commercial surface for Database@Azure and a second for the legacy tenancy, and the chargeback model must join them rather than pretend they are one bill.

Artefacts that make it work:

• A mandatory tag taxonomy applied in both clouds before resources are created: product_line, cost_centre, environment, owner. Enforce it in Azure Policy and in OCI with defined tags plus a Security Zone or Cloud Guard rule that reports untagged resources weekly.
• A monthly FinOps report that joins the Azure cost export with the OCI cost and usage report on the shared tags, and publishes showback per product line. Without the join, the two teams will argue about the total forever.
• Budget alarms at 80% and 100% per product line, in both clouds, routed to the product owner rather than to finance.
• An exception process: untagged spend is reported to the owning executive monthly, and anything still untagged after 30 days is charged to a central IT overhead bucket. Once the overhead bucket grows, tagging compliance follows.
• Quarterly access review and the annual DR/key-custody tests folded into the same governance calendar, so compliance evidence is a by-product of operations rather than a scramble.

Given last year's 38% overrun, add a capacity review of the three Exadata systems: overprovisioning is the most common cause of exactly this pattern, and no amount of tagging fixes a system sized for peak that never arrives.