This article is about securing your CopyStorm data at the field level using CS:Govern, as well as recommendations on securing the target CopyStorm database. Fundamentally, the basic essential steps are the following:
Manage access to the Database. This is an action taken by the Database Administrator.
Manage access to specific fields within a table through users and roles. These are actions taken by the CopyStorm/CS:Govern user.
Remove all access to the Encryption Keys. This is an action taken by the Database Administrator.
It is suggested that the customer use their own Security Standards and Knowledge to append and/or replace the basic Security Architectural Design offered in this article.
Securing a CS:Govern database is the process of ensuring that only database users granted rights by CS:Govern can access decrypted values of fields.
For any user to be able to access decrypted data (where they have CS:Govern rights), execute access to a single function (per table with encrypted data) is required.
To access decrypted data in table “Contact” a user will need execute rights on the function guardContact_GET().
By default, CS:Govern grants public execute rights to all generated _GET functions and hides others.
Each _GET function enforces access policies set up by CS:Govern .
If a user accesses an encrypted field WITHOUT using the corresponding _GET function, they will always get the masked value for the field.
As an example of how to use the _GET function (sometimes referred to as the getter) here is how one would include the Contact.Email field in a typical SQL SELECT statement (in this example we are using SQL Server):
SELECT id, guardContact_GET(id, ‘Email’, Email) FROM Contact;
When a field is placed under CS:Govern protection, two basics pieces of information need to be supplied:
A masking rule is required that determines what the field data will look like to a user who does not have permission to view the field unencrypted.
One or more Compliance Categories should be applied to the field. Compliance Categories are combined with database user access rules to determine who should be able to see unencrypted field data.
Let’s look at a simple example for Account.ShippingCity:
The Compliance Category for ShippingCity is set to “PII”
The Rule is set to “Random”
In practice this means:
Database users allowed to see PII database will see Account.ShippingCity unencrypted.
Databases users without PII privileges will see a ShippingCity like jkmIjlM,
If the Masking Rules was set to a different rule, such as Asterisks, then users without PII privileges would see *********** when querying the Account.ShippingCity field.
A best practice for the initial setup of CS:Govern protected fields and their associated Compliance Categories is to examine Salesforce field meta data and mimic these rules in CS:Govern . This is an easy best practice to adopt by using a feature on the Edit Field Rules tab.
The Discover Sensitive Fields button (in the lower left corner) will scan Salesforce field metadata looking for encrypted/protected fields and suggest that the same fields be protected by CS:Govern . Of course, CS:Govern’s suggestions can be completely or partially ignored but accepting them is quick and easy.
The easiest Masking Rule best practice is to let CS:Govern choose the rule. If you do not like CS:Govern’s choice, you can always override it.
By default, CS:Govern will choose a masking rule for a newly protected field. CS:Govern’s built in rules will choose:
Asterisks for String fields.
A simple constant base64 encoded string for BASE64 fields (like Attachment.Body)
Randomized characters for Email and URL fields. The results will still be valid Email or Urls — but with random character substitution.
A Null value for Picklist, Combobox, or Multipicklist field.
A string with digits changed to asterisks for a Phone field.
A Null value of all other field types.
If the Masking rule for a field is changed AFTER data has already been encrypted, the newly encrypted data will use the new masking rule but older fields will not be changed until their containing record is updated. Additionally, a Remask Custodian will be created automatically that can be used to re-mask the exiting records in the database.
Please read this article to learn more about choosing an appropriate masking rule.
Prerequisite —
it is a requirement that a CopyStorm database exist prior to running CS:Govern. If that is not the case then CS:Govern will present the user with an error prompt and will then gracefully exit. Note that the CopyStorm database does not have to have data. The minimal requirement is that the Salesforce object tables, along with a handful of CopyStorm metadata tables exist. There are two strategies to consider here:
Strategy 1: Execute CopyStorm with the “Schema Only” option set such that the Salesforce object tables will be created in the CopyStorm database, but no data will be copied. Then CS:Govern can be used to add field encryption rules to the data that will eventually be copied down from Salesforce upon subsequent executions of CopyStorm.
Strategy 2: Execute CopyStorm with the “Schema Only” option unchecked such that the Salesforce object tables will be created in the CopyStorm database, AND data will be copied as well. Then CS:Govern can be used to add field encryption rules to that data, and the generated Custodians can be run to encrypt the data according to the CS:Govern rules that were created.
Regardless of the path taken, in either case a CopyStorm database will be present with the Salesforce object tables and the CopyStorm metadata tables. These are the necessary and sufficient tables required to successfully use CS:Govern.
Using the Login to CS:Govern
Using the Add Fields to be encrypted
Using the Run all Custodians that have been Added
Using the Assign compliance categories to users and roles to control decryption permissions.
While one is free to choose among the various masking rules that appear in the field’s drop-down, care should be taken when restoring data back into Salesforce using CopyStorm/Restore, as Salesforce has restrictions on the values that can be associated with a field value based upon that field’s data type. For example, the Contact.Email field is of type “Email” and Salesforce will be unhappy if that field value is not formatted as a legitimate email address. Legitimate in this sense does not mean it is a “legal” value (aka it is an actual email address that can send and receive emails), but, rather, it means that it “looks” like a real email address. So, while you are free to use masking rules such as “Asterisks”, “Lorem Ipsum”, “Random”, etc. for purposes of restoring data the “To Null” masking rule is your best option.For data analysis purposes, in which one is running reports, there are no such limits (unless the reporting tool has similar restrictions as Salesforce) and choosing from some of the other masking rules becomes a meaningful operation.
The following table lists the provided masking rules for the different Salesforce data types. The first entry for each data type is the default. Any masking rule highlighted in blue is an acceptable value that can be used when the goal is to restore data back into Salesforce.
Ensure that CopyStorm is connected to a PostgreSQL database. If this is the first time setting it up, follow the recommended best practices for .
CS:Govern for PostgreSQL requires that the pgcrypto package be installed. On most installations of CopyStorm, when a PostgreSQL database schema is created, this library will have been automatically added. However on older CopyStorm installations it is possible that pgcrypto was not included. If that is the case then the following command will add this required package:
Issue this command as the Database Administrator:
DateTime
DateTime To Null
Double
Numeric To Null
To Null Asterisks Base64 Digit Asterisks Lorem Ipsum Random Shuffle To Blank
EncryptedString
Base64 Asterisks Digits to Asterisks To Null To Blank Shuffle Random Lorem Ipsum
Int
Numeric To Null
JSON
To Null
Location
To Null
Long
Numeric To Null
MultiPickList
To Null
Percent
Numeric To Null
Phone
Digit to Asterisks Asterisks To Null To Blank Shuffle Random Lorem Ipsum
Picklist
To Null
Reference
To Null
String
Asterisks Digits to Asterisks To Null To Blank Base64 Shuffle Random Lorem Ipsum
Textarea
Lorem Ipsum Digits to Asterisks To Null To Blank Base64 Shuffle Random Asterisks
Time
Time To Null
URL
To Null
Address
Asterisks Digits to Asterisks To Null To Blank Shuffle Random Lorem Ipsum
Base64
Base64 To Null
ComboBox
To Null Asterisks Base64 Digit Asterisks Lorem Ipsum Random Shuffle To Blank
Currency
Numeric To Null
Date
Date To Null
CREATE
Allows creation of tables, functions, indexes, and triggers in the connected database.
USAGE ON SCHEMA [schema]
Allows use of the target schema (typically public) for creating objects.
CREATE ON SCHEMA [schema]
Required to create new tables and functions in the schema used by Govern.
SELECT
Allows querying Govern tables (e.g., for decrypting values, checking access roles).
INSERT
This query checks if the pgcrypto extension is available in your database. This extension is required for encryption and decryption functions such as pgp_sym_encrypt and pgp_sym_decrypt.
If pgcrypto is installed, you’ll see it listed in the results, usually under the public schema. If no rows are returned, the extension is not installed.
pgcrypto
public
This checks if the current user has the ability to use and create objects in the given schema. Note: Having CREATE on a schema allows creating tables, views, and functions.
Having CREATE privilege on the current schema means the user can:
Create tables, which they automatically own
Create functions and procedures
Create triggers on any tables they own
This level of access satisfies the required permissions for most CS:Govern operations within that schema, including defining DML triggers, custom logic, and support functions.
t
CREATE EXTENSION IF NOT EXISTS pgcrypto;REVOKE SELECT ON GuardianKey FROM public;SELECT * FROM pg_extension WHERE extname = 'pgcrypto';-- Replace 'your_schema' with the target schema name
SELECT has_schema_privilege(current_user, 'your_schema', 'USAGE, CREATE') AS has_required_schema_privileges;Ensure that CopyStorm is connected to a Microsoft SQL Server database. If this is the initial setup, follow the recommended best practices for configuring CopyStorm with SQL Server.
CREATE TABLE
Required to create Govern tables during initial installation.
Database-level permissions include actions like creating tables, procedures, functions, and managing schemas or indexes.
This output reflects the effective database-level permissions for the current user; results may vary depending on your specific permissions, roles, and inherited access rights.
The below SQL is useful for analyzing available schema-level permissions to the SQL Server user:
This output reflects the effective schema-level permissions for the current user; results may vary depending on your specific permissions, roles, and inherited access rights. If ALTER or CONTROL is returned, the user has sufficient rights to create DML triggers on any object within the specified schema.
Used to insert config data like access categories and key records during setup.
UPDATE
Needed to modify Govern config data (e.g., version updates, key rotations).
DELETE
Used to remove or reset records during setup or upgrades.
REFERENCES
Required to define foreign key constraints between Govern tables.
TRIGGER
Needed to create insert/update triggers used by Govern field enforcement logic.
CREATE FUNCTION
Required to create user-defined functions like guard_archive_get, which implement field decryption and access logic for Govern.
SELECT ON pg_roles / pg_user
Allows Govern functions to check current user’s database roles for field-level access decisions.
CREATE EXTENSION pgcrypto
Required to use built-in encryption functions like pgp_sym_encrypt and pgp_sym_decrypt for CS:Govern field protection.
VIEW DEFINITION
DATABASE
ALTER
DATABASE
ALTER ON SCHEMA::[schema]
Allows creation and modification of objects (like tables, indexes, and functions) in the Govern schema.
INSERT
Used to seed initial data such as Govern access categories and configuration values.
UPDATE
Allows updates to seed/config rows and ongoing modifications to Govern metadata.
DELETE
Used to remove existing config values, masking rules, or other records during reinitialization or management.
SELECT
Required to query Govern tables (e.g., metadata, access categories, encrypted values).
REFERENCES
Needed to define foreign key relationships between Govern tables (e.g., rule → field mappings).
CREATE FUNCTION
Required to define UDFs such as guard_encrypt and guard_archive_get.
CREATE INDEX
Allows creation of indexes to optimize performance on frequently queried columns.
EXECUTE ON [schema].guard_archive_get
Grants access to the main Govern UDF for retrieving decrypted field values, if the user has access. Internal function calls are executed under owner context.
SET IDENTITY_INSERT
Required to insert predefined identity values into tables like GovernAccessCategory.
CONTROL SERVER (optional)
Only required if using OLE Automation procedures (e.g., for developer-mode logging inside encryption UDFs).
CREATE PROCEDURE
DATABASE
CREATE TABLE
DATABASE
CREATE INDEX
ALTER
SCHEMA
DATABASE
-- Check effective database-level permissions for current user
SELECT *
FROM fn_my_permissions(NULL, 'DATABASE')
WHERE permission_name IN (
'ALTER ANY SCHEMA',
'CREATE FUNCTION',
'CREATE PROCEDURE',
'CREATE TRIGGER',
'CREATE TABLE',
'CREATE INDEX',
'VIEW DEFINITION',
'CONTROL',
'ALTER',
'VIEW ANY DEFINITION'
);-- Check permissions on specific schema (e.g., dbo)
SELECT *
FROM fn_my_permissions('dbo', 'SCHEMA')
WHERE permission_name IN (
'ALTER',
'CONTROL'
);Ensure that CopyStorm is connected to an Oracle database. If this is the initial setup, follow the recommended best practices for configuring CopyStorm with Oracle.
CS:Govern using Oracle requires that the DBMS_CRYPTO package is installed and accessible. The following command can be executed to give permissions to use the functions in that package:
GRANT EXECUTE ON SYS.DBMS_CRYPTO TO PUBLIC;The GuardianKey table, created by CS:Govern, contains highly sensitive data and should be granted the highest level of protection. It is strongly recommended that the database administrator execute the following command to restrict access to this table:
REVOKE ALL ON GUARDIANKEY FROM public;You can remove the WHERE clause from the query to display all session-level privileges granted to the current user. This will return an exhaustive list of effective privileges and will typically encapsulate most, if not all, of the required permissions for installing and operating CS:Govern, including those related to table operations, object creation, and encryption support.
This list represents typical permissions required for the application to function end-to-end. These include creating and indexing tables, defining stored logic (procedures and triggers), and executing or reading objects across the database. Your user account should return most, if not all, of these privileges.
This query checks if the current user has permission to execute the DBMS_CRYPTO package, which is often required for encryption or decryption operations. This privilege must be explicitly granted and is essential if the application uses database-native cryptographic functions.
A row with EXECUTE on DBMS_CRYPTO confirms that your user can call built-in cryptographic procedures. If no results are returned, that permission must be granted manually by an admin.
This query verifies whether the current session has permission to query the database’s internal dictionary views. This is required to inspect role assignments, privileges, and metadata — necessary for features like role-based access auditing or privilege introspection.
If SELECT ANY DICTIONARY is listed, the user has access to system-level metadata views. This enables advanced functionality such as privilege inspection, audit logging, or dynamic permission validation within the application.
CREATE TABLE
Allows creation of Govern tables for metadata, keys, masking rules, access control, etc.
CREATE PROCEDURE
Required to create stored procedures and user-defined functions used by Govern (e.g., decrypt functions).
CREATE TRIGGER
Needed to define insert/update/delete triggers used for enforcing masking and auditing.
CREATE FUNCTION
Required to create user-defined functions used by Govern (e.g., field access logic and decryption routines).
CREATE INDEX
SELECT *
FROM SESSION_PRIVS
WHERE PRIVILEGE IN (
'CREATE FUNCTION',
'CREATE PROCEDURE',
'CREATE TRIGGER',
'CREATE INDEX',
'EXECUTE ANY PROCEDURE',
'CREATE TABLE',
'ALTER ANY TABLE',
'DROP ANY TABLE',
'SELECT ANY TABLE',
'INSERT ANY TABLE',
'UPDATE ANY TABLE',
'DELETE ANY TABLE',
'CREATE SEQUENCE',
'CREATE VIEW',
'CREATE SYNONYM',
'CREATE TYPE'
);CREATE TABLE
CREATE PROCEDURE
CREATE TRIGGER
CREATE INDEX
EXECUTE ANY PROCEDURE
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'DBMS_CRYPTO'
AND PRIVILEGE = 'EXECUTE'
AND GRANTEE = USER;MY_USER
DBMS_CRYPTO
EXECUTE
SELECT *
FROM SESSION_PRIVS
WHERE PRIVILEGE = 'SELECT ANY DICTIONARY';SELECT ANY DICTIONARY
Allows creation of indexes to improve performance on Govern metadata queries.
SELECT
Allows querying Govern-owned tables (e.g., key lookup, access category resolution).
INSERT
Used to seed initial data such as access categories, masking rules, and configuration.
UPDATE
Required to modify Govern configuration or metadata records.
DELETE
Needed to remove config data or reset records during upgrades or testing.
REFERENCES
Required to define foreign key constraints between Govern tables.
EXECUTE ON DBMS_CRYPTO
Needed to perform encryption and decryption using Oracle’s DBMS_CRYPTO package.
SELECT ON DBA_ROLES
Allows Govern to evaluate database roles for user access enforcement.
GRANT SELECT_CATALOG_ROLE (optional)
Grants read access to all data dictionary views, including DBA_ROLES. Required if explicit access isn’t granted.
GRANT EXECUTE ON Govern Functions
If using AUTHID DEFINER, users must be granted EXECUTE to call decrypt/access functions directly.
SELECT ANY TABLE