Audit Log

Audit logs are records of what happens inside your GoodData environment. These logs help you track who did what, when they did it, how they did it, and what they changed.

The audit log can support you in several critical areas:

• Security and fraud prevention – Monitor unauthorized or suspicious activity.
• Compliance and legal requirements – Meet GDPR, HIPAA, or SOC2 standards.
• Troubleshooting and support – Quickly trace issues and understand changes that impact your setup.

Audit Log Scope and AI-Initiated Actions

The audit log records events that GoodData considers relevant for security investigations, data access, and changes to the solution. It is not intended to contain every individual interaction with the platform.

For example, searching for a dashboard or visualization through the user interface, API, or AI Assistant does not create an audit log entry unless the action also triggers one of the events listed in the Audit Events section.

AI Assistant does not grant users additional permissions. If the AI Assistant performs an action on behalf of a user and the same action is covered by the audit log when performed directly through the UI or API, GoodData records the same audit event. Depending on the action, additional metadata may distinguish whether the action was initiated through the AI Assistant, for example by including an agent identifier.

Diagnostic identifiers such as traceId or X-GDC-TRACE-ID are used for internal troubleshooting. They are not intended as stable end-to-end audit correlation identifiers.

Setting up Audit Logging

To deliver audit logs to you, GoodData uses AWS Cloud services as the supported storage platform. GoodData generates the audit log data and sends it through the Audit Log Event Forwarder component to an Amazon S3 bucket that you provide and control. This setup ensures that you have full ownership of your audit data and can integrate it with your internal systems (such as SIEM tools).

Follow the steps below to get started:

1. Using the following definition, create or update your S3 bucket policy to allow GoodData to deliver audit log files.

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "GD-Cloud-auditlog-access",
          "Effect": "Allow",
          "Principal": {
              "AWS": "arn:aws:iam::772547432422:root"
          },
          "Action": [
              "s3:PutObject",
              "s3:GetBucketLocation",
              "s3:AbortMultipartUpload",
              "s3:ListBucket"
          ],
          "Resource": [
              "arn:aws:s3:::<bucket-name>",
              "arn:aws:s3:::<bucket-name>/*"
          ]
      }
  ]
}

2. Once your bucket is ready, provide our Support team with the bucket-name (as defined in the previous step). We will take care of the remaining setup and configure the system to write audit logs directly to your specified S3 bucket.

3. After the setup, the logs will begin appearing in your S3 bucket under the auditlog/default/<orgId> path. From there, you can integrate them into your Security Information and Event Management (SIEM) system for ongoing monitoring, alerting, and incident response.

Example:

$ aws s3 ls s3://<your-bucket-name>/auditlog/default/<your-org-id>/ --profile <your-profile>
YYYY-MM-DD HH:MM:SS      24850 12345678901234.json
YYYY-MM-DD HH:MM:SS      24850 12345678901285.json

Audit Log Entries

Each audit log entry is saved in JSON format and includes a set of mandatory fields, which are standardized and present in every log entry, regardless of the event type:

Example Audit Log Entry:

{
  "eventName": "user_login",
  "categoryUid": "3",
  "classUid": "3002",
  "description": "User XY logged in",
  "ts": "2023-01-20T18:55:32.466Z",
  "orgId": "org_abc123",
  "workspaceId": "workspace_xyz456",
  "userId": "user_XY",
  "target": "organization_setting_XY",
  "source": "1.2.3.4",
  "sessionContextType": "OIDC",
  "sessionContextIdentifier": "token_1234",
  "success": true,
  "type": "audit"
}

Audit Events

Below is a complete list of all audit log events, including their meanings, categories, and classes. The categories and classes follow the Open Cybersecurity Schema Framework (OCSF) where applicable.

Audit Logging for Layout APIs

When using the layout APIs, deletion of old resources is recorded through a single audit log message per action, rather than individual entries for each sub-resource. However, creation events are logged individually for each entity.

Here is how deletion events are logged:

• eventName = workspace_delete, target = <org_id> (Triggered by the organization layout API) This also deletes: workspace settings, dashboards, visualizations, and permissions.

• eventName = workspace_delete, target = <workspace_id> (Triggered by the workspace layout API) This also deletes: workspace settings, dashboards, visualizations, and permissions.

• eventName = analytics_model_delete, target = <workspace_id> (Triggered by the analytics model layout API) This also deletes related permissions.

• eventName = datasource_delete, target = <organization_id> Deletes the data source and all related permissions.

Limitations

• The audit log does not provide a complete record of every API request, UI interaction, or AI Assistant conversation.
• Authorization failures, 403 responses, failed AI actions, prompt-injection attempts, and policy-blocked actions are not generally recorded as audit events unless they correspond to one of the events listed in the Audit Events section.
• Diagnostic logs may contain additional troubleshooting information, but diagnostic log fields and formats are not part of the public audit log.