Operations

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

Registering Clients

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

Registering a ProtectFile 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 ProtectFile client's registration with the CipherTrust Manager. Single registration token can be used to register any number of ProtectFile clients.

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

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

By default, CipherTrust Manager issues a Local CA with Common Name "KeySecure Root CA" which is used by ProtectFile for signing client certificates. This Local CA is, by default, marked as trusted by the "web" interface which is also used by ProtectFile for client authentication. Make sure that the CA whose signature is used for registering ProtectFile 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 ProtectFile 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 ProtectFile clients must be added to the list of trusted CAs for the "web" interface on the CipherTrust Manager. Refer to the "Certificate Authority" section in the CipherTrust Manager Administrator Guide 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 ProtectFile 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 ProtectFile Clients User's Guide for details.

Reregistering ProtectFile 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 CA certificate. The client administrator reregisters the client with the CipherTrust Manager. Refer to "Reregistering ProtectFile Clients" in the ProtectFile 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 ProtectFile. 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 ProtectFile:

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	Windows	True	NoAccess

   Note

   For no encryption policies, set the encrypt data parameter to false.

   Similarly, an access policy group can be created for Linux clients.

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. ProtectFile supports AES-256 encryption keys. When creating the encryption key for ProtectFile, 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 ProtectFile for encryption.

5. Create a rule to protect data.

   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. Also, specify whether to encrypt data or provide access control only.

   For Linux clients, you can 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. ProtectFile 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

ProtectFile can encrypt network shares mounted on clients with ProtectFile 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 ProtectFile installation is designated to encrypt the network share accessed by clients.

The following diagram shows steps to protect network shares using ProtectFile:

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/DFS server where NAS path is shared.

   • Path shared on the NAS/DFS server.

   • Type of the network share—SMB or NFS. Specify the following:

     • For an SMB share, specify the user name, password, DFS, and DFS alias.

     • For an NFS share, specify whether the share is automatically mounted through Autofs.

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

Protecting Clusters

ProtectFile can encrypt data stored on ProtectFile clients in a cluster.

To encrypt data on a cluster:

1. Make sure that all clients, that will from the cluster, are registered with the CipherTrust Manager.

2. Create the cluster on the CipherTrust Manager.

   When creating a cluster, specify:

   • Friendly name for the cluster.

   • Operating system (Windows or Linux) running on all clients that will from the cluster. The default operating system is Windows. Depending on the OS, specify the following:

     • For Windows, specify a unique name for the Windows cluster.

     • For Linux, name of the encryptor client. This client will perform encryption of data shared among clients in the cluster. If an encryptor client is not specified, data on the clients in the cluster cannot be encrypted. However, you can modify the cluster to specify the encryptor client later.

   Refer to Clusters for details.

3. Add clients to the cluster. Use the "ProtectFile/Clusters > Add Client" API to link the client with the cluster.

   When linking a client with a cluster, specify:

   • The ID of the cluster.

   • The ID of the client.

   After linking the clients with the cluster, 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 cluster.

10. Deploy the rule.