System Requirements

CipherTrust Transparent Encryption - Live Data Transformation (LDT) requires the following environment.

Note

See the latest Compatibility Matrix for CTE Agent for a list of CTE versions and supported operating systems.

CipherTrust Software Requirements

• CTE Agent version 7.0.0 or higher must be installed on every client that you want to protect.

• The CipherTrust Manager with which these clients are registered must be version 2.0.0 or higher.

LDT License Requirements

• One LDT license is required for each protected host.

Host System Requirements

Memory requirements: Both Linux and Windows require a minimum of 8 GB memory on each protected host.

Disk space requirements: LDT requires a specific amount of disk space in the file system or NFS/CIFS share for each GuardPoint, over and above the space required for the guarded files themselves. LDT uses the additional space to store LDT metadata.

• For Linux, to estimate the amount of free file system disk space required by LDT on a Linux host, use the voradmin ldt space <guardpoint-name> command.

• For Windows, the typical minimum space requirement for a GuardPoint is the number of files in the GuardPoint multiplied by 4K, plus 256MB. To estimate the amount of free space required for a GuardPoint, use the voradmin ldt space <guardpoint-name> command.

Backup Requirements

• For Windows, GuardPoints in local file systems or CIFS shares, the application can use Volume Shadow Copy service (VSS) or roboCopy for backup and restore.

• For Linux, GuardPoints in local file systems, the backup application must have the capability to back up user-extended attributes. For example, Thales tested LDT with NetBackup. You can also use other applications that can back up user-extended attributes.

Backup Requirements for Linux GuardPoint backup on NFS

• You can only perform a backup or restore on the NFS client designated as the primary client for the GuardPoint. Use backup clients or tools such as tar, rsync, etc. on this client. You can backup or restore individual files, or subdirectories, within a GuardPoint namespace without an Apply Key Effect. However, this excludes MDS files and all LDT private files under vorm_ldtprivspace.

• Performing a backup or restore on a non-primary client is not supported and may lead to data and/or LDT metadata inconsistencies, in target files, in the backup image or in the restored files. Attempts to restore files on a non-primary client will be detected and rejected. Refer to section Encrypted Backup and Restore for additional information.

• File backup/restore can only be executed when the GuardPoint is rekeyed, or in a subsequent rekeying suspended state. File backup should not be executed during initial rekeying state.

• For Linux, GuardPoints on NFS shares, the normal procedure is to back up the NAS server that serves the NFS clients rather than backing up the individual NFS clients. Because backups on NAS servers are remote from a CTE perspective, it is extremely important that CTE is not performing any data transformation in any GuardPoint while the NAS server is being backed up. This includes both initial data transformation and automatic or manual data rekey.

Warning

Make sure that all live data transformation has completed on all NFS GuardPoints before you back up the NAS servers associated with the NFS shares on which those GuardPoints reside. You must also make sure that no automatic rekey tasks will start while the NAS backup is in progress.

Linux-Specific Requirements

• To use LDT on an ext3 or ext4 file system, the block size must be 4K. Run dumpe2fs to determine the block size of the ext3 or ext4 file systems before using LDT. This limitation does not apply to XFS file systems or NFS shares. You can use LDT on XFS with a block size of 1K or 2K.

Local File System Requirements

• For LDT to work properly on local file systems, the underlying file system must support and enable user-extended attributes. All of the file systems supported by LDT support these attributes. If you are using LDT with ext3 or ext4 mount points, you must explicitly enable the extended attribute mount option by editing /etc/fstab and adding the user_xattr mount option. In the other file systems supported by LDT, user extended attributes are enabled by default, so you do not have to explicitly enable them.

  Example /etc/fstab entry for ext3 on Red Hat or SLES:

  /dev/sdb1 /disk2 ext3 defaults,user_xattr 0 0

  Example /etc/fstab entry for ext4 on Red Hat or SLES 12 (ext4 is not supported on SLES 11):

  /dev/sdc1 /disk3 ext4 auto,users,user_xattr,exec 0 0

For more information about extended attributes, see LDT Metadata in Extended Attributes.

NFS Share Requirements

• For GuardPoints on NFS shares, LDT embeds file specific LDT metadata in the beginning of each file during the initial data transformation phase. The size of each file becomes larger by 4096 bytes to accommodate this required metadata. Both the metadata and the file size increase are hidden from users and applications as long as the GuardPoint remains enabled.

• If a GuardPoint is disabled, the metadata remains in each file and both the metadata and the file size increase become visible to users and applications.

Note

Thales highly recommends that NFS shared directory be mounted with sync option.

Supported Applications in Linux

• For all of the supported operating systems for database applications, see the Compatibility Matrix for CTE Agent.

Replication

• rsync

• Hardware/software based replication system

SAP HANA Fibre Channel Systems

• SAP HANA is compatible with LDT. See the Compatibility Matrix for CTE Agent.

Windows-Specific Requirements

CIFS Share Requirements

• For GuardPoints on CIFS shares, LDT embeds file specific LDT metadata in beginning of each file during the initial data transformation phase. This metadata remains hidden to users and other applications as long as the GuardPoint is enabled.

• If a GuardPoint is disabled, the metadata remains in each file and becomes visible to users and other applications.

• The size of each file becomes larger by 4096 bytes to accommodate the required LDT metadata.