📖Veza Glossary
Definitions and explanations for key terms and concepts used within Veza.
Last updated
Was this helpful?
Definitions and explanations for key terms and concepts used within Veza.
Last updated
Was this helpful?
Was this helpful?
As Veza evolves and integrates more advanced functionalities, the terminology can sometimes be intricate. The Veza glossary serves as a reference for terms and related topics. Whether you're a new user getting acquainted with the platform, or just seeking a refresher, this glossary can help you learn the essential terms.
Browse the categories to explore, or search to find a specific term.
A time-bound snapshot of entities, relationships, and their attributes collected by Veza integrations. Used for investigating, intelligence automation, and rule creation across connected applications, identity providers, and cloud services.
A Cloud Service Provider (CSP), such as AWS or Microsoft Azure, offers a platform for infrastructure, applications, storage, and other services such as Identity and Access Management or data warehousing.
Permissions are the individual rights and authorizations that a user has to perform actions on resources. In modern IAM, “effective permissions” are the actual permissions a user is authorized to perform after applying all the constructs of IAM, including deny, service control policy, permission boundary, or other access controls. “System permissions” are the permissions that are directly assigned or granted to a principal (e.g., user, group, or role) on a specific resource (e.g., file, folder, or object). These permissions are typically defined and managed within the security system and set the basic level of access.
In Veza, Effective Permissions can be Data (C)reate, (R)ead, (W)rite, (D)elete, (N)on-Data, and (M)etadata.
In Graph search, (S)ub indicates when a principal has permissions on sub-resources within a service. Examples of effective permissions and corresponding capabilities
MetadataWrite, MetadataRead, MetadataCreate, MetadataDelete - Permission to create a Redshift Database table, or change an S3 bucket policy.
DataRead, DataWrite, DataCreate, DataDelete - A data read, write, create, or delete permission, such as reading database tables, or pushing to a repository.
NonData - All other permissions that do not apply to data, such as permission to cancel a Redshift query or reboot a Redshift cluster.
A group is a collection of users sharing the same set of permissions.
Identity and Access Management (IAM) is a security framework that helps organizations manage and control access to their resources and applications.
An Identity Provider (IdP), such as Okta or AWS SSO, is a service that stores and verifies user identity. IdPs are typically cloud-hosted and enable single sign-on to other systems.
A set of permissions that are local to a single data system, computer, or device within an organization.
An account created on a single system (data systems, an app, etc.), computer, or device within an organization. Local accounts cannot be used on other data systems, computers, or devices.
Role-Based Access Control (RBAC) is a method of managing access to resources and applications based on the roles of individual users.
In Role-based Access Control (RBAC), a role is a collection of permissions that define the actions a user is authorized to perform for resources within an organization’s IT environment.
Veza Search features include Graph, Query Builder, and Tagged Entity Search. Veza Access Reviews leverage graph queries and entity metadata for access and entitlement review.
Service accounts are non-human accounts that log into servers, run batch jobs and scripts. Machine identities are similar but connote devices and IOT principals. Meanwhile, bots are similar but focused on automation. All these are sometimes summarized as non-human identities.
A webhook is a way for an application to provide other applications with real-time information. It is a simple HTTP callback that allows a sender to provide information to a receiver when a particular event occurs.
When configuring an integration, use this tab to specify additional attributes on entities to collect, by providing the name and type of attribute Veza will gather. For example, if an organization uses custom security attributes for Azure AD or Okta (such as deskNumber), these custom properties can be enabled when adding the integration, and used to filter results for search and access reviews.
Data Sources are the individual resources (SaaS apps, data lakes, databases, etc.) from which Veza extracts authorization metadata.
A connector built directly into Veza, for ingesting data from external systems. Each inbound integration represents an inbound connection to a cloud provider, identity provider, or external application. Some integrations support activity monitoring, audit logs, and lifecycle Management (when granted additional permissions). Each integration may have multiple child discoverers and data sources representing services and resources. Veza Actions are outbound integrations for triggering actions in external systems.
Option to globally prevent discovery of all resources for a provider service (for example, AWS EC2).
Option when configuring an Identity Provider integration, allowing users to define cross-service connections between Identity Provider accounts and local accounts in other integrated systems (if Veza cannot automatically detect the connection).
Veza Activity Monitoring features provide insight into resource and privilege utilization for your users. These include Overprovisioned Access Scores and special reports leveraging cloud provider audit logs.
An Open Authorization API integration built by Veza, a customer, or the open-source community that is available in our community GitHub repository.
An Open Authorization API integration built by a customer for one of their proprietary systems that is not published to the public repository.
An Open Source framework for adding off-the-shelf or in-house-developed proprietary applications and identity providers to the Veza graph.
An integration built directly into Veza for sending data to external systems and enabling downstream processes around Veza alerts and access reviewer actions. You can configure generic webhooks, create Jira issues, or ServiceNow tickets with Veza Actions, or enable Slack and email notifications.
Option when configuring an integration, setting limits on the individual resources Veza will attempt to extract and parse (for example, AWS S3 Bucket).
A Veza-provided VM image or docker container to enable connections to systems without APIs, or without publicly reachable APIs.
Workers are the components that find and catalog the authorization metadata and Data Source components of the integration.
A customizable period used to calculate Over Provisioned Scores for users and roles, based on entitlement usage within a set period of time. To change the range, go to the System Settings page and pick 1, 7, 30, 60, 90, or 120 days as the value. The default value (Auto) is 30 days.
Alerts activate when a built-in or custom rule condition is met. Each alert includes a summary of changed entities since the last rule evaluation. Alerts are published via notifications, which include a summary of the original query. Notification delivery methods include email and outbound integrations or webhooks.
The primary Veza landing page features customizable dashboards and report summaries. The dashboard provides a high-level overview of access risks and out-of-the-box insights, with options to quickly act on any tile. You can add or remove reports to Dashboards by adding them to the Dashboard Reports report category.
An entity to ignore as a Risky Entity, due to matching a condition or being individually marked as an exception. Constraints on the query can mark entities as "Exceptions" based on a filter rule (for example, all resources in a test environment, or system roles that are not reasonably actionable).
Veza Insights provide tools to understand and act on risky entities and relationships using the Authorization Graph. Veza Insights include customizable Reporting, the Access Risks Dashboard, Rules, and Alerts.
OPAS represents the percentage of resources an identity is granted permission to access, but has not utilized recently. For example, if a user reads on 3 tables, but is entitled to read from 10, they are over-provisioned by 70%. The OPAS can change depending on the resources and permissions selected by the original query.
A system-provided attribute listing all integrations involved in a query. You can filter by integration when searching for queries to add to Reports, or on the Saved Queries page.
A customer or system-provided attribute, intended for risk categorization and query organization.
A collection of queries, organized into sections for actionable insights on Authorization Graph data. Reports can be built-in or user-created, and private or public.
Report categories are used to group reports on the Reporting > Reports page. Access Risk tiles are based on reports in the Dashboard report category.
Sections in reports contain groups of saved queries, based on the provider, type or risk, or other customizable criteria.
Any entity that appears in the results of a saved query with a risk level is considered a Risk. Marking a query as a Risk can define security baseline, misconfiguration, common access risk, or other anomalies, enabling alerts and recommendations. You can mark a Risk as an Exception to prevent it from appearing as a risk.
Level of risks if the query result contains non-zero results. Risk level can be 'critical' or 'warning'.
A rule consists of a baseline query, thresholds of conditions, and notification settings, delivered when conditions are met. The default action is to send an Alert to the Alerts page.
A Page with a complete list of system events as well as events related to Integrations and Rules
Predefined filter that narrows down search results to specific parent Azure tenants or AWS accounts. Particularly useful in multi-environment setups.
A time-bound snapshot of entities, relationships, and their attributes collected by Veza integrations. Used for investigating, intelligence automation, and rule creation across connected applications, identity providers, and cloud services.
Advanced Graph visualization options for labeling entities by provider account or tenant, and highlighting relationships of interest such as assume role paths, disabled users, or risky entities. Display options will vary based on the entity types in your search.
Option to only return results of the source type with NO relationship to entities of the destination type
Entities represent the authorization, data, and identity objects discovered by Veza, as shown in search results or on the Entities page. Entities can be data services or resources, identity domains, users or groups, and IAM or RBAC elements such as policies and roles. Entities have properties to contain attribute metadata such as manager, is_active, or encryption_enabled. Queries typically will specify both source and destination entity types, such as Okta User to AWS S3 Bucket or Google User to Google Group. Higher-level entity type groupings such as All Users and All Resources can be used to search for several entity types at once.
Entity Attributes are the rich metadata associated with an entity, to enable granular filters based on a range of possible properties. These attributes may be added by Veza during parsing (such as name, is human, or full admin), or ingested directly from the provider (mfa_enabled, is_encrypted, and so on)
Search option to only return results where source and destination are NOT connected by a particular entity type (for example, to show access granted without an assigned group). This can be used to show only access granted in a way that bypasses a user's intended groups, and filter results that aren't related to particular groups, roles, or policies.
Advanced Action in Effective graph search mode to show raw permissions and IAM relationships resulting in an effective permission calculation (represented by an EP node).
Filters which constrain query results based on the source, destination, or intermediate entity''s attributes (such as Name, ID, or Is Active).
Option to filter query results by raw or effective permissions, such as s3:DeleteBucket or Data Delete.
Condition to filter results based on a Veza Tag or native provider tag applied to the source, destination, or intermediate entity. Filters can always apply to source and destination entities. The query must define Required intermediate entities to filter by tags on intermediate entity types.
Graph search shows the relationships between entities and resulting effective permissions, based on the latest Authorization Graph or Time Machine snapshot. Actions and filters provide utilities for traversing the graph and understanding and remediating risky access.
A search against the Veza graph. Queries can be built-in or created using the Query Builder. Saved Queries are shown in Veza Reports and on the Saved Queries page. Queries can -have labels and be assigned a risk level. Integrations associated with entities in the query are saved as query attributes, for easier retrieval and organization.
Search option to either show Effective Permissions from source to destination entities OR additional intermediate entity types such as IAM/RBAC roles and policy bindings.
Effective mode calculates and shows all possible actions, after accounting for any potential restrictions (such as policy deny statements and other controls). Effective Permissions represent all the metadata and non-data actions the principal can take on a resource.
System mode shows the configured permissions and access path, before processing potentially overriding policies such as deny statements, SCPs, and network policies. Configuration mode is useful for understanding, certifying, and enforcing rules based on User > Role relationships and role-based permissions for CSPs like Google and Azure.
Depending on the query mode, reviewers will sign off on the combined Permissions for each result, or the Path Summary and Concrete Permissions for each result.
Query Builder option to filter results based on the number of related destination entities. The count operator can be <, =, >, etc.
The final entity type for a query. By default, each result will include the effective permissions between the source and destination entities.
Advanced Graph visualization options to show or hide graph columns (layers/entity types) and relationships. Depending on the search, the Advanced View toggle shows additional intermediate entities such as local user accounts between principal identities and data resources.
Parameter to only return results where an entity of the selected type (such as a local group) connects the source and destination nodes. Requiring an intermediate entity enables filters on the intermediate entity's attributes
Graph search option indicating that pages of results are shown instead of all results. Pagination will be enabled by default for graph searches that return more results than Veza can render at once.
Parameter to include or exclude indirect and nested relationships (such as roles that are assumed by other roles, or groups that are members of other groups) from search and in the reviewer interface. The option to Show assumed [entity type] appears under Advanced Options > Relationship Options when the query source or destination is nestable (such as Snowflake Group or AWS IAM Role).
The initial node for a query. Entities of the Source type are included in a review scope for review and attestation if a relationship exists between that entity and another entity of the Destination type. If no destination is specified, the query will return all entities of the source entity type.
Option to select a single entity of the selected source or destination entity type, and only return relationships for that unique identity, IAM/RBAC entity, or resource.
An individual privilege defined in the provider-native terms, such as s3:BucketDelete in AWS Identity and Access Management (IAM). System permissions are the basic building blocks of access control, and are typically assigned directly to principals (users, groups, or roles) on resources (files, folders, or objects).
The Tagged Entities page provides a way to view and search all entities that have matching Tags.
Tags are used to add extra metadata to entities, using key:value pairs. Two types of tags are supported by the Veza platform:
Veza Tags that users add to Authorization Graph entities
Provider-specific tags that Veza discovers, such as AWS tags, Snowflake tags, and Google Cloud labels. Tagged Entity Search offers a way to quickly find entities with a matching tag. You can also add tag filters to constrain search results based on whether entities have (or do not have) a certain set of tags.
Option indicating the Authorization Graph snapshot to execute the query against.
Access Reviews can use a time machine snapshot or use the most recent one when a review is created.
Use the Authorization Graph Time Machine to search against a snapshot of relationships and entities at a specific point in time.
A query including a source entity type, destination entity type, and other search parameters defining the access under review. Individual reviews will show the query results as rows for review and sign-off, based on a historical snapshot or the current graph data.
Queries can be very broad (All Users to All Resources) or very specific, including filters on tags, property-based constraints, and intermediate node requirements.
Each query has a source and optionally a destination node. Entities of the Source type are included in the results for review and attestation if a relationship exists between that entity and another entity of the Destination type.
Results shown in the reviewer interface include source and destination entity details, the effective permissions for that relationship, and optionally, a summary of the path that made the connection.
Features for user access and entitlement review. Access Reviews provide a framework for repeatable, multi-user review processes with a full audit trail, using the power of Veza graph search.
Status indicating that all review rows were signed off by the due date.
Individuals explicitly specified as Reviewers (for all results) when creating a review.
An alternate user assigned to carry out the responsibilities of an original user who would be auto-assigned as a reviewer but is unavailable.
Status indicating that not all rows were signed off in a review. by the due date.
Fallback Reviewers are specified when creating a review and assigned when rules prevent the assignment of the original user, or when a manager does not exist for a row.
In the context of an access review scope, graph, or query builder search, filters apply constraints based on attributes, tags, or permissions. When reviewing access, filters limit the number of results shown at one time and can be used to act on many results with the same attribute at once.
Filters can apply to the source or destination entity, or an intermediate entity property (such as Last Login).
In the reviewer interface, filters can apply to result properties such as decision state (Signed Off).
Bulk actions can be used to act on all review rows matching a filter.
System-wide setting to enable reviewer recommendation and manager auto-assignment using an integrated Identity Provider. This enables any user in your organization to log in with Single Sign-On and review their assigned rows.
In the context of an access review, a manager is another user from your identity provider, specified as in the manager attribute of the source entity. When this metadata is available, managers can be suggested or auto-assigned to each row.
Managers or owners of resources, assigned as reviewers for an access review. Veza can identify potential reviewers using metadata from an identity provider, or with Veza Tags. Resource owners can be assigned as reviewers using auto-assignment.
Operator action to indicate that the recommendation has been carried out for a row. Rejected and Signed-off items can be Marked as Fixed to log that remediation took place.
Emails sent to update users involved in an access review, including notifications when rows are reassigned, and reminders about inactivity and deadlines.
Status for reviews that are not expired, and still have items pending sign-off.
Support-enabled option to highlight special rows such as disabled users, based on filter criteria.
Reviewer or operator action assigning one or more rows to another reviewer, after a review has begun.
Type of email notification sent to remind reviewers and stakeholders that action is needed due to inactivity or approaching deadlines. Final reminders can also be configured to escalate remaining tasks.
A review is a scheduled instance of access or entitlement review, with unique deadlines and reviewers.
Each review has an underlying configuration, which defines:
A query defining the entities and relationships under review.
Default notification and integration settings, inherited by reviews for the configuration.
Attributes such as a name and description, for identification and internal reference.
Reviewer assignments, defining the initial reviewers and fallback reviewers.
Reviewers can open a review instance to see the results of the query, and sign off on each row.
Reviewers can accept, reject, or delegate items.
Rejected items can be marked as "fixed" by operators after remediation
Reviews are based on immutable graph snapshots and an underlying query.
When reviewing their assigned rows, reviewers will:
Accept: Reviewer decision to approve the access specified in the row (as legitimate access).
Reject: Reviewer decision to refute the current access as illegitimate. Reject actions can trigger remediation processes using webhooks integrations.
Sign Off: Action to finalize the decision for a row, making it immutable. Signed-off items can be marked as fixed by operators.
Reviewers can also re-assign rows to another user, add a note, or view more details.
A row in an access review describes a source entity, and typically its permissions on a destination entity. Depending on the review scope, rows can describe a single entity, a relationship between two entities, or include a summary of intermediate entities such as groups, roles, or projects.
Option to assign managers and resource owners as reviewers using metadata Veza has discovered, with fallback reviewers if a match can't be found or a rule prevents review. Auto-assignment enables review owners to assign many reviewers at once, either to specific reviewers, or to resource or team managers using metadata from an identity provider, or Veza Tags. The identity provider must be integrated with Veza and Global IdP Settings must be enabled.
Global list of users who are blocked from being assigned as reviewers.
Review scope option, enabling visibility into a single connecting entity and its properties, existing between the source and destination nodes. The reviewer interface will include optional columns for each intermediate attribute, such as the name and type of the connecting group or role.
Review scope option, enabling visibility into the RBAC configuration granting access to the destination entity. When configured, reviews will include a default Summary Entities column, showing the names and sequence of selected entities when they connect the source and destination. For example, when a group is selected as a summary entity, the column will contain either:
Group 1 (indicating access is granted directly by that group)
Group 1 > Group 2 (indicating that the first group allows access to the second)'
Status for pending reviews with no signed-off items.
Role that enables users to review and certify items within their assigned access reviews. Allows access solely to the Access Reviews panel and assigned reviews.
Highest-level user role with full control over settings, integrations, and privileges. Inherits all capabilities of Operator and Access Reviewer roles.
Integration configurations are saved settings for connecting to an external platform, including the credentials and optional settings for the connection. Integrations are added and managed on the Integrations page.
Role allowing users to create configurations and initiate reviews, as well as review all items in reviews they create. Operators can access all Veza features such as Search and public Reports, but cannot manage other users or integrations.
Sign-in Settings is a Veza Administration panel for managing Multi-factor authentication (MFA), Single Sign-On (SSO), and configuring local account (non-SSO) access for your Veza tenant
The page where users can be added, removed, or edited and have roles assigned.
Webhooks are automated messages containing a payload of instructions that are sent to a specific URL when the conditions associated with the webhook are met.