Configure Audit and Access Logging

When you provide Backblaze B2 Cloud Storage through a platform, reseller service, or managed offering, use several complementary log sources to build an audit trail. Backblaze Bucket Access Logs record requests made on a bucket, including the requester identity, operation, object name, IP address, status, and request ID. Per-tenant application keys let you associate those requests with a tenant. Event Notifications can provide faster signals for object changes, while your application, proxy, or CDN logs preserve the customer and user context that is not available to the storage service.

This guide uses the S3-Compatible API as the primary configuration path and includes procedures for the Backblaze web console and enterprise web console.

Prerequisites

Before you begin, ensure that you have the following items:

• A Backblaze account with Backblaze B2 enabled

• A separate destination Backblaze B2 bucket in the same Backblaze account and region as the source bucket
  Permission to read objects from the destination bucket

• A private Backblaze B2 bucket and its S3 endpoint

• An Application Key with the writeBucketLogging and readBucketLogging capabilities

• A durable mapping between each tenant and its application key ID

• A centralized log-processing or security-monitoring system

• Optional: Access to Event Notifications, requested through Backblaze Support

• Optional: An HTTPS webhook endpoint and a 32-character HMAC SHA-256 signing secret for Event Notifications

Do not enable Object Lock on the Bucket Access Logs destination bucket. Backblaze cannot deliver access logs to an Object Lock-enabled destination. If you require immutable retention, copy or ingest the delivered logs into a separate Object Lock-enabled archive.

Log Sources

No single log source contains every layer of identity and activity in a white-labeled service. Combine the sources that match your operational and audit requirements.

Enable Bucket Access Logs

Bucket Access Logs are available to paying customers, but Backblaze does not collect them by default. Enable logging separately on each source bucket and select a destination bucket for the generated log objects.

Use a dedicated destination bucket. Sending logs to the source bucket can create a loop because each delivered log object generates another logged request. The destination bucket must be a B2 bucket in the same account and region as the source bucket, and it cannot have Object Lock enabled.

Enable Logging with the S3-Compatible API

Create a file named logging.json with the destination bucket and an optional prefix:

{
  "LoggingEnabled": {
    "TargetBucket": "platform-access-logs",
    "TargetPrefix": "tenant-storage/"
  }
}

Run the following AWS CLI command. Replace the source bucket and endpoint values with your own values:

aws s3api put-bucket-logging \
  --bucket tenant-storage \
  --bucket-logging-status file://logging.json \
  --endpoint-url https://s3.<region>.backblazeb2.com \
  --profile backblaze

Verify the configuration:

aws s3api get-bucket-logging \
  --bucket tenant-storage \
  --endpoint-url https://s3.<region>.backblazeb2.com \
  --profile backblaze

The application key used for these requests must include the writeBucketLogging and readBucketLogging capabilities.

Enable Logging in the Backblaze Web Console

Enable Logging in the Enterprise Web Console

Organize Access Logs for Multiple Tenants

Use prefixes that make the source and ownership of each log object apparent. Date-based partitioning is useful when a query engine or log processor regularly reads a time range.

access-logs/
  <account-id>/
    <region>/
      <source-bucket>/
        <year>/<month>/<day>/

The correct aggregation design depends on your tenant model:

Attribute Requests to Tenants

Create a distinct application key for each tenant, service, or trust boundary. Restrict each key to only the bucket, prefix, and capabilities that the tenant requires.

Bucket Access Logs include an identity value for authenticated requests. For an application key, the value has the following format:

identity:applicationKey:<application-key-id>

Store a durable mapping between the application key ID and your internal tenant ID. The application key ID is an identifier, not the application key secret. Keep mappings for retired keys for at least as long as you retain the corresponding logs so that historical activity remains attributable after key rotation.

If several tenants share one application key, Bucket Access Logs cannot distinguish those tenants. In that design, your application or gateway must record the authenticated tenant and user for every storage operation.

Do not include customer names, email addresses, or other unnecessary personal information in application key names, object names, or log prefixes. Use an internal tenant identifier and resolve it through your control plane.

Interpret Bucket Access Log Records

Backblaze writes space-delimited records that follow the AWS S3 Bucket Access Log format, with Backblaze-specific identity values. Each record represents one request and can contain the following information:

• Bucket owner and bucket name

• Request time in UTC

• Remote IP address and requester identity

• Request ID, operation, and object name

• Request URI, HTTP status, and error code

• Bytes sent, object size, and processing time

• User agent, authentication type, endpoint, cipher suite, and TLS version

The following shortened example shows the general record structure:

<bucket-owner> <bucket-name> [<timestamp>] <remote-ip>
identity:applicationKey:<application-key-id> <request-id>
REST.GET.OBJECT <object-key> "GET /<object-key> HTTP/1.1"
200 - <bytes-sent> <object-size> <total-time> <turnaround-time>

Restrict access to the destination bucket. Access records can contain object names, IP addresses, user agents, and request URIs. Do not copy raw credentials, application key secrets, encryption keys, authorization headers, or complete signed URLs into additional application logs.

Query Tenant Activity

Ingest the records into your preferred query engine, SIEM, or monitoring platform. Normalize the log fields before building alerts or reports.

For example, after defining a table over the log objects, query requests made with a specific tenant application key:

SELECT
  requestdatetime,
  remoteip,
  requester,
  operation,
  key,
  httpstatus,
  errorcode,
  requestid
FROM b2.bucket_access_logs.source_bucket_logs
WHERE requester = 'identity:applicationKey:<application-key-id>';

To review object downloads, filter for the applicable GET operation:

SELECT
  requestdatetime,
  requester,
  remoteip,
  key,
  httpstatus,
  bytessent
FROM b2.bucket_access_logs.source_bucket_logs
WHERE operation IN ('REST.GET.OBJECT', 'REST.S3_GET_OBJECT');

Confirm the operation values present in your records before you build permanent detections. Normalize S3-Compatible API and B2 Native API operation names when they represent the same control.

Add Event Notifications for Faster Change Signals

Use Event Notifications when a downstream system should react quickly to object creation, deletion, or hide events. Event Notifications send JSON webhook messages to an HTTPS endpoint. This feature requires access from Backblaze Support.

Event Notifications complement Bucket Access Logs. They do not replace them because download events are not supported and notification payloads do not contain the full request record.

The following example shows the fields in an Event Notification payload:

{
  "events": [
    {
      "accountId": "e85c6a500333",
      "bucketId": "aea8c5bc362ae55070130333",
      "bucketName": "tenant-storage",
      "eventId": "ba9a8e4eacda8b4b7d23a0ec1f04046342c319f3c608903e794c45a5b57184be",
      "eventTimestamp": 1684793309123,
      "eventType": "b2:ObjectCreated:Upload",
      "eventVersion": 1,
      "matchedRuleName": "object-change-events",
      "objectName": "tenant-123/reports/report.csv",
      "objectSize": 10495842,
      "objectVersionId": "4_zaea8c5bc362a..."
    }
  ]
}

Use the following processing sequence:

1. Receive the HTTPS webhook request.

2. Verify the X-Bz-Event-Notification-Signature header with the HMAC SHA-256 signing secret.

3. Validate the payload and record the eventId.

4. Return an HTTP 200 response within three seconds.

5. Place the event on a durable queue for additional processing.

6. Deduplicate events by eventId.

7. Enrich the event with the internal tenant identifier and forward it to your monitoring or audit system.

Event Notifications use at-least-once delivery, so your consumer must tolerate duplicate messages. Backblaze retries a webhook when the endpoint does not return an HTTP 200 response within three seconds.

Record Application and CDN Context

B2 can identify the application key used for a request, but it cannot identify the person or application session behind a shared credential. Record that context before your service calls B2.

At minimum, record the following fields in your application or gateway log:

• Timestamp in UTC

• Internal tenant identifier

• Authenticated user or service identifier

• Requested operation and object key

• Authorization decision

• Application correlation ID

• B2 request ID, when available

• Response status and error category

• Number of bytes transferred

If a CDN serves objects, retain the CDN access logs needed to identify cache hits and viewer requests. A request served from cache might not reach B2, so the B2 access record alone cannot represent every end-user download.

Protect and Retain Logs

Define retention based on your investigation, contractual, and compliance requirements. Enabling logging does not, by itself, satisfy a particular compliance standard.

• Restrict write access to the raw-log destination bucket.

• Grant read access only to the log-processing service and authorized security or operations personnel.

• Monitor whether each source bucket still has logging enabled and whether its destination remains accessible.

• Use Lifecycle Rules to remove logs after the approved retention period.

• If immutability is required, copy or ingest delivered log objects into a separate Object Lock-enabled archive and apply the required retention setting there.

• Protect the tenant-to-key mapping for at least as long as you retain the logs.

• Encrypt log data in transit and at rest, and avoid writing secrets into the log stream.

Access log objects count toward storage usage. Include log volume, query processing, replication or copying, and long-term retention in your cost estimate.

Understand the Limitations

• Bucket Access Logs are delivered on a best-effort basis, usually within a few hours. Delivery time is not guaranteed.

• Access logs can be incomplete or contain duplicate records. Do not use them as the only source for billing or an exact accounting of every request.

• S3 Put Object Lock Configuration, S3 Get Object Lock Configuration, and CORS OPTIONS requests are not currently collected in Bucket Access Logs.

• Event Notifications do not support object download events.

• Event Notifications require access from Backblaze Support, and Group administrators cannot manage notification rules in a Group member's account.

• A shared application key does not provide per-tenant or per-user attribution.

• A Bucket Access Logs destination must be in the same B2 account and region as the source bucket.

• The access-log destination cannot have Object Lock enabled.

• Bucket Access Logs do not replace application, identity-provider, CDN, or organization-level administrative logs.

Troubleshooting

Use the following checks when expected access records or Event Notifications are missing.

Frequently Asked Questions

Does Backblaze B2 have access logs?

Yes. Bucket Access Logs are available to paying customers and record requests made on a bucket. You must enable logging on each source bucket and select a separate destination bucket in the same account and region. Delivery is best effort, and the logs can be delayed, incomplete, or duplicated.

How do I attribute activity to each tenant?

Issue a distinct, scoped application key to each tenant and maintain a mapping between the application key ID and your internal tenant ID. The Bucket Access Log identity field identifies the application key used for an authenticated request. If tenants share a credential, record tenant identity in your application or proxy logs.

Can Event Notifications record downloads?

No. Event Notifications support object creation, deletion, hide, replication-destination, and related change events, but they do not support object downloads. Use Bucket Access Logs for requests that reach B2 and CDN logs for viewer requests served at the edge.

Additional Resources

• Bucket Access Logs

• Enable and Manage Bucket Access Logs in the Enterprise Web Console

• Query Bucket Access Logs

• S3 Put Bucket Logging

• S3 Get Bucket Logging

• Event Notifications Reference Guide

• Create and Use Event Notifications

• Application Key Capabilities

• Cloud Storage Object Lock