Prepare your Oracle Cloud accounts for a security incident

Why this matters

An incident in Oracle Cloud rarely stalls because nobody knows what to do. It stalls because the one person who can revoke a key is on a plane, the API key belongs to a contractor who left, or the audit records you need sat in a bucket the attacker could delete. Preparation removes those failure points before anything catches fire.

Oracle Cloud gives you solid building blocks: compartments, IAM policies, identity domains, Cloud Guard, the Audit service, Vault and Object Storage retention rules. None of them help if you have not decided who uses them under pressure, or where the evidence lives.

Think in three lanes: access, evidence and action. Access means a small, known group can get in when normal sign-in fails. Evidence means logs and configuration snapshots survive an attacker with admin rights. Action means a written, tested sequence for isolating a user, a key, an instance or a subnet.

Before you start

List every Oracle Cloud tenancy your company owns, including ones under a department card or a former contractor. For each, note the tenancy administrator, the identity domain in use, and the billing owner.

Pick an incident lead and a deputy. Pick one channel for incident talk that does not depend on the cloud, such as a separate chat workspace or a phone bridge. Write down who can authorize taking a production system offline, because that call will come at 2 a.m.

Decide your evidence window and location now. You need an Object Storage bucket in a separate tenancy, or at least a separate compartment, with a retention rule that blocks deletion. Decide who holds the keys to that bucket.

Find your Oracle Support customer support identifier and the path to open a severity 1 ticket. Support can help with tenancy recovery, but only if you know the identifier and the contacts listed on it.

How to do it

The work splits into identity, detection, evidence and playbooks. Do identity first, because every other control depends on knowing who can change what.

Keep everyday administration separate from emergency access. Your normal admins should sign in through your identity provider with MFA. A separate break-glass identity exists for the day federation breaks or an admin account is locked.

Run the steps in order, then test the whole path with people who would actually be on the call.

1. Map who can act in each tenancy. Export IAM users, groups, dynamic groups and policies for every compartment. Look for policy statements with manage all-resources in tenancy and for users with API signing keys or customer secret keys. Note who owns each key.
2. Create two break-glass identities. Create two local users in the default identity domain, each with MFA and a unique password. Store credentials in a safe that requires two people to open. Give one tenancy administrator rights and keep the other read-only for evidence review.
3. Move daily admin to federation. Connect your identity provider, map an administrator group, and remove standing admin rights from personal accounts. Use break-glass only when federation is down.
4. Turn on Cloud Guard and route findings. Enable Cloud Guard at the tenancy level and choose the reporting region. Send problems to a Notifications topic that reaches your on-call channel, not an inbox nobody reads.
5. Copy audit events out of the tenancy. Export audit events with the OCI CLI or the Audit API into an Object Storage bucket in another compartment. Add a retention rule and a legal hold so a compromised admin cannot delete the history.
6. Write a one-page isolation runbook. List the exact console and CLI actions to disable a user, delete an API signing key, block a subnet with a network security group, stop an instance and rotate a Vault key. Add the owner and approval needed for each.
7. Set up an out-of-band contact tree. Store incident lead, deputy, legal, communications and Oracle Support contacts where you can reach them without SSO. Print a copy and keep it with the break-glass credentials.
8. Run a tabletop and a live test. Walk through a stolen API key scenario for 60 minutes. Then disable a test user and revoke a test key for real, and time how long it takes to confirm each change.

How to check it worked

Measure the things that matter under pressure. Can two people sign in with break-glass credentials without asking anyone? How long does it take to revoke an API key and confirm it is dead? Can you find the audit event for that revocation in your copied bucket?

Review Cloud Guard problems weekly for a month after setup. If the Notifications topic is wrong or the responder recipe is missing, you will get silence, and silence looks like safety.

Test the evidence path: try to delete a test object from the audit bucket and confirm the retention rule blocks it. Repeat from the tenancy admin account. If the admin can delete the bucket, the copy is not evidence.

Check coverage, not just existence. Confirm audit is on in every compartment and region you use, that Vault key deletion has a waiting period you control, and that backups for critical volumes and databases can restore into a clean compartment.

Mistakes to avoid

Using the break-glass account for daily work. The moment it becomes convenient, it becomes a target and you lose the signal that something is wrong. Keep it offline and check its sign-in audit monthly.

Keeping the only audit copy in the same tenancy. An attacker with tenancy admin can delete buckets and logs. The copy must sit behind a different admin boundary.

Writing a runbook nobody has run. A command that moved or a console page that changed wastes the first ten minutes. Test the commands in a sandbox tenancy.

Skipping the boring parts: contact lists, support numbers, approval paths and a printed copy. If you want an outside read before your first drill, the Cloud security review from Cloudverg is $6,500/month, fixed scope, covers up to five cloud accounts, and runs 2 to 3 weeks. Treat it as one option among tabletop exercises, peer review and your own testing.

Frequently asked questions