Client Profiles

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

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

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

ProtectFile continues connection attempts in loops with the CipherTrust Manager appliances until success. If all the CipherTrust Manager appliances are tried once, ProtectFile 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

ProtectFile generates large amount of access logs for operations happening on encrypted paths. By default, these logs are stored on the ProtectFile client. ProtectFile provides options to redirect access logs to a dedicated Syslog server. Redirected access logs are sent in the format of ProtectFile 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 ProtectFile. They can change any setting on the client and install or uninstall any software including ProtectFile.

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

• Restricting Substituted User Access

Granting NoAccess to the root User

With ProtectFile, 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 ProtectFile service and uninstalls ProtectFile, 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.

Restricting Substituted User Access

When the allowSuAccess flag is set to true, client administrators (users with the “root” access) can gain access rights of a different user through su. With this setting, all the client administrators can access rights of a different user through su.

Example

Assume three client administrators: fsa1, fsa2, and fsa3. They are granted No Access and testuser is granted the ReadWrite access permission on a protected path. Now, the administrators use the su command to access the protected path as testuser.

The three cases are:

• When the allowSuAccess flag is set to false, fsa1, fsa2, and fsa3 cannot get the ReadWrite access of testuser. This is the default setting.

• When the allowSuAccess flag is set to true, but the allowSuException parameter is not specified, all three administrators, fsa1, fsa2, and fsa3, get the ReadWrite access of testuser.

• When the allowSuAccess flag is set to true and fsa2;fsa3 is specified in the allowSuException parameter, then fsa2 and fsa3 cannot get the ReadWrite access of testuser; they will continue to have No Access assigned to them. Only fsa1 will be granted ReadWrite access of testuser.