Serverless audit trail

Audit trail is the first log type available for log delivery in Elastic Cloud Serverless. Enabling it delivers audit logs to your selected destination project so you can track and investigate activity in the source project.

An audit trail includes activity such as the following Elasticsearch and Kibana project events:

• Kibana sign-ins
• UI access, such as page navigation and UI requests
• Configuration changes to Elasticsearch resources, such as indices, templates, pipelines, and transforms
• Data access, including searches, reads, and writes

Delivering an audit trail to a project lets you investigate end-to-end activity in one place. For example, you can:

• Detect suspicious sign-in activity
• Observe changes or deletions of Kibana saved objects such as detection rules
• Inspect access denied on an index pattern
• Determine who searched a sensitive index
• Follow a user journey across service.name values for the same user.name and time window

The destination project has several tools to help with your investigation. Refer to Explore delivered logs for more information.

Complete the following steps to configure audit trail log delivery in your project.

You must have the Admin or Editor role on the source project.

Apply ignore filters to exclude certain events from being delivered. Refer to Log delivery in Elastic Cloud Serverless > Ignore filters to learn more about their impact on your delivery volume and bill.

The following table describes which ignore filters are available for the audit trail log type and when to select them.

In the following table, find the recommended combination of filters to select for typical use cases.

After delivery is enabled, explore your audit trail on the destination project with the provided dashboards, alerting rules, Discover or ES|QL, and AutoOps.

When you enable an audit trail, the destination project creates dashboards to help you explore and investigate audit activity. Select View dashboards after you save your log delivery configuration, or open the destination project and find the audit trail dashboards in Kibana.

The following dashboards are available:

• Command Center: Overview of audit activity, including volume, key indicators, higher-risk identities, and a live feed of recent events.
• Identity 360: Full activity trail for one user. Select a person to filter every panel to their events.
• Identity & Access: Sign-ins and access attempts by method, source, and outcome, with user identifiers resolved to real identities where available.
• Kibana Object Forensics: Kibana saved objects that were created, edited, deleted, or opened, grouped by type, name, space, and actor.
• Elasticsearch Data Access: Which indices each identity used, request types, denied requests, and access to system or hidden indices.
• Security & Anomalies: Risk signals for sensitive and privileged actions, operation failures, and newly seen identities.
• Geo & Network: Activity by geographic location, routed from each identity's real address, including unusual location patterns.

Set up alerting rules on the destination project to run continuously and notify you when sign-in or location patterns look suspicious, even when you're not watching the dashboards. These alerts link to the relevant dashboards for context, so you can use them together to enhance the security of your projects.

The destination project includes the following as templates. Create a rule from each template to receive alerts.

Select View logs after you save, or use Discover or ES|QL on the destination project to explore delivered audit trail logs in the following locations:

Explore the following examples of what you can investigate with your delivered audit logs. Run each query against logs-*_audit.otel-* in Discover.

FROM logs-*_audit.otel-*
| WHERE event.outcome == "failure" OR event.action IN ("access_denied", "authentication_failed")
| KEEP @timestamp, user.name, user.id, event.action, event.outcome, source.ip, project.id, service.name
| SORT @timestamp DESC
| LIMIT 100
		

FROM logs-*_audit.otel-*
| WHERE event.action IN (
    "rule_create", "rule_delete", "rule_update",
    "saved_object_create", "saved_object_delete", "saved_object_update",
    "connector_create", "connector_delete", "connector_update",
    "space_update"
  )
| KEEP @timestamp, user.name, event.action, elastic_cloud.serverless_audit.space.id, elastic_cloud.serverless_audit.saved_object.type, elastic_cloud.serverless_audit.saved_object.id, service.name
| SORT @timestamp DESC
| LIMIT 100
		

FROM logs-*_audit.otel-*
| WHERE event.action == "access_denied"
| KEEP @timestamp, user.name, elastic_cloud.serverless_audit.action, elastic_cloud.serverless_audit.indices, source.ip, service.name
| SORT @timestamp DESC
| LIMIT 100
		

FROM logs-*_audit.otel-*
| WHERE event.type IN ("creation", "change", "deletion")
| STATS events = COUNT(*) BY user.name, event.action, service.name
| SORT events DESC
| LIMIT 20
		

Do not select the Ignore data searches and reads filter for this query. Replace <INDEX_PATTERN> with the index or pattern to watch.

FROM logs-*_audit.otel-*
| WHERE event.action == "access_granted"
  AND elastic_cloud.serverless_audit.indices LIKE "<INDEX_PATTERN>"
| KEEP @timestamp, user.name, user.id, elastic_cloud.serverless_audit.action, elastic_cloud.serverless_audit.indices, source.ip, service.name
| SORT @timestamp DESC
| LIMIT 100
		

Use the AutoOps Storage Tier view on the destination project to monitor your ingest rate and storage retained.