Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

CTE Agent Windows Advanced Configuration Guide

Special Cases for CTE Policies

search

Please Note:

Special Cases for CTE Policies

This following section describes a CTE-specific configuration task related to configuring policies in the key manager.

When using hard links on Windows, all the hard links to a file must be within the boundary of a GuardPoint and must use the same key. The following scenarios provide additional details:

  • If hard links to the same file are inside a GuardPoint and outside a GuardPoint, the effect on the file depends on what process accesses which hard link first. If the hard link within the GuardPoint is opened first, the file is transformed. If the hard link outside the GuardPoint is opened first, the file won’t be transformed.

  • If hard links to the same file exist in different GuardPoints with different keys, the file will be corrupted.

  • If hard links to the same file exist in the same GuardPoint but with different keys, such as if folder-based rules are used, there will be a conflict in the key.

Security Rule Ordering for Polices

If you want to enforce restrictions when guarding NFS shares using an LDT or standard policy with a CBC-CS1 key, note the following:

CipherTrust Transparent Encryption embeds and hides LDT and/or IV (initialization vector) attributes in the first 4K of files for NFS shares guarded with an LDT or standard policy with a CBC-CS1 key. Embedding CipherTrust Transparent Encryption attributes increases the actual file size by 4K, and CTE hides that extra 4K when reporting the file size. The exception to this is when a backup/restore process reads/writes such files. This requires embedded attributes to be read/restored by the backup/restore process. In such cases, CipherTrust Transparent Encryption does not hide the 4K attribute space in the file. The backup user/process views the actual file size. Non-backup users/applications view the file size as less than 4K.

If you want a security rule to enforce restricted access for reading file level attributes on such GuardPoints, you must specify the Apply Key effect. Alternatively, you can place the security rule that is enforcing the restricted access after the rule granting read/write access. This avoids application failure if the Apply key effect is not desired. For example, the order of the two rules in a policy that does not hide the user user-name would be:

  • Security Rule n

    Rule Value
    User <user-name>
    Action Read-file-attribute and/or Read directory
    Effect permit

  • Security Rule n + 1

    Rule Value
    User <user-name>
    Action all_ops
    Effect permit, apply-key

Assuming <user-name> is not affiliated with backup/restore operations, <user-name> would view the actual file size which is 4K larger than the size of the user data in the file. The returned file size can result in failure when user-name attempts to read/write files. By reordering rules n and n + 1, <user-name> will view the correct size hiding the 4K attribute space in the target file.

For more information, see Adding Security Rules in the CipherTrust Manager documentation.

On this page