Protect Database Fields

The procedure for bringing a field under CS:Govern protection is fairly simple:

1. Choose the field(s) to protect.
2. Choose the masking technique for each field.
3. Choose one or more compliance categories for each field.
4. Tell CS:Govern to start protecting the fields.
5. If there is existing data in the fields then tell CS:Govern to encrypt the fields.  If necessary, use a Custodian to encrypt existing data.

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 this 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 Grant Access to Database Users tutorial.