Last updated
Was this helpful?
Note: SoD queries should be based on your actual environment, configuration, and roles. These are examples and not necessarily indicative of actual access.
Veza provides a way to write SoD queries that encompass multiple platforms, e.g., rules involving both NetSuite and Coupa roles. Queries for SoD controls can be:
Single Application: Queries within a single application. For example, a user with the “approver” role cannot also be a “submitter” on Zendesk.
Multi-dimensional: Queries spanning applications. For example, an “approver” in Coupa cannot also be a “submitter” in Zendesk.
See the following examples for queries involving different types of applications:
In this conflict involving Oracle Fusion roles, an individual can enter a fictitious payment and reconcile the cash account, resulting in cash position manipulation:
Source Entity Type: Oracle Fusion Cloud User
Related to Oracle Fusion Cloud Role: "Accounts Payable Payment Supervisor" OR "Accounts Payable Manager"
(AND) Has relation to Oracle Fusion Cloud Role: "Cash Manager"
In this conflict, a user could modify compensation data and reconcile payroll records, potentially concealing unauthorized changes:
Source Entity Type: Workday Account
Related to Workday Domain Security Policy “Access Compensation Basis” OR “Add Compensation Plans”
(AND) Has relation to Workday Domain Security Policy "Manage: Global Payroll Reconciliation"
This query detects identities with access to Salesforce who can also delete critical S3 storage infrastructure:
Source Entity Type: Okta User
Related to (Any) S3 Bucket with s3:DeleteBucket permission
(AND) Has relation to (Any) Salesforce User
Here is a simple SoD conflict for GitHub, requiring that Personal Accounts in a GitHub organization can’t be assigned to either the developers or qa team, and also be admins:
Source Entity Type: GitHub User
Related to GitHub Team: "developers" OR "qa"
(AND) Related to GitHub Team: "admins"
Here is a more complex query involving Okta User assignments to applications, and their access to data in Snowflake. In it, users assigned to Salesforce and ServiceNow can’t also have permissions on the ACCESS schema in Snowflake, or any write permission on the AUDITLOG_RESULTS table:
Source Entity Type: Okta User
First Condition (either):
Has relation to Okta App: Salesforce.com OR
Has relation to Okta App: ServiceNow UD
AND Second Condition (either):
Has relation to Snowflake Schema: ACCESS (Any Permissions) OR
Has relation to Snowflake Table: AUDITLOG_RESULTS (Metadata Write)
