Before you can enable encryption ensure that you
have purchased a license and activated before configuring the function on the system. Enabling the
encryption feature is a nondisruptive procedure. During the procedure, the system continues to
process the I/O operations normally and the existing storage objects are not impacted. The system supports two methods of configuring encryption. You can use a
centralized key server that simplifies creating and managing encryption keys on the system. This
method of encryption key management is preferred for security and simplification of key management.
In addition, the system also supports storing encryption keys on USB flash drives. USB flash drive-based encryption requires physical access to the systems and is
effective in environments with a minimal number of systems. For organizations that require strict
security policies regarding USB flash drives, the system supports disabling these ports to prevent
unauthorized transfer of system data to portable media devices. If you have such security
requirements, use key servers to manage encryption keys.
To encrypt data that is stored on drives, the
control enclosure on which they are connected must contain an active license and be configured to
use encryption.
For systems that also support
self-encrypting drives, the drives also benefit from obtaining a license to protect access to these
drives.
When encryption is activated and enabled on the
system, valid encryption keys must be present on the system when the system unlocks the drives or
the user generates a new key.
If key server encryption is enabled on the system,
the key is retrieved from the key server.If USB encryption is enabled on the system, the
encryption key must be stored on USB flash drives that contain a copy of the key that was generated
when encryption was enabled.
To use
encryption on the system, you must purchase an encryption license, upload certificates, activate the
license on the system, set up your method of key management, and create copies of the keys. If you have not purchased a license,
contact a customer representative to purchase an encryption license.
Before you activate and enable encryption, you must
determine the method of accessing key information during times when the system requires an
encryption key to be present. The system requires an encryption key to be present during the
following operations:
- System power-on
- System restart
- User initiated rekey operations
- System recovery
Several factors must be considered when planning for encryption.
- Physical security of the system
- Additional security requirements for USB ports and portable media. If your environment requires
USB ports to be disabled, use key servers to manage encryption keys.
- Need
and benefit of manually accessing encryption keys when the system requires
- Availability of key data
- Encryption license is purchased, activated, and
enabled on the system
- If
you are using IBM® Security Guardium® Key Lifecycle Manager to create and
manage keys, ensure that you are using version 2.7.0 or later. If you are using version 2.7, the
system supports one master (primary) key server and secondary key servers. However, replication is a
manual process and during rekey operations, keys are not available until replication is completed.
If you use version 3.0 or higher, the system supports multiple master key servers, which
automatically replicates keys to all configured key servers.
- If you are using Gemalto SafeNet KeySecure key servers to create and manage keys, determine whether
the system needs a user name and password to authenticate to the KeySecure key servers. If you plan to
use a username and password to authenticate the system to these key servers, you must configure user
credentials for authentication in the key server management interface. For KeySecure
versions of 8.10 and up, administrators can configure a username and password to authenticate the
system when it connects. Before version KeySecure 8.10, the use of a password is optional.
- If you are using Thales
CipherTrust Manager key server to create and manage keys, determine whether the system needs a user
name and password to authenticate to the CipherTrust Manager key servers. If you plan to use a
username and password to authenticate the system to these key servers, you must configure user
credentials for authentication in the key server management interface. After configuration, you can
select your username from the interface. For more information on migrating key servers, refer to
Migrating from Gemalto SafeNet
KeySecure to Thales CipherTrust Manager key servers
Key server encryption
Key servers provide useful features that make them desirable to use such as being responsible
for encryption key generation, backups, and following an open standard that aids
interoperability. When planning for key server encryption, the following items are important to
consider.
- SSL certificates
- Certificates are the primary method that the key server uses to
authenticate a client (for example,
a system node), and that the client uses to authenticate the key server in order to verify that
access to the keys stored in the key server is permitted. The authentication of the client ensures
that the key server does not give access to keys to any party that is not trusted. The
authentication of the key server ensures that the client does not ask for sensitive keys to be
stored by a party that is not trusted. The system requires a server certificate to allow it to
communicate with the IBM Security Guardium Key Lifecycle Manager server. As
part of the process of provisioning a key server, the user must export the certification authority
(CA) certificate required to authenticate the key server's certificate and install it in the system.
All of the IBM Security Guardium Key Lifecycle Manager key servers can be
configured to use a single CA certificate (which is used for all key severs) or configured so that
each individual key server has its own self-signed certificate. Furthermore, the user must install
the system certificate onto each key server, and the IBM Security Guardium Key Lifecycle Manager administrator can then accept the
certificate to grant the system access to the key server. Implementation of key server encryption
requires that there be an external key server to generate keys and act as a repository for those
keys.
- Spectrum Virtualize and key servers use SSL certificates to authenticate each other and create a
secure connection.
- Certificate can be signed by certificate authorities.
- The correct certificates and certificate authority certificates must be installed in Spectrum
Virtualize and on the key servers.
- Updating the self-signed certificate logs you out of the current session, requiring a fresh
login. Features that use certificate authentication (for example, encryption key servers, IP quorum,
secured IP partnerships, multifactor authentication with IBM Security Verify) will not be able to
establish a secure connection when the self-signed certificate is renewed. The new self-signed
certificate must be exported and added to other devices to re-establish a secure connection.
To configure, Thales CipherTrust Manager, see Configuring encryption with Thales CipherTrust Manager or Gemalto SafeNet KeySecure key servers.
- System requirements
- Only one type of key server is supported at this time. The system implements the Key
Management Interoperability Protocol (KMIP) that is sent over an SSL connection between the client
and the server. Support is provided for self-signed and CA-signed
certificates.
Thales CipherTrust Manager does not support a self-signed system certificate.
Only CA-signed certificates can be used by Thales CipherTrust Manager key servers.
The
system validates the server's SSL certificate and conforms to the KMIP standard. Existing SAS hardware needs access to at least one master key to unlock and needs
to be able to respond to key server master keys.
Enabling key servers for the first time
is a simple procedure. Once key server encryption is enabled, the type can be configured and
enabled, server end-points can be created, and then the keys can be prepared and committed.
- Security requirements
- Security of all key server communications is governed by the TLS
1.2 protocol. Encryption keys
are distributed between nodes in the system using TLS 1.2. The system uses AES-256 encryption that uses OpenSSL library interfaces.
- IP addresses and ports
-
All nodes that want to communicate with key servers must have their service IP address
configured. A node must have its full service IP stack configured (address, gateway, mask)
in order for that node to be a candidate for attempting to contact the key server. Key
servers are typically set up on a private LAN, and this requires enforcement of service IP
addresses. If only a subset of nodes have service IP addresses set, then those nodes without
a service IP address log an error. The IP address that the user supplies must be the one
that
the
system uses to communicate with the key server.
Each key server has a TCP port associated with its access. Since a key server serves
multiple clients,
the
system allows the user to use a different port for each server and enables access for this
port when required. KMIP server conformance mandates that TCP port 5696 be supported, so
this is the default port for the server end point.
- Key generation policy and key database
-
If key server encryption is enabled, then the key server generates and manages the master
keys. The node generates all other keys.
The key database can be clustered or unclustered depending on the type of key server that
is used. For unclustered key servers, the user needs to consider backup and replication of the key
database. IBM Security Guardium Key Lifecycle Manager is an example of a key
server product where replication must be configured in order for encryption keys to be shared
automatically between IBM Security Guardium Key Lifecycle Manager instances.
Without replication configured, manual backup and restore operations must be used. Other products
might self-replicate, so other key server instances automatically have any new keys created. For IBM Security Guardium Key Lifecycle Manager, complete backups and restores by
following the IBM Security Guardium Key Lifecycle Manager user guide.
The
SafeNet KeySecure server and Thales CipherTrust Manager support both clustered and unclustered key
servers configuration.
- Update requirements for key server encryption
-
If encryption was enabled on a pre-7.8.0 code level system and the
system is updated to code level 7.8.x or above, you must run a USB rekey operation to enable
key server encryption. Use the
management GUI or run the
chencryption command before you enable key server encryption. To perform
a rekey operation, use the
management GUI or run the following commands.
chencryption -usb newkey -key prepare
chencryption -usb newkey -key commit
-
The rekey operation must be run after the update is completed to the
7.8.x code level or higher and before you attempt to enable key server encryption.