Concepts
Application
An application, configured on the CipherTrust Manager, contains the necessary settings that are required to protect/reveal/reprotect data. Refer to Managing Application for details.
Access policy
Access policies contain set of rules that govern how the protected data will be revealed to users. Since there is no concept of users in BDT, the data will be revealed based on the default reveal format configured in the access policy.
Note
For BDT, it is recommended to configure the default reveal format as plaintext.
Refer to Managing Access Policy for details.
Dynamic Masking
Creates masking format for the reveal operation. Dynamic masking format determines how the output of the reveal operation is displayed to the application users. Refer to Masking Format for details.
Heartbeat
Heartbeat is a lightweight mechanism that allows BDT to poll the CipherTrust Manager for any change in configurations. Refer to Heartbeat Configuration
Note
Every transformation will run with the latest configurations.
For BDT, only protection policy configurations get reflected with heartbeat in a running transformation. Modifications done in all other configurations can not get reflected in a running transformation.
The time on both the client and server machines must be synchronized. To achieve this, NTP (Network Time Protocol) should be configured. Follow instructions to set up NTP.
Behavior of BDT when heartbeat timeout count is reached
If the count of the continuous skipped heartbeat becomes equivalent to the value of Heartbeat Timeout Count parameter, the BDT client enters a revoked state after a maximum of 5 minutes. At this point, its liveness and health probes become false. In this scenario, BDT does not transform data. This safeguard ensures the crypto operations are not performed when the container’s state is unhealthy and unrecoverable.
Note
If a client is processing a job and in-between its heartbeat timeout count has reached due to any issue on the Key Manager, the client enters a revoked state. The CipherTrust Manager will stop running the job linked to that client. The job status page may not reflect the actual progress of that stopped job.
Behavior of BDT when client gets deleted, revoked, or expired
If a client gets deleted, revoked or expired on Key Manager, the liveness and health probes become false. In this scenario, BDT does not transform data. This safeguard ensures the crypto operations are not performed when the container’s state is unhealthy and unrecoverable.
Note
When a client gets deleted on Key Manager, the status of its running job will no longer get updated on the Job Status page. As a result, the associated job configuration can't be reused to run a new job.
The deleted, revoked, or expired client will be in healthy state for maximum 5 minutes.
Key Caching
The key caching feature allows BDT to securely cache a copy of the in-use key that it received from the CipherTrust Manager using the REST protocol. Key caching is limited for the value set in the Key Cache Expiry parameter while creating an application to perform cryptographic operations locally.
See the Key Cache Expiry parameter under the BDT tab here for details.
Key States
A key state determines which operations can be performed using that key. Refer to Key States for details. Based on the key states, BDT will throw error for the following key states.
Compromised Key State: Cannot Protect with Compromised Key Version
Deactivated Key State: Cannot perform operation with Deactivated Key Version
