What began with GDPR and HIPPA, is now an expanding wave of Regulatory Compliance expectations that will be challenging for Salesforce users. It is no longer enough for administrators to only dictate Compliance standards within the Salesforce environment. They must now also ensure that these standards are applied to all integrated and lower environments. CS:Govern was created to solve this exact problem. To maintain the most stringent interpretation of Regulatory rules, CS:Govern focuses on all four tenets within regulatory audit guidelines:
Data Security – “secure” is now the minimal standard, compliance is a much higher and more detailed standard
Data Minimization – this is conceptually opposed to Salesforce as a primary operational platform or system of record
Consumer Rights-to-Know – Salesforce cultivates data as a corporate asset aligned within use cases that optimize processes. Little consideration is given to develop consumer-centric data models that consider consumer rights to knowledge of what data businesses have and transparently share that with consumers
User Access – data security best practices focus on data as a whole, as well as large containers of mass records. However, regulatory obligations now revolve around individuals
Furthermore, CS:Govern provides the functionality to enhance and control all of your Salesforce Data Governance needs. Data Definitions and access can now be easily controlled by the business units with little to no intervention from Application Developers, DBAs, or BAs. Designated business users are now able to control each of the primary Governance functions that are required by Government Regulations or Internal Use Restrictions.
Installation Instructions
Step 1
Install CS:Govern on the platform of your choice: Windows or Linux/Mac.
Step 2
Implement CS:Govern on your chosen Database following the Step by Step Instructions found within the CopyStorm Best Practices documentation:
Installing CS:Govern takes a few seconds and does not touch any system files. You should not need root permissions.
Make sure your computer meets the prerequisites.
Java 1.8 (or above) must be installed.
Download CS:Govern from CapStorm
Change to the same directory as where CopyStorm is installed (usually /opt/capstorm with CopyStorm as a subdirectory). Be sure that you have administrative privileges on this directory so that you can unzip the download into this location (see the next step.)
Unzip the downloaded zip file into the “/opt/capstorm” directory. A single directory named CSGovern will be created.
Go to the “/opt/capstorm/CSGovern” directory and:
Run the command “sh CSGovern.sh” (or make the launch script executable).
CS:Govern Installation (Windows)
Installing CS:Govern (Windows)
Installing CS:Govern takes a few seconds and does not touch any system files or registry values. You should not need an administrator.
Make sure your computer meets the prerequisites.
All required software is packaged in the download as long as a Win64 version of the application is selected.
Download CS:Govern from CapStorm.
Change to the directory containing the directory CopyStorm (this is the directory in which CopyStorm is installed and is often C:/capstorm). Be sure that you have administrative privileges on this directory so that you can unzip the download into this location (see the next step.)
Unzip the downloaded zip file into the same the directory as the step above. A directory named CSGovern will be created at the same level as CopyStorm.
Go to the CSGovern directory and:
Double click on CSGovern.bat
CS:Govern Best Practices
This section contains best practice and how-to articles useful when installing and administering CS:Govern.
Database Setup
For database-specific setup guidance, see the corresponding CopyStorm reference articles:
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;
Steps for a Successful First Time Use
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.
Main Tab
The Main Tab is used to manage connection information and credentials for Salesforce and the target CopyStorm database.
It is a requirement that a CopyStorm database exist prior to running CS:Govern. If that is not the case then, upon switching tabs, 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 Custodians Tab Run all Custodians that have been Added
Using the Edit User Access Rules Tab Assign compliance categories to users and roles to control decryption permissions.
Steps for a Successful First Time Use
CS:Govern 1.64.1
Release Date: 5-Aug-2025
This is a minor feature, bug fix, and Salesforce API version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
Patch Levels
Date
Patch Level
5-Aug-2025
Original Release
Salesforce API Update
This release updates CS:Govern to use Salesforce API version 64.
Application Experience and Interface
Resolve issue causing the CS:Govern GUI to freeze when importing large rules files.
Resolve SQL/Server specific issue causing the CopyStorm BackupCreatedDate and BackupModifiedDate audit fields to be erased.
Improve transaction handling in CS:Govern schema updates.
Add CS:Govern launch feature to require OAuth login before accessing the application.
This article applies to CS:Govern installations which choose to use the built-in encryption key generation/management system. The built in system uses what is native to the respective database (for example: PostgreSQL uses AES256 keys and pgcrypto) and this is what most installations use. This article also applies to installations that have opted to manage their own keys.
When encryption keys are rotated:
New encryption keys are computed and stored in CS:Govern as the current keys.
Future encryption will be performed with the new keys.
Previously encrypted records will continue to use their original keys until a database update/insert forces them to use the new keys.
The key rotation operation is simple:
Select Tools => Rotate Encryption Keys option from the application menu bar in the top left of the application GUI..
Click on the Rotate Encryption Keys button.
Once done, the new encryption keys are installed in the default CS:Govern key store and will be used for future protection.
CS:Govern Release Notes
Common Tasks
Custodians Tab
Custodians
A CS:Govern Custodian is a small secure process used to perform long running tasks on a CS:Govern enabled CopyStorm database.
Here are a few examples where a Custodian is important.
Example 1: A User adds a protection rule to the field Attachment.Body and the CopyStorm database already has 1.2 million Attachment records. Someone needs to protect the existing 1.2 millions Attachment records WHILE CopyStorm continues to backup modified or new Attachments. The solution is an EncryptFields Custodian which will faithfully work to protect Attachment.Body fields until all of them are protected.
Example 2: A User removes protection from the Contact.HomePhone field AFTER CS:Govern has protected all (or part) of the Contact.HomePhone values. Someone needs to decrypt the Contact.HomePhone fields WHILE CopyStorm continues to backup modified or new records (without protection). The solution is a DecryptFields Custodian which will faithfully work to unprotect Contact.HomePhone fields until all of them are unprotected.
Example 3: A user wishes to change the masking rule for an existing protected field, from Asterisks to Lorem Ipsum. The solution is to use the Edit Field Rules tab to change the masking rule on the desired field, and then Save & Protect the change to the database. A RemaskFields Custodian will be automatically generated and can be used to apply the masking rule change to all records for the field’s table in the database. Additionally, all new records or all modifications to the existing records will use the new masking rule.
Custodians Tab
The Custodians tab’s role is to view, run, create, and otherwise manipulate CS:Govern Custodians.
Run a Custodian
To run/start a Custodian:
Right-Click on Custodian
Choose the Run Custodian option.
The Custodian will immediately begin processing data and its progress can be viewed by clicking on the Search button. While a Custodian is running several bits of information will be updated:
Last Update — Indication of how long the job has been running in a format such as 1h23m17s.
Process Id — the system process assigned to the Custodian by the operation system.
#Modified — the number of records updated so far.
LastRecord — the Salesforce Id of the most recent record scanned by the Custodian.
Once a Custodian completes, it will be marked inactive, and the Finished column will be set to the date on which the Custodian finished.
View the Details of a Custodian
To view detailed information about a Custodian.
Right-Click on a Custodian and choose the View Details option.
Or Double-Click on a Custodian.
Harvest Zombie Custodians
A Zombie Custodian is a Custodian which terminated unexpectedly without cleaning up after itself. This can happen when:
The Custodian Task Manager is killed manually while Custodians are running.
An admin reboots a computer while the Custodian Task Manager is running.
Plus three dozen of random variations of “the box crashed.”
The Zombie Harvest process looks for Custodians which indicate that they are running (by having a non-blank Process Id) and cleans up those whose Process Id is not running. “Clean Up” puts a Custodian into an “In Progress” state, making it eligible to be resumed by the Custodian Task Manager.
If the Zombie Harvest happens quickly (the normal case) then the only change you may see is a Process Id value disappearing from the list of Custodians. If the Zombie Harvest takes more than a second then it will display a progress dialog.
Add a New Compliance Category
How to Add a New Compliance Category to CS:Govern
A default CS:Govern deployment includes the Compliance Categories which Salesforce defines in its metadata. These include:
CCPA, COPPA, GDPR, HIPAA, PCI, PII, and Public (CS:Govern added Public).
CS:Govern stores all defined Compliance Categories in the database table GovernAccessCategory and adding a new Compliance category is as simple as adding a new record to this table.
To add a new Compliance Category:
Open the Tools => Edit Compliance Categories dialog from the menubar.
Remember to click on Save Changes to save edits to the database.
Click the Add New Category button to add a new compliance category to the table. You must give the category a name in order to save it.
Click the Undo Changes button to restore the dialog to match the current state of the database.
Click the Save Changes button to write all changes to the database.
Click the Cancel button to throw away all changes and closed the dialog.
The Type column will have one of these values:
Built-In — the category is built-in to CS:Govern and the only permissible option is to make the category active or inactive.
Custom — the category was created by a customer. Its name, description, and active option can be edited.
New — the category was added using the Add New Category button but not yet saved to the database.
For security and protection purposes, custom categories are treated the same as CS:Govern built-in categories.
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.
The Database option specifies the type of database where CS:Govern rules will be installed. If CS:Govern is not installed in the target directory, CS:Govern will automatically install itself on first database connection.
CS:Govern connection parameters are identical to what is used for other CapStorm products. For details see the instructions for CopyStorm.
Open the EditField Rules or View Field Rules tab and uncheck the field(s) to remove them from CS:Govern protection.
When a field is removed from CS:Govern protection, new and updated values will be stored directly in the corresponding CopyStorm table BUT records masked before the removal of protection will still be masked.
CapStorm applications respect CS:Govern masking rules in real-time and will automatically begin using unmasked values for all subsequent data inserts or updates.
CS:Govern automatically creates a Custodian which will unmask every value safely even while other database updates are in progress.
To return a field completely to its unmasked state, run the Custodian which was created.
Can I Add a New Masking Rule?
How to Create A New Masking Rule
CS:Govern Masking Rules are implemented as custom database functions and are persisted in the GovernMaskingRule table in a CopyStorm database.
The procedure to create a new Masking Rule is:
Review the code of an existing Masking Rule in your database.
Write and test SQL code for a new Masking Rule.
Insert a new record into the CS:Govern Masking Rule control table.
In this example, create a new masking rule which masks data by reversing its characters (e.g. ABC become CBA).
The follow code for SQL/Server was developed by looking at an existing masking rule.
After installing the new function into the database, the next step is to teach CS:Govern about the new Masking Rule.
Restart the CS:Govern GUI and the new Reverse masking rule will be available.
Does CS:Govern Allow For the Use of a Custom Encryption Key or a Keystore?
Does CS:Govern Allow For the Use of a Custom Encryption Key or a Keystore?
Database encryption is a process to convert data in the database to “cipher text” (unreadable text) using an algorithm. CS:Govern uses the database encryption inherent to its’ database to encrypt and decrypt the data designated as sensitive or confidential. In order to accomplish this, an encryption key is generated and used to encrypt and decrypt the text. CS:Govern leaves the choice of how the key is generated and where it is managed up to each client. You can utilize CS:Govern’s built-in key generation and management capability or employ your own encryption key. In order to employ your own encryption key, you must add your encryption key into CS:Govern’s encryption key management system.
The following section describes the steps necessary to add a custom encryption key to CS:Govern.
How to add a custom encryption key to CS:Govern
To add your own encryption key to CS:Govern’s Key Management System:
The rotation policy should include a process that inserts the new encryption key (manually or programmatically) into the CS:Govern GuardianKey table.
Login to the Database that is governed by CS:Govern as the owner of the encryption keys. The owner is the only one that should have access to the GuardianKey table.
Run or create a procedure that inserts the new key into the GuardianKey table. A sample script written for Microsoft SQL/Server is included below:
algorithm–A descriptive name for the system that generated the key
publicKey–the generated key
privateKey–the generated key
createdDate–current date and time
Edit Field Rules Tab
Edit Field Rules Tab
The Edit Field Rules tab is where fields are selected to be protected by CS:Govern. There are two ways to add a table to CS:Govern:
Click on the Add Tables Manually button in the lower left corner. This button will launch a dialog where you can pick one or more tables to add to CS:Govern.
Click on the Discover Sensitive Fields button in the lower left corner. This button will launch a dialog that searches Salesforce field meta data looking for all fields which have Compliance Categories and/or are marked as encrypted. Once the search is complete, the dialog will ask if fields it found should be added to CS:Govern.
Edit Rules for a Table
When a table is selected from the left section of the tab, a listing of all encryptable fields in the table will be displayed. By definition an encryptable field is one that is NOT included in the following list of named fields:
Id
IsDeleted
SystemModStamp
LastModifiedDate
Additionally an encryptable field is one that does not exist outside of the primary CopyStorm database (in other words, it is not a partitioned field. See the reference for more on partitioned fields.)
To add additional fields to CS:Govern protection:
Check the box in the Govern Enabled column for the field. Note that upon saving these changes, an Encrypt Custodian will be generated, and only when those Custodians are run will the CopyStorm data actually be encrypted. For more information about Custodians refer to our article.
Select one or more Compliance Categories for the field by clicking on the Compliance Category cell.
Optionally change the masking rule assigned with the field. The Masking rule determines what a user will see for the field when they do not have permission to access unencrypted data. For more information about masking rules refer to our article. For more information related to choosing an appropriate masking rule please refer to our
To remove a field from CS:Govern protection:
Uncheck the box in the Govern Enabled column for the field. Note that upon saving these changes, a Decrypt Custodian will be generated, and only when those Custodians are run will the CopyStorm data actually be decrypted. For more information about Custodians refer to our article.
Once CS:Govern field rules have been modified in the editor, they must be pushed to the corresponding CopyStorm database in order for them to take effect. The Save & Protect button writes pending changes to the database AND enables protection for the changes.
Note that upon saving these changes, Encrypt or Decrypt Custodian will be generated, and only when those Custodians are run will the existing CopyStorm data actually be encrypted or decrypted. Newly inserted or updated data will continue to be placed into the CopyStorm database using CS:Govern protection (if encrypted) or in its unmasked form (if no longer being CS:Govern protected.) For more information about Custodians refer to our article.
For completeness, the Undo Changes button will throw away unsaved changes and restore the editor to match what is currently stored in the CopyStorm database. No Custodians are generated when this action is taken.
Export CS:Govern Rules to Another Database
CS:Govern supports migrating protection and user access rules from one CopyStorm instance to another via its export and import subsystems.
Export CS:Govern Protection Rules
To export the current CS:Govern protection rules use the application menu bar File => Export Protection Rules operation.
A normal File Save dialog will be opened.
A file of configuration rules will created (.csGovernRules extension).
The exported rule file is an XML file that can be viewed (and edited if required). It will look like:
Importing previously export CS:Govern protection rules into a CopyStorm database is a three step process:
Use the File => Import Protection Rules into CS:Govern.
Verify the list of rules imported from a dialog CS:Govern displays.
Deploy the updated rules using the Save & Protect button.
View Compliance Assignments Tab
View Compliance Assignments
The View Compliance Assignments tab displays all CS:Govern fields that have been assigned a selected Compliance Category, and organized in a table with one line per field. For each field in the list a user can remove it from the selected Compliance Category. Note that it does not remove the field from CS:Govern protection. It only changes which Compliance Categories that protection is assigned to. For example, if the field is protected and assigned to HIPAA and PII, but the intent was to only have it assigned to HIPAA, then removing the assignment to PII is as simple as selecting PII from the Filter drop-down and clicking the Remove button next to the field.
How Does CS:Govern Work With CopyStorm?
How Does CS:Govern Work With CopyStorm
Simply put, CopyStorm retains the exact same functionality with CS:Govern as it does without. With this being said, there are some key facts that must be understood regarding the Encryption of the data.
Encryption occurs whenever a job is run
If it is a full load, then all fields as defined by CS:Govern will be encrypted from the beginning of time
If it is an incremental load, only records that CopyStorm deems to relevant to the appropriate time frame will be encrypted (Encryption Rules defined by CS:Govern)
It is not necessary to do a full SalesForce backup with CopyStorm when a new rule is developed within CS:Govern.
CS:Govern encrypts all appropriate records (defined in Edit Rules Tab) utilizing the CS:Govern Custodian job
Custodian Runner Tab
Though CS:Govern Custodians can be started from the main Custodian tab, the best practice is to manage the running of Custodians using the Custodian Task Runner.
The Custodian Task Runner is a command line tool which inspects the CS:Govern database tables to determine what Custodians should be running.
The Customer Task Runner is easily scheduled as an automatic task.
Overview
CS:Govern adds rich transparent field encryption capabilities to the entire suite of CapStorm® products. With CS:Govern you can:
Force fields in a CopyStorm backup to automatically be encrypted (without changing any of your current backup processes.)
Inherit encryption and compliance categories from Salesforce/Shield® and automatically apply the same rules in a CopyStorm backup.
CS:Govern 1.62.1
Release Date: 16-Dec-2024
This is a minor feature, bug fix, and Salesforce API version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
Date
Patch Level
This release updates CS:Govern to use Salesforce API version 62.
Do I Need to Shut Down CopyStorm, Restore or Medic When Running Govern?
Generally speaking, there are two types of events that would require that CopyStorm, Restore or Medic be shut down while CS:Govern is being used. The first is when the Table/Field rules are being added or removed. Those changes are not reflected in the CopyStorm, Restore or Medic sessions until they are re-started. For example, Medic will prevent a user from dropping any table that has at least one Governed field. However, if a new field is added to Govern protection while Medic is already started, then the user will be able to drop the table that contains that field. It is only when Medic is restarted that it will know that the table should not be able to be removed.
The second event is when a Custodian is being executed. Restore should definitely be shut down if any of the tables being restored back to Salesforce are under CS:Govern protection. And, depending upon what task is being executed in Medic, that, too, would need to be shut down. For example, if one is running a Restore session, and an Encryption Custodian is executing in CS:Govern, until that Custodian has completed, it is possible that some of the records in tables being restored have not yet been encrypted and masked, as it takes the Custodian a non-zero amount of time to protected those records. In that case one risks restoring unprotected data back into Salesforce. Whether this is a problem or not depends upon the use case. In the case of Restore, it also depends upon whether the objects being restored are under CS:Govern protection or not. Similarly, depending upon which Medic tool is being applied, similar discrepancies can occur. For example, if the Base64 Export tool of Medic is being used, and an Encryption Custodian is executing, some of the files dumped to the file system will be protected and others will not.
The same argument holds true for changes to the masking rules, user and role privileges or compliance categories. Depending upon how much data resides in the CoyStorm database and what activities are being conducted in CopyStorm, Restore or Medic, one may see transient results in the data which may lead to unexpected data discrepancies.
How Does CS:Govern Work With Base64 Chunking?
All databases have upper limits on how much data a column can hold, and the CS:Govern supported databases are no exception. Some data originating in Salesforce are large documents (Attachment, and ContentVersion are good examples) that can easily exceed the maximum database limit on column width.
To get around this problem, CopyStorm introduced a feature known as “chunking” and since the field types for these large documents are Base64, the technique is commonly referred to as Base64 Chunking.
When chunking Base64 field values, CopyStorm will break the field value into as many chunks as it takes to store the effective field value in the database across several records. A separate table, the CopyForceTableFieldChunk table, holds the chunks as Base64 values. Later, when restoring these field values back into Salesforce, these chunks are recombined (we refer to that as “stitching”) and restored back into Salesforce as a whole.
The same discussion holds true of the Snapshotting system with the exception that the field value chunks are stored in a CopyForceArchiveFieldChunk table. And unlike the “normal” CopyStorm field values which are only chunked if a Chunk Base64 Values configuration flag is enabled, Snapshot Base64 field values are ALWAYS chunked regardless of how big or small those values may be.
Since chunked values are always stored in a separate table from the Salesforce object table in the CopyStorm database, one might wonder what field value is placed into the object table column? When chunking is performed, CopyStorm, as well as the Snapshot system, will place a “pointer”, which is a JSON representation of the metadata pointing to the respective chunk tables, into the column value.
CS:Govern 1.56.3
Release Date: 12-Jan-2024
This is a minor feature and bug fix release. As always, existing CS:Govern configuration files are backwards compatible.
Date
Patch Level
The “Detect Sensitive Fields” logic has been updated to identify Salesforce fields that do not have an assigned compliance category.
CS:Govern 1.54.1
Release Date: 22-Aug-2022
This is a minor feature, bug fix, and Salesforce API version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
Date
Patch Level
CS:Govern has been updated with the ability to protect numbers, reference fields, dates, and date/times.
View Field Rules Tab
The View Field Rules tab lists all fields added to CS:Govern (including those not yet saved or protected) and provides limited editing capabilities. The purpose of this tab is to list just the fields in CS:Govern.
There are several editing operations that can be performed on fields using the tab.
Remove a field from CS:Govern protection by unchecking the box in the Govern Enabled column.
Modify the Compliance Categories assigned to a field.
CS:Govern 1.56.2
Release Date: 15-Sept-2023
This is a minor feature and bug fix release. As always, existing CS:Govern configuration files are backwards compatible.
Date
Patch Level
This release adds support for Long Ids in Govern-Enabled CopyStorm Snapshots – adding support for CopyStorm Snapshot configurations that store more than 2.1 billion records.
CS:Govern 1.59.1
Release Date: 17-Apr-2024
This is a minor feature, bug fix, and Salesforce API version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
Date
Patch Level
This release updates CS:Govern to use Salesforce API version 59.
CS:Govern 1.59.3
Release Date: 22.Aug.2024
This is a bug fix version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
CopyStorm and CS:Govern must stay on the same version. If CS:Govern is upgraded to version 1.59.3, CopyStorm must also be upgraded to version 10.59.3.
Date
Patch Level
Large Attachments are now supported for full end-to-end encryption.
22-Aug-2022
Original Release
Patch Levels
New Field Type Support
Large Attachment Support
15-Sept-2023
Original Release
Patch Levels
Add Long Id Support for Govern Snapshots
As an example, let us suppose that one is using the Restore Set Editor in Restore and previewing data for Account records. Let us also suppose that the BillingStreets field of those records are being protected by CS:Govern using an Asterisks masking rule. And, finally, let us suppose that inside of CS:Govern a user is changing the masking rule for that field from Asterisks to Blank. It is conceivable that when previewing the data in Restore, some of the records will appear as asterisks, while others will appear as blank. If one is restoring the data back into Salesforce, it is possible that some of the Account records will restore the BillingStreet with asterisk values while other records are blank.
As a rule of thumb, it is safest to shut down all CopyStorm, Restore and Medic sessions while changes are being made to CS:Govern.
Do I Need to Shut Down CopyStorm, Restore or Medic When Running Govern?
When CS:Govern is used to protect Base64 chunked field values (such as the Body field of an Attachment, or the VersionData field of a ContentVersion record) there are two operations that have to happen:
The “pointer” column value has to be encrypted in the storage table, and the field value has to be masked. This is all standard CS:Govern functionality.
The chunks need to be individually encrypted and those encrypted values need to be placed into the GuardianTableFieldChunk table or the GuardianArchiveFieldChunk table, depending on whether the record is being created for CopyStorm or the Snapshotting system.
Note that field values for CS:Govern protected fields are ALWAYS chunked regardless of whether the Chunk Base64 Values configuration switch is enabled or not. If a field value was not originally chunked, but is later protected under CS:Govern, then when a Custodian is run on that value, that field will become a set of one or more chunks stored in the tables mentioned above.
CS:Govern creates INSTEAD OF INSERT triggers on the CopyStorm chunk tables (CopyForceTableFieldChunk and CopyForceArchiveFieldChunk) which is significant because it implies that should there be any error in processing the field value chunks, the insertion of chunks into those tables are in the same transaction as encrypting the chunk values and putting those into the respective CS:Govern chunk tables. In this manner there is no transient state in which some unencrypted chunks reside in the CopyStorm tables. They are either residing in an encrypted state in one of the CS:Govern chunk tables, or they do not reside anywhere.
Control CopyStorm decrypted field access based on database user/role rules you define.
Control encryption keys yourself or use CS:Govern’s built in support for the industry standard encryption standards (example: AES256).
Why would a CopyStorm customer want to add CS:Govern capabilities?
A customer wants a complete backup of Salesforce — including all data which is encrypted in Salesforce.
A customer wants to safely use their CopyStorm backup for reporting and analytics without exposing sensitive data to all database users.
A customer wants to adhere to all Compliance and Regulatory requirements throughout the Salesforce backup environment
CS:Govern employs a technique called Transparent Data Encryption (TDE) to achieve a security compliant CopyStorm database. In a TDE implementation:
An application writing to a database does not know that certain fields are being encrypted.
An application writes to database fields as if the fields are encrypted or unencrypted automatically.
CS:Govern achieves TDE by dynamically generating and installing code into a CopyStorm database based on the security rules supplied by a customer. The only way to bypass the security code installed by CS:Govern is by explicitly deleting CS:Govern code as a database administrator (i.e. a high level, high privilege bad actor is required).
In addition, CS:Govern has exactly one component that should be kept secret from normal database users — the encryption key store.
Making decryption totally transparent is pretty much impossible to do unless a person writes to the database engine. What CS:Govern does is generate database access code for every table under CS:Govern management. The code determines if the current database session user has access to a field and returns its unencrypted value if access is allowed (based on CS:Govern rules) or the field’s masked value otherwise. Naturally, CapStorm’s application automatically generate database queries which include CS:Govern access code wrappers. Other applications can do the same or, for simplicity, create a database view which uses the CS:Govern wrappers.
CS:Govern is, at a minimum, an intelligent dynamic SQL function and trigger generator that reacts to administrative changes to the selected fields to be Governed, the masking rules, and the associated compliance categories.
CS:Govern currently supports Oracle, SQL Server and PostgreSQL.
CS:Govern Overview
How Does CS:Govern Work?
Supported Databases
This release introduces a new custodian type that re-encrypts data when the CS:Govern encryption key is updated.
SQL/Server Audit Fields: Fix
Resolve a SQL/Server issue preventing population of the BackupCreatedDate and BackupModifiedDate audit fields.
Progress Reporting: Fix
Resolve a progress reporting / apparent deadlock issue when redeploying database automation.
SQL/Server Lock Contention: Fix
Resolve SQL/Server lock contention issue when modifying CS:Govern configuration for multiple objects simultaneously.
16-Dec-2024
Original Release
Patch Levels
Salesforce API Update
Add Key Rotation Custodian
Bugfixes and Performance Improvements
Fields will be identified if they are in the CopyStorm database and any of the following are true:
The field is Shield-Encrypted.
The field is of type “Encrypted String”.
The field has an assigned Compliance Group.
The field has an assigned Security Classification.
Fields will be placed into the Compliance Group assigned in Salesforce, if that Compliance Group is also present in CS:Govern. If the Salesforce Compliance Group is not present in CS:Govern, then the “Public” Compliance Group will be assigned.
Resolve an issue that could cause CS:Govern configurations to be retained when the target CopyStorm database is changed.
12-Jan-2024
Original Release
Patch Levels
Revamp “Detect Sensitive Fields” Logic
Resolve UI Caching Issue
This release updates CS:Govern to support very long Salesforce table names – i.e. table names far longer than the maximum. This allows support for managed packages whose combined prefix (e.g. “mypackage__”), table name, and postfix (e.g. “__History”) are longer than 64 characters.
Update to prevent partitioned fields from being selected in the CS:Govern UI.
Fix an issue causing an apparent application hang when importing a very large CS:Govern rules file.
Resolve a GUI issue preventing the “Save & Protect” from being enabled on the “View Compliance Assignments” tab when an assignment is removed.
17-Apr-2024
Original Release
Patch Levels
Salesforce API Update
Add Support for Long Table Names
Bug Fixes and Misc Improvements
Snapshot Decryption: Performance Improvement
Improved Performance Monitoring during automatic discovery of Salesforce sensitive fields
New fields added to CS:Govern are now assigned a default compliance category of Public
Date Formatting: Bug Fix
Fix Consistency of Date Formatting when Reading from Snapshots
Support Added: for non-DBO schemas in SQL/Server
22.Aug.24
Patch Levels
Original Release
Application Experience & Interface
Example: Create Reverse Masking Rule
modifiedDate–current date and time
CREATE OR ALTER FUNCTION [dbo].[guard_mask_to_reverse]( @original NVARCHAR(MAX) ) RETURNS NVARCHAR(MAX)
AS
BEGIN
IF @original IS NULL RETURN NULL;
IF @original = '' RETURN '';
RETURN REVERSE(@original)
END;
BEGIN
DECLARE @id INT;
DECLARE @templateRuleId INT;
DECLARE @now DATETIME;
--
-- Insert a top level masking rule.
--
INSERT INTO GuardianMaskingRule(name,functionName,isActive,createdDate,modifiedDate)
VALUES( 'Reverse', 'guard_mask_to_reverse([[VALUE]])', 1, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP)
;
--
-- Pick an existing rule which works on the same field types as the new rule.
-- Find the unique id assigned to the new rule.
--
SELECT @templateRuleId=id FROM GuardianMaskingRule WHERE name='Asterisks';
SELECT @id=id, @now=createdDate FROM GuardianMaskingRule WHERE name='Reverse';
--
-- Register the type of Salesforce fields supported by the masking rule.
--
INSERT INTO GuardianMaskingRuleFieldType(fieldTypeName, maskingRuleId
, createdDate, modifiedDate)
SELECT fieldTypeName, @id, @now, @now
FROM GuardianMaskingRuleFieldType
WHERE maskingRuleId = @templateRuleId;
END;
INSERT INTO [dbo].[GuardianKey]
([algorithm]
,[publicKey]
,[privateKey]
,[createdDate]
,[modifiedDate])
VALUES
(<algorithm, nvarchar(64),>
,<publicKey, nvarchar(max),> ,<privateKey, nvarchar(max),> ,<createdDate, datetime,>
,<modifiedDate, datetime,>)
GO
The Custodian Task Runner is smart enough to detect when a Custodian failed to complete normally and will automatically resume a Custodian. Example: If a computer is rebooted during protection of Attachments, the Custodian Task Runner will automatically resume Attachment protection.
The primary purpose of the Custodian Task Runner tab is to generate a command line which can be scheduled to run Custodians. The generated command lines support the following command line arguments.
Command Line Switch
Options
Description
-action
run status
The “-action run” command switch tells the runner to start active Custodians which are not currently running. The runner will wait for the all custodians to be finished before exiting and will automatically detect new Custodians added before it exits The “-action status” command switch tells the runner to print out tables of currently running and pending Custodians.
-custodians
Comma separated list of Ids
The Custodian Runner generates and displays command lines based on the current CS:Govern configuration.
Three different command lines are generated:
Local Computer: This command line can be run directly on the current computer.
Windows: This command line will work on a Windows computer. You will need to replace {GovernInstallation} with the path to CS:Govern (example: c:\Capstorm\CSGovern)
Linux or Mac: This command line will work on a Linux or Mac computer. You will need to replace {GovernInstallation} with the path to CS:Govern (example: /opt/Capstorm/CSGovern)
Custodian Runner
Generated Command Lines
Modify the Masking Rule associated with a field.
Of course, pending CS:Govern changes can also be Saved & Protected, or Undone using the standard buttons at the bottom of the tab.
View Field Rules
View Table Rules Tab
View Table Rules
The View Table Rules tab displays all CS:Govern fields organized in a table with one line per table. For each table in the list a user can:
Double click on a table to launch a dialog of information about the table.
Right click on a table to launch a context menu with operations such as:
Reinstall Protection — upgrade the CS:Govern protection rules (even if the code thinks this is unnecessary).
Install Protection — apply CS:Govern rules to just the selected table.
Remove Protection — remove CS:Govern protection for all fields in the table.
View Details — show CS:Govern details about the table. The same details can be displayed using a double-click.
Of course, pending CS:Govern changes can also be Saved & Protected, or Undone using the standard buttons are the bottom of the tab.
Double-clicking on a table will show a dialog with details about a table and its protection.
Name
Description
The lower part of the dialog lists each field protected in the table. The following table lists each field property displayed.
Name
Description
SQL Server Permissions
SQL Server Permissions
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.
Required Permissions
Permission Required
Why It’s Needed
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.
permission_name
class_desc
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.
permission_name
class_desc
Field Compliance Categories and Masking
Field Compliance Categories and Masking
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:
In this case:
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.
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 article to learn more about choosing an appropriate masking rule.
How Does CS:Govern Work With Snapshotting?
How Does CS:Govern Work With Snapshotting?
The CopyStorm Snapshotting system is analogous to the old cartoon flip books in which each successive page of the book was slightly different from the one before it. By rapidly flipping through those pages, however, a story is told. Think of a CopyStorm snapshot as being a page in the book – it is a view of the state of your Salesforce data at that point in time that it was created. Viewing the data in succession is like the cartoon flip book – your data evolves over time and those views tell your data story.
All Capstorm products were designed to work together in concert, and accordingly, CS:Govern integrates seamlessly with the CopyStorm snapshotting system. The functionality parallels that of a “normal” CopyStorm database with similarities and differences described in the following table:
Feature
CopyStorm
Snapshot
The interaction between CS:Govern and the Snapshotting system parallels the interaction it has with the CopyStorm database. CopyStorm is not CS:Govern “aware”, and the Snapshotting system is mostly not aware either. It must be emphasized that in both cases at no point in time are new or updated records with protected fields stored anywhere in a human readable form (aka, unencrypted). That includes the CopyStorm database as well as the Snapshot records XML document. Should CopyStorm, or a running Custodian, mysteriously hang, or should the machine running either CopyStorm or a Custodian, crash, there is no transient state in which processed CopyStorm records, or Snapshot records contain any unencrypted data. For the case of an EncryptFields Custodian crash, the incremental execution of a Custodian guarantees that upon rebooting the system, or restarting CS:Govern, the Custodian will continue where it left off and continue the encryption process on the remaining records. Should a CopyStorm session be running in parallel with any Custodian executing at the same time, all new and updated records in CopyStorm will have their protected fields encrypted.
While Salesforce data is entered into the CopyStorm database, depending upon the CS:Govern field rules, triggers may, behind the scenes, encrypt that data and push masked values into the CopyStorm records, and encrypted values into the associated CS:Govern storage tables. This is how CopyStorm is completely CS:Govern un-aware.
The Snapshotting system is only slightly different from CopyStorm in the sense that the XML data document in a Snapshot record IS the storage medium as well as the holder of unencrypted data. Triggers do not create the Snapshot records – the Snapshot system is responsible for that. The Snapshot system needs to know which records are protected, so that it can intelligently retrieve the encrypted values, which are then stored as a Base64 representation in the XML tag. That is why the Snapshot system is “mostly” CS:Govern un-aware.
The following screenshot is an example of a Snapshot XML document. Notice that it contains non-encrypted data as well as encrypted data along with the masked values for BillingCity and BillingStreet. Encrypted values are stored in the XML document in their Base64 representation.
How Does CS:Govern Work With CopyStorm Restore?
How Does CS:Govern Work With CopyStorm Restore
CapStorm developed each of their products to seamlessly integrate with each of the other products within its inventory. CopyStorm/Restore maintains the exact same functionality with just a key few features added within. These features determine whether or not the user has the rights to see the decrypted data extracted from the CopyStorm Backup Database.
Step 1: CS:Govern determines whether the user has the rights to decrypt the data.
Step 2: If the user has the rights to decrypt the data, the user can then determine whether they want the data to remain encrypted or to decrypt the data when performing the restore.
How Does CS:Restore determine whether a user can view the decrypted data?
CS:Restore integrates seamlessly with CS:Govern to determine the Compliance Rules that grants or denies a user the right to see the decrypted data.
If a user does not have access, how does the data appear?
If a user has not been granted access, the data will be encrypted
***Note that the Billing City and Billing Street are Encrypted with asterisks and lorem ipsum below
If a user has been granted access, the data will be decrypted
***Note that the Billing City and Billing Street are Decrypted with viewable data below
In CopyStorm/Restore, follow the steps below:
Login to CopyStorm/Restore
Go to the “Global Parameters” tab
Select the ‘Decrypt Compliance Data’ checkbox to see and restore the decrypted value
Leave the checkbox unchecked to leave the values encrypted
CS:Govern 1.65.1
Release Date: 28-Apr-2026
This is a Salesforce API version upgrade release. As always, existing CS:Govern configuration files are backwards compatible.
Salesforce API version 65 deprecates the SOAP username/password login endpoint. Customers should migrate to an external client application configured with OAuth. CS:Govern execution using a login type that does not support API 65 will automatically fall back to API 64, and an exception will be logged when running tasks.
This exception can not be eliminated until OAuth authentication is used.
Salesforce API Version Fallback for Username/Password Logins
The "Fallback API Detected" error does not stop jobs from running - it is informational, and indicates that CopyStorm is not able to use the most recent Salesforce API features. The error will be resolved when updating to JWT (or other OAuth) authentication.
Please reference
This release updates CS:Govern to use Salesforce API version 65.
Edit User Access Rules Tab
Edit User Access Rules
The Edit User Access Rules tab is used to specify the Compliance Categories accessible to database users and roles. Basically, a field and user must have at least one common Compliance Category in order for a user to see unencrypted field data.
If a database user is not in the User Access Rules table and not a member of a database role in the table (directly or indirectly) then the database user will be denied access to CS:Govern protected fields. “Denied Access” means that they will see the Masked value for any CS:Govern field they try to read.
If a database user is in the User Access Rules table (directly or because of database role membership) then they will be able to view encrypted data for any CS:Govern protected field which matches one of the Compliance Categories assigned to the user.
Examples:
Suppose database user “henry” is in the User Access Rules table and his Compliance Categories include Public and PII. When reading CopyStorm field data, “henry” will be able to view any field in the Public or PII compliance categories unencrypted. For CS:Govern fields in other compliance categories “henry” will see the masked value.
Suppose database user “mary” is not in the User Access Rules table but “mary” is a member of the database role “HumanResources” in the User Access Rules table. If “HumanResources” can see unencrypted data in PII fields, then so can “mary”.
Suppose database user “greg” is in the User Access Rules table but no compliance categories have been set his record. User “greg” will not be able to see any decrypted field values.
To add a new database user or role to the CS:Govern rules:
Click on the Add Additional Users or Roles button. This will launch a dialog for selecting users and roles.
Edit the Compliance Categories for the newly added user or role.
Click on the Save button to write changes to the CopyStorm database. After the save operations CS:Govern will be using the rules.
Removing a user is simple: Click on the Remove button at the far right of any user or role record.
Once a user or role is selected set the Compliance Categories accessible to the user or role.
What Happens if My System Crashes During a Custodian Run?
What Happens if My System Crashes During a Custodian Run?
Custodians always record the last Id of the record that they process. In the event of a system crash or failure, a simple restart of CS:Govern and resume of the Custodian, will result in that Custodian continuing on from where it left off as though nothing ever went wrong.
Additionally, as new records are brought down by CopyStorm, which include Governed fields, those fields will be protected (encrypted and masked) as expected.
Note, however, that during the time between when the system crashed and new records are brought down from CopyStorm, there will be a certain number of records that should have been protected by the Custodian that have not (that is, assuming this is an Encryption Custodian). There are two ways to ensure that the gap in these records is filled:
After a system crash and the machine has been brought back to normal functioning levels (e.g. a system reboot), the CS:Govern user can manually launch the Custodian that was running prior to the failure.
The Custodian runner (see ) can be used to detect that a previous run of a Custodian was stopped midstream due to a system failure, and will automatically resume that Custodian (or Custodians.)
Of the two, clearly the second option is the preferred one and the solution most recommended, as it is an automated process that requires no manual intervention.
PostgreSQL Permissions
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:
Permission Required
Why It’s Needed
Choosing A Masking Rule
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.
Run only the specified Custodians. The “Id” for a Custodian is listed as the first column on the Custodians Tab.
-maxJobs
20
The maximum number of Custodians to run concurrently.
-silent
None
If specified, there will be no output from the runner unless and error occurs.
-apacheLog
None
If specified then the Apache Commons Logging framework will be used.
-cscredentials
String
The argument to this flag is an AES256 encrypted version of the credentials required to connect to the CopyStorm database used by CS:Govern . It is possible to specify the credentials on the command line in an unencrypted form, but this approach is not recommended.
A string with digits changed to asterisks for a Phone field.
Name of the function which can decrypt field values. Of course, it will decrypt a field only if the current database user has permission to see a field. Note: This function should made executable for all users.
Insert Trigger
Name of the CS:Govern created insert trigger on the CopyStorm table. This trigger is foundational to how CS:Govern enforces transparent encryption. Note: Often the Insert and Update trigger are the same.
Update Trigger
Name of the CS:Govern created update trigger on the CopyStorm table.
Delete Trigger
Name of the CS:Govern created delete trigger on the CopyStorm table. When a record is deleted by CopyStorm the trigger automatically deletes the corresponding encrypted data for the record.
Truncate Trigger
If a database supports triggers on TRUNCATE operations, CS:Govern will install a trigger on a CopyStorm table to mimic truncate operation. Most database do not support this type of trigger.
Insert Function
Some databases require the code for a trigger to be separate from a trigger declaration (PostgreSQL for example). When required, this is the function invoked by the insert trigger.
Update Function
Some databases require the code for a trigger to be separate from a trigger declaration (PostgreSQL for example). When required, this is the function invoked by the update trigger.
Delete Function
Some databases require the code for a trigger to be separate from a trigger declaration (PostgreSQL for example). When required, this is the function invoked by the deletetrigger.
Truncate Function
Some databases require the code for a trigger to be separate from a trigger declaration (PostgreSQL for example). When required, this is the function invoked by the truncate trigger.
Compliance Category
Semi-colon separated list of compliance categories assigned to the field.
Deployed
Yes if the field is protected. No if there are pending changes to be deployed for the field.
Salesforce Table
Name of the Salesforce table. This may be different than the CopyStorm database table name.
Deployed
Yes if the database protection code has been deployed to the database. No if there are changes pending deployment.
Storage Table
Id
Internal unique CS:Govern id for a field.
Field
Salesforce API name for a field.
Guardian Masking Rule
Name of the database table used to store encrypted field values.
Rule for showing field data to a person without permission to see the unencrypted value.
Field data is stored as chunks in the CopyForceTableFieldChunk table depending upon whether the Base64 chunking function is enabled in the configuration and whether the Base64 value, in its entirety exceeds the configured maximum chunk size or not. If chunks are created then the field value in the CopyStorm object table is a “pointer” (a JSON snippet containing metadata related to the record in the CopyForceTableFieldChunk table.)
Field data is ALWAYS stored as chunks in the CopyForceArchiveFieldChunk table. The XML field value is a “pointer” (a JSON snippet containing metadata related to the record in the CopyForceArchiveFieldChunk table.)
Insertion Policy
Immediate upon executing a CopyStorm session.
NEVER. The CopyStorm database is considered the effective latest snapshot, so storing new records in a snapshot would be redundant.
Update Policy
Immediate upon executing a CopyStorm session.
Depending upon the snapshot policy configuration, a new snapshot record will be created in the CopyForceArchiveRecord table either prior to, or after, the update.
Location of CS:Govern Field Assignment Masking Rules and Compliance Categories
The CS:Govern database, GuardianFieldAccessCategory and GuardianField tables.
The Snapshot database, CopyForceArchiveFieldSet table.
Record Storage
Salesforce Object Table (e.g. Account)
CopyForceArchiveRecord Table. A single XML document contains all the field values for a record.
Field Value Location
One-to-one correspondence with Salesforce Object Table column.
XML Tag inside the parent XML document containing all field values.
Deleted Record Handling
Depending on deleted record retention settings in the config, records are eventually deleted. If the retention period is zero, the record is immediately deleted.
Field data is NEVER deleted. It would defeat the purpose of having a snapshot in the first place, and would be equivalent to deleting a page in the cartoon flip book.
Base64 Handling
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
Check Database Level Permissions
Expected Output
Check Schema Level Permissions
Expected Output
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'
);
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.
extname
schema
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.
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;
Check If pgcrypto Is Installed
Expected Output
Check If the User Has USAGE,CREATE On the Current Schema
Expected Output
Data Type
Available Masking Rules
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
Choosing A Masking Rule
Protect Database Fields
Protect Database Fields
The procedure for bringing a field under CS:Govern protection is fairly simple:
For our example, we will protect the BillingCity and BillingStreet fields of the Account object in a PostgreSQL database.
The Masking Rule selection determines what value will be shown to a user when a user has insufficient privileges to view the field.
By default, CS:Govern picks an appropriate masking technique based on the Salesforce field type, However, you can override the default. Please read article to learn more about choosing an appropriate masking rule.
A CS:Govern protected field is assigned to one of more Compliance Categories and the assignment determines what the user can see when viewing unencrypted data.
The rule for field visibility is simple:
If a Field has compliance category “A” and a User has been configured to access category “A” then the user will see the data unmasked.
Note: If a field is not assigned a Compliance Category then no database users will be able to see the data unmasked.
Clicking on the Save & Protect button will tell CS:Govern to dynamically generate new database code to protect the fields you have specified.
Once a field has been protected, all changes to the field will be masked and the actual field value will be stored in a protected encrypted store.
You may be asking “What happens to unprotected data already in CopyStorm?” This question is answered in a later step.
When CS:Govern protection is applied to a field then all future changes to the field will be masked — IMMEDIATELY.
Suppose Account.BillingCity was just added to CS:Govern AND your database already has 2 million email records. Here is how the existing data is masked while ongoing Account.BillingCity changes are also automatically masked.
When CS:Govern protection is added to a table already containing data, a CS:Govern Custodian is created to mask existing data.
A Custodian will patiently walk thru all existing data and mask it only if it has not already been masked.
Custodians recover from various failures and can be resumed. By default, a Custodian works until the job is done.
There are two ways to run a Custodian:
A Custodian can be started by hand from the Custodians tab. This is what is illustrated below.
A Custodian Job Runner can be run as a regularly scheduled task and it will automatically run available Custodians (this is the preferred approach for production).
Select and run the Custodian which was automatically created when the fields were protected.
Look at the database again and see that each CS:Govern field is masked.
Note: Applying the default masking rules is a technique the maintains compatibility with Salesforce so the masked data can be used to populate a sandbox. Although there may be other masking rules to choose from, not all of them will be acceptable when attempting to restore those masked values into a Salesforce org. For analytics purposes, using non-default masking rules may be more appropriate.
By default, adding CS:Govern protection to a field hides the data from EVERYONE. To grant access to selected database users/roles see the tutorial.
Admin Log Tab
Admin Log
The Admin Log is used to record administrative tasks performed with CS:Govern along with details necessary to reconstruct a task. At minimum the following tasks are recorded.
Task
Description
Rotate Encryption Keys
Generate and install new encryption keys. All subsequently encrypted data will use this key.
Admin Log records are listed in a simple table with the following columns:
Column
Description
Oracle Permissions
Ensure that CopyStorm is connected to an Oracle database. If this is the initial setup, follow the recommended best practices for configuring .
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:
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:
Permission Required
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.
Date To Null
DateTime
DateTime To Null
Double
Numeric To Null
Email
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
The name of the host computer in use when the action was performed.
Host Address
The IP address of the host computer running CS:Govern.
Created (UTC)
The timestamp when the action was performed.
Details
Details about exactly what was changed in the database.
Add Field
Add a new field to those to protect with CS:Govern.
Create Encrypt Table
Create the CS:Govern database table that holds encrypted data for a corresponding Salesforce table.
Protect
Generate and install CS:Govern protection code on a table.
Add User
Add a new access rule for a database user or role.
Modify User
Modify the rules for an already defined CS:Govern user record.
Delete User
Delete a user/role from CS:Govern.
Delete Field
Delete a Salesforce field from CS:Govern protection. Note that the code which protects the field will not be updated until a corresponding Protect task is executed.
Id
Internal unique id for a log record.
Action
The task type of the log record. See the list at the top of this page for all actions.
Object
The Admin Log GUI
The database object affected by the action. The type is dependent on the action and may be a Field Name, a Database Table, A User Name, etc. The type value is generally obvious from the action.
Why It’s Needed
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
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.
PRIVILEGE
CREATE TABLE
CREATE PROCEDURE
CREATE TRIGGER
CREATE INDEX
EXECUTE ANY PROCEDURE
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.
GRANTEE
TABLE_NAME
PRIVILEGE
MY_USER
DBMS_CRYPTO
EXECUTE
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.
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'
);
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'DBMS_CRYPTO'
AND PRIVILEGE = 'EXECUTE'
AND GRANTEE = USER;
SELECT *
FROM SESSION_PRIVS
WHERE PRIVILEGE = 'SELECT ANY DICTIONARY';
Check If The User Has Essential Database Level Privileges
Expected Output
Check If the User Has EXECUTE Permission On DBMS_CRYPTO
Expected Output
Check If The User Can View Roles
Expected Output
Allows creation of indexes to improve performance on Govern metadata queries.
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
How Does CS:Govern Work?
How Does CS:Govern Work?
Conceptually, CS:Govern’s implementation of Transparent Data Encryption (TDE) is simple:
CS:Govern dynamically generates database code to enforce and implement TDE based on protection rules provided by a CS:Govern administrative user.
CS:Govern generated database code is applied as database triggers to prevent bad-actors from bypassing TDE rules.
Though conceptually simple, the details of CS:Govern’s internals are anything but simple. This article is intended to help a technical person understand the high level aspects of CS:Govern without delving into internal complexities.
An important point to be made is that, throughout a field value’s lifecycle, AT NO POINT is that value stored in a CopyStorm table in an unencrypted state. If the CS:Govern field rules include that field, it’s value will NEVER be exposed in human readable form in the database. This includes insert and update of field values, as well as the execution of CS:Govern Custodians.
CS:Govern started out as a white board discussion whose initial scope was proposed as a one-page diagram — CS:Govern on a Napkin. The following “napkin drawing” is a copy of the original and still accurately represents CS:Govern’s purpose and design.
Since CS:Govern generates database protection code based on user defined rules, a big part of the CS:Govern is the protection rule configuration system.
CS:Govern contains the following rule configuration components:
Protection Component
Description
The following ERD shows the primary CS:Govern tables used to define data protection rules. It is important to note:
None of these tables need to be accessible by regular database users.
The actual implementation varies slightly be target database type.
The key tables and their purpose are listed in the following table:
Key Table
Description
Though the technique for encrypted data storage varies slightly for each CS:Govern database type, the general approach is outlined in this section.
When CS:Govern is first configured to protect fields on a CopyStorm table several operations happen.
A table is created with a name in the format guardTableName. The purpose of this table is to store encrypted data and it is not accessible to normal database users.
Example: If Contact fields are to be protected, then a table named guardContact will be created in the target database.
Triggers are installed on the original CopyStorm table. These triggers intercept table insert/update/delete operations to enforce TDE.
When CS:Govern rules are updated, the process is similar except that existing encryption related database elements are updated rather than created.
The table used to hold encrypted data has a fairly simple format illustrated by this example for a Contact table (from a SQL/Server implementation)
Field
Description
Note that each protected field is associated with its own encryption key Id. CS:Govern records which key was used to encrypt the field’s value at the time that the encryption occurred. This implies that key Id’s may not be the same across all fields of a record, depending upon the sequence of events of the lifecycle of that record. In a typical scenario in which encryption keys are never rotated, then those key Id’s willbe the same in each record and every field.
When a field is under CS:Govern protection, the original CopyStorm field stores a masked value while the original field is stored in a encryption table. This section explains how to retrieve unencrypted data.
When a CS:Govern table contains protected fields, a generally accessible function named guard<>_GET.
Example: If the Contact table contains protected fields, then a function name guardContact_GET() is created and given public access.
Each generated _GET function has the form:
String guardContact_GET( Id String, fieldName String, defaultValue String )
where:
Id = unique Id of a Salesforce record in the Contact table.
fieldName = name of a Contact field protected by CS:Govern (case insensitive).
defaultValue = value to return if the caller does not have permission to read the field decrypted (or if the field is not under CS:Govern protection).
Example: To read a decrypted Contact.Email address SQL code like the following is required:
SELECT Id, guardContact_GET( Id, ‘Email’, email) as email FROM Contact WHERE …
A decryption function works by first determining if the caller has permission to read decrypted values by computing the intersection of the compliance categories of the user with the compliance categories of the associated field. If the result is not empty then the user has permission to see the field descrypted.
If the current user has permission to read decrypted data and the field is encrypted then the function simply decrypts the stored data and returns it. If the user does not have permission, then the default value is returned.
Does this sound simple? High level descriptions are deceptive since this process is the hardest part of CS:Govern to do in an efficient and accurate manner.
When CS:Govern rules change, long running changes to the CopyStorm database can be required. Custodians are lightweight processes designed for long running tasks which will run safely in parallel with CS:Govern protection. There are three types of Custodians:
**EncryptFields:**as the name suggests this Custodian will apply masking rules to the selected fields for all records in the field’s database table. It will also enter encrypted values into the associated guardTableName table (known as the “storage” table.) This action is not performed on field values that have already been encrypted.
**DecryptFields:**this Custodian performs the inverse operation of the EncryptFields Custodian in the sense that it will decrypt the selected fields and restore the decrypted field values back into the CopyStorm database. Field values in the guardTableName table are nulled.
**RemaskFields:**this Custodian, as the name suggests, will change the mask value in the CopyStorm database table for the selected fields and for all records in that table.
Example: Suppose the field Contact.Email has been added to CS:Govern AND there are already one million unencrypted Contact.Email records. In this case:
CS:Govern will install database code which will protect all future updates to Contact.Email records.
CS:Govern will create a Custodian whose job is protect existing Contact.Email records.
Though Custodians run outside of the database, their activity is logged in CS:Govern tables.
The primary purpose for the Custodian tables is to report on the current progress and history of custodian tasks.
Note that the recommended way to run Custodians is via the Custodian Runner command line tool.
A CS:Govern Custodian is created to encrypt existing data in the CopyStorm table.
Access Category
An Access Category is a classification that can be applied to a field and is also known as a Compliance Category. Example Access Categories include: PII, HIPAA, etc. In short, an Access Category determines the type of access security to apply to a field. Though CS:Govern includes a variety of built-in access categories, a customer may add any number of additional categories.
Masking Rule
A Masking Rule is a rule for transforming original field data into a masked value which will be shown to database users without privileges to see the original data. Though CS:Govern provides a rich set of masking rules, it is possible to add additional rules.
Field Registry
GuardianField
This table contains a record for each field which is protected by CS:Govern. The companion linking table, GuardianFieldAccessCategory, assigns access categories to a field. It is the intersection of a field’s access categories with the user’s access categories that determines if a user can see the unencrypted value in a field.
GuardianUser
This table contains a record for each user and database role which has rights to access field data protected by CS:Govern . The companion linking table, GuardianUserAccessTable, assigns the permitted access categories for a user or role.
GuardianTable
CREATE TABLE [dbo].[guardContact](
[id] [char](18) NOT NULL,
[keyId] [int] NOT NULL,
[Name] [varbinary](max) NULL,
[keyId1] [int] NOT NULL,
[Email] [varbinary](max) NULL,
[keyId2] [int] NOT NULL,
[FirstName] [varbinary](max) NULL,
[keyId3] [int] NOT NULL,
[LastName] [varbinary](max) NULL,
[keyId4] [int] NOT NULL
PRIMARY KEY CLUSTERED
(
[id] ASC
))
id
Salesforce Id for the corresponding record in the CopyStorm Contact table.
keyId
Id of the CS:Govern keys used to encrypt the record. Note that this column has been deprecated but remains in the schema for backward compatibility purposes.
Name
CS:Govern on a Napkin
CS:Govern Protection Rules
Protection Rules ERD
Encrypted Data Storage
Unencrypted Data Access and Masking
Custodians — Processes to Clean Up Data
The Field Registry associates Access Categories and a Masking Rule with Salesforce fields. When CS:Govern generates database code to protect a field, this is the primary registry it queries.
Example:
Add the Contact.Email field, set its Access Category to PII, and mask it with the built in email masking rule.
Table Rule Registry
The Table Rule Registry is used to track table level database components generated by CS:Govern for a table.
Key Registry
The Key Registry is CS:Govern’s built-in storage for encryption keys. It is the ONLY CS:Govern component where access should be highly restricted. In practice, no one but the CS:Govern administrator account needs access to this registry,
Custodian Registry
The Custodian Registry contains a history of CS:Govern Custodian tasks launched on the database.
This table is used to keep track for CS:Govern generated database code for a CopyStorm table.
storageTableName — the name of the database used to store encrypted data for a corresponding CopyStorm table.
insertTriggerName — the name of the database trigger implementing TDE on database inserts on a CopyStorm table.
decryptFunctionName — the name of a function which will decrypt data based on the rights of the current database user. Note: This is the ONLY function which needs general execution access.
GuardianKey
The GuardianKey table is the default storage location for the keys used to encrypt/decrypt data. It is also the ONLY table to which normal database users should be denied access. All CS:Govern generated database code gains access to this table via defined rights declared on the generated code.
Encrypted value of the Contact.Name field. If null, then the Contact.Name field is null or the Contact.Name field has not yet been encrypted.
keyId1
Id of the CS:Govern keys used to encrypt the Contact.Name field.
Email
See Name.
keyId2
Id of the CS:Govern keys used to encrypt the Contact.Email field.
FirstName
See Name.
keyId3
Id of the CS:Govern keys used to encrypt the Contact.FirstName field.
LastName
See Name.
keyId4
Id of the CS:Govern keys used to encrypt the Contact.LastName field.
