ibm.com/redbooks

Front cover

IBM Tivoli Storage ManagerBuilding a Secure Environment

Charlotte BrooksLloyd Dieter

Dan EdwardsHelder GarciaCarsten HahnMatthew Lee

Are you as safe as you think you are?

Understanding security threats

Si noitpyrcne thgir rof ouy?

International Technical Support Organization

IBM Tivoli Storage Manager: Building a Secure Environment

June 2007

SG24-7505-00

© 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 ScheduleContract with IBM Corp.

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).

Note: Before using this information and the product it supports, read the information in “Notices” on page xiii.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvThe team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Overview of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Why is security important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Why is Tivoli Storage Manager security important . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Tivoli Storage Manager security objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 How is Tivoli Storage Manager security implemented . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Types of threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Threats from within the organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.2 Threats from outside the organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.3 Threats to physical storage of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.4 Threats when data is transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Data transport methodologies with Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . 71.5.1 Review of the Open Systems Interface data model . . . . . . . . . . . . . . . . . . . . . . . . 71.5.2 Interfacing networks together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5.3 A review of OSI Layer 1 - Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.4 A review of Fibre Channel technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.5 A review of VPN technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5.6 Networking summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6 Tivoli Storage Manager data movement and storage . . . . . . . . . . . . . . . . . . . . . . . . . . 131.6.1 On-site data movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.6.2 Off-site data movement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.6.3 Server-to-server data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.7 Introduction to encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.7.1 Symmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7.2 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.7.3 Certificates, keystores, and key managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.8 Tivoli Storage Manager client data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.8.1 DES56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.8.2 AES128. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.9 Tape encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Part 1. Tivoli Storage Manager client considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 2. Client sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1 Client authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1 Command line authentication flow (non-root user) . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 Command line and scheduler authentication flow (root user) . . . . . . . . . . . . . . . . 252.1.3 Web access authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Communication between the server and the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

© Copyright IBM Corp. 2007. All rights reserved. iii

2.2.1 Session types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Multi-session and transaction data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.1 Multi-session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2 Client thread types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.3 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 3. Client files and services management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1 Access controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.1 Types of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.2 Ownership and access permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.3 Mapping allowable tasks to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.4 Protecting the UNIX and Linux client files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 The client services and daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.1 Running services on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.2 Running services on UNIX or Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.3 Shared drives and file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.1 Windows shared drives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.2 UNIX and Linux Network File System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 4. Securing the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1 Client authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1.1 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.2 Password processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.1.3 Registering nodes without an administrator ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.1.4 Password rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2 Command action schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3 Pre and post commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4 Authority of scheduled commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.5 Scheduled restores and retrieves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.6 Access restriction by user or group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.7 Remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.8 Cross client restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.8.1 Restoring your data to another workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.8.2 Restoring data from another workstation locally . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.9 Proxy nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.10 Manipulating node objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.10.1 Deactivated nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.10.2 Renaming nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.11 Controlling client options from the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.12 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.12.1 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.12.2 Operating system and network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.12.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Part 2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Chapter 5. Tivoli Storage Manager client data encryption . . . . . . . . . . . . . . . . . . . . . . 815.1 Client encryption primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1.1 Encryption of session traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.1.2 Encryption of data traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2 Platforms that can use client data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.1 Advantages of client side data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.2 Considerations for client side data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.2.3 Using data encryption with client compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

iv IBM Tivoli Storage Manager: Building a Secure Environment

5.3 Backup/archive client encryption key management . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3.1 Session keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3.2 Data encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.4 Data encryption using the backup/archive client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.1 Enabling encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.2 Include and exclude statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.4.3 PASSWORDACCESS and ENCRYPTKEY interaction . . . . . . . . . . . . . . . . . . . . 915.4.4 Backup/archive client session examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.4.5 Verifying that backed up data is encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.5 Data encryption using the API client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.5.1 API application-managed encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.5.2 API transparent encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.5.3 Verifying that API data is encrypted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.6 Performance observations of the backup/archive client . . . . . . . . . . . . . . . . . . . . . . . 1055.7 Upgrading the level of the Tivoli Storage Manager client . . . . . . . . . . . . . . . . . . . . . . 1125.8 Changing the client host name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.9 Encryption and hierarchical storage management clients. . . . . . . . . . . . . . . . . . . . . . 1125.10 Encryption and LAN-free. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Chapter 6. TS1120 Tape encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.1 Introduction to TS1120 encryption options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146.2 IBM System Storage TS1120 Tape Drive overview . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.1 TS1120 tape drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.2.2 Encryption Key Manager (EKM) software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.2.3 Encryption policy configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2.4 Tivoli Storage Manager with AME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.2.5 Tivoli Storage Manager with LME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2.6 Tivoli Storage Manager with SME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.3 Encryption on a TS3500 Tape Library with ALMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.4 Configuration with different encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.4.1 AME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.4.2 Configuring EKM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.4.3 Device configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.4.4 LME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416.4.5 SME configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.5 EKM server backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.5.1 EKM server disaster recovery considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.6 Recommended best practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Part 3. Tivoli Storage Manager server considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Chapter 7. Server administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.1 Security concerns for the Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . 1607.2 Overview of Tivoli Storage Manager administrator roles. . . . . . . . . . . . . . . . . . . . . . . 160

7.2.1 No authority granted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607.2.2 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607.2.3 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.2.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637.2.5 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667.2.6 Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677.2.7 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677.2.8 Administrator IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687.2.9 Special administrator IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Contents v

7.2.10 Server options related to administrative privilege . . . . . . . . . . . . . . . . . . . . . . . 1707.3 A typical implementation of administrator roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727.4 Maintaining an audit trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7.4.1 Activity log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737.4.2 Server summary table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747.4.3 Accounting records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767.4.4 Event receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

7.5 Controlling access to the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817.5.1 Commands and options affecting the entire server. . . . . . . . . . . . . . . . . . . . . . . 1817.5.2 Commands and options that affect client nodes . . . . . . . . . . . . . . . . . . . . . . . . . 1837.5.3 Session control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

7.6 Using the server to manage operations on a client node . . . . . . . . . . . . . . . . . . . . . . 1857.6.1 General considerations for scheduled client operations . . . . . . . . . . . . . . . . . . . 1857.6.2 Session initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7.7 Securing a network of Tivoli Storage Manager servers. . . . . . . . . . . . . . . . . . . . . . . . 1887.8 Encryption for server-to-server communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

7.8.1 Server-to-server session setup encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897.9 Command routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.10 Virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.11 Using a configuration manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

7.11.1 Security aspects of profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947.11.2 Administrator ID management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957.11.3 Policy management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1967.11.4 Other profile associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

7.12 Security considerations for exports and backup sets . . . . . . . . . . . . . . . . . . . . . . . . 1977.13 Administrator roles and Operational Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

7.13.1 Operational Reporting overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1997.13.2 Operational Reporting connections to the Tivoli Storage Manager server . . . . 199

7.14 Integrated Solutions Console security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2027.14.1 Adding administrators to the ISC/Administration Center. . . . . . . . . . . . . . . . . . 2027.14.2 Connecting ISC and Tivoli Storage Manager administrator IDs . . . . . . . . . . . . 205

7.15 ISC/AC communication security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2077.15.1 Web browser link to ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2077.15.2 ISC/AC to Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

7.16 Setting up SSL for the ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.16.1 Overview of the required steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.16.2 Create key and trust files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.16.3 Create the JACL script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2217.16.4 Modify wsadmin.properties to reflect the correct SOAP port . . . . . . . . . . . . . . 2227.16.5 Run wsadmin on the JACL script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2237.16.6 Modify the ConfigService.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2237.16.7 Modify the web.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2237.16.8 Stop the ISC portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2247.16.9 Modify the soap.client.props file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2247.16.10 Start the ISC/AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Chapter 8. Storage pool considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2278.1 Storage pool overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

8.1.1 Primary storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.1.2 Copy storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.1.3 Active-data storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

8.2 How is data written to storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.2.1 Disk storage pool volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

vi IBM Tivoli Storage Manager: Building a Secure Environment

8.2.2 Tape storage pool volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2308.3 Encrypted data in storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

8.3.1 Tivoli Storage Manager client encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2368.3.2 Tivoli Storage Manager tape encryption usage. . . . . . . . . . . . . . . . . . . . . . . . . . 237

8.4 Data shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2378.4.1 Why use data shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2388.4.2 Setting up shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2398.4.3 Storage pool shredding considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

8.5 How to protect your data in storage pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Chapter 9. Deployment in a network secured environment . . . . . . . . . . . . . . . . . . . . 2479.1 What is a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2489.2 Tivoli Storage Manager clients in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

9.2.1 TCP/IP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2499.2.2 Example configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2519.2.3 Initiating scheduled sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2529.2.4 Server-initiated sessions: Configuration example . . . . . . . . . . . . . . . . . . . . . . . . 254

9.3 Sample configurations and best practice recommendations. . . . . . . . . . . . . . . . . . . . 2629.3.1 Tivoli Storage Manager server in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629.3.2 Tivoli Storage Manager server not in a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629.3.3 Tivoli Storage Manager server in a dedicated network in the DMZ . . . . . . . . . . 2639.3.4 Backing up clients of different security levels on the same server . . . . . . . . . . . 263

Chapter 10. Protecting the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26510.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26610.2 Security policy considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26610.3 Operating system security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

10.3.1 UNIX and Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26810.3.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

10.4 Network security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27010.4.1 Wired network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27010.4.2 Wireless network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10.5 Security assessment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27410.6 Human aspects of security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

10.6.1 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27610.7 Environmental considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27710.8 High availability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27710.9 Change management considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27810.10 Security audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27810.11 Tivoli Storage Manager server running as a non-root user . . . . . . . . . . . . . . . . . . . 279

10.11.1 Why run as a non-root user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28010.11.2 Set up the non-root user environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28210.11.3 Scripts to start and stop the Tivoli Storage Manager service . . . . . . . . . . . . . 28710.11.4 Location of Tivoli Storage Manager files for disaster recovery . . . . . . . . . . . . 290

10.12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Part 4. Recovery scenarios and summarized guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Chapter 11. Providing a secure disaster recovery environment. . . . . . . . . . . . . . . . . 29311.1 Disaster recovery planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

11.1.1 Seven tiers of disaster recovery solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29511.2 Off-site data vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

11.2.1 Choosing a balance between cost and security . . . . . . . . . . . . . . . . . . . . . . . . 29811.2.2 Hot site and security (BC Tier 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Contents vii

11.2.3 Warm site and security (BC Tier 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30111.2.4 Cold site and security (BC Tier 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30211.2.5 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

11.3 Data encryption and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30311.3.1 No data encryption used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30411.3.2 Tivoli Storage Manager-provided encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 30411.3.3 System-managed encryption and library-managed encryption. . . . . . . . . . . . . 30711.3.4 Off-site encryption key and password handling . . . . . . . . . . . . . . . . . . . . . . . . 308

11.4 Tape and data security using SAN access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30911.5 Virtual volumes and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

11.5.1 A review of virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31011.6 Database backup security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31111.7 Copy storage pool security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31111.8 Backup set security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31211.9 Active-data pool security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31311.10 Tivoli Continuous Data Protection security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31411.11 Special tape topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

11.11.1 If a tape is scratched or overwritten, can you still access older data . . . . . . . 31411.11.2 Erasing or destroying media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

11.12 Best practices for off-site data vaulting and security . . . . . . . . . . . . . . . . . . . . . . . . 316

Chapter 12. Recovery and prevention of security breaches or data loss . . . . . . . . . 31912.1 Legal and compliance issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32012.2 Missing storage pool volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

12.2.1 Missing copy storage tape volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32012.2.2 Missing primary storage pool tape volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32312.2.3 Missing active-data storage pool tapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32512.2.4 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

12.3 A missing or stolen database backup tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32812.4 Stolen Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33012.5 Missing client backup set tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33212.6 Unauthorized tape drive and library and data access . . . . . . . . . . . . . . . . . . . . . . . . 33312.7 Encryption-related recovery topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

12.7.1 A lost, forgotten, or destroyed client encryption key . . . . . . . . . . . . . . . . . . . . . 334

Chapter 13. Guidelines for audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33513.1 Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33613.2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33613.3 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33613.4 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33713.5 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33713.6 Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33813.7 People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33813.8 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33813.9 Categorize your data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

viii IBM Tivoli Storage Manager: Building a Secure Environment

Figures

1-1 Open Systems Interface (OSI) Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81-2 Interfacing between networks using repeaters, hubs, bridges, switches, and routers . . 91-3 OSI Layer 1 - Physical connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101-4 Fiber optic cables: single-mode and multi-mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111-5 VPN with IPSec over an Internet connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131-6 Tivoli Storage Manager on-site data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141-7 DRM off-site rotation to an external vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151-8 Symmetric key encryption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171-9 Asymmetric key encryption process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182-1 Non-root dsmc authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242-2 Tivoli Storage Manager dsmc authentication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252-3 Tivoli Storage Manager Java Applet-dsmagent authentication flow . . . . . . . . . . . . . . . 262-4 Producer-Consumer model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292-5 Producer - Consumer transaction handling and multithreaded backup . . . . . . . . . . . . 302-6 Transaction processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313-1 Manage auditing and security log Security Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 383-2 Ownership of backed up objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403-3 Ownership of archived objects for non-authorized users . . . . . . . . . . . . . . . . . . . . . . . 413-4 Ownership of archived objects for authorized users . . . . . . . . . . . . . . . . . . . . . . . . . . . 413-5 Authorization check to access objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423-6 Tivoli Storage Manager basic services on Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . 483-7 Check disk quota restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503-8 Changing the logon properties of a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513-9 System State backup on Windows Server 2003. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553-10 Registry backup on Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554-1 Log-in process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604-2 Password encrypted on Windows Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614-3 Using node name authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664-4 Using Web Client and Administrator validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664-5 Restoring data to another workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714-6 Restoring files from other workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724-7 Proxy node configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744-8 Preventing include option from client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775-1 GUI encryption key password dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935-2 Registry entry for encryption key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945-3 Prompt during backup if saved encryption key is not present. . . . . . . . . . . . . . . . . . . . 945-4 Prompt during restore if saved encryption key is unavailable . . . . . . . . . . . . . . . . . . . . 955-5 Error when invalid key is presented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955-6 Prompt during backup if saved encryption key is not present. . . . . . . . . . . . . . . . . . . . 965-7 Prompt during restore-saved if encryption key is unavailable. . . . . . . . . . . . . . . . . . . . 975-8 Error when invalid key is presented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975-9 Unencrypted data sent from API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045-10 Portion of an encrypted data packet sent through the API using dapismp . . . . . . . . 1055-11 CPU utilization for test one . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075-12 CPU utilization for test two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085-13 CPU utilization for test three with AES128 encryption . . . . . . . . . . . . . . . . . . . . . . . 1105-14 CPU utilization for test four with AES128 encryption . . . . . . . . . . . . . . . . . . . . . . . . 1116-1 TS1120 encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

© Copyright IBM Corp. 2007. All rights reserved. ix

6-2 Logical diagram of the TS1120 tape drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166-3 EKM uses both symmetric and asymmetric encryption keys . . . . . . . . . . . . . . . . . . . 1176-4 Encryption data flow for the AME process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226-5 Decryption data flow for the AME process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226-6 Library-managed tape encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246-7 Key and policy flow in a SME environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256-8 Output from Library Specialist indicating tape J12457 is encrypted . . . . . . . . . . . . . . 1296-9 Adding EKM server TCP/IP addresses to Tape specialist . . . . . . . . . . . . . . . . . . . . . 1406-10 Ping connectivity test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406-11 Output indicating successful ping of the EKM server from the tape library. . . . . . . . 1416-12 Example of logical libraries within the Tape Specialist . . . . . . . . . . . . . . . . . . . . . . . 1416-13 Example of how to enable the logical library for LME . . . . . . . . . . . . . . . . . . . . . . . . 1426-14 Library 20-33 has been enabled with the LME method . . . . . . . . . . . . . . . . . . . . . . 1426-15 Barcode encryption policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436-16 Tape SJ0011 is not encrypted before it is used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446-17 Output from the Tape Specialist after the archiving test . . . . . . . . . . . . . . . . . . . . . . 1456-18 Tape Specialist configuring the logical library with SME. . . . . . . . . . . . . . . . . . . . . . 1486-19 Two EKM servers with a shared configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527-1 Web client error from missing node authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687-2 Web client error with locked administrator ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687-3 Server ACTLOG table columns and descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737-4 Server summary table fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757-5 Format of data that is written using filetextexit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797-6 Administrative command logged to application event log . . . . . . . . . . . . . . . . . . . . . . 1817-7 Web client error when SERVERONLY initiation is specified. . . . . . . . . . . . . . . . . . . . 1877-8 Setup for server-to-server tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897-9 Data packet when using server-to-server virtual volumes . . . . . . . . . . . . . . . . . . . . . 1937-10 Tivoli Storage Manager server network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947-11 Automatic entry for local Tivoli Storage Manager server on Windows . . . . . . . . . . . 2007-12 Setting the administrator ID in Operational Reporting . . . . . . . . . . . . . . . . . . . . . . . 2007-13 Wizards in the Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2017-14 ISC/AC user and group management panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2027-15 Add user dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037-16 Newly added ISC/AC administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037-17 Users and group management menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047-18 All portal user groups menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047-19 Iscadmins group menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2057-20 Add server connection menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2067-21 Dialog for creating server connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2077-22 Successful server connection definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2077-23 ikeyman utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117-24 Server key file name and location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117-25 Password prompt for server key file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2127-26 Create a new self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2127-27 Self-signed certificate menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137-28 Successful creation of personal self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . 2137-29 Extract Certificate button. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2147-30 Enter the file name and location for the extracted server certificate . . . . . . . . . . . . . 2147-31 Setting the name for the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2147-32 Password prompt for the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2157-33 Add a new certificate to the server trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2157-34 Specifying the server certificate to import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2167-35 Successful import of server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

x IBM Tivoli Storage Manager: Building a Secure Environment

7-36 Creating another key file for the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2177-37 Enter file name and directory path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2177-38 Password prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2187-39 Create a new self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2187-40 Values for the client self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2197-41 Successful creation of client key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2197-42 File name for exported client key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2207-43 File name for client trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2207-44 Password for client key trust file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2207-45 Selecting the client key to import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2217-46 Enter the label for the certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2217-47 URL for successful SSL connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2257-48 SSL-enabled session indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2258-1 Word.doc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2348-2 How data shredding works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2389-1 A sample DMZ configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2489-2 Overview of TCP/IP parameters in dsm.opt and dsmserv.opt . . . . . . . . . . . . . . . . . . 2509-3 Prevent administrative access through a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2529-4 Dedicated network for backup in DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26310-1 Packet filtering firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27110-2 Circuit level gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27110-3 Application firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27210-4 Stateful Inspection firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27211-1 Seven tiers of disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29511-2 Production and hot site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30111-3 Production and Warm site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30211-4 Server-to-server virtual volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Figures xi

xii IBM Tivoli Storage Manager: Building a Secure Environment

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.

© Copyright IBM Corp. 2007. All rights reserved. xiii

TrademarksThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 enterprise’s 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 enterprise’s 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 bookThis 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

© Copyright IBM Corp. 2007. All rights reserved. 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 Brasília. 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 IBM Tivoli Storage Manager: Building a Secure Environment

Thanks to the following people for their contributions to this project:

Babette Haeusser, Emma Jacobs, and Deanna PolmInternational 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 StakutisIBM Tivoli Storage Manager Development, Marketing, and Test

Ric Bradshaw, Gregory Gendron, Jon Peake, and Rob WilsonIBM Tape Development and Marketing

Anthony Abete and Jeff ZiehmIBM Advanced Technical Support

Tom Benjamin, Timothy Hahn, John Morganti, and John PeckIBM EKM Development

Carl GuslerIBM Austin

Rosane Goldstein Golubcic Langnor and Eduardo TomazIBM Brazil

Deon George IBM Australia

Ian SanerCristie

Jim Carrick, Andrew Gorelick, Ann Kurtz, and David SwitsStrategic Computer Solutions, NY

Othmar WeberBayer Business Services, Germany

Tom and Jenny Chang, and the staff of The Garden Inn, Los Gatos, CA

Become a published authorJoin 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 welcomeYour 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 OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

xviii IBM Tivoli Storage Manager: Building a Secure Environment

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

© Copyright IBM Corp. 2007. All rights reserved. 1

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 securityThis 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 encryptionIn 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 securityThis 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 recommendationsIn 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 environment’s security and which can assist you to prepare for an audit.

2 IBM Tivoli Storage Manager: Building a Secure Environment

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 organization’s 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.

IntegrityData 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 3

ConfidentialityData 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.

AvailabilityData 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 securityTivoli 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 securityThe 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 configurationThe 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 configurationThe 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.

4 IBM Tivoli Storage Manager: Building a Secure Environment

Data center securityYour 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 securityIn 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 organization’s Business Continuity strategy.

Chapter 1. Introduction 5

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 mediaRemovable 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 site’s 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.

DiskBecause 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 Manager’s 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.

6 IBM Tivoli Storage Manager: Building a Secure Environment

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 application’s 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

Chapter 1. Introduction 7

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

PVCs, SVC

s

Network

Channel

ExtendersD

WD

MSO

NET

PtP, DSn, O

Cn

Frame R

elay

IBM

SN

AIB

M

Net

BU

IIB

M

APP

NM

icro

Soft

Net

Bio

sN

ovel

lIP

XA

pple

loca

l tal

kD

ECD

ecN

et

othe

rs

Ban

yon

Vine

s

7- Application

6- Presentation

5- Session

4- Transport

3- Network

2-Data Link

1- Physical

LAN - Campus

MAN - WAN

AH DATA

SH

TH

NH

7- Application

6- Presentation

5- Session

4- Transport

3- Network

2-Data Link

1- Physical

Workstation Workstation

NH

TH

SH

AHData

Ethernet shared & switched;10-Base2, 10-Base5, 10-BaseT,10-BaseF, 100-BaseT, 100-BaseF,1000-BaseT, 1000-BaseF . . . . . . .

TR shared & switched; 4 & 16 Mbps

MAC

LLC

MAC

LLC

……...

……...

……...

……...

……...……...

WW

WH

TML

E-MAIL

SAP

DB2, O

racleVoice PSTNVoice VoIP

Video

Tivoliother...

MS Exchange

LANE-C

IP

Sate

llite

s

Mic

row

ave

Free

Spa

ceO

ptic

s FS

O

UTP

3, 4

, 5, 6

Sing

le M

ode

Fibe

r - L

aser

Mul

ti M

ode

Fibe

r - L

ight

c

Vide

o C

oax

Cab

le T

V

Coa

xth

ick

thin

Wire

less

Net

wor

k

ATMInternet Protocol (IP)

LH

LT

PH

PH

LH

LT

8 IBM Tivoli Storage Manager: Building a Secure Environment

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.

7- Application

6- Presentation

5- Session

4- Transport

3- Network

2-Data Link

1- Physical

Network

Data Link

Physical

7- Application

6- Presentation

5- Session

4- Transport

3- Network

2-Data Link

1- Physical

Network B

Peer-to-Peer Communication

Network A

Network

Data Link

Physical

Rou

ters

Ethernet 10 Base T (shared) Ethernet 10 Base F (shared)Ethernet 10 Base T (Shared/Switched) Ethernet 100 Base F (Shared/Switched)

Token-Ring 4 Mbps (Shared/Switched) Token-Ring 16 Mbps (Shared/Switched)

Token-Ring 4/16 Mbps (Shared/Switched) Ethernet 100 Base T (Shared/Switched)

LAN

- C

ampu

s

IP Subnet xx.xx.xx.xx IP Subnet yy.yy.yy.yy

Repeater

Bridge

Bridge

BridgeRouter

Internet Protocol (IP) Novell IPX RouterMicrosoft NetBios Digital Equipment DecNet RouterATM (LANE & CIP) ATM WAN (PVCs) SwitchFrame Relay ATM WAN (PVCs) SwitchPtP, DSn - OCn SONET SwitchSONET DWDM Switch

MA

N -

WA

N

ATM (LAN, MAN and WAN) DWDM Switch

Switc

hes

Hub

s / B

ridge

s

Rep

eate

rs

Chapter 1. Introduction 9

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.

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 today’s 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.

Network

1- Physical

LAN - Campus

MAN - WAN

1- Physical

MAC MAC

Sate

llite

s

Mic

row

ave

Free

Spa

ceO

ptic

s FS

O

UTP

3, 4

, 5, 6

Sing

le M

ode

Fibe

r - L

aser

Mul

ti M

ode

Fibe

r - L

ight

c

Vide

o C

oax

Cab

le T

V

Coa

xth

ick

thin

Wire

less

Net

wor

k

10 IBM Tivoli Storage Manager: Building a Secure Environment

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

Figure 1-4 Fiber optic cables: single-mode and multi-mode

Multi-mode fiberCharacteristics 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.

DATA Cladding 125 micron dia.

Core 50 or 62.5 micron dia

Outer coating 250 micron dia.

LED = Light Emitting Dioder

Multimode (MM) Fiber"Multiple paths" for light to travel

DATA

Outer coating 250 micron dia.

Cladding 125 micron dia.

Core

9 micron diameter

LX Laser =Long Wavelength Laser

Single Mode (SM) Fiber"Single path" for Laser to travel

Chapter 1. Introduction 11

Single-mode fiberCharacteristics 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.

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.

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).

12 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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 company’s 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

CorporateIntranet

Disaster Recovery

Site

Internet

ISP ISP

Firewall

Router

Firewall

Router

TSM Server

Production TSM Server

Encryption

Authentication

VPN

Chapter 1. Introduction 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 IBM Tivoli Storage Manager: Building a Secure Environment

– 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.

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.

Vault Retrieve State

Vault Staff

Vault State

Courier State

MountableState

Courier RetrieveState

CourierOperator

TSMServer

Vault Facility

Chapter 1. Introduction 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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.

Symmetric Encryption E.g. Data Key

Chapter 1. Introduction 17

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.

Asymmetric Encryption Eg., Key Encrypting Key

18 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 1. Introduction 19

20 IBM Tivoli Storage Manager: Building a Secure Environment

Part 1 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

Part 1

© Copyright IBM Corp. 2007. All rights reserved. 21

22 IBM Tivoli Storage Manager: Building a Secure Environment

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.

2

© Copyright IBM Corp. 2007. All rights reserved. 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 client’s 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 server’s 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.

Figure 2-1 Non-root dsmc authentication flow

TSM Server

dsmc sends the encrypted buffer to the TSM server

Encrypted buffer sent to the client

1

Authentication Flowdsmc and dsmtca

Non-root

4

Non-root user invokes dsmc and enters the user ID and password

3TSM 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.

5dsmtca 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

6

TSM B/A Client

Server's final validation, sends AUTH SUCCESS, or AUTH FAILED in an encrypted buffer

8

dsmc session begins once the AUTH SUCCESS is received

2dsmtca 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.

7

9

24 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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 flowUse 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.

TSM Server

dsmc sends encrypted data to the TSM server

4

Encrypted data is sent to the client

1

Authentication Flowdsmc

root and Administrator

5

3

dsmc generates authentication data and encrypts the data using a known client/server shared algorithm

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.

6dsmc decrypts the data and validates the content, repacks the data, then it is encrypted with the shared algorithm

7 dsmc encrypted data sent to server

8

TSM B/A Client

Server's final validation, sends AUTH FAILED, or Auth failed

9 dsmc session begins once the AUTH SUCCESS is received

2

root user invokes dsmc and enters the ID and password

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.

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

TSM Server

dsmagent sends the encrypted data to the TSM server

3

Encrypted buffer sent to the client

1

Authentication FlowJava Applet (dsm.jar) and

dsmagentPasswordaccess=generate

4

User invokes the dsm.jar either by the Web GUI or dsmj, then logs in with the admin ID and password

2

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.

5

dsm.jar decrypts the buffer and validates the content, repacks the buffer with a response, and encrypts with the shared algorithm

6

dsmagent sends the encrypted buffer to the TSM server

7

TSM B/A Client

Server's final validation, sends AUTH SUCCESS, or AUTH FAILED

8

Session begins once the AUTH SUCCESS received, with dsmagent continuing to proxy for dsm.jar (Web GUI session).

9

dsmagent establishes a client session using the node ID and password (passwordaccess generate). As per the authentication flow for root users.

10

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.

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.

11

12

26 IBM Tivoli Storage Manager: Building a Secure Environment

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 Comm. Sess Wait Bytes Bytes Sess Platform Client NameNumber Method State Time Sent Recvd Type------ ------ ------ ------ ------- ------- ----- -------- --------------------63,795 Tcp/Ip Run 0 S 10.4 M 142 Admin WinNT ADMIN_163,798 Tcp/Ip Run 0 S 2.9 K 198 Admin WinNT ADMIN_264,659 Tcp/Ip Run 0 S 261 438 Serv- AIX-RS/- SERVER_1 er 600067,227 Memory SendW 1.3 H 478.1 K 214 Admin Server ADMIN_1 IPC67,228 Tcp/Ip IdleW 10.8 M 227.4 M 4.9 K Node WinNT SERVER_267,233 Tcp/Ip RecvW 0 S 3.4 K 9.2 G Node TDP MSS- SERVER_3 QL Win- 3267,234 Tcp/Ip IdleW 3 S 329.2 M 3.0 K Node SUN SOL- SERVER_4 ARIS67,238 Tcp/Ip RecvW 6.2 M 1.3 K 1.6 G Node TDPO SERVER_5 Linux8667,244 Tcp/Ip RecvW 0 S 130.3 K 9.7 G Node TDP Dom- SERVER_6 ino

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 sessionsThese 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 sessionsYou 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:

Chapter 2. 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-sessionTivoli 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 2. Client sessions 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.

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.

fsAfsB.........

FilespaceQueue

txnproducer

txnproducer

txn 1txn 2txn 3................

txn consumer

txn consumer

txn consumer

TransactionQueue

TSMserver

Sessions to server

Main threadParses cmd

User interface

PerformanceMonitor

30 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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.

File00AFile00BFile00CFile00DFile00EFile00FFile00GFIle00H

IBM Tivoli Storage Manager Client "HARRY"

A

BC

D

E

F

GH

ABCDEFGH

File001File002File003File004File005...

Consumer 1Transaction 001

Consumer 2Transaction 002

Transaction 001

02

Chapter 2. Client sessions 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

3

© Copyright IBM Corp. 2007. All rights reserved. 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 administrator’s 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 usersWe 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.

SuperuserThe 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 user’s 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 userA 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 file’s group is set to the primary group of that user. On Windows

34 IBM Tivoli Storage Manager: Building a Secure Environment

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 userAfter 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.optexport 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 user’s 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 guest dsmchown guest dsmcchmod 4755 dsmchmod 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

SummaryTherefore 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 userA 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 user’s 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 dsmtcachmod 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 specificsOn 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”

Chapter 3. Client files and services management 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 administratorsThis 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 privilegeA 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 privilegeA 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 section’s 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.

Chapter 3. Client files and services management 39

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.

TSM Server

permissions owner group filename-rwxr--r-- user1 users file1-rwxr--r-- user2 users file2

user1Backup file1 and file2

object ownerfile1 user1file2 user2

40 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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 retrieveA 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.

TSM Server

permissions owner group filename-rwxr--r-- user1 users file1-rwxr--r-- user2 users file2

Archive file1 and file2

object ownerfile1 user1file2 user1

user1

Non-authorized user

TSM Server

permissions owner group filename-rwxr--r-- user1 users file1-rwxr--r-- user2 users file2

user1Archive file1 and file2

object ownerfile1 rootfile2 root

Authorized user

Chapter 3. Client files and services management 41

Table 3-1 User access to objects in UNIX and Linux

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.

Figure 3-5 Authorization check to access objects

Session owner Object owner User access

NULL (root or authorized user) Any name or empty Yes

Specific name (non-authorized user) Empty No

Specific name (non-authorized user) Same name Yes

Specific name (non-authorized user) Different name No

TSM ServerCan I access this object?TSM B/A Client

4

Send answer to the client.

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.

My session owner is USER.1

Backup/Archive Client initiates the session. Session owner is determined.

3

Backup/Archive client mounts the request of objects.

Query my backup objects for this node.

2

Client authenticated.

Authentication process happens here.

Backup/Archive client initiates the restore/retrieve or aborts operation depending on the answer from the server.

5

TSM DB

Object Ownerfile1 user1file2 rootfile3 user2file4 user1

42 IBM Tivoli Storage Manager: Building a Secure Environment

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

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.

User name User type Session owner Objects that the user can see

root Superuser NULL All

user1 Authorized user NULL All

user2 Non-authorized user user2 file3

Chapter 3. Client files and services management 43

Table 3-3 User authorization table

Task Root user Authorized user Non-authorized user

Install the backup/archive client

Yes No No

Registering new nodes with Tivoli Storage Manager server

Yes Yes No, even when the registration is set to open on the server.

Create or change the Tivoli Storage Manager password file for client workstations

Yes Yes, if the user has write permission to the file.

No

Create and modify dsm.sys

Yes Yes, if the user has write permission or owns the file.

No

Create and modify the client user options file (dsm.opt)

Yes Yes, if the user has write permission or owns the file.

Yes, if the user is using a personalized file, using the DSM_CONFIG variable.

Create and modify an include-exclude list

Yes Yes, if the user has write permission or owns the file.

No

Backup Yes Yes, if the user has read permission, regardless of ownership.

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. 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 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.

Yes, if the user has read permission, regardless of ownership.

44 IBM Tivoli Storage Manager: Building a Secure Environment

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 onlyThe 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.

Retrieve Yes. When retrieving to a new location or to the same location, file permissions and ownership are preserved.

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 archived the file. Ownership of all retrieved objects will be changed to the non-authorized user.

Client Scheduler Yes Yes No

Grant user access to files on the Tivoli Storage Manager server

Yes Yes Yes, for files that the user owns on the Tivoli Storage Manager server.

Delete Tivoli Storage Manager server file spaces

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.

No.

Task Root user Authorized user Non-authorized user

Chapter 3. Client files and services management 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 objectTo 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.shroot@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.shroot@myhost:/usr/tivoli/tsm # chmod 500 recover_perm.sh

4. Execute the scripts:

root@myhost:/usr/tivoli/tsm # ./recover_owner.shroot@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

Chapter 3. Client files and services management 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 user’s 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 servicesAn 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 IBM Tivoli Storage Manager: Building a Secure Environment

An MSDN® article contains a script to change the password on a service’s 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.

Chapter 3. Client files and services management 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 IBM Tivoli Storage Manager: Building a Secure Environment

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

Chapter 3. Client files and services management 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 User’s 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 network’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 user’s 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 Administrator’s Guide for your platform to see how to implement NDMP backups.

Chapter 3. Client files and services management 53

Using the Local System to back up network mapped drivesYou 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 passwordpath_to_dmsc\dsmc inc x:\filenet 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 user’s 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 session’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

Windows share definitionsBecause mapped drive definitions are not part of the file or folder attributes of Windows shares, they are not restored together with the share’s 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

Chapter 3. Client files and services management 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' failedANS4007E Error processing '/mnt/nfs/.sh_history': access to the object is deniedNormal File--> 175 /mnt/nfs/TSM.PWD ** Unsuccessful **ANS1228E Sending of object '/mnt/nfs/TSM.PWD' failedANS4007E Error processing '/mnt/nfs/TSM.PWD': access to the object is deniedNormal 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: 4Total number of objects backed up: 2Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 2Total number of bytes transferred: 2.80 KBData transfer time: 0.00 secNetwork data transfer rate: 133,742.55 KB/secAggregate data transfer rate: 0.05 KB/sec

56 IBM Tivoli Storage Manager: Building a Secure Environment

Objects compressed by: 0%Elapsed processing time: 00:00:52tsm>

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 User’s 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 Administrator’s Guide for your platform to see how to implement NDMP backups.

Chapter 3. Client files and services management 57

58 IBM Tivoli Storage Manager: Building a Secure Environment

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.

4

© Copyright IBM Corp. 2007. All rights reserved. 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 client’s 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.

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.

Figure 4-1 Log-in process

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.

No

Client prompts forUser and Password

User = NodenameAND

Pass = Node's pass

Accept connection

User = Registered AdminAND

Pass = Admin's pass

YesYes

Reject connection

No

60 IBM Tivoli Storage Manager: Building a Secure Environment

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 PROMPTWhen 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 GENERATEWhen 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 alice TCPServeraddress atlantic TCPClientaddress client passwordaccess generate passworddir /home/guest

errorlogname /home/guest/log/aliceerror1.log schedlogname /home/guest/log/alicesched1.log

Servername stanza2 nodename alice TCPServeraddress kanaga TCPClientaddress client passwordaccess generate passworddir /home/guest errorlogname /home/guest/log/aliceerror2.log schedlogname /home/guest/log/alicesched2.log

Servername stanza3 nodename bob TCPServeraddress atlantic TCPClientaddress client passwordaccess generate passworddir /home/guest errorlogname /home/guest/log/boberror1.log schedlogname /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=stanza1dsmc -se=stanza2dsmc -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 IBM Tivoli Storage Manager: Building a Secure Environment

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-charactersSTANZA1ALICEnon-printable-charactersSTANZA2ALICEnon-printable-charactersSTANZA3BOBnon-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

Permissions on the password fileBecause 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 client’s 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 passwordThe 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 because the process is running in the background.

However even when using PASSWORDACCESS GENERATE, incorrect setups can lead to problems with the password synchronization between the server and the client.

Where the password is stored What makes up the affinity

Windows Registry Node name + Tivoli Storage Manager server name

Password File - TSM.PWD Stanza name + node name

Chapter 4. Securing 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 AgentOn 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 AgentThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 /home/guest/dsmerror.logschedlogname /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.

Chapter 4. Securing the client 65

.

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.

.

Figure 4-4 Using Web Client and Administrator validation

TSM Server

Local Client Access

Node Authentication(WS135)

Admins: Alice BobNode Authentication

(WS204)

Bob

WS204

Alice

WS135

Nodes: WS135 WS204passwordaccess generate

WS135

Web Client Access

Credentials Validation

(Alice)

Node Authentication

(WS135)

12

3

Alice

WS342

Nodes: WS135 WS204Admins:AliceBob

TSM Server

66 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 4. Securing the client 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 yessrvprepostsnapdisabled 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 user2groups group1 group2

Chapter 4. Securing the client 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 User’s 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 node’s 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 NODEB’s file system.

70 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Figure 4-5 Restoring data to another workstation

Because Alice specified VIRTUALNODENAME NODEA, she is prompted for NODEA’s 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 node’s 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.

Restore nodea's data

Provides nodea'spassword

-virtualnode=nodea

Alice

NODEBTSM

Server

Chapter 4. Securing the client 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 node’s information at your own node, but you need to have permission to access the source node data. This permission is established by the source node’s 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.

Figure 4-6 Restoring files from other workstation

As in the previous example, Alice does not have NODEB’s node password. But in this case, the user responsible for NODEB has explicitly granted access to NODEA for NODEA’s backed up objects.

Consult the client installation guide for your platform for more details about using this option.

-fromnode =nodeb

Restore nodeb's data to nodea

set access backup "*" nodea

Alice

NODEB

NODEA

TSM Server

72 IBM Tivoli Storage Manager: Building a Secure Environment

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 NODEAasnodename 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.

Chapter 4. Securing the client 73

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

NODEB NODECNODEA

/fs1/fs2

/fs3

NODEZ:/fs1/fs2/fs3

TSM Server

74 IBM Tivoli Storage Manager: Building a Secure Environment

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 NODEA’s 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 node’s 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.

Chapter 4. Securing the client 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 client’s 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 cloptset engbackup description=’Backup options for eng. dept.’define clientopt engbackup inclexcl "exclude *:\...\*" seq=10define clientopt engbackup inclexcl "include *:\...\*.odt" seq=20update 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 IBM Tivoli Storage Manager: Building a Secure Environment

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

dsm.opt/dsm.sys-------------------------include e:\...\*.aviinclude e:\...\*.mpginclude e:\...\*.avi

Client Option Set-------------------------exclude *:\...\*include *:\...\*.odt

Eva

luat

ion

NODEA

TSM Server

Chapter 4. Securing the client 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 IBM Tivoli Storage Manager: Building a Secure Environment

Part 2 Encryption

This part describes two methods for encrypting data within Tivoli Storage Manager: client encryption and TS1120 tape hardware encryption.

Part 2

© Copyright IBM Corp. 2007. All rights reserved. 79

80 IBM Tivoli Storage Manager: Building a Secure Environment

Chapter 5. Tivoli Storage Manager client data encryption

This chapter discusses Tivoli Storage Manager’s 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

5

© Copyright IBM Corp. 2007. All rights reserved. 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 Protocol Info 1 0.000000 192.168.204.128 192.168.99.231 TCP 1267 > 1500 [PSH, ACK] Seq=1303180445 Ack=399704979 Win=64324 Len=4

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 IBM Tivoli Storage Manager: Building a Secure Environment

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 00 2b f1 a5 01 00 1d 41 4e 52 32 30 36 33 49 20 .+.....ANR2063I 0010 4e 6f 64 65 20 4e 45 4e 59 41 20 75 70 64 61 74 Node NENYA updat0020 65 64 2e 7e ff 00 00 00 00 00 00 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 encryptionThis 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 00 3e 1e a5 66 15 07 d7 02 02 0b 0f 39 00 00 00 .>..f.......9...0010 07 00 07 00 0a 00 05 00 04 00 00 00 00 f7 7b bf ..............{.0020 6e f6 00 00 00 00 00 00 00 00 00 00 02 53 45 52 n............SER0030 56 45 52 31 4c 69 6e 75 78 2f 69 33 38 36 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 00 42 1a a5 66 00 00 00 05 04 02 00 05 00 09 00 .B..f...........0010 0e 00 00 00 00 0e 00 0a 00 00 dc f7 fa 88 00 00 ................0020 00 00 00 00 00 00 00 00 00 00 57 69 6e 4e 54 56 ..........WinNTV

84 IBM Tivoli Storage Manager: Building a Secure Environment

0030 45 4e 59 41 2d 57 49 4e 64 73 63 65 6e 75 2e 74 ENYA-WINdscenu.t0040 78 74 00 55 2a a5 00 01 00 29 00 05 00 03 00 04 xt.U*....)......0050 00 00 00 00 00 04 01 00 00 00 00 00 00 00 00 00 ................0060 04 00 09 00 0d 00 0f 00 1c 00 10 35 2e 30 31 56 ...........5.01V0070 45 4e 59 41 2d 57 49 4e 31 39 32 2e 31 36 38 2e ENYA-WIN192.168.0080 32 30 34 2e 31 32 38 07 72 33 e0 87 3d 11 d9 b2 204.128.r3..=...0090 e3 00 0c 29 cd c0 a4 ...)...

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 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 fc ................0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0070 00 00 00 00 00 00 00 00 00 00 00 00 56 45 4e 59 ............VENY0080 41 2d 57 49 4e 57 69 6e 4e 54 53 54 41 4e 44 41 A-WINWinNTSTANDA0090 52 44 5c 5c 76 65 6e 79 61 2d 77 69 6e 5c 63 24 RD\\venya-win\c$00a0 01 ff fe 11 ff ff ff fe 5c 01 ff fe 11 ff ff ff ........\.......00b0 fe 42 41 54 43 48 01 ff fe 11 ff ff ff fe 53 54 .BATCH........ST00c0 41 4e 44 41 52 44 53 54 41 4e 44 41 52 44 07 09 ANDARDSTANDARD..00d0 16 00 91 16 1b 01 00 00 00 00 00 00 00 00 02 4a ...............J00e0 00 00 0e 00 07 cf 16 d1 5d 00 00 00 30 00 00 00 ........]...0...0280 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 09 ................0290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................02a0 00 00 00 00 00 00 00 00 00 00 00 00 56 45 4e 59 ............VENY02b0 41 2d 57 49 4e 57 69 6e 4e 54 53 54 41 4e 44 41 A-WINWinNTSTANDA02c0 52 44 5c 5c 76 65 6e 79 61 2d 77 69 6e 5c 63 24 RD\\venya-win\c$02d0 01 ff fe 11 ff ff ff fe 5c 42 41 54 43 48 5c 01 ........\BATCH\.02e0 ff fe 11 ff ff ff fe 50 41 53 53 57 4f 52 44 53 .......PASSWORDS02f0 2e 54 58 54 01 ff fe 11 ff ff ff fe 53 54 41 4e .TXT........STAN0300 44 41 52 44 44 45 46 41 55 4c 54 07 09 16 00 91 DARDDEFAULT.....0310 16 1b 01 00 00 00 00 00 00 00 51 02 49 00 00 0e ..........Q.I...0470 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0480 00 02 00 00 00 00 00 00 00 51 4d 79 20 73 75 70 .........QMy sup0490 65 72 73 65 63 72 65 74 20 70 61 73 73 77 6f 72 ersecret passwor04a0 64 20 69 73 20 41 42 43 31 32 33 34 0d 0a 0d 0a d is ABC1234....04b0 43 72 65 64 69 74 20 43 61 72 64 20 4e 75 6d 62 Credit Card Numb04c0 65 72 20 30 31 32 33 2d 34 35 36 37 2d 38 39 30 er 0123-4567-89004d0 31 2d 32 33 34 35 2d 36 37 38 39 00 06 13 a5 01 1-2345-6789.....04e0 00 .

Backup session with AES128 data encryptionNext, 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).

Chapter 5. Tivoli Storage Manager client data encryption 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 00 3e 1e a5 66 15 07 d7 02 02 0b 38 23 00 00 00 .>..f......8#...0010 07 00 07 00 0a 00 05 00 04 00 00 00 00 f7 7b bf ..............{.0020 6e f6 00 00 00 00 00 00 00 00 00 00 02 53 45 52 n............SER0030 56 45 52 31 4c 69 6e 75 78 2f 69 33 38 36 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 00 42 1a a5 66 00 00 00 05 04 02 00 05 00 09 00 .B..f...........0010 0e 00 00 00 00 0e 00 0a 00 00 dc f7 fa 88 00 00 ................0020 00 00 00 00 00 00 00 00 00 00 57 69 6e 4e 54 56 ..........WinNTV0030 45 4e 59 41 2d 57 49 4e 64 73 63 65 6e 75 2e 74 ENYA-WINdscenu.t0040 78 74 00 55 2a a5 00 01 00 29 00 05 00 03 00 04 xt.U*....)......0050 00 00 00 00 00 04 01 00 00 00 00 00 00 00 00 00 ................0060 04 00 09 00 0d 00 0f 00 1c 00 10 35 2e 30 31 56 ...........5.01V0070 45 4e 59 41 2d 57 49 4e 31 39 32 2e 31 36 38 2e ENYA-WIN192.168.0080 32 30 34 2e 31 32 38 07 72 33 e0 87 3d 11 d9 b2 204.128.r3..=...0090 e3 00 0c 29 cd c0 a4 ...)...

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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0070 00 00 00 00 00 00 00 00 00 00 00 00 56 45 4e 59 ............VENY0080 41 2d 57 49 4e 57 69 6e 4e 54 53 54 41 4e 44 41 A-WINWinNTSTANDA0090 52 44 5c 5c 76 65 6e 79 61 2d 77 69 6e 5c 63 24 RD\\venya-win\c$00a0 01 ff fe 11 ff ff ff fe 5c 01 ff fe 11 ff ff ff ........\.......00b0 fe 42 41 54 43 48 01 ff fe 11 ff ff ff fe 53 54 .BATCH........ST00c0 41 4e 44 41 52 44 53 54 41 4e 44 41 52 44 07 09 ANDARDSTANDARD..00d0 16 00 91 16 1b 01 00 00 00 00 00 00 00 00 02 4a ...............J0280 00 00 01 00 00 00 00 00 00 00 00 00 00 00 01 09 ................0290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................02a0 00 00 00 00 00 00 00 00 00 00 00 00 56 45 4e 59 ............VENY02b0 41 2d 57 49 4e 57 69 6e 4e 54 53 54 41 4e 44 41 A-WINWinNTSTANDA02c0 52 44 5c 5c 76 65 6e 79 61 2d 77 69 6e 5c 63 24 RD\\venya-win\c$02d0 01 ff fe 11 ff ff ff fe 5c 42 41 54 43 48 5c 01 ........\BATCH\.02e0 ff fe 11 ff ff ff fe 50 41 53 53 57 4f 52 44 53 .......PASSWORDS02f0 2e 54 58 54 01 ff fe 11 ff ff ff fe 53 54 41 4e .TXT........STAN

86 IBM Tivoli Storage Manager: Building a Secure Environment

0300 44 41 52 44 44 45 46 41 55 4c 54 07 09 16 00 91 DARDDEFAULT.....0310 16 1b 01 00 00 00 00 00 00 00 51 02 49 80 02 0e ..........Q.I...03c0 59 20 19 e3 2e a2 1a 12 86 87 e4 d8 82 c1 95 5e Y .............^03d0 21 44 f3 0c 6a 0c 66 3d e5 a1 0a 14 c5 d9 a5 b5 !D..j.f=........03e0 51 5f c9 c7 03 3e 6b 5a be 0a 0e 37 1d 6e 6e de Q_...>kZ...7.nn.03f0 fe 63 07 66 a5 c1 2f 72 aa ed e4 32 51 47 dc 6d .c.f../r...2QG.m0400 c5 79 3f 76 34 01 d2 cd 10 3b b2 9b da 6f f5 0a .y?v4....;...o..0410 63 15 41 4b 64 af b3 3e f1 25 67 dc 9a 6e c6 00 c.AKd..>.%g..n..0420 cf 9a b6 45 d5 36 dc c9 03 27 72 6e 83 4e e6 96 ...E.6...'rn.N..0430 f0 88 9e de b9 88 a4 2a 1a 6a 25 4a 02 b2 a8 ff .......*.j%J....0440 b4 78 5e a7 6b f3 ca cd 88 9d c1 47 cf 3d 1b a5 .x^.k......G.=..0450 2c 27 9d 4f f0 36 89 7d 14 06 b4 5c c3 d4 0b 3c ,'.O.6.}...\...<0460 47 12 b2 71 d5 8b b1 b3 64 5c ae 05 30 22 f3 de G..q....d\..0"..0470 88 23 4b 74 47 b0 fe d3 c3 53 4e 01 ff bd c0 a2 .#KtG....SN.....0480 6d 79 d6 e4 32 4f c7 0d db 52 93 c9 0e 7f 68 65 my..2O...R....he0490 99 69 0e 42 6d 03 e6 ab 2a da 26 6e 6c 85 43 ee .i.Bm...*.&nl.C.04a0 20 b1 74 1b 39 09 fd 6d 9d d0 67 97 36 00 70 6f .t.9..m..g.6.po04b0 50 39 ca 5b 28 98 da 22 12 24 f0 11 f4 9b d9 7e P9.[(..".$.....~04c0 dd ef af d8 db 98 e7 82 4e f0 cc b7 c5 df 22 91 ........N.....".04d0 91 5e 28 00 14 07 a5 4f 88 83 d9 00 47 c1 29 cf .^(....O....G.).04e0 72 28 47 7a 4d 1e 89 00 06 13 a5 01 00 r(GzM........

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.

Note: The node name, file space, directory structure, and file name are not encrypted, only the contents of the file.

Chapter 5. Tivoli Storage Manager client data encryption 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.

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:

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.

88 IBM Tivoli Storage Manager: Building a Secure Environment

– For V5.3 clients, the encrypted key password is under:

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\NODENAME\SERVERNAME]

– For V5.4 clients, the encrypted key password is under:

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\NODENAME\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.

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:

Note: This is an important concept: The password is not the key but is used to create the key.

Chapter 5. Tivoli Storage Manager client data encryption 89

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\NODENAME\SERVERNAME]

– For V5.4 clients, the registry key password is under:

[HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\NODENAME\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 keysAt 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 client’s 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 retentionUnlike 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

ENCRYPTIONTYPEThis parameter specifies the type of encryption that you want: either DES56 or AES128. The default (and recommended type) is AES128.

ENCRYPTKEYThis 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.

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

Note: The default for the backup/archive client is to not encrypt the data.

Operation PASSWORDACCESS ENCRYPTKEY Result

Authorized userbackup

Prompt Prompt Prompts for both session password and encryption key password

Chapter 5. Tivoli Storage Manager client data encryption 91

Table 5-2 Authorized user restore behavior with PASSWORDACCESS and ENCRYPTKEY options

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 GUIThis 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.

Prompt Save Prompts for session password

Generate Prompt Prompted for encryption key password for files

Generate Save Not prompted. Uses the stored passwords

Operation PASSWORDACCESS ENCRYPTKEY Result

Authorized user restore

Prompt Prompt Prompted for both session password and encryption key password

Prompt Save Prompted for session password only

Generate Prompt Prompted for encryption key password

Generate Save Not prompted. Uses the stored passwords

Operation PASSWORDACCESS ENCRYPTKEY Result

92 IBM Tivoli Storage Manager: Building a Secure Environment

The client system options file contains the entries that are shown in Example 5-8.

Example 5-8 Windows client options file

TCPSERVERADDRESS 192.168.99.231nodename venya-win

encryptkey saveencryptiontype AES128include.encrypt *

PASSWORDACCESS GENERATEMANAGEDSERVICES WEBCLIENT SCHEDULEtxnbytelimit 25600tcpwindowsize 63tcpnodelay yessubdir yes

Initial backup with ENCRYPTKEY SAVEIn 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.

Chapter 5. Tivoli Storage Manager client data encryption 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 SAVEAs 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 keyIf 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 IBM Tivoli Storage Manager: Building a Secure Environment

Figure 5-4 Prompt during restore if saved encryption key is unavailable

Multiple keysWhen 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.

Chapter 5. Tivoli Storage Manager client data encryption 95

Example 5-9 Linux client system options file

SErvername local COMMmethod TCPip TCPPort 1500 TCPServeraddress 127.0.0.1 passwordaccess generate

encryptkey save encryptiontype aes128 include.encrypt /home/* include.encrypt /home/.../*

Initial backup with ENCRYPTKEY SAVEIf 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.

Subsequent backups or restores with ENCRYPTKEY SAVEAs 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 keyIf 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.

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.

96 IBM Tivoli Storage Manager: Building a Secure Environment

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 keysWhen 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 lineThe 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.

Chapter 5. Tivoli Storage Manager client data encryption 97

Example 5-10 Windows client options file

TCPSERVERADDRESS 192.168.99.231nodename venya-win

encryptkey saveencryptiontype AES128include.encrypt *

PASSWORDACCESS GENERATEMANAGEDSERVICES WEBCLIENT SCHEDULEtxnbytelimit 25600tcpwindowsize 63tcpnodelay yessubdir yes

Initial backup with ENCRYPTKEY SAVEThe 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 operationAction [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 saveAs 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 lostIn 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 operationAction [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 operationAction [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.

Chapter 5. Tivoli Storage Manager client data encryption 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 encryptionThis 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 nenya COMMmethod TCPip TCPPort 1500 TCPServeraddress 127.0.0.1

passwordaccess generate encryptiontypeaes 128

include.encrypt /* include.encrypt /.../*

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 nenyasubdir yes

Chapter 5. Tivoli Storage Manager client data encryption 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_apisubdir 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 APIThe output from the test without encryption is shown in the following sections.

Log in to the Tivoli Storage Manager serverExample 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. Signon1. Backup2. Restore3. Archive4. Retrieve5. Queries6. Change Password7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent8. Set preferences, envSetUp9. Exit to system10. Restore/Retrieve Without Offset Prompt

102 IBM Tivoli Storage Manager: Building a Secure Environment

11. Extended Signon

Enter selection ==>0Node name:nenya_apiOwner name:nenya_apiPassword:nenyaAPI Config file:/opt/tivoli/tsm/client/ba/api/bin/dsm.optSession options:User Name:nenya_apiUser pswd:nenyaAre the above responses correct (y/n/q)? yDoing signon for node nenya_api, owner nenya_api, with password nenyaHandle on return = 1

Backup of test file with no encryptionExample 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. Signon1. Backup2. Restore3. Archive4. Retrieve5. Queries6. Change Password7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent8. Set preferences, envSetUp9. Exit to system10. Restore/Retrieve Without Offset Prompt11. Extended Signon

Enter selection ==>1Filespace:/Highlevel:/tmpLowlevel:/testfile.txtObject Type(D/F):fObject Owner Name:nenya_apiObject already compressed?(Y/N):nWait for mount?(Y/N):yFile size:1024Number of files:1Seed string:This is a test fileMgmt class override:Are the above responses correct (y/n/q)? yCreating 1 object(s) called //tmp/testfile.txt(nnn) each of size 1,024.Creating object 1 of 1 Size=1,024 Name=//tmp/testfile.txtObject: 1 Buffer: 1 Bytes sent: 1,024 Bytes left: 0

Chapter 5. Tivoli Storage Manager client data encryption 103

Total bytes sent: 1,024Compression: NOCompressed size: 0LAN-free bytes sent: 0Encryption: NOEncryption Strength: NONE

Network trace without encryptionFirst, 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.

Figure 5-9 Unencrypted data sent from API

Network trace with encryptionTransparent 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 aes128include.encrypt /*include.encrypt /.../*enableclientencryptkey 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. Signon1. Backup2. Restore3. Archive4. Retrieve5. Queries6. Change Password7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent8. Set preferences, envSetUp9. Exit to system10. Restore/Retrieve Without Offset Prompt11. Extended Signon

0130 ff ff 54 68 69 73 20 69 73 20 61 20 74 65 73 74 ..This is a test0140 20 66 69 6c 65 32 30 54 68 69 73 20 69 73 20 61 file20This is a0150 20 74 65 73 74 20 66 69 6c 65 34 31 54 68 69 73 test file41This0160 20 69 73 20 61 20 74 65 73 74 20 66 69 6c 65 36 is a test file60170 32 54 68 69 73 20 69 73 20 61 20 74 65 73 74 20 2This is a test 0180 66 69 6c 65 38 33 54 68 69 73 20 69 73 20 61 20 file83This is a 0190 74 65 73 74 20 66 69 6c 65 31 30 34 54 68 69 73 test file104This

104 IBM Tivoli Storage Manager: Building a Secure Environment

Enter selection ==>1Filespace:/Highlevel:/tmpLowlevel:/testfile.txtObject Type(D/F):fObject Owner Name:nenya_apiObject already compressed?(Y/N):nWait for mount?(Y/N):yFile size:1024Number of files:1Seed string:This is a test file tooMgmt class override:Are the above responses correct (y/n/q)? yCreating 1 object(s) called //tmp/testfile.txt(nnn) each of size 1,024.Creating object 1 of 1 Size=1,024 Name=//tmp/testfile.txtObject: 1 Buffer: 1 Bytes sent: 1,024 Bytes left: 0Total bytes sent: 1,030Compression: NOCompressed size: 0LAN-free bytes sent: 0Encryption: CLIENTENCRKEYEncryption 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.

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.

0130 f8 df 9d 8e 27 20 bf dd d4 19 f2 e8 c5 84 e9 fa ....' ..........0140 13 f1 ae 2e b5 4a 7f 33 92 9a 6c 5e b7 33 98 ba .....J.3..l^.3..0150 2d 9e d2 c8 7e 38 3e 66 73 bb f2 47 24 e1 00 00 -...~8>fs..G$...0160 08 a5 00 00 01 00 00 00 04 16 80 03 00 c2 0f 00 ................0170 05 19 f0 36 06 29 d6 2f 8d fd c5 87 a3 5b 31 3d ...6.)./.....[1=0180 57 bf 3c ca 8b 2f 79 f2 49 37 0c dc 92 ad 4b 30 W.<../y.I7....K00190 e0 67 3d aa f1 31 6d 0f 49 3b e2 21 48 e9 8d bf .g=..1m.I;.!H...

Chapter 5. Tivoli Storage Manager client data encryption 105

Description of the test environmentFor 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 tcpip TCPPort 1500 TCPServeraddress localhost nodename adsm01

passwordaccess generate errorlogname /tmp/dsmerror.log errorlogretention 7 d schedlogname /tmp/dsmsched.log schedlogretention 7 d schedmode prompted managedservices webclient schedule

encryptiontype AES128 encryptkey prompt

include * to_backuptape2* include.encrypt /Install/* to_backuptape2* include.encrypt /Install/.../* 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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 5-19 Test 1 without encryption

root@adsm01:bin>dsmc s '/Install/*' -subdir=yes -quietIBM Tivoli Storage ManagerCommand 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: ADSM01Session 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,361Total number of objects backed up: 26,361Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 3.45 GBData transfer time: 13.69 secNetwork data transfer rate: 264,444.16 KB/secAggregate data transfer rate: 12,421.10 KB/secObjects 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.

Chapter 5. Tivoli Storage Manager client data encryption 107

Example 5-20 Test two without encryption

root@adsm01:bin>dsmc s '/Install/*' -subdir=yes -quietIBM Tivoli Storage ManagerCommand Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.0 Client date/time: 02/20/07 13:43:56(c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved.

Node Name: ADSM01Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 3, Level 2.0 Server date/time: 02/20/07 13:43:56 Last access: 02/20/07 13:35:21

Total number of objects inspected: 26,361Total number of objects backed up: 26,361Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 3.45 GBData transfer time: 23.26 secNetwork data transfer rate: 155,703.37 KB/secAggregate data transfer rate: 11,910.81 KB/secObjects 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 tcpip TCPPort 1500 TCPServeraddress localhost nodename adsm01

passwordaccess generate errorlogname /tmp/dsmerror.log errorlogretention 7 d schedlogname /tmp/dsmsched.log schedlogretention 7 d schedmode prompted managedservices webclient schedule

encryptiontype AES128 encryptkey prompt

include * to_backuptape2 include.encrypt /Install/* to_backuptape2 include.encrypt /Install/.../* to_backuptape2

Example 5-22 Test three with AES128 encryption

root@adsm01:bin>dsmc s '/Install/*' -subdir=yes -quietIBM Tivoli Storage ManagerCommand Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.0 Client date/time: 02/20/07 14:02:35(c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved.

Node Name: ADSM01Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 3, Level 2.0 Server date/time: 02/20/07 14:02:35 Last access: 02/20/07 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 operationAction [1,A] : 1

Enter encryption key password:Confirm encryption key password:

Total number of objects inspected: 26,361

Chapter 5. Tivoli Storage Manager client data encryption 109

Total number of objects backed up: 26,361Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 3.45 GBData transfer time: 26.15 secNetwork data transfer rate: 138,509.40 KB/secAggregate data transfer rate: 10,838.15 KB/secObjects 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

root@adsm01:bin>dsmc s '/Install/*' -subdir=yes -quietIBM Tivoli Storage ManagerCommand Line Backup/Archive Client Interface Client Version 5, Release 3, Level 2.0 Client date/time: 02/20/07 14:11:22(c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved.

Node Name: ADSM01Session established with server ADSM: AIX-RS/6000 Server Version 5, Release 3, Level 2.0 Server date/time: 02/20/07 14:11:22 Last access: 02/20/07 14:02:45

--- User Action is Required ---File: /Install/dlmgr.pro requires an encryption key.

Select an appropriate action

110 IBM Tivoli Storage Manager: Building a Secure Environment

1. Prompt for encrypt key password A. Abort this operationAction [1,A] : 1

Enter encryption key password:Confirm encryption key password:

Total number of objects inspected: 26,361Total number of objects backed up: 26,361Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 3.45 GBData transfer time: 26.43 secNetwork data transfer rate: 137,037.30 KB/secAggregate data transfer rate: 10,501.22 KB/secObjects 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

In this simple test scenario, we saw a significant increase in CPU utilization but a relatively small decrease in backup throughput.

Test one

Test two

Average one and two

Test three

Test four

Averagethree and four

Percent Change

MB/Sec 12.421 11.910 12.165 10.838 10.501 10.669 -12.3%

Maximum CPU%

17.0 18.3 17.65 35.1 27.8 31.4 78%

Chapter 5. Tivoli Storage Manager client data encryption 111

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.

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.

112 IBM Tivoli Storage Manager: Building a Secure Environment

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.

6

Note: IBM intends to make encryption available for LTO tape drives by using similar methods to the methods we describe here.

© Copyright IBM Corp. 2007. All rights reserved. 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).

Figure 6-1 TS1120 encryption methods

Application-managed encryptionApplication-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.

Enc

rypt

ion

Key

Man

ager

Encryption Methods

Library-Managed___________

TS3500______________

System-Managed________z/OS & AIX__________

Application-Managed(TSM Only) Policy

Policy

Policy

114 IBM Tivoli Storage Manager: Building a Secure Environment

Library-managed encryptionWith 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 encryptionWith 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

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 codesAll 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.

uP

TAPE DRIVE

Compression

FC port0 FC port1

Decompression

Encryption

Dynamicdecryption

buffer

ASIC

Drive Firmware

AES

Host Interface DMA

ECC and format encoding

RW electronics

RW Head

Tape Media

Code Memory

Code Memory

Host

116 IBM Tivoli Storage Manager: Building a Secure Environment

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 drive’s 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.

Chapter 6. TS1120 Tape encryption 117

EKM componentsEKM 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 keystoreThe 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 User’s 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 fileThis 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 tableThe 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/keymanagerperigee> 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 TS1120Tivoli 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.

Chapter 6. TS1120 Tape encryption 119

Table 6-1 Managing encryption policy

Types of encryption management

Description Notes Supported environment

Application-managed The application directly controls whether a cartridge is encrypted. The policy and keys are passed between the application layer and the drives.

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 somenon-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.

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.

Considerations:� 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 drive’s alternate Fibre Channel connection.

IBM Atape AIX device driver, IBMtape Solaris device driver, and z/OS (through DFSMS™)

120 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Library-managed The library controls whether a specific cartridge is encrypted.

Considerations:� Based on drive

settings, the library allows you to 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.

All applications that support the TS3500 Tape Library and are open-attached.

Types of encryption management

Description Notes Supported environment

Chapter 6. TS1120 Tape encryption 121

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.

Figure 6-5 Decryption data flow for the AME process

Tape1 AES Data Key Tape3 AES Data Key

Tape2 AES Data Key Tape4 AES Data Key

Database

Generate DKStore DK in Database

Tivoli Storage Manager

DriveDK+DATA=>Encrypted Data

TapeAES 256

Encrypted Data

Encrypted Data

DK

Tape ID

Tape ID

1

1

2

3

13

4

2

Tape1 AES Data Key Tape3 AES Data KeyTape2 AES Data Key Tape4 AES Data Key

Database

Search Table for Tape IDRetrieve DK from Database

Tivoli Storage Manager

DriveDK+Encrypted DATA=>Clear Data

TapeAES 256

Encrypted Data

Decrypted Data

DK

Tape ID

Tape ID

1

3

122 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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.

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.

Chapter 6. TS1120 Tape encryption 123

Figure 6-6 Library-managed tape encryption

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.

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.

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.

3592TS1120

TS3500

Tape

EKM Server Application

DeviceDriver

Keys

Fibre

TCP/IP

Data

Library-Managed Encryption for Open Systems servers

Note: SME is currently available on AIX, Solaris, and z/OS operating systems.

124 IBM Tivoli Storage Manager: Building a Secure Environment

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.

3592TS1120

TS3500

Tape

AIX

AtapeFibre

Keystore

EKMData and Keys

System-Managed Encryption for Open Systems Servers (In-band)

Application

Chapter 6. TS1120 Tape encryption 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.

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 classThe 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

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.

126 IBM Tivoli Storage Manager: Building a Secure Environment

Library Name Drive Name Device Type On-Line------------ ------------ ----------- -------------------LIB2-ENCRYPT DRV1-3592 3592 YesLIB2-ENCRYPT DRV2-3592 3592 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 Device Estimated Pct Pct High Low Next Stora-Pool Name Class Name Capacity Util Migr Mig Mig ge Pool Pct Pct----------- ---------- ---------- ----- ----- ---- --- -----------LIB2-ENCRY- LIB2-ENCR- 900 G 0.0 20.0 90 70 PT_POOL YPT

tsm: PERIGEE>q devclass lib2-encrypt f=d

Device Class Name: LIB2-ENCRYPT Device Access Strategy: Sequential Storage Pool Count: 2 Device Type: 3592 Format: DRIVE Est/Max Capacity (MB): Mount Limit: DRIVES Mount Wait (min): 5 Mount Retention (min): 0 Label Prefix: ADSM Library: LIB2-ENCRYPT Directory: Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: No

Chapter 6. TS1120 Tape encryption 127

Drive Encryption: On Scaled Capacity: 20Last Update by (administrator): ADMIN Last Update Date/Time: 08/10/06 12:31:02

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: J12457 Storage Pool Name: LIB2-ENCRYPT_POOL Device Class Name: LIB2-ENCRYPT Estimated Capacity: 300,000.0 Scaled Capacity Applied: 20 Pct Util: 0.0 Volume Status: Filling Access: Read/Write Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 1 Write Pass Number: 1 Approx. Date Last Written: 02/27/07 17:02:14 Approx. Date Last Read: 02/27/07 17:02:07 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location:Volume is MVS Lanfree Capable : NoLast Update by (administrator): Last Update Date/Time: 02/27/07 17:01:40 Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: Tivoli Storage Manager

Note: Drive Encryption is set to ON for Tivoli Storage Manager with AME.

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 IBM Tivoli Storage Manager: Building a Secure Environment

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 User’s Guide, GA76-0418, for assistance to decide which keystore type to use. Some keystores are only supported on particular operating system platforms, for example.

Chapter 6. TS1120 Tape encryption 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 EnvironmentWe 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 -altotal 146392drwxr-xr-x 4 root system 512 Feb 05 17:37 .drwxr-xr-x 46 bin bin 1024 Feb 05 18:13 ..-rw-r----- 1 root system 74936320 Jan 31 18:42 j532redist.tardrwxr-xr-x 31 root sys 512 Nov 18 2005 licensedrwxr-xr-x 7 root sys 512 Oct 09 08:43 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/binP9=/usr/java50/sdk/binJAVA_HOME=/usr/java50/sdk/jreCLASSPATH=/usr/java50/sdk/jre/libPATH=$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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 6-9 Java version output

/home/root> java -versionjava 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_bHdSMRJIT - 20060908_1811_r8GC - 20060906_AA)JCL - 20061002

Install the unrestricted policy filesRegardless 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 -altotal 128drwxr-xr-x 2 root sys 512 Feb 07 13:07 .drwxr-xr-x 10 root sys 1024 Oct 09 08:43 ..-rw-r--r-- 1 root system 2199 Feb 05 18:06 US_export_policy.jar-rw-r--r-- 1 root sys 29731 Oct 02 04:03 cacerts-rw-r--r-- 1 root sys 2646 Oct 02 04:03 java.policy-rw-r--r-- 1 root sys 9609 Oct 02 04:03 java.security-rw-r--r-- 1 root system 2212 Feb 05 18:06 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 -altotal 7624drwxr-xr-x 2 root sys 512 Oct 09 08:43 .drwxr-xr-x 10 root sys 1024 Oct 09 08:43 ..-rw-r--r-- 1 root sys 183719 Oct 02 04:03 CmpCrmf.jar-rw-r--r-- 1 root sys 268451 Oct 02 04:03 IBMKeyManagementServer.jar...

Chapter 6. TS1120 Tape encryption 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,failureAudit.event.types = allAudit.eventQueue.max = 0Audit.handler.file.directory = keymanager/auditAudit.handler.file.name = kms_audit.logAudit.handler.file.size = 10000Admin.ssl.keystore.name = testkeysAdmin.ssl.truststore.name = testkeysconfig.drivetable.file.url = FILE://keymanager/drivetabledebug = nonedebug.output = simple_filedebug.output.file = keymanager/debugfips = OffTransportListener.ssl.ciphersuites = JSSE_ALLTransportListener.ssl.clientauthentication = 0TransportListener.ssl.keystore.name = keymanager/testkeysTransportListener.ssl.keystore.type = jceksTransportListener.ssl.port = 443TransportListener.ssl.protocols = SSL_TLSTransportListener.ssl.truststore.name = testkeysTransportListener.ssl.truststore.type = jceksTransportListener.tcp.port = 3801 config.keystore.file = keymanager/testkeysconfig.keystore.provider = IBMJCEconfig.keystore.type = jceks

Creating the keystoreNow 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 GIcert1keytool -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 GIcert1keytool -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 GIcert2keytool -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 GIcert2keytool -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 GIcert3keytool -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 GIcert3keytool -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 GIcert4keytool -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 GIcert4keytool -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.

Chapter 6. TS1120 Tape encryption 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: JCEKSKeystore 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:74gicert3, Jan 30, 2007, keyEntry,Certificate fingerprint (MD5): 89:69:F6:B1:7A:97:C1:24:20:32:81:0A:90:1C:43:6Dgicert2, Jan 30, 2007, keyEntry,Certificate fingerprint (MD5): B1:A8:02:6E:D1:88:E9:C1:6B:B7:BE:93:A5:7F:2C:8Cgicert1, 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 fileExample 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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 6-15 Customized KeyManagerConfig.properties file

TransportListener.ssl.port = 443TransportListener.tcp.port = 3801fips = OffAdmin.ssl.keystore.name = GIkeys.jcksconfig.keystore.provider = IBMJCETransportListener.ssl.clientauthentication = 0TransportListener.ssl.ciphersuites = JSSE_ALLAudit.handler.file.size = 10000drive.acceptUnknownDrives = falseTransportListener.ssl.truststore.name = GIkeys.jcksAudit.handler.file.directory = auditTransportListener.ssl.protocols = SSL_TLSconfig.keystore.file = GIkeys.jcksTransportListener.ssl.truststore.type = jceksdebug.output = simple_fileTransportListener.ssl.keystore.name = GIkeys.jcksAudit.eventQueue.max = 0debug.output.file = keymanager/debugTransportListener.ssl.keystore.type = jceksAudit.handler.file.name = kms_audit.logconfig.keystore.type = jceksAudit.event.outcome = success,failuredebug = noneAudit.event.types = allconfig.drivetable.file.url = FILE:/usr/ekm/keymanager/drivetableAdmin.ssl.truststore.name = GIkeys

Start the EKM serverExample 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# startekmpassword: *********** <-- enter password hereLoaded drive key store successfullyStarting the Encryption Key Manager 1.0-20060816Processing ArgumentsProcessingServer is started

# statusServer is running. TCP port: 3801, SSL port: 443

# listconfigdebug.output=simple_fileconfig.drivetable.file.url=FILE:/usr/ekm/keymanager/drivetableAdmin.ssl.keystore.name=GIkeys.jcksAudit.handler.file.directory=auditAudit.event.types=allAdmin.ssl.truststore.name=GIkeys

Chapter 6. TS1120 Tape encryption 135

debug.output.file=keymanager/debugTransportListener.ssl.protocols=SSL_TLSAudit.handler.file.name=kms_audit.logTransportListener.ssl.keystore.name=GIkeys.jcksAudit.eventQueue.max=0TransportListener.tcp.port=3801TransportListener.ssl.truststore.name=GIkeys.jcksconfig.keystore.file=GIkeys.jcksAudit.handler.file.size=10000config.keystore.type=jceksTransportListener.ssl.ciphersuites=JSSE_ALLTransportListener.ssl.clientauthentication=0TransportListener.ssl.port=443TransportListener.ssl.keystore.type=jceksdebug=noneconfig.keystore.provider=IBMJCETransportListener.ssl.truststore.type=jceksAudit.event.outcome=success,failuredrive.acceptUnknownDrives=falsefips=Off

# listcerts -vKeystore entries: 4Keystore type:jceksKeystore provider:IBMJCE

Alias name: gicert4Creation date: Tue Feb 06 00:53:00 MST 2007Entry type: keyEntryOwner: CN=GIcomIssuer: CN=GIcomSerial number: 1170748379Valid from: Tue Feb 06 00:52:59 MST 2007 until: Sun Nov 01 00:52:59 MST 2009Certificate 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:88: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:46: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:1b: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: gicert1Creation date: Mon Feb 05 18:24:47 MST 2007Entry type: keyEntryOwner: CN=GIcomIssuer: CN=GIcomSerial number: 1170725087Valid from: Mon Feb 05 18:24:47 MST 2007 until: Sat Oct 31 18:24:47 MST 2009

136 IBM Tivoli Storage Manager: Building a Secure Environment

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:63: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

Defining the tape drivesNow 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 administrator’s 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.

Note: To detect new certificates added while the EKM is running, you need to restart the EKM.

Chapter 6. TS1120 Tape encryption 137

Example 6-17 Example of how to get a tape drive serial number

tsm: PERIGEE>query drive lib2-encrypt f=d

Library Name: LIB2-ENCRYPT Drive Name: DRV1-3592 Device Type: 3592 On-Line: Yes Read Formats: 3592-2C,3592-2,3592C,3592 Write Formats: 3592-2C,3592-2,3592C,3592 Element: 295 Drive State: EMPTY Volume Name: Allocated to: WWN: 5005076300010833 Serial Number: 000001350440 Last Update by (administrator): ADMIN Last Update Date/Time: 08/09/06 17:35:03Cleaning Frequency (Gigabytes/ASNEEDED/NONE): NONE

Library Name: LIB2-ENCRYPT Drive Name: DRV2-3592 Device Type: 3592 On-Line: Yes Read Formats: 3592-2C,3592-2,3592C,3592 Write Formats: 3592-2C,3592-2,3592C,3592 Element: 296 Drive State: UNKNOWN Volume Name: Allocated to: WWN: 5005076300010834 Serial Number: 000001350446 Last Update by (administrator): ADMIN Last Update Date/Time: 02/21/07 15:53:22Cleaning Frequency (Gigabytes/ASNEEDED/NONE): 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 party’s public key needs to be stored in our local EKM keystore. The external party’s 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 party’s keystore.

138 IBM Tivoli Storage Manager: Building a Secure Environment

� 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 location’s public key label. Again, the DR location’s public key must be stored within the local 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

# listdrivesDrive entries:2SerialNumber = 000001350440SerialNumber = 000001350446

Registering the EKM server with the tape libraryTo 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 User’s 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 EKMAlthough 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: 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.

Note: Do not remove an expired certificate from the keystore because this prevents an encrypted tape from being read.

Chapter 6. TS1120 Tape encryption 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 libraryTo 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.

Chapter 6. TS1120 Tape encryption 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

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.

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.

142 IBM Tivoli Storage Manager: Building a Secure Environment

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

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 LMEFrom 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.

Note: The IBM System Storage TS3500 Tape Library Operator Guide, GA32-0560-01 still refers to the BEP as the scratch encryption policy.

Chapter 6. TS1120 Tape encryption 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: LIB2-ENCRYPT Device Access Strategy: Sequential Storage Pool Count: 2 Device Type: 3592 Format: DRIVE Est/Max Capacity (MB): Mount Limit: DRIVES Mount Wait (min): 5 Mount Retention (min): 0 Label Prefix: ADSM Library: LIB2-ENCRYPT Directory: Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: No Drive Encryption: Allow Scaled Capacity: 20Last Update by (administrator): ADMIN Last Update Date/Time: 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.jarArchive 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 Type Filespace FSID Client's Name for File Name--------------- ---- ---------- ---- ---------------------PERIGEE Arch /tmp 7 /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.

Chapter 6. TS1120 Tape encryption 145

Example 6-22 Query volume output for LME

tsm: PERIGEE>query volume sj0011 f=d

Volume Name: SJ0011 Storage Pool Name: LIB2-ENCRYPT_POOL Device Class Name: LIB2-ENCRYPT Estimated Capacity: 300,000.0 Scaled Capacity Applied: 20 Pct Util: 0.0 Volume Status: Filling Access: Read/Write Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 1 Write Pass Number: 1 Approx. Date Last Written: 02/07/07 00:51:22 Approx. Date Last Read: 02/07/07 00:51:22 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location:Volume is MVS Lanfree Capable : NoLast Update by (administrator): Last Update Date/Time: 02/07/07 00:51:22 Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: 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.

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.

146 IBM Tivoli Storage Manager: Building a Secure Environment

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 driverUpgrade 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 SMESME 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.

Chapter 6. TS1120 Tape encryption 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 encryptionGetting drive encryption settings...Encryption settings:Drive Encryption Capable.... YesEncryption Method........... SystemEncryption State............ On

perigee> tapeutil -f /dev/rmt71 encryptionGetting drive encryption settings...Encryption settings:Drive Encryption Capable.... YesEncryption Method........... SystemEncryption State............ On

Updating the Atape EKM proxy configuration fileThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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:portperigee 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 configurationTwo 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 -El rmt70| grep encryptdrv_encryption yes Drive Encryption Support Falsesys_encryption no Use System Encryption FCP Proxy Manager Truewrt_encryption off System Encryption for Write Commands at BOP True

perigee> lsattr -El rmt71| grep encryptdrv_encryption yes Drive Encryption Support Falsesys_encryption no Use System Encryption FCP Proxy Manager Truewrt_encryption 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.

Chapter 6. TS1120 Tape encryption 149

[Entry Fields] Tape Drive rmt70 Tape Drive type 3592 Tape Drive interface fcp Description IBM 3592 Tape Drive (> Status Available Location 11-08-01 Parent adapter fscsi0 Connection address 88 SCSI ID 0xa1a6d Logical Unit ID 0x0 World Wide Port Name 0x5005076300410833 World Wide Node Name 0x5005076300010833 New Logical Name [] Enable Alternate Pathing Support no + Block Size (0=Variable Length) [0] +# Use DEVICE BUFFERS during writes yes + Use Hardware Compression on Tape yes + Activate volume information logging no + Maximum size of log file (in # of entries) [500] +# Backward Space/Forward Space Record Mode SCSI + Use Immediate Bit in Rewind Commands no + Trailer Label Processing no + Use System Encryption FCP Proxy Manager yes + System Encryption for Write Commands at BOP on +

Example 6-28 shows that both tape drives, rmt70 and rmt71, now have SME enabled.

Example 6-28 lsattr output

perigee> lsattr -El rmt70 | grep encryptdrv_encryption yes Drive Encryption Support Falsesys_encryption yes Use System Encryption FCP Proxy Manager Truewrt_encryption on System Encryption for Write Commands at BOP True

perigee> lsattr -El rmt71 | grep encryptdrv_encryption yes Drive Encryption Support Falsesys_encryption yes Use System Encryption FCP Proxy Manager Truewrt_encryption on System Encryption for Write Commands at BOP True

Verify Tivoli Storage Manager with SMEWe 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.txtArchive 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 IBM Tivoli Storage Manager: Building a Secure Environment

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: 2Total number of objects archived: 2Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 964 BData transfer time: 0.00 secNetwork data transfer rate: 117,675.78 KB/secAggregate data transfer rate: 0.00 KB/secObjects 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 Type Filespace FSID Client's Name for File Name--------------- ---- ---------- ---- -----------------------PERIGEE Arch /tmp 7 /ekm/ SME-backup-test.txt

tsm: PERIGEE>query volume sj0011 f=d

Volume Name: SJ0011 Storage Pool Name: LIB2-ENCRYPT_POOL Device Class Name: LIB2-ENCRYPT Estimated Capacity: 300,000.0 Scaled Capacity Applied: 20 Pct Util: 0.0 Volume Status: Filling Access: Read/Write Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 1 Write Pass Number: 1 Approx. Date Last Written: 02/08/07 01:20:00 Approx. Date Last Read: 02/08/07 01:20:00 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location:Volume is MVS Lanfree Capable : NoLast Update by (administrator):

Chapter 6. TS1120 Tape encryption 151

Last Update Date/Time: 02/08/07 01:19:40 Begin Reclaim Period: End Reclaim Period: Drive Encryption Key Manager: System

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 synchronizationExample 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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 6-31 Manual synchronization of configuration files

# sync -all -ipaddr 9.11.124.253:443Attempting to contact remote server 9.11.124.253:443Sync completed

Automatic synchronizationTo 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:443sync.action=rewritesync.timeinhours=24sync.type=all...

Other synchronization methodsOther 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

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.

Chapter 6. TS1120 Tape encryption 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/shjava com.ibm.keymanager.KMSAdminCmd KeyManagerConfig.properties <<EOFstartekmpassphrasestatusEOF

� 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 abcd1234Keystore type: jceks

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.

154 IBM Tivoli Storage Manager: Building a Secure Environment

Keystore provider: IBMJCEYour keystore contains 4 entriesgicert4, Feb 6, 2007, keyEntry,Certificate fingerprint (MD5): 99:6A:AE:51:70:B9:F4:06:1C:9D:FE:BB:E0:23:CC:71gicert3, Feb 6, 2007, keyEntry,Certificate fingerprint (MD5): 1F:F5:7C:5A:1E:B3:E6:F5:43:B9:24:FE:C6:B1:59:E2gicert2, Feb 6, 2007, keyEntry,Certificate fingerprint (MD5): 67:C1:E7:39:FC:2F:C9:B2:DC:A4:0A:97:2E:3E:61:FCgicert1, 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 User’s 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 User’s 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 User’s Guide, GA76-0418

� Keytool User Guide for SDK 1.4.2, available at:

http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDocs/KeyToolUserGuide-142.html

Chapter 6. TS1120 Tape encryption 155

156 IBM Tivoli Storage Manager: Building a Secure Environment

Part 3 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

Part 3

© Copyright IBM Corp. 2007. All rights reserved. 157

158 IBM Tivoli Storage Manager: Building a Secure Environment

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)

7

© Copyright IBM Corp. 2007. All rights reserved. 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 Administrator’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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: ADMIN Last Access Date/Time: 01/29/2007 09:05:31 Days Since Last Access: <1 Password Set Date/Time: 01/26/2007 14:20:18 Days Since Password Set: 3 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Yes Policy Privilege: ** Included with system privilege ** Storage Privilege: ** Included with system privilege ** Analyst Privilege: ** Included with system privilege ** Operator Privilege: ** Included with system privilege ** Client Access Privilege: ** Included with system privilege ** Client Owner Privilege: ** Included with system privilege ** Registration Date/Time: 01/26/2007 14:20:18 Registering Administrator: SERVER_CONSOLE Managing profile:Password Expiration Period: Email Address:

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 Administrator’s Reference for your server platform in the chapter “Using Commands Based on Privilege Class.”

UnrestrictedUnrestricted 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=policyANR2077I Unrestricted policy privilege granted to administrator POLICYADMIN.tsm: SERVER1>q admin policyadmin f=d

Administrator Name: POLICYADMIN Last Access Date/Time: 01/29/2007 09:27:24 Days Since Last Access: <1 Password Set Date/Time: 01/29/2007 09:27:24 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Policy Privilege: ** Unrestricted ** Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/29/2007 09:27:24 Registering Administrator: ADMIN Managing profile:Password Expiration Period: Email Address:

RestrictedAdministrators 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=newdomainANR2078I Restricted policy privilege granted to administrator POLICYADMIN - policy domain NEWDOMAIN.tsm: SERVER1>q admin policyadmin f=d

Administrator Name: POLICYADMIN Last Access Date/Time: 01/29/2007 09:27:24 Days Since Last Access: <1 Password Set Date/Time: 01/29/2007 09:27:24 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Policy Privilege: NEWDOMAIN Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/29/2007 09:27:24

162 IBM Tivoli Storage Manager: Building a Secure Environment

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: policyadmin

Enter your password: *****

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 newdomainANR2035E DELETE DOMAIN: Administrator POLICYADMIN is not authorized to issue this command.ANS8001I Return code 9.

tsm: SERVER1>copy domain standard testdomainANR2035E COPY DOMAIN: Administrator POLICYADMIN is not authorized to issue this command.ANS8001I Return code 9.

tsm: SERVER1>define domain testdomainANR2035E 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 Administrator’s Reference for your server platform, in the chapter “Using Commands Based on Privilege Class.”

UnrestrictedAn 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.

Chapter 7. Server administration 163

Example 7-5 ID with unrestricted storage privilege

tsm: SERVER1>grant authority storageadmin class=storageANR2079I Unrestricted storage privilege granted to administrator STORAGEADMIN.tsm: SERVER1>q admin storageadmin f=d

Administrator Name: STORAGEADMIN Last Access Date/Time: 01/29/2007 09:45:12 Days Since Last Access: <1 Password Set Date/Time: 01/29/2007 09:45:12 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Policy Privilege: Storage Privilege: ** Unrestricted ** Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/29/2007 09:45:12 Registering Administrator: ADMIN Managing profile:Password Expiration Period: Email Address:

RestrictedAn 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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 7-6 ID with restricted storage privilege

tsm: SERVER1>grant authority storageadmin class=storage stgpool=backuppoolANR2080I Restricted storage privilege granted to administrator STORAGEADMIN - storage pool BACKUPPOOL.tsm: SERVER1>q admin storageadmin f=d

Administrator Name: STORAGEADMIN Last Access Date/Time: 01/29/2007 09:45:12 Days Since Last Access: <1 Password Set Date/Time: 01/29/2007 09:45:12 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Policy Privilege: Storage Privilege: BACKUPPOOL Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/29/2007 09:45:12 Registering Administrator: ADMIN Managing profile:Password Expiration Period: Email Address:

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: storageadmin

Enter your password: *****

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=2ANR2035E UPDATE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command.ANS8001I Return code 9.

tsm: SERVER1>define stgpool disk testpoolANR2035E DEFINE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command.ANS8001I Return code 9.

tsm: SERVER1>delete stgpool archivepoolANR2035E DELETE STGPOOL: Administrator STORAGEADMIN is not authorized to issue this command.ANS8001I Return code 9.

Chapter 7. Server administration 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=operatorANR2082I Operator privilege granted to administrator OPERATORtsm: SERVER1>q admin operator f=dSession 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: OPERATOR Last Access Date/Time: 01/29/2007 09:58:42 Days Since Last Access: <1 Password Set Date/Time: 01/29/2007 09:58:42 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Yes Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/29/2007 09:58:42 Registering Administrator: ADMIN Managing profile:Password Expiration Period: Email Address:

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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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 ownerAn 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 node’s 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 client’s domain has client owner privilege by default.

Client accessClient access privilege restricts somewhat the capabilities provided with the standard client owner privileges:

Chapter 7. Server administration 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 client’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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_CONSOLEThis 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_CENTERThe 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.

Chapter 7. Server administration 169

Example 7-9 ADMIN_CENTER ID details

Tivoli Storage Manager: SERVER1>q admin admin_center f=d

Administrator Name: ADMIN_CENTER Last Access Date/Time: 01/26/2007 14:02:57 Days Since Last Access: 3 Password Set Date/Time: (?) Days Since Password Set: (?) Invalid Sign-on Count: 0 Locked?: Yes Contact: Administration Center System Privilege: Policy Privilege: Storage Privilege: Analyst Privilege: Operator Privilege: Client Access Privilege: Client Owner Privilege: Registration Date/Time: 01/26/2007 14:02:57 Registering Administrator: SERVER_CONSOLE Managing profile:Password Expiration Period: Email Address:

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.

QUERYAUTHThe 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.

REQSYSAUTHOUTFILEThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 7. Server administration 171

7.3 A typical implementation of administrator roles

This section shows how administrator roles might be assigned in a typical mid-sized implementation.

ScenarioThe 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.

OperatorsThe 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 supervisorThe 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 productsThe 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 Company’s Tivoli Storage Manager administrator has also split the storage pools so that the data from the database application is stored in each DBA’s 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 administratorsThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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.

COLNAME REMARKS TYPENAME LENGTH------------------ ------------------ ------------------ -----------DATE_TIME Date/Time TIMESTAMP 0MSGNO Message number INTEGER 0SEVERITY Message severity ENUMERATED(SEVERI- 1 TY_TYPE)MESSAGE Message VARCHAR 1600ORIGINATOR Originator VARCHAR 20NODENAME Node Name VARCHAR 64OWNERNAME Owner Name VARCHAR 64SCHEDNAME Schedule Name VARCHAR 30DOMAINNAME Policy Domain Name VARCHAR 30SESSID Sess Number INTEGER 0SERVERNAME Server Name VARCHAR 64SESSION SESSION INTEGER 0PROCESS PROCESS INTEGER 0

Chapter 7. Server administration 173

Example 7-10 Tivoli Storage Manager SQL query for activity log records

set sqldisplaymode wideselect -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:26Originator: 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 IBM Tivoli Storage Manager: Building a Secure Environment

The fields within the summary table are shown in Figure 7-4.

Figure 7-4 Server summary table fields

COLNAME REMARKS TYPENAME LENGTH------------------ ------------------ ------------------ -----------START_TIME Start time TIMESTAMP 0END_TIME End Time TIMESTAMP 0ACTIVITY Process or Session VARCHAR 64 Activity NameNUMBER Process or Session INTEGER 0 NumberENTITY Associated user or VARCHAR 64 storage pool(s) associated with the activityCOMMMETH Communications VARCHAR 8 Method UsedADDRESS Communications VARCHAR 64 AddressSCHEDULE_NAME Schedule Name VARCHAR 30EXAMINED Number of objects DECIMAL 18 (files and/or directories) examined by the process/sessionAFFECTED Number of objects DECIMAL 18 affected (moved, copied or deleted) by the process/sessionFAILED Number of objects DECIMAL 18 that failed in the process/sessionBYTES Bytes processed DECIMAL 18IDLE Seconds that the INTEGER 0 session/process was idleMEDIAW Seconds that the INTEGER 0 session/process was waiting for access to mediaPROCESSES Number of INTEGER 0 processes used for processSUCCESSFUL Successful ? ENUMERATED(YESNO_- 9 TYPE)VOLUME_NAME Volume Name VARCHAR 64DRIVE_NAME Drive Name VARCHAR 64LIBRARY_NAME Library Name VARCHAR 64LAST_USE Last Use VARCHAR 64COMM_WAIT Current comm wait INTEGER 0 time in secondsNUM_OFFSITE_VOLS Number of offsite INTEGER 0 volumes processed

Chapter 7. Server administration 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,511070,130,1,94,0,4,0,0,0,0,4,0

The content of each field is explained in the Tivoli Storage Manager Administrator’s 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 Contents1 Product version2 Product sublevel3 Product name, ‘ADSM’,4 Date of accounting (mm/dd/yyyy)5 Time of accounting (hh:mm:ss)6 Node name of Tivoli Storage Manager client7 Client owner name (UNIX)8 Client Platform9 Authentication method used10 Communication method used for the session11 Normal server termination indicator (Normal=X'01', Abnormal=X'00')12 Number of archive store transactions requested during the session13 Amount of archived files, in kilobytes, sent by the client to the server14 Number of archive retrieve transactions requested during the session15 Amount of space, in kilobytes, retrieved by archived objects16 Number of backup store transactions requested during the session17 Amount of backup files, in kilobytes, sent by the client to the server18 Number of backup retrieve transactions requested during the session19 Amount of space, in kilobytes, retrieved by backed up objects20 Amount of data, in kilobytes, communicated between the client node and the server during the session21 Duration of the session, in seconds22 Amount of idle wait time during the session, in seconds23 Amount of communications wait time during the session, in seconds24 Amount of media wait time during the session, in seconds

176 IBM Tivoli Storage Manager: Building a Secure Environment

25 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.26 Number of space-managed store transactions requested during the session27 Amount of space-managed data, in kilobytes, sent by the client to the server28 Number of space-managed retrieve transactions requested during the session29 Amount of space, in kilobytes, retrieved by space-managed objects30 Product release31 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)

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.

Note: Setting up or modifying event receivers requires Tivoli Storage Manager system authority.

Chapter 7. Server administration 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 LinuxIn 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 IBM Tivoli Storage Manager: Building a Secure Environment

– 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 >>\

Chapter 7. Server administration 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 ADMIN issued command: QUERY PROCESS ~20070208093937 ADMIN issued command: ROLLBACK ~20070208094019 ADMIN issued command: QUERY VOLUME ~20070208094027 ADMIN issued command: DELETE VOLUME /stg1/TSM/bkup0.dsm ~20070208094030 ADMIN issued command: DELETE VOLUME /stg1/TSM/bkup0.dsm ~20070208094030 ADMIN issued command: ROLLBACK ~

Using the NT Event Log event receiver on WindowsIn 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 consoleAll server events are ENABLED for the CONSOLE receiver.

tsm: TSM01>q enabled actlogAll 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 platform’s Tivoli Storage Manager Administrator’s Guide and Tivoli Storage Manager Administrator’s Reference.

Chapter 7. Server administration 181

SET AUTHENTICATIONThis 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.

SET MINPWLENGTHThis 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 PASSEXPThe 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 REGISTRATIONClient registration can be either open or closed.

OpenWith 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.

ClosedWith closed registration, the client’s 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.

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.

182 IBM Tivoli Storage Manager: Building a Secure Environment

SET SERVERNAMEAlthough 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 SERVERPASSWORDServer-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 NODEWhen 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

ForcepwresetIf 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 administrator’s own password. The default for this command is NO.

BackdelSetting 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.

ArchdelThis 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.

ContactThe contact option is not required but is nonetheless a good option to include. At a minimum, the responsible administrator’s name and possibly phone number need to be included.

Chapter 7. Server administration 183

URLThe 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.

EmailaddressThis 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 SESSIONSThese 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 SESSIONCANCEL 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 modesTivoli 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 Administrator’s Guide for each platform.

PollingPolling 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.

PromptedThis 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 Administrator’s Guide and Tivoli Storage Manager Administrator’s 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.

Chapter 7. Server administration 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 client’s 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 SRVPREPOSTSNAPDISABLEDThese 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 client’s 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.

SCHEDCMDDISABLEDSCHEDCMDDISABLED 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.

SCHEDRESTRETRDISABLEDWhen 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.

ReplaceIf 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 TCPip TCPPort 1500 TCPClientPort 1501 TCPServeraddress 192.168.99.128 managedservices webclient schedmode prompted passwordaccess 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 schedIBM Tivoli Storage ManagerCommand 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: NENYAANS1382E Server does not allow client-initiated connections for this node.

Chapter 7. Server administration 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 Session 15 started for node NENYA (Linux86) (Tcp/Ip localhost(1290)).ANR0476W Session 15 for node NENYA (Linux86) refused - node is not allowed to initiate sessions.ANR0403I 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 servername MAINset serverpassword mainset serverhladdress 192.168.99.231set serverlladdress 1500

Example 7-22 Setup for server REMOTE

set servername REMOTEset serverpassword remoteset serverhladdress 192.168.204.128set 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

Chapter 7. Server administration 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: 4Data (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 00 3a 1e a5 66 15 07 d7 02 0b 0e 15 2e 00 00 00 .:..f...........0010 06 00 06 00 07 00 05 00 04 00 00 00 00 f7 7b bf ..............{.0020 7e f6 00 00 00 00 00 00 00 00 00 00 02 52 45 4d ~............REM0030 4f 54 45 57 69 6e 64 6f 77 73 OTEWindows

Server LOCAL issues the information in Example 7-25.

Example 7-25 Issued from LOCAL

Data (105 bytes)

0000 00 69 1a a5 69 00 00 00 0a 0e 04 00 0a 00 04 00 .i..i...........0010 0e 00 04 01 00 12 00 2d 18 19 ff 00 00 00 60 00 .......-......`.0020 00 00 00 00 00 00 00 00 00 00 4c 69 6e 75 78 2f ..........Linux/0030 69 33 38 36 4d 41 49 4e 4d 41 49 4e 2f 6f 70 74 i386MAINMAIN/opt0040 2f 74 69 76 6f 6c 69 2f 74 73 6d 2f 63 6c 69 65 /tivoli/tsm/clie0050 6e 74 2f 62 61 2f 62 69 6e 2f 64 73 6d 63 6c 69 nt/ba/bin/dsmcli0060 65 6e 74 76 33 2e 63 61 74 entv3.cat

And server REMOTE responds (Example 7-26).

Example 7-26 Response from REMOTE

Data (28 bytes)

0000 00 1c 1c a5 00 00 00 0a 00 01 03 03 01 02 02 01 ................0010 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 00 38 16 a5 00 00 00 30 1e 48 9f 41 fe 02 cb 5c .8.....0.H.A...\0010 32 7d 58 3b ef 1f 03 c8 ee 5b e6 b9 2e 1f 2f a2 2}X;.....[..../.0020 9e 5c 32 de 95 29 49 74 31 de a4 a7 6e ff 1a 17 .\2..)It1...n...

190 IBM Tivoli Storage Manager: Building a Secure Environment

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 sessANR1699I 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 Comm. Sess Wait Bytes Bytes Sess Platform Client NameNumber Method State Time Sent Recvd Type------ ------ ------ ------ ------- ------- ----- -------- -------------------- 14 Tcp/Ip Run 0 S 13.0 K 107 Admin WinNT REPORT 36 Tcp/Ip IdleW 2.6 M 11.3 K 198 Admin WinNT SCS 38 Tcp/Ip Run 0 S 154 233 Admin Linux/i- ADMIN 386ANR1688I 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 sessANR1699I 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 Administrator’s Guide and Tivoli Storage Manager Administrator’s 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.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

0000 00 04 12 a5 00 e0 92 a5 00 00 22 00 04 00 26 00 .........."...&.0010 0a 00 30 00 08 00 38 00 0b 01 00 00 00 19 00 19 ..0...8.........0020 00 09 00 43 00 08 00 4b 00 08 00 53 00 04 00 57 ...C...K...S...W0030 00 03 00 5a 00 33 00 00 00 00 1f 40 00 00 07 d7 ...Z.3.....@....0040 02 0c 0d 2a 05 02 02 41 44 53 41 44 53 4d 2f 52 ...*...ADSADSM/R0050 45 4d 4f 54 45 2e 42 46 53 2e 31 37 31 33 31 36 EMOTE.BFS.1713160060 35 31 32 42 46 53 2e 4f 42 4a 2e 31 4d 41 49 4e 512BFS.OBJ.1MAIN0070 4c 69 6e 75 78 2f 69 33 38 36 53 54 41 4e 44 41 Linux/i386STANDA0080 52 44 41 44 53 4d 2e 53 45 52 56 45 52 53 54 41 RDADSM.SERVERSTA0090 4e 44 41 52 44 53 54 41 4e 44 41 52 44 4d 41 49 NDARDSTANDARDMAI00a0 4e 20 20 20 01 00 00 00 00 00 00 00 00 91 02 00 N ............00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 ................00c0 d7 02 0c 0d 2a 05 ff ff 00 00 00 00 00 00 00 00 ....*...........00d0 06 52 45 4d 4f 54 45 00 00 00 00 00 00 00 00 00 .REMOTE.........00e0 00 00 00 00 01 99 07 a5 52 46 45 53 02 00 20 00 ........RFES.. .00f0 01 00 00 00 55 01 00 00 00 00 00 00 02 c4 00 00 ....U...........0100 00 00 00 00 00 00 00 00 01 1e c5 a5 02 00 00 00 ................0110 05 00 05 00 07 00 0c 00 08 00 14 00 01 01 00 15 ................0120 00 05 00 1a 00 0d 00 27 00 08 00 2f 00 07 00 36 .......'.../...60130 00 04 00 3a 00 7c 00 00 00 00 00 00 04 00 07 d7 ...:.|..........0140 02 0c 0c 16 2e 00 01 00 00 00 00 00 00 00 00 00 ................0150 00 00 00 b6 00 00 00 00 00 00 00 00 00 00 00 00 ................0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0170 4e 45 4e 59 41 4c 69 6e 75 78 38 36 53 54 41 4e NENYALinux86STAN0180 44 41 52 44 2f 2f 74 6d 70 2f 70 61 73 73 77 6f DARD//tmp/passwo0190 72 64 73 2e 74 78 74 53 54 41 4e 44 41 52 44 44 rds.txtSTANDARDD01a0 45 46 41 55 4c 54 72 6f 6f 74 07 09 16 00 66 0c EFAULTroot....f.01b0 00 01 00 00 00 00 00 00 00 23 02 49 00 00 0f 00 .........#.I....01c0 07 00 03 85 58 00 00 81 a4 00 00 00 00 00 00 00 ....X...........01d0 00 45 c9 04 95 45 c9 04 95 00 00 00 00 45 d0 cb .E...E.......E..01e0 c6 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ................01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0220 00 00 00 00 00 00 80 03 00 00 0f 00 00 00 00 00 ................0230 04 02 00 00 00 00 00 00 00 23 4d 79 20 73 75 70 .........#My sup0240 65 72 73 65 63 72 65 74 20 70 61 73 73 77 6f 72 ersecret passwor0250 64 20 69 73 20 61 62 63 31 32 33 34 0a 52 46 45 d is abc1234.RFE0260 53 02 00 20 00 02 00 00 00 00 00 00 00 00 00 00 S.. ............0270 00 02 c4 00 00 00 00 00 00 00 00 00 00 00 06 13 ................0280 a5 01 00 ...

Chapter 7. Server administration 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 Administrator’s Guide and Tivoli Storage Manager Administrator’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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/Ip192.168.204.1(1942)).ANR2017I Administrator ADMIN issued command: DEFINE SUBSCRIPTION adminsserver=mainANR0408I Session 34 started for server MAIN (Linux/i386) (Tcp/Ip) forconfiguration 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) forconfiguration management.ANR3152I Configuration refresh started with configuration manager MAIN.ANR3361I Locally defined administrator REPORT replaced during configurationrefresh processing.ANR3153I Configuration refresh ended successfully with configuration managerMAIN.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.

Chapter 7. Server administration 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 Policy Mgmt Copy Versions Versions Retain RetainDomain Set Name Class Group Data Data Extra OnlyName Name Name Exists Deleted Versions Version--------- --------- --------- --------- -------- -------- -------- -------NEWDOMAIN ACTIVE STANDARD STANDARD 10 1 30 60NEWDOMAIN STANDARD STANDARD STANDARD 10 1 30 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 Policy Mgmt Copy Versions Versions Retain RetainDomain Set Name Class Group Data Data Extra OnlyName Name Name Exists Deleted Versions Version--------- --------- --------- --------- -------- -------- -------- -------NEWDOMAIN ACTIVE STANDARD STANDARD 5 1 30 60NEWDOMAIN STANDARD STANDARD STANDARD 5 1 30 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=newdomainANR3045I 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 domainsANR3030I DEFINE SUBSCRIPTION: Subscription defined for profile DOMAINS.

196 IBM Tivoli Storage Manager: Building a Secure Environment

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 domainsANR0408I Session 6 started for server MAIN (Linux/i386) (Tcp/Ip) forconfiguration 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) forconfiguration management.ANR3152I Configuration refresh started with configuration manager MAIN.ANR3352I Locally defined domain NEWDOMAIN replaced during configuration refreshprocessing.ANR3153I Configuration refresh ended successfully with configuration managerMAIN.

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 Policy Mgmt Copy Versions Versions Retain RetainDomain Set Name Class Group Data Data Extra OnlyName Name Name Exists Deleted Versions Version--------- --------- --------- --------- -------- -------- -------- -------NEWDOMAIN STANDARD STANDARD STANDARD 5 1 30 60

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.

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.

Chapter 7. Server administration 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 node’s 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 encryptionWhen 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 encryptionIf 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.

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,

Note: In order to read the encrypted tape, the correct key must be available from a key manager.

198 IBM Tivoli Storage Manager: Building a Secure Environment

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 Administrator’s 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 serverFor 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.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 serverOperational 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.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 user’s 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.

Chapter 7. Server administration 207

Example 7-39 Captured log-in information from browser

No. Time Source Destination Protocol Info 8 0.044980 192.168.204.128 192.168.99.231 TCP 1049 > 8421 [PSH, ACK] Seq=1314021294 Ack=2645440192 Win=64512 Len=141

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: 141Data (141 bytes)

0000 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap0010 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 77 77 2d plication/x-www-0020 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 65 64 0d form-urlencoded.0030 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:0040 20 37 30 0d 0a 0d 0a 77 70 73 2e 70 6f 72 74 6c 70....wps.portl0050 65 74 73 2e 75 73 65 72 69 64 3d 69 73 63 61 64 ets.userid=iscad0060 6d 69 6e 26 70 61 73 73 77 6f 72 64 3d 69 73 63 min&password=isc0070 61 64 6d 69 6e 26 50 43 5f 37 5f 30 5f 33 47 5f admin&PC_7_0_3G_0080 5f 6c 6f 67 69 6e 3d 4c 6f 67 2b 69 6e _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 55 47 4c 30 35 30 30 4f 34 5f 61 64 6d 69 6e 6e UGL0500O4_adminn00e0 61 6d 65 3d 6c 64 69 65 74 65 72 26 50 43 5f 36 ame=admin12&PC_600f0 74 30 30 30 30 30 30 53 46 30 30 30 34 30 56 55 t000000SF00040VU0100 33 32 55 47 4c 30 35 30 30 4f 34 5f 70 61 73 73 32UGL0500O4_pass0110 77 6f 72 64 3d 6c 61 64 37 30 32 34 26 50 43 5f word=abc1234&PC_0120 36 74 30 30 30 30 30 30 53 46 30 30 30 34 30 56 6t000000SF00040V0130 55 33 32 55 47 4c 30 35 30 30 4f 34 5f 70 61 73 U32UGL0500O4_pas0140 73 77 6f 72 64 76 65 72 69 66 69 65 72 3d 6c 61 swordverifier=ab0150 64 37 30 32 34 26 50 43 5f 36 74 30 30 30 30 30 c1234&PC_6t000000160 30 53 46 30 30 30 34 30 56 55 33 32 55 47 4c 30 0SF00040VU32UGL00170 35 30 30 4f 34 5f 73 65 72 76 65 72 61 64 64 72 500O4_serveraddr0180 65 73 73 3d 31 39 32 2e 31 36 38 2e 39 39 2e 32 ess=192.168.99.20190 33 31 26 50 43 5f 36 74 30 30 30 30 30 30 53 46 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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 7-41 ISC login to Tivoli Storage Manager server

0000 00 4a 1a a5 67 00 00 00 06 07 01 00 06 00 05 00 .J..g...........0010 0b 00 05 00 00 10 00 10 2a 3f 10 24 59 08 00 00 ........*?.$Y...0020 00 00 00 00 00 00 00 00 00 00 44 53 4d 41 50 49 ..........DSMAPI0030 41 44 4d 49 4e 41 44 4d 49 4e 18 03 01 01 03 03 ADMINADMIN......0040 2c 2e 01 01 01 00 00 00 00 00 ,.........

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 00 f7 f0 a5 00 00 00 ed 00 00 1a 58 8f ec f6 20 ...........X... 0010 a5 63 b5 74 ef d7 5c 09 28 00 86 c1 40 39 e4 f7 .c.t..\.(...@9..0020 4f 98 9f 09 10 3d 6f ab 87 30 7b a9 b5 e3 cf 36 O....=o..0{....60030 7a 7c b2 68 e9 f2 84 f5 73 89 5b 9f ef 98 a5 a7 z|.h....s.[.....0040 e6 d9 5f ab b4 8a 79 7c 92 1b 71 65 1c 13 3b 1b .._...y|..qe..;.0050 e0 0a 06 ec c5 fa 63 c8 b1 9b dd 9c 53 7c 5f 38 ......c.....S|_80060 a2 09 ef 9a 57 79 48 89 1e ef 96 df 00 ca b7 b1 ....WyH.........0070 6f 20 5b 27 36 6e a1 6f 6f a3 1a 48 66 63 e3 ba o ['6n.oo..Hfc..0080 cf fd 51 6c b5 a8 07 dc df 86 5b df 61 f8 ec f6 ..Ql......[.a...0090 2b 5b 70 ca dd 44 6e 54 a5 1f 70 4c d0 61 fd f8 +[p..DnT..pL.a..00a0 26 8d ba 2f 64 a9 7c 2d 1a 5e 77 d0 b4 af 2a 96 &../d.|-.^w...*.00b0 d2 9b 40 4f 3a 26 f5 e9 20 63 82 c6 88 fc 67 db ..@O:&.. c....g.00c0 4b 66 3c b7 c0 cd 25 e1 42 f7 06 59 b1 dd 91 f6 Kf<...%.B..Y....00d0 a7 d5 c3 54 7a 48 de 1b a9 1d 5d be d5 b6 8b 88 ...TzH....].....00e0 38 ed 65 b9 b3 ca 43 8a 06 e4 60 95 82 60 85 99 8.e...C...`..`..00f0 3b cc d3 b3 65 78 5a ;...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 01 23 f1 a5 03 07 d7 02 0f 09 1e 19 07 e1 02 01 .#..............0010 12 41 4e 52 32 30 31 37 49 20 41 64 6d 69 6e 69 .ANR2017I Admini0020 73 74 72 61 74 6f 72 20 41 44 4d 49 4e 20 69 73 strator ADMIN is0030 73 75 65 64 20 63 6f 6d 6d 61 6e 64 3a 20 55 50 sued command: UP0040 44 41 54 45 20 4e 4f 44 45 20 4e 45 4e 59 41 20 DATE NODE NENYA 0050 3f 2a 2a 2a 3f 20 46 4f 52 43 45 50 57 52 45 53 ?***? FORCEPWRES0060 45 54 3d 4e 4f 20 50 41 53 53 45 58 50 3d 30 20 ET=NO PASSEXP=0 0070 43 4c 4f 50 54 53 45 54 3d 20 43 4f 4e 54 41 43 CLOPTSET= CONTAC0080 54 3d 20 55 52 4c 3d 68 74 74 70 3a 2f 2f 31 39 T= URL=http://190090 32 2e 31 36 38 2e 39 39 2e 32 33 31 3a 31 35 38 2.168.99.231:15800a0 31 20 56 41 4c 49 44 41 54 45 50 52 4f 54 4f 43 1 VALIDATEPROTOC00b0 4f 4c 3d 4e 4f 20 53 45 53 53 49 4f 4e 49 4e 49 OL=NO SESSIONINI00c0 54 49 41 54 49 4f 4e 3d 43 4c 49 45 4e 54 4f 52 TIATION=CLIENTOR00d0 53 45 52 56 45 52 20 48 4c 41 44 44 52 45 53 53 SERVER HLADDRESS00e0 3d 31 39 32 2e 31 36 38 2e 39 39 2e 32 33 31 20 =192.168.99.231 00f0 4c 4c 41 44 44 52 45 53 53 3d 31 35 30 31 20 44 LLADDRESS=1501 D0100 41 54 41 57 52 49 54 45 50 41 54 48 3d 41 4e 59 ATAWRITEPATH=ANY0110 20 44 41 54 41 52 45 41 44 50 41 54 48 3d 41 4e DATAREADPATH=AN0120 59 20 7e Y ~

Chapter 7. Server administration 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 Administrator’s 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

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.

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.

210 IBM Tivoli Storage Manager: Building a Secure Environment

Figure 7-23 ikeyman utility

Create and populate the server key file and trust fileThis 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 certificateThe 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.

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.

Note: This is the server key file.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 certificateNow, to extract the public certificate:

1. Click Extract Certificate as shown in Figure 7-29 on page 214.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Note: This is the server trust file.

Chapter 7. Server administration 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 fileThis section shows how to create the client key file, the client certificate, and the client trust file.

Create the client key fileThe steps are:

1. From the main menu, select Key Database File → New. See Figure 7-36 on page 217.

216 IBM Tivoli Storage Manager: Building a Secure Environment

Figure 7-36 Creating another key file for the client

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.

Note: This is the client key file.

Chapter 7. Server administration 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 certificate1. From the main menu shown in Figure 7-41, click Extract Certificate.

Chapter 7. Server administration 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 fileCreate 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

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.

Note: This is the client trust file.

220 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 7. Server administration 221

Example 7-44 Sample JACL script

# new SSL entry in the SSL repertoire# setting the security objectset security_root [$AdminConfig list Security]# setting the variables for the entryset 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 lineset 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 objectset ssl_entry [list [list alias $ssl_alias] [list setting $ssl_def] ]# remove existing dummy SSL entryset 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 entryset 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 = falseredirect.logout.ssl = false

3. Change the two lines in step 2 to:

redirect.login.ssl = trueredirect.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/deployments/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>

Chapter 7. Server administration 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/DummyClientKeyFile.jks

� com.ibm.ssl.keyStorePassword={xor}CDo9Hgw\=

� com.ibm.ssl.trustStore=/opt/IBM/ISC6011/AppServer/profiles/default/etc/DummyClientTrustFile.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 IBM Tivoli Storage Manager: Building a Secure Environment

/opt/IBM/ISC6011/AppServer/profiles/default/logs/ISC_Portal/startServer.logADMU0128I: Starting tool with the default profileADMU3100I: Reading configuration for server: ISC_PortalADMU3200I: 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

Chapter 7. Server administration 225

226 IBM Tivoli Storage Manager: Building a Secure Environment

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.

8

© Copyright IBM Corp. 2007. All rights reserved. 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

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.

Note: This section is a brief overview only. See “Chapter 10. Managing Storage Pools and Volumes” in the IBM Tivoli Storage Manager Administrator’s 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.

228 IBM Tivoli Storage Manager: Building a Secure Environment

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.txtthis 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.

Example 8-3 Content of a DISK storage pool volume

SERVERWinNTSTANDARD\\server\d$ÿþÿÿÿþ\TESTFILES\ÿþÿÿÿþTEST.TXTÿþÿÿÿþSTANDARDDEFAULT • †I â‹ ¤ ÇDª‡øq ÇDªÆÝÈPÇDªÆÝÈP©d6> D ù¿ÿÿ~ ) ¤ „ 0 L ŠZA`¨7ÖeÀê2ë ŠZA`¨7ÖeÀê2 X $ ÿ ŠZA`¨7ÖeÀê2ë ÿ ÿ †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.

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.

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 IBM Tivoli Storage Manager: Building a Secure Environment

Test one: Simple text filesIn 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): 1Enter Destination File: /test/4.txtEnter 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 errorResidual count: 1048576

Error Sense Data, Length 36

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0000 - F000 0800 1000 001C 0000 0000 0005 0000 [ð...............] 0010 - 2074 000C 0000 0000 0000 0000 0000 0000 [ t..............] 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.

Chapter 8. Storage pool considerations 231

Example 8-6 First file, which was probably tape header

åÖÓñÂÁèððø@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ÈÄÙñÁÄâÔKÂÆâKåðððññ÷Á@@@@@@ðððñðððñ@@@@@@ððñóñó@ùùóöõðððððððÁÄâÔ@@@@@@@@@@@@@@@@ÈÄÙòäòöòñôððððð@ð@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

� 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$ÿþÿÿÿþ\ÿþÿÿÿþTESTFILESÿþÿÿÿþSTANDARDIMAGE ‘ J ÖÓ¼ 0 0 ̀ ÇNÔàYraÇNïDŸ#ÍÇNáþ+p‰©r6L D ä0 0 ` μ1zÄl›(¼0ô{ q μ1zÄl›(¼0ô{ „ L ÿ ÿ ¿ ! fÅ¥ " 5 E M T T ª ×3 þ SERVERWinNTFILE\\SERVER\d$ÿþÿÿÿþ\TESTFILES\ÿþÿÿÿþTEST.TXTÿþÿÿÿþSTANDARDDEFAULT ‘ †I ÃDç 0 0 ̀ ÇNÔå½ãïÇNÞñ6ÞÊÇNÔê朽6L D ä0 0 ` μ1zÄl›(¼0ô{ q μ1zÄl›(¼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.TXTÿþÿÿÿþSTANDARDDEFAULT ‘ †I ÃDç 0 0 ̀ ÇNÔï«n ÇNáú*=]ÇNÔê朽6L D õu„sYÀðª″þD ‰Â0r=8ôF –ƒ›Ez″<`%˜kH˜ 96ËØ )UíÜÆÃN„!'hiPå; ‰“Š9‘wȼÆ2Ħä=)fÎã…^—nÂê,©<eºàÏï9@W‰]…6-¾->}EûIÁ‰#+“Æ ÚÕ&+VõmWngó$cÑßDFòÎ}æ-^ }FJ¦ÑŒÐ¯xZ`μ+ÌÕíìO¬!)þ•(…ŸéÉñºV|[;ç‡X?2BÏ’U¬kÝ|-—P*"é©!•ÿö0›ú nã§μÿÅÑ(h9÷ë&ľ?îøJ`bTÚr(ˆ¶zTUŸ\±/¬Ïúú8kÖƒá¤À»S^çíÕë•”üJ~¯Ð/¤âü¥+,‰[ÈŠÖÊ*-N×æ÷·¸É¦˜GŒ Ÿ•~J;7Y%ÚÅá\MuÙɦ¯ú\f]B<|vW%ËÚüúI Ð(ðóÐMí__»6ÉrÅ¥ " 5 Q Y ` ` ª ×3 SERVERWinNTFILE\\SERVER\d$ÿþÿÿÿþ\TESTFILES\ÿþÿÿÿþTEST_COMPRESSION.TXTÿþÿÿÿþSTANDARDDEFAULT ‘ ~I ÃDç 0 0 ̀ ÇNÔî÷áÇNï·ÂÉÇNï·Âɶ96L D ñÙÌ H 9CÁ 9,H‘b T XË@=ÄØlBÁ½= â@„ PÁ‰b,¨‘£G"IšÜ@À@ˆÅ¤Ó'

232 IBM Tivoli Storage Manager: Building a Secure Environment

BÀ à_ zfA„Ï:… %Á”2ý`BÔ«_©q•¥Ë¡1ÑDà‡š4s@à″2sè¸h ÀîÞ½}ÿ\øn^Ä~&løqÞÄ’WÖ{9òbÊŽ9óõ< ñáΊKo†œZshÖAŸÝZ¶eÚ±MßÆüY·hÞª_£Î½zxïâ¸O|6p×ÎICß-Ýöïê¾a+^;»ñæÔ»#n];øëâ—“÷Î|:zâê±—?=wø÷·‡Ç¿_ÿ{ÿæ `yßX í!¸Þ|öõwÞ ì-Xÿ=x`„ôåga‚6X¡2H!„"xa‰J¨!ˆ*:Èb†.*ã‡2zHâ„&†ˆcŠ3Þ¸b•#ž¸ã‹6ùc‡Aêx$ŠD&Ù"•Hæø¤1FÉc‘JVÉ$Röh¤–Cry¥“^få–V6Ù%–S~yf˜iŠ©æ˜k’Éfm¶qÅ¥ " 5 P X _ _ ª ×3 SERVERWinNTFILE\\SERVER\d$ÿþÿÿÿþ\TESTFILES\ÿþÿÿÿþTEST_ENCRYPTION.TXTÿþÿÿÿþSTANDARDDEFAULT ‘ †I ÃDç 0 0 ̀ ÇNÔîCk″ÇNïNeÇNÔê朽6L D õu„sYÀðª″þD ‰Â0r=8ôF –ƒ›Ez″<`%˜kH˜ 96ËØ )UíÜÆÃN„!'hiPå; ‰“Š9‘wȼÆ2Ħä=)fÎã…^—nÂê,©<eºàÏï9@W‰]…6-¾->}EûIÁ‰#+“Æ ÚÕ&+VõmWngó$cÑßDFòÎ}æ-^ }FJ¦ÑŒÐ¯xZ`μ+ÌÕíìO¬!)þ•(…ŸéÉñºV|[;ç‡X?2BÏ’U¬kÝ|-—P*"é©!•ÿö0›ú nã§μÿÅÑ(h9÷ë&ľ?îøJ`bTÚr(ˆ¶zTUŸ\±/¬Ïúú8kÖƒá¤À»S^çíÕë•”üJ~¯Ð/¤âü¥+,‰[ÈŠÖÊ*-N×æ÷·¸É¦˜GŒ Ÿ•~J;7Y%ÚÅá\MuÙɦ¯ú\f]B<|vW%ËÚüúI Ð(ðóÐMí__»6ÉSEFR

� 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

ÅÖÆñÁÄâÔKÂÆâKåðððññ÷Á@@@@@@ðððñðððñ@@@@@@ððñóñó@ùùóöõðððððõðÁÄâÔ@@@@@@@@@@@@@@@@ÅÖÆòäòöòñôððððð@ð@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

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_00cpio: End of tape, insert the next tape.Enter the device or file name when ready to continue.

Test two: Application format filesOur 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.

Chapter 8. Storage pool considerations 233

Figure 8-1 Word.doc

Example 8-10 A part of word.doc in HEX/binary

00000a00:54 68 69 73 20 69 73 20 62 6f 6c 64 2e 0d 54 68 This is bold..Th00000a10:69 73 20 69 73 20 75 6e 64 65 72 6c 69 6e 65 64 is is underlined00000a20:2e 0d 54 61 62 6c 65 3a 0d 76 65 72 79 07 69 6d ..Table:.very.im00000a30:70 6f 72 74 61 6e 64 07 64 61 74 61 07 31 07 32 portant.data.1.200000a40:07 07 33 07 34 07 35 07 36 07 37 07 07 0d 45 6e ..3.4.5.6.7...En00000a50:64 20 6f 66 20 64 6f 63 75 6d 65 6e 74 2e 0d 00 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 cf 11 e0 a1 b1 1a e1 00 00 00 00 00 00 00 00 ÐÏ.ࡱ.á........00000010:00 00 00 00 00 00 00 00 3e 00 03 00 fe ff 09 00 ........>...þÿ..00000020:06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................00000030:26 00 00 00 00 00 00 00 00 10 00 00 28 00 00 00 &...........(...00000040:01 00 00 00 fe ff ff ff 00 00 00 00 25 00 00 00 ....þÿÿÿ....%...00000050:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Example 8-12 End of a Word document in HEX

00005420:4d 69 63 72 6f 73 6f 66 74 20 4f 66 66 69 63 65 Microsoft Office00005430:20 57 6f 72 64 2d 44 6f 6b 75 6d 65 6e 74 00 0a Word-Dokument..00005440:00 00 00 4d 53 57 6f 72 64 44 6f 63 00 10 00 00 ...MSWordDoc....00005450:00 57 6f 72 64 2e 44 6f 63 75 6d 65 6e 74 2e 38 .Word.Document.800005460:00 f4 39 b2 71 00 00 00 00 00 00 00 00 00 00 .ô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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

ConclusionsObviously, 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 compressionWe 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 encryptionIf 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 permissionsOf 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.

Chapter 8. Storage pool considerations 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.TXTÿþÿÿÿþSTANDARDDEFAULT • †I eÀ›Ð ¼ ÇDª‡øq ÇJÙðž ÇDªÆÝÈP©d6> D ‚ &GöÙ*zèöº?¸-S‹ÁPZŒtnžz´fQlæÎÍFâÆP„iþ…a~¢}}û{ a/7›ò‹6OÇR <¨9r’à©}ŒÇ:|/u[Ør…y'§mžA$åM ÎO7Ü″éR½Ý"Jª¥†5Ç&rø,&{ò“ôŸçw< •‹g‚þÓ″ÔjÙ"nbuØÙ¶âÞY$VÑC—å“eøòŸRÞ¼êkÁ>ÌøZd=Òéù6:41‰÷Æž0ÅåÞ„>xkÖÍýh‰DÓáT¢×·›×Tʈjþë3ïòÉ1Öw78>I″cÇ~2¦]«So]ÉÙ(—]ž+92ƒü7ÜHš5ž:\ÇnÛŠÍèCj½†q9 gÙl8‚hðïlà#"ϼBwø<IÑÛž[ôèX(àmFÂð2Î8[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 IBM Tivoli Storage Manager: Building a Secure Environment

Example 8-15 Using the find command on a file name

D:\tsmdata\server1>find "TEST.TXT" disk1.dsm

---------- DISK1.DSMSERVERWinNTSTANDARD\\byzzkt\d$? ¦? ¦\TESTFILES\? ¦? ¦TEST.TXT? ¦? ¦STANDARDDEFAULT ?

D:\tsmdata\server1>

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

Chapter 8. Storage pool considerations 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 data’s 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.

Figure 8-2 How data shredding works

A test scenario without shreddingWe 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.

a bab

a c

b

Shreddable Storage Pool

b b

a c

Database

Database references to object “a”

a bab

a c

b

Shreddable Storage Pool

b b

a c

Database

Database references deleted and object

“a” overwritten

Object “a”deleted/moved

238 IBM Tivoli Storage Manager: Building a Secure Environment

Example 8-16 Deleting all file spaces

tsm: TSM01>del files SERVER *ANR2238W This command will result in the deletion of all inventory referencesto 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)) yANS8003I Process number 10 started.

tsm: TSM01>q filesANR2034E 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.TXTÿþÿÿÿþSTANDARDDEFAULT • †I â‹ ¤ ÇDª‡øq ÇDªÆÝÈPÇDªÆÝÈP©d6> D ù¿ÿÿ~ ) ¤ „ 0 L ŠZA`¨7ÖeÀê2ë ŠZA`¨7ÖeÀê2 X $ ÿ ŠZA`¨7ÖeÀê2ë ÿ ÿ †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)) yANR2119I 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

Chapter 8. Storage pool considerations 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=3ANR2200I Storage pool SHREDDINGPOOL_2 defined (device class DISK).tsm: TSM01>define stgpool shreddingpool_1 disk shred=1 nextpool=shreddingpool_2ANR2200I 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=10ANR2491I 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 shreddingANR1500I Policy domain SHREDDING defined.

define policyset shredding shreddingANR1510I Policy set SHREDDING defined in policy domain SHREDDING.

tsm: TSM01>define mgmtclass shredding shredding shredding

240 IBM Tivoli Storage Manager: Building a Secure Environment

ANR1520I Management class SHREDDING defined in policy domain SHREDDING, set SHREDDING.

tsm: TSM01>define copygroup shredding shredding shredding type=backup destination=shreddingpool_1ANR1530I 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_2ANR1535I Archive copy group STANDARD defined in policy domain SHREDDING, set SHREDDING, management class SHREDDING.

tsm: TSM01>assign defmgmtclass shredding shredding shreddingANR1538I Default management class set to SHREDDING for policy domain SHREDDING,set SHREDDING.

tsm: TSM01>validate policyset shredding shreddingtsm: TSM01>activate policyset shredding shredding

Do you wish to proceed? (Yes (Y)/No (N)) yANR1514I 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 ^A^A+^A'˜^A,+Ñ^B^D^D^C^O^D^A^S^Z=^GD^DH|^D^G+^S^M4^A-FREDAIXSTANDARD/usr/tivoli/tsm/client/ba/bin/test.txtSTANDARDDEFAULTroot^G ^Vf^L^AM-^@^BI^O^G^APM-^^M-^AñE=»¦E=»¦E=¦ ^DM-^@^C^O^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^A'˜TANDAR^O¦^A^F^O+'^P^F^O=^Am^E^O·^B^E^P^D^B^O^P^NARCHIVEPOOL^E^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 Administrator’s 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.

Chapter 8. Storage pool considerations 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: No Objects Awaiting Shred: 206 Occupied Space (MB): 7Data Left To Shred (MB): 20

Example 8-25 Query shredding status with manual shredding and SHRED DATA is running

tsm: BY-TSM01>query shredstatus format=detailed

Shredding Active: Yes Objects Awaiting Shred: 94 Occupied Space (MB): 4Data Left To Shred (MB): 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 andskipping 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 ^A^A+^A'˜^DM-^[Ñ+i^\+bSf;eF8¦B¦$e^N¦t½"¦Uz.-μM-^P^B9% N¦-kG^^íynM-^G=

@-FM-^Y=M-^Nj(,óM-^P^?b«{=ñM-^B_G¿++¦^EbH(eºíM-^QB·^W^L^N^C/·"M-^Lq$.^LºM-^Z^Bá^PMNpx~G^UM-^S2n¿M-^AV--XZM-^N{,|óºcL«|M-^R"M-^BM-^C7++-M-^Z+bA¦ÑeM-^H^ZgB-^S ^N+(i"pM-^MH.-:[^BM-^GtqNM-^TKM-^YGM-^L)(nIH-+M-^^M-^N^LM-^PHó>(T« 'QM-^B¬^?^X+<M-^Seb°|ÑeTM-^V»+_^N%^Fd"¦ja.^NG~^Be^P+N+GdM-^CM-^HvnjM-^Jn-[QpM-^N^]_=óUM-^MB«¦=LM-^BQaa+-^G+b/P9e-V+B-$¦^N÷óM"^Q+^E.-_M-^Q^B+Ñ7NvChG·^K%n^KM-^D5-bpM-^N«+¦ó8RM-^B«^?-^RM-^Bx^Yi+M-^^6^Gbμ=M-^Re+M-^Z-B^V¦O^NG^KB"Fe=.^Pk^B<=tNºFG±

242 IBM Tivoli Storage Manager: Building a Secure Environment

?~n,!M-^X-Td¬M-^N+?+ó^C9=«M-^@^]}M-^B^_d^[+M-^OaTb^](^De^LísB¦W¦^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=yesANR2588E UPDATE STGPOOL: Storage pool "SHREDDINGPOOL_2" cannot have CACHE setto 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 pool’s 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\server1ANR2203I Device class NON_SHREDDING defined.

tsm: TSM01>def stgp NON_SHREDDING NON_SHREDDING maxscratch=1ANR2200I Storage pool NON_SHREDDING defined (device class NON_SHREDDING).

tsm: BY-TSM01>upd stgp SHREDDINGPOOL_2 next=NON_SHREDDINGANR1309W Shred value zero for storage pool NON_SHREDDING may render deleteddata 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 poolData 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.

Chapter 8. Storage pool considerations 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=yesANR2233W This command will move all of the data stored on volumeD:\TSMDATA\SERVER1\SHRED_1.DSM to other volumes in storage pool DISKPOOL; thedata will be inaccessible to users until the operation completes.

Do you wish to proceed? (Yes (Y)/No (N)) yANS8003I 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=DISKPOOLANR2233W This command will move all of the data stored on volumeD:\TSMDATA\SERVER1\SHRED_1.DSM to other volumes in storage pool DISKPOOL; thedata will be inaccessible to users until the operation completes.

Do you wish to proceed? (Yes (Y)/No (N)) yANR1317E MOVE DATA: Storage pool DISKPOOL is not a shreddable pool.ANS8001I Return code 3.

Deleting data from a shreddable poolWhen 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 setsSensitive 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 server’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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

Chapter 8. Storage pool considerations 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

9

© Copyright IBM Corp. 2007. All rights reserved. 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.

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.

Back-end network allows only communication

from inside the DMZ to the back-end network

Internet orunsecured

networkWeb

serverDatabase

server

Front end

Firewall Firewall

Internet DMZ Intranet

Allowed Allowed

Prohibited

Back-end network

248 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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.

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.

Chapter 9. Deployment in a network secured environment 249

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.

TCPPORTThis 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

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.

Admin (dsmadmc)

Client (dsm, dsmc)

dsm.opt dsmserv.opt

TCPPORTTCPADMINPORT

TCPCLIENTADDRESSTCPCLIENTPORT

ADMINONCLIENTPORT NOTCPPORTTCPADMINPORT

REGISTER NODE SERVER mypassword HLAddress=192.168.99.236LLAddress=1501

TSM Server

15001502

192.168.99.2361501

250 IBM Tivoli Storage Manager: Building a Secure Environment

TCPADMINPORTThis 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.

TCPCLIENTADDRESSThe 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.

TCPCLIENTPORTThe 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 TCPIP TCPPort 1500TCPADMINPort 1502adminonclientport no

The dsm.opt file contains the entries in Example 9-2.

Example 9-2 Sample settings in the dsm.opt

TCPSERVERADDRESS 192.168.99.1TCPPORT 1500TCPCLIENTADDRESS 192.168.99.236TCPCLIENTPORT 1501

Chapter 9. Deployment in a network secured environment 251

SESSIONINITIATION SERVERONLYPASSWORDACCESS GENERATESCHEDMODE 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.

Figure 9-3 Prevent administrative access through a firewall

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

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.

Back-end network allows only communication

from inside the DMZ to the back-end network

Internet orunsecured

network

TSMClient A

TSMServer

Front end

Firewall Firewall

Allowed on port TCPPORT

Prohibited on TCPADMINPORT

TSMClient B

Back-end network

Internet DMZ Intranet

Allo

wed

on

port

TCPP

ORT

Allo

wed

on

TCPA

DMIN

PORT

252 IBM Tivoli Storage Manager: Building a Secure Environment

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 sessionsIf 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 client’s dsm.opt:

SCHEDMODE POLLING

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 sessionsIf 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.

Note: If you use SCHEDMODE POLLING in a client’s 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.

Chapter 9. Deployment in a network secured environment 253

To specify client-initiated scheduled sessions, set the SCHEDMODE parameter in the client’s 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.

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.

Note: If you use SCHEDMODE PROMPTED in a client’s 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.

254 IBM Tivoli Storage Manager: Building a Secure Environment

Test scenarioOur 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 node’s 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.

Example 9-3 dsm.opt prepared for server-initiated sessions only

TCPSERVERADDRESS 192.168.99.1TCPPORT 1500TCPCLIENTADDRESS 192.168.99.236TCPCLIENTPORT 1501SESSIONINITIATION SERVERONLYPASSWORDACCESS GENERATESCHEDMODE 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 SESSION_INITIATION CLIENT_HLA CLIENT_LLA------------------ ------------------ ------------------ ------------------MYCLIENT ServerOnly 192.168.99.236 1501

tsm: TSM01>select SERVER_NAME, SERVER_HLA, SERVER_LLA from status

SERVER_NAME SERVER_HLA SERVER_LLA------------------ ------------------ ------------------TSM01 192.168.99.1 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

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.

Chapter 9. Deployment in a network secured environment 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 UtilityCommand Line Interface - Version 5, Release 4, Level 0.0(C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved.Last Updated Nov 27 2006TSM Api Verison 5.4.0

Command: Install TSM Client ServiceMachine: MYCLIENT (Local Machine)

Installing TSM Client Service:

Machine : MYCLIENT Service Name : TSM_SCHEDULER Client Directory : D:\Program Files\Tivoli\TSM\baclient Automatic Start : yes Logon Account : LocalSystem

The service was successfully installed.

Creating Registry Keys ...

Updated registry value 'ImagePath' .Updated registry value 'EventMessageFile' .Updated registry value 'TypesSupported' .

256 IBM Tivoli Storage Manager: Building a Secure Environment

Updated registry value 'TSM_SCHEDULER' .Updated registry value 'ADSMClientKey' .Updated registry value 'OptionsFile' .Updated registry value 'EventLogging' .Updated registry value '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 UtilityCommand Line Interface - Version 5, Release 4, Level 0.0(C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved.Last Updated Nov 27 2006TSM Api Verison 5.4.0

Command: Query TSM Client Service ParametersMachine: MYCLIENT(Local Machine)

Connecting to service 'tsm_scheduler' ...

Service Configuration/Status:

Service Name : tsm_schedulerImage Path : "D:\Program Files\Tivoli\TSM\baclient\dsmcsvc.exe"Logon Account : LocalSystemStart Type : AutoCurrent Status : Stopped

TSM Client Service Registry Settings:

Client Service Type = Client Scheduler ServiceOptions file = D:\Program Files\Tivoli\TSM\baclient\dsm.optEvent Logging = YESTSM Client Node = MYCLIENTComm Protocol = (value not currently set)Server = (value not currently set)Server Port = (value not currently set)Schedule Log = (value not currently set)Error Log = (value not currently set)Cluster Enabled = (value not currently set)Cluster Name = (value not currently set)

D:\Program Files\Tivoli\TSM\baclient>

6. Set the password.

Chapter 9. Deployment in a network secured environment 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 because the process is running in the background.

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 scheduleIBM Tivoli Storage ManagerCommand 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 scheduleIBM Tivoli Storage ManagerCommand 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 next scheduled event.Node Name: MYCLIENTSession established with server TSM01: Windows Server Version 5, Release 4, Level 0.0 Server date/time: 02/09/2007 00:31:33 Last access: 02/09/2007 00:31:27

Next operation scheduled:------------------------------------------------------------Schedule Name: @1Action: CommandObjects: D:\Program Files\Tivoli\TSM\baclient\dir.cmdOptions: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>nulFinished command. Return code is: 0ANS1908I 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 next scheduled event.Node Name: MYCLIENTSession established with server TSM01: Windows Server Version 5, Release 4, Level 0.0 Server date/time: 02/09/2007 00:31:35 Last access: 02/09/2007 00:31:33

Next operation scheduled:------------------------------------------------------------Schedule Name: DAILY_INCRAction: IncrementalObjects:Options:Server Window Start: 16:20:05 on 02/09/2007------------------------------------------------------------Waiting to be contacted by the server.

Chapter 9. Deployment in a network secured environment 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 UtilityCommand Line Interface - Version 5, Release 4, Level 0.0(C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved.Last Updated Nov 27 2006TSM Api Verison 5.4.0

Command: Start TSM Client ServiceMachine: 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 UtilityCommand Line Interface - Version 5, Release 4, Level 0.0(C) Copyright IBM Corporation, 1990, 2007, All Rights Reserved.Last Updated Nov 27 2006TSM Api Verison 5.4.0

Command: Query TSM Client Service ParametersMachine: MYCLIENT(Local Machine)

Connecting to service 'TSM_SCHEDULER' ...

Service Configuration/Status:

Service Name : TSM_SCHEDULERImage Path : "D:\Program Files\Tivoli\TSM\baclient\dsmcsvc.exe"Logon Account : LocalSystemStart Type : AutoCurrent Status : Started

TSM Client Service Registry Settings:

Client Service Type = Client Scheduler ServiceOptions file = D:\Program Files\Tivoli\TSM\baclient\dsm.optEvent Logging = YESTSM Client Node = MYCLIENTComm Protocol = (value not currently set)Server = (value not currently set)Server Port = (value not currently set)Schedule Log = (value not currently set)Error Log = (value not currently set)Cluster Enabled = (value not currently set)Cluster Name = (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 Local Address Foreign Address State TCP MYCLIENT:epmap MYCLIENT:0 LISTENING TCP MYCLIENT:microsoft-ds MYCLIENT:0 LISTENING TCP MYCLIENT:1030 MYCLIENT:0 LISTENING TCP MYCLIENT:1052 MYCLIENT:0 LISTENING TCP MYCLIENT:1501 MYCLIENT:0 LISTENING

e. In the dsmsched.log, you also see information that confirms the schedule is running correctly. See Example 9-18 on page 262.

Chapter 9. Deployment in a network secured environment 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 sessionBecause 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>dsmcIBM Tivoli Storage ManagerCommand 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: MYCLIENTANS1017E 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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

Client a

Client b

Front end LANBa

ck u

p LA

N

TSM server

internet

back end LAN

Internet DMZ Intranet

Chapter 9. Deployment in a network secured environment 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 IBM Tivoli Storage Manager: Building a Secure Environment

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

10

© Copyright IBM Corp. 2007. All rights reserved. 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.

10.2 Security policy considerations

Central to any security discussion is the organization’s security policy. The objective of a security policy is to provide and maintain the confidentiality, integrity, and availability of the organization’s 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 organization’s security policy is a living document and needs to be updated regularly to reflect the current risk assessment posture. A company’s business objectives and the perceived level of threat are several of the areas to consider when determining the company’s 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

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.

266 IBM Tivoli Storage Manager: Building a Secure Environment

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 company’s 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.orghttp://www.first.orghttp://csrc.ncsl.nist.govhttp://www.securityfocus.comhttp://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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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.

Chapter 10. Protecting the server 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 organization’s network.

Firewalls can generally be classified into the following types.

Packet filtering firewallThis 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 IBM Tivoli Storage Manager: Building a Secure Environment

Figure 10-1 Packet filtering firewall

Circuit level gatewayThis 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 gatewayThis 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.

Chapter 10. Protecting the server 271

Figure 10-3 Application firewall

Stateful multilayer inspection firewallThis 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 SystemsIntrusion 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 10. Protecting the server 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 point’s owner or department. Your pet’s 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.

NessusOne 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 IBM Tivoli Storage Manager: Building a Secure Environment

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/

Chapter 10. Protecting the server 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 administrator’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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 organization’s 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 organization’s 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.

Chapter 10. Protecting the server 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 organization’s 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.

AssessmentSeveral 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 organization’s 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 reportingThis 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

Chapter 10. Protecting the server 279

Manager server is broken or stolen. It also shows the effect you can get from a non-root server in a SAN environment.

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.

SecurityThe 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 instancesAnother 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

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

280 IBM Tivoli Storage Manager: Building a Secure Environment

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 PID CPU% PgSp Ownerdsmserv 50104 12.3 827.3 tsm01topas 71224 0.2 1.9 imycpperl 63218 0.0 46.2 rootsyncd 14240 0.0 0.6 rootdsmserv 44974 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 > dfFilesystem 512-blocks Free %Used Iused %Iused Mounted on/dev/tsm01homelv 1048576 818616 22% 252 1% /home/tsm01/dev/tsm01db01lv 52428800 2244136 96% 28 1% /tsm01db01/dev/tsm01log01lv 25165824 808552 97% 15 1% /tsm01log01/dev/tsm01db02lv 52428800 2244136 96% 28 1% /tsm01db02/dev/tsm01log02lv 25165824 808552 97% 15 1% /tsm01log02

/dev/tsm02homelv 1048576 905328 14% 179 1% /home/tsm02/dev/tsm02db01lv 62914560 2027464 97% 33 1% /tsm02db01/dev/tsm02log01lv 18874368 1159720 94% 12 1% /tsm02log01/dev/tsm02db02lv 62914560 2027464 97% 33 1% /tsm02db02/dev/tsm02log02lv 18874368 1159720 94% 12 1% /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% KBPS TPS KB-Read KB-Writ PageIn 0hdisk11 28.0 104.0 25.5 104.0 0.0 PageOut 0 PAGING SPACEhdisk13 21.5 72.0 20.0 72.0 0.0 Sios 0 Size,MB 4096dac0 0.0 0.0 0.0 0.0 0.0 % Used 0.6dac0-utm 0.0 0.0 0.0 0.0 0.0 NFS (calls/sec) % Free 99.3dac1 0.0 0.0 0.0 0.0 0.0 ServerV2 0dac1-utm 0.0 0.0 0.0 0.0 0.0 ClientV2 0 Press:hdisk2 0.0 0.0 0.0 0.0 0.0 ServerV3 0 "h" for helpdac2 0.0 104.0 25.5 104.0 0.0 ClientV3 0 "q" to quitdac2-utm 0.0 0.0 0.0 0.0 0.0dac3 0.0 72.0 20.0 72.0 0.0dac3-utm 0.0 0.0 0.0 0.0 0.0hdisk3 0.0 0.0 0.0 0.0 0.0

Chapter 10. Protecting the server 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 -l hdisk11hdisk11:LV NAME LPs PPs DISTRIBUTION MOUNT POINTtsm01log02lv 24 24 18..00..00..01..05 /tsm01log02jfs2log01lv 1 1 00..01..00..00..00 N/Atsm01db02lv 50 50 00..17..17..16..00 /tsm01db02tsm01homelv 1 1 00..00..00..00..01 /home/tsm01machine01:/home/user > lspv -l hdisk13hdisk13:LV NAME LPs PPs DISTRIBUTION MOUNT POINTtsm01db01lv 50 50 17..16..17..00..00 /tsm01db01tsm01log01lv 24 24 01..00..00..17..06 /tsm01log01jfs2log01lv 1 1 00..01..00..00..00 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.

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.

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.

282 IBM Tivoli Storage Manager: Building a Secure Environment

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 instanceWe 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 > lsvgrootvgtsm01vgtsm02vg

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 > lspvhdisk0 005aabbcc5dcbe51 rootvg activehdisk1 005aabbcc5dcbf43 rootvg activehdisk11 005aabbc5d912eed tsm01vg activehdisk12 005aabbc5dafb473 tsm02vg activehdisk13 005aabbc5d912d51 tsm01vg activehdisk14 00c3f33a43a6a5f6 tsm02vg activehdisk15 005aabbc5d9123b2 tsm01vg activehdisk16 005aabbc5d912550 tsm01vg activehdisk17 005aabbc5d9126f1 tsm01vg activehdisk18 005aabbc5d912881 tsm01vg activehdisk19 005aabbc5d912a12 tsm01vg activehdisk20 005aabbc5d912bb0 tsm01vg activehdisk21 005aabbc5dafaf57 tsm02vg activehdisk22 005aabbc5dafb118 tsm02vg activehdisk23 005aabbc5dafb2bb tsm02vg activehdisk2 none Nonehdisk3 none None

Chapter 10. Protecting the server 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 userTo 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 tsm01fsmount /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 usersBecause 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 usersIn 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' tsm01chown tsm01:tsm /home/tsm01chmod 750 /home/tsm01

284 IBM Tivoli Storage Manager: Building a Secure Environment

Define server db, log, and storage pool volumes and adjust accessExample 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.

Example 10-12 Create database logical volume and file system

mklv -ytsm01db01lv -tjfs2 -ex tsm01vg 278 hdisk11 hdisk13crfs -vjfs2 -dtsm01db01lv -m/tsm01db01 -An -prw -tn -u tsm01fsmount /tsm01db01chown tsm01:tsm /tsm01db01

Example 10-13 Creating a storage pool raw volume

mklv -ytsm01001lvlv -traw -ex tsm01vg 200 hdisk14chown tsm01:tsm /dev/rtsm01001lv

Permission setting for db, log, and storage pool volumesThe 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------ 3 tsm01 tsm 256 Jun 13 2006 tsm01db01-rw------- 1 tsm01 tsm 210763776 Feb 20 00:22 log01.dsmdrwx------ 3 tsm01 tsm 256 Jun 13 2006 tsm01log01-rw------- 1 tsm01 tsm 2098200576 Feb 20 00:22 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------- 1 tsm01 tsm 30, 2 Feb 14 19:41 /dev/rtsm01001lvcrw------- 1 tsm01 tsm 30, 4 Feb 14 19:47 /dev/rtsm01002lvcrw------- 1 tsm01 tsm 30, 3 Feb 12 22:51 /dev/rtsm01003lvcrw------- 1 tsm01 tsm 10, 15 Jun 13 2006 /dev/rtsm01004lvcrw------- 1 tsm01 tsm 10, 16 Jun 13 2006 /dev/rtsm01005lv

Note: In a real environment, we recommend to use either jfs2 or raw for all Tivoli Storage Manager volumes.

Chapter 10. Protecting the server 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/rtsm01001lvANR2404E DEFINE VOLUME: Volume /dev/rtsm01001lv is not available.ANS8001I Return code 14.

Adjust file permissions for the user groupSet 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.

Example 10-17 Minimum permissions for licenses

-rwxr----- 1 root tsm 800 Dec 08 2004 dataret.lic-rwxr----- 1 root tsm 831 Dec 08 2004 tsmbasic.lic-rwxr----- 1 root tsm 834 Dec 08 2004 tsmee.lic-rwxr-x--- 1 root tsm 1167004 Dec 08 2004 dsmlicense

Example 10-18 Wrong permissions for tsmbasic.lic

ANR2017I Administrator ADMIN issued command: REGISTER LICENSE FILE=tsmbasic.licANR9625E Could not open file /usr/tivoli/tsm/server/bin/tsmbasic.lic.

Configuration filesThe 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.

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.

286 IBM Tivoli Storage Manager: Building a Secure Environment

Example 10-19 Content of /home/tsm01/config

-rw-r----- 1 tsm01 tsm 3048 Feb 23 06:01 devconf-rw-r--r-- 1 tsm01 tsm 1086 Sep 26 2001 dsm.opt-rw-r----- 1 tsm01 tsm 137 Feb 20 00:40 dsmserv.dsk-rw-r--r-- 1 tsm01 tsm 52498 Sep 21 2004 dsmserv.optdrwxr-sr-x 2 tsm01 tsm 59904 Feb 23 14:00 log-rw-rw---- 1 tsm01 tsm 10465 Feb 20 00:39 nodelock-rw-rw---- 1 tsm01 tsm 6401 Feb 23 12:02 volhist

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/volhistDEVCONFIG /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/binexport DSMSERV_CONFIG=~/config/dsmserv.optulimit -d unlimitedexport LANG=en_USdsmserv

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.

Chapter 10. Protecting the server 287

Example 10-23 A sample script to start dsmserv

#!/bin/ksh## Variables and initialization#

# check TSM administrator IDtsm_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 codeexport DSMSERV_DIR=/usr/tivoli/tsm/server/bin

# environment variable for dsmserv.optexport DSMSERV_CONFIG=/home/$tsm_admin/config/dsmserv.opt

echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $LOGecho "+ STARTING start_tsm ..." `date` >> $LOGecho "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $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 2else 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 dsmservexit 0fi

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 IBM Tivoli Storage Manager: Building a Secure Environment

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/6000Version 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 disclosurerestricted 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: HALTANR0991I 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

Chapter 10. Protecting the 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 errorsexport DSM_CONFIG=/home/$user/config/dsm.opt# check for executing user IDrm /tmp/${user}.PIDdsmadmc -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 IBM Tivoli Storage Manager: Building a Secure Environment

Part 4 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.

Part 4

© Copyright IBM Corp. 2007. All rights reserved. 291

292 IBM Tivoli Storage Manager: Building a Secure Environment

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

� Recovery of a component of the Tivoli Storage Manager server:

– 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

� Complete recovery of the Tivoli Storage Manager server:

– 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

11

© Copyright IBM Corp. 2007. All rights reserved. 293

� 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 executive’s 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

Figure 11-1 Seven tiers of disaster recovery

A breakdown of the seven tiersIn 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 today’s disaster recovery capabilities. They need only to be updated for today’s 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.

Recovery Time Objective 15 Min. 1-4 Hr.. 4 -8 Hr.. 8-12 Hr.. 12-16 Hr.. 24 Hr.. Days

Valu

e (C

ost)

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 7 Site Mirroring with automated recovery

BC Tier 6 Storage mirroring (with or without automation)

BC Tier 5 Software mirroring (transaction integrity)

BC Tier 1 Restore from Tape

Recovery from a disk image Recovery from tape copy

Chapter 11. Providing a secure disaster recovery environment 295

BC Tier 0: No off-site dataBusinesses 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 siteBusinesses 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 solutionsSolutions 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 siteBusinesses 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 solutionsSolutions 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 vaultingThe 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 solutionsSolutions 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 copiesBC 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 solutionsSolutions 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 integrityTier 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 solutionsSolutions include software, two-phase commit, such as DB2® remote replication, MQSeries®, or Oracle DataGuard.

BC Tier 6: Zero or little data lossTier 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 solutionsSolutions 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 solutionTier 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.

Chapter 11. Providing a secure disaster recovery environment 297

Disaster recovery solutionsSolutions 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 solutionIt 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 vendor’s 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 vendor’s 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.

1 The Global State of Information Security, written by Scott Berinato with Research Editor Lorraine

Cosgrove Ware, September 15, 2005

Chapter 11. Providing a secure disaster recovery environment 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 dataAs 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 site’s 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.

Nodes

Tape Library

Tape Library

Production Data Center Hot-site Data Center

FC San

TSM ServerTSM Server

Nodes

Disk SystemDisk System

Chapter 11. Providing a secure disaster recovery environment 301

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 provider’s 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.

Nodes

Tape Library

Tape Library

Production Data Center Warm-site Data Center

Private

IP

ISCSI

SAN

Network

TSM ServerTSM Server

Nodes

Disk SystemDisk System

302 IBM Tivoli Storage Manager: Building a Secure Environment

11.2.5 Summary

With security factors, along with your company’s 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 encryptOutside 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.

Chapter 11. Providing a secure disaster recovery environment 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 riskIn 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)

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 encryptionAdvanced 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.

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

304 IBM Tivoli Storage Manager: Building a Secure Environment

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).

Steps to reduce riskClient 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:

Steps to reduce riskClient 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)

Tivoli Storage Manager client API encryptionAES-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.

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.

Note: DRM tracks the tape movement states that we just listed as:

� NOTMOUNTABLE� COURIER � VAULT� VAULTRETRIEVE� COURIERRETRIEVE� ONSITERETRIEVE

Chapter 11. Providing a secure disaster recovery environment 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.

Steps to reduce riskClient 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.

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.

Note: DRM tracks the tape movement states that we just listed as:

� NOTMOUNTABLE� COURIER � VAULT� VAULTRETRIEVE� COURIERRETRIEVE� ONSITERETRIEVE

306 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Steps to reduce riskWhen 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).

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.

Note: DRM tracks the tape movement states that we just listed as:

� NOTMOUNTABLE� COURIER � VAULT� VAULTRETRIEVE� COURIERRETRIEVE� ONSITERETRIEVE

Chapter 11. Providing a secure disaster recovery environment 307

The keys and passwords for these encryption types are managed within EKM’s 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.

Steps to reduce risk

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)

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.

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.

Note: DRM tracks the tape movement states that we just listed as:

� NOTMOUNTABLE� COURIER � VAULT� VAULTRETRIEVE� COURIERRETRIEVE� ONSITERETRIEVE

308 IBM Tivoli Storage Manager: Building a Secure Environment

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 encryptionIf 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 serverIf 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.

Chapter 11. Providing a secure disaster recovery environment 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.

Figure 11-4 Server-to-server virtual volumes

Potential risks using virtual volumesVirtual 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.

UNIX WindowsOther Platforms

IBM Tivoli Storage Manager source server

IBM Tivoli Storage Manager target server

LAN/WANTCP/IP

IBM Tivoli Storage Manager clients

Data Flow

(Local) (Remote)

Primary Storage PoolDatabase BackupCopy Storage PoolDisaster Recovery Plan File

Virtual Volumes

310 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Steps to reduce riskTo 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

Chapter 11. Providing a secure disaster recovery environment 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.

Steps to reduce riskUse 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 IBM Tivoli Storage Manager: Building a Secure Environment

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).

Steps to reduce riskBackup 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.

Steps to reduce riskActive-data storage pool tapes can be stored off-site. This presents a security risk, therefore, here are recommendations to reduce this risk:

Chapter 11. Providing a secure disaster recovery environment 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 typesIf you do not want to use the tape again, it must be either destroyed or degaussed.

Should you use a vendor for tape disposalMany vendors offer media collection and destruction services. However, this moves a critical security step outside your company’s 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.

Chapter 11. Providing a secure disaster recovery environment 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 erasingA 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.

IncinerationIncineration 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 commandsMany 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Chapter 11. Providing a secure disaster recovery environment 317

318 IBM Tivoli Storage Manager: Building a Secure Environment

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 today’s 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 staff’s 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.

12

© Copyright IBM Corp. 2007. All rights reserved. 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 enterprise’s 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.

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.

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.

320 IBM Tivoli Storage Manager: Building a Secure Environment

– 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 stepsWe 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)

– 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:

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 riskDetermine the content of the missing volume and take the appropriate business and legal action based on the lost data.

Recommended steps to offset future risksWe 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

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.

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.

322 IBM Tivoli Storage Manager: Building a Secure Environment

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.

Recommended resolution stepsWe 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)

Chapter 12. Recovery and prevention of security breaches or data loss 323

– 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.

9. After exhausting your options or the tape was damaged, perform the following steps:

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

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.

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.

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.

324 IBM Tivoli Storage Manager: Building a Secure Environment

� 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.

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

Recommended steps to offset future risksWe 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.

Chapter 12. Recovery and prevention of security breaches or data loss 325

� The tape volume was ejected using library device driver commands.

Recommended resolution stepsWe 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)

– 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.

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>

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.

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.

326 IBM Tivoli Storage Manager: Building a Secure Environment

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.

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

Recommended steps to offset future risksWe 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.

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.

Chapter 12. Recovery and prevention of security breaches or data loss 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.

Recommended resolution stepsIf 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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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 riskIf 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 the common password expiry value:

• RESET PASSWEXPIRY

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.

Chapter 12. Recovery and prevention of security breaches or data loss 329

Nevertheless, the other information contained within the stolen database might be deemed a security risk, according to your organization’s policy.

Recommended steps to offset future risksWe 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?

Recommended resolution stepsWe 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 IBM Tivoli Storage Manager: Building a Secure Environment

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 stolenRisks 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.

Chapter 12. Recovery and prevention of security breaches or data loss 331

Recommended steps to offset current risksThe 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).

Recommended steps to offset future risksWe 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.

Recommended resolution stepsThere 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 setThe 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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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 risksDetermine the content of the missing volume and take the appropriate business and legal action based on the lost data.

Recommended steps to offset future risksWe 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.

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.

Recommended steps to offset future risksThe 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).

Note: As always, pay attention to capacity planning to avoid experiencing a library full condition.

Chapter 12. Recovery and prevention of security breaches or data loss 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.

Recommended steps to offset future risksImplement 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 IBM Tivoli Storage Manager: Building a Secure Environment

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.

13

© Copyright IBM Corp. 2007. All rights reserved. 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 IBM Tivoli Storage Manager: Building a Secure Environment

� 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:

– 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.

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.

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 IBM Tivoli Storage Manager: Building a Secure Environment

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 IBM Tivoli Storage Manager: Building a Secure Environment

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 RedbooksFor 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 publicationsThese 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 User’s Guide V5.4, SC32-0145

© Copyright IBM Corp. 2007. All rights reserved. 341

� IBM Tivoli Storage Manager for Windows Backup Archive Clients Installation and User’s Guide, SC32-0146

� IBM Tivoli Storage Manager for Windows Backup Archive Clients Installation and User’s Guide, SC32-0144

� IBM Tivoli Storage Manager Using the Application Program Interface, SC32-0147

� IBM Encryption Key Manager - Introduction, Planning and User’s 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 User’s 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 resourcesThese 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.orghttp://www.first.orghttp://csrc.ncsl.nist.govhttp://www.securityfocus.comhttp://www.sans.org

� OpenSSH

http://www.openssh.org

� TS1120 information

http://www.ibm.com/systems/storage/tape/

342 IBM Tivoli Storage Manager: Building a Secure Environment

� EKM

http://www.ibm.com/support/docview.wss?&uid=ssg1S4000504

� Keytool User Guide

http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/keytoolDocs/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 IBMIBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services

Related publications 343

344 IBM Tivoli Storage Manager: Building a Secure Environment

Index

Symbols/etc/ibmekm.conf 148

Aaccess controls 34access permissions 39accounting records 176ACL 270Active Directory 269active-data storage pool 228, 313, 325activity log 173ACTLOG event receiver 177ad hoc mode 273adddrive 137ADMIN_CENTER ID 169administrative authorities 26administrative sessions 28administrator roles 172administrators 38ADMINONCLIENTPORT 250AES 17, 115AES128 19, 82, 188AIX

topas 281allow clients to delete archives 183allow clients to delete backups 183ALMS 125API client encryption 82, 100

application managed encryption 100transparent encryption 101

API file access 43application firewall 271Application-Managed Encryption 114, 121, 126, 306ASIC 115asymmetric encryption 17–18, 117asymmetric key encryption 17asynchronous data replication 301Atape device driver 124, 147

proxy configuration file 148audit trail 172authentication 24authentication methods 60authority of scheduled commands 69authorized user 34, 39, 41, 52availability 4, 266

Bbackup Network File System 56Backup Operators group 38backupset security 312Barcode Encryption Policy 123, 142BEP see Barcode Encryption Policybuffer 24

© Copyright IBM Corp. 2007. All rights reserved.

business continuity 277Business Impact Analysis 279

Ccategorize data 303CDP 314Certificate Authority 18certificate labels 138change management 278CIFS 53cipher text 16circuit level gateway 271Client Acceptor Daemon 47, 51–52client access privilege 26, 39, 167

See also Web clientclient authentication 24, 60client authentication methods 60client compression 88client encryption 82, 198client key management 90client option set 76client owner privilege 26, 39, 167

See also Web clientclient password 60client registration 182client scheduling modes 184client services and daemons 47client sessions 27client thread types 29client threads

multiple 28client transaction 31client-initiated communication 249, 252CLIENTORSERVER 253client-server communication 26closed client registration 182clustering 277cold site 296, 302command action schedules 68command line authentication 24command routing 191compression 231, 235confidentiality 4, 266configuration manager 194configure SSL ISC communication 210connect with TSM administrator ID 205CONSOLE event receiver 177Consumer thread 28–29copy storage pool 228, 244, 320copy storage pool security 311CRC 311Cristie BMR 305–306cross client restore 70

345

Ddapismp 102data categorization 303data encryption keys 89data movement 13data shredding 237data transport 7deactivated nodes 74degaussing 245, 315–316DES 13, 17DES56 19, 82, 188digital certificate 18disaster recovery 277Disaster Recovery Manager 6, 15disaster recovery planning 295disaster recovery tiers 295disk quota 49disk storage pool 229DK 117DMZ 248, 277DOO 298DRIVEENCRYPTION 114, 123–124, 143, 306–307dsmapi 208dsmfmt 285

EEAP 274EEDK 117, 143EKM 113–114, 198EKM configuration file 132EKM Jar file 131electronic vaulting 296, 299, 301enabling client encryption 91enabling for client 91encryption 12, 16, 82, 91, 114, 231, 303, 337

asymmetric 117best practices 153Certificate Authority 18data encryption keys 89digital certificate 18hardware 16HSM 112include/exclude statements 91key management 88key manager 18, 114, 129keystore 18, 117, 132LAN-free 112managing client keys 90offsite encryption and password handling 308offsite tapes 303performance overhead 105policy 119recovery 334server-to-server communication 188session keys 88session traffic 82software 16symmetric 17, 115, 117Tivoli Storage Manager API client 82, 100, 305

Tivoli Storage Manager client 19, 198, 236, 304TS1120 114with ALMS 125with compression 88with long-term data retention 90

Encryption Key Manager 113–114, 116, 307adddrive command 137backup and recovery 152certificate labels 138components 118configuration file 118, 132, 134configure devices 140configuring 129connectivity test 140Data Key 117define tape drives 137DR considerations 152EEDK 117, 143expired certificates 139high availability 118Internal Label Encryption Policy 143Jar file 131Java security keystore 118KEK 117Key Labels 117KeyManagerConfig.properties 134keystore 117–118, 132, 308keystore password 132, 154keytool 132manage expired certificates 139multiple servers 118proxy configuration file 148Public Key 117recover configuration 152register server with tape library 139self-signed certificates 133start server 135synchronize configuration 152System-Managed Encryption 147, 322, 325tape drive table 118, 155tape library/drive configuration 140unrestricted policy files 131

encryption policy configuration 119ENCRYPTKEY 91, 334ENCRYPTKEY PROMPT 88–89ENCRYPTKEY SAVE 88environmental threats 5EOD 314erase media 245event receivers 177Event Server 177expired password 63external threats 5

FFibre Channel 11Fibre Channel Network Extender 12FILE event receiver 177filetext exit event receiver 178firewall 13, 248

346 IBM Tivoli Storage Manager: Building a Secure Environment

application 271packet filtering 270stateful multilayer inspection 272

force password reset 183FROMNODE 70, 72

GGDPS 297Global Copy, FlashCopy 297Global Mirror 297

HHACMP 277HACMP/XD 297hardware encryption 16HIPAA 3HLADDRESS 254hot site 296, 299–300HSM encryption 112

IIBMi5OSKeyStore 118IBMKeyManagementServer.jar 131IDS 272IIS 270ILM 303infrastructure mode 273initiating scheduled sessions 252Integrated Services Console see ISC 169integrity 3, 266Internal Label Encryption Policy 143internal threats 5INVALIDPWLIMIT 67IPS 272IPSec 12–13ISC 202, 205

add administrators 202ADMIN_CENTER ID 169configure SSL communication 210SSL connection 207

iSCSI 296ITIL 278

JJACL 221Java runtime environment 129Java security keystore 118JCE4758KS/JCECAAKS 118JCE4785RACFKS/JCECCARACFKS 118JCEKS 118, 130, 134JCERACFKS 118JRE 129

KKEK 117Kerberos 269Key Labels 117

key management 88key manager 18, 114, 129KeyManagerConfig.properties 134keystore 18, 117–118, 132, 308keytool 132

LLAN-free encryption 112LDAP 269LEAP 274least privilege 160Library-Managed Encryption 115, 123, 141, 307–308, 311–314, 317Linux

Network File System 56operating system security 268Tivoli Storage Manager services 51

LLADDRESS 254Local Service account 48Local System account 48, 52, 54lock cipher 19lost copypool tape 322lost or compromised data 300

MMain thread 29manage administrative IDs 195MANAGEDSERVICES 25, 51managing client keys 90Man-in-the-Middle network attack 303MAXNUMMP 30MAXSESSIONS 30MBSA 270media security 338Metro Copy 297Metro Mirror 297Migration Manager 297minimum password length 182MINPWLENGTH 67, 183mirrored database and log 300missing active-data tape 325missing backupset 332missing primary tape 323missing storage pool volumes 320MMC 199multi-mode fibre 11multi-session clients 28multi-session function 29

NNDMP 53Nessus 274Network File System 56network interface devices 8network security 4, 270NFS 56node

deactivated 74

Index 347

non-authorized user 36, 40non-client sessions 27NRO 298NT EventLog event receiver 180

Ooffsite data movement 15offsite data vaulting 298offsite location 5offsite tape rotation 6offsite vaulting 15onsite data movement 14open client registration 182OpenSSL 18operating system security 4, 267operating system users 34Operational Reporting 198OSI 7

physical layer 1 10overwritten tape media 314ownership 39

Ppacket filtering firewall 270PASSEXP 67password 60password expiry 63, 182password file 35, 63password file permissions 63password policy 267password processing 61password rules 67PASSWORDACCESS GENERATE 35, 43, 51–52, 60–61, 70PASSWORDACCESS PROMPT 61Performance Monitor thread 29PKCS11|mplKS 118plaintext 16point-in-time copies 296policy management 196polling scheduling 184POSTNSCHEDULECMD 68, 185POSTSCHEDULECMD 68, 185POSTSNAPSHOTCMD 68PRENSCHEDULECMD 68, 185PRESCHEDULECMD 68, 185PRESNAPSHOTCMD 68prevent client-initiated sesions 186primary storage pool 228principle of least authority 160private-key cryptography 17Producer thread 28–29prompted scheduling 184, 251proxy node 73PTAM 296, 302Public Key 117Public/Private Key pair 132

QQUERYAUTH 170, 173QUERYSCHEDPERIOD 184

RRAID 277reclamation 245Redbooks Web site 343

Contact us xviiiregulations

lost or compromised data 300regulatory compliance 3, 320remote access 70removable media 6rename node 75REQSYSAUTHOUTFILE 170RESOURCEUTILIZATION 29–31REVOKEREMOTEACCESS 70root access 45, 267RPO 298RTO 298–299, 301run as non-root 279

SSACL 38SAN 6

security 337tape and data security 309

Sarbanes-Oxley 3, 267SCHEDCMDDISABLED 68, 186SCHEDCMDUSER 68–69SCHEDMODE 251, 253SCHEDRESTRETRDISABLED 69, 186schedule pre/post commands 68scheduled client operations 185scheduled command authority 69scheduled commands 68scheduled restores 69scheduler authentication 25scheduler password 258scheduler service 256scheduling modes 184Scratch Encryption Policy 123, 142scratch tape 314SCW 269security 202

availability 266breaches 319confidentiality 266data center 5disk storage 6firewall 13human aspects 276integrity 266media 338network 4, 270objectives 3operating system 4, 267SAN 6

348 IBM Tivoli Storage Manager: Building a Secure Environment

social engineering 276storage 6threats 5wired network 270wireless network 273

security audit 278, 335security compliance 3security objectives 3–4Security Policy 266see EKMself-signed certificates 133server name 183server stanzas 62server summary table 174server to server communication 188SERVER_CONSOLE ID 169server-initiated communication 249, 252–253SERVERONLY 253server-to-server communication 16, 188, 310server-to-server sessions 28session and transaction concepts 28session control 184session encryption 82session initiation 186, 252session keys 88session owner 41, 43session traffic encryption 82session types 27SESSIONINITIATION 186, 251, 253–254SET AUTHENTICATION 60shared drives 52short-wave 11shredding media 316SIEM 273, 275Signal Waiting thread 29single-mode fibre 12SME see System-Managed Encryption 115SNMP 27SNMP event receiver 178SOAP 222social engineering 276software encryption 16SONET 12source server 310SRVPREPOSTSCHEDDISABLED 68, 186SRVPREPOSTSNAPDISABLED 186SSID 273SSL 12, 207, 210, 269, 309stateful multilayer inspection firewall 272stolen copypool tape 322stolen Tivoli Storage Manager server 330Storage Agent 249storage media 6storage pool 228

for tape encryption 126storage pool format 228storage pool volume

missing 320storage pool volume permissions 235SUID 24

suid 24superuser 34symmetric encryption 17, 115, 117sys_encryption 149System State 51System-Managed Encryption 115, 124, 147, 307, 322, 325

Ttape drive 114tape drive encryption 114tape drive table 118, 155tape encryption 235

encryptiontape 19

tape storage pool volume 230tape vaulting 299tapeutil 231, 245, 333target server 310TCPADMINPORT 251TCPCLIENTADDRESS 251, 254TCPCLIENTPORT 249, 251, 254TCPPORT 250TDES 13Tivioli Storage Manager

scheduled restores 69Tivoli Continuous Data Protection 314Tivoli Security Compliance Manager 275Tivoli Security Operations Manager 273, 275Tivoli Storage Manager 56, 60, 91, 279, 300

access controls 34access permissions 39accounting records 176active-data storage pool 228, 313activity log 173ACTLOG event receiver 177ADMIN ID 169ADMIN_CENTER ID 169administrative authorities 26administrative IDs 168, 336administrative port 251administrative privilege 170administrative roles 160administrative sessions 28administrator roles 172administrators 38allow clients to delete archives 183allow clients to delete backups 183allow only root access 45analyst privilege 167API client encryption 82, 100, 305API file access 43Application-Managed Encryption 121, 126, 306audit trail 172authentication 24, 60authority of scheduled commands 69authorized user 35, 39, 41, 52backup shared drives 52backupset security 197, 312Client Acceptor Daemon 47, 51–52

Index 349

client access privilege 26, 39, 167client authentication 24client authentication methods 60client encryption 19, 82, 198, 231, 236, 304client key management 90client option set 76client owner privilege 26, 39, 167client port 250client registration 182client scheduler 47client scheduling modes 184client services and daemons 47client sessions 27client thread types 29client-initiated communication 249, 252client-server communication 26closed client registration 182clustering 277command action schedules 68command line authentication 24command routing 191compression 88, 231, 235configuration manager 194CONSOLE event receiver 177Consumer thread 28control authentication 182copy storage pool 228, 244, 300copy storage pool security 311cross client restore 70data encryption keys 89data movement 13data shredding 237data transport 7database backup 301database backup security 311deactivated nodes 74default administrative privilege 160default administrator 169disable passwords 182Disaster Recovery Manager 6, 15, 296, 301disk storage pool 229DMZ 248DMZ best practices 262enable passwords 182encryption 16encryption key management 88encryption nclude/exclude statements 91encryption performance overhead 105event receivers 177Event Server 177expired password 63exported data security 197FILE event receiver 177file ownership 39filetext exit event receiver 178force password reset 183high availability 277HSM encryption 112initiating scheduling sessions 252ISC security 202

LAN-free encryption 112Library-Managed Encryption 123, 143, 307–308, 311–314, 317lost client encryption key 334manage administrative IDs 195manage policies 196managing client keys 90minimum password length 182mirror database and recovery log 277missing storage pool volumes 320multiple server instances 280Network File System 56NFS 56node privilege 167non-authorized user 40non-client sessions 27non-root 279NT Event Log receiver 180offsite data movement 15offsite vaulting 15onsite data movement 14open client registration 182Operational Reporting 198operator privilege 166overwriting tapes 314password 60password expiry 63, 182password file 35, 63password file permissions 63password processing 61password rules 67policy management 196policy privilage 161polling scheduling 184prevent client-initiated sessions 186prevent schedule restore 69primary storage pool 228Producer thread 28profile associations 197profiles 194prompted scheduling 184, 251protect client encryption password 309protect UNIX/Linux client files 45protecting data in storage pools 244proxy node 73QUERY and SELECT commands 170receive events 177reclamation 245remote access 70rename node 75reporting 199restore to another client 70restrict access 69restricted policy privilege 162restricted storage privilege 164, 172run as regular Windows account 48schedule authentication 25schedule pre/post commands 68scheduled client operations 185scheduled command authority 69

350 IBM Tivoli Storage Manager: Building a Secure Environment

scheduled commands 68scheduler 51scheduler password 258scheduler service 256scheduling modes 184securing a network of servers 188security audit 335security objectives 3server access control 181server name 183server password 183server security considerations 266server stanzas 62server summary table 174SERVER_CONSOLE ID 169server-initiated communication 249, 252–253server-to-server communication 16, 188, 310server-to-server sessions 28session control 184session encryption 82session initiation 186, 252session keys 88session owner 41, 43session traffic encryption 82session types 27set authentication 182shared drives 52SNMP event receiver 178special administrative IDs 169SQL interface 173SQL SELECT statements 173SSL ISC communication 210start and stop scripts 287stolen database backup tape 328stolen server 330Storage Agent 249storage pool 228storage pool format 228storage pool protection 245storage pool volume permissions 235storage privilege 163summary table 174system privilege 160, 172System-Managed Encryption 124, 150, 307tape drive encryption 114tape encryption 19, 235tape storage pool volume 230tasks 43TCP/IP ports 249test encryption 143transaction 31Trusted Communication Agent 64unrestricted policy privilege 161unrestricted storage privilege 163UserExit 178verify encryption 150virtual nodename 70virtual volume 191, 309volume permissions 285Web client agent 47

Web client authentication 25write to a system file 170

Tivoli Storage Manager client 82, 231topas 281transaction

client 31transaction integrity 297Trusted Communication Agent 64TS1120 19

Application-Managed Encryption 121, 126encryption options 119encryption settings 149Library-Managed Encryption 123System-Managed Encryption 124tape encryption 235

TS1120 Tape Drive 115TS1120 tape drive encryption 114TS3500

ALMS 125Barcode Encryption Policy 142configure Library-Managed Encryption 141System-Managee Encryption 147

types of users 34

Uunauthorized tape access 333UNC 53UNIX

client files 45Network File System 56operating system security 268Tivoli Storage Manager services 51

unrestricted policy files 131Unshielded Twisted Pair (UTP) 10UserExit 178users

authorized 34, 39, 41, 52non-authorized 36, 40superuser 34types 34Windows 37

Vvirtual nodename 70virtual volume 191, 309–310VIRTUALNODE 39VIRTUALNODENAME 70VPN 12

Wwarm site 296, 299, 301Web client

access 70administrative authorities 26administrative ID 65agent 47authentication 25client access privilege 26, 39

Index 351

client owner privilege 26, 39userid 26

WEP 273Windows

ACL 270Active Directory 269Backup Operators group 38disk quota 49Event Log 180IIS 270Local Service account 48Local System account 48, 52, 54MBSA 270SCW 269security 269shared drives 52System State 51Tivoli Storage Manager services 47

Windows users 37wireless access point 273wireless network security 273wirred network security 270WPA 273wrt_encryption 149

Zz/OS Global Mirror 297

352 IBM Tivoli Storage Manager: Building a Secure Environment

(0.5” spine)0.475”<

->0.873”

250 <->

459 pages

IBM Tivoli Storage M

anager: Building a Secure Environment

IBM Tivoli Storage M

anager: Building a Secure Environm

ent

IBM Tivoli Storage M

anager: Building a Secure Environm

ent

IBM Tivoli Storage M

anager: Building a Secure Environment

IBM Tivoli Storage M

anager: Building a Secure Environm

ent

IBM Tivoli Storage M

anager: Building a Secure Environm

ent

®

SG24-7505-00 ISBN 0738489263

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

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

IBM Tivoli Storage ManagerBuilding 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 enterprise’s 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 enterprise’s 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.

Back cover