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.

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::972873489489: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