Access to Audit Logs

Ataccama ONE records security-relevant activity in your environment, such as sign-ins, permission changes, and administrative actions. Ataccama keeps these audit logs for its internal security and compliance purposes.

On request, Ataccama shares your environment’s audit logs with you. You get read-only access to them in Amazon S3 and can ingest them into your own security information and event management (SIEM) or log management tooling.

This page describes what the audit logs contain, how long they are available, and what you need to prepare to get access.

How audit logs are collected

ONE records an audit event whenever a user, service account, or the platform itself performs an audited action. The events eligible for export are written to a dedicated audit log store for your environment:

Events are written in batches as compressed files, usually within a few minutes.
Audit logs are transferred over TLS between clusters and to Amazon S3, where they’re stored with server-side encryption.
Exported audit logs stay in the same geography as your environment. For details, see Cloud Regions and Data Residency.

Audited events

Audit logs include events in the following categories. The exact set of audited events can change as the platform evolves.

Category	Description
Authentication and sessions	Sign-ins and sign-outs, failed or rejected authentication attempts, and access token activity.
Account and identity management	Changes to users, groups, role assignments, credentials, and API clients.
Authorization	Changes to access levels and permissions, and denied access attempts.
Data access and changes	Data previews, exports, imports, and changes, as well as content package activity.
Data governance	Changes to stewardship and governance roles, and task assignments.
Data observability	Configuration changes and activity in data observability, such as alerts, policies, and integrations.
Lineage	Lineage scans and changes to scan plans.
AI Agent	Actions performed by ONE AI Agent and failed authentication to it.

Log format and structure

Audit logs for your environment are organized in daily folders:

Audit log file path

tenants/<TENANT_NAME>/<YYYY-MM-DD>/<TIMESTAMP>-<UUID>.log.gz

<TENANT_NAME>: The tenant name of your environment.
<YYYY-MM-DD>: The date the events occurred, in UTC. Files for a given day can still be added shortly after midnight UTC, so when you poll for new files, also check the previous day’s folder.
<TIMESTAMP>-<UUID>.log.gz: A gzip-compressed file with a Unix timestamp and a unique identifier in its name.

Each file contains one or more events, one JSON object per line. Each line holds the audit event in its message field, along with an observed_timestamp. message.timestamp is when the event happened, and observed_timestamp is when it entered the logging pipeline, usually within a second. The date folder is based on observed_timestamp.

Example audit event

The following example shows a single line, formatted for readability:

USER_LOGIN event, formatted for readability

{
  "observed_timestamp": "2026-10-01T08:15:42.481203117Z",
  "message": {
    "level": "INFO",
    "action": {
      "type": "USER_LOGIN",
      "status": "SUCCESS",
      "description": "User logged in: user j.doe, client onefrontend-one-webapp-public-client"
    },
    "tenant_name": "acme-prod",
    "user": {
      "id": "5f0c2a9e-7b1d-4c3e-9a68-2d4e8f1b7c35",
      "username": "j.doe",
      "email": "j.doe@example.com"
    },
    "network": {
      "source_ip": "203.0.113.42",
      "destination_ip": null,
      "destination_hostname": "acme.ataccama.one",
      "destination_port": 443,
      "http": {
        "request_uri": "/auth/realms/acme-prod/login-actions/authenticate",
        "method": "POST",
        "status_code": null,
        "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/153.0.0.0 Safari/537.36"
      }
    },
    "additional_details": {
      "event": "LOGIN",
      "user_type": "user",
      "client_id": "onefrontend-one-webapp-public-client",
      "session_id": "a1B2-c3D4e5F6g7H8i9J0kL1m",
      "username": "j.doe",
      "auth_method": "openid-connect",
      "auth_type": "code",
      "login_method": "LOCAL"
    },
    "timestamp": "2026-10-01T08:15:42Z",
    "log_type": "audit"
  }
}

Retention of exported audit logs

Exported audit logs are available for 14 days. After that, they’re deleted automatically. This retention period can be adjusted on request.

How access through the S3 access point works

Access to your audit logs is provided through an Amazon S3 access point dedicated to your environment:

The access point is limited to your environment’s audit logs. You can’t see or list any other data.
Access is read-only. You can list and download audit logs, but you can’t modify or delete them.
List requests must include your environment’s prefix, tenants/<TENANT_NAME>/, with the trailing slash. Listing the root of the access point or any other prefix returns AccessDenied.
Only the AWS Identity and Access Management (IAM) roles you specify in your AWS account are allowed to use the access point.
You read the audit logs with your own AWS credentials. No Ataccama credentials are shared with you.
All requests must use HTTPS.
Ataccama records access to your exported audit logs.

Because the access point is in an Ataccama AWS account, access is granted across accounts. Both sides must allow it: Ataccama allows your IAM role in the access point policy, and you allow the same role to use the access point in your IAM policy.

Prerequisites

An AWS account.
IAM permissions to create IAM roles and policies in that account.
An IAM role that reads the audit logs, for example, the role your SIEM uses to ingest data from Amazon S3.

Use an IAM role rather than an IAM user, so that no long-term access keys are involved. A dedicated role also keeps this access separate from your other permissions.

Prepare your IAM role

Attach the following identity-based policy to the IAM role that reads the audit logs. You receive the values in angle brackets once access is set up (see What you receive). You can create the role and policy before that, and update the policy when you have the values.

Identity-based policy for the audit log reader role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListAuditLogs",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": [
        "arn:aws:s3:<REGION>:<ATACCAMA_ACCOUNT_ID>:accesspoint/<ACCESS_POINT_NAME>",
        "arn:aws:s3:::<BUCKET_NAME>"
      ],
      "Condition": {
        "StringLike": {
          "s3:prefix": "tenants/<TENANT_NAME>/*"
        }
      }
    },
    {
      "Sid": "ReadAuditLogs",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": [
        "arn:aws:s3:<REGION>:<ATACCAMA_ACCOUNT_ID>:accesspoint/<ACCESS_POINT_NAME>/object/tenants/<TENANT_NAME>/*",
        "arn:aws:s3:::<BUCKET_NAME>/tenants/<TENANT_NAME>/*"
      ]
    }
  ]
}

The policy names both the access point and the bucket behind it, because AWS checks requests from another account against both. This doesn’t give you direct access to the bucket: Ataccama allows requests only through your access point.

Grant only these permissions. The role doesn’t need any other access to the Ataccama AWS account.

Request access

To request access to your audit logs, contact Ataccama Support. Requests are accepted only from an authorized contact for your environment, such as an environment administrator or your designated security contact.

Include the following information in your request:

Information Example Why it’s needed

Information	Example	Why it’s needed
Tenant name	`acme-prod`	Identifies which environment’s audit logs to share. It’s also the folder name under `tenants/`. If you’re not sure, send your Ataccama ONE sign-in URL.
AWS account ID	`123456789012`	The account that will read the audit logs.
IAM role Amazon Resource Name (ARN)	`arn:aws:iam::123456789012:role/audit-log-reader`	The roles allowed to use the access point. You can provide more than one ARN.
Technical contact	Name and email address	The person Ataccama contacts about the setup.

Tenant name

acme-prod

Identifies which environment’s audit logs to share. It’s also the folder name under tenants/. If you’re not sure, send your Ataccama ONE sign-in URL.

AWS account ID

123456789012

The account that will read the audit logs.

IAM role Amazon Resource Name (ARN)

arn:aws:iam::123456789012:role/audit-log-reader

The roles allowed to use the access point. You can provide more than one ARN.

Technical contact

Name and email address

The person Ataccama contacts about the setup.

What you receive

Once access is set up, you receive:

The access point ARN, for example, arn:aws:s3:<REGION>:<ATACCAMA_ACCOUNT_ID>:accesspoint/<ACCESS_POINT_NAME>.
The access point alias, which you can use anywhere a bucket name is expected, such as the AWS CLI, AWS SDKs, and SIEM integrations that poll Amazon S3. When you configure a SIEM integration or another tool that polls Amazon S3, set its prefix (often called key prefix or path) to tenants/<TENANT_NAME>/.
The name of the bucket behind the access point, which your IAM policy references.
The AWS Region.
Your environment’s tenant name, which is the folder name under tenants/.

Use these values to complete the policy in Prepare your IAM role.

Verify access

Using credentials for the IAM role you provided, run the following AWS CLI commands:

List the available days:

aws s3 ls s3://<ACCESS_POINT_ALIAS>/tenants/<TENANT_NAME>/ --region <REGION>

Download a file from one of the days:

aws s3 cp s3://<ACCESS_POINT_ALIAS>/tenants/<TENANT_NAME>/<YYYY-MM-DD>/<FILE_NAME> . --region <REGION>

Decompress the file:
```
gunzip <FILE_NAME>
```
Each line in the decompressed file is one audit event in JSON.

Check that:

The list command returns daily folders for your environment.
You can download and decompress a file.

If a command returns AccessDenied, check that:

You’re using the same IAM role whose ARN you provided.
The policy from Prepare your IAM role is attached to the role and contains the values you received.
The paths in your commands include tenants/<TENANT_NAME>/, with the trailing slash. aws s3 ls s3://<ACCESS_POINT_ALIAS>/ without a path always returns AccessDenied.
Your organization’s guardrails, such as service control policies, permission boundaries, or VPC endpoint policies, allow access to the access point ARN and the bucket.

If the issue persists, contact Ataccama Support.

Shared responsibilities for audit log access

Ataccama is responsible for:

Collecting audit events and storing them separately for each environment.
Transferring audit logs over TLS between clusters and to Amazon S3, and storing them encrypted at rest.
Enforcing the retention period.
Limiting the access point to your environment’s audit logs and to the IAM roles you specified.

You’re responsible for:

Securing the IAM role that reads the audit logs and the credentials used to assume it.
Protecting the audit logs you download and keeping them for as long as your own policies require.
Contacting Ataccama Support when the roles that need access change, or when access is no longer needed.

Change or revoke access

To add or replace IAM roles or to revoke access, contact Ataccama Support with the same information as in Request access.

Was this page useful?