Overview
Compliance and privacy requirements make protecting data more critical than ever.
Bizagi Cloud Platform implements encryption of data both at rest and in transit to provide a secure environment that complies with strict governance and security requirements regarding data privacy.
This section details how Bizagi Cloud Platform treats encryption of data at rest in particular.
TDE technology
For data at rest, Bizagi relies on the TDE technology.
TDE stands for Transparent Data Encryption. It is a technology that enhances security at the underlying database service.
This implemented measure prevents reading of data from the physical media by potential attackers (For example if physical files being stolen unauthorized users could not attach or restore your database files in another server).
Quick facts about the use of TDE in Bizagi Cloud Platform:
•With TDE, real-time I/O encryption and decryption at the page level is carried out.
Pages are encrypted before writing them to disk and decrypted back when reading them data into memory.
•All physical files (.mdf data files, .ldf log files, or .bak backup files) are encrypted this way.
•The use of highly secure algorithms is employed (AES which stands for Advanced Encryption Standard) along with a 256-bit symmetric key.
•There is no significant performance penalty (it is minimal and estimated at 3%).
•No additional settings, query design considerations or permissions are involved.
|
Additional security measures and controls are in place across Bizagi Cloud Platform. Bizagi Cloud Platform along with its IaaS associate (Microsoft Azure), adheres to protecting information in terms of implementing high-security physical, technological and administrative safeguards which are not detailed in this document. This section refers specifically to security feature related to data encryption which is relevant assuming that an intruder gets past the perimeter and network security protocols. |
TDE through images
The following images illustrate how data is encrypted with TDE.
Assuming these rows are given in a table:
How data is stored at the page level without TDE in place, would be somewhat like this (an ASCII representation, viewed while using a hex-editor):
Implementing TDE yields a representation such as this one:
Implementation in detail
In a TDE-protected database, a symmetric Database Encryption Key (DEK) is stored in the database's boot record.
To secure the DEK, a mechanism is employed using both a certificate in the master database and the master key.
This approach creates a key hierarchy that prevents database files from being accessed on a different database instance that does not contain the certificate.
The process of using TDE to encrypt a database follows these steps from a SQL Server database perspective:
1.A master key is created.
2.The certificate is set up.
3.The DEK is created.
This DEK is protected with the certificate.
4.TDE is enabled on the database.
The service master key exists at the instance level. Upon its setup, it protects further keys used in this hierarchy.
Backup procedures and policies
The certificate employed to protect the database with TDE (the DEK), is rotated at least once every 90 days.
Furthermore and for contingency procedures such as those related to DR, different keys are involved for different data centers and procedures are in place, to make sure that the adequate key and certificates are available to render the database operational.
Last Updated 8/2/2023 10:09:12 AM