8.2.14 Key Rotation in HADR Environment

Information

Some additional considerations are needed when working in an HADR environment.

A key rotation on the primary database in an HADR environment drives a key rotation automatically on the standby. The change, however, does not occur until other log records are sent to the standby database. If you want to force the rotated key to the standby, the archive log command can be used to generate the log records that are needed to replay the rotation on the standby.

Rationale:

When the MK is rotated, the database begins to use the new key immediately, but access to the old MK value is still needed in the following scenarios:

Transaction log files that have not been reused since the key rotation

Archived encrypted transaction log files that used the previous MK value

Encrypted backup images that used the previous MK value

Do not delete an MK from the keystore unless you are certain it is no longer referenced by any encrypted object on any of the hosts of the HADR environment.

When using a local keystore file, you need to provide an identical copy of the keystore at each Db2 member that is associated with the database. If you choose to use a shared file system, ensure that network access is maintained for that file system while Db2 is actively working with the encrypted database. In an HADR setup, you should copy the keystore containing the encryption keys between the hosts.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Retain all Master Keys until you are certain they are not use on any of the hosts in an HADR environment.

The same DEK and master key is used on all members in a DPF or pureScale deployment and each member requires access to the keystore to access master keys, which can be a shared file.

See Also

https://workbench.cisecurity.org/benchmarks/10752

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6b.

Plugin: IBM_DB2DB

Control ID: b79eff6845da90b6aea59c7ed59d074ebfd3260a312502da726a7f8c836b9dca