Brocade Fabric OS Encryption Administrator’s Guide Supporting NetApp Lifetime Key Manager (LKM) and KeySecure Storage Secure Key Manager (SSKM) Environments (Supporting Fabric OS v7.2.0) - Manual (Page 221)

Fabric OS Encryption Administrator’s Guide (LKM/SSKM) 203
53-1002925-01
Turn off host-based encryption
5
Turn off host-based encryption
If a host has an encryption capability of any kind, be sure it is turned it off before using the
encryption engine on the encryption switch or blade. Encryption and decryption at the host may
make it impossible to successfully decrypt the data.
Avoid double encryption
Encryption and decryption at tape drives does not affect the encryption switch or blade
capabilities, and does not cause problems with decrypting the data. However, double encryption
adds the unnecessary need to manage two sets of encryption keys, increases the risk of losing
data, may reduce performance, and does not add security.
PID failover
Virtual device PIDs do not persist upon failover within a single fabric HA cluster. Upon failover, the
virtual device is s assigned a different PID on the standby encryption switch or blade.
Some operating systems view the PID change as an indication of path failure, and will switch over
to redundant path in another fabric. In these cases, HA clusters should not be implemented. These
operating systems include the following:
• HP-UX prior to 11.x. The issue is not present beginning with 11.31 and later releases.
• All versions of IBM AIX, unless dynamic tracking is enabled.
• Solaris 2.x releases, Solaris 7, and later releases.
Turn off compression on extension switches
We recommend disabling data compression on FCIP links that might carry encrypted traffic to
avoid potential performance issues as compression of encrypted data might not yield desired
compression ratio. We also recommend that tape pipelining and fastwrite also be disabled on the
FCIP link if it is transporting encrypted traffic.
Rekeying best practices and policies
Rekeying should be done only when necessary. In key management systems, DEKs are never
exposed in an unwrapped or unencrypted state. For all opaque key management systems, you
must rekey if the master key is compromised. The practice of rekeying should be limited to the
following cases:
• Master key compromise in the case of opaque key vaults.
• Insider security breaches.
• As a general security policy as infrequently as every six months or once per year.
When using LKM/SSKM, DEKs are accessible only to privileged users, and can be compromised
only by an insider breach of security.