The article explains Data Access Management (DAM) for Snowflake works in OvalEdge. This feature makes it easy for organizations to quickly view, modify, and sync role or user permissions on various data objects (i.e., Databases, Schemas, Tables). This capability makes it easier to manage permissions without writing complex queries or relying on Database Administrators. In addition, this article covers how to create and modify Roles, Users, Policies, like Masking Policies or Row Access Policies, and Tags and sync all these automatically to the source system while capturing an audit log of all actions.
Data Access Management
The Data Access Management submodule controls all Access Management operations at the OvalEdge level.
Crawl
Data Access-enabled crawling is divided into ‘Crawl Users and Roles’ and ‘Crawl Permissions, Policies, and Tags’.
Crawl Users & Roles: Crawling Users & Roles initiates a job to import all roles, users, and associated objects, such as warehouses, from the particular instance into OvalEdge. This job also brings in various account-level privileges associated with the roles crawled.
Crawl Permissions, Policies, and Tags: Crawl Permissions, Policies, and Tags initiates a job to capture all permissions associated with selected data objects, like databases, schemas, and tables, in OvalEdge. This job also crawls for various policies, like masking and row access policies, and their associations with tables and table columns.
Schedule: The crawling of Users and Roles, Crawl Permissions, Policies, and Tags can be scheduled on defined timelines.
Grouping of connectors by instance
The created connectors are grouped in the Data Access module according to their associated server instance, shown in a hierarchical tree view on the left side of the page. The tabs displayed for each instance level vary depending on the connector type.
Instance Details
The ‘Instance Details’ tab acts as an instance-level landing page. It includes a Summary of the Instance, Role Settings, User Settings, and Notifications.
Summary: The ‘Summary’ tab under this section lists all the parameters to establish that connection. Some parameters, such as Server, Port, and Connection String, are non-editable, while others, like Username and Password, are editable. Organizations can configure different admin roles to handle different databases and schemas.
Role Settings: Role Settings allow Data Access Admins to manage role configurations. They can add, edit, delete, and designate roles as immutable.
- Allow Add/Edit of Snowflake Roles: This option enables Data Access Admins to add or edit roles in Snowflake through OvalEdge.
- Allow Delete of Snowflake Roles: This option enables Data Access Admins to delete the roles in Snowflake through OvalEdge.
Note: To enable the ‘Allow Delete of Snowflake Roles,’ the ‘Allow Add/Edit of Snowflake Roles' checkbox should be enabled as a prerequisite. - Immutable Snowflake Roles: To prevent certain Snowflake roles from being changed or deleted through OvalEdge, they can be marked as immutable. These roles will then be disabled in the Roles tab.
User Settings: User Settings allow Data Access Admins to manage user configurations, including adding, editing, deleting, and making users immutable.
- Allow Add/Edit of Snowflake Users: This option enables Data Access Admins to add or edit users in Snowflake through OvalEdge.
- Allow Delete of Snowflake Users: This option enables Data Access Admins to delete the users in Snowflake through OvalEdge.
Note: To enable the ‘Allow Delete of Snowflake Users,’ the ‘Allow Add/Edit of Snowflake Roles' checkbox should be enabled as a prerequisite. - Delta Crawl: The Delta Crawl option checks the timestamp of the last crawled user. If any users have been created or modified in the source system after the timestamp is captured, only those users will be crawled into OvalEdge. This feature, when enabled, improves performance.
- Immutable Users: This option allows Important Snowflake users to be marked as immutable to prevent them from being changed or deleted from OvalEdge.
To prevent Snowflake users from being changed or deleted through OvalEdge, they can be marked as immutable. These users are disabled in the Roles tab.
Notifications: Configured users/teams/roles receive notifications about various actions performed in the source system after crawling or through Data Access Management.
- Changes to Roles/Users during crawling(source system sync): This option allows the configured OvalEdge roles, teams, and users to be notified if certain users and roles have been added or deleted at Snowflake that are found during the crawl.
Note: Whenever Configure notifications for Data Access Admin is enabled, the above notifications will be received by all the Data Access Admins defined under the instance-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Changes to Roles/Users from Data Access Management: This option allows users to receive notifications whenever a role/user is added, edited, or deleted in the Data Access Management module in OvalEdge.
Note: Whenever Configure notifications for Data Access Admin is enabled, the above notifications will be received by all the Data Access Admins defined under the instance-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Configure notifications for Data Access Admin: This option sends notifications to this instance's Data Access Admins.
Connectors
The ‘Connectors’ tab displays the list of all the connectors in this server instance, with additional information.
Once the Connector is created on the connector page and the Data Access License is enabled, those will be displayed under the Connectors tab.
- Connector ID: ID of the specific connector.
- Connector Name: Name of the specific connector.
- Database: The database used to create the connection string for the specific connector.
- Last Crawled Date: The last crawled date of the specific connector.
Roles
The Roles tab displays all roles from the Snowflake instance when crawling is completed.
Below are the listed columns:
- Snowflake Role: Names the specific role in the source system, which is editable inline.
- Role Type: Identifies whether the role is system-defined or custom. System-type roles cannot be modified or deleted.
- Description: Displays a role description that can be edited inline.
- Account Privileges: Displays the account-level privileges associated with the role, which can be edited inline.
- Source: Displays whether the role is created in Snowflake or OvalEdge.
- Warehouse: Displays the default warehouse to which the role is associated.
- Source Created Date: Displays the timestamp for when this particular role was created in the source system.
- OvalEdge Created Date: Displays the timestamp of when this particular role was created in OvalEdge.
- OvalEdge Role: During Role crawling, if any roles have permissions on any data objects crawled into OvalEdge, and the specific role has the same name in OvalEdge, these two roles are mapped and shown.
- Parent Role: Parent roles defined on the role are shown. If a role is defined as a Parent role, a parent-child relationship is formed, and the corresponding role defined as a parent is granted to the current role to be utilized. This can be edited inline.
Create/Add a New Role
OvalEdge enables Data Access Admins to create new roles through OvalEdge, which can then be synced to Snowflake.
To create a new role, click on the plus icon at the top right and fill in corresponding fields like Role Name, Description of role, the Default Warehouse that has to be associated with the role, any Account-level privileges the role should be granted, and any relevant parent role defined for the specific role.
Note: As a prerequisite, select the ‘Allow Add/Edit of Snowflake Roles’ checkbox at Instance Details > Role Settings.
Users
After crawling is performed, all users from the Snowflake instance are displayed under the Users tab.
Below are the listed columns:
- Source System’s Username: Displays the source system username. It can be edited inline.
- Display name: Displays the name given to the user in the source system. It can be modified inline.
- Login name: Displays the ‘Login name’ given to the user in the source system. It can be edited inline.
- First name: Displays the ‘First name’ given to the user in the source system. It can be edited inline.
- Last name: Displays the ‘Last name’ given to the user in the source system. It can be edited inline.
- Email: Displays the email address associated with the corresponding user. It can be edited inline.
- Roles: Displays the roles that are associated with the corresponding user. It can be edited inline.
- Description: Displays the user's description. It can be edited inline.
- Warehouse: Displays the default warehouse that is associated with the user.
- Source: Displays where the particular user was created, whether in the source system or OvalEdge.
- Source Created Date: Displays the timestamp of when this particular user was created in the source system.
- OvalEdge Created Date: Displays the timestamp of when this particular user was created in OvalEdge.
- OvalEdge User: During user crawling, if any role has been assigned to a particular user that has permission to access any data objects crawled into OvalEdge, and if that specific user has the same name in OvalEdge, these two users are mapped and shown.
Create/Add a New User
OvalEdge enables a Data Access Admin to create new users in OvalEdge, who can then be synced to Snowflake.
To create a new user, click on the plus icon at the top right and fill in the corresponding fields like Username, Password, and Confirm password, as well as the optional fields email, login name, display name, first name, last name, default role, default warehouse for the user, and a brief description of the user.
Note: As a prerequisite, select the ‘Allow Add/Edit of Snowflake Users’ checkbox at Instance Details > User Settings.
Warehouse
The Warehouse tab displays the list of warehouses hosted under the Snowflake server instance. Warehouses are clusters of computing resources that provide necessary resources, such as CPU, memory, and temporary storage, to perform select statement queries and other DML operations.
Connector Level
The following tabs are displayed for each connector level. Navigate to a connector under each server instance in the left-side hierarchical Data Access Management grouping.
Connector Details
The ‘Connector Details’ tab acts as the connector-level landing page.
Below are its listed sub-tabs:
Summary
Data Access Admins (DAA) can manage various settings for a connector on the Connector Summary page. This connector's Data Access Administrator roles can also be defined here.
Enable Access Management: This option allows organizations to decide if they wish to perform any DAM operations on various data object permissions (modifying databases, schemas, and table permissions), policies (creating and assigning policies), and creating and assigning tags through OvalEdge and sync to the source system.
- Manage Database Permissions: This option enables the corresponding Data Access Admin to Add, Edit, or Delete the permissions for roles on databases.
- Manage Schema Permissions: This option enables the corresponding Data Access Admin to Add, Edit, or Delete the permissions for roles on schemas.
- Manage Table Permissions: This option enables the corresponding Data Access Admin to Add, Edit, or Delete permissions for roles on tables.
- Sync OvalEdge Permissions with Snowflake Permissions: This option ensures that the permissions configured in OvalEdge's Security module for different crawled data objects are synchronized with the corresponding data objects in the source system.
- Manage and assign Masking Policies: This option enables the Data Access Admin to Add, Edit, or Delete masking policies and associate/dissociate them on Table columns and Tags.
- Sync Source System’s Masking Policies to OvalEdge: Enabling this option will sync masking policies created and present in the source system assigned on table columns to OvalEdge.
- Sync OvalEdge’s Masking Policies to Source System: Enabling this option will sync masking policies created and present in OvalEdge assigned on table columns to the source system.
- Manage and assign Row Access Policies: This option enables the corresponding Data Access Admin to Add, Edit, or Delete row access policies and associate/dissociate those masking policies on Tables.
- Crawl and Manage Tags: OvalEdge will crawl tags created in the source system, and a Data Access Admin can modify them by adding, editing, or Deleting them through OvalEdge.
This option enables the crawl of tags created in the source system, and a Data Access Admin can modify them by adding, editing, or Deleting them through OvalEdge. - Enable Access Cart: This option enables access requests for specific schemas and tables.
Permissions
The Permissions tab under Connector Details displays the list of the source system’s permissions on data objects and how they are mapped to OvalEdge’s metadata and data permissions.
Databases: Displays the list of database permissions on the source system that have been defined and how those are mapped to OvalEdge regarding OvalEdge’s metadata and data permissions.
Schemas: Displays the list of schema permissions on the source system that have been defined and how those are mapped to OvalEdge regarding OvalEdge’s metadata and data permissions. The checkboxes allow users to choose whether those permissions can be raised through the Access Cart.
Tables: Displays the list of table permissions on the source system that have been defined and how those are mapped to OvalEdge regarding OvalEdge’s metadata and data permissions. The checkboxes allow users to choose whether those permissions can be raised through the Access Cart.
Notifications
Configured users/teams/roles receive notifications about various actions performed in the source system after crawling or through Data Access Management.
- Changes to Permissions of Databases, Schemas, Tables, Columns, policy associations during crawling(source system sync): This option allows the configured OvalEdge roles, teams, and users to get a notification whenever there's a change in permissions of databases, schemas, tables, columns, policy associations, and tag associations in Snowflake. This will be notified after the crawling has been performed in Data Access Management.
Note: Whenever Configure notifications for Data Access Admin is enabled, only then the above notifications will be received by all the Data Access Admins defined under the connector-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Changes to Row Access Policies, Masking Policies(source system sync): This option allows the configured OvalEdge roles, teams, and users to get a notification if there are any changes to row access policies or masking policies in Snowflake. This will be notified after the crawling is performed in Data Access Management.
Note: Whenever Configure notifications for Data Access Admin is enabled, only then the above notifications will be received by all the Data Access Admins defined under the connector-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Changes to Permissions of Databases, Schemas, Tables, Columns, policy associations from Data access management: This option allows users/roles/teams to receive notifications if there are any changes in the permissions of databases, schemas, tables, columns, policy associations, and tag associations in the Data Access Management in OvalEdge.
Note: Whenever Configure notifications for Data Access Admin is enabled, the above notifications will be received by all the Data Access Admins defined under the instance-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Changes to Row Access Policies Masking Policies from Data Access Management: This option allows the configured OvalEdge roles, teams, and users to receive notifications if there are any changes to row access policies or masking policies in the Data Access Management in OvalEdge.
Note: Whenever Configure notifications for Data Access Admin is enabled, the above notifications will be received by all the Data Access Admins defined under the connector-level Data Access Admins section, along with the users, teams, and roles defined in the Notifications section. - Configure notifications for Data Access Admins: This option sends notifications to this instance's Data Access Admins.
- OvalEdge Users: Assigned users will receive notifications about the actions enabled in the Notifications settings.
- OvalEdge Teams: Assigned teams will receive notifications about the actions enabled in the Notifications settings.
- OvalEdge Roles: Assigned roles for the users will receive notifications about the actions enabled in the Notifications settings.
Databases
The Databases tab displays the list of databases crawled into OvalEdge, with permissions attached to roles. The corresponding Data Access Admin can modify these permissions inline by adding, updating, or deleting them. This page shows permissions grouped by roles.
Schemas
The Schemas tab displays the schemas crawled into OvalEdge, with permissions attached to roles on them. These permissions can be modified inline: Added, Updated, or Deleted only by the corresponding Data Access Admin. This page shows permissions grouped by roles.
Tables
The Tables tab displays the tables crawled into OvalEdge, with permissions attached to roles. These permissions can be modified inline: Added, Updated, or Deleted only by the corresponding Data Access Admin. This page shows permissions grouped by roles.
The ‘Type’ column indicates whether the corresponding table is a View, Materialized View, or Table.
It also displays additional information, such as whether the table has any tags attached and whether a row access policy has been assigned.
Bulk Permissions Modifications
Click on the nine dots option at the top right-hand side. OvalEdge supports bulk permission modifications for databases, schemas, and tables through four actions (Add Role Permissions, Replace Permissions, Remove Roles, and Remove Roles Permissions).
Add Role Permissions: The Add Role Permissions option allows you to add a few permissions at once to specific databases/schemas/tables. If a role already has some permission, the new permission will be appended or added to the existing role, and if the role has no permission, then the new role will be assigned to the database/schema/table with the corresponding permission given.
Replace Roles’s Permissions: Replace Role’s Permissions option allows the removal of all the existing permissions on selected databases/schemas/tables at once, and new ones defined will be assigned.
Remove Roles: The Remove Roles option allows certain roles with all their permissions on databases/schemas/tables to be removed using the nine-dots option. Once the Remove action is complete, the roles will not have any permissions on the selected databases/schemas/tables.
Remove Roles Permissions: The Remove Roles Permission option uses the nine-dots option to remove specific permissions from multiple databases/schemas/tables at once. Once the Remove Role’s Permission action is complete, permissions present from multiple roles are removed at once.
Table Columns
Table Columns display a list of columns that are part of the tables crawled into OvalEdge.
The ‘Schema’ and ‘Table’ columns indicate the schema and the table to which the corresponding column belongs.
The masking policy and tags columns indicate any masking policies or tags associated with a table column.
A Data Access Admin can associate/dissociate any tag or masking policy with the table column, compared to what is present in OvalEdge at that time.
Tags
Snowflake tags are schema-level objects that monitor sensitive data for compliance and discovery purposes.
This tab shows the list of tags crawled from the source system and created through OvalEdge. Only the corresponding Data Access Admin can create, modify, or delete tags.
When a masking policy is associated with a Snowflake tag, it can be used for data privacy. Once a tag is associated with a table or table column, the data is masked depending on the tag's allowed value and the column type of the masking policy. Since the data is masked through tags, manually assigning a masking policy to table columns is unnecessary.
In addition to the tag name, additional information shown in this tab includes the ‘Schema’ in which the tag is created, the tag’s values that are defined, a comment made to describe the tag, the source at which the particular tag was created (source system or OvalEdge) if any masking policy is associated to the tag, the timestamp at which the corresponding tag was created, the owner of the tag, the role that has created/updated the tag in the source system. The ‘Updated By’ column shows the user who created/updated the tag through OvalEdge.
Add Tag
Add a tag by selecting the Plus icon in the top right corner of the page. Then, enter the relevant details and save. A tag gets created and displayed in the Tags tab.
Masking Policies
Masking policies are schema-level objects that protect sensitive data from being accessible to unauthorized individuals. Applying a masking policy overrides the column data with characters, numbers, null values, or specific patterns to hide the original data. This Masking Policies tab lists Snowflake's crawled masking policies and those created through OvalEdge. Only the corresponding Data Access Admin can create masking policies. In a nutshell, masking policies can provide column-level security.
The Masking Policies tab shows the following columns:
Policy: Whether this masking policy relates to a business or technical masking policy.
Policy SQL: The SQL defines how the policy should function.
Masking Policy Scheme: The pattern in which the data should be masked.
There are multiple masking schemes that OvalEdge supports, like
- Mask alphanumeric characters with xxxx (abc@123 → xxx@xxx)
- Mask all characters with xxxxxx (abc@123 → xxxxxx)
- Show last 4 characters (abc@123 → xxx@123)
- Show first 4 characters (abc@123 → abc@xxx)
- Show blank (abc@123 → ‘ ‘)
Datatype: The corresponding datatype of the column on which the particular masking policy is designed to mask the data, like Varchar, Timestamp, Integer, etc.
Schema: The corresponding schema in which the masking policy is created.
Authorized Roles & Authorized Users: The authorized roles and users can view the data in the actual form.
Comment: Any comment made on the masking policy to describe it.
Owner: The role that created/updated the masking policy in the source system is the owner of the masking policy.
Policy Type: Indicates whether the policy is technical or business.
Source: The source at which the particular masking policy was created (source system or OvalEdge).
Created Date: The timestamp at which the corresponding masking policy was created.
Updated by: The user who created/updated the masking policy through OvalEdge.
Add Masking Policy
It is possible to create two types of masking policies in OvalEdge: a business masking policy and a technical masking policy. Masking policies can be created by clicking the plus icon in the top right.
Business Masking Policy: The Business Masking policy comprises OvalEdge-specific masking schemes that define how the data should be masked.
Technical Masking Policy: The "Technical Masking policy" enables the creation of a custom masking policy using SQL code. This code specifies how data should be masked.
Row Access Policies
A Row Access Policy provides row-level additional security. It defines whether a particular row of a table or view should be accessible by a specific individual.
For example, an organization stores employee details in an employee information table. Now, the organization can design the Row Access Policy so that when an employee accesses that table, only the specific row or rows should be accessible. This can be accomplished by using a parameter such as Employee ID.
The Row Access Policies tab lists all the row access policies crawled, created, and present in a schema. Only the corresponding Data Access Admin can create a Row Access Policy through OvalEdge.
Add Row Access Policy
Add a row access policy by selecting the Plus icon at the top right corner of the page. Then, enter the relevant details and Save. The policy is created and displayed in the Row Access Policies tab.
Assign a Row Access Policy
Row Access Policies can be assigned/removed inline on a Snowflake Table or View.
Sync
Every action made through OvalEdge gets synced back to the source system, and different icons indicate the sync behavior.
Sync taking place: During sync, a sync icon is displayed, and the corresponding field on which the modification is done will be frozen until the sync is completed.
Sync Failure: If sync fails for specific reasons, a corresponding icon will indicate the same.
Post sync: After the sync is completed, the corresponding field will again be made available in its normal state if any modification needs to be made.
Data Access Audit
Data Access Audit displays the audit trail of any actions taken from the Data Access module, whether adding, updating, or deleting. OvalEdge captures fields like the timestamp of an action, the specific user who has taken the action, and a brief description of the action. The tabs change dynamically based on the selected server instance of the source system.
Below is a list of fields to display:
- Instance: Here, the logs are captured when the creation, updation, or deletion of instances and corresponding connectors occurs within Data Access Management. It also records the username of the person who performed the action and the action's timestamp.
- Roles: Here, the logs are captured when roles are created, updated, or deleted within Data Access Management. Additionally, entries are logged after the crawl if new roles are added/deleted/updated in the source system. The log also records the username of the person who acted and the action's timestamp.
- Users: Here, the logs are captured when users are created, updated, or deleted within Data Access Management. Additionally, entries are logged after the crawl if new users are added/deleted/updated in the source system. The log also records the username of the person who acted and the action's timestamp.
- Database Permissions: Here, the logs are captured when the addition, updation, or deletion of database permissions is assigned to a role on a particular database in Data Access Management. Additionally, entries are logged after the crawl if new database permissions are added/deleted/updated in the source system. It also records the username of the person who performed the action and the action's timestamp.
- Schema Permissions: Here, the logs are captured when the addition, updation, or deletion of schema permissions is assigned to a role on a particular schema in Data Access Management. Additionally, entries are logged after the crawl if new schema permissions are added/deleted/updated in the source system. It also records the username who performed the action and its timestamp.
- Table Permissions: Here, the logs are captured when the addition, updation, or deletion of table permissions is assigned to a role on a particular table in Data Access Management. Additionally, entries are logged after the crawl if new table permissions are added/deleted/updated in the source system. It also records the username who performed the action and its timestamp.
- Tags: Here, the logs are captured when tags are added, updated, or deleted through Data Access Management. Additionally, entries are logged after the crawl if new tags are added/deleted/updated in the source system. It also records the username who performed the action and its timestamp.
- Masking Policies: Here, the logs are captured when masking policies are added, updated, or deleted through Data Access Management. Additionally, entries are logged after the crawl if new masking policies are added/deleted/updated in the source system. The log also records the username who performed the action and the action's timestamp.
- Row Access Policies: Here, the logs are captured when row access policies are added, updated, or deleted through Data Access Management. Additionally, entries are logged after the crawl if new row access policies are added/deleted/updated in the source system. The log also records the username who performed the action and the action's timestamp.
- Tag Associations: Here, the logs are captured when tags are associated or disassociated from tables or table columns through Data Access Management. Additionally, entries are logged after the crawl if any tag is associated or disassociated from a table or table column in the source system. The action also records the username who performed it and its timestamp.
- Masking Policy Associations: Here, the logs are captured when masking policies are associated or disassociated from table columns or tags through Data Access Management. Additionally, entries are logged after the crawl if any masking policy is associated or disassociated from a table column or a tag in the source system. It also records the username who performed the action and its timestamp.
- Row Access Policy Associations: Here, the logs are captured when row policies are associated or disassociated from tables through Data Access Management. Additionally, entries are logged after the crawl if any row access policy is associated or disassociated from a table in the source system. It also records the username who performed the action and its timestamp.