Client Profiles

A client profile contains the CipherTrust Manager redundancy information, logging criteria for CTE UserSpace clients, and settings that can be used for several CTE UserSpace clients.

The CTE UserSpace Server includes a default client profile, Default_ClientProfile. If a client profile is not specified when registering a client, the default profile is automatically linked to the client on successful registration with the CipherTrust Manager. The linked client profile can be modified later. It is recommended to not delete Default_ClientProfile.

This section provides instructions to create and manage client profiles on the CipherTrust Manager. Next, it describes how to enable redirection of access logs from a CTE UserSpace client to a configured Syslog server. The section also provides instructions on how to protect sensitive data from a rogue “root” user.

Creating a Client Profile

The following table lists the parameters that are required when creating or managing a client profile:

CTE UserSpace provides options to view existing client profiles, view and modify their details, and delete them when they are no longer required. Also, you can configure whether to upload client logs to a configured Syslog server.

Using Enhanced CipherTrust Manager Failover

Configuring a client profile requires the IP address of a CipherTrust Manager for communicating with CTE UserSpace clients. Optionally, the IP addresses of multiple CipherTrust Manager appliances to use for failover can be specified. These CipherTrust Manager appliances must be part of the same cluster, and that cluster must share CTE UserSpace Server settings and keys.

If the CipherTrust Manager with which the client was registered is down, the first available CipherTrust Manager (if defined in the client profile) automatically serves client’s requests.

Subsequently, other CipherTrust Manager appliances are tried in the order of their appearance (in the client profile) to serve client’s requests. This results in higher availability of the CipherTrust Manager to serve client’s requests.

CTE UserSpace continues connection attempts in loops with the CipherTrust Manager appliances until success. If all the CipherTrust Manager appliances are tried once, CTE UserSpace continues connection attempts starting with the first CipherTrust Manager in the list.

Refer to Creating a Client Profile for details on creating a client profile.

Redirecting Access Logs to the Syslog Server

CTE UserSpace generates large amount of access logs for operations happening on encrypted paths. By default, these logs are stored on the CTE UserSpace client. CTE UserSpace provides options to redirect access logs to a dedicated Syslog server. Redirected access logs are sent in the format of CTE UserSpace client logs.

Redirection of access logs to the configured Syslog server can be configured through client profiles. This can be done either when creating new profiles or when editing profiles. Refer to Creating a Client Profile for details.

Protection Against the Rogue root User

Any user with the root access is the master of a Linux client. Such users have access to all configuration files, including CTE UserSpace. They can change any setting on the client and install or uninstall any software including CTE UserSpace.

Additionally, a rogue root user can su to a different user having the ReadWrite access and gain unauthorized access to sensitive data.

A rogue root user’s access to sensitive data can be controlled by:

• Granting NoAccess to the root User

• Controlling Impersonation

Granting NoAccess to the root User

With CTE UserSpace, it is possible to ensure that the root user cannot see the protected data in plaintext. To achieve this, grant the NoAccess permission to the root user on the protected path. Even if the root user stops the CTE UserSpace service and uninstalls CipherTrust Transparent Encryption UserSpace, the root user can only get the encrypted data, not the plaintext data.

Controlling Impersonation

On Linux clients, a root user can su to get access permissions of a different user; this is called impersonation. By default, the allowSuAccess flag is set to false. In this case, a root user cannot get the ReadWrite access of a different user through su, and thereby get access to the plaintext data.

A client profile provides an option to control a rogue root user's unauthorized access to sensitive data. This can be controlled when creating a new or editing a linked client profile. Use client profiles to control which access rights to enforce to the root user doing su — the original logged in ID’s or the switched user’s.

When the allowSuAccess flag is set to true, substituted user’s access rights become effective. The root user can access the protected path with access rights of the substituted user.

Example

Assume that the root user is granted NoAccess and the testuser is granted ReadWrite access permission on a protected path. The root user uses the su command to access the protected path as testuser.

The two cases are:

• When allowSuAccess is set to false, the root user cannot get ReadWrite access of testuser. This is the default setting.

• When allowSuAccess is set to true, the root user gets ReadWrite access of testuser.