Platform Requirements

General Requirements and Considerations

• You can only associate an Access Control Policy with a data disk encrypted by Cryptographic Security Platform Vault for VM Encryption.

  You cannot associate a policy with an unencrypted data disk, a data disk encrypted by some application other than Cryptographic Security Platform Vault for VM Encryption, or with a boot disk (even if the boot disk is encrypted by Cryptographic Security Platform Vault for VM Encryption).

• If a disk is associated with an Access Control Policy, system administrators can still perform basic disk management functions such as creating mount points or adding, expanding, or shrinking partitions. They cannot, however, decrypt the disk until they remove the Access Control Policy.
• If you want to protect a disk accessed by Application Services (such as a web server), make sure all Application Services and Programs run under specific user accounts that you can add to the permissions list.
• The Access Control Policy creates a user "htadmin". Before associating a policy, make sure you don't already have a predefined user named "htadmin" in the VM.

Linux-Only Requirements and Considerations

• With Linux, you can create only one Access Control Rule per policy that provides a "whitelist" of local VM user accounts that can access both files and blocks on the disk. You can't grant file access while denying block access to a particular user, nor can you grant access to a domain-qualified user name.
• If you want to use an Access Control Policy on a Linux VM, you need to install three SELinux packages and an Entrust-supplied rpm package. For details, see Enabling Access Controls on a Linux VM.

• For security reasons, you cannot enable an Access Control Policy on a VM with any custom SELinux configuration settings or modules. If the Policy Agent finds any such customizations, the policy association will fail.

  Important: After you associate an Access Control Policy with a Linux VM, do not customize any SELinux configuration settings or modules. If you do so, the interaction between the SELinux customizations and the access controls could cause data loss.

  In addition, if the Policy Agent determines that any Entrust SELinux policies have been removed or that SELinux has been disabled or tampered with in any way (as could be done with a custom SELinux policy), the Policy Agent prevents the disk from being attached and access to the data will be lost.

• The hcld daemon must be run by the root user.
• One of the supported Linux filesystems must already exist on the disk before you can associate it with an Access Control Policy. 
• You can associate one and only one Access Control Policy with one or more data disks on a specific VM. Linux does not support using different Access Control Policies for different disks on the same VM.

• Once the Policy Agent enables access controls on a disk, users on that disk operate in a custom SELinux environment, which can restrict certain sudo actions.

  In addition, users with root privileges are blocked from performing operations such as file system checks or data backup for any access-controlled disks on the VM.

• If you apply an Access Control Policy for the first time while users are actively using the disk, all logged-in users will immediately lose access to the disk, even if they are included in the permissions list. Allowed users must log out and log back in before they can continue accessing the files and data blocks on the disk.

  If you apply a valid update to an existing Access Control Policy, the Policy Agent verifies that all active users are still included in the permissions list. If they are, those users can continue to access the disk as normal. If any currently active users have been removed from the permissions list, the Policy Agent automatically logs them out as soon as it validates the new version of the Access Control Policy.

  In either case, if the Access Control Policy contains invalid users, the Policy Agent does not apply that version and does not validate currently active users. This means that if you want to block a currently active user from accessing the disk, the Access Control Policy version you apply must be valid before the Policy Agent logs off the now-unauthorized user.

• If you want to move a disk to another registered VM in the same Cloud VM Set, you must first remove the Access Control Policy from the Linux disk before you move it. Access Control Policies do not move with the Linux disk.
• If you import a disk into a VM that is already associated with an Access Control Policy, the Access Control Policy is not automatically associated with the new disk. You must explicitly associate the Access Control Policy with the imported disk.
• If the Linux VM has multiple disks protected by the Access Control Policy, you cannot remove the Access Control Policy from only one of those disks. Policy removal is an all-or-nothing operation, so if you remove the Access Control Policy from one disk, the Policy Agent removes it from all disks and reboots the VM. You must then re-associate the policy with the disks that you want to protect.
• The VM must support creating local user accounts, as some access control functions require the Policy Agent to create (and then delete) a temporary local user account as needed.

• Enable password-based SSH login on the VM if you want to add, change, or remove an Access Control Policy, because setting and enforcing SELinux policies requires SSH login as an Entrust-admin. The superuser cannot perform these activities. After you successfully associate the policy, you can disable password-based SSH login until you need to associate the policy with a different disk or change or remove the existing policy.

  If you attempt to add, change, or remove an Access Control Policy and password-based SSH login is not enabled, the attempt will fail, and the following message will be displayed in the Cryptographic Security Platform Vault Audit Log:

  Error enforcing policy <policy name>, version <version no> on VM <vmname>. Check if password-based SSH login is enabled on the VM.

  Note: Password-based SSH login is enabled by default for most Linux systems, but it is disabled by default for VMs in an Amazon Web Services (AWS) or Microsoft Azure environment. For details about enabling it for those VMs, see your AWS or Azure documentation.

• To remove the VM from Cryptographic Security Platform Vault for VM Encryption, first remove the Access Control Policy associated with the VM by following the procedure described in Removing Access Controls from a Disk. This procedure also removes the Entrust SELinux customizations from the VM. If you remove the VM from the Cryptographic Security Platform Vault for VM Encryption without following this procedure, you may encounter issues accessing the data on the disk or with normal VM behavior because of these SELinux customizations. For this reason, the hcl unregister command will fail if an Access Control Policy is associated with the disk.
• To back up your Cryptographic Security Platform Vault for VM Encryption configuration, first remove any Linux Access Control Policies applied to your Linux disks. If you create the backup with any Linux Access Control Policies still active, you may be unable to access those VMs when you restore your Cryptographic Security Platform Vault for VM Encryption configuration from the backup file.

• When Access Control Policy is enabled on a Linux system, do not set up auto-mount on the access-controlled disk using hcl (for example, hcl set mntpt=/mnt/sdd1 sdd1), as the mount will fail on VM reboot, because root is not allowed to access the disk. The workaround is to create a script to mount the access-controlled disk after the VM is rebooted, rather than using HCL commands to set up auto-mount.

Windows-Only Requirements and Considerations

• With Windows, you can protect the disk at the folder level, the file level, the data block level, or any combination of the three. Each protection type has a separate policy rule with its own permissions list. Each permissions list can contain users and groups that are either local to the VM or defined in Active Directory (AD). You can grant access to some users or groups while denying access to others so that you can grant access to an entire group but then deny access to selected members within the group. For details, see Windows Access Control Rule Processing and Windows Access Control Rule Recommendations and Considerations.
• Because local accounts can introduce security issues, we recommend adding only users and groups from Active Directory. If a System Administrator removes a local account included in the permissions list for an Access Control Policy and reboots the VM, the Policy Agent disables access controls but leaves the encrypted disk attached. This cannot happen if all users and groups in the permissions list come from AD, because the Policy Agent ignores non-existent AD accounts during policy verification and applies the rest of the Access Control Policy to the disk.

• Windows System Administrators can still use most Windows Disk Management Tools on access-controlled disks to perform basic disk management functions such as managing partitions, creating shadow volumes, and monitoring disk performance. However, they cannot:

  • Check for or fix errors on a disk by any means other than chkdsk.exe. Error checking is blocked for the Windows Disk Manager and the Windows Explorer Tools UI.
  • Format a volume with Windows Explorer. Instead, System Administrators need to format volumes with Windows Disk Manager, the diskpart CLI command, or format.com.

• If the data on the Windows disk is accessed by Windows Services, you need to add the Windows Service Accounts or the SYSTEM account under which the Services are running to the Access Control Policy permissions list. If you add SYSTEM, be aware that System Administrators will be able to run programs under the SYSTEM account.

  This is especially important for Active Directory disks, because AD will not boot if it cannot access the data through the SYSTEM account. For other applications, check the appropriate documentation to see if the program can run under a specific user account instead of using SYSTEM.

  Note: Most antivirus programs require that scheduled antivirus scans run under the SYSTEM account. This means that scheduled scans will be blocked on a disk protected by an Access Control Policy that does not allow access to SYSTEM. However, when an authorized user accesses a file on the protected disk, the on-access antivirus scan will work for most antivirus software, as that scan does not run under SYSTEM.

• An Access Control Policy is associated with a Windows disk, not a VM. You can associate different Access Control Policies with different disks on the same VM. If you move any of the disks from one VM to another, the associated Access Control Policy moves with the disk.

  The only caveat is if the disk was originally imported from another VM before you applied an Access Control Policy. In this case, if you move the disk back to the original VM after applying an Access Control Policy, the Access Control Policy does not move with the disk.

• If an unauthorized user attempts to access a protected disk, the Policy Agent adds an entry to the Cryptographic Security Platform Vault for the VM Encryption Audit Log. The log message specifies the file that the user tried to access, the login account associated with the request, the process name that made the request, and the name of the Access Control Rule that blocked the request.
• When you apply a valid Access Control Policy version to a disk while users are actively using that disk, the access controls take effect immediately. Active users with Allow permissions can continue accessing the disk as normal. Active users not listed in the permissions list, or those with Deny permissions, will immediately lose access to the files and data blocks on the disk.

• Do not apply an Access Control Policy to a parent volume that contains one or more folder mount points of access controlled volumes, because applying an Access Control Policy to the parent volume would flood the Cryptographic Security Platform Vault for VM Encryption Audit Log. For example, if an Access Control Policy has been applied to G:, mounted on N: (N:\GDrive), no Access Control Policy must be applied to N:.