Keystore best practices
Employ security best practices to keep your keystores and master keys secure.
- A prompt for operator input of the credentials
- Access through a provided file argument
- Use of a “stash” file
When creating or changing passwords for local keystone files, ensure that the passwords are strong, by using the –strong parameter of the gsk8capicmd_64 command. For more information about the full syntax of the gsk8capicmd_64 command, see: GSKCapiCmd Users Guide.
The keystore configuration files are not included as part of a Db2 database backup and must be backed up manually. Keystore credentials, if stored on disk, must also be backed up manually.
For local keystore files, the configuration file is not included as part of a Db2 database backup and must be backed up manually.
For a centralized keystore, consult the documentation for your keystore product to understand their recommendations for keystore backups.
MK label uniqueness
Db2 uses the MK label to uniquely identify each MK, and stores the label value in each encrypted object, be it a database, transaction log, or backup file. This stored label value identifies the MK that is used to decrypt the data encryption key (DEK), which is used to encrypt the data in the object. It is critical to use unique MK labels to avoid duplication. If unique labels are not used, access to encrypted data can be lost. Access to encrypted data is lost when the MK that is retrieved from the keystore for a label is different from the MK that is used to encrypt the DEK in the object.
Master key retention
MKs are needed to access the DEKs that are stored in encrypted databases, transaction logs, and backup images. Since multiple MKs can exist over the life time of these objects, it is necessary to retain them while the encrypted data is retained. Therefore, do not delete MKs from the keystore.
Keystore configuration changes
Thoughtful planning needs to precede any changes to the Db2 database managed
keystore configuration parameters or the contents of a keystore configuration, as not all changes
can be completed online. Each new key request reads these values when it is accessing the keystore.
With some exceptions, changes to these configuration values are reflected in the Db2 processing on the
next key request. Although the Db2 database manager
configuration parameters keystore_type and keystore_location are configurable online, you should set them in the a single
update dbm cfg command. Otherwise, Db2 might attempt to
access the keystore between the updates and report an access error. Changes to the SSL_KEYDB,
SSL_KEYDB_STASH, and SSL_KMIP_CLIENT_CERTIFICATE_LABEL keystore configuration values require an
instance restart to take effect. Changes to the LIBRARY keystore configuration value do not take
effect until Db2 is restarted.
Similarly, if the configuration value is not changed, changes to the physical copy of the library do
not take effect until Db2 is restarted. As
access the keystore periodically, it is highly recommended that you stop Db2 when making
configuration changes, to avoid potential errors. If a mixture of encrypted and unencrypted
databases exists under the same instance, it is sufficient to quiesce those databases that are
- 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