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 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:

1. Create a registration token using the ID of the Local CA signed by the external CA. Refer to Creating a Registration Token for details.

2. 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.

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.

While reregistering a client, you can enable capabilities even if they were disabled earlier.

To reregister a client with the CipherTrust Manager:

1. 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.

2. 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:

• Standard Policies

• LDT Policies

• COS Policies

• IDT Policies

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:

• User Sets

• Process Sets

• Resource Sets

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.