Skip to content

Row Level Security (RLS) and Column Level Security (CLS)

1. Introduction

eXate provides a centralized data security layer that allows organizations to enforce Row Level Security (RLS) and Column Level Security (CLS) consistently across multiple database platforms.

Unlike native database implementations such as Oracle Virtual Private Database (VPD) or Snowflake Row Access Policies, eXate enforces policies through the eXate JDBC driver and policy engine. For database capabilities where native RLS exists, eXate can push the entitlements to that system instead. This allows a single security model to be applied across Oracle, SQL Server, PostgreSQL, MariaDB, MySQL, DB2, Snowflake, and other JDBC-compliant platforms.

2. Architecture Overview

3. Understanding Manifests

A Manifest is the central metadata object used by eXate to describe and govern a database schema. A Manifest contains:

  • Tables
  • Columns
  • Data classifications
  • Logical business terms
  • Row level security policies
  • Column level security policies
  • Masking rules
  • Access control definitions

Typically, one Manifest represents a single schema.

4. Creating a Database Manifest

Method 1: Database Discovery via the eXate Portal

Supported connectors on the UI: Oracle, SQL Server, PostgreSQL, MariaDB, MySQL, DB2, Snowflake.

Process:

  1. Create a database connection
  2. Select schemas
  3. Generate a Manifest
  4. Review imported metadata
  5. Run GatorAId classification
  6. Publish the Manifest

Method 2: CSV Upload

Example CSV:

SCHEMA,TABLE_NAME,COLUMN_NAME,DATA_TYPE,MAX_LENGTH,LOGICAL_TERM,SENSITIVE
HR,EMPLOYEE,FIRST_NAME,VARCHAR,250,Name,TRUE
HR,EMPLOYEE,LAST_NAME,VARCHAR,250,Name,TRUE
HR,EMPLOYEE,EMAIL,VARCHAR,250,Email Address,TRUE

Method 3: REST API

Workflow: Create Manifest → Create Tables → Create Columns → Assign Business Terms → Assign Security Policies → Publish Manifest

5. Discovery and Classification using GatorAId

GatorAId automatically identifies sensitive information and recommends classifications. Examples:

Column Suggested Classification
FIRST_NAME Name
LAST_NAME Name
EMAIL Email Address
DOB Date of Birth

Logical business terms provide an abstraction layer between physical columns and security policies.

6. Column Level Security

Column Level Security is achieved by associating columns with logical business terms and applying masking policies. Example, for the business term "Email Address":

User group Access level
Admin Users Full Access
Support Users Partial Mask
External Users Fully Masked

The eXate JDBC driver applies masking before data is returned to the application.

7. Row Level Security

Row Level Security determines which records a user may access. Access decisions can be based on:

  • User identity
  • Active Directory groups
  • Access Control Lists (ACLs)
  • User attributes
  • Dynamic filter expressions

Recommended model: Restrict All Rows enabled (default deny). Users only see records when a filter explicitly grants access.

8. Creating Row Filters in the Portal

  1. Select the table
  2. Open the Actions menu
  3. Select "Add Filter Expressions"
  4. Open the Filter Expression Wizard

Step 1: Basic Information — Filter Name, Description.

Step 2: Access Control — define who can use the filter: Users, AD Groups, or ACLs. Examples: AD Group = HR_Admins, ACL = EmployeeDataReaders.

Step 3: Filter Definition

  • Retain Records That Match: only matching rows are returned.
  • Restrict All Rows: no rows are returned unless access is granted by a filter.
  • Groups: act as logical brackets, for example (FIRST_NAME='Joe Bloggs') OR (EMAIL IN HighlySensitive).
  • Conditional Script: allows advanced dynamic filtering based on user attributes, departments, regions, dates, or custom logic.

9. Row Filter API Example

Illustrative payload, not a finalised schema:

{
  "table": "EMPLOYEE",
  "filterName": "HR Access",
  "retainRecordsThatMatch": true,
  "restrictAllRows": true,
  "accessControl": {
    "adGroups": ["HR_Admins"]
  },
  "rules": [
    {
      "column": "DEPARTMENT",
      "condition": "Equal",
      "value": "HR"
    }
  ]
}

10. Future Enhancement

Current releases define filters against physical columns. Future releases will support filters applied directly to Logical Business Terms. Example:

Business Term: Employee Information, mapped to columns FIRST_NAME, LAST_NAME, FULL_NAME, DISPLAY_NAME.

Policies applied to the business term would automatically apply to all associated columns.

11. Apache Calcite Integration

Apache Calcite is used by the eXate JDBC driver to process and rewrite SQL before execution. Responsibilities:

  • Apply RLS filters
  • Apply CLS masking
  • Rewrite SQL statements
  • Support heterogeneous database platforms
  • Handle platform-specific SQL differences