What you should know about security before you install or upgrade the server

Review information about the enhanced security features in the IBM Spectrum® Protect server and the requirements for updating your environment.

Before you begin

Beginning in Version 8.1.2, enhancements were added to IBM Spectrum Protect that enforce stricter security settings. Before you install or upgrade IBM Spectrum Protect, complete the following steps:
  • In IBM® Documentation, in the What's New topic, review the information in the Security sections to learn about security updates for each version.
  • If you have previous versions of the server in your environment, review the restrictions and known issues in technote 562939. To avoid these restrictions and take advantage of the latest security enhancements, plan to update all IBM Spectrum Protect servers and backup-archive clients in your environment to the latest version.
  • Verify that you backed up the following directories and files, which are required to restore the server:
    • Server options file (dsmserv.opt)
    • Device configuration file (for example, devconf.dat)
    • Volume history file (for example, volhist.dat)
    • Master encryption key files (dsmkeydb.kdb or dsmkeydb.sth)
    • Server certificate and private key files (cert.kbd or cert.sth)

Security enhancements

The following security enhancements were added beginning in V8.1.2:
Security protocol that uses Transport Layer Security (TLS)

IBM Spectrum Protect V8.1.2 and later software has an improved security protocol that uses TLS Version 1.2 or later for authentication between the server, storage agent, and backup-archive clients.

Beginning with IBM Spectrum Protect V8.1.11, you can enable the TLS 1.3 protocol to secure communications between servers, clients, and storage agents. To use TLS 1.3, both parties in the communication session must use TLS 1.3. If either party uses TLS 1.2, then both parties use TLS 1.2 by default.

Automatic Secure Sockets Layer (SSL) configuration and distribution of certificates
Servers, storage agents, and clients using V8.1.2 or later software are automatically configured to authenticate with each other by using TLS.

Using the new protocol, each server, storage agent, and client has a unique self-signed certificate that is used to authenticate and allow TLS connections. IBM Spectrum Protect self-signed certificates enable secure authentication between entities, enable strong encryption for data transmission, and automatically distribute public keys to client nodes. Certificates are automatically exchanged between all clients, storage agents, and servers that use V8.1.2 or later software. You do not have to manually configure TLS or manually install the certificates for every client. The new TLS enhancements do not require options changes, and certificates are transferred to clients automatically upon first connection unless you are using a single administrator ID to access multiple systems.

By default, self-signed certificates are distributed, but you can optionally use other configurations such as certificates that are signed by a certificate authority. For more information about using certificates, see Secure Sockets Layer and Transport Layer Security communication.

Combination of TCP/IP and TLS protocols for secure communication and minimal impact to performance
In previous versions of IBM Spectrum Protect software, you had to choose either TLS or TCP/IP to encrypt all communication. The new security protocol uses a combination of TCP/IP and TLS to secure communication between servers, clients, and storage agents. By default, TLS is used only to encrypt authentication and metadata, while TCP/IP is used for data transmission. Since TLS encryption is primarily used for authentication only, performance for backup and restore operations is not affected.

Optionally, you can use TLS to encrypt data transmission by using the SSL client option for client-to-server communication, and the SSL parameter in the UPDATE SERVER command for server-to-server communication.

Backward compatibility makes it easier to plan upgrades in batches
Upgraded versions of IBM Spectrum Protect servers and clients can continue to connect to older versions when the SESSIONSECURITY parameter is set to TRANSITIONAL.

You are not required to update backup-archive clients to V8.1.2 or later before you upgrade servers. After you upgrade a server to V8.1.2 or later, nodes and administrators that are using earlier versions of the software will continue to communicate with the server by using the TRANSITIONAL value until the entity meets the requirements for the STRICT value. Similarly, you can upgrade backup-archive clients to V8.1.2 or later before you upgrade your IBM Spectrum Protect servers, but you are not required to upgrade servers first. Communication between servers and clients that are using different versions is not interrupted. However, you will not have the benefits of the security enhancements until both clients and servers are upgraded.

Enforce strict security with the SESSIONSECURITY parameter
To use the new security protocol, the server, client node, or administrator entities must be using IBM Spectrum Protect software that supports the SESSIONSECURITY parameter. Session security is the level of security that is used for communication among IBM Spectrum Protect client nodes, administrative clients, and servers. You can specify the following values for this parameter:
Enforces the highest level of security for communication between IBM Spectrum Protect servers, nodes, and administrators, which is currently TLS 1.2.
Specifies that the existing communication protocol (for example, TCP/IP) is used until you update your IBM Spectrum Protect software to V8.1.2 or later. This is the default. When SESSIONSECURITY=TRANSITIONAL, stricter security settings are automatically enforced as higher versions of the TLS protocol are used and as the software is updated to V8.1.2 or later. After a node, administrator, or server meets the requirements for the STRICT value, session security is automatically updated to the STRICT value, and the entity can no longer authenticate by using a previous version of the client or earlier TLS protocols.
If SESSIONSECURITY=TRANSITIONAL and the server, node, or administrator has never met the requirements for the STRICT value, the server, node, or administrator will continue to authenticate by using the TRANSITIONAL value. However, after the server, node, or administrator meets the requirements for the STRICT value, the SESSIONSECURITY parameter value automatically updates from TRANSITIONAL to STRICT. Then, the server, node, or administrator can no longer authenticate by using a version of the client or an SSL/TLS protocol that does not meet the requirements for STRICT.
Restriction: After an administrator successfully authenticates with a server by using IBM Spectrum Protect V8.1.2 or later software or Tivoli® Storage Manager V7.1.8 or later software, the administrator can no longer authenticate with the same server by using client or server versions earlier than V8.1.2 or V7.1.8. This restriction also applies to the destination server when you use functions such as command routing, server-to-server export that authenticates with the destination IBM Spectrum Protect server as an administrator from another server, administrator connections using the Operations Center, and connections from the administrative command-line client.
For client and administrative sessions, administrative command routing sessions might fail unless the administrator ID has already acquired certificates for all servers to which the administrator ID will connect. Administrators that authenticate by using the dsmadmc command, dsmc command, or dsm program cannot authenticate by using an earlier version after authenticating by using V8.1.2 or later. To resolve authentication issues for administrators, see the following tips:
  • Ensure that all IBM Spectrum Protect software that the administrator account uses to log on is upgraded to V8.1.2 or later. If an administrator account logs on from multiple systems, ensure that the server's certificate is installed on each system.
  • If necessary, create a separate administrator account to use only with clients and servers that are using V8.1.1 or earlier software.

Before you upgrade

Before you upgrade a server, review the guidelines in the following checklist.
Table 1. Planning checklist
Guideline Description
Back up the following server files:
  • Key databases (cert.kdb and dsmkeydb.kdb)
  • Stash files (cert.sth and dsmkeydb.sth)

Beginning with IBM Spectrum Protect Version 8.1.2, a master encryption key is automatically generated when you start the server if the master encryption key did not previously exist.

The master encryption key is stored in a key database, dsmkeydb.kdb. Server certificates are still stored in the cert.kdb key database and accessed by the stash file cert.sth. You must protect both the key databases (cert.kdb and dsmkeydb.kdb) and the stash files (cert.sth and dsmkeydb.sth) that provide access to each of the key databases. By default, the BACKUP DB command protects the master encryption key in the same manner in which the volume history and devconfig files are protected. You must remember the database backup password to restore the database. The IBM Spectrum Protect server dsmserv.pwd file, which was used to store the master encryption key in previous releases, is no longer used.

Carefully plan upgrades for administrator IDs Identify all systems that administrator accounts use to log in for administration purposes.
After a successful authentication to V8.1.2 or later software, administrators cannot authenticate to earlier versions of IBM Spectrum Protect software on the same server. If a single administrator ID is used to log in to multiple systems, plan to upgrade all of those systems with V8.1.2 or later software to ensure that the certificate is installed on all systems that the administrator logs in to.
Tip: You will not get locked out of a server if the SESSIONSECURITY parameter for all of your administrator IDs is updated to the STRICT value. You can manually import the server’s public certificate to a client from which you issue the dsmadmc command.
If you're using TLS with previous versions of the client that use the TSM Server SelfSigned Key (cert.arm) certificate, update your clients to V8.1.4 or later. In releases prior to V7.1.8, the default certificate was labeled TSM Server SelfSigned Key and had an MD5 signature, which does not support the TLS 1.2 or later protocol that is required by default for V8.1.2 or later clients and the Operations Center. To resolve this issue, complete one of the following steps:
  • Upgrade the server to V8.1.4 or later. Beginning with V8.1.4, servers that use the MD5-signed certificate as the default are automatically updated to use a default certificate with a SHA signature that is labeled TSM Server SelfSigned SHA Key. A copy of the new default certificate is stored in the cert256.arm file, which is located in the server instance directory.
    Tip: Before you update the server to use the new default certificate with a SHA signature, distribute the cert256.arm file to clients to prevent client backup failures. Each client must obtain and import the new certificate before they can connect to a server that is using the new default SHA certificate. You do not need to remove previous certificates.
  • To manually update your default certificate, follow the instructions in technote 562939.

What to do next