Storage space encryption

You can encrypt storage spaces. The data in encrypted storage spaces is unintelligible without the encryption key. Encrypting storage spaces is an effective way to protect sensitive information that is stored on disk.

You must have IBM® Global Security Kit (GSKit) installed to enable storage space encryption. GSKit is installed by default when you install the database server.

Before you can enable storage space encryption, you must use the onkstore utility to create a keystore file. There are several types of keystore files. A “local” keystore contains the key used by the database server for storage space encryption. An “AWS” keystore file contains credentials that are used to retrieve an encryption key from an Amazon Web Services account.

See The onkstore utility for information on creating and managing keystore files.

Once you have created and verified your keystore file, you enable storage space encryption by setting the DISK_ENCRYPTION configuration parameter and restarting the database server. The value of the DISK_ENCRYPTION parameter is a comma-separated list of attributes, one of which points to your keystore file. For example:
DISK_ENCRYPTION keystore=/work/ifmx/keystores/my_ks,cipher=aes192

See The DISK_ENCRYPTION configuration parameter for information on setting this important value correctly.

Each storage space is encrypted separately with its own encryption key. By default, the encryption cipher is set to AES with 128-bit keys. You can specify a stronger encryption key by including the cipher option in the DISK_ENCRYPTION configuration parameter value.

Any storage space that you create when storage space encryption is enabled is automatically encrypted, unless you explicitly specify to create it as unencrypted. If you initialize a new database server before setting the DISK_ENCRYPTION configuration parameter, the root dbspace is not encrypted. You can, however, encrypt unencrypted storage spaces, including the root dbspace, by running a restore that encrypts the spaces.

Keystore Files May Be Shared

Once you have a valid keystore file, whether a local or network type, it can be used with any number of IDS instances. You are not required to create a new keystore file for an HDR secondary, for example. It can utilize a copy of the keystore file (along with any associated stash file) from the primary, or an entirely different keystore file. There is no forced connection between the encryption keys used for a primary node and HDR or RSS secondaries. However, an SDS secondary must use the same keystore file used by its primary, since they are reading from the same disk. That file may be a duplicate or the same inode, as long as the contents are identical between the file used by the primary and the one used by the SDS secondary.


Copyright© 2019 HCL Technologies Limited