Activity Monitoring for AWS

Identify overprovisioned and inactive users using CloudTrail logs.

ℹ️ Early Access: Monitoring for AWS is part of Access Monitoring, which must be enabled by our support team.

Veza gathers CloudTrail logs to audit user activity and generates Over Provisioned Scores (OPS) to show the percentage of unutilized access. This document provides steps to enable audit log extraction for an integrated AWS account.

Notes

• Supported Entities: Veza generates over-provisioned scores for these relationships:

  Source Entity	Destination Entity
  AWS IAM User	AWS S3 Bucket
  AWS IAM User	AWS Secrets Manager Secret
  AWS IAM User	AWS KMS Key
  Okta Identity*	AWS S3 Bucket
  Okta Identity*	AWS Secrets Manager Secret
  Okta Identity*	AWS KMS Key

  * Requires Activity Monitoring for Okta

• Monitoring for multiple AWS accounts: To enable Activity Monitoring across several accounts in your organization, you'll need to repeat these steps for each integration for each account. In Query Builder results, OPS will be N/A for users from accounts where Activity Monitoring is not enabled.

• The Activity Monitoring dashboard shows the dormant and over-provisioned AWS IAM Users, based on the resources they can access and the current Activity Monitoring time range. You can add constraints on OPS to Queries and Rules to enforce policies around user activity and actual resource usage.

• Activity Monitoring Attributes: Veza creates properties to track different types of activity based on the resource type:

  • AWS IAM User:

    • Last Activity At: Timestamp of the most recent activity where the user was the principal, including activities in services not currently supported in Activity Monitoring (e.g., EC2 RunInstances)

  • AWS KMS Key:

    • Last Activity At: Timestamp of the most recent key usage of any type

    • Last Viewed: Timestamp of the most recent cryptographic operation that consumed key material (e.g., Decrypt)

Enabling Activity Monitoring for AWS

You can enable monitoring for a single AWS account with an account-level trail, or create an organization trail containing events from several regions and accounts:

• In AWS, create an organization or account-level trail for activity monitoring, or use an existing one. If you have many accounts where you want to enable monitoring, an organization trail is recommended for easier configuration.

• In AWS, ensure the Veza service principal has authorization to discover cloud trails and read the trail in S3.

• In Veza, enable audit logs for each AWS account integration. You can specify the same S3 bucket and organization trail (identified by its AWS resource name) for all integrations.

Enabling Activity Monitoring with AWS Control Tower For organizations that use AWS Control Tower to govern a multi-account AWS environment, AWS CloudTrail is configured by default, with two key accounts:

• A Management account at the organization root, where Control Tower is configured.

• A Log Archive account containing the S3 bucket where audit logs are stored.

In this scenario, you will need to configure Veza to extract audit logs from the log archive account, and skip extraction for the management account and other accounts in the organization:

1. Integrate the Log Archive account with Veza, if it is not already. To do so, use Cloud Formation for AWS Organizations, or add an AWS Account Integration.

2. Ensure that the Log Archive integration trust policy includes a policy for audit log extraction, allowing s3:ListBucket and s3:GetObject on the bucket and log files.

3. Enable audit logs for the Log Archive account integration. Enable the option "Extract for Organization" for this account.

4. Enable audit logs for all other accounts in the organization, choosing the "Skip Extraction" option for each account.

See the following steps for more details. Apply the appropriate policies based on your CloudTrail configuration:

Step 1: Retrieve CloudTrail region and trail name

Each account integration connects to a single Trail with event logs for the desired regions, accounts, and resources to gather activity data.

• To use an existing Trail, search for CloudTrail on the AWS Console, and save the name and region for configuring the integration in Veza. The trail must include S3, Secret Manager, and IAM events.

  • 

• If Veza cannot use an existing Trail, see Creating a Trail for the current instructions from AWS.

Step 2: Update AWS integration permissions

To enable Audit Log Extraction and Activity Monitoring for several AWS account integrations in Veza, you will need to update the integration trust policy within each AWS account to grant access to the S3 bucket and trail.

The AWS IAM Policy used by each Veza-AWS integration must grant permissions to read CloudTrail metadata, and list and retrieve objects in the S3 bucket and path where the CloudTrail logs are stored.

Follow the instructions below for organization or account trails, depending on your AWS architecture.

To update the integration trust policy:

1. On the AWS IAM Console, open the Policies page and locate the one used by the Veza-AWS Integration.

2. Search for the following SID, and create it if necessary:

   {
     "Sid": "CloudTrail",
     "Effect": "Allow",
     "Action": [
     "cloudtrail:GetTrail"
     ],
     "Resource": "*"
   }

   This is required to discover if trails exist in the AWS account. Creating an AWS integration using the recommended policy includes the CloudTrail statement by default.

3. Enable access to account and organization-level cloud trails, using the examples below.

4. Save the changes to the policy.

Policy for audit log extraction

Organization Trails

Update the integration IAM policy for the account where the organization trails resides to include the following statement. Depending on your environment, this could be the management account, or a dedicated log archive account. The following statement will allow Veza read access to retrieve logs from S3:

{
  "Sid": "CloudTrail",
  "Effect": "Allow",
  "Action": [
    "cloudtrail:GetTrail"
  ],
  "Resource": "*"
},
{
  "Sid": "CloudTrail-S3",
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::<bucket name>/AWSLogs/<organization id>/*",
    "arn:aws:s3:::<bucket name>"
  ]
}

To configure Activity Monitoring, use the organization trail ARN to enable audit logs for accounts in the organization where you want to enable monitoring. Choose "Extract for Organization" for the account where logs are stored. For other accounts in the organization, enter the trail ARN and select "Skip Extraction".

See Creating a trail for an organization for more on configuring organization trails in AWS.

Account Trails

To enable audit logs for multiple AWS accounts with account-level trails configured, each AWS account integration must have read permissions to discover trails and retrieve logs from S3.

See Creating a trail for your AWS account for more information about account-level trails.

Integration trust policy

For each account where you want to enable activity monitoring, update the integration policy to include the statement:

{
  "Sid": "CloudTrail-S3",
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
     "arn:aws:s3:::<bucket name>/AWSLogs/<path to the files for the veza account>/*",
     "arn:aws:s3:::<bucket name>"
  ]
}

The path contains the AWS account ID. In the example above, <path to files for the Veza account> should have a unique value in each integration trust policy.

Key and bucket policies

You will need to update the S3 bucket policy or ACL, and possibly add a key policy, to ensure the Veza service principal (user or role) for each account integration has permission to read the files in S3. The required privileges are:

• s3:ListBucket on the S3 bucket that CloudTrail logs into

• s3:GetObject on the files logged by this trail in the bucket

• kms:Decrypt on the KMS key (if a key is used to encrypt the trail)

Example bucket policy:

{
  "Sid": "sid",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN of the Veza user or role>"
  },
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "arn:aws:s3:::<bucket name>/AWSLogs/<path to the files for the veza account>/*",
}
{
  "Sid": "sid",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN of the Veza user or role>"
  },
  "Action": [
    "s3:ListBucket",
  ],
  "Resource": [
    "arn:aws:s3:::<bucket name>"
  ]
}

Example key policy:

{
  "Sid": "sid",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN of the Veza user or role>"
  },
  "Action": "kms:Decrypt",
  "Resource": "<the key ARN>"
}

You can find the file and key location under “General details” on the trail details page.

Testing audit log permissions

To validate if an integration can access a trail in S3, try to download the file with the user or role that Veza assumes to access AWS:

aws s3api get-object --bucket <the S3 bucket for the trail> --key <any log file in the bucket> <path to save the file>

Step 3: Enable Audit Logs for the AWS Integration

In Veza, enable audit logs for each account where activity monitoring will be active:

1. On the Veza Integrations page, go to the Integrations page and click Enable Audit Logs next to the name of the AWS integration.

   

   Enabling audit logs.
2. In the modal, enter the values from AWS:

   • The name of the Trail Veza will connect to, e.g., veza_s3_monitoring. For Organization trails, use the full ARN as the name, or when the trail is owned by an account other than the integration account.

   • The AWS region the CloudTrail service resides, e.g., us-east-2.

   • For organization trails, check "Extract for Organization" for the management account, and "Skip Extraction" for other accounts in the organization.

   • If your environment uses a log archive account for trail storage, check "Extract for Organization" for that account, and "Skip Extraction" for all other integrations.

   • For account trails, leave both checkboxes unchecked.

     

     Enabling an organization trail for the owner account.
3. Save your changes. The integration will gather CloudTrail logs to calculate Over-Provisioned Access Scores during the next extraction cycle.

4. Repeat this step for each AWS integration where you want to enable Activity Monitoring.