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:
Parameter | Description |
---|---|
Name | Name for the client profile. This field is mandatory. |
Allow Offline | (Not applicable to ProtectFile) Enable/disable the offline mode. The default value is 'false'. |
Offline Timeout | (Not applicable to ProtectFile) Duration of the offline mode in days. The default value is '7' days. This field is applicable when the offline mode is enabled. |
Cluster Host List | Semicolon-separated list of hostnames or IP addresses of the CipherTrust Manager nodes in the cluster. The default value is ' '. If the CipherTrust Manager with which the client was registered is down, the first available CipherTrust Manager automatically serves ProtectFile client requests. Refer to Using Enhanced CipherTrust Manager Failover for details. |
Cluster Port | Port number on which all the CipherTrust Manager nodes in the cluster will communicate. The default value is 443. Refer to Using Enhanced CipherTrust Manager Failover for details. |
Log Level | Log level of the clients logs. Values can be: • ERROR • WARN • INFO • DEBUG • NONE If log level is set to ERROR , only error logs are captured. Similarly, if log level is set to WARN , log errors and warnings are captured, and so on. The log level NONE disables the logging. The default log level is WARN . |
Syslog Enabled | Enable/disable log upload to the Syslog server. The default value is false. Refer to Redirecting Access Logs to the Syslog Server for details. |
Syslog Server IP | IP address or hostname of the Syslog server. |
Syslog Server Port | Port of the Syslog server. |
Syslog Protocol | Protocol of the Syslog server. ProtectFile supports the udp protocol only. |
Syslog Facility | Name of the Syslog server facility. |
Allow su Access | Allow/disallow user impersonation. The default value is false .Refer to Protection Against the Rogue root User for details. |
Allow su Exception | List of users to be prevented from gaining access rights of a different user through su . Separate multiple users by semicolons. Client users that are not specified in this field can gain access rights of a different user through su .This field is applicable if user impersonation is allowed, that is, when Allow su Access is set to true . Refer to Restricting Substituted User Access for details. |
Polling Interval | Specify the polling interval in seconds. Clients contact the CipherTrust Manager during this interval for any configuration changes. The default polling interval is 180 to 360 seconds.The allowed minimum polling interval is 60 seconds. |
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 on creating a client profile.
Protection Against the Rogue root User
Note
Information in this section is applicable to ProtectFile Linux clients.
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
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 tofalse
, the root user cannot getReadWrite
access oftestuser
. This is the default setting.When
allowSuAccess
is set totrue
, the root user getsReadWrite
access oftestuser
.
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 tofalse
,fsa1
,fsa2
, andfsa3
cannot get theReadWrite
access oftestuser
. This is the default setting.When the
allowSuAccess
flag is set totrue
, but theallowSuException
parameter is not specified, all three administrators,fsa1
,fsa2
, andfsa3
, get theReadWrite
access oftestuser
.When the
allowSuAccess
flag is set totrue
andfsa2;fsa3
is specified in theallowSuException
parameter, thenfsa2
andfsa3
cannot get the ReadWrite access oftestuser
; they will continue to haveNo Access
assigned to them. Onlyfsa1
will be grantedReadWrite
access of testuser.