Best Practices
Naming convention
It is recommended to keep the names of rules short but descriptive. Using the description field of a rules is highly recommended for the benefit of whomever might be maintaining it in the future. Rule names may appear in logs therefore keeping choosing an appropriate name would make it easier to find in the Ruleset tree.
Keeping the same host names, addresses and data element names across environment where possible will make it environment agnostic. Keeping the environments configuration in sync is common for testing and diagnosing. This can be done by backing up, export and restore the configuration of one environment to another. The minimum changes needed to be made after import and restore, the better.
Learn mode
Learn mode is useful for studying the payload of an application for creating the appropriate data protection transformation rules, diagnosing a problem, or analyzing performance. It however impacts performance due to the disk IO involved in the process. It also occupies disk space that otherwise would not have been used. Some regulations may require certain handling of such log information in a production system which DSG may not comply with and therefore it is highly recommended to keep Learn mode disabled for the services used in a production system.
Note: The rules displayed in the Learn mode screen and the payload message difference are stored in a separate file in DSG. The default file size limit for this file is 3MB. If the payloads and rules in your configuration are high in volume, you can configure this file size.
In the ESA CLI Manager, navigate to Administration > OS Console. Edit the webuiConfig.json file in the /opt/protegrity/alliance/config/webinterface
directory to add the Learn mode file size parameter as follows:
{
"learnMode": {
"MAX_WORKER_THREADS": 5,
"LEARNMODE_FLOW_DUMP_FILESIZE": 10
}
}
Using prefix and suffix
The optional use of prefix and suffix to “mark” protected data makes the Ruleset more generic, optimized, and resilient for potential modifications. This is since the unprotection set of rules is targeting a payload type rather than a specific message. This means that the rule will be useful for any new message which the application may be extended to so long that it uses the same payload type the system is configured to manage.
To make the use of prefix and suffix efficient, apply the data protection on a word-by-word bases rather than a complete sentence. The reason behind this recommendation is that application may use spaces to break down sentences to words and index each word separately. Using prefix and suffix on each word individually will maintain its value should the application do so in the backend.
By using different sequence for different class, prefix and suffix may also be used to distinguish between different types of protected data classification.
Profile reference
Profile references can be used to point at a specific profile as if the rules in the profile existed in place of the reference. A single copy of repeatedly used rules hierarchy can then be maintained and referenced from other profiles.
For example, creating a generic rule to protect an SSN in a certain way might be useful in more than one place. It is recommended to create a separate profile and reference it from where it is needed. That way should protection of SSN ever change in the future, adjustment will be required in one place only.
Note that references can be made across services. One may choose to create a service which is not associated with any tunnel (dormant) and use it as a container for profiles referenced from other services.
Modifying out-of-the-box profiles and rules
DSG does not block users from updating any of the rules provided out-of-the-box. Customers are however encouraged to avoid such changes in profiles used in production environment. Updates that Protegrity may release for these out-of-the-box profiles may conflict with customer modification. Customer modifications in this case may be overwritten. It is recommended to make a copy of the profile and disable the out-of-the-box profile/branch as a mean to avoid such conflict.
Defining services
Services are fundamental containers that further define the rules used for data security operations. When designing DSG implementations, you must ensure that only one service type per protocol-hostname combination is created. You can further divide all applicable rules under this service in form of profiles.
If you create multiple services per protocol-hostname combination, DSG might never process the rules under the second service.
For example, consider a situation where you want certain payload, such as text, to use tokenization data elements as the chosen form of data security, and other payload, such as CSV, to use encryption data elements. You create Service A to use the tokenization elements, while Service B to use the encryption data elements. In the given scenario, if both services are enabled, DSG will execute the first service, Service A.
To avoid this situation, the correct approach would be creating a Profile A that includes subsequent rules to use tokenization data elements, and Profile B that includes rules to use encryption data elements.
Caution: It is recommended that when creating Rulesets for Dynamic CoP, the Profile Reference rule is used for data transformation instead of the Transform rule. The security benefits of using Profile Reference rule are higher than the Transform rule since the requests can be triggered out of the secure network perimeter of an organization.
Default certificates and keys
The DSG generates default admin certificates and keys that are required for internal communication between DSG nodes and ESA.
If any certificates or keys in the DSG expire, then you must note the following points before regenerating them.
It is recommended that you do not use any default certificates in production environments. Ensure that you use custom admin certificates and keys and upload them to the DSG using the ESA Web UI.
For any other non-production environments, if you have used default admin certificates and keys, you must generate them from any machine other than the DSG.
The admin tunnel, which is used by DSG for internal communication between appliances (ESA and DSG), requires the
.pem
files. Ensure that for default DSG certificates, the.pem
files are also generated along with the.crt
and.key
files.
Note: Ensure that the common name is set to
protegrityClient
in the openssl command to generate the default certificates.
Ensure that after you generate the default certificates and keys, they are renamed as defined in the gateway.json file. You can access the gateway.json file from the ESA Web UI, by navigating to Settings > System. The following image highlights the names of the certificates, keys, and commonName settings in the gateway.json file.
If you have used custom certificates for the admin certificates and keys, then you must ensure that the common name that was used to generate the
.csr
file is set in the gateway.json file.You must edit the gateway.json file to change the commonName parameter as required.
Migration of Data Tokenized by DSG
If you want to migrate any data tokenized in DSG, then following point must be considered. The DSG only generates UTF-8 encoded tokens. If the tokens generated by DSG need to be used in other ecosystems that are configured for an encoding other than UTF-8, a translation is required to the encoding of the target ecosystem.