Before using Data Masking or Data Encryption with your database, read the information on the DATAMASK and DATAENCRYPT data set physical options in the ClearPath Enterprise Servers Enterprise Database Server for ClearPath MCP Data and Structure Definition Language (DASDL) Programming Reference Manual.
Before using Data Encryption with your database, read the information on database encryption and the Security Center in these manuals:
ClearPath Enterprise Servers Enterprise Database Server for ClearPath MCP Utilities Operations Guide, ‘Section 23, Database Encryption’
ClearPath Enterprise Servers MCP Security Overview and Implementation Guide, ‘Section 7, Introduction to Security Center’
Data Encryption is an optional, separately priced product for DMSII databases. It is not possible to use the Data Encryption feature in AB Suite without having purchased and installed the Data Encryption product first. Attempting to do so will result in syntax errors at build time. Use the Build Preview feature to verify that there are no issues with database changes before going ahead with the actual system build. |
CautionNote: Data Encryption with AB Suite requires DMSII IC DMSII-059.1A.3 or higher.
It is possible to secure the data in a DMSII database by one of the following techniques:
DataMasking
DataEncryption
Although it is possible to use data masking and data encryption in the same database, DMSII does not allow the use of data masking and data encryption in the same data set. Only one form of data security might be used in a data set.
To support the use of data masking and data encryption of data in the database, AB Suite provides two model properties:
SecureTechnique: class model property
IsSecure: attribute model property
SecureTechnique is used to specify whether the secured persistent attributes in the class will be encrypted or masked.
The valid values for SecureTechnique are:
None (default value)
Data Masking
Data Encryption
IsSecure is used to specify whether the attribute will be secured. If you would like an attribute within a class to be secured, set the IsSecure property on the attribute to True.
Persistent attributes will be secured according the SecureTechnique setting on the owning class. (MCP applications only.)
AB Suite allows these primitive types to be secured:
String
Number
Signed Number
Date
Boolean
The valid values for IsSecure are:
False (default value)
True
Restrictions:
Data masking and data encryption at the class level is not supported in this release. A means by which AB Suite can apply data masking or data encryption to an entire class will be considered for a future AB Suite release.
AB Suite does not support data masking or data encryption on persistent attributes for these conditions:
The persistent attribute is used in a profile as key data, or in the conditions for a profile.
The StoreIfPresent property is set to True.
The persistent attribute is a National String.
AB Suite does not support data masking on persistent attributes for this condition:
The IsKey property is set to True.
The attribute is used as a key in a profile.
The attribute is a Boolean or a number whose length is 1.
AB Suite does not support data encryption on persistent attributes for this condition:
The IsKey property is set to True, the attribute is numeric (number, signed number, date, Boolean) and the attribute’s length is uneven (not divisible by 2).
Data encryption for the whole database by setting DataEncrypt in the default data set physical options in the DASDL is not supported.
Note: Data masking and data encryption will not be effective unless the appropriate configuration properties have been set up in the configuration from which AB Suite MCP TargetBuilder builds your application.
Using Data Masking to Secure Persistent Attributes
To secure the data of a persistent attribute in the database with data masking:
Set the SecureTechnique property on the class owning the persistent attribute to DataMasking
Set the IsSecure property on the attribute to True
These settings will not take effect until the Obfuscate Level configuration property is set to a value greater than 0 in the configuration that will be used to build the system. The masking of data in the database occurs when the SecureTechnique property is set to DataMasking, the IsSecure property is set to True and the Obfuscate Level configuration property is 1, 2, or 3.
The Obfuscate Level option instructs DMSII to select the methodology of masking the data content. The valid values of the Obfuscate Level MCP configuration property are 0, 1, 2, or 3. A value of 0 indicates that masking is not required in the database.
The following table describes the level of masking.
| Obfuscate Level | Description |
|---|---|
| 0 | This level suppresses data masking. The OBFUSCATELEVEL option is not generated in DASDL, and DATAMASK is not generated for any persistent attribute. This is the default value. |
1 | This level specifies that the entire database uses the same methodology of masking data. |
2 | This level specifies that each structure in the database uses a different method to scramble data. |
3 | This level specifies that each record of a structure uses its own methodology to scramble data. Note: An Obfuscate Level 3 is only allowed on structures in which the Extended Edition property is set to True. You have to ensure that the Extended Edition property is set to True on all data sets (<<ispec>>, <<copyispec>>, <<event>>, Classes with no stereotypes, and <<copyevent>> classes and with persistent attributes). |
Restrictions
DMSII requires that the Extended Edition property be set to True on all data sets when OBFUSCATELEVEL is 3. With respect to AB Suite, you must ensure that the Extended Edition configuration property is set to True on all Classes with no stereotype, and Classes with stereotype, <<ispec>>, <<copyispec>>, <<event>> and <<copyevent>> it these classes have persistent attributes when Obfuscate Level is 3.
When using MCP Runtime Transfer, you must set Obfuscate Level to the same value for the source configuration and target configuration. RTU enforces this rule when the Obfuscate Level is 0 or 3.
Refer to the Enterprise Database Server for ClearPath MCP Data and Structure Definition Language (DASDL) Programming Reference Manual for more information on OBFUSCATELEVEL and DATAMASK
Using Data Encryption to Secure Persistent Attributes
To secure the data of a persistent attribute in the database with data masking:
Set the SecureTechnique property on the class owning the persistent attribute to DataEncryption
Set the IsSecure property on the attribute to True
These settings will not take effect until the Data Encryption Type configuration property is set to one of the encryption algorithms in the configuration that will be used to build the system. The encryption of data in the database occurs when the SecureTechnique property is set to DataEncryption, the IsSecure property is set to True and the Data Encryption Type configuration property is AESGCM or AESHMAC.
The Data Encryption Type option instructs DMSII to select the algorithm to use when encrypting the data content. The valid values of the Data Encryption Type MCP configuration property are None, AESGCM or AESHMAC. A value of None indicates that encryption is not required in the database.
Encryption Key Set Maintenance
While using data encryption in your database, it necessary to have an encryption key set for the database. As soon as an encryption algorithm is specified using the Data Encryption Type segment configuration property, the Data Encryption Key Set segment configuration property will be enabled and set to UseExisting. An encryption key set will be created for the database during the next system build. You are responsible for backing up the key set manually using the Security Center (Refer to ClearPath Enterprise Servers Enterprise Database Server for ClearPath MCP Data and Structure Definition Language (DASDL) Programming Reference Manual for more information).
For security purposes, you can change the existing key set by setting Data Encryption Key Set to NEWKEYSET or REPLACEKEYSETS before the next system build.
NEWKEYSET – generates completely new FLE keys and a new RSA Master Key. (Requires a database reorganization.)
REPLACEKEYS – generates a new RSA Master key and re-encrypt all of the existing FLE keys. (Requires a control file update.)
Perform the following after changing the value of Data Encryption Key Set to one of the above values:
Perform a system build.
Take a backup of the keyset when prompted by the build.
After the build, change the value of Data Encryption Key Set property to UseExisting before the next build.
Once the key set has been changed, it can no longer be used to decrypt an old database backup. Therefore, you must take a full database backup after the key set has been changed. |
Refer to ClearPath Enterprise Servers Enterprise Database Server for ClearPath MCP Data and Structure Definition Language (DASDL) Programming Reference Manual for information on these options.
Notes:
The APPL_BLD server will prompt the user to back up the Key Set when the Data Encryption Key Set is set to UseExisting and the database is being created as new or there is a database reorganization.
The APPL_BLD server will prompt the user to back up the Key Set when the Data Encryption Key Set is set to NEWKEYSET or REPLACEKEYS. The user might override the configuration setting and change to confirm the action requested. It will be necessary to set Data Encryption Key Set back to ‘UseExisting’ in Developer to suppress the prompts from the APPL_BLD server.
The First Build after Creating an Encryption Key Set
After an Encryption Key Set has been created or updated, it is necessary to do a backup of the keys before the database is accessed. There are a number of programs in the deployment phase that need to access the database after the DASDL compile has taken place. If a new database is being created, the deployment job will prompt the user to do a backup of the Encryption Key Set after the DASDL compile, and before proceeding with the programs that access the database. If there is a database change, the deployment job will issue a message that recommends the database keys be backed up. If the Encryption Key Set is not backed up immediately after the keys have been created or replaced, the deployment will wait on the first program wanting to access the database. Refer to the Security Center Help for information on backing up the Encryption Key Set.
Refer to the Enterprise Database Server for ClearPath MCP Data and Structure Definition Language (DASDL) Programming Reference Manual for more information on DATAENCRYPTTYPE, DATAENCRYPTKEYSET and DATAENCRYPT.
Location of the Encrypted Data Items in the DMS file
For performance reasons, DMSII puts encrypted data items together at the end of the record, after the non-encrypted items and before the DBFILLER, if one is present. AB Suite has followed this order so that it can support the DMSII Data Encryption feature.
If you use the Data Encryption feature with any of the persistent attributes in your application, you will see the attributes ordered in the DMS file using the following sequence:
Non-encrypted alpha items
Non-encrypted numeric items
Non-encrypted DB Filler items, in the order as they were added after the DB Filler was set up
DB Filler
Encrypted numeric items
Encrypted alpha items
Restrictions and Recommendations
When using MCP Runtime Transfer, it is mandatory to keep the Data Encryption Type setting the same for the source configuration and target configuration. RTU enforces this.
Do not mix deployment types on the production system. Do not use Runtime Transfer to deploy the production system one time then use Developer build to deploy the production system (or vice versa). Due to the nature of the MCP Runtime Transfer, the target database uses the same keyset as the source database, not its own keyset. Mixing deployment types could jeopardize the ability to recover the data in the database.