About Secure Views¶

For most databases like Snowflake and Redshift DB, native enforcement of row-level security (RLS) and column-level masking is supported. However, some databases like PostgreSQL and Databricks SQL do not support native enforcement of RLS and column-level masking. In such cases, Privacera has an option to use Secure Views to enforce these security measures. With this option enabled, Privacera creates Secure Views on top of the original tables and applies RLS and column-level masking policies to these views. When a user queries the Secure View, these policies are dynamically enforced.

In the below example, User 1 and User 2 are accessing data through Secure Views corresponding to the original tables. However, when User 1 is trying to access the original table directly, the access is denied.

flowchart TB
    %% Subgraphs for layout clarity
    subgraph Top["Users"]
        User1[User 1]
        User2[User 2]
    end

    subgraph Middle["Secure Views"]
        View1[db1_secure.table1]
        View2[db2_secure.table2]
    end

    subgraph Bottom["Tables"]
        Table1[db1.table1]
        Table2[db2.table2]
    end

    %% Normal allowed paths
    User1 --> View1
    User1 --> View2
    User2 --> View1
    User2 --> View2
    View2 --> Table2
    View1 --> Table1

    %% Simulated "denied" path: label with "X" and style it red
    User1 -->|X| Table2

Here is an example of accessing a table through a Secure View:

1
2

    -- Secure View
    SELECT * FROM account_secure.customer;

Key Advantages¶

• Dynamic Enforcement: Secure Views allow for the enforcement of RLS and column-level masking dynamically without modifying the underlying database schema.
• Layered Security: Secure Views are created on top of existing tables, and RLS and column-level masking policies are applied to the views. When a user queries the Secure View, these policies are dynamically enforced.

Limitations¶

1. Only SELECT Queries Supported: Secure Views support only SELECT queries.
2. Query Updates Required: Users need to update their existing queries to use the new namespace (e.g., database or schema name) or table name.

In addition to these limitations, there are some considerations to keep in mind when using Secure Views:

1. Secure Views are created for every table that are managed by Privacera. This can lead to a large number of Secure Views being created in the database.
2. When Secure View setting is enabled, users won't have access to the original tables. They will have to access the data through the Secure Views created by Privacera. Refer to the Data Admin section for more providing access to the original tables.
3. Secure Views might not be created immediately after the table is created. Privacera's connector fetches metadata from the database on regular intervals to create Secure Views. This can lead to a delay in the creation of Secure Views. If event driven setup is enabled, then the time taken to create Secure Views will be dependent on the time the even is received by Privacera and the time taken to process the event.
4. If there are synchronization going on when the change events are received, then the Secure Views will be created after the synchronization is completed. This can lead to a delay in the creation of Secure Views and the time taken might vary depending on the number of changes the connector is processing during the synchronization

Implementation¶

• Creation of Secure Views: For each table that requires RLS and column-level masking, Privacera creates a Secure View. Users are mandated to access data through these Secure Views, and Privacera grants access accordingly.
• Naming Convention: The naming convention for Secure Views is configurable. By default, Privacera creates a new database or schema with the same name as the original, appended with a _secure suffix, and creates Secure Views within this schema. The Secure Views have the same names as the original tables for easy identification.

Managing Secure Views and Permissions¶

Privacera's connector periodically fetches metadata from the database to create Secure Views and grant access to users, groups, and roles. These Secure Views are created and managed by Privacera. For any changes to the masking or row-level security policies, the secure views are updated accordingly. Also, if there are any changes to the columns in the table, Privacera updates the Secure Views to reflect these changes. This eliminates the need for manual intervention to manage the Secure Views by the system administrators.

sequenceDiagram
    participant PrivaceraConnector
    participant Database

    PrivaceraConnector->>Database: Get metadata on regular intervals
    Database-->>PrivaceraConnector: Databases, Schemas and Tables
    PrivaceraConnector->>Database: Create Secure View for each table
    PrivaceraConnector->>Database: Grant privileges to users, groups and roles for Secure View

Query Execution¶

When a user queries a Secure View, the RLS and column-level masking policies are enforced dynamically.

sequenceDiagram
    participant User
    participant Database

    User->>Database: Query Secure View
    Note right of Database: RLS and column-level masking enforced dynamically
    Database-->>User: Return data with RLS and column-level masking applied

Data Admin¶

Some users may need the ability to update the data in the tables. These users can be granted the Data Admin privilege in Privacera. The Data Admin is special privilege within Privacera which allows users to update data in the underlying tables. However, for these users, RLS and column-level masking policies are not enforced.

The Data Admin privilege are generally given to service users and regular users who need to update the data in the tables.

Use Cases for Data Admin¶

1. You have ETL jobs which needs to create and update data in the tables. Generally, these jobs run as service users and need to have the Data Admin privilege.
2. You have users who own the underlying data and need to update the data in the tables.
3. You want users who needs to create views on the table.

Here are how the privileges are enforced for the users with Data Admin privilege:

Advanced Use Cases¶

Fine-grained Access Control to limited number of users¶

In some cases, to want to enforce RLS and column-level masking policies to a limited number of users. There are no options that are available to selective enable the table which needs to be managed using SecureView.

Here are few options that you can consider:

1. Enable SecureView for the connector and provide DataAdmin privilege to the users who needs to access to the entire table. Others will access the data using Secure Views and for these users RLS and column-level masking policies are enforced. Please note that in this SecureView will be created for all the tables.
2. Create a new connector and enable SecureView for this connector. This connector will have only the tables that needs to be managed using SecureView. For the other tables, you can use the existing connector. This way, you can provide access to the entire table to the users who needs it and for the other users, you can enforce RLS and column-level masking policies.

Comments