Storage space encryption

You can encrypt storage spaces (dbspaces, blobspaces and smart blobspaces) with Informix Dynamic Server. 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.

You can enable storage space encryption by setting the DISK_ENCRYPTION configuration parameter.

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 con"guration 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 with the onspaces utility. If you initialize a new database server before setting the DISK_ENCRYPTION con"guration parameter, the root dbspace and all storage spaces created before setting DISK_ENCRYPTION are not encrypted. However, you can encrypt unencrypted storage spaces, including the root dbspace, by running a restore that encrypts the spaces.

As mentioned above, each storage space is encrypted with its own Space Encryption Key (SEK). The SEKs are generated by the system (oninit) based on a Master Encryption Key (MEK). The MEK is created by the onkstore utility and can be stored locally in the keystore created by the onkstore, or remotely in a Remote Key Server (RKS). In both cases, you must use the onkstore utility to create a keystore that will contain a MEK or the credentials necessary to reach the MEK at a Remote Key Server.

Figure 1. Storage Space Encryprtion
This figure shows storage space encryption.

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

Once you have created and veri"ed your keystore "le, you enable storage space encryption by setting the DISK_ENCRYPTION con"guration parameter to point to the keystore you created and then 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 "le. For example:
DISK_ENCRYPTION keystore=/work/ifmx/keystores/my_ks,cipher=aes192

See The DISK_ENCRYPTION con"guration parameter for information on setting this important value correctly.

Using a locally stored Master Encryption Key

When using a local Master Encryption Key (MEK), the MEK is created locally and stored inside the keystore file pointed by the DISK_ENCRYPTION configuration parameter. In this scenario, the MEK is generated locally by the onkstore and placed inside the keystore file.

Using a remotely stored Master Encryption Key

The Master Encryption Key can also be created and/or stored in a Remote Key Server. Currently, it is possible to use servers that conform with the KMIP standard and also, selected Cloud Providers (Amazon AWS KMS and Azure KeyVault at this moment). If using a Remote Key Server, the credentials necessary to access the Remote Key Server are recorded inside the keystore file pointed by the DISK_ENCRYPTION configuration parameter.

The credentials needed to reach the RKS change depending on the type of RKS you are using. You can see details about this on the description of the onsktore utilty.

If you are using a RKS, there are two options on how we manage the MEK:
  • Option 1: The MEK is stored at the RKS encrypted using a a Remote Master Encryption Key. The Remote Master Encryption Key (RMEK) is a managed key (managed by the RKS) and never leaves the RKS. Currently, we will use this method with AWS-KMS and Azure KeyVault RKS. In the case of AWS, the MEK is generated remotely at the AWS infrastructure. In the case of Azure, the MEK is generated locally. In bothe cases the MEK will the be encrypted with RMEK and the result stored at the Cloud server.
    Figure 2. Method 1 to manage the MEK
    This figure shows the method 1 to manage the MEK.
  • Option 2: The MEK is the Managed Key (Managed by the RKS), its encrypted and protected internally by the RKS. Currently, this method is used with KMIP RKS.
    Figure 3. Method 2 to manage the MEK
    This figure shows the method 2 to manage the MEK.

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, the SDS secondary must use the same keystore file used by its primary, as 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.