This section provides information on operations that the CTE Server Administrator performs on the CipherTrust Manager. These operations include registering CTE clients with the CipherTrust Manager, and protecting file system on a CTE client.
Registration is the process of configuring a CTE client with a CipherTrust Manager. This process creates SSL certificates for further communication between the CipherTrust Manager and the CTE client.
Registering a CTE client with the CipherTrust Manager requires a registration token. Single registration token can be used to register any number of CTE clients. Refer to the CTE Agent Quick Start Guide specific to your platform for details.
The following diagram shows the process of registering CTE clients with the CipherTrust Manager:
By default, CipherTrust Manager issues a Local CA with Common Name "KeySecure Root CA" which is used by CTE for signing client certificates. This Local CA is, by default, marked as trusted by the "web" interface which is also used by CTE for client authentication. Make sure that the CA whose signature is used for registering CTE clients is trusted by the "web" interface. Refer to Authentication Settings for NAE, KMIP, and Web Interfaces for details.
Third party (external) CA certificates can also be used for securing communication between the CipherTrust Manager and CTE clients. Refer to Using External CA Certificates for details.
Using External CA Certificates
All local and external CAs that participate in securing communication between the CipherTrust Manager and CTE clients must be added to the list of trusted CAs for the "web" interface on the CipherTrust Manager. Refer to Certificate Authority for details.
To use an external CA certificate:
Create a registration token using the ID of the Local CA signed by the external CA. Refer to Creating a Registration Token for details.
Register the CTE clients using this registration token. The registration process will automatically use the Local CA signed by the external CA. Refer to the CTE Agent Quick Start Guide specific to your platform for details.
CA Certificates Renewal Notification
If the CA that signed the client certificate or the web interface certificate is modified, the CTE client is notified about this change. The CTE client can now generate or install a new certificate and update the truststore for uninterrupted connections.
CA certificate renewal notification is applicable to the CipherTrust Manager 2.14, CTE 7.5, CTE UserSpace 10.2, and their higher versions.
CA_RENEWALcapability is added to the CTE Agents for CA certificate renewal notification. CTE Administrators can enable this capability when installing the CTE Agent on clients.
If an older client is registered with an older version of the CipherTrust Manager and the certificate is expired or modified, you need to reregister the client, as described in Reregistering CTE Clients below.
CipherTrust Manager 2.14 and higher versions use client management profiles for creating registration tokens. When you upgrade the CipherTrust Manager to 2.14 (or higher versions), the CA that was linked to the token used for registration of older clients will be linked to a client management profile.
CA certificate renewal notification is not available on CTE for Kubernetes clients.
Manual intervention is needed in these cases:
The clients are running older CTE Agent versions that don't support certificate renewal notification.
The clients running a compatible CTE Agent version are registered with the CipherTrust Manager 2.13 or older. If the CipherTrust Manager is upgraded to 2.14 or higher:
The CipherTrust Manager is unaware of the auto CA renewal capability of the existing CTE clients.
The CipherTrust Manager cannot notify the CTE clients.
In this case, reboot the CTE clients so they can be initialized and can send the required notification capabilities to the CipherTrust Manager for receiving auto renewal notifications in the future.
Reregistering CTE Clients
In some cases, you need to change the CA certificate that was used to register a client with the CipherTrust Manager. If the CA used to generate the client certificate is about to expire or is modified, the CTE clients are notified of the CA certificate auto renewal.
If the client certificate is not renewed timely, it results in a connection failure. You need to reregister the client with the CipherTrust Manager.
While reregistering a client, you can enable capabilities even if they were disabled earlier.
To reregister a client with the CipherTrust Manager:
Create a new registration token. Use the ID of the trusted CA that will be used to sign the client certificate. By default, a local CA will be used to issue certificates. Refer to Creating a Registration Token for details.
Register the client again using the new registration token created in step 1. The client administrator reregisters the client with the CipherTrust Manager. Steps are similar to registering a new client with the CipherTrust Manager.
Protecting Data on Clients
After registration, the client can communicate with the CipherTrust Manager, and is ready for data protection using CTE. This section describes how CTE GuardPoints, policies, and policy elements work together to encrypt file systems.
Refer to Common Scenarios for prerequisites and procedures to encrypt data in the most common scenarios.
A GuardPoint specifies the path on the client that is to be protected with different access and encryption policies. GuardPoint is configured by specifying the guard path, policy, and other policy/path specific configuration parameters.
A sample configuration of a GuardPoint is shown below:
Refer to Managing GuardPoints for details.
A policy is the resource where all the access privileges and key configuration is done to achieve the required use cases. Policies are categorized as:
Refer to Creating Policies for details.
Depending on the availability of data in GuardPoints, standard policies can be applied in two different scenarios.
The GuardPoint does not contain any data. The data would be created after the GuardPoint is applied. These policies are also called production policies.
A sample production policy is shown below:
The GuardPoint already contains data. The existing data is migrated to encrypted form by using the data transformation (dataxform) policy.
A sample dataxform policy is shown below:
After the data is migrated, unguard the dataxform policy, apply the standard policy with same key (as used by the dataxform policy). A sample standard policy applied after unguarding a dataxform policy is shown below:
Dataxform policies are created by turning on the Data Transformation toggle when creating a Standard policy. These policies require downtime, so they are referred to as offline policies. If you do not want downtime, you can deploy LDT policies.
As their name implies, LDT policies perform live transformation of data. They do not require any time downtime, so they are referred to as online policies. You can continue to work while the transformation of your data in GuardPoints is in progress. To benefit from LDT, you need to purchase an Add-On LDT license with the CTE Base license.
LDT policies can handle both these cases:
The GuardPoint does not contain any data. No data is migrated. A production policy is applied to encrypt/decrypt the future data.
The GuardPoint already contains data. The existing data is automatically migrated. After the data is migrated, the data is encrypted/decrypted like a production policy.
A sample LDT policy is shown below:
These policies are used to encrypt data and apply access rules on the GuardPoints on cloud. CTE supports Amazon S3 buckets.
A sample COS policy is shown below:
These policies are used to create GuardPoints for Teradata clusters. Access to data is blocked during encryption or rekeying of data.
A sample IDT policy is shown below:
Refer to Protecting Teradata Appliances for details on protecting Teradata appliances.
To achieve different access privileges based on users, processes, and different resources (sub-directory/specific file formats), create these policy elements:
Refer to Creating Policy Elements for details.
Groups of single or multiple users that can be used as individual entities in policies to grant user specific privileges. A sample user set is shown below:
Groups of single or multiple processes that can be used as individual entities in policies to grant process specific privileges.
Groups of single or multiple resources (sub-directory or specific file formats) that can be used as individual entities in policies to grant resource specific privileges.