Overview
In some business scenarios, it may be desirable to include additional security measures to protect information.
To do this, Bizagi provides functionality to encrypt information in the database (for specific attributes).
Examples of these scenarios are:
•When there is very sensitive data that must be hidden from unintended users, particularly if many users have authorized access to the database and its information.
•When you are integrating external data sources into your project (through Virtualization and Replication), and you wish to provide that extra security protection for the local information stored at Bizagi.
Encryption of information at the database is carried out by Bizagi through encryption algorithms configured by your project.
This section describes how to use this feature called Database encryption.
|
This feature is not eligible for Automation Service. The possibility to encrypt specific database table columns is not targeted for cloud environments given that these environments already implement full encryption for data at rest. |
How does it work?
To enable database encryption, you will need to specify a key (for example, a 32-character GUID) for the encryption algorithm.
This key is stored in a file on a physical path which has restricted access; only you will know the location of the file.
Bizagi will use the hashing algorithm of your choice to generate this key in bits for the encryption algorithm.
You will also need to specify which encryption algorithm to use.
The following image illustrates this feature's concept:
Supported hashing and encryption algorithms
Bizagi's Database encryption feature supports the following algorithms:
Hashing algorithms
•SHA1
•SHA2 256
|
Choose SHA2 256 for the highest security conversion. Choose SHA1 if you don’t want performance to be penalized by a more sophisticated conversion procedure. |
Symmetric Encryption algorithms
•DES
•Triple DES 1
•Triple DES 2
•AES (recommended), either using 128, 192 or 256 bits.
|
DES or Triple DES encryption algorithms (with keys less than 192 bits) are NOT recommended due to security risks. We recommend to using the AES algorithm using more than 192 bits. |
Important
Bizagi Ltd is not responsible for the key defined for this purpose. (Bizagi does not itself store the key; you will choose where to store it.)
The defined key is solely under your control and custody, and thus duly protected. Consequently, you alone are responsible for the storage, safekeeping and protection of the key, and for restricting access to it.
For this reason, you should have contingency plans or a backup in case the key is lost, as encrypted information is not recoverable in any circumstances by Bizagi without it.
What you need to do
To use the database encryption feature, you will need to perform the following:
1.Authorize those users who will be allowed to configure database encryption features
2.Set the encryption algorithm and its key
3.Configure what information should be encrypted
Procedure
Follow these steps to configure database encryption.
1. Authorize those users who will be allowed to configure database encryption
By default, users are not authorized to configure database encryption.
In order to utilize this feature, you will need to make sure that the business administrator user is explicitly authorized to configure the necessary parameters for encryption (such as the algorithm and, most importantly, the key used in the encryption).
To authorize users, first open your project through Bizagi Studio.
Once in your project, there are two different ways to grant a user access to this feature: by setting the user up as an administrator, or by specifically allowing a user to use database encryption.
First option: by setting the user up as an administrator
This option will enable the user to use the database encryption feature as well as delegate the privilege to other users.
To set up the user, carry out the following steps:
1.Navigate to Bizagi Studio Security module by locating the File tab and then Bizagi Studio Security.
2.Click on the Configure option.
3.Add the user to the Administrators group by clicking on the Add User button.
4.Make sure you tick the Include checkbox to specify that this user will have administrator privileges.
5.Click Close to apply the changes.
|
You may also choose to add a group to the Administrators group by following the same steps taken previously but using the Add Group button instead. |
Second option: by specifically allowing a user to use database encryption
This option will allow the user to configure database encryption options.
To set up the user, carry out the following steps:
1.In the Expert view, select the Entities module.
2.Right-click on the Entities main node and select the Security option:
3.Add the user by clicking on the Add user button.
Once added, make sure you set the privilege called Encrypt Data to Allow:
4.Click Close to apply the changes.
|
You may also choose to add a group to the Administrators group by following the same steps taken previously but using the Add Group button instead. |
2. Set the encryption algorithm and its key
Follow the steps below to configure the hashing and encryption algorithms, and the encryption key.
2.1 Define a key for the encryption algorithm to use and save it into a plain text file.
Make sure this file is saved in a network-available location with restricted access.
In our example below, the key has 32 characters as it was taken from an auto-generated GUID:
2.2 Enable database encryption in Bizagi.
To do this, open Bizagi Studio and select the Environment option located in the Configuration tab.
2.3 Select Advanced tab and then scroll down to Cryptography Options.
Keep in mind that these options will only be displayed to users explicitly authorized to configure this feature (as described in the first step).
CONFIGURATION PROPERTY |
DESCRIPTION |
|---|---|
Hashing algorithm |
Select the hashing algorithm used to convert the key into bits. Available algorithms are: SHA1, SHA2 256. Note that SHA2 will use 256 bits (as opposed to the 160 bits used by SHA1), thereby creating a more dispersed definition of the key (more secure). |
Encryption algorithm |
Select the encryption algorithm that will use the key you’ve set to encrypt information. Options are: •DES •Triple DES 1 •Triple DES 2 •AES (recommended) either using 128, 192 or 256 bits. |
Key File location (URL) |
Specify the location of your key file. Keep in mind that this has to be a URL accessible by the Bizagi Server. You may specify the URL as per the options or examples below: •A local path of the Bizagi Server. •A location on a file server (e.g, file://[your_file_server]/KeyFiles/KeyFile.txt) •An HTTP or HTTPS URL (e.g, https://[HTTP_Server]/SslText/KeyFile.txt) |
Set authentication properties |
To specify valid credentials to access the key file, tick this checkbox. If this option is left unmarked, Bizagi will use: •For the configuration: the logged credentials of the Bizagi Studio user. •During runtime: the credentials used by the Bizagi Server (i.e, in IIS, the identity defined for the application pool). |
User name |
Enter the username of the user authorized to access the key file (applies when the set authentication properties is marked). |
Password |
Enter the password of the user authorized to access the key file (applies when the set authentication properties is marked). |
Domain |
Enter the domain of the user authorized to access the key file (applies when the set authentication properties is marked). |
2.4 Click OK to apply the changes.
3. Configure what information should be encrypted
Once you have set the encryption algorithm and its key, you may mark which attributes you want to set as encrypted information.
Do this, when defining each attribute, by ticking the Encrypted checkbox:
|
Bear in mind that the encryption of attributes can only be performed to parametric and master entities. |
Example
In order to explain how to set or add an encrypted attribute, the process we created earlier, My First Process (Vacation Request Process), will be used to illustrate this step.
We will assume that the number of days available will be an attribute that can only be viewed through the work portal. This then will be the business condition that makes it necessary to set Availabledays as an encrypted attribute.
Any user with a user name and password that can access the database is able to see the table where the vacation requests are stored (remember that the entities created in the Model Data step of the Wizard will create a table in the database configured for Bizagi Studio).
Without setting any attributes as encrypted, any user with the correct credentials would be able to see all the information clearly:
This is an undesirable situation because NumberOfDaysAvailable will be an attribute that must only be viewable through the work portal. As it stands, the attribute can be queried by any SQL Editor that has a connection to the database.
In order to resolve the situation, we will define the attribute NumberOfDaysAvailable as encrypted. To do this:
1. Go to Step 2 of the Wizard called Model Data.
2.Right-click on the entity where the encrypted attribute will be set or added, and select the option Edit Attribute List.
3.The Attributes List for the entity will be displayed. Select the required attribute to be set as encrypted.
4.Tick the Encrypted option. This will hide the attribute’s Default Value property, and Localizable property where pertinent.
5.Click Finish to save and apply the changes.
6.Save the Data Model.
|
When adding attributes to the list, the option to encrypt them will be allowed only when the individual types selected are available to be encrypted. |
At this point, Bizagi will have altered the corresponding database table in order to encrypt the field selected in the previous steps. In the database the table structure looks like this now:
The attribute NumberOfDaysAvailable was an int type before the Encryption process and now it is an image type. Most importantly, the data is not visible to the user logged in.
|
The example above was created using a SQL Server Database; the data type in an Oracle database would be BLOB. |
When the Work Portal is launched, the data previously encrypted will be decrypted before presentation to the user as you can see in the next image. In this way, we have resolved the potentially negative situation raised by the business condition:
Important considerations
Take into account the following considerations when using this feature.
1.Applies for business entities
Note that database encryption is available for attributes of Master or Parameter entities.
This means that you may not encrypt user properties of the WFUser entity, or any attributes of System or Application entities.
2.Not all types of attributes can be encrypted
Supported data types of attributes for database encryption are:
•Tiny integer (8 bits)
•Small integer (16 bits)
•Integer (32 bits)
•Big integer (64 bits)
•Real (4 bytes)
•Float (8 bytes)
•Currency (16 bytes)
•String
•Extended Text
•Long Text
•Date Time
|
Other attributes such as files or images, are already by default not readable through the database. |
3.Encrypted attributes for end users
When using database encryption for attributes of your data model, consider the following:
•They are supported in Bizagi queries when they are used as part of the results. Not supported as filters.
•They are supported in Search controls when they are used as part of the results. Not supported as filters.
•They are supported for Customized Columns
•They are shown decrypted when getting data using Bizagi API methods
•They are stored encrypted when saving data using Bizagi API methods
•They are supported in Email and Document templates
|
Database encryption does affect performance when used in Combo-boxes that display information bound to external data sources. Therefore, carefully consider and evaluate your UI design and use of this feature when needed. |
4.Non-reversible feature
Once that an attribute using the database encryption feature has been deployed to a Production Environment, it will be not possible to reverse the use of this feature.
This means that you may not activate this feature for an attribute which is already working in a production environment without it, nor deactivate it for an attribute which has this feature active and working in a production environment.
In case you need to either start or stop using this feature, you will need to create new process versions and make sure that your process data model uses a new different attribute.