Operations

This section provides information on operations that CTE UserSpace Server Administrator performs on the CipherTrust Manager. These operations include registering CTE UserSpace clients with the CipherTrust Manager, protecting a local file system on a CTE UserSpace client and protecting network shares.

Registering Clients

Registration is the process of configuring a CTE UserSpace client with a CipherTrust Manager. This process creates SSL certificates for further communication between the CipherTrust Manager and the CTE UserSpace client.

Registering a CTE UserSpace client with the CipherTrust Manager requires a registration token and the fingerprint of the server’s web interface certificate. These are used as parameters during CTE UserSpace client's registration with the CipherTrust Manager. Single registration token can be used to register any number of CTE UserSpace clients.

Refer to "Registering Clients" in the CTE UserSpace Clients User's Guide.

The following diagram shows the process of registering CTE UserSpace clients with the CipherTrust Manager:

By default, CipherTrust Manager issues a Local CA with Common Name "KeySecure Root CA" which is used by CTE UserSpace for signing client certificates. This Local CA is, by default, marked as trusted by the "web" interface which is also used by CTE UserSpace for client authentication. Make sure that the CA whose signature is used for registering CTE UserSpace 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 UserSpace 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 UserSpace 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 UserSpace clients using this registration token. The registration process will automatically use the Local CA signed by the external CA. Refer to "Registering Clients" in the CTE UserSpace Clients User's Guide for details.

Reregistering CTE UserSpace 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.

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 and the fingerprint of the old CA certificate. The client administrator reregisters the client with the CipherTrust Manager. Refer to "Reregistering CTE UserSpace Clients" in the CTE UserSpace Clients User's Guide for details.

Protecting Local File Systems

After registration, the client can communicate with the CipherTrust Manager, and is ready for data protection using CTE UserSpace. The following diagram depicts steps involved in protecting a local file system. The diagram also shows sample access permissions granted to an administrator and an application user. Grant access permissions to different types of users, groups, and processes based on your organization's security requirements.

The following diagram shows steps to protect local file systems using CTE UserSpace:

To protect a local file system:

1. Create an access policy.

   Create an access policy to grant required permissions to entities. For example, create an access policy, AP, with the following permissions:

   Entity	Name	Permission
   user	AppUser	ReadWrite
   user	Administrator	ReadWriteCipher

2. Create an access policy group.

   Create an access policy group to group multiple access policies of the same type. For example, create an access policy group, APG, with the following:

   Name	OS Type	Encrypt Data	Default Access
   APG	Linux	True	NoAccess

3. Add the policy to the access policy group.

   When adding the policy to the access policy group, specify:

   • The identifier of the access policy.

   • The identifier of the access policy group to which the access policy will be added.

4. Create an encryption key.

   A CipherTrust Manager administrator creates an encryption key on the CipherTrust Manager. CTE UserSpace supports AES-256 encryption keys. When creating the encryption key for CTE UserSpace, make sure that the key is exportable and the ProtectFile Users group has export permissions on the key. Contact the CipherTrust Manager administrator for creation of the encryption key.

   Note

   • ProtectFile Admins must have ReadKey permission on encryption keys when creating a client-rule association.
   • ProtectFile Users must be granted ReadKey and ExportKey permissions on encryption keys.
   • DO NOT create versions of keys used by CTE UserSpace for encryption.

5. Create a rule to protect data.

   CTE UserSpace supports folder level encryption. It does not support file level encryption.

   Create a rule to specify the path to be protected. Specify file extensions to include or ignore during encryption and whether the rule will apply recursively to a directory. You can also specify a list of directories to ignore during encryption.

6. Link the rule with the client.

   When linking the rule with the client, specify:

   • The identifier of the client.

   • The identifier of the rule to link to the client.

   • The key to encrypt data.

   • The identifier of the access policy group.

   Note

   A rule can be linked with multiple clients. The same path on all linked clients will be protected using the same access policy.

7. Deploy the rule.

   After the rule is linked with the client, deploy the rule to enforce the access policy. To deploy the rule, specify:

   • The identifier of the client.

   • The identifier of the rule.

   • Encrypt as the operation of the rule.

When the "encryption" rule is deployed, the client will start polling for any changes in client-rule association. The client will get new client-rule association in the next polling and the encryption process starts. Depending on the size of data, encryption may take some time to complete. A "no encryption" rule is deployed faster because it does not involve encryption of data.

After a path is encrypted successfully, the client-rule association state is set to "Encrypt" and end-users can start accessing the data. If the key used for encryption is required to be changed, this can be done using the KeyRotate operation. This is referred to as key rotation. Type of key rotation can also be specified. CipherTrust Transparent Encryption UserSpace supports deep and shallow key rotation.

Similarly, a rule applied on a path of an associated client can be removed. This removes the enforced access policies and returns the path to plaintext. This is referred to as decryption. For a no encryption policy, only the enforced access control is removed.

Protecting Network Shares

CTE UserSpace can encrypt network shares mounted on clients with CTE UserSpace installed. A path is shared on the NAS server. This shared path is referred to as a network share. The network share is mounted on clients where it will be accessed.

One client, known as the encryptor client, with CTE UserSpace installation is designated to encrypt the network share accessed by clients.

The following diagram shows steps to protect network shares using CTE UserSpace:

To encrypt a network share:

1. Make sure that all clients, where the network share will be accessed, are registered with the CipherTrust Manager.

2. Create the network share on the CipherTrust Manager.

   When creating a network share, specify:

   • A unique friendly name for the share.

   • IP address or hostname of the NAS server where NAS path is shared.

   • Path shared on the NAS server.

   • Type of the network share—NFS.

   • Name of the client that will perform initial encryption of data on the network share. If an encryptor client is not specified, data on the network share cannot be encrypted. However, you can modify the network share to specify the encryptor client later.

   Refer to Creating a Network Share for details.

3. Link the network share with clients. Use the "ProtectFile/Client-Share > Create Link" API to link the share with clients.

   When linking the network share with a client, specify:

   • The ID of the client.

   • The ID of the network share.

   After linking the network share with clients, perform the following steps. Refer to Protecting Local File Systems for description of steps 4 to 8.

4. Create an access policy.

5. Create an access policy group.

6. Add the policy to the access policy group.

7. Create an encryption key.

8. Create a rule to protect data.

9. Link the rule with the network share.

10. Deploy the rule.