By Rajkumar Raghuwanshi, Senior Software Engineer - PLSQL, EDB, and Tushar Ahuja, Senior QA Manager, EDB.
EnterpriseDB provides a high level of database security, which includes in-database password policy management, enhanced auditing for compliance, data encryption, built-in SQL Injection Protection and so on. Along with Vormetric Data Security Platform, it provides encryption for data-at-rest, prevention of privilege user access, policy-driven encryption/decryption and much more at the operating system level. VTE ensures that it does not impact the mission-critical business applications, IT infrastructure and service level agreements.
Fundamentals of VTE
Vormetric Transparent Encryption (VTE) of Thales security is a transparent block-level encryption with access controls to provide data security. It is simple to deploy and manage. It consists of two main components:
- Vormetric Transparent Encryption (VTE) – Transparent block-level encryption with access controls.
- Vormetric Data Security Manager (DSM) – Central key and policy manager for all Vormetric solutions.
Set up for POC
As part of POC for VTE over EnterpriseDB Advanced Server the following set up is created:
1. Vormetric Data Security Manager (DSM) environment with EnterpriseDB host machine with a VTE registered agent
2. Encryption/decryption key created with algorithm AES256 and automatic key rotation with 180 days
3. Policy created with policy type as Live Data Transformation (which only allows the user enterprisedb to access the data/base directory and denies access to all the other users including system root).
Figure 1 shows how a policy looks on a DSM console.
Figure 1: Policy on a DSM console
VTE file-level encryption
VTE enables file-level encryption using policies to prevent privileged user access. We tested that this does not impact any functionality provided by EDB Advanced Server. With the above setup, it was observed that when the privilege root user tried to access the data/base directory it got permission denied error. Even when the root user did a switch user (su) to enterprisedb the same error is being thrown. When the user enterprisedb (which is authorized) logged in to the system it is able to access the directory. This is depicted in Figure 2.
Figure 2: Access to the data directory
Figure 3: VTE Logs
This security level is verified at a granular level when only the access to the process edb-postgres for the user enterprisedb is allowed. EDB Postgres Advanced Server functions in the same way with and without VTE. Verification is done by running pg_regress suite, streaming replications (master-replica configuration), and other EnterpriseDB utilities which uses file systems like pg_dump, pg_restore, pg_upgrade and so on.
Performance Impact
As VTE agent interacts with the DSM server for policy validations before allowing a user or a process to access the file system this results in some performance overhead. We have done some performance benchmarking using direct loads using EDB*Loader and COPY utilities and transactions using the pgbench tool. This overhead is in the acceptable range of 0-20%.
Graphical Representation of Performance Impact
The following graphs show the performance impact of VTE with EnterpriseDB Advanced Server.
Table 1: Host Specifications with VTE
|
Specification |
Description |
|
Operating System |
Centos 7x64 |
|
CPUs |
4 |
|
RAM |
8GB |
|
HDD |
320 GB |
|
Database |
EnterpriseDB Advanced Server v11 with VTE agent Installed
|
|
Policy type |
Live Data Transformation |
|
Encryption |
Algorithm - AES256 |
|
User |
Only enterprisedb user allowed |
|
Guard |
/var/lib/edb/as11/database/ with policy |
Figure 4: Impact of VTE with EDB*Loader and COPY
Figure 5: Impact of VTE with PGBENCH