Data encryption

Starting with ActiveBatch Version 2023.2, sensitive data is now encrypted using Enhanced Data Encryption (EDE).

 

Key Concepts

 

The keys, used to secure sensitive data, are dynamically generated and should be managed by the administrator of the system. The keys are required to complete the configuration of a 2023 (and higher) Job Scheduler Service (see sections Select Data Encryption Key Action and Select Transfer Key Action) and will be automatically generated if you do not supply them. The keys are secured and stored in the registry using the Microsoft Data Protection API available on Windows.

 

There are two key types, both are required and serve different purposes in protecting sensitive data.

 

  1. The Data Encryption Key (DEK) is the primary key of a Job Scheduler, used to secure all sensitive data at rest and in transit.

  2. The Transfer Key (TK) is responsible for securing sensitive data while being transferred between different Job Schedulers within an environment.

 

The legacy encryption - with key - still exists within the product, for backwards compatibility purposes, but it is not used to secure newly entered data after an upgrade to 2024.

 

Installation/Configuration

 

During configuration of the Job Scheduler component, additional pages have been added to the setup process in the ActiveBatch Management Console. See sections Select Data Encryption Key Action and Select Transfer Key Action. Additional configuration is not required for any other ActiveBatch components.

 

  • The encryption keys will be bound to the Job Scheduler service account.

  • Once configured in the Management Console, the encryption keys are themselves encrypted using the Microsoft Data Protection API and stored in the registry for runtime operations.

  • To view the encryption keys after an initial configuration, the Job Scheduler service account must be used the launch the ActiveBatch Management Console.

 

Moving Data between Job Schedulers

 

To ensure security of data in transit, and to be compatible with multiple Job Schedulers which do not share the same

DEK, data in transit is encrypted using the TK instead of the DEK.

 

  • For each Job Scheduler that is expected to share the same objects, the system administrator is responsible for configuring each with the same TK.

  • For Job Schedulers which do not share the same TK, or for moving objects to older versions of the product, all sensitive data must be cleared on export or recreated in the target environment after transfer.

 

Backwards compatibility

 

Execution Agents

  • To maintain backward compatibility with older Agents, legacy encryption is used when performing certain actions against older Agents. This only applies to data in motion, sensitive data at rest (in the ActiveBatch database) is still secured with EDE regardless of Agent status.

Change Management and Import/Export

  • All V12 and lower exports can be imported seamlessly into a 2024 environment.

  • Objects CANNOT be transferred, either with Change Management or Import/Export,

    from a 2024 environment to a lower environment.

  • All sensitive data must be cleared on export or recreated in the target environment after transfer.

 

Linux/Unix Considerations

 

The initial release of 2023 and higher does not provide Linux/Unix Agents that support EDE. Support for EDE is anticipated in the future for Linux/Unix Agents. Similar to the behavior of backwards compatibility for Windows Agents, only data in transit will utilize the legacy encryption. No loss of functionality is associated with Linux/Unix Agents after an upgrade.

 

Recommended Practices

 

Keep a backup copy of the DEK and TK

 

  • In the event of a catastrophic system failure where the keys are lost from the system; the ability to restore the key from a backup allows for a quicker recovery.

  • If the DEK is lost and cannot be restored from a backup, then all sensitive data must be manually re-entered to resume processing of your workflows.

  • If the TK is lost and cannot be restored, any export file produced with that key, will need to be manually purged of sensitive data before it can be imported.

 

Leveraging EDE & Cleansing legacy data

 

Depending on security requirements, certain practices can be followed to ensure higher levels of security for the ActiveBatch environment.

 

  • To avoid interruptions to service on upgrade, objects created on the previous version of the product will continue to use the legacy encryption.

  • Additionally, the revision history of an object will contain artifacts from when the legacy encryption was used.

    Note: These practices only need to be performed for objects with sensitive data, such as User Account Objects or objects with secured variables.

 

Re-save objects to start leveraging EDE

 

  • After upgrade, any new object modifications will automatically leverage the enhanced data encryption.

  • Any modification to the object, regardless of the field, will cause all sensitive data to be re-encrypted.

  • Once the data-at-rest has been updated, all data in transit will inherently be secured as well.

  • Revision history can be purged to eliminate legacy encryption artifacts.

 

Generating new password/secured values

 

  • Generating new values for all sensitive data would provide the highest level of security for the environment.

  • By generating a new secure value, and updating the ActveBatch object, the new value would be fully secured using EDE. All older revision data would be invalidated when a new value is generated.

  • This is strongly recommended for any situations where the data of the ActiveBatch database has been exposed to anyone other than trusted personnel.

 

Secure traffic between AB components

 

  • To avoid tedious configuration requirements on upgrade, a key exchange mechanism has been implemented between the Job Scheduler & Execution Agent components.

    • All secure data transiting the connection will remain encrypted by the Job Scheduler’s DEK.

    • To maintain secrecy of the encryption keys used to secure the data, it is recommended that a secure connection is configured between the JSS and EA components.

      • Existing documentation, for establishing TLS communication between the JSS and EA components can be reviewed to facilitate this. See section TLS Certificate Security.

  • As is already a best practice, the Web Console interface should be configured to use HTTPS communication.

  • Other interfaces, such as the Console, PS Module, etc. have been updated to secure communication between the client and the back-end Job Scheduler. No additional considerations are necessary for these interfaces.