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 Levels
Encryption will use CPU resources, and the 'harder' the encryption, the
more CPU will be required. FDRCRYPT offers four 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.
SUBSTITUTION combined with compression will protect from unsophisticated
attacks, and has a relatively small CPU overhead. It uses a 128-bit
encryption key to generate a 256-byte substitution table, where each
byte value in the backup data block (after compression) is translated
to a different unique byte value.
CIPHER requires a bit more resource than Substitution, but is very
difficult to crack. It uses the same byte replacement as Substitution
but then adds transposition, so every byte is relocated to a different
place within a backup data block making it very difficult to detect
patterns within the encrypted data.
AES is very resource intensive but there is no record of it every
being cracked. It is the current standard for US Government encryption
and should be used for critically sensitive data, or information that
is specifically subject to an AES compliance requirement.
AESFAST requires 50-60% of the processing of the standard AES process.
It does not meet the official AES specification, but is still believed
to be very secure. It is appropriate for data that requires a very high
level of security while not demanding AES compliance.
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.
Invoking Encryption
To use encryption you specify the type of encryption required as a keyword
on the dump statement
DUMP TYPE=FDR,ENCRYPT=ALL,ENCRYPTTYPE=AES128
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
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.
Innovation plans to add encryption algorithms to FDRSOS and FDR/UPSTREAM
as chargeable options in future.
As a nice little extra, 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.
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).