📊Access Monitoring

Over Provisioned Scores and dormant access insights

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.

Supported Integrations

Platform
Activity Monitoring
Audit Log Source
OPAS Supported
Feature Status

CloudTrail

Generally Available

Query History

Generally Available

Audit Logs

Generally Available

System Logs

Early Access

Entra ID Activity

Early Access

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

  • Entra ID activity logs (for SharePoint monitoring)

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.

Enabling Audit Log Extraction: On the Veza Integrations page, locate your integration and click the integration name to view details. Then, expand the actions menu at the top right and click Enable Audit Logs.

Enabling audit logs for an AWS integration

This will enable activity monitoring for the selected platform.

Last Activity 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 (OPAS) 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 Access Score (OPAS).

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.

How Activity Monitoring Works

Activity Monitoring analyzes your organization's actual access patterns by:

  1. Collecting Activity Data: Veza gathers audit logs from integrated systems (AWS CloudTrail, Snowflake query history, Okta system logs, etc.)

  2. Analyzing Usage Patterns: The system identifies which resources are actively accessed versus those that are simply granted

  3. Calculating OPAS Scores: Over Provisioned Access Scores are calculated using the formula: (Total Resources - Accessed Resources) / Total Resources * 100

  4. Providing Insights: Activity data is combined with authorization data to highlight over-privileged access and dormant permissions

Data Timeframe: Activity analysis is based on your configured monitoring timeframe (30-120 days), allowing you to adjust the sensitivity of dormant access detection.

Over Provisioned Score

Over Provisioned Access Score (OPAS) adds 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 Access Score (OPAS) 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 OPAS is 50%. If they had read only 20 tables, the OPAS would be 80%.

Users can have different scores for different resource types (such as tables, views, or databases). Over Provisioned Access Score (OPAS) 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.

Activity Monitoring Calculated Fields

After enabling Access Monitoring and audit log extraction, Veza provides several calculated fields to track entity activity and usage patterns. These fields are available for supported integrations including Snowflake, AWS, Okta, and others.

Last Activity At (Entity Property)

Last Activity At is a node property that represents the most recent timestamp when any activity occurred for a particular entity (such as a Role, Database, Table, or User). This field captures all types of activity for the entity, including:

  • Direct resource access (e.g., querying a table, reading a file)

  • Administrative operations (e.g., metadata queries like "SHOW GRANTS")

  • Configuration changes to the entity itself

  • Any other logged activity involving the entity

This field behaves consistently across all query types and represents the entity's overall activity timestamp, regardless of which specific resources were involved in the activity.

Last Activity With Resource At (Relationship Property)

Last Activity With Resource At is an edge property that captures the timestamp for when a specific relationship between two entities was last active. This applies to entity pairs such as:

  • (User, Role) - when the user last utilized the role

  • (Role, Database) - when the role last accessed the database

  • (User, Table) - when the user last accessed the table

This field is only shown in Query Builder when the "Show Destination Entities" option is enabled, as it represents the relationship-specific activity rather than general entity activity.

An important distinction exists between these two fields: "Last Activity At" for an entity may be more recent than the maximum "Last Activity With Resource At" for any of its associated resources.

Example Scenario:

  1. Time T1: User U1 uses Role R1 to access multiple resources (tables, databases, etc.)

    • Role R1's "Last Activity At" = T1

    • "Last Activity With Resource At" for each accessed resource = T1

  2. Time T2 (later): User U1 uses Role R1 to perform a metadata query like "SHOW GRANTS" (no specific resources accessed)

    • Role R1's "Last Activity At" = T2 (updated to reflect recent activity)

    • "Last Activity With Resource At" for resources remains = T1 (no resource-specific access occurred)

In this scenario, R1's "Last Activity At" (T2) is more recent than any "Last Activity With Resource At" timestamp (T1), demonstrating that the role was active but did not access specific tracked resources.

Last Used At (Source System Property)

Last Used At differs from the calculated fields above as it represents a timestamp extracted directly from the integrated data source. This field:

  • Typically represents the last time an identity or resource was used for any reason according to the source system

  • Is not available in or provided by all systems

  • Will show "Never" if this metadata is unavailable from the source

  • May use different criteria than Veza's activity monitoring for determining "usage"

Query Builder Usage

In the Query Builder, these attributes appear as filterable columns:

  • Single-node queries: Show "Last Activity At" for the queried entity type

  • Relationship queries with "Show Destination Entities" enabled: Show both "Last Activity At" for source entities and "Last Activity With Resource At" for the relationship pairs

  • Node-with-count queries: Show "Last Activity At" for source entities, with relationship-specific activity available in expanded views

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 (such as 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 Access Score (OPAS).

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

Access Monitoring using Query Builder

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

The following queries support Over Provisioned Access Score (OPAS):

  • 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 Service Account 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 Access Score (OPAS) column. Click a score to show:

  • All resources a principal relates to

  • Details about the used and unused permissions

  • Last activity time

Over Provisioned Access Score (OPAS) 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 OPAS-based queries and creating rules from these queries.

OPAS for individual permissions or resources

To see user OPAS 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 Access Score (OPAS) 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 Access Score (OPAS) have changed

  5. Next, pick from the Permissions menu to filter the results and update the OPAS 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 OPAS 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 Access Score (OPAS) threshold to only show users with high OPAS 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 Access Score (OPAS)

You can create queries that filter results by OPAS, 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 OPAS of over 33%:

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

  2. Set the Over Provisioned Access Score (OPAS) 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 Access Score (OPAS)

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

  1. Create a rule for a query that uses OPAS, 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 Access Score (OPAS)

  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

Technical Reference

Configuration Options

Activity Monitoring Timeframe: You can customize how far back Veza looks for activity data when calculating OPAS scores. The default is 30 days, but you can extend this to 60, 90, or 120 days depending on your organization's access patterns. Longer timeframes provide more comprehensive usage data but may classify seasonal or infrequent access as dormant.

Score Calculation: OPAS scores are calculated when you run queries, ensuring you always see current results based on the latest activity data and your selected timeframe.

Data Retention: Veza retains activity data according to your configured timeframe and maintains additional historical data for trend analysis and reporting.

API Field Reference

These fields appear in API responses and may differ from display names:

  • last_activity_at: Most recent activity timestamp for the entity

  • last_activity_with_resource_at: Most recent activity timestamp for specific entity relationships

  • over_provisioned_score: Percentage of unused access permissions (OPAS)

  • engagement_score: Percentage of permissions actively used

  • accessed_count: Number of resources with recorded activity

  • total_count: Total number of resources the entity has access to

Setup Requirements

For detailed setup instructions including specific permissions and configuration steps, refer to the individual integration guides:

Troubleshooting

Issue
Troubleshooting Steps

OPAS scores not appearing in Query Builder

- Verify that audit log extraction is enabled for your integration - Check that the integration has the required permissions to access audit logs - Ensure you're using a supported query type (see "Access Monitoring using Query Builder" section)

Activity data seems incomplete or missing

- Activity monitoring begins collecting data after feature enablement; historical scores are not retroactive - Activity data processing can take up to 24 hours after initial setup - Verify that the monitored systems are generating audit logs in the expected format

OPAS scores appear inconsistent

- OPAS is calculated based on your selected Activity Monitoring timeframe - Scores will change as you apply different permission filters in Query Builder - Different resource types (tables, views, databases) may have different OPAS scores for the same user

Need help with specific integrations?

For integration-specific troubleshooting, authentication issues, or detailed setup guidance, refer to the individual integration documentation linked in the Setup Requirements section above.

Last updated

Was this helpful?