Operations
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.
Registering Clients
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 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.
Reregistering CTE Clients
In some cases, you need to change the CA certificate that was used to register a client with the CipherTrust Manager. For example, when the existing CA certificate expires or the certificate needs to be renewed to meet security requirements of your organization, the client must be reregistered with the CipherTrust Manager.
While reregistering a client, you can enable capabilities (for example, COS and LDT) 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.
GuardPoints
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.
Policies
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.
Standard Policies
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.
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:
COS Policies
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:
IDT Policies
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.
Policy Elements
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.
User Sets
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:
Process Sets
Groups of single or multiple processes that can be used as individual entities in policies to grant process specific privileges.
Resource Sets
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.
