Updated June 2020
New related features regarding Informix storage and backup encryption are available in IDS 14.10 and described in other Oninit articles.
Abstract
GDPR is causing many companies to revise their policies regarding data privacy, and encrypting data may help meet some of the requirements. Fortunately, storage space (dbspace) encryption (otherwise known as “Encryption at rest” or EAR) is a very easy-to-use feature available in all Informix Dynamic Server (IDS) editions since version 12.10.xC8. No application changes are required.
This should be combined with encryption of backups – both archives and logical logs – whether created via “onbar” or “ontape”:
- Prior to IDS 10, this had to be performed after backup files had been created.
- IDS 10 allowed backup or restore via any pipe with “ontape -t STDIO”, but only for archives.
- From IDS 11, configuration parameters exist to pass all backups and restores through specified filter commands, which is ideal for in-line compression and encryption.
This article explains the steps involved in implementing both storage and backup encryption (using method 3 above) on supported IDS versions.
Content
All commands shown below should be run as user “informix”.
For storage encryption, first make sure that the IBM Global Security Kit (GSKit) is set up. For example, the installer is present but not yet run in either of these free Docker images:
https://hub.docker.com/r/ibmcom/informix-innovator-c
https://hub.docker.com/r/ibmcom/informix-developer-database
You can fix that with:
It doesn’t seem to cause any harm if the above is repeated unnecessarily. Note that the installed GSKit location varies with platform, for example:
Linux: /usr/local/ibm/gsk8_64 AIX: /usr/opt/ibm/gsk8_64
Next, you need to add a line such as this to the $INFORMIXDIR/etc/$ONCONFIG file:
The exact line above is recommended which automatically handles multiple instances. For example, if the Informix server name is “test”, the following files will be created automatically in the same directory:
There are other options that can be appended, but none of them essential:
www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/ids_adr_1199.htm
The default cipher is 128-bit AES.
If the above is in place before you first initialize an instance for the first time with “oninit -iv”, all dbspaces will be encrypted from the outset.
If you wish to encrypt all dbspaces for an existing instance, set up the above and then perform a level 0 archive, stop the instance, and restore it again specifying encryption. For example, using “ontape” with a directory in configuration parameter TAPEDEV, these are the necessary commands:
Note that, should you need to perform a cold restore of a previously encrypted instance, it will fail unless the key files are removed beforehand with:
Should you wish to have only some dbspaces encrypted, this can be achieved by using the “onspaces” command to create individual dbspaces with or without the “-u” (unencrypted) option, for example:
www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/ids_adr_0466.htm.
You can check which dbspaces are encrypted with “onstat -d”, which shows “E” in the “flags” column where applicable (whereas “E” would mean “expandable” in the second “Chunks” list):
www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/ids_adr_0504.htm
Backup encryption is equally straightforward. This article assumes the use of “openssl” as it is the most portable tool, for example it’s available as standard on both Linux and AIX. The main alternative on Linux is “pgp”, but no binary installer exists at this time for AIX 7.
We first need to create a file in a secure location containing the encryption password on one line:
The contents entered with “vi” above could be 128 bytes randomly generated here:
www.browserling.com/tools/random-string
Next, create a filter script with two names as follows:
The shell script contents entered with “vi” above could be as follows:
Finally, set configuration parameters to use the above automatically:
The new settings entered with “vi” above should be:
The solution above assumes that, as well as encryption, “gzip” compression is desired, as it often is.
On later versions of “openssl”, you may find the “-z” option is supported which similarly performs compression with the “zlib” library. This would reduce the number of processes and in theory make it possible to do without the shell script.
Otherwise, pipe symbols in BACKUP_FILTER or RESTORE_FILTER cause the operation to fail, even if quoted as documented, so there is no choice but to have a script. There are in any case other advantages, such as having the cipher details and password location defined once, and the latter not accessible to other users with “ps -f”.
On larger systems with many CPU cores, consider compiling and using the much faster multi-threaded implementation of “gzip” available here:
The cipher chosen in the filter script is 128-bit AES (the same as the DISK_ENCRYPTION default). It uses around 10% of the CPU used by “gzip” during a backup and 50% during a restore. You could go up to 256-bit with a modest performance penalty.
Caveats
You obviously need to copy encryption key files from $INFORMIXDIR/etc to another secure location any time they change. Otherwise:
- If the disk encryption key files (*.p12 and *.stm) were lost, Informix would stay running as the keys are cached, but you would be unable to restart the instance without a full restore.
- If the backup encryption key file (.openssl/*) was lost, you could recreate it with new contents, but you would not be able to restore from previous backups.
Beware that setting BACKUP_FILTER and RESTORE_FILTER for whatever purpose causes the “archecker” and “onlog” tools to fail prior to IDS 11.50.xC7W1 due to defects such as:
IC68956 Reading of archived logical logs using the onlog utility does not work if BACKUP_FILTER /usr/bin/gzip is used
Conclusion
Assuming a small CPU overhead is acceptable, there is every reason to implement storage and backup encryption if your databases contain personal or sensitive data. Everything you need to know is given in this article, and it’s not that difficult to implement.
Disclaimer
Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.
Contact us
If you have any questions regarding Informix storage and backup encryption, or would like to find out more, simply contact us.
