How to turn on audit logging in Oracle Cloud

Why this matters

Oracle Cloud Infrastructure (OCI) already records API calls in the Audit service. You do not flip a switch to start it. When someone creates a user, changes a security list, deletes a bucket or rotates a key, Audit writes an event with the principal, the request, the source IP and the time. The console keeps those events for 90 days.

That default is useful for troubleshooting. It is thin for investigations, customer security reviews and incident response. After 90 days the events are gone unless you copied them. Audit is also control plane only. Reading an object, querying a database or calling a function can happen without an Audit event, depending on the service. And nobody gets paged when a sensitive change happens.

Turning on audit logging in Oracle Cloud really means three things: keep the events longer than 90 days, fill the data plane gaps with Logging service logs where the service supports them, and route the events you care about to a person or a queue. Do that and the audit trail survives an admin mistake, a compromised account and a slow investigation.

Before you start

You need tenancy administrator rights for the first pass. You will work in the root compartment for Audit and in a separate archive compartment for storage. Create that archive compartment first. Do not put it inside a project compartment that a product team can delete.

Pick a home for the archive. A dedicated compartment named audit-archive, a private Object Storage bucket, and a policy that only a small group can delete from. Decide the retention period before you create the bucket. If a customer contract or internal rule says one year, write that down and configure the bucket and connector to match.

You also need a group for security operators and a separate group for auditors. Operators manage connectors and buckets. Auditors read audit events and archived objects, nothing else. The policy allow group Auditors to read audit-events in tenancy is the base. Add read objects in the archive compartment. Keep those roles apart from the admin group that can delete the bucket.

Check the tenancy limits for Service Connector Hub and Object Storage. Create the notification topic and subscription first if you want alerts on day one. Have a short list ready: identity changes, network changes, key and secret changes, bucket policy changes. You will use that list for filters and alerts.

How to do it

Work in the root compartment for Audit and the archive compartment for storage. Keep names boring and consistent: audit-archive bucket, audit-connector, audit-alerts topic. That makes policies and later searches easier.

Audit has no on switch. Your job is to confirm collection, copy events out, add the logs Audit does not cover and set alerts. The steps below follow that order. Test in a small compartment first if your tenancy has production workloads that you do not want to touch.

The connector batches events. Expect a delay between an action and an object in the bucket. A batch window of five or ten minutes is common; shorter windows mean more small objects. Set the window to match how quickly you need evidence, not how quickly you need an alert. Alerts should come from Events, not from the archive.

1. Confirm Audit is collecting. Open Governance and Administration, then Audit. Set the compartment to the root and look at the last hour. Create a test bucket in a sandbox compartment if the list is empty, then refresh. You should see the create event with your user name and source IP.
2. Create a private archive bucket. In Object Storage, create a bucket in the audit-archive compartment. Set visibility to Private, turn on object versioning, and add a retention rule if you need immutable copies. Do not enable public access.
3. Grant the connector access. Create a policy that lets the service connector read audit events in the tenancy and write objects in the archive compartment. The Service Connector Hub create screen shows the exact statement for the source and target you pick. Keep the policy in the audit compartment, not in a broad admin group.
4. Create the Service Connector Hub connector. Open Service Connector Hub and create a connector. Choose Audit as the source and Object Storage as the target. Pick the archive bucket, set a batch size and batch time, and leave the format as JSON. Start the connector and note its state.
5. Turn on service logs for data plane activity. Open Logging, create a log group called audit-data-plane, and enable service logs for the services you use that support them, such as Object Storage, API Gateway, Load Balancer and Functions. Enable only what you will read. Not every OCI service emits data plane logs, so check the service list before you promise coverage.
6. Route sensitive events to a topic. In Notifications, create a topic and add an email or HTTPS subscription. In Events, create a rule for the services and event types on your list, such as identity user changes, security list changes and bucket deletion. Send the rule to the topic. Keep the rule narrow at first.
7. Give auditors read only access and document the owner. Create an Auditors group and allow it to read audit-events in the tenancy and read objects in the archive compartment. Do not give it manage access. Write down the bucket name, connector name, retention period, alert topic and owning group, then test with a real auditor account.

How to check it worked

Go back to Audit and find the test bucket event. Then open the Service Connector Hub connector and check its metrics and last run status. Wait for one batch window and list the objects in the archive bucket. You should see JSON objects with a date in the name. Download one and open it. Look for eventType, eventTime, principalId, sourceIpAddress and requestId. If those fields are present and readable, the archive is usable.

Search the Logging service for a request you made, such as a bucket list or a function call. If the log group is empty, the service log may not be enabled or the service may not emit that category. Check the log status and the compartment, then make another request.

Test the alert path. Create a test bucket in a sandbox compartment and confirm the notification arrives. Have an auditor sign in and try to open Audit and the archive bucket. They should see events and objects, and no delete button. Finally, check the connector error metric after a day. A connector that ran once and stopped is worse than no connector because it looks like coverage.

Mistakes to avoid

Treating Audit as off is the first mistake. It is already on, so a team can spend a week looking for a toggle and miss the real gaps: retention, data plane logs and alerts. Check the service before you add tools.

The second mistake is a public or shared archive bucket. Audit events contain user names, IP addresses, resource names and sometimes request details. Keep the bucket private, keep delete rights in a small group, and do not let the same admins who are under investigation control the archive. Use a separate compartment and a retention rule.

A third mistake is collecting everything and reading nothing. Audit is noisy. Start with a short list of events that would wake you up: new identity provider, new admin, security list opened to the internet, key deleted, bucket made public. Route those to a topic and review the rest on a schedule. Also watch the connector error and throughput metrics. Silent failure is common when policies change.

Do not assume the archive is evidence of coverage. Walk through one real question, such as who deleted a bucket last month, and see if you can answer it from the console and the archive. If you want an outside read on identity, exposure, encryption and logging across your Oracle Cloud tenancy, Cloudverg's Cloud security review is a fixed price $6,500 review. It is one option; an internal review with the same checklist works too.

Frequently asked questions