Access

An access policy defines which user, group, and process can access protected content, their read/write permissions, and whether they can view ciphertext or plaintext. Users, groups, and processes are referred to as "entities" in this document. An access policy can be created for individual entities or combination of "user and process" and "group and process".

Specific entities can be allowed to read and write plaintext while others can only be allowed to read plaintext. For example, users responsible for creating backups can be allowed to read ciphertext only. Similarly, users responsible for creating and restoring backups can be allowed to read and write ciphertext only.

Access policies operate as additional control on top of operating system’s access permissions. ProtectFile’s access policies can only limit or control the “allow” permissions, not the “deny” permissions. For example, if User1 is granted the read and write access to File1, ProtectFile can limit the access to read only. Similarly, if User1 does not have any access to File2, ProtectFile cannot modify the user’s access permissions to this file.

Access Priority

ProtectFile enforces access policies in order of their priority in the access policy group, that is, from top to bottom.

An individual process takes higher priority than a user or a group. However, when a policy has a combination of user, group, and process, then the priority order is "user/group & process," process, and user/group.

Priority is automatically assigned to entities, as described below:

• User/Group and Process – When a policy has a combination of user, group, and process, then the priority order is "user/group and process," process, and user/group.

  For example, a policy for the combination of User A and Process A is granted the highest priority than individual priorities of Process A, User A, and Group A.

  Consider access policies for the following are added to an access policy group:

  • User A and Process A

  • User A

  • Process A

  In this case, the order of access priority is:

  1. User A and Process A – This access policy gets the highest priority.

  2. Process A – This access policy gets the second highest priority; lower than combination of User A and Process A but higher than individual User A (listed lower in priority order).

  3. User A – This access policy gets the third highest priority; lower than combination of User A and Process A and individual Process A.

  4. Default – This access policy is always the lowest in priority.

  Similarly, if access policies for the following are added to an access policy group:

  • Group A and Process A

  • Group A

  • Process A

  In this case, the order of access priority is:

  1. Group A and Process A – This access policy gets the highest priority.

  2. Process A – This access policy gets the second highest priority; lower than combination of Group A and Process A but higher than individual Group A (listed lower in access priority list).

  3. Group A – This access policy gets the third highest priority; lower than combination of Group A and Process A and individual Process A.

  4. Default – This access policy is always the lowest in priority.

• Processes – Individual processes take higher priority than individual users and processes in an access policy group. However, they take lower priority than a combination of "user/group and process." Therefore, they appear above users and groups, but below combination of "user/group and process" in an access policy group.

  In case of multiple processes, priority is granted in the order they are added to the access policy group. For example, if Process A is added to the access policy group before Process B, then Process A is granted higher priority than Process B, or vice-versa. Similarly, a child process can be granted higher or lower priority than its parent process, as appropriate.

  ProtectFile enforces access policy on a process (whether parent or its child) that is added first to the access policy group. Therefore, it is recommended to add access policies in the order of their priority according to security requirements.

  Note

  (Applicable to ProtectFile Linux clients) When a parent process is assigned higher priority than its child processes, the child processes inherit the access policy of the parent process. However, when a child process is assigned higher priority than its parent process, the access policy assigned to the child process takes priority. Refer to Process Inheritance for details.

  Note

  To access the link to a process, ensure that both the process and the link to it are in the access policy group. Accessing the process executable directly through its link is not supported. Therefore, paths to the link and the actual process executable must be added separately to the access policy group.

• Users/Groups – Users/groups take lower priority than processes and combination of "user/group and process." Access priority is granted to users/groups in the order they are added to the access policy group. For example, if User A is added before User B, then User A takes higher priority than User B, or vice-versa. Similarly, a user can be granted higher or lower priority than its group, or any other group, as appropriate.

  For example, to grant a group one type of access but allow one member (user) of the group a higher level of access, add access policy for the user individually before adding access policy for its group.

  ProtectFile enforces access policy on a user or group that is added first to the access policy group. Therefore, it is recommended to add access policies in the order of their priority according to security requirements.

Creating an Access Policy Group

An access policy group is a logical grouping of access policies of the same type. The access policy group is used when associating an encryption rule with a client to enforce access control.

A new access policy group has a default access setting. The default setting applies access permissions to entities that do not have specific permissions assigned. Access policies can be associated and removed from an access policy group.

The following table lists the parameters that are required when creating or managing an access policy group on the CipherTrust Manager:

ProtectFile provides options to view existing access policy groups, view their details, update their names, and delete them when they are no longer required. Also, you can view the list of access policies linked to a group, link an access policy to a group, and remove an access policy from a group.

Group Types

ProtectFile supports two group types:

• Access Control & Encryption – This type of group can be associated with rules performing data encryption. Therefore, access policies having Read/Write Cipher and Read/Write permissions can be part of this group. Refer to Permissions for Access Control & Encryption for details.

• Access Control Only – This type of group can be associated with rules that do not perform encryption. Therefore, access policies having only Read/Write permissions can be part of this group. Refer to Permissions for Access Control Only for details.

Permissions for Access Control & Encryption

Permissions for Access Control & Encryption are:

• NoAccess – Denies access to a protected file or directory. A Permission denied error message is returned when an entity tries to access the protected path. This is the highest security level.

  Note

  Setting Default Access to NoAccess provides the highest security. It assures that entities not specifically associated with the policy cannot access files and directories where the linked encryption rule is applied.

• ReadWrite – Grants permissions to read and write/modify an encrypted file and to create a new file in a protected directory.

• Read – Grants permissions to read but not to write/modify an encrypted file.

• ReadWriteCipher – Grants permissions to read and write the protected data in ciphertext only. No access is granted to the plaintext data. No encryption or decryption happens with this access permission. This access should be reserved for entities that create and restore backups of protected data.

  Note

  For tools that take backup from the volume/disk, for example, Acronis 11.5 and Symantec Backup Exec 2014, the restore must happen through the ReadWriteCipher entities only.

• ReadCipher – Grants permissions to read the protected data in ciphertext only. No access is granted to write/modify ciphertext. This access should be reserved for entities to take a backup of protected files, but not to restore a backup.

  Note

  Entities with ReadCipher or ReadWriteCipher permissions should only access the encrypted files using programs intended for creating and restoring encrypted server backups.

• Write – Grants permissions to write/modify an encrypted file and create a new file in a protected directory, but not to read that file.

Permissions for Access Control Only

Permissions for Access Control Policy are:

• NoAccess – Denies access to a protected file or directory. A "Permission denied" error message is returned when a user, group, or process tries to access the protected path. This is the highest security level.

  Note

  Setting Default Access to NoAccess provides the highest security, assuring that any user, group, or process not specifically associated with the policy cannot access directories and files in the encryption policies linked to this access policy.

• ReadWrite – Grants permissions to read and write/modify a protected file and to create a new file in a protected directory.

• Read – Grants permissions to read but not to write/modify a protected file.

• Write – Grants permissions to write/modify a protected file and to create a new file in a protected directory, but not to read that file. Read as well as operations those require read permission (for example, copy) are not allowed. All other operations such as delete, append, and overwrite are allowed.

Creating an Access Policy

An access policy is used to manage entities' access to a protected path. At least one entity or a valid combination of entities (for example, "user/group and process") is required to create an access policy.

The following table lists the parameters that are required when creating or managing an access policy on the CipherTrust Manager:

Important Notes for Windows Clients

For system processes and other applications using protected data to work properly, it is recommended to provide appropriate access to system accounts. Windows services mostly use the SYSTEM@NT AUTHORITY system account. ProtectFile audit logs can be used to determine appropriate process or system account used by applications.

When the path to be migrated is used by system services, create access policies for built-in system accounts (for example, SYSTEM@NT AUTHORITY, NetworkService@NT AUTHORITY, and LocalService@NT AUTHORITY) with appropriate access rights.

Create access policies for different Windows users and groups, as described below:

• Users and Groups – Create access policies for names users@BUILTIN and administrators@BUILTIN.

• System Accounts – Create access policies for SYSTEM@NT AUTHORITY, NetworkService@NT AUTHORITY, and LocalService@NT AUTHORITY.

• Local Users and Groups – Create access policies for users and groups (other than "built-in users and groups" and "built-in system accounts") as follows:

  • Add <user_or_group_name>@<localhost>, where <user_or_group_name> may exist on any client. For example, TestUser@<localhost> and TestGroup@<localhost>.

  • Add @, where exist on a specific client. For example, TestUser@QA-SFNT or TestGroup@QA-SFNT where QA-SFNT is a client’s hostname.

• Active Directory Users and Groups: Create access policies for Active Directory (AD) users and groups, as follows:

  • Create access policy for User Name, <DOMAIN>\<User>; for example, DOMAIN\User.

  • Create access policy for Group Name, <DOMAIN>\<Group>; for example, DOMAIN\Group.

Modifying Access Policies

After an access policy is created, you can edit the name of the user/group and process and change the access permission for the access policy.

To modify an existing access policy:

1. Open the ProtectFile & Transparent Encryption UserSpace application.

2. In the left pane, click Access Policies.

3. Under the Access Policies section, click the overflow icon () corresponding to the policy you want to modify.

4. Click Edit.

5. Edit the required details, as appropriate.

   • Access: Select the desired access. The access can be:

     • ReadWrite

     • Write

     • Read

     • ReadWriteCipher

     • ReadCipher

     • NoAccess

     Refer to Permissions for Access Control & Encryption for details.

   • User Name: Name of the user to add to the policy. If the user is a domain user, specify domain name with the user name; for example, user@domain.com. When editing a user name, the Group Name field is not displayed.

   • Group Name: Name of the group of users to add to the policy. If the group is a domain group, specify domain name with the group name; for example, group@domain.com. When editing a group name, the User Name field is not displayed.

   • Process Name: Name of the process to add to the policy. For example, /path/to/process.

6. Click Save.

The access policy is modified.

Access Policies for Processes

Access permissions can be granted to processes irrespective of the users running them. It ensures that unnecessary access permission is not granted to any user and the targeted access can be provided to a process. The process can access the protected path according to its access permissions even if the user running it does not have such permissions.

Process Inheritance (Linux Clients)

Access permissions for child processes are inherited from the access policies of their parent processes. Access policies can be defined for parent/child processes in the following scenarios:

• Only Parent Process is Assigned Policy

• Parent Process is Assigned Higher Priority

• Child Process is Assigned Higher Priority

Only Parent Process is Assigned Policy

Access policy is assigned for the parent process only.

For example, the process PostgreSQL startup script (/etc/init.d/postgresql) uses commands/processes such as chown, touch, and cat. Here, the script /etc/init.d/postgresql the parent process and chown, touch, and cat are its child processes.

The /etc/init.d/postgresql script is assigned the ReadWrite access on a protected path. All the commands/processes invoked by this script will gain the ReadWrite access on the protected path. When invoked from outside the /etc/init.d/postgresql script, these commands/processes would not gain the same access to the path.

Similarly, if the /etc/init.d/postgresql script is assigned the NoAccess on a path, then the commands/processes invoked by the script cannot access the protected path.

Parent Process is Assigned Higher Priority

Access policy is defined individually for a parent process and its child processes. The parent process is assigned higher priority than its child processes.

ProtectFile enforces policies in the order of their priority (from top to bottom) in the list of access policies. So in this case, the access policy of the parent process will be enforced on its child processes.

For example, the parent process, /opt/abc.h, is assigned the highest priority with ReadWrite access. Its child processes, /bin/ls and bin/cat, are individually assigned the NoAccess.

In this example, although the child processes are assigned individual access policies, they will inherit access policies of their parent process. The ReadWrite access will be enforced to them.

Child Process is Assigned Higher Priority

Access policy is defined individually for a parent process and its child processes. A child process is assigned higher priority than its parent process.

ProtectFile enforces policies in the order of their priority (from top to bottom) in the list of access policies. So in this case, the child process will be enforced its own access policy; it will not inherit access policy from its parent process.

For example, the child process, /bin/ls, is assigned the highest priority with NoAccess. Its parent process, opt/abc.h, is assigned the ReadWrite access. And another child process, /bin/cat, is assigned the NoAccess.

In this example, the child process, /bin/ls, having the highest priority, will be enforced its own access policy, NoAccess. It will not inherit its parent’s ReadWrite access. However, the other child process, /bin/cat, despite having assigned the NoAccess, will inherit its parent’s ReadWrite access.

Access Policy and Group Association

Access policies for individual entities on a particular path can be created and associated to an access policy group. This access policy group is used when creating a client-rule association to provide required access control.