Access Management for Snowflake¶
Overview¶
Privacera seamlessly integrates with Snowflake to enforce data access policies and ensure regulatory compliance. This document outlines the key features, benefits, and configuration steps for integrating Snowflake with Privacera.
Access Management Methodology¶
| Topic | Detail |
|---|---|
| Integration methodology | Privacera PolicySync |
| Access Tools | JDBC |
| Supported User Identities | Snowflake Database Users and Roles |
| Resource policy Service type (default) | privacera_snowflake |
Supported Access Management Features¶
| Feature | Supported | Native | Using SecureView |
|---|---|---|---|
 Database Access Control | Yes | Yes | N/A |
| Table Access Control | Yes | Yes | N/A |
| View Access Control | Yes | Yes | N/A |
| Column Access Control | Yes | Yes | N/A |
| Column Data Masking | Yes | Yes | N/A |
| Row Level Filtering | Yes | Yes | N/A |
| Centralized Access Audit | Yes | N/A | N/A |
| Granular Access Audit Record | Yes | N/A | N/A |
How does it work¶
In Snowflake, access permissions are managed using roles. Privacera PolicySync synchronizes access policies from Privacera to Snowflake. Users select the Snowflake role when authenticating with Snowflake and performing the SQL operations. Access policies are enforced in Snowflake based on the selected role and the permissions assigned to it.
The following section describes in detail how the policies are translated to Snowflake roles and permissions.
Limitations¶
Here are some limitations of the Privacera Snowflake integration:
- The connector for Snowflake does not support deny policies.
- Since Snowflake does not support column level access control, any restrictions on columns are enforced by creating dynamic masking on the columns. This may introduce additional overheads on the Snowflake side.
- Prev topic: About Snowflake Connector
- Next topic: Prerequisites