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