Anonymization connection requirements
Published 11 September 2025
This document outlines the required database permissions for the commands the require a database connection.
Overview
The Classify commands are read-only operations that perform data analysis, while the Masking command modifies data and requires additional permissions.
SqlServer
These permissions are at the database level.
Classify Command
The following permissions are required for the Classify command:
| Permission | Purpose |
|---|---|
CONNECT | Establish connection to the database |
SELECT | Read data from tables for classification analysis |
VIEW ANY COLUMN ENCRYPTION KEY DEFINITION | Access encrypted column metadata |
VIEW ANY COLUMN MASTER KEY DEFINITION | Access master key information for encrypted data |
VIEW DATABASE PERFORMANCE STATE | Monitor database performance during operations |
Masking Command
The following permissions are required for the Masking command:
| Permission | Purpose |
|---|---|
CONNECT | Establish connection to the database |
SELECT | Read original data that needs to be masked |
UPDATE | Modify data with masked values |
VIEW ANY COLUMN ENCRYPTION KEY DEFINITION | Access encrypted column metadata |
VIEW ANY COLUMN MASTER KEY DEFINITION | Access master key information for encrypted data |
VIEW DATABASE PERFORMANCE STATE | Monitor database performance during operations |
ALTER ANY TRIGGERS DDL | Modify triggers that may interfere with masking operations |
PostgreSQL
These permissions are per schema and per table in a database.
Classify Command
he following permissions are required for the Classify command:
| Object | Permission | Purpose |
|---|---|---|
| Database | CONNECT | Establish connection to the database |
| Schema | USAGE | Allows access to objects contained in the schema (assuming that the objects' own privilege requirements are also met). |
| Table | SELECT | Allows read access to a table-like objects |
Masking Command
We need a user that has superuser privileges or to be the owner of the tables you are planning to mask because that is, to our knowledge, the only way to disable triggers and constraints in PostgreSQL.
We only try to disable triggers and constraints that are enabled, meaning if they have been disabled before Masking then, following are the least amount of privileges needed:
| Object | Permission | Purpose |
|---|---|---|
| Database | CONNECT | Establish connection to the database |
| Schema | USAGE | Allows access to objects contained in the schema (assuming that the objects' own privilege requirements are also met). |
| Table | SELECT | Allows read access to a table-like objects |
| Table | UPDATE | Allows update of any column or column(s) in a table |
MySql/MariaDB/Oracle
We currently have no way of Anonymizing these databases without being the schema owner or a proxy user.
