📊Access Monitoring

Over Provisioned Scores and dormant access insights

Early Access: Access Monitoring is provided on an Early Access basis. Please contact our customer success team to enable the feature. By default, monitoring supports AWS, Snowflake, and Google Cloud BigQuery, after enabling audit logs for these integrations. Monitoring for Okta is available in Early Access.

Overview

Veza Access Monitoring provides visibility into actual access and usage of resources across your cloud environments and data stores. It collects and analyzes log data to determine which identities (users, roles, service accounts) have accessed specific resources such as databases, data tables, cloud storage, applications, and more.

Access Monitoring enables Veza operators to search for identities with more privileges than they are actually using, create rules to govern permission creep, and remediate dormant access with reports, queries, and the Activity Monitoring page.

Access Monitoring is currently supported for the Snowflake, Okta, AWS, and Google Cloud BigQuery integrations. Toggling Audit Log extraction for these integrations will enable or disable monitoring capabilities.

Key Features

Access Auditing: When enabled, Veza gathers access logs from sources such as:

• Snowflake

• AWS CloudTrail

• Okta system logs

• Google Cloud Audit Logs

Veza aggregates this data to show which identities accessed which resources, and when the access occurred.

To gather this information, you will need to enable audit log extraction on the Veza Integrations page, and ensure the integration service account has the required permissions to read available activity logs.

Last Accessed Tracking: For monitored resources, the feature tracks the last time each identity accessed the resource. This highlights dormant or unused access that can potentially be revoked to reduce the attack surface.

An Over Provisioned Access score is calculated for each identity and resource pair, comparing the actual activity level against the level of access granted. Higher scores indicate over-privileged access that may need review.

Access data can power rules, alerts, and workflow triggers. For example, creating a remediation ticket whenever an over-privileged identity is detected based on Over Provisioned Scores.

Cloud Entitlements Dashboard: For supported systems, pre-built dashboards provide an overview of:

• Most active identities

• Dormant and unused identities

• Dormant roles

• Other entitlement metrics

This provides visibility for privileged access management and identifying areas to apply least privilege principles.

Use these tools to understand the gap between granted permissions and actual usage, and optimize access rights to align with the principle of least privilege.

Over Provisioned Score

Over Provisioned Scores add an additional dimension to the Query Builder and search results, enabling filtering and sorting based on recent activity and actual usage. For supported queries, an additional column shows the Over Provisioned Score (OPS) for each result. This score represents a ratio of the total resources a user has permissions on, compared to the how many resources they are actually interacting with.

A higher score indicates more underutilized access. If a user can read 100 tables, but only used this permission on 50 tables, their Table Read OPS is 50%. If they had read only 20 tables, the OPS would be 80%.

Users can have different scores for different resource types (such as tables, views, or databases). Over Provisioned Scores update as query filters are applied to limit the range of utilized permissions or destination resources.

Customizing the date range for Access Monitoring: Administrators can customize the date range for Access Monitoring under System Settings > Activity Monitoring Time Frame. The period of inactivity can be 30, 60, 90, or 120 days.

"Last Used At" and "Last Activity At" in Query Builder

After enabling Access Monitoring and audit log extraction, supported entities (such as Snowflake Local Roles) will have a "Last Activity At" attribute.

In the Query Builder, these attributes are shown in filterable columns. The "Last Activity At" attribute differs from the "Last Used At" attribute.

• Last Activity At is a timestamp generated from activity logs. It represents the last time a source entity had any activity on a resource, such as a user utilizing a role to gain access to a resource, or edit the role itself.

• Last Used At is a timestamp extracted directly from the integrated data source. It typically represents the last time an identity or resource was used for any reason, and is not available in or provided by all systems. The Last Used At value will be "Never" if this metadata is unavailable.

Activity Monitoring

The Activity Monitoring page is a streamlined search interface providing an overview of dormant access for supported platforms. You can open any search in the Query Builder to add constraints and save it to use in reports, create rules, or filter another query.

To use the Activity Monitoring overview:

1. Go to Access Monitoring > Activity Monitoring

2. Use the menus to choose a platform (AWS, Okta, Snowflake, or Google Cloud)

3. Choose a principal (Okta User, AWS IAM User or Role, Snowflake User or Role, Google Workspace User, or Google Cloud Service Account)

4. Choose a related resource (Okta App, AWS S3 Bucket or AWS Secrets Manager Secret, Snowflake database, view, table, or schema, BigQuery Dataset, or BigQuery Table)

5. Optionally, enable Show dormant entities only to filter out results with no Over Provisioned Score.

Extra columns appear containing usage information for each result. These show the Over Provisioned Score, total available resources, actual resources accessed, and the percentage of total utilized access.

Access Monitoring using Query Builder

To create queries with Over Provisioned Score parameters, go to Access Visibility > Query Builder, and choose a supported source and related entity type.

The following queries support Over Provisioned Scores:

• Okta User to Okta App or AWS S3 Bucket or AWS Secrets Manager Secret or AWS KMS Key

• AWS IAM User or Role to AWS S3 Bucket or AWS Secrets Manager Secret or AWS KMS Key

• Snowflake User or Role to Snowflake Database, View, Table, or Schema.

• Snowflake Role to Snowflake User

• Snowflake User to Snowflake Role

• Google Workspace User to BigQuery Dataset or BigQuery Table

• Google Cloud ServiceAccount to BigQuery Dataset or BigQuery Table

You can also open a search on the Activity Monitoring page to pre-fill the query builder.

For supported queries, results have an Over Provisioned Score column. Click a score to show:

• All resources a principal relates to

• Details about the used and unused permissions

• Last activity time

Over Provisioned Score Threshold: Use these Query Builder options to filter out results that are above, below, or equal to a given score based on the activity monitoring time range.

Permissions: In Query Builder, scores are based on the current permission filters. With no permissions specified, any usage will count as activity.

Last Activity timestamps: This column is enabled when using the "Show (Resource)" option in Query Builder. This returns results as principal and resource pairs, instead of showing one result for each principal. Use this to review detailed metadata about each destination resource.

Access Monitoring Examples

Here are a few examples for creating OPS-based queries and creating rules from these queries.

OPS for individual permissions or resources

To see user OPS for specific databases, or for a particular set of permissions:

Search for Snowflake Local User grouped by Snowflake Database. The results will show all users with access to any database. The Over Provisioned Score for the results accounts for any permission on any Snowflake database.

Optionally, click a number in the "Snowflake Databases column to see all databases the user can access, and their cumulative effective permissions on that database:

Apply a constraint on the database name:

1. Click Filters > Add Attribute Filter

2. Pick "Snowflake Database" for the Entity Type

3. Filter Snowflake Databases with the constraint "Name" "Equals" "<Single Database Name>"

4. Note that the query results and Over Provisioned Scores have changed

5. Next, pick from the Permissions menu to filter the results and update the OPS accordingly.

You can filter on one or more canonical or system permissions. A system permission is an explicit privilege, as defined by the service provider (such as RENAME TABLE in Snowflake). The canonical permission is the effective Create/Read/Write/Delete equivalent (such as METADATA WRITE).

Google Cloud BigQuery

To check for over-provisioned Google Cloud users with access to BigQuery datasets:

1. Create a new query for "Google Workspace User" grouped by "Big Query Dataset"

2. The results will show all users with access to any dataset, with their OPS score based on actual dataset usage

3. To focus on specific permissions, use the Permissions filter to select BigQuery-specific permissions like bigquery.datasets.get or canonical permissions like DATA READ

4. Add an Over Provisioned Score threshold to only show users with high OPS values (e.g., 75% or higher)

5. Save the query for future reference or to create rules based on it

Alerts and Rules with Over Provisioned Scores

You can create queries that filter results by OPS, and then create rules to alert when the number of dormant entities meets or exceeds a threshold.

For example, to alert when a Veza detects a user with a Database Read OPS of over 33%:

1. Create a new query for "Snowflake Local User" grouped by "Snowflake Database"

2. Set the Over Provisioned Score Threshold:

   1. Change the operator to >= (greater than or equal to)

   2. Set the threshold to 33%

3. Add the DATA READ canonical permission.

4. Save the Query with a name and description

5. Go to Saved Queries and find the new query:

   1. Open the query actions menu and click Add Alert Rule

   2. Add the condition "If Query Results have increased by more than 1 occurrences"

   3. Pick an alert destination and click next

   4. Add a name and description. Click Finish to save the rule.

After configuration, the target destination will receive a notification payload when Veza detects a user with actual usage of less than a third of their total "Database Data Read" entitlements.

Rule Conditions for Over Provisioned Scores

You can also create rules that trigger when there are changes to OPS scores for individual query results.

1. Create a rule for a query that uses OPS, by saving a Query Builder query, the Saved Queries page, or Access Monitoring dashboard.

2. Change the if condition from Query Results to Over Provisioned Score

3. Pick an operator, for example, "are more than"

4. Pick a value, such as 75

5. Choose where to deliver the alert

6. Set the name, description, and severity

7. Save the rule