Backup data is a potential security risk, especially if the backup tapes are held off-site and out of your control. Anyone who has a copy of the backup program can read those tapes and extract the data, which could be company confidential or maybe customer data that could lead to identity theft. Most countries have data protection laws that would be violated if those backup tapes were intercepted and read.
FDR backups can be protected using FDRCRYPT, a recently released product that interfaces with FDR, FDRDSF, FDRABR and FDRAPPL backup programs. FDRCRYPT makes the backup data unreadable, unless the reader possesses the key to decrypt that data.
You have several options for Key management; you can provide the encryption key yourself and make it consistent for a set of backups or you can use randomly generated keys. Randomly generated keys are different for each disk volser and backup time combination, so they are very secure. The keys are recorded in a key database, and if that key database is available then FDR and FDRABR will read it and automatically decrypt backups for recovery. This means you must have a process to independently store that key database, and retrieve it to your DR site when required. Finally, FDRCRYPT can use master keys that can be used to read encrypted backups if the normal keys are not available. Obviously, the master keys needs to be securely locked away for emergency use only.
Encryption will use CPU resources, and the 'harder' the encryption, the more CPU will be required. FDRCRYPT offers five different levels of encryption so you can get the right balance between security and resource utilisation. Top level encryption is expensive in terms of CPU and elapsed time, and so is not appropriate for all backups.
All of the encryption algorithms are implemented in software within FDRCRYPT modules and do not depend on any other installed encryption hardware or software; this ensures that your data can be decrypted at any disaster site.
FDRCRYPT will automatically use the AES-128 hardware encryption feature that comes with the IBM z9-109, and tapes created using hardware encryption are fully compatible with the FDRCRYPT AES-128 software encryption.
To use encryption you specify the type of encryption required as a keyword on the dump statement
When the backup job runs the job output will indicate that encryption is required
FDR178 BACKUP OF VOL=IDPLB3 COPY=ALL WILL BE ENCRYPTED TYPE=AES128
Another option is to use the default CIPHER encryption as this will reduce CPU and elapsed time. This example uses an optional FDRCRYPT DD statement to specify that a master key will be used for all the encrypted backups created by this job. The value of this master key will be obtained from the RACF security profile facility FDRCRYPT.ABRBKUP, as directed by the MASTERKEYID keyword.
//FDRCRYPT DD *
If you create duplicate backups using TAPEx and TAPExx DD statements you can encrypt one copy only by applying the encryption parameters
to the relevant COPYx statement.
If you want to supply your own encryption/decryption key, you use an optional FDRCRYPT DD statement to code the extra parameters.
FDRCRYPT version 2 can interface with IBM's IDCAMS using an FDRCAMS module. This means you can encrypt the output from a REPRO command for secure external data shipment. The recipient will need the encryption key, and can download a free copy of FDRCAMS to decrypt the received files. To use this, you replace the IDCAMS exec program statement with the FDRCAMS program. This takes standard IDCAMS JCL and parameters, but can encrypt the output from a REPRO statement with AES-128 by default
Be aware that encryption will interfere with tape hardware compression, and you can end up using a lot more tapes. Innovation try to help here by using software compression before encryption. This saves tapes and has the added benefit of making the encryption even harder to crack.
FDRTCOPY and FDRTSEL support encryption, so you can copy an encrypted tape and make an unencrypted copy (if you have the encryption key).
You need to supply the encryption key to a restore job to get your data back and this is usually contained in a keyfile. If the location of that Keyfile is recorded in the ABR Global Options table, and that file is available, then standard recovery jobs can be used. In a Disaster recovery situation, that file would need to be recovered or provided first. Otherwise, each restore job will need an FDRCRYPT DD statement that points to the Keyfile
FDRCRYPT DD DISP=SHR,DSN=name.of.fdrcrypt.keyfile
It is also possible to include the keys as instream JCL statements as shown for AES encryption below. The AESKEY statements will be 32 hexidecimal numbers.
FDRCRYPT DD *