IBM Tivoli Storage Manager Building A Secure Environment Sg247505

Front cover
IBM Tivoli Storage Manager Building a Secure Environment
Are you as safe as you think you are?
Understanding security threats
Si noitpyrcne thgir rof ouy?
Charlotte Brooks Lloyd Dieter Dan Edwards Helder Garcia Carsten Hahn Matthew Lee
ibm.com/redbooks
International Technical Support Organization IBM Tivoli Storage Manager: Building a Secure Environment June 2007
SG24-7505-00
Note: Before using this information and the product it supports, read the information in Notices on page xiii.
First Edition (June 2007) This edition applies to Version 5.4 of IBM Tivoli Storage Manager (5608-ISM) and IBM Tivoli Storage Manager Extended Edition (5608-ISX).
Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Overview of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Why is security important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Why is Tivoli Storage Manager security important . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Tivoli Storage Manager security objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 How is Tivoli Storage Manager security implemented . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Types of threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Threats from within the organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2 Threats from outside the organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.3 Threats to physical storage of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.4 Threats when data is transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Data transport methodologies with Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . 7 1.5.1 Review of the Open Systems Interface data model . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5.2 Interfacing networks together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5.3 A review of OSI Layer 1 - Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.4 A review of Fibre Channel technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.5 A review of VPN technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5.6 Networking summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6 Tivoli Storage Manager data movement and storage . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6.1 On-site data movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.6.2 Off-site data movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6.3 Server-to-server data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.7 Introduction to encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.7.1 Symmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.7.2 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.7.3 Certificates, keystores, and key managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.8 Tivoli Storage Manager client data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.8.1 DES56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.8.2 AES128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.9 Tape encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Part 1. Tivoli Storage Manager client considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Chapter 2. Client sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Client authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Command line authentication flow (non-root user) . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Command line and scheduler authentication flow (root user) . . . . . . . . . . . . . . . . 2.1.3 Web access authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Communication between the server and the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 24 24 25 25 26
Copyright IBM Corp. 2007. All rights reserved.
iii
2.2.1 Session types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Multi-session and transaction data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Multi-session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Client thread types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3. Client files and services management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Access controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Types of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Ownership and access permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Mapping allowable tasks to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Protecting the UNIX and Linux client files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 The client services and daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Running services on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Running services on UNIX or Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Shared drives and file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Windows shared drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 UNIX and Linux Network File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4. Securing the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Client authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Password processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Registering nodes without an administrator ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 Password rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Command action schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Pre and post commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Authority of scheduled commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Scheduled restores and retrieves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Access restriction by user or group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Cross client restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Restoring your data to another workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Restoring data from another workstation locally . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Proxy nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Manipulating node objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.1 Deactivated nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.2 Renaming nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Controlling client options from the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.1 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 Operating system and network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27 28 28 29 31 33 34 34 39 43 45 47 48 51 52 52 56 59 60 60 61 65 67 68 68 69 69 69 70 70 70 72 73 74 74 75 76 77 77 77 78
Part 2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Chapter 5. Tivoli Storage Manager client data encryption . . . . . . . . . . . . . . . . . . . . . . 5.1 Client encryption primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Encryption of session traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Encryption of data traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Platforms that can use client data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Advantages of client side data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Considerations for client side data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Using data encryption with client compression . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
IBM Tivoli Storage Manager: Building a Secure Environment
81 82 82 83 87 87 88 88
5.3 Backup/archive client encryption key management . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.1 Session keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.2 Data encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4 Data encryption using the backup/archive client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.4.1 Enabling encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.4.2 Include and exclude statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.4.3 PASSWORDACCESS and ENCRYPTKEY interaction . . . . . . . . . . . . . . . . . . . . 91 5.4.4 Backup/archive client session examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.4.5 Verifying that backed up data is encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.5 Data encryption using the API client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.5.1 API application-managed encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.5.2 API transparent encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.5.3 Verifying that API data is encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.6 Performance observations of the backup/archive client . . . . . . . . . . . . . . . . . . . . . . . 105 5.7 Upgrading the level of the Tivoli Storage Manager client . . . . . . . . . . . . . . . . . . . . . . 112 5.8 Changing the client host name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.9 Encryption and hierarchical storage management clients. . . . . . . . . . . . . . . . . . . . . . 112 5.10 Encryption and LAN-free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Chapter 6. TS1120 Tape encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Introduction to TS1120 encryption options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 IBM System Storage TS1120 Tape Drive overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 TS1120 tape drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Encryption Key Manager (EKM) software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Encryption policy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Tivoli Storage Manager with AME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.5 Tivoli Storage Manager with LME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.6 Tivoli Storage Manager with SME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Encryption on a TS3500 Tape Library with ALMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Configuration with different encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 AME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Configuring EKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Device configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 LME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 SME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 EKM server backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 EKM server disaster recovery considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Recommended best practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 114 115 115 116 119 121 123 124 125 126 126 129 140 141 147 152 152 153 155
Part 3. Tivoli Storage Manager server considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Chapter 7. Server administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Security concerns for the Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . 7.2 Overview of Tivoli Storage Manager administrator roles. . . . . . . . . . . . . . . . . . . . . . . 7.2.1 No authority granted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.5 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.6 Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.7 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.8 Administrator IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.9 Special administrator IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
159 160 160 160 160 161 163 166 167 167 168 169 v
7.2.10 Server options related to administrative privilege . . . . . . . . . . . . . . . . . . . . . . . 7.3 A typical implementation of administrator roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Maintaining an audit trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Activity log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Server summary table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Accounting records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.4 Event receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Controlling access to the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Commands and options affecting the entire server. . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Commands and options that affect client nodes . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Session control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Using the server to manage operations on a client node . . . . . . . . . . . . . . . . . . . . . . 7.6.1 General considerations for scheduled client operations . . . . . . . . . . . . . . . . . . . 7.6.2 Session initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Securing a network of Tivoli Storage Manager servers. . . . . . . . . . . . . . . . . . . . . . . . 7.8 Encryption for server-to-server communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.1 Server-to-server session setup encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.9 Command routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10 Virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11 Using a configuration manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11.1 Security aspects of profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11.2 Administrator ID management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11.3 Policy management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11.4 Other profile associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.12 Security considerations for exports and backup sets . . . . . . . . . . . . . . . . . . . . . . . . 7.13 Administrator roles and Operational Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.13.1 Operational Reporting overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.13.2 Operational Reporting connections to the Tivoli Storage Manager server . . . . 7.14 Integrated Solutions Console security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.14.1 Adding administrators to the ISC/Administration Center. . . . . . . . . . . . . . . . . . 7.14.2 Connecting ISC and Tivoli Storage Manager administrator IDs . . . . . . . . . . . . 7.15 ISC/AC communication security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.15.1 Web browser link to ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.15.2 ISC/AC to Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16 Setting up SSL for the ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.1 Overview of the required steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.2 Create key and trust files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.3 Create the JACL script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.4 Modify wsadmin.properties to reflect the correct SOAP port . . . . . . . . . . . . . . 7.16.5 Run wsadmin on the JACL script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.6 Modify the ConfigService.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.7 Modify the web.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.8 Stop the ISC portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.9 Modify the soap.client.props file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.16.10 Start the ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 8. Storage pool considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Storage pool overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Primary storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 Copy storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3 Active-data storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 How is data written to storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Disk storage pool volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
170 172 172 173 174 176 177 181 181 183 184 185 185 186 188 188 189 191 191 194 194 195 196 197 197 198 199 199 202 202 205 207 207 208 210 210 210 221 222 223 223 223 224 224 224 227 228 228 228 228 228 229
vi
8.2.2 Tape storage pool volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Encrypted data in storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Tivoli Storage Manager client encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Tivoli Storage Manager tape encryption usage. . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Data shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 Why use data shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 Setting up shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 Storage pool shredding considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 How to protect your data in storage pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 9. Deployment in a network secured environment . . . . . . . . . . . . . . . . . . . . 9.1 What is a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Tivoli Storage Manager clients in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 TCP/IP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.2 Example configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.3 Initiating scheduled sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.4 Server-initiated sessions: Configuration example . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Sample configurations and best practice recommendations. . . . . . . . . . . . . . . . . . . . 9.3.1 Tivoli Storage Manager server in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Tivoli Storage Manager server not in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.3 Tivoli Storage Manager server in a dedicated network in the DMZ . . . . . . . . . . 9.3.4 Backing up clients of different security levels on the same server . . . . . . . . . . . Chapter 10. Protecting the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Security policy considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Operating system security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 UNIX and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Network security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 Wired network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.2 Wireless network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Security assessment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 Human aspects of security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.1 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7 Environmental considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8 High availability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9 Change management considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.10 Security audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.11 Tivoli Storage Manager server running as a non-root user . . . . . . . . . . . . . . . . . . . 10.11.1 Why run as a non-root user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.11.2 Set up the non-root user environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.11.3 Scripts to start and stop the Tivoli Storage Manager service . . . . . . . . . . . . . 10.11.4 Location of Tivoli Storage Manager files for disaster recovery . . . . . . . . . . . . 10.12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
230 236 236 237 237 238 239 243 244 247 248 248 249 251 252 254 262 262 262 263 263 265 266 266 267 268 269 270 270 273 274 276 276 277 277 278 278 279 280 282 287 290 290
Part 4. Recovery scenarios and summarized guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Chapter 11. Providing a secure disaster recovery environment. . . . . . . . . . . . . . . . . 11.1 Disaster recovery planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Seven tiers of disaster recovery solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Off-site data vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Choosing a balance between cost and security . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Hot site and security (BC Tier 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
293 295 295 298 298 300 vii
11.2.3 Warm site and security (BC Tier 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.4 Cold site and security (BC Tier 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.5 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Data encryption and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.1 No data encryption used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2 Tivoli Storage Manager-provided encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 System-managed encryption and library-managed encryption. . . . . . . . . . . . . 11.3.4 Off-site encryption key and password handling . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Tape and data security using SAN access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Virtual volumes and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5.1 A review of virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6 Database backup security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 Copy storage pool security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8 Backup set security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.9 Active-data pool security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10 Tivoli Continuous Data Protection security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.11 Special tape topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.11.1 If a tape is scratched or overwritten, can you still access older data . . . . . . . 11.11.2 Erasing or destroying media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.12 Best practices for off-site data vaulting and security . . . . . . . . . . . . . . . . . . . . . . . . Chapter 12. Recovery and prevention of security breaches or data loss . . . . . . . . . 12.1 Legal and compliance issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Missing storage pool volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.1 Missing copy storage tape volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.2 Missing primary storage pool tape volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.3 Missing active-data storage pool tapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.4 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 A missing or stolen database backup tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Stolen Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Missing client backup set tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.6 Unauthorized tape drive and library and data access . . . . . . . . . . . . . . . . . . . . . . . . 12.7 Encryption-related recovery topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7.1 A lost, forgotten, or destroyed client encryption key . . . . . . . . . . . . . . . . . . . . . Chapter 13. Guidelines for audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6 Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.7 People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.8 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.9 Categorize your data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
301 302 303 303 304 304 307 308 309 309 310 311 311 312 313 314 314 314 315 316 319 320 320 320 323 325 328 328 330 332 333 334 334 335 336 336 336 337 337 338 338 338 339 341 341 341 342 343 343
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 viii

Figures
1-1 Open Systems Interface (OSI) Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1-2 Interfacing between networks using repeaters, hubs, bridges, switches, and routers . . 9 1-3 OSI Layer 1 - Physical connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1-4 Fiber optic cables: single-mode and multi-mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1-5 VPN with IPSec over an Internet connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1-6 Tivoli Storage Manager on-site data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1-7 DRM off-site rotation to an external vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1-8 Symmetric key encryption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1-9 Asymmetric key encryption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2-1 Non-root dsmc authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2-2 Tivoli Storage Manager dsmc authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2-3 Tivoli Storage Manager Java Applet-dsmagent authentication flow . . . . . . . . . . . . . . . 26 2-4 Producer-Consumer model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2-5 Producer - Consumer transaction handling and multithreaded backup . . . . . . . . . . . . 30 2-6 Transaction processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3-1 Manage auditing and security log Security Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3-2 Ownership of backed up objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3-3 Ownership of archived objects for non-authorized users . . . . . . . . . . . . . . . . . . . . . . . 41 3-4 Ownership of archived objects for authorized users . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3-5 Authorization check to access objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3-6 Tivoli Storage Manager basic services on Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3-7 Check disk quota restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3-8 Changing the logon properties of a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3-9 System State backup on Windows Server 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3-10 Registry backup on Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4-1 Log-in process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4-2 Password encrypted on Windows Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4-3 Using node name authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4-4 Using Web Client and Administrator validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4-5 Restoring data to another workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4-6 Restoring files from other workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4-7 Proxy node configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4-8 Preventing include option from client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5-1 GUI encryption key password dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5-2 Registry entry for encryption key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5-3 Prompt during backup if saved encryption key is not present. . . . . . . . . . . . . . . . . . . . 94 5-4 Prompt during restore if saved encryption key is unavailable . . . . . . . . . . . . . . . . . . . . 95 5-5 Error when invalid key is presented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5-6 Prompt during backup if saved encryption key is not present. . . . . . . . . . . . . . . . . . . . 96 5-7 Prompt during restore-saved if encryption key is unavailable. . . . . . . . . . . . . . . . . . . . 97 5-8 Error when invalid key is presented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5-9 Unencrypted data sent from API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5-10 Portion of an encrypted data packet sent through the API using dapismp . . . . . . . . 105 5-11 CPU utilization for test one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5-12 CPU utilization for test two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5-13 CPU utilization for test three with AES128 encryption . . . . . . . . . . . . . . . . . . . . . . . 110 5-14 CPU utilization for test four with AES128 encryption . . . . . . . . . . . . . . . . . . . . . . . . 111 6-1 TS1120 encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ix
6-2 Logical diagram of the TS1120 tape drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 EKM uses both symmetric and asymmetric encryption keys . . . . . . . . . . . . . . . . . . . 6-4 Encryption data flow for the AME process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 Decryption data flow for the AME process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6 Library-managed tape encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 Key and policy flow in a SME environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 Output from Library Specialist indicating tape J12457 is encrypted . . . . . . . . . . . . . . 6-9 Adding EKM server TCP/IP addresses to Tape specialist . . . . . . . . . . . . . . . . . . . . . 6-10 Ping connectivity test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 Output indicating successful ping of the EKM server from the tape library. . . . . . . . 6-12 Example of logical libraries within the Tape Specialist . . . . . . . . . . . . . . . . . . . . . . . 6-13 Example of how to enable the logical library for LME . . . . . . . . . . . . . . . . . . . . . . . . 6-14 Library 20-33 has been enabled with the LME method . . . . . . . . . . . . . . . . . . . . . . 6-15 Barcode encryption policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16 Tape SJ0011 is not encrypted before it is used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17 Output from the Tape Specialist after the archiving test . . . . . . . . . . . . . . . . . . . . . . 6-18 Tape Specialist configuring the logical library with SME. . . . . . . . . . . . . . . . . . . . . . 6-19 Two EKM servers with a shared configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Web client error from missing node authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Web client error with locked administrator ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Server ACTLOG table columns and descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Server summary table fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Format of data that is written using filetextexit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 Administrative command logged to application event log . . . . . . . . . . . . . . . . . . . . . . 7-7 Web client error when SERVERONLY initiation is specified. . . . . . . . . . . . . . . . . . . . 7-8 Setup for server-to-server tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9 Data packet when using server-to-server virtual volumes . . . . . . . . . . . . . . . . . . . . . 7-10 Tivoli Storage Manager server network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11 Automatic entry for local Tivoli Storage Manager server on Windows . . . . . . . . . . . 7-12 Setting the administrator ID in Operational Reporting . . . . . . . . . . . . . . . . . . . . . . . 7-13 Wizards in the Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 ISC/AC user and group management panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15 Add user dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16 Newly added ISC/AC administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17 Users and group management menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18 All portal user groups menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Iscadmins group menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20 Add server connection menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Dialog for creating server connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22 Successful server connection definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23 ikeyman utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24 Server key file name and location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25 Password prompt for server key file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26 Create a new self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27 Self-signed certificate menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28 Successful creation of personal self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . 7-29 Extract Certificate button. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30 Enter the file name and location for the extracted server certificate . . . . . . . . . . . . . 7-31 Setting the name for the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32 Password prompt for the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33 Add a new certificate to the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34 Specifying the server certificate to import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35 Successful import of server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
116 117 122 122 124 125 129 140 140 141 141 142 142 143 144 145 148 152 168 168 173 175 179 181 187 189 193 194 200 200 201 202 203 203 204 204 205 206 207 207 211 211 212 212 213 213 214 214 214 215 215 216 216
7-36 Creating another key file for the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37 Enter file name and directory path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38 Password prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39 Create a new self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40 Values for the client self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-41 Successful creation of client key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42 File name for exported client key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43 File name for client trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-44 Password for client key trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-45 Selecting the client key to import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-46 Enter the label for the certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47 URL for successful SSL connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48 SSL-enabled session indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Word.doc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2 How data shredding works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1 A sample DMZ configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2 Overview of TCP/IP parameters in dsm.opt and dsmserv.opt . . . . . . . . . . . . . . . . . . 9-3 Prevent administrative access through a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4 Dedicated network for backup in DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Packet filtering firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Circuit level gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Application firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4 Stateful Inspection firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1 Seven tiers of disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2 Production and hot site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 Production and Warm site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4 Server-to-server virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
217 217 218 218 219 219 220 220 220 221 221 225 225 234 238 248 250 252 263 271 271 272 272 295 301 302 310
Figures
xi
xii
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
xiii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
Redbooks (logo) i5/OS z/OS AIX 5L AIX Domino DB2 DFSMS FlashCopy GDPS GPFS HyperSwap HACMP IBM Lotus MQSeries Netcool OS/400 Redbooks System i System p System z System Storage Tivoli Enterprise Tivoli Enterprise Console Tivoli TotalStorage
The following terms are trademarks of other companies: SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries. Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates. Snapshot, NetApp, and the Network Appliance logo are trademarks or registered trademarks of Network Appliance, Inc. in the U.S. and other countries. IT Infrastructure Library, IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Java, JRE, Solaris, Streamline, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Active Directory, Excel, Microsoft, MSDN, Windows NT, Windows Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
xiv
Preface
Many people want to be famous, but nobody wants to hit the headlines in an incident resulting in the theft or misuse of their employees or clients confidential data. While the necessity of securing the confidentiality, integrity, and availability of the enterprises servers and data is well-known and understood, the backup server is often overlooked in the security planning. This is very regrettable, because the backup server infrastructure stores copies of all the enterprises most important data, often going back years. Valuable data is often copied to tape and transported off-site. These tape cartridges are highly portable and hence potentially vulnerable to loss or theft. Knowing all this, the backup server and its infrastructure can represent a highly attractive target of unauthorized access from either inside or outside your data center. How secure is your backup server and its disk arrays? Do you know where each and every one of your backup tapes is located - right now? This book will take you through the various security features of Tivoli Storage Manager and show you how to use them, together with best practice principles, to design, implement, and administer a more secure backup management environment. We will cover passwords, administrative levels of control, the vital role of encryption, and procedures for managing off-site data, among other topics. This book is targeted at experienced Tivoli Storage Manager administrators. We assume that you have a good knowledge of how Tivoli Storage Manager works and how to install and administer it. You can use the publications listed in the Bibliography as background reading, particularly, IBM Tivoli Storage Management Concepts, SG24-4877, and IBM Tivoli Storage Manager Implementation Guide, SG24-5416.
The team that wrote this book

This book was produced by a team of specialists from around the world working at the International Technical Support Organization, San Jose Center. Charlotte Brooks is an IBM Certified IT Specialist and Project Leader for Tivoli Storage and System Storage Solutions at the International Technical Support Organization, San Jose Center. She has 15 years of experience with IBM in storage hardware and software support, deployment, and management. She has written many IBM Redbooks publications, and has developed and taught IBM classes in all areas of storage and storage management. Before joining the ITSO in 2000, she was the Technical Support Manager for Tivoli Storage Manager in the Asia Pacific Region. Lloyd Dieter is a Systems Engineer for Strategic Computer Solutions in Syracuse, NY. He has been in IT since 1983 and has been consulting extensively and performing IBM Tivoli Storage Manager implementations on a variety of platforms since 1998. He is an IBM Certified Advanced Technical Expert (CATE) with certifications in Tivoli Storage Manager, HACMP, and AIX. He previously co-authored Using TSM in a SAN Environment, SG24-6132. Dan Edwards is a Consulting I/T Specialist with IBM Global Services, Global Technology Services, based in Ottawa, Canada. Dan has over 29 years experience in the computing industry, including 17 years spent working on UNIX, High Availability, Tivoli Storage Manager (ADSM), and other storage solutions. He holds multiple product certifications, including Tivoli Storage Manager, AIX, HACMP, and Oracle. He is also an IBM Certified Professional and a member of the I/T Specialist Certification Board. Dan contracts with IBM
xv
clients globally, and over the past five years, has primarily consulted on Tivoli Storage Manager, High Availability, and Disaster Recovery engagements. Dan has previously co-authored IBM Tivoli Storage Manager in a Clustered Environment, SG24-6679, among others. Helder Garcia is an IT Specialist for IBM Brazil, based in Braslia. He has six years experience with Tivoli Storage Manager working with IBM accounts in Brazil, and 16 years in the IT industry, with a strong background in network protocols and management. Before joining IBM in 2005, Helder worked since 1999 with Tivoli products for an IBM Business Partner in Brazil. His areas of expertise include consulting, planning, and implementation of IBM Tivoli Storage Manager backup solutions and storage management, and he has also taught Tivoli Storage Manager classes for clients and IBM Business Partners. He is an IBM Certified Deployment Professional for Tivoli Storage Manager V5.2 and V5.3, and has the ITIL Foundation Certificate. Carsten Hahn is a Systems Engineer for Bayer Business Services in Leverkusen, Germany. He has 12 years of IT experience, and for the last seven years, he has worked with Tivoli Storage Manager, including LAN-free and Lotus Domino backup. His areas of expertise include Tivoli Storage Manager planning, installation, maintenance, and monitoring, as well as SAN storage infrastructure, management, and implementation, SVC, Windows, and AIX. He has a degree in Computer Science from the University of Applied Sciences in Bingen. Matthew Lee is a Technical Solution Architect with IBM Global Services, Global Technology Services, in Sydney, Australia. He has worked in the IT industry for 21 years and has been with IBM since 1999. His areas of expertise include UNIX, systems management, and security and storage solution design, implementation, and management. He has a Bachelor of Electrical Engineering from the University of Western Australia and a Post Graduate degree in Business Administration from Singapore Institute of Management.
The team: Matt, Helder, Carsten, Dan, Lloyd, and Charlotte xvi
Thanks to the following people for their contributions to this project: Babette Haeusser, Emma Jacobs, and Deanna Polm International Technical Support Organization Matt Anglin, Kai Asher, Janet Bolton, Dave Cannon, Rob Edwards, Barry Fruchtman, Bill Haselton, Jon Haswell, Kevin Hoyt, Mark Haye, Avishai Hochberg, Harry Husfelt, Tricia Jiang, Alexei Kojenov, Zong Ling, Toby Marek, Howard Martin, Diem Nguyen, Joanne Nguyen, Jim Smith, and Chris Stakutis IBM Tivoli Storage Manager Development, Marketing, and Test Ric Bradshaw, Gregory Gendron, Jon Peake, and Rob Wilson IBM Tape Development and Marketing Anthony Abete and Jeff Ziehm IBM Advanced Technical Support Tom Benjamin, Timothy Hahn, John Morganti, and John Peck IBM EKM Development Carl Gusler IBM Austin Rosane Goldstein Golubcic Langnor and Eduardo Tomaz IBM Brazil Deon George IBM Australia Ian Saner Cristie Jim Carrick, Andrew Gorelick, Ann Kurtz, and David Swits Strategic Computer Solutions, NY Othmar Weber Bayer Business Services, Germany Tom and Jenny Chang, and the staff of The Garden Inn, Los Gatos, CA
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbooks publication dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll have the opportunity to team with IBM technical professionals, IBM Business Partners, and Clients. Your efforts will help increase product acceptance and client satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html
Preface
xvii
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review form found at: ibm.com/redbooks Send your comments in an e-mail to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
xviii
Chapter 1.
Introduction
This chapter serves as an introduction for this book about security considerations for IBM Tivoli Storage Manager. It discusses the topics that we will discuss, the intended audience, and the structure of the chapters. Additionally, we begin to describe the types of threats that the Tivoli Storage Manager administrator might face, and how the Tivoli Storage Manager administrator can counter these threats. The amount of introductory material contained in this section is intentionally somewhat limited, because this book assumes some familiarity with Tivoli Storage Manager.
1.1 Overview of this book

The purpose of this book is to provide an in-depth look at security for the Tivoli Storage Manager administrator. Here is a brief overview of the contents of the rest of the book.
Part 1 - Client side security

This section of the book deals with the Tivoli Storage Manager clients and providing secure Tivoli Storage Manager services from the client perspective. The topics include client session authentication and data flow. We discuss the behavior of the types of clients, native compared to Web client, and the trusted communications agent (dsmtca). We dedicate a chapter to securing the client from an operating system perspective, including operations by authorized and non-authorized users, file permissions, and operations with network attached file systems.
Part 2 - Tivoli Storage Manager and encryption

In Part 2, Encryption on page 79, we discuss how to use encryption to secure Tivoli Storage Manager stored data and prevent unauthorized access. This includes Tivoli Storage Manager client encryption and tape encryption. We focus on the encryption available with the IBM TS1120 tape drive (and planned for the next generation of LTO products), although other vendors, for example, Solaris/STK, also provide a tape encryption solution. You can also perform encryption at the network level, for example, using IPSec, VPN, or appliance solutions, such as those provided by Decru. We do not discuss these in any great detail, because they operate independently of Tivoli Storage Manager.
Part 3 - Server side security

This section focuses on security from the standpoint of the Tivoli Storage Manager server administrator. This section discusses server administrator roles, Operational Reporting, and the Integrated Services Console/Administration Center (ISC/AC). We discuss disk storage pools and tape storage pools, including their vulnerability to access, and recommendations for destruction. We discuss running the Tivoli Storage Manager in a firewalled secure network environment and especially how to restrict running client sessions. We give general best practices for server security, covering both physical and personal threats, and present a procedure for running a Tivoli Storage Manager server from a non-superuser ID.
Part 4 - Recovery scenarios and recommendations

In the final part of the book, we discuss securing your disaster recovery environment, in the context of the overall Business Continuity Plan. We then present a number of scenarios for particular security-related Tivoli Storage Manager incidents that can occur, including how to recover from them, and more importantly, how to prevent these incidents from occurring in the first place. Finally, as a summary of many of the topics that we have presented in the book, we organize many of our recommendations into categorized lists, which you can use to run a check of your environments security and which can assist you to prepare for an audit.
In the rest of this chapter, we describe the basic principles of security to provide both a background and education for a typical storage administrator, who might not have considered this topic in-depth and who needs to understand the language of the security experts.
1.2 Why is security important

Data is one of one of the primary assets of any company or organization; without data, most organizations cannot function. As with any vital asset, protecting the data must be one of the highest priorities. Additionally, in recent years there has been a significant increase in the level of oversight of the business practices of every organization. HIPAA, Sarbanes-Oxley, SEC/NASD, and US DoD 5015.2 among others, have forced organizations to closely review their electronic data management practices. Failure to comply with the regulations pertaining to an organizations area of business can result in civil, or in some cases, criminal penalties. Depending on the business sector, the data to be protected might be client accounts, payroll statements, financial statements, personal health records, or even government defense and security information.
1.2.1 Why is Tivoli Storage Manager security important

In a typical medium-to-large environment that includes Tivoli Storage Manager, Tivoli Storage Manager might be the principal application that reaches into every corner of the enterprise, from the largest database server to the desktop. Not only is the Tivoli Storage Manager server likely to have the most recent backups from many systems, but it likely has large quantities of historical data, potentially going back for years. Further, the Tivoli Storage Manager server has the ability to execute commands and control applications on the clients attached to it. Tivoli Storage Manager must therefore be viewed as one of the most valuable and powerful applications in any organization where it is widely deployed.
1.2.2 Tivoli Storage Manager security objectives

When first considering security, a common mistake is to believe that the biggest threats are from outside the organization, when in actuality, the opposite is true. Your Tivoli Storage Manager system is far more likely to be damaged (deliberately or accidentally) by an individual or issue from within the company than by an external cracking attempt. In a Tivoli Storage Manager implementation with a well implemented security structure, protection against these internal factors is one of the greatest benefits. When implementing Tivoli Storage Manager security, it is important to keep in mind what the objectives are. These can be broken down into the following categories.
Integrity
Data integrity is ensuring that the information stored is valid, intact, and protected from corruption. A well-designed Tivoli Storage Manager security implementation can protect the accuracy of the information on your Tivoli Storage Manager system. With the right security, you can prevent unauthorized changes or deletions of data.
Chapter 1. Introduction
Confidentiality
Data confidentiality is ensuring that only authorized individuals or systems have access to data, and those individuals and systems can only access the data for which they are authorized. Good Tivoli Storage Manager security practices can prevent people from obtaining and disclosing information to which they should not have access.
Availability
Data availability is ensuring that the data is available when needed. If an individual or system accidentally or intentionally damages data on your system, you cannot access those resources until you recover them. A good Tivoli Storage Manager security structure can minimize or prevent this kind of damage.
1.3 How is Tivoli Storage Manager security implemented

True security, in general, is not obtained by a single point solution. It is best implemented as a series of successive layers with different verifications and checks performed at the different layers.
Network security
Tivoli Storage Manager is a client/server application and requires reliable network connectivity in order to function. A detailed treatment of this layer is beyond the scope of this book, but proper implementation of network security practices is a key element of securing the Tivoli Storage Manager environment. Properly implementing network security practices restricts access to only those systems and individuals that should have access to the Tivoli Storage Manager server and clients.
Operating system security

The Tivoli Storage Manager server and clients run on individual operating systems, such as UNIX, Linux, Windows, NetWare, or z/OS, or other supported platforms. In a sense, the operating system is the underlying foundation for the application code running on the system. Poor security practices that are implemented at the operating system layer make compromises to the applications running on that operating system easier and more likely.
Tivoli Storage Manager server configuration

The way that you configure a Tivoli Storage Manager server determines who is allowed to access the system, and the type of authority that each user has. Solid security practices here are very important, because the Tivoli Storage Manager server can interact with all of its client nodes and typically executes operations with administrative authority on those clients.
Tivoli Storage Manager client configuration

The Tivoli Storage Manager client does not have the broad-reaching power of the server, but it still touches all of the data that is resident on the client node. Therefore, a good understanding of how the client operates and its capabilities is required for good security.
Data center security

Your Tivoli Storage Manager server, its storage pools, and probably many of the clients, will be located in a data center. Physical access control to the center, perhaps restricted areas even within the data center, and media control policies all come into play when securing the data center.
Off-site security
In most cases, backup data is physically or electronically transported to another site for disaster recovery purposes. Because this process is often entrusted to a third party, this introduces an extension of the circle of trust. Appropriate service level agreements and regular audits must be in place.
1.4 Types of threats

A threat to your Tivoli Storage Manager environment can be anything that jeopardizes the objectives outlined in 1.2.2, Tivoli Storage Manager security objectives on page 3. Threats to the Tivoli Storage Manager environment and the data contained therein can be grouped into the following general categories.
1.4.1 Threats from within the organization

All too often, the greater threat to data comes not from outside, but from inside the organization. By virtue of the fact that the people and systems within the organization will have more access to data than those outside, the potential of threat exposure is increased: Internal personnel threats People make mistakes and can be influenced by outside factors. With a poorly defined or nonexistent security policy in place, personnel might be able to access or delete data that they should not. This type of access or deletion can be accidental or deliberate. Physical threats or equipment failure Physical threats, such as power loss due to accidental or deliberate power disruption in the data center, should be considered and proper data center access controls used. Equipment failure can result in data loss if proper data protection methodologies are not used.
1.4.2 Threats from outside the organization

Threats from outside the organization can include: External attacks These are attacks that originate outside of your environment. Attacks can be of a specific nature where an educated source targets particular data, applications, or servers, or more broadly based, such as a fishing expedition that is aimed at discovering vulnerabilities. Because of its strategic importance, Tivoli Storage Manager is intended to be used in a relatively secure environment, and it is assumed that an organization will have external firewalls and physical security in place at a minimum. Environmental threats These include fire, flooding, or natural phenomena, such as earthquakes, and should be considered as part of the overall security plan. Clearly, here security interacts with an organizations Business Continuity strategy.
1.4.3 Threats to physical storage of data

This section discusses potential threats for stored data: data on disk, tape, or other media.
Removable media
Removable media likely presents the biggest potential exposure for stored data. By definition, removable media is portable and can be easily transported and possibly lost or stolen. Removable media might be handled by numerous individuals both inside and outside of the organization throughout its life cycle. Cartridges, when they are in transit, leave the controlled environment of the data center and can be damaged or stolen. Off-site media (typically tape) rotation is handled either automatically by the Tivoli Storage Manager sites Disaster Recovery Manager module, or through manual scripts and processes. When Tivoli Storage Manager stores data on removable media, it does not write any index or catalog to the media itself, because the intent is that the Tivoli Storage Manager database should also be available for any recovery. This makes data extraction from a single lost or stolen cartridge difficult, but as we discuss later in this book, it is not impossible. However, encrypting the data stored on removable media makes it essentially impossible to extract the data from that cartridge. A key message throughout this book is the vital role of encryption for security purposes.
Disk
Because disk is normally not transported off-site, the primary risk of data loss or theft comes from either inside attackers, equipment failure, or environmental factors. Unless you use Tivoli Storage Managers client encryption, data stored in a disk storage pool or file storage pool is not encrypted. If an attacker can gain access to the storage pool disk, for example, through incorrect zoning or LUN masking in a SAN environment, the attacker might be able to read the unencrypted data on disk using operating system utilities. Equipment failure primarily comes into play if the Tivoli Storage Manager data structures are placed on unprotected disk, such as striped or unmirrored volumes.
1.4.4 Threats when data is transmitted

Data might be transmitted several times in the Tivoli Storage Manager environment, depending on how the system is set up. At a minimum, data is transmitted between the client and server, either over a network link or SAN. If the data is unencrypted while in transit, it might be possible for an attacker to use packet sniffing techniques to view or capture data in flight. The use of network switches, which have largely replaced simple hubs, has helped to alleviate this risk, but a skilled attacker can still gain access using these methods. Data in transit across a SAN is typically at much less risk, because it is much more difficult to tap into a Fibre Channel SAN link. Client encryption will encrypt the data at the client prior to transmission, thereby helping to eliminate this type of risk.
1.5 Data transport methodologies with Tivoli Storage Manager

Tivoli Storage Manager uses a client/server model, with clients sending data to or from the Tivoli Storage Manager server typically using either IP networking or Fibre Channel connections. The Tivoli Storage Manager servers themselves also have the capability to pass data to or from storage devices as well as to other Tivoli Storage Manager servers. Network connectivity, whether IP-based or Fibre Channel-based, is an important piece of any Tivoli Storage Manager implementation. This section provides a brief overview of networking technologies that are used with Tivoli Storage Manager.
1.5.1 Review of the Open Systems Interface data model

There are seven layers in the Open Systems Interface (OSI) data model; each layer represents a specific functionality. The overall objective is to allow Layer 7 applications (such as Tivoli Storage Manager, e-mail, Web servers, and Web browsers) to connect to each other; this chart, Figure 1-1 on page 8, represents the details of what is required to make that happen. There are headers shown on the left and right side of the OSI chart in Figure 1-1 on page 8. The applications data is progressively encapsulated with headers as the data passes from layer to layer, in preparation for transmission to the other site. At the other end, headers are progressively removed as the data is passed up toward the receiving application. The header abbreviations are: AH - application header PH - presentation header SH - session header TH - transport header NH - network header LH - data link header
Workstation
Workstation ... ... ... ... ... ...
MS Exchange other...
DB2, Oracle SAP
Voice PSTN
Tivoli Video Voice VoIP
E-MAIL
WWW HTML
A H
DATA
7- Application
7- Application
Data
A H
P H
6- Presentation
6- Presentation
P H
S H
5- Session
5- Session
S H
T H
4- Transport
IBM SNA MicroSoft NetBios Apple local talk Banyon Vines others IBM APPN DEC DecNet IBM NetBUI Novell IPX
4- Transport
T H
N H
3- Network
LLC
3- Network
LLC
N H
Internet Protocol (IP)

L H L T
2-Data Link
MAC
TR shared & switched; 4 & 16 Mbps ATM Ethernet shared & switched; 10-Base2, 10-Base5, 10-BaseT, 10-BaseF, 100-BaseT, 100-BaseF, 1000-BaseT, 1000-BaseF . . . . . . .
LANE-CIP
PtP, DSn, OCn
2-Data Link
Channel Extenders DWDM
MAC
L T
L H
Frame Relay
PVCs, SVCs
SONET
Multi Mode Fiber - Lightc
UTP 3, 4, 5, 6
Single Mode Fiber - Laser
Free Space Optics FSO
Video Coax Cable TV
Wireless Network Coax thick thin
LAN - Campus MAN - WAN
Network
Figure 1-1 Open Systems Interface (OSI) Data Model
1.5.2 Interfacing networks together

Having explained the OSI model, we turn next to the need for and methods of interfacing between two networks. There are four basic types of network interface devices (Figure 1-2 on page 9): Repeaters Hubs/Bridges Switches Routers
Satellites
1- Physical
Microwave
1- Physical
7- Application 6- Presentation 5- Session 4- Transport
7- Application 6- Presentation
Peer-to-Peer Communication
5- Session 4- Transport
3- Network
Network
Routers
Network
3- Network
2-Data Link
Data Link
Hubs / Bridges Repeaters
Switches
Data Link Physical
2-Data Link
1- Physical
Physical
1- Physical
Network A
Ethernet 10 Base T (shared) LAN - Campus Ethernet 10 Base T (Shared/Switched) Token-Ring 4 Mbps (Shared/Switched) Token-Ring 4/16 Mbps (Shared/Switched) IP Subnet xx.xx.xx.xx Internet Protocol (IP) MAN - WAN Microsoft NetBios ATM (LANE & CIP) Frame Relay PtP, DSn - OCn SONET ATM (LAN, MAN and WAN)
Network B
Ethernet 10 Base F (shared) Ethernet 100 Base F (Shared/Switched) Token-Ring 16 Mbps (Shared/Switched) Ethernet 100 Base T (Shared/Switched) IP Subnet yy.yy.yy.yy Novell IPX Digital Equipment DecNet ATM WAN (PVCs) ATM WAN (PVCs) SONET DWDM DWDM Repeater Bridge Bridge Bridge Router Router Router Switch Switch Switch Switch Switch
Figure 1-2 Interfacing between networks using repeaters, hubs, bridges, switches, and routers
As shown by the vertical arrows, the determining factor in which device is used depends on what layer of the OSI model is to be interfaced: Repeaters are used when the highest level of network interconnection is fundamentally at the OSI Layer 1 physical connection level. Hubs and Bridges are used when the highest level of network interconnection is fundamentally at the OSI Layer 2 data link level. Switches are used when the highest level of network interconnection is fundamentally at the more basic levels of the OSI Layer 3 network level. Routers are used when the highest level of network interconnection is fundamentally deep within the OSI Layer 3 network level. In reality, there are no hard and fast lines between these four types of interconnection devices. Vendors all have varying levels of technology, and that technology can and does span layer interconnections. By understanding the OSI model, you can ask intelligent questions of the vendor's implementation in order to determine exactly what layer and interfaces are the domain of the individual products.
1.5.3 A review of OSI Layer 1 - Physical Layer

Within the discussion regarding secure disaster recovery sites, it is important to briefly review the OSI physical layer 1, as shown in Figure 1-3, because this demonstrates the types of physical connections that exist as options.
MAC
MAC
Multi Mode Fiber - Lightc
UTP 3, 4, 5, 6
Single Mode Fiber - Laser
Free Space Optics FSO
Video Coax Cable TV
Microwave
1- Physical
Wireless Network Coax thick thin
1- Physical
Satellites
LAN - Campus MAN - WAN
Network
Figure 1-3 OSI Layer 1 - Physical connection
As shown in Figure 1-3, physical connections between two ends of the network can consist of (but are not limited to): Wireless, including variants of todays wireless LAN technology and cell phone technology. Network thick or thin coax. Unshielded Twisted Pair (UTP), which comes in various levels (3, 4, 5, or 6), each of which describes a certain level of drive distance, bandwidth capability, and resistance to electromagnetic interference. Video and cable, television coax. Fiber optic cable, which is the current strategic physical connection networking technology. Fiber optic cable can be either multi-mode or single-mode cable. These modes are defined in Figure 1-4 on page 11. Free Space Optics, which are wireless or microwave technologies to handle one of the biggest problems in using the strategic fiber optic capability, which is, How do I get fiber run the last mile (from the network provider's closest connection point to my particular data center)? Microwave and Satellites, which are wireless technologies used for networking communication, especially at very long distances, and which require no physical interconnection. In Figure 1-3, the LAN-Campus arrow shows that, in the LAN-Campus environment, the networking Layer 1 physical connection technologies are usually one or more of the following: Wireless, Network coax, Unshielded Twisted Pair, Video coax, and Multi-mode fiber optic.
10
Conversely, in the Metropolitan Area Network (MAN) or the Wide Area Network (WAN) (that is, longer distance than LAN-Campus), the Layer 1 physical interconnection technologies are typically: UTP, video coax, multi-mode and single-mode fiber optic, free space optics, microwave, and satellites. To begin any networking connection, the first requirement is to establish a physical Layer 1 connection by using one or more of these technologies.
1.5.4 A review of Fibre Channel technology

Fiber optic cable is at the OSI layer 1 physical layer. The data link (layer 2), network (layer 3), and transport (layer 4) are on top of the physical layer. Therefore, multiple different types of protocols in these other layers can traverse a physical layer (fiber optic cable) at the same time. There are two major types of fiber optic cable, as shown in Figure 1-4: Multi-mode fiber Single-mode fiber
Multimode (MM) Fiber

"Multiple paths" for light to travel
Outer coating 250 micron dia.

Cladding 125 micron dia. Core 50 or 62.5 micron dia
DATA
LED =
Light Emitting Dioder
Single Mode (SM) Fiber

"Single path" for Laser to travel
Outer coating 250 micron dia. Cladding 125 micron dia. Core 9 micron diameter
DATA
LX Laser = Long Wavelength
Laser
Figure 1-4 Fiber optic cables: single-mode and multi-mode
Multi-mode fiber
Characteristics are: Less expensive per foot/installation than single-mode fiber Typically used within the data center or for short haul distances (on Fibre Channel SANs or Gbit Ethernet, typical maximum distance is about 500 meters) Uses LED to drive the light signal Sometimes, the term short-wave is used to describe what is properly known as multi-mode fiber.
11
Single-mode fiber
Characteristics are: More expensive per foot/installation than multi-mode fiber. Typically used where longer distances are required. The maximum distance for Fibre Channel SANs today is about 20 km; although, this distance is extending all the time. Uses a laser to drive the light signal. Note: Two strands per fiber optic link will be required; one strand to transmit in each direction (or from a single end perspective, one to transmit and one to receive). Fibre Channel Network Extenders will connect multi-mode to single-mode or single-mode to multi-mode Fibre Channel. These devices will extend your Fibre Channel network by approximately 110 km. The network technologies that are currently supported by the channel extender vendors include Fibre Channel, Ethernet/IP, ATM-OC3, and T1/T3, SONET. When using channel extender products, the channel extender vendor will determine the maximum distance supported between the primary and secondary systems. The channel extender vendor should supply details concerning their distance capability, line quality requirements, and WAN attachment capabilities. Evaluation, qualification, approval, and support of the configurations using channel extender products should be expected from the channel extender vendor. You can expect dark fiber strand pricing to be quoted in dollars per strand per mile per month. While costs vary, and clearly are decreasing depending on the geography and competition, the cost for dark fiber strands is substantial. In certain circumstances, there will be a need for at least two geographically separate paths to the other site, so that is another factor causing the cost to effectively double.
1.5.5 A review of VPN technology

Connecting your company network to a remote site for disaster recovery introduces risks. Deployment planning must include capital funding to ensure that both security and performance are maintained whenever electronic vaulting, hot site, or warm site solutions are implemented. If Tivoli Storage Manager client (or API) encryption is not implemented, data sent to Tivoli Storage Manager copy storage pools (every file, including every time that the file changes, from every server) flows across this link in the clear. In addition, your Tivoli Storage Manager full database backups flow across this network segment and are also not encrypted. The use of VPN hardware devices that include encryption and decryption capabilities secures your data as it traverses the network, travelling across public networks. Methods of achieving this encryption and decryption software layer include IP Security Architecture (IPSec) and SSL Network Extenders. These software layers work in conjunction with hardware devices to build fast and secure data protection between your sites. In addition to IPSec, technologies, such as layer 2 tunneling and remote access authentication servers, provide the necessary flexibility to apply adequate security to any VPN scenario.
12
As shown in Figure 1-5, one way to implement a VPN connection between the corporate headquarters and a disaster recovery site is for the company to purchase Internet access from an ISP.
Corporate Intranet
ISP Router ISP
Disaster Recovery Site
Internet
VPN
Router
Production TSM Server
Firewall Authentication Encryption
Firewall
TSM Server
Figure 1-5 VPN with IPSec over an Internet connection
Firewalls, routers with integrated firewall functionality, or in some cases, a VPN server with IPSec capability, are placed at the boundary of each of the intranets to protect the company traffic from Internet malicious hackers. Most of the hardware within this scenario can provide Triple DES (TDES) with AES256 bit encryption. With this configuration, the clients and servers do not need to support IPSec or SSL technology, because the IPSec or SSL-enabled firewalls (or routers) provide the necessary data packet authentication and encryption. With this approach, any confidential information is hidden from untrusted Internet users and the firewall denies access to potential attackers. With the establishment of this disaster recovery site connection, the companys corporate headquarters will be able to securely and cost-effectively send Tivoli Storage Manager data to its off-site location through the use of open IPSec technology.
1.5.6 Networking summary

We have provided a brief network overview related to improving your network component understanding. This is important when working through your Business Continuity Plan and determining if an electronic vaulting solution is good for your company. If this option is attractive, including network requirements that enhance sequential I/O over MAN and WAN link is essential. In addition, network encryption (VPN - IPSec/SSL) will allow for the best available security at the lower layers. We will provide more detailed guidelines for network security in 10.4, Network security considerations on page 270.
1.6 Tivoli Storage Manager data movement and storage

Data movement is a critical characteristic of any Tivoli Storage Manager environment. Backups and restores for client nodes across both LAN and SAN, as well as tape or optical cartridge handling, both on-site and off-site, occur frequently. Accordingly, if not protected
13
appropriately, there are numerous potential opportunities for your data to be lost, deleted, or stolen. This section lists some of those access points and provides a background for further discussion.
1.6.1 On-site data movement

The on-site data movement for a typical Tivoli Storage Manager environment looks similar to Figure 1-6.
Figure 1-6 Tivoli Storage Manager on-site data movement
Data is transmitted between the clients and the Tivoli Storage Manager server, either across the LAN or SAN (and possibly the WAN as well). Data is typically written to either disk or tape, or possibly both. Operations staff will likely handle the physical data cartridges for off-site vaulting, or possibly for tape library overflow management. Points of exposure might include: Unauthorized physical access: Unauthorized physical access to Tivoli Storage Manager server and disk storage pools Unauthorized physical access to tape library and media Unauthorized physical access to on-site library overflow location and media Physical media handling: Dropped cartridges Lost cartridges
14
Stolen cartridges Data export media Backup set of media Network packet sniffing Insecure access methods to Tivoli Storage Manager server or library interface Weak or no passwords or authentication for Tivoli Storage Manager server or underlying operating system Excessive authority granted to client node administrators or operations staff
1.6.2 Off-site data movement

Off-site data movement to an external vaulting facility is a daily process for most organizations. After a piece of media leaves your facility, the potential exposure for data loss or theft increases again, because you are typically trusting an external vendor to handle and transport your data. Most organizations using Tivoli Storage Manager now use Tivoli Storage Manager Disaster Recovery Manager (DRM) to manage their tape rotation. The DRM tape rotation cycle is shown in Figure 1-7.
Vault Retrieve State
TSM Server Vault State Mountable State Courier Retrieve State
Courier
Operator
Vault Staff Vault Facility Courier State
Figure 1-7 DRM off-site rotation to an external vault
When off-site vaulting is performed, this widens the scope of people involved with handling the data. In addition to the on-site operations staff, there will typically be one or more couriers and staff at the vaulting center. Furthermore, the media will be shipped over public highways.
15
Additional points of exposure might include: Courier staff: Lost media Stolen media Vaulting facility staff: Lost media Stolen media Vehicular accident: Media lost Media destroyed
1.6.3 Server-to-server data movement

In some cases, Tivoli Storage Manager server-to-server communication is used for electronic vaulting or other data movement. Using this method instead of physical off-site media vaulting eliminates the risks associated with media transport. However, network exposures can still exist, especially if insecure network paths are used between the two Tivoli Storage Manager servers.
1.7 Introduction to encryption

Encryption is the process of transforming plaintext into an unintelligible format, also known as cipher text, so that anyone, who does not have the encryption key, cannot access the data.
Encryption is a critical technique for securing data, because even if an intruder gains physical access, they cannot interpret any of the information. If you do not know how the data was encrypted, it can range from hard to virtually impossible to decrypt the data. Enterprise encryption methods are orders of magnitude more robust than the trivial algorithm used to encode some of the text on the front cover of this publication. Encryption can be implemented in hardware or software: Hardware-based encryption Hardware-based encryption is performed by special processors in certain types of hardware (such as a tape drive, a network router, or a specialized appliance), which are very fast and can encrypt in real time. There is no impact to the data transfer rate and no CPU resources on the computer server are needed, because the encryption is off-loaded to other hardware. Software-based encryption Software based encryption uses the server CPU to do the work. Because most computer CPUs are not specialized for encryption, this can take longer and consume CPU resources that otherwise are available for other operations. Tivoli Storage Manager can support both software encryption and hardware encryption. Software encryption is implemented within the Tivoli Storage Manager client. Hardware encryption is available with certain tape drives. While there are many methods of encryption, modern encryption methods can be classified into either symmetric or asymmetric encryption.
16
1.7.1 Symmetric encryption

This is also referred to as private-key cryptography, because a single secret key is used to both encrypt and decrypt the plaintext. Several of the common symmetric encryption algorithms are Advanced Encryption Standard (AES), Data Encryption Standard (DES), Triple DES (TDES), and Skipjack. Figure 1-8 shows how plain text can be encrypted into cipher text using a symmetric encryption key. The decryption process uses an identical key to transform the cipher text back to plaintext. An advantage of using symmetric encryption is the encryption speed, which is much faster than asymmetric encryption. The major drawback of symmetric encryption is related to sharing the private or secret key with the receiving party. How do we transmit this secret key to the recipient without anyone tampering with it? A common method of overcoming this problem is to use asymmetric key encryption to transmit the secret key.
Symmetric Encryption
E.g. Data Key
Figure 1-8 Symmetric key encryption process
1.7.2 Asymmetric encryption

Asymmetric encryption, on the other hand, uses a Private/Public key pair for the encryption process. A public key is used to encrypt the data and a private key is used to decrypt the data. The Private/Public keys are generated so that it is impossible to determine one key by using the other key. The Public/Private key pair eliminates the inherent problem of having to distribute the secret key that is required in the symmetric key encryption process. Figure 1-9 on page 18 shows a typical asymmetric key encryption process in greater detail.
17
Asymmetric Encryption
Eg., Key Encrypting Key
Figure 1-9 Asymmetric key encryption process
1.7.3 Certificates, keystores, and key managers

A digital certificate is a digitally signed certificate that uniquely identifies the ownership of an an entity. Digital certificates are used in the asymmetric key cryptography process that uses a pair of digital keys, the public and private key pair for the encryption process. A digital certificate is used to verify the ownership of a key when it is transmitted; the digital certificate verifies that it really came from the designated source. The type of information that is stored within a digital certificate is: Key Label Key size The subject distinguished name, for example, cn=gicert1 Name of the issuer The validity of the certificate Digital certificates are normally signed by a Certificate Authority. A Certificate Authority is an entity that issues a signed digital certificate for use by another entity, that is, another person or server. Examples of commercially available Certificate Authorities are Verisign or Thawte. In addition, you can also create your own Certification Authority using OpenSSL, which is part of the open source project. The point is that if a key is sent embedded in a certificate from a trusted authority, you can then trust the contents, that is, the key itself. A keystore is a repository for digital certificates. These certificates represent Public and Private encryption keys. Keystores are normally created and managed by a key management tool, also known as a key manager.
18
1.8 Tivoli Storage Manager client data encryption

When Tivoli Storage Manager client encryption is used, the data is encrypted by the client itself, and the data is therefore protected as soon as it leaves the client for its entire life span in the Tivoli Storage Manager storage hierarchy. Most Tivoli Storage Manager clients, as of V5.4.0, are capable of encrypting data using either DES56 or AES128 software encryption. Information regarding these encryption standards is available at the following National Institute of Standards and Technology Web site: http://csrc.nist.gov/CryptoToolkit/tkencryption.html Both DES and AES are block ciphers and use symmetric key algorithms, which require substantially less CPU power than asymmetric algorithms. Symmetric key encryption schemes require the use of a shared secret key.
1.8.1 DES56
The first encryption offered for Tivoli Storage Manager client was 56 bit DES. DES keys are 56 bits long (hence, the DES56 designation), which means there are approximately 7.2 x 1016 possible DES keys. DES uses a block length of 64 bits.
1.8.2 AES128
AES is able to use key sizes of 128, 192, and 256 bits, with a block length of 128 bits. Tivoli Storage Manager clients that are capable of AES encryption use 128 bit keys; with 128 bit AES, there are approximately 3.4 X 1038 possible keys. Thus, there are many more possible AES128 keys than DES56 keys. We discuss Tivoli Storage Manager client encryption in Chapter 5, Tivoli Storage Manager client data encryption on page 81.
1.9 Tape encryption

IBM provides hardware encryption on the IBM System Storage TS1120 tape drive. There is also an announced intent to provide encryption on 4th generation LTO devices. Tape hardware encryption allows the use of AES256 encryption for any tapes that are written on the device without any loss of performance that software-based encryption methods incur. Different key management methodologies are available when using TS1120 tape encryption; these include application-managed encryption (AME), system-managed encryption (SME), and library-managed encryption (LME). We discuss the use of each of these methods on the TS1120 tape drive in a Tivoli Storage Manager environment in Chapter 6, TS1120 Tape encryption on page 113. Other vendors also provide encryption-capable tape devices; check with those vendors for their capabilities in a Tivoli Storage Manager environment.
19
20
Part 1
Part
Tivoli Storage Manager client considerations

In this part, we cover security aspects related to the Tivoli Storage Manager client. This part includes the following topics: An overview of how client to server authentication works The data flow in client sessions, including transactions and client threads How access controls work in the client Client services and daemons Client security, including authentication, options for restricting functionality, and privilege on the client
21
22
Chapter 2.
Client sessions
This chapter discusses the client authentication process, including the client/server conversation flow. In addition to authentication, this chapter describes handling client multi-sessions; this chapter also describes client session thread types and thread type interaction during transaction handling.
23
2.1 Client authentication

This section outlines the authentication flow between a Tivoli Storage Manager client and server. For security reasons, we show this flow at a mid-high level only. Tivoli Storage Manager uses a mutually suspicious algorithm to establish authentication between the client and server. The process works as follows: 1. Password credentials are used on the client to encrypt a simple message, known as a buffer, which is sent to the server. 2. The server decrypts the buffer and is, therefore, assured of the clients authenticity. 3. The process repeats in the other direction; the server creates another buffer and sends it to the client. 4. Provided that the client can validate the content, the client is then assured of the servers authenticity. In this way, client and server know that both parties are who they present to be.
2.1.1 Command line authentication flow (non-root user)

On UNIX, when a non-root user starts the dsmc or dsm command, dsmtca is called as a SUID program to decrypt and encrypt the password file, which is then used for the authentication exchange that we describe in the previous section. This process is documented in Figure 2-1. This occurs because only the root user has authority to read the password file directly.
TSM B/A Client

Non-root user invokes dsmc and enters the user ID and password
Authentication Flow dsmc and dsmtca Non-root
TSM Server
1 2
dsmtca is called to read (decrypt) the password file (suid function). Only dsmtca will ever read or use the password in this transaction sequence. dsmtca encrypts the buffer and passes this to dsmc.
dsmc sends the encrypted buffer to the TSM server
TSM server decrypts the buffer and validates the content. If the decryption or validation fails, AUTH FAILED is returned. If the information is good, the server responds with another encrypted buffer using the shared algorithm.
dsmtca decrypts the buffer and validates the content, if OK. Then repacks/encrypts the response with the shared algorithm and passes the buffer to dsmc
dsmc sends the encrypted buffer to the TSM server
Encrypted buffer sent to the client
Server's final validation, sends AUTH SUCCESS, or AUTH FAILED in an encrypted buffer
dsmc session begins once the AUTH SUCCESS is received
Figure 2-1 Non-root dsmc authentication flow
24
The password is never part of any exchange between the client and the server. Instead, the password is used locally on both sides to validate the data and to ensure that both parties have a common knowledge of the password, otherwise authentication fails.
2.1.2 Command line and scheduler authentication flow (root user)

On UNIX and Windows, the root and Administrator authorities have the authority to decrypt and encrypt the password file (or registry entry for Windows). The client/server authentication happens when the following commands are invoked; dsmc, dsm, or dsmcad (MANAGEDSERVICES SCHEDULE parameter in the dsm.sys file). Therefore, the dsmtca executable is not required, and the buffer authentication exchange proceeds as shown in Figure 2-2.
TSM B/A Client
Authentication Flow dsmc root and Administrator
TSM Server
root user invokes dsmc and enters the ID and password dsmc generates authentication data and encrypts the data using a known client/server shared algorithm
dsmc sends encrypted data to the TSM server
Server decrypts the data and validates the content. If the decrypt or validation fails, AUTH FAILED is returned. If the data is good, server repacks the athentication data and encrypts with the shared algorithm.
Encrypted data is sent to the client
6 7
dsmc decrypts the data and validates the content, repacks the data, then it is encrypted with the shared algorithm
dsmc encrypted data sent to server Server's final validation, sends AUTH
FAILED, or Auth failed
dsmc session begins once the AUTH SUCCESS is received
Figure 2-2 Tivoli Storage Manager dsmc authentication flow
The password is never part of any exchange between the client and the server. Instead, the password is used locally on both sides to validate the data and to ensure that both parties have a common knowledge of the password; otherwise, authentication fails.
2.1.3 Web access authentication flow

Use of the Web client interface forces authentication whenever backup, restore, archive, or retrieve functions are performed. The Web GUI loads a Java Applet (dsm.jar) when the client HTTP port is accessed. The dsm.jar can also be invoked from the command line as the dsmj command.
Chapter 2. Client sessions
25
An administrator ID is required when using the Java Applet interface. This administrator ID, and associated password, is used to authenticate that the user has sufficient authority to perform remote client functions. This authentication happens using the dsmagent process, which logs into the Tivoli Storage Manager server and establishes a dsmagent server session. Two administrative privileges are provided to enable this authentication: Client owner Client access These administrative privileges are used with the REGISTER ADMIN or UPDATE ADMIN command. These privileges can be used to enable usage of the Java Applet interface for backup/archive client owners and help desk personnel. A user ID with client access privilege can only restore data back to its original system. A user ID with client owner privilege can restore data to another system if required. The interaction between the Java Applet (dsm.jar), in conjunction with the dsmagent (proxy) on the client side, and the Tivoli Storage Manager server is shown in Figure 2-3.
Authentication Flow Java Applet (dsm.jar) and dsmagent

Passwordaccess=generate
TSM B/A Client
TSM Server
1 2
User invokes the dsm.jar either by the Web GUI or dsmj, then logs in with the admin ID and password
dsmagent establishes a client session using the node ID and password (passwordaccess generate). As per the authentication flow for root users.
TSM server decrypts the buffer and validates the content. If the data is good, the server responds with AUTH SUCCESS, then repacks the buffer and encrypts it with the shared algorithm.
TSM server replies with an encrypted buffer with AUTH SUCCESS.
3 4
5 6
Once the server/node session is established, dsmagent then presents the login prompt for the admin ID and password. dsm.jar generates authentication data and
encrypts this using a known client/server shared algorithm.
dsmagent sends the encrypted data to the TSM server
TSM server decrypts the buffer and validates the content. If the decrypt or validation fails, an AUTH FAILED is sent. If the data is good, server repacks the buffer and encrypts it with the shared algorithm.
Encrypted buffer sent to the client
9 10
dsm.jar decrypts the buffer and validates the content, repacks the buffer with a response, and encrypts with the shared algorithm
dsmagent sends the encrypted buffer to the TSM server Server's final validation, sends AUTH SUCCESS, or AUTH FAILED
11
12
Session begins once the AUTH SUCCESS received, with dsmagent continuing to proxy for dsm.jar (Web GUI session).
Figure 2-3 Tivoli Storage Manager Java Applet-dsmagent authentication flow
Again, the password is not exchanged between the client and the server.
2.2 Communication between the server and the client

The Tivoli Storage Manager server and client use sessions to communicate. This is normally done by a TCP/IP connection on one or more ports, depending on your configuration. There
26
are various types of sessions. A few are shown in Example 2-1 on page 27. Note the Sess Type heading.
Example 2-1 Sample output from QUERY SESSION
Sess Number -----63,795 63,798 64,659 67,227 67,228 67,233
Comm. Method -----Tcp/Ip Tcp/Ip Tcp/Ip
67,234 67,238 67,244
Sess Wait Bytes Bytes Sess Platform State Time Sent Recvd Type ------ ------ ------- ------- ----- -------Run 0 S 10.4 M 142 Admin WinNT Run 0 S 2.9 K 198 Admin WinNT Run 0 S 261 438 Serv- AIX-RS/er 6000 Memory SendW 1.3 H 478.1 K 214 Admin Server IPC Tcp/Ip IdleW 10.8 M 227.4 M 4.9 K Node WinNT Tcp/Ip RecvW 0 S 3.4 K 9.2 G Node TDP MSSQL Win32 Tcp/Ip IdleW 3 S 329.2 M 3.0 K Node SUN SOLARIS Tcp/Ip RecvW 6.2 M 1.3 K 1.6 G Node TDPO Linux86 Tcp/Ip RecvW 0 S 130.3 K 9.7 G Node TDP Domino
Client Name -------------------ADMIN_1 ADMIN_2 SERVER_1 ADMIN_1 SERVER_2 SERVER_3
SERVER_4 SERVER_5 SERVER_6
2.2.1 Session types

Tivoli Storage Manager communicates using different kinds of sessions for the various communications among the Tivoli Storage Manager clients, the administrative command line (dsmadmc), or other Tivoli Storage Manager servers. The sessions can be summarized into two groups: Client sessions Non-client sessions
Client sessions
These sessions are between the Tivoli Storage Manager server and the client, which is the typical backup/archive session. You use these sessions for transmitting data to be backed up, restored, archived, and retrieved along with the associated metadata from or to the client. Usually a client generates two sessions: one to query the server and one to send file data for a backup or archive session. These sessions are indicated as the SessType Node in the QUERY SESSION output.
Non-client sessions
You use these sessions, for example, when acquiring a drive from the library manager, running administrative commands using dsmadmc, sending SNMP traps, communicating between the Tivoli Storage Manager server and Storage Agents, notifying subscribers, or sending events to the event server. Here is a list of all of the non-client sessions:
27
Administrative sessions These sessions are used by dsmadmc to issue commands against the server. These sessions are indicated as SessType Admin in the QUERY SESSION output. Server-to-server sessions When a Tivoli Storage Manager server is communicating with another server using server-to-server communication, for example, this session is used to back up a storage pool to a virtual volume. SNMP subagent sessions These sessions are used to send an SNMP trap to an SNMP subagent. Storage Agent sessions These sessions are similar to client sessions, but these sessions are initiated and used by a Storage Agent. Library client sessions These sessions are used when a library client communicates with the library manager to acquire a drive. Managed server sessions These sessions are used to notify a managed server subscriber to a profile of a command. Event server sessions These sessions are used by a server to send an event to an event server. Apart from the administrative sessions, all other non-client sessions will be indicated as SessType Server in the QUERY SESSION output.
2.3 Multi-session and transaction data flow

The Tivoli Storage Manager clients use various internal techniques to improve performance. In this section, we describe the multi-session capabilities and client transaction concepts.
2.3.1 Multi-session
Tivoli Storage Manager exploits the multithreading capabilities of modern operating systems by transparently initiating multiple backup/archive or restore and retrieve sessions on the client where necessary for rapid processing and data transfers between the client and the server. The underlying multithreading model used by Tivoli Storage Manager is called the Producer-Consumer or Reader-Writer model. This model usually involves two basic types of threads (seen in Figure 2-4 on page 29): Producer thread that writes data to a buffer Consumer thread that reads data from a buffer
28
Figure 2-4 Producer-Consumer model
2.3.2 Client thread types

The multi-session function involves five types of threads: main, signal waiting, producer, consumer, and performance monitor. Main thread: The main thread handles common housekeeping tasks, such as general system initialization, processing options, authentication with the Tivoli Storage Manager server, command parsing, and policy set retrieval. It also creates the producer thread and the performance monitor thread, and it queues up file specifications to be processed by the producer thread. Signal waiting thread: The signal waiting thread captures signals for the command line client, such as a CTRL+C or CTRL+BREAK to cancel a session. On Windows, the console event handler is used instead. Producer thread: The producer thread is the front end for further processing. It starts the consumer thread and retrieves file specifications queued up by the main thread. This thread queries the Tivoli Storage Manager server and examines the file system to determine which files to back up. Finally it queues the transactions to be processed by the consumer thread. Consumer thread: The consumer thread is the back end for further processing. This thread handles file I/O and, if applicable, it compresses or encrypts data. It processes the transactions queued by the producer thread and sends and commits the data to the Tivoli Storage Manager server. Performance monitor thread: The performance monitor thread attempts to optimize performance by balancing thread usage, which can be affected by the client option RESOURCEUTILIZATION. Periodically, the performance monitor tries to optimize the current performance with the following behavior: Attempts to start a new consumer thread if a new transaction needs to be queued, but the transaction queue is full or the next transaction waiting to be processed is the same as the last time we checked. Attempts to start a new producer thread if the next file waiting to be processed is the same since the last time we checked. Quiesces a consumer thread if more than one consumer thread is running and the time since anything new has been placed on the transaction queue exceeds the threshold.
29
Quiesces a producer thread if more than one producer thread is running, the file queue is empty, and the time since anything new has been placed on the transaction queue exceeds the threshold. Consumer and producer threads are quiesced when there is no more work to be done. Considering these details about the thread model used in Tivoli Storage Manager, the overall process of a multithreaded backup occurs in the following sequence (seen in Figure 2-5): 1. The main thread queues up the file specification for processing by the producer thread. 2. The producer thread gets a file specification from the queue and determines what files in the specification to back up. 3. The producer thread builds transactions and queues them up for processing by the consumer thread. 4. The consumer thread gets a transaction from the queue and sends the data to the Tivoli Storage Manager server. 5. The performance monitor thread helps to determine whether a new producer or consumer thread can be started.
Main thread
Parses cmd User interface
Filespace Queue
fsA fsB ... ... ...
Transaction Queue
txn 1 txn 2 txn 3 .... .... .... ....
Performance Monitor
txn producer txn producer
txn consumer txn consumer txn consumer
Sessions to server
TSM server
Figure 2-5 Producer - Consumer transaction handling and multithreaded backup
The administrator and the user each have controls to influence the number of sessions that a client can start. On the server, the global setting MAXSESSIONS limits the total number of sessions of any kind that can be present. The client node setting MAXNUMMP, in its server definition, controls how many mount points (for sequential devices, such as tape drives) a client can allocate. Finally, the RESOURCEUTILIZATION setting in the client options file increases or decreases the ability of the client to create multiple sessions. Remember that increasing the value for RESOURCEUTILIZATION might require a change to MAXNUMMP. If the client opens more sessions for data transfer, it might need more mount points for storing the data. Therefore, you need to pay attention to the individual settings for these parameters in comparison to the available mount points and the number of clients to process.
30
Additionally, reading and processing one physical disk with more than one consumer thread might decrease local disk performance instead of increasing the overall performance. Whenever there is more than one physical disk to process by one client, we recommend more than one consumer thread, and the system variable RESOURCEUTILIZATION value needs to increase.
2.3.3 Transactions
All data sent to Tivoli Storage Manager storage during a backup or archive session occurs within the bounds of a transaction. Files are not sent to the server as individual objects; instead, Tivoli Storage Manager combines multiple files in one transaction to reduce overhead and to increase performance. When the client starts sending or receiving data, it pays attention to both sides of the communication (the server and the client). All operations are controlled in such a way that Tivoli Storage Manager can detect any data inconsistency during the transfer (due to a network problem, full hard drive, or a file that already exists, for example). This provides a high level of data integrity for the Tivoli Storage Manager product. A single transaction is an atomic action, the smallest possible unit of work. Data sent within the bounds of a transaction is either committed completely to the system at the end of the transaction, or it is all rolled back if the transaction is ended prematurely.
IBM Tivoli Storage Manager Client "HARRY"
D B C E
02
A A B C D E F G H
Transaction 001
Consumer 1 Transaction 001

File00A File00B File00C File00D File00E File00F File00G FIle00H
Consumer 2 Transaction 002

File001 File002 File003 File004 File005 ...
H G
Figure 2-6 Transaction processing
Figure 2-6 shows an example of two backup transactions (Transaction 001 and Transaction 002) that are on their way to the server. Neither of them has finished, because the client is still sending the files related to those transactions. As the server receives the files, it saves them in storage, but it only commits the transaction in the server database after receiving all of the associated files for that specific transaction.
31
If while sending File00F to the server, there is a loss of communication long enough to exceed the timeout period, all the files in Transaction 001 are backed out; that is, none of File00A through File00H is stored. Only incomplete transactions are rolled back ; any completed transactions are not affected. In this way, if for example, a scheduled incremental backup terminates abnormally, when we rerun it, we do not need to resend any files that have already been committed. That is, Tivoli Storage Manager remembers the progress that it has made.
32
Chapter 3.
Client files and services management

This chapter discusses the approaches that are available to configure Tivoli Storage Manager client file permissions and user management for the backup services on Windows and UNIX systems. Other topics include enabling non-root users to access Tivoli Storage Manager functions, preventing non-root users from accessing Tivoli Storage Manager functions, and classifying these users as authorized or non-authorized users. Finally, this chapter presents security issues concerning backing up shared drives and file systems.
33
3.1 Access controls

A variety of factors are involved in determining the resulting access privileges that a user is granted when dealing with Tivoli Storage Manager client services and functions. These factors include local file system permissions, operating system user rights, node access lists, and Tivoli Storage Manager administrators privileges. This section describes each of these access controls.
3.1.1 Types of users

Basically, two types of user or authorization processes take place on the client system. The first process relates to operating system rights and file and directory ownership and permissions. The second type of authorization process happens in the Tivoli Storage Manager realm. Each backed up, or archived, object has an owner recorded in Tivoli Storage Manager, as well as possible authorized nodes or administrators. We will consider these in turn.
Operating system users

We define three types of users when dealing with local system rights: superuser, authorized user, and non-authorized user. These types relate to the operating system account that is used when the user logs in to the local machine. The user ID that is used to log in is used by the operating system to determine access rights to files related to the Tivoli Storage Manager backup/archive client. And, this user ID is also used by the client to register the owner of objects on the Tivoli Storage Manager database (see 3.1.2, Ownership and access permissions on page 39 for more information). Most of these definitions apply for UNIX and Linux systems only, but the general concepts are still valid for Windows behavior and some specific information is provided in the text.
Superuser
The administrator user on UNIX systems is also known as the root user and has an ID with the value of 0 (zero). Other users can have their users ID changed to 0 (zero) also, granting the user the same authority of root user. A user with the user ID of 0 can perform any operating system task and manage Tivoli Storage Manager client resources. Windows systems have the same concept that uses the user name Administrator and a local group called Administrators. After a user is included as a member of this group, the user has all privileges on Tivoli Storage Manager client resources. We refer this type of user as a superuser.
Authorized user
A user who is not a superuser, but instead has full control of Tivoli Storage Manager client files, is referred as an authorized user. For UNIX systems, this user is usually the owner of the files comprising the client package. And, the executable files have permissions set with the SUID bit turned on as shown here for two files owned by user Alice: -rw-r--r-- 1 alice users 55229 Jan 31 15:34 dsmwebcl.log -rwsr-xr-x 1 alice users 7259022 Nov 27 16:49 dsmc Note the first portion of the permission bits for file dsmc. The s indicates the SUID bit is set for this file. The SUID bit means that the process launched by this file will run with the privileges of the owner, instead of the user ID that launched it, which is the default behavior. When a file is created, the user ID that created the file becomes the owner of this file on UNIX and Linux systems, and the files group is set to the primary group of that user. On Windows
34
2003 systems, by default any object created by an Administrator is owned by the local Administrators group. Objects created by a regular user have ownership assigned to the user. Windows XP systems always assign ownership to the creator by default. The Tivoli Storage Manager client package must be installed using a superuser account, so initially all objects, files, and folders are owned by the superuser.
Running Tivoli Storage Manager backup/archive client as an authorized user

After installation, you might want to run the backup/archive client as an authorized user, rather than as root. If so, you need to consider: Password file: Configuring the client files to create an authorized user is a way to promote a non-root user to have control over the functions of Tivoli Storage Manager backup/archive client. This user still has more limited access than the superuser to operating system resources, such as file systems. This user is able to restore or retrieve objects only to locations where this user has write privileges. The backup/archive client node is authenticated by the server using a node name and a password. To allow unattended operations, this password must be encrypted and stored locally to be used by the client when the client has been started. This option eliminates the need to enter the password at the prompt each time that a backup must be processed. The option PASSWORDACCESS GENERATE, included on the client options file, is used to activate this feature. When passwords are stored by using PASSWORDACCESS GENERATE, the default location of the password file is normally a system-wide repository for security-related files. For example, in Windows, the encrypted password is stored in the registry (see Figure 4-2 on page 61). On UNIX other than AIX, and Linux, the default location is /etc/adsm. On AIX, the default location is /etc/security/adsm. The directory /etc/security is used by other applications to store files that need to be secure. Therefore, the directories in /etc/security are usually only accessible by the root user; that is, an authorized user does not have access to those locations. To be able to create and access the password file without using the default path, the authorized user must change the target location for the password file on the client options file to point to a directory where the authorized user has write permissions. The option used for this purpose is PASSWORDDIR in the client system options file. This option is valid for UNIX and Linux clients only; you cannot change the registry location in Windows: passworddir /home/guest If the default location is not changed, then only the root user can create and change the password whenever the password expires, because the authorized user can only use the password file, not change it. Options and log files: An authorized user must be able to change the options files as well to write to the log files. The authorized user can get this ability by changing the ownership of these files to the authorized user or by using an alternative location for the option and log files specified using the DSM_CONFIG and DSM_LOG environment variables. For UNIX systems, you can set a different directory by exporting the variables in the profile script for the authorized user: export DSM_CONFIG=/home/guest/dsm.opt export DSM_LOG=/home/guest/log The command to export the variables and the shell script to include them varies depending on the shell used by your system or user, such as bash, korn shell, or C shell. DSM_CONFIG specifies the fully qualified path and file name of the client user options file for users who create their own personalized options file. The client user options file can be set to any suitable directory, except for the root (/) directory. If DSM_CONFIG is not set, or
Chapter 3. Client files and services management
35
the OPTFILE command line option is not used, then these conditions hold for the client user options file: The options file must be named dsm.opt. If DSM_DIR is not set, then the options file must reside in the default installation directory. If DSM_DIR is set, then the file must reside in the directory that is specified by DSM_DIR. DSM_LOG points to the directory where you want the dsmerror.log, dsmwebcl.log, and dsmsched.log files to reside. You cannot specify the root (/) directory for DSM_LOG. If the root directory is specified, the log is written to the default installation directory. If the options ERRORLOGNAME and SCHEDLOGNAME are present in the options file, these options override the DSM_LOG setting. Client executable (binary) files: By default, these files, such as dsmc and dsm, are located relative to the installation directory. Use the DSM_DIR environment variable to specify an alternative location. DSM_DIR specifies the directory where the executable files, the resource files, and the dsm.sys file reside. The directory can be any suitable directory, except for root (/). To set the directory permanently, include a statement, such as this statement, in the users profile script or set the DSM_DIR environment variable in Windows: export DSM_DIR=/home/guest/bin As an alternative to setting DSM_DIR, you can use the files in their original location, but change their ownership to the authorized user. For example: chown chown chmod chmod guest dsm guest dsmc 4755 dsm 4755 dsmc
You must set the SUID bit for the dsm and dsmc executable files. Otherwise, the backup/archive client reports this error message and exits: ANS1501E Trusted agent execution/owner permissions are invalid USERS statement: Check your dsm.sys file to see if it has a USERS statement. If a USERS statement exists, make sure that the authorized user is included. If the statement does not exist, there is no restriction, so you do not need to add it. users root, guest
Summary
Therefore to become an authorized user, you must satisfy the following conditions: You must be able to create, read, and write to the password file. You need the ability to create, read, and write to the log files. You must be able to create, read, and write to the preferences files, such as dsm.opt and dsm.sys. You must have ownership of the binary files dsm and dsmc, and the SUID bit of these files must be set.
Non-authorized user A non-authorized user means a user who is neither a superuser, nor the owner of the Tivoli
Storage Manager client files and folders, but somehow has permission to access Tivoli Storage Manager client services.
36
In UNIX and Linux systems, this requires performing at least one of the following procedures: The owner of the files, or the superuser, has granted group read and execute permissions, and the non-authorized user belongs to the same group. Read and execute permissions are granted to other users by the owner of the files, or the superuser. For example, the user bob has permission to read and execute dsmc if the file has the permissions shown here and if bob belongs to the group called users: -rwxr-x--1 alice users 7259022 Nov 27 16:49 dsmc
Although a non-authorized user cannot modify the default system preferences file (dsm.sys), a non-authorized user still can create a unique user preferences file (dsm.opt) and set the environment variable DSM_CONFIG to use this personalized file when running Tivoli Storage Manager client utilities. Although, this function is more restricted on UNIX systems, because most available options must be inserted on the dsm.sys file. To enable non-authorized users to access and use Tivoli Storage Manager services to manage their own data, the root user must do the following: 1. Set the permissions on the files so that non-authorized users can read and execute the binary files dsm and dsmc. 2. Set the permissions on the options file so that non-authorized users can read those files. 3. Set the DSM_LOG variable on the profile script for each user to point to a directory where the user has write privileges, such as the users home director. The root user must ensure that options ERRORLOGNAME and SCHEDLOGNAME are not specified on the server stanza, because these options override DSM_LOG setting. 4. Set the ownership of dsmtca file to root and set the SUID bit for this file. The permission should be 4755. Use the commands: chown root dsmtca chmod 4755 dsmtca 5. Check your dsm.sys file to see if it has a USERS statement. If the USERS statement exists, make sure that the non-authorized user is included. If the statement does not exist, there is no restriction, so you do not need to add it. users root, guest 6. While logged in as root, generate the password file on the Tivoli Storage Manager client by specifying the node password for the first time. After the password file is stored, the non-authorized user can access Tivoli Storage Manager client services, because the Trusted Communication Agent (dsmtca) will manage the password file access. This process runs with root privileges, because the SUID bit for dsmtca is turned on. A non-authorized user must always make use of the Trusted Communication Agent (dsmtca). For more information about dsmtca, see The Trusted Communication Agent on page 64.
Windows specifics
On Windows systems, a regular user can create a unique options file and include the options SCHEDLOGNAME and ERRORLOGNAME in it. These options must point to a directory where the user has write access. The dsm or dsmc executable must be called to pass the options file location through the OPTFILE option. For example, users can create a shortcut on their desktop to launch the command: C:\Program Files\Tivoli\TSM\baclient\dsm.exe -optfile=C:\Documents and Settings\user2\dsm.opt
37
However, to be able to perform backup and restore operations of an entire machine, the user must be a member of either the Administrators group or the Backup Operators group. With the privileges of one of these groups, the user can access all files across the system. Be sure that the Manage auditing and security log right has been assigned to this group (as shown in Figure 3-1) when working with NTFS; otherwise, backup and restore operations might fail. This right is required to access NTFS System Access Control list (SACL) security descriptors. The client interrogates the SACL of each NTFS object to determine if the object needs to be backed up or updated due to a change in its attributes.
Figure 3-1 Manage auditing and security log Security Settings
A member of the Backup Operators group can execute the following operations: Start the scheduler service. Back up or restore files. Back up or restore Windows System Services. Back up or restore Windows System State. A member of the Backup Operators group cannot execute the following operations: Start any other service (Client Acceptor, Remote Client Agent, or Journal Services). Install and configure client services. Use Tivoli Storage Manager Open File Support. Perform image backup and restore. Back up and restore Windows file shares. Perform a backup of a cluster quorum on a server cluster.
Tivoli Storage Manager administrators

This section discusses Tivoli Storage Manager administrators with node privilege. We discuss the remaining privilege classes in 7.2, Overview of Tivoli Storage Manager administrator roles on page 160. Administrators with node privilege can remotely access a Web backup/archive client and perform backup and restore actions on that client using the administrator ID and password. The privilege can be for one or more specific nodes or all client nodes in a domain. The command GRANT AUTHORITY is used to grant privileges to an administrator, and the command REVOKE AUTHORITY is used to revoke them. When using node class, one of two authorization levels must be applied: client owner or client access.
38
For example, this command grants node privileges to the administrator BOB over the node NODEA with the authorization level of client owner: grant authority BOB class=NODE authority=OWNER node=NODEA
Client owner privilege

A user with client owner privilege can access the client and its data from either a remote Web client or the native backup client so that data can be restored either to the original client or to another client using the VIRTUALNODE option. Administrators, who have system or policy privileges over the domain where the client node is registered, have client owner privilege by default. Using the option USERID in the commands REGISTER NODE or UPDATE NODE creates an administrator with client owner privilege over that node. The REGISTER NODE command, if issued without the USERID option, creates an administrator with client owner privilege over the registering node using the same name of the node to the administrator. Alternatively, you can specify USERID=none to prevent defining the administrator, or USERID=<somestring> to use a different name than the node name.
Client access privilege

A user with client access privilege can access the client and its data from a remote node client and can only restore the client data back to the original client. This is the default authorization level for the node privilege class.
3.1.2 Ownership and access permissions

This sections content is valid for UNIX, Linux, and Mac OS X backup archive clients. When backing up objects with the Tivoli Storage Manager backup/archive client, standard permissions are saved together with the files and directory objects. Depending on the client platform, you can save extra information as well, for example, for AIX files, any Access Control Lists (ACLs) are saved along with the standard permissions. The file or directory owner is stored in the Tivoli Storage Manager database, regardless of which operating system user ID executes the backup operation. Figure 3-2 on page 40 shows two files: File1 is owned by user1, and file2 is owned by user2. The file permissions are also indicated. Both user IDs are members of the group users. Assume that user1 is an authorized Tivoli Storage Manager user (as defined in Authorized user on page 34). Because the permissions that have been set give user1 read authority on both file1 and file2, user1 can back up both files. The ownership of those files that is recorded in Tivoli Storage Manager remains the same: User2 is registered as the owner of the object file2, and user1 is registered as the owner of file1.
39
TSM Server
Backup file1 and file2
user1
permissions -rwxr--r--rwxr--r-owner user1 user2 group users users filename file1 file2 object file1 file2 owner user1 user2
Figure 3-2 Ownership of backed up objects
You can check the ownership of an object through a SELECT statement in the Tivoli Storage Manager administrative interface as shown: select node_name,ll_name,owner from backups where node_name= node name and STATE= ACTIVE_VERSION Note that this SELECT clause can return a long list and have a significant impact on a busy Tivoli Storage Manager server. We recommend that you provide stricter conditions to filter out unneeded data. A non-authorized user can only restore files that the user owns while a superuser or an authorized user can restore any file. When restoring objects with an authorized user other than the owner of the backed up object, the restored files have their ownership changed to the authorized user. Unless the file already exists, in which case, the original owner is preserved. For archive operations, the user who runs the archive command becomes the owner of all of the archived objects, no matter who owns the original file on the local file system. See Figure 3-3 on page 41 for an example.
40
Non-authorized user
TSM Server
Archive file1 and file2
user1
permissions -rwxr--r--rwxr--r-owner user1 user2 group users users filename file1 file2 object file1 file2 owner user1 user1
Figure 3-3 Ownership of archived objects for non-authorized users
The root user becomes the owner of the Tivoli Storage Manager objects when the files were archived using an authorized user. See Figure 3-4.
Authorized user
TSM Server
Archive file1 and file2
user1
permissions -rwxr--r--rwxr--r-owner user1 user2 group users users filename file1 file2 object file1 file2 owner root root
Figure 3-4 Ownership of archived objects for authorized users
To retrieve an archived object, the user running the command must be either the owner, the superuser, or an authorized user. Note that the owner of the archived object on the Tivoli Storage Manager server cannot be the original owner of the local file.
What objects are visible for restore and retrieve

A UNIX or Linux client session assigns a session owner when contacting the Tivoli Storage Manager server. If the session is initialized with an explicit owner name, which happens when the client is run as a non-authorized user, only Tivoli Storage Manager objects, which have that owner name associated with them, are returned. Essentially, this means that a Tivoli Storage Manager client running as the root user or an authorized user has access to all objects, whereas a non-authorized user running the Tivoli Storage Manager client can only access objects owned by the user. Table 3-1 on page 42 presents the rules for determining which objects you can access in UNIX and Linux.
41
Table 3-1 User access to objects in UNIX and Linux Session owner NULL (root or authorized user) Specific name (non-authorized user) Specific name (non-authorized user) Specific name (non-authorized user) Object owner Any name or empty Empty Same name Different name User access Yes No Yes No
On Windows clients, the session owner is always initialized with a NULL value, and the owner field for client objects in the Tivoli Storage Manager database is empty. This is because Windows file permissions and ACLs are made of separate pieces from the file attributes and can vary in length, normally larger than file attributes. These objects are kept in the storage pools instead of in the Tivoli Storage Manager database. The same applies to NetWare clients. File attributes are stored in the Tivoli Storage Manager database regardless of platform. For UNIX and Linux systems, the file permissions are part of the attributes; therefore, they are stored in the Tivoli Storage Manager database for this client platform. Figure 3-5 shows the process where the server verifies which objects the client can access for the node that is being used. Due to the specific implementation of permissions on Windows and NetWare clients, the authorization process shown in Figure 3-5 does not apply for those platforms and a regular user can access objects that were backed up by any other user.
TSM B/A Client
Can I access this object?

TSM Server
Object file1 file2 file3 file4 Owner user1 root user2 user1 TSM DB
Backup/Archive Client initiates the session. Session owner is determined.

My session owner is USER.
Authentication process happens here.

Client authenticated.
Backup/Archive client mounts the request of objects.

Query my backup objects for this node.
Server receives the request and checks the object owner. If session owner and object owner are the same, access is permitted. Also if session owner is NULL. Otherwise, access is denied.
Backup/Archive client initiates the restore/retrieve or aborts operation depending on the answer from the server.
Send answer to the client.
Figure 3-5 Authorization check to access objects
42
Table 3-2 shows how the session owner is determined by the Tivoli Storage Manager backup/archive client:
Table 3-2 Session owner and access scope for backup/archive client User type Superuser Authorized user Non-authorized user Session owner NULL NULL user2 Objects that the user can see All All file3
User name root user1 user2
In summary, the following rules apply when a client requests access to a object that has been backed up or archived: Root user and authorized users can restore or retrieve any object for the node. The authorized user needs, in addition, to use a destination where the authorized user has write permissions. Non-authorized users can restore any objects that they own. In backup operations, the ownership of the original files is honored; therefore, the user can own files that are backed up by the root user or an authorized user. Non-authorized users can retrieve objects that they archived, because the ownership of archived objects is always registered in the Tivoli Storage Manager server to the user who launched the archive command.
Using the application programming interface

Using the Tivoli Storage Manager client application programming interface (API), however, prevents you from changing the session owner when using PASSWORDACCESS GENERATE. The session owner field is always set to the user running the process when you use the API, and the option PASSWORDACCESS is set to GENERATE. When PASSWORDACCESS is set to PROMPT, the program that uses the API can set the session owner field. This process protects the data from unauthorized users taking advantage of the use of a password file, running malicious code to access the API, and trying to get access to the data of other users. The API functions available to initiate an API session are the dsmInit and dsmInitEx functions. For these functions, a parameter called clientOwnerNameP points to the session owner. IBM Tivoli Storage Manager Using the Application Program Interface, SC32-0147, states that This parameter must be NULL if the PASSWORDACCESS option in the dsm.sys file is set to GENERATE. The API then uses the log-in user ID. and If PASSWORDACCESS is set to PROMPT, it is not necessary for the owner name to match the active user ID of the session running the application.
3.1.3 Mapping allowable tasks to users

Table 3-3 on page 44 shows common Tivoli Storage Manager tasks and whether root, authorized users, and non-authorized users can perform these tasks. As we mentioned earlier, most of the restrictions for restore and retrieve of objects do not apply to Windows systems.
43
Table 3-3 User authorization table Task Install the backup/archive client Registering new nodes with Tivoli Storage Manager server Create or change the Tivoli Storage Manager password file for client workstations Create and modify dsm.sys Create and modify the client user options file (dsm.opt) Root user Yes Yes Authorized user No Yes Non-authorized user No No, even when the registration is set to open on the server. No
Yes
Yes, if the user has write permission to the file. Yes, if the user has write permission or owns the file. Yes, if the user has write permission or owns the file.
Yes
No
Yes
Yes, if the user is using a personalized file, using the DSM_CONFIG variable. No
Create and modify an include-exclude list Backup
Yes
Yes, if the user has write permission or owns the file. Yes, if the user has read permission, regardless of ownership. Yes. However, the operating system will prevent writing to the same location if the file has read only permission. If the file exists, ownership will not be changed. If the file does not exist, ownership will be changed to authorized user. Yes, if the user has read permission, regardless of ownership.
Yes
Yes, if the user owns the file.
Restore
Yes. When restoring to a new location or the same location, file permission and ownership are restored also.
Yes, if the user owns the file or if the user is granted access (SET ACCESS command). The ownership of the restored file will change to the non-authorized user.
Archive
Yes
Yes, if the user has read permission, regardless of ownership.
44
Task Retrieve
Root user Yes. When retrieving to a new location or to the same location, file permissions and ownership are preserved.
Authorized user Yes. However, the operating system will prevent writing to the same location if the file has read only permission. If the file exists, ownership will not be changed. If the file does not exist, ownership will be changed to authorized user. Yes Yes
Non-authorized user Yes, if the user archived the file. Ownership of all retrieved objects will be changed to the non-authorized user.
Client Scheduler Grant user access to files on the Tivoli Storage Manager server Delete Tivoli Storage Manager server file spaces
Yes Yes
No Yes, for files that the user owns on the Tivoli Storage Manager server. No.
Yes, if the user is granted backup or archive delete authority by a Tivoli Storage Manager server administrator.
Yes, if the user is granted backup or archive delete authority by a Tivoli Storage Manager server administrator.
The reason why a non-authorized user can archive files that the non-authorized user does not own, although this user cannot back them up, is that otherwise the version-based policy of backed up objects allows the user to quickly saved object versions by running repeated backup operations. That way, a user can force the expiration of historical data, which belongs to other users, that was not supposed to be removed from storage at that time. Archived objects are not under version-based retention policies, so the implementation allows a user to archive objects belonging to another owner.
3.1.4 Protecting the UNIX and Linux client files

For UNIX and Linux clients, we have previously discussed how to allow authorized users and non-authorized users to access and run Tivoli Storage Manager functions. Although those configurations provide higher flexibility to use and manage the system, they increase the risk of undesirable exposure of the data resulting from a mistake in the configuration tasks. The most restrictive environment only allows Tivoli Storage Manager access from the root account. Any other users are denied any access to the executable binaries and configuration files of the Tivoli Storage Manager client package. The following section shows how to create this type of an environment.
Restricting client access to the root user only

The UNIX and Linux Tivoli Storage Manager client package includes several files and directories. The exact number depends on the platform, architecture, use of language packs, and log files generated. The top level directory for the client package is called client and the default location is /usr/tivoli/tsm or /opt/tivoli/tsm.
45
We will start the procedure at this directory level: 1. Log on as root user. Change to the client parent directory: /usr/tivoli/tsm or /opt/tivoli/tsm. 2. Save the original ownership and permissions by generating a file containing the tree structure: root@myhost:/usr/tivoli/tsm # find client -ls | awk '{printf "%s %s %s %s\n", $3, $5, $6, $11}' > orig_permissions.txt With this file, you can always revert back to the original settings if necessary. Change the permission of this file so that only the root user can read it: root@myhost:/usr/tivoli/tsm # chmod 400 orig_permissions.txt 3. Remove all group and other permissions and root write permissions on the client tree: root@myhost:/usr/tivoli/tsm # chmod -R u-w,go-rwx client The client directory entry now shows: dr-x-----7 root system 256 Dec 07 13:06 client 4. Change to the client/ba/bin directory: root@myhost:/usr/tivoli/tsm # cd client/ba/bin 5. Remove the SUID bit of file dsmtca. This prevents the use of the Trusted Communication Agent, although the regular user has already been denied access to the client files through the previous changes: root@myhost:/usr/tivoli/tsm/client/ba/bin # chmod u-sx dsmtca The file entry now shows: -r-------1 root system 4241400 Nov 27 16:49 dsmtca 6. Grant permissions to root to read and write the log files. The location of the log files can vary depending on your configurations in dsm.sys: root@myhost:/usr/tivoli/tsm/client/ba/bin # chmod 600 *.log 7. Within the Tivoli Storage Manager client, you can also prevent any other users than root from accessing the client functions. Again, this is an additional measure, because the previous steps prevent the regular user from accessing the files. Include the following line on the dsm.sys stanza for the client: users root 8. Start the dsmc client and check for any errors. 9. Start your service, depending on your implementation, either the client acceptor or the client scheduler, as a daemon. 10.Schedule an action and check the client log files to confirm that everything works properly. 11.Verify other application level security options, as described in Chapter 4, Securing the client on page 59 and apply them according to your needs. Those options allow you to prevent an administrator or a client from running scheduled commands or scripts, for example.
Reverting to the original ownership and permission settings of an object

To restore the original ownership and permission settings, you need the text file that was generated in step 2 in the previous section. In our example, we called it orig_permissions.txt. The commands we present here were developed in Korn shell. If you use another shell, you might need to make minor adjustments.
46
To restore the original ownership and permission settings: 1. Log on as root user. Change to the Tivoli Storage Manager parent directory, for example, /usr/tivoli/tsm or /opt/tivoli/tsm. We assume that file orig_permissions.txt is located here. 2. Generate a script to revert the ownership of the files and directories, issuing the command: root@myhost:/usr/tivoli/tsm # cat orig_permissions.txt | awk '{ printf "chown %s:%s %s\n",$2,$3,$4 }' > recover_owner.sh root@myhost:/usr/tivoli/tsm # chmod 500 recover_owner.sh 3. Generate a script to recover the original permission settings of the files: root@myhost:/usr/tivoli/tsm # cat orig_permissions.txt | sed "s/^$[-d]$$[-rwx][-rwx][-rwx]$$[-rwx][-rwx][-rwx]$$[-rwx][-rwx][-rwx]$/ u=\2,g=\3,o=\4/;s/$[=rw]$-*/\1/g" | awk '{ printf "chmod %s %s\n",$1,$4 }' > recover_perm.sh root@myhost:/usr/tivoli/tsm # chmod 500 recover_perm.sh 4. Execute the scripts: root@myhost:/usr/tivoli/tsm # ./recover_owner.sh root@myhost:/usr/tivoli/tsm # ./recover_perm.sh 5. To make sure that everything is exactly the same as before, we can create another text file with the current tree. Use a different name for the output file, so that you do not overwrite the original file: root@myhost:/usr/tivoli/tsm # find client -ls | awk '{printf "%s %s %s %s\n", $3, $5, $6, $11}' > curr_permissions.txt 6. Use the operating system utility called diff to check differences between the two files: the original file and the current file: root@myhost:/usr/tivoli/tsm # diff orig_permissions.txt curr_permissions.txt If there were no differences, this command returns with no output. If differences are reported, adjust the remaining files manually.
3.2 The client services and daemons

Among the Tivoli Storage Manager client package, there are components that you can configure as services on Windows machines or daemons on UNIX or Linux systems. Several of these services enable scheduled operations to execute without user intervention, and other services implement special features, such as the Web client or Journal service for Windows. We discuss the basic set of services in this section, and they are: Tivoli Storage Manager client scheduler: This service is responsible for executing operations on the client node, such as backup/archive, according to tasks received from the scheduler process running on the Tivoli Storage Manager server. When running this process continually as a service, you need to restart it in order to make any change to the client options file effective. Tivoli Storage Manager Web client agent: This service implements the Web interface to the client, allowing the user to execute operations on the client node through a Web browser that was started on a remote system. Tivoli Storage Manager Client Acceptor Daemon: Use this service to manage one or both of the previous services. It works as a wrapper, starting the required service (scheduler or Web client) when a request for that service is
47
received, or at the time scheduled to execute a task. When you use this service, the other two services remain dormant and return to this state after finishing the task that is requested by the Client Acceptor. In addition to reducing the CPU load required to run the services, using the Client Acceptor to manage the scheduler also means that you do not need to restart any service after changing the options file. Figure 3-6 shows these Windows services.
Figure 3-6 Tivoli Storage Manager basic services on Windows
Next, we discuss how these services are affected by the users authorization, as well as how, and if, they can run under a non-privileged user.
3.2.1 Running services on Windows

On Windows clients, the Tivoli Storage Manager client services are usually configured to run with the Local System account. This is a powerful built-in account with full access to all resources on the local computer. This account does not have a password to be managed, because this account cannot be used as a log-in account by a regular user. Apart from this difference, this account can be used by services to authenticate and access local resources in the same manner as a regular user account. With the release of Windows Server 2003, Microsoft made several changes to the built-in accounts and introduced the Local Service account. This new special account has limited privileges while it is still intended to be used by Windows or third-party software that needs to run as services. Because most core Windows Server 2003 services still require the use of the Local System account, the Local Service account does not have sufficient privileges to be used by Tivoli Storage Manager services without significant changes to its default permissions.
Using a regular account for the Tivoli Storage Manager services

An alternative approach is to use a regular user account and give it the necessary privileges to start the services and back up all local files. This approach increases considerably the burden of system administrators to maintain the Tivoli Storage Manager services availability, because the regular password expiration policy applies. Recovering from the situation where the service will not start because the password has expired, or preventing this situation from happening before the expiration date, can be a painful process. Both the user password and the password in the services properties must be changed. Changing the user password and the password in the services properties manually and quickly becomes impractical in environments with many nodes. The administrator can choose to write a script and deploy it using a software distribution tool or even by using logon scripts. In this case, the administrator still has the difficult task of keeping control of where those services are installed and running.
48
An MSDN article contains a script to change the password on a services user account. Note that we provide this for information only. We have not tested this script to prove its functionality or applicability to a Tivoli Storage Manager environment: http://msdn2.microsoft.com/en-us/library/ms675577.aspx There are tools that are available as commercial packages, including: Lieberman Service Account Manager ScriptLogic Service Explorer These commercial packages and other tools provide a discover function, which allows the administrator to dynamically maintain a database of managed machines and the services that they run; searching capabilities to filter machines running specific services; and a centralized update of the services properties. To configure an account on Windows Server 2003 to be used by the Tivoli Storage Manager services, you need to: 1. Log on to the system as an administrator. 2. Install the Tivoli Storage Manager client as usual, and configure the scheduler, Web client, and Client Acceptor using the Local System account. 3. Stop the services. 4. Create the account that will be used to run the Tivoli Storage Manager services. Use a common name across the enterprise to make it easier to administer. 5. Include this user in the Backup Operators group. 6. Ensure that the Backup Operators group has the Manage auditing and security log right. See Figure 3-1 on page 38. This right is not assigned to this group by default. 7. You must also be certain that there are no disk quota restrictions that might restrict your access to a hard disk. These restrictions make it impossible for you to back up data. To check whether there are any disk quota restrictions, right-click the disk to which you want to save data, click Properties, and select the Quota tab, as shown in Example 3-7 on page 50.
49
Figure 3-7 Check disk quota restrictions
8. Change the schedule log and error log destinations by using the ERRORLOGNAME and SCHEDLOGNAME options in the client options file to a directory for which the user has the write privilege. Restart the client GUI one time to make sure that it works. If the client cannot write to the log file, you will see an error display. Using the GUI is better than the command line client for this test, because the CLI window quickly closes after the error, usually before you can see the error message. 9. In the Windows Services applet, select each Tivoli Storage Manager service and change the Log On tab property information to the user that was recently created. This user is automatically assigned the correct rights the first time that the user performs this task. See Figure 3-8 on page 51.
50
Figure 3-8 Changing the logon properties of a service
10.Start the service. If you use the Client Acceptor, this is the only service configured as Automatic and the service continues. Run a scheduled operation to check that the scheduler works properly. Note that if you decide to run services under a regular account, you must check to see if the account has the correct authority to back up the required objects, especially System State, for example. You might see that it is not possible to use a user account and that you have to return to using the Local System account. In order to allow the scheduler to execute actions unattended, you must specify PASSWORDACCESS GENERATE on the client options file (dsm.opt) and also store the password locally by running a command locally that forces a connection to the server, such as dsmc query session.
3.2.2 Running services on UNIX or Linux

As we discussed in the introduction to this section, 3.2, The client services and daemons on page 47, you can choose to use the Tivoli Storage Manager Client Acceptor Daemon to manage the scheduler or simply run the scheduler process in the background. The Client Acceptor Daemon (also known as dsmcad or CAD) causes a smaller CPU load than the scheduler process that runs continually and does not require a restart of the daemon when options change in the client options file. The use of the CAD to manage the schedule requires the clause MANAGEDSERVICES in the client options file: managedservices scheduler The command to start the Tivoli Storage Manager CAD on a UNIX or Linux system must specify the complete path to the options file: /path_to_dsmcad/dsmcad -optfile=/path_to_optionfile/myfile.opt
51
Because the CAD becomes a daemon, it looks, by default, in the root (/) directory for the options file, unless you specify the full path on the command. To use the scheduler without being managed by the CAD, run the command: nohup /path_to_dsmc/dsmc sched -se=servername & In this command, the servername is the name that is specified by the clause SERVERNAME for the client stanza in the client options file. This command starts the scheduler in the background and remains active even after you log out of the system. To start the process or daemon automatically, you need to include calls for them on the initialization scripts, commonly in the /etc/inittab file. Refer to the Tivoli Storage Manager Client Guide for your platform to see more details about this topic. Regarding the user chosen to run these services, consider: The CAD runs as a daemon and cannot be started as any other user than the root user. The scheduler can run as a non-root user in the background but might have limited access to objects in the file systems to execute Tivoli Storage Manager client operations. If the user running the scheduler is a non-root user, this user must be an authorized user. Read Types of users on page 34 to see how to define an authorized user. A non-authorized user is not allowed to run the Tivoli Storage Manager client scheduler. Regardless of whether the scheduler is managed by the CAD or started in the background, the initialization scripts for these daemons are normally inserted in the /etc/inittab file. See Backup-Archive Installation and Users Guide for Unix and Linux, SC23-0145, for more details about how to configure these services. In order to allow the scheduler to execute actions in an unattended mode, you must specify PASSWORDACCESS GENERATE on the server stanza indicated in the dsm.sys file and store the password locally by running a command locally to force a connection to the server, such as dsmc query session.
3.3 Shared drives and file systems

This section discusses the requirements for unattended backups or archives of the network mapped drives, also known as shared drives, or simply shares. Because there is an inherent impact on the networks performance and the security of the protocols that are used to allow resources sharing, we suggest alternatives to this type of operation in your environment.
3.3.1 Windows shared drives

To backup network mapped drives, the Tivoli Storage Manager client must be configured to use an account with sufficient privileges on the target machine. The Local System account, that the Tivoli Storage Manager client services are usually configured to use, does not have access to network shared resources. Configure the Tivoli Storage Manager scheduler service to run under a domain authorized user by using the dsmcutil or the Service Control Panel Application. This account must have authority to access the network drives that you want to back up. Shares from file servers that belong to different domains or from file servers configured as standalone servers in a workgroup are not accessible for Tivoli Storage Manager client services, such as scheduler and Web client, because, in these services, the system prompts you for the user and password.
52
A common mistake is to test the backup manually while logged in as a regular user and to configure the scheduler service to run under the Local System user. The test can be successful, but the unattended backup will probably fail. In addition to the use of a domain account for the scheduler service, the scheduled commands must use the Universal Naming Convention (UNC) name to specify the share to back up or archived. The UNC name is a network resource name for a share point on a workstation. The resource name includes the workstation name that is assigned to the workstation and a name that you assign to a drive or directory so that it can be shared. A UNC name has the form: \\server\share This is an example of a command to back up a network share called myshare on server alice: dsmc sel \\alice\myshare You can optionally add the UNC names to the DOMAIN clause in the client options file: DOMAIN \\alice\myshare To configure the scheduler service to run under the authorized domain account, which enables it to back up the network shared resources, perform the following steps: 1. In the Services applet, locate the Tivoli Storage Manager scheduler service. See Figure 3-6 on page 48. 2. Right-click the entry, and select Properties. 3. Select the Log On tab. See Figure 3-8 on page 51. 4. Select This Account. 5. Enter the domain name and user account in the text box, using the form DOMAIN\ACCOUNT. 6. Enter the password twice in the appropriate text boxes. 7. Click OK. 8. Restart the service. You need to update the password of this service and restart it every time that the users password expires. See Using a regular account for the Tivoli Storage Manager services on page 48 to read about considerations for managing the password expiration of accounts that are used by services. Backing up Windows file shares is inherently inefficient and requires the creation of a domain account with special privileges. The data is transmitted twice on the network: one time from the file server to the client machine and from that machine to the Tivoli Storage Manager server. You need to avoid this configuration whenever possible. Consider these options: Using the Tivoli Storage Manager client on the file server. Consider the use of the Journal service to improve the backup efficiency. If you are backing up NetApp CIFS shares or EMC Celerra NAS file servers, consider using the NDMP support in Tivoli Storage Manager Extended Edition to speed up the backup process and to avoid the network traffic. Also, network backup support for heterogeneous volumes with a mixture of NTFS and UNIX files is limited and you need to avoid it. Check the IBM Tivoli Storage Manager Administrators Guide for your platform to see how to implement NDMP backups.
53
Using the Local System to back up network mapped drives

You can back up network mapped drives from a machine that does not belong to the same domain of the file server or from a file server configured as a standalone server. You use the Local System account to start the scheduler service and use scripts that map the drive, execute the backup, and then unmap the drive. For example, this is a script that you can execute: net use x: \\server\share /user:server\user password path_to_dmsc\dsmc inc x:\file net use x: /delete On older versions of Windows, such as Windows NT and Windows 2000 Server, the drive letters of local and mapped drives are visible globally on the system. This means that all users see all of the same defined drives, even those network drives that were created by other users and, if they have the necessary rights, a user can access them also. For Windows Server 2003 and Windows XP, each user has a unique set of drive letters. A user then cannot see the mapped drives that were created by other user. Actually, the mapped drives are created based on logon sessions, where the system keeps the relationship between the users Logon Security Identifier (SID) and the set of drive letters for this identifier. Even the same user can have simultaneous logon sessions on the system, each session with its own set of drive letters, preventing a session from seeing or manipulating drives assigned to another session. The sessions identifier can be related to a logged on user or a service configured to run under a user account. In this case, the service creates a new logon session and is not able to see, for example, drives mapped manually by a user through an interactive and simultaneous session. For the Local System account, however, all processes running under this credential share the same logon session, and drives mapped under this account are visible to all logon sessions on the system. Users logged into the same system are able to see the drives on the file manager and a user with adequate permissions, such as users in the local Administrators group, can manipulate data on the network share. Refer to the following Microsoft article, INFO: Services and Redirected Drives for more information about this topic: http://support.microsoft.com/kb/180362/ Go to this Web site for another Microsoft article, Network access validation algorithms and examples for Windows Server 2003, Windows XP, and Windows 2000: http://support.microsoft.com/kb/103390/ Therefore, we do not recommend that you use the method that uses the Local System account to launch scripts explicitly mapping shares to drive letters, because it includes at least two security risks: You need to include the user and the password of the remote user in the script, because the Local System account does not have privileges to access network resources, so you need to specify a remote user to access it. It forces you to use the drive letters to the shares, instead of making use of UNC names, which exposes the drives to other users on the system.
54
Windows share definitions

Because mapped drive definitions are not part of the file or folder attributes of Windows shares, they are not restored together with the shares content. Share definitions are saved into the Windows registry under the HKEY_LOCAL_MACHINE subtree and the following key: SYSTEM\CurrentControlSet\Services\LanmanServer\Shares This information is only backed up through the System State backup on Windows Server 2003 systems. When you select Registry, the whole System State is automatically selected, as shown in Figure 3-9:
Figure 3-9 System State backup on Windows Server 2003
On Windows XP systems, the registry is included in the System Object. See Figure 3-10.
Figure 3-10 Registry backup on Windows XP
55
3.3.2 UNIX and Linux Network File System

Network File System (NFS) Protocol is a protocol that was first introduced by RFC1094. It is intended to provide remote access to file systems that are physically located on other systems and connected by a TCP/IP network. RFC1094 is available at: http://www.ietf.org/rfc/rfc1094.txt?number=1094 For many reasons, NFS is widely considered insecure, with several known exploits and weaknesses. Notwithstanding this general impression, NFS is very popular and widely used in corporate environments. Due to this fact, many people have been working to improve NFS security. One modification of NFS implementation allows you to use Kerberos authentication to NFS exports. A simple search on the Internet gives you many sources of information about this topic. You can obtain a good guide for securing NFS in Securing NFS in AIX An Introduction to NFS v4 in AIX 5L Version 5.3, SG24-7204. Also, NVS V4 has addressed several performance and security issues. You can read the definition of NFS v4 at: http://www.ietf.org/rfc/rfc3530.txt?number=3530 Refer to the documentation for your specific UNIX operating system for further details about mounting NFS file systems. When backing up remote file systems using NFS, the node responsible for issuing the backup must have read access to the remote file system and files. For example, assume that the directory /home/guest is exported on the vanilla system (NFS server) and mounted by the sky system (NFS client) on /mnt/nfs. The data can be backed up from node sky using the command shown in Example 3-1.
Example 3-1 Backup of an NFS file system
tsm> inc /mnt/nfs/ Incremental backup of volume '/mnt/nfs/' Normal File--> 1,178 /mnt/nfs/.sh_history ** Unsuccessful ** ANS1228E Sending of object '/mnt/nfs/.sh_history' failed ANS4007E Error processing '/mnt/nfs/.sh_history': access to the object is denied Normal File--> 175 /mnt/nfs/TSM.PWD ** Unsuccessful ** ANS1228E Sending of object '/mnt/nfs/TSM.PWD' failed ANS4007E Error processing '/mnt/nfs/TSM.PWD': access to the object is denied Normal File--> 1,326 /mnt/nfs/dsmerror.log [Sent] Normal File--> 48 /mnt/nfs/testenfs.txt [Sent] ANS1114I Waiting for mount of offline media. Retry # 1 Normal File--> 1,326 /mnt/nfs/dsmerror.log [Sent] Retry # 1 Normal File--> 48 /mnt/nfs/testenfs.txt [Sent] ANS1802E Incremental backup of '/mnt/nfs/*' finished with 2 failure Total number of objects inspected: 4 Total number of objects backed up: 2 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 2 Total number of bytes transferred: 2.80 KB Data transfer time: 0.00 sec Network data transfer rate: 133,742.55 KB/sec Aggregate data transfer rate: 0.05 KB/sec 56
Objects compressed by: Elapsed processing time: tsm>
0% 00:00:52
Note that two objects failed to back up because of the lack of file read permissions. You can specify the NFS file system in the DOMAIN clause of the client options file: domain /mnt/nfs The keyword all-nfs for this clause includes all network file systems on the backup except those network file systems handled by the automounter: domain all-nfs Refer to IBM Tivoli Storage Manager for UNIX and Linux Backup Archive Clients Installation and Users Guide V5.4, SC32-0145, for more details about implementing the backup of NFS file systems. Backing up remote file systems through NFS is inherently inefficient and can introduce security breaches if you do not configure it carefully. The data is transmitted twice on the network: one time from the file server to the client machine and from that machine to the Tivoli Storage Manager server. You need to avoid this configuration whenever possible. Consider these options: Using the Tivoli Storage Manager client on the file server. If you back up NetApp CIFS shares or EMC Celerra NAS file servers, consider using the NDMP support that exists on Tivoli Storage Manager Extended Edition to speed up the backup process and avoid the network traffic. Also, network backup support for heterogeneous volumes with a mixture of NTFS and UNIX files is limited and needs to be avoided. Check the Tivoli Storage Manager Administrators Guide for your platform to see how to implement NDMP backups.
57
58
Chapter 4.
Securing the client

This chapter covers the available options for you to protect the client system of Tivoli Storage Manager client resources. These options include: Client authentication methods Client password management Prevention of Tivoli Storage Manager scheduler service from executing commands or scripts Management of cross-client restores Usage of proxy nodes Benefits of client option sets Remote access restriction We also discuss the authentication methods for Tivoli Storage Manager client, password management, and authority levels that are used by several components in the relationship between the Tivoli Storage Manager client and server.
59
4.1 Client authentication

In order to connect to a Tivoli Storage Manager server, you can require the client to provide a user ID and password. This requirement is controlled in the server configuration and is ON by default. It can be changed using the SET AUTHENTICATION command; however, we recommend keeping authentication enabled for a secure system and all of our examples assume that authentication is enabled. The following sections provide an outline of the main features of client password management and also give recommendations for maintaining a secure environment.
4.1.1 Authentication methods

A native backup/archive client can log on to Tivoli Storage Manager using the clients node name and password or an administrator ID and password. The administrator ID password is managed independently from the password that is generated with the PASSWORDACCESS GENERATE client option. Note: The client must have the option PASSWORDACCESS GENERATE specified in their client options file to enable the use of the Web backup/archive client. When starting a connection using local utilities, such as dsmc or the Java GUI, the backup/archive client prompts the user for a user ID and password. The user ID that is provided by the user is first checked against the node name. If they match, Tivoli Storage Manager attempts to authenticate the session as a node name. If they do not match or the authentication fails, the server attempts to find a registered administrator to compare with the ID provided by the user and authenticates the session with this ID and password. Figure 4-1 shows how the authentication process works for local access.
Client prompts for User and Password
User = Nodename AND Pass = Node's pass
No
User = Registered Admin AND Pass = Admin's pass
Yes
Yes
No
Accept connection
Reject connection
Figure 4-1 Log-in process
60
You can create an administrator ID when you register a node by using the option USERID of the command REGISTER NODE. If you do not specify this option, an administrator with the same name as the node is created by default with client owner authority. The Web client service only allows you to use an administrator ID.
4.1.2 Password processing

There are two methods of accessing passwords. The PASSWORDACCESS option in the client options file (dsm.opt or dsm.sys, depending on the platform) determines which method to use.
PASSWORDACCESS PROMPT
When you set PASSWORDACCESS to PROMPT, the client software requests the user to enter the user ID and password interactively every time the client software is started. This behavior prevents the scheduler service from running activities automatically on behalf of the client. To allow unattended operations through scheduled jobs, the second method is often used, which is called GENERATE mode.
PASSWORDACCESS GENERATE
When using PASSWORDACCESS GENERATE, the user must first establish an initial local connection and provide the password to access the server through dsmc or dsm. After this first access, however, the password is encrypted and stored locally in a file called TSM.PWD on UNIX, Linux, NetWare, and Mac systems and stored in a registry key on Windows systems. When the password expires, a new password is generated automatically, encrypted, and stored again in place of the previous password. Because a single client system can have multiple nodes and can be associated with many Tivoli Storage Manager servers, an affinity is kept on the password file that associates the encrypted password with the node to which it belongs. This affinity is slightly different on Windows where the passwords are kept in the registry rather than in a physical file. For Windows clients, the registry entry shown below is used: SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\<nodename>\<servername> Figure 4-2 shows a screen capture of the registry tree.
Figure 4-2 Password encrypted on Windows Registry
Chapter 4. Securing the client
61
The registry shows that this one physical Windows system uses a node name of ALICE registered on servers ATLANTIC_TSM and KANAGA_TSM and a second node name, BOB, which is registered on server ATLANTIC_TSM only. Each node name has corresponding password entries. If any Tivoli Storage Manager server name changes (by using a SET SERVERNAME command), this invalidates the stored password and you need a client session to update the registry entry. For UNIX and Linux clients, multiple server-node associations are configured with stanzas in the dsm.sys file, as shown in Example 4-1.
Example 4-1 Sample dsm.sys file
Servername stanza1 nodename TCPServeraddress TCPClientaddress passwordaccess passworddir errorlogname schedlogname Servername stanza2 nodename TCPServeraddress TCPClientaddress passwordaccess passworddir errorlogname schedlogname Servername stanza3 nodename TCPServeraddress TCPClientaddress passwordaccess passworddir errorlogname schedlogname
alice atlantic client generate /home/guest /home/guest/log/aliceerror1.log /home/guest/log/alicesched1.log
alice kanaga client generate /home/guest /home/guest/log/aliceerror2.log /home/guest/log/alicesched2.log
bob atlantic client generate /home/guest /home/guest/log/boberror1.log /home/guest/log/bobsched1.log
In Example 4-1, the node ALICE is registered on two servers with host names ATLANTIC and KANAGA, and the node BOB is registered on the server ATLANTIC. The stanza names are stanza1, stanza2, and stanza3. After the first connection with these clients, the passwords for all three nodes are encrypted and saved in the file /home/guest/TSM.PWD. The commands that are used to store the passwords are: dsmc -se=stanza1 dsmc -se=stanza2 dsmc -se=stanza3 Optionally, you can have options files that point to the specific stanza name. For example, an options file for the node bob can be called bob1.opt with the following text content: servername stanza3 To run the client specifying this connection, use the command: dsmc -optfile=bob1.opt 62
For UNIX and Linux systems, changing the Tivoli Storage Manager server name does not affect the password affinity stored in the TSM.PWD file. Instead this relationship is maintained using the stanza name, so the stored password is only affected if you change the stanza name for some reason. For example, if you change the word stanza3 to stanza03 in the dsm.sys file, the content of bob1.opt must be changed also and the password entry stored on TSM.PWD is invalidated. The content of the password file should be similar to Example 4-2.
Example 4-2 Sample encrypted password file
This file contains an encrypted TSM password, do not change or delete. non-printable-charactersSTANZA1ALICE non-printable-charactersSTANZA2ALICE non-printable-charactersSTANZA3BOB non-printable-characters The non-printable characters represent the special markers and the encrypted passwords. You can see a line for each stanza and its associated node name. This means that a change on the stanza name or the node name requires the creation of a new entry in this file. Table 4-1 summarizes the affinity that is stored by the two kinds of systems.
Table 4-1 Password affinity Where the password is stored Windows Registry Password File - TSM.PWD What makes up the affinity Node name + Tivoli Storage Manager server name Stanza name + node name
Permissions on the password file

Because PASSWORDACCESS GENERATE stores the password locally, what happens if the password file is copied to another system? With knowledge of the Tivoli Storage Manager server host name and address, you can create a simple dsm.opt file by guessing the node name (which is easy if, as is often the case, it is the same as the clients host name). You can then access the Tivoli Storage Manager server by impersonating the original node and restore its data. Therefore, if using PASSWORDACCESS GENERATE, the Tivoli Storage Manager administrator must be restrictive regarding the permissions on these password files. For UNIX and Linux systems, we recommend setting the permissions to none for others, none for the group, and read and write permissions for the root user only as shown in this example: -rw------1 root system 118 Jan 29 13:56 TSM.PWD
Expired password
The use of PASSWORDACCESS GENERATE is intended to avoid situations where the scheduler cannot start the client because the node password has expired and a manual intervention is needed to update the password. If using PASSWORDACCESS PROMPT and the password expires, the Tivoli Storage Manager client scheduler fails and generates the message: ANS2050E TSM needs to prompt for the password but cannot prompt process is running in the background. because the
However even when using PASSWORDACCESS GENERATE, incorrect setups can lead to problems with the password synchronization between the server and the client.
63
For example, two separate physical machines have the same Tivoli Storage Manager node name and connect to the same Tivoli Storage Manager server. There is only one node defined on the Tivoli Storage Manager server; however, two separate clients are trying to use the same configuration. This can be caused by an incomplete or incorrect configuration of nodes in a cluster environment, for example, without the CLUSTERNODE YES setting or by an improper configuration when restoring data from one node to another machine. See IBM Tivoli Storage Manager in a Clustered Environment, SG24-6679 for more details about how to configure Tivoli Storage Manager in a clustered environment. You need to avoid this situation. In order to detect if this situation has occurred, look for the message ANR139I Attributes changed for node nodeName: changed attribute list in the activity log. In this situation, if a password expires, only the node that first establishes contact with the Tivoli Storage Manager server triggers the automatic generation of a new password. All subsequent attempts to connect from the duplicate nodes fail, because there is no logical link between their respective copies of the old password and the updated copy generated by the node definition that was used first. After the first node has successfully updated the password, any other nodes receive the message: ANS1262I Password is not updated. Either an invalid current password was supplied or the new password does not fulfill the server password requirements. As we said, you need to avoid this situation because it is a bad configuration practice. However, if you have a valid reason for this situation and if the password expires, you need to reset the password on the server and then manually update the passwords on all affected nodes by using an interactive connection.
The Trusted Communication Agent

On UNIX and Linux systems, a Tivoli Storage Manager utility called dsmtca implements the Trusted Communication Agent (TCA), which serves as an intermediary to allow non-root users to use Tivoli Storage Manager client services without having direct permissions on the password file. This file has the SUID bit set in the permissions, which means that this executable always runs using the authority of its owner, which is the root user by default. Running with root authority, the dsmtca process, which is called as a child process of the application client, is able to open the password file. However, only the root user or a Tivoli Storage Manager authorized user can create or regenerate the password file. The TCA is not used in these situations: The PASSWORDACCESS option is set to PROMPT. The log-in user is root. The log-in user is a Tivoli Storage Manager authorized user, as described in 3.1.1, Types of users on page 34.
Working without Trusted Communication Agent

The information provided here applies to UNIX and Linux clients only. The Trusted Communication Agent (TCA), a child process, normally controls access to the protected password file. It is possible to have the PASSWORDACCESS GENERATE function without starting the TCA and without using root privileges to access the client application. To do this: 1. Set the PASSWORDDIR option in the dsm.sys file to point to a directory where this user has read-write access. For example, under the server stanza in dsm.sys, you enter: passworddir /home/guest
64
2. Set the ERRORLOGNAME and SCHEDLOGNAME options in the dsm.sys file to point to a directory where this user has read-write access. For example, under the server stanza in dsm.sys, you enter: errorlogname schedlogname /home/guest/dsmerror.log /home/guest/dsmsched.log
3. Register the node if you are using closed registration. 4. Change the ownership of the application, for example, the dsmc executable application, to the corresponding user. The owner of the application executable must be the same as the user ID that runs the program, in this example, user guest: chown guest dsmc 5. Set the S bit (set the effective user ID) to On for the application executable. The owner of that application executable can then become a Tivoli Storage Manager authorized user. This permits the user to create a password file, update passwords, and run applications: chmod 4755 dsmc 6. Start the Tivoli Storage Manager client so the password file can be created. Refer to Chapter 3, Client files and services management on page 33 for more details about managing client files and services.
4.1.3 Registering nodes without an administrator ID

If the node is registered with USERID=NONE, the backup/archive client can be authorized using the node name or through a Web client using another valid and suitably authorized Tivoli Storage Manager administrator. The decision about whether to use a separate administrator ID for each client node depends on the need for remote access through the Web client by regular users. From a security perspective, the administrator needs to open only what is necessary. If regular users are allowed to perform backup, archive, restore, and retrieve operations on their own using the Web client, the best approach is to create administrator IDs using their user names or other identification that is linked to the person, not the machine. These administrators are then granted the client owner authority to the nodes that they are allowed to operate. If this access is not required, the Tivoli Storage Manager administrator can prevent this access by not creating this administrator ID and by allowing other Tivoli Storage Manager administrators to perform these operations at the request of the regular users. Figure 4-3 on page 66 illustrates a Tivoli Storage Manager configuration with administrators registered for each user. Administrator IDs have been defined using the users names, Alice and Bob, with client owner authority over nodes WS135 and WS204. However, when Alice logs in to her workstation WS135 with PASSWORDACCESS GENERATE, by default, node name authentication is used, not the administrator ID.
65
WS135
Alice
Nod eA uth (WS entica tion 135 )
TSM Server
Nodes: WS135 WS204
Local Client Access

passwordaccess generate
WS204
n atio ntic the ) e Au Nod (WS204
Admins: Alice Bob
Bob
Figure 4-3 Using node name authentication
For local access, such as using dsmc or dsm (dsmj for UNIX systems), the node starts a session with the server authenticating initially using the node name and password. The administrator ID is not used for this connection unless this authentication fails. By contrast, Figure 4-4 shows Alice accessing the Web client of her workstation (WS135) while seated at another system (WS342) using a standard Web browser. .
WS342
Alice
Web Client Access
tion tica en uth eA n WS135 NodS135) atio (W alid ls V ntia de Cre e) 3 c (Ali
TSM Server
Nodes: WS135 WS204 Admins: Alice Bob
Figure 4-4 Using Web Client and Administrator validation
66
At a simplified level, the following steps occur: 1. Alice points her browser to the Web client URL, such as: http://ws135.company.com:1581 A Java applet is loaded in the system, WS342, where Alice is running the browser. 2. The Web agent, which is running as a service on system WS135, starts a session with the Tivoli Storage Manager server using a generated client password. After the session is successfully established and any function is requested by Alice on the Web interface, a log-in prompt displays on her browser. She must provide the login, ALICE, not the node name. 3. The Web agent validates the administrator ID and password that Alice provided. If this authentication succeeds, the operation that Alice requested is provided. Although the Web client executes this validation of the administrator credentials, all sessions with the server are made using node entity, which means that the Web agent acts as a proxy to the administrator access. Alice can now back up or restore files for her system WS135. In this situation, administrator Alice has client owner authority over node WS135, and administrator Bob has client owner authority over node WS204. The implementation is almost the same as the default behavior, except that the administrators names are not identical to the node name. This type of configuration helps to track user activities and avoid confusion among the users relating to password issues. Because it is unclear that there are two different objects, the lack of synchronization on the passwords of node and administrator can cause misunderstanding.
4.1.4 Password rules

Tivoli Storage Manager provides a number of standard features to help in hardening password and access policies. The Tivoli Storage Manager administrator needs to use these features to align the password policy with global security policies that exist in the enterprise. These Tivoli Storage Manager options include: Minimum password length (MINPWLENGTH): The administrator needs to configure this option on the server administrative interface to a value aligned with the global company policies. The default value is 0 (zero), which means that password length is not checked. You can set this value using the command SET MINPWLENGTH on the server. Password Expiration: This option must be set to assure passwords will be renewed regularly. The company policies must be applied here also. You can set this value individually on a per node basis using the option PASSEXP of the commands REGISTER NODE and UPDATE NODE. If there is no value defined for a particular node, the global value from the server will be used, which is set using the command SET PASSEXP on the server. The value can be anything from 1 to 9999 days, or 0, which indicates that the password never expires. Maximum invalid logon attempts (INVALIDPWLIMIT): This server option locks the client node when a certain number of invalid logon attempts are reached. The administrator must use this setting to prevent brute force guessing of passwords. This value can be set using the command SET INVALIDPWLIMIT on the server - from 0 (do not lock) to 9999 (lock after 9999 unsuccessful logon attempts). Node contact: It is a good practice to fill this field for each client node, including the person responsible for that system and how to contact that person. This way, when tracking a certain activity done on behalf of this node, you already know who to ask first for information. Use the commands REGISTER NODE or UPDATE NODE on the server to set it.
67
4.2 Command action schedules

Defining a client schedule with ACTION=COMMAND allows an administrator to execute any system command or script on the client. This command or script runs under the authority of the scheduler service or daemon, which is usually started under root or system authority, unless the administrator uses the SCHEDCMDUSER option. That means a Tivoli Storage Manager administrator with the privilege to create schedules can run commands on the clients on behalf of root or administrator users. The client option SCHEDCMDDISABLED can be used to prevent the execution of scheduled commands on the client. This option goes in the client options file, dsm.opt: schedcmddisabled yes A Tivoli Storage Manager administrator can choose to include this option locally in all options files from the beginning of the client deployment. Therefore, if this option is required for a particular configuration, it can be enabled on an exception basis.
4.3 Pre and post commands

Although the SCHEDCMDDISABLED option prevents execution of scheduled commands, it still allows execution of pre and post commands in a schedule. These commands are defined using the client options: PRESCHEDULECMD PRENSCHEDULECMD PRESNAPSHOTCMD POSTSCHEDULECMD POSTNSCHEDULECMD POSTSNAPSHOTCMD A client node can prevent an administrator from executing pre-schedule and post-schedule commands through the use of the SRVPREPOSTSCHEDDISABLED option and, similarly, from running pre-snapshot and post-snapshot commands with the option SRVPREPOSTSNAPDISABLED. Both options are available in the client options file. Additionally, if there are blank strings for the PRESCHEDULECMD/PRENSCHEDULECMD and POSTSCHEDULECMD/POSTNSCHEDULECMD options in the schedule definition, this prevents the client from running pre and post commands. The use of blank strings for these options in the client options file makes an administrator unable to run those commands as well, although the same result can be accomplished with option SRVPREPOSTSCHEDDISABLED. Note that if these settings in the schedule definition and the client options file are different, the more restrictive approach (blank strings) prevails. For the maximum protection, include the following statements in all client options files: srvprepostscheddisabled yes srvprepostsnapdisabled yes And for each schedule that is created, the Tivoli Storage Manager administrator needs to include these statements on the options field for each schedule definition: -preschedulecmd= -postschedulecmd=
68
The commands DEFINE SCHEDULE or DEFINE CLIENTACTION are used to create client schedules. This configuration, together with SCHEDCMDDISABLED option, prevents any local system command or script from being executed unattended. Only regular Tivoli Storage Manager client operations, such as backups and restores and archives and retrieves, are allowed, and exceptions can be managed individually as required. The blank string values have priority over any real command definition. From the client perspective, the Tivoli Storage Manager administrators are forbidden to run pre and post commands by the presence of the SRVPREPOSTSCHEDDISABLED and SRVPREPOSTSNAPDISABLED options in the client options files. From the server perspective, the client users, even if they have write access to options files, are forbidden to schedule commands before or after the backup and, in this way, are forbidden from taking advantage of the authority of the backup process to launch commands that they otherwise are forbidden to run. This occurs because every scheduled action carries the PRESCHEDULECMD and POSTSCHEDULECMD option pointing to a blank string.
4.4 Authority of scheduled commands

The option SCHEDCMDUSER allows scheduled commands to run under the authority of regular users instead of using root or administrator authority. It can be only used in the options field of the schedule definition. The example below illustrates the definition of a client action schedule using the SCHEDCMDUSER option: DEF CLIENTACT NODE ACTION=COMMAND OBJECTS="SCRIPTNAME" OPTIONS="-SCHEDCMDUSER=USER" The user that is referenced must exist as an operating system user locally on the client. This option is not valid for Windows clients.
4.5 Scheduled restores and retrieves

Restore and retrieve operations can overwrite critical data if you do not perform them correctly. To prevent a client from performing a scheduled restore and retrieve operation, the Tivoli Storage Manager administrator can disable these operations by including the following statement in the client options file: SCHEDRESTRETRDISABLED YES This still allows other scheduled operations, and the client user can still perform their own restores and retrieves using the backup/archive client.
4.6 Access restriction by user or group

For UNIX and Linux clients, access to client services can be restricted to specific users and groups of the operating system. You restrict this access by using the user and groups clauses in the client options file, for example: users user1 user2 groups group1 group2
69
Several users and groups can be specified on one clause or you can use several clauses on the options file. Refer to Tivoli Storage Manager for UNIX and Linux Backup Archive Clients Installation and Users Guide V5.4, SC32-0145, for more details. If only the root user is specified on the USERS clause, all other users are prevented from using the backup/archive client. Non-authorized users receive the following message from dsmc: ANS1216E Not authorized to run TSM. See the administrator for your system.
4.7 Remote access

Access to a Web backup/archive client requires either client owner authority or client access authority. Administrators with system or policy privileges over the client nodes domain have client owner authority by default. The administrator ID created (unless specifically excluded) at registration has client owner authority by default. To display the administrator IDs and their privileges, use the QUERY ADMIN command. The option REVOKEREMOTEACCESS restricts administrators with client access privileges from connecting to the client using the Web client service. It is included in the client options file: revokeremoteaccess access This option does not restrict administrators with client owner, system, or policy privilege from accessing the workstation through the Web client.
4.8 Cross client restores

Cross client restores mean restoring data backed up by one Tivoli Storage Manager client
node to another. Tivoli Storage Manager provides two methods to accomplish this task: the VIRTUALNODENAME and FROMNODE options. The option that you use depends on whether you own the data. This section presents an overview of the use of both options. Use these mechanisms instead of a commonly used method of copying or changing options files to reflect a new node name. We do not recommend copying or changing options files. This method can introduce a potential exposure because the password for the new node name is stored on the system if PASSWORDACCESS GENERATE is set. To assure valid restored data when making cross-node restores or retrieves, the source and destination need to have the same file system architecture.
4.8.1 Restoring your data to another workstation

When retrieving data that you own to another client node, it is assumed that you are starting the client application on the target system. You then use the option VIRTUALNODENAME to inform Tivoli Storage Manager that you are working on behalf of another client. This means you will be requested to provide authentication regarding the node specified on the VIRTUALNODENAME clause. In this case, the user Alice, who is responsible for and knows the password for NODEA, wants to restore some of her data (which was backed up from NODEA) onto NODEBs file system.
70
She runs the dsmc command from NODEB in order to restore data: dsmc restore -virtualnodename=nodea \\nodea\d$\projx\*.* c:\myfiles\ Figure 4-5 illustrates this situation. NODEA is the source of the data and NODEB is the target.
NODEB
Provides nodea's password
TSM Server
Alice
Restore nodea's data -virtualnode=nodea
Figure 4-5 Restoring data to another workstation
Because Alice specified VIRTUALNODENAME NODEA, she is prompted for NODEAs password, which she knows. She must have received local access to the operating system on NODEB in order to restore her files to that machine. When you use this method to access files, you have access to all files that are backed up and archived from the VIRTUALNODENAME workstation. You are considered a virtual root user. Even if NODEB is using PASSWORDACCESS GENERATE, the source or virtual nodes password is not stored in its password file. Actually, NODEB as an Tivoli Storage Manager entity does not play any role in this scenario. What happens is that: 1. Alice gains access to the physical machine and can log in to the system. 2. Alice, as an accepted user on the target machine, also has privileges to write files to the local file system. 3. She has authority over the data that is backed up from her machine under the NODEA Tivoli Storage Manager node. 4. She can run Tivoli Storage Manager client operations as if she was running it from her own machine. 5. All sessions from this connection are interpreted and logged on Tivoli Storage Manager server as NODEA sessions. Although NODEB is not used in this activity, the configuration options present on the client options file are honored and necessary, such as TCPSERVERADDRESS and others. The default client options file dsm.opt is used unless you specify another file with the OPTFILE command line option: dsmc restore -optfile=myfile.opt -virtualnodename=nodea Consult the client installation guide for your platform to see more details about using this option.
71
4.8.2 Restoring data from another workstation locally

When you want to access data owned by another node and restore this data on your local system, you need to use the option FROMNODE. You authenticate using your own nodes information at your own node, but you need to have permission to access the source node data. This permission is established by the source nodes owner adding your node to its node access list by using the SET ACCESS command when accessing the client through dmsc or through the Web client GUI, menu options Utilities Node Access List. In our example, the client NODEB adds NODEA to its access list: set access backup * nodea You can use file pattern matching to allow access to all (as in our example), or just a subset of the backed up data. Now, on NODEA, Alice can use the FROMNODE option to restore files from the source NODEB to her node. dsmc restore -fromnode=nodeb \\nodeb\d$\projx\* d:\projx\ The FROMNODE option is also allowed for the interactive (loop) mode of dsmc. Figure 4-6 shows an example of the use of FROMNODE.
NODEB
set access backup "*" nodea
TSM Server
NODEA
Alice
-fromnode =nodeb
Figure 4-6 Restoring files from other workstation
Restore nodeb's data to nodea
As in the previous example, Alice does not have NODEBs node password. But in this case, the user responsible for NODEB has explicitly granted access to NODEA for NODEAs backed up objects. Consult the client installation guide for your platform for more details about using this option.
72
4.9 Proxy nodes

Proxy node support allows execution of Tivoli Storage Manager client operations on behalf of
another node. By granting proxy node authority to another node, a relationship is defined where the grantor is called a target node and the grantee node or nodes are called the proxy
(or agent) nodes.
With this relationship in place, the administrator can spread the load of high volume file servers into several agent nodes, which reduces the backup window and shortens restore times in environments, such as IBM GPFS. For example, you can create three agent nodes, NODEA, NODEB, and NODEC, to consolidate the backup of shared data under a target node named NODEZ. The target node can be a logical entity or a real node. This feature is also useful for distributed environments where components of an application are distributed among several physical machines. It is easier to administer the data under a unique logical instance, because you can restore the data, partially or entirely, to another system in the distributed environment. To grant the proxy authority, the Tivoli Storage Manager administrator must issue the command GRANT PROXYNODE in the Tivoli Storage Manager server. For example: grant proxynode target=nodez agent=nodea,nodeb,nodec Agent nodes must supply the options NODENAME and ASNODENAME in their options files. For example, the NODEA options file must include the lines: nodename NODEA asnodename NODEZ When accessing from the client command line in the NODEA system, you see this message immediately before the interactive prompt: Accessing as node: NODEZ The use of proxy nodes implies that any agent node can restore or retrieve any shared data; all the proxy nodes are equivalent peers. For instance, NODEA can restore data backed up by the NODEB agent, because the Tivoli Storage Manager server is not aware of which agent performed the backup operations. All objects are included as NODEZ objects. Figure 4-7 on page 74 shows the configuration.
73
NODEA
NODEB
NODEC
TSM Server
NODEZ: /fs1 /fs2 /fs3
/fs1
/fs2
/fs3
Figure 4-7 Proxy node configuration
The major concern, however, is that the UNIX permissions and ownerships are not considered when determining what an agent node can access or restore. Any agent node can restore data as if it has root authority. Unless you have strict control over who has log-in access to the machines that are involved in the proxy relationship, you need to avoid this configuration on systems that host classified data. Consult the Tivoli Storage Manager client guide for your platform to read about compatibility with proxy node support.
4.10 Manipulating node objects

During its lifetime, a Tivoli Storage Manager client can transition through a number of operational stages: beginning with creation, possible name changes, and eventual possible deactivation. These state modifications have consequences for the Tivoli Storage Manager administrative processes. This section covers aspects that a Tivoli Storage Manager administrator must consider when managing these situations. An important prerequisite is cooperation between the network administration department and the area responsible for Tivoli Storage Manager administration to ensure that there is appropriate communication when, for example, a new server is added to the network, has its name changed, or is removed.
4.10.1 Deactivated nodes

Deactivating a server or workstation means that the services provided by this system are no longer necessary or have been migrated to another system with completely new settings. This does not mean, however, that the Tivoli Storage Manager client data backed up for this system can be immediately discarded. Indeed, retaining the data can be mandatory for compliance reasons in order to recover old data. The node definition must therefore not be removed from the Tivoli Storage Manager server until all its data has become obsolete or is
74
no longer needed. Depending on the policy configuration, one or more versions of objects can be retained indefinitely because active data never expires and even inactive objects can be kept forever if options RETEXTRA or RETONLY are set to NOLIMIT. Therefore, the process of removal must be manual. And you must ask the person, who is accountable for the previous services that this node provided, when and if this data can be considered obsolete. Because the node does not exist anymore, it does not access the Tivoli Storage Manager server unless a restore or retrieve operation is necessary. Therefore, the node needs to be locked on the Tivoli Storage Manager server with the LOCK NODE command to prevent any unauthorized or even accidental use of this node name. The contact field of the node object can be updated to include information about the services that this node used to provide, the deactivation date, and the date that the remaining data can be discarded from the storage pools. After confirming that all data related to an inactive node can be safely discarded, the file spaces belonging to the node can be deleted, as well as the node definition itself, from Tivoli Storage Manager. You use these commands for an inactive node, for example, NODEA: delete filespace NODEA * remove node NODEA This removes all references to NODEAs data, including data in copy storage pools. Note that you cannot delete a node that still has backed up or archived data in Tivoli Storage Manager storage pools. An alternative to keeping the backup data in its original management classes and storage pools is to perform a onetime archive of the nodes important data by specifying an appropriate retention period. If you perform this type of archive, the data simply expires automatically from Tivoli Storage Manager after the determined retention period. You can then delete the node. Alternatively on decommissioning the node, you can create a backup set. You can copy this backup set to external media, for example, CD, and then you can delete the node immediately.
4.10.2 Renaming nodes

The node name does not have to be the same as the host name, although this practice is commonly followed for simplicity. Therefore, if you do change the host name, you are not necessarily required to reflect this change on the Tivoli Storage Manager node. If you need to change the node name for any reason, use the command RENAME NODE on the Tivoli Storage Manager server: rename node NODEA MYNODE All references to backed up or archived objects are preserved. Also, any administrator, who had client owner authority to the former node name, has the administrator reference updated to the new node name. Note that the administrator name does not change. For example, if the node NODEA was registered using the default options, an administrator ID named NODEA was created at the same time. When renaming the node to MYNODE, the administrator name is not changed; however, administrator ID NODEA automatically gets client owner privileges to MYNODE. Although they have been created through the same command, REGISTER NODE, they are separate entities.
75
4.11 Controlling client options from the server

Using the local client options files, the clients can customize their backup, archive, and space management operations. This provides more flexibility but can have consequences if users change the options to back up unwanted data or not back up critical data. Similarly, in many configurations, you do not want users to be able to set backup/archive processing options. For this reason, client option sets, which allow many options to be enforced centrally by the Tivoli Storage Manager administrator, are provided. A client option set is a group of defined options that are individually set to provide values to client options. You can configure these options to overwrite any definition that is set in the client options files by using the FORCE=YES parameter. In particular, include and exclude options, if specified in a client option set, always override anything that is set in the client options file. Include and exclude options are logically appended to the bottom of the clients include and exclude list and therefore are evaluated first. The administrator can define one or more client option sets and then assign each node to the appropriate set. A common method is to define a client option set for each operating system platform. For example, you can prevent files with certain extensions from being backed up for some clients by including an exclude option in a client option set and assigning those clients to this client option set. The following commands, which are issued on the administrative command line, create this client option set, add an option to exclude .avi file types, and assign NODEA to the client option set: define cloptset engbackup description=Backup options for eng. dept. define clientopt engbackup inclexcl "exclude *:\...\*.avi" update node nodea cloptset=engbackup A more restrictive approach is to completely prevent any include or exclude option that might exist on client options files. You can easily do this using the following statements. Note the use of sequence numbers in the option definition: define define define update cloptset engbackup description=Backup options for eng. dept. clientopt engbackup inclexcl "exclude *:\...\*" seq=10 clientopt engbackup inclexcl "include *:\...\*.odt" seq=20 node nodea cloptset=engbackup
In this example, the only files that are allowed for NODEA backups are files with extension .odt. All include and exclude options in client options files are ignored. Because the two entries in the previous statements are evaluated first, if the include option does not match the object, the second statement certainly does. Remember that include and exclude statements are evaluated from the bottom up and pattern matching stops when a match is found. Figure 4-8 on page 77 shows how the include and exclude list is configured for NODEA.
76
Evaluation
dsm.opt/dsm.sys ------------------------include e:\...\*.avi include e:\...\*.mpg include e:\...\*.avi
NODEA
TSM Server
Client Option Set ------------------------exclude *:\...\* include *:\...\*.odt
Figure 4-8 Preventing include option from client
Because the client option set that is pushed from the server to the client contains an exclude everything clause, the include and exclude list created on the client configuration is never used. This configuration changes the behavior of processing to a so-called white list approach in which everything is forbidden, except what is explicitly allowed. In addition, the user has no control over the final results.
4.12 Other considerations

This chapter covered the main features available on Tivoli Storage Manager client to prevent certain actions from being executed in the client system and provided a detailed explanation of client/server authentication. One essential factor in increasing the level of protection on any system is to understand what is happening on your system, why you have these resources running, and how they work. Other areas of securing a system were not covered here either because they are outside the scope of this book or because they are covered in other chapters. These areas are no less important in the overall process of hardening a system. Here is a brief summary.
4.12.1 Physical security

This is the most essential concern. You need to categorize your servers according to the impact in case of their loss or an intrusion. Servers with critical data need to be kept in restricted areas where only the required staff has access.
4.12.2 Operating system and network security

A wide range of tools and processes are available to improve protection at the operating system and network levels. The tools and processes depend on the platform used and they usually involve more than one group of administrators because they require skills on the
77
operating systems, network protocols, social engineering, and security threats, among others. We provide a brief summary of these factors in Chapter 10, Protecting the server on page 265.
4.12.3 Encryption
Encryption is an important resource to protect your sensitive data. You have several options available to implement encryption, such as client side encryption, tape drive encryption, and specialized appliances. Each option has its own advantages and disadvantages and specific implementation details. See Part 2, Encryption on page 79 for more details.
78
Part 2
Part
Encryption
This part describes two methods for encrypting data within Tivoli Storage Manager: client encryption and TS1120 tape hardware encryption.
79
80
Chapter 5.
Tivoli Storage Manager client data encryption

This chapter discusses Tivoli Storage Managers client encryption functions for both the backup/archive client and the API. Topics include: What is encrypted Key management for the backup/archive clients and the API How to enable client encryption Client performance when using encryption Upgrade considerations and potential challenges Encryption with other client types
81
5.1 Client encryption primer

When discussing client encryption, there are two elements to consider: the methodology that the client node uses to authenticate with and log in to the Tivoli Storage Manager server and data encryption where the actual client data files are encrypted before they are sent to the Tivoli Storage Manager server. Session authentication and encryption refers to the method by which the client logs in to the Tivoli Storage Manager server. We describe this exchange in detail in Chapter 2, Client sessions on page 23. Tivoli Storage Manager has always provided session encryption for authentication of the backup/archive and the administrative client node sessions that attach to the server. It is important to note that the password is never sent between the client and server during this log-in and authentication process; instead, the password is used locally on each end to validate the data exchange. Tivoli Storage Manager client data encryption is the ability to encrypt the actual data file payload for a backup, archive, restore, or retrieve session. This encryption occurs only on the client; the server has no part in the data encryption process. For the backup/archive client, neither the encryption key nor the encryption key password is ever sent to the Tivoli Storage Manager server. For the API client, transparent encryption is now available. When you use this option, the encryption key is sent to the Tivoli Storage Manager server (the encryption key is itself encrypted) and is stored on the Tivoli Storage Manager server. Prior to V5.3, the only available encryption option was the Data Encryption Standard called DES56. The Tivoli Storage Manager client V5.3 introduced the Advanced Encryption Standard named AES128 for most clients.
5.1.1 Encryption of session traffic

Authentication traffic between the client and server is encrypted during session setup by default for backup/archive and API client nodes and it cannot be disabled. This traffic does not include passwords, which are not passed between the client and the server. For administrative clients, commands sent to the server are encrypted, but the output that is returned to the administrative client from those commands is not encrypted. So, if you use the administrative client to change a password for an administrator or client node, the password change data that is sent to the server is encrypted, but the information that the password was changed is returned unencrypted to the administrative client. Note, the unencrypted return message does not include the actual password. The information shown in Example 5-1 and Example 5-2 on page 83 is a portion of a network trace that is monitoring a Windows administrative client at the IP address 192.168.204.128 connecting to a Linux Tivoli Storage Manager server at the IP address 192.168.99.231. The administrative client issues a password change for a node.
Example 5-1 Encrypted command sent to server
No.
Time Source Destination 1 0.000000 192.168.204.128 192.168.99.231 1500 [PSH, ACK] Seq=1303180445 Ack=399704979 Win=64324 Len=4
Protocol Info TCP 1267 >
Frame 1 (58 bytes on wire, 58 bytes captured) Ethernet II, Src: Vmware_39:f3:56 (00:0c:29:39:f3:56), Dst: Vmware_e2:04:c2 (00:50:56:e2:04:c2) 82
Destination: Vmware_e2:04:c2 (00:50:56:e2:04:c2) Source: Vmware_39:f3:56 (00:0c:29:39:f3:56) Type: IP (0x0800) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Transmission Control Protocol, Src Port: 1267 (1267), Dst Port: 1500 (1500), Seq: 1303180445, Ack: 399704979, Len: 4 Source port: 1267 (1267) Destination port: 1500 (1500) Sequence number: 1303180445 Next sequence number: 1303180449 Acknowledgement number: 399704979 Header length: 20 bytes Flags: 0x0018 (PSH, ACK) Window size: 64324 Checksum: 0x81a2 [correct] Data (4 bytes) 0000 00 04 18 a5 ....
The command sent to the server is encrypted, but the response from the server to the administrative client is not.
Example 5-2 Unencrypted server response
Frame 6 (97 bytes on wire, 97 bytes captured) Ethernet II, Src: Vmware_e2:04:c2 (00:50:56:e2:04:c2), Dst: Vmware_39:f3:56 (00:0c:29:39:f3:56) Destination: Vmware_39:f3:56 (00:0c:29:39:f3:56) Source: Vmware_e2:04:c2 (00:50:56:e2:04:c2) Type: IP (0x0800) Internet Protocol, Src: 192.168.99.231 (192.168.99.231), Dst: 192.168.204.128 (192.168.204.128) Transmission Control Protocol, Src Port: 1500 (1500), Dst Port: 1267 (1267), Seq: 399704983, Ack: 1303180482, Len: 43 Source port: 1500 (1500) Destination port: 1267 (1267) Sequence number: 399704983 Next sequence number: 399705026 Acknowledgement number: 1303180482 Header length: 20 bytes Flags: 0x0018 (PSH, ACK) Window size: 64240 Checksum: 0x9383 [correct] Data (43 bytes) 0000 0010 0020 00 2b f1 a5 01 00 1d 41 4e 52 32 30 36 33 49 20 4e 6f 64 65 20 4e 45 4e 59 41 20 75 70 64 61 74 65 64 2e 7e ff 00 00 00 00 00 00 .+.....ANR2063I Node NENYA updat ed.~.......
5.1.2 Encryption of data traffic

Data traffic for a file backup/archive session is unencrypted by default, but encryption can be enabled easily. In this section, we show portions of network traces for both unencrypted and encrypted sessions.
Chapter 5. Tivoli Storage Manager client data encryption
83
Backup session without data encryption

This section shows portions of a network trace performed on a standard unencrypted backup session between a Windows XP client and a Linux Tivoli Storage Manager server. The server has the IP address 192.168.99.231; the client has the IP address 192.168.204.128. Example 5-3 shows the client logging in to the server; the login and password are encrypted.
Example 5-3 Network trace of encrypted backup session login
Frame 4 (58 bytes on wire, 58 bytes captured) Ethernet II, Src: Vmware_39:f3:56 (00:0c:29:39:f3:56), Dst: Vmware_e2:04:c2 (00:50:56:e2:04:c2) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Transmission Control Protocol, Src Port: 1363 (1363), Dst Port: 1500 (1500), Seq: 3066147214, Ack: 3405165318, Len: 4 Source port: 1363 (1363) Destination port: 1500 (1500) Sequence number: 3066147214 Next sequence number: 3066147218 Acknowledgement number: 3405165318 Header length: 20 bytes Flags: 0x0018 (PSH, ACK) Window size: 64512 Checksum: 0xf2e8 [correct] Data (4 bytes) 0000 00 04 1d a5 ....
Next, certain basic information is exchanged between the client and the server. This includes server platform, client platform, and versions (Example 5-4). In the interest of brevity, only the data (payload) of the packets in which we are interested are shown (Example 5-4).
Example 5-4 Network trace of unencrypted backup session setup
Frame 6 (116 bytes on wire, 116 bytes captured) Internet Protocol, Src: 192.168.99.231 (192.168.99.231), Dst: 192.168.204.128 (192.168.204.128) Data (62 bytes) 0000 0010 0020 0030 00 07 6e 56 3e 00 f6 45 1e 07 00 52 a5 00 00 31 66 0a 00 4c 15 00 00 69 07 05 00 6e d7 00 00 75 02 04 00 78 02 00 00 2f 0b 00 00 69 0f 00 00 33 39 00 02 38 00 00 00 f7 7b bf 53 45 52 36 .>..f.......9... ..............{. n............SER VER1Linux/i386
Frame 7 (205 bytes on wire, 205 bytes captured) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Data (151 bytes) 0000 0010 0020 00 42 1a a5 66 00 00 00 05 04 02 00 05 00 09 00 0e 00 00 00 00 0e 00 0a 00 00 dc f7 fa 88 00 00 00 00 00 00 00 00 00 00 00 00 57 69 6e 4e 54 56 .B..f........... ................ ..........WinNTV
84
0030 0040 0050 0060 0070 0080 0090
45 78 00 04 45 32 e3
4e 74 00 00 4e 30 00
59 00 00 09 59 34 0c
41 55 00 00 41 2e 29
2d 2a 00 0d 2d 31 cd
57 a5 04 00 57 32 c0
49 00 01 0f 49 38 a4
4e 01 00 00 4e 07
64 00 00 1c 31 72
73 29 00 00 39 33
63 00 00 10 32 e0
65 05 00 35 2e 87
6e 00 00 2e 31 3d
75 03 00 30 36 11
2e 00 00 31 38 d9
74 04 00 56 2e b2
ENYA-WINdscenu.t xt.U*....)...... ................ ...........5.01V ENYA-WIN192.168. 204.128.r3..=... ...)...
After several more session setup packets, data is sent from the client to the server (portions of the trace have been omitted for brevity. See Example 5-5.
Example 5-5 Unencrypted client data sent to the server
Frame 59 (1303 bytes on wire, 1303 bytes captured) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Data (1249 bytes) 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 0280 0290 02a0 02b0 02c0 02d0 02e0 02f0 0300 0310 0470 0480 0490 04a0 04b0 04c0 04d0 04e0 00 00 00 41 52 01 fe 41 16 00 00 00 00 41 52 01 ff 2e 44 16 80 00 65 64 43 65 31 00 00 00 00 2d 44 ff 42 4e 00 00 00 00 00 2d 44 ff fe 54 41 1b 00 02 72 20 72 72 2d 01 00 00 57 5c fe 41 44 91 0e 01 00 00 57 5c fe 11 58 52 01 00 00 73 69 65 20 32 00 00 00 49 5c 11 54 41 16 00 00 00 00 49 5c 11 ff 54 44 00 00 00 65 73 64 30 33 00 00 00 4e 76 ff 43 52 1b 07 00 00 00 4e 76 ff ff 01 44 00 00 00 63 20 69 31 34 00 00 00 57 65 ff 48 44 01 cf 00 00 00 57 65 ff ff ff 45 00 00 00 72 41 74 32 35 00 00 00 69 6e ff 01 53 00 16 00 00 00 69 6e ff fe fe 46 00 00 00 65 42 20 33 2d 00 00 00 6e 79 fe ff 54 00 d1 00 00 00 6e 79 fe 50 11 41 00 00 00 74 43 43 2d 36 00 00 00 4e 61 5c fe 41 00 5d 00 00 00 4e 61 5c 41 ff 55 00 00 00 20 31 61 34 37 00 00 00 54 2d 01 11 4e 00 00 00 00 00 54 2d 42 53 ff 4c 00 00 51 70 32 72 35 38 00 00 00 53 77 ff ff 44 00 00 00 00 00 53 77 41 53 ff 54 51 00 4d 61 33 64 36 39 00 00 00 54 69 fe ff 41 00 00 00 00 00 54 69 54 57 fe 07 02 00 79 73 34 20 37 00 00 00 56 41 6e 11 ff 52 00 30 00 00 56 41 6e 43 4f 53 09 49 00 20 73 0d 4e 2d 06 00 00 45 4e 5c ff fe 44 00 00 00 00 45 4e 5c 48 52 54 16 00 00 73 77 0a 75 38 13 00 00 4e 44 63 ff 53 07 02 00 01 00 4e 44 63 5c 44 41 00 00 00 75 6f 0d 6d 39 a5 fc 00 59 41 24 ff 54 09 4a 00 09 00 59 41 24 01 53 4e 91 0e 00 70 72 0a 62 30 01 ................ ................ ............VENY A-WINWinNTSTANDA RD\\venya-win\c$ ........\....... .BATCH........ST ANDARDSTANDARD.. ...............J ........]...0... ................ ................ ............VENY A-WINWinNTSTANDA RD\\venya-win\c$ ........\BATCH\. .......PASSWORDS .TXT........STAN DARDDEFAULT..... ..........Q.I... ................ .........QMy sup ersecret passwor d is ABC1234.... Credit Card Numb er 0123-4567-890 1-2345-6789..... .
Backup session with AES128 data encryption

Next, we enabled AES encryption and ran the same backup again using the same client and server. The client login to the server remains the same. Session setup packets, which includes basic server information, basic node information, and management class data, remains unencrypted (Example 5-6 on page 86).
85
Example 5-6 Session setup using AES encryption
Frame 8 (116 bytes on wire, 116 bytes captured) Internet Protocol, Src: 192.168.99.231 (192.168.99.231), Dst: 192.168.204.128 (192.168.204.128) Data (62 bytes) 0000 0010 0020 0030 00 07 6e 56 3e 00 f6 45 1e 07 00 52 a5 00 00 31 66 0a 00 4c 15 00 00 69 07 05 00 6e d7 00 00 75 02 04 00 78 02 00 00 2f 0b 00 00 69 38 00 00 33 23 00 02 38 00 00 00 f7 7b bf 53 45 52 36 .>..f......8#... ..............{. n............SER VER1Linux/i386
Frame 9 (205 bytes on wire, 205 bytes captured) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Data (151 bytes) 0000 0010 0020 0030 0040 0050 0060 0070 0080 0090 00 0e 00 45 78 00 04 45 32 e3 42 00 00 4e 74 00 00 4e 30 00 1a 00 00 59 00 00 09 59 34 0c a5 00 00 41 55 00 00 41 2e 29 66 00 00 2d 2a 00 0d 2d 31 cd 00 0e 00 57 a5 04 00 57 32 c0 00 00 00 49 00 01 0f 49 38 a4 00 0a 00 4e 01 00 00 4e 07 05 00 00 64 00 00 1c 31 72 04 00 00 73 29 00 00 39 33 02 dc 57 63 00 00 10 32 e0 00 f7 69 65 05 00 35 2e 87 05 fa 6e 6e 00 00 2e 31 3d 00 88 4e 75 03 00 30 36 11 09 00 54 2e 00 00 31 38 d9 00 00 56 74 04 00 56 2e b2 .B..f........... ................ ..........WinNTV ENYA-WINdscenu.t xt.U*....)...... ................ ...........5.01V ENYA-WIN192.168. 204.128.r3..=... ...)...
After session authentication and setup, the client again begins sending data to the server, as in Example 5-7. Compared with Example 5-5 on page 85, the data is now encrypted and cannot be interpreted.
Example 5-7 Client data transferred using AES encryption
Frame 61 (1315 bytes on wire, 1315 bytes captured) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Data (1261 bytes) 0060 0070 0080 0090 00a0 00b0 00c0 00d0 0280 0290 02a0 02b0 02c0 02d0 02e0 02f0 00 00 41 52 01 fe 41 16 00 00 00 41 52 01 ff 2e 00 00 2d 44 ff 42 4e 00 00 00 00 2d 44 ff fe 54 00 00 57 5c fe 41 44 91 01 00 00 57 5c fe 11 58 00 00 49 5c 11 54 41 16 00 00 00 49 5c 11 ff 54 00 00 4e 76 ff 43 52 1b 00 00 00 4e 76 ff ff 01 00 00 57 65 ff 48 44 01 00 00 00 57 65 ff ff ff 00 00 69 6e ff 01 53 00 00 00 00 69 6e ff fe fe 00 00 6e 79 fe ff 54 00 00 00 00 6e 79 fe 50 11 00 00 4e 61 5c fe 41 00 00 00 00 4e 61 5c 41 ff 00 00 54 2d 01 11 4e 00 00 00 00 54 2d 42 53 ff 00 00 53 77 ff ff 44 00 00 00 00 53 77 41 53 ff 00 00 54 69 fe ff 41 00 00 00 00 54 69 54 57 fe 00 56 41 6e 11 ff 52 00 00 00 56 41 6e 43 4f 53 00 45 4e 5c ff fe 44 00 00 00 45 4e 5c 48 52 54 00 4e 44 63 ff 53 07 02 01 00 4e 44 63 5c 44 41 00 59 41 24 ff 54 09 4a 09 00 59 41 24 01 53 4e ................ ............VENY A-WINWinNTSTANDA RD\\venya-win\c$ ........\....... .BATCH........ST ANDARDSTANDARD.. ...............J ................ ................ ............VENY A-WINWinNTSTANDA RD\\venya-win\c$ ........\BATCH\. .......PASSWORDS .TXT........STAN
86
0300 0310 03c0 03d0 03e0 03f0 0400 0410 0420 0430 0440 0450 0460 0470 0480 0490 04a0 04b0 04c0 04d0 04e0
44 16 59 21 51 fe c5 63 cf f0 b4 2c 47 88 6d 99 20 50 dd 91 72
41 1b 20 44 5f 63 79 15 9a 88 78 27 12 23 79 69 b1 39 ef 5e 28
52 01 19 f3 c9 07 3f 41 b6 9e 5e 9d b2 4b d6 0e 74 ca af 28 47
44 00 e3 0c c7 66 76 4b 45 de a7 4f 71 74 e4 42 1b 5b d8 00 7a
44 00 2e 6a 03 a5 34 64 d5 b9 6b f0 d5 47 32 6d 39 28 db 14 4d
45 00 a2 0c 3e c1 01 af 36 88 f3 36 8b b0 4f 03 09 98 98 07 1e
46 00 1a 66 6b 2f d2 b3 dc a4 ca 89 b1 fe c7 e6 fd da e7 a5 89
41 00 12 3d 5a 72 cd 3e c9 2a cd 7d b3 d3 0d ab 6d 22 82 4f 00
55 00 86 e5 be aa 10 f1 03 1a 88 14 64 c3 db 2a 9d 12 4e 88 06
4c 00 87 a1 0a ed 3b 25 27 6a 9d 06 5c 53 52 da d0 24 f0 83 13
54 51 e4 0a 0e e4 b2 67 72 25 c1 b4 ae 4e 93 26 67 f0 cc d9 a5
07 02 d8 14 37 32 9b dc 6e 4a 47 5c 05 01 c9 6e 97 11 b7 00 01
09 49 82 c5 1d 51 da 9a 83 02 cf c3 30 ff 0e 6c 36 f4 c5 47 00
16 80 c1 d9 6e 47 6f 6e 4e b2 3d d4 22 bd 7f 85 00 9b df c1
00 02 95 a5 6e dc f5 c6 e6 a8 1b 0b f3 c0 68 43 70 d9 22 29
91 0e 5e b5 de 6d 0a 00 96 ff a5 3c de a2 65 ee 6f 7e 91 cf
DARDDEFAULT..... ..........Q.I... Y .............^ !D..j.f=........ Q_...>kZ...7.nn. .c.f../r...2QG.m .y?v4....;...o.. c.AKd..>.%g..n.. ...E.6...'rn.N.. .......*.j%J.... .x^.k......G.=.. ,'.O.6.}...\...< G..q....d\..0".. .#KtG....SN..... my..2O...R....he .i.Bm...*.&nl.C. .t.9..m..g.6.po P9.[(..".$.....~ ........N.....". .^(....O....G.). r(GzM........
Note: The node name, file space, directory structure, and file name are not encrypted, only the contents of the file.
5.2 Platforms that can use client data encryption

For V5.2 file backup/archive clients, the strongest available encryption level was DES56. With the release of the V5.3.0 backup/archive clients, AES128 encryption was added for all clients except for NetWare, z/OS, and OS/400. AES128 is now the default encryption type; however, DES56 can be selected using the ENCRYPTIONTYPE parameter in the client options file. As of client V5.4.0, the strongest available encryption for NetWare, z/OS, and OS/400 is DES56. API encryption was added with the release of V5.3. API encryption supports both DES56 and AES128 for supported clients.
5.2.1 Advantages of client side data encryption

The primary advantage of client-side encryption is that the data that is sent to the Tivoli Storage Manager server is encrypted, and therefore protected from packet sniffers, before it leaves the client host. This is an advantage for sensitive data where you suspect that the traffic might be captured during transmission to or from the Tivoli Storage Manager server. See 5.1, Client encryption primer on page 82. Client side encryption is of particular importance where the client data might traverse insecure networks on the way to the server. The encrypted data is then stored in the storage pools and is protected from unauthorized access there as well.
87
5.2.2 Considerations for client side data encryption

When using client side encryption with the Tivoli Storage Manager client, the performance impact due to the encryption process might need to be a consideration. Although as we discuss in 5.6, Performance observations of the backup/archive client on page 105, this overhead is typically very small. A more important consideration is the issue of key management. With any form of encryption, there is a key that needs to be presented in order to gain access to the encrypted data. At the time of writing this book, backup/archive keys are managed manually according to the ENCRYPTKEY setting in the client options file. If ENCRYPTKEY SAVE is used, the password is saved locally on the client and supplied automatically when required. If ENCRYPTKEY PROMPT is used, the key password is not saved but must be entered each time by the user. This means that a copy of the key password needs to be stored separately from the client in order to make sure that the data can be encrypted in case the client copy or record of the key is destroyed. Note: If you forget the encryption key password and no longer have the TSM.PWD file for UNIX, Linux, NetWare, or Mac or the encrypted password in the registry for Windows, the data encrypted with that key cannot be restored or retrieved. Refer to 5.3, Backup/archive client encryption key management on page 88 for more on this topic. For the API client, an option for transparent key management is available as of V5.4.0. This option stores the key in the Tivoli Storage Manager database along with the stored object and eliminates the issue of key management altogether.
5.2.3 Using data encryption with client compression

If client compression is used along with client encryption, the client data is compressed before encryption is performed because encrypted data does not compress. During backups or archives, encryption is the last client processing step to occur before the data is sent to the Tivoli Storage Manager server. During restores or retrieves, encryption will be the first client processing step performed when the data arrives at the client from the Tivoli Storage Manager server.
5.3 Backup/archive client encryption key management

This section discusses key management for backup archive clients for both the session keys and the data encryption keys when using client data encryption.
5.3.1 Session keys

When a previously registered backup/archive client attempts to log in to the Tivoli Storage Manager server, the client either prompts the user for a password, or if PASSWORDACCESS GENERATE is in the client options file and the password has been previously saved, the client retrieves the password locally. When using PASSWORDACCESS GENERATE: For the Windows client, the password is saved in the registry: 88
For V5.3 clients, the encrypted key password is under: [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\No des\NODENAME\SERVERNAME] For V5.4 clients, the encrypted key password is under: [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\NODENA ME\SERVERNAME] For UNIX and Linux clients, the password is stored in a file called TSM.PWD, which is located in the /etc/adsm directory (/etc/security/adsm on AIX) unless the password is otherwise set with the PASSWORDDIR option in the client system options file. For NetWare clients, the password is stored in a file called TSM.PWD, which located in the directory where the Tivoli Storage Manager client was installed by default, otherwise the password is stored in a location specified by the PASSWORDDIR option in the client options file. For Macintosh clients, the password is also stored in a file called TSM.PWD, which is located in /Library/Preferences/Tivoli Storage Manager, unless the password is otherwise indicated by the PASSWORDDIR option in the client options file. Note that this is the same location that is used to save the data encryption key password as described in the following section. More information about session authentication between the client and the server is covered in Chapter 2, Client sessions on page 23.
5.3.2 Data encryption keys

A shared key must be used before encryption or decryption can occur because both DES and AES are symmetric key algorithms. Unlike what you might expect with backup/archive client encryption, the Tivoli Storage Manager client never transfers the shared key to the Tivoli Storage Manager server. The key is only used on the Tivoli Storage Manager client. Accordingly, the Tivoli Storage Manager server plays no part in the encryption or decryption process; the server simply receives what the client sends to it. When data encryption is first used on the client, the user supplies a password (case sensitive) which is used to create the key. Note: This is an important concept: The password is not the key but is used to create the key. The key generated from the password is stored on an internal key ring cache, which remains as long as the client is running. When the client session exits, the cache is destroyed. When the client session starts, the key ring cache is empty. Accordingly, when a file needs to be encrypted or decrypted, the client is unable to locate the key on the internal cache and either: Prompts the user for the key password if the ENCRYPTKEY PROMPT option is used Retrieves the encryption key password locally if you are using the ENCRYPTKEY SAVE option: For the Windows client, the encrypted key password is saved in the registry. For V5.3 clients, the registry key password is under:
89
[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\No des\NODENAME\SERVERNAME] For V5.4 clients, the registry key password is under: [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\NODENA ME\SERVERNAME] For UNIX and Linux clients, the key password is stored in a file called TSM.PWD, which is located in the /etc/adsm directory (/etc/security/adsm on AIX), unless the password is otherwise set with the PASSWORDDIR option in the client system options file. For Netware, the key password is stored in a file called TSM.PWD, which is located in the directory where the Tivoli Storage Manager client was installed by default, otherwise the password is stored in the location specified by the PASSWORDDIR option in the client options file. For Macintosh clients, the key password is also stored in a file called TSM.PWD, which is located in /Library/Preferences/Tivoli Storage Manager, unless the password is otherwise indicated by the PASSWORDDIR option in the client options file.
Methods for managing client keys

At the time of writing this book, there is no transparent key management function for the backup/archive client data encryption, such as the function that is used for API data encryption. Accordingly, you should consider how you can access the encrypted data stored on the Tivoli Storage Manager server if the client node no longer had its copy of the stored key. The options are: Manually store and track the passwords used to generate the key, which is done externally to the affected Tivoli Storage Manager clients and replicated in two or more locations. If the encrypted data needs to be recovered from the Tivoli Storage Manager server and the saved key is not available, the user or administrator is prompted for this password before the data can be restored. Remember that if the clients copy of the key is destroyed, these passwords are the only method of retrieving the encrypted data on the Tivoli Storage Manager server. Save copies somewhere else of the TSM.PWD file (non-Windows) or exported registry key password (Windows) from the nodes and save them in multiple locations. The benefit of this is that an unauthorized intruder is not able to decrypt the data without the key. This also means that any external copies of the keys must be appropriately secured against inappropriate access.
Considerations for encryption with long-term data retention

Unlike the client session password, which might change periodically based upon the PASSEXP server parameter, client encryption key passwords do not expire. Accordingly, data is still retrievable up to the expiration parameters that are set in the copy groups on the server, provided that the encryption key password is: Still retained in the registry (Windows) Still retained in the TSM.PWD file (non-Windows platforms) Provided by the user at restore and retrieve time
90
5.4 Data encryption using the backup/archive client

This section describes enabling and using the client data encryption feature for the backup/archive clients.
5.4.1 Enabling encryption

Enabling encryption for backup/archive clients is quite easy. It is in fact enabled by default, you only have to select the data that you want to encrypt in INCLUDE.ENCRYPT statements. Two client system option parameters affect the behavior of client encryption: ENCRYPTIONTYPE and ENCRYPTKEY.
ENCRYPTIONTYPE
This parameter specifies the type of encryption that you want: either DES56 or AES128. The default (and recommended type) is AES128.
ENCRYPTKEY
This parameter specifies whether the encryption key password is saved locally on the client (ENCRYPTKEY SAVE), or if you will be prompted for the key password (ENCRYPTKEY PROMPT) for backup, archive, restore, and retrieve operations. ENCRYPTKEY SAVE is the default.
5.4.2 Include and exclude statements

Even after setting the ENCRYPTKEY and ENCRYPTIONTYPE options, you still must explicitly tell the client with an INCLUDE.ENCRYPT statement to encrypt the data. Note: The default for the backup/archive client is to not encrypt the data. There is also an EXCLUDE.ENCRYPT statement. Use INCLUDE.ENCRYPT and EXCLUDE.ENCRYPT to fine-tune the selection of the data that you want to encrypt. The file pattern that is used with INCLUDE.ENCRYPT and EXCLUDE.ENCRYPT is the same as with regular INCLUDE and EXCLUDE statements. These statements are processed from the bottom to the top.
5.4.3 PASSWORDACCESS and ENCRYPTKEY interaction

The settings for the PASSWORDACCESS and ENCRYPTKEY options determine how the client behaves during different operations. This information is in the individual Tivoli Storage Manager client manuals, but a short summary that shows the behavior observed during our testing is shown in Table 5-1 and Table 5-2.
Table 5-1 Authorized user backup behavior with PASSWORDACCESS and ENCRYPTKEY options Operation Authorized user backup PASSWORDACCESS Prompt ENCRYPTKEY Prompt Result Prompts for both session password and encryption key password
91
Operation
PASSWORDACCESS Prompt Generate
ENCRYPTKEY Save Prompt
Result Prompts for session password Prompted for encryption key password for files Not prompted. Uses the stored passwords
Generate
Save
Table 5-2 Authorized user restore behavior with PASSWORDACCESS and ENCRYPTKEY options Operation Authorized user restore PASSWORDACCESS Prompt ENCRYPTKEY Prompt Result Prompted for both session password and encryption key password Prompted for session password only Prompted for encryption key password Not prompted. Uses the stored passwords
Prompt Generate
Save Prompt
Generate
Save
In most cases, PASSWORDACCESS and ENCRYPTKEY are set to either GENERATE and SAVE or PROMPT and PROMPT. As indicated in Table 5-1 and Table 5-2, if PASSWORDACCESS=GENERATE and ENCRYPTKEY=SAVE, the encrypted session password and encryption key password are saved locally in the TSM.PWD file (UNIX and Linux) or registry (Windows). Refer to 5.3, Backup/archive client encryption key management on page 88 for more information about where the passwords are stored. If PASSWORDACCESS=PROMPT and ENCRYPTKEY=PROMPT, the user is prompted for both the session password and the encryption key password for any encrypted files. With few exceptions, these are the preferred methods. For more information about authorized and non-authorized client users, refer to 3.1, Access controls on page 34.
5.4.4 Backup/archive client session examples

In this section, we show examples of backup/archive client behavior when encryption is enabled and the prompts that a user can expect to encounter.
Windows backup/archive client GUI

This section shows the behavior of the GUI when using encryption under different scenarios. For this example, we are using a Windows XP host running client V5.4.0. The server is a Linux host running Tivoli Storage Manager server V5.4.0.
92
The client system options file contains the entries that are shown in Example 5-8.
Example 5-8 Windows client options file
TCPSERVERADDRESS nodename encryptkey encryptiontype include.encrypt PASSWORDACCESS MANAGEDSERVICES txnbytelimit tcpwindowsize tcpnodelay subdir
192.168.99.231 venya-win save AES128 * GENERATE WEBCLIENT SCHEDULE 25600 63 yes yes
Initial backup with ENCRYPTKEY SAVE

In our test, we backed up a single directory containing two text files by using selective backup from in the native Windows GUI. After selecting the files to back up, the window shown in Figure 5-1 displays.
Figure 5-1 GUI encryption key password dialog box
After we entered a password for the key, the backup successfully completed. The maximum allowed password length is 63 characters and it is case sensitive. Because of the ENCRYPTKEY SAVE setting in the dsm.opt file, the encryption key password is saved in the registry at: [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\NODENAME \SERVERNAME] The regedit output is shown in Figure 5-2.
93
Figure 5-2 Registry entry for encryption key
Note that the session password and data encryption keys are separate registry entries.
Subsequent backups or restores with ENCRYPTKEY SAVE

As long as the registry entry shown in Figure 5-2 is correct and intact, the user will not be prompted for an encryption key password for backups or restores.
Subsequent backups or restores with ENCRYPTKEY SAVE and a missing key

If the previously saved encryption key password is missing, the client behaves as though this is an initial backup with encryption; that is, the client prompts for a password to generate a new encryption key. Figure 5-3 shows the message that is presented to the user performing a backup in the event that the previously saved encryption key is inaccessible.
Figure 5-3 Prompt during backup if saved encryption key is not present
In Figure 5-1 on page 93, note that the password entered in this dialog box is used to generate a new registry encryption key password entry, because ENCRYPTKEY SAVE is specified in the dsm.opt. For restores, you need to enter the original password that was used for the encryption. The dialog box presented adds a check box to indicate that the newly generated key must be used for all remaining files (Figure 5-4 on page 95).
94
Figure 5-4 Prompt during restore if saved encryption key is unavailable
Multiple keys
When using ENCRYPTKEY SAVE, there is only one encryption key password saved locally on the client for each node-server pair. If the client backs up to multiple Tivoli Storage Manager servers, or uses different node names to contact the same server, separate keys will be generated for each server or node name. When backups or archives are performed, the client will always use the key associated with that node-server pair to encrypt or decrypt. If however, the key is lost and a new key is generated, any subsequent sessions, whether they are backup, restore, archive, or retrieve, will attempt to use that key. If data stored previously with a different key is encountered, the client will show the error shown in Figure 5-5 and request the correct key password.
Figure 5-5 Error when invalid key is presented
After the user inputs the correct key password, the data will be restored or retrieved. Also, while the session remains active, the client stores both keys on the session keyring cache. After the session is closed, the cache is destroyed. Subsequent sessions will again prompt for a key password for any files that do not match the locally stored key.
UNIX and Linux backup/archive client GUI

This section shows examples of using client encryption with the UNIX and Linux native GUI (dsmj). For this example, we use a Linux host running client V5.4.0. The server is a Linux host running Tivoli Storage Manager server V5.4.0. The client system options file contains the entries shown in Example 5-9 on page 96.
95
Example 5-9 Linux client system options file
SErvername local COMMmethod TCPPort TCPServeraddress passwordaccess encryptkey encryptiontype include.encrypt include.encrypt
TCPip 1500 127.0.0.1 generate save aes128 /home/* /home/.../*

If the file /etc/adsm/TSM.PWD (or /etc/security/adsm/TSM.PWD on AIX) does not exist and PASSWORDACCESS GENERATE is in the client system options file, the client will prompt for a password for the session on initial contact with the Tivoli Storage Manager server. This will create the TSM.PWD file and populate it with the encrypted password for the client session. When the client session performs an action that requires an encryption key and no key password is present in the TSM.PWD file, it will prompt the user as in Figure 5-6.
Figure 5-6 Prompt during backup if saved encryption key is not present
After the encryption key password is entered, the encryption key is saved in the file /etc/adsm/TSM.PWD. Note: Unlike the Windows client, the UNIX and Linux client stores both the session password and encryption key password in the same location (/etc/adsm/TSM.PWD). So in order to delete one password, both the session password and the encryption key password need to be reset.
Subsequent backups or restores with ENCRYPTKEY SAVE

As long as the contents of the TSM.PWD file are correct and intact, the user will not be prompted for an encryption key password for backups or restores.
Subsequent backups or restores with ENCRYPTKEY SAVE and a missing key

If the previously saved encryption key password is missing, the client behaves as though this is an initial backup with encryption; that is, it prompts for a password to generate a new encryption key. For restores, the client is prompted for the original password that was used for the encryption, as shown in Figure 5-7 on page 97.
96
Figure 5-7 Prompt during restore-saved if encryption key is unavailable
Note the checkbox in Figure 5-7 to indicate that to use the generated key for remaining files.
Multiple keys
When using ENCRYPTKEY SAVE, there is only one encryption key password saved locally on the client for each node-server pair. If the client backs up to multiple Tivoli Storage Manager servers or uses different node names to contact the same server, separate keys will be generated for each server or node name. When backups or archives are performed, the client will always use the key associated with that node-server pair to encrypt or decrypt. If, however, the key password is lost and a new key is generated, any sessions, whether they are backup, restore, archive, or retrieve, will attempt to use that key. If data stored previously with a different key is encountered, the client will show the error shown in Figure 5-8 and request the correct key password.
Figure 5-8 Error when invalid key is presented
Backup/archive client command line

The process for the Windows command line and the UNIX and Linux command line is very similar, so we will use the Windows client in this section. For this example, we use a Windows XP host running client V5.4.0. The server is a Linux host running Tivoli Storage Manager server V5.4.0. The client system options file contains the entries shown in Example 5-10 on page 98.
97
Example 5-10 Windows client options file
TCPSERVERADDRESS nodename encryptkey encryptiontype include.encrypt PASSWORDACCESS MANAGEDSERVICES txnbytelimit tcpwindowsize tcpnodelay subdir
192.168.99.231 venya-win save AES128 * GENERATE WEBCLIENT SCHEDULE 25600 63 yes yes

The backup runs as shown in Example 5-11.
Example 5-11 Command line prompt for key password
tsm> s c:\batch\* Selective Backup function invoked.
--- User Action is Required --File: \\venya-win\c$\batch\passwords.txt requires an encryption key.
Select an appropriate action 1. Prompt for encrypt key password A. Abort this operation Action [1,A] : 1 Enter encryption key password: ******* Confirm encryption key password: ******* Directory--> 0 \\venya-win\c$\batch [Sent] Normal File--> 81 \\venya-win\c$\batch\passwords.txt [Sent] Normal File--> 62 \\venya-win\c$\batch\tsmconsole.bat [Sent]
Selective Backup processing of '\\venya-win\c$\batch\*' finished without failure.
Subsequent backups or restores with ENCRYPTKEY save

As with the GUI clients, when the encryption key password is initially saved, the client will not prompt for it for any backup, restore, archive, and retrieve operations provided that the registry key or TSM.PWD is correct and intact.
Backups or restores with ENCRYPTKEY save if the key is lost

In Example 5-12 on page 99, the saved encryption key password was deleted prior to starting the session. The client prompts the user for the key password prior to restoring the files.
98
Example 5-12 Prompt during restore if saved encryption key is unavailable
tsm> restore c:\* Restore function invoked. ANS1247I Waiting for files from the server... Restoring 0 \\venya-win\c$\batch [Done]
--- User Action is Required --File '\\venya-win\c$\batch\passwords.txt' exists Select an appropriate action 1. Replace this object 2. Replace all objects that already exist 3. Skip this object 4. Skip all objects that already exist A. Abort this operation Action [1,2,3,4,A] : 2 --- User Action is Required --File: \\venya-win\c$\batch\passwords.txt requires an encryption key.
Select an appropriate action 1. Prompt for encrypt key password 2. Skip this object from decryption 3. Skip all objects that are encrypted A. Abort this operation Action [1,2,3,A] : 1 Enter encryption key password: ******* Confirm encryption key password: ******* Restoring 81 \\venya-win\c$\batch\passwords.txt [Done] Restoring 62 \\venya-win\c$\batch\tsmconsole.bat [Done] Restore processing finished.
5.4.5 Verifying that backed up data is encrypted

A crude method of verifying that the data sent to the Tivoli Storage Manager has been encrypted is to move the saved key password (export the registry entry and delete the key for Windows, or rename the TSM.PWD file for other clients) to another location temporarily and attempt a restore. If the data is truly encrypted, you will be prompted for a key password. Remember to move the key password back into the correct place after performing this test. To view the data that is sent to the Tivoli Storage Manager server, you can use a packet sniffer to capture a network trace of the data as it is sent. Example 5-7 on page 86 shows an example of a trace of an encrypted client data session. If the Tivoli Storage Manager server (or client) is on AIX, the native utility iptrace can also be used.
99
To view the client data as it is stored in the client disk storage pools, it is easiest to create a small disk storage pool and an associated management class that points to the disk storage pool. After storing a small quantity of data in the new disk storage pool, the storage pool files can be viewed using a tool, such as a hex editor. An example of data that is stored in a storage pool in both unencrypted and encrypted form is shown in 8.2, How is data written to storage pools on page 228.
5.5 Data encryption using the API client

API data encryption was introduced with V5.3 clients. API client encryption can be used by all the Tivoli Storage Manager application clients, for example, Tivoli Storage Manager for Databases and Tivoli Storage Manager for Mail. Essentially any application capable of sending data to or from the Tivoli Storage Manager server using the API, as well as the hierarchical storage management (HSM) for Windows client, can use API data encryption. With API data encryption, there are two methods available: application-managed encryption and transparent encryption. You need to use only one of these methods on a specific node in order to prevent issues when attempting to restore data.
5.5.1 API application-managed encryption

Using this method, the application that uses the API sends the key password to the API, and then it is up to the application to manage the key password. The application provides the key password in the dsmInitEx call and must provide the correct password at restore time to retrieve the data. One of the primary advantages of using this method is that there is no server version dependency; unlike API transparent encryption, this method does not require a V5.3 or higher server. To use this method, the following steps must occur: 1. The application must set the bEncryptKeyEnabled variable to bTrue in the call to dsmInitEx and set the encryptionPasswordP variable to point to a string with the encryption key password. 2. Specify an INCLUDE.ENCRYPT statement in the dsm.opt (for Windows) or the dsm.sys (for UNIX and Linux). The default behavior is to not encrypt the data, so an explicit INCLUDE.ENCRYPT statement is required. 3. Set -ENCRYPTKEY=PROMPT | SAVE in the option string that is passed to the API in the dsmInitEx call or use the ENCRYPTKEY option in the dsm.sys (UNIX and Linux) or dsm.opt (for Windows and Netware). The default is ENCRYPTKEY=PROMPT. This allows the use of different keys for different operations; if ENCRYPTKEY=SAVE is used, the one saved key password is used for all operations involving client encryption. Refer to the manual IBM Tivoli Storage Manager: Using the Application Program Interface, SC32-0147, for more information about this topic.
100
5.5.2 API transparent encryption

The transparent encryption method is typically easier to enable, because it does not require any changes to the API application code in order to be implemented. The application has no awareness that the data backed up is encrypted; the API and the Tivoli Storage Manager server handle all aspects of the encryption. The API client generates a random encryption key for each session and stores that key on the Tivoli Storage Manager server in the server database. Accordingly, unlike the file backup/archive client, the key is sent to the Tivoli Storage Manager server and is encrypted in transit between the client and the server. The only time that the key is transmitted unencrypted is during direct server-to-server exports and imports. To use this method of key management, the API must set the option ENABLECLIENTENCRYPTKEY to YES. You can do this either by defining the option in the client system options file (dsm.sys on UNIX and Linux or dsm.opt on Windows) or by including the option -ENABLECLIENTENCRYPTKEY=YES in the option string that is passed to the API on the dsmInitEx call.
Configuration for the client using API transparent encryption

This section includes an example of setting up a client to use both data encryption for the file backup/archive client and transparent data encryption for the API.
Client system options file (dsm.sys)

The client system options file that we used for this example is shown in Example 5-13. The first stanza is for the file backup/archive client; the second stanza is for use with the API.
Example 5-13 Contents of client system options file (dsm.sys)
SErvername COMMmethod TCPPort TCPServeraddress passwordaccess encryptiontypeaes include.encrypt include.encrypt
nenya TCPip 1500 127.0.0.1 generate 128 /* /.../*
SErvername nenya_api COMMmethod TCPip TCPPort 1500 TCPServeraddress 127.0.0.1 passwordaccess generate encryptiontypeaes 128 include.encrypt /* include.encrypt /.../* enableclientencryptkey yes
Client options file for the file backup/archive client (dsm.opt)

The client options file for the backup/archive client contains the following entries: SERVERNAME nenya subdir yes
101
Client options file for the API client (dsm_api.opt)

The contents of the dsm_api.opt file for the API are: SERVERNAME nenya_api subdir yes
5.5.3 Verifying that API data is encrypted

Data sent to the Tivoli Storage Manager server using the API is typically not clear text; usually, it is application data that is sent using a Data Protection module, for example, Tivoli Storage Manager for Mail. Even if the data is sent unencrypted, it is quite difficult to extract a usable chunk of the data so that it can be used again with the sending application. In order to determine that the data piped through the API is readable when unencrypted, we used the sample utility, called dapismp, that is included with the API. After installation on UNIX or Linux, this is included in source code form in the directory <INSTALL_DIR>/sample. In AIX, this is /usr/tivoli/tsm/client/api/bin/sample. On Linux or other UNIX platforms, it is /opt/tivoli/tsm/client/api/bin/sample. On Windows, it is precompiled and located in the folder C:\Program Files\Tivoli\TSM\api\SAMPRUN. The executable is called dapismp.exe. On platforms where only the source is provided, you can build the executable by using a standard C compiler and the commands indicated in the file makesmp.<XXX> in the sample directory. On an x86 Linux system, this file is called makesmp.linux86. On Windows, the file is makesmp.mak. On all platforms, the user interface is the same.
Using dapismp to perform an unencrypted backup using the API

The output from the test without encryption is shown in the following sections.
Log in to the Tivoli Storage Manager server

Example 5-14 shows how to provide the necessary log-in information to the program. User responses are indicated with bold text. Note that the node definitions must already exist on the Tivoli Storage Manager server.
Example 5-14 dapismp login to Tivoli Storage Manager server through API
nenya:~ # dapismp ************************************************************************* * Welcome to the sample application for the Tivoli Storage Manager API. * * API Library Version = 5.4.0.0 * ************************************************************************* Choose one of the following actions to test: 0. Signon 1. Backup 2. Restore 3. Archive 4. Retrieve 5. Queries 6. Change Password 7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent 8. Set preferences, envSetUp 9. Exit to system 10. Restore/Retrieve Without Offset Prompt 102
11.
Extended Signon
Enter selection ==>0 Node name:nenya_api Owner name:nenya_api Password:nenya API Config file:/opt/tivoli/tsm/client/ba/api/bin/dsm.opt Session options: User Name:nenya_api User pswd:nenya Are the above responses correct (y/n/q)? y Doing signon for node nenya_api, owner nenya_api, with password nenya Handle on return = 1
Backup of test file with no encryption

Example 5-15 shows the session output when you create and back up a test file from within the dapismp sample application. User responses are shown in bold text. The output indicates that there was no encryption used for this session.
Example 5-15 Creation and backup of test file with dapismp
Choose one of the following actions to test: 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Signon Backup Restore Archive Retrieve Queries Change Password Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent Set preferences, envSetUp Exit to system Restore/Retrieve Without Offset Prompt Extended Signon
Enter selection ==>1 Filespace:/ Highlevel:/tmp Lowlevel:/testfile.txt Object Type(D/F):f Object Owner Name:nenya_api Object already compressed?(Y/N):n Wait for mount?(Y/N):y File size:1024 Number of files:1 Seed string:This is a test file Mgmt class override: Are the above responses correct (y/n/q)? y Creating 1 object(s) called //tmp/testfile.txt(nnn) each of size 1,024. Creating object 1 of 1 Size=1,024 Name=//tmp/testfile.txt Object: 1 Buffer: 1 Bytes sent: 1,024 Bytes left: 0
103
Total bytes sent: Compression: Compressed size: LAN-free bytes sent: Encryption: Encryption Strength:
1,024 NO 0 0 NO NONE
Network trace without encryption

First, the file was backed up using the previous command without enabling encryption. From the network trace, the contents of the file can be seen in transit in Figure 5-9. 0130 0140 0150 0160 0170 0180 0190 ff 20 20 20 32 66 74 ff 66 74 69 54 69 65 54 69 65 73 68 6c 73 68 6c 73 20 69 65 74 69 65 74 61 73 38 20 73 32 20 20 20 33 66 20 30 66 74 69 54 69 69 54 69 65 73 68 6c 73 68 6c 73 20 69 65 20 69 65 74 61 73 31 61 73 34 20 20 20 30 20 20 31 66 74 69 34 74 69 54 69 65 73 54 65 73 68 6c 73 20 68 73 20 69 65 74 61 69 74 61 73 36 20 20 73 ..This is a test file20This is a test file41This is a test file6 2This is a test file83This is a test file104This
Figure 5-9 Unencrypted data sent from API
Network trace with encryption

Transparent API encryption was then enabled by adding the lines in Example 5-16 to the API dsm.sys file.
Example 5-16 Enable transparent API encryption in the dsm.sys file
encryptiontype include.encrypt include.encrypt enableclientencryptkey
aes128 /* /.../* yes
The logon through dapismp was the same as shown previously in Example 5-14 on page 102. The output from the backup session using encryption is shown in Example 5-17. Note that the completion information shown now indicates that the data was encrypted; as a side note, the volume of data has increased slightly as well.
Example 5-17 Creation and backup of test file with dapismp using encryption
Choose one of the following actions to test: 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 104 Signon Backup Restore Archive Retrieve Queries Change Password Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent Set preferences, envSetUp Exit to system Restore/Retrieve Without Offset Prompt Extended Signon
Enter selection ==>1 Filespace:/ Highlevel:/tmp Lowlevel:/testfile.txt Object Type(D/F):f Object Owner Name:nenya_api Object already compressed?(Y/N):n Wait for mount?(Y/N):y File size:1024 Number of files:1 Seed string:This is a test file too Mgmt class override: Are the above responses correct (y/n/q)? y Creating 1 object(s) called //tmp/testfile.txt(nnn) each of size 1,024. Creating object 1 of 1 Size=1,024 Name=//tmp/testfile.txt Object: 1 Buffer: 1 Bytes sent: 1,024 Bytes left: 0 Total bytes sent: 1,030 Compression: NO Compressed size: 0 LAN-free bytes sent: 0 Encryption: CLIENTENCRKEY Encryption Strength: AES_128BIT Figure 5-10 shows the relevant portion of the network trace when the data was resent, therefore, verifying that the data was no longer in clear text. 0130 0140 0150 0160 0170 0180 0190 f8 13 2d 08 05 57 e0 df f1 9e a5 19 bf 67 9d ae d2 00 f0 3c 3d 8e 2e c8 00 36 ca aa 27 b5 7e 01 06 8b f1 20 4a 38 00 29 2f 31 bf 7f 3e 00 d6 79 6d dd 33 66 00 2f f2 0f d4 92 73 04 8d 49 49 19 9a bb 16 fd 37 3b f2 6c f2 80 c5 0c e2 e8 5e 47 03 87 dc 21 c5 b7 24 00 a3 92 48 84 33 e1 c2 5b ad e9 e9 98 00 0f 31 4b 8d fa ba 00 00 3d 30 bf ....' .......... .....J.3..l^.3.. -...~8>fs..G$... ................ ...6.)./.....[1= W.<../y.I7....K0 .g=..1m.I;.!H...
Figure 5-10 Portion of an encrypted data packet sent through the API using dapismp
5.6 Performance observations of the backup/archive client

An important question when considering whether to implement client encryption is the potential performance impact. Clearly, there is overhead on the client to encrypt the data. We performed a number of backups and restores both with and without encryption in order to gain empirical data.
105
Description of the test environment

For these tests, we used the following: We used an IBM p520 server with two processors and 4 GB of memory at AIX V5.3 Technology Level 3. The Tivoli Storage Manager client and server are located on this host in order to eliminate the potential effects of any network traffic. The Tivoli Storage Manager server is at Version 5.3.2.0 and the Tivoli Storage Manager client is at Version 5.3.2.0. Three 3592 (TS1120) Fibre Channel tape drives, which are directly attached to the server, reside in an IBM 3494 tape library. The data to be backed up is a single file system that is located on a mirrored logical volume, which was placed on two mirrored 73 GB 10 K RPM drives. The drives are internal to the p520. The data was located contiguously on both drives. There were approximately 26,000 files, which had an average size of 135 K, in the file system and a total data volume of 3.45 GB. Data was written directly to a single 3592 drive. The test was repeated three times. The first test was discounted in order not to include media wait time. The command, which was run as root, that we used to perform the backup is: dsmc s '/Install/*' -subdir=yes -quiet The contents of the dsm.sys file for the first two tests are shown in Example 5-18. Note that the INCLUDE.ENCRYPT statements are commented out for these tests.
Example 5-18 dsm.sys file for test one and test two with no encryption
SErvername adsm COMMMethod TCPPort TCPServeraddress nodename passwordaccess errorlogname errorlogretention schedlogname schedlogretention schedmode managedservices encryptiontype encryptkey
tcpip 1500 localhost adsm01 generate /tmp/dsmerror.log 7 d /tmp/dsmsched.log 7 d prompted webclient schedule AES128 prompt
* *
include * to_backuptape2 include.encrypt /Install/* include.encrypt /Install/.../*
to_backuptape2 to_backuptape2
Example 5-19 on page 107 shows the client output for the first test, and Figure 5-11 on page 107 shows the CPU utilization that was gathered by using AIX nmon during that period. The test ran between approximately 13:36 and 13:40. CPU utilization during that period peaked at about 20% with an aggregate transfer rate of approximately 12.4 MB/sec.
106
Example 5-19 Test 1 without encryption
root@adsm01:bin>dsmc s '/Install/*' -subdir=yes -quiet IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.0 Client date/time: 02/20/07 13:35:21 (c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved. Node Name: ADSM01 Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 3, Level 2.0 Server date/time: 02/20/07 13:35:21 Last access: 02/20/07
13:26:38
Total number of objects inspected: 26,361 Total number of objects backed up: 26,361 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 3.45 GB Data transfer time: 13.69 sec Network data transfer rate: 264,444.16 KB/sec Aggregate data transfer rate: 12,421.10 KB/sec Objects compressed by: 0% Elapsed processing time: 00:04:51
Figure 5-11 CPU utilization for test one
Example 5-20 on page 108 and Figure 5-12 on page 108 show the output and monitoring results for the second test. This was performed in the same manner as the first test, that is, without encryption.
107
Example 5-20 Test two without encryption
13:35:21
Total number of objects inspected: 26,361 Total number of objects backed up: 26,361 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 3.45 GB Data transfer time: 23.26 sec Network data transfer rate: 155,703.37 KB/sec Aggregate data transfer rate: 11,910.81 KB/sec Objects compressed by: 0% Elapsed processing time: 00:05:04
Figure 5-12 CPU utilization for test two
The results were similar as we expected. Aggregate transfer rate was approximately 11.9 MB/sec, with a maximum CPU utilization at about 20%. Next, we ran two more tests: test three and test four. This time, we enabled AES128 encryption. Aside from this change, the tests were identical to tests one and two. Example 5-22 on page 109 shows the client output from test three with CPU utilization shown in Figure 5-13 on page 110.
108
The dsm.sys file that we used for tests three and four is shown in Example 5-21. Note that the INCLUDE.ENCRYPT statements are no longer commented.
Example 5-21 dsm.sys file for test three and test four with AES128 encryption enabled
SErvername adsm COMMMethod TCPPort TCPServeraddress nodename passwordaccess errorlogname errorlogretention schedlogname schedlogretention schedmode managedservices encryptiontype encryptkey include include.encrypt include.encrypt
tcpip 1500 localhost adsm01 generate /tmp/dsmerror.log 7 d /tmp/dsmsched.log 7 d prompted webclient schedule AES128 prompt * to_backuptape2 /Install/* to_backuptape2 /Install/.../* to_backuptape2
Example 5-22 Test three with AES128 encryption
13:43:56
--- User Action is Required --File: /Install/dlmgr.pro requires an encryption key.
Select an appropriate action 1. Prompt for encrypt key password A. Abort this operation Action [1,A] : 1 Enter encryption key password: Confirm encryption key password: Total number of objects inspected: 26,361
109
Total number of objects backed up: 26,361 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 3.45 GB Data transfer time: 26.15 sec Network data transfer rate: 138,509.40 KB/sec Aggregate data transfer rate: 10,838.15 KB/sec Objects compressed by: 0% Elapsed processing time: 00:05:44
Figure 5-13 CPU utilization for test three with AES128 encryption
For test three, the aggregate throughput was approximately 10.8 MB/sec with a peak CPU utilization of about 25%. The results for test four are shown in Example 5-23 and Figure 5-14 on page 111.
Example 5-23 Test four with AES128 encryption
14:02:45
--- User Action is Required --File: /Install/dlmgr.pro requires an encryption key.
Select an appropriate action
110
1. Prompt for encrypt key password A. Abort this operation Action [1,A] : 1 Enter encryption key password: Confirm encryption key password: Total number of objects inspected: 26,361 Total number of objects backed up: 26,361 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 3.45 GB Data transfer time: 26.43 sec Network data transfer rate: 137,037.30 KB/sec Aggregate data transfer rate: 10,501.22 KB/sec Objects compressed by: 0% Elapsed processing time: 00:05:52
Figure 5-14 CPU utilization for test four with AES128 encryption
For test four, the aggregate throughput was 10.5 MB/sec with peak CPU utilization at about 25%. Results for the tests are summarized in Table 5-3.
Table 5-3 Summary of test results Test one MB/Sec Maximum CPU% 12.421 17.0 Test two 11.910 18.3 Average one and two 12.165 17.65 Test three 10.838 35.1 Test four 10.501 27.8 Average three and four 10.669 31.4 Percent Change -12.3% 78%
In this simple test scenario, we saw a significant increase in CPU utilization but a relatively small decrease in backup throughput.
111
Note: This test is simply intended for comparative purposes between encryption and non-encryption. No attempt was made to tune performance. Therefore, do not use these results as an indication of actual Tivoli Storage Manager achievable results. The impact of encryption on CPU and throughput can be affected by many other factors, such as other concurrent workloads on the system. Therefore, you must test in your own environment to gauge this impact. Nevertheless, we want to emphasize throughout this book that although client encryption has an observable effect on performance, we highly recommend client encryption for security reasons. We think that the benefits outweigh the disadvantages.
5.7 Upgrading the level of the Tivoli Storage Manager client

When upgrading the UNIX, Linux, or Windows clients from V5.3.x to V5.4 or higher, you are prompted to reenter the encryption key password. The format of the password file and the registry key have changed in V5.4, which is why it is necessary to reenter the encryption key password. We recommend that you continue to use the same password that you used before the upgrade.
5.8 Changing the client host name

Before V5.4 (or V5.3.4 with the Macintosh client), changing the host name (for UNIX, Linux, or Mac) or the computer name (for Windows) invalidated the encryption key password that is stored on the client. APAR IC48782 discusses this issue. If the host name or computer name changes, the user is prompted to reenter the encryption key password in order to access the encrypted data. This dependency is removed with later client versions. Note that changing the TCP/IP address does not affect encryption.
5.9 Encryption and hierarchical storage management clients

The Windows hierarchical storage management (HSM) client uses the standard Tivoli Storage Manager client API; therefore, transparent API encryption is possible when using the Windows HSM client. API application-managed encryption is not supported with the Windows HSM client configuration, because the application in this case is not written to take advantage of API application-managed encryption. Encryption is not currently supported for the UNIX and Linux HSM clients.
5.10 Encryption and LAN-free

Client encryption occurs after client compression (if client compression is used) and before the data is sent from the client to the server. Accordingly, if client encryption is used for a file, the file is still encrypted if it is sent to the server using LAN-free. However, the data is difficult to intercept in transit, because the data path for the bulk data movement is normally over a Fibre Channel SAN.
112
Chapter 6.
TS1120 Tape encryption

In 2006, the IBM System Storage TS1120 Tape Drive introduced integrated encryption technology, which allows data encryption to be performed by the tape drive hardware instead of at the software level. Encryption is performed at full drive speed after data compression, which results in little or no additional overhead in encrypting data on tape drives. Topics that we discuss in this chapter include: An introduction to the encryption options An overview of the TS1120 tape drive Encryption options with the TS1120 tape drive Configuring Tivoli Storage Manager with various encryption options IBM Encryption Key Manager (EKM) server backup and recovery Recommended best practices References Other vendors have encryption-capable tape drives that might provide similar capabilities from a Tivoli Storage Manager perspective. Consult their Web sites or other documentation for information about how to configure these devices. Note: IBM intends to make encryption available for LTO tape drives by using similar methods to the methods we describe here.
113
6.1 Introduction to TS1120 encryption options

Encryption is the process of transforming plaintext into an unintelligible format, which is also known as cipher text, in order that non-authorized users do not have access to the data. While there are many methods of encryption, modern encryption methods can be classified into either symmetric or asymmetric encryption. We provided a general introduction to encryption concepts in 1.7, Introduction to encryption on page 16.
The IBM System Storage TS1120 Tape Drive can perform the encryption of data as the data is written. The data encryption can be enabled or managed at one of three levels: application, system, and library as shown in Figure 6-1.
Application-managed encryption (AME) is managed within a software application, which

uses the tape drive. Currently, IBM Tivoli Storage Manager is the only application that supports TS1120 encryption. In this case, Tivoli Storage Manager manages the keys that are used for encryption. The other two methods, system-managed encryption (SME) and library-managed encryption (LME), use an External Encryption Key Manager. You can also configure Tivoli Storage Manager to work with either of these methods. The external key manager that is used is a product called IBM Encryption Key Manager (EKM).
Encryption Methods
Application-Managed
(TSM Only) Policy
Encryption Key Manager
System-Managed________ z/OS & AIX__________ Library-Managed___________
Policy
Policy
TS3500______________
Figure 6-1 TS1120 encryption methods
Application-managed encryption
Application-managed encryption (AME) for the TS1120 tape drive is performed through the Tivoli Storage Manager server; that is, the server functions as the key manager. The encryption policy that identifies where encryption is implemented is defined at the Tivoli Storage Manager device class level by using a new parameter called DRIVEENCRYPTION. See 6.2.4, Tivoli Storage Manager with AME on page 121 for more details.
114
Library-managed encryption
With LME, the tape library controls whether a specific cartridge is encrypted. By default, all tape cartridges within a library-managed logical library are enabled for encryption. In addition, LME provides you with the option to use barcode encryption policies to define which VOLSER within the logical library is encrypted. See 6.2.5, Tivoli Storage Manager with LME on page 123 for more details.
System-managed encryption
With SME, encryption within a logical tape library is determined at the tape drive level, because all of the tape drives within the logical library do not need to have encryption enabled. See 6.2.6, Tivoli Storage Manager with SME on page 124 for more details. Both LME and SME require the use of the EKM. AME does not require the EKM.
6.2 IBM System Storage TS1120 Tape Drive overview

The TS1120 tape drive encryption solution consists of three major components: TS1120 tape drive Encryption Key Manager software Encryption configuration policy The following sections provide a high level overview of the components. For more detailed information, refer to IBM Encryption Key Manager component for the Java platform Introduction, Planning, and User's Guide, GA76-0418, and IBM System Storage TS1120 Tape Encryption Planning, Implementation, and Usage Guide, SG24-7320.
6.2.1 TS1120 tape drive

The TS1120 tape drive has been available for several years and offers enterprise-class performance, capacity, and reliability. In 2006, the TS1120 tape drive was enhanced to provide built-in data encryption. The IBM Tape Encryption solution uses an Advanced Encryption Standard (AES) algorithm with a key length of 256 bits. AES is a symmetric encryption key method, which means that the same key (private or secret key) is used for both encryption and decryption. The keys are identical. Within the TS1120, symmetric key encryption is implemented by using an application specific integrated circuit (ASIC) chip. Figure 6-2 on page 116 provides a logical diagram of the elements within the TS1120 hardware.
Chapter 6. TS1120 Tape encryption
115
Host
FC port0
FC port1
TAPE DRIVE Drive Firmware
Host Interface DMA ASIC Compression

Decompression
uP
AES Encryption
Dynamic decryption
Code Code Memory Memory
buffer ECC and format encoding RW electronics RW Head
Tape Media
Figure 6-2 Logical diagram of the TS1120 tape drive
The ASIC chip also has a built-in compression engine to compress data dynamically before the data is encrypted. Symmetric encryption was chosen at this level because the encryption speed is significantly faster than asymmetric encryption. Both symmetric and asymmetric encryption processes are used to encrypt the data in the IBM Tape Encryption solution. Refer to 6.2.2, Encryption Key Manager (EKM) software on page 116 for more detail.
Feature codes
All TS1120 tape drives with feature code 5592 or 9592 are encryption-capable, which means that they are functionally capable of performing hardware encryption. All TS1120 drives ordered after the encryption feature became available are automatically encryption-capable. Drives which were installed before encryption became available can also be upgraded for this function; this is a chargeable option. The encryption function must then be activated in order to perform the encryption functions; This activation is referred to as encryption-enabled. Your IBM service support representative can enable the encryption function. There is no charge for enabling encryption on encryption-capable drives at the time of original installation; however, if you enable the encryption at a later date, there is a charge. Refer to the TS1120 documentation available at: http://www.ibm.com/systems/storage/tape/
6.2.2 Encryption Key Manager (EKM) software

EKM is a Java-based application for performing key management. It is used for cryptographic key management when the backup application is not performing this function within the actual application. That is, EKM is required for SME and LME with TS1120, but not for AME.
116
EKM is a free download from: http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504 EKM is supported on z/OS, i5/OS, AIX, Linux, HP-UX, Sun Solaris, and Windows. You can also obtain information relating to prerequisites and dependencies at the Web site. EKM uses both symmetric and asymmetric encryption to encrypt the data when writing and reading to a TS1120 encryption-enabled tape drive. Here is a summary of the encryption process: 1. When a scratch tape is first mounted, the tape drive communicates with the EKM to obtain the key necessary to encrypt the data. 2. EKM generates a random symmetric data encryption key. This is a secret key; it is also called the Data Key (DK) in EKM terminology. AES 256-bit encryption is used. The DK is used to encrypt the clear text to form cipher text. 3. Key Labels or aliases are associated with each tape drive that uses EKM. See the table at Tape drive table on page 118. These key labels are linked to public key certificates stored within the keystore. 4. The DK is wrapped with the Public Key that is associated with the tape drives key label. This public key is also called the Key Encryption Key (KEK). The wrapped data key, along with key label information about which private key is required to unwrap the symmetric key, forms a digital envelope called an Externally Encrypted Data Key (EEDK) structure. 5. Both the EEDK and the wrapped DK are stored on the tape. The same encryption key, which is also called the Data Key (DK), is used if more data is later appended to the same tape. Figure 6-3 shows these steps as a process chart.
Figure 6-3 EKM uses both symmetric and asymmetric encryption keys
The decryption process essentially works the same way but in reverse: 1. When a read request is received by the tape drive, the drive sends the EEDK to the EKM. 2. The EKM verifies the tape device against the drive table entries in the EKM server. 3. The EKM fetches the corresponding private key from the keystore. 4. The EKM unwraps the EEDK using the private key to recover the DK. 5. The data key is then sent to the tape drive in a secure manner. 6. The tape drive uses the DK to decrypt the data or to append more data to the tape.
117
EKM components
EKM consists of three components: the Java security keystore, the EKM configuration file, and the tape drive table. We describe how to configure EKM and each of these components in 6.4.2, Configuring EKM on page 129.
Java security keystore The Java security keystore, as the name implies, is a Java-based application used to hold the
certificates and the keys that are used by EKM to perform cryptographic operations. EKM supports multiple Java keystores that offer various operational characteristics. Currently, the supported IBM keystores are: JCEKS JCE4758KS/JCECAAKS JCE4785RACFKS/JCECCARACFKS JCERACFKS PKCS11|mplKS IBMi5OSKeyStore See the IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0148, for detailed information about the EKM and its supported keystores. We show you how to create the keystore in Creating the keystore on page 132.
EKM configuration file

This file controls the properties for EKM. The administrator needs to customize this file for the correct EKM operation. We discuss this further in Modify the EKM configuration file on page 134.
Tape drive table

The tape drive table file is a binary file that you cannot edit. The tape drive table file is used to track the tape devices with which EKM communicates to encrypt the data. The section Defining the tape drives on page 137 shows how to update this drive table. The drive table file is stored in the location that is indicated by the config.drivetable.file.url parameter in the EKM configuration file (see Installing the EKM Jar and configuration file on page 131).
Example 6-1 EKM drive table file
perigee> pwd /usr/ekm/keymanager perigee> ls -al -rw-r--r-1 root
system
1470 Feb 08 01:46 drivetable
Note: The EKM server needs to be up and running when you perform tape encryption and decryption. For redundancy reasons, there must be more than one EKM server. Data needs to be synchronized among the various servers. The TS3500 Library Specialist allows you to define up to four EKM servers. The EKM provides a synchronization command, sync, which makes sure that the three components mentioned, Java keystore, the EKM configuration file, and the tape drive table, are consistent among all the EKM servers. When there are multiple EKM servers, the EKM function fails over to another server if the first server is unavailable for any reason. See the EKM manual and 6.5, EKM server backup and recovery on page 152 for more information about how to set this up.
118
6.2.3 Encryption policy configuration

The Policy is the process of defining which data to encrypt. The IBM TS1120 tape encryption solution provides policy options at three levels: the application layer, the system layer, and the library layer. IBM supports two methods for managing the encryption keys: either through the application (in Open Systems) or through the EKM.
Encryption options with TS1120

Tivoli Storage Manager can be configured to work with the TS1120 tape drive through AME, SME, and LME. Table 6-1 on page 120 describes factors to consider when selecting the encryption method.
119
Table 6-1 Managing encryption policy Types of encryption management Application-managed Description The application directly controls whether a cartridge is encrypted. The policy and keys are passed between the application layer and the drives. Notes Considerations: The application manages allocations of cartridge format types to appropriate drives in heterogeneous environments. This method supports a large number of systems (for example, IBM and some non-IBM libraries). You can control encryption based on existing DEVCLASS type policies. Program updates are required for the application and, in some cases, the underlying operating systems or components. Considerations: Supported environment Tivoli Storage Manager for AIX, Windows, Linux, and Solaris
System-managed
The device driver controls whether data is encrypted. All of the cartridges in the logical library become encrypted when written from the beginning of the tape.
Encryption management is by drive, rather

than by cartridge. This method transparently supports a large number of systems (for example, non-IBM libraries). For AIX and Solaris, new device drivers must be deployed on tape servers. For AIX and Solaris, this method is available for only IBM device drivers. For AIX, the device driver supports failover to the drives alternate Fibre Channel connection.
IBM Atape AIX device driver, IBMtape Solaris device driver, and z/OS (through DFSMS)
120
Types of encryption management Library-managed
Description The library controls whether a specific cartridge is encrypted.
Notes Considerations: Based on drive settings, the library allows you to
Supported environment All applications that support the TS3500 Tape Library and are open-attached.
encrypt data by cartridge.
This method is the most transparent, because the application and device driver might not need updates. New library firmware must be deployed. This method is supported only on IBM libraries.
6.2.4 Tivoli Storage Manager with AME

At the time of writing this book, Tivoli Storage Manager is the only application that can use the TS1120 tape drive in AME mode. In this mode, the Tivoli Storage Manager application acts as the key manager and is responsible for managing the encryption keys. The EKM is not used (and therefore, does not have to be installed and configured) in this mode of encryption. Figure 6-4 on page 122 provides a high level overview of how the Tivoli Storage Manager server performs tape encryption when used with AME: 1. The tape drive mounts a tape for encryption and sends the tape ID (VOLSER) to Tivoli Storage Manager. 2. Tivoli Storage Manager then generates a 256-bit AES data key, encrypts the DK, and stores it and the tape identifier in the Tivoli Storage Manager database. 3. The tape drive encrypts data to the tape using the AES algorithms and the DK that was sent to the tape drive.
121
DK
Tivoli Storage Manager

Generate DK Store DK in Database
2
Database
Tape1 Tape2 AES Data Key AES Data Key Tape3 Tape4 AES Data Key AES Data Key
Tape ID
1 3
DK+DATA=>Encrypted Data
Encrypted Data
Drive
Tape
Tape ID
AES 256 Encrypted Data
Figure 6-4 Encryption data flow for the AME process
Figure 6-5 shows the high level data flow when you decrypt a tape or when you append data to an encrypted tape. The steps are: 1. The tape drive reads the tape ID or VOLSER and sends that information to Tivoli Storage Manager. 2. Tivoli Storage Manager looks up that tape ID in its internal database and finds the entry associated with it. 3. Tivoli Storage Manager decrypts the data key from the entry and sends the data key to the tape drive. 4. Now, the tape drive can read data from the tape, decrypting the data as it reads using the 256-bit AES data key and the AES algorithms to yield clear data.
DK

Search Table for Tape ID Retrieve DK from Database
2
Database
Tape1 Tape2 AES Data Key AES Data Key Tape3 Tape4 AES Data Key AES Data Key
Tape ID
Drive
DK+Encrypted DATA=>Clear Data
Decrypted Data
4
Tape ID
Tape
AES 256 Encrypted Data
Figure 6-5 Decryption data flow for the AME process
122
All tape drives within a logical tape library must use the same encryption method; mixing different encryption methods within the same logical library is not supported. This option is the easiest to set up when Tivoli Storage Manager is the primary backup and restore software in a Windows, UNIX, or Linux environment, because generating, maintaining, and expiring the data keys is done transparently within the Tivoli Storage Manager application. However, encryption using AME is limited to Tivoli Storage Manager backup/archive data only. Backup sets and Tivoli Storage Manager database backup and export tapes are not encrypted through Tivoli Storage Manager when you use AME. Therefore, you need to manage these volumes with greater security, especially because the Tivoli Storage Manager database contains the secret keys that are used to encrypt and decrypt encrypted tapes. We provide more information about the implications of using AME in Chapter 11, Providing a secure disaster recovery environment on page 293 and Chapter 12, Recovery and prevention of security breaches or data loss on page 319. By contrast, SME and LME can encrypt all Tivoli Storage Manager tapes. To enable AME within Tivoli Storage Manager, set the new device class parameter DRIVEENCRYPTION to ON. Refer to 6.4.1, AME configuration details on page 126 to read about how to configure Tivoli Storage Manager with AME. Note: The symmetric key is used to encrypt the data and there is a key for each encrypted tape. Tapes encrypted with AME can only be decrypted with data keys that are stored in the Tivoli Storage Manager server database. Unlike LME and SME, the data key is not stored on the tape cartridge. Therefore, you must make sure to secure Tivoli Storage Manager database backups, because without the database, which contains the encryption keys, you will not be able to decrypt any backed up data. Data that is encrypted using Tivoli Storage Manager with AME is incompatible with SME and LME. You cannot convert to LME or SME to recover the data.
6.2.5 Tivoli Storage Manager with LME

With LME, the library manages the encryption policy. By default, the encryption policy encrypts all tape cartridges within a logical library. The data key is stored on the tape. LME provides you with the option to use Barcode Encryption Policy or Scratch Encryption Policy (these are used interchangeably) to customize further which VOLSERs within the logical library to encrypt. To enable LME within Tivoli Storage Manager, you set the new device class parameter DRIVEENCRYPTION to ALLOW. Then, you must also configure EKM as the key manager. Figure 6-6 on page 124 shows the high level data flow of the LME process. When a tape is mounted in the library, the library through its encryption policies determines if the tape is encrypted or unencrypted. If it is an encrypted tape, the TS1120 sends a request through the library using TCP/IP to the EKM for the correct keys to encrypt the data to tape. Both symmetric and asymmetric encryption keys are used in this process. Refer to 6.2.2, Encryption Key Manager (EKM) software on page 116 for a description of how the encryption process occurs.
123
Library-Managed Encryption for Open Systems servers
3592 TS1120
TCP/IP
Keys
EKM Server
Application
Tape
Fibre
Device Driver
Data
TS3500
Figure 6-6 Library-managed tape encryption
Note: In a Windows, Linux, or UNIX environment, an out-of-band interface using TCP/IP protocol is used between the library and the EKM to transmit the data encryption key management requests and the keys that use the public and private key method.
6.2.6 Tivoli Storage Manager with SME

Similar to LME, the encryption process is transparent to Tivoli Storage Manager. In contrast to LME, SME is enabled at the tape drive level; therefore, not all tape drives within an SME system need to have encryption enabled. In SME, the data key is stored on the tape. To enable SME within Tivoli Storage Manager, you set the new device class parameter DRIVEENCRYPTION to ALLOW. As with LME, SME uses the EKM to act as the key manager. In the case of Tivoli Storage Manager deployed in an AIX or Solaris environment, the key manager communicates with the Atape device driver to manage the encryption policies. Note: SME is currently available on AIX, Solaris, and z/OS operating systems. Figure 6-7 on page 125 shows the dataflow among EKM, the AIX Atape device driver, and the encrypted tape drive. In this mode, the encryption process is transparent to the application that provides the data.
124
System-Managed Encryption for Open Systems Servers (In-band)
3592 TS1120
Data and Keys
Fibre
Atape
EKM
Tape
Application
Keystore
AIX TS3500
Figure 6-7 Key and policy flow in a SME environment
SME and LME are transparent to each other. In other words, a tape that is encrypted using SME can be decrypted using LME, and the reverse is also true, provided they both have access to the same EKM keystore and both use the same device driver.
6.3 Encryption on a TS3500 Tape Library with ALMS

While using Advance Library Management Support (ALMS) with the IBM System Storage TS3500 Tape Library is not required, we highly recommend that you use ALMS with encryption for the following reasons. Without ALMS, encryption is configured at the physical library level. Even if separate logical tape libraries are used, all of the tape drives within the physical library must be new TS1120 tape drives with encryption enabled. With ALMS, you can use both encryption-enabled and non-encryption-enabled drives. In addition, the following restrictions apply to a non-ALMS tape library: You can add an encryption-capable tape drive to a non-ALMS library that previously contained only non-encryption-capable tape drives, but you cannot enable encryption on the new tape drive. You can add a non-encryption-enabled tape drive to a non-ALMS library that is installed with encryption-capable tape drives, so long as they are not encryption-enabled. These encryption-capable tape drives are then restricted from becoming encryption-enabled. A tape drive that is not encryption-capable cannot be added to a non-ALMS library that has encryption-enabled drives. If it is added, it will be unavailable for use.
125
6.4 Configuration with different encryption methods

As we know, there are three encryption methods that you can use with Tivoli Storage Manager: AME, LME, and SME. We first describe AME. Then, we discuss how to configure the EKM because it is required for both LME and SME. See 6.4.2, Configuring EKM on page 129. There are also several common library configurations and device configurations for both LME and SME. We discuss these configurations in 6.4.3, Device configuration on page 140. Finally, we describe the specific configuration details for LME and SME individually.
6.4.1 AME configuration details

Before Tivoli Storage Manager can be enabled to use AME with TS1120 tape drives, you need to: Check that the tape library firmware and tape drive firmware are at the correct levels to support encryption. This should be the latest available firmware, which you can download from: ftp://ftp.ibm.com/storage See your device documentation for instructions to update the firmware. The encryption policies within Tivoli Storage Manager must be defined. We show you how to define the encryption policies. Note: All tape drives within a logical library must use the same encryption method. ALMS is available as an option with the TS3500 Tape Library. ALMS provides enhanced flexibility and capabilities for partitioning the TS3500 Tape Library. We recommend that you use ALMS when you deploy encryption, as we discussed in 6.3, Encryption on a TS3500 Tape Library with ALMS on page 125. Our environment uses Tivoli Storage Manager V5.4 on AIX, a TS3500 Tape Library, and two TS1120 tape drives.
Define a storage pool to use the encrypted device class

The steps are: 1. Define the library. You also define the drives to be used in the library. See Example 6-2 on page 126.
Example 6-2 Display library and drives
tsm: PERIGEE> query library lib2-encrypt libtype=SCSI Library Name: LIB2-ENCRYPT Library Type: SCSI ACS Id: Private Category: Scratch Category: WORM Scratch Category: External Manager: Shared: Yes LanFree: ObeyMountRetention:
tsm: PERIGEE>query drive lib2-encrypt 126

Library Name -----------LIB2-ENCRYPT LIB2-ENCRYPT
Drive Name -----------DRV1-3592 DRV2-3592
Device Type ----------3592 3592
On-Line ------------------Yes Yes
2. Define a device class LIB2-ENCRYPT with DRIVEENCRYPTION set ON. This option indicates to Tivoli Storage Manager that Tivoli Storage Manager is providing the AME. See Example 6-3.
Example 6-3 Define the device class LIB2-ENCRYPT
tsm: PERIGEE> define devclass LIB2-ENCRYPT library=lib2-encrypt driveencrypt=on 3. Define a storage pool called LIB2-ENCRYPT and associate it with the device class. See Example 6-4.
Example 6-4 Define storage pool LIB2-ENCRYPT_POOL
tsm: PERIGEE> define stgpool LIB2-ENCRYPT_POOL LIB2-ENCRYPT maxscr=10 4. We query the storage pool and the device class that were just created. See Example 6-5 on page 127.
Example 6-5 Verify the storage pool and the device class that we created
tsm: PERIGEE>query stgpool lib2-encrypt_pool Storage Pool Name ----------LIB2-ENCRYPT_POOL Device Class Name ---------LIB2-ENCRYPT Estimated Capacity ---------900 G Pct Util ----0.0 Pct Migr ----20.0 High Mig Pct ---90 Low Mig Pct --70 Next Storage Pool -----------
tsm: PERIGEE>q devclass lib2-encrypt f=d Device Class Name: Device Access Strategy: Storage Pool Count: Device Type: Format: Est/Max Capacity (MB): Mount Limit: Mount Wait (min): Mount Retention (min): Label Prefix: Library: Directory: Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: LIB2-ENCRYPT Sequential 2 3592 DRIVE DRIVES 5 0 ADSM LIB2-ENCRYPT
No
127
Drive Encryption: Scaled Capacity: Last Update by (administrator): Last Update Date/Time:
On 20 ADMIN 08/10/06
12:31:02
Note: Drive Encryption is set to ON for Tivoli Storage Manager with AME.
5. Now, back up data to the newly created encrypted device class. 6. To verify that the data stored on tape is encrypted by AME through Tivoli Storage Manager, query the tape volume in the storage pool that was used, as shown in Example 6-6 on page 128. Note the field Drive Encryption Key Manager is Tivoli Storage
Manager.
Example 6-6 Verify AME
tsm: PERIGEE>query volume j12457 f=d Volume Name: Storage Pool Name: Device Class Name: Estimated Capacity: Scaled Capacity Applied: Pct Util: Volume Status: Access: Pct. Reclaimable Space: Scratch Volume?: In Error State?: Number of Writable Sides: Number of Times Mounted: Write Pass Number: Approx. Date Last Written: Approx. Date Last Read: Date Became Pending: Number of Write Errors: Number of Read Errors: Volume Location: Volume is MVS Lanfree Capable : Last Update by (administrator): Last Update Date/Time: Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: J12457 LIB2-ENCRYPT_POOL LIB2-ENCRYPT 300,000.0 20 0.0 Filling Read/Write 0.0 Yes No 1 1 1 02/27/07 17:02:14 02/27/07 17:02:07 0 0 No 02/27/07 17:01:40
Note: With AME, the data keys that pertain to encrypted tapes are stored within the Tivoli Storage Manager database. It is important to keep the Tivoli Storage Manager database in a secure environment. Ideally, Tivoli Storage Manager database backup tapes also need to be kept separately from the data tapes, so that data is not compromised even if the Tivoli Storage Manager database is stolen. See Chapter 11, Providing a secure disaster recovery environment on page 293 for more information about security considerations.
128
Figure 6-8 on page 129 shows the Library Specialist view, which indicates that tape J12457 is encrypted after the archiving process.
Figure 6-8 Output from Library Specialist indicating tape J12457 is encrypted
6.4.2 Configuring EKM

EKM is a Java-based application that is used as the key manager when you configure Tivoli Storage Manager with LME and SME. The EKM application must be installed on one of the supported platforms, which, at the time of writing this book, are z/OS, i5/OS, AIX, Linux, HP-UX, Sun Solaris, and Windows. The configuration is largely the same for both LME and SME. Therefore, we present the configuration one time here for you to use with either encryption method, and we highlight any differences between the encryption methods. Before installing EKM, verify that you have a supported operating system platform at: http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504 At this Web site, you can also download the EKM application, documentation, a sample configuration file, and the correct Java Runtime Environment (JRE) that is required for the supported platforms. Here is a summary of the installation procedure: 1. Install the JRE. 2. Install the Unrestricted Policy Files. These files are needed by EKM to generate the encryption keys. 3. Install the EKM software. 4. Decide which keystore type to use. The keystores that you can use in conjunction with EKM are: JCEKS JCE4758KS/JCECAAKS JCE4785RACFKS/JCECCARACFKS JCERACFKS PKCS11|mplKS IBMi5OSKeyStore See the section Which keystore is right for you in the IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0418, for assistance to decide which keystore type to use. Some keystores are only supported on particular operating system platforms, for example.
129
5. Create the keystore and the required encryption keys. 6. Customize the EKM configuration file. 7. Start the EKM. 8. Define the tape drives with which the EKM communicates. As an illustration, we show how to set up the EKM in an AIX environment using a Java Cryptographic Extension Keystore (JCEKS). The JCEKS keystore is a Unix System Services Java file-based keystore that is supported on all platforms that can run the EKM. This keystore is password-protected and Triple Data Encryption Standard (DES)-encrypted. For the details about installing the EKM on Windows, see IBM System Storage TS1120 Tape Encryption Planning, Implementation, and Usage Guide, SG24-7320.
Install the IBM Java Runtime Environment

We got the AIX Java package from this Web site and and installed it according to the instructions: http://www-128.ibm.com/developerworks/java/jdk/aix/service.html The steps are: 1. We used the Java5-32 bit version of the JRE. You need to perform a free and simple user ID registration process before you can download this package from IBM. In our example, we downloaded the file j532redist.tar to the /usr/java50 subdirectory and ran the command tar -xvf j532redist.tar. Example 6-7 shows the output.
Example 6-7 Output from installation of the Java Runtime Environment
/usr/java50> ls -al total 146392 drwxr-xr-x 4 root drwxr-xr-x 46 bin -rw-r----1 root drwxr-xr-x 31 root drwxr-xr-x 7 root
system bin system sys sys
512 1024 74936320 512 512
Feb Feb Jan Nov Oct
05 05 31 18 09
17:37 18:13 18:42 2005 08:43
. .. j532redist.tar license sdk
2. We need to set the Java home directory. We modified .profile to include the environment variables shown in Example 6-8, because we use the AIX Korn Shell.
Example 6-8 Setting the PATH variable
... P8=/usr/java50/sdk/jre/bin P9=/usr/java50/sdk/bin JAVA_HOME=/usr/java50/sdk/jre CLASSPATH=/usr/java50/sdk/jre/lib PATH=$JAVA_HOME:/usr/bin:/usr/sbin:$P1:$P2:/etc:$P3:$HOME:$P8:$P9:. 3. After reloading the profile, we ensure that we have the correct Java version (Example 6-9 on page 131).
130
Example 6-9 Java version output
/home/root> java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20061002a (SR3)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20061001 (JIT enabled) J9VM - 20060915_08260_bHdSMR JIT - 20060908_1811_r8 GC - 20060906_AA) JCL - 20061002
Install the unrestricted policy files

Regardless of which version of Java you use, you must replace the US_export_policy.jar file and local_policy.jar file in your $JAVA_HOME/lib/security directory with downloadable files. These unrestricted policy files are required by the EKM so that it can serve the AES keys. Note that you must be a registered IBM user to access these files. Registration is free and simple. Download the files from: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk The new policy files are shown in Example 6-10.
Example 6-10 Installing the unrestricted policy files
/home/root> cd $JAVA_HOME/lib/security /usr/java50/sdk/jre/lib/security> ls -al total 128 drwxr-xr-x 2 root sys 512 drwxr-xr-x 10 root sys 1024 -rw-r--r-1 root system 2199 -rw-r--r-1 root sys 29731 -rw-r--r-1 root sys 2646 -rw-r--r-1 root sys 9609 -rw-r--r-1 root system 2212
Feb Oct Feb Oct Oct Oct Feb
07 09 05 02 02 02 05
13:07 08:43 18:06 04:03 04:03 04:03 18:06
. .. US_export_policy.jar cacerts java.policy java.security local_policy.jar
Installing the EKM Jar and configuration file

The steps to install the EKM Jar and configuration file are: 1. Download the latest EKM Jar file, IBMKeyManagementServer.jar, from this Web site: http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504 2. Copy the file IBMKeyManagementServer.jar file into the $JAVA_HOME/sdk/jre/lib/ext directory.
Example 6-11 location of IBMKeyManagementServer.jar file
/usr/java50/sdk/jre/lib/ext> ls -al total 7624 drwxr-xr-x 2 root sys 512 Oct drwxr-xr-x 10 root sys 1024 Oct -rw-r--r-- 1 root sys 183719 Oct -rw-r--r-- 1 root sys 268451 Oct ...
09 09 02 02
08:43 08:43 04:03 04:03
. .. CmpCrmf.jar IBMKeyManagementServer.jar
131
3. From the same Web site, also download the sample EKM configuration file, KeyManagerConfig.properties. Example 6-12 shows a copy of the newly downloaded file before customization. We have highlighted in bold several of the parameters we plan to modify.
Example 6-12 Sample copy of EKM configuration file: KeyManagerConfig.properties
Audit.event.outcome = success,failure Audit.event.types = all Audit.eventQueue.max = 0 Audit.handler.file.directory = keymanager/audit Audit.handler.file.name = kms_audit.log Audit.handler.file.size = 10000 Admin.ssl.keystore.name = testkeys Admin.ssl.truststore.name = testkeys config.drivetable.file.url = FILE://keymanager/drivetable debug = none debug.output = simple_file debug.output.file = keymanager/debug fips = Off TransportListener.ssl.ciphersuites = JSSE_ALL TransportListener.ssl.clientauthentication = 0 TransportListener.ssl.keystore.name = keymanager/testkeys TransportListener.ssl.keystore.type = jceks TransportListener.ssl.port = 443 TransportListener.ssl.protocols = SSL_TLS TransportListener.ssl.truststore.name = testkeys TransportListener.ssl.truststore.type = jceks TransportListener.tcp.port = 3801 config.keystore.file = keymanager/testkeys config.keystore.provider = IBMJCE config.keystore.type = jceks
Creating the keystore

Now we want to create the keystore that is required to store the encrypted keys and certificates. We use the keytool utility, which is located in $JAVA_HOME/sdk/jre/bin directory. This directory was added to our path in Example 6-8 on page 130. We recommend that you use the Keytool User Guide for SDK 1.4.2 as a reference. It is available at: http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDocs/ KeyToolUserGuide-142.html In our example, we use JCEKS because this keystore is supported on all the EKM platforms. To create the keystore: 1. In Example 6-13 on page 133, we use the keytool utility to create a self-signed Public/Private Key pair with the RSA encryption algorithm. We recommend that you create a dedicated directory, for example, /usr/ekm before you run the keytool commands. The first command (with the -genkey option) creates the specified keystore file because it does not already exist, GIkeys.jcks, in our example. The next keytool command with the -selfcert option creates a self-signed certificate. We also specify an EKM password with the -keypass parameter (passphrase, in our example), which is used whenever we start or run the EKM program.
132
We create and self-sign four certificates: GIcert1, GIcert2, GIcert3, and GIcert4.
Example 6-13 Command to create keystore and generate self-signed certificate
#Command to generate a key GIcert1 keytool -genkey -alias GIcert1 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to selfsign a key GIcert1 keytool -selfcert -alias GIcert1 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to generate a key GIcert2 keytool -genkey -alias GIcert2 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to selfsign a key GIcert2 keytool -selfcert -alias GIcert2 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to generate a key GIcert3 keytool -genkey -alias GIcert3 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to selfsign a key GIcert3 keytool -selfcert -alias GIcert3 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to generate a key GIcert4 keytool -genkey -alias GIcert4 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 #Command to selfsign a key GIcert4 keytool -selfcert -alias GIcert4 -dname CN=GIcom -keystore GIkeys.jcks -provider IBMJCE -keyalg RSA -keysize 2048 -keypass "passphrase" -storepass "passphrase" -storetype JCEKS -validity 999 2. We can list our generated certificates in the keystore as shown in Example 6-14 on page 134.
133
Example 6-14 Listing of the certificates that are stored in the keystore
/usr/ekm>keytool -list -storetype JCEKS -keystore GIkeys.jcks -storepass passphrase -provider IBMJCE Keystore type: JCEKS Keystore provider: IBMJCE Your keystore contains 4 entries gicert4, Jan 30, 2007, keyEntry, Certificate fingerprint (MD5): 2B:0F:B2:62:E5:0F:C8:F3:C4:45:35:A0:94:96:A8:74 gicert3, Jan 30, 2007, keyEntry, Certificate fingerprint (MD5): 89:69:F6:B1:7A:97:C1:24:20:32:81:0A:90:1C:43:6D gicert2, Jan 30, 2007, keyEntry, Certificate fingerprint (MD5): B1:A8:02:6E:D1:88:E9:C1:6B:B7:BE:93:A5:7F:2C:8C gicert1, Jan 30, 2007, keyEntry, Certificate fingerprint (MD5): 0F:2B:37:49:16:86:91:90:26:98:26:A1:EB:22:71:2C Note that self-signed certificates must only be used in a testing environment. We recommend that production environments use signed certificates from a Certificate Authority.
Modify the EKM configuration file

Example 6-15 on page 135 shows the modified KeyManagerConfig.properties file. We copied the sample file in Example 6-12 on page 132 to the /usr/ekm directory and modified it as shown. It now points to our certificate file and our drive table file location /usr/ekm/keymanager/drivetable (indicated by the config.drivetable.file.url parameter). JCEKS is the default keystore type; therefore, we did not have to alter these parameters.
134
Example 6-15 Customized KeyManagerConfig.properties file
TransportListener.ssl.port = 443 TransportListener.tcp.port = 3801 fips = Off Admin.ssl.keystore.name = GIkeys.jcks config.keystore.provider = IBMJCE TransportListener.ssl.clientauthentication = 0 TransportListener.ssl.ciphersuites = JSSE_ALL Audit.handler.file.size = 10000 drive.acceptUnknownDrives = false TransportListener.ssl.truststore.name = GIkeys.jcks Audit.handler.file.directory = audit TransportListener.ssl.protocols = SSL_TLS config.keystore.file = GIkeys.jcks TransportListener.ssl.truststore.type = jceks debug.output = simple_file TransportListener.ssl.keystore.name = GIkeys.jcks Audit.eventQueue.max = 0 debug.output.file = keymanager/debug TransportListener.ssl.keystore.type = jceks Audit.handler.file.name = kms_audit.log config.keystore.type = jceks Audit.event.outcome = success,failure debug = none Audit.event.types = all config.drivetable.file.url = FILE:/usr/ekm/keymanager/drivetable Admin.ssl.truststore.name = GIkeys
Start the EKM server

Example 6-16 shows how to start the EKM. Enter the password, which is the passphrase configured earlier in Example 6-13 on page 133. You will see a number symbol (#) prompt, where you can enter the EKM commands. We show several useful commands. We had already generated two more certificates, making a total of four certificates in the keystore.
Example 6-16 EKM server startup process
/usr/ekm>java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties # startekm password: *********** <-- enter password here Loaded drive key store successfully Starting the Encryption Key Manager 1.0-20060816 Processing Arguments Processing Server is started # status Server is running. TCP port: 3801, SSL port: 443 # listconfig debug.output=simple_file config.drivetable.file.url=FILE:/usr/ekm/keymanager/drivetable Admin.ssl.keystore.name=GIkeys.jcks Audit.handler.file.directory=audit Audit.event.types=all Admin.ssl.truststore.name=GIkeys
135
debug.output.file=keymanager/debug TransportListener.ssl.protocols=SSL_TLS Audit.handler.file.name=kms_audit.log TransportListener.ssl.keystore.name=GIkeys.jcks Audit.eventQueue.max=0 TransportListener.tcp.port=3801 TransportListener.ssl.truststore.name=GIkeys.jcks config.keystore.file=GIkeys.jcks Audit.handler.file.size=10000 config.keystore.type=jceks TransportListener.ssl.ciphersuites=JSSE_ALL TransportListener.ssl.clientauthentication=0 TransportListener.ssl.port=443 TransportListener.ssl.keystore.type=jceks debug=none config.keystore.provider=IBMJCE TransportListener.ssl.truststore.type=jceks Audit.event.outcome=success,failure drive.acceptUnknownDrives=false fips=Off # listcerts -v Keystore entries: 4 Keystore type:jceks Keystore provider:IBMJCE Alias name: gicert4 Creation date: Tue Feb 06 00:53:00 MST 2007 Entry type: keyEntry Owner: CN=GIcom Issuer: CN=GIcom Serial number: 1170748379 Valid from: Tue Feb 06 00:52:59 MST 2007 until: Sun Nov 01 00:52:59 MST 2009 Certificate fingerprint (MD5withRSA): 9c:cf:5f:f0:d2:8b:4a:f0:25:db:e6:18:a4:5a:76:a4:59:3b:5b:9a:98:95:4d:62:79:3a:35:8 8:c1:46:21:eb:aa:6d:4b:f7:2b:b:5e:4e:6e:a0:7e:56:74:e3:aa:77:16:33:bd:7b:70:1f:29: 8:fe:e6:e2:ac:3e:45:af:60:f8:35:4:ae:a8:68:fe:ed:ba:14:4a:d0:71:45:a8:dc:b7:33:d6: 74:ad:ee:17:9f:ca:57:32:f8:73:5c:41:64:24:7a:2b:7a:a1:fe:dd:b9:68:6b:35:15:23:5e:4 6:50:f7:a3:71:4a:da:a:15:f0:64:d4:f0:1b:a5:66:3d:f9:ed:e7:ec:c5:d5:fd:f:43:4:81:5: 63:2d:82:f9:65:3f:a5:3d:1f:ce:88:3c:1a:87:e6:27:7a:e:69:f0:b:5f:7e:16:f3:60:67:65: 96:79:1e:d5:d7:a1:7e:7b:11:11:a4:98:e3:aa:34:46:86:83:75:ca:34:7a:63:7b:a9:f3:8a:1 b:99:ee:72:14:83:8c:35:72:4b:f6:a3:25:ba:f3:61:fa:54:8:a6:df:ee:74:c5:26:63:46:a4: 3d:a4:60:78:8a:67:a6:34:55:81:f4:f6:a1:dd:71:c5:d4:ab:b7:23:4f:5e:3:95:7a:f2:c0:56 :e7:f:78:ca:ca:b1 Some entries deleted Alias name: gicert1 Creation date: Mon Feb 05 18:24:47 MST 2007 Entry type: keyEntry Owner: CN=GIcom Issuer: CN=GIcom Serial number: 1170725087 Valid from: Mon Feb 05 18:24:47 MST 2007 until: Sat Oct 31 18:24:47 MST 2009
136
Certificate fingerprint (MD5withRSA): 73:2b:6d:1c:fa:7a:82:50:d9:76:56:e5:43:e5:f6:ce:64:6b:52:89:89:91:18:c4:d7:e1:1e:6 3:79:44:28:ae:3c:df:3a:49:a8:62:d1:4c:ce:c4:4b:4b:f6:4:c4:32:fd:62:bd:54:15:9c:dd: fb:fd:ef:db:c4:52:3b:84:f3:d7:8:55:5a:77:da:22:2f:10:eb:39:da:a8:28:81:8d:91:d1:4e :5f:40:fb:2c:70:75:61:60:f2:8b:90:cd:d5:3:31:cd:10:3f:47:a8:98:da:6f:21:a7:6:d0:6f :19:bc:87:4b:6b:14:60:99:e6:45:d4:6:fa:3:65:2b:2f:ec:ba:e9:8e:55:9e:75:c1:63:e6:82 :3b:89:45:af:a6:42:be:90:6d:dc:79:18:98:27:f6:8c:1f:77:bb:f3:5f:3e:3e:12:6b:28:b0: 16:6c:1c:3d:65:15:2f:d9:f8:96:4a:4a:7a:bf:e4:1d:74:eb:83:97:27:f1:a4:6:ec:26:a4:12 :21:9c:76:5e:ae:b3:45:d1:cf:f4:5c:a3:bb:8d:90:33:c8:78:22:de:b0:bd:b4:de:c1:20:8e: 3a:4d:0:15:1e:b0:d8:7a:6b:8d:e6:73:ab:16:20:8b:50:0:19:67:b3:3:bb:23:bd:42:1:8c:90 :c9:cc:2d:bb:9b:9 Note: To detect new certificates added while the EKM is running, you need to restart the EKM.
Defining the tape drives

Now we need to let EKM know with which tape drives it communicates. You can add the tape drives automatically or manually. We recommend that you add the tape drives manually for greater control. To have tape drives automatically added when they are detected by the EKM, enter the drive.acceptUnknownDrives parameter into the EKM configuration file. By default, this parameter is not present and is therefore FALSE. If you enter the parameter and set it to TRUE, then the EKM tape drive table is automatically populated whenever a new tape drive contacts the EKM. From a security perspective, disable this parameter to minimize rogue hardware from being deployed without proper change control or the administrators knowledge. Instead of automatically adding tape drives, add them manually using the adddrive command from the EKM prompt. You need the tape drive serial number before you can use the adddrive command. Example 6-17 on page 138 shows you one way to get the tape drive serial number.
137
Example 6-17 Example of how to get a tape drive serial number
tsm: PERIGEE>query drive lib2-encrypt f=d Library Name: Drive Name: Device Type: On-Line: Read Formats: Write Formats: Element: Drive State: Volume Name: Allocated to: WWN: Serial Number: Last Update by (administrator): Last Update Date/Time: Cleaning Frequency (Gigabytes/ASNEEDED/NONE): Library Name: Drive Name: Device Type: On-Line: Read Formats: Write Formats: Element: Drive State: Volume Name: Allocated to: WWN: Serial Number: Last Update by (administrator): Last Update Date/Time: Cleaning Frequency (Gigabytes/ASNEEDED/NONE): LIB2-ENCRYPT DRV1-3592 3592 Yes 3592-2C,3592-2,3592C,3592 3592-2C,3592-2,3592C,3592 295 EMPTY
5005076300010833 000001350440 ADMIN 08/09/06 17:35:03 NONE LIB2-ENCRYPT DRV2-3592 3592 Yes 3592-2C,3592-2,3592C,3592 3592-2C,3592-2,3592C,3592 296 UNKNOWN
5005076300010834 000001350446 ADMIN 02/21/07 15:53:22 NONE
Associated with each certificate is a label or alias. You can configure each tape drive with one or more certificate labels. The syntax for adding a tape drive is: # adddrive -drivename <serialnumber> [-rec1 <alias1>] [-rec2 <alias2>] Using rec1 and rec2 is optional. If they are not specified, the values are obtained from the parameters drive.default.alias1 and drive.default.alias2, which are defined within the KeyManagerConfig.properties file. These parameters are not predefined by default. You can use the parameters rec1 and rec2 in several ways: For situations where there is no need to share data with a third party, the values for both rec1 and rec2 can be the same, that is, the same label for the public key can be used for both parameters. If tapes need to be read by a third party in a location that does not have a copy of our keystore, the external partys public key needs to be stored in our local EKM keystore. The external partys public key label is then used for the parameter rec2. This definition allows the encrypted tape to be decrypted either locally by our private key stored within the local keystore or remotely at the external location through the private key that is stored in the third partys keystore.
138
Additionally, if there is a requirement to have a unique key at a disaster recovery (DR) site, rec2 can be used to refer to the DR locations public key label. Again, the DR locations public key must be stored within the local keystore. Note: The TS1120 tape drives can share labels or aliases. At a minimum, you need to have one key (either a self-signed or Public-Private key pair) defined with the keystore. Example 6-18 shows an example of adding tape drives manually to the EKM by using unique key labels.
Example 6-18 Adding drives to the EKM and listing the drives
# adddrive -drivename 000001350440 -rec1 gicert1 -rec2 gicert2 # adddrive -drivename 000001350446 -rec1 gicert3 -rec2 gicert4 # listdrives Drive entries:2 SerialNumber = 000001350440 SerialNumber = 000001350446
Registering the EKM server with the tape library

To allow the tape library to communicate with the EKM server, you need to register all of your EKM servers within the Tape Library Specialist. Up to four EKM servers can be registered. Refer to 6.4.3, Device configuration on page 140 to learn how to register your EKM servers. If you have multiple EKM servers, you need to keep them synchronized, which can be done manually or automatically. See the section Synchronizing data between two EKM servers in the IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0418, and 6.5.1, EKM server disaster recovery considerations on page 152 for information about how to handle two EKM servers.
Managing certificates within the EKM

Although you must specify a validity period when you define a key certificate, at the time of writing this book, the EKM does not check the expiration dates of the certificates in use. You can continue to read, write, and append data to tapes with expired certificates. The administration of security policies differs from company to company. Depending on the security policies, an organization might choose to continue to use expired certificates for various reasons, such as ease of management, limited security exposures, and so forth. The EKM presently provides this flexibility by allowing usage of expired certificates. In general, however, it is not good security practice to continue to use expired certificates. Currently, EKM does not managed expired certificates and, therefore, you need to manage security policies externally to the EKM. Note: Do not remove an expired certificate from the keystore because this prevents an encrypted tape from being read.
139
6.4.3 Device configuration

To configure a device: 1. Update the firmware for the tape library and the tape drive to the most current levels. Download the TS3500 firmware from: ftp://ftp.software.ibm.com/storage/358x/3584/ Download the TS1130 and 3592 tape drive firmware from: ftp://ftp.software.ibm.com/storage/3592/ You can update the firmware through the Tape Library Specialist. Refer to the IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560, for more details. 2. Modify the library EKM address panel to include the TCP/IP addresses of the EKM servers. On the Tape Library Specialist, select Manage Access Key Manager Addresses Create. See Figure 6-9. Enter the IP address of the Key Manager Server. The port 3801 is the default port. Click Apply.
Figure 6-9 Adding EKM server TCP/IP addresses to Tape specialist
3. In Figure 6-10, select Refresh to see the EKM server update on the panel. 4. Perform a connectivity test by pinging the address as shown in Figure 6-10 and Figure 6-11 on page 141.
Figure 6-10 Ping connectivity test
140
Figure 6-11 Output indicating successful ping of the EKM server from the tape library
We are now ready to configure specifically either SME or LME.
6.4.4 LME configuration details

To configure the TS3500 tape library for LME: 1. Enable encryption for a logical library. 2. Set up the barcode encryption policy or the internal label encryption policy. 3. Verify Tivoli Storage Manager with LME.
Enable encryption for a logical library

To enable encryption for a logical library: 1. At the Tape Specialist, go to Managed Library By Logical Library. A page similar to Figure 6-12 displays. Check the appropriate logical library, select Modify Encryption Method option, and click Go.
Figure 6-12 Example of logical libraries within the Tape Specialist
2. Figure 6-13 on page 142 displays. In the Encryption Method list box, select Library-Managed. For the Scratch Encryption Policy, select Barcode (default). Click Apply.
141
Figure 6-13 Example of how to enable the logical library for LME
3. Figure 6-14 shows that library 20-33 has been enabled for LME.
Figure 6-14 Library 20-33 has been enabled with the LME method
Note: LME is performed at the tape cartridge level. The default LME setting is to encrypt all cartridges in a logical library. Usage of the barcode encryption policy (BEP) is optional and is only available with LME. BEP is used to further define which tape cartridges to encrypt and which tape cartridges to leave unencrypted. The maximum allowable BEP is 300 for the entire TS3500 Tape Library.
Barcode encryption policy (BEP)

This is also called the scratch encryption policy. The BEP allows the TS3500 to identify which scratch tapes to encrypt when a new scratch tape is required. A BEP specifies which scratch cartridges to encrypt; it does not indicate which cartridges are currently encrypted. When you create a BEP, you need to specify two key labels. These key labels refer to the certificates that have been defined previously within an EKM keystore. Associated with each key label is a key mode. A key mode is the method by which a key manager identifies the public and private keys that were used to encrypt a data key.
142
Choices for key mode are: Default label: The label was configured at the EKM. Clear label: The Externally Encrypted Data Key (EEDK) that is referenced by the specified key label. Hash label: The EEDK that is referenced by a computer value, which corresponds to the public key that is referenced by the specified key label. This is shown in Figure 6-15.
Figure 6-15 Barcode encryption policy
Note: The IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560-01 still refers to the BEP as the scratch encryption policy. An alternative encryption policy, the Internal Label Encryption Policy, is available. At the time of writing this book, this policy is used by VERITAS NetBackup.
Verifying Tivoli Storage Manager with LME

From the Tivoli Storage Manager server perspective, we can use similar definitions as in Define a storage pool to use the encrypted device class on page 126. However, we set the parameter DRIVEENCRYPTION to ALLOW in the device class definition in order to enable LME. Example 6-19 on page 144 shows the setting of this parameter for a device class named lib2-encrypt.
143
Example 6-19 lib2-encrypt device class with drive encryption value set to ALLOW
tsm: PERIGEE>query devclass lib2-encrypt f=d Device Class Name: Device Access Strategy: Storage Pool Count: Device Type: Format: Est/Max Capacity (MB): Mount Limit: Mount Wait (min): Mount Retention (min): Label Prefix: Library: Directory: Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: Drive Encryption: Scaled Capacity: Last Update by (administrator): Last Update Date/Time: LIB2-ENCRYPT Sequential 2 3592 DRIVE DRIVES 5 0 ADSM LIB2-ENCRYPT
No Allow 20 ADMIN 02/06/07
01:17:55
Figure 6-16 shows the Tape Library Specialist volume listing before backing up data using the LME device class. Note that volume SJ0011 is marked Not Encrypted.
Figure 6-16 Tape SJ0011 is not encrypted before it is used
144
In Example 6-20, we perform a client archive operation to a management class that has been preconfigured earlier to use the encrypted device class.
Example 6-20 Perform a test archiving to library enabled with LME
tsm> archive -archmc=data /tmp/ekm/local_policy.jar Archive function invoked. Normal File--> 2,212 /tmp/ekm/local_policy.jar [Sent] ANS1114I Waiting for mount of offline media. Retry # 1 Normal File--> 2,212 /tmp/ekm/local_policy.jar [Sent] Archive processing of '/tmp/ekm/local_policy.jar' finished without failure. We query the contents of the tape that was used in order to show that it was the destination of the archive operation. See Example 6-21.
Example 6-21 Query tape contents
tsm: PERIGEE>query con sj0011 Node Name --------------PERIGEE Type ---Arch Filespace Name ---------/tmp FSID ---7 Client's Name for File --------------------/ekm/ local_policy.jar
In Figure 6-17, we display the Tape Specialist again to show that the tape cartridge SJ0011 is now encrypted after the Tivoli Storage Manager archiving process.
Figure 6-17 Output from the Tape Specialist after the archiving test
We can verify the encryption also from Tivoli Storage Manager, as in Example 6-22 on page 146. Note the Drive Encryption Key Manager field.
145
Note: In Example 6-22, the field displays NONE (the field did not update correctly), which is a known issue with the level of Tivoli Storage Manager that we used. We expect a fix for this in a future release so that it displays Library.
Example 6-22 Query volume output for LME
tsm: PERIGEE>query volume sj0011 f=d Volume Name: Storage Pool Name: Device Class Name: Estimated Capacity: Scaled Capacity Applied: Pct Util: Volume Status: Access: Pct. Reclaimable Space: Scratch Volume?: In Error State?: Number of Writable Sides: Number of Times Mounted: Write Pass Number: Approx. Date Last Written: Approx. Date Last Read: Date Became Pending: Number of Write Errors: Number of Read Errors: Volume Location: Volume is MVS Lanfree Capable : Last Update by (administrator): Last Update Date/Time: Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: SJ0011 LIB2-ENCRYPT_POOL LIB2-ENCRYPT 300,000.0 20 0.0 Filling Read/Write 0.0 Yes No 1 1 1 02/07/07 00:51:22 02/07/07 00:51:22 0 0 No 02/07/07 00:51:22
NONE
Example 6-23 on page 147 is sample output from the EKM audit file kms_audit.log, which is located in the /usr/ekm/audit directory. This output shows the certificates that were used during the encryption process.
146
Example 6-23 Sample entries from the EKM kms_audit.log file
Runtime event:[ timestamp=Wed Feb 07 00:51:22 MST 2007 event source=com.ibm.keymanager.g.fb outcome=[result=successful] event type=SECURITY_RUNTIME resource=[name= Drive Serial Number: 000001350446 WWN: 5005076300010834 VolSer : SJ0011 Key Alias/Label[0]: GIcert3 Key Alias/Label[1]: GIcert4;type=file] action=stop ] Runtime event:[ timestamp=Wed Feb 07 14:51:40 MST 2007 event source=com.ibm.keymanager.c.a.a outcome=[result=successful] event type=SECURITY_RUNTIME resource=[name=EKMAdmin;type=application] action=runKMSAdmin user=[name=EKMAdmin] ]
6.4.5 SME configuration details

Setting up SME on the TS1120 tape drive is similar to LME in that: The tape library and tape drive firmware must be updated to the latest versions, which we discussed in 6.4.3, Device configuration on page 140. Key Management is still done by the EKM. We described how to set up EKM in 6.4.2, Configuring EKM on page 129. We set up SME using the IBM AIX Atape device driver for the TS1120 drives. Here are the configuration steps required to enable SME: 1. Install or update the Atape device driver to the current level. 2. Enable the logical library for SME through the Tape Specialist. 3. Update the Atape EKM proxy configuration file. 4. Update the Atape device driver configuration. 5. Verify that you have Tivoli Storage Manager with SME.
Installing or updating the Atape device driver

Upgrade to the latest version of the Atape device driver. You can download this version from: ftp://ftp.software.ibm.com/storage/devdrvr
Enabling the logical library for SME

SME for a logical tape library is enabled through the Tape Library Specialist. This was described in Enable encryption for a logical library on page 141. We use the same method, but we select system-managed, instead of library-managed. Figure 6-18 on page 148 show the options available when you enable SME. SME can be enabled on an individual drive basis.
147
Figure 6-18 Tape Specialist configuring the logical library with SME
Example 6-24 shows the new encryption flag for tapeutil after enabling the tape drives within a logical library for SME.
Example 6-24 Tape drive tapeutil output after setting the logical library to SME
perigee> tapeutil -f /dev/rmt70 encryption Getting drive encryption settings... Encryption settings: Drive Encryption Capable.... Yes Encryption Method........... System Encryption State............ On perigee> tapeutil -f /dev/rmt71 encryption Getting drive encryption settings... Encryption settings: Drive Encryption Capable.... Yes Encryption Method........... System Encryption State............ On
Updating the Atape EKM proxy configuration file

The addresses of the EKM servers need to be made known to Atape. The Atape EKM configuration file is called ibmekm.conf and is located in the /etc directory. In our example, Tivoli Storage Manager and EKM are both installed on the same server. We modify the /etc/ibmekm.conf file to include the TCP/IP address and port that are used by the EKM server. See Example 6-25 on page 149.
148
Example 6-25 Modified copy of /etc/ibmekm.conf file
# The Encryption Key Server address:port can be a local loop back # address 127.0.0.1:port if the server is on the same host or a network # address:port if external to the host. Up to 16 server address:port # entries are supported if there are multiple TCP/IP connections to the same # server and/or multiple servers. # server timeout address:port perigee 10 127.0.0.1:3801
The entry in Example 6-25 indicates that the EKM application is installed on the server called perigee and is using port 3801 with a timeout of 10 seconds. If the EKM server is installed on another server, the timeout value must be increased to allow for potential network delay.
Atape device driver configuration

Two new attributes have been added to the TS1120 tape drives for encryption. These attributes are listed in Example 6-26.
Example 6-26 Encryption attributes in the device driver
perigee> lsattr drv_encryption sys_encryption wrt_encryption perigee> lsattr drv_encryption sys_encryption wrt_encryption
-El rmt70| grep encrypt yes Drive Encryption Support False no Use System Encryption FCP Proxy Manager True off System Encryption for Write Commands at BOP True -El rmt71| grep encrypt yes Drive Encryption Support False no Use System Encryption FCP Proxy Manager True off System Encryption for Write Commands at BOP True
The sys_encryption attribute enables device driver SME for a tape drive by setting the value to yes. The wrt_encryption attribute controls whether the device driver sets the tape drive to encryption-enabled for write commands. When set to no, the tape drive uses encryption for read operations, and write operations do not use encryption. When set to yes, the tape drive uses encryption for both read and write operations. When set to custom, the device driver does not modify the current tape drive setting. The custom setting is intended for applications using SME to control write encryption without device driver intervention. To enable SME, the sys_encryption parameter must be set to yes and the wrt_encryption parameter must be set to ON. These tape drive parameters can be modified using SMIT on AIX. Select Change/Show Characteristics of a Tape Drive and enable the parameters Use System Encryption FCP Proxy Manager and System Encryption for Write Commands at BOP. Repeat the process for all of the drives in the logical library. Example 6-27 on page 149 shows the settings for one of the tape drives.
Example 6-27 Encryption attributes that are set for a tape drive
Change / Show Characteristics of a Tape Drive Type or select values in entry fields. Press Enter AFTER making all desired changes.
149
Tape Drive Tape Drive type Tape Drive interface Description Status Location Parent adapter Connection address SCSI ID Logical Unit ID World Wide Port Name World Wide Node Name New Logical Name Enable Alternate Pathing Support Block Size (0=Variable Length) Use DEVICE BUFFERS during writes Use Hardware Compression on Tape Activate volume information logging Maximum size of log file (in # of entries) Backward Space/Forward Space Record Mode Use Immediate Bit in Rewind Commands Trailer Label Processing Use System Encryption FCP Proxy Manager System Encryption for Write Commands at BOP
[Entry Fields] rmt70 3592 fcp IBM 3592 Tape Drive (> Available 11-08-01 fscsi0 88 0xa1a6d 0x0 0x5005076300410833 0x5005076300010833 [] no + [0] +# yes + yes + no + [500] +# SCSI + no + no + yes + on +
Example 6-28 shows that both tape drives, rmt70 and rmt71, now have SME enabled.
Example 6-28 lsattr output
perigee> lsattr drv_encryption sys_encryption wrt_encryption perigee> lsattr drv_encryption sys_encryption wrt_encryption
-El rmt70 | grep encrypt yes Drive Encryption Support False yes Use System Encryption FCP Proxy Manager True on System Encryption for Write Commands at BOP True -El rmt71 | grep encrypt yes Drive Encryption Support False yes Use System Encryption FCP Proxy Manager True on System Encryption for Write Commands at BOP True
Verify Tivoli Storage Manager with SME

We now perform a simple archive test from Tivoli Storage Manager to verify the SME. See Example 6-29 on page 150.
Example 6-29 Archive test from a Tivoli Storage Manager client
tsm> archive -archmc=data /tmp/ekm/SME-backup-test.txt Archive function invoked. Directory--> 512 /tmp/ekm [Sent] Normal File--> 450 /tmp/ekm/SME-backup-test.txt [Sent] ANS1114I Waiting for mount of offline media. Retry # 1 Directory--> 512 /tmp/ekm [Sent]
150
Retry # 1 Normal File--> 450 /tmp/ekm/SME-backup-test.txt [Sent] Archive processing of '/tmp/ekm/SME-backup-test.txt' finished without failure.
Total number of objects inspected: 2 Total number of objects archived: 2 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 964 B Data transfer time: 0.00 sec Network data transfer rate: 117,675.78 KB/sec Aggregate data transfer rate: 0.00 KB/sec Objects compressed by: 0% Elapsed processing time: 00:10:26
Example 6-30 on page 151 shows the server CLI verifying that the files were stored on a tape volume. Note that the Drive Encryption Key Manager field for the volume is set to System, which we expect.
Example 6-30 Tivoli Storage Manager query content and query volume output for tape SJ0011
tsm: PERIGEE>q cont sj0011 Node Name --------------PERIGEE Type ---Arch Filespace Name ---------/tmp FSID ---7 Client's Name for File ----------------------/ekm/ SME-backup-test.txt
tsm: PERIGEE>query volume sj0011 f=d Volume Name: Storage Pool Name: Device Class Name: Estimated Capacity: Scaled Capacity Applied: Pct Util: Volume Status: Access: Pct. Reclaimable Space: Scratch Volume?: In Error State?: Number of Writable Sides: Number of Times Mounted: Write Pass Number: Approx. Date Last Written: Approx. Date Last Read: Date Became Pending: Number of Write Errors: Number of Read Errors: Volume Location: Volume is MVS Lanfree Capable : Last Update by (administrator): SJ0011 LIB2-ENCRYPT_POOL LIB2-ENCRYPT 300,000.0 20 0.0 Filling Read/Write 0.0 Yes No 1 1 1 02/08/07 01:20:00 02/08/07 01:20:00 0 0 No
151
Last Update Date/Time: 02/08/07 Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: System
01:19:40
6.5 EKM server backup and recovery

The EKM server is critical to the operation of a TS1120 encrypted tape drive because the EKM server is accessed every time that an encrypted TS1120 tape is mounted for a read or write operation. We recommend a two server mirrored configuration for high availability; one server acts as the primary EKM server while the other server is a secondary EKM server. Figure 6-19 on page 152 shows a logical diagram of an EKM configuration with two independent servers with identical keystores, drive tables, and configuration files.
Figure 6-19 Two EKM servers with a shared configuration
Details about how to configure the Tape Library Specialist to include a secondary EKM server are in 6.4.3, Device configuration on page 140. Details about how to configure the Atape EKM configuration file, which is used in SME, to include a secondary EKM server are in Updating the Atape EKM proxy configuration file on page 148.
6.5.1 EKM server disaster recovery considerations

In order to recover an EKM server, the drive table, the EKM configuration file (KeyManagerConfig.properties), and the EKM keystore file, for example, GIkeys.jcks, need to be backed up on a regular basis. EKM provides methods to synchronize the configuration. The EKM synchronization process backs up the EKM configuration file and the drive table from the primary EKM server to the secondary EKM server. The EKM synchronization process can be initiated manually or automatically.
Manual synchronization
Example 6-31 shows the command to manually synchronize the primary EKM server configuration files and drive table to the target EKM server through port 443. The SSL_port value must match the value specified for TransportListener.ssl.port in the KeyManagerConfig.properties file of the receiving EKM.
152
Example 6-31 Manual synchronization of configuration files
# sync -all -ipaddr 9.11.124.253:443 Attempting to contact remote server 9.11.124.253:443 Sync completed
Automatic synchronization
To automatically synchronize the drive table and the properties file from the primary EKM server to the secondary EKM server, the following parameters must be defined in the primary EKM server configuration file, as shown in Example 6-32 on page 153: sync.ipaddress: This parameter specifies the IP address and the SSL port of the target EKM server. sync.action: This value is either merge or rewrite. The synchronization of the drive table and the properties file is always a rewrite. sync.timeinhours: This parameter specifies how often synchronization must occur. The default is every 24 hours. sync.type: This parameter specifies the data to send. The drive table, the configuration properties file, or both files can be sent. In our case, both the primary and secondary EKM servers are identical to each other.
Example 6-32 Sample EKM configuration file to automate EKM configuration file synchronization
... sync.ipaddress=9.11.124.253:443 sync.action=rewrite sync.timeinhours=24 sync.type=all ... Important: The above EKM synchronization process only backs up the EKM configuration file KeyManagerConfig.properties and the drive table. The EKM keystore file is not backed up by using this process. The keystore can be copied to the remote location by using utilities, such as secure copy (SCP). We recommend that you back up the keystore to a backup location, such as /usr/ekm/backup. This helps you to avoid overwriting the existing keystore file that is kept open by the EKM process on the remote server.
Other synchronization methods

Other synchronization methods include: Back up the critical EKM files, that is, the drive table, the keystore, and the configuration file, by using another secure mechanism that is independent of TS1120 encryption. Store these in a secure location, for example, a vault. Keep a copy of all of the certificates that are loaded into the keystore. These certificates can be used to rebuild the keystore if required.
6.6 Recommended best practices

Here are our recommended best practices: When using AME with Tivoli Storage Manager, the data keys for each tape are stored in the Tivoli Storage Manager database. If a Tivoli Storage Manager database backup tape is lost or stolen, the data on the encrypted tapes might be compromised. With AME, the
153
Tivoli Storage Manager database backups are not encrypted. A stolen Tivoli Storage Manager database backup tape can result in compromised data on the encrypted tapes. To minimize the risk of compromising the data on the encrypted tapes, we recommend that you keep Tivoli Storage Manager database tapes in a secure environment that is separate from the Tivoli Storage Manager data tapes. See Chapter 11, Providing a secure disaster recovery environment on page 293 for more information. The EKM server (if you use SME or LME) must be operational during the backup and restore processes from encrypted tape drives. It is important to have multiple EKM servers for redundancy. The Tape Library Specialist allows you to configure up to four EKM servers for the library. One EKM server is the primary EKM server while the others are secondary standby EKM servers if the primary EKM server is unavailable. Furthermore, we recommend that data from the primary EKM server is automatically synchronized to the secondary EKM server. The EKM configuration file, KeyManagerConfig.properties, and the drive table file, drivetable, can be updated through the SYNC command within the EKM while the keystore file needs to be manually copied, as we described in 6.5.1, EKM server disaster recovery considerations on page 152. Backing up the EKM server keystore, the configuration file, and the drive table file is very important and must be performed regularly. We recommend that you use another method than backup to Tivoli Storage Manager to back up the EKM server keystore, the configuration file, and the drive table file, for example, tar, copy on CD-ROM, WinZip using encryption, and so forth. From a security perspective, we do not recommend that you start EKM automatically by having the password stored in the EKM configuration file because the password is in clear text. We recommend that you force the prompt for the password each time, which is what we showed in our examples. EKM can also be started as a daemon from within a UNIX shell script as shown in Example 6-33. This, however, poses a risk because the password is in clear text as well. To provide obfuscation of the commands and password that are used within a shell script, you can use shell script compilers, such as SHC, to produced a stripped binary executable. Make sure that you do not forget or lose the EKM keystore password.
Example 6-33 Sample start EKM script with passphrase in clear text
#!/usr/bin/sh java com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties <<EOF startekm passphrase status EOF Note: Losing the keystore password results in the loss of all digital certificates stored within the keystore. There is no recovery process from this situation. You need to periodically change the keystore password based on corporate password policies, for example, every 90 days. Example 6-34 shows how to change this using the keytool utility.
Example 6-34 Keytool utility to change stored password from passphrase to abcd1234
keytool -storepasswd -new abcd1234 -storetype jceks -keystore GIkeys.jcks -storepass passphrase perigee> keytool -list -storetype jceks -keystore GIkeys.jcks -storepass abcd1234 Keystore type: jceks
154
Keystore provider: IBMJCE Your keystore contains 4 entries gicert4, Feb 6, 2007, keyEntry, Certificate fingerprint (MD5): 99:6A:AE:51:70:B9:F4:06:1C:9D:FE:BB:E0:23:CC:71 gicert3, Feb 6, 2007, keyEntry, Certificate fingerprint (MD5): 1F:F5:7C:5A:1E:B3:E6:F5:43:B9:24:FE:C6:B1:59:E2 gicert2, Feb 6, 2007, keyEntry, Certificate fingerprint (MD5): 67:C1:E7:39:FC:2F:C9:B2:DC:A4:0A:97:2E:3E:61:FC gicert1, Feb 5, 2007, keyEntry, Certificate fingerprint (MD5): 77:D4:8F:8C:A5:B4:11:8C:3F:27:2D:55:CE:FF:0C:03 If there are two EKM servers, you need to establish a secure sockets layer (SSL) session between the EKM servers during the synchronization process. See the section Synchronizing data between the two EKM servers in IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0418, for more information. EKM can be configured to allow automatic updates of the tape drive table when a newly added tape drive contacts EKM. This is enabled through the drive.acceptUnknownDrives parameter in the configuration file. To eliminate the possibility of putting encrypted data on an unauthorized tape drive, we recommend that you set this parameter to false or omit this parameter from the configuration file altogether. It is important to understand that the encryption capabilities of the TS1120 drives relate to the tape media. Encryption prevents anyone who steals or removes media from the library from accessing the data. Equally important is the need to have the appropriate storage area network (SAN) zoning or other security techniques to ensure that only designated hosts are able to access the TS1120 tape drives through a SAN. Without correct SAN security, particularly with LME or SME, any host that can see the library and drives can install the device driver and use utilities, such as tapeutil, to access the data.
6.7 References
References for this chapter include: IBM Encryption Key Manager - Introduction, Planning and Users Guide, GA76-0418 IBM Tape Device Drivers - Encryption Support, GA32-0565 IBM System Storage TS1120 Tape Encryption Planning, Implementation, and Usage Guide, SG24-7320 IBM System Storage TS1120 Tape Drive and Controller Operator Guide 3592 Models J1A, E05, J70 and C06, GA32-0556 IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560-01 IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0418 Keytool User Guide for SDK 1.4.2, available at: http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDo cs/KeyToolUserGuide-142.html
155
156
Part 3
Part
Tivoli Storage Manager server considerations

In this part, we describe aspects of security that are related to the Tivoli Storage Manager server. This part includes the following topics: Options and recommendations for administering the server Server storage pools, their vulnerabilities, and how to prevent them Deploying the server in a secure network environment Considerations for protecting the server environment
157
158
Chapter 7.
Server administration
This chapter of the book discusses the security aspects of Tivoli Storage Manager administration. This chapter includes: Server administrator roles Best practices for pursuing a policy of least privilege Password handling and policies Maintaining an audit trail for your server Session and process control Security and server-to-server communication Security implications of using Operational Reporting Securing the Integrated Solutions Console (ISC)
159
7.1 Security concerns for the Tivoli Storage Manager server

In the computing world, one of the basic tenets of data security is the principle of least privilege, sometimes also referred to as the principle of least authority . The idea behind this concept is that a person or a piece of code has only enough privileges to perform the tasks that are required, and no more. In the event that someone or something attempts to perform a destructive or damaging action, either accidentally or intentionally, the damage is either eliminated or minimized. Controlling access to the Tivoli Storage Manager server is an important security concern, because usually the Tivoli Storage Manager server necessarily has access into many systems in a particular environment. This chapter addresses methods for managing and securing Tivoli Storage Manager server access.
7.2 Overview of Tivoli Storage Manager administrator roles

When a new administrator ID is registered, it has few capabilities. In order to perform useful work, additional authority must be given to it by another administrator with sufficient authority to grant additional authority. Assigning additional capability to an administrator ID is performed with the GRANT AUTHORITY command. In order to begin implementing a policy of least privilege in Tivoli Storage Manager, we need to first understand the available administrative roles and their capabilities. This information is described in detail in the Tivoli Storage Manager Administrators Guide for each server operating system platform, but we summarize the information here for convenience. You can see the current privilege class associated with a specific administrator ID by issuing the QUERY ADMIN command with the optional FORMAT=DETAILED flag.
7.2.1 No authority granted

When an administrator is first registered, but has not been granted any authority, it has few capabilities. The administrator can perform these commands: QUERY HELP QUIT SELECT (if the server option QUERYAUTH has not been set yet) Of these commands, the most powerful is SELECT. Potentially, even an unprivileged administrator can either extract limited information about the Tivoli Storage Manager configuration using this command or execute a denial of service attack by executing large queries. For this reason, we recommend that you set the QUERYAUTH option to a suitable level for server protection (refer to QUERYAUTH on page 170).
7.2.2 System
System authority on a Tivoli Storage Manager server is the highest privilege class available. It is analogous to having root authority on a UNIX server or domain administrator on a Windows server.
160
An administrator with system authority: Has system-wide responsibilities Manages the enterprise Tivoli Storage Manager environment Manages Tivoli Storage Manager security, including managing the authority of other Tivoli Storage Manager administrators Example 7-1 shows an ID with system privilege.
Example 7-1 Admin ID with system privilege
tsm: SERVER1>q admin admin f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address: ADMIN 01/29/2007 09:05:31 <1 01/26/2007 14:20:18 3 0 No Yes ** Included with system ** Included with system ** Included with system ** Included with system ** Included with system ** Included with system 01/26/2007 14:20:18 SERVER_CONSOLE
privilege privilege privilege privilege privilege privilege
** ** ** ** ** **
7.2.3 Policy
With policy privilege, an administrator can modify existing policies as well as any policies that are created in the future but cannot create new policy domains. Policy privilege can be either unrestricted (all domains) or restricted by domain. This privilege affects anything associated with a policy domain, including client schedules. Valid commands for administrators with policy authority are shown in the Tivoli Storage Manager Administrators Reference for your server platform in the chapter Using Commands Based on Privilege Class.
Unrestricted
Unrestricted policy privilege allows modification of all existing and future policy information and is granted by either not specifying a domain list or using a blank domain list with the GRANT AUTHORITY command, as shown in Example 7-2 on page 162.
Chapter 7. Server administration
161
Example 7-2 Unrestricted policy privilege
tsm: SERVER1>grant authority policyadmin class=policy ANR2077I Unrestricted policy privilege granted to administrator POLICYADMIN. tsm: SERVER1>q admin policyadmin f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address: POLICYADMIN 01/29/2007 09:27:24 <1 01/29/2007 09:27:24 <1 0 No
** Unrestricted **
01/29/2007 09:27:24 ADMIN
Restricted
Administrators with restricted policy privilege are allowed to modify only those domains that have been specified by the granting administrator. The restriction is placed by using the DOMAIN statement when granting the policy privilege, as shown in Example 7-3.
Example 7-3 Restricted policy privilege
tsm: SERVER1>grant authority policyadmin class=policy domain=newdomain ANR2078I Restricted policy privilege granted to administrator POLICYADMIN - policy domain NEWDOMAIN. tsm: SERVER1>q admin policyadmin f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: POLICYADMIN 01/29/2007 09:27:24 <1 01/29/2007 09:27:24 <1 0 No
NEWDOMAIN
01/29/2007 09:27:24
162
Registering Administrator: ADMIN Managing profile: Password Expiration Period: Email Address:
Note that while the ID policyadmin has the authority to make changes to the domain newdomain, this ID cannot create new domains or delete existing domains, as shown in Example 7-4.
Example 7-4 Limitations with restricted policy privilege
Enter your user id: Enter your password:
policyadmin *****
Session established with server SERVER1: Linux/i386 Server Version 5, Release 4, Level 0.0 Server date/time: 01/29/2007 09:34:04 Last access: 01/29/2007 09:27:24 tsm: SERVER1>delete domain newdomain ANR2035E DELETE DOMAIN: Administrator POLICYADMIN is not authorized to issue this command. ANS8001I Return code 9. tsm: SERVER1>copy domain standard testdomain ANR2035E COPY DOMAIN: Administrator POLICYADMIN is not authorized to issue this command. ANS8001I Return code 9. tsm: SERVER1>define domain testdomain ANR2035E DELETE DOMAIN: Administrator POLICYADMIN is not authorized to issue this command. ANS8001I Return code 9.
7.2.4 Storage
Storage privilege deals with the management of storage on the Tivoli Storage Manager server. This privilege includes management of all current and future storage pools (unless restricted) but does not include the ability to add or delete storage pools. Valid commands for administrators with storage privilege are shown in the Tivoli Storage Manager Administrators Reference for your server platform, in the chapter Using Commands Based on Privilege Class.
Unrestricted
An administrator with unrestricted storage privilege can manage all elements of the storage belonging to a Tivoli Storage Manager server, including storage pools, volumes, database and log volumes, libraries, drives, and paths. This privilege is granted by specifying a class of storage, without a specific storage pool, as shown in Example 7-5 on page 164.
163
Example 7-5 ID with unrestricted storage privilege
tsm: SERVER1>grant authority storageadmin class=storage ANR2079I Unrestricted storage privilege granted to administrator STORAGEADMIN. tsm: SERVER1>q admin storageadmin f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address: STORAGEADMIN 01/29/2007 09:45:12 <1 01/29/2007 09:45:12 <1 0 No
** Unrestricted **
01/29/2007 09:45:12 ADMIN
Restricted
An administrator with restricted storage privilege can manage only the specific storage pools that have been assigned to that individual administrator. This restricted storage privilege also prevents management of any storage that is not in the assigned pools, such as the database and log, and any physical devices, such as tape libraries and tape drives. Restricted storage privilege is granted by using the storage pools argument with the GRANT AUTHORITY command, as shown in Example 7-6 on page 165.
164
Example 7-6 ID with restricted storage privilege
tsm: SERVER1>grant authority storageadmin class=storage stgpool=backuppool ANR2080I Restricted storage privilege granted to administrator STORAGEADMIN storage pool BACKUPPOOL. tsm: SERVER1>q admin storageadmin f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address: STORAGEADMIN 01/29/2007 09:45:12 <1 01/29/2007 09:45:12 <1 0 No
BACKUPPOOL
01/29/2007 09:45:12 ADMIN
Server operations for the restricted storage administrator are limited to the storage pool for which access is defined, as shown in Example 7-7.
Example 7-7 Limitations with restricted storage privilege
Enter your user id: Enter your password:
storageadmin *****
Session established with server SERVER1: Linux/i386 Server Version 5, Release 4, Level 0.0 Server date/time: 01/29/2007 09:53:56 Last access: 01/29/2007 09:45:12 tsm: SERVER1>update stgpool archivepool migprocess=2 ANR2035E UPDATE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command. ANS8001I Return code 9. tsm: SERVER1>define stgpool disk testpool ANR2035E DEFINE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command. ANS8001I Return code 9. tsm: SERVER1>delete stgpool archivepool ANR2035E DELETE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command. ANS8001I Return code 9.
165
7.2.5 Operator
Operator authorization provides the ability to issue commands that control the immediate
operation of the server and the availability of media but blocks any command that can impact data retention or client operations. For example, an administrator with operator authorization can enable or disable sessions globally, cancel individual sessions, reply to requests, and move media (as well as halt the server) but cannot update storage pools or policy information. Operator privilege is granted with the GRANT AUTHORITY command, as shown in Example 7-8.
Example 7-8 ID with operator privilege
tsm: SERVER1>grant authority operator class=operator ANR2082I Operator privilege granted to administrator OPERATOR tsm: SERVER1>q admin operator f=d Session established with server SERVER1: Linux/i386 Server Version 5, Release 4, Level 0.0 Server date/time: 01/29/2007 10:15:37 Last access: 01/29/2007 09:43:35
Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address:
OPERATOR 01/29/2007 09:58:42 <1 01/29/2007 09:58:42 <1 0 No
Yes
01/29/2007 09:58:42 ADMIN
An administrator with operator privilege can only perform the commands that are shown in 7.2.5, Operator on page 166. These commands are in addition to the commands that are available by default to all administrators, which are shown in 7.2.1, No authority granted on page 160. Note that while an operator-privileged ID can issue MOVE MEDIA and MOVE DRMEDIA commands, it cannot control any storage devices. Therefore, an operator cannot issue the CHECKOUT LIBVOLUME, CHECKIN LIBVOLUME, or LABEL LIBVOLUME commands. The commands that are available to an ID with operator privilege are: CANCEL SESSION ENABLE SESSIONS 166
MOVE DRMEDIA QUERY MEDIA UPDATE VOLUME VARY DISABLE SESSIONS DISMOUNT VOLUME MOVE MEDIA REPLY HALT
7.2.6 Analyst
Analyst authorization is typically the administrator ID with the least privilege on the server. An analyst ID can only reset statistics on the server and issue queries. The analyst ID is not permitted to use define, register, update, or delete commands. Commands that can be successfully issued by an analyst ID are: RESET BUFPOOL RESET DBMAXUTILIZATION RESET LOGCONSUMPTION RESET LOGMAXUTILIZATION QUERY SELECT This is in addition to the commands that are available by default to all administrators shown in 7.2.1, No authority granted on page 160.
7.2.7 Node
Node privilege is given to the administrator ID that is created by default when a node is first registered. This ID has the same name as the node and is granted client owner authority automatically. The creation of the node ID can be suppressed, or the administrator can still be created with a different ID if preferred by using the REGISTER NODENAME command.
Client owner
An administrator ID with client owner privileges for a node: An administrator ID with client owner privileges can access the client through the Web backup/archive client or native backup/archive client. An administrator ID with client owner privileges owns the data and has a right to physically access the data remotely. This ID can backup and restore files on the same or a different machine, delete file spaces, or archive data. The user ID with client owner authority can also access the data from another machine using the NODENAME parameter. An administrator ID with client owner privileges can change the client nodes password for which it has authority. This is the default authority level for the client at registration. An administrator with system or policy privileges to a clients domain has client owner privilege by default.
Client access
Client access privilege restricts somewhat the capabilities provided with the standard client owner privileges:
167
An ID with client access privilege can only access the client through the Web backup/archive client. An ID with client access privilege can restore data only to the original client. A user ID with client access authority cannot access the client from another machine using the NODENAME parameter. The client data can only be restored to the original client. A user ID with client access privilege cannot directly access a clients data from a native backup/archive client. This privilege is useful for help desk personnel so that they can assist users in backing up or restoring data without requiring system or policy privileges. If the administrator ID for a node does not have either of the node privileges defined, the Web client receives the error message shown in Figure 7-1 when the Web client attempts to access the server.
Figure 7-1 Web client error from missing node authorities
If the node administrator is locked, the Web client receives a different error message, as shown in Figure 7-2.
Figure 7-2 Web client error with locked administrator ID
7.2.8 Administrator IDs

In order to keep track of the activities of an individual administrator, we recommend that you create unique IDs for each person accessing the Tivoli Storage Manager server directly. Over time in any organization, there are personnel changes and sometimes a Tivoli Storage Manager administrator leaves. On those occasions, you need to eliminate access for that administrator.
168
For situations where the administrator plans to return after a certain period of time, you can lock an ID using the LOCK ADMINISTRATOR command. If an administrator is not expected to return, remove the ID from the system using the REMOVE ADMIN command.
7.2.9 Special administrator IDs

There are two special administrators that are defined on the Tivoli Storage Manager server at installation, SERVER_CONSOLE and, on V5.3 and above, ADMIN_CENTER. Additionally, the administrator ADMIN is created automatically on Windows and AIX platforms. The administrator ADMIN is not created automatically on the Linux platform. On those platforms where the ADMIN administrator ID is created at installation, it has system-level authority. This section describes these IDs and their functions.
SERVER_CONSOLE
This ID is installed when the Tivoli Storage Manager server is installed and is a special ID that cannot be removed, locked, updated, or renamed. Essentially, the SERVER_CONSOLE ID is a reserved ID. There is no preset password for this ID, and a password cannot be assigned to it. The administrative client cannot use this ID to connect unless authentication is turned off, in which case, the administrative client bypasses all system security. The SERVER_CONSOLE ID has system-level authority over the Tivoli Storage Manager server. Normally, this ID is only used if the Tivoli Storage Manager server is started manually by executing the Tivoli Storage Manager server executable (dsmserv).
ADMIN_CENTER
The ADMIN_CENTER ID is new with Tivoli Storage Manager V5.3 and is a special ID used by the Tivoli Storage Manager Integrated Services Console/Administration Center (ISC/AC). See 7.14, Integrated Solutions Console security on page 202 for more information. Immediately after installation, the ADMIN_CENTER ID has the characteristics that are shown in Example 7-9 on page 170.
169
Example 7-9 ADMIN_CENTER ID details
Tivoli Storage Manager: SERVER1>q admin admin_center f=d Administrator Name: Last Access Date/Time: Days Since Last Access: Password Set Date/Time: Days Since Password Set: Invalid Sign-on Count: Locked?: Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: Registering Administrator: Managing profile: Password Expiration Period: Email Address: ADMIN_CENTER 01/26/2007 14:02:57 3 (?) (?) 0 Yes Administration Center
01/26/2007 14:02:57 SERVER_CONSOLE
Note that the ID is locked and has no privileges at installation time. The ISC/AC prompts the user to unlock the ID when a new server connection is defined.
7.2.10 Server options related to administrative privilege

This section describes two server options (in dsmserv.opt) that affect administrative privilege.
QUERYAUTH
The QUERYAUTH server option sets the minimum level of administrative privilege necessary to issue QUERY and SELECT statements to the Tivoli Storage Manager server. By default, any administrator ID can issue QUERY and SELECT commands; however using this option, you can restrict the ability to issue these commands to administrators with the specified privilege. Valid values are NONE (default), SYSTEM, POLICY, STORAGE, OPERATOR, or ANALYST. Regardless of the value of this setting, an administrator with SYSTEM privilege can always issue these commands. Restricting this access prevents unauthorized administrators from displaying the server configuration.
REQSYSAUTHOUTFILE
The REQSYSAUTHOUTFILE server option determines whether system administrative privilege is required to write to a system file on the Tivoli Storage Manager server host from the Tivoli Storage Manager server. Note: If the administrative client is installed on the Tivoli Storage Manager server, the output from that client can be redirected to the host operating system, which causes a write to the Tivoli Storage Manager server host. The operating system file permissions determine whether this write is successful.
170
Commands that are affected by this option are: MOVE MEDIA: If the CMD parameter is NOT specified: Operator or system privilege. If the CMD parameter is specified and the REQSYSAUTHOUTFILE server option is set to NO: Operator, unrestricted storage, or system privilege. If the CMD parameter is specified and the REQSYSAUTHOUTFILE server option is set to YES (the default): System privilege. QUERY MEDIA with CMD parameter Any administrator with system or operator privilege can issue these commands unless the CMD parameter is used: If the CMD parameter is specified and the REQSYSAUTHOUTFILE server option is set to NO, the administrator must have operator, unrestricted storage, or system privilege. If the CMD parameter is specified and the REQSYSAUTHOUTFILE server option is set to YES (the default), the administrator must have system privilege. BACKUP VOLHISTORY with FILENAMES parameter Any administrator can issue this command unless it includes the FILENAMES parameter: If the FILENAMES parameter is specified and the REQSYSAUTHOUTFILE server option is set to YES, the administrator must have system privilege. If the FILENAMES parameter is specified and the REQSYSAUTHOUTFILE server option is set to NO, the administrator must have operator, policy, storage, or system privilege. BACKUP DEVCONFIG with FILENAMES parameter Any administrator can issue this command unless it includes the FILENAMES parameter: If the FILENAMES parameter is specified and the REQSYSAUTHOUTFILE server option is set to YES, the administrator must have system privilege. If the FILENAMES parameter is specified and the REQSYSAUTHOUTFILE server option is set to NO, the administrator must have operator, policy, storage, or system privilege. TRACE BEGIN with a file name specified: If the file name is specified and the REQSYSAUTHOUTFILE server option is set to YES, the administrator must have system privilege. If the file name is specified and the REQSYSAUTHOUTFILE server option is set to NO, any administrator, including those administrators with client privileges, can issue this command and start tracing. QUERY SCRIPT with OUTPUTFILE parameter Any administrator can issue this command unless it includes the OUTPUTFILE parameter: If the OUTPUTFILE parameter is specified and the REQSYSAUTHOUTFILE server option is set to YES, the administrator must have system privilege. If the OUTPUTFILE parameter is specified and the REQSYSAUTHOUTFILE server option is set to NO, the administrator must have operator, policy, storage, or system privilege.
171
7.3 A typical implementation of administrator roles

This section shows how administrator roles might be assigned in a typical mid-sized implementation.
Scenario
The ITSO Electronics Company is a medium-sized business with a single Tivoli Storage Manager server. The ITSO Electronics Company runs two shifts and has an operator for each shift, a manager, who acts as an operations supervisor, and two individuals, who are the Tivoli Storage Manager administrators.
Operators
The operators are responsible for daily tape rotation and general monitoring of the Tivoli Storage Manager server. Accordingly, they are each given a unique Tivoli Storage Manager ID and granted operator privileges. This allows them to issue the commands that are listed in 7.2.5, Operator on page 166. These commands only allow actions that affect storage at a high level; they cannot affect the retention of data, the deletion of data, or the control of specific devices. In particular, the operators cannot perform the check in or check out of a volume in a tape library, nor can they label tapes.
Operations supervisor
The ITSO Electronics Company has chosen to give the operations supervisor a unique Tivoli Storage Manager administrator ID with unrestricted storage authority, as well as operator authority. Accordingly, the operations supervisor can issue all operator commands, as well as label tapes, check media in or check media out, and affect devices and storage pools. The ITSO Electronics Company intends for the operations supervisor to provide next level support for the operators.
DBAs with responsibility for the backups of their database products

The ITSO Electronics Company has given the DBAs unique administrator IDs with client owner authority over the client nodes for which they are responsible. This authority allows the DBAs to back up and restore both locally and by using the Web interface, as well as to perform cross-node restores. The ITSO Electronics Companys Tivoli Storage Manager administrator has also split the storage pools so that the data from the database application is stored in each DBAs own storage pool. Accordingly, the DBAs have also been granted restricted storage privilege over their individual storage pool, which allows the DBAs to change its characteristics.
Tivoli Storage Manager administrators

The Tivoli Storage Manager administrators have each been given unique administrator IDs with system privilege. This allows them to perform all administrative tasks on the Tivoli Storage Manager server but shows in the activity log which admin performed a particular action.
7.4 Maintaining an audit trail

Part of maintaining a good security model is keeping a log of the actions that were performed by the individuals working on the system. This section discusses various ways to track activity on the Tivoli Storage Manager server.
172
7.4.1 Activity log

The Tivoli Storage Manager server automatically keeps a record of all of the server activity in the activity log. The number of days that the records are retained is determined by the SET ACTLOGRETENTION command. This is likely the easiest method for tracking server activity but keeping an excessive number of activity log records can increase the size of the database. In addition to managing the size of the activity log by adjusting the number of days retained, the SET ACTLOGRETENTION command allows you to specify that the log must be pruned after it reaches a specified size, rather than a particular number of days. If you need to keep a record of server activity for a longer period in order to satisfy auditing or regulatory requirements, you can periodically issue queries against the ACTLOG table and redirect the output to an external file, which can be archived elsewhere to create a long-term permanent record. A simple method to query the ACTLOG table is to issue QUERY ACTLOG commands and redirect the output to a text file. Another possible method is to issue SQL SELECT statements using the Tivoli Storage Manager SQL interface. You can issue SQL SELECT statements by directly issuing SQL from a script or using the ODBC interface to import directly into an external application (Microsoft Excel or Access, for example). The ACTLOG table contains the fields that are shown in Figure 7-3. COLNAME -----------------DATE_TIME MSGNO SEVERITY MESSAGE ORIGINATOR NODENAME OWNERNAME SCHEDNAME DOMAINNAME SESSID SERVERNAME SESSION PROCESS REMARKS -----------------Date/Time Message number Message severity Message Originator Node Name Owner Name Schedule Name Policy Domain Name Sess Number Server Name SESSION PROCESS TYPENAME -----------------TIMESTAMP INTEGER ENUMERATED(SEVERITY_TYPE) VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR INTEGER VARCHAR INTEGER INTEGER LENGTH ----------0 0 1 1600 20 64 64 30 30 0 64 0 0
Figure 7-3 Server ACTLOG table columns and descriptions
For example, you can save the query in Example 7-10 on page 174 as a script, execute it periodically, and redirect the output to an external file. Executing this script requires an administrator ID with adequate privileges if QUERYAUTH is set on the server. Refer to QUERYAUTH on page 170 for more information about this option.
173
Example 7-10 Tivoli Storage Manager SQL query for activity log records
set sqldisplaymode wide select date(date_time) as "Date", time(date_time) as "Time", originator as "Originator", servername as "Server", nodename as "Node", domainname as "Domain", schedname as "Schedule", session as "Session", process as "Process", Severity as "Severity", message as "Message" from actlog where date_time>current_timestamp-$1 day order by 1,2 A sample script execution and the output are shown in Example 7-11.
Example 7-11 Activity log query execution and output
tsm: SERVER1>run showme_actlog 2 Date: 2007-02-06 Time: 09:23:26 Originator: SERVER Server: Node: Domain: Schedule: Session: 1 Process: Severity: I Message: ANR2017I Administrator ADOPS issued command: DELETE VOLUME /stg1/TSM/bkup0.dsm discarddata=yes (SESSION: 1) This is only an example of the types of methods available; this approach can be customized to meet the requirements of a specific organization.
7.4.2 Server summary table

The server summary table keeps track of all server processing and nonadministrative session activity. Accordingly, the server summary table is a good resource for auditing general client and server operations, but it does not show the commands that are issued by an administrator. The server summary table is populated automatically and pruning is automatic as well. The length of time that data is kept in this table is controlled by the SET SUMMARYRETENTION command. The default is 30 days. Using a setting of 0 prevents records from being written to the server summary table. To display the current setting, use the QUERY STATUS command.
174
The fields within the summary table are shown in Figure 7-4. COLNAME -----------------START_TIME END_TIME ACTIVITY NUMBER ENTITY REMARKS -----------------Start time End Time Process or Session Activity Name Process or Session Number Associated user or storage pool(s) associated with the activity Communications Method Used Communications Address Schedule Name Number of objects (files and/or directories) examined by the process/session Number of objects affected (moved, copied or deleted) by the process/session Number of objects that failed in the process/session Bytes processed Seconds that the session/process was idle Seconds that the session/process was waiting for access to media Number of processes used for process Successful ? Volume Name Drive Name Library Name Last Use Current comm wait time in seconds Number of offsite volumes processed TYPENAME -----------------TIMESTAMP TIMESTAMP VARCHAR INTEGER VARCHAR LENGTH ----------0 0 64 0 64
COMMMETH ADDRESS SCHEDULE_NAME EXAMINED
VARCHAR VARCHAR VARCHAR DECIMAL
8 64 30 18
AFFECTED
DECIMAL
18
FAILED
DECIMAL
18
BYTES IDLE
DECIMAL INTEGER
18 0
MEDIAW
INTEGER
PROCESSES
INTEGER
SUCCESSFUL VOLUME_NAME DRIVE_NAME LIBRARY_NAME LAST_USE COMM_WAIT NUM_OFFSITE_VOLS
ENUMERATED(YESNO_TYPE) VARCHAR VARCHAR VARCHAR VARCHAR INTEGER INTEGER
9 64 64 64 64 0 0
Figure 7-4 Server summary table fields
175
As with the ACTLOG table, SQL queries can be constructed against the server summary table and the output can be redirected to an external text file on a periodic basis.
7.4.3 Accounting records

The command SET ACCOUNTING ON enables the Tivoli Storage Manager server to write accounting records continuously to a file called dsmaccnt.log. This file is created in the current directory when the server is started, but non-default locations can be specified by setting the DSMSERV_ACCOUNTING_DIR environment variable before the server start-up. Use the QUERY STATUS command to determine whether accounting is currently enabled. In the same way that the summary table works, accounting does not track administrative commands that have been issued against the Tivoli Storage Manager server, just client activities and server processes. The resulting file is in comma separated variable (CSV) format. A sample record is shown in Example 7-12.
Example 7-12 Sample record from dsmaccnt.log
5,0,ADSM,02/07/2007,11:16:38,NENYA,,Linux86,1,Tcp/Ip,1,0,0,0,0,321,510901,0,0,5110 70,130,1,94,0,4,0,0,0,0,4,0 The content of each field is explained in the Tivoli Storage Manager Administrators Guide for each server operating system platform and is reproduced in Example 7-13 for your convenience.
Example 7-13 Format of accounting records
Field 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Contents Product version Product sublevel Product name, ADSM, Date of accounting (mm/dd/yyyy) Time of accounting (hh:mm:ss) Node name of Tivoli Storage Manager client Client owner name (UNIX) Client Platform Authentication method used Communication method used for the session Normal server termination indicator (Normal=X'01', Abnormal=X'00') Number of archive store transactions requested during the session Amount of archived files, in kilobytes, sent by the client to the server Number of archive retrieve transactions requested during the session Amount of space, in kilobytes, retrieved by archived objects Number of backup store transactions requested during the session Amount of backup files, in kilobytes, sent by the client to the server Number of backup retrieve transactions requested during the session Amount of space, in kilobytes, retrieved by backed up objects Amount of data, in kilobytes, communicated between the client node and the server during the session Duration of the session, in seconds Amount of idle wait time during the session, in seconds Amount of communications wait time during the session, in seconds Amount of media wait time during the session, in seconds
176
25 26 27 28 29 30 31
Client session type. A value of 1 or 4 indicates a general client session. A value of 5 indicates a client session that is running a schedule. Number of space-managed store transactions requested during the session Amount of space-managed data, in kilobytes, sent by the client to the server Number of space-managed retrieve transactions requested during the session Amount of space, in kilobytes, retrieved by space-managed objects Product release Product level
Typically, these records are gathered for a period of time and then imported into a spreadsheet for analysis.
7.4.4 Event receivers

Tivoli Storage Manager can log information to different targets called event receivers. An event receiver is simply a location to which Tivoli Storage Manager sends events that match parameters that have been defined by the Tivoli Storage Manager administrator. Valid event receivers are: Server console (CONSOLE) Activity log (ACTLOG) Event Server File FileText SNMP Tivoli UserExit NTEventLog (Windows only) Note: Setting up or modifying event receivers requires Tivoli Storage Manager system authority. The event receivers CONSOLE and ACTLOG have all of the events enabled by default. The CONSOLE receiver can be disabled or have its rules modified; the ACTLOG receiver cannot. The ACTLOG receiver has all server events logged to it, which cannot be altered or disabled. Accordingly, the ACTLOG is the most complete method of recording activity on the server. An event server is another Tivoli Storage Manager server that is configured to receive event information from a remote server. This communication is established by enabling server-to-server communication between the Tivoli Storage Manager servers and defining the receiving server as an event server. The FILE event receiver records events into a user-specified binary file. The data is stored as a data block that includes binary information, which is shown in Example 7-14.
177
Example 7-14 Binary file exit data block structure
typedef struct { int32 eventNum; /* the event number. */ int16 sevCode; /* event severity. */ int16 applType; /* application type (hsm, api, etc) */ int32 sessId; /* session number */ int32 version; /* Version number of this structure (2) */ int32 eventType; /* event type */ * (ADSM_CLIENT_EVENT, ADSM_SERVER_EVENT) */ DateTime timeStamp; /* timestamp for event data. */ uchar serverName[MAX_SERVERNAME_LENGTH+1]; /* server name */ uchar nodeName[MAX_NODE_LENGTH+1]; /* Node name for session */ uchar commMethod[MAX_COMMNAME_LENGTH+1]; /* communication method */ uchar ownerName[MAX_OWNER_LENGTH+1]; /* owner */ uchar hlAddress[MAX_HL_ADDRESS+1]; /* high-level address */ uchar llAddress[MAX_LL_ADDRESS+1]; /* low-level address */ uchar schedName[MAX_SCHED_LENGTH+1]; /* schedule name if applicable */ uchar domainName[MAX_DOMAIN_LENGTH+1]; /* domain name for node */ uchar event[MAX_MSGTEXT_LENGTH]; /* event text */ int16 reserved1; /* reserved field 1 */ int16 reserved2; /* reserved field 2 */ uchar reserved3[1400]; /* reserved field 3 */ } eventInfo; The SNMP event receiver requires that you modify the dsmserv.opt file to point to a system where the Tivoli Storage Manager SNMP subagent (dsmsnmp) is running. The subagent then connects to a DPI-enabled SNMP agent (currently supported on AIX only) for data transport. When enabled, Tivoli Storage Manager writes events to the receiver. A network monitoring tool can then be used to monitor Tivoli Storage Manager using this method. A UserExit allows a user-written program to process events as they are sent from the server. Sample code is bundled with the Tivoli Storage Manager server and is available in the server directory.
Using a text file exit event receiver on UNIX or Linux

In some cases, you might want to keep a running log of the commands that administrators run on the server. One method to track these commands is to set up a FILETEXTEXIT event receiver. This event receiver writes plain text records, which match events that have been specified by the administrator, to a specified file. You can review this file at a later time. The steps to set up using a text file exit event receiver are: 1. Edit the Tivoli Storage Manager server options file (dsmserv.opt). Uncomment or insert the FILETEXTEXIT option. The format of the option is: FILETEXTEXIT [YES | NO] <filename> [APPEND | REPLACE | PRESERVE] The option parameters are: [YES | NO]: Inform server to ACTIVATE the text file exit receiver during start-up. This is analogous to issuing the BEGIN EVENTLOGGING FILETEXT command on the server console. <filename>: The name of the file where you save generated events. If the filename does not begin with a forward slash character (/) or period (.), the DSMSERV_DIR environment variable is prepended to the filename. 178
APPEND: Append event information to the specified file. If the file did not exist, create it. If the file already exists, there is no check performed on the file to ensure that the data that already exists on the file is Tivoli Storage Manager event records. REPLACE: If the file already exists, replace the contents with new event records. All current data is destroyed before the first event record is written. If the file did not exist previously, create it. PRESERVE: If the file already exists, do not overwrite or append it. An example is: FILETEXTEXIT YES /tmp/tsmadmincommands.txt REPLACE This example starts logging to the event receiver at the server start-up, writes to the file /tmp/tsmadmincommands.txt, and overwrites the file each time that logging is restarted, such as a Tivoli Storage Manager server restart. 2. When logged in as an administrator with system authority, issue from the administrative command: ENABLE EVENTS FILETEXT ANR2017 3. Start event logging for the filetext receiver: BEGIN EVENTLOGGING FILETEXT At this point, all administrator commands are logged to the specified file. Each line added to the file is very long, 2,500 characters, so periodic pruning is necessary. The format of each line is shown in Figure 7-5.
Figure 7-5 Format of data that is written using filetextexit
In order to get shorter, easier to read lines, you might prefer to trim the unneeded portions of each line. On UNIX or Linux, a simple method to do this is to run something, such as the following command on a regular, perhaps daily, basis (note that this is a single command continued across lines): cut -b 33-47,443-550 /tmp/filetextexit.out >>\
179
/tmp/tsmadmincommands_$(date +"%m%d%g_%H%M%S").txt This creates a file called /tmp/tsmadmincommands_<date>_<time>.txt in which <date> and <time> represent the time that the file was created. Example 7-15 on page 180 shows a sample of the data contained in the file.
Example 7-15 Sample command log contents
20070208093937 20070208093937 20070208094019 20070208094027 20070208094030 20070208094030
ADMIN ADMIN ADMIN ADMIN ADMIN ADMIN
issued issued issued issued issued issued
command: command: command: command: command: command:
QUERY PROCESS ~ ROLLBACK ~ QUERY VOLUME ~ DELETE VOLUME /stg1/TSM/bkup0.dsm ~ DELETE VOLUME /stg1/TSM/bkup0.dsm ~ ROLLBACK ~
Using the NT Event Log event receiver on Windows

In addition to the event receivers that are available on other platforms, the Windows Tivoli Storage Manager server also has the ability to write to the Windows event viewer using the NTEVENTLOG receiver. The NTEVENTLOG receiver is enabled at installation, so it is not necessary to edit the dsmserv.opt file. Tivoli Storage Manager events are written to the Application log. By default, a large number of events are enabled at installation. If the server is extremely active, we recommend that you limit which Tivoli Storage Manager events are logged. For our purposes, we want to only record commands that were executed by Tivoli Storage Manager administrators. The steps are: 1. To view the events that are currently enabled to be written in the event log, issue the command QUERY ENABLED NTEVENTLOG. A portion of the output is shown: ANR1096, ANR1097, ANR1098, ANR1099, ANR1103, ANR1104, ANR1107, ANR1110, ANR1111, ANR1113, ANR1114, ANR1121, ANR1122, ANR1123, ANR1124, ANR1125, ANR1126, ANR1127, ANR1128, ANR1129, ANR1130, ANR1131, ANR1132, ANR1133, ANR1134, ANR1135, ANR1165, ANR1166, ANR1167, ANR1170, ANR1172, There are a large number of events that are enabled by default. 2. Stop event logging to the NTEVENTLOG receiver by using - DISABLE EVENTS NTEVENTLOG ALL. 3. Change the events, which are logged to the NTEVENTLOG receiver, to only include administrator-issued commands by using - ENABLE EVENTS NTEVENTLOG ANR2017. 4. Restart the event logging for the NTEVENTLOG receiver by using - BEGIN EVENTLOGGING NTEVENTLOGGING. From this point, any administrative commands issued on the Tivoli Storage Manager server are logged into the Windows application event log as well. An example of a logged event is shown in Figure 7-6 on page 181.
180
Figure 7-6 Administrative command logged to application event log
Note that while we have limited the logged events for the Windows event log, the other active receivers (the activity log and console) continue to receive all events, as shown in Example 7-16.
Example 7-16 The other active receivers, the CONSOLE and the ACTLOG
tsm: TSM01>q enabled console All server events are ENABLED for the CONSOLE receiver. tsm: TSM01>q enabled actlog All server events are ENABLED for the ACTLOG receiver.
7.5 Controlling access to the server

This section discusses security and system control from a Tivoli Storage Manager server perspective. This section includes commands and options that control when access can be gained. This section also includes setting the requirements that must be satisfied for access.
7.5.1 Commands and options affecting the entire server

The options and commands that we discuss here are system-wide and do not affect a particular client. All commands in this section are covered in each platforms Tivoli Storage Manager Administrators Guide and Tivoli Storage Manager Administrators Reference.
181
SET AUTHENTICATION
This is possibly the most important option on the Tivoli Storage Manager server. If authentication is turned off, no passwords are needed for nodes or administrators to connect to the server. With authentication off, anyone with an administrative client can guess an administrator ID, and, if this user were to connect with an ID that has system level privilege, can wreak havoc on the system and possibly clients as well. Authentication is set on at installation, and the server requires system privilege in order to change it. Note: If authentication is disabled on the server, data that is sent by the client API when using transparent encryption is still encrypted, but the encryption key is not encrypted. We do not recommend that you disable authentication on the server.
SET MINPWLENGTH
This command sets the minimum password length that can be used on a system-wide basis. This password length is enforced not only for nodes but for administrator ID passwords and server passwords as well.
SET PASSEXP
The SET PASSEXP command sets the password expiration in days, either globally (the default), just for nodes, or just for administrators. Individual administrator IDs and node IDs can be selected as well. Execution of this command requires system privilege.
SET REGISTRATION
Client registration can be either open or closed.
Open
With open registration, a previously unregistered client node can register itself with the Tivoli Storage Manager server. In order to self-register, the STANDARD policy domain must exist on the server. If it does not exist, self registration fails. While allowing a node to self-register is not highly risky, the possibility exists that allowing a node to self-register can be used as a denial of service attack. An example of a denial of service attack can be repeatedly registering with fake node names or possibly by registering a new node and backing up huge volumes of data, which impacts server operation. If you want to use open registration, we recommend that you remove any backup and archive copy groups in the standard domain. This change allows nodes to self-register, but the nodes are unable to back up or archive until the Tivoli Storage Manager administrator moves them into a valid policy domain that has working copy group destinations.
Closed
With closed registration, the clients initial attempt to contact the Tivoli Storage Manager server fails unless the Tivoli Storage Manager administrator has already registered the client. Using this policy requires that a Tivoli Storage Manager administrator register each node and provide an initial password to the node administrator.
182
SET SERVERNAME
Although not directly related to server security, changing the server name can disrupt communication with other Tivoli Storage Manager servers and Storage Agents. Changing the server name requires system privilege.
SET SERVERPASSWORD
Server-to-server communication and LAN-free communication require that the Tivoli Storage Manager server password is set to a non-null value. If the server password is not set, you cannot establish communication with other servers or LAN-free Storage Agents. Setting the server password requires system privilege. For more information about this command, refer to 7.7, Securing a network of Tivoli Storage Manager servers on page 188.
7.5.2 Commands and options that affect client nodes

The commands in this section are Tivoli Storage Manager server commands but executing them has an impact upon the capabilities of client nodes.
REGISTER NODE and UPDATE NODE

When registering or updating a node, you must set an initial password, which must be at least as long as the value that is defined for MINPWLENGTH (see SET MINPWLENGTH on page 182. Registering or updating a node requires the administrative authority level of system, unrestricted policy, or restricted policy privilege for the policy domain to which the client node belongs. Next, we list the other security-related options for these commands
Forcepwreset
If this option is set to YES, the client node is required to reset its password when it first contacts the server after registration. We recommend that you select this option when you use closed registration to force the client administrator to input the client administrators own password. The default for this command is NO.
Backdel
Setting BACKDEL=YES allows the client to delete its own backup data. Unless the data stored by the client is deemed not valuable, this option needs to be left at the default setting of NO. The exceptions to this option are many Tivoli Data Protection clients that require the ability to perform deletions of their backup data to function properly.
Archdel
This option allows the client to delete its own archives if it remains set to the default setting of YES. The policies in place at a particular organization likely dictate whether this must be changed to NO.
Contact
The contact option is not required but is nonetheless a good option to include. At a minimum, the responsible administrators name and possibly phone number need to be included.
183
URL
The URL field is free-form text but is intended to store the URL to the Web backup/archive client for the client. We discussed the security implications of using the Web backup/archive client in Chapter 4, Securing the client on page 59.
Emailaddress
This field is a new field for Tivoli Storage Manager V5.4 and is currently undocumented in the server manuals. This field is intended to allow the server administrator to save the e-mail address of the individual who is responsible for the management of the client node. Maintaining up-to-date contact information for client nodes is a good practice. Therefore, entering the correct e-mail address in this field is a good idea.
7.5.3 Session control

You can use Tivoli Storage Manager commands to control the various client, administrator, or server sessions.
ENABLE SESSIONS and DISABLE SESSIONS

These commands, ENABLE SESSIONS and DISABLE SESSIONS, enable or disable sessions for client nodes, administrators, other servers, or for all. These commands require either system or operator privilege.
CANCEL SESSION
CANCEL SESSION can either cancel a specific session or can cancel all client node sessions by using the keyword ALL. System or operator authority is required to use this command.
Client scheduling modes

Tivoli Storage Manager has two methods of controlling client-scheduled actions: prompted and polling. This section gives you a brief overview of the two methods. The SET SCHEDMODES command controls which methods are allowed; valid options are POLLING, PROMPTED, or ANY. This information is discussed in-depth in the Tivoli Storage Manager Server Administrators Guide for each platform.
Polling
Polling is the default and indicates that the client must query the Tivoli Storage Manager server on a periodic basis to get updated schedule information. The frequency of these polls is determined either by the QUERYSCHEDPERIOD setting on the server, which affects all clients, or, if this is set to CLIENT, by the same parameter in the client options file. In the latter case, different nodes can have differing periods between server schedule updates. With older versions of Tivoli Storage Manager, it was necessary to use this method of client scheduling for nodes that operated in a different firewall zone than the Tivoli Storage Manager server or in situations that required the use of specific ports for communication between the client and the server. With the current versions of Tivoli Storage Manager client and server code, this is no longer true.
Prompted
This method of scheduling indicates that the client does not periodically poll the server for updated schedule information but rather that the server should contact the node with updated
184
schedule information when necessary. With the current releases of Tivoli Storage Manager, this method can now be used for scheduled client operations through a firewall. Refer to Chapter 9, Deployment in a network secured environment on page 247 for more information about client/server communication through a firewall.
7.6 Using the server to manage operations on a client node

The Tivoli Storage Manager scheduler can perform a variety of operations on clients that are listening with the client scheduler or the client acceptor daemon. See Chapter 3, Client files and services management on page 33 for information about these services and daemons. These operations include: Backups, both incremental and selective (full), including the execution of pre-backup and post-backup commands on the client Archive operations, including archive delete Restores, including possibly overwriting existing files Retrieval of archived data, including possibly overwriting later versions Image backup operations, including backing up an entire volume image Image restore operations, restoring an entire volume image, and possibly overwriting newer data Command and the ability to execute an arbitrary command on the client Macro, including the ability to execute a predefined Tivoli Storage Manager macro on the client node This section covers the security implications of allowing the server to perform operations on a client node using the Tivoli Storage Manager server scheduler.
7.6.1 General considerations for scheduled client operations

The Tivoli Storage Manager scheduler allows the administrator to specify options for the client to use during scheduled operations. Refer to Chapter 4, Securing the client on page 59 and Tivoli Storage Manager Administrators Guide and Tivoli Storage Manager Administrators Reference for each server operating system platform for additional information about these options. These options include: PRESCHEDULECMD and PRENSCHEDULECMD POSTSCHEDULECMD and POSTNSCHEDULECMD PRESNAPSHOTCMD and POSTSNAPSHOTCMD These client options can be passed as options to a scheduled operation for a client. The PRESCHEDULECMD and PRENSCHEDULECMD options specify a command to execute before beginning the backup. The POSTSCHEDULECMD and POSTNSCHEDULECMD options perform a similar function after the scheduled operation has occurred. PRESNAPSHOTCMD and POSTSNAPSHOTCMD apply to image backup operations.
185
On the server, the Tivoli Storage Manager administrator might consider setting these options to an empty string when defining client schedules unless pre-operation or post-operation scripts are required. Setting these options to a null string prevents the commands from executing even if the commands are defined in the clients options file. If the client has specified the option SRVPREPOSTSCHEDDISABLED in the client options file, this option prevents execution of these scripts as well. Note that there is no option to override SRVPREPOSTSCHEDDISABLED from a client option set; nor can SRVPREPOSTSCHEDDISABLED be passed as an option when defining a client schedule on the server. If the client has the option SRVPREPOSTSCHEDDISABLED in the client option file, the server cannot execute pre-schedule or post-schedule commands.
SRVPREPOSTSCHEDDISABLED and SRVPREPOSTSNAPDISABLED

These options can be specified in the client options file. These options cannot be specified as an option when defining a client schedule on the server, nor can these options be specified in a client option set. If the client has specified these options in the clients option file, the client does not execute pre-event or post-event commands, even if the pre-event and post-event commands are specified from the server.
SCHEDCMDDISABLED
SCHEDCMDDISABLED can be specified in the client option set, and prevents the server from executing arbitrary commands from the Tivoli Storage Manager server through the scheduler. This option cannot be specified or overridden from the Tivoli Storage Manager server, as it cannot be passed as an option from the Tivoli Storage Manager scheduler, nor can it be specified in a client option set.
SCHEDRESTRETRDISABLED
When specified in the client option set, SCHEDRESTRETRDISABLED prevents the Tivoli Storage Manager scheduler from performing a scheduled restore or retrieval operation. This option cannot be specified or overridden from the Tivoli Storage Manager server, because it cannot be passed as an option from the Tivoli Storage Manager scheduler. The client cannot specify SCHEDRESTRETRDISABLED in a client option set.
Replace
If the client has not disabled scheduled restores and retrievals by using the SCHEDRESTRETRDISABLED option (see SCHEDRESTRETRDISABLED), the Tivoli Storage Manager administrator can specify -replace=yes or -replace=all when defining scheduled client restores or retrievals. Using -replace=yes or -replace=all causes the client to overwrite the existing files if files exist. From the Tivoli Storage Manager server, this option can only be specified as an option to a scheduled operation; replace is not valid in a client option set.
7.6.2 Session initiation

When clients are registered or updated by using the REGISTER NODE and UPDATE NODE server commands, the administrator has the option to prevent the client node from initiating sessions to the Tivoli Storage Manager server by using the SESSIONINITIATION option. The default for this option is CLIENTORSERVER, which indicates that either the client or the server can initiate communication. By setting this option to SERVERONLY, the client is prevented from initiating a connection to the server.
186
If SESSIONINITIATION is set to SERVERONLY for a node, the client scheduling mode must be set to PROMPTED and the client acceptor daemon cannot be used to manage the scheduler. Example 7-17 is an example of updating a node for SERVERONLY initiation. We updated the client node to indicate that only the server can initiate the session.
Example 7-17 Updating a node for SERVERONLY initiation
update node nenya sessioninit=serveronly hladdress=192.168.99.231 lladdress=1501 In our client option file, we have the lines shown in Example 7-18.
Example 7-18 Client options for server-only initiation
COMMmethod TCPPort TCPClientPort TCPServeraddress managedservices schedmode passwordaccess
TCPip 1500 1501 192.168.99.128 webclient prompted generate
After restarting the client acceptor (dsmcad) process and pointing our Web browser at the client node on port 1581, we can successfully bring up the Web interface. But when we attempt a backup or restore, we receive the message that is shown in Figure 7-7.
Figure 7-7 Web client error when SERVERONLY initiation is specified
When attempting to connect from the command line client, we receive the message that is shown in Example 7-19.
Example 7-19 Command line client error when SERVERONLY initiation is specified
nenya:~ # dsmc q sched IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 4, Level 0.0 Client date/time: 02/12/07 10:45:39 (c) Copyright by IBM Corporation and other(s) 1990, 2007. All Rights Reserved. Node Name: NENYA ANS1382E Server does not allow client-initiated connections for this node.
187
The server records the failed connection attempt in the activity log. See Example 7-20.
Example 7-20 Server activity log message for refused session
ANR0406I ANR0476W initiate ANR0403I
Session 15 started for node NENYA (Linux86) (Tcp/Ip localhost(1290)). Session 15 for node NENYA (Linux86) refused - node is not allowed to sessions. Session 15 ended for node NENYA (Linux86).
Note that while backup/archive sessions are disabled, administrative sessions from this node are allowed. See 9.2.3, Initiating scheduled sessions on page 252 for more information about the SESSIONINITIATION parameter.
7.7 Securing a network of Tivoli Storage Manager servers

Tivoli Storage Manager has the ability to communicate between server instances, whether they reside on the same physical hardware or not, and independently of the underlying operating system. A Tivoli Storage Manager server running on AIX can communicate with a Tivoli Storage Manager server running on any other supported platform, such as Windows, Solaris, HP-UX, Linux, or z/OS. In this following sections, we discuss the security implications of server-to-server communication, including administrative traffic, virtual volumes, and server-to-server exports and imports.
7.8 Encryption for server-to-server communication

When using server-to-server communication, the session initiation is encrypted using the highest level of encryption available from both servers. For V5.3 and 5.4 Tivoli Storage Manager servers, AES128 is used for server-to-server session initiation. If one or both servers are V5.2 or below, DES56 is used. We performed a series of network traces while running various server-to-server operations. Figure 7-8 on page 189 shows a diagram that illustrates the two servers that we used for this test and their IP addresses.
188
Figure 7-8 Setup for server-to-server tests
7.8.1 Server-to-server session setup encryption

In order to view the traffic that occurs between the two servers, we first had to establish server-to-server communication between the systems. We issued the commands that are shown in Example 7-21 and Example 7-22 for Tivoli Storage Manager servers, MAIN and REMOTE.
Example 7-21 Setup for server MAIN
set set set set
servername MAIN serverpassword main serverhladdress 192.168.99.231 serverlladdress 1500
Example 7-22 Setup for server REMOTE
set set set set
servername REMOTE serverpassword remote serverhladdress 192.168.204.128 serverlladdress 1500
We initiated a network trace using ethereal: http://www.ethereal.com And, we issued the following command from server MAIN: define server remote serverpassword=main nodename=main password=main hladdress=192.168.204.128 lladdress=1500 In the network trace, Example 7-23, we see that the packet was sent from LOCAL to REMOTE.
Example 7-23 Initial server-to-server login
No.
Time Source Destination Protocol Info 8 0.002267 192.168.99.231 192.168.204.128 TCP 1891 > 1500 [PSH, ACK] Seq=4257552632 Ack=682094886 Win=1460 Len=4 TSV=26648672 TSER=0
189
Frame 8 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Vmware_c0:00:08 (00:50:56:c0:00:08), Dst: Vmware_39:f3:56 (00:0c:29:39:f3:56) Internet Protocol, Src: 192.168.204.1 (192.168.204.1), Dst: 192.168.204.128 (192.168.204.128) Transmission Control Protocol, Src Port: 1891 (1891), Dst Port: 1500 (1500), Seq: 4257552632, Ack: 682094886, Len: 4 Data (4 bytes) 0000 00 04 1d a5 ....
Server REMOTE responds. See Example 7-24 (packet headers were omitted for brevity).
Example 7-24 Response from REMOTE
Data (58 bytes) 0000 0010 0020 0030 00 06 7e 4f 3a 00 f6 54 1e 06 00 45 a5 00 00 57 66 07 00 69 15 00 00 6e 07 05 00 64 d7 00 00 6f 02 04 00 77 0b 0e 15 2e 00 00 00 00 00 00 00 f7 7b bf 00 00 00 02 52 45 4d 73 .:..f........... ..............{. ~............REM OTEWindows
Server LOCAL issues the information in Example 7-25.

Example 7-25 Issued from LOCAL
Data (105 bytes) 0000 00 69 0010 0e 00 0020 00 00 0030 69 33 0040 2f 74 0050 6e 74 0060 65 6e entv3.cat 1a 04 00 38 69 2f 74 a5 01 00 36 76 62 76 69 00 00 4d 6f 61 33 00 12 00 41 6c 2f 2e 00 00 00 49 69 62 63 00 2d 00 4e 2f 69 61 0a 18 00 4d 74 6e 74 0e 19 00 41 73 2f 04 ff 4c 49 6d 64 00 00 69 4e 2f 73 0a 00 6e 2f 63 6d 00 00 75 6f 6c 63 04 60 78 70 69 6c 00 00 2f 74 65 69 .i..i........... .......-......`. ..........Linux/ i386MAINMAIN/opt /tivoli/tsm/clie nt/ba/bin/dsmcli
And server REMOTE responds (Example 7-26).

Example 7-26 Response from REMOTE
Data (28 bytes) 0000 0010 00 1c 1c a5 00 00 00 0a 00 01 03 03 01 02 02 01 01 00 4c 69 6e 75 78 2f 69 33 38 36 ................ ..Linux/i386
Next follow several packets of encrypted data between the source server and the target server (Example 7-27).
Example 7-27 Encrypted server-to-server traffic
Data (56 bytes) 0000 0010 0020 00 38 16 a5 00 00 00 30 1e 48 9f 41 fe 02 cb 5c 32 7d 58 3b ef 1f 03 c8 ee 5b e6 b9 2e 1f 2f a2 9e 5c 32 de 95 29 49 74 31 de a4 a7 6e ff 1a 17 .8.....0.H.A...\ 2}X;.....[..../. .\2..)It1...n...
190
0030
ad a0 2d 41 75 0a 3f c3
..-Au.?.
At no time during the server log-in exchange were we able to see the server passwords transmitted in the clear.
7.9 Command routing

Command routing is the ability of one Tivoli Storage Manager server to execute administrative commands on another server by way of server-to-server communication. In order for command routing to work, the Tivoli Storage Manager administrator must have already established server-to-server communication, and the administrator ID used to issue the routed command must exist, be unlocked, and have adequate privilege on the target server. Example 7-28 shows the output from a successfully routed command as seen from the source server.
Example 7-28 Successfully routed command from MAIN to REMOTE
tsm: MAIN>remote: q sess ANR1699I Resolved REMOTE to 1 server(s) - issuing command Q SESS against server(s). ANR1687I Output for command 'Q SESS ' issued against server REMOTE follows: Sess Number -----14 36 38 Comm. Method -----Tcp/Ip Tcp/Ip Tcp/Ip Sess State -----Run IdleW Run Wait Time -----0 S 2.6 M 0 S Bytes Sent ------13.0 K 11.3 K 154 Bytes Recvd ------107 198 233 Sess Type ----Admin Admin Admin Platform -------WinNT WinNT Linux/i386 Client Name -------------------REPORT SCS ADMIN
ANR1688I Output for command 'Q SESS ' issued against server REMOTE completed. ANR1694I Server REMOTE processed command 'Q SESS ' and completed successfully. ANR1697I Command 'Q SESS ' processed by 1 server(s): 1 successful, 0 with warnings, and 0 with errors
If the administrator ID on the target server is missing, is locked, or does not have adequate authority, the routed command fails. Example 7-29 shows the output when the administrator ID on the target server is locked.
Example 7-29 Unsuccessfully routed command due to locked administrator on target server
tsm: MAIN>remote: q sess ANR1699I Resolved REMOTE to 1 server(s) - issuing command Q SESS against server(s). ANR4373E Session rejected by target server REMOTE, reason: No Resource. ANR1696E Server REMOTE attempted to process command 'Q SESS ' but encountered errors. ANR1697I Command 'Q SESS ' processed by 1 server(s): 0 successful, 0 with warnings, and 1 with errors. ANS8001I Return code 4.
7.10 Virtual volumes

Tivoli Storage Manager virtual volumes are volumes that are defined or created on a remote Tivoli Storage Manager server (called the target) that can be used by the local server (called the source) for data storage. A complete explanation of the setup and the use of virtual volumes is beyond the scope of this book; refer to the Tivoli Storage Manager Administrators Guide and Tivoli Storage Manager Administrators Reference for each server operating system platform for information about this subject. For the purpose of this topic, we were interested in determining if an individual armed with a packet sniffer can read data in-flight between servers when virtual volumes were in use.
191
The test setup that we used was described in 7.8, Encryption for server-to-server communication on page 188. We defined a copy storage pool using a device class that used the server REMOTE as a target, then issued a BACKUP STGPOOL command on MAIN while capturing packets transmitted across the network while the process was running. The initial packet exchange is the same as we saw before in 7.8.1, Server-to-server session setup encryption on page 189, with the encrypted login and password conversation. Further on in the exchange, we observed the packet payload shown in Figure 7-9 on page 193.
192
0000 0010 0020 0030 0040 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 00f0 0100 0110 0120 0130 0140 0150 0160 0170 0180 0190 01a0 01b0 01c0 01d0 01e0 01f0 0200 0210 0220 0230 0240 0250 0260 0270 0280
00 0a 00 00 02 45 35 4c 52 4e 4e 00 d7 06 00 01 00 05 00 00 02 00 00 4e 44 72 45 00 07 00 c6 00 00 00 00 04 65 64 53 00 a5
04 00 09 03 0c 4d 31 69 44 44 20 00 02 52 00 00 00 00 05 04 0c 00 00 45 41 64 46 01 00 45 00 00 00 00 00 02 72 20 02 02 01
12 30 00 00 0d 4f 32 6e 41 41 20 00 0c 45 00 00 00 05 00 00 0c 00 00 4e 52 73 41 00 03 c9 00 00 00 00 00 00 73 69 00 c4 00
a5 00 43 5a 2a 54 42 75 44 52 20 00 0d 4d 00 00 00 00 1a 3a 16 b6 00 59 44 2e 55 00 85 04 00 00 00 00 00 00 65 73 20 00
00 08 00 00 05 45 46 78 53 44 01 00 2a 4f 01 55 00 07 00 00 2e 00 00 41 2f 74 4c 00 58 95 04 00 00 00 00 00 63 20 00 00
e0 00 08 33 02 2e 53 2f 4d 53 00 00 05 54 99 01 00 00 0d 7c 00 00 00 4c 2f 78 54 00 00 45 00 00 00 00 00 00 72 61 02 00
92 38 00 00 02 42 2e 69 2e 54 00 00 ff 45 07 00 00 0c 00 00 01 00 00 69 74 74 72 00 00 c9 00 00 00 00 80 00 65 62 00 00
a5 00 4b 00 41 46 4f 33 53 41 00 00 ff 00 a5 00 00 00 27 00 00 00 00 6e 6d 53 6f 00 81 04 00 00 00 00 03 00 74 63 00 00
00 0b 00 00 44 53 42 38 45 4e 00 00 00 00 52 00 01 08 00 00 00 00 00 75 70 54 6f 00 a4 95 00 00 00 00 00 00 20 31 00 00
00 01 08 00 53 2e 4a 36 52 44 00 00 00 00 46 00 1e 00 08 00 00 00 00 78 2f 41 74 23 00 00 00 00 00 00 00 23 70 32 00 00
22 00 00 1f 41 31 2e 53 56 41 00 00 00 00 45 00 c5 14 00 00 00 00 00 38 70 4e 07 02 00 00 00 00 00 00 0f 4d 61 33 00 00
00 00 53 40 44 37 31 54 45 52 00 00 00 00 53 00 a5 00 2f 00 00 00 00 36 61 44 09 49 00 00 00 00 00 00 00 79 73 34 00 00
04 00 00 00 53 31 4d 41 52 44 00 00 00 00 02 02 02 01 00 04 00 00 00 53 73 41 16 00 00 00 00 00 00 00 00 20 73 0a 00 00
00 19 04 00 4d 33 41 4e 53 4d 91 00 00 00 00 c4 00 01 07 00 00 00 00 54 73 52 00 00 00 45 00 00 00 00 00 73 77 52 00 00
26 00 00 07 2f 31 49 44 54 41 02 00 00 00 20 00 00 00 00 07 00 00 00 41 77 44 66 0f 00 d0 00 00 00 00 00 75 6f 46 00 06
00 19 57 d7 52 36 4e 41 41 49 00 07 00 00 00 00 00 15 36 d7 00 00 00 4e 6f 44 0c 00 00 cb 00 00 00 00 00 70 72 45 00 13
.........."...&. ..0...8......... ...C...K...S...W ...Z.3.....@.... ...*...ADSADSM/R EMOTE.BFS.171316 512BFS.OBJ.1MAIN Linux/i386STANDA RDADSM.SERVERSTA NDARDSTANDARDMAI N ............ ................ ....*........... .REMOTE......... ........RFES.. . ....U........... ................ ................ .......'.../...6 ...:.|.......... ................ ................ ................ NENYALinux86STAN DARD//tmp/passwo rds.txtSTANDARDD EFAULTroot....f. .........#.I.... ....X........... .E...E.......E.. ................ ................ ................ ................ ................ .........#My sup ersecret passwor d is abc1234.RFE S.. ............ ................ ...
Figure 7-9 Data packet when using server-to-server virtual volumes
From this test, we can conclude that while session-setup traffic is indeed encrypted with either DES56 or AES128, the client data transmitted while using virtual volumes is not. As with regular unencrypted client traffic, Tivoli Storage Manager embeds various control structures into the data stream, and there are no clear markers to indicate where the file begins and ends. But a determined cracker might be able to reconstruct enough information from the data stream to cause damage, particularly if the data is plain text.
193
Accordingly, we advise that you either only send the data across secure networks when using virtual volumes or else use client encryption to encrypt the data prior to transmitting it between servers.
7.11 Using a configuration manager

When using server-to-server communication, it is possible to define one Tivoli Storage Manager server as a configuration manager using the SET CONFIGMANAGER ON command. Other Tivoli Storage Manager servers in the network are able to subscribe to the configuration manager. These servers are referred to as managed servers. The configuration manager is able to create collections of items called profiles that are distributed to the managed servers. Profiles can contain collections of: Administrators Administrative schedules Server scripts Policy domains Client option sets Other Tivoli Storage Manager servers Groups of other Tivoli Storage Manager servers Detailed information about setting up a server as a configuration manager and defining profiles is contained in the Tivoli Storage Manager Administrators Guide and Tivoli Storage Manager Administrators Reference for each operating system platform.
7.11.1 Security aspects of profiles

For this section, we continue to use the two servers that we have used in previous sections, except that now we have enabled MAIN to be a configuration manager and REMOTE to be a managed server, as shown in Figure 7-10.
Figure 7-10 Tivoli Storage Manager server network
After an administrator on a Tivoli Storage Manager configuration manager creates a profile, the client Tivoli Storage Manager servers, which we refer to as managed servers, can
194
subscribe to that profile using the DEFINE SUBSCRIPTION command. When the command is issued, the items defined within the profiles override any matching items on the managed server.
7.11.2 Administrator ID management

For example, assume a managed server has an administrator ID called operator, and the configuration manager has a profile called admins that also contains an administrator ID called operator. If the managed server subscribes to the admins profile, the operator ID in the managed server will be overwritten by the operator ID from the profile. This can include different system authority and a different password. The DEFINE SUBSCRIPTION command must be issued from the managed server, but the administrator on the managed server can use command routing to execute commands on the managed server after server-to-server communication has been established. For example, we established the profile ADMINS on the configuration manager MAIN and populated it with the administrator IDs operator and report. The report ID already exists on the REMOTE server; the operator ID does not. See Example 7-30.
Example 7-30 Creating an populating a profile
define profile admins desc=Administrator IDs define profassociation admins admins=operator,report In Example 7-31, the command, which we issued on the configuration manager MAIN using command routing to the managed server REMOTE, creates a subscription for the profile ADMINS.
Example 7-31 Using command routing to define a subscription
REMOTE: define subscription ADMINS server=MAIN Example 7-32 shows the activity log detail on the REMOTE server.
Example 7-32 Local administrator ID overwritten by profile
ANR0407I Session 33 started for administrator ADMIN (Linux/i386) (Tcp/Ip 192.168.204.1(1942)). ANR2017I Administrator ADMIN issued command: DEFINE SUBSCRIPTION admins server=main ANR0408I Session 34 started for server MAIN (Linux/i386) (Tcp/Ip) for configuration management. ANR0409I Session 34 ended for server MAIN (Linux/i386). ANR3030I DEFINE SUBSCRIPTION: Subscription defined for profile ADMINS. ANR0405I Session 33 ended for administrator ADMIN (Linux/i386). ANR0408I Session 35 started for server MAIN (Linux/i386) (Tcp/Ip) for configuration management. ANR3152I Configuration refresh started with configuration manager MAIN. ANR3361I Locally defined administrator REPORT replaced during configuration refresh processing. ANR3153I Configuration refresh ended successfully with configuration manager MAIN. ANR0409I Session 35 ended for server MAIN (Linux/i386). The text in bold shows where the local report ID on the managed server has been replaced by the ID of the same name from the configuration manager profile.
195
As Example 7-32 on page 195 suggests, any item contained in a profile from a configuration manager overwrites an item by the same name on the managed server.
7.11.3 Policy management

As we just saw, items in a configuration profile overwrite a local item with the same name. This overwriting has particular implications when a managed server subscribes to a profile that contains domains. When a managed server subscribes to a profile containing a domain, a domain on the managed server, which has the same name as the domain in the subscribed profile, is overwritten. This overwriting includes policy sets, management classes, copy groups, and client schedules. 1. To demonstrate this behavior, we setup a domain called NEWDOMAIN on the managed server (REMOTE), with the characteristics shown in Example 7-33.
Example 7-33 Domain NEWDOMAIN on the REMOTE server
tsm: REMOTE>q copygroup newdomain * * Policy Domain Name --------NEWDOMAIN NEWDOMAIN Policy Set Name --------ACTIVE STANDARD Mgmt Class Name --------STANDARD STANDARD Copy Group Name --------STANDARD STANDARD Versions Data Exists -------10 10 Versions Data Deleted -------1 1 Retain Extra Versions -------30 30 Retain Only Version ------60 60
2. We created a domain of the same name on the configuration manager server (MAIN) with a different setting for the VEREXISTS parameter, which is shown in Example 7-34.
Example 7-34 Domain NEWDOMAIN on the MAIN server
tsm: MAIN>q copygroup newdomain * * Policy Domain Name --------NEWDOMAIN NEWDOMAIN Policy Set Name --------ACTIVE STANDARD Mgmt Class Name --------STANDARD STANDARD Copy Group Name --------STANDARD STANDARD Versions Data Exists -------5 5 Versions Data Deleted -------1 1 Retain Extra Versions -------30 30 Retain Only Version ------60 60
3. We created a new profile called DOMAINS on MAIN, the configuration server, and associated the domain NEWDOMAIN with the profile in Example 7-35.
Example 7-35 Creating a profile and association
tsm: MAIN>define profile domains desc="Profile for Domains" ANR3017I DEFINE PROFILE: Profile DOMAINS defined. tsm: MAIN>define profassociation domains domain=newdomain ANR3045I DEFINE PROFASSOCIATION: Domain NEWDOMAIN associated with profile DOMAINS. 4. Last, we subscribed the managed server REMOTE to the new DOMAINS profile (Example 7-36).
Example 7-36 REMOTE subscribing to DOMAINS profile
tsm: REMOTE>define subscription domains ANR3030I DEFINE SUBSCRIPTION: Subscription defined for profile DOMAINS.
196
5. In the activity log of the managed server REMOTE, we see the configuration server overriding a domain of the same name (Example 7-37).
Example 7-37 Configuration server overriding a domain of the same name
ANR2017I Administrator ADMIN issued command: DEFINE SUBSCRIPTION domains ANR0408I Session 6 started for server MAIN (Linux/i386) (Tcp/Ip) for configuration management. ANR0409I Session 6 ended for server MAIN (Linux/i386). ANR3030I DEFINE SUBSCRIPTION: Subscription defined for profile DOMAINS. ANR0408I Session 7 started for server MAIN (Linux/i386) (Tcp/Ip) for configuration management. ANR3152I Configuration refresh started with configuration manager MAIN. ANR3352I Locally defined domain NEWDOMAIN replaced during configuration refresh processing. ANR3153I Configuration refresh ended successfully with configuration manager MAIN. 6. The NEWDOMAIN domain has been replaced by the domain of the same name from the configuration manager MAIN, as shown in Example 7-38.
Example 7-38 Replaced copygroup from configuration manager
tsm: REMOTE>q copygroup newdomain * * Policy Domain Name --------NEWDOMAIN Policy Set Name --------STANDARD Mgmt Class Name --------STANDARD Copy Group Name --------STANDARD Versions Data Exists -------5 Versions Data Deleted -------1 Retain Extra Versions -------30 Retain Only Version ------60
Note: The configuration manager does not distribute the active policyset through the subscription. You must activate the policyset that you want if changes are needed after a refresh.
7.11.4 Other profile associations

The cautions outlined in the preceding sections, 7.11.2, Administrator ID management on page 195 and 7.11.3, Policy management on page 196, also apply to: Administrative schedules Server scripts Client option sets Other Tivoli Storage Manager servers Groups of other Tivoli Storage Manager servers The general concept is that any profile-managed item that is distributed from the configuration manager overwrites the item of the same name on the managed server.
7.12 Security considerations for exports and backup sets

Exporting data from Tivoli Storage Manager is the process of making a new copy of existing data, primarily for the purpose of migrating it to another Tivoli Storage Manager system. An export can be written either to physical media that can be transported physically to another server, or if server-to-server communication used, the exported data can be directly written across the network to the target system.
197
A backup set is a copy of some or all of the active data belonging to a particular node that is written to a set of media, and usually the intention is to remove it from the physical tape library. In addition to the nodes data, a backup set also includes all of the metadata for that data; it is, in effect, a self-describing archive of that data. The Tivoli Storage Manager server does not perform data encryption, so if data is to be exported or a backup set is to be generated from the Tivoli Storage Manager server, make sure to consider the vulnerability of the data after it leaves the home system. Exported data or backup sets being moved between systems face the same potential threats as off-site copy storage pool media (if using physical media) or potential network attacks if using server-to-server exports. If client data has not been either encrypted on the client before being sent to the Tivoli Storage Manager server or written to an encryption-capable device, the data can be potentially recovered by an attacker if the media is lost or stolen.
Exported data or backup sets encrypted using client encryption

When the data is received at the importing system, the Tivoli Storage Manager server allows the data to be imported without requesting a key password, because the client node does the decryption. When a restore of imported data is attempted, the client requires the user to provide a key in order to access the data.
Exported data or backup sets encrypted using TS1120 encryption

If you use application-managed encryption (AME), export and backup set tapes are not encrypted. If the exported data or backup set is written to an encrypting tape drive when using either system-managed encryption (SME) or library-managed encryption (LME), the data is encrypted on the media. In order to import the data on the receiving system, the tape drive reading this media needs to have access to the key, which was used by the writing drive to encrypt the data on the tape. If the target system has IP connectivity to the system that has the Encryption Key Manager running that originally provided the key to the source system, the target system can be configured to access the Encryption Key Manager server to obtain the correct key for that volume. If IP connectivity to the Encryption Key Manager server is not available, you need to set up an Encryption Key Manager instance local to the target Tivoli Storage Manager system with the correct key available. Note: In order to read the encrypted tape, the correct key must be available from a key manager. Refer to Chapter 6, TS1120 Tape encryption on page 113 for more information about encryption with the TS1120 tape drive.
7.13 Administrator roles and Operational Reporting

This section discusses the security implications of using the Tivoli Storage Manager Operational Reporting module. Tivoli Storage Manager Operational Reporting is provided as an additional no-charge module that can be used with any Tivoli Storage Manager server, 198
regardless of platform. Operational Reporting is installed by default on Windows Tivoli Storage Manager servers. Although Operational Reporting works with current Tivoli Storage Manager servers on any platform, it can only run on a Windows host as a Microsoft Management Console (MMC) snap-in.
7.13.1 Operational Reporting overview

Operational Reporting provides two types of information: reports and monitors. A report is generated periodically, usually once a day, and shows activity for a specific period of time, as well as alerts for potential issues with the server. A monitor is similar to a report but is run more frequently and is intended to alert personnel of potential problems that might need attention, typically sooner than the issues shown under reports. Each of these functions, reports and monitors, is created and updated through SQL queries submitted to the Tivoli Storage Manager server. For reports, the results are used to update the reports for the specified time period; for monitors, the results might be used to generate an alert through e-mail or the Windows Net Messenger service. The report updates are run by using a Windows service TSMReptSvc, which is installed and configured automatically when you load Operational Reporting. More information about Operational Reporting is provided in the Tivoli Storage Manager Administrators Guide for each server operating system platform.
7.13.2 Operational Reporting connections to the Tivoli Storage Manager server

Because Operational Reporting depends on SQL queries to the Tivoli Storage Manager server or servers for updates, there must be an administrator ID for the Operational Reporting to use when issuing these queries. As discussed in 7.2.10, Server options related to administrative privilege on page 170, by default, any valid administrator ID can issue SQL queries to the Tivoli Storage Manager server. However, it is good practice to limit this ability to a minimum number of users with administrative authority in order to reduce the possibility of a denial-of-service type attack on the server.
Windows Tivoli Storage Manager server

For Windows Tivoli Storage Manager servers, Operational Reporting is installed as part of the server installation. Operational Reporting automatically has the local Tivoli Storage Manager server defined within the Management Console, as shown in Figure 7-11 on page 200.
199
Figure 7-11 Automatic entry for local Tivoli Storage Manager server on Windows
Tivoli Storage Manager servers that are remote, whether they are Windows or not, must be explicitly added to Operational Reporting. Regardless of whether the server is local (on the same host) or remote, an administrator ID must be given with which to access the server. Figure 7-12 shows the dialog where the administrator ID is set for a particular server instance.
Figure 7-12 Setting the administrator ID in Operational Reporting
Because the Management Console/Operational Reporting runs locally on a Windows Tivoli Storage Manager server, it is more acceptable to use an administrator ID with a higher level of authority when connecting to the local server, because no traffic should be traveling across 200
the network. This setup assumes that the proper security is used at the operating system level to prevent unauthorized access. Using an ID with, for example, system authority also allows the administrator to use the interface to perform other administrative tasks, such as using the configuration wizards, shown in Figure 7-13.
Figure 7-13 Wizards in the Management Console
If an ID with minimal authority (for example, analyst) is used to communicate with the server from the Management Console, most of these wizards fail due to inadequate privileges on the Tivoli Storage Manager server.
Non-Windows Tivoli Storage Manager server

Operational Reporting runs only on a Windows host, but it can display reports for non-Windows Tivoli Storage Manager servers. As when running locally on a Windows Tivoli Storage Manager server, Operational Reporting generates these reports by issuing SQL queries against the Tivoli Storage Manager instance. However, when the Tivoli Storage Manager server is remote (nonlocal), the queries and their responses must travel across the network. Also, when running Operational Reporting for a non-Windows Tivoli Storage Manager server, features, such as the wizards do not function correctly (or at all). For these reasons, we recommend that you give the administrator ID that is used to generate reports in Operational Reporting for a nonlocal Tivoli Storage Manager server a low privilege, such as ANALYST. Additionally, we recommend that you set the Tivoli Storage Manager server QUERYAUTH parameter in the server options file (dsmserv.opt) to a minimum privilege level of ANALYST. See QUERYAUTH on page 170.
201
7.14 Integrated Solutions Console security

The Integrated Solutions Console (ISC) and its Tivoli Storage Manager management application, the Tivoli Storage Manager Administration Center (AC), were introduced with Tivoli Storage Manager V5.3 as a replacement for the previous Tivoli Storage Manager Web interface. Just as we recommend that each Tivoli Storage Manager administrator has a unique ID, we also recommend that each administrator, who performs work through the ISC/AC, has its own ID. Furthermore, we recommend that each Tivoli Storage Manager administrator ID has an ISC/AC ID of the same name. After initially installing the ISC/AC, there exist one ISC user ID, which is normally iscadmin. This is configurable during installation, but we recommend that you accept the defaults of the ID iscadmin with the password iscadmin. This ID is roughly analogous to the root user ID for a UNIX or Linux system or Administrator on a Windows system. The ISC/AC has its own user IDs and groups that are created and maintained separately from the Tivoli Storage Manager server administrator IDs. The user and group information, along with the roles and permission assigned to those IDs are stored in a credential vault. The credential vault cannot be modified or accessed from within the ISC by any user ID.
7.14.1 Adding administrators to the ISC/Administration Center

To add new administrators to the ISC/AC, log in with an existing ID; for new ISC installations, this ID is likely iscadmin: 1. Click Console Settings User and Group Management. In the right panel, click New User as shown in Figure 7-14.
Figure 7-14 ISC/AC user and group management panel
2. The Add User dialog box then displays; as noted earlier, we recommend that you use the same ID here as the administrator ID that is used on the Tivoli Storage Manager server. Complete the fields as required, as shown in Figure 7-15 on page 203.
202
Figure 7-15 Add user dialog box
3. Click OK to return to the parent menu, where the new ID displays, which is shown in Figure 7-16.
Figure 7-16 Newly added ISC/AC administrator
4. Click the Users and Groups link above New User to return to the parent menu. Next, you see the panel shown in Figure 7-17 on page 204.
203
Figure 7-17 Users and group management menu
5. From this panel, click All Portal User Groups. The panel shown in Figure 7-18 displays.
Figure 7-18 All portal user groups menu
If you want the newly added ID to administer the ISC/AC, you need to add the newly added ID to the iscadmins group; if this ID only requires access to Tivoli Storage Manager and will not add IDs to the ISC, you can add it to the TSM_AdminCenter group. If the ID is a member of the TSM_AdminCenter group, there is no option provided for that ID to make any changes on the ISC/AC.
204
For the purpose of this section, we add an ID that is able to control both the ISC/AC and connect to the Tivoli Storage Manager server. 1. Click the iscadmins ID link shown in Figure 7-18 on page 204. The panel shown in Figure 7-19 appears.
Figure 7-19 Iscadmins group menu
Click Add Member. Select the administrator ID to add to the iscadmins group from the list that appears.
7.14.2 Connecting ISC and Tivoli Storage Manager administrator IDs

When an administrator logs on to the ISC/AC, they must first add a connection to a Tivoli Storage Manager server in order to manage it. To do this, select Tivoli Storage Manager Storage Devices. In the right Servers panel, click Select Action Add Server Connection as shown in Figure 7-20 on page 206.
205
Figure 7-20 Add server connection menu
2. The resulting menu is shown in Figure 7-21 on page 207. The administrator ID provided here is used to connect to the Tivoli Storage Manager server. This administrator ID must have already been created before attempting a server connection from the ISC using this ID. As we noted earlier, the administrator ID used on the ISC must be the same ID used on the Tivoli Storage Manager server. When defining this connection, the user must provide an administrator log-in ID and password for the server to be managed. The capabilities that the ISC/AC user has on the Tivoli Storage Manager server are defined by the authority that the provided administrator ID has on the server.
206
Figure 7-21 Dialog for creating server connection
3. After creating a connection, a success message displays (Figure 7-22).
Figure 7-22 Successful server connection definition
7.15 ISC/AC communication security

When an administrator works with the Tivoli Storage Manager server using the ISC/AC, there are typically two network links involved: one network link from the users Web browser to the system running the ISC/AC and another network link from the ISC/AC to the target Tivoli Storage Manager server. This section provides an overview of how this communication occurs and how to set up SSL communication for the link between the Web browser and the ISC/AC.
7.15.1 Web browser link to ISC/AC

The initial browser connection is made to the following URL: http://<servername_or_ip>:8421/ibm/console This is a normal unencrypted connection to port 8421 on the ISC/AC server. When a user logs in to the ISC/AC from a browser, the traffic is visible in clear text as shown in Example 7-39 on page 208.
207
Example 7-39 Captured log-in information from browser No. Time Source Destination 8 0.044980 192.168.204.128 192.168.99.231 ACK] Seq=1314021294 Ack=2645440192 Win=64512 Len=141 Protocol Info TCP 1049 > 8421 [PSH,
Frame 8 (195 bytes on wire, 195 bytes captured) Ethernet II, Src: Vmware_39:f3:56 (00:0c:29:39:f3:56), Dst: Vmware_ee:25:a5 (00:50:56:ee:25:a5) Internet Protocol, Src: 192.168.204.128 (192.168.204.128), Dst: 192.168.99.231 (192.168.99.231) Transmission Control Protocol, Src Port: 1049 (1049), Dst Port: 8421 (8421), Seq: 1314021294, Ack: 2645440192, Len: 141 Data (141 bytes) 0000 0010 0020 0030 0040 0050 0060 0070 0080 43 70 66 0a 20 65 6d 61 5f 6f 6c 6f 43 37 74 69 64 6c 6e 69 72 6f 30 73 6e 6d 6f 74 63 6d 6e 0d 2e 26 69 67 65 61 2d 74 0a 75 70 6e 69 6e 74 75 65 0d 73 61 26 6e 74 69 72 6e 0a 65 73 50 3d 2d 6f 6c 74 77 72 73 43 4c 54 6e 65 2d 70 69 77 5f 6f 79 2f 6e 4c 73 64 6f 37 67 70 78 63 65 2e 3d 72 5f 2b 65 2d 6f 6e 70 69 64 30 69 3a 77 64 67 6f 73 3d 5f 6e 20 77 65 74 72 63 69 33 61 77 64 68 74 61 73 47 70 2d 0d 3a 6c 64 63 5f Content-Type: ap plication/x-wwwform-urlencoded. .Content-Length: 70....wps.portl ets.userid=iscad min&password=isc admin&PC_7_0_3G_ _login=Log+in
Even after the session is established, all network traffic between the browser and the ISC/AC is unencrypted. Example 7-40 shows a payload from a data packet sent between the browser and ISC/AC when defining a server connection.
Example 7-40 Traffic in clear text
00d0 00e0 00f0 0100 0110 0120 0130 0140 0150 0160 0170 0180 0190
55 61 74 33 77 36 55 73 64 30 35 65 33
47 6d 30 32 6f 74 33 77 37 53 30 73 31
4c 65 30 55 72 30 32 6f 30 46 30 73 26
30 3d 30 47 64 30 55 72 32 30 4f 3d 50
35 6c 30 4c 3d 30 47 64 34 30 34 31 43
30 64 30 30 6c 30 4c 76 26 30 5f 39 5f
30 69 30 35 61 30 30 65 50 34 73 32 36
4f 65 53 30 64 30 35 72 43 30 65 2e 74
34 74 46 30 37 53 30 69 5f 56 72 31 30
5f 65 30 4f 30 46 30 66 36 55 76 36 30
61 72 30 34 32 30 4f 69 74 33 65 38 30
64 26 30 5f 34 30 34 65 30 32 72 2e 30
6d 50 34 70 26 30 5f 72 30 55 61 39 30
69 43 30 61 50 34 70 3d 30 47 64 39 30
6e 5f 56 73 43 30 61 6c 30 4c 64 2e 53
6e 36 55 73 5f 56 73 61 30 30 72 32 46
UGL0500O4_adminn ame=admin12&PC_6 t000000SF00040VU 32UGL0500O4_pass word=abc1234&PC_ 6t000000SF00040V U32UGL0500O4_pas swordverifier=ab c1234&PC_6t00000 0SF00040VU32UGL0 500O4_serveraddr ess=192.168.99.2 31&PC_6t000000SF
7.15.2 ISC/AC to Tivoli Storage Manager server

Traffic between the ISC/AC and the Tivoli Storage Manager server uses the dsmapi. The dsmapi is written in Java and is unique to the ISC/AC. The connections to the Tivoli Storage Manager servers are special in that the results from commands are returned to the ISC/AC as XML documents. With dsmapi, the login is transmitted unencrypted, but the password is sent encrypted. Example 7-41 on page 209 shows a portion of a network trace from a session login between the ISC/AC and the Tivoli Storage Manager server. The log-in ID is transmitted unencrypted, but the password is encrypted.
208
Example 7-41 ISC login to Tivoli Storage Manager server
0000 0010 0020 0030 0040
00 0b 00 41 2c
4a 00 00 44 2e
1a 05 00 4d 01
a5 00 00 49 01
67 00 00 4e 01
00 10 00 41 00
00 00 00 44 00
00 10 00 4d 00
06 2a 00 49 00
07 3f 00 4e 00
01 10 44 18
00 24 53 03
06 59 4d 01
00 08 41 01
05 00 50 03
00 00 49 03
.J..g........... ........*?.$Y... ..........DSMAPI ADMINADMIN...... ,.........
All other commands transmitted to the Tivoli Storage Manager server are encrypted. Example 7-42 is a portion of a network trace showing the encrypted command transmitted from the ISC/AC to the Tivoli Storage Manager server to change the node password.
Example 7-42 Encrypted node password change from ISC to Tivoli Storage Manager server
0000 0010 0020 0030 0040 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 00f0
00 a5 4f 7a e6 e0 a2 6f cf 2b 26 d2 4b a7 38 3b
f7 63 98 7c d9 0a 09 20 fd 5b 8d 9b 66 d5 ed cc
f0 b5 9f b2 5f 06 ef 5b 51 70 ba 40 3c c3 65 d3
a5 74 09 68 ab ec 9a 27 6c ca 2f 4f b7 54 b9 b3
00 ef 10 e9 b4 c5 57 36 b5 dd 64 3a c0 7a b3 65
00 d7 3d f2 8a fa 79 6e a8 44 a9 26 cd 48 ca 78
00 5c 6f 84 79 63 48 a1 07 6e 7c f5 25 de 43 5a
ed 09 ab f5 7c c8 89 6f dc 54 2d e9 e1 1b 8a
00 28 87 73 92 b1 1e 6f df a5 1a 20 42 a9 06
00 00 30 89 1b 9b ef a3 86 1f 5e 63 f7 1d e4
1a 86 7b 5b 71 dd 96 1a 5b 70 77 82 06 5d 60
58 c1 a9 9f 65 9c df 48 df 4c d0 c6 59 be 95
8f 40 b5 ef 1c 53 00 66 61 d0 b4 88 b1 d5 82
ec 39 e3 98 13 7c ca 63 f8 61 af fc dd b6 60
f6 e4 cf a5 3b 5f b7 e3 ec fd 2a 67 91 8b 85
20 f7 36 a7 1b 38 b1 ba f6 f8 96 db f6 88 99
...........X... .c.t..\.(...@9.. O....=o..0{....6 z|.h....s.[..... .._...y|..qe..;. ......c.....S|_8 ....WyH......... o ['6n.oo..Hfc.. ..Ql......[.a... +[p..DnT..pL.a.. &../d.|-.^w...*. ..@O:&.. c....g. Kf<...%.B..Y.... ...TzH....]..... 8.e...C...`..`.. ;...exZ
The response back from the server to the ISC is unencrypted, but the Tivoli Storage Manager server hides the password in the response (Example 7-43).
Example 7-43 Node password hidden in server response
0000 0010 0020 0030 0040 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 00f0 0100 0110 0120 ~
01 12 73 73 44 3f 45 43 54 32 31 4f 54 53 3d 4c 41 20 59
23 41 74 75 41 2a 54 4c 3d 2e 20 4c 49 45 31 4c 54 44 20
f1 4e 72 65 54 2a 3d 4f 20 31 56 3d 41 52 39 41 41 41 7e
a5 52 61 64 45 2a 4e 50 55 36 41 4e 54 56 32 44 57 54
03 32 74 20 20 3f 4f 54 52 38 4c 4f 49 45 2e 44 52 41
07 30 6f 63 4e 20 20 53 4c 2e 49 20 4f 52 31 52 49 52
d7 31 72 6f 4f 46 50 45 3d 39 44 53 4e 20 36 45 54 45
02 37 20 6d 44 4f 41 54 68 39 41 45 3d 48 38 53 45 41
0f 49 41 6d 45 52 53 3d 74 2e 54 53 43 4c 2e 53 50 44
09 20 44 61 20 43 53 20 74 32 45 53 4c 41 39 3d 41 50
1e 41 4d 6e 4e 45 45 43 70 33 50 49 49 44 39 31 54 41
19 64 49 64 45 50 58 4f 3a 31 52 4f 45 44 2e 35 48 54
07 6d 4e 3a 4e 57 50 4e 2f 3a 4f 4e 4e 52 32 30 3d 48
e1 69 20 20 59 52 3d 54 2f 31 54 49 54 45 33 31 41 3d
02 6e 69 55 41 45 30 41 31 35 4f 4e 4f 53 31 20 4e 41
01 69 73 50 20 53 20 43 39 38 43 49 52 53 20 44 59 4e
.#.............. .ANR2017I Admini strator ADMIN is sued command: UP DATE NODE NENYA ?***? FORCEPWRES ET=NO PASSEXP=0 CLOPTSET= CONTAC T= URL=http://19 2.168.99.231:158 1 VALIDATEPROTOC OL=NO SESSIONINI TIATION=CLIENTOR SERVER HLADDRESS =192.168.99.231 LLADDRESS=1501 D ATAWRITEPATH=ANY DATAREADPATH=AN Y
209
7.16 Setting up SSL for the ISC/AC

As we discussed in section 7.15.1, Web browser link to ISC/AC on page 207, the ISC/AC does not use encryption, Secure Sockets Layer (SSL), by default for Web browser traffic. This section shows how to enable SSL for the ISC/AC. This information is covered in the Tivoli Storage Manager Administrators Guide for each server operating system platform, but we found that some steps were not fully covered. IBM has also released a Technote #1231106, Enabling the Secure Sockets Layer (SSL) for the Integrated Solutions Console V 6.0.1 Official Certificates, which has an updated procedure. This Technote is available at: http://www-1.ibm.com/support/docview.wss?uid=swg21240020 Note: This procedure is written specifically for using self-signed certificates. If official certificates are required, it is necessary during the key and trust file generation steps to create certificate requests and submit them to a certifying authority.
7.16.1 Overview of the required steps

The steps are: 1. Create the SSL Server/Client key and trust files. 2. Create the JACL script in <isc_root>\AppServer\bin. 3. Modify wsadmin.properties to reflect the correct SOAP port. 4. Run wsadmin on the JACL script. 5. Modify ConfigService.properties. 6. Modify web.xml. 7. Stop the ISC_Portal. 8. Modify the soap.client.props. 9. Start the ISC_Portal. 10.Test your changes.
7.16.2 Create key and trust files

On Windows, the default installation path for the ISC is C:\program files\IBM\ISC601; on UNIX/Linux, it is /opt/IBM/ISC601. For the remainder of this section, <isc_root> refers to the installation path for your system. The ISC/AC includes a key management utility called ikeyman, which is installed in the <isc_root>/AppServer/bin. To launch, change to the correct directory. On Windows, run ikeyman.bat. On UNIX/Linux, execute ./ikeyman.sh. After starting the application, the main window appears, which is shown in Figure 7-23 on page 211.
210
Figure 7-23 ikeyman utility
Create and populate the server key file and trust file
This section describes how to create and import a self-signed server certificate for use with the ISC/AC.
Create the server key file and a new self-signed certificate

The steps are: 1. From the menu bar in ikeyman, select Key Database File New. In Figure 7-24, ensure that the Key database type is set to JKS. Use the directory <isc_root>/AppServer/etc/ and store the key file as ISCServerKeyFile.jks. Note: This is the server key file.
Figure 7-24 Server key file name and location
2. You receive a password prompt as shown in Figure 7-25 on page 212. Enter your password twice and click OK. You need this password in future steps, so remember it.
211
Figure 7-25 Password prompt for server key file
3. Create a new self-signed certificate. Click the icon shown in Figure 7-26 or select Create New self-signed certificate:
Figure 7-26 Create a new self-signed certificate
4. In the menu in Figure 7-27 on page 213, complete the required fields as shown. Click OK when finished.
212
Figure 7-27 Self-signed certificate menu
5. When the certificate is successfully generated, the main menu displays the personal certificate as shown in Figure 7-28.
Figure 7-28 Successful creation of personal self-signed certificate
Extract the server certificate

Now, to extract the public certificate: 1. Click Extract Certificate as shown in Figure 7-29 on page 214.
213
Figure 7-29 Extract Certificate button
2. In the window that appears (Figure 7-30), enter the certificate file name for the extracted server certificate. This certificate file name has an .arm file extension. Enter the file location and click OK.
Figure 7-30 Enter the file name and location for the extracted server certificate
Create and populate the server trust file and import the certificate
Now, create the server trust file: 1. Click Key Database File New, and enter the name ISCServerTrustFile.jks as shown in Figure 7-31. Enter the location and click OK.
Figure 7-31 Setting the name for the server trust file
214
Note: This is the server trust file. 2. As before, you are prompted again for a password. Enter the password twice and click OK. Remember the password for future use (Figure 7-32).
Figure 7-32 Password prompt for the server trust file
3. Next, we import the certificate that we created in Extract the server certificate on page 213. From the main menu, click Add as shown in Figure 7-33.
Figure 7-33 Add a new certificate to the server trust file
4. Choose the certificate that was created in Extract the server certificate on page 213, which is shown in Figure 7-34 on page 216. Click OK.
215
Figure 7-34 Specifying the server certificate to import
5. You need to supply a certificate file name for the certificate to be imported. Use the name ISCIntSec CA. Enter the location. Click OK. After a successful import, the main panel appears as in Figure 7-35.
Figure 7-35 Successful import of server certificate
Create and populate the client key file and client trust file
This section shows how to create the client key file, the client certificate, and the client trust file.
Create the client key file

The steps are: 1. From the main menu, select Key Database File New. See Figure 7-36 on page 217.
216
Figure 7-36 Creating another key file for the client
Note: This is the client key file. 2. In the dialog box that appears, Figure 7-37, enter the file name ISCClientKeyFile.jks, and specify the same directory location as before, which is <iscroot>/AppServer/etc/. Click OK.
Figure 7-37 Enter file name and directory path
3. In the next dialog box, Figure 7-38 on page 218, enter the password and reenter it to confirm. Click OK. As before, remember this password because you will need it in future steps.
217
Figure 7-38 Password prompt
4. As you did for the server key file, create a self-signed certificate. Select Create New self-signed certificate. See Figure 7-39.
Figure 7-39 Create a new self-signed certificate
5. Complete the required fields as shown, using the value ISCIntSecClientKey for the label. Click OK. See Figure 7-40 on page 219.
218
Figure 7-40 Values for the client self-signed certificate
6. After successful creation, the certificate appears in the list of personal certificates as in Figure 7-41.
Figure 7-41 Successful creation of client key
Extract the client certificate

1. From the main menu shown in Figure 7-41, click Extract Certificate.
219
2. In the resulting panel, enter the file name for the exported key; use the name ISCClientKeyFile.arm as shown in Figure 7-42. Enter the location and click OK.
Figure 7-42 File name for exported client key
Create and populate the client trust file

Create the client trust file: 1. From the main menu, click Key Database File New. In the dialog box that appears, enter the name for the new client trust file. Use the name ISCClientTrustFile.jks as shown in Figure 7-43. Enter the location and click OK.
Figure 7-43 File name for client trust file
2. When prompted, supply a password for this client key trust file. Reenter the password and click OK. See Figure 7-44.
Figure 7-44 Password for client key trust file
Note: This is the client trust file. 3. From the main menu, import the client key that was exported in Extract the client certificate on page 219. Click Add in the main menu. In the dialog box that appears, Figure 7-45 on page 221, enter the client key name to import. Enter the location and click OK.
220
Figure 7-45 Selecting the client key to import
4. Enter the name or label to give the certificate. Use ISCIntSec CA as shown in Figure 7-46. Then, click OK.
Figure 7-46 Enter the label for the certificate
7.16.3 Create the JACL script

Next, a script needs to be created in the directory <isc_root>/AppServer/bin. A sample script is shown in Example 7-44 on page 222. The file name of the script needs to be addSSLentry.jacl. The lines in bold in Example 7-44 on page 222 need to be changed to match the directory structure where the script is to be run and to match the passwords used to create the trust certificates in the previous sections.
221
Example 7-44 Sample JACL script
# new SSL entry in the SSL repertoire # setting the security object set security_root [$AdminConfig list Security] # setting the variables for the entry set ssl_alias "DefaultNode/DefaultSSLSettings" set ssl_clientAuthentication [list clientAuthentication false] set ssl_enableCryptoHardwareSupport [list enableCryptoHardwareSupport false] set ssl_keyFileFormat [list keyFileFormat "JKS"] # this next line should be one long line: set ssl_keyFileName [list keyFileName "C:/ISC/AppServer/etc/ISCServerKeyFile.jks"] set ssl_keyFilePassword [list keyFilePassword "<password>"] set ssl_securityLevel [list securityLevel "HIGH"] set ssl_trustFileFormat [list trustFileFormat "JKS"] # this next line should be one long line: set ssl_trustFileName [list trustFileName "C:/ISC/AppServer/etc/ISCServerTrustFile.jks"] set ssl_trustFilePassword [list trustFilePassword "<password>"] # this next line (set ssl def\u2026) should be on ONE line set ssl_def [list $ssl_clientAuthentication $ssl_enableCryptoHardwareSupport $ssl_keyFileFormat $ssl_keyFileName $ssl_keyFilePassword $ssl_securityLevel $ssl_trustFileFormat $ssl_trustFileName $ssl_trustFilePassword] # defining the whole SSL object set ssl_entry [list [list alias $ssl_alias] [list setting $ssl_def] ] # remove existing dummy SSL entry set sslList [$AdminConfig list SSLConfig] $AdminConfig remove [lindex $sslList 0] # creating the new entry $AdminConfig create SSLConfig $security_root $ssl_entry repertoire # setting variables using the new entry set sslList [$AdminConfig list SSLConfig] set default_ssl [list [list defaultSSLSettings [lindex $sslList 0]]] # modifying the security object to use new entry $AdminConfig modify $security_root $default_ssl # saving the configuration $AdminConfig save
7.16.4 Modify wsadmin.properties to reflect the correct SOAP port

The steps are: 1. View the file serverindex.xml in the directory <isc_root>/AppServer/profiles/default/config/cells/DefaultNode/nodes/DefaultNode. Look under the serverEntry stanza, and locate the section with serverName=ISC_Portal.
222
2. Within this section, there is a line with the entry, endPointName=SOAP_CONNECTOR_ADDRESS. Take note of the port that is specified. It is likely to be port 9425. 3. Edit the file wsadmin.properties file in the directory: <isc_root>/AppServer/profiles/default/properties. 4. Change the com.ibm.ws.scripting.port setting to the port number that you located in step 2. As we noted, this is probably port 9425. Save the file.
7.16.5 Run wsadmin on the JACL script

Run wsadmin on the JACL script with the ISC/AC running: Change the directory to the <isc_root>/AppServer/bin directory. Execute the following command for Windows: wsadmin.bat f addSSLentry.jacl user <user ID> -password <password> Or, if you are on a UNIX or Linux host: wsadmin.sh f addSSLentry.jacl user <user ID> -password <password> In each case, use the user ID and password for the ISC/AC (for example, iscadmin/iscadmin). If you are successful, the output message is: WASX7209I: Connected to process "ISC_Portal" on node DefaultNode using SOAP connector; The type of process is: UnManagedProcess
7.16.6 Modify the ConfigService.properties file

To modify the ConfigService.properties file: 1. Open the ConfigService.properties file in the directory <isc_root>/PortalServer/shared/app/config/services/. 2. Locate the following lines: redirect.login.ssl = false redirect.logout.ssl = false 3. Change the two lines in step 2 to: redirect.login.ssl = true redirect.logout.ssl = true 4. Save the file.
7.16.7 Modify the web.xml file

To modify the web.xml file: 1. Change to the directory: <isc_root>/AppServer/profiles/default/config/cells/DefaultNode/applications/wps.ear/deplo yments/wps/wps.war/WEB-INF/ 2. Open the file web.xml. 3. Locate the line <security-constraint id=SecurityConstraint_1> within the file. Beneath this line, there is a stanza with the line: <transport-guarantee>NONE</transport-guarantee>
223
Change this line to: <transport-guarantee>CONFIDENTIAL</transport-guarantee> 4. Save the file.
7.16.8 Stop the ISC portal

To stop the ISC portal: Use the command for Windows: <isc_root>/PortalServer/bin/stopISC.bat ISC_Portal <user ID> <password> Or use the command for UNIX and Linux: <isc_root>/PortalServer/bin/stopISC.sh ISC_Portal <user ID> <password> In these commands, the user ID and the password are the administrator IDs for the ISC/AC (typically iscadmin/iscadmin).
7.16.9 Modify the soap.client.props file

In the directory <isc_root>/AppServer/profiles/default/properties, edit the file soap.client.props. Change the following lines to reflect the locations and and the passwords of the server and client trust files created in Create and populate the server trust file and import the certificate on page 214 and Create and populate the client trust file on page 220: com.ibm.ssl.keyStore=/opt/IBM/ISC6011/AppServer/profiles/default/etc/DummyClientK eyFile.jks com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\= com.ibm.ssl.trustStore=/opt/IBM/ISC6011/AppServer/profiles/default/etc/DummyClien tTrustFile.jks com.ibm.ssl.trustStorePassword={xor}CDo9Hgw\= For example: com.ibm.ssl.keyStore=/opt/IBM/ISC6011/AppServer/etc/ISCClientKeyFile.jks com.ibm.ssl.keyStorePassword=mynewpassword com.ibm.ssl.trustStore=/opt/IBM/ISC6011/AppServer/etc/ISCClientTrustFile.jks com.ibm.ssl.trustStorePassword=mynewpassword Save the file.
7.16.10 Start the ISC/AC

Start the ISC portal. Issue: <isc_root>/PortalServer/bin/startISC.bat ISC_Portal (Windows) or <isc_root>/PortalServer/bin/startISC.sh ISC_Portal (UNIX and Linux) Watch for any error messages. A successful start shows messages similar to the following: ADMU0116I: Tool information is being logged in file 224
/opt/IBM/ISC6011/AppServer/profiles/default/logs/ISC_Portal/startServer.log ADMU0128I: Starting tool with the default profile ADMU3100I: Reading configuration for server: ISC_Portal ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server ISC_Portal open for e-business; process id is 9674 If it starts successfully, launch a web browser and go the ISC/AC URL: http:<servername_or_ip>:8421/ibm/console You will likely receive warnings regarding the validity of the SSL certificate for the self-signed certificates; these warnings can be safely ignored. If everything is correct, your browser is redirected to an SSL connection on port 8422 as shown in Figure 7-47 (Firefox browser shown).
Figure 7-47 URL for successful SSL connection
Also, in the lower right corner of the browser, you see the small lock symbol indicating an SSL session (Figure 7-48).
Figure 7-48 SSL-enabled session indicator
225
226
Chapter 8.
Storage pool considerations

In this chapter, we provide a brief introduction to the three types of Tivoli Storage Manager storage pools. We then provide general information about how data is stored in the volumes within a disk storage pool or a tape storage pool. We show you how unencrypted data can potentially be accessed within these pools. We then discuss the important role of encryption in securing your data in the storage pools. Next, we describe data shredding, which is a way to destroy the physical data from volumes by overwriting the data multiple times after the data is deleted from Tivoli Storage Manager. Finally, we present advice about how to secure your storage pool volumes.
227
8.1 Storage pool overview

A storage pool is a group of volumes. Storage pool volumes are the basic units used by Tivoli Storage Manager to store the clients backed up, archived, or space-managed data. A volume can be allocated space on disk or a tape cartridge. Storage pools collectively are known as server storage and can be set up hierarchically. There are three types of storage pools in Tivoli Storage Manager: Primary storage pools Copy storage pools Active-data storage pools Note: This section is a brief overview only. See Chapter 10. Managing Storage Pools and Volumes in the IBM Tivoli Storage Manager Administrators Guide for your server platform for more detailed information about storage pools and volumes. You also can read about this topic in general in IBM Tivoli Storage Management Concepts, SG24-4877, and IBM Tivoli Storage Manager Implementation Guide, SG24-5416.
8.1.1 Primary storage pools

Primary storage pools are always located on-site. If a client requests to restore or retrieve a file, the file is obtained from a primary pool first, if it is possible. Archived, backed up, or space-managed files can be in the same or different primary storage pool, depending on your design. Data can be moved through multiple storage pools in the hierarchy through the migration process.
8.1.2 Copy storage pools

Copy storage pools can use only sequential-access storage, such as tape devices or FILE
class devices. Copy storage pools provide an extra level of backup for data in case the primary volume, for example, a tape catridge, is lost or damaged. Typically, you can move copy storage pool volumes off-site to provide a means of recovering from a disaster at the on-site location.
8.1.3 Active-data storage pools

Active-data storage pools contain only active data. If a version of a file is updated, the older
version is deactivated and is removed during the next reclamation process. Active-data storage pools can use any type of sequential-access storage, such as a tape device class or FILE device class. Active-data storage pools associated with a FILE device class are ideal for fast restores because all date is on disk, no mounts are required, and the server does not have to position past inactive files.
8.2 How is data written to storage pools

We conducted a few tests to see what can be read from both disk and tape volumes, using this as a basis for how you can increase the security of your data.
228
8.2.1 Disk storage pool volume

To show how data is stored in a DISK device class, we created a single small text file as shown in Example 8-1. We then backed this file up to a Tivoli Storage Manager server.
Example 8-1 Content of test.txt
D:\TESTFILES>more test.txt this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. D:\TESTFILES> We use QUERY BACKUP on the client to check that the file is backed up, as shown in Example 8-2.
Example 8-2 Output of QUERY BACKUP
tsm> q backup "D:\TESTFILES*" -detail Size Backup Date Mgmt Class A/I File ----------------------- --- ---134 B 01/30/2007 21:19:31 DEFAULT \\server\d$\TESTFILES\test.txt Modified: 01/30/2007 21:11:07 Created: 01/30/2007 21:09:21 The backup was stored on a storage pool with the device class of DISK. We opened the volume in the storage pool where the file was stored in an ASCII viewer, as in Example 8-3. Note: This test can only be done by a user ID with read permissions to the actual file, so an important point here is to make sure that read permissions are restricted on the disk storage pool volumes. In general, only the user ID, which is running the Tivoli Storage Manager server process, requires read and write access. All other access should be disabled. See Storage pool volume permissions on page 235 for more information.
Example 8-3 Content of a DISK storage pool volume
SERVERWinNTSTANDARD\\server\d$\TESTFILES\TEST.TXTSTANDARDDEFAULT I Dq DPDPd6> D ~ ) 0 L ZA`7e2 ZA`7e2 X $ ZA`7e2 this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test.RFES As you can see, the content of our text file is quite readable.
Chapter 8. Storage pool considerations
229
Now, this is just a small example and in practice it is not so simple. Typical disk storage pool volumes are large with hundreds or thousands of files. Files can span across multiple storage volumes and can be interspersed with image and other application-type backups, as well as sub-file backups. Use of differential backups also makes the data harder to interpret. In particular, we do not want to suggest that there is a reliable method for recovering data from the storage pools in the event that the Tivoli Storage Manager server database is unavailable. There is no substitute for adequate protection of the database volumes themselves combined with regular database backups. Nevertheless, someone with enough time and expertise can scan storage pool volumes and extract at least some data. Even if it is not feasible to browse byte by byte through the file, someone with file access can also search for likely text within the volume, even while Tivoli Storage Manager is running. See Example 8-4. So, it is possible to expose some information, which you do not want to make available, in the disk storage pools. For this reason, encryption is essential to ensure security of the data, which we discuss in 8.3.1, Tivoli Storage Manager client encryption on page 236 and later in 5.1.1, Encryption of session traffic on page 82.
Example 8-4 Searching within a disk storage pool volume while Tivoli Storage Manager is running
D:\tsmdata\server1>find "this is a test" disk1.dsm ---------- DISK1.DSM this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test.RFES?
8.2.2 Tape storage pool volume

Here are several tests to show what you might potentially read from a Tivoli Storage Manager backup tape. All of these tests are for an incremental backup, using only small files, to a scratch tape. So the data was written sequentially onto a single tape. In an actual production environment, the data is not so neatly laid out as in our tests. Because files can span over different tape volumes. Also, the presence of other data formats, such as NDMP, image backups, sub-file backups, and a mixture of incremental and differential backups, also make the data harder to isolate and extract. Nevertheless, as we have said before, we want to again emphasize the necessity of using encryption in order to securely protect data. Our tests were done on an IBM LTO tape drive, which at the time of writing this book, does not provide hardware encryption capabilities; however, hardware encryption capabilities will be provided in the near future. Note: These tests can only by done by someone, who has sufficient access to mount and read tape volumes, or who has stolen a tape volume. Throughout this book, we stress the importance of restricting the number of trusted users in your environment to a minimum and of providing secure tape storage and transport facilities.
230
Test one: Simple text files

In this test, we back up four files to a tape storage pool. To show the effect of encryption and Tivoli Storage Manager client compression, we used four simple text files, which were backed up with the following characteristics: D:\TESTFILES\TEST.TXT (unencrypted and uncompressed) D:\TESTFILES\TEST_BOTH.TXT (Tivoli Storage Manager client encryption and client compression) D:\TESTFILES\TEST_COMPRESSION.TXT (unencrypted and client compression) D:\TESTFILES\TEST_ENCRYPTION.TXT (Tivoli Storage Manager client encryption and uncompressed) After the backup was complete, we simulated how someone might try to read the tape: either from a host in the enterprise network with visibility to the the tape device, or, assuming the cartridge was stolen, in another compatible tape drive. Because this is an IBM LTO tape, we use tapeutil (which is included with the device drive) to read sequentially through the tape. The output of each read operation was written to a text file. Tivoli Storage Manager has used this tape one time to back up the four files that we listed above. We can extract three separate files using tapeutil. On the fourth read iteration, we got an error indicating that the end of the valid data had been reached, as shown in Example 8-5.
Example 8-5 Reading from a tape volume using tapeutil and the final read fails at the end of the data
Select (1=Read file from tape, 2=Write file to tape): 1 Enter Destination File: /test/4.txt Enter number of records to read or <enter> for entire file: Opening destination file /test/4.txt... Querying tape parameters... Setting block size to variable... Reading file from tape... Read terminated, 0 records, 0 total bytes read... Operation failed with errno 5: I/O error Residual count: 1048576 Error Sense Data, Length 36 0123456789ABCDEF [...............] [ t..............] [... ]
0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 - F000 0800 1000 001C 0000 0000 0005 0000 0010 - 2074 000C 0000 0000 0000 0000 0000 0000 0020 - 06EA 0000
Hit <enter> to continue... The three files extracted using tapeutil looked like this: First file This probably was the tape header. See Example 8-6 on page 232.
231
Example 8-6 First file, which was probably tape header
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ KK@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Second file This file is data, and it is the actual data content of the storage pool. See Example 8-7. We can see each file name and directory highlighted, but only the first unencrypted and uncompressed file shows any readable text. We conclude that any combination of client encryption or compression makes the data unreadable.
Example 8-7 Second file: contents of the Tivoli Storage Manager storage pool
ZMNP SEFR b D. [ " + < D I I 3 SERVERWinNTFILE\\SERVER\d$\TESTFILESSTANDARDIMAGE J 0 0 ` NYraND#N+pr6L D 0 0 ` 1zl(0{ q 1zl(0{ L ! f " 5 E M T T 3 SERVERWinNTFILE\\SERVER\d$\TESTFILES\TEST.TXTSTANDARDDEFAULT I D 0 0 ` NN6N6L D 0 0 ` 1zl(0{ q 1zl(0{ L ! this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test.k " 5 J R Y Y 3 SERVERWinNTFILE\\SERVER\d$\TESTFILES\TEST_BOTH.TXTSTANDARDDEFAUL T I D 0 0 ` Nn N*=]N6L D usYD 0r=8F Ez<`%kH 96 )UN !'hiP; 9w2=)f^n,<e9@W]6-->}EI#+ &+VmWng$cDF }-^ }FJxZ`+O!)(V|[;X?2BUk|-P*"!0 n(h9&?J`b Tr(zTU\/8kS^J~/+ ,[ *-NG ~J;7 Y%\Mu\f]B <|vW%I (M__6r " 5 Q Y ` ` 3 SERVERWinNTFILE\\SERVER\d$\TESTFILES\TEST_COMPRESSION.TXTSTANDAR DDEFAULT ~I D 0 0 ` NNN96L D H 9C 9,Hb T X@ =lB= @ Pb,G"I@@'
232
B _ zfA: %2`B_ q1D4s@2sh }\n^~&lqW{9b9< KoZshAZeMYh _zxO|6pIC-a+^;#n];|:z?=w_{ `yX !|w -X=x`ga6X2H!"xaJ!*:b.*2zH&c3b#6 cAx$D&"H1FcJV$RhCry^fV6%S~yfikfmq " 5 P X _ _ 3 SERVERWinNTFILE\\SERVER\d$\TESTFILES\TEST_ENCRYPTION.TXTSTANDARD DEFAULT I D 0 0 ` NCkNNeN6L D usYD 0r=8F Ez<`%kH 96 )UN !'hiP; 9w2=)f^n,<e9@W]6-->}EI#+ &+VmWng$cDF }-^ }FJxZ`+O!)(V|[;X?2BUk|-P*"!0 n(h9&?J`b Tr(zTU\/8kS^J~/+ ,[ *-NG ~J;7 Y%\Mu\f]B <|vW%I (M__6SEFR Third file This is the end of the tape. See Example 8-8.
Example 8-8 Third file, which is the end of the data
KK@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Other tools, such as tctl, dd, and cpio, were also not able to read beyond the end of data (EOD) mark.
Example 8-9 Error with cpio reading beyond EOD marker
root@server:/home/root 167$ cpio -itv </dev/01_00 cpio: End of tape, insert the next tape. Enter the device or file name when ready to continue.
Test two: Application format files

Our next small test was for non-text application data, for example, Microsoft Word. For this test, we created a small file using text formatting and a table. The source file is listed in Figure 8-1 on page 234 and in binary format in Example 8-10 on page 234.
233
Figure 8-1 Word.doc Example 8-10 A part of word.doc in HEX/binary
00000a00:54 00000a10:69 00000a20:2e 00000a30:70 00000a40:07 00000a50:64
68 73 0d 6f 07 20
69 20 54 72 33 6f
73 69 61 74 07 66
20 73 62 61 34 20
69 20 6c 6e 07 64
73 75 65 64 35 6f
20 6e 3a 07 07 63
62 64 0d 64 36 75
6f 65 76 61 07 6d
6c 72 65 74 37 65
64 6c 72 61 07 6e
2e 69 79 07 07 74
0d 6e 07 31 0d 2e
54 65 69 07 45 0d
68 64 6d 32 6e 00
This is bold..Th is is underlined ..Table:.very.im portant.data.1.2 ..3.4.5.6.7...En d of document...
Again, we back up the file to an unencrypted tape volume. We used no Tivoli Storage Manager client encryption or compression for this test. We read the content of the tape using tapeutil as in Test one: Simple text files on page 231. By investigating, we learn that Word documents appear to start and end with a specific pattern, as shown in Example 8-11 and Example 8-12. For example, you can easily search for .doc files in the dumped tape content. Therefore, we can search for these strings in the extracted file.
Example 8-11 Beginning of a Word document in HEX
00000000:d0 00000010:00 00000020:06 00000030:26 00000040:01 00000050:ff
cf 00 00 00 00 ff
11 00 00 00 00 ff
e0 00 00 00 00 ff
a1 00 00 00 fe ff
b1 00 00 00 ff ff
1a 00 00 00 ff ff
e1 00 00 00 ff ff
00 3e 00 00 00 ff
00 00 00 10 00 ff
00 03 00 00 00 ff
00 00 00 00 00 ff
00 fe 01 28 25 ff
00 ff 00 00 00 ff
00 09 00 00 00 ff
00 00 00 00 00 ff
.......... ........>..... ................ &...........(... ........%...
Example 8-12 End of a Word document in HEX
00005420:4d 00005430:20 00005440:00 00005450:00 00005460:00
69 57 00 57 f4
63 6f 00 6f 39
72 72 4d 72 b2
6f 64 53 64 71
73 2d 57 2e 00
6f 44 6f 44 00
66 6f 72 6f 00
74 6b 64 63 00
20 75 44 75 00
4f 6d 6f 6d 00
66 65 63 65 00
66 6e 00 6e 00
69 74 10 74 00
63 00 00 2e 00
65 0a 00 38
Microsoft Office Word-Dokument.. ...MSWordDoc.... .Word.Document.8 .9 q..........
There are a few more lines with 00 only, but these are not necessary to re-create the document. To recover the file, we copied the text between the header and footer from the file that was extracted off of the tape and saved this file as a Word document, for example, e.g. 234
extractedtext.doc. We then opened this file in Word and learned that we can then see the contents of the file in the same way as the original.
Conclusions
Obviously, this is a fairly simplistic test: using one common application and we already knew what we were looking for. It is likely that other applications have standard header and footers for which someone can scan. In this way, a determined intruder with enough effort can likely retrieve at least some data from storage pool disk or tape volumes if the data is unencrypted and uncompressed. Therefore, we strongly recommend that you do not back up data in the clear. Use at least either (or both) client encryption or compression to increase the security of the data. During the test, we observed that for efficiency reasons Tivoli Storage Manager client compression is not used for files smaller than approximately than 2 Kb. So note that extremely small files are not protected by client compression.
Client compression as opposed to tape compression

We saw that backing up data using Tivoli Storage Manager client compression rendered the data unreadable on the tape. What about tape compression? All tape drives are able to compress data as it is written. First from an efficiency standpoint, having the tape compress data, which has already been compressed at the client, provides no space saving benefit. More importantly, tape compression does not improve data security because when reading back a tape that has been compressed by the hardware, the device driver simply (helpfully) uncompresses it for you.
The role of tape encryption

If you use tape hardware encryption, such as the encryption that is provided by the IBM System Storage TS1120 Tape Drive (see Chapter 6, TS1120 Tape encryption on page 113), data cannot be read from the tape without the encryption key. If you read the tape on the same tape library where it was written, the configuration of the library attempts to decrypt the tape. However, if the tape is stolen, it cannot be decrypted on any other device. Therefore, using tape hardware encryption protects you against anyone who steals the tape, but not from a rogue employee or anyone who has access to the original tape library to mount and read the tape. Note that if you are using tape encryption only, and the data is first written to a primary storage pool on disk, the data is not encrypted until it reaches the tape and is, therefore, potentially vulnerable in the disk storage pool.
Storage pool volume permissions

Of course, you need the correct permissions to even read the contents of a storage pool volume. Typically, when these volumes are created, they need to be owned by the process that created them, for example, the user ID running the dsmserv process if you format the volume at the time of creation with Tivoli Storage Manager. Normally, only this user ID requires read access. Therefore, you must check the ownership of these volumes, and we recommend that you disable read and write access from any user ID except the user ID that runs the Tivoli Storage Manager server. See 10.11, Tivoli Storage Manager server running as a non-root user on page 279 for a procedure to run your Tivoli Storage Manager server as another user ID. Similarly for tape volumes, physical access to the volumes and tape drives must be tightly controlled.
235
8.3 Encrypted data in storage pools

This section helps you to understand the effects of encryption, as previously described on the security of the data in storage pools. As we have already seen in Part 2, Encryption on page 79, there are two encryption techniques available today with Tivoli Storage Manager: client (software) encryption and tape (hardware) encryption.
8.3.1 Tivoli Storage Manager client encryption

Tivoli Storage Manager client encryption (see Chapter 5, Tivoli Storage Manager client data encryption on page 81) is a function of the client software. By default, client backup/archive data is sent unencrypted over the network to the Tivoli Storage Manager server. The data is then stored unencrypted in the storage pools. As we saw in Example 8-3 on page 229, the data is readable with a normal ASCII or HEX viewer. To enhance security, you can enable client encryption to transmit and save your data encrypted on the Tivoli Storage Manager storage pool volumes. When you use client encryption, the contents of the file are no longer readable in the Tivoli Storage Manager storage pool volume, as shown in Example 8-13. Example 8-13 represents the same file backed up that we showed in Example 8-3 on page 229, but this time, the file was backed up with client encryption.
Example 8-13 Content of a DISK storage pool volume with encrypted file
SERVERWinNTSTANDARD\\server\d$\TESTFILES\TEST.TXTSTANDARDDEFAULT I e Dq J DPd6> D &G*z?-SPZtnzfQlFPia~}}{ a/76 OR <9r } :|/u[ry'mA$M O7R"J5&r,&{w< gj"nbuY$VCeR k>Zd=6:410>xkhDTTj31w78>Ic~2]So](]+92 7H 5:\nCjq9 gl8hl#"Bw<I[X(mF28[Jk>O[~ _I;-u/RFES Furthermore, you cannot search for the content of the backup file by using the find command. See Example 8-14.
Example 8-14 Using the find command to find contents of a backup file in the disk storage pool
D:\tsmdata\server1>find "this is a test" disk1.dsm ---------- DISK1.DSM D:\tsmdata\server1> But, you can still find the filename and directory as shown in Example 8-15 on page 237.
236
Example 8-15 Using the find command on a file name
D:\tsmdata\server1>find "TEST.TXT" disk1.dsm ---------- DISK1.DSM SERVERWinNTSTANDARD\\byzzkt\d$? ? DDEFAULT ? D:\tsmdata\server1>
\TESTFILES\? ?
TEST.TXT? ?
STANDAR
8.3.2 Tivoli Storage Manager tape encryption usage

Tape encryption is hardware-based. When Tivoli Storage Manager writes data to an encryption capable tape drive, the data is encrypted while writing it to tape. See Chapter 6, TS1120 Tape encryption on page 113 for more information. You cannot retrieve any data from backed up files (including the directory names or file names) from an encrypted tape, unless you have the key.
8.4 Data shredding

Shredding is the destruction of deleted data to make it difficult to discover and reconstruct that data later. Tivoli Storage Manager V5.4 and above support shredding data in random-access disk storage pools. You can shred sensitive data either automatically or manually.
Without shredding, after client data has been deleted, for example, if it has expired from the Tivoli Storage Manager database, or by using a DELETE FILESPACE command, it might still be possible to recover the client data if you have the time and advanced tools. For sensitive data, this condition is a potential security exposure. The destruction of deleted data, also known as shredding, lets you store sensitive data so that it is physically overwritten one or more times after it is deleted. This process greatly increases the difficulty of discovering and reconstructing the data later. Tivoli Storage Manager performs shredding only on data in random-access disk storage pools. You can configure the server to ensure that sensitive data is stored only in storage pools in which shredding is enforced (shred pools). Shredding occurs only after a data deletion commits and will take some time to complete after it is initiated. The space that is occupied by the data to be shredded remains occupied while the shredding takes place and is not available as free space for new data until the shredding is complete. Shredding performance is affected by the amount of data to be shredded, the number of times that data is to be overwritten, and the speed of the disk and server hardware. You can specify that the data is to be overwritten up to 10 times. The more times that the data is overwritten, the greater security you have, but also the greater the impact on server performance. We strongly recommend that write caching is disabled for any disk devices used to store sensitive data, because caching adversely affects shredding performance. For performance reasons, you need to also use Tivoli Storage Manager policy to ensure that only data that really needs to be shredded is written to shreddable storage pools. In general, one shredding pass is sufficient in most circumstances. The first pass overwrites data so that it cannot be recovered by typical software-based forensic discovery tools. Performing additional shredding passes provides additional protection only against the use of specialized hardware or firmware forensic tools. The incremental benefit of each additional pass is less than linear; however, the performance overhead and degradation of each pass is
237
linear; that is, the first shred pass of a specific amount of data takes about twice the time it took to originally back up the data, two shred passes about three times, and so on. Shredding can be done either automatically after the data is deleted or manually by command. The advantage of automatic shredding is that it is performed without administrator intervention whenever deletion of data occurs. This limits the time that sensitive data might be compromised. Automatic shredding also limits the time that the space used by deleted data is occupied. However, the automatic shredding might impact server performance. Specifying manual shredding allows it to be performed when this process does not interfere with other server operations.
8.4.1 Why use data shredding

When Tivoli Storage Manager expires data, the server database reference to the location of the object within the storage pools is deleted. By default, Tivoli Storage Manager does not physically delete the data, which therefore still exists on the volume or tape cartridge. When you set up a storage pool for data shredding, the data is physically overwritten on the disk on the next run of the SHRED DATA command, or as soon as possible, if the SHREDDING parameter is set to AUTOMATIC. Using shredding for sensitive data enforces the datas physical deletion from Tivoli Storage Manager storage volumes. Good candidates for data shredding are data that is not encrypted, confidential data, or data, which is required by your security policy to be deleted permanently after it expires. Figure 8-2 shows before and after illustrations for data that is deleted from a shreddable storage pool.
Shreddable Storage Pool

a b a b b a a b
Shreddable Storage Pool

a b b a
b a
b c
Object a deleted/moved
b a
b c
Database references to object a Database Database
Database references deleted and object a overwritten
Figure 8-2 How data shredding works
A test scenario without shredding

We first deleted a previously backed up client node, which was called SERVER, as in Example 8-16 on page 239. You can see the database has no record of the data.
238
Example 8-16 Deleting all file spaces
tsm: TSM01>del files SERVER * ANR2238W This command will result in the deletion of all inventory references to the data on file spaces that match the pattern * (fsId=3) for node SERVER , whereby rendering the data unrecoverable. Do you wish to proceed? (Yes (Y)/No (N)) y ANS8003I Process number 10 started. tsm: TSM01>q files ANR2034E QUERY FILESPACE: No match found using this criteria. ANS8001I Return code 11. However, viewing the disk volume, you can see the data as shown in Example 8-17. At some stage, the space in the volume is overwritten with new data but this might not happen for some time.
Example 8-17 Content of disk1.dsm after deleting the file space
SERVERWinNTSTANDARD\\server\d$\TESTFILES\TEST.TXTSTANDARDDEFAULT I Dq DPDPd6> D ~ ) 0 L ZA`7e2 ZA`7e2 X $ ZA`7e2 this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test.RFES
8.4.2 Setting up shredding

This section describes how to configure Tivoli Storage Manager so that data, which is identified as sensitive, is stored only in storage pools that enforce shredding after that data is deleted. The process is: 1. Specify that you want data to be shredded either automatically after it is deleted or manually by an administrator. You specify how shredding is to be done using the SHREDDING server option in dsmserv.opt. shredding automatic You can also set the shredding option dynamically by using the SETOPT command. See Example 8-18.
Example 8-18 Setting shredding dynamically to manual
tsm: TSM01>setopt shredding manual Do you wish to proceed? (Yes (Y)/No (N)) y ANR2119I The SHREDDING option has been changed in the options file.
2. Set up one or more random access disk storage pool hierarchies that will enforce shredding and specify how many times the data is to be overwritten after deletion. This is
239
shown in Example 8-19, where we define two shredding pools so that shreddingpool_1 migrates to shreddingpool_2.
Example 8-19 Define a hierarchy of shredding pools
tsm: TSM01>define stgpool shreddingpool_2 disk shred=3 ANR2200I Storage pool SHREDDINGPOOL_2 defined (device class DISK). tsm: TSM01>define stgpool shreddingpool_1 disk shred=1 nextpool=shreddingpool_2 ANR2200I Storage pool SHREDDINGPOOL_1 defined (device class DISK).
Note the use of the SHRED parameter, which indicates how many times the data is to be overwritten. You can set the SHRED parameter to any value from 1 to 10. If the value of SHRED is 0, which is the default, no shredding is performed. Caching is not allowed on a shreddable pool. Therefore, the CACHE parameter must be set to NO on the storage pool. 3. Define volumes to those pools and specify disks for which write caching can be disabled, as in Example 8-20.
Example 8-20 Define volumes in shredding pools
tsm: TSM01>define volume shreddingpool_2 d:\tsmdata\server1\shred_2.dsm formatsize=10 ANR2491I Volume Creation Process starting for D:\TSMDATA\SERVER1\SHRED_1.DSM, Process Id 13. ANS8003I Process number 13 started. In the activity log, you see the messages shown in Example 8-21.
Example 8-21 Activity log messages
ANR2206I Volume D:\TSMDATA\SERVER1\SHRED_1.DSM defined in storage pool SHREDDINGPOOL_2 (device class DISK). (SESSION: 23, PROCESS: 13) ANR0986I Process 13 for DEFINE VOLUME running in the BACKGROUND processed 1 items for a total of 10,485,760 bytes with a completion state of SUCCESS at 20:25:51. (SESSION: 23, PROCESS: 13) ANR1305I Disk volume D:\TSMDATA\SERVER1\SHRED_1.DSM varied online. (SESSION: 23, PROCESS: 13) 4. Similarly, we define a volume in the shreddingpool_1 called shred1.dsm. The output is the same as in Example 8-24 on page 242. define volume shreddingpool_1 d:\tsmdata\server1\shred_1.dsm formatsize=10 5. Define and activate a policy for the sensitive data, as in Example 8-22. The policy binds the data to a management class whose copy groups specify the shred storage pools.
Example 8-22 Set up the policy to use shredding
tsm: TSM01>define domain shredding ANR1500I Policy domain SHREDDING defined. define policyset shredding shredding ANR1510I Policy set SHREDDING defined in policy domain SHREDDING. tsm: TSM01>define mgmtclass shredding shredding shredding
240
ANR1520I Management class SHREDDING defined in policy domain SHREDDING, set SHREDDING. tsm: TSM01>define copygroup shredding shredding shredding type=backup destination=shreddingpool_1 ANR1530I Backup copy group STANDARD defined in policy domain SHREDDING, set SHREDDING, management class SHREDDING. tsm: TSM01>define copygroup shredding shredding shredding type=archive destination=shreddingpool_2 ANR1535I Archive copy group STANDARD defined in policy domain SHREDDING, set SHREDDING, management class SHREDDING. tsm: TSM01>assign defmgmtclass shredding shredding shredding ANR1538I Default management class set to SHREDDING for policy domain SHREDDING, set SHREDDING. tsm: TSM01>validate policyset shredding shredding tsm: TSM01>activate policyset shredding shredding Do you wish to proceed? (Yes (Y)/No (N)) y ANR1514I Policy set SHREDDING activated in policy domain SHREDDING. 6. Identify those client nodes whose data must be shredded after deletion and assign them to the new domain. We redefined the node to Tivoli Storage Manager. update node SERVER domain=shredding 7. We now write data in the shredding storage pool by running a backup from the client node. 8. We then delete it from the Tivoli Storage Manager database using the DELETE FILESPACE command. However, the data can still be seen in the storage pool volume, as shown in Example 8-23.
Example 8-23 Contents of storage pool before shredding
SEFR^B ÂÂ+Â'Â,+^B^D^D^CÔ^DÂ^S^Z=^GD^DH|^D^G+^S^M4Â-FREDAIXSTANDAR D/usr/tivoli/tsm/client/ba/bin/test.txtSTANDARDDEFAULTroot^G ^Vf^LÂM-^@^BIÔ ^GÂPM-^^M-ÂE=E=E= ^DM-^@^CÔ^D^BM-^@this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. this is a test. SEFR^B ^BÂ'TANDARÔÂ^FÔ+'^P^FÔ=ÂmÊÔ^BÊ^P^D^BÔ^P^NARCHIVEPOOLÊ^P^X
9. Now, we shred the data to overwrite it in the storage pool. Because we specified to use manual shredding with the SHREDDING server option, in Example 8-18 on page 239, we start the shredding process with the SHRED DATA command. This command lets you specify how long the process runs before it is cancelled (the default is to allow the process to run until all of the data is shredded) and how the process responds to an I/O error during shredding. See the Administrators Reference for your server platform for full details of the syntax and these options. For objects that cannot be shredded, the server reports each object.
241
SHRED DATA DURATION=20 To monitor the data shredding process and to see how much data is waiting to be shredded, use the QUERY SHREDSTATUS command. The server reports a summary of the number and size of objects waiting to be shredded. More information is displayed if the QUERY SHREDSTATUS FORMAT=DETAILED command is used. Example 8-24 and Example 8-25 show the output of the QUERY SHREDSTATUS FORMAT=DETAILED command when shredding is not running and is running.
Example 8-24 Query shredding status with manual shredding and no SHRED DATA is running
tsm: TSM01>query shredstatus format=detailed Shredding Active: Objects Awaiting Shred: Occupied Space (MB): Data Left To Shred (MB): No 206 7 20
Example 8-25 Query shredding status with manual shredding and SHRED DATA is running
tsm: BY-TSM01>query shredstatus format=detailed Shredding Active: Objects Awaiting Shred: Occupied Space (MB): Data Left To Shred (MB): Yes 94 4 12
When the data shredding process completes, a message is issued in the activity log, Example 8-26, that reports the amount of data that was successfully shredded and the amount of data that was skipped, if any.
Example 8-26 Result of shredding in activity log
ANR1326I Shredding process complete after shredding 6,916,840 bytes and skipping 0 bytes. If automatic shredding is used, it starts automatically when shreddable data is deleted. When shredding starts, you see this activity log message: ANR1329I Automatic shredding started When shredding ends, you see this message in the activity log: ANR1327I Automatic shredding stopped. Total bytes shredded was 6,916,840 and total bytes skipped was 0 bytes 10.Finally, we looked through the contents of the storage pool volume. After shredding, we can no longer see any intelligible data, as in Example 8-27.
Example 8-27 Contents of the storage pool volume after shredding
^_^BSEFR^D ÂÂ+Â'^DM-^[+i^\+bSf;eF8B$e^Nt"Uz.-M-^P^B9% N-kG^^ynM-^G= @-FM-^Y=M-^Nj(,M-^P^?b{=M-^B_G++Êb H(eM-^QB^W^L^N^C/"M-^Lq$.^LM-^Z^B^PMNpx~GÛM-^S2nM-ÂV--XZM-^N{,|cL|M^R"M-^BM-^C7++-M-^Z+bAeM-^H^ZgB-^S ^N+(i"pM-^MH.-:[^BM-^GtqNM-^TKM-^YGM-^L)(nI H-+M-^^M-^N^LM-^PH>(T 'QM-^B^?^X+<M-^Seb|eTM-^V+_^N%^Fd"ja.^NG~^Be^P+N+Gd M-^CM-^HvnjM-^Jn-[QpM-^N^]_=UM-^MB=LM-^BQaa+-^G+b/P9e-V+B-$^NM"^Q+Ê.-_M-^ Q^B+7NvChG^K%n^KM-^D5-b pM-^N+8RM-^B^?-^RM-^Bx^Yi+M-^^6^Gb=M-^Re+M-^Z-B^VO^NG^KB"Fe=.^Pk^B<=tNFG 242
?~n,!M-^X-TdM-^N+?+^C9=M-^@^]}M-^B^_d^[+M-ÔaTb^](^De^LsBW^N^X^?X"?^D.-^V
8.4.3 Storage pool shredding considerations

At the time of writing this book, there are several current limitations for disk storage pool shredding: Only storage pools with a device class of DISK can be shredded. Centera and Snaplock storage pools do not allow shredding. If you enable shredding on a storage pool by specifying a SHRED value greater than zero, the value of the CACHE parameter must be NO. See Example 8-28.
Example 8-28 Cache must be NO when SHRED value is greater than 0
tsm: TSM01>upd stgp SHREDDINGPOOL_2 cache=yes ANR2588E UPDATE STGPOOL: Storage pool "SHREDDINGPOOL_2" cannot have CACHE set to YES with a non zero SHRED attribute. ANS8001I Return code 3. You can set the NEXTPOOL parameter for a shredded pool to point to a non-shredding pool. This might be a random access pool without shredding defined or a sequential access pool, which is incapable of data shredding. If you set the NEXTPOOL to one of these types of pools, only data actually on the shreddable pool is shredded when eligible. You get a warning message when a shreddable pools NEXTPOOL parameter is set to point to a non-shreddable pool, as in Example 8-29.
Example 8-29 NEXTPOOL pointing to a sequential access pool warning message
tsm: TSM01>def devc non_shredding devt=file mountl=2 maxcap=10M dir=D:\tsmdata\server1 ANR2203I Device class NON_SHREDDING defined. tsm: TSM01>def stgp NON_SHREDDING NON_SHREDDING maxscratch=1 ANR2200I Storage pool NON_SHREDDING defined (device class NON_SHREDDING). tsm: BY-TSM01>upd stgp SHREDDINGPOOL_2 next=NON_SHREDDING ANR1309W Shred value zero for storage pool NON_SHREDDING may render deleted data non shreddable. ANR2202I Storage pool SHREDDINGPOOL_2 updated. When data on a shreddable pool migrates to the next storage pool in the storage hierarchy, when the migration is complete, the data in the source storage pool is shredded. As we just saw, the NEXTSTGPOOL of a shreddable pool does not have to be another shreddable pool. If the storage pool specified in NEXTSTGPOOL is a non-shreddable pool, the server does not print any warning message during the migration. This situation is typically the case if the NEXTSTGPOOL points to a pool using tape.
Backing up or moving data from a shreddable pool

Data in a shreddable pool can be backed up to a copy storage pool with the BACKUP STGPOOL command or moved with the MOVE DATA command. If the destination is a non-shreddable pool, you must specify SHREDTONOSHRED=YES to force the backup to occur, as in Example 8-30 on page 244.
243
If the SHREDTONOSHRED keyword is not specified, the default value is NO and the server prints an error message and does not allow the backup, as in Example 8-31 on page 244. When the command is complete, the original data has been shredded.
Example 8-30 MOVE DATA with shredtonoshred=yes
tsm: TSM01>move data D:\TSMDATA\SERVER1\SHREd_1.dsm stgp=DISKPOOL shredtonoshred=yes ANR2233W This command will move all of the data stored on volume D:\TSMDATA\SERVER1\SHRED_1.DSM to other volumes in storage pool DISKPOOL; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANS8003I Process number 19 started.
Example 8-31 MOVE DATA without shredtonoshred default, which is no
tsm: BY-TSM01>move data D:\TSMDATA\SERVER1\SHREd_1.dsm stgp=DISKPOOL ANR2233W This command will move all of the data stored on volume D:\TSMDATA\SERVER1\SHRED_1.DSM to other volumes in storage pool DISKPOOL; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANR1317E MOVE DATA: Storage pool DISKPOOL is not a shreddable pool. ANS8001I Return code 3.
Deleting data from a shreddable pool

When any data in a shreddable pool is deleted by any server function, such as EXPIRE INVENTORY, DELETE FILESPACE, or DELETE VOLUME, the data is shredded. When an object is deleted that has version copies in both shreddable and non-shreddable pools, the server only shreds the copies in the shreddable pools and does not print any warning message during deletion.
Shreddable pools and backup sets

Sensitive data can be exported and included in backup sets. By definition, those copies of the data are not shreddable. You must specify ALLOWSHREDDABLE=YES to allow data from a shreddable pool to be included in backup sets. If the keyword is not specified, the server prints a warning message and skips the shreddable data.
8.5 How to protect your data in storage pools

This section covers how to protect client data that is backed up to the Tivoli Storage Manager server. This section also describes how to make sure that the data in the Tivoli Storage Manager servers disk storage pools and tape storage pools is protected against damage, loss, or unauthorized access. One way to protect your data against damage is the use of copy storage pools. We provide more detailed recommendations about copy storage pools in Chapter 11, Providing a secure disaster recovery environment on page 293. One way to protect your backed up data that is physically located in the Tivoli Storage Manager server storage pools is to make a copy of these storage pools onto copy storage pools. Tivoli Storage Manager provides commands to copy this data automatically by using a
244
schedule. Using copy storage pools increases the protection of your data against damaged disks, tape faults, or lost cartridges. You can use Tivoli Storage Manager commands to restore data from copy storage pools. By default, if you try to restore data from a primary storage pool volume that is unavailable for any reason, Tivoli Storage Manager locates the data on a copy storage pool if it is available and requests the appropriate volume. To get the highest availability and security for your data, we recommend these best practices: If you discover that one file is damaged or a whole tape or disk volume is unavailable or destroyed, restore these files and volumes from the copy storage pool soon to avoid losing them by a second error. Restoring these files and volumes makes sure that you have both copies (primary and copy storage pool) intact. You must immediately investigate any read or write errors that occur on storage pool volumes. Backup data and the original data on the client must not be located in the same room or building. If possible, back up the data to another building or location. Think about natural disasters, such as earthquakes or floods. If you are located in an area that has a high risk of earthquakes, we recommend that you store your copy storage pools far enough away to make sure that they cannot be destroyed by the same natural disaster if a disaster strikes your location. Limit physical and logical access to volumes and tapes, for example, utilities such as tapeutil, which access at the operating system level, to trusted administrators only. A rogue administrator with access to primary and copy storage pool volumes can delete these volumes. All information about backed up files and the file locations are stored within the Tivoli Storage Manager database; therefore, the database is crucial to restoring data. Especially if your database backup tapes are unencrypted, you need to transport and store these tapes separately from copy storage pool volumes to reduce the risk of unauthorized recreation of the data. Tape volumes that become empty through reclamation or data deletion are only logically empty; that is, the pointers to the data are deleted from the Tivoli Storage Manager database. Tivoli Storage Manager does not erase the tape. If you dispose of any tape media, you must erase or destroy them first. Several methods for physically erasing the data or destroying the media are: Degaussing, which uses magnetism to destroy the data (Degaussing (bulk or secure erase) on page 315) Cutting the media into small pieces Overwriting multiple times with different random patterns Burning Relabeling the volume (11.11.1, If a tape is scratched or overwritten, can you still access older data on page 314) Make sure that all disk volumes that are replaced by you, the manufacturer, or a service contract are erased securely and that no data remains on the volumes before disposal. Many vendors provide for you on request a document about the data security when a disk is replaced due to failure. Normally, the vendors have internal mechanisms to erase all the data and make sure that the data is unrecoverable if the disk is returned to the spare parts inventory. Many tape libraries can be physically locked with a key. If you have this type of tape library, make sure that the tape library is always locked and the key is not stored on top of the tape library. Put the key in a secure place in a different locked room. Only let authorized personnel know where the key is kept and be able to get it. Otherwise, anyone
245
with access to this room, for example, a service technician, can remove tapes from your library and try to access data in a lab or at home. Do not resell used disks or tape volumes unless you are absolutely sure that no one is able to recover them. The best way to make sure that the data is unrecoverable is to physically destroy it.
246
Chapter 9.
Deployment in a network secured environment

This chapter first introduces the concept of a demilitarized zone (DMZ), and the Tivoli Storage Manager ports that are relevant in a firewall environment. Then, this chapter shows several ways that a Tivoli Storage Manager server can be located in a DMZ environment and gives the advantages and disadvantages for each way. This chapter also provides a step-by-step configuration for using Tivoli Storage Manager through a firewall without opening ports.
247
9.1 What is a DMZ

In a computer network, a DMZ is a separate network with limited access. It is a subnet which is connected to an external network, most often the Internet and an internal network. A DMZ is typically used for systems, such as e-mail, Web servers, or Domain Name Systems (DNSs). The DMZ is necessary because a Web server might need access to data stored on a database server on the intranet to generate the output for a Web page. Usually, there is no direct access to this database server from the Internet in order to secure the data you need in an external accessible network against hacking. You can get access through the firewalls to a server within the DMZ, but you cannot get access to a server behind the DMZ. This is blocked by firewall rules. Only servers within the DMZ can get connections to servers behind the DMZ to get requested data for a Web page, for example. Thus, servers within the DMZ work as a form of proxy. Figure 9-1 shows a typical DMZ configuration. We provide an overview of various types of firewalls in 10.4.1, Wired network security on page 270.
Internet
Front end
DMZ
Intranet
Firewall
Internet or unsecured network Allowed Prohibited Web server
Firewall
Allowed Database server
Back-end network
Back-end network allows only communication from inside the DMZ to the back-end network
Figure 9-1 A sample DMZ configuration
9.2 Tivoli Storage Manager clients in a DMZ

In most cases, the Tivoli Storage Manager server and clients can work across a firewall or the server can securely manage client backup and restore operations and administrative functions across a firewall. Because every firewall is different, the firewall administrator might need to consult the instructions for the firewall software or hardware in use.
248
Tivoli Storage Manager has two methods for enabling communication between the client and the server across a firewall: client-initiated communication and server-initiated communication. To allow either client-initiated or server-initiated communication across a firewall, client options must be set to agree with server parameters on the REGISTER NODE or UDPATE NODE commands. Enabling server-initiated communication overrides client-initiated communication, including client address information that the server might have previously gathered in server-prompted sessions. If client-initiated sessions are permitted, then the client might start a normal backup/archive client session, or server-prompted scheduling can be used to prompt the client to connect to the server. If server only sessions are configured, the client does not (and cannot) attempt to connect to the server. The only sessions permitted are by server-prompted scheduling on the port defined in TCPCLIENTPORT in the client option file. Recommendation: A firewall needs to be configured so that it does not terminate running sessions with either the server or the Storage Agent. When a firewall terminates a valid session, unpredictable problems can occur, which make processes and sessions appear to be stopped on communication I/O. We recommend using the standard known ports when configuring Tivoli Storage Manager components to facilitate excluding Tivoli Storage Manager sessions from timeout restrictions. This section gives you an overview of the configuration options when the Tivoli Storage Manager clients are within a DMZ. It shows how the Tivoli Storage Manager server and client communicate, how you have to configure the firewall, and which ports need to be opened so that your environment works. If you need a reminder about the type of sessions that are possible between the client and server, refer back to 2.2, Communication between the server and the client on page 26.
9.2.1 TCP/IP ports

Figure 9-2 on page 250 shows the ports and configuration options for the Tivoli Storage Manager client and server, including the mappings between the client ports and definitions, and the server definitions to use when defining or updating a node.
Chapter 9. Deployment in a network secured environment
249
Admin (dsmadmc)
dsm.opt
TSM Server
dsmserv.opt ADMINONCLIENTPORT NO TCPPORT TCPADMINPORT REGISTER NODE SERVER mypassword HLAddress=192.168.99.236 LLAddress=1501
TCPPORT TCPADMINPORT
1500 1502
TCPCLIENTADDRESS 192.168.99.236 TCPCLIENTPORT 1501
Client (dsm, dsmc)

Figure 9-2 Overview of TCP/IP parameters in dsm.opt and dsmserv.opt
There are two types of TCP/IP ports available when using COMMMETHOD TCPIP on the backup/archive client. These types specify the ports that are used for backup/archive sessions (dsmc) and administrative client sessions (dsmadmc): TCPPORT TCPADMINPORT Normally, both types use the same port, 1500, but you can change to separate ports for various reasons. Note: You can use TCPPORT and TCPADMINPORT in both dsmserv.opt and dsm.opt. Make sure that they match. See Figure 9-2 on page 250.
TCPPORT
This port is used normally for both client and administrative sessions. If you run Tivoli Storage Manager in a DMZ environment, you can prevent administrative access to the Tivoli Storage Manager server by setting this port for only client access if your Tivoli Storage Manager server is outside the DMZ in the intranet. To do this, set ADMINONCLIENTPORT NO in the dsmserv.opt file. Then, if you open just this port through the firewall, the server does not accept non-client sessions from within the DMZ. See Figure 9-3 on page 252. The default settings are: TCPPort 1500 adminonclientport yes
250
TCPADMINPORT
This parameter is used to specify a TCP port to use only for administrative sessions, which is different from the TCPPORT. For example, set TCPADMINPORT 1502 to indicate that port 1502 is to be used for administrative client sessions. By default, this port is set to the same value as TCPPORT unless ADMINONCLIENTPORT is set to NO. If ADMINONCLIENTPORT is set to NO, you must specify a different value for TCPADMINPORT.
TCPCLIENTADDRESS
The TCPCLIENTADDRESS option specifies a TCP/IP address to use if your client node has more than one address and you want the server to contact an address other than the one that was used to make the first server contact. The server uses this address when it begins a server-prompted scheduled operation. Use this option only if SCHEDMODE is set to PROMPTED. If SESSIONINITIATION is set to SERVERONLY in the node definition (see 9.2.3, Initiating scheduled sessions on page 252), the value for the TCPCLIENTADDRESS client option must be the same as the value for the HLADDRESS server option.
TCPCLIENTPORT
The TCPCLIENTPORT option specifies a TCP/IP port number for the server to contact the client when the server begins a server-prompted scheduled operation. Use this option only if SCHEDMODE is set to PROMPTED. If SESSIONINITIATION is set to SERVERONLY in the node definition (see 9.2.3, Initiating scheduled sessions on page 252), the value for the TCPCLIENTPORT client option must be the same as the value for the LLADDRESS server option.
9.2.2 Example configuration

In Figure 9-3 on page 252, we have only opened the TCPPORT in the firewall so that client A in the DMZ can run only backup/archive client sessions. Client B, which is in the same zone as the Tivoli Storage Manager server, can run administrative sessions. Therefore, we have effectively disabled administrative access to the Tivoli Storage Manager server except for clients in the intranet. The dsmserv.opt file contains the entries in Example 9-1.
Example 9-1 Sample settings in the dsmserv.opt
COMMmethod TCPPort TCPADMINPort adminonclientport
TCPIP 1500 1502 no
The dsm.opt file contains the entries in Example 9-2.

Example 9-2 Sample settings in the dsm.opt
TCPSERVERADDRESS TCPPORT TCPCLIENTADDRESS TCPCLIENTPORT
192.168.99.1 1500 192.168.99.236 1501

251
SESSIONINITIATION SERVERONLY PASSWORDACCESS GENERATE SCHEDMODE PROMPTED
For a client that has administrative access (client B, in our example), it must also include: TCPADMINPORT 1502
Actually, client A can also include this option because the port is blocked at the firewall and it is therefore unable to start the administrative session. However, we recommend only including the relevant and permitted options in the client options file.
Internet
Front end
DMZ
Intranet
Firewall
TSM Client A Internet or unsecured network
Firewall
TSM Server
Allowed on port TCPPORT Prohibited on TCPADMINPORT

All ow ed on All por ow t TC ed PP on OR TC T PA DM INP OR T
TSM Client B
Back-end network
Back-end network allows only communication from inside the DMZ to the back-end network
Figure 9-3 Prevent administrative access through a firewall
Note: If you have set tcpadminport on the Tivoli Storage Manager server, you can use tcpadminport on the clients dsm.opt to make sure dsmadmc uses the admin port when connecting to the Tivoli Storage Manager server.
9.2.3 Initiating scheduled sessions

There are two methods for establishing a scheduled session between the Tivoli Storage Manager server and client. These have different impacts on your firewall configuration: Client-initiated Server-initiated
252
The parameter SESSIONINITIATION used in the REGISTER NODE or UPDATE NODE commands controls whether the server or the client initiates sessions. The default is that the client initiates sessions: CLIENTORSERVER Specifies that the client can initiate sessions with the server by communicating on the TCP/IP port defined with the server option TCPPORT. Server-prompted scheduling can also be used to prompt the client to connect to the server. SERVERONLY Specifies that the server does not accept client requests for sessions. All sessions must be initiated by server-prompted scheduling on the port defined for the client with the REGISTER NODE or UPDATE NODE commands. You cannot use the client acceptor (dsmcad) to start the scheduler when SESSIONINITIATION is set to SERVERONLY.
Client-initiated sessions
If you set up your environment for client-initiated scheduled sessions, the client connects periodically every few hours to the server to query for scheduled backup operations. If the server is outside the DMZ, that means that you have to open the port specified in TCPPORT from the DMZ to the intranet to the Tivoli Storage Manager server. Otherwise, the client is not able to query the schedules from the server and no scheduled backups are run. To specify client-initiated scheduled sessions, set the SCHEDMODE parameter in the clients dsm.opt: SCHEDMODE POLLING Note: If you use SCHEDMODE POLLING in a clients dsm.opt, make sure that your Tivoli Storage Manager server-allowed schedule modes are set to either ANY or POLLING by using the SET SCHEDMODES command. If the server has specified a particular schedule mode, SCHEDMODE must be set in the client to match the specified server mode; otherwise, no scheduled operations are processed. To enable clients to communicate with a server across a firewall, open the TCP/IP port for the server as specified in the TCPPORT option in the dsmserv.opt file. The default TCP/IP port is 1500. When authentication is turned on, the information that is sent over the wire is encrypted. To enable administrative clients to communicate with a server across a firewall, open the TCP/IP port for the server as specified in the TCPADMINPORT option in the dsmserv.opt file. The default TCP/IP port is the TCPPORT value. When authentication is turned on, the information that is sent over the wire is encrypted. If the TCPADMINPORT option is specified, backup/archive sessions from clients can be started on the TCPPORT port only. If the server dsmserv.opt specifies TCPADMINPORT, which is different from the TCPPORT, and sets ADMINONCLIENTPORT to NO, then administrative client sessions can be started on the TCPADMINPORT port only. If you set SESSIONINITIATION to CLIENTORSERVER, the client can start sessions with the server, and in addition, server-prompted scheduling can be used to prompt the client to connect to the server.
Server-initiated sessions
If you use server-initiated sessions, the server prompts the client to perform a scheduled backup. In this case, it is not necessary to open any ports on the firewall.
253
To specify client-initiated scheduled sessions, set the SCHEDMODE parameter in the clients dsm.opt to: SCHEDMODE PROMPTED The following options can be used to make sure that the server uses the correct address and port when the prompted schedule starts. Client dsm.opt: TCPCLIENTADDRESS Use only if SCHEDMODE is PROMPTED. This value must match the value of HLADDRESS used in the REGISTER NODE or UPDATE NODE command. TCPCLIENTPORT Use only if SCHEDMODE is PROMPTED. This value must match the value for LLADDRESS used by REGISTER NODE or UPDATE NODE command. REGISTER NODE or UPDATE NODE command: HLADDRESS The TCP/IP address of the client that the server uses to contact the client. LLADDRESS The TCP/IP port of the client that the server uses to contact the client.
Note: If you use SCHEDMODE PROMPTED in a clients dsm.opt, make sure that your Tivoli Storage Manager server schedule modes are set to either ANY or PROMPTED by using the SET SCHEDMODES command. If the server has specified a particular schedule mode, SCHEDMODE must be set in the client to match the specified server mode; otherwise, no scheduled operations are processed. If SESSIONINITIATION=SERVERONLY for a node defined on the IBM Tivoli Storage Manager server, the client must have SESSIONINITIATION SERVERONLY in its option file. The server uses DNS to determine the name of client nodes. If your DNS is incorrectly configured, there might be delays or failures in looking up names. The DNSLOOKUP option is available to specify whether the server uses DNS to determine the names of client nodes.
9.2.4 Server-initiated sessions: Configuration example

To limit the start of backup/archive client sessions to the Tivoli Storage Manager server, you must specify SERVERONLY on the server and also synchronize the information in the client option file. In either the REGISTER NODE or UPDATE NODE command, select the SERVERONLY option of the SESSIONINITIATION parameter. Provide the HLADDRESS and LLADDRESS client node addresses. This configuration assumes a Tivoli Storage Manager server in the intranet or secure zone that needs to back up clients in the DMZ. See Figure 9-1 on page 248. By default, the firewall is configured to block incoming connections to the intranet but allows outgoing connections from the intranet. There is no extra configuration required on the firewall.
254
Test scenario
Our test scenario uses a Windows client V5.4.0.0 and Tivoli Storage Manager V5.4 Windows server. In our test, we performed these tasks: 1. Register the node on the server using: register node myclient mypassword hladdress=192.168.99.236 lladdress=1501 sessioninitiation=serveronly userid=none ANR2060I Node MYCLIENT registered in policy domain STANDARD. 2. Modify your nodes dsm.opt as in Example 9-3 and make sure that PASSWORDACCESS is set to GENERATE, SCHEDMODE is set to PROMPTED, and SESSIONINITIATION is set to SERVERONLY. Tip: Check that the port for TCPCLIENTPORT is not used for any other purpose. In particular, it must be specified as the value for TCPADMINPORT.
Example 9-3 dsm.opt prepared for server-initiated sessions only
TCPSERVERADDRESS TCPPORT TCPCLIENTADDRESS TCPCLIENTPORT SESSIONINITIATION PASSWORDACCESS SCHEDMODE
192.168.99.1 1500 192.168.99.236 1501 SERVERONLY GENERATE PROMPTED
Make sure that the values for TCPSERVERADDRESS, TCPPORT, TCPCLIENTADDRESS, and TCPCLIENTPORT match the values defined on the server. See Example 9-4 on page 255. 3. You can check that the client and server parameters match correctly using two select statements shown in Example 9-4. The NODE_NAME value must be written in capital letters.
Example 9-4 Get all necessary values for the dsm.opt
tsm: TSM01>select NODE_NAME, SESSION_INITIATION, CLIENT_HLA, CLIENT_LLA from nodes where node_name='MYCLIENT' NODE_NAME -----------------MYCLIENT SESSION_INITIATION -----------------ServerOnly CLIENT_HLA -----------------192.168.99.236 CLIENT_LLA -----------------1501
tsm: TSM01>select SERVER_NAME, SERVER_HLA, SERVER_LLA from status SERVER_NAME -----------------TSM01 SERVER_HLA -----------------192.168.99.1 SERVER_LLA -----------------1500
The HLADDRESS specifies the IP address of the client node and is used whenever the server contacts the client. The LLADDRESS specifies the low level address of the client node and is used whenever the server contacts the client. The client node listens for sessions from the server on the LLADDRESS port number. If
255
SESSIONINITIATION=SERVERONLY for a node defined on the Tivoli Storage Manager server, the client must have SESSIONINITIATION SERVERONLY in its option file. In addition, the TCP/IP address of the client must correspond to the information supplied with the HLADDRESS server parameter. Finally, TCPCLIENTPORT in the client options file must correspond to the port supplied in the LLADDRESS server parameter or the server does not know how to contact the client. 4. Define a scheduler service. Now, you can define a scheduler service on the client. This scheduler service executes scheduled commands as defined on the server. Define the schedule using dsmcutil executed from the baclient directory as shown in Example 9-5 on page 256. dsmcutil inst /name:"TSM_SCHEDULER /node:MYCLIENT /password:mypassword /autostart:yes /validate:no /startnow:no Use /validate:no to prevent the client from trying to connect to the server using the Tivoli Storage Manager API in order to validate the password. Because there are no ports open in the firewall, the client cannot connect to the server and this situation generates an error. The parameter /startnow:no prevents the defined schedule from starting up. In order to run scheduled commands correctly, you need to start the schedule one time in the foreground to set the password. We show you how to do this in step 8. Example 9-5 on page 256 shows the output of the dsmcutil command to define the schedule.
Example 9-5 Output of dsmcutil inst command
D:\Program Files\Tivoli\TSM\baclient>dsmcutil inst /name:"TSM_SCHEDULER" /node:MYCLIENT /password:mypassword /autostart:yes /validate:no /startnow:no TSM Windows NT Client Service Configuration Utility Command Line Interface - Version 5, Release 4, Level 0.0 (C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved. Last Updated Nov 27 2006 TSM Api Verison 5.4.0 Command: Install TSM Client Service Machine: MYCLIENT (Local Machine)
Installing TSM Client Service: Machine Service Name Client Directory Automatic Start Logon Account : : : : : MYCLIENT TSM_SCHEDULER D:\Program Files\Tivoli\TSM\baclient yes LocalSystem
The service was successfully installed.
Creating Registry Keys ... Updated registry value 'ImagePath' . Updated registry value 'EventMessageFile' . Updated registry value 'TypesSupported' . 256
Updated Updated Updated Updated Updated
registry registry registry registry registry
value value value value value
'TSM_SCHEDULER' . 'ADSMClientKey' . 'OptionsFile' . 'EventLogging' . 'ClientNodeName' .
Can't generate registry password: validate=no. D:\Program Files\Tivoli\TSM\baclient> 5. Verify that the scheduler was correctly created with the command dsmcutil query /name:tsm_scheduler. Make sure the scheduler is stopped; otherwise, you cannot set the password in the next step.
Example 9-6 Output of dsmcutil query
D:\Program Files\Tivoli\TSM\baclient>dsmcutil query /name:tsm_scheduler TSM Windows NT Client Service Configuration Utility Command Line Interface - Version 5, Release 4, Level 0.0 (C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved. Last Updated Nov 27 2006 TSM Api Verison 5.4.0 Command: Query TSM Client Service Parameters Machine: MYCLIENT(Local Machine) Connecting to service 'tsm_scheduler' ... Service Configuration/Status: Service Name Image Path Logon Account Start Type Current Status : : : : : tsm_scheduler "D:\Program Files\Tivoli\TSM\baclient\dsmcsvc.exe" LocalSystem Auto Stopped
TSM Client Service Registry Settings: Client Service Type Options file Event Logging TSM Client Node Comm Protocol Server Server Port Schedule Log Error Log Cluster Enabled Cluster Name = = = = = = = = = = = Client Scheduler Service D:\Program Files\Tivoli\TSM\baclient\dsm.opt YES MYCLIENT (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set)
D:\Program Files\Tivoli\TSM\baclient> 6. Set the password.
257
If you do not first set the password, the scheduler never runs successfully and you get a message in the dsmerror.log. See Example 9-7.
Example 9-7 Error from dsmerror.log when starting the schedule service before the password is set
ANS2050E TSM needs to prompt for the password but cannot prompt process is running in the background.
because the
a. To set the password, create a file named dir.cmd in the baclient directory D:\Program Files\Tivoli\TSM\baclient with the content in Example 9-8 on page 258. This is just a simple test file, which lists the current directory.
Example 9-8 Content of dir.cmd in D:\Program Files\Tivoli\TSM\baclient
dir > nul b. Start the scheduler in the foreground by using dsmc schedule as shown in Example 9-9.
Example 9-9 dsmc schedule waiting for a scheduled action
D:\Program Files\Tivoli\TSM\baclient>dsmc schedule IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 4, Level 0.0 Client date/time: 02/09/2007 00:26:42 (c) Copyright by IBM Corporation and other(s) 1990, 2007. All Rights Reserved. Waiting to be contacted by the server. If dsmc schedule is already running in the background, you get an error. See Example 9-10.
Example 9-10 dsmc schedule is already running as a background process
D:\Program Files\Tivoli\TSM\baclient>dsmc schedule IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 4, Level 0.0 Client date/time: 02/09/2007 18:56:37 (c) Copyright by IBM Corporation and other(s) 1990, 2007. All Rights Reserved. ANS1018E Port 1501 is already in use D:\Program Files\Tivoli\TSM\baclient> c. While the client scheduler is listening in the foreground, define a client action on the Tivoli Storage Manager server as in Example 9-11.
Example 9-11 Defining a client action on server
tsm: TSM01>DEFine CLIENTAction myclient action=command objects=D:\Program Files\Tivoli\TSM\baclient\dir.cmd ANR2500I Schedule @1 defined in policy domain STANDARD. ANR2510I Node MYCLIENT associated with schedule @1 in policy domain STANDARD. ANR2505I 1 schedules were defined for DEFINE CLIENTACTION. d. The server now contacts the client scheduler process. In the client scheduler session, you are prompted to enter the password. After you enter the password, the 258
clientaction command is executed and the encrypted password is saved in the registry (or the password file for UNIX or Linux). Note that we saw that there is a small time interval to enter the password before a timeout occurs. If you do not enter the password quickly enough, the session is lost and you must wait until the server tries again to contact the client. There is no other way to set the password if the port is not open through the firewall.
Example 9-12 Prompt to enter the password
Waiting to be contacted by the server. Enter password for node "MYCLIENT": ********** Querying server for Node Name: MYCLIENT Session established Server Version 5, Server date/time: next scheduled event. with server TSM01: Windows Release 4, Level 0.0 02/09/2007 00:31:33 Last access: 02/09/2007 00:31:27
Next operation scheduled: -----------------------------------------------------------Schedule Name: @1 Action: Command Objects: D:\Program Files\Tivoli\TSM\baclient\dir.cmd Options: Server Window Start: 00:27:13 on 02/09/2007 -----------------------------------------------------------Executing scheduled command now. Executing Operating System command or script: D:\Program Files\Tivoli\TSM\baclient\dir.cmd D:\Program Files\Tivoli\TSM\baclient>dir 1>nul Finished command. Return code is: 0 ANS1908I The scheduled command completed successfully. Scheduled event '@9' completed successfully. Sending results for scheduled event '@1'. Results sent to server for scheduled event '@1'. Querying server for Node Name: MYCLIENT Session established Server Version 5, Server date/time: next scheduled event. with server TSM01: Windows Release 4, Level 0.0 02/09/2007 00:31:35 Last access: 02/09/2007 00:31:33
Next operation scheduled: -----------------------------------------------------------Schedule Name: DAILY_INCR Action: Incremental Objects: Options: Server Window Start: 16:20:05 on 02/09/2007 -----------------------------------------------------------Waiting to be contacted by the server.
259
e. Press q twice to exit the foreground scheduler session. You have now successfully set the password and can start the scheduler service in background. 7. Check the set up and make sure that the scheduled operations run next time without prompting for the password. a. Check in the registry if the password is set successfully (Windows only). See Example 9-13 on page 260.
Example 9-13 Export key from registry
D:\>regedit /e D:\tsm.reg HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes This dumps the registry key to an ASCII file. You can view this using your favorite text editor, as shown in Example 9-14. Make sure that there is a password entry corresponding to your node name and server, which stores the encrypted password.
Example 9-14 Dumped contents of registry key
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes] [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\MYCLIENT] [HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\MYCLIENT\TSM01] "Password"=hex:03,e9,a4,23,e8,6d,51,ee,cf,32,68 b. Start the service for the scheduler so that the client listens to be contacted by the server for the next scheduled action. Obviously, you will need actual production client backup schedules to be executed. See Example 9-15.
Example 9-15 Starting client scheduler
D:\Program Files\Tivoli\TSM\baclient>dsmcutil start /name:TSM_SCHEDULER TSM Windows NT Client Service Configuration Utility Command Line Interface - Version 5, Release 4, Level 0.0 (C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved. Last Updated Nov 27 2006 TSM Api Verison 5.4.0 Command: Start TSM Client Service Machine: MYCLIENT(Local Machine)
Starting the 'TSM_SCHEDULER' service ... The service was successfully started.
D:\Program Files\Tivoli\TSM\baclient> c. Check the service status and look for Current Status : Started. See Example 9-16 on page 261.
260
Example 9-16 Check status of the scheduler
D:\Program Files\Tivoli\TSM\baclient>dsmcutil query /name:TSM_SCHEDULER TSM Windows NT Client Service Configuration Utility Command Line Interface - Version 5, Release 4, Level 0.0 (C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved. Last Updated Nov 27 2006 TSM Api Verison 5.4.0 Command: Query TSM Client Service Parameters Machine: MYCLIENT(Local Machine) Connecting to service 'TSM_SCHEDULER' ... Service Configuration/Status: Service Name Image Path Logon Account Start Type Current Status : : : : : TSM_SCHEDULER "D:\Program Files\Tivoli\TSM\baclient\dsmcsvc.exe" LocalSystem Auto Started
TSM Client Service Registry Settings: Client Service Type Options file Event Logging TSM Client Node Comm Protocol Server Server Port Schedule Log Error Log Cluster Enabled Cluster Name = = = = = = = = = = = Client Scheduler Service D:\Program Files\Tivoli\TSM\baclient\dsm.opt YES MYCLIENT (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set) (value not currently set)
D:\Program Files\Tivoli\TSM\baclient> d. You also can check if the server is listening on the port. See Example 9-17.
Example 9-17 netstat -a sample
D:\Program Files\Tivoli\TSM\baclient>netstat -a Active Connections Proto TCP TCP TCP TCP TCP Local Address MYCLIENT:epmap MYCLIENT:microsoft-ds MYCLIENT:1030 MYCLIENT:1052 MYCLIENT:1501 Foreign Address MYCLIENT:0 MYCLIENT:0 MYCLIENT:0 MYCLIENT:0 MYCLIENT:0 State LISTENING LISTENING LISTENING LISTENING LISTENING
e. In the dsmsched.log, you also see information that confirms the schedule is running correctly. See Example 9-18 on page 262.
261
Example 9-18 Information in dsmsched.log about scheduler status
02/09/2007 00:42:51 Waiting to be contacted by the server.
Attempt to run a client-initiated session

Because we disabled client-initiated sessions and the client port is blocked at the firewall, the server is effectively unreachable if you try to start a dsmc or dsm session from the client, as shown in Example 9-19.
Example 9-19 Client session rejected
C:\Program Files\Tivoli\TSM\baclient>dsmc IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface - Version 5, Release 4, Level 0.0 (c) Copyright by IBM Corporation and other(s) 1990, 2007. All Rights Reserved. Node Name: MYCLIENT ANS1017E Session rejected: TCP/IP connection failure
9.3 Sample configurations and best practice recommendations

Finally, we list our recommendations for where to locate your Tivoli Storage Manager server and provide guidance about backing up clients with different security levels.
9.3.1 Tivoli Storage Manager server in a DMZ

The first and simplest idea is to put your Tivoli Storage Manager server directly in the DMZ. In this case, there is no need to configure the firewall because the clients and the server are all in the same secured network. But if you want to run the administrative client (dsmadmc) to manage the Tivoli Storage Manager server, you must either run the administrative client from a workstation in the same network segment, or you must open the firewall to allow connections to the Tivoli Storage Manager server from outside the DMZ. We discourage opening the firewall from a security perspective. The primary reason to not put the Tivoli Storage Manager server in the DMZ is that your backed up data on the server is now in the same location as the clients themselves and is also accessible from the Internet. A best practice to minimize your vulnerability to attack is to separate the source and targets for backup, so that if the either the source or the targets are compromised, the other set is still safe.
9.3.2 Tivoli Storage Manager server not in a DMZ

In this configuration, the Tivoli Storage Manager server is not within the DMZ but is behind the firewall, as shown in Figure 9-3 on page 252. Because all backup data must go through the firewall, the necessary ports must be open. The safest configuration is to use separate ports for client and non-client sessions as we illustrated in Figure 9-3 on page 252. In this way, you can open the backup port in the firewall, but not the administrative port, preventing unauthorized administration sessions through the Internet. If your backup data is going through a firewall, the firewall device is likely to become a bottleneck, because all data sent is checked by the rules defined on the firewall. You must
262
carefully monitor the performance of your firewall under peak backup loads to make sure that the firewall can handle the traffic within the time allocated for your backup window.
9.3.3 Tivoli Storage Manager server in a dedicated network in the DMZ

We have shown the potential security shortcomings of installing your Tivoli Storage Manager server directly in the DMZ or in a network that is under limited access. And we have seen that using a firewall might negatively impact the backup window and the workload on the firewall. But there is one solution that includes the benefits of both configurations: Secure access to the Tivoli Storage Manager server without the potential throughput impact of a firewall, as shown in Figure 9-4. We show the Tivoli Storage Manager server and clients (A and B) communicating on a dedicated subnet within the DMZ. In this case, the front-end clients (A and B) present a Web interface to the Internet through one network. The front-end clients have a separate network through the DMZ to communicate with data sources on the secure intranet and a third separate network that is used only for backup traffic. See Figure 9-4. A disadvantage to this approach is that you need a network adapter dedicated for the backup in each client. But, the advantage is that it should improve performance and allow the backup to proceed without impacting other network traffic.
Internet
Front end LAN
DMZ
Intranet
back end LAN
Client a
Back up LAN
TSM server
internet
Client b
Figure 9-4 Dedicated network for backup in DMZ
9.3.4 Backing up clients of different security levels on the same server

One of the primary reasons to put the Tivoli Storage Manager in a DMZ or in a separate network is to keep the data stored in the Tivoli Storage Manager separate from the data in other network segments. What if you need to back up clients that need to be very secure, as well as other non-secured or less-secured clients (which are typically in different network zones)? This represents a potential vulnerability. If the client data is unencrypted, a Tivoli Storage Manager administrator can potentially restore data from any node. In addition, a Tivoli Storage Manager client can try to restore data from another node by using password guessing methods. Therefore, if you are backing up both secure and less-secure clients, use Tivoli Storage Manager client encryption on the secure data to protect against unauthorized access at a minimum. A best practice is to use separate Tivoli Storage Manager servers (or server instances, using a different connection port) for different security levels. The separate servers
263
or instances can have different administrators so that only very trusted personnel have access to the most sensitive data. Another point to consider in this environment is the backup media (disk storage pools or tape storage pools) where the data is stored on the server. Even if you are separating the differently secured clients on Tivoli Storage Manager servers or instances, in a small configuration, the storage pool volumes for both servers can share the same physical tape or disk device, whether local or networked. A best practice, although a more costly one, is to use completely separate tape and disk devices for the storage pools used by each server. For the more secure clients, these devices must also be located in an area with restricted physical access. A less expensive way to increase security is to use client encryption, which prevents access to the secure data from any other client unless the encryption key is known.
264
10
Chapter 10.
Protecting the server

This chapter covers: Security policy considerations Operating systems security considerations Networking security considerations Security assessment tools Human aspects of security Environmental considerations High availability considerations Change management considerations Security audit considerations How to run your Tivoli Storage Manager server as a non-root user References
265
10.1 Overview
Often the primary role of Tivoli Storage Manager administrators is related to ensuring the integrity of the backup and recovery process. Security-related activities are frequently carried out by another department and might not be high on the to do list of tasks for a Tivoli Storage Manager administrator. The Tivoli Storage Manager server is essentially a network-based application, which connects Tivoli Storage Manager clients and Tivoli Storage Manager servers. During the backup process, data transfer between the client and the server traverses through a variety of paths, for example, through fiber and copper networks using a variety of protocols, Storage Array Networks, and so forth, before data finally arrives on the tape drives. Because of the client/server nature of Tivoli Storage Manager software, security implications are critical. The intent of this chapter is to provide the Tivoli Storage Manager administrator with a broad overview of security considerations within an organization. The aim is to increase the level of awareness of Tivoli Storage Manager administrators so that they can effectively communicate with those who formulate the security policy in the enterprise. Note: Obviously, security is a very broad-reaching topic that affects all parts of an enterprise. We focus on Tivoli Storage Manager-specific considerations in this chapter, although many of the guidelines apply more generally to computer security. For more security resources, see 10.12, References on page 290.
10.2 Security policy considerations

Central to any security discussion is the organizations security policy. The objective of a security policy is to provide and maintain the confidentiality, integrity, and availability of the organizations data.
Confidentiality refers to ensuring only authorized people have access to information that they
are allowed to see.
Integrity refers to maintaining the data in a protected form that cannot be modified without
authorization. Information is only of value if it is correct.
Availability refers to ensuring information is available when needed.

The organizations security policy is a living document and needs to be updated regularly to reflect the current risk assessment posture. A companys business objectives and the perceived level of threat are several of the areas to consider when determining the companys risk assessment posture because this often dictates the amount of effort and money available. Integral to the security policy are various guidelines and standards that are used to control how processes, procedures, software, and hardware are managed in an IT environment. A good security policy must also adhere to internationally recognized compliance standards because these are becoming more important. The most common security standard is ISO/IEC 17799. See: http://www.iso.org/iso/en/prods-services/popstds/informationsecurity.html
266
In addition, the Sarbanes-Oxley (SOX) act of 2002 has a very significant impact on how IT infrastructures are to be managed. Detailed discussion of SOX is outside the scope of this project. However, one of the mandated requirements from SOX is that the United States Securities and Exchange Commission (SEC) requires a companys internal control mechanism for financial reporting to be based on a recognized internal control framework. From an IT perspective, various control mechanisms must be in place for a company to be SOX compliant. There is much information publicly available on security controls, for example, a document called the IT Control Objectives for Sarbanes-Oxley that was published by the IT Governance Institute. A copy of this document can be downloaded from this Web site by using the links Resource Center ITGI publications. http://www.itgi.org/ For those organizations that are in the health care industry, the need for Heath Insurance Portability and Accountability Act (HIPAA) compliance is also critical. Among other rules stipulated, policies, processes, and procedures must be in place to ensure privacy, security, and patients rights. More information about HIPAA can be read at: http://www.hipaadvisory.com/REGS/HIPAAprimer.htm Both SOX and HIPAA further highlight the importance of having a good security policy and having the appropriate procedures and processes in place to ensure security compliance. Many vendors and consultants can advise you about security. If required, examples of security policies can be purchased from this Web site: http://www.information-security-policies-and-standards.com/ The next few sections discuss areas to consider from a security perspective.
10.3 Operating system security considerations

All operating systems have inherent flaws or vulnerabilities. To minimize potential security-related risks related to these flaws, consider the following areas. These areas are common to all operating systems: Disable any unnecessary services if they are not required, for example, Common Desktop Environment (CDE) and remote log-in services. Implement an operating system and application patching regime to ensure that critical patches are implemented as soon as possible. These patches must be tested and verified to work across various environments, for example, development and test before finally installing them in production machines. Minimize and secure administrator or root access to the operating system. This is critical because of the power of these user IDs; only trusted people need to be given this authority. In a Tivoli Storage Manager context, a root user can restart the Tivoli Storage Manager server process by using dsmserv with authentication disabled and access any backed up data from any client. Enforce a strict password policy. The policy must stipulate the minimum password length, minimum number of alphanumeric characters, password expiration periods, and password reuse restrictions.
Chapter 10. Protecting the server
267
Subscribe to security report mailing lists and review security-related Web sites regularly. Examples of the popular Web sites are: http://www.cert.org http://www.first.org http://csrc.ncsl.nist.gov http://www.securityfocus.com http://www.sans.org Perform frequent backup of the operating systems and verify the integrity of the backups. Operating system backups must be stored in a secure location. The next section discusses security considerations pertaining to UNIX, Linux, and Windows operating systems in more detail. Other publications that might be useful, particularly in the System z environment, include: z/OS UNIX Security Fundamentals, REDP-4193 Deployment Guide Series: IBM Tivoli Security Compliance Manager, SG24-6450 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014 Introduction to the New Mainframe: Security, SG24-6776
10.3.1 UNIX and Linux

Securing the operating system has many commonalities across the various versions of UNIX and Linux. As an example, we discuss at a high level methods of hardening AIX: Where applicable, services within an AIX machine need to be kept to a minimal. Examples of these services that must be disabled if not needed are FTP, X11, CDE, Rsh, Rlogin, Telnet, and Finger. There are known security exposures to these utilities, for example, when using Telnet, the password is sent across the network in clear text. Use the OpenSSH software tool. This tool provides shell functions in which network traffic is encrypted between the client and the server. The tools include SSH, which is a replacement for Telnet and SCP as an FTP replacement. More information about OpenSSH is at the Web site: http://www.openssh.org Instructions for installing OpenSSH on AIX are at AIX documentation Security Securing the base Operating System at: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp Traditionally, passwords for UNIX users are stored in /etc/passwd and the /etc/security/passwd file. If an organization has a large number of UNIX systems, managing users accounts and passwords on these systems can be difficult and in fact increase security exposure because there is a greater tendency for users to write down the password for each account that the user has. Using a central user management repository can alleviate some of these problems. Solutions available for central management include LDAP, Kerberos, NIS, and NIS+. LDAP has several advantages over NIS in the areas of scalability, security, and availability. More details about using LDAP and Kerberos for user authentication are in Integrating AIX into Heterogenous LDAP Environments, SG24-7165.
268
On UNIX systems, root level access is often difficult to secure. One method of overcoming this problem is to introduce additional tools to provide more fine-grained access control. An example of a tool is Tivoli Access Manager for Operating Systems (TAMOS). All accesses to resources, files, and data are audited and authorized through a customizable security policy within TAMOS. More information about TAMOS is at: http://www.ibm.com/software/tivoli/products/access-mgr-operating-sys For further information about securing AIX, see AIX documentation Security at: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp
10.3.2 Windows
A number of versions of Windows are available from Microsoft. As an example, this section discusses Windows 2003 Server security features and common methods of hardening the operating system. A Windows 2003 server can be configured to provide various roles, which include domain controllers, file and print servers, application servers, Internet servers, and certificate servers. Many security features are available on Windows 2003 Server to provide a more secure operating environment.
The Security Configuration Wizard (SCW)

This is a new role-based tool available through Windows 2003 Server Service Pack 1, which you need to use to make your server more secure. Features of SCW are: The ability to determine which services are not required Reduce security exposures from some protocols, such as SMB and NetBIOS Provide network port filtering functions when used with the Windows firewall Create and verify security policies for a group of servers from a computer Generate audit policies to capture events of interest
Active Directory (AD)

The Active Directory is a repository of objects, for example, users, groups, resources, and services. It is an implementation of LightWeight Directory Access Protocol (LDAP) on the Windows platform. Security is enhanced through the use of Active Directory because: AD provides a single logon to authentication users and authorized access to objects within the AD repository or the datastore. AD can enhance authentication through the use of other authentication mechanisms, such as Kerberos V5, SSL, and Public Key Certificates. AD simplifies user administration functions by minimizing the number of accounts needed for each user and provides central management of these accounts. AD allows various policies to be enabled within Active Directory to improve security. An example is Group Policy. When Group Policy is used within an Active Directory implementation, you can define, configure, and implement enterprise-side security policies.
269
Here are suggestions for hardening the Windows environment: Install and use Microsoft Baseline Security Analyzer (MBSA). This tool is used to check for security misconfiguration. Use Windows Update to receive regular Windows security patches. Use NTFS partitions on all machines so you can use Active Directory and domain-based security. Change the Administrator and Guest account to another name. Replace the Everyone group with another group name inside the access control lists (ACLs) of your shares. Disable IIS if not required. More detailed information about hardening and securing the Windows 2003 Server environment is at: http://www.microsoft.com/windowsserver2003/technologies/security/default.mspx
10.4 Network security considerations

The network is a critical piece of Tivoli Storage Manager configurations because data flows over the network except where a client is backing up to a local server. Networks can be divided at a high level into wired and wireless. Network security implies securing the network infrastructure from unauthorized access. Network attacks come in many types. Examples are denial of services attack, man-in-the-middle (MITM) attack, targeted service attack, and so forth.
10.4.1 Wired network security

To mitigate network-related attacks, firewalls are normally implemented within an organization network in strategic locations. These strategic locations act as choke points to prevent undesired traffic from penetrating into an organizations network. Firewalls can generally be classified into the following types.
Packet filtering firewall

This type of firewall is implemented through a dual-home machine (that is, a machine with two network cards). Each network card is connected to a different network. Packets from one network are forwarded to other network based on a set of filtering rules. These rules define which IP addresses and ports can be forwarded or blocked at the network level. This works at the IP layer of the TCP/IP stack. Figure 10-1 on page 271 provides a schematic of a firewall.
270
Figure 10-1 Packet filtering firewall
Circuit level gateway

This works on the TCP layer of the TCP/IP stack. It monitors the TCP handshake between the client and the server to determine if the session is valid. The remote client sees the circuit level gateway as the server even though traffic originates from a server located within the internal network, therefore, protecting the internal server. Figure 10-2 shows a schematic of a circuit level gateway.
Figure 10-2 Circuit level gateway
Application firewall and gateway

This works similarly to the circuit level gateway except that filtering is done at the application layer of the TCP/IP stack. Application firewalls act as a proxy server for incoming and outgoing traffic. Examples of application firewalls are Web proxy servers. They are configured only to allow for Web traffic. Other application layer protocols, such as FTP, Telnet, and gopher are not allowed through this proxy. These firewalls often require manual configuration. Figure 10-3 on page 272 shows a schematic.
271
Figure 10-3 Application firewall
Stateful multilayer inspection firewall

This firewall uses a combination of features from all of the above firewalls to determine if traffic is allowed into an internal network. Traffic is checked at the IP level, TCP level, and Application level before a client can connect to an internal server. This firewall however requires more complex configuration. Figure 10-4 shows a schematic.
Figure 10-4 Stateful Inspection firewall
Intrusion Detection Systems and Prevention Systems

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) are closely related to the way you use firewalls. Firewall devices can be viewed as a perimeter defense, that is, they protect a network from being attacked. Alternatively, IDS are used for alerting when a security breach has occurred. IDS can be further classified into Host-Based IDS and Network-based IDS. Host-Based IDS refers to the monitoring of audits or event logs on systems to look for abnormal trends and
272
behaviors. Network-Based IDS however monitors data packets on the network using promiscuous mode to detect for traffic anomalies or an attack signature. IPS works the same way as IDS except that in addition to intrusion detection, IPS also prevents intrusions. For example, if a malware virus has been detected and it uses a certain port on a firewall, the IPS can automatically disable this port on firewalls to avoid further spreading this malware virus. In a large organization, many events that are generated often lead to false positive triggers. Numerous tools are available in the marketplace to provide better management of these events through various analysis and event correlation techniques. An example is IBM Tivoli Security Operations Manager, which is a Security Information and Event Management (SIEM) platform designed to improve the effectiveness, efficiency, and visibility of security operations and information risk management. More information about this tool is in Tivoli Security Operations Manager (TSOM) on page 275.
10.4.2 Wireless network security

Current wireless LAN technology is based on the IEEE 802.11x set of standards. It uses the standard unlicensed 2.4 GHz band on one of 15 specific channels. Wireless LAN can exist in two modes: infrastructure or ad hoc mode. Infrastructure mode refers to connection to a wired network through a wireless access point (AP). Ad hoc refers to peer-to-peer communication between two computers without going through a wireless access point. The most common mode is infrastructure. Wireless devices communicate to a wired network through an access point. Each access point needs to be configured with a unique ID called Service Set Identifier (SSID). Wireless LAN traffic typically uses one of these encryption methods.
Wired Equivalent Policy (WEP)

This is part of the original IEEE 802.11b standard. WEP encryption is supported on most hardware. WEP has several inherent flaws, particularly that WEP uses an RC4 cipher stream that can easily be cracked by using publicly available tools, such as aircrack-ng, weplab, WEPCrack, or airsnort.
WiFi Protected Access (WPA)

To overcome the weaknesses inherent in WEP, WPA was introduced by the WiFi Alliance. The WiFi Alliance is a consortium of vendors consisting of 3Com, Cisco, Intersil, Nokia, and Symbol technologies. WPA implements most of the IEEE 802.11i standards. It was created as an interim solution while the IEEE 802.11i was developed. IEEE 802.11i or WPA2 rectifies the earlier security problems related to the IEEE 802.11b standards by introducing more secure encryption protocols. Both WPA and WPA2 can operate in either the personal mode (pre-shared key-PSK) or enterprise mode. The personal/PSK mode is used in a small environments where WPA can operate without the need of an 802.1x authentication server. A common passphrase needs to be configured on each computer before it can communicate with the access point. To minimize vulnerability to password cracking tools, we recommend that password length is at least 20 characters (PSK allows you to define up to 63 characters). Passphrases are shared among the uses who need to have access to the wireless network. WPA/WP2 in enterprise mode uses an 802.1x authentication server. A wireless client is prompted for credentials when it tries to access the network through a wireless access point.
273
The client credentials are forwarded to a Remote Authentication Dial-In User Service (RADIUS) for authentication and authorization. The IEEE 802.1x defines standard extensible authentication protocol (EAP). The commonly used EAPs are EAP-MD5, EAP-Cisco Wireless (also known as LEAP), EAP-TLS, and EAP-TTLS. Common practices regarding setting up wireless networks are: Do not use the default SSID. The default SSID must be changed to a value that is unrelated to the access points owner or department. Your pets name is not a good choice. Disable SSID broadcasting so that the SSID is known only to authorized users. Use MAC address filtering so that only machines with appropriate MAC addresses can communicate with the access point. Use WPA encryption instead of WEP. Use a RADIUS server to authenticate users. Change the default administrator ID and password for the wireless devices. Limit the signal range of an access point.
10.5 Security assessment tools

Many tools are available to scan, detect, and audit for system and network vulnerabilities. This section discusses a few of the more popular tools.
Nessus
One of the most popular free vulnerability scanning tools is Nessus. Nessus includes these components: Nessus clients and servers Plug-ins Knowledge database MySQL database Scanning for vulnerabilities (both host and network vulnerabilities) is initiated by a Nessus client against one or more Nessus servers deployed across an organization. Associated with each Nessus server is a security vulnerability knowledge database, which consists of thousands of plug-ins. Each plug-in refers to an identified security threat. The knowledge databases can be updated daily to reflect the latest vulnerability threats. In addition, security analysts can also develop their own plug-ins if required. Discovered vulnerability can be logged to a MySQL database server. Reports can be performed against MySQL to report vulnerability trends, to generate security compliance reports, and to request a security budget based on vulnerability threats identified, and so forth. More information about Nessus is available at: http://www.nessus.org
274
Tivoli Security Compliance Manager (TSCM)

TSCM helps identify security vulnerabilities and security policy violation by performing the following functions: Automated scans of servers and desktop systems to help reduce the cost and time associated with manual security checks Reports to security officers and compliance auditors with detailed information about the security health of the business so they can take the appropriate steps to make individual systems and departments compliant Identification of software security vulnerabilities prior to costly damage being inflicted by security incidents Improvement of business operations and assistance to increase efficiencies through automation and centralization Assistance to address compliance issues in regulations and standards by automating compliance tasks, monitoring correspondence, reducing human error, and taming compliance costs Integration with Tivoli automated security management tools to help mediate security policy violations and risks For more information about TSCM, see: http://www.ibm.com/software/tivoli/products/security-compliance-mgr/
Tivoli Security Operations Manager (TSOM)

TSOM is a security information and event management (SIEM) platform designed to improve the effectiveness, efficiency, and visibility of security operations and information risk management. TSOM centralizes security information from various sources so that you can: Automate log aggregation, correlation, and analysis Recognize, investigate, and respond to incidents automatically Streamline incident tracking and handling Enable monitoring and enforcement of policy Provide comprehensive reporting for compliance efforts TSOM consist of the following components: Event Sensors: A sensor is defined as any device, server, operating system, or application that provides logs to TSOM. Event Aggregation Module (EAM): Numerous EAMs can be deployed within an organization. Events from sensors are classified and normalized here. False positive events and routine events are also filtered before real events are forwarded to CMS. Central Management System (CMS): The CMS acts as the hub for TSOM and receives data events from all of the EAMs deployed in the network. Event correlation and threat analysis are performed here by correlating with known attack signatures. After correlation is completed, results are stored in an event-persistent database for reporting or viewing. TSOM integrates closely with enterprise network and system management products, including Netcool event managers and dashboards, as well as Tivoli Enterprise Console, and IT Help Desk ticketing systems to further facilitate incident remediation. For more information about TSOM, see: http://www.ibm.com/software/tivoli/products/security-operations-mgr/
275
10.6 Human aspects of security

One of the most important but often neglected areas of computer-related security breaches has to do with human beings. Human beings by nature are prone to errors: we make mistakes, we can be deceived, we make compromises or shortcuts, and so forth. Human beings can also be persuaded or can be motivated to do the wrong thing for many reasons, including revenge and personal gain. Because we are an integral part of the IT infrastructure, our weaknesses can be exploited by other people. In addition to using technology to focus on security, the organization must also focus on the various human aspects related to security. As the saying goes, Your security is as strong as the weakest link.
10.6.1 Social engineering

Social engineering can be described as a non-technical method of obtaining confidential
information with the sole purpose of attaining unauthorized access to systems or information. These unauthorized accesses can often result in identity fraud, systems or network disruptions, bribery, theft, and so forth. By non-technical, we mean that human users are manipulated by other human beings to disclose information or perform actions. It is important to note that social engineering can be performed both by employees within an organization and by external parties. A recent study by CSO magazine, together with Carnegie Mellon University and the US Secret Service, has indicated that a high proportion of computer-related crimes are committed by internal staff. A copy of this report can be downloaded from: http://www.cert.org/archive/pdf/ecrimesummary05.pdf Social engineering attacks come in many forms, for example, phone, e-mail, instant messaging, persuasion through conversations, dumpster diving, cooperation, involvements, and so forth. Examples of social engineering can be read at: http://www.crimes-of-persuasion.com/ Most social engineering attacks can be avoided by raising the security awareness within the organization through education, common sense, and policies. Examples of these are: Create and maintain a security awareness culture within the organization. Provide training to all employees about the importance of security and provide examples of social engineering and how to avoid theses situations. Do not open e-mails from unknown sources. Enforce separation of duties and privileges based on a need to know basis. Shred confidential materials before disposing of them, including computer tapes, printed materials, and hand-written materials. Reformat all hard disks on computers before decommissioning them. Limit administrators system level access to as few people as possible. Perform audit tracking of all systems management-related activities. Implement strict password policies and change passwords regularly. Perform background checks on systems and network administrators before hiring them. Deactivate employee computer access following terminations.
276
Minimize the number of passwords required within an organization. Perform regular security audits to ensure compliance. Institute a good change management regime so that changes can be audited and tracked.
10.7 Environmental considerations

Tivoli Storage Manager server must ideally be located behind a management subnet behind the Demilitarized Zone (DMZ). Access to this management subnet must be minimized and limited only to certain administrators. This management subnet must always be located in a physically and environmentally secured environment. Further details about how to configure Tivoli Storage Manager server within a DMZ are in Chapter 9, Deployment in a network secured environment on page 247.
10.8 High availability considerations

High availability (HA) can be accomplished at several levels, for example, from within the Tivoli Storage Manager server, in the Tivoli Storage Manager backup infrastructure, or by replicated data centers at different locations. While a backup application, such as Tivoli Storage Manager, might be seen as a non-mission critical application as compared to an Enterprise Resource Planning application, such as SAP Business Suite; in fact, Tivoli Storage Manager is absolutely pivotal in the restoration of an organizations data in the event of a disaster. Consider these areas in protecting the Tivoli Storage Manager server. A detailed description is beyond the scope of this book, so this is only a basic summary: At the simplest level, the Tivoli Storage Manager application, Tivoli Storage Manager database, and recovery logs can be mirrored either with Tivoli Storage Manager software mirroring, hardware mirroring , or operating system mirroring to different disks to minimize application outages due to disk failures. In addition, disk hot spares, redundant power supplies, or UPSs with power from different sources need to also be used to increase availability. The type of mirroring that you need to use (Tivoli Storage Manager, hardware, or operating system software) is a complex choice, which depends on available resources as well as performance issues. Either Tivoli Storage Manager or hardware (RAID) mirroring is almost always preferred over operating system mirroring. Clustering can be used to provide a highly available Tivoli Storage Manager server and client environment: the TCP/IP network, SAN fabric, Tivoli Storage Manager server, and its associated tape libraries and backup devices. The objective of this highly available environment is to avoid a single point of failure (SPOF). Various high availability software from different vendors is available. Several HA solutions are IBM AIX/HACMP, VERITAS Cluster Server, Microsoft Cluster server, and Tivoli System Automation on Linux. For more details about how to configure Tivoli Storage Manager in a clustering environment, see IBM Tivoli Storage Manager in a Clustered Environment, SG24-6679. High availability requirements of Tivoli Storage Manager server are often closely related to the organizations disaster recovery (DR) requirements. Various tiers of DR strategies can be set in place depending on the Tivoli Storage Manager server uptime requirements. See Disaster Recovery Strategies with Tivoli Storage Management, SG24-6844, for more details. For an enterprise-wide disaster recovery and Business Continuity discussion, see IBM System Storage Business Continuity: Part 1 Planning Guide, SG24-6547, and IBM System Storage Business Continuity: Part 2 Solutions Guide, SG24-6548.
277
10.9 Change management considerations

Stringent change management practices are not only a good practice but are also critical from a security and auditing perspective. Changes can occur at the application code level, policy level, process level, and infrastructure level. Security exposures can result if these changes are not managed properly. Proper procedures must be instituted to ensure that all changes are tested and verified to be working before implementing them in a production environment. Many examples of change management good practices are available on the Internet. Change management is one of the fundamental IT Infrastructure Library (ITIL) processes: http://www.itsmf.org
10.10 Security audit

A security audit is a systematic approach to determine if an organization is in compliance with its security policy. Audits can be performed by internally trained or externally trained auditors. The audit process is an iterative process and can be used as a feedback mechanism to further enhance an organizations security posture. Security auditors normally perform their audit based on industry best practice guidelines. Audits are often performed using automated tools or scripts through interviews with staff and by reviewing audit log trails. A security audit encompasses many areas, for example, IT infrastructure, processes, and staff behavior. The Web site below provides useful links to numerous guidelines and a checklist for auditing information security: http://www.ussecurityawareness.org/highres/infosec-auditing.html In general, the audit process can be divided into three phases: preparation, assessment, and analysis and reporting.
Preparation
Preparation refers to reviewing existing security policies, procedures, and guidelines.
Assessment
Several areas assessed in a typical security audit are: Physical and environmental security: Verifying that the IT infrastructure, including systems, network devices, and telecommunication devices, is safely secured. This area can also include environmental factors, such as humidity, temperature, dust, access control, and so forth. System security: Ensuring that systems and application configurations and settings comply with the configurations and settings outlined in the organizations security policy. This evaluation is often performed through scanning, a penetration test, or vulnerability tools and then reconfirmed through a manual process. Network security: Network security audits are similar to system security audits but are performed against both wired and wireless network devices. In addition, network traffic and protocols are also audited to ensure that confidential data cannot be read. Data security: Verifying backup media is correctly protected both on-site and off-site in accordance with the security policy.
278
Personnel security: This includes personnel screening, for example, matching the security clearance of a person with a particular job role, staff awareness to security policies, and social engineering attacks.
Analysis and reporting

This final phase refers to sorting the vast amount of collected information for reporting to management. It is important to emphasize that you need to think of the security audit as a feedback mechanism to assist your organization with improving security compliance or posture. Sometimes security audits are viewed as to do tasks and the reports generated are not considered very important from a management perspective.Therefore, a Business Impact Analysis needs to always be part of the security report when highlighting the various identified vulnerabilities. Where possible, these impacts must be quantified so that management can provide the appropriate resources to address the issues. Typical questions often encountered in a Tivoli Storage Manager security audit are: User ID management-related questions, for example: What is the minimum password length? When does the password expire? How are user IDs created, suspended, or deleted? What are the access control policies and how are they managed? For example, are they based on a least privilege policy? Does each administrator have a unique user ID? How is critical data encrypted? Are audit logs available and how long are they kept? Are there appropriate permission settings on the Tivoli Storage Manager server binaries? Is physical access to the Tivoli Storage Manager server and storage restricted? What security is available for on-site and off-site tape management? Are regular audits run of the location of all of the tape volumes? Where is the most recent report? Are all on-site tapes in a locked library? How are missing tapes managed? How do you dispose of damaged or obsolete tapes? How are operating systems and Tivoli Storage Manager application vulnerability issues addressed? Is there a process to track and fix issues? Is the LAN connection between the clients and the server secure? We provide guidelines for preparing for and surviving an audit in Chapter 13, Guidelines for audits on page 335.
10.11 Tivoli Storage Manager server running as a non-root user

This section explains how to run your Tivoli Storage Manager server as a non-root user. There are a few considerations, which are explained in this chapter. Running Tivoli Storage Manager as a non-root user also gives you disaster recovery when your Tivoli Storage
279
Manager server is broken or stolen. It also shows the effect you can get from a non-root server in a SAN environment. Note on running multiple servers: This example uses the concepts of running multiple Tivoli Storage Manager server instances on a single physical system. For more information about how to set this up, refer to the Installation Guide or: http://www-1.ibm.com/support/docview.wss?rs=663&uid=swg21052631
10.11.1 Why run as a non-root user

By default on installation, the Tivoli Storage Manager process runs as the root user. There are a lot of good reasons to run your Tivoli Storage Manager server as non-root, the most obvious reason is to improve security. However, running Tivoli Storage Manager as a non-root user also improves the maintainability and availability of your environment. In addition, we show you in our configuration how to externalize the configuration and other required files onto SAN disk, for example. Taken together, these configuration recommendations can help you to restore Tivoli Storage Manager services more quickly after a hardware problem. We show how to perform these customizations on AIX; however, it is possible to do most of these customizations but not all of them for other operating systems. Our recommended configuration sets up not only a separate, dedicated user ID to run each server process but also customizing the names of the file systems, volume groups, and logical volumes used for the server to make administration easier.
Security
The most important reason to run the Tivoli Storage Manager server process (dsmserv) as a non-root user is the same as many other applications. If there is a bug in the code, for example, a buffer overflow, or a hacker finds another way to get control over the dsmserv process, the intruder gets the authority of the user ID running the process. So, if the process is running as root, they get root authority. For this reason, it is common and recommended not to run processes as the root user unless absolutely necessary.
Availability, monitoring, and multiple server instances

Another reason to run dsmserv as a non-root user is if you are running more than one instance. It is possible to run multiple instances as either root or non-root users; however, for clarity, it is a good idea to run each instance as a different user. In Example 10-1, there are two server instances running and each instance is run by a user ID that is the same as the instance. Suppose you are running multiple instances, all on the same user ID. One instance is not responding and you need to kill the server process. How do you know which one to kill if they are all running under the same user ID? However, if you set up your environment according to the process in this section, you can easily detect and kill the correct process. In addition, you can easily identify the configuration files and storage pool volumes that belong to each Tivoli Storage Manager server instance.
Example 10-1 Two instances of dsmserv running as different users
machine01:/home/user > ps -edf|grep dsmserv tsm01 44974 1 0 Feb 07 - 213:34 /usr/tivoli/tsm/server/bin/dsmserv tsm02 50104 1 92 Oct 06 - 18051:37 /usr/tivoli/tsm/server/bin/dsmserv
280
Another use for this configuration is measuring performance on a machine to determine which instance is using what amount of a resource. If all processes run as root, you cannot discover what amount of a resource a particular instance is using easily. However, when you use different users for each instance, it is extremely easy. With our configuration by using the AIX topas command, the server instances are listed separately, as shown in Example 10-2.
Example 10-2 Output of topas
Name dsmserv topas perl syncd dsmserv
PID 50104 71224 63218 14240 44974
CPU% PgSp Owner 12.3 827.3 tsm01 0.2 1.9 imycp 0.0 46.2 root 0.0 0.6 root 0.0 354.4 tsm02
Example 10-3 shows that we have configured separate, easily identifiable home, database, and log (including mirrors) logical volumes and file systems for each server instance. In this configuration, we mirror the database and log; therefore, we have separate file systems and directories to be used for each copy for each instance.
Example 10-3 Different file systems for the users: /home, DB, LOG, and mirrors
machine01:/home/user > df Filesystem 512-blocks /dev/tsm01homelv 1048576 /dev/tsm01db01lv 52428800 /dev/tsm01log01lv 25165824 /dev/tsm01db02lv 52428800 /dev/tsm01log02lv 25165824 /dev/tsm02homelv /dev/tsm02db01lv /dev/tsm02log01lv /dev/tsm02db02lv /dev/tsm02log02lv 1048576 62914560 18874368 62914560 18874368
Free %Used 818616 22% 2244136 96% 808552 97% 2244136 96% 808552 97% 905328 2027464 1159720 2027464 1159720 14% 97% 94% 97% 94%
Iused %Iused Mounted on 252 1% /home/tsm01 28 1% /tsm01db01 15 1% /tsm01log01 28 1% /tsm01db02 15 1% /tsm01log02 179 33 12 33 12 1% 1% 1% 1% 1% /home/tsm02 /tsm02db01 /tsm02log01 /tsm02db02 /tsm02log02
You also can more easily see performance data if you use separate physical disks for each file system. Example 10-4 shows that hdisk11 and hdisk13 are the most heavily loaded disks.
Example 10-4 Performance data using topas
Disk Busy% hdisk11 28.0 hdisk13 21.5 dac0 0.0 dac0-utm 0.0 dac1 0.0 dac1-utm 0.0 hdisk2 0.0 dac2 0.0 dac2-utm 0.0 dac3 0.0 dac3-utm 0.0 hdisk3 0.0
KBPS 104.0 72.0 0.0 0.0 0.0 0.0 0.0 104.0 0.0 72.0 0.0 0.0
TPS KB-Read KB-Writ 25.5 104.0 0.0 20.0 72.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 25.5 104.0 0.0 0.0 0.0 0.0 20.0 72.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
PageIn PageOut Sios
0 0 0
NFS (calls/sec) ServerV2 0 ClientV2 0 ServerV3 0 ClientV3 0
PAGING SPACE Size,MB 4096 % Used 0.6 % Free 99.3 Press: "h" for help "q" to quit
281
In Example 10-5, we list the logical volumes and file systems on each of the loaded disks. We can see that disks contain database and log volumes, which indicates that this is the source of the I/O load rather than storage pools. Note this is a simple example only. For high performance production environments, we normally recommend that you have separate disks for database and logs.
Example 10-5 Output of the lspv command for hdisk11 and hdisk13
machine01:/home/user > lspv hdisk11: LV NAME LPs tsm01log02lv 24 jfs2log01lv 1 tsm01db02lv 50 tsm01homelv 1 machine01:/home/user > lspv hdisk13: LV NAME LPs tsm01db01lv 50 tsm01log01lv 24 jfs2log01lv 1
-l hdisk11 PPs DISTRIBUTION 24 18..00..00..01..05 1 00..01..00..00..00 50 00..17..17..16..00 1 00..00..00..00..01 -l hdisk13 PPs 50 24 1 DISTRIBUTION 17..16..17..00..00 01..00..00..17..06 00..01..00..00..00 MOUNT POINT /tsm01log02 N/A /tsm01db02 /home/tsm01
MOUNT POINT /tsm01db01 /tsm01log01 N/A
So, if you use different user names based on your Tivoli Storage Manager instance name, you can make your server more manageable and easily see what belongs to what instance. Note: The SAN discovery feature on AIX can only be run as root. SAN discovery is a very useful feature of Tivoli Storage Manager for configuring and potentially re-configuring SAN-attached devices. It is especially useful when tape drives have dual SAN paths, because WWPNs can change. You should carefully consider if you will run SAN discovery, before making the configuration changes here to run in a non-root environment. One suggestion is to perform your initial device configuration using the SAN discovery function, while running the Tivoli Storage Manager as root. Then, after you are satisfied with the setup, you can reconfigure as shown here, to run as a non-root user. If you run the Tivoli Storage Manager server as non-root and your SAN configuration changes, you might have to redefine the paths to the SAN devices manually. This can be scripted if required.
10.11.2 Set up the non-root user environment

Here is a summary of the steps required to set up the configuration for non-root authority on the server process. We will cover each step in detail in the following sections. We will set up two server instances, called tsm01 and tsm02. The process can easily be extended to more instances: 1. Define a volume group for each Tivoli Storage Manager instance. 2. Define logical volumes for the users home directories. 3. Create the home file system for the user. 4. Define a group for all Tivoli Storage Manager users. 5. Define the Tivoli Storage Manager users. 6. Define the Tivoli Storage Manager database log and storage pool volumes and adjust access. 7. Adjust file permissions to reflect Tivoli Storage Manager group. 282
8. Make scripts to start and stop the Tivoli Storage Manager service. If you set up your environment for running each Tivoli Storage Manager instance as a different user, use a new group for all these users, for example, called tsm. You need to modify some access rights to the Tivoli Storage Manager binaries for this group later. You can provide scripts for these users to stop and start the corresponding Tivoli Storage Manager instance. If a normal operating system user switches to the Tivoli Storage Manager user (through su), this user can use these scripts to maintain only the corresponding instance, and not accidentally stop the wrong process.
Define a volume group for each Tivoli Storage Manager instance

We use a separate volume group for each dsmserv instance, as in Example 10-6. This is very helpful when using SAN storage. If you want or need to move one instance to another server, for maintenance on the hardware or because of a hardware fault, you easily can map the disks belonging to the volume group to another server including all necessary files to start the dsmserv on a different machine. If you also use unique names for all instances and these names are used for the volume groups and associated logical volumes and file systems, this prevents problems with duplicated volume group names or usernames.
Example 10-6 Separate VG for each Tivoli Storage Manager instance
machine01:/home/user > lsvg rootvg tsm01vg tsm02vg Use multiple disks (LUNs) in each volume group. We recommend using at least one LUN for database, log, and storage pool volumes for each instance. Example 10-7 on page 283 shows multiple LUNs in each volume group. This makes it easy to analyze the performance of a single instance and to isolate the I/O impact of each instance. Example 10-7 on page 283 lists the physical volumes and to which volume group they belong.
Example 10-7 lspv shows your volumes and the volume groups
machine01:/home/user > lspv hdisk0 005aabbcc5dcbe51 hdisk1 005aabbcc5dcbf43 hdisk11 005aabbc5d912eed hdisk12 005aabbc5dafb473 hdisk13 005aabbc5d912d51 hdisk14 00c3f33a43a6a5f6 hdisk15 005aabbc5d9123b2 hdisk16 005aabbc5d912550 hdisk17 005aabbc5d9126f1 hdisk18 005aabbc5d912881 hdisk19 005aabbc5d912a12 hdisk20 005aabbc5d912bb0 hdisk21 005aabbc5dafaf57 hdisk22 005aabbc5dafb118 hdisk23 005aabbc5dafb2bb hdisk2 none hdisk3 none
rootvg rootvg tsm01vg tsm02vg tsm01vg tsm02vg tsm01vg tsm01vg tsm01vg tsm01vg tsm01vg tsm01vg tsm02vg tsm02vg tsm02vg None None
active active active active active active active active active active active active active active active
283
Define LV and home directory for each Tivoli Storage Manager user
Each user ID, which will run a server instance, requires a home directory. When you are using SAN disk storage you can use a SAN disk for the users home directory. You can set up Tivoli Storage Manager to store all necessary files for this instance on this volume. Then, in case of a hardware problem with the physical server, you can mount the disk to another system to restart the instance there. Example 10-8 shows creating a logical volume on tsm01vg which will be the home directory for user ID tsm01. Repeat for tsm02, specifying tsm02homelv and tsm02vg.
Example 10-8 Creating logical volume for /home /tsm01 sample
mklv -ytsm01homelv -tjfs2 -ex tsm01vg 1 <hdisk_name>
Create the home file system for the user

To make a file system for your user, use the commands shown in Example 10-9 to create, mount, and make the file system accessible.
Example 10-9 Creating /home /tsm01filesystem
crfs -vjfs2 -dtsm01homelv -m/home/tsm01 -An -prw -tn -u tsm01fs mount /home/tsm01 The -u parameter is used to put all file systems in one group. You can later easily unmount all file systems for this group, in our case, a Tivoli Storage Manager instance, by using this group name on the umount command.
Define a group for all Tivoli Storage Manager users

Because some files need to be accessed by all Tivoli Storage Manager users, the easiest way is to define a group for all Tivoli Storage Manager users, as shown in Example 10-10 on page 284.
Example 10-10 Creating a group sample.
mkgroup -'A' tsm
Define Tivoli Storage Manager users

In Example 10-11, we define user tsm01 for the Tivoli Storage Manager instance tsm01. Create additional users for other instances and also assign them to the group tsm. Finally, change access and ownership of the home directory created in Example 10-9 on page 284 to your user ID.
Example 10-11 Creating a Tivoli Storage Manager user ID
mkuser pgrp='tsm' fsize='-1' chown tsm01:tsm /home/tsm01 chmod 750 /home/tsm01
tsm01
284
Define server db, log, and storage pool volumes and adjust access
Example 10-12 uses jfs2 and Example 10-13 uses raw volumes to show the difference between setting rights for directories and files and setting access to raw volumes. The database and log are on a jfs2 file system, and the storage pools are on a raw file system. Use similar commands for all the server database, log, and storage pool volumes. Note: In a real environment, we recommend to use either jfs2 or raw for all Tivoli Storage Manager volumes.
Example 10-12 Create database logical volume and file system
mklv -ytsm01db01lv -tjfs2 -ex tsm01vg 278 hdisk11 hdisk13 crfs -vjfs2 -dtsm01db01lv -m/tsm01db01 -An -prw -tn -u tsm01fs mount /tsm01db01 chown tsm01:tsm /tsm01db01
Example 10-13 Creating a storage pool raw volume
mklv -ytsm01001lvlv -traw -ex tsm01vg 200 hdisk14 chown tsm01:tsm /dev/rtsm01001lv
Permission setting for db, log, and storage pool volumes

The installation process of the Tivoli Storage Manager package creates small initial database, log, and storage pool volumes. These should be deleted because we are creating these in our defined directories. We will then initialize the server to point to our configured files. Now, we need to format the database and log volumes, because in our configuration they are using jfs2. You should run the dsmfmt command as the Tivoli Storage Manager user, which owns these volumes. After the format is complete, check the permissions so that they are the minimum required. You will definitely have to adjust ownership and permissions if you run dsmfmt as root. Example 10-14 shows the minimum required permissions. We assume you know how to format the volumes. You will create as many as are required for your configuration.
Example 10-14 Minimum necessary permissions for DB/LOG directories and files
drwx------rw------drwx------rw-------
3 1 3 1
tsm01 tsm01 tsm01 tsm01
tsm tsm tsm tsm
256 210763776 256 2098200576
Jun Feb Jun Feb
13 20 13 20
2006 00:22 2006 00:22
tsm01db01 log01.dsm tsm01log01 db01.dsm
If you are using raw volumes for either database, log, or storage pools, you have to set the access rights for the /dev/r* correctly, as shown in Example 10-15. If you do not do this, the DEFINE VOLUME command will fail as you can see in Example 10-16.
Example 10-15 Minimum necessary permissions for raw file volumes set to 600
crw------crw------crw------crw------crw-------
1 1 1 1 1
tsm01 tsm01 tsm01 tsm01 tsm01
tsm tsm tsm tsm tsm
30, 2 Feb 30, 4 Feb 30, 3 Feb 10, 15 Jun 10, 16 Jun
14 14 12 13 13
19:41 19:47 22:51 2006 2006
/dev/rtsm01001lv /dev/rtsm01002lv /dev/rtsm01003lv /dev/rtsm01004lv /dev/rtsm01005lv 285
crw-------
1 tsm01
tsm
10, 18 Feb 08 04:03 /dev/rtsm01006lv
Example 10-16 Error message on console while defining a volume with wrong permissions
tsm: TSM01>def vol STG_DISK /dev/rtsm01001lv ANR2404E DEFINE VOLUME: Volume /dev/rtsm01001lv is not available. ANS8001I Return code 14.
Adjust file permissions for the user group

Set the permissions of the license files (*.lic) so that all users in the group can access these files, as shown in Example 10-17. If these are not set correctly, you will receive an error in the activity log when registering a license as in Example 10-18. The execute bit for owner and group on dsmlicense should also be set. Note: The Tivoli Storage Manager server seems to check the file permissions on startup only. So, if you change the settings, you will need to restart dsmserv to pick up your changes.
Example 10-17 Minimum permissions for licenses
-rwxr-----rwxr-----rwxr-----rwxr-x---
1 1 1 1
root root root root
tsm tsm tsm tsm
800 831 834 1167004
Dec Dec Dec Dec
08 08 08 08
2004 2004 2004 2004
dataret.lic tsmbasic.lic tsmee.lic dsmlicense
Example 10-18 Wrong permissions for tsmbasic.lic
ANR2017I Administrator ADMIN issued command: REGISTER LICENSE FILE=tsmbasic.lic ANR9625E Could not open file /usr/tivoli/tsm/server/bin/tsmbasic.lic.
Configuration files
The next step is to locate all the needed configuration files in the config directory in the home directory. Sample content is given in Example 10-19. You can copy the sample dsmserv.opt from the Tivoli Storage Manager binary directory to the config directory and modify it. Make sure to set user, owner, and permissions for these files correctly. To prevent dsmserv from being started as other users or from using old or incorrectly configured option files, delete any previous dsmserv.opt, devconfig, volhist, and older, unused dsmserv.dsk from the /usr/tivoli/tsm/server/bin directory. The dsm.opt file is needed for the stop script. This is added as a sample later in this chapter.
286
Example 10-19 Content of /home/tsm01/config
-rw-r-----rw-r--r--rw-r-----rw-r--r-drwxr-sr-x -rw-rw----rw-rw----
1 1 1 1 2 1 1
tsm01 tsm01 tsm01 tsm01 tsm01 tsm01 tsm01
tsm tsm tsm tsm tsm tsm tsm 6401 Feb
3048 Feb 23 06:01 1086 Sep 26 2001 137 Feb 20 00:40 52498 Sep 21 2004 59904 Feb 23 14:00 10465 Feb 20 00:39 23 12:02 volhist
devconf dsm.opt dsmserv.dsk dsmserv.opt log nodelock
To make sure your devconfig and volhistory are stored in this location, set these two options in your dsmserv.opt (which is also located in the config directory).
Example 10-20 Server option files for setting for VOLHISTORY and DEVCONFIG
VOLUMEHistory /home/tsm01/config/volhist DEVCONFIG /home/tsm01/config/devconf Another good preparation for disaster recovery is to add the commented lines in the dsmserv.opt as seen in Example 10-21. These lines, when uncommented, prevent the Tivoli Storage Manager server from listening for sessions and from running any scheduled actions or migrations. Therefore, if you need to run the server completely in standalone mode for maintenance reasons, you can simply uncomment these lines and restart dsmserv in console mode.
Example 10-21 Some options to prevent the server from access during recovery or maintenance
* * * *
This options disable the server!!!! commmethod NONE DISABLESCHEDS YES NOMIGRRECL
To start the server in the foreground, first su to the required Tivoli Storage Manager user (for example, - tsm01) and export all variables as shown in Example 10-22 to point to the correct Tivoli Storage Manager configuration files and the settings for the user.
Example 10-22 Starting dsmserv as Tivoli Storage Manager user in foreground
export DSMSERV_DIR=/usr/tivoli/tsm/server/bin export DSMSERV_CONFIG=~/config/dsmserv.opt ulimit -d unlimited export LANG=en_US dsmserv
10.11.3 Scripts to start and stop the Tivoli Storage Manager service
We use a simple script to start the dsmserv process. This script checks first if the username starts with the string tsm to make sure only our intended Tivoli Storage Manager users can start the process. If other users try to start dsmserv, they get an error, because the dsmserv.opt and dsmserv.dsk do not exist in their home directory. Save this script, for example, starttsm, and store in a directory accessible by all Tivoli Storage Manager users.
287
Example 10-23 A sample script to start dsmserv
#!/bin/ksh # # Variables and initialization # # check TSM administrator ID tsm_admin=`whoami | awk '{print $1}'` if [[ $tsm_admin != tsm* ]] then echo "wrong user\n" exit 8 fi
LOG="/home/$tsm_admin/config/log/start_tsm.log" # environment variable for TSM server code export DSMSERV_DIR=/usr/tivoli/tsm/server/bin # environment variable for dsmserv.opt export DSMSERV_CONFIG=/home/$tsm_admin/config/dsmserv.opt echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $LOG echo "+ STARTING start_tsm ..." `date` >> $LOG echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $LOG if [ ` ps -u$adsm_admin -Fpid,command | grep dsmserv | wc -l ` -gt 0 ] ; then echo TSM server still running as $tsm_admin echo Server not started. exit 2 else ulimit -d unlimited export LANG=en_US # start server echo Server is starting ... cd /home/$tsm_admin/config nohup ${DSMSERV_DIR}/dsmserv >> $LOG 2>&1 & echo $! > /tmp/${tsm_admin}.PID ps -u$tsm_admin | grep dsmserv
exit 0 fi exit 0 A good reason to start dsmserv with nohup and piping all output into one file is that this will capture messages during startup or shutdown or also if Tivoli Storage Manager crashes (which you otherwise would not see). In this configuration, all output is piped to /home/tsm01/config/log/start_tsm.log. You can use tail -f for example to see in real time what is happening on the server. We show sample output from the startup in Example 10-24.
288
If there was a crash of dsmserv, you might also find more information about the crash at the end of start_tsm.log.
Example 10-24 Sample output file
ANR7800I DSMSERV generated at 02:59:54 on May 10 2006. Tivoli Storage Manager for AIX-RS/6000 Version 5, Release 3, Level 3.1 Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 2006. All rights reserved. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation. ANR0900I Processing options file /home/tsm01/config/dsmserv.opt. ANR8227E Fileset devices.common.IBM.fc.hba-api is not at the required level. ANR7813W The 64-bit server is not supported on a 32-bit kernel. ANR4726I The ICC support module has been loaded. ANR0990I Server restart-recovery in progress. ANR7821E Error reading from standard input. ANR0200I Recovery log assigned capacity is 200 megabytes. ANR0201I Database assigned capacity is 2000 megabytes. ANR0306I Recovery log volume mount in progress. ANR0353I Recovery log analysis pass in progress. ANR0354I Recovery log redo pass in progress. ANR0355I Recovery log undo pass in progress. ANR0352I Transaction recovery complete. ANR1635I The server machine GUID, 00.00.00.00.cb.fc.11.d8.a3.af.08.63.c0.a8.02.02, has initialized. ANR2100I Activity log process has started. ANR1791W HBAAPI wrapper library /usr/lib/libHBAAPI.a(shr_64.o) failed to loador is missing. ANR4726I The NAS-NDMP support module has been loaded. ANR1305I Disk volume /dev/rtsm01001lv varied online. ANR2803I License manager started. ANR8200I TCP/IP driver ready for connection with clients on port 1500. ANR2560I Schedule manager started. ANR0993I Server initialization complete. ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use. ANR2828I Server is licensed to support IBM System Storage Archive Manager. ANR2828I Server is licensed to support Tivoli Storage Manager Basic Edition. ANR2828I Server is licensed to support Tivoli Storage Manager Extended Edition. ANR1305I Disk volume /dev/rtsm01002lv varied online. ANR1305I Disk volume /dev/rtsm01003lv varied online. TSM:TSM01> ANR0407I Session 1 started for administrator ADMIN(AIX) (Tcp/Ip loopback(35118)). ANR2017I Administrator ADMIN issued command: HALT ANR0991I Server shutdown complete. start_adsm.log: END To stop the running instance, a simple halt command is used. This command is in a script (Example 10-25) that first checks the user, points to the corresponding dsm.opt, and then issues the HALT command. If you are running multiple Tivoli Storage Manager server
289
instances, make sure the dsm.opt points to the correct tcpport, otherwise you might shut down the wrong Tivoli Storage Manager instance.
Example 10-25 A sample script to stop dsmserv
tsm_admin=`whoami | awk '{print $1}'` if ($tsm_admin =~ /tsm/ || die "wrong user! script must not be started by user $tsm_admin!\n")
# logfile for script errors export DSM_CONFIG=/home/$user/config/dsm.opt # check for executing user ID rm /tmp/${user}.PID dsmadmc -id=userid -pass=password halt exit 0
10.11.4 Location of Tivoli Storage Manager files for disaster recovery

When you set up your server the way we describe, all your configuration and log output files are located in the home directory of the Tivoli Storage Manager user defined for this instance. If your server hardware, for example, is damaged, you can mount the SAN disks to another server and all you need is the same binary level for Tivoli Storage Manager installed locally on this server, plus the start and stop scripts. All configuration and the logged output from the last actions your Tivoli Storage Manager server performed are stored within your home directory.
10.12 References
Chapter 7, Security of AIX 5L and Windows 2000: Side by Side, SG24-4784 AIX 5L Version 5.2 Security Supplement, SG24-6066 http://www.information-security-policies-and-standards.com/ ISO/IEC 17799: http://www.iso.org/iso/en/prods-services/popstds/informationsecurity.html http://www.bizforum.org/whitepapers/ibm.htm (SOX whitepaper from IBM-Tivoli) Hardening Windows by Jonathan Hassell, Apress, 2005, ISBN 1590595394 The Art of Deception: Controlling the Human Element of Security, Kevin D. Mitnick and William L. Simon, Wiley, 2003, ISBN 0-471-23712-4
290
Part 4
Part
Recovery scenarios and summarized guidelines

In this section, we bring together the topics already have been discussed. We describe how to provide a secure disaster recovery environment, information about responding to and preventing security breaches, and finally present a simple set of guidelines to help you configure your environment in preparation for an audit.
291
292
11
Chapter 11.
Providing a secure disaster recovery environment

Providing a secure disaster recovery environment encompasses the complete data protection spectrum. Although disaster recovery of your data is a small portion of the overall Business Continuity Plan (BCP), this data protection is critical to your business survival in times of disaster. This leads us to the question, What is a disaster? We define a disaster as any unplanned event that affects the availability of your IT operation. Consider the following list of potential disaster situations. Your Business Continuity strategy must include actions for recovery for all of these as appropriate. We use this list as a context for discussing the security and recovery of your data using Tivoli Storage Manager in the rest of this chapter: Recovery of application data on a Tivoli Storage Manager client: Human errors: Data deletion and permission changes Data corruption: Recovery log corruption and database corruption Hardware failures: Disk or disk array failures Software failures: Application bugs and incorrect application configuration Malicious intent: Erased, corrupted, stolen or compromised (altered) data Human errors: Erasing client data (backup or archive data) or lost tapes Data corruption: Database or recovery logs Hardware failures: Database, recovery log, or disk storage pool disk failure Software failures: Operating system failure, file system corruption, or software defects Malicious intent: Deleted or stolen client data over network connections or stolen disk or tape volumes Human errors: Removal of critical file systems or deletion of critical files Data corruption: Power failures (spikes or surges) Software failures: Programming errors (defects) Malicious intent: Erased data, stolen disks, or stolen server Hardware failures: Disk array failure (possibly a write cache failure), disk failure, or tape drive failure 293
Recovery of a component of the Tivoli Storage Manager server:
Complete recovery of the Tivoli Storage Manager server:
Recovery due to a computer room failure: Flooding Electrical failures Fire-related damage Vandalism and other malicious actions
Absolute site failure: Act of terrorism: bombing, chemical attack, or biological attack Vandalism and other malicious actions Natural disaster: Typhoon, tsunami, earthquake, ice storm, hurricane, tornado, or flood This chapter focuses on strategies for building secure disaster recovery capabilities within your company by using Tivoli Storage Manager, along with supporting technologies. The secure data disaster recovery encompasses: Secure backup of your critical application data (Tivoli Storage Manager client and API) Secure transmission of your data throughout the company infrastructure (IP and SANs) Secure storage of your data within the Tivoli Storage Manager hierarchy (disk and tape) Secure transmission or transport of your data to an off-site disaster recovery location Secure storage of your data while it resides at the off-site disaster recovery location Secure volume management after your critical data has expired within the Tivoli Storage Manager hierarchy We discuss the choices regarding security and your backup data along with associated risks to these choices. By identifying the obstacles related to building and managing a secure disaster recovery environment, we hope to increase your awareness of security and improve your proactive behavior toward the security of your disaster recovery infrastructure.
Whenever your data physically leaves the safety of your corporately controlled environment, security must become your highest priority.
294
11.1 Disaster recovery planning

Disaster recovery has many meanings to many people. For the purpose of this chapter, we are more narrowly focused on the security of your data while it is managed by Tivoli Storage Manager. Positioning the data recovery appropriately within the Business Continuity planning stage is essential for ensuring that you plan and budget for the correct resources for your business executives approval.
11.1.1 Seven tiers of disaster recovery solutions

The goal of any disaster protection planning is to protect the most business-critical processes and minimize unplanned downtime. Keep in mind that all planning for any type of a disaster-tolerant solution is always subject to balancing the solution as opposed to the downtime as opposed to the cost. The recovery time of any of the seven tiers depends heavily on: Recovery of the IT infrastructure Recovery time for the data availability Restoring the operational processes Restoring the business processes
Recovery from a disk image Recovery from tape copy
BC Tier 7 Site Mirroring with automated recovery
Value (Cost)
BC Tier 6 Storage mirroring (with or without automation) BC Tier 5 Software mirroring (transaction integrity) BC Tier 4 Point in Time disk copy, Tivoli Storage Manager BC Tier 3 Electronic Vaulting, Tivoli Storage Mgr BC Tier 2 Hot Site, Restore from Tape BC Tier 1 Restore Days from Tape
15 Min.
1-4 Hr..
4 -8 Hr..
8-12 Hr..
12-16 Hr..
24 Hr..
Recovery Time Objective

Figure 11-1 Seven tiers of disaster recovery
A breakdown of the seven tiers

In 1992, the SHARE user group in the United States, in combination with IBM, defined a set of disaster recovery tiers. This was done to address the need to properly describe and quantify various methodologies for successful mission-critical computer systems disaster recovery implementations. Accordingly, within the IT Business Continuance industry, the tier concept continues to be used, and it is very useful for describing todays disaster recovery capabilities. They need only to be updated for todays specific disaster recovery technologies and associated Recovery Time Objective (RTO) and Recovery Point Objective (RPO). These seven tiers of disaster recovery solutions offer a simple methodology to define your current service level and to identify the target service level and the required environment to meet your recovery requirements.
Chapter 11. Providing a secure disaster recovery environment
295
BC Tier 0: No off-site data

Businesses with a Business Continuity (BC) Tier 0 disaster recovery solution have no Disaster Recovery Plan. There is no saved information, no documentation, no backup hardware, and no contingency plan. Typical recovery time: The length of recovery time in this instance is unpredictable. In fact, it might not be possible to recover at all. Your business longevity if any disaster occurs is at risk.
BC Tier 1: Data backup using a cold site

Businesses that use BC Tier 1 disaster recovery solutions physically ship their Tivoli Storage Manager copy storage pool and database backup tapes for storage at this facility. Depending on how often backups are transported, these companies are prepared to accept several days to weeks of data loss, but their backups are secure off-site. However, this tier lacks the system infrastructure on which to restore data.
Sample solutions
Solutions are Pickup Truck Access Method (PTAM) and Tivoli Storage Manager Disaster Recovery Manager (DRM) used for recovery.
BC Tier 2: Data backup with a hot site or warm site

Businesses using BC Tier 2 disaster recovery solutions make regular backups on tape (daily). This is combined with an off-site facility and infrastructure (known as a hot or warm site), in which you restore systems from those tapes in the event of a disaster. This tier solution still results in the need to re-create several hours to days worth of data, but it is more predictable in recovery time. Part of the supporting infrastructure often includes high speed network connectivity.
Sample solutions
Solutions are PTAM with a hot site available, Tivoli Storage Manager virtual volume transmitting (secure IP network), or Tivoli Storage Manager electronic vaulting (secure SCSI over IP network). If a Fibre Channel network exists, there is also the possibility of Tivoli Storage Manager electronic vaulting. Tivoli Storage Manager DRM is used for recovery.
BC Tier 3: Electronic vaulting

The BC Tier 3 solutions utilize components of the BC Tier 2. Additionally, all Tivoli Storage Manager copy storage pool data is electronically vaulted. There should be a Tivoli Storage Manager server (the same platform as your production site) connected to the off-site library. As a result, there is less data loss when a disaster is declared. The transition from the state of idle off-site storage to becoming the primary recovery source is much faster than Tier 1 and Tier 2 because the data is physically loaded and ready. This methodology is reliable and very predictable for recovery times. Automation can be built-in and there is significantly less staff resource required for annual or semi-annual testing.
Sample disaster recovery solutions

Solutions are electronic vaulting of data (Fibre Channel network or iSCSI if a secure IP network exists) and Tivoli Storage Manager DRM used for recovery.
BC Tier 4: Point-in-time copies

BC Tier 4 solutions are used by businesses that require both greater data currency and faster recovery than companies who use the lower tiers. Rather than relying largely on tape recovery, which is common in the lower tiers, Tier 4 solutions begin to incorporate more
296
disk-based solutions. Several hours of data loss is still possible, but it is easier to make point-in-time (PIT) copies with greater frequency than data that can be replicated through tape-based solutions.
Sample disaster recovery solutions

Solutions include: Batch/online database shadowing and journaling Metro/Global Copy FlashCopy FlashCopy Manager Peer-to-Peer Virtual Tape Server TotalStorage Productivity Center for Replication Tivoli Storage Manager DRM N series Snapshot
BC Tier 5: Transaction integrity

Tier 5 solutions are used by businesses with a requirement for consistency of data between production and recovery data centers. There is little to no data loss in these solutions; however, the presence of this functionality is entirely dependent on the application in use.
Sample solutions
Solutions include software, two-phase commit, such as DB2 remote replication, MQSeries, or Oracle DataGuard.
BC Tier 6: Zero or little data loss

Tier 6 disaster recovery solutions maintain the highest levels of data currency. They are used by businesses with little or no tolerance for data loss that need to restore data to applications rapidly. These solutions have no dependence on the applications to provide data consistency.
Sample solutions
Solutions include: Metro Mirror Global Mirror z/OS Global Mirror GDPS HyperSwap Manager Peer-to-Peer VTS with synchronous write PPRC Migration Manager TotalStorage Productivity Center for Replication AIX HACMP/XD with Logical Volume Mirroring
BC Tier 7: Highly automated, business-integrated solution

Tier 7 solutions include all the major components that are used for a Tier 6 solution with the additional integration of automation. This allows a Tier 7 solution to ensure consistency of data above that of Tier 6 solutions. Additionally, recovery of the applications is automated, which allows for restoration of systems and applications much faster and more reliably than possible through manual disaster recovery procedures.
297
Disaster recovery solutions

Solutions include: GDPS/PPRC with or without HyperSwap GDPS/XRC GDPS/GM AIX HACMP/XD with Metro Mirror System i High Availability Business Partner Software System i Copy Services Toolkit
Selecting the optimum disaster recovery solution

It is important to understand that the cost of a solution must be in reasonable proportion to the business value of IT. Most of your business requirements are determined during your Business Continuity Planning; although, ideally you do not spend more money on a disaster recovery solution than the financial loss you can suffer from a disaster. Based on the following objectives, it becomes relatively simple to decide, as a business, which solution to select according to how much you can afford to spend and the speed at which you need your data recovered. The quicker the recovery is required, the higher the cost: Recovery Time Objective (RTO) How long can you afford to be without your systems? Recovery Point Objective (RPO) When it is recovered, how much data can you afford to re create? Degraded Operations Objective (DOO) What is the impact on operations with fewer data centers? Network Recovery Objective (NRO) How long to switch over the network? Normally, all the components that make up continuous availability are situated in the same computer room. The building, therefore, becomes the single point-of-failure. While you must be prepared to react to a disaster, the solution you select might be more of a recovery solution than a continuous availability solution. A recovery solution must then be defined by making a trade-off among implementation costs, maintenance costs, and the financial impact of a disaster. These costs are all reviewed as a result of performing a business impact analysis as part of a larger Business Continuity Plan. For more information about Business Continuity planning, see IBM System Storage Business Continuity: Part 1 Planning Guide, SG24-6547.
11.2 Off-site data vaulting

When data is transported (physically or electronically), what do you need to consider? Does the method or technology chosen for off-site data storage affect data security (direct Fibre Channel write as opposed to iSCSI as opposed to virtual volumes as opposed to tape shelving)?
11.2.1 Choosing a balance between cost and security

Data security and the associated threats have evolved over time. Organizations (businesses, government, and other institutions) have invested decades building and managing distributed networks with improved defenses against intrusion. These measures have made the business community more effective at blocking threats from the outside and made it 298
increasingly difficult for hackers or viruses to penetrate and cause damage to valuable information. As these technologies have matured and greatly improved, a growing risk from within the organization has emerged as the future threat. A report by CIO magazine entitled The Global State of Information Security,1 showed that 33 percent of information security attacks originated from internal employees, while 28 percent came from ex-employees and partners. Though certainly not forgotten by businesses, government agencies, and industry analysts, the risk of security breaches from within is often overshadowed by more dramatic intrusions such as denial-of-service attacks, widespread viruses, or outright thefts of intellectual or financial capital. Tivoli Storage Manager is a product designed to provide enhanced data protection and security. However, you must deploy Tivoli Storage Manager on secure networks and configure the product to leverage the level of security that meets your company requirements, including security practices. The result of your efforts produces a secure future for your business and its information.
Why consider tape vaulting (BC Tier 1 and 2)

Previous limitations in both network and storage technologies positioned this traditional storage method as the only off-site option. This method became the baseline for evaluating what an acceptable cost might be and to compare with the business risks of no site coverage at all. Cost is still the primary reason for choosing physical tape vaulting, whether storing the tape volumes at a corporately owned remote vault or a vendors off-site vaulting solution. Technology advancements now include secure data transport and secure storage. In addition, technology improvements have increased performance and decreased the implementation costs (electronic vaulting, for example).
Electronic data vaulting (BC Tier 2 and 3)

Electronic vaulting of tape backups reduces tape-based application recovery time from days to hours. This is a flexible alternative for business systems with more demanding RTOs. Leveraging high speed, high-bandwidth data networks, the electronic vaulting process writes backup data directly to tape devices located at a hot site or warm site data center. With greater scope for automation than traditional tape vaulting, electronic vaulting increases the chances of successfully restoring data. Electronic vaulting also speeds up the overall backup process. Your business RTO is directly related to the cost of computing downtime to your business. When your RTO is less than 24 hours, consider the electronic vaulting option.
When simplicity and automation are important, hot site and warm site configurations remove the potential for human error and the risks associated with physically transporting, storing, and managing your data tapes in a vendors vault. This enhances predictability of the recovery times and can be tested on a regular basis without incurring large testing staff costs. Now, we need to increase the security of your data, which is critical to survival. Creating, transporting, and storing off-site tape volumes, which hold all of your business critical data, has business security teams and auditors considering this option in conjunction with various encryption techniques.
The Global State of Information Security, written by Scott Berinato with Research Editor Lorraine Cosgrove Ware, September 15, 2005
299
Electronic vaulting might encompass disk, tape, or both. Because the data flows electronically, there are no risks associated with physical media transport and handling. Recovery from a site disaster is significantly quicker (less downtime) because the data is already contained within a library or disk system. Depending on the bandwidth to the remote site, recovering data from the copy storage pool tape or disk is quicker than requesting tapes from your vault vendor, which includes the transport of the media, then inserting these tapes into the library for mounting (check in). The actual creation of the copy storage pool tapes can be very close to local tape throughput.
Legal consequences related to lost or compromised data

As of 31 December 2006, 34 US states have passed laws requiring companies to notify clients, employees, and other affected individuals when a breach of personal security occurs. Other countries have similar legislation. An example of this breach might be an off-site copy storage pool tape volume, which is missing and contains personal information of any kind. The subsequent actions equate to thousands, if not millions of dollars for all activities related to notifications, follow-ups, legal costs, financial settlements, and damage to your business reputation. This legislation trend is growing worldwide. Ultimately, you must protect your business data (and client or employee personal information) with the best technology available and consider this as a high priority task.
11.2.2 Hot site and security (BC Tier 2)

A hot site for disaster recovery implies the hardware, software, and networking infrastructure is configured and operating. Because the Tier 2 hot site includes the infrastructure to be production ready, this might include data protection levels that encompass components up to Tier 7. The data held on a hot site can be mirrored or replicated in the disk system and if a site disaster occurs, switching production to a hot site takes minutes to hours, with data loss determined by the actual technology deployed. The networking infrastructure to support a hot site is considerable, and data mirroring or data replication requirements are based on the volume of changed data (block level disk mirroring or replication is used). This model is considered a direct extension of an existing corporate infrastructure, with the hot site facility usually owned by the same company that owns the data being protected, thus maintaining all the characteristics for both physical and logical security. This is considered the most secure off-site storage method with the fasted recovery capabilities and the highest associated cost. The network connectivity is discussed further in 1.5.4, A review of Fibre Channel technology on page 11. In this model, the Tivoli Storage Manager database can be mirrored, replicated, or recovered daily using a full database backup or snapshot. Recovery tests occur daily to validate the capability of remote recovery. The copy storage pool tapes are written directly to the hot-site tape library, which is owned and controlled by the remote Tivoli Storage Manager server (current production). The database is restored daily at the hot site and the remote hot site Tivoli Storage Manager server performs a daily DRM task, giving it visibility to the library and copy storage pool volumes, which is shown in Figure 11-2 on page 301.
300
Production Data Center

Nodes
Hot-site Data Center

Nodes
TSM Server
TSM Server
FC San
Tape Library
Tape Library
Disk System Disk System
Figure 11-2 Production and hot site model
11.2.3 Warm site and security (BC Tier 2)

A warm site is maintained for disaster recovery purposes and the available hardware and communications are not in a state of operational readiness. Because this site is not in a state of operational readiness, either asynchronous data replication or electronic vaulting is used. If a site disaster occurs, switching your production operations to a warm site is measured in hours to days as compared to minutes with a hot site. Following a disaster, a complete data restore is required if only Tivoli Storage Manager electronic vaulting is implemented (copy storage pool data). This facility is considered a direct extension of an existing corporate infrastructure and, therefore, maintains the characteristics for physical and network security as every other site. The networking infrastructure to support a warm site is moderate to none, depending on your RTO requirements and the type of warm site you have deployed. Electronic vaulting or data replication requires more bandwidth and security. Technology choices might lower your bandwidth requirements. Categorizing your data and ensuring you are only transmitting business critical or business important data also reduces bandwidth requirements and cost. In this model, the Tivoli Storage Manager database backup is either written to the remote sites library or direct to disk, which is then replicated. The DRM plan file is either written directly to the remote site or to a disk, which is replicated. The copy storage pool tapes are written directly to the warm site tape library, which is owned and controlled by the remote (current production) Tivoli Storage Manager server. Recovery tests occur often to validate the capability of remote recovery. The Tivoli Storage Manager database is restored at least weekly to the warm site Tivoli Storage Manager server, and the Tivoli Storage Manager server performs at least a monthly DRM task, giving it visibility to the library and copy storage pool volumes. This facilitates weekly recovery tests as required, which is shown in Figure 11-3 on page 302.
301
Production Data Center

Nodes
Warm-site Data Center

Nodes
TSM Server
TSM Server
Private IP ISCSI SAN Network Tape Library
Tape Library
Disk System Disk System
Figure 11-3 Production and Warm site model
The RTO of applications that rely on tape-based disaster recovery strategies is measured in days, rather than hours. The recovery process involves locating the appropriate tapes and transporting them to a disaster recovery site where they can be restored. The interdependence of application systems often complicates the recovery process, requiring a specific sequence of restores before restarting the desired application.
11.2.4 Cold site and security (BC Tier 1)

A cold site for disaster recovery implies the space is temporary, shared with others, and rented on a reserved basis from a service provider. The hardware, software, and networking infrastructure is prearranged based on the requirements supplied to the DR service provider but not available for use unless prescheduled or a disaster situation occurs. Annual or semi-annual recovery tests are performed. There is rarely a network infrastructure connecting the production site to the cold site provider location; typically, these sites have vault locations that will store your copy storage pool data (off-site tapes). This model has a copy of your critical business data stored at the providers site. The physical security is the responsibility of the service provider, and your data is transported to the site daily or weekly depending on your business requirements for recovery and is often referred to as pickup truck access method (PTAM). It is likely your off-site tapes and other media storage requirements might be stored at this site. Storing your off-site media at the same site you have contracted for disaster recovery support makes good business and recovery sense. Because the facility is shared, this requires changes on how the physical security is managed and increases your data risks. In addition to external physical security aspects, how you choose to protect this externally stored data is discussed in Off-site tape security and whether you need to encrypt on page 303. This method is the least expensive; however, it holds the most risk-related considerations. Choosing methods of data encryption becomes critical to maintaining your corporate security. 302
11.2.5 Summary
With security factors, along with your companys RTO, and an overall Business Continuity Plan, you ought to have a clear understanding of your off-site requirements for disaster recovery and ultimately the capital costs to be invested. Knowing your requirements (performance, volume, and security) and capital spending capacity, you can choose the technology in which you are willing to invest (or must deploy), which then influences the distance separating your sites. Combining multiple technologies might help you spread your capital funding further; however, you need to complete the following steps to achieve this: Categorize your data, that is, business critical, important, development, and test data Position your Tivoli Storage Manager infrastructure to leverage the best components (newest, fastest, and most costly) for your most critical and business important data Position all your other data to use less costly technologies, because these technologies have the longest (most) RTO values Following this approach, you apply an information life cycle management (ILM) methodology to data management hierarchies, such as Tivoli Storage Manager. You are able to drastically reduce electronic data volumes by only transmitting critical or business important data while using the less expensive off-site storage (or no off-site) for the less important data.
11.3 Data encryption and disaster recovery

This section discusses briefly not using any encryption and then various encryption methods. We assume that you have already read the chapters about encryption (Part 2, Encryption on page 79). Now, we discuss how these encryption methods apply to disaster recovery, off-site tape storage, and security.
Off-site tape security and whether you need to encrypt

Outside of your secure corporate environment, you transport and store your critical corporate information. The business or legal requirements that result in the need for site disaster coverage are varied and many. Some of the options for transporting and storing data remotely are discussed in this chapter. What method you choose to secure your business from a site disaster is often a matter of weighing cost against the acceptable risk. When considering the costs or overhead to enable encryption, review the risks associated with managing unencrypted data, such as the classic Man-in-the-Middle network attack. This attack relies on convincing two hosts that a computer in the middle is in fact the other host. This attack can be accomplished with a domain name spoof if the system is using Domain Name System (DNS) to identify the other host or Address Resolution Protocol (ARP) spoofing on the LAN. Both of these methods are possible externally (when your data is transmitted over an unsecured WAN) and are possible on your internal network with insider access. From a business perspective, there is little debate on whether to encrypt your data. Encryption provides very high levels of data protection beyond your physical security and at a varying cost, starting with free (included in the cost of the Tivoli Storage Manager license). Your question needs to be what type of encryption is appropriate for your business, including the consideration for off-site data handling and the infrastructure overhead to manage the encryption process.
303
11.3.1 No data encryption used

We do not recommend this option. The risks are high from the time your data is copied from the Tivoli Storage Manager client (application server) through the transporting of these copies throughout your infrastructure and out to your off-site location on tape or electronically. From a purely Tivoli Storage Manager perspective, if both the database backup and the copy storage pool sets of tapes are misplaced or stolen together, your data can be easily recovered by another party.
Steps to reduce risk

In order to reduce risk: Use separate off-site locations for each type of tape (database and copy storage pool). For the highest level of security, you can choose to use separate off-site providers (one for database backups and the other for copy storage pool tapes). Avoid shipping the copy storage pool and database tapes together. Use secure (lockable) containers for transport. Ensure the couriers, who handle your data, are security-cleared (or bonded) or: Choose an off-site vendor that includes a secure transportation option. Verify the complete and accurate movement of tape volumes throughout the data protection life cycle to ensure that all tapes are accounted for. The following are states at which your tape volumes physically move: Ejected from your library Picked up by the courier Received by vault vendor Picked up by the courier for return upon expiration or if needed for restore Arrive at your receiving location Inserted into your library as scratch (or for private use)
Note: Tivoli Storage Manager DRM tracks the tape movement as states. These states match the ones we just listed: NOTMOUNTABLE COURIER VAULT VAULTRETRIEVE COURIERRETRIEVE ONSITERETRIEVE
11.3.2 Tivoli Storage Manager-provided encryption

You can encrypt at the application level, that is, using Tivoli Storage Manager-provided encryption methods.
Tivoli Storage Manager client encryption

Advanced Encryption Standard (AES) 128 bit encryption is available for Tivoli Storage Manager V5.3 or higher clients. See Chapter 5, Tivoli Storage Manager client data encryption on page 81 for more details.
304
The advantage of using Tivoli Storage Manager client encryption is that this type of encryption is secure regardless of how the data is processed or stored downstream. To restore any client data, the decryption key must be supplied either by the user (prompted) or is stored locally in the Tivoli Storage Manager client system (encrypted file or registry entry). Note: If you are using a Bare Metal Recovery (BMR) product, such as Cristie BMR, be aware that using client encryption, which encompasses the complete boot drive, might prevent the boot drive recovery. Backup and restore work as designed using either the Tivoli Storage Manager backup/archive client or the API. However, the bare metal boot process for recovery might not use the Tivoli Storage Manager API layer for the initial phase, therefore, it is unable to decrypt the backup data.

Client encryption does not encrypt Tivoli Storage Manager database backups. To achieve optimal protection for the copy storage pool tapes, which have been encrypted using Tivoli Storage Manager client encryption, review this list:

Client encryption does not encrypt Tivoli Storage Manager database backups. To achieve optimal protection for the copy storage pool tapes which have been encrypted using Tivoli Storage Manager client encryption, the following should be reviewed: Do not ship copy storage pool and database backup tapes together. Implement a corporate policy for the management of encryption key passwords for the many Tivoli Storage Manager clients that encrypt data. Ensure the client encryption key process is documented for use at the disaster recovery location. Verify the complete and accurate movement of tape volumes throughout the data protection life cycle to ensure that all tapes are accounted for. The following are states through which your tape volumes physically move: Ejected from your library Picked up by the courier Received by vault vendor Picked up by the courier for return upon expiration or if needed for restore Arrive at your receiving location Inserted into your library as scratch (or for private use)
Note: DRM tracks the tape movement states that we just listed as: NOTMOUNTABLE COURIER VAULT VAULTRETRIEVE COURIERRETRIEVE ONSITERETRIEVE
Tivoli Storage Manager client API encryption

AES-128 bit encryption is available for Tivoli Storage Manager V5.3 or higher clients. See Chapter 5, Tivoli Storage Manager client data encryption on page 81 for more details.
305
The advantage of using the Tivoli Storage Manager client API encryption is that this type of encryption is secure regardless of how the data is processed or stored downstream. To restore any client API data, the decryption key must be supplied by the Tivoli Storage Manager server. Note: If you are using a Bare Metal Recovery (BMR) product, such as Cristie BMR, be aware that using client encryption, which encompasses the complete boot drive, might prevent the boot drive recovery. The backup and restore process works as designed using either the Tivoli Storage Manager backup/archive client or the API. However, the bare metal boot process for recovery might not use the Tivoli Storage Manager API layer for the initial phase, therefore, it is unable to decrypt the backup data.

Client API encryption does not encrypt Tivoli Storage Manager database backups. To achieve optimal protection for the copy storage pool tapes, which have been encrypted using Tivoli Storage Manager client API encryption, review this list: Do not ship copy storage pool and database backup tapes together. Use separate off-site vendor locations for each type of tape (database and copy storage pool), or for the highest level of security, you might choose to use separate off-site vendors (one for database backups and the other for copy storage pool tapes). Use secure (lockable) containers for transport. Ensure the couriers who handle your data are security-cleared (or bonded) or: Choose an off-site vendor that includes a secure transportation option. Verify the complete and accurate movement of tape volumes throughout the data protection life cycle to ensure that all tapes are accounted for. The following are states through which your tape volumes physically move: Ejected from your library Picked up by the courier Received by vault vendor Picked up by the courier for return upon expiration or if needed for restore Arrive at your receiving location Inserted into your library as scratch (or for private use)
Tivoli Storage Manager server encryption

This method of encryption is configured at the Tivoli Storage Manager device class layer for sequential storage pools on supported tape devices. This encryption method supplies AES 256-bit protection. It is specified using DRIVEENCRYPTION ON in the device class definition and is also known as application-managed encryption (AME) within the IBM Tape Encryption solution. See Chapter 6, TS1120 Tape encryption on page 113 for more information.
306
Note: Specifying DRIVEENCRYPTION ON secures only the user data written to storage pools mapped to the device class. Database backups and backup sets that use the device class are not encrypted. With unencrypted database backups, the database and copy storage pool tapes must not be transported or stored together in order to achieve optimal protection for the copy storage pool tapes, which have been encrypted.

When using AME, your primary risk occurs if an unencrypted Tivoli Storage Manager database backup is lost, stolen, or compromised in some manner. The following suggestions reduce your risk level: Use separate off-site vendor locations for each type of tape (database and copy storage pool). For the highest level of security, you can choose to use separate off-site vendors (one for database backups and another for copy storage pool tapes). Do not ship copy storage pool and database backup tapes together. Use secure (lockable) containers for transport. Ensure the couriers who handle your data are security-cleared (or bonded) or: Choose an off-site vendor that includes a secure transportation option. Verify the complete and accurate movement of tape volumes throughout the data protection life cycle to ensure that all tapes are accounted for. The following are states through which your tape volumes physically move: Ejected from your library Picked up by the courier Received by vault vendor Picked up by the courier for return upon expiration or if needed for restore Arrive at your receiving location Inserted into your library as scratch (or for private use)
11.3.3 System-managed encryption and library-managed encryption

System-managed encryption (SME) and library-managed encryption (LME) are alternatives for tape-level encryption that work with Encryption Key Manager (EKM) software to provide encryption key handling for all tapes written on drives that are encryption capable and configured within EKM. To enable Tivoli Storage Manager to work with SME or LME, DRIVEENCRYPTION ALLOW is specified within the device class definition, and in addition, EKM must be externally configured (see Chapter 6, TS1120 Tape encryption on page 113).
307
The keys and passwords for these encryption types are managed within EKMs keystore, which is external to Tivoli Storage Manager and requires secure management and a backup copy to be maintained. When using either of these methods, all data written to the encryption-capable device class, including storage pools, database backups, and backup sets are encrypted. All tape volumes are equally protected, can travel together, and can be stored together without additional risk.

Important: If your tapes are accessed through a SAN, you must use zoning or other methods to limit access to only systems that require direct tape access (such as the Tivoli Storage Manager for SAN product, which is also known as LAN-free). Without appropriate zoning, any SAN-connected system is able to access tapes and drives within your library. Regardless of whether SME or LME is used, read access to your critical business data is decrypted before forwarding the data to the viewing system. Verify the complete and accurate movement of tape volumes throughout the data protection life cycle to ensure that all your off-site tapes are accounted for. The following are states through which your tape volumes physically move: Ejected from your library Picked up by the courier Received by vault vendor Picked up by the courier for return upon expiration or if needed for restore Arrive at your receiving location Inserted into your library as scratch (or for private use) Note: DRM tracks the tape movement states that we just listed as: NOTMOUNTABLE COURIER VAULT VAULTRETRIEVE COURIERRETRIEVE ONSITERETRIEVE
11.3.4 Off-site encryption key and password handling

As we have seen, there are a number of encryption methods. Each method requires its key (or password) in order to decrypt that specific type of encryption. It is feasible that multiple layers of encryption might coexist, therefore, all layers of the associated key or password information are required to recover the data at the disaster recovery site.
SME and LME

For SME or LME, a disaster recovery site needs the encrypted tapes, the keystore and its password, the EKM, a configuration file, and a drive table. If using LME, a library, not just standalone drives, is also required, because the encryption is configured at the library level. We recommend that you configure and run multiple EKM servers, including an image at the disaster recovery site if you have consistent IP connectivity to the site. If there is no IP connectivity to the disaster recovery site, we recommend that you back up your EKM environment and store it off-site in a secure environment. This backup is critical for any off-site recovery and is considered a single point of failure.
308
Consider a bare metal recovery process for protecting your EKM server. Store this separate media for the EKM server in an off-site (secure) vault. An example of a good System p protection scheme is to have the EKM and Tivoli Storage Manager server on the same system, the Tivoli Storage Manager disk storage pools, database, and recovery log files stored on a SAN device, and the AIX rootvg protected using the mksysb command. More information about protecting the EKM server is in Chapter 6, TS1120 Tape encryption on page 113.
Tivoli Storage Manager client encryption

If using Tivoli Storage Manager client encryption, the client encryption password is required at the disaster recovery location. With Tivoli Storage Manager client levels of v5.4 and above, the encryption key is stored at the client side (or not stored at all and the client owner must supply the password when the files are decrypted upon restore). The Tivoli Storage Manager client API libraries if you use transparent encryption (see 5.5.2, API transparent encryption on page 101) store the encryption key password in the Tivoli Storage Manager server database, not at the client side.
Tivoli Storage Manager server

If application-managed tape encryption is used, the server database must be restored to a system that is of an equivalent binary platform and binary level to the production server.
11.4 Tape and data security using SAN access

When configuring and using tape devices over a SAN (LAN-free or electronic vaulting, for example), appropriate care must be taken to protect access to your library, tape drives, and, ultimately, the tape media. If not restricted through zoning, the tape drive and library are visible to any system (and platform) that has a matching tape driver installed. A program, such as tapeutil (which is provided within the device drive for IBM tape drives and libraries) allows an unauthorized user to mount a tape and read its contents. Other library device drivers and library manager software (client-side drivers) might have the same behavior, although only the IBM tape drivers were tested in this book.
11.5 Virtual volumes and security

Virtual volumes in the context of disaster recovery are used to transmit data (from the source Tivoli Storage Manager server) over an IP WAN connection to a remote Tivoli Storage Manager server (target server). These volumes are not encrypted by the IBM tape encryption solution, because they are not tape volumes. To protect this data, you need to use: VPN with IPSec or SSL External hardware encryption appliances, for example, Decru Tivoli Storage Manager client or API encryption Sending virtual volumes over a public IP network without any additional security represents a serious security risk and is not recommended, because the risk outweighs the benefits of an off-site disaster recovery copy getting stored.
309
11.5.1 A review of virtual volumes

Tivoli Storage Manager enables a server (a source server) to store the results of various operations on another server (a target server) by using server-to-server communication. The data is stored in what are known as virtual volumes, which appear to be normal sequential media volumes on the source server but are actually stored as archive files on a target server. Virtual volumes can be any of these: Server database backups Storage pool backups Data that is backed up, archived, or space-managed from client nodes Client data migrated from storage pools on the source server Any data that can be moved by EXPORT and IMPORT commands DRM plan files The source server is a (special type of) client of the target server, and the data for the source server is managed only by the source server. In other words, the source server controls the expiration and deletion of the files that comprise the virtual volumes on the target server. At the target server, the virtual volumes from the source server are seen as archive data. Figure 11-4 shows the relationship between the source and target Tivoli Storage Manager servers. The source server is registered as a client node (TYPE=SERVER) at the target server and is assigned to a policy domain. The archive copy group of the default management class of that domain specifies the storage pool for the data from the source server.
Other Platforms Windows IBM Tivoli Storage Manager clients
UNIX
LAN/WAN
TCP/IP (Local)
IBM Tivoli Storage Manager source server IBM Tivoli Storage Manager target server
(Remote)
Virtual Volumes
Primary Storage Pool Database Backup Copy Storage Pool Disaster Recovery Plan File
Data Flow
Figure 11-4 Server-to-server virtual volumes
Potential risks using virtual volumes

Virtual volumes written to remote Tivoli Storage Manager servers is a common method to provide site disaster coverage in a more automated and less expensive fashion. This method is less expensive primarily because it uses the IP transport layer (OSI layer 3). The performance of the lower OSI layers is still an important consideration. 310
There are risks that exist for this method of storing your disaster recovery data: If a non-VPN, non-IPsec/SSL secured/non-encrypted network is used to connect the two Tivoli Storage Manager servers (sites), you transmit a large amount of critical company data over an insecure public network; therefore, a risk of a man-in-the-middle (MITM) attack exists. Both servers (target and source) must be available for the recovery of a virtual volume to occur. This creates recovery latency risks during a disaster situation, depending on the scope of the disaster.

To help reduce the risk, follow these steps: Only transmit copy storage pool volumes that have client-encrypted data. Use VPN with IPSec/SSL or other network encryption-based security for all external network segments. Ensure your network provider is capable of delivering your required Class of Service. Test the recovery of copy storage pool volumes and database backups (timing is important). Maintain two database backups (full and snapshot). One backup is on a virtual volume, and the other backup is stored within your tape library: The database snapshot held in your library is used for local server recovery. When using virtual volumes for disaster coverage, ensure the source and target servers are located at different physical sites and not on the same physical server. Turn on cyclic redundancy checking (CRC) with the REGISTER or UPDATE NODE and DEFINE or UPDATE SERVER commands.
11.6 Database backup security

When using SME and LME, transporting and storing the database backup tape is very secure. The tapes are encrypted as we noted earlier and the tape volumes cannot be read without the encryption key stored within the EKM keystore. With or without SME and LME, your database backup tapes need to be managed with DRM, which is a best practice, to ensure accurate tape tracking. You must know where your tape volumes are at all times and reconcile any variances between your physical tape inventory and the DRM inventory immediately. See Chapter 12, Recovery and prevention of security breaches or data loss on page 319 for more information.
11.7 Copy storage pool security

When using AME, SME, or LME, transporting and storing the copy storage pool tapes are very secure because the data is encrypted. A copy storage pool tape is written in a proprietary format, which as we have seen in 8.2, How is data written to storage pools on page 228 might yield some data if given enough effort from a hacker. Therefore, if tape encryption is not deployed, use client encryption on
311
any data backed up to Tivoli Storage Manager so that data in the copy storage pool is not accessible. Manage copy storage pool tapes with DRM (best practice) to ensure accurate tape tracking. You must know where your tape volumes are at all times and resolve any inconsistencies between the logical and physical inventory immediately.

Use these steps to reduce risk: 1. Encrypt copy storage pool data, using Tivoli Storage Manager client (including API) encryption, SME, or LME. 2. Manage copy storage pool tapes with DRM. 3. If the Tivoli Storage Manager database backup tapes are not encrypted, transport the database backup tapes and copy storage pool tapes separately. If data security is critical to your business, we recommend the use of IBM system-managed hardware tape encryption (SME) and library-managed hardware tape encryption (LME) (or equivalent functionality from other vendors) for all of your Tivoli Storage Manager tape volumes. This creates the highest level of data security and simplifies downstream tape handling requirements. If hardware-based encryption is not used, in the short term consider building a key management process to control the Tivoli Storage Manager client encryption key and turn on client encryption (128-bit AES), which protects your data immediately, at least until hardware encryption can be obtained.
11.8 Backup set security

The Tivoli Storage Manager backup set feature creates a set of media, which is a portable self-describing backup of a particular client or group of clients, using either the active versions only or a point-in-time copy of active versions of backup files. This set of media can be written to tape for storage and access within the Tivoli Storage Manager library or written on commonly supported media (between the server and client and is meant to be read directly by the Tivoli Storage Manager client system). Other ways that the Tivoli Storage Manager client can read a backup set might be as a file from a locally attached or network-attached disk. Last, a backup set can be restored through a Tivoli Storage Manager server, where the data is stored within the library. Backup sets are not managed by DRM and if these media sets are removed from a library (or other secure handling environments), they are only visible within Tivoli Storage Manager until the expiration date has been reached. After this date, the media reference is deleted from the volume history file and is no longer visible, therefore, further tracking is not possible using Tivoli Storage Manager. At the point in which the backup set is no longer tracked, you now have a complete self-describing set of media that can be read by any Tivoli Storage Manager client (anywhere and anytime). A manual tracking process must be established to ensure the backup set media volumes, which are stored outside of a library (or physical corporate security environment), are inventoried on a continual basis.
312
If EKM-based encryption is used (SME or LME) and if you want to restore the backup set, the Tivoli Storage Manager client must have access to an EKM compatible drive that supports encryption. This allows for decryption of the backup set data locally (from the directly attached tape device).

Backup sets, which are complete client backups, can be stored off-site. These backup sets might present a security risk. Here are several factors to consider when reviewing backup set security risks: Do not remove backup set media from your library unless the media is required for client restore. Return the tapes to the library after the restore has completed: However, if removing these tapes from your library, use SME or LME if possible: The tape device that is used for the restore must be part of the system and hardware encryption configuration. You require a copy (or backup) of your EKM configuration if there are no communication capabilities from a remote client site.
Alternatively, if removing these tapes from your library, use Tivoli Storage Manager client encryption (128-bit AES): The client encryption key must be secured for disaster recovery situations (documented in a corporate recovery plan).
Whenever backup set tapes are removed from your library, establish and manage a manual tape tracking process to ensure an up-to-date tape inventory is available at all times.
11.9 Active-data pool security

An active-data storage pool copies the most recent backup files (active data) into a separate sequential storage pool for the clients, which are within a Policy Domain and Management Class that has the ACTIVEDESTINATION parameter set to reference a configured active-data storage pool. Active-data storage pools are not managed by DRM, so removing these tape volumes from a library creates an audit exposure and increases your risks related to tape volume tracking. It is a Tivoli Storage Manager best practice to hold your active-data storage pool volumes within your tape library or disk system (if the device type is FILE). In addition, if the active-data storage pool volumes are outside the library, only manual reclamation is possible because unlike copy storage pool tapes, the volumes cannot be re-created from the original pools. In this situation, Tivoli Storage Manager administrators often do not run regular reclamation against these types of storage pools, which ultimately increases risks as the number of tape volumes stored in this manner grows. If active-data storage pool tapes are removed from the library and stored in an off-site location, a manual tracking process must be established to ensure the active-data media volumes, which are stored outside of a library (or physical corporate security environment), are inventoried on a continual basis.

Active-data storage pool tapes can be stored off-site. This presents a security risk, therefore, here are recommendations to reduce this risk:
313
Do not remove active-data storage pools tapes from your library: The best practice is to use copy storage pool tapes for off-site use. If the tapes are removed from the library, use SME or LME (or another tape encryption method): The tape device, which is used for restore, must be part of the SME or LME configuration. If the tapes are removed from the library, use Tivoli Storage Manager client encryption: The client encryption key must be secured for disaster recovery situations (documented in a corporate recovery plan). If the tapes are removed from the library, establish and manage a manual tape tracking process to ensure an up-to-date tape inventory is available at all times.
11.10 Tivoli Continuous Data Protection security

Tivoli Continuous Data Protection (CDP) backups can be protected by 128-bit AES encryption from the source (client system that is protected). Turning this feature on ensures the data backup is protected regardless of the Tivoli Storage Manager downstream configuration.
11.11 Special tape topics

Here, we discuss considerations for tape media, including overwritten or scratch tapes, and how to securely destroy unwanted or failed media.
11.11.1 If a tape is scratched or overwritten, can you still access older data
Assume a tape is returned to scratch after a previous use. It is a common belief that after a tape is relabeled (or transitions to a scratch tape) by Tivoli Storage Manager, this renders the data previously written as inaccessible. What if you reuse the tape but only partially, so that there is still some of the older data on the rest of the tape? Is there any way to read past the new End-of-Data (EOD) marker to get the old contents that have been logically but not physically overwritten? Tivoli Storage Manager does not erase the data on the tape when the data is logically deleted or expired. Instead, Tivoli Storage Manager continually overwrites the previous information and manages this activity by moving the EOD marker along the tape as it appends data. After a tape has been in use and then becomes scratch through the expiration and reclamation process, when the tape is overwritten it physically holds both new and old data with the EOD marker as the separator. Therefore, scratch does not mean empty or erased. A status of scratch only means the tape is available for reassignment into a storage pool. After this reassignment happens, Tivoli Storage Manager begins to overwrite the previous data from the beginning and again logically manages the EOD marker as Tivoli Storage Manager appends to the tape. So, is it possible to read past the current EOD to get to the previous contents of the tape? For IBM Linear Tape Option (LTO) and most other tape technologies, it is very unlikely (although we do not say impossible) that anyone can force the tape to read past the EOD, because the hardware programming (microcode or firmware) prevents any software, such as 314
the device driver or other utilities, from reading past the EOD. Therefore, a quick, effective way to prevent logically deleted data from being retrieved is to immediately write a new Tivoli Storage Manager label on any tapes, which are expired and returned to scratch. This writes a new EOD marker and prevent almost any attempts to read the old data. To completely guarantee erasure of the tape, you can use a secure erase function (for example, with the LTO tapeutil command), to overwrite the old data. Note that it takes the same amount of time to erase the tape as it does to write data to the full length of the tape, so this time must be weighed against the level of security required. For IBM 3590, 3592, and TS1120, clients have requested and been provided with utilities, which do allow reading past the end-of-data mark, for emergency recovery purposes if a tape is accidentally overwritten or relabelled. So, for these devices, only a complete erase and overwrite of the volume ensures previously written data cannot be restored. For TS1120 tapes that are encrypted using SME or LME, a different random AES 256-bit data key is generated for each cartridge. The data key is encrypted in the EKM and is stored exclusively on the tape cartridge. When the tape is reused, the previously used data key is overwritten. Therefore, because the old data key is destroyed, previously written data beyond the new EOD cannot be decrypted even if it is physically readable.
11.11.2 Erasing or destroying media

We recommend decommissioning any data tapes, which log write or read errors as soon as these errors are noted, because it is likely that these types of errors will recur, possibly at a time that allows no time for corrective action (disaster situation). Similarly, when a tape cartridge is no longer needed for any reason, destroy it. Destroying tapes requires special handling practices if there is data physically on the tapes, even after moving the data to another volume.
Disposal methods for various media types

If you do not want to use the tape again, it must be either destroyed or degaussed.
Should you use a vendor for tape disposal

Many vendors offer media collection and destruction services. However, this moves a critical security step outside your companys control. If you choose this process, ensure the following items are included in your contract: Vendor must use uniformed, bonded, and insured couriers. Transportation of media must be in locked steel containers. Your company must provide an observer, who escorts the shipment and witnesses the destruction process. Your company must be supplied with a certificate acknowledging the successful completion of destruction, which lists the items destroyed and the method used. Following these guidelines helps ensure your company has successfully completed the data retention cycle.
Degaussing (bulk or secure erase)

This is used exclusively on magnetic media (4 MM, 8 MM, DLT, LTO, 3580, 3592, 3590, and so forth) A high intensity electromagnet destroys all information on the media so that the media cannot subsequently be written or read. On some type of cartridges, it might be possible to reuse the cartridge after degaussing; for IBM format media (3590, 3592, 3580), the degaussing process erases the servo tracks so that the cartridge cannot be written to again.
315
Check with your vendor for specifications on degaussing their media. Most modern tapes are highly resistant to magnetic fields to ensure the continuing readability of the data over time, which, as a downside, makes them difficult to erase. So you need to make sure your degaussing equipment is powerful enough to delete the data when required. For example, IBM LTO, 3592, and TS1120 media require a two-time degaussing process, rotated 90 degrees after the first pass, on equipment with an electromagnetic field rated at higher than 4000 Oe at the belt surface.
Shredding
Currently, this is the standard process for destroying data on optical formats (laser disc, CD, DVD, optical platter, and so forth) and microforms (microfiche and microfilm) but might also be used on magnetic media. The material is not available for reuse; however, sizes up to 5/8 of an inch might still remain after the process is complete.
Optical erasing
A new technology released into the consumer market in late 2006 erased optical media (CD and DVD) by the use of a single laser that burns away all the ones and zeros. The material must still be disposed of, however, your data has effectively been removed.
Incineration
Incineration is the ultimate in the destruction process. As the name implies, all material is completely incinerated and therefore unavailable for recycling or reuse. Certain highly classified material in both the corporate world and the government sector requires this type of protection. Incineration is the least desirable from a green perspective (highest level of pollution), therefore, choosing a vendor that meets strict emissions standards is important to everyone.
Erasing tape media using operating system commands

Many device drivers include utilities to erase the data. For example, with the IBM tape device driver, use the command tapeutil -f /dev/rmtX erase. On AIX, use tctl -f /dev/rmtX erase. Note that these commands take equally as long as a full tape write (greater than two hours per cartridge) to complete.
11.12 Best practices for off-site data vaulting and security

1. Always test your restore processes: Primary volume recovery Tivoli Storage Manager database recovery Recovery from a server failure due to insufficient space in the recovery log Tivoli Storage Manager server recovery (using DRM) simulating local server recovery from a bare metal condition Tivoli Storage Manager server recovery 2. Only remove Tivoli Storage Manager database backup and copy storage pool tapes from your library. These are tracked by DRM: Maintain backup sets within the production or off-site library. Only remove them for immediate client recovery, then return the tape as soon as the recovery is complete. 3. Categorize your data based on levels of business (or legal) importance: Only store your business critical and business important data off-site.
316
4. Create copy storage pools for low priority data, which is stored locally at the production site: Copy storage pools protect against failure of individual media only. 5. Use multiple small copy storage pools or group collocation for your business critical and important copy storage pool data: This reduces the tape contention and during a site disaster recovery, reduces the number of copy storage pool tapes required within the library during restore operations (100 critical client tapes, instead of 500 tapes if only one large copy storage pool is required). 6. Application encryption (Tivoli Storage Manager client, API encryption, or AME) needs to be used for all business critical or business important data. 7. SME or LME (or equivalent functionality provided by other vendors) is used for any Tivoli Storage Manager full (or snapshot) database backup cartridges, which are removed from the library: When there is no SME or LME, transport and store the Tivoli Storage Manager database backup separately from the copy storage pool data. 8. All electronic vaulting is transferred over: An encrypted IP network segment, using VPN, IPSec, or SSL-based encryption OSI layer 1 Fibre Channel network 9. All copy storage pool data needs to consist of active and inactive data.
317
318
12
Chapter 12.
Recovery and prevention of security breaches or data loss

There are many security-related challenges in your computing environment. Some challenges are malicious in nature and other challenges are more innocent, such as administrator and operator errors. All types represent risks to your business critical data. This chapter discusses possible Tivoli Storage Manager and data failure scenarios, then discusses: Security risks associated with the scenario Recommendations for resolution Recommendations for reducing the current risk Recommendations to reduce the risk of recurrence Whether the reason for a failure is due to a breach of security, a failed component, or a natural disaster, we discuss these situations with security in mind because compromised corporate data is becoming more prevalent in todays computing world. Compromised data (stolen or a malicious intent to destroy the data) is certainly not a normal situation; however, it is statistically more likely than most large scale natural or man-made disasters, such as earthquakes, storms, or terrorist attacks. In all cases, you must rehearse recovery scenarios in a test environment. Do not wait until you experience an incident to perform these procedures for the first time. Regular verification of recovery procedures improves your staffs ability to perform them under pressure, as well as expose any process weaknesses or omissions. Our examples and recommendations leverage IBM tape encryption solutions; however, it is important to mention that other vendor encryption solutions exist and might exist within your corporate enterprise. Implementing and managing multiple layers and types of encryption might require additional testing and process management.
319
12.1 Legal and compliance issues

Security incidents involving loss of data are extremely serious because of your legal compliance obligations to clients, employees, business partners, and ultimately your share holders. If you experience this type of loss, your enterprises Security Incident team has standard procedures and notifications that need to be followed. This chapter focuses on how to reconcile your backup repository in the event of certain loss situations. However in all cases, you need to work closely with the Security procedures to ensure the incident is properly documented, tracked, audited, closed, and disclosed. The timing of all these activities needs to be synchronized with any internal or external process requirements. We now present a series of possible failure or breach scenarios.
12.2 Missing storage pool volumes

This section discusses missing storage pool volumes, including the risks to your business if you suspect the missing volumes have been stolen. Maintaining all your primary pool volumes within your tape library or disk systems located within your corporate secure environment is the most secure data protection policy. Primary or copy sequential pool volumes (standalone without the Tivoli Storage Manager database) are protected by writing the data to tape in a proprietary method, and these methods require the Tivoli Storage Manager database to reference the files on the tape. However, it can be possible to extract some data from these tapes if someone has enough time and experience - see 8.2, How is data written to storage pools on page 228. Avoiding situations that cause primary tape volumes to be removed from your library is a sound prevention for lost tapes. If your business is approaching a library full condition, we recommend you perform timely capacity planning to make sure you can acquire and deploy tape libraries sufficient to meet your growing capacity needs. If your library is not big enough, you need to eject and store some tape cartridges. The human resource effort to account for and reconcile a tape volume audit increases dramatically as the number of tape volumes not managed within a library increases. Note: If a tape is missing, the actions recommended in the following sections are intended to help you re-create the data within the Tivoli Storage Manager repository and to synchronize the database entries. As long as the tape is not located, the tape is vulnerable to unauthorized access. If at a later time you find the missing tape, you need to overwrite or destroy its contents, as described in 11.11.2, Erasing or destroying media on page 315.
12.2.1 Missing copy storage tape volume

There are a few reasons why you might not be able to account for a copy storage pool tape volume. Reasons include but are not limited to: The tape volume is physically located in an overflow location and not at your off-site vault: Tivoli Storage Manager Disaster Recovery Manager (DRM) was used; however, a new member of staff placed the tape on a shelf instead of in the courier case.
320
DRM was not used and the volume ACCESS and LOCATION fields were not properly updated before removing the tape volume. The tape volume was removed from the library without performing a CHECKOUT LIBV command: The volume ACCESS and LOCATION fields were not properly updated before removing the tape volume. The tape volume was damaged in some way (tape drive failure, picker failure, or dropped during external handling) and was discarded without updating Tivoli Storage Manager or notifying an administrator. The DRM state was not updated when the volume was moved: This might especially be true if the tape is in VAULTRETRIEVE state, yet not found at the off-site vendor location. The incorrect volume was moved with no manual VOLSER checking done. The tape volume was ejected using library device driver commands without updating DRM or the Tivoli Storage Manager volume ACCESS or LOCATION fields. When a copy storage pool tape has been lost (unavailable and cannot be located), there is the potential for a breach of security (risk to your data). Immediately investigating the root cause of the missing tape is critical to corporate data security.
Recommended resolution steps

We recommend you take these steps: 1. Review the content of the missing volume. Ensure you assess the corporate risk (legal and business) based on the Tivoli Storage Manager client system and the related files stored on the missing tape volume. Use this command to view the content: q content <missing_volser> 2. Review volume history output for the missing volume: q volhistory Pipe the output to a file and search for the entries related to the missing volume. 3. Review library output for the missing volume: q libv library_name <missing_volser> 4. Review the activity log for instances of the missing volume: q actlog begind=-360 search=<missing_volser> 5. Review DRM output for the missing volume: q drm <missing_volser> 6. Review historical DRM Recovery plan output to look for any reference to the missing volume. 7. Review DRM hardcopy printouts for outgoing and incoming tapes (operational logs): Most data center security audits require someone to verify the volume has been handled and moved to the next stage in the tape management process. 8. Contact your off-site vendor and request a physical inventory, then verify your vault inventory is as expected. 9. Search all physical locations in which your tape volumes are stored or have been stored in the past. 10.Review all hardware service logs that might be maintained in your data center.
Chapter 12. Recovery and prevention of security breaches or data loss
321
11.Inventory your tape library by using the following command, depending on your library: mtlib -l /dev/lmcp0 -qI (3494 library) tapeutil -f /dev/smc0 inventory (SCSI library) Note: External library managers provide Tivoli Storage Manager with the inventory details. Thus, if there is any discrepancy between the actual library inventory and the library manager inventory, you need to resolve this discrepancy within the library manager software, not Tivoli Storage Manager. If you find any variances between the Tivoli Storage Manager inventory and the library, use the AUDIT LIBRARY command to restore the inventory to a consistent state. Missing volumes are deleted and the locations of the moved volumes are updated. However, new volumes are not added during an audit. After completing the options just listed or if the volume was damaged in any way, use the following steps for resolution: Critical note: If the volume cannot be located and contains information that requires legal disclosure, print the Q CONTENT output and contact your business management. Do not
continue to the following commands until you are approved to do so.

12.DELETE VOLUME <missing_volser> DISCARDDATA=YES 13.BACKUP STGP PRIMARY_STGP COPY_STGP
Risks if a copy storage pool tape is lost (or stolen)

The risks are: High to extremely high without encryption: High as a standalone tape volume depending on the content of the missing volume Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing volume Low to extremely high if encrypted with application-managed encryption (AME): Low as a standalone tape volume, which is encrypted Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing tape Low if encrypted with system-managed encryption (SME) or library-managed encryption (LME) Low if encrypted with Tivoli Storage Manager client encryption
Recommended steps to offset current risk

Determine the content of the missing volume and take the appropriate business and legal action based on the lost data.
Recommended steps to offset future risks

We recommend that you consider the following items to offset future risks: 1. Implement any one of the following encryption options: Hardware-based encryption, for example, TS1120 SME, AME, or LME Tivoli Storage Manager client encryption, including API encryption 322
2. Implement electronic vaulting, which reduces physical media handling.
12.2.2 Missing primary storage pool tape volume

There are a few reasons why you might no be able to account for a primary tape storage pool volume. These reasons include but are not limited to: The tape volume is physically located in an overflow location. The volume ACCESS and LOCATION fields were not properly updated prior to the tape volume being removed. The tape volume was removed from the library without performing a CHECKOUT LIBV command. The volume ACCESS and LOCATION fields were not properly updated before removing the tape volume. The tape volume was damaged in some manner (tape drive, picker, or dropped) and was removed from the library without updating Tivoli Storage Manager. The tape volume was ejected using library device driver commands. The root cause of missing primary pool tapes can be a library full condition when tapes which need to be stored within the library instead are placed on shelves in the data center or some other location. This is a data security risk, an audit exposure, and certainly not a best practice. Capacity planning needs to be regularly performed to avoid emergency library full conditions, because after you start to store overflow tapes externally to the library, this can easily turn into a common and risky practice.

We recommend that you follow these steps: 1. Review the content of the missing volume. Ensure you assess the corporate risk (legal and business) based on the Tivoli Storage Manager client system and the related files stored on the missing tape volume. Use this command to view the content: q content <missing_volser> 2. Review volume history output for the missing volume: q volhistory Pipe the output to a file and search for the entries related to the missing volume. 3. Review library output for the missing volume: q libv library_name <missing_volser> 4. Review the activity log for instances of the missing volume: q actlog begind=-360 search=<missing_volser> 5. Review historical DRM Recovery plan output looking for any reference to the missing volume. 6. Search all physical locations in which your tape volumes are stored or have been stored in the past. 7. Review all hardware service logs that might be maintained in your data center. 8. Inventory your tape library by using the following command depending on your library: mtlib -l /dev/lmcp0 -qI (3494 library attached to AIX as an example) tapeutil -f /dev/smc0 inventory (SCSI library attached to AIX as an example)
323
Note: External library managers provide Tivoli Storage Manager with the inventory details. Therefore, if there is any discrepancy between the actual library inventory and the library manager inventory, you need to resolve this discrepancy within the library manager software, not Tivoli Storage Manager. If you find any variances between the Tivoli Storage Manager inventory and the library, use the AUDIT LIBRARY command to restore the inventory to a consistent state. Missing volumes are deleted and the locations of the moved volumes are updated. However, new volumes are not added during an audit. Critical note: If the volume cannot be located and contains information that requires legal disclosure, print out the Q CONTENT output and contact your business management. Do not continue to the following commands until you are approved to
do so.
9. After exhausting your options or the tape was damaged, perform the following steps:
Critical note: Before restoring the volume, you must be sure that the incident has been correctly recorded according to your Security management procedures, because after these steps, there is no record in Tivoli Storage Manager that the data is missing.
a. Determine which copy storage pool volumes need to be recalled from the vault: restore volume <missing_volser> preview=yes b. Recall the volumes listed from your off-site location. Or, if you have an on-site copy storage pool, the volumes can be accessed immediately. c. After the volumes arrive, check these volumes into the library as private volumes: checkin libv library_name <incoming_volser> status=private d. Update the copy storage pool volumes to prevent writing to the tape: upd vol <missing_volser> access=ro e. Restore the volume: restore volume <missing_volser> Note that this command changes the original volume to status DESTROYED until all files are restored. After all files are restored, the original volume is deleted from the database. f. Check out the copy storage pool volumes: checkout libv library_name <outgoing_volser> remove=yes
Risks if a primary pool tape is lost (or stolen)

These are the risk levels if a primary pool tape is lost or stolen: High to extremely high without encryption: High as a standalone tape volume, depending on the content of the missing volume Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing volume 324
Low to extremely high if encrypted with AME: Low as a standalone tape volume, depending on the content of the missing volume Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing volume Low if encrypted with Tivoli Storage Manager client encryption Low if encrypted with SME or LME The root cause of missing tapes can be a library full condition, when tapes which should be stored within the library instead are placed on shelves in the data center or some other location. This is a data security risk, an audit exposure, and certainly not a best practice. Capacity planning must be regularly performed to avoid emergency library full conditions, because after you start to store overflow tapes externally to the library, this can easily turn into a common and risky practice.


We recommend that you consider taking the following items to offset future risks: 1. Implement any one of the following encryption options: Hardware-based encryption, for example, TS1120 SME, AME, or LME Tivoli Storage Manager client encryption, including API encryption 2. If your business is approaching or currently is experiencing a library full condition, initiate a a capacity planning exercise to make sure you can acquire and deploy a library, which meets your growing capacity needs. The staff resource effort to account for and reconcile tape volume audit exposures increases dramatically as the number of tape volumes not managed (stored outside of the library and not tracked by DRM) increases. The cost associated to legal disclosure based on lost tapes likely exceeds the cost of increasing your library capacity.
12.2.3 Missing active-data storage pool tapes

Active-data storage pool tape volumes contain a complete set of the most recent files found on a Tivoli Storage Manager client (as of the last backup session). These volumes are different from normal primary storage or copy storage volumes because they are not tracked by DRM. There are a few reasons why you might not be able to account for an active-data tape volume. These reasons include but are not limited to: The tape volume is physically located in an overflow location. The volume ACCESS and LOCATION fields were not properly updated before removing the tape volume. The tape volume was removed from the library without performing a CHECKOUT LIBV command. The volume ACCESS and LOCATION fields were not properly updated before removing the tape volume. The tape volume was damaged in some manner (tape drive, picker, or dropped) and was removed from the library without updating Tivoli Storage Manager.
325
The tape volume was ejected using library device driver commands.

We recommend: 1. Review the content of the missing volume. Ensure you assess the corporate risk (legal and business obligations) based on the Tivoli Storage Manager client system and the related files stored on the missing tape volume. Use this command to view the content: q content <missing_volser> 2. Review volume history output for the missing volume: q volhistory Pipe the output to a file and search for information about the missing volume. 3. Review library output for the missing volume: q libv library_name <missing_volser> 4. Review the activity log for instances of the missing volume: q actlog begind=-360 search=<missing_volser> 5. Search all physical locations in which your tape volumes are stored or have been stored in the past. 6. Review all hardware service logs that might be maintained in your data center. 7. Inventory your tape library by using the following command, depending on your library: mtlib -l /dev/lmcp0 -qI (3494 library attached to AIX as an example) tapeutil -f /dev/smc0 inventory (SCSI library attached to AIX as an example) Note: External library managers provide Tivoli Storage Manager with the inventory details. Therefore, if there is any discrepancy between the actual library inventory and the library manager inventory, you need to resolve this discrepancy within the library manager software, not Tivoli Storage Manager. If you find any variances between the Tivoli Storage Manager inventory and the library, use the AUDIT LIBRARY command to restore the inventory to a consistent state. Missing volumes are deleted, and the locations of the moved volumes are updated. However, new volumes are not added during an audit. Critical note: If the volume cannot be located and contains information that requires legal disclosure, print out the Q CONTENT output and contact your business management. Do not continue to the following commands until you are approved to
do so.
8. After exhausting your options or the tape was damaged, perform the following steps: update vol <missing_volser> access=destroyed delete vol <missing_volser> discardd=yes copy activedata <primary_stgp> <active_stgp>
326
Critical note: Deleting the volume, then rebuilding the active-data storage pool does not adversely affect your data inventory because the data is a copy of active data held within a primary storage pool. This activity does not alleviate any risks; it merely updates your active-data storage pool inventory.
Risks if an active-data pool tape is lost (or stolen)

The risks are: High to extremely high without encryption: High as a standalone tape volume, depending on the content of the missing volume Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing volume Low to extremely high if encrypted with AME: Low as a standalone tape volume, depending on the content of the missing volume Extremely high if there is a Tivoli Storage Manager database backup missing, depending on the content of the missing volume Low if encrypted with Tivoli Storage Manager client encryption Low if encrypted with SME or LME The root cause of missing tapes can be a library full condition when tapes that need to be stored within the library instead are placed on shelves in the data center or some other location. This is a data security risk, an audit exposure, and certainly not a best practice. Capacity planning must be regularly performed to avoid emergency library full conditions, because when you start to store overflow tapes externally to the library, this can easily turn into a common and risky practice.


We recommend that the following items be considered to offset future risks: 1. Implement any one of the following encryption options: Hardware-based encryption, for example, TS1120 SME, AME, or LME Tivoli Storage Manager client encryption, including API encryption 2. If your business is approaching or currently is experiencing a library full condition, initiate a a capacity planning exercise to make sure you can acquire and deploy a library that meets your growing capacity needs. The staff resource effort to account for and reconcile tape volume audit exposures increases dramatically as the number of tape volumes not managed (stored outside of the library and not tracked by DRM) increases. The cost associated to legal disclosure based on lost tapes likely exceeds the cost of increasing your library capacity. 3. Implement electronic vaulting.
327
12.2.4 Summary
There are normal operating situations that might occur where a tape falls through the process cracks and is lost due to human error. As you investigate such incidents, document them and build process improvements when required. We have emphasized the importance of: Capacity planning in ensuring you have sufficient tape library capacity to meet your current and projected needs. Organizations that do not pay attention to capacity planning usually end up either removing tapes from the library, reducing retention values, or deleting backup data as a workaround. All of these actions represent risks to security. Using encryption properly ensures that even if the worst happens and a tape falls into the wrong hands, the data is protected from access.
12.3 A missing or stolen database backup tape

The Tivoli Storage Manager database holds all the pointers to objects in the storage pools (data offsets into the storage media), as well as metadata about the Tivoli Storage Manager server itself. Proper protection and a backup regime for the Tivoli Storage Manager database is an absolutely fundamental component of any implementation. See the product documentation or IBM Tivoli Storage Manager Implementation Guide, SG24-5416, for more information.

If the most recent database backup tape is missing, immediately make another full database backup. Until you create another backup, you are vulnerable if your live database needs to be restored. If the missing tape was your most recent off-site database backup, make a new snapshot backup to replace it.
Risks if a database backup is lost (or stolen)

The security risk is high if a Tivoli Storage Manager database backup is missing, and the tape is not encrypted. Note that the only way to encrypt a Tivoli Storage Manager database backup is using external tape encryption (for example, TS1120 SME or LME). If the tape is not encrypted, it can be read by a device driver or data extraction tools or restored (using Tivoli Storage Manager dsmserv restore db command to a like platform) if the tape is loaded on a drive using a similar tape technology. Often the latest model of a drive technology read all older or smaller tape formats. While you cannot extract any actual file data from a database tape alone, because this is stored in the storage pools, other information about your computing environment can be discovered, which then positions your environment for a malicious attack. The information that is available in the Tivoli Storage Manager full database backup includes: Internal IP addresses Client node names, which are often identical to host names Employee names and contact numbers if these are stored in the contact fields of administrator and client node definitions Encrypted client and administrator passwords Listing of all file spaces per client node
328
Complete storage pool volume content (every tape and disk path and file and directory name) Listing of all path and file information per client node Server-to-server passwords (encrypted) Events and activity logs Details of every client session (amount of data, number of objects, backup times, and many other session details) that are backdated for the length of time that the activity retention is set Server scripts Client options sets All Tivoli Storage Manager server volume information
Recommended steps to offset the current risk

If you suspect that a database backup has been stolen, we suggest a simple step that helps protect the integrity of your Tivoli Storage Manager client/server connections: 1. Determine if you are missing any tape volumes from your library or data center. If storage pool volumes are also missing, the risk level is highly elevated. 2. Determine if there are any missing tapes at your off-site vault location. If copy storage pool volumes are also missing, the risk level is highly elevated. 3. Alter Tivoli Storage Manager passwords by performing the following commands at the administrative CLI: Change the password expiry value for all nodes and administrators to one day: SET PASSEXPIRY 1 RESET PASSWEXPIRY Reset the common password expiry value: This forces password resets. Although this might seem like an extreme action, it is a simple and quick step for proactive data protection. When the password expiry option is changed, the following can be anticipated: For PASSWORDACCESS GENERATE clients, this automatically happens on the next connection (for example, a scheduled backup or it can be forced through an immediate client action schedule for all nodes), For PASSWORDACCESS PROMPT, this generates the message to change the password. For the Tivoli Storage Manager administrators, their next server access prompts them to change their password. Reset any server-to-server passwords, including for Storage Agents (UPDATE SERVER command).
4. After passwords have been reset, perform a Tivoli Storage Manager full database backup. These actions invalidate all the passwords that are stored within the missing Tivoli Storage Manager database backup and ensure there is no ability to use any of these passwords for malicious purposes. Man-in-the-Middle scenarios, which utilize methods such as Address Resolution Protocol (ARP) and Domain Name System (DNS) spoofing, still require methods to gain the trust of the other systems that they want to victimize. Changing client and administrator passwords as soon as a Tivoli Storage Manager database backup appears to be missing is the simplest protection against this form of attack.
329
Nevertheless, the other information contained within the stolen database might be deemed a security risk, according to your organizations policy.

We recommend that you consider the following steps to offset future risks: 1. Create a new database backup (or verify one will be created in the near future). 2. Use electronic vaulting for database backups to minimize the existence and movement of physical media. 3. Implement hardware-based encryption, for example, TS1120 SME or LME. 4. Implement secure tape handling practices using DRM to minimize the risk of loss.
12.4 Stolen Tivoli Storage Manager server

A break in at your corporate data center or remote site has resulted in your Tivoli Storage Manager server being stolen (complete physical system, including internal disks). Less commonly, someone might have mistakenly relocated or readdressed the server so that it is no longer reachable on the network. Understanding the following items helps you establish what you have lost and what is required to recover. Note that a lot of this information is normally retrieved by querying the Tivoli Storage Manager database. At this point, you have to rely on other sources, such as DRM plan files (or other saved configuration files and environment information if you do not use DRM), reports from your off-site vendor, or any other external record keeping. Here are several initial questions you must consider: How old is your most recent database backup? At what time did the server disappear (check client backup logs)? Were the disks hosting the database and recovery log taken? Were the disk storage pools stolen: How much data was lost on the disk storage pools? When did your last backup storage pool operation complete? Are there any tape volumes missing? How long will it take to acquire replacement hardware and rebuild the server?

We recommend that you take these steps: Note: Recovering from this scenario is a fairly complex operation. Our process presented here assumes you have been using DRM. If you use custom tools and methods to record your configuration information, you need to adapt them for recovery. Our process is not intended to be a complete flowchart for recovery, because every failure situation is unique. We attempt to summarize the basic required steps. Regular testing of disaster recovery procedures is essential, so that the process can be verified and customized for your environment. See Disaster Recovery Strategies with Tivoli Storage Management, SG24-6844, for more information about disaster recovery scenarios.
330
1. Build a new Tivoli Storage Manager server: Acquire hardware and software. Use the DRM Plan for sizing reference. Use the DRM Plan to rebuild your server. 2. After your Tivoli Storage Manager server database has been recovered, you might need to run the commands: a. audit library library_name Ensure the Tivoli Storage Manager database and the library inventory are in sync. b. dsmserv auditdb Look for any errors during the restore db or dsmserv startup process that do not appear normal (normal is missing volumes, incorrect time, and so forth). c. audit volume Look for any missing files or volume-related errors. d. restore volume Run this command if the audit volume reports errors and cannot fix them. If primary volumes are missing, use your copy storage pool volumes to rebuild. e. restore stgpool Use this command when you believe that a backup stgpool command had been run before the server and disk storage pools were removed. This command can recover lost files in the random access pools.
Risks if your Tivoli Storage Manager server is stolen

Risks are: 1. Does the stolen server configuration hold the database and recovery log files on the internal disk structure? If yes, review 12.3, A missing or stolen database backup tape on page 328 to view some potential data found in the database. 2. Are any tapes missing based on your latest DRM Plan? Check for missing tapes through a physical inventory of your library, local shelves, and off-site vendor facilities that hold your Tivoli Storage Manager tape volumes. If there are volumes missing, refer to 12.2.1, Missing copy storage tape volume on page 320 and 12.2.2, Missing primary storage pool tape volume on page 323 to understand the potential impact. 3. Are there any internal disk storage pools missing: Do you have storage pool caching configured? Are you delaying migration from any internal disk storage pools? Was either backup stgpool or migration run based on the time that the server disappeared? 4. Have the clients completed backups prior to the server going off-line? Review your client logs for information about how much data was sent and at what time did this task complete.
331
Recommended steps to offset current risks

The risks related to losing a Tivoli Storage Manager server vary based on the data content and the type of protection used for the tape volumes (the actual data). These are the risk levels: If the complete server loss includes a recent Tivoli Storage Manager database, see 12.3, A missing or stolen database backup tape on page 328, which explains steps to reduce the risks associated to your current production environment. After recovery of the Tivoli Storage Manager server using your most recent database backup tape and assessing your risk by establishing what data is missing, follow your local legal requirements regarding the disclosure of a breach of security (personal information).

We recommend that you consider the following steps to offset future risks: 1. Implement SME or LME to encrypt the Tivoli Storage Manager database backups. 2. Store your Tivoli Storage Manager database and recovery log volumes on a separate physical system, such as a SAN disk system. This action minimizes the impact of a particular theft. 3. Improve your physical site security.
12.5 Missing client backup set tapes

Backup sets, which are complete self-describing client backups, can be stored off-site. Here are factors to consider when reviewing backup set security risks. Are you using either SME or LME: If yes, will your client system have access to the Encryption Key Manager (EKM) keystore? If no, was the client data originally backed up using Tivoli Storage Manager client encryption: If no, the client data is at risk and the backup sets must be stored in a secure access-controlled environment. If yes, the client encryption key must be backed up and documented in your disaster recovery plan. This helps ensure recovery in a disaster recovery scenario.

There are no actions that you can take to avoid unwanted usage of these tapes, because if they are not encrypted, by design they are self-describing and therefore readable on any system with a compatible tape drive and operating system. Resolution steps are focused on investigation and future prevention steps: 1. Perform a postmortem to understand why this situation occurred. Adjust processes based on findings. 2. Reevaluate backup set use (ensure business needs are greater than security risks).
Risks related to losing a backup set

The risks related to losing a client backup set vary based on the data content and the type of protection used. Here are the risk levels:
332
Extremely high without encryption Because this is a standalone, self-describing set of tapes, this client can easily be compromised. This risk is also dependent on the content of the Tivoli Storage Manager client system (including the application data held within the backup set). Low if you have implemented Tivoli Storage Manager client encryption. Low if you have implemented SME or LME.
Recommended steps to offset current risks


We recommend that you consider the following steps to offset future risks: 1. Implement one of the following encryption options: Hardware-based encryption, for example, TS1120 SME or LME Tivoli Storage Manager client encryption 2. Include your backup set requirements when performing capacity planning for your tape library. You need to store your backup sets inside the library unless and until they are required to be shipped to Tivoli Storage Manager client location. Note: As always, pay attention to capacity planning to avoid experiencing a library full condition.
12.6 Unauthorized tape drive and library and data access

With the use of the tapeutil command in the IBM tape device driver for Windows, Solaris, Linux, HP-UX, and AIX, it is possible for an unauthorized user to access data over a SAN. If TS1120 EKM-based encryption (SME or LME) is used, this user requires access permissions to run the tapeutil command and must configure the ibmekm.conf file, which allows access to the EKM server port. In this situation. any system that has the IBM tape driver installed and is physically connected to the same Storage Area Network as your library and tape drives has decrypted data access, regardless of the use of SME or LME. The SME or LME design assumes that if an application (or system) has physical access with EKM configuration (one line entry in a single configuration file), this is sufficient security. What the implementer and data owners (users) must realize is there is no system or user security between hosts that have physical access to the tape library; therefore, any system, which has SAN tape access, also has uncontrolled and decrypted data access.

The recommended steps are: 1. Implement a standalone (isolated) tape SAN that only connects your Tivoli Storage Manager server, tape library, tape drives, and Tivoli Storage Manager for SAN clients (LAN-free clients).
333
2. Secure your company SAN with appropriate zoning to control access to the tape drives and library using Host Bus Adapter WWPN addresses. This is a best practice, which often is overlooked. 3. Restrict knowledge and if possible access to your EKM server port (access control using tcpwrappers or a similar program) if access is not controlled by allowing only authorized system access.
12.7 Encryption-related recovery topics

In Part 2, Encryption on page 79, we discussed various forms of encryption, specifically: Tivoli Storage Manager client encryption Tivoli Storage Manager client API encryption TS1120 tape encryption, including AME, SME, and LME Each encryption method has specific management needs to ensure key or password security is maintained. As part of the security of encryption, there is the potential for lost data due to breakdowns in processes, hardware, or software all relating to the security of the keys and passwords.
12.7.1 A lost, forgotten, or destroyed client encryption key

This is a significant single point of failure for the client encryption mechanism. The key can be stored locally in the TSM.PWD file or, for Windows systems, within the registry. When the PASSWORDACCESS GENERATE and ENCRYPTKEY SAVE options are set, there is no need to enter the password or encryption key when restoring provided the save file or registry entry is valid. If a client system failure occurs, and the boot drive must be restored, these files do not exist, and the user must supply the encryption password. If the encryption password is not supplied, the data is not restored. There is no recovery for this failure situation.

Implement a secure key handling mechanism for any Tivoli Storage Manager client encryption keys. This must be secure and must also be included in your site disaster recovery plans.
334
13
Chapter 13.
Guidelines for audits

Over time, a Tivoli Storage Manager server configuration changes and expands. A common scenario is that someone works on the system and creates definitions of various objects, such as storage pools, client definitions, policies, scripts, and so forth, perhaps for testing or for diagnostic purposes. The individual forgets to delete these definitions after the definitions are no longer needed, and the individual might change to another job or company. What if you inherit this scenario? How do you discover out what sort of cleanup is necessary? Here are several tips from our experience that are based on the most common issues raised during an audit. A general guideline to keep in mind is to give any entity, whether it is people, computers, processes, or devices, only the rights and privileges needed to perform the particular task.
335
13.1 Administrators
Suggestions for administrators: Delete all unused or extra administrator IDs. Ensure security policies are in place for administrator passwords. We recommend that you delete the default ADMIN account before you do any other server configuration, such as registering nodes, defining schedules, and so forth. If you do not delete the ADMIN account, at a minimum, change the default password (admin). Each Tivoli Storage Manager administrator needs to have and use their own administrator ID with only the authority that is required. Use secure remote access sessions to the Tivoli Storage Manager server operating system, for example, SSH.
13.2 Nodes
Recommendations for nodes: Delete any old or unused node definitions. Make sure backed up data for expired or defunct nodes is retained according to enterprise requirements. Delete any old or unused proxy definitions. Client node password policies need to be configured according to enterprise standards and enforce regular changes. Monitor restore activity for unusual behaviors: SELECT START_TIME,ACTIVITY, ENTITY FROM SUMMARY WHERE ACTIVITY='RESTORE'
13.3 Policy
Suggestions for your policy: Check for unused policies, management classes, and copy groups. Delete them if they are not needed. Use storage pool shredding for random access pools to ensure deleted data cannot be salvaged. Delete any old or unused schedule definitions.
336
Query the management class usage to determine which management classes are in use and which management classes are not, and then determine why not. Remove the management classes that are not required: Note: Be careful when running the following SELECT statements and consider other tasks that might run concurrently. On very large databases or at very busy processing times, running these SELECT statements might contribute to overall performance degradation. A large server during a quiet time might take one or more hours to return results. Consider redirecting the output to a file, and ensure your session timeout is long enough. for backups, use: select distinct node_name,class_name,state,count(*) as backups from backups group by node_name,class_name,state for archives, use: select distinct node_name,class_name from archives group by node_name,class_name
13.4 Encryption
Suggestions for encryption: AES 128-bit is a minimum level. Tivoli Storage Manager client encryption is inexpensive, is fairly lightweight, and provides end-to-end security. Use Tivoli Storage Manager as a minimum level of security, especially if tape or other hardware encryption is not available. TS1120 application-managed encryption (AME) puts key management within Tivoli Storage Manager. TS1120 system-managed encryption (SME) and library-managed encryption (LME) encrypt all data, including Tivoli Storage Manager database backups. TS1120 SME and LME prevent access to data on tapes that have been illegally removed from the library. If you use the Encryption Key Manager (EKM), have a redundant EKM server and back up your configuration files. Encryption performed by a dedicated appliance encrypts all data, including Tivoli Storage Manager database backups. Always encrypt your WAN segments (VPN and IPSec/SSL). Make sure your key management strategy works so that you know the location of your keys, including knowing where your keys are in a disaster scenario.
13.5 Physical security

Recommendations for physical security: Do not leave the keys to devices on top of the cabinet. Know and audit who has physical access to devices. Make sure your SAN is designed with security in mind. Techniques, such as zoning and LUN masking, must be used to prevent unauthorized device access.
Chapter 13. Guidelines for audits
337
13.6 Media
Recommendations for media: Store all sequential primary storage pool volumes in your secured library. Do you know where your tapes are? All of them? Implement a tape tracking mechanism and perform regular audits of the location of all volumes. When disposing of old media, make sure it is securely erased or physically destroyed. Consider separating transport and storage of Tivoli Storage Manager database backup and copy storage pool tapes, especially if they are not encrypted. Verify service level agreements (SLAs) and the liability of your off-site storage vault provider.
13.7 People
Suggestions for your people: Apply the principle of least privilege. Restrict root and Administrator access to as few people as necessary. Restrict physical access to your Tivoli Storage Manager server, including disk and tape storage, to as few people as necessary. Make sure that functional backup is in place for key personnel in the event of a disaster. Implement audit trails so that you can trace who performed what action and at what time. Implement and publicize security awareness policies to protect against social engineering attacks.
13.8 Processes
Recommendations for processes: Perform regular security audits to ensure compliance and to prevent surprises on external audits. Document your recovery scenarios and regularly test them because these recovery scenarios must be repeatable, reliable processes: Primary volume recovery Tivoli Storage Manager database recovery Recovery log expansion process from the command line, which you use if you accidentally run out of recovery log space Tivoli Storage Manager server recovery (using DRM), simulating local server recovery from a bare metal condition Tivoli Storage Manager server recovery at or simulating a disaster recovery (DR) site recovery Regularly check for the latest hardware and operating system fixes and firmware updates.
338
13.9 Categorize your data

Suggested ways to categorize your data: Based on levels of business and legal importance: Only store off-site your business critical and business important data. Reduce the amount of off-site data for cost control and recovery efficiency. Consider multiple smaller copy storage pools or group collocation for your business critical and business important copy storage pool data. This reduces the tape contention, and during a site disaster recovery, reduces the number of copy storage pool tapes required within the library during restore operations (100 critical client tapes compared to 500 total tapes if only one large copy storage pool is required). Copy storage pools for data with lower importance can be stored at the production site in an overflow location, which provides media disaster coverage yet greatly reduces costs that might be incurred for transmission or transporting these tapes.
Chapter 13. Guidelines for audits
339
340
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see How to get IBM Redbooks publications on page 343. Note that some of the documents referenced here may be available in softcopy only. IBM Tivoli Storage Management Concepts, SG24-4877 IBM Tivoli Storage Manager Implementation Guide, SG24-5416 IBM System Storage TS1120 Tape Encryption Planning, Implementation, and Usage Guide, SG24-7320 IBM Tivoli Storage Manager in a Clustered Environment, SG24-6679 Disaster Recovery Strategies with Tivoli Storage Management, SG24-6844 IBM System Storage Business Continuity: Part 1 Planning Guide, SG24-6547 Securing NFS in AIX An Introduction to NFS v4 in AIX 5L Version 5.3, SG24-7204 IBM System Storage TS1120 Tape Encryption Planning, Implementation, and Usage Guide, SG24-7320 Chapter 7, Security, of AIX 5L and Windows 2000: Side by Side, SG24-4784 AIX 5L Version 5.2 Security Supplement, SG24-6066
Other publications
These publications are also relevant as further information sources: IBM Tivoli Storage Manager for AIX Administrator's Guide, SC32-0117 IBM Tivoli Storage Manager for AIX Administrator's Reference, SC32-0123 IBM Tivoli Storage Manager for HP-UX Administrator's Guide, SC32-0118 IBM Tivoli Storage Manager for HP-UX Administrator's Reference, SC32-0773 IBM Tivoli Storage Manager for Linux Administrator's Guide , SC32-0119 IBM Tivoli Storage Manager for Linux Administrator's Reference, SC32-0125 IBM Tivoli Storage Manager for Sun Solaris Administrator's Guide, SC32-0120 IBM Tivoli Storage Manager for Sun Solaris Administrator's Reference, SC32-0126 IBM Tivoli Storage Manager for Windows Administrator's Guide, SC32-0121 IBM Tivoli Storage Manager for Windows Administrator's Reference, SC32-0127 IBM Tivoli Storage Manager for z/OS Administrator's Guide, SC32-0122 IBM Tivoli Storage Manager for z/OS Administrator's Reference, SC32-0128 IBM Tivoli Storage Manager for UNIX and Linux Backup Archive Clients Installation and Users Guide V5.4, SC32-0145
341
IBM Tivoli Storage Manager for Windows Backup Archive Clients Installation and Users Guide, SC32-0146 IBM Tivoli Storage Manager for Windows Backup Archive Clients Installation and Users Guide, SC32-0144 IBM Tivoli Storage Manager Using the Application Program Interface, SC32-0147 IBM Encryption Key Manager - Introduction, Planning and Users Guide, GA76-0418 IBM Tape Device Drivers - Encryption Support, GA32-0565 IBM System Storage TS1120 Tape Drive and Controller Operator Guide 3592 Models J1A, E05, J70 and C06, GA32-0556 IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560-01 IBM Encryption Key Manager component for the Java platform Introduction, Planning, and Users Guide, GA76-0418 A report by CIO magazine, The Global State of Information Security, written by Scott Berinato with Research Editor Lorraine Cosgrove Ware, September 15, 2005 Hardening Windows by Jonathan Hassell, Apress, 2005, ISBN 1590595394 The Art of Deception: Controlling the Human Element of Security, Kevin D. Mitnick and William L. Simon, Wiley, 2003, ISBN 0471237124
Online resources
These Web sites are also relevant as further information sources: National Institute of Standards and Technology web site: http://csrc.nist.gov/CryptoToolkit/tkencryption.html ISO/IEC 17799 http://www.iso.org/iso/en/prods-services/popstds/informationsecurity.html IT Governance Institute http://www.itgi.org/ IT Service Management Forum http://www.itsmf.org HIPPA http://www.hipaadvisory.com/REGS/HIPAAprimer.htm Security-related Web sites http://www.cert.org http://www.first.org http://csrc.ncsl.nist.gov http://www.securityfocus.com http://www.sans.org OpenSSH http://www.openssh.org TS1120 information http://www.ibm.com/systems/storage/tape/
342
EKM http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504 Keytool User Guide http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDo cs/KeyToolUserGuide-142.htm Unrestricted JCE policy files https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk AIX Documentation http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp Windows 2003 Security Services http://www.microsoft.com/windowsserver2003/technologies/security/default.mspx Technote #1231106, Enabling the Secure Sockets Layer (SSL) for the Integrated Solutions Console V 6.0.1 Official Certificates: http://www-1.ibm.com/support/docview.wss?uid=swg21240020 http://www.information-security-policies-and-standards.com/ http://www.bizforum.org/whitepapers/ibm.htm (SOX white paper from IBM Tivoli)
How to get IBM Redbooks publications

You can search for, view, or download IBM Redbooks publications, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy IBM Redbooks publications or CD-ROMs, at this Web site: ibm.com/redbooks
Help from IBM

IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services
Related publications
343
344
Index
Symbols
/etc/ibmekm.conf 148 business continuity 277 Business Impact Analysis 279
A
access controls 34 access permissions 39 accounting records 176 ACL 270 Active Directory 269 active-data storage pool 228, 313, 325 activity log 173 ACTLOG event receiver 177 ad hoc mode 273 adddrive 137 ADMIN_CENTER ID 169 administrative authorities 26 administrative sessions 28 administrator roles 172 administrators 38 ADMINONCLIENTPORT 250 AES 17, 115 AES128 19, 82, 188 AIX topas 281 allow clients to delete archives 183 allow clients to delete backups 183 ALMS 125 API client encryption 82, 100 application managed encryption 100 transparent encryption 101 API file access 43 application firewall 271 Application-Managed Encryption 114, 121, 126, 306 ASIC 115 asymmetric encryption 1718, 117 asymmetric key encryption 17 asynchronous data replication 301 Atape device driver 124, 147 proxy configuration file 148 audit trail 172 authentication 24 authentication methods 60 authority of scheduled commands 69 authorized user 34, 39, 41, 52 availability 4, 266
C
categorize data 303 CDP 314 Certificate Authority 18 certificate labels 138 change management 278 CIFS 53 cipher text 16 circuit level gateway 271 Client Acceptor Daemon 47, 5152 client access privilege 26, 39, 167 See also Web client client authentication 24, 60 client authentication methods 60 client compression 88 client encryption 82, 198 client key management 90 client option set 76 client owner privilege 26, 39, 167 See also Web client client password 60 client registration 182 client scheduling modes 184 client services and daemons 47 client sessions 27 client thread types 29 client threads multiple 28 client transaction 31 client-initiated communication 249, 252 CLIENTORSERVER 253 client-server communication 26 closed client registration 182 clustering 277 cold site 296, 302 command action schedules 68 command line authentication 24 command routing 191 compression 231, 235 confidentiality 4, 266 configuration manager 194 configure SSL ISC communication 210 connect with TSM administrator ID 205 CONSOLE event receiver 177 Consumer thread 2829 copy storage pool 228, 244, 320 copy storage pool security 311 CRC 311 Cristie BMR 305306 cross client restore 70
B
backup Network File System 56 Backup Operators group 38 backupset security 312 Barcode Encryption Policy 123, 142 BEP see Barcode Encryption Policy buffer 24
345
D
dapismp 102 data categorization 303 data encryption keys 89 data movement 13 data shredding 237 data transport 7 deactivated nodes 74 degaussing 245, 315316 DES 13, 17 DES56 19, 82, 188 digital certificate 18 disaster recovery 277 Disaster Recovery Manager 6, 15 disaster recovery planning 295 disaster recovery tiers 295 disk quota 49 disk storage pool 229 DK 117 DMZ 248, 277 DOO 298 DRIVEENCRYPTION 114, 123124, 143, 306307 dsmapi 208 dsmfmt 285
E
EAP 274 EEDK 117, 143 EKM 113114, 198 EKM configuration file 132 EKM Jar file 131 electronic vaulting 296, 299, 301 enabling client encryption 91 enabling for client 91 encryption 12, 16, 82, 91, 114, 231, 303, 337 asymmetric 117 best practices 153 Certificate Authority 18 data encryption keys 89 digital certificate 18 hardware 16 HSM 112 include/exclude statements 91 key management 88 key manager 18, 114, 129 keystore 18, 117, 132 LAN-free 112 managing client keys 90 offsite encryption and password handling 308 offsite tapes 303 performance overhead 105 policy 119 recovery 334 server-to-server communication 188 session keys 88 session traffic 82 software 16 symmetric 17, 115, 117 Tivoli Storage Manager API client 82, 100, 305
Tivoli Storage Manager client 19, 198, 236, 304 TS1120 114 with ALMS 125 with compression 88 with long-term data retention 90 Encryption Key Manager 113114, 116, 307 adddrive command 137 backup and recovery 152 certificate labels 138 components 118 configuration file 118, 132, 134 configure devices 140 configuring 129 connectivity test 140 Data Key 117 define tape drives 137 DR considerations 152 EEDK 117, 143 expired certificates 139 high availability 118 Internal Label Encryption Policy 143 Jar file 131 Java security keystore 118 KEK 117 Key Labels 117 KeyManagerConfig.properties 134 keystore 117118, 132, 308 keystore password 132, 154 keytool 132 manage expired certificates 139 multiple servers 118 proxy configuration file 148 Public Key 117 recover configuration 152 register server with tape library 139 self-signed certificates 133 start server 135 synchronize configuration 152 System-Managed Encryption 147, 322, 325 tape drive table 118, 155 tape library/drive configuration 140 unrestricted policy files 131 encryption policy configuration 119 ENCRYPTKEY 91, 334 ENCRYPTKEY PROMPT 8889 ENCRYPTKEY SAVE 88 environmental threats 5 EOD 314 erase media 245 event receivers 177 Event Server 177 expired password 63 external threats 5
F
Fibre Channel 11 Fibre Channel Network Extender 12 FILE event receiver 177 filetext exit event receiver 178 firewall 13, 248
346
application 271 packet filtering 270 stateful multilayer inspection 272 force password reset 183 FROMNODE 70, 72
key management 88 key manager 18, 114, 129 KeyManagerConfig.properties 134 keystore 18, 117118, 132, 308 keytool 132
G
GDPS 297 Global Copy, FlashCopy 297 Global Mirror 297
L
LAN-free encryption 112 LDAP 269 LEAP 274 least privilege 160 Library-Managed Encryption 115, 123, 141, 307308, 311314, 317 Linux Network File System 56 operating system security 268 Tivoli Storage Manager services 51 LLADDRESS 254 Local Service account 48 Local System account 48, 52, 54 lock cipher 19 lost copypool tape 322 lost or compromised data 300
H
HACMP 277 HACMP/XD 297 hardware encryption 16 HIPAA 3 HLADDRESS 254 hot site 296, 299300 HSM encryption 112
I
IBMi5OSKeyStore 118 IBMKeyManagementServer.jar 131 IDS 272 IIS 270 ILM 303 infrastructure mode 273 initiating scheduled sessions 252 Integrated Services Console see ISC 169 integrity 3, 266 Internal Label Encryption Policy 143 internal threats 5 INVALIDPWLIMIT 67 IPS 272 IPSec 1213 ISC 202, 205 add administrators 202 ADMIN_CENTER ID 169 configure SSL communication 210 SSL connection 207 iSCSI 296 ITIL 278
M
Main thread 29 manage administrative IDs 195 MANAGEDSERVICES 25, 51 managing client keys 90 Man-in-the-Middle network attack 303 MAXNUMMP 30 MAXSESSIONS 30 MBSA 270 media security 338 Metro Copy 297 Metro Mirror 297 Migration Manager 297 minimum password length 182 MINPWLENGTH 67, 183 mirrored database and log 300 missing active-data tape 325 missing backupset 332 missing primary tape 323 missing storage pool volumes 320 MMC 199 multi-mode fibre 11 multi-session clients 28 multi-session function 29
J
JACL 221 Java runtime environment 129 Java security keystore 118 JCE4758KS/JCECAAKS 118 JCE4785RACFKS/JCECCARACFKS 118 JCEKS 118, 130, 134 JCERACFKS 118 JRE 129
N
NDMP 53 Nessus 274 Network File System 56 network interface devices 8 network security 4, 270 NFS 56 node deactivated 74
K
KEK 117 Kerberos 269 Key Labels 117
Index
347
non-authorized user 36, 40 non-client sessions 27 NRO 298 NT EventLog event receiver 180
Q
QUERYAUTH 170, 173 QUERYSCHEDPERIOD 184
O
offsite data movement 15 offsite data vaulting 298 offsite location 5 offsite tape rotation 6 offsite vaulting 15 onsite data movement 14 open client registration 182 OpenSSL 18 operating system security 4, 267 operating system users 34 Operational Reporting 198 OSI 7 physical layer 1 10 overwritten tape media 314 ownership 39
R
RAID 277 reclamation 245 Redbooks Web site 343 Contact us xviii regulations lost or compromised data 300 regulatory compliance 3, 320 remote access 70 removable media 6 rename node 75 REQSYSAUTHOUTFILE 170 RESOURCEUTILIZATION 2931 REVOKEREMOTEACCESS 70 root access 45, 267 RPO 298 RTO 298299, 301 run as non-root 279
P
packet filtering firewall 270 PASSEXP 67 password 60 password expiry 63, 182 password file 35, 63 password file permissions 63 password policy 267 password processing 61 password rules 67 PASSWORDACCESS GENERATE 35, 43, 5152, 6061, 70 PASSWORDACCESS PROMPT 61 Performance Monitor thread 29 PKCS11|mplKS 118 plaintext 16 point-in-time copies 296 policy management 196 polling scheduling 184 POSTNSCHEDULECMD 68, 185 POSTSCHEDULECMD 68, 185 POSTSNAPSHOTCMD 68 PRENSCHEDULECMD 68, 185 PRESCHEDULECMD 68, 185 PRESNAPSHOTCMD 68 prevent client-initiated sesions 186 primary storage pool 228 principle of least authority 160 private-key cryptography 17 Producer thread 2829 prompted scheduling 184, 251 proxy node 73 PTAM 296, 302 Public Key 117 Public/Private Key pair 132
S
SACL 38 SAN 6 security 337 tape and data security 309 Sarbanes-Oxley 3, 267 SCHEDCMDDISABLED 68, 186 SCHEDCMDUSER 6869 SCHEDMODE 251, 253 SCHEDRESTRETRDISABLED 69, 186 schedule pre/post commands 68 scheduled client operations 185 scheduled command authority 69 scheduled commands 68 scheduled restores 69 scheduler authentication 25 scheduler password 258 scheduler service 256 scheduling modes 184 Scratch Encryption Policy 123, 142 scratch tape 314 SCW 269 security 202 availability 266 breaches 319 confidentiality 266 data center 5 disk storage 6 firewall 13 human aspects 276 integrity 266 media 338 network 4, 270 objectives 3 operating system 4, 267 SAN 6
348
social engineering 276 storage 6 threats 5 wired network 270 wireless network 273 security audit 278, 335 security compliance 3 security objectives 34 Security Policy 266 see EKM self-signed certificates 133 server name 183 server stanzas 62 server summary table 174 server to server communication 188 SERVER_CONSOLE ID 169 server-initiated communication 249, 252253 SERVERONLY 253 server-to-server communication 16, 188, 310 server-to-server sessions 28 session and transaction concepts 28 session control 184 session encryption 82 session initiation 186, 252 session keys 88 session owner 41, 43 session traffic encryption 82 session types 27 SESSIONINITIATION 186, 251, 253254 SET AUTHENTICATION 60 shared drives 52 short-wave 11 shredding media 316 SIEM 273, 275 Signal Waiting thread 29 single-mode fibre 12 SME see System-Managed Encryption 115 SNMP 27 SNMP event receiver 178 SOAP 222 social engineering 276 software encryption 16 SONET 12 source server 310 SRVPREPOSTSCHEDDISABLED 68, 186 SRVPREPOSTSNAPDISABLED 186 SSID 273 SSL 12, 207, 210, 269, 309 stateful multilayer inspection firewall 272 stolen copypool tape 322 stolen Tivoli Storage Manager server 330 Storage Agent 249 storage media 6 storage pool 228 for tape encryption 126 storage pool format 228 storage pool volume missing 320 storage pool volume permissions 235 SUID 24
suid 24 superuser 34 symmetric encryption 17, 115, 117 sys_encryption 149 System State 51 System-Managed Encryption 115, 124, 147, 307, 322, 325
T
tape drive 114 tape drive encryption 114 tape drive table 118, 155 tape encryption 235 encryption tape 19 tape storage pool volume 230 tape vaulting 299 tapeutil 231, 245, 333 target server 310 TCPADMINPORT 251 TCPCLIENTADDRESS 251, 254 TCPCLIENTPORT 249, 251, 254 TCPPORT 250 TDES 13 Tivioli Storage Manager scheduled restores 69 Tivoli Continuous Data Protection 314 Tivoli Security Compliance Manager 275 Tivoli Security Operations Manager 273, 275 Tivoli Storage Manager 56, 60, 91, 279, 300 access controls 34 access permissions 39 accounting records 176 active-data storage pool 228, 313 activity log 173 ACTLOG event receiver 177 ADMIN ID 169 ADMIN_CENTER ID 169 administrative authorities 26 administrative IDs 168, 336 administrative port 251 administrative privilege 170 administrative roles 160 administrative sessions 28 administrator roles 172 administrators 38 allow clients to delete archives 183 allow clients to delete backups 183 allow only root access 45 analyst privilege 167 API client encryption 82, 100, 305 API file access 43 Application-Managed Encryption 121, 126, 306 audit trail 172 authentication 24, 60 authority of scheduled commands 69 authorized user 35, 39, 41, 52 backup shared drives 52 backupset security 197, 312 Client Acceptor Daemon 47, 5152 Index
349
client access privilege 26, 39, 167 client authentication 24 client authentication methods 60 client encryption 19, 82, 198, 231, 236, 304 client key management 90 client option set 76 client owner privilege 26, 39, 167 client port 250 client registration 182 client scheduler 47 client scheduling modes 184 client services and daemons 47 client sessions 27 client thread types 29 client-initiated communication 249, 252 client-server communication 26 closed client registration 182 clustering 277 command action schedules 68 command line authentication 24 command routing 191 compression 88, 231, 235 configuration manager 194 CONSOLE event receiver 177 Consumer thread 28 control authentication 182 copy storage pool 228, 244, 300 copy storage pool security 311 cross client restore 70 data encryption keys 89 data movement 13 data shredding 237 data transport 7 database backup 301 database backup security 311 deactivated nodes 74 default administrative privilege 160 default administrator 169 disable passwords 182 Disaster Recovery Manager 6, 15, 296, 301 disk storage pool 229 DMZ 248 DMZ best practices 262 enable passwords 182 encryption 16 encryption key management 88 encryption nclude/exclude statements 91 encryption performance overhead 105 event receivers 177 Event Server 177 expired password 63 exported data security 197 FILE event receiver 177 file ownership 39 filetext exit event receiver 178 force password reset 183 high availability 277 HSM encryption 112 initiating scheduling sessions 252 ISC security 202
LAN-free encryption 112 Library-Managed Encryption 123, 143, 307308, 311314, 317 lost client encryption key 334 manage administrative IDs 195 manage policies 196 managing client keys 90 minimum password length 182 mirror database and recovery log 277 missing storage pool volumes 320 multiple server instances 280 Network File System 56 NFS 56 node privilege 167 non-authorized user 40 non-client sessions 27 non-root 279 NT Event Log receiver 180 offsite data movement 15 offsite vaulting 15 onsite data movement 14 open client registration 182 Operational Reporting 198 operator privilege 166 overwriting tapes 314 password 60 password expiry 63, 182 password file 35, 63 password file permissions 63 password processing 61 password rules 67 policy management 196 policy privilage 161 polling scheduling 184 prevent client-initiated sessions 186 prevent schedule restore 69 primary storage pool 228 Producer thread 28 profile associations 197 profiles 194 prompted scheduling 184, 251 protect client encryption password 309 protect UNIX/Linux client files 45 protecting data in storage pools 244 proxy node 73 QUERY and SELECT commands 170 receive events 177 reclamation 245 remote access 70 rename node 75 reporting 199 restore to another client 70 restrict access 69 restricted policy privilege 162 restricted storage privilege 164, 172 run as regular Windows account 48 schedule authentication 25 schedule pre/post commands 68 scheduled client operations 185 scheduled command authority 69
350
scheduled commands 68 scheduler 51 scheduler password 258 scheduler service 256 scheduling modes 184 securing a network of servers 188 security audit 335 security objectives 3 server access control 181 server name 183 server password 183 server security considerations 266 server stanzas 62 server summary table 174 SERVER_CONSOLE ID 169 server-initiated communication 249, 252253 server-to-server communication 16, 188, 310 server-to-server sessions 28 session control 184 session encryption 82 session initiation 186, 252 session keys 88 session owner 41, 43 session traffic encryption 82 session types 27 set authentication 182 shared drives 52 SNMP event receiver 178 special administrative IDs 169 SQL interface 173 SQL SELECT statements 173 SSL ISC communication 210 start and stop scripts 287 stolen database backup tape 328 stolen server 330 Storage Agent 249 storage pool 228 storage pool format 228 storage pool protection 245 storage pool volume permissions 235 storage privilege 163 summary table 174 system privilege 160, 172 System-Managed Encryption 124, 150, 307 tape drive encryption 114 tape encryption 19, 235 tape storage pool volume 230 tasks 43 TCP/IP ports 249 test encryption 143 transaction 31 Trusted Communication Agent 64 unrestricted policy privilege 161 unrestricted storage privilege 163 UserExit 178 verify encryption 150 virtual nodename 70 virtual volume 191, 309 volume permissions 285 Web client agent 47
Web client authentication 25 write to a system file 170 Tivoli Storage Manager client 82, 231 topas 281 transaction client 31 transaction integrity 297 Trusted Communication Agent 64 TS1120 19 Application-Managed Encryption 121, 126 encryption options 119 encryption settings 149 Library-Managed Encryption 123 System-Managed Encryption 124 tape encryption 235 TS1120 Tape Drive 115 TS1120 tape drive encryption 114 TS3500 ALMS 125 Barcode Encryption Policy 142 configure Library-Managed Encryption 141 System-Managee Encryption 147 types of users 34
U
unauthorized tape access 333 UNC 53 UNIX client files 45 Network File System 56 operating system security 268 Tivoli Storage Manager services 51 unrestricted policy files 131 Unshielded Twisted Pair (UTP) 10 UserExit 178 users authorized 34, 39, 41, 52 non-authorized 36, 40 superuser 34 types 34 Windows 37
V
virtual nodename 70 virtual volume 191, 309310 VIRTUALNODE 39 VIRTUALNODENAME 70 VPN 12
W
warm site 296, 299, 301 Web client access 70 administrative authorities 26 administrative ID 65 agent 47 authentication 25 client access privilege 26, 39
Index
351
client owner privilege 26, 39 userid 26 WEP 273 Windows ACL 270 Active Directory 269 Backup Operators group 38 disk quota 49 Event Log 180 IIS 270 Local Service account 48 Local System account 48, 52, 54 MBSA 270 SCW 269 security 269 shared drives 52 System State 51 Tivoli Storage Manager services 47 Windows users 37 wireless access point 273 wireless network security 273 wirred network security 270 WPA 273 wrt_encryption 149
Z
z/OS Global Mirror 297
352

(0.5 spine) 0.475<->0.873 250 <-> 459 pages
Back cover
IBM Tivoli Storage Manager

Building a Secure Environment
Are you as safe as you think you are? Understanding security threats Si noitpyrcne thgir rof ouy?
Many people want to be famous, but nobody wants to hit the headlines in an incident resulting in the theft or misuse of their employees or clients confidential data. While the necessity of securing the confidentiality, integrity, and availability of the enterprises servers and data is well-known and understood, the backup server is often overlooked in the security planning. This is very regrettable, because the backup server infrastructure stores copies of all the enterprises most important data, often going back years. Valuable data is often copied to tape and transported off-site. These tape cartridges are highly portable and hence potentially vulnerable to loss or theft. Knowing all this, the backup server and its infrastructure could represent a highly attractive target of unauthorized access from either inside or outside your data center. How secure is your backup server and its disk arrays? Do you know where each and every one of your backup tapes is located - right now? This book will take you through the various security features of Tivoli Storage Manager, and show you how to use them, together with best practice principles, to design, implement, and administer a more secure backup management environment. We will cover passwords, administrative levels of control, the vital role of encryption, and procedures for managing off-site data, among other topics.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-7505-00 ISBN 0738489263

IBM Tivoli Storage Manager Building A Secure Environment Sg247505

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IBM Tivoli Storage Manager Building A Secure Environment Sg247505

Încărcat de

Drepturi de autor:

Formate disponibile

Front cover

IBM Tivoli Storage Manager Building a Secure Environment

Are you as safe as you think you are?

Understanding security threats

Si noitpyrcne thgir rof ouy?

Copyright IBM Corp. 2007. All rights reserved.

IBM Tivoli Storage Manager: Building a Secure Environment

293 295 295 298 298 300 vii

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 viii

Copyright IBM Corp. 2007. All rights reserved.

IBM Tivoli Storage Manager: Building a Secure Environment

Copyright IBM Corp. 2007. All rights reserved.

IBM Tivoli Storage Manager: Building a Secure Environment

The team that wrote this book

Become a published author

IBM Tivoli Storage Manager: Building a Secure Environment

Copyright IBM Corp. 2007. All rights reserved.

1.1 Overview of this book

Part 1 - Client side security

Part 2 - Tivoli Storage Manager and encryption

Part 3 - Server side security

Part 4 - Recovery scenarios and recommendations

IBM Tivoli Storage Manager: Building a Secure Environment

1.2 Why is security important

1.2.1 Why is Tivoli Storage Manager security important

1.2.2 Tivoli Storage Manager security objectives

1.3 How is Tivoli Storage Manager security implemented

Operating system security

Tivoli Storage Manager server configuration

Tivoli Storage Manager client configuration

IBM Tivoli Storage Manager: Building a Secure Environment

Data center security

1.4 Types of threats

1.4.1 Threats from within the organization

1.4.2 Threats from outside the organization

1.4.3 Threats to physical storage of data

1.4.4 Threats when data is transmitted

IBM Tivoli Storage Manager: Building a Secure Environment

1.5 Data transport methodologies with Tivoli Storage Manager

1.5.1 Review of the Open Systems Interface data model

Workstation ... ... ... ... ... ...

DB2, Oracle SAP

Tivoli Video Voice VoIP

Internet Protocol (IP)

PtP, DSn, OCn

Channel Extenders DWDM

Multi Mode Fiber - Lightc

Single Mode Fiber - Laser

Free Space Optics FSO

Video Coax Cable TV

Wireless Network Coax thick thin

LAN - Campus MAN - WAN

Figure 1-1 Open Systems Interface (OSI) Data Model

1.5.2 Interfacing networks together

IBM Tivoli Storage Manager: Building a Secure Environment

7- Application 6- Presentation 5- Session 4- Transport

Data Link Physical

1.5.3 A review of OSI Layer 1 - Physical Layer

Multi Mode Fiber - Lightc

Single Mode Fiber - Laser

Free Space Optics FSO

Video Coax Cable TV