Configuring native encryption in an HADR environment

When you are encrypting a Db2® HADR configuration, it is important to remember that you are encrypting more than one database. Both the primary and standby databases need to be encrypted to provide the highest level of security.

Before you begin

It is possible to run an encrypted primary database and an unencrypted standby database. However, this configuration is recommended only if the standby database does not need to access any of the files that are encrypted on the primary. An example of such an encrypted file is an archived transaction log file.

While the primary and standby databases each have an independent, unique data encryption key, they must also have access to the same master key (MK). This access ensures that the MK label can flow between the databases when a MK rotation is done, and when the primary and standby databases need to access shared encrypted files.

It is recommended that all of the databases in an HADR environment have access to the same keystore. This can be a PKCS12 key store on a shared file system, or a centralized key store such as a KMIP key manager or PKCS11 hardware security module. It is not recommended to use separate PKCS12 key stores, since they must be manually kept in sync. In cases where a centralized keystore is being used, the databases might each be configured to treat different clones of the same keystore as their primary keystore.

It is also recommended that you consider implementing encryption for the HADR communication as well, to ensure that the data is never exposed. Refer to Configuring TLS for the communication between primary and standby HADR servers for setup instructions.

Procedure

To implement an HADR relationship for encrypted database, take the following steps:

Create and configure a common keystore for both the primary and standby databases and place the MK in the keystore. Save the keystore on a shared keystore service that can be accessed by both the primary and standby databases.
For a non-encrypted database, configure Db2 to recognize the keystore. You can also migrate an old, local keystore to a new centralized KMIP or PKCS #11 keystore on the primary node.
Back up the primary database:
```
db2 backup db <dbname>
```
Stop the HADR service on the primary node:
```
db2 stop hadr on db <dbname>
```
Deactivate the database on the standby node:
```
db2 deactivate db <dbname>
```
Drop the standby database:
```
db2 drop db <dbname>
```
Restore the database on the standby node with the ENCRYPT option, specifying the encryption options and the label for the MK:
```
ddb2 restore db <dbname> encrypt
```

Modify HADR configuration parameters for standby:

db2 update db cfg for <dbname> USING HADR_LOCAL_HOST <hostname> HADR_LOCAL_SVC <servicename> HADR_SYNCMODE <syncmode> HADR_TARGET_LIST <principalhostname:principalservicename|auxhostnameN:auxservicenameN>  HADR_REMOTE_HOST <principalhostname> HADR_REMOTE_SVC <principalservicename> HADR_REMOTE_INST <principalinstname>

Start the encrypted standby database:

db2 start hadr on db <dbname> as standby

Reenter the HADR environment through the primary database:
```
db2 start hadr on db <dbname> as primary
```
When the standby database catches up to the primary database, run the following command on the standby database to have it take over as the new primary:
```
db2 takeover hadr on db <dbname>
```
Repeat steps 2 through 10, using the new primary database as the starting point.
Repeat steps 2 through 9, using auxiliary standby instead of standby, for each auxiliary standby.

Results

The primary and standby servers of your Db2 HADR configuration are now properly encrypted.