Cloud Audit Logs with Cloud Storage

This page provides supplemental information for using Cloud Audit Logs with Cloud Storage. Use Cloud Audit Logs to generate logs for API operations performed in Cloud Storage.

Overview

Google Cloud services write audit logs to help you answer the questions, "Who did what, where, and when?" within your Google Cloud resources. You can also attach custom information to audit logs for more granular information about how your resources are accessed.

Your Google Cloud projects contain only the audit logs for resources that are directly within the Google Cloud project. Other Google Cloud resources, such as folders, organizations, and billing accounts, contain the audit logs for the entity itself.

For a general overview of Cloud Audit Logs, see Cloud Audit Logs overview. For a deeper understanding of the audit log format, see Understand audit logs.

Available audit logs

The following types of audit logs are available for Cloud Storage:

  • Admin Activity audit logs: Entries for user-driven operations that modify the configuration or metadata of Cloud Storage resources.

  • Data Access audit logs: Entries for user-driven operations that are not tracked in Admin Activity audit logs. There are several sub-types of Data Access audit logs:

    • ADMIN_READ: Entries for operations that read the configuration or metadata of Cloud Storage resources.

    • DATA_READ: Entries for operations that read user-provided Cloud Storage resource data.

    • DATA_WRITE: Entries for operations that modify user-provided Cloud Storage resource data.

    To receive Data Access audit logs, you must explicitly enable them.

  • System Event audit logs: Entries for operations that modify Cloud Storage resources. These are generated by Google Cloud systems and not driven by user action.

In addition to audit logs for Cloud Storage, Cloud Audit Logs can create audit logs for Storage Insights.

For fuller descriptions of the audit log types, see Types of audit logs.

Audited operations

The following table summarizes which Cloud Storage operations correspond to each audit log type:

Audit log type Sub-type Cloud Storage operations
Admin Activity ADMIN_WRITE
  • Setting bucket or managed folder IAM policies
  • Setting object ACLs1
  • Creating buckets
  • Deleting buckets
  • Restoring soft-deleted buckets
  • Relocating buckets
  • Updating bucket metadata
  • Creating tag bindings on buckets
  • Deleting tag bindings on buckets
  • Creating managed folders
  • Deleting managed folders
  • Updating Storage Intelligence configuration for a project, a folder, or an organization
  • Creating Rapid Cache caches
  • Pausing Rapid Cache caches
  • Resuming Rapid Cache caches
  • Disabling Rapid Cache caches
  • Updating Rapid Cache caches
  • Creating HMAC keys
  • Deleting HMAC keys
  • Updating HMAC keys
  • Cancelling long-running operations
  • Deleting long-running operations
  • Creating Storage Insights inventory report configurations
  • Updating Storage Insights inventory report configurations
  • Deleting Storage Insights inventory report configurations
  • Creating Storage Insights dataset configurations
  • Updating Storage Insights dataset configurations
  • Deleting Storage Insights dataset configurations
  • Linking Storage Insights dataset configurations
  • Unlinking Storage Insights dataset configurations
Data Access ADMIN_READ
  • Getting bucket or managed folder IAM policies
  • Getting object ACLs
  • Getting bucket metadata
  • Listing buckets
  • Listing tag bindings on buckets
  • Listing effective tags on buckets
  • Getting managed folder metadata
  • Listing managed folders
  • Getting Storage Intelligence configuration for a project, a folder, or an organization
  • Getting Rapid Cache caches
  • Listing Rapid Cache caches
  • Getting HMAC keys
  • Listing HMAC keys
  • Getting long-running operations
  • Listing long-running operations
  • Getting Storage Insights inventory report configurations
  • Listing Storage Insights inventory report configurations
  • Getting Storage Insights inventory reports
  • Listing Storage Insights inventory reports
  • Getting Storage Insights dataset configurations
  • Listing Storage Insights dataset configurations
Data Access DATA_READ
  • Getting object data
  • Getting object metadata
  • Listing objects
  • Getting folder metadata
  • Listing folders
  • Copying objects2
  • Composing objects2
  • Listing ongoing XML API multipart uploads
  • Listing XML API multipart upload parts
Data Access DATA_WRITE
  • Creating objects
  • Deleting objects
  • Deleting multiple objects using the XML API
  • Restoring soft-deleted objects
  • Moving objects
  • Updating non-ACL object metadata
  • Setting retentions for objects
  • Overriding unlocked retentions for objects
  • Copying objects2
  • Composing objects2
  • Initiating XML API multipart uploads
  • Creating parts in an XML API multipart upload
  • Aborting XML API multipart uploads
  • Completing XML API multipart uploads
  • Creating folders
  • Deleting folders
  • Renaming folders
System Event
  • Start of bucket relocate process3
  • End of bucket relocate process

1 Admin Activity audit logs are not generated if/when ACLs are initially set at object creation.

2 These operations involve both reading and writing data. As a result, these operations each generate two log entries.

3 Bucket relocate might not start immediately after the initial request. The system event log gets written when the process actually begins.

Restrictions

The following restrictions apply to Cloud Audit Logs with Cloud Storage:

  • Cloud Audit Logs does not track access to public objects.
  • Cloud Audit Logs does not track changes made by the Object Lifecycle Management or Autoclass features.
  • Data Access logs generated from authenticated browser downloads have their principalEmail and callerIp fields redacted when the download occurs outside of the Google Cloud console.

If you need logging capabilities in one of these cases, consider using Cloud Storage usage logs.

Audit log format

Audit log entries include the following components:

  • The log entry itself, which is a LogEntry object. Useful fields include the following:

    • The logName contains the resource ID and audit log type.
    • The resource contains the target of the audited operation.
    • The timestamp contains the time of the audited operation.
    • The protoPayload contains the audited information.
  • The audit logging data, which is an AuditLog object held in the protoPayload field of the log entry.

    • Within the protoPayload field, the metadata field includes information specific to Cloud Storage. For example, a rewrite operation's object GET request's log includes a destination field in the metadata field of its audit log to specify the bucket where the data has been copied to.

    • Within the protoPayload field, additional audit information specific to Cloud Storage is included in the request and response fields when Detailed audit logging mode is enforced. Note that you don't need to enforce detailed audit logging to attach custom information to audit logs.

For other fields in these objects, and how to interpret them, see Understand audit logs.

Log name

Cloud Audit Logs log names include resource identifiers indicating the Google Cloud project or other Google Cloud entity that owns the audit logs, and whether the log contains Admin Activity or Data Access audit logging data.