Data encryption at rest

<< Click to Display Table of Contents >>

Navigation:  Security and compliance > Data encryption >

Data encryption at rest


Compliance and privacy requirements make protecting data more critical than ever.

Bizagi PaaS implements encryption of data both at rest and in transit in order to provide a secure environment that complies to strict governance and security requirements regarding data privacy.


This document details how Bizagi PaaS 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, and 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 (i.e, in the event of physical files being stolen --preventing unauthorized users from being able to attach or restore such database files in another server).


Quick facts about the use of TDE in Bizagi PaaS are:

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 similarly 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) and the use of a 256-bit symmetric key.

There is no significant performance penalty (it is minimal and estimated at 3%).

No additional settings, query design considerations nor permissions are involved.



Note that additional security measures and controls are in place across the Bizagi PaaS service.

Bizagi PaaS along with its IaaS associate (Microsoft Azure), adheres to protecting the information in terms of implementing high-security physical, technological and administrative safeguards which are not detailed in this document.

This document refers specifically to the 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 set of images illustrate how data is encrypted by relying on TDE.


Assuming these rows were given in a table:





How is data stored at the page level without TDE in place, would be reflected somewhat like this (back from an ASCII representation, viewed while using a hex-editor):




On the other hand, implementing TDE would yield a similar 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 where a certificate is created in the master database and protected by the master key as well.

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 is followed throughout 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 it with the certificate.

4.TDE is enabled on the database.




Notice that the service master key that exists at the instance level and upon its setup, protects the further keys used in this hierarchy. 


Backing procedures and policies

The certificate employed to protect the database with TDE (the DEK), is rotated at least every 90 days.

Furthermore and for contingency procedures such as those related to DR, different keys are involved per different data centers and procedures are in place accordingly, to ensure that the adequate key and certificates are considered to render the database operational.