Archiving the DB2 keystore file

After certain events, for example, initial installation of a platform edition or other encryption-related database tasks, archive the keystore file that is used to consolidate DB2® key encryption keys (KEKs), that are also known as master keys. If a valid keystore file does not exist, the DB2 database data is inaccessible.

Before you begin

If you have more than one instance of IBM® Intelligent Operations Center and you are archiving multiple keystore files to the same central location, determine a mechanism for differentiating between the different keystore files and their respective versions. For example, create a separate directory for each instance of IBM Intelligent Operations Center, or establish a renaming convention for the keystore files that you copy to the target system.

About this task

In IBM Intelligent Operations Center, DB2 data is encrypted with a data encryption key (DEK). The DEK is protected by one or more key encryption keys (KEKs) that are also known as master keys. The master keys are consolidated in a keystore file that is protected by a passphrase. By default, the keystore file is /home/db2i1own/db2i1own-p12.db.

An obfuscated version of the keystore passphrase is stored in a stash file, to eliminate the need to supply the keystore passphrase every time that DB2 is started. By default, the stash file is /home/db2i1own/db2i1own-p12.sth. Losing or inadvertently deleting the stash file is not catastrophic if the keystore passphrase is available. However, losing or inadvertently deleting the keystore file is catastrophic, unless a backup copy exists and is restored.

Note: IBM recommends that you archive the keystore and, optionally, the stash file to one or more highly resilient locations or devices.
For a platform edition of IBM Intelligent Operations Center, archive the keystore file and, optionally, the stash file after any of the following events:
  • Initial installation of a platform edition.
  • Creation of an encrypted database without specifying the MASTER KEY LABEL option on the CREATE DATABASE command.
  • Restoring a new database by using the ENCRYPT option but without specifying the MASTER KEY LABEL option on either the RESTORE DATABASE command or the RECOVER DATABASE command.
  • Rotation of the database master key without specifying an explicit master key label in the ADMIN_ROTATE_MASTER_KEY procedure.
  • Addition of an encryption key to the keystore explicitly by using the gsk8capicmd GSKit command.

Procedure

Use the following procedure to relocate a keystore file from the IBM Intelligent Operations Center data server to an archival directory on a highly resilient target system.

  1. Identify a suitable, highly resilient target system. Limit physical access to the location or device. Do not use removable or portable devices such as USB keys, removable hard disks, and so on.
  2. On the target system, create both a user and a group named iocarch. The only purpose of the user is to maintain archived copies of the DB2 keystore file, and to limit the iocarch password to a few people. It is important that you use proper access control to limit runtime access to the location or the device.
  3. On the target system, create an archival directory that will contain the DB2 keystore files. For example, create a directory structure similar to the structure created by entering the following command:
    mkdir -p /opt/IBM/ioc/ks_depot
  4. Change ownership of the archival directory to user iocarch, and to group iocarch. The following command changes ownership for the example opt/IBM/ioc/ks_depot archival directory:
    chown -R iocarch:iocarch /opt/IBM/ioc/ks_depot
  5. Change the permissions for the archival directory to 0700. The following command changes permissions for the example opt/IBM/ioc/ks_depot archival directory:
    chmod 0700 /opt/IBM/ioc/ks_depot
  6. Securely copy the keystore file and, optionally, the stash file from the IBM Intelligent Operations Center data server to the archival directory on the target system. Use an appropriate tool, for example, the Secure Copy Protocol (SCP).
  7. Rename the keystore file and the stash file by appending a time stamp to the file name. If you need to restore a database to a previous point in time, you will need to retrieve the keystore file and, possibly, the stash file that was in use at the time when the database backup was created.
  8. Ensure that the permissions on the keystore file and the stash file are set to 0600.